18:00:31 <SlickNik> #startmeeting trove
18:00:32 <openstack> Meeting started Wed Nov 19 18:00:31 2014 UTC and is due to finish in 60 minutes.  The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:36 <openstack> The meeting name has been set to 'trove'
18:00:52 <SlickNik> Giving folks a few minutes to trickle in
18:00:54 <sgotliv> o/
18:01:19 <peterstac> o/
18:01:21 <amrith> ./
18:01:58 <SlickNik> Agenda at:
18:02:01 <SlickNik> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting#Meeting_Nov_19th
18:02:32 <grapex> o/
18:03:19 <SlickNik> #topic oslo-incubator changes
18:04:02 <amrith> hello all
18:04:03 <SlickNik> amrith: floor is yours
18:04:07 <dougshelley66> o/
18:04:08 <amrith> I'd like some reviews of these changes
18:04:24 <schang> o/
18:04:27 <amrith> thanks to sergey, peterstac, mariam, denis, duk, doug so far
18:04:29 <sgotliv> I will review it later today
18:04:31 <amrith> but would like some others
18:04:44 <amrith> the changes are now relatively small
18:04:56 <amrith> the hard work is in the oslo merge (to come)
18:05:11 <amrith> so depending on peoples thoughts, I'd like to get it staged to merge at the time when we think it should
18:05:36 <amrith> SlickNik, i'm done
18:06:08 <SlickNik> Thanks amrith — sounds good. Will take a look as well.
18:06:50 <SlickNik> #topic Better documentation for Image building
18:06:51 <sgotliv> SlickNik, please, take a look on messaging patch as well
18:07:22 <amrith> SlickNik, I thought I picked up the action item in Paris.
18:07:22 <SlickNik> sgotliv: Yes, it's on my list as well.
18:07:27 <amrith> are you looking to change it
18:07:28 <sgotliv> thanks!
18:07:42 <SlickNik> amrith: no, just looking for a follow up
18:07:59 <SlickNik> And what the action item actually entails.
18:08:08 <amrith> I haven't worked on it since Paris. I will brush it up and have it in the monday meeting in two weeks for review. does that work?
18:08:23 <amrith> the action item currently entails telling basically how to run dib
18:08:26 <SlickNik> i.e is this going in the dev docs or in the installation manual?
18:08:29 <amrith> and documenting the elements we already have
18:08:53 <amrith> it should also provide a simple cookbook on how to make a new one if someone wanted to.
18:09:31 <amrith> I would expect that it goes in dev docs, not installation manual
18:09:55 <SlickNik> Do we need another section that's part of the official install guide?
18:10:09 <amrith> the question is this, do we expect end users to create their own images?
18:10:29 <amrith> I was assuming not
18:10:36 <sgotliv> why not?
18:10:36 <georgelorch> o/
18:10:52 <SlickNik> the current install guide says this:
18:11:06 <SlickNik> "Create an image for the type of database you want to use, for example, MySQL, MongoDB, Cassandra.
18:11:07 <SlickNik> This image must have the trove guest agent installed, and it must have the trove-guestagent.conf file configured to connect to your OpenStack environment. To correctly configure the trove-guestagent.conf file, follow these steps on the guest instance you are using to build your image: …"
18:11:13 <SlickNik> #link http://docs.openstack.org/juno/install-guide/install/apt/content/trove-install.html
18:12:00 <amrith> ok, let me look at that and get back to you with a better estimate next week.
18:12:02 <amrith> would that work?
18:12:37 <amrith> I was expecting this to be more of an operators thing
18:12:41 <amrith> rather than an end user of trove
18:12:57 <amrith> I was expecting that an IT org or a csp would make the images and make them available
18:13:03 <amrith> and that the end user would pick one.
18:13:09 <amrith> not that the end users would be making their own
18:13:18 <SlickNik> amrith: is anyone collaborating with you on this?
18:13:21 <amrith> I guess that's a matter of defining who the "user is".
18:13:29 <sgotliv> today end user uploads images to Glance
18:13:31 <amrith> I was working with abramley on this a while ago.
18:13:41 <amrith> more recently, I haven't done anything on it.
18:14:13 <amrith> I was also working with laurel on this
18:14:17 <amrith> from the doc perspective
18:14:19 <amrith> a while ago
18:15:19 <SlickNik> amrith: It is for operators, but the Install guide is also for operators — not just developers.
18:17:32 <SlickNik> But sounds good. Let's chat after the meeting to see what we can do to make this happen soon (both for the dev docs and install guide — the instructions likely won't be the same).
18:17:37 <amrith> ok
18:17:44 <SlickNik> Thanks!
18:18:36 <SlickNik> #topic Trove Mid Cycle Sprint in Seattle, WA
18:18:47 <amrith> SlickNik, I have a request
18:18:51 <amrith> re: mid-cycle
18:19:09 <SlickNik> amrith: yes?
18:19:19 <amrith> Thx, there appear to be no late night flights to the east coast.
18:19:30 <amrith> therefore a W-F schedule means we can't leave till saturday
18:19:39 <amrith> would it be possible to do Tu-Th?
18:19:41 <amrith> instead.
18:19:54 <amrith> last flight (direct) to Boston is 2pm (as an example)
18:21:10 <amrith> <eof>
18:21:13 <SlickNik> How do other folks feel about a Tu-Th instead of a Wed-Fri meetup?
18:21:20 <dougshelley66> +1
18:21:20 <SlickNik> Well, let's back up a bit.
18:21:29 <amrith> or monday to wednesday
18:21:39 <amrith> I'd be happy with a late Sunday flight to seattle.
18:22:01 <SlickNik> It looks like the mid-cycle will be in February
18:22:15 <SlickNik> I've set up a doodle poll to decide which week in Feb
18:22:18 <esmute> there is always the redeye flights
18:22:33 <amrith> esmute, I don't see redeye to boston.
18:22:47 <amrith> last flight is 2:07pm, JB.
18:22:50 <SlickNik> #link http://doodle.com/veabvxtc84czm9ep
18:23:09 <dougshelley66> so is the doodle about picking a week or picking specific days in a week
18:24:06 <SlickNik> It's about picking the week — I wasn't able to get doodle an option to show a week in the poll instead of days.
18:24:09 <SlickNik> We can revisit the specific days once we have the week sorted out
18:24:14 <dougshelley66> ah ok thx
18:24:59 <SlickNik> I had thought of Wed-Fri initially, but I'm open to Mon-Wed or Tue-Thu if folks prefer that.
18:25:00 <amrith> Nikhil, don't use a calendar event, use a free-text event for week choices.
18:25:24 <amrith> you can make doodle a poll for anything, right now I have another doodle event to choose a restaurant (options are free text).
18:25:41 <esmute> amrith: you would think boston is a big enough of a city to have more directly flights..
18:25:53 <amrith> esmute, we're a small place
18:25:59 <amrith> but wait till we get the next olympics
18:26:04 <amrith> we'll even have an airport.
18:27:27 <esmute> The think about not ending in a friday is how productive i'll be during the weekday... i might be brain exhausted or drunk :P
18:28:02 <amrith> and as exhibit (a), here we have esmute on a wednesday ;)
18:28:04 <SlickNik> #link http://doodle.com/ahrvmneuddzi92kn
18:28:17 <cp16net> esmute: isnt that every day?
18:28:19 <cp16net> :-P
18:28:20 <SlickNik> ^^ Use this poll instead — to clear up some confusion
18:28:33 <SlickNik> Will update the link in the page.
18:29:07 <esmute> cp16net: lol
18:29:11 <cp16net> :-D
18:30:21 <SlickNik> Okay, would be good if folks could take a minute today to fill out that poll, so I can have a better idea of the week for the Mid-cycle.
18:31:35 <SlickNik> Let me also check with a few folks who would help with organizing this on whether Mon-Wed, or Tue-Thur would be a better option.
18:31:49 <SlickNik> #action SlickNik to follow up on dates for Mid-cycle
18:32:00 <SlickNik> Will get back to folks after I check on that.
18:32:08 <SlickNik> Any other questions relating to this?
18:33:23 <SlickNik> Okay, let's move on then
18:33:28 <SlickNik> #topic Trove Cross Project Liasons
18:33:58 <SlickNik> So this (Cross Project Liasons) is something that teams across openstack are trying.
18:34:21 <SlickNik> Basically for Cross-Project issues, the idea is that the team would have a go-to point of contact.
18:34:37 <SlickNik> You've probably already seen some discussion around this on the Mailing List
18:34:55 <SlickNik> #link https://wiki.openstack.org/wiki/CrossProjectLiaisons
18:35:45 <SlickNik> The wiki page identifies the current cross-project groups for which teams are designating liasons.
18:35:59 <amrith> SlickNik, do you want us to just go and edit the page (to signify volunteering)?
18:36:05 <peterstac> From the page: The liaison should be a core reviewer for the project, but does not need to be the PTL
18:36:33 <SlickNik> peterstac: The liason does not _need_ to be a core reviewer.
18:37:44 <SlickNik> The only requirement afaik is:
18:37:44 <SlickNik> 1. she be passionate about the cross-project area
18:37:45 <SlickNik> 2. she be available for a cross project meeting (IRC) during which the particular topics might be brought up.
18:38:10 <SlickNik> Depending on the team they might have a few other responsibilities
18:38:47 <SlickNik> like triaging security issues for the vulnerability mgmt one, and getting involved in releases for rel mgmt.
18:39:00 <SlickNik> Also there can be more than one person as the liason.
18:39:35 <SlickNik> amrith: Updating the wiki page as you volunteer sounds good
18:41:32 <SlickNik> Any questions around this?
18:41:56 * SlickNik goes off to look at the webpage to see if we have volunteers.
18:42:35 <peterstac> better hurry, spots are filling up fast ;)
18:42:42 <peterstac> only Stable Branch, Vulnerability management, API Working Group left ...
18:43:40 <SlickNik> peterstac: There can be more than one
18:45:03 <SlickNik> Okay, I'll let folks fill that in at their convenience.
18:45:11 <SlickNik> Any other questions regarding this?
18:46:02 <SlickNik> Feel free to chat with me if you're interested in one of these roles, but are not sure what it might entail.
18:46:19 <SlickNik> #topic Open Discussion
18:46:43 <amrith> I have one ...
18:46:47 <amrith> but I'll wait
18:46:50 <amrith> and go last
18:47:54 <cp16net> i think you should fill this silence.
18:47:57 <SlickNik> I'm not sure I see any other topics, so go for it.
18:48:08 <amrith> This was about the issue of datastore and flavors
18:48:09 <amrith> https://review.openstack.org/#/c/109824/
18:48:24 <amrith> I saw a mention that riddhi was going to talk about it at next trove meeting.
18:48:27 <amrith> I assume that is now
18:48:33 <amrith> so if it is, I'd like to discuss that.
18:49:18 <amrith> anyone?
18:49:19 <Riddhi> amrith: sgoltiv wanted to chat about it
18:49:31 <Riddhi> i think its night time for him though
18:49:37 <amrith> he was here earlier, and I saw the comment in the review
18:49:50 <amrith> hence I bring it up
18:49:56 <amrith> there was some urgency about this on monday
18:50:11 <amrith> and therefore I'd like to make sure it doesn't linger
18:50:20 <amrith> there appear to be two issues
18:50:28 <amrith> 1. whether the api is Restful
18:50:36 <Riddhi> yeah..he pinged me after that comment..we would discuss about it tomorrow and i will update the patch with the details of what we discussed
18:50:39 <amrith> 2. whether it can be changed given that what was implemented was what was in the spec
18:50:48 <amrith> so the question is this
18:50:58 <amrith> if you come to the conclusion that (1) it isn't restful
18:51:08 <amrith> can it be changed.
18:51:22 <Riddhi> yes..i wanted more feedback on this
18:51:22 <amrith> My understanding from Monday was that the BP would be RST'ed and then we would review it
18:51:24 <amrith> is that correct?
18:51:33 <amrith> this is mostly a question to grapex and SlickNik
18:51:41 <amrith> did I understand monday's meeting correctly?
18:51:46 <SlickNik> amrith: There was an RST'd BP that already merged.
18:51:49 <Riddhi> yeah..the rst has been approved and is now in trove -specs
18:51:58 <grapex> amrith: I figured the big stuff had already been discussed
18:51:59 <SlickNik> amrith: Not sure if you saw it
18:52:07 <amrith> SlickNik, that went by so quick
18:52:10 <grapex> But if people had more questions we can still talk about it
18:52:19 <amrith> I was assuming that review meant it would be around for a bit
18:52:22 <amrith> I guess I was wrong
18:52:30 <grapex> amrith: Well there's still a review for the code, but the Spec BP was approved
18:52:36 <amrith> also, the process re: bp's was (I thought) that the BP would be +2'ed when the code +2'ed
18:52:37 <grapex> which makes sense as it was already in the wiki for a long time
18:52:42 <amrith> I have a bunch of BP's otu there.
18:52:46 <amrith> they were discussed
18:52:48 <amrith> they haven't merged.
18:52:52 <Riddhi> the stuff sgotliv wanted to discuss was if /{tenant_id}/flavors/datastores/versions/{datastore_version_id} is a valid REST api
18:53:16 <SlickNik> The BP is +2'ed when the design is agreed upon, not when the code merges.å
18:53:26 <amrith> could I get some reviews (like +2's) on my bp's
18:53:31 <Riddhi> grapex: https://blueprints.launchpad.net/trove/+spec/associate-flavors-datastores
18:53:32 <amrith> have we agreed to the 'design'
18:53:41 <amrith> on how to handle obsolete oslo modules?
18:53:44 <grapex> SlickNik: That was my view as well
18:53:55 <grapex> amrith: Sorry, I'll try to look over more of your blueprints
18:54:22 <SlickNik> amrith: Does that need to be a BP? It seems more of a housekeeping task to me. We're not really adding new functionality
18:54:30 <SlickNik> I thought we decided to use a bug instead?
18:54:59 <amrith> SlickNik, not that I know of. we reviewed the BP's at a monday meeting. I could go and check but I don't know about the decision to use a bug.
18:55:09 <amrith> I'm happy to do that. just let me know which tree to go bark up.
18:55:56 <grapex> So- does anyone know what sgoltiv's question was?
18:56:11 <amrith> yes, he had objections to the end points.
18:56:23 <amrith> he (and I agree with this) feels that the URL's should not be as in the spec
18:56:33 <amrith> let me find his exact words, one second
18:56:42 <SlickNik> amrith: IIRC I'm pretty sure other projects are using bugs, so I'd prefer doing the same.
18:56:43 <Riddhi> his question was : /{tenant_id}/flavors/datastores/versions/{datastore_version_id}
18:56:51 <Riddhi> the above url is not RESTful
18:57:05 <Riddhi> his suggestions were:
18:57:06 <Riddhi> 1. How about sending datastore_version_id as a query parameter
18:57:12 <Riddhi> OR
18:57:19 <Riddhi> 2. /{tenant_id}/datastores/{datastore}/versions/{id}/flavors which is even better.
18:57:41 <amrith> SlickNik, ok, I'll kill the BP's.
18:58:20 <SlickNik> Looks like the BP mentions the bug in it as well
18:58:37 <SlickNik> #link https://bugs.launchpad.net/trove/+bug/1380789
18:58:40 <uvirtbot> Launchpad bug 1380789 in trove "Do not use obsolete modules from oslo-incubator " [Undecided,In progress]
18:58:57 <grapex> I'll admit, sgoltiv's option #2 seems better to me
18:59:00 <amrith> done, BP is history.
18:59:20 <grapex> But at this point I think we have devs implementing stuff based on what they think is community consensus only to find they were obeying an echo whose author has been forgotten. :p
18:59:57 <amrith> yes, but this was (I thought) the reason why we thought we'd review it again on Monday.
19:00:14 <grapex> Actually, scratch that
19:00:38 <grapex> I think the query param is better- that was #1 right- I'm saying I'm ok with some change
19:00:47 <grapex> but this has been discussed since this summer
19:01:07 <SlickNik> amrith: IIRC the reason we wanted the RST is to track the BPs in kilo
19:01:12 <grapex> So there isn't any urgency, I'd just like everyone to settle on these last questions since we've long since decided we're ok with the idea
19:01:29 <SlickNik> I.e. so that we're not merging a BP in kilo without a corresponding spec
19:02:33 <grapex> I've got another question- is the blueprint meeting to be used to announce new specs that are now pull requests in Gerrit, and to give a deadline to approve or deny specs from the past week?
19:02:48 <grapex> As in, are we saying we want to wait a week to approve specs?
19:03:02 <amrith> SlickNik, grapex ... there was much discussion about this spec on monday and I know that I said "#idea ... take existing BP and make it an RST and let people comment on it"
19:03:11 <amrith> that was certainly my intent.
19:03:22 <amrith> I know that sgotliv and others had already expressed concerns on the change
19:03:29 <amrith> in areas that reflected on the spec/bp.
19:04:02 <amrith> anyway, let's decide what we want to do procedurally with BP's.
19:04:19 <amrith> to grapex question, above, what's the process?
19:04:27 <Riddhi> i agree with grapex: although there is no urgency, we can atleast be on the same page about the implementation..this is the last nitpik with respect to the feature..i still do not see how one REST url is better than the other..
19:04:44 <SlickNik> The design for a BP is accepted when the spec merges
19:04:53 <SlickNik> which can happen independent of the BP meeting.
19:05:29 <SlickNik> So the BP meeting is to have a discussion around new specs and iron out any controversial issues that may arise.
19:05:47 <SlickNik> We're not making any "approve" or "deny" requests as part of that meeting.
19:05:58 <SlickNik> That happens offline as part of merging the spec in gerrit
19:06:18 <grapex> SlickNik: Cool
19:06:20 <amrith> so, a new BP/spec doesn't need to come to the monday meeting.
19:06:28 <amrith> only if there is a reason to discuss.
19:06:29 <amrith> yes?
19:06:34 <SlickNik> Yes
19:06:36 <Riddhi> SlickNik: got it:)
19:06:49 <grapex> I also think we should get better about having features go on for months because of minor nitpicks in details such as REST paths
19:07:22 <amrith> ok, what do we do about this spec?
19:07:24 <amrith> it is now merged.
19:07:28 <grapex> I get that it can be ugly, but its like if someone's code could be improved in a pull request- make a comment and then hopefully it can be decided in a week or so
19:07:50 <grapex> amrith: I think we just move on revieiwng Riddhi's implementation
19:08:41 <grapex> If I'm correct, the only blocker is sgoltiv's opinion on what the service.py stuff needs to look like
19:08:52 <SlickNik> amrith: There's nothing in the spec which prevents us from altering the implementation to change the API endpoint to be more RESTful, so why is this even an issue?
19:08:53 <amrith> at this point, yes
19:08:59 <SlickNik> spec is at https://review.openstack.org/#/c/135128/3/specs/kilo/associate-flavors-datastores.rst,cm
19:09:32 <amrith> SlickNik, the reason I brought it up is that it was discussed in the review that we could discuss in the trove meeting.
19:09:47 <amrith> and I didn't want this to linger for too long
19:09:59 <amrith> since there was a mention of discussing in the "next trove meeting" I brought it up.
19:10:10 <Riddhi> SlickNik: yeah, i will discuss this with sgotliv and keep you all in the loop about it
19:10:14 <grapex> amrith: Sorry. I was really moving us for to close to some kind of agreement on Monday's meeting until SlickNik pointed out he needed the spec for Kilo book keeping, and I was like "drat! Defeated!"
19:10:28 <grapex> amrith: I still want to push us to come to consenus on this
19:10:40 <grapex> I think Riddhi should email sgoltiv, CC the cores and will figure out what this last nitpick is
19:11:00 <amrith> grapex, I would too, hence I brought this up.
19:11:33 <grapex> amrith: I think we agree then.
19:11:39 <grapex> I vote we give this topic a REST!
19:11:40 * grapex rimshot
19:11:44 <SlickNik> So the only remaining item is with the last comment on the code review (the actual REST endpoint). The spec isn't an issue here.
19:11:48 <SlickNik> grapex: +1
19:11:56 <Riddhi> grapex: yes..! although I do not clearly right now get the significance of the URL being RESTful or not.. will implement based on the discussion..so the end:)
19:12:08 <SlickNik> Riddhi: Thanks.
19:12:39 <SlickNik> Please follow up with sgotliv.
19:12:56 <grapex> You know what? I don't care if an API is RESTful. There, I said it.
19:12:56 <Riddhi> SlickNik: yup..will do:) will keep you all in the loop
19:13:01 * grapex waits to hear the audience's gasp
19:13:11 <SlickNik> And on that note. :)
19:13:14 <SlickNik> #endmeeting