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