18:02:44 <SlickNik> #startmeeting trove
18:02:46 <openstack> Meeting started Wed Jul 16 18:02:44 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:50 <openstack> The meeting name has been set to 'trove'
18:03:00 <grapex> o/
18:03:03 <vipul> o/
18:03:05 <annashen_> o/
18:03:13 <johnma> Hello
18:03:13 <iccha> o/
18:03:21 <cp16net> o/
18:03:21 <amrith> 0/
18:03:24 <tvoran> o/
18:03:27 <robertmyers> o/
18:03:30 <pdmars_> o/
18:03:33 <esp> o/
18:03:50 <SlickNik> Agenda at
18:03:53 <SlickNik> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting
18:04:06 <kevinconway> o/
18:04:12 <dougshelley66> o/
18:04:25 <SlickNik> Summary from previous meeting at:
18:04:27 <SlickNik> #link http://eavesdrop.openstack.org/meetings/trove/2014/trove.2014-07-09-18.00.html
18:04:33 <mattgriffin> o/
18:04:35 <amcrn> o/
18:04:40 <vgnbkr> o/
18:04:58 <SlickNik> No specific action items from last time, so let's get started with Agenda topics.
18:05:01 <michael-yu> o/
18:05:06 <peterstac> o/
18:05:21 <SlickNik> #topic Initial Clustering UI options
18:05:38 <SlickNik> michael-yu: all yours.
18:05:46 <michael-yu> cool. thanks, SlickNik.
18:05:56 <michael-yu> i'll give everyone a chance to look at the wiki
18:06:00 <michael-yu> https://wiki.openstack.org/wiki/Trove-Clustering-UI
18:06:25 <michael-yu> in short, i have a couple of proposals for clustering UI
18:06:31 <michael-yu> you can see the mock screenshots there
18:07:29 <esp> michael-yu: nice screen shots :)
18:07:41 <michael-yu> thanks esp
18:07:50 <cp16net> i like pretty pictures
18:07:59 <SlickNik> michael-yu: Nice work on the mock screenshots!
18:08:00 <robertmyers> michael-yu: looks good
18:08:06 <michael-yu> thanks everyone
18:08:15 <michael-yu> i'm opening the floor up to any questions
18:08:23 <michael-yu> before i go into a question i have for discussion
18:08:41 <dougshelley66> michael-yu: I noticed the "Datastore" on the launch dialog has "2.4"?
18:08:56 <michael-yu> ah yes
18:09:02 <dougshelley66> seems like the "Mongo" bit is missing - just wondering how the type of cluster gets specififed
18:09:03 <cp16net> michael-yu: for every cluseter you create are you always going to "add shard"
18:09:07 <michael-yu> that is based on the single drop down horizon patch
18:09:07 <peterstac> Right, shouldn't there be a datastore version as well?
18:09:08 <robertmyers> I prefer the first option rather then the expand view inside the list
18:09:08 <cp16net> or is that just the case of mongo
18:09:30 <vipul> that '# of shards' stuff seems confusing
18:09:49 <michael-yu> peterstac / dougshelley66 - if you recall, the single drop down auto selects if there's only one
18:10:13 <dougshelley66> michael-yu: right - just wondered where the "Mongo" part is
18:10:14 <michael-yu> and for that mock shot, there's only "mongodb" -> "2.4"
18:10:46 <dougshelley66> ok so on the "Add shards" part - is that specific to the type of cluster?
18:10:56 <michael-yu> doughshelley - if you click on the datastore drop down, you would see "mongodb"
18:11:09 <michael-yu> dougshelley66 / cp16net - correct
18:11:18 <michael-yu> for mongodb
18:11:36 <dougshelley66> ok so some other type of cluster might generate different UI elements?
18:11:43 <cp16net> fwiw i think the first option is a better view than the accordion example
18:11:58 <iccha> i prefer the first option as well, because the expanded row has way too much information
18:12:01 <SlickNik> cp16net: robertmyers said the same thing as well, and I agree with that.
18:12:18 <michael-yu> dougshelley66 - correct. when additional data stores are supported for clustering, those changes or refactoring needs to come in
18:12:54 <cp16net> if there is some other awesome way maybe later it can look like that :-P
18:13:10 <cp16net> but this should be good and convey the data we have
18:13:20 <dougshelley66> I was wondering if we could get a quick status as to the Clustering API? I assume if must be far along given you are building out UI elements for it?
18:13:28 <dougshelley66> s/if/it
18:13:30 <esp> cp16net: +1
18:13:47 <amcrn> dougshelley66: it's working, we're finishing up some tests + refactoring
18:14:05 <dougshelley66> amcrn: thx
18:14:15 <amcrn> dougshelley66: plus adding some more of the minor aspects (blocking existing instance operations that are dangerous in cluster environments, etc.)
18:14:23 <dougshelley66> amcrn: are you still aiming for Juno?
18:14:36 <robertmyers> so how will other datastore register the name to 'add shard'
18:14:42 <amcrn> dougshelley66: we'll see
18:14:49 <cp16net> amcrn: thats tite
18:14:50 <amcrn> dougshelley66: that's up the reviewers ;)
18:14:53 <amcrn> up to the*
18:14:54 <ramashri> for what its worth, the accordian style does present data on a single screen rather than having to back and forth by clicking into a cluster
18:15:07 <dougshelley66> amcrn: :)
18:15:12 <SlickNik> amcrn / michael-yu: Thanks. I know mattgriffin had some ideas around trying to add support for xtradbcluster, so he was very interested in taking a look at the clustering API pieces.
18:15:26 <cp16net> robertmyers: good question.
18:15:26 <robertmyers> WHat if you made multiple tables in the cluster list
18:15:33 <robertmyers> one for eash cluster
18:15:33 <michael-yu> ramashri: that is correct. from the UX standpoint, the accordion could make more sense. thoughts?
18:15:38 <robertmyers> with all the instances in it
18:15:42 <peterstac> ramashri: I agree - would probably be faster too
18:16:50 <vgnbkr> How are different node types/rolls (Arbiter etc) selected?
18:16:59 <michael-yu> robertmyers: our thoughts are that we take the same approach as when MySQL was the first datastore supported.  The initial clustering UI will reflect and support the first iteration of clustering (which will be for MongoDB).
18:17:03 <ramashri> robertmyers, the accoridian style is preferable over the multiple tables since it allows the user to select which cluster detail he wants a view into
18:17:18 <robertmyers> michael-yu: http://docs.openstack.org/training-guides/content/figures/5/a/figures/image10.jpg
18:17:26 <robertmyers> sort of like that
18:17:26 <amcrn> vgnbkr: different node types aren't supported in the first iteration
18:18:31 <michael-yu> robertmyers: what would each table be?
18:18:40 <michael-yu> one table for mongodb clusters?
18:18:46 <robertmyers> the cluster with the controls
18:18:48 <michael-yu> another for couch base clusters?
18:18:59 <robertmyers> no, one for each cluster
18:19:02 <michael-yu> hmm...
18:19:11 <michael-yu> i don't know about that
18:19:14 <robertmyers> then the table would be the instances
18:19:17 <michael-yu> for N number of clusters i have, i would see N tables
18:19:22 <SlickNik> robertmyers: So it changes when you click on the cluster in question?
18:19:29 <michael-yu> what if N is large
18:19:39 <amcrn> robertmyers: the issue with that is, if you have a particular tenant in certain environments that will be responsible for all production deployments, that is a *ton* of tables
18:19:40 <robertmyers> pagination?
18:20:08 <robertmyers> well, they'll have an issue either way
18:20:20 <robertmyers> but I'm just giving ideas
18:20:51 <michael-yu> robertmyers: yup, understood. thanks.
18:21:12 <ramashri> the accordian gives best of both (summary list of all clusters) with a peek into details of the cluster the user needs a look at
18:21:24 <SlickNik> michael-yu: I don't dislike the idea of an accordion. I'm not sure I like that particular view in the accordion. A couple of things I don't like about it are — 1. A lot of wasted space on the right, 2. It has tabs in the accordion view.
18:21:30 <abramley> michael-yu - I have used the accordion style UI in I think the containers screen - and I find it very diffiicult to read - the layout never looks right to me
18:21:42 <kevinconway> i like pie graphs
18:22:22 <amcrn> kevinconway: i like pie, particularly apple
18:22:22 <cp16net> kevinconway: dont you mean pi
18:22:47 <robertmyers> SlickNik: +1
18:22:54 <michael-yu> SlickNik: thanks for pointing that out. as for #1… i didn't do a good job on the mock on that as i'm not a pro on html/css… but i was hoping to convey that the entire details tabs covers the length of entire row
18:23:01 <michael-yu> not just one column as you see in the mock
18:23:05 <ramashri> from a op admin standpoint accoridan could be useful, though i couldnt speak to aesthetics... slicknick you have any ideas on how the aesthetics can be better
18:24:04 <michael-yu> abranley: understood. it's both a pro and con. pro in that you get a quick and easy way to look into the cluster details as ramashri pointed out. con in that it could be cluttered with information,
18:24:10 <michael-yu> abramley
18:24:10 <SlickNik> michael-yu: I think for a v1 implementation it might be prudent to leave out the accordion. It can be added as a separate task later.
18:24:34 <SlickNik> michael-yu: I'd assume we'd want to do something similar with instance details as well, so this might not be specific to clusters.
18:24:40 <michael-yu> SlickNik: ok. i like that idea.
18:24:47 <esmute> instead of the accordion, is it possible to have a hover panel showing the overview?
18:24:50 <SlickNik> michael-yu: Perhaps as part of a different UX improvement BP?
18:24:58 <esmute> Or are they not standard in horizon?
18:24:58 <michael-yu> plus the implementation for v1 will most likely be used for accordion
18:25:34 <SlickNik> michael-yu: yup.
18:25:35 <michael-yu> esmute: that was an option we ran through, but haven't seen that elsewhere in horizon. anyone know?
18:25:42 <abramley> esmute - for consistency I think we would want to work with the horizon folks to have a similar way of doing this across all of the dashboard - we shouldn't pick a different UI paradigm for the trove components
18:25:42 <michael-yu> SlickNik: sounds goopd
18:25:43 <ramashri> SlickNik: why shouldnt we have accordian/hover for V1
18:26:13 <esmute> abramley: yeah that is what i thought.. but it does look better and slicker with the hover
18:26:15 <abramley> esmute - not saying it is a bad idea -just we should aim for consistency too
18:26:52 <vgnbkr> I assume the Instances tab enumerates the instances for a shard.  Will it have options to add/delete instances in a shard?
18:26:54 <SlickNik> ramashri: because this isn't UI that's specific to clusters. It really is a _different_ UX work item (i.e. how do we surface details (either instance or cluster) inline so that the user doesn't  have to click back and forth)
18:27:15 <amcrn> vgnbkr: deleting instances in a shard will not be supported in the first iteration
18:27:23 <michael-yu> vgnbkr: add shard possibly for v1. delete shard no.
18:28:13 <vgnbkr> What does a user do if an instance crashes and isn't recoverable?
18:28:16 <ramashri> SlickNik: thanks for clarifying, I still think it should nto be a separate effor because effort is double and it also puts onus on person doing the improvement to improve all or none
18:28:35 <amcrn> vgnbkr: the first iteration isn't mean to be production-deployable; as is the case with our cassandra + mongo standalone instance implementations
18:29:15 <iccha> michael-yu: what if we had selected items in the accordion view and then the user would have to click on it to go to a seprate page for more detailed view?
18:29:44 <michael-yu> iccha: for example what kind of selected items?
18:29:51 <SlickNik> ramashri: I'm fine with doing them separately, or incrementally; just pointing out that we should plan to address both to have a consistent UX, and that it's not cluster specifix.
18:30:10 <SlickNik> specific*
18:30:38 <michael-yu> iccha: also the point of having the accordion is so that they don't have to navigate to a different page
18:30:54 <SlickNik> Okay, we should move on to the next topic.
18:31:11 <ramashri> SlickNik: agree that both should be addressed. I am just concerned that it is double the effort to do first option UI and then do the accordian as well
18:32:33 <SlickNik> ramashri: is it really double? That view needs to be implemented anyway for the on-click, I think. The difference is whether you also implement it as an accordion or not.
18:32:43 <michael-yu> SlickNik is correct
18:32:51 <SlickNik> ramashri: Let's talk about it offline after the meeting in the interest of time.
18:32:54 <ramashri> ok i rest my case
18:32:55 <michael-yu> accordion work needs the first option UI work
18:33:23 <SlickNik> #topic Doc Scrub Update
18:33:38 <amrith> SlickNik, I have something for this topic
18:33:46 <SlickNik> #link https://etherpad.openstack.org/p/trove-doc-items
18:34:21 <SlickNik> So I added a couple of new sections: reviewer(s), and reviews
18:35:20 <SlickNik> The idea being that people can volunteer do reviews of certain docs, and folks can add links to the reviews as they work on them so that the reviewers can review them
18:35:25 <SlickNik> amrith: go for it.
18:35:36 <amrith> ok
18:35:43 <amrith> I'd signed up for the guest image piece at the meeting on 09
18:35:53 <amrith> there was a conversation at that meeting about jeos being outdated
18:36:01 <amrith> and therefore superceded (sp?) by dib
18:36:07 <amrith> I've been working on my part of this
18:36:18 <amrith> today I notice a commit for the jeos stuff and it is now in the reviews section
18:36:27 <amrith> I notice also that johnma was reviewing it (comments on irc0
18:36:30 <amrith> icr)
18:36:32 <amrith> irc)
18:36:35 <amrith> was confused
18:36:41 <amrith> are you still looking for dib documentation
18:36:42 <amrith> or not?
18:36:58 <amrith> didn't want to spend my time (and laurel's potentially) if the commit denis pushed up is sufficient
18:37:00 <amrith> or required
18:37:03 <amrith> <eof>
18:37:36 <SlickNik> amrith: AFAIK heat-jeos is superseded by dib
18:38:01 <SlickNik> and we should have docs detailing the image-building procedure using diskimage-builder.
18:38:11 <amrith> ok, thx. I'll keep going
18:38:15 <amrith> update on status.
18:38:19 <amrith> slower than I had expected
18:38:34 <SlickNik> I'm not sure why denis pushed up heat-jeos related image building instructions, but I can follow up with him on that.
18:38:43 <amrith> I will try to get to juno-2 deadline.
18:39:05 <amrith> thanks
18:39:21 <amrith> <done with my update>
18:39:30 <johnma> yes I just started reviewing it and noticed that there were heat documentation on doing it both ways - DIB and JEOS. So should I hold off on doing the reviews
18:39:57 * amrith redirects question to SlickNik
18:40:38 <SlickNik> johnma: If you look here: https://github.com/sdake/heat-jeos you'll see a note about heat-jeos being superseded.
18:40:57 <SlickNik> johnma: So I would wait for the dib docs to land and would review those.
18:41:21 <johnma> ok, sounds good. Thanks
18:41:23 <SlickNik> hopefully amrith and laurelm will push that patch up soon to review.
18:41:34 <SlickNik> Thanks johnma for signing up to review these docs.
18:41:36 * amrith runs for cover
18:41:57 <johnma> sure, glad to help out :)
18:42:25 <SlickNik> Okay, other folks feel free to sign up as reviewers.
18:42:53 <SlickNik> shayneburgess isn't here, so I'm going to "volunteer" him to review a few docs. :P
18:43:14 <SlickNik> Any other questions regarding the doc-scrub update?
18:43:33 <SlickNik> Hoping to whip this up into shape soon!
18:44:04 <SlickNik> #topic Juno-2 cut next week
18:44:21 <SlickNik> Release schedule is here:
18:44:23 <SlickNik> #link https://wiki.openstack.org/wiki/Juno_Release_Schedule
18:44:43 <SlickNik> And trove work items that are currently assigned to juno-2
18:44:45 <SlickNik> #link https://launchpad.net/trove/+milestone/juno-2
18:45:01 <amrith> ha, what?
18:45:21 <SlickNik> So a couple of things around this.
18:45:25 <cp16net> OH MAN
18:45:25 <amrith> was there a change?
18:45:27 <cp16net> already?
18:45:31 <amrith> it was 24th
18:45:37 <amrith> all along, I thought?
18:46:14 <SlickNik> next week is the week of the 24th
18:46:28 <amrith> yes
18:46:34 <amrith> that's what I thought
18:46:51 <SlickNik> So there's no change here.
18:47:22 <amrith> ok. figured out the confusion. "openstack changed the topic to: Juno-2 cut next week" which I read to mean that the schedule has changed
18:47:25 <amrith> no the topic changed
18:47:26 <amrith> that's all
18:47:32 <amrith> I need glasses
18:47:38 <vipul> the capabilities BP.. shoudl that be High for Juno-2?
18:48:17 <dougshelley66> vipul: seems like capabilities ended up in a black hole
18:48:25 <SlickNik> vipul, nope. I'm going to tidy up the work item list today to ensure we have a good predictor of what will make it in Juno-2.
18:48:34 <vipul> we probalby should retarget
18:48:36 <vipul> ok thanks SlickNik
18:48:42 <dougshelley66> vipul: understood
18:49:08 <SlickNik> If something's in progress, and won't make it for the cut - please ping me and let me know.
18:49:30 <vipul> so SlickNik does code need to be merged for us to meet these ?
18:49:40 <SlickNik> I'll ping folks on the channel once we have a proposed milestone.
18:50:01 <SlickNik> Yes, we need to concentrate on reviews and getting what's targeted for Juno-2 merged.
18:50:14 <vipul> roger
18:50:55 <SlickNik> ^ cp16net / grapex / hub_cap / amcrn
18:51:02 <amcrn> aye aye captain.
18:51:07 <cp16net> word
18:51:29 <grapex> SlickNik: Will do.
18:51:33 <SlickNik> That's all I had on juno-2
18:51:36 <SlickNik> Thanks guys.
18:51:42 <SlickNik> #topic Open Discussion
18:51:53 <amrith> got one (not bp related)
18:52:15 <SlickNik> amrith: floor is yours
18:52:17 <amrith> will wait to see if someone has bp related question
18:52:33 <amrith> in response to an earlier conversation
18:52:39 <amrith> with cp16net I entered https://bugs.launchpad.net/oslo/+bug/1342857
18:52:45 <uvirtbot> Launchpad bug 1342857 in oslo "Provide additional logging from execute()" [Undecided,New]
18:52:53 <amrith> it is a bug to push some code up to oslo, to enhance execute() logging
18:53:06 <amrith> there's currently some code for the trove execute_with_timeout() change
18:53:19 <amrith> should we do both?
18:53:28 <amrith> I'm not sure when the oslo code will filter back down
18:53:38 <amrith> so my q ...
18:53:49 <amrith> what's the eta on something getting pushed up to oslo coming back down to trove
18:53:52 <amrith> <end question>
18:53:58 <amcrn> needs to land in oslo, then we sync
18:54:13 <amcrn> on a patch i submitted, it took maybe a week or so
18:54:18 <amrith> ok, thanks
18:54:20 <amcrn> ymmv
18:54:29 <amrith> in that case I'll just schedule these sequentially
18:54:43 <amrith> once my stuff gets into oslo (if my stuff...) then I'll plan on the merge back
18:54:45 <amrith> thanks!
18:54:56 <SlickNik> amrith: That sounds like a good idea.
18:55:02 <SlickNik> amrith: Thanks for the follow up!
18:55:29 <amrith> I'll co-author oslo fix with the person who put the code into trove
18:56:33 <SlickNik> Did anyone have anything else for Open Discussion?
18:57:01 <SlickNik> .
18:57:06 <SlickNik> #endmeeting