16:01:00 <cdent> #startmeeting api-sig 16:01:01 <openstack> Meeting started Thu Nov 30 16:01:00 2017 UTC and is due to finish in 60 minutes. The chair is cdent. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:05 <openstack> The meeting name has been set to 'api_sig' 16:01:11 <cdent> #chair edleafe elmiko dtantsur 16:01:11 <elmiko> heyo/ 16:01:12 <openstack> Current chairs: cdent dtantsur edleafe elmiko 16:01:23 <cdent> dtantsur: are you around today? 16:01:26 <edleafe> \o 16:01:32 <cdent> #link https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda 16:01:34 <dtantsur> o/ 16:01:45 <dtantsur> cdent: it feels so, but I'm not confident :) 16:01:53 <cdent> I know how that can be 16:02:09 <edleafe> likewise 16:02:12 <elmiko> hehe 16:02:31 <cdent> #link last log http://eavesdrop.openstack.org/meetings/api_sig/2017/api_sig.2017-11-16-16.00.html 16:02:36 <cdent> #topic old biz 16:02:47 <cdent> I think it's been so long that any biz has died on the vine? 16:02:55 <elmiko> seems likely 16:03:04 <dtantsur> yeah, I cannot recall anything already 16:03:11 <cdent> right then 16:03:14 <cdent> #topic new biz 16:03:28 <cdent> #link summit session etherpad https://etherpad.openstack.org/p/api-sig-sydney-forum 16:03:40 <cdent> anything we need to lift from that 16:03:52 <cdent> the main topic ended up being sdk related 16:04:05 <elmiko> interesting 16:04:16 <edleafe> has anyone heard anything from any SDK folk? 16:04:21 <cdent> sort of a "how to engage with sdk folk" 16:04:23 <cdent> since then? no 16:04:37 <cdent> but I think they, like us, have been travelling and turkeying &c 16:04:42 <elmiko> makes sense 16:05:00 <elmiko> would be nice to figure out how we can pull some of the sdk folks in closer 16:05:16 <cdent> At this stage of the game I don't think there's a specific action for us other than to continue to provide a place for people to talk 16:05:23 <elmiko> agreed 16:05:24 <cdent> and if they aren't talking yet, that's okay 16:05:28 <elmiko> yup 16:06:02 <cdent> dtantsur: did you ever find my email and if you di, did you decide about your availability? 16:06:32 <dtantsur> cdent: man sorry, I don't think I even looked for it :( 16:07:08 <cdent> well we can do it here? Would you like to be a core reviewer on the guidelines? (as in, do you have to continue doing what you were already doing, with slightly more time?) 16:07:29 <dtantsur> cdent: you did hit spam :) I'll gladly join you guys 16:07:41 <cdent> #startvote should dtantsur be a core, yes or no 16:07:41 <openstack> Unable to parse vote topic and options. 16:07:50 <cdent> omg 16:07:57 <cdent> #startvote should dtantsure be core? 16:07:58 <openstack> Begin voting on: should dtantsure be core? Valid vote options are Yes, No. 16:08:00 <openstack> Vote using '#vote OPTION'. Only your last vote counts. 16:08:02 <cdent> undo 16:08:02 <elmiko> #vote yes 16:08:08 <edleafe> #vote YEs 16:08:10 * cdent breaks everything 16:08:25 * edleafe expects nothing less from cdent 16:08:27 <cdent> #vote yes 16:08:29 <cdent> #endvote 16:08:30 <openstack> Voted on "should dtantsure be core?" Results are 16:08:38 * dtantsur votes meow - just for the sake of voting 16:08:54 <cdent> well that went about as well as every other official thing we do 16:08:58 <cdent> welcome to the club 16:08:58 <edleafe> wow - lots of votes to tally 16:09:03 <cdent> #info dtantsur is core 16:09:04 <dtantsur> thanks :) 16:09:12 <cdent> #action cdent to update the gerrit stuff 16:09:21 <edleafe> Now for the initiation rites... 16:09:33 <cdent> THEY ARE SUPPOSED TO BE A SURPRISE 16:09:43 <elmiko> XD 16:09:46 * dtantsur gets ready to hide 16:09:54 <cdent> any other new biz? 16:10:42 * dtantsur looks at mordred 16:10:42 <cdent> The only thing I've got is that I continue to maintain all my good intentions about writing additional guidelines and that summary/frontdoor thing I mentioned a while ago 16:10:48 <cdent> but so far they are all good intentions 16:11:04 <dtantsur> ++ a few good intentions here too 16:11:17 <dtantsur> well, we're in discussion on how to expose API versions in ironicclient in a saner fashion 16:11:18 <cdent> #topic guidelines 16:11:20 <edleafe> I have *lots* of good intentions 16:11:25 <dtantsur> this may end up in something readable 16:11:27 <cdent> undo 16:11:32 <cdent> #undo 16:11:33 <openstack> Removing item from minutes: #topic guidelines 16:11:50 * cdent is at a standing desk, all my typing problems are multiplied 16:12:13 <cdent> dtantsur: you mean so the client can express which version they want, or so that the version is inferred or what? 16:12:29 <cdent> I ask because that seems to be a big deal for the non-python SDKs (and for osc as well I guess) 16:12:45 <dtantsur> cdent: so, now the only thing you can do with ironicclient is to pass api_version into its __init__ 16:13:01 <dtantsur> which is a very lame way to use microversions, and it can easily lead to broken upgrades 16:13:21 <cdent> ah, indeed 16:13:23 <dtantsur> we want to expose some actual negotiation, make a caller be able to be flexible 16:13:48 <dtantsur> we have a few options of how precisely that could work 16:13:56 <dtantsur> and we have a real-world case: nova-ironic interaction 16:13:59 <mordred> yes - also to allow it to be per-call 16:13:59 <cdent> the emerging best practice is allow people to set a version on every request, _if_ they want to, based on what discovery/negotiation has revealed 16:14:05 <edleafe> dtantsur: sounds like a reasonable solution would be the __init__ value is the default used, but individual calls should be able to override 16:14:25 <dtantsur> well, yes, but there are still details :) 16:14:28 <mordred> yah. the keystoneauth options added a default_microversion to the __init__ - and then a microversion= argument to each request/get/post whatnot 16:14:52 <dtantsur> in our case this ^^^ will require rewriting half of ironicclient, I'm afraid.. 16:14:57 <dtantsur> but that's a side note 16:14:59 <mordred> havne't fully decided how to expose that in the openstacksdk object layer 16:15:02 <cdent> that ksa stuff is good soup 16:15:37 <dtantsur> I'm thinking of getting a guideline, explaining this with a real-world example in Python and *preferably* in some compiled language 16:15:45 * dtantsur looks at his rust-openstack and sighs 16:15:50 <cdent> :) 16:15:51 <mordred> dtantsur: well - we could discuss whether or not we can implement what you need in sdk more easier and switch nova to using that instead of python-ironicclient - but that's probably *way* out of scope here 16:16:08 <mordred> dtantsur: I'd love to work with you on both the guideline ... AND rust-openstack :) 16:16:23 <dtantsur> mordred: welcome - to both :) 16:16:35 * cdent clones self 16:16:41 <dtantsur> well, rust-openstack got to the stage of compiling AGAIN after the switch to newer HTTP library 16:16:46 <dtantsur> now, unit tests........... 16:16:57 <dtantsur> but that's kinda offtopic :) 16:17:19 <cdent> naw mate, we the api-sig now, nearly everything is on topioc 16:17:28 <dtantsur> hah, true 16:17:28 <elmiko> hehe 16:17:31 <edleafe> on tapioca? 16:17:37 <mordred> dtantsur: I keep wanting to do more rust - but the lack of an http library as good as requests is annoying 16:17:41 <elmiko> moar rust-openstack! \o/ 16:17:55 <dtantsur> mordred: they have something actually, it has a funny name like reqwest 16:17:59 <elmiko> edleafe: tapioca-openstack? 16:18:13 <cdent> neither tapioca nor bubble-tea are on topic and while I stand on this hill never will be 16:18:15 <dtantsur> but I use Hyper, it's more low level. and it got rewritten a few months ago essentialyl from scratch ._< 16:18:48 <dtantsur> mordred: https://docs.rs/reqwest/0.8.1/reqwest/ 16:19:00 <elmiko> cdent: lol 16:19:42 <dtantsur> anyway, we should team up with TheJulia and come up with something around this version negotiation topic 16:19:51 <cdent> +1 16:19:58 <mordred> dtantsur: oh awesome! that wasn't there last time I looked 16:20:05 * TheJulia appears and looks slightly confused 16:20:13 <TheJulia> oh, that topic :( 16:20:30 <dtantsur> TheJulia: about having a guideline on dealing with api versions in SDKs like ironicclient 16:20:32 <edleafe> dtantsur: Reading that code with an Elmer Fudd voice 16:20:44 <dtantsur> heh 16:20:55 <TheJulia> edleafe: lol 16:21:01 <edleafe> http://www.barbneal.com/the-collection/looney-tunes/elmer-fudd/ 16:21:07 <mordred> dtantsur: fwiw, TheJulia just added some code to shade that consumes ironic microversion - but the shade story for microversion is likely different than the sdk version 16:21:32 <dtantsur> I suspect so, but worth checking. #link? 16:22:18 <mordred> the shade pov is, I *think* that users should never know anything about a microversion, and as we add support to shade for more microversoins it should use the best available - and normalize the data model we return to include the various fields with None values if the cloud doesn't support the newer thing 16:22:21 <TheJulia> dtantsur: https://review.openstack.org/#/c/499774/ 16:22:54 <TheJulia> dtantsur: fwiw, I will be revising it later today to align with mordred POV which I agree with 16:22:57 <mordred> but shade is a higher-level do-things-for-you interface ... for the object layer in sdk, I imagine we'll need the ability for a user to request microversion specifics and do negotiation 16:23:17 <dtantsur> #link https://review.openstack.org/#/c/499774/ shade patch to implement microversions for ironic 16:23:18 <edleafe> #link https://review.openstack.org/#/c/499774/ 16:23:23 <mordred> that'll be... interesting ... because the object layer has resource objects that make calls behind the scenes for you ... 16:23:38 <dtantsur> mordred: I still cannot decide if I should make rust-openstack something like shade or something like clients.. 16:23:52 <mordred> cdent: you had a microversion-consumption-version-negotiation lib somewhere didn't you? 16:24:11 <edleafe> dtantsur: in my experience, SDK users generally want things to "just work" 16:24:14 <mordred> dtantsur: well.... I got some positive feedback from fokls in sydney about eh approach for the shade/sdk merge ... 16:24:31 <dtantsur> that's where I'm leaning too 16:24:34 <mordred> which is that we'll have all three in the same thing - 16:24:39 <cdent> mordred: server side header parsing, but it includes a handy Version class that might be of some use "microversion-parse" 16:24:40 <mordred> you get a Connectoin to the cloud-region 16:24:42 <dtantsur> esp. since I'm not ready to implement All The Things OpenStack in Rust myself 16:24:57 <cdent> there's some pending changes under review that ought to make it a bit more useful 16:25:07 <cdent> and it can happily grow to become whatever is required 16:25:09 <mordred> then from that you can do conn.list_servers() (shade version) conn.compute.servers() (sdk object layer) or conn.compute.get('/servers) (rest fallthrough on the compute endpoint) 16:25:12 <cdent> patches accepted etc 16:25:58 <mordred> so sdk should *always* be usable to talk to all the services in all the openstack clouds at at least the rest layer - and as objects are added or shade fancy functions are added, people can shift to them as they desire 16:26:15 <mordred> cdent: ah yes - cool - I remember that now 16:26:43 <dtantsur> mordred: that's.. an interesting approach, I like it. 16:27:01 <mordred> dtantsur: the second two parts of that above strategy work today in sdk master ... haven't combined the shade OpenStackCloud object and the Connection object just yet ... 16:27:30 <mordred> but that's mostly just code-reorg work rather than actually hard work 16:27:39 <cdent> that onion approach++ 16:27:43 <dtantsur> yeah 16:28:00 <dtantsur> and it can be developed gradually (still thinking about rust-openstack) 16:28:22 <dtantsur> start with list_servers(), keeping compute private until it's ready.. 16:28:26 <dtantsur> or the other way around - depends 16:28:34 * dtantsur has food for thought now, thanks all 16:30:01 <cdent> Unless someone has something to say about them I think we can skip both the guidelines and bugs topics as they haven't seen any recent action (as explained above). 16:30:56 <cdent> #topic weekly newsletter 16:30:56 <cdent> #link https://etherpad.openstack.org/p/api-sig-newsletter 16:31:17 <cdent> Any takers? I got time if nobody else is dying to do it. 16:31:41 * cdent listens to the crickets 16:31:50 <elmiko> i have more meetings after this, i'd be thankful for someone else doing it 16:31:52 <edleafe> Maybe dtantsur would like to give it a go? 16:32:03 <edleafe> Being all official and such 16:32:14 <cdent> I figured since in this one we'd be announcing his ascendancy it would be better if it were someone else. He's on the hook for next week. 16:32:16 <dtantsur> I'm avoiding that because of my English being not on the same level 16:32:35 * cdent does it 16:32:46 <edleafe> dtantsur: well, the rest of us review before sending it out 16:32:47 <cdent> I'll ping folk when it's ready for a look 16:32:52 <edleafe> but yeah, I get it 16:32:53 <elmiko> thanks cdent ! 16:32:59 <dtantsur> edleafe: nice, then it's not so painful :) 16:33:06 <cdent> Gonna switch puters though 16:33:16 <cdent> Thanks everyone for coming and the interesting discussion. 16:33:28 <cdent> #endmeeting