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