16:00:17 <elmiko> #startmeeting api wg
16:00:19 <openstack> Meeting started Thu Feb 25 16:00:17 2016 UTC and is due to finish in 60 minutes.  The chair is elmiko. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:22 <cdent> o/
16:00:23 <openstack> The meeting name has been set to 'api_wg'
16:00:26 <elmiko> #chair cdent
16:00:27 <openstack> Current chairs: cdent elmiko
16:00:36 <elmiko> #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
16:00:52 <elmiko> maybe give a few minutes for folks to arrive
16:01:09 <stevelle> o/
16:01:54 <elmiko> #topic previous meeting action items
16:02:00 <elmiko> #link http://eavesdrop.openstack.org/meetings/api_wg/2016/api_wg.2016-01-28-16.00.html
16:02:30 <elmiko> hmm, that's an old meeting
16:02:41 <elmiko> i *think* we got all those items though
16:03:10 <cdent> yeah, thus the confusion about the accuracy of the agenda
16:03:15 <elmiko> #undo
16:03:16 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0xaf12190>
16:03:21 <elmiko> #link http://eavesdrop.openstack.org/meetings/api_wg/2016/api_wg.2016-02-11-16.00.txt
16:03:29 <elmiko> that's the right one
16:03:40 <cdent> #undo
16:03:40 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0xb27bb50>
16:03:42 <cdent> #link http://eavesdrop.openstack.org/meetings/api_wg/2016/api_wg.2016-02-11-16.00.html
16:04:16 <elmiko> i think sdake took care of his
16:04:34 <cdent> one of the action items there, sdague's, was done, but then because of my action item, there's been some discussion of changing things more
16:04:35 <elmiko> er sdague, not sdake (sorry)
16:04:43 <elmiko> yea
16:04:49 <cdent> #link https://review.openstack.org/#/c/280381/
16:05:28 <cdent> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/087086.html
16:05:39 <elmiko> seems like aside from jaypipes' issue, folks are accepting that review
16:06:02 <elmiko> loved the title on that email lol
16:06:54 <elmiko> and i think it gives us a good segue to
16:06:55 <elmiko> #topic service type vs. project name for use in headers
16:07:13 <elmiko> #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/085145.html
16:07:20 <elmiko> #link http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-02-02-20.01.log.html#l-263
16:07:43 <elmiko> is there anymore to discuss here, i thought we had decided to support service type?
16:07:48 <cdent> I think we decide it would be service type and thus the service registry was born
16:07:53 <elmiko> k
16:08:06 <elmiko> #info api-wg has agreed that service type is the preferred usage
16:08:19 <elmiko> and great setup cdent
16:08:21 <elmiko> #topic taking on the service type registry
16:08:30 <elmiko> so...
16:08:53 <cdent> sdague has laid the groundwork for that with a repo and getting tc stuff in place
16:09:05 <elmiko> yea, saw that review
16:09:08 <cdent> but efforts to get some basic starting points into the repo have stalled because of other work
16:09:21 <elmiko> do we need to generate a cross-project spec to define the effort?
16:09:37 <elmiko> i haven't followed along with what we are going to put in that repo
16:09:59 <cdent> I think we've already made it past the need for cross-project spec, by fiat
16:10:01 <elmiko> is it just a text file with a list and folks make reviews against it when they want on the list?
16:10:05 <elmiko> k
16:10:18 <cdent> there are some etherpads where experimentation is happening
16:10:21 * cdent looks for them
16:10:49 <cdent> #link https://etherpad.openstack.org/p/service-registry-format
16:10:53 <elmiko> thanks, i feel like i totally missed whereever this was posted
16:11:01 <elmiko> i saw sdague's original review
16:11:10 <cdent> I think the discussion for this happened in the service catalog ng meeting
16:11:16 <cdent> there's a bit of overlap with that
16:11:21 <elmiko> ah, yea.
16:11:31 <elmiko> i should probably add that to my calendar
16:12:46 <elmiko> i can't seem to find the link to the new repo, do you have it cdent ?
16:13:24 <cdent> #link http://git.openstack.org/cgit/openstack/service-types-authority/tree/
16:13:35 <elmiko> awesome, cdent++
16:14:12 <elmiko> so, i guess once the format is solidified will the service catalog folks be adding reviews or should we start with all the defcore services?
16:14:29 <elmiko> or really, all the governance services
16:15:03 <cdent> I think the idea was to start with all the stuff that is not contentious
16:15:11 <elmiko> right, that makes sense
16:15:16 <cdent> which some small segment of "we" ought to be able to figure out
16:15:24 <cdent> defcore seems a reasonable starting point
16:15:34 <elmiko> cool
16:15:44 <elmiko> i don't mind helping (assuming we agree on the format from that etherpad)
16:17:01 <elmiko> do you know if that format is where we are starting?
16:17:18 <cdent> I think you're core in the group
16:17:34 <cdent> the format is still being figured out, but I think it is on you and me to resolve what it should be
16:17:45 <elmiko> oh wow, ok
16:17:48 <cdent> the debate was pretty much around how much information do we really need
16:18:14 <elmiko> yea, i would think we don't need that much. we just want a mapping from service type to project name right?
16:18:22 <elmiko> (the links are nice too though)
16:18:23 <cdent> and how multiple projects on the same service type are to be represented
16:18:32 <elmiko> that's a great question
16:19:00 <cdent> it's easy enough to have a list under service-type
16:19:03 <elmiko> so, there needs to be some standard form for extending the service-type for additional info?
16:19:31 <elmiko> although, this may be an area for the suggestion you had brought up before
16:19:37 <elmiko> what if we have a header like
16:19:52 <cdent> the hope was that we could do some easy yaml
16:19:53 <elmiko> OpenStack-SomeService-Foo: Project_A Bar
16:19:58 <elmiko> OpenStack-SomeService-Foo: Project_B Bar
16:20:24 <cdent> given the consistency goals I think we'd never want that
16:20:30 <elmiko> i agree, yaml is nice for the format
16:20:34 <elmiko> ok, too bad
16:20:47 <cdent> If you are supporting a service then you are supporting the api of that service
16:20:57 <cdent> so idealy both project and project b would use (the modern version:
16:21:08 <cdent> OpenStack-Foo:
16:21:23 <elmiko> hmm
16:21:25 <cdent> (with service on the right hand side if it is needed,)
16:21:39 <elmiko> oh right, i didn't realize that proposal gained traction
16:21:58 <elmiko> so we won't have, for example, OpenStack-Compute-Foo ?
16:22:46 <cdent> it's not clear if it has gained traction or not, the mailing list thread above some people kind of liked it
16:23:24 <cdent> #action: cdent to clarify if people really want to consider it
16:23:26 * sdague sneaks in as kiddo is asleep
16:23:34 <elmiko> welcome sdague
16:23:36 <sdague> how about we be pragmatic on it
16:23:40 <cdent> #undo
16:23:40 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0xaf25fd0>
16:23:45 <sdague> 3 projects currently have microversions
16:23:58 <cdent> #action: cdent to clarify if people want the radical change to microversion headers
16:24:00 <sdague> can we get those 3 on board?
16:24:09 <sdague> if yes, go
16:24:10 <elmiko> great question
16:24:47 <elmiko> so, just to restate, the idea here is that we would move to OpenStack-API-Version: Compute x.y.z   (for example)
16:24:52 <sdague> yep
16:25:03 <elmiko> cool, i'm down with that. if the projects are on board
16:25:18 <sdague> and I'm actually pro that, and think can represent the nova position.
16:25:23 <elmiko> cdent: are you going to check with the projects then?
16:25:29 <elmiko> sdague: cool, thanks!
16:25:31 <sdague> so get an ironic and manilla rep to ack
16:25:32 <cdent> elmiko: yes
16:25:35 <sdague> then we do it
16:25:36 <elmiko> awesome
16:26:06 <sdague> so cdent's action is to get a position from ironic and manilla projects
16:26:08 <elmiko> so, we will need a header guidelines update to reflect these changes if everyone is onboard
16:26:14 <elmiko> sdague: yes
16:26:20 <sdague> elmiko: yeh
16:26:30 <cdent> #action cdent get a position from ironic and manilla projects on modernization of microversion headers
16:26:38 <elmiko> ok, and then i guess we'll revisit this at the next meeting
16:26:44 <elmiko> (which sadly, i won't be able to attend)
16:26:59 <sdague> cdent: and I think the only thing to consider is what to do for non registered service types
16:27:14 <elmiko> good point
16:27:39 <cdent> sdague: as long as they are using the standard header on the left hand side it really doesn't matter what they do on the right
16:27:39 <sdague> because I'm going to assume we will require service type registration for the token on the rhs
16:27:41 <cdent> that's kind of the point
16:27:49 <sdague> cdent: oh, right, I suppose so
16:27:50 <elmiko> it might be nice to have some sort of readme in the service-types-authority that can speak to the non-registered types?
16:27:57 <sdague> never mind, solves a bunch of other things in the process
16:28:05 <cdent> services with types obviously _should_ use their type
16:28:18 <cdent> but other things can use "my mom" if they want to
16:28:27 <sdague> elmiko: agreed, it's on my list. But right now I'm trying to stay bug focussed until the nova RC process begins
16:28:32 <elmiko> qotd material right there cdent
16:28:49 <sdague> I am totally building a rest service that uses that
16:28:49 <elmiko> sdague: ack, totally fair and i don't want to derail you
16:28:58 <elmiko> hahah!
16:29:12 * cdent has disgraced his own mother
16:29:15 <cdent> the shame!
16:29:20 <elmiko> unforced error
16:29:35 <cdent> So, I have a topic related to this one that I mentioned to elmiko a couple days ago
16:29:46 <cdent> which is things on the right hand side that use redudant info
16:30:02 <cdent> the example is: x-openstack-request-id: req-<uuid>
16:30:05 <cdent> req is redundant
16:30:14 <elmiko> #topic header values
16:31:14 <elmiko> cdent: but, to your previous point about using whatever on the right hand side. do we need to advise a guideline here?
16:31:51 <cdent> I'm not sure, that's why I ask.
16:32:10 <cdent> It may be just that I don't like this specific case
16:32:19 <elmiko> actually, now that i think about this again. it would be nice to at least give some suggestions about reducing redundant info
16:32:34 <cdent> because I'm really annoyed by things which contain uuids but have prefixes or suffixes, thus making them no longer _truly_ uuids
16:32:44 <elmiko> we don't have to say *NEVER DO THIS*, but we could expand the idea
16:32:50 <elmiko> right
16:33:17 <elmiko> i'd be ok with a guideline giving best practices for header right side values
16:33:39 <cdent> I'll go ahead and do that one since I seem to be in the mood
16:33:48 <cdent> #action cdent  guideline giving best practices for header right side values
16:33:50 <elmiko> awesome, thanks cdent !
16:34:22 <elmiko> #topic the trouble with names
16:34:30 <elmiko> was this yours sdague ?
16:34:44 <elmiko> and did we cover it already
16:34:45 <cdent> i think we've done it already. it's headers and service type authority
16:34:50 <elmiko> yea
16:34:56 <elmiko> popular topic ;)
16:35:13 <cdent> we should probalby talk about cache invalidation, since that's the other main problem everywhere all the time
16:35:27 <elmiko> #topic cache invalidation
16:35:31 <elmiko> go for it
16:35:39 <cdent> It' was a joke
16:35:53 <elmiko> <whooosh>
16:35:59 * elmiko looks up too late
16:36:09 <elmiko> #topic Glance-Glare (Artifacts)
16:36:21 <nikhil> o/
16:36:25 <elmiko> hey
16:36:31 <elmiko> was just about to ping =)
16:36:33 <mfedosin> o/
16:36:38 <elmiko> the floor is yours
16:36:44 <nikhil> We've a spec up for this new API proposal
16:36:47 <nikhil> #link https://review.openstack.org/#/c/283136/
16:36:48 <mfedosin> hi folks
16:36:59 <nikhil> hey Mike
16:37:18 <nikhil> so, mfedosin is leading the spec
16:37:20 <mfedosin> if it's tl;dr just skip to rest api impact
16:37:40 <elmiko> that is a thorough spec, well done
16:38:09 <nikhil> The use cases are pretty elaborate! thanks to mfedosin and team
16:38:20 <nikhil> there were a couple of specific ones
16:38:46 <mfedosin> our main goal was to keep Glare compatible with Glance v2
16:38:48 <cdent> Is it possible to get an artifact by id without knowing its type?
16:39:02 <mfedosin> cdent no
16:39:12 <cdent> is that by design
16:39:25 <mfedosin> it may happen that different artifacts may have the same id
16:39:45 <mfedosin> because they are stored in different db
16:39:57 <elmiko> for me, the actions section stands out as something we advise against
16:40:04 <mfedosin> (Glance v1 allows manually set image id)
16:40:42 <elmiko> why not just PATCH /v1/artifacts/{artifact_type}/{artifacts_id} with the requested state?
16:40:57 <nikhil> :)
16:41:03 <nikhil> deja vu
16:41:05 <elmiko> haha
16:41:12 <mfedosin> to keep compatibility with Glance v2 first
16:41:24 <nikhil> elmiko: it's the activate and deactive stuff from glance v2 API
16:41:27 <mfedosin> http://developer.openstack.org/api-ref-image-v2.html
16:41:39 <elmiko> ok
16:42:15 <mfedosin> elmiko: I don't like it neither :)
16:42:17 <elmiko> other than that, the rest impact section looks pretty good to me
16:42:22 <nikhil> mfedosin: I think we wanted to ask about the PUT vs DELETE for blobs correct?
16:42:36 <cdent> I'm going to have to look at it more closely than now really allows, but I will asap
16:43:10 <mfedosin> nikhil: it's better to use PATCH
16:43:22 <mfedosin> because we modify blob property
16:43:31 <nikhil> hmm
16:43:57 <mfedosin> elmico cdent thanks folks. we're waiting your comments there
16:44:08 <elmiko> cool, thanks for bringing this up
16:44:23 <cdent> It looks extremely detailed, which is great to see
16:44:29 <elmiko> mfedosin: are you saying that deleting a blob is done through a PATCH?
16:44:33 <elmiko> cdent: +1
16:44:44 <nikhil> elmiko:  yeah
16:44:53 <nikhil> line 1101
16:44:56 <cdent> brb
16:45:04 <elmiko> yea, that's what i'm looking at
16:45:08 <nikhil> cool
16:45:09 <mfedosin> we delete blob property from artifact
16:45:20 <elmiko> i would think you would want to support DELETE /v1/artifacts/{artifact_type}/{artifacts_id}/blobs/{blob_name}
16:45:34 <elmiko> interesting...
16:45:42 <nikhil> :)
16:45:52 <elmiko> mfedosin: but wouldn't that be a PATCH to the artifact not the blob?
16:46:03 <mfedosin> I thought about it, but wanted to hear your opinion on that matter
16:46:06 <nikhil> that's the catch
16:46:26 <nikhil> would we want to support both?
16:46:34 <elmiko> hmm, i was just thinking that
16:46:38 <mfedosin> elmiko: ah, I see what you mean
16:46:55 <elmiko> i would think that for deleting a resource, the DELETE method should be the main way to do it
16:47:03 <mfedosin> so we need right API to remove blob from artifact while it's queued
16:47:14 <mfedosin> elmiko: got it
16:47:15 <elmiko> and if the user requests a blob delete through a PATCH to the artifact it should return a 4xx
16:47:27 <elmiko> i'm curious if cdent agrees
16:47:58 <elmiko> my reasoning is that removing a resource should always be an explicit action
16:48:07 <nikhil> oh
16:48:24 <mfedosin> it makes sense
16:48:36 <nikhil> elmiko: so the issue being the resource is being referenced as a property
16:48:41 <mfedosin> so - if we PATCH with remove, than return 400
16:48:46 <elmiko> now granted, i don't know the technical limitations behind these choices. so, grain of salt
16:49:09 <nikhil> elmiko: what this would mean is:
16:49:18 <nikhil> 1. DELETE the blob resource
16:49:21 <cdent> I'm back,
16:49:22 * cdent thinks
16:49:32 <nikhil> 2. Update the artifact that contains it
16:49:49 <elmiko> ok, so 2 issues for me
16:49:57 <nikhil> so it would be a two step delete with two separate actions
16:50:03 <elmiko> yea, that seems weird
16:50:04 * nikhil listens
16:50:14 <cdent> sigh, I closed that tab and now gerrit is throwing 503
16:50:24 <elmiko> 1. are the blob and the artifact 2 separate resources?
16:50:40 <mfedosin> elmico yes
16:50:41 <elmiko> 2. if they are, then PATCHing the artifact is ok without deleting the blob
16:50:53 <mfedosin> two instances I mean
16:50:58 <elmiko> like, would i ever remove the blob property from the artifact and leave the blob around?
16:51:32 <nikhil> umm
16:51:36 <mfedosin> blob will have status 'deleted' after that
16:51:38 <elmiko> are they actually 2 separate, independent resources, or are they tied together
16:51:46 <elmiko> ?
16:51:50 <nikhil> I think there may be a case when it has a dependency?
16:52:16 <elmiko> if they are dependent, i would lean towards a DELETE on the blob, and the server would automatically update the artifact property
16:52:28 <cdent> By having a URL that is /v1/artifacts/{artifact_type}/{artifacts_id}/blobs/{blob_name} then the implciation is that the way to delete that thing is to DELETE it
16:52:37 <nikhil> elmiko: so blob is designed this way as it is much much bigger in size compare to other artifacts properties (MB< GB etc)
16:52:37 <mfedosin> blob property in artifact is just a link to blob instance in db
16:52:50 <mfedosin> foreign key
16:53:00 <mfedosin> so we can replace it
16:53:13 <elmiko> ok, so blobs can act independently of artifacts then?
16:53:24 <nikhil> elmiko: essentially at the core of the artifacts design, it's just another property. but how can we separate it is still open question..
16:53:36 <elmiko> ah, gotcha. thanks nikhil
16:53:50 <elmiko> i still lean towards DELETE as the main way to remove a blob
16:54:17 <stevelle> +1 for DELETE as the main way, single operation
16:54:23 <elmiko> (also, 5 min left)
16:54:25 <mfedosin> will be updated
16:54:34 <elmiko> cool
16:54:44 <nikhil> please share your thoughts on the spec! :)
16:54:45 <elmiko> thanks again nikhil and mfedosin for bringing this up =)
16:54:48 <cdent> we should quickly decide if any current guidelines are ready for freeze
16:54:48 <elmiko> will do
16:54:54 <elmiko> good point
16:54:56 <nikhil> thanks in advance
16:55:07 <nikhil> elmiko: :)
16:55:07 <elmiko> #topic guidelines for freeze
16:55:19 <elmiko> cdent: did you have some in mind?
16:55:53 <elmiko> i guess these two are getting close
16:55:55 <cdent> the only two recent ones that are currently +1 are two of the microversion things from alex_xu
16:55:57 <elmiko> #link https://review.openstack.org/#/c/243429/
16:56:04 <elmiko> #link https://review.openstack.org/#/c/243414/
16:56:13 <elmiko> i'll put em up if we think they are good
16:56:14 <cdent> yeah, those, but I'm not entirely sure
16:56:18 <elmiko> (seems like the reviews say they are)
16:56:24 <cdent> may as well then
16:56:36 <cdent> oh wait
16:56:41 <elmiko> should we take one more pass given the recent ideas about headers?
16:56:46 <cdent> yes, exactly
16:56:56 <elmiko> ok, let's table these until next meeting then
16:56:57 <cdent> i'll do my actions on that first
16:57:04 <elmiko> makes sense
16:57:09 <elmiko> and thanks =)
16:57:46 <elmiko> i still need to revisit the actions guideline, not sure how to bring that into alignment
16:57:53 <elmiko> and i'd like to start a links guideline
16:58:32 <elmiko> ok, another other business for the last minute?
16:58:39 <elmiko> er any other...
16:58:52 <elmiko> man... only noon and i can't type already
16:59:06 <elmiko> going once
16:59:11 <elmiko> twice
16:59:13 <elmiko> ...
16:59:15 <elmiko> sold!
16:59:20 <elmiko> thanks everyone!
16:59:23 <elmiko> #endmeeting