18:02:45 #startmeeting trove 18:02:46 Meeting started Wed Jul 23 18:02:45 2014 UTC and is due to finish in 60 minutes. The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:47 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:49 The meeting name has been set to 'trove' 18:02:55 o/ 18:02:56 o/ 18:02:59 o/ 18:03:02 o/ 18:03:05 o/ 18:03:16 Agenda at: 18:03:19 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting 18:03:21 o/ 18:03:49 Notes from previous meeting at: 18:03:51 #link http://eavesdrop.openstack.org/meetings/trove/2014/trove.2014-07-16-18.02.html 18:04:49 No Action items per se, so moving on to the agenda items. 18:05:03 #topic Juno-2 cut 18:05:47 We cut the trove juno-2 release this morning. 18:06:03 #link https://github.com/openstack/trove/releases/tag/2014.2.b2 18:06:13 #link https://bugs.launchpad.net/trove/+milestone/juno-2 18:06:54 nice work! 18:06:56 I've rolled over the work-items (bugs/bps) that didn't make it to the cut to juno-3. 18:07:01 w00t 18:07:28 +1 18:07:53 We got quite a few bps / bugfixes in — so thanks to you all for your hard work on it! 18:08:03 *high fives all around* 18:08:21 Let's keep the momentum going into juno-3. 18:08:27 Keep those reviews coming! :) 18:08:31 hells ya 18:09:44 Anyone else have anything to add for this? 18:10:02 good job SlickNik! 18:10:08 kudos to all! 18:11:11 Thanks amrith. 18:11:19 To juno-3, and beyond! 18:11:31 #topic Doc Scrub Update 18:12:12 Just a reminder to folks to keep the momentum going on this one. 18:12:40 There are quite a few patches up for review to tackle some of this already. 18:13:03 Thanks to folks who put them up, and for folks stepping up to review them. 18:13:53 A couple of areas that still need some love are the deployment guide, and API docs. 18:14:46 Hope to see patches for them up soon as well. 18:15:16 fyi, my swift item (deployment/install guide) is currently mired in a docbook infrastructure issue that anne is working on, but we don't have the answer yet. in progress tho. 18:16:35 laurelm: ah, okay thanks for the update. Keep us informed of any ETA on when a fix for that will be available. 18:16:46 slicknik: will do 18:16:57 i'll try to get some API docs patches up soon.. 18:17:02 SlickNik, I'm mired in the doc of the guest images 18:17:13 vipul / amrith: +1 18:17:14 will keep you updated on progress 18:18:00 I know folks have been busy with juno-2 work items. :) But didn't want us to lose track of progress on this. 18:18:24 That's all I had for this — anyone want to add anything else? 18:18:44 . 18:18:47 Let's move on. 18:18:55 #topic Flavor UUIDs 18:19:08 OK, I added this in the morning. 18:19:11 #link https://launchpad.net/bugs/1333852 18:19:12 Launchpad bug 1333852 in trove "Trove does not support flavor UUIDs" [Medium,In progress] 18:19:19 based on a conversation with adam_g, who I believe is here. 18:19:26 heya 18:19:41 adam, would you like to explain why you'd like this change. 18:19:45 sure 18:20:10 the ironic team is currently working on getting increasd tempest test coverage of a devstack deployed ironic environment 18:20:37 it so happens that the baremetal nova flavor created by devstack uses an autogenerated uuid for the ID of the created flavor 18:21:01 causing tempest.api.database.flavors.test_flavors.DatabaseFlavorsTest to no longer pass 18:21:34 oh i think this was something we knew* about for a while now... 18:22:01 the bug was opened ~1 month ago by someone else 18:22:24 ive proposed a change to devstack to workaround the issue by using an integer ID for the flavor, but this is less than ideal and NACKed by QA folk 18:22:28 so, if I may pick up the string 18:22:33 https://review.openstack.org/#/c/107814/ 18:22:35 hmm wonder if there is another bug in there somewhere thats like 2 years old ;) 18:22:43 I understand the issue of not changing the API. 18:22:59 but would it (and I'm asking out of profound ignorance here) be OK to add a field to the view? 18:23:12 what if we added uuid? without the conversion? 18:23:33 would that satisfy the two competing desires; having the UUID exposed and not breaking the API contract? 18:23:42 amrith: I think that's what grapex suggests if you scroll down to the comments at the bottom of the bug. 18:23:45 it is cheesy; I agree. 18:24:06 what happens to the current id when it isn't an integer? 18:24:12 sorry, hadn't see that. I proposed this in the agenda in the morning (but I feel better knowing that he suggested it). 18:24:17 kevinconway: It raises an exception 18:24:18 its just a string 18:24:20 and you get a 500 18:24:22 kevinconway, we'd return some indicator in the uuid field 18:24:25 or an error 18:24:37 i'm ok with adding a "uuid" field as grapex suggests 18:24:51 amrith: It's a bit hacky, and you'd need change the code to identify flavors with either the id or the uuid. 18:24:55 kevinconway: Sorry, I thought you meant what happens now. Yeah if we add a uuid which is a string I say if the number isn't an int we return None for the id field. 18:25:13 Rather than sometimes return a string for the ID. Then yo have people not knowing what it should be 18:25:21 well, the code right now appears to convert something to an integer and happily return it 18:25:30 but it totally sucks that the API barfs with a 500 today, if nova has a flavor that has a UUID. 18:25:34 so I'm assuming that whatever comes in is convert'able to int 18:25:51 yeah, uuid's have alpha chars 18:26:10 yes, so does the current code hurl if it gets one of those? 18:26:17 amrith: yep 18:26:42 would we want to continue to hurl if we added a uuid column? 18:26:51 because, if the answer is yes, we've not solved the problem 18:26:54 i don't think 500 is a part of the contract 18:26:58 amrith: no 18:27:44 amrith: No. So I think we have two choices on what to do for the "id" field if the actual value is a string 18:27:51 1) return "null" 18:27:58 2) return the actual string instead of the int 18:28:03 if it's an int, continue returning "id", if it's a uuid, return "uuid" field 18:28:05 to me 1) is clearer 18:28:14 in all cases we should return uuid as a string 18:28:19 where if it's an int, uuid also contains the id 18:28:22 correct 18:28:52 amcrn: I guess then we also have 3) don't return the id field at all 18:29:03 if int, return "id": 7, "uuid": "7"; if it's a uuid, return "uuid": "1-2-3-4" 18:29:03 since if you're using GUIDs for IDs it is useless to you anyway 18:29:04 so "id" will return the int (if it exists) and "uuid" return the string repr 18:29:05 is not returning id an options? 18:29:08 i dont think we can remove fields 18:29:10 if you don't return the id isn't that breaking? 18:29:14 grapex, amcrn wouldn't that last idea (not return id) break the contract 18:29:14 so id has to always be returned 18:29:20 iccha: You're right 18:29:26 amrith: you too 18:29:31 what i've proposed follows the existing behavior 18:29:36 though it is kind of ridiculous to have to return a field that people wouldn't be using 18:29:39 kevinconway: I don't think so - I think that would be an API change. 18:30:04 I think returning "null" is the only way then to stay close to the contract 18:30:12 I volunteered to do this (I still do). so for my own edification, may I summarize? 18:30:21 1. add a uuid 18:30:29 2. return uuid always (as a string) 18:30:41 3. if uuid converts to an integer, return it in the current id field 18:30:50 4. if uuid won't convert, return None in id 18:30:54 18:30:58 i don't agree with 4 18:31:10 sorry 18:31:10 could we make the id: -1 or 0? since it should be an int? 18:31:15 4. return Null? 18:31:20 don't return the field at all 18:31:24 people use 0 cp16net 18:31:29 aka ==> [11:29:15] if int, return "id": 7, "uuid": "7"; if it's a uuid, return "uuid": "1-2-3-4" 18:31:30 amcrn: but if we don't return none for id, and instead just don't have it, isn't that a contract break? 18:31:41 no, because there was no contract if it was a uuid, because it 500'd 18:31:49 amcrn: Agree... 18:32:02 maybe we just tell people we return None but actually don't return it at all since we all know its dumb 18:32:03 ah, amcrn hits nail on head 18:32:20 amcrn: How about we return mu 18:32:25 unless we _want_ to consider server errors a part of the API contract 18:32:29 so, amcrn what is your proposal for #4? 18:32:31 would reduce the number of bugs to fix 18:32:33 lol @kevinconway 18:32:40 kevinconway: lol 18:32:48 kevinconway: lol 18:32:59 So this has implications to trove-create as well. So are we now saying that we support creating instances by either passing in flavor id or uuid? 18:33:00 Hey don't fix those, our users like those 500s 18:33:21 SlickNik: I think on the create we can accept an int or a string 18:33:24 i think it's already a string in the case of create 18:33:33 since it can be a 'ref' 18:33:36 vipul, grapex +1 18:33:38 ah, in that case — carry on 18:33:39 yeah and other places where we reference flavors, it will be two cols to check 18:33:55 do we need to make any Horizon changes? 18:34:02 is there a panel that does a flavor-list? 18:34:08 amcrn, what would you do if id was not convert'able to int? 18:34:12 iccha: i think it's still one collumn 18:34:16 amrith: you don't return the id field 18:34:20 ok 18:34:32 vipul - horizon pulls in the flavor list into a bunch of choice boxes 18:34:39 1. add a uuid. 18:34:39 2. return uuid always (as a string). 18:34:39 3. if uuid converts to an integer, return it in the current id field. 18:34:39 4. if uuid won't convert, don't return id. 18:34:39 18:34:58 abramley: I suppose all those places will need to check if what got returned is a id or uuid 18:35:00 vipul: it should definitely be uprev'd to use the uuid, because if the id is conditionally available, that won't be good. 18:35:17 amcrn: we could just always use uuid i suppose 18:35:21 vipul: or we can start standardizing on uuid 18:35:32 amcrn: I agree — safest to change it to always use uuid 18:35:37 vipul - I had been wondering if we should switch hotizon to use the nova flavor-list 18:35:47 nooooo 18:35:53 abramley: hiss booo hiss ;) 18:36:01 i think we have plans to manage flavors independenty 18:36:12 vipul: =1 18:36:13 +1 18:36:14 yeah i think trove needs to 18:36:16 +1 18:36:17 word 18:36:36 abramley: tread carefully. 18:36:40 here be dragons :) 18:36:40 which they were recently talking about on the mailing list (tagging flavors to services) 18:36:47 vipul - in that case we need the api's to manage those flavors 18:37:10 yea there is a BP out there.. may even be started by someone and dropped on the floor 18:37:14 abramley: You mean do more than list them? 18:37:28 grapex: probably as an admin 18:37:44 makes sense 18:37:46 not to be a bother, but this conversation is tangential to the agenda item 18:37:47 grapex - you can create / delete flavors today in horizon for nova 18:37:48 vipul: I think I've seem something. 18:37:55 amcrn: +1 18:38:07 So we have a clear path forward for this work item then. 18:38:08 amcrn, I'd like to see if it uncovers any other things that must be done 18:38:17 (or not) 18:38:29 SlickNik has spoken. so it has been written, so it shall be done. 18:38:42 amrith: there maybe other things that this causes a problem 18:39:02 * amrith quickly erases all that was written 18:39:06 but now we have defined the goal 18:39:34 thanks for dedicating meeting time to this, everyone :) 18:39:38 amrith: And As It Is Such, So Also As Such Is It Unto You 18:40:14 adam_g: not a problem. I think amrith has a path forward for a fix to this that doesn't make a breaking API change. 18:40:27 ok, that works for me. let me get something working that does the four things I said. and I'll try and understand waht kevinconway said ;) 18:40:38 Any additional issues that come up, we can tackle when they come up as part of the code-review / tests. 18:40:55 thx adam_g 18:41:09 amrith, thanks for driving ! 18:41:16 the plan: 1. add a uuid 18:41:16 2. return uuid always (as a string) 18:41:16 3. if uuid converts to an integer, return it in the current id field 18:41:16 4. if uuid won't convert, return None in id 18:41:29 np 18:41:38 I think we're scrapping 4 — from our earlier discussion 18:41:54 so 4. if uuid won't convert don't return id 18:42:00 If I understood correctly 18:42:07 sorry, wrong cut/paste 18:42:14 1. add a uuid. 18:42:14 2. return uuid always (as a string). 18:42:14 3. if uuid converts to an integer, return it in the current id field. 18:42:14 4. if uuid won't convert, don't return id. 18:42:14 18:42:23 ??? 18:42:29 5. Profit? 18:42:44 lol kevinconway 18:42:50 Sounds good. 18:42:55 5. Fun or profit. 18:43:01 #topic Open Discussion 18:43:02 SlickNik, I'm all set. 18:43:19 Thanks amrith, and adam_g :) 18:43:30 Did anyone have anything for open discussion? 18:44:20 yes 18:44:31 does anyone know who Longgeek is? 18:44:38 he's the current owner of this bug 18:45:15 I'll take that as a no. 18:45:16 thx 18:45:37 Okay then. 18:45:40 #endmeeting