00:00:18 <etoews> #startmeeting api wg
00:00:18 <openstack> Meeting started Thu Feb 19 00:00:18 2015 UTC and is due to finish in 60 minutes.  The chair is etoews. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:00:21 <openstack> The meeting name has been set to 'api_wg'
00:00:38 <etoews> #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
00:00:54 <etoews> #topic mission statement
00:01:20 <etoews> #link https://review.openstack.org/#/c/155911/
00:01:36 <etoews> the discussion is going well
00:01:40 <etoews> not really much to say
00:01:43 <etoews> except...
00:02:02 <ryansb> Might we be ready for a vote?
00:02:12 <etoews> rosmaita has a question..."My question is: what is the sense of "pragmatic" in this sentence?"
00:02:24 <etoews> which ties into our next topic
00:02:38 <rosmaita> we can kill 2 birds with one stone!
00:02:44 <etoews> death to birds
00:03:04 * sigmavirus24 is suddenly feeling uncomfortable here as a bird with arms
00:03:11 <miguelgrinberg> these are big birds though, we need a bigger stone :)
00:03:28 <etoews> rosmaita do you have a preference on which aspect you want to tackle this from?
00:03:33 <sigmavirus24> I know, we'll use miguelgrinberg as the stone =P
00:03:37 <rosmaita> not really
00:03:51 <rosmaita> maybe concrete first, though
00:03:59 <etoews> discuss the abstract "pragmatic" or concrete review first
00:04:03 <etoews> review it is
00:04:22 <etoews> #topic Glance and functional API
00:04:29 <etoews> #link http://lists.openstack.org/pipermail/openstack-dev/2015-February/056968.html
00:04:35 <etoews> #link https://etherpad.openstack.org/p/glance-adding-functional-operations-to-api
00:04:41 <etoews> #link https://review.openstack.org/#/c/135122
00:05:32 <etoews> thoughts and feels?
00:06:00 <rosmaita> i was trying to explain the discussion to some glance devs this afternoon
00:06:20 <rosmaita> they feel like we have a simple use case, disable an image
00:06:39 <elmiko> i like jay's idea, but i think i prefer option C
00:06:40 <rosmaita> it seems like a lot of extra overhead to create a resource
00:07:00 <etoews> rosmaita the "heavyweight"
00:07:02 <miguelgrinberg> rosmaita: I agree about the overhead
00:07:08 <cyeoh> so I think Jay's is fine where have async calls
00:07:23 <elmiko> cyeoh: yea, makes a ton of sense there
00:07:37 <cyeoh> but it does seem heavy to me too for sync calls if the caller can know straight away if it succeded/failed
00:07:53 <elmiko> agreed, i think that's why i prefer C in this case
00:09:18 <cyeoh> so although this specific case only handles sync, will it ever expand with other actions which may be async?
00:09:20 <nikhil_k> o/
00:09:51 <rosmaita> cyeoh: no, we have actual tasks for that
00:09:54 <rosmaita> (already)
00:10:01 <sigmavirus24> nikhil_k: o/
00:10:18 * nikhil_k hi5s sigmavirus24
00:10:21 <cyeoh> rosmaita: ok
00:10:30 <sigmavirus24> etoews: fwiw, the other "heavyweight" is using the existing /tasks endpoint for this
00:10:33 <nikhil_k> Glance tasks are supposed to be user centric
00:10:51 <nikhil_k> and this operations is admin/oper specific
00:11:03 <nikhil_k> these*
00:11:07 <nikhil_k> are*
00:11:18 <rosmaita> plus tasks come with a framework to make them easy to implemenet
00:12:21 <etoews> to me (c) sounds like a controller that operates on a resource as per "RESTful Web Services Cookbook"
00:12:29 <etoews> (section 2.6)
00:12:47 <etoews> rosmaita nikhil_k do either of you know if that was the intention?
00:13:27 * jaypipes likes jay's idea as well
00:13:38 <rosmaita> hi jay!
00:13:45 <jaypipes> heh, hi :)
00:13:59 * sigmavirus24 likes jaypipes and his idea
00:15:09 <nikhil_k> etoews: am looking into that section
00:17:33 <nikhil_k> etoews: reading through half way seems to indicate that it was the intent (or one of the main ones)
00:17:44 <rosmaita> i concur
00:18:20 <nikhil_k> Actaually, I was reading some blogs this afternoon which pointed me to retrospect of the same things
00:19:19 <etoews> i'm starting to lean towards (c)
00:20:08 <rosmaita> i think it is a pragmatic and respectable solution
00:20:16 <etoews> (d) seems to veer away from the stated intent of that api (async calls)
00:21:27 <etoews> if the task resource wasn't dedicated to async, it would be a different story i think.
00:22:04 <etoews> jaypipes miguelgrinberg thoughts?
00:22:07 <sigmavirus24> Yeah, I stopped having strong feelings either way a while ago, so while I like jaypipes's idea, I just want this discussion to finish up
00:22:37 <etoews> sigmavirus24 +1
00:22:37 <miguelgrinberg> as I said in the ML, in my view none of the options currently in the table are the best, but of all I like jaypipes best
00:23:20 <nikhil_k> jaypipes: hi
00:23:31 <etoews> let me throw this out there
00:23:40 <nikhil_k> jaypipes: I wanted to ask why your felt so strongly for task vs action ?
00:23:51 <etoews> how would people feel about (c) being used in other apis?
00:24:19 <etoews> or put another way, is what we come up with this decision to be a guideline going forward?
00:24:37 <miguelgrinberg> I will never +1 such a guideline, sorry
00:24:41 <sigmavirus24> I think it shouldn't be a guideline
00:24:41 <rosmaita> i am ok with other apis doing this where appropriate
00:24:50 <nikhil_k> == rosmaita
00:25:22 <elmiko> i'm withi rosmaita, i'd be ok with it where it makes sense
00:25:27 <sigmavirus24> It seems to me that the people who already implemented this elsewhere regret it already so that should be a reason to avoid this (or maybe I'm thinking of a separate conversation)
00:25:36 <elmiko> i also think there is an important distinction between sync/async
00:26:14 <rosmaita> i think people who mixed sync and async in the same resource are the ones with regrets
00:26:21 * nikhil_k wonders if perfect ontology exists for scalable, maintainable, portable large scale computational systems
00:26:21 <cyeoh> yea, for sync calls I think (C) is good, when it can be async then tasks are appropriate
00:26:32 <rosmaita> cyeoh: +1
00:26:33 <elmiko> cyeoh: +1
00:27:05 <cyeoh> if it is a resource that could have sync or async depending on the operation, then I'd prefer (d) as a recommendation
00:27:26 <elmiko> that makes sense to me
00:27:32 <cyeoh> but then I guess this part of "pragmatism" ;-)
00:27:42 <elmiko> hehe
00:27:54 <rosmaita> cyeoh: you brought us full circle!
00:28:04 <cyeoh> :-)
00:28:07 <etoews> sunrise sunet
00:28:17 <etoews> s/sunet/sunset/
00:28:54 <sigmavirus24> I like sunet better
00:30:11 <etoews> i think jaypipes got distracted (i know he has another meeting at this time)
00:30:55 <etoews> i'm not sure what else to do besides put it to a vote.
00:30:58 <sigmavirus24> Yeah jaypipes has disappeared
00:31:37 <rosmaita> if it's a tie we can call him back
00:32:05 <nikhil_k> We also had flavio vote for option C on the ML
00:33:13 <etoews> phrasing....
00:34:57 <etoews> #startvote should glance use POST /images/{image_id}/actions/[deactivate|activate] (aka (c)) to put images into a deactive or active state?
00:34:58 <openstack> Begin voting on: should glance use POST /images/{image_id}/actions/[deactivate|activate] (aka (c)) to put images into a deactive or active state? Valid vote options are Yes, No.
00:34:59 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
00:35:27 <rosmaita> #vote Yes
00:35:35 <elmiko> #vote Yes
00:35:55 <elmiko> (gotta say this feels a little weird voting on what glance should do)
00:36:14 <ryansb> well it's voting on the wg's recommendation
00:36:15 <etoews> good point
00:36:18 <sigmavirus24> (they asked for our input)
00:36:21 <ryansb> #vote yes
00:36:27 <ryansb> #vote Yes
00:36:28 <elmiko> ryansb: yea, exactly
00:36:36 <etoews> ryansb uses words good
00:36:39 <cyeoh> yea, when passing it on should probably clarify that its just a recommendation. We can't make them do anything
00:36:40 <elmiko> lol
00:36:45 <nikhil_k> #vote Yes
00:36:46 <cyeoh> #vote yes
00:36:59 <rosmaita> cyeoh: +1
00:37:00 <elmiko> right, vote on what we recommend they do. i guess that's implied.
00:37:15 <etoews> my bad phrasing
00:37:21 <elmiko> no worries
00:37:34 <etoews> the point is well taken
00:37:39 <etoews> #vote Yes
00:37:53 <etoews> sigmavirus24 miguelgrinberg ?
00:38:06 * sigmavirus24 is abstaining purposefully =P
00:38:16 <etoews> imo a No vote is perfectly respectable.
00:38:25 <sigmavirus24> I don't feel strongly either way at this point
00:38:26 <elmiko> etoews: +1
00:38:26 <etoews> but abstaining is okay too
00:38:33 <miguelgrinberg> there's nothing that I find interesting, so I'm not voting
00:38:43 <etoews> okay
00:39:02 <etoews> #showvote
00:39:17 <sigmavirus24> I think it's #endvote, no?
00:39:18 <etoews> meetbot y u no #showvote
00:39:23 <sigmavirus24> Even so it doesn't work =P
00:39:35 <etoews> supposedly there's a #showvote
00:39:39 <etoews> forget it
00:39:43 <etoews> #endvote
00:39:44 <openstack> Voted on "should glance use POST /images/{image_id}/actions/[deactivate|activate] (aka (c)) to put images into a deactive or active state?" Results are
00:39:52 <stevelle> I'm pretty sure I have a sticky with a lead on that voting bug
00:39:53 <sigmavirus24> endvote is supposed to show the results but doesn't
00:40:04 <sigmavirus24> stevelle: /me assigns it to you
00:40:26 <elmiko> hmm, that endvote bug really stings lol
00:41:04 <etoews> #agreed the api wg recommends that glance use POST /images/{image_id}/actions/[deactivate|activate] (aka (c)) to put images into a deactive or active state
00:41:57 <sigmavirus24> elmiko: 99% sure no one voted No ;)
00:42:04 <sigmavirus24> Besides jaypipes in spirit
00:42:34 <etoews> well that wasn't an easy discussion but i do want to thank rosmaita and nikhil_k for reaching out to us.
00:42:47 <elmiko> sigmavirus24: yea, that was softball
00:42:51 * nikhil_k thanks everyone for their valuable input and background knowledge
00:42:55 <rosmaita> so it looks like "pragmatic" means there's some reasonable prior art, like for example the controller pattern in the web svcs cookbook?
00:43:20 <nikhil_k> elmiko: thanks to you for that reference in the cookbook!
00:43:25 <nikhil_k> etoews: ^
00:43:29 <elmiko> ?
00:43:32 <sigmavirus24> one of you e* people ;)
00:43:33 <nikhil_k> elmiko: sorry, bad day
00:43:41 <elmiko> =)
00:43:50 <elmiko> nikhil_k: hope it gets better tomorrow
00:44:16 <nikhil_k> :)
00:44:52 * nikhil_k still trying to digest the winter storm warning
00:45:27 <elmiko> oh man... that could be serious depending your locale
00:46:12 <nikhil_k> no kidding
00:46:29 <sigmavirus24> I'm not sure why everyone's complaining. It's -15 with windchill here
00:46:36 <sigmavirus24> You don't hear me complaining
00:46:44 <sigmavirus24> (-15F)
00:46:45 <etoews> rosmaita ya. to me "pragmatic" means taking into account the wider context.
00:46:57 <cyeoh> 35C over here :)
00:47:05 <rosmaita> etoews: that seems reasonable
00:47:08 <sigmavirus24> etoews: pretty sure that's convergence more than pragmatism
00:47:19 <elmiko> sigmavirus24: about the same here, a tad warmer
00:47:23 <nikhil_k> sigmavirus24: :) because MSP is always prepared for long and chilly winters!
00:47:24 <sigmavirus24> we have an existing well designed API practice, let's converge on that
00:47:50 <sigmavirus24> nikhil_k: heh, I'm only in this general region for ~2 years now though so, I wasn't last year
00:48:33 <cyeoh> sigmavirus24: If the practice is clearly wrong, I think we can recommend what best practice is though (presumably has some advantages) and then expect over time that the older projects will converge to that
00:48:38 <nikhil_k> :)
00:49:23 <sigmavirus24> cyeoh: correct
00:49:43 <cyeoh> eventually ally the projects are going to have to tackle backwards incompatible changes (and probably in a way that allows them to do it over time rather than big version bumps.
00:49:46 <sigmavirus24> pragmatism I think means "without over-architecting an one aspect of an API" IMO
00:50:20 <etoews> "pragmatic" is a mighty squishy term.
00:50:31 <nikhil_k> == etoews
00:50:44 <sigmavirus24> perhaps we should squash it from the mission statement then
00:50:47 <elmiko> agreed about squishy-ness, but sometimes squishy is called for
00:51:01 <etoews> elmiko that's why i left it in there
00:51:33 <etoews> it's a very subjective term
00:51:47 <sigmavirus24> "deferring to best current practice when one is available"
00:52:13 <elmiko> my understanding is that we are using "pragmatic" to indicate that we will attempt to create guidelines that pay respects to best practices in the field as well as attempting to honor the existing choices that have been made. then making decisions that have the greatest gain with the least pain =)
00:52:22 <nikhil_k> how feasible is it to apply webservices semantics to infrastructure system resources?
00:53:00 <etoews> elmiko i like that take on it
00:53:02 <sigmavirus24> nikhil_k: I think that's better asked "how feasible is it to expose infrastructure system resources through web services?"
00:53:24 <nikhil_k> sigmavirus24: heh, abs. I think we need to un-cloud stuff now ;)
00:53:45 * sigmavirus24 wants his almost 3 year old nephews to use requests to make clouds go soon ;)
00:54:08 * nikhil_k finds his magic wand
00:54:11 <sigmavirus24> heh
00:54:25 <etoews> if anyone feels strongly about the word pragmatic please comment on the mission statement review.
00:54:54 <rosmaita> i like what elmiko said above
00:55:30 <etoews> #topic previous meeting action items
00:55:31 * nikhil_k like=then making decisions that have the greatest gain with the least pain
00:55:51 <etoews> #link http://eavesdrop.openstack.org/meetings/api_wg/2015/api_wg.2015-02-12-16.00.html
00:56:32 <etoews> *desparately wants to discuss versioning but knows we don't have enough time*
00:56:59 <cyeoh> etoews: microversioning of apis?
00:57:34 <etoews> imo we need to say _something_ about versioning
00:57:57 <etoews> it's always the second question we get.
00:58:12 <etoews> how do we go from x to y?
00:58:17 <cyeoh> yea, projects should at least think about it early on before it gets even more expensive to do
00:58:26 <etoews> exactly
00:58:39 <cyeoh> the nova microversions will probably be enabled next wed
00:59:03 <elmiko> could we develop some sort of checklist that might help for projects considering a version change?
00:59:08 <cyeoh> and from what little I've seen of it, the ironic one looks very similar (at least from the user point of view)
00:59:39 <etoews> we'll need a survey of the current designs.
01:00:02 <sigmavirus24> And time
01:00:09 <sigmavirus24> at which point I'm going to grab dinner
01:00:13 <sigmavirus24> good night all
01:00:23 <etoews> #endmeeting