Re: Traffic Ops profile import/export format

2018-09-17 Thread Robert Butts
>So actually we don't really need to add a new API endpoint at all Sure. I don't object to renaming, if people want to. But the existing one does work, yes. >Those endpoints should be sufficient enough to support the legacy format import/export There's no reason to support legacy export, just im

Re: Traffic Ops profile import/export format

2018-09-17 Thread Rawlin Peters
So actually we don't really need to add a new API endpoint at all if my understanding is correct. We currently have /api/*/profiles/:id/export and /api/*/profiles/import. Those endpoints should be sufficient enough to support the legacy format import/export without the need for new endpoints, right

Re: Traffic Ops profile import/export format

2018-09-17 Thread Robert Butts
>It just seems wrong to me to add a new API endpoint to support a deprecated format. So people who've exported their data are just out of luck? We just "don't support" migrating your data forward? It seems egregiously wrong to me _not_ to support importing old data, for any app or service, ever. I

Re: Traffic Ops profile import/export format

2018-09-17 Thread Rawlin Peters
It just seems wrong to me to add a new API endpoint to support a deprecated format. There's much more involved in maintaining an API endpoint as opposed to a one-off script to convert formats. IMO if we do add a new endpoint just to support the deprecated legacy format, then it should also be marke

Re: Traffic Ops profile import/export format

2018-09-17 Thread Robert Butts
>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

Re: Traffic Ops profile import/export format

2018-09-17 Thread Rawlin Peters
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 wrote: > > Ah, e

Re: Traffic Ops profile import/export format

2018-09-17 Thread Robert Butts
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

Re: Traffic Ops profile import/export format

2018-09-17 Thread Dan Kirkwood
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

Re: Traffic Ops profile import/export format

2018-09-17 Thread Jeremy Mitchell
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 pro

Re: ATC Fall Summit 2018 - Registration and CFP

2018-09-17 Thread Dave Neuman
Hey All, We are now a little less than a month away from our Fall Summit! If you are planning on coming and haven't registered yet, please do so here: https://cwiki.apache.org/confluence/display/TC/ATC+Autumn+Summit+-+October+2018%2C+Denver%2C+CO

Re: Traffic Ops profile import/export format

2018-09-17 Thread Robert Butts
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 pa

Re: [EXTERNAL] Re: Removing uid and gid from user

2018-09-17 Thread Robert Butts
>the "confirmLocalPasswd" field (and related db column) should also be deprecated +1 On Sat, Sep 15, 2018 at 3:29 PM Dan Kirkwood wrote: > +1 on this plan -- remove UID/GID from the db, keep (deprecated) in the API > until the next major version of the API. > > Sorry to add to it, but the "co