20:01:40 <hub_cap> #startmeeting trove
20:01:41 <openstack> Meeting started Wed Oct 23 20:01:40 2013 UTC and is due to finish in 60 minutes.  The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:45 <openstack> The meeting name has been set to 'trove'
20:01:47 <KennethWilke> hello
20:01:49 <robertmyers> o/
20:01:51 <kevinconway> 0/
20:01:51 <dmakogon_> щ.
20:01:54 <ashestakov> hi
20:01:54 <dmakogon_> o/
20:01:54 <cp16net> 0^/
20:02:03 <imsplitbit> o/
20:02:06 <hub_cap> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting
20:02:06 <datsun180b> here here
20:02:20 <hub_cap> #link http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-10-16-20.00.html
20:02:23 <grapex> o/
20:02:24 <hub_cap> #topic action items
20:02:33 <hub_cap> grapex: BUILDING_ERROR_DNS
20:02:35 <pdmars> o/
20:02:36 <do> hi everybody
20:02:40 <hub_cap> grapex to fix issue where instances in BUILDING_ERROR_DNS cannot be deleted.
20:02:54 <grapex> hub_cap: Argh! I didn't quiet finish this- I will soon. Sorry!
20:03:11 <hub_cap> do u have status on that grapex?
20:03:11 <vipul> o/
20:03:15 <kevinconway> grapex: did you do anything to finish that?
20:03:21 <[a]mcrn> o/ (until 13:30)
20:03:24 <grapex> hub_cap: I didn't do much of it yet, sorry.
20:03:28 <hub_cap> sorry grapex i didnt see your update
20:03:30 <imsplitbit> grapex: do you think the timeline is realistic
20:03:31 <hub_cap> doh
20:04:03 <hub_cap> ok so do u want me to keep it in grapex for next wk?
20:04:08 <grapex> hub_cap: I do.
20:04:11 <hub_cap> #action grapex to fix issue where instances in BUILDING_ERROR_DNS cannot be deleted.
20:04:22 <grapex> hub_cap: I'll be sure to do that before next week. Thanks!
20:04:39 <hub_cap> ok lets move on
20:04:50 <hub_cap> datsun180b to add backup status updates to conductor
20:04:53 <cp16net> lets do
20:05:02 <hub_cap> do u have updates for that datsun180b?
20:05:37 <datsun180b> gerrit review added backups to conductor this morning. do you know what your other two wishes are?
20:05:37 <kevinconway> datsun180b: do you have code?
20:05:37 <imsplitbit> datsun180b: please do update us
20:06:19 <hub_cap> lulz
20:06:26 <cp16net> <3
20:06:40 <hub_cap> ok so moving on?
20:06:44 <datsun180b> working on adding robertmyers' suggestions through real-mode tests presently, i'll append a new review when those clear
20:06:45 <dmakogon_> нгз
20:06:48 <dmakogon_> yup
20:07:00 <hub_cap> #topic conductor support
20:07:23 <datsun180b> well if it was an action then i don't know that it needs to be a topic too
20:07:37 <robertmyers> datsun180b: good work
20:07:43 <hub_cap> datsun180b: link your reviews
20:08:07 <datsun180b> #link https://review.openstack.org/#/c/45116/
20:08:20 <hub_cap> ok so status is waiting for reviews eh?
20:08:22 <datsun180b> i'll abandon the other once since the two pieces are now fused
20:08:55 <hub_cap> oh man
20:09:06 <hub_cap> maybe we should make them dependent commits on each other
20:09:11 <datsun180b> nope, abandoned
20:09:11 <hub_cap> thats a topic i need to gain more clarity on
20:09:24 <hub_cap> dukhlov: has an issue with a huge commit
20:09:25 <vipul> datsun180b: Do you think we should completely remove the sql_connection string in the conf?
20:09:43 <hub_cap> and we need to find a way to split them better, and i think this is another case of that datsun180b
20:09:50 <vipul> datsun180b: If we are sure that we don't need db anymore -- we should do that
20:09:56 <grapex> hub_cap: I'd like to discuss it at some point. I think we should tiny commits with one idea each, but they shouldn't be so small they are dependent on each other.
20:10:18 <hub_cap> grapex: yes can u add it to the agenda (breaking up commits)
20:10:29 <datsun180b> vipul: worth adding that to the review i'd say, but i'll agree when conductor isn't optional
20:10:54 <vipul> datsun180b oh so you have made it optional
20:11:18 <datsun180b> i tried splitting the conductor work up earlier, and it kind of didn't go anywhere so today i figured i'd just stack the backups stuff on top and get it all done in one swipe
20:11:22 <robertmyers> if we make it not optional that would clean it up a lot
20:11:35 <dmakogon_> robertmyers, yes
20:11:36 <datsun180b> the backups needed to be redone so conductor _could_ do the work
20:11:42 * hub_cap is confused... its optional?
20:11:45 <dmakogon_> that is why it should be done
20:11:48 <grapex> vipul: is making it optional as important if it completely replaces guest agent communication to the db in one fell swoop?
20:11:58 <dmakogon_> because we have huge refactoring coming
20:12:01 <datsun180b> hub_cap: by request it was, because in rev1 it didn't completely sever the db tie
20:12:10 <grapex> vipul: Previously I had issues as I felt pushing conductor would force anyone using the reference agent to use both conductor as well as allowing db access from the agent
20:12:14 <vipul> grapex: No.. I think if we catch everything then I am ok with it not being optional
20:12:26 <grapex> vipul: Cool.
20:12:42 <robertmyers> lets do it then
20:12:50 <hub_cap> #action conductor is no longer optional
20:12:54 <vipul> so just as a side though
20:13:03 <hub_cap> #undo
20:13:04 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x1765d10>
20:13:12 <vipul> we've run nova-network in multi-host.. we had to disable nova-conductor
20:13:17 <vipul> because it couldn't keep up with the status updates
20:13:28 <datsun180b> yeah making it not optional isn't tough
20:13:34 <hub_cap> #action datsun180b to make conductor no longer optional
20:13:45 <hub_cap> vipul: thats not a very nice bug :o
20:13:46 <datsun180b> especially compared to refactoring backups mid-change without breaking my stride
20:13:57 <datsun180b> >:C
20:14:37 <hub_cap> vipul: so we have a issue where a deployed conductor started choking right, the nova conductor?
20:15:01 <grapex> vipul: In that case, I know it could be considered cruft but maybe we should keep using it optional for awhile
20:15:17 <hub_cap> maybe that means we should deploy >1 conductor  in a given topic, eh?
20:15:18 <vipul> hub_cap: Yes.. so if we feel confident the same won't happen with trove-conductor then i'm ok with making it required
20:15:24 <vipul> but it's a insurance policy in case
20:15:43 <grapex> vipul: I like insurance. :)
20:15:45 <hub_cap> vipul: is nova-conductor disabled?
20:15:46 <vipul> hub_cap: That's an option.. it really depends on how many guests you have
20:15:49 <hub_cap> or just on a per-host
20:16:00 <grapex> I vote we keep it optional for now until we have more data on its real world behavior.
20:16:08 <robertmyers> how often are the heart beats?
20:16:14 <hub_cap> i believe the "insecure" way for nova-conductor was to put it on each host
20:16:15 <vipul> 90 seconds maybe
20:16:15 <datsun180b> robertmyers: ~1minute?
20:16:19 <datsun180b> maybe 90 seconds
20:16:34 <vipul> hub_cap: yep, then it defeats the purpose of conductor which was no db access to other things
20:16:47 <hub_cap> vipul: well somewhat
20:17:05 <hub_cap> if u get root access to the vm u still dont ahve db access unless u can get on the host
20:17:12 <hub_cap> or craft msgs, knowing the uuid's of other guests
20:17:13 <kevinconway> robertmyers: the guests should just send a message when they die
20:17:19 <kevinconway> letting everyone know that it died
20:17:21 <kevinconway> sounds simple
20:17:29 <robertmyers> dead simple
20:17:39 <hub_cap> kevinconway: lol
20:17:41 <grapex> kevinconway: It would look like "{ 'method':'death', 'args', 'aarggggggghhhhh'}"
20:17:53 <datsun180b> well what if it sends the swansong 90 seconds before it dies
20:17:55 <esp> kevinconway: like a suicide letter?
20:18:00 <datsun180b> that way we'll know ahead of time
20:18:01 <hub_cap> 'message': 'i regret nothing'
20:18:02 <grapex> esp: That's even better
20:18:04 <vipul> lol esp
20:18:12 <hub_cap> ok srsly though
20:18:19 <datsun180b> especially if it's for an unpredicted reason or a kp or segfault or something
20:18:28 <hub_cap> im ok w/ making conductor disable'able
20:18:34 <hub_cap> but the thing that scares me is that if its disable-able
20:18:34 <vipul> datsun180b, grapex: i say we make it optional for v1
20:18:38 <hub_cap> that means everyone will disable it
20:18:42 <hub_cap> and bugs wont ever get fixed
20:18:43 <vipul> let's enable it in gate
20:18:51 <datsun180b> hooray, less work for me
20:18:54 <hub_cap> if it requires u to put it on every host, like nova-conductor
20:19:01 <hub_cap> then its obvi that there is an issue
20:19:58 <vipul> we can deprecate it in 'J'
20:20:39 <hub_cap> deprecate what? the old comm layer? in J /
20:20:40 <hub_cap> ?
20:20:46 <vipul> the optional flag
20:20:50 <grapex> vipul: Hmm- there were some things, like scheduled backups, that depended on this though. :(
20:20:57 <hub_cap> or we can make it non optional
20:21:08 <hub_cap> and make u do the _exact_ same thing u have to do anywya for nova-conductor
20:21:25 <hub_cap> and since its running in your env  you have a reason to try to fix it
20:21:27 <datsun180b> use_conductor is defaulted to True in cfg.py fyi
20:21:32 <hub_cap> rather than leaving it disabled ;)
20:21:52 <vipul> fair enough.. the only thing with that is it'll be another thing that has to run alongside guest
20:21:57 <hub_cap> what scares me vipul
20:22:03 <hub_cap> is that a 3rd thing will come along which needs db acces
20:22:14 <hub_cap> then we have to build 2x ways to talk to the db for that _thing_
20:22:24 <hub_cap> because its optional
20:22:53 <vipul> Sure yea it'll be a headache to support all these code paths
20:23:08 <hub_cap> so we deal w/ the fact that we have a known issue and have 1 logic path
20:23:38 <hub_cap> and spend cycles fixing it rather than spend cycles on building the next thing w/ 2 db paths
20:24:32 <datsun180b> i'm all for stamping out the "guest agent can just update the host db" idea forever
20:24:46 <vipul> sure - It may be the case that we have a lot less traffic going to conductor.. and it may not cause issues like it does for nova
20:24:50 <datsun180b> so if anyone suggests a new feature that uses it we can all exchange sidelong glances and knowing smiles
20:25:15 <vipul> we just gotta be careful it doesn't become the sink for every db request
20:25:19 <hub_cap> ok we are almost 30 min in on this subject
20:25:29 <datsun180b> i thought its whole point was to be the sink
20:25:59 <vipul> For the Guest Agent.. possibly.. since it doesn't do a whole lot anyway with the DB
20:26:04 <hub_cap> the agent shouldnt _need_ db access to read
20:26:10 <hub_cap> it should be passed wht it needs
20:26:18 <hub_cap> if it needs to update the db it uses conductor
20:26:18 <hub_cap> for now
20:26:21 <datsun180b> right, it should be the sink for GAs access to the db
20:26:28 <hub_cap> for GA writes to the db
20:26:39 <hub_cap> for GA reads, we pass in the info it needs
20:27:00 <datsun180b> ^^ captured in my changes to backup's process fyi
20:27:01 <vipul> ok works for me
20:27:23 <hub_cap> ok so non-optional vipul?
20:27:37 <imsplitbit> go!
20:27:42 <vipul> sure -- we'll be sure to test it out
20:27:47 <hub_cap> heh ya :)
20:28:04 <hub_cap> ok moving on
20:28:13 <hub_cap> #topic Tempest for integration tests
20:28:17 <hub_cap> so this was on last wk
20:28:24 <hub_cap> but i dont think it was discussed
20:28:47 <hub_cap> with clarkb and co we defined a way to preseed the nodes with the needed stuff for diskimage builder
20:29:03 <hub_cap> then devstack can build the images easier / faster
20:29:24 <dmakogon_> hub_cap, could we use heat-jeos for images ?
20:29:37 <dmakogon_> hub_cap, it is official part of heat
20:29:39 <hub_cap> then we can run those w/ tempest tests after devstack uploads them
20:29:53 <hub_cap> dmakogon_: if heat-jeos uses dib then yes
20:29:57 <hub_cap> dib is waht we use
20:30:06 <hub_cap> http://docs.openstack.org/developer/heat/getting_started/jeos_building.html
20:30:10 <hub_cap> diskimage-builder/bin/disk-image-create vm fedora heat-cfntools -a amd64 -o fedora-heat-cfntools
20:30:19 <hub_cap> correct dmakogon_: that tutorial uses dib
20:30:32 <hub_cap> this is what weve done since the beginning of dib
20:30:53 <dmakogon_> hub_cap, i will start ML thread for this
20:31:01 <hub_cap> dmakogon_: why?
20:31:06 <hub_cap> we know what we are doing
20:31:13 <hub_cap> what do u need to discuss?
20:31:24 <dmakogon_> hub_cap, i think we nee several options
20:31:29 <hub_cap> nope not for testing
20:31:35 <hub_cap> you can do whatever u want dmakogon_ in production
20:31:42 <dmakogon_> k
20:31:58 <hub_cap> this topic is specific for tempest testing (see the topic change above)
20:32:14 <dmakogon_> i know
20:32:23 <hub_cap> so this will be useful for the old tests (the ones run by jenkins) and the new ones (tempest)
20:32:30 <dmakogon_> any updates with trove framework ?
20:32:45 <hub_cap> with respect to testing?
20:33:28 <dmakogon_> yes
20:33:36 <hub_cap> nope we dont need to test it
20:33:39 <hub_cap> im sorry
20:33:43 <hub_cap> we dont neec to change it to test
20:33:57 <hub_cap> moving on? other questions?
20:34:09 <dmakogon_> hm, could you describe your plans for tempest and trove
20:34:11 <dmakogon_> please
20:34:15 <hub_cap> demorris: around?
20:34:29 <hub_cap> dmakogon_: plans are well known, i descibed them above
20:34:35 <hub_cap> but i will write up a wiki article explaining
20:34:42 <dmakogon_> hub_cap, thanks
20:34:46 <hub_cap> #action write up wiki article wrt testing + tempest + trove
20:34:52 <hub_cap> #totpic Blueprint Rigor / Structure
20:34:56 <hub_cap> lol totpic
20:34:59 <hub_cap> #topic Blueprint Rigor / Structure
20:35:23 <hub_cap> so demorris has brought to attention the lack of details on some of our blueprints
20:35:45 <hub_cap> and possibly that we come up with a base structure for them, so that we dont get 1 line blueprints that really do a terrible job at describing things
20:36:10 <hub_cap> so i agree that we (the people on teh bug triage team) need to better triage this
20:36:59 <hub_cap> i also think that we need to be blueprinting early rather than creating a blueprint after we finish the code
20:37:02 <hub_cap> box
20:37:04 <hub_cap> just as a check bo
20:37:18 <dmakogon_> agreed
20:37:32 <hub_cap> so the bug triage team needs to do better work here
20:37:45 <hub_cap> cuz i dont think we have a bug triage team if i look @ the "new" bugs in trove
20:37:50 <vipul> hub_cap: yup agree with evyerthing you said
20:37:53 <grapex> hub_cap: True, but will a lack of blueprints some time before code is finished mean completed code can't be checked in? What in the case of tinier items?
20:37:57 <hub_cap> 37 New bugs
20:38:11 <hub_cap> grapex: everythign needs a blueprint
20:38:18 <hub_cap> jk
20:38:25 <hub_cap> i thik we can relax rules on blueprints sometimes
20:38:31 <hub_cap> if its a VERY small change, and not pertaining to a bug
20:38:36 <hub_cap> i think its ok to not have a blueprint
20:38:37 <grapex> For example, if someone is looking at the code and finds a small thing they can fix, I'd rather they make a tiny blue print for it rather than list it as a bug.
20:38:42 <demorris> hub_cap: sorry, my wireless is spotty on the ride back to Austin, I take it we are talking about my BP topic
20:38:47 <grapex> hub_cap: Ok, no blue print for those cases is even better. :)
20:38:50 <hub_cap> demorris: we were ;)
20:38:54 <kevinconway> so if i have a cool idea i want someone else to do, can i make a blueprint?
20:38:57 <hub_cap> jk demorris but we have spoke a lot about it
20:39:01 <hub_cap> kevinconway: hell yes u can
20:39:03 <hub_cap> and should
20:39:08 <demorris> k, i could drop at any moment, but I will try to contribute while I am connected
20:39:38 <hub_cap> demorris: i covered it from your perspective i think
20:40:33 <vipul> one other point.. is we discuss any blueprints in IRC, the author shoudl be responsible for capturing the decision points and writing them up in teh BP
20:40:46 <hub_cap> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
20:40:52 <hub_cap> thats to vipul ^ ^
20:41:07 <hub_cap> otherwise t hey will have to deal with us asking the same questions over and over hehe
20:41:18 <vipul> I have a hard time keeping up with eveything we've talked about.. so it'll make it easier at review time
20:42:18 <hub_cap> #action bug triage team to police blueprints better
20:42:52 <hub_cap> ok time to move on!!
20:43:02 <cp16net> do it!
20:43:10 <hub_cap> #topic Datastore types
20:43:16 <hub_cap> ashestakov:  ^ ^ go!
20:44:07 <ashestakov> guys, review it pls, i know there are lot of changes, but it already blocker for another things
20:44:13 <hub_cap> ashestakov: plz link the reviews
20:44:17 <hub_cap> just so we can see them
20:44:19 <hub_cap> #link them
20:44:36 <jodom> ashestakov: is the blueprint up to date with the current implementation?
20:44:36 <ashestakov> 1 min, im from another pc
20:44:55 <ashestakov> jodom, not at all
20:45:11 <ashestakov> it contains no new updates
20:45:50 <jodom> ashestakov: ok, perhaps i need to go read through the mailing list thread to see where we landed based on grapex's feedback.
20:46:09 <demorris> i believe the API changed a bit, so it would be helpful to see that updated on the core BP
20:46:21 <hub_cap> ++
20:46:25 <jodom> +1
20:46:33 <ashestakov> https://review.openstack.org/#/c/47936/ cli
20:46:35 <demorris> not that I am opposed to anything specific, just want to see the holistic spec
20:46:49 <ashestakov> https://review.openstack.org/#/c/47934/
20:47:45 <ashestakov> hub_cap: can you share link to my gist with doc draft?
20:47:52 <hub_cap> yes sec
20:48:00 <hub_cap> crap i closed your gist ashestakov
20:48:11 <hub_cap> ashestakov: fwiw, make your gists public
20:48:22 <ashestakov> let me recover it
20:48:55 <kevinconway> also, to anyone making gists: please make the text fit in the box
20:49:04 <hub_cap> ++ kevinconway
20:49:10 <ashestakov> https://gist.github.com/andreyshestakov/657d7cb0528092f4c6e9
20:49:19 <demorris> did we settle on the topic around nesting versions with a datastore type?  And also the issue around GUID's for types vs. just string names?
20:49:23 <ashestakov> this draft
20:49:35 <hub_cap> ashestakov: plz update to put in the wiki :)
20:49:42 <hub_cap> and make your gists public ;)
20:49:48 <datsun180b> use #link for your links pretty please
20:49:49 <grapex> ashestakov: I find gists harder to follow than the ML
20:49:49 <kevinconway> and fit in the box
20:49:52 <ashestakov> will do, once finish
20:50:00 <hub_cap> like this hehe
20:50:00 <hub_cap> https://gist.github.com/hub-cap?page=10
20:50:34 <hub_cap> ok so we moving on?
20:51:22 <hub_cap> ill tkae that as a yes!
20:51:24 <demorris> well, I am still not sure of the status...
20:51:34 <hub_cap> demorris: status is that there are revies
20:51:36 <hub_cap> *reviews
20:51:40 <demorris> whats left on this one, the review is in, there are a few outstanding comments
20:51:44 <ashestakov> demorris, now it supports names and uuids
20:51:45 <demorris> and we want the wiki BP updated
20:51:53 <grapex> demorris: I'm updating my review of it with a few more issues
20:52:06 <grapex> Minor stuff
20:52:13 <demorris> grapex: okay
20:52:18 <hub_cap> demorris: so its still in flight more or less
20:52:19 <grapex> Though there are currently no tests associated with the PR
20:52:29 <ashestakov> anything else except minor stuff?
20:52:39 <demorris> so maybe in the next day we could be done talking about this one :)
20:52:51 <hub_cap> ashestakov: i htink its all minor at this point
20:52:59 <hub_cap> demorris: feel free to review the code ;)
20:53:13 <hub_cap> yogeshmehra do we need to talk about "multiple node templates"
20:53:16 <hub_cap> im not sure if that was from last wk
20:53:19 <ashestakov> if only minor staff left, i can fix it even today
20:53:23 <yogeshmehra> yes...
20:53:27 <yogeshmehra> hello...
20:53:28 <demorris> oh I have browsed it…i think ashestakov has done a great job
20:54:03 <hub_cap> yogeshmehra: did u discuss that last wk? or is that a new item?
20:54:10 <demorris> i am not going to get in the business of reviewing y'alls code…I'll stick to spec's and BP's for now :)
20:54:16 <hub_cap> #topic Multiple Node templates
20:54:18 <yogeshmehra> hub_cap:this is new item
20:54:24 <hub_cap> ok go yogeshmehra
20:54:30 <dmakogon_> nice topic
20:54:34 <dmakogon_> i like it
20:54:39 <yogeshmehra> :-)
20:54:42 <dmakogon_> (facebook like)
20:54:52 <dmakogon_> ;)
20:55:06 <yogeshmehra> current trove/heat integration even with the externalization is incomplete..
20:55:49 <yogeshmehra> some maintenance of the stack within trove....topics like this are pending even before we get into clustering/replication
20:56:28 <dmakogon_> yogeshmehra, could you describe bottlenecks ?
20:56:54 <yogeshmehra> will the guestagent be running on all nodes...
20:57:00 <dmakogon_> yogeshmehra, what kind of problems do we have ?
20:57:05 <dmakogon_> yes
20:57:10 <yogeshmehra> would there be multiple prepare msgs posted for each of the nodes from task manager
20:57:22 <dmakogon_> yes
20:57:26 <dmakogon_> i suppose
20:57:27 <vipul> currently we don't keep track of the multiple nodes in Trove
20:57:42 <yogeshmehra> i went through: https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API
20:57:45 <dmakogon_> vipul, because we don't have 2
20:57:54 <vipul> do we keep track of the stack id?
20:58:01 <imsplitbit> yogeshmehra: thank you!
20:58:03 <dmakogon_> no
20:58:12 <dmakogon_> vipul, no
20:58:16 <vipul> so how do we do things against the 'stack'?
20:58:34 <vipul> and what are things that shoudl be done against the 'stack' through heat vs. directly through Nova
20:58:35 <dmakogon_> creating instance/volume - that is all
20:58:38 <yogeshmehra> dmakogon_: no for>
20:58:41 <yogeshmehra> no for?
20:58:47 <vipul> what about restart / resize,e etc
20:58:56 <hub_cap> 2 minutes
20:59:03 <dmakogon_> vipul, doing it with nova
20:59:13 <vipul> that breaks down when you have >1 instance no?
20:59:17 <dmakogon_> vipul, heat only creates stack
20:59:27 <dmakogon_> vipul, somehow
20:59:33 <yogeshmehra> dmakogon_: along with instances...
21:00:13 <yogeshmehra> how does the framework take care of multiple nodes getting "prepare"d
21:00:13 <vipul> probably need to continue in #openstack-trove
21:00:23 <kevinconway> or ML
21:00:26 <hub_cap> yes vipul
21:00:33 <dmakogon_> ML would be great
21:00:47 <hub_cap> ML ftw
21:00:53 <hub_cap> #endmeeting