>Do we really want to add a new API endpoint just to support the legacy format
An endpoint and UI page are easier to use for Self-Service CDN consumers. Some CDN tenants might not know how to run a script or use a command line. I'm not sure I understand the objection. Why is it such a big deal to add an endpoint? And/or to support importing old formats? IMO importing old data formats should be a first-class citizen, in any API or UI. Data jails are bad. >traffic_ops/app/bin/config2json The difference is that the TO config is used by system administrators. As Self-Service moves forward, profiles and other API data will be used by CDN tenants, who may have very little technical knowledge. We need to make sure anything a Self-Service tenant may need to do has a simple graphical way to do it, and also an API so people deploying TC can write their own UIs if necessary. On Mon, Sep 17, 2018 at 1:23 PM Rawlin Peters <rawlin.pet...@gmail.com> wrote: > Do we really want to add a new API endpoint just to support the legacy > format? Couldn't we just provide a script that converts between the > two formats, similar to what we did for cdn.conf with > traffic_ops/app/bin/config2json? > > - Rawlin > On Mon, Sep 17, 2018 at 11:04 AM Robert Butts <r...@apache.org> wrote: > > > > Ah, excellent. It wasn't clear from the docs that `POST > /api/1.2/profiles` > > and `GET /api/1.2/profiles/:id` accept parameters. We should fix that. > > > > That said, I would be in favor of adding a new endpoint, to import in the > > old format, `/api/profile/import-legacy` or something. Just so people > with > > old exports can import them back in. Data jails are bad (I know it's > > human-readable and not that difficult to convert, but it'd still be > > frustrating). > > > > I made Github issues for both: > > https://github.com/apache/trafficcontrol/issues/2827 > > https://github.com/apache/trafficcontrol/issues/2826 > > > > On Mon, Sep 17, 2018 at 10:08 AM Dan Kirkwood <dang...@gmail.com> wrote: > > > > > yes -- that's really what I meant. Import/Export should not be a > separate > > > operation as documented here: > > > > > > > https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/default_profiles.html?highlight=import > > > , > > > but should be part of the "normal" API. The default profile files we > keep > > > in http://trafficcontrol.apache.org/downloads/profiles/ are in the > format > > > I'm describing. They should be in the more standard form and should > > > associate all parameters in the file with the profile. > > > > > > The Go `POST api/1.3/profiles` endpoint already loads the parameters > into > > > memory, but ignores the parameters list. > > > > > > -dan > > > > > > On Mon, Sep 17, 2018 at 9:58 AM Jeremy Mitchell <mitchell...@gmail.com > > > > > wrote: > > > > > > > Maybe this is what Dan said but imo there should be no import/export > > > > endpoints but these should do the job: > > > > > > > > GET /api/*/profiles/:id <-- this is essentially an export. it gives > you > > > the > > > > json of a profile (along with all the parameters). save the json to a > > > file > > > > and you've essentially exported the profile. > > > > POST /api/*/profiles <-- this is how you create profiles. if you > supply > > > > parameters as well you've essentially done an import. > > > > > > > > jeremy > > > > > > > > > > > > > > > > On Mon, Sep 17, 2018 at 9:16 AM Robert Butts <r...@apache.org> wrote: > > > > > > > > > Can you clarify, are you referring to `/profile/import` and > > > > > `/profile/:id/export`? Or `/api/$version/profiles/:id/export` and > > > > > `/api/$version/profiles/import`? > > > > > > > > > > We should definitely deprecate and remove the non-API endpoints. > But > > > IMO > > > > we > > > > > need to keep a way to create and get an entire profile, with > > > parameters, > > > > in > > > > > a single request. Users shouldn't have to make a dozen requests to > > > import > > > > > and export a profile. > > > > > > > > > > Also +1 on changing them to real booleans (not sure if the api > > > > > export/import is, they appear to be undocumented). Though we can't > > > break > > > > > the current API; we could make the POST accept either, but the GET > > > would > > > > > have to be a new endpoint I think. > > > > > > > > > > > > > > > On Sat, Sep 15, 2018 at 3:15 PM Dan Kirkwood <dang...@apache.org> > > > wrote: > > > > > > > > > > > I’d like to propose deprecating the import/export format of > profiles. > > > > The > > > > > > current format (Perl-based) is inconsistent with the standard > POST > > > > > > api/x.x/profiles format. Import/Export can/should be done using > the > > > > same > > > > > > API. Traffic Portal Import should use the standard API > endpoint. > > > > > > > > > > > > Import/export (shown below) has this form which includes the > > > "profile" > > > > > key > > > > > > at the top level. The "secure" option in the "parameters" secion > > > uses > > > > a > > > > > > 0/1 rather than a boolean true/false. These 2 things make it > > > > > inconsistent. > > > > > > > > > > > > Opinions are welcome... > > > > > > > > > > > > Dan > > > > > > > > > > > > { > > > > > > "profile": { > > > > > > "name": "myname", > > > > > > ... > > > > > > }, > > > > > > "parameters": [ > > > > > > { > > > > > > "name": "foo", > > > > > > "secure": 0, > > > > > > ... > > > > > > ] > > > > > > } > > > > > > > > > > > > > > > > > > >
