18:00:09 <amrith> #startmeeting trove 18:00:10 <openstack> Meeting started Wed May 18 18:00:09 2016 UTC and is due to finish in 60 minutes. The chair is amrith. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:13 <peterstac> o/ 18:00:13 <openstack> The meeting name has been set to 'trove' 18:00:19 <amrith> ./ 18:00:30 <cp16net> howdy 18:00:31 <mvandijk> O/ 18:00:32 <dloi> o/ 18:00:34 <dougshelley66> o/ 18:00:39 <amrith> 'owdy cp16net 18:01:11 <tellesnobrega> o/ 18:02:01 <amrith> let's give people 1 minute to trickle in 18:02:51 <amrith> ok, let's get started 18:02:57 <pmalik> ./ 18:03:03 <amrith> #topic Action items from last week's meeting 18:03:17 <amrith> there are none ... we finished them off last week (during the meeting) 18:03:28 <amrith> #topic Trove pulse update 18:03:38 <amrith> #link http://bit.ly/1VQyg00 18:03:47 <amrith> #link https://gist.github.com/amrith/abab5d5553864b1562d7c99ab88351fc 18:04:14 <amrith> Good progress on the reviews this past week 18:04:26 <amrith> the number of open reviews (backlog) reduced slightly 18:04:35 <SlickNik> o/ 18:04:47 <amrith> hi SlickNik 18:04:52 <dougshelley66> seems like a good trend 18:05:06 <amrith> yes, it was a move in the right direction, i think. 18:05:38 <amrith> I know that there were several changes I wanted merged in stable/mitaka that got merged 18:05:47 <vgnbkr> o/ 18:05:51 <amrith> and that contributed (positively) to the reduction in #open reviews 18:05:57 <amrith> hi vgnbkr 18:06:15 <amrith> anyone have other things to add on this subject? 18:06:28 <vkmc> o/ 18:07:29 <amrith> . 18:07:54 <amrith> let's try and keep the momentum going this week 18:08:02 <amrith> there are still a good number of open reviews 18:08:11 <amrith> and a fair number in need of review at this point 18:08:22 <amrith> #topic Announcements 18:08:35 <amrith> I didn't have any, wasn't sure if others had anything that they'd like to add 18:09:25 <amrith> hearing nonw 18:09:27 <amrith> none 18:09:28 <pmackinn> amrith, any updates on newton mid-cycle plan? 18:09:41 <amrith> pmackinn, haven't got any 18:09:45 <pmackinn> k 18:09:49 <amrith> other than the time and place 18:10:07 <amrith> I've seen other projects put out google-docs or other sign up mechanisms 18:10:11 <amrith> for their mid-cycles in July 18:10:16 <amrith> so I figured I have abotu a month :) 18:10:38 <amrith> I'll get more details in the next couple of weeks. 18:10:48 <amrith> #topic Specs that are up for review 18:10:59 <amrith> So, there are a couple on the agenda today 18:11:05 <amrith> I see 3 18:11:19 <amrith> so in the interest of time, I'm going to suggest that we try and spend about 15m each 18:11:26 <amrith> it is now 2:11, I'll keep time 18:11:31 <amrith> vkmc, you're up first 18:11:38 <amrith> with RPC API Versioning https://review.openstack.org/#/c/315079/ 18:11:40 <amrith> #topic RPC API Versioning https://review.openstack.org/#/c/315079/ 18:11:45 <amrith> all yours vkmc 18:11:54 <vkmc> thanks amrith 18:12:34 <vkmc> so the RPC API Versioning spec proposes adding independent versioning for Trove components 18:13:10 <vkmc> so operators can perform upgrades as they see fit without the need of taking all the services down 18:13:29 <vkmc> there were a few questions that I replied earlier today 18:13:35 <vkmc> is there any other question or comment? 18:13:43 <vkmc> do somebody want to talk about a specific question in particular? 18:14:09 <amrith> i do but I'll wait to see if others have anything to say first. 18:14:24 <pmackinn> vkmc, do we have a reference from other projects? 18:14:39 <vkmc> pmackinn, we do, this has been implemented already in many defcore projects 18:14:51 <vkmc> pmackinn, and AFAIK Sahara was moving towards that path as well 18:15:18 <johnma> So vkmc, there is a spec already out for instance upgrades. Does this overlap with that in any way? 18:15:57 <vkmc> johnma, not so much, the instance upgrades aims to cover guestagent/os/database upgrades 18:17:01 <amrith> but isn't a guestagent part of the versioning API that you propose here? 18:17:03 <vkmc> johnma, the rpc api versioning one aims to guarantee operators that they can perform upgrades for different components in trove with no downtime 18:17:54 <vkmc> amrith, yes, but you will upgrade to a new version of the guestagent using the method provided by the instance upgrades feature 18:18:25 <amrith> but how then does a guest agent know what version it should run at? 18:18:37 <dougshelley66> vkmc i'm still not clear how the taskmanager (for example) knows which version of the message to send to the guest 18:18:38 <amrith> how do you intend to communicate the pin to a guestagent? 18:18:52 <amrith> dougshelley66, ++ 18:19:05 <vkmc> amrith, in the configuration of the guestagent that would be 18:19:07 <pmackinn> could go into guest_info, no? 18:19:11 <amrith> which is why I think johnma's question is an interesting thing. 18:19:21 <vkmc> it is interesting indeed :) 18:19:34 <dougshelley66> so you have a new TM and a running (i.e. old) guest 18:19:45 <dougshelley66> some one runs say backup_create 18:19:53 <dougshelley66> which let's say has some new api in the new TM 18:20:03 <dougshelley66> how does the TM know that it can't send that new message to the old guest 18:20:35 <amrith> i.e discovery 18:20:50 <amrith> and that part of it isn't related to upgrade (of the guest) 18:21:09 <vkmc> so that would be a major upgrade... if it's a breaking change 18:21:18 <amrith> the question is in general, how does a participant know what version(s) another participant will understand. 18:22:03 <amrith> anyway, as a time check. it has been 10m. 18:22:05 <vkmc> if there is a breaking change we need to perform controls over the version to "translate" the message accordingly 18:22:12 <pmackinn> 1.0 == unknown version 18:22:23 <amrith> one of my concerns about this spec is that we describe a software mechanism but don't describe how it will be used. 18:22:30 <amrith> therefore it is hard to evaluate the specification. 18:22:43 <vkmc> fair enough, let me add details about this 18:22:45 <amrith> put differently, the specs says you will add versions to messages. taht's true 18:23:19 <vkmc> agree 18:23:21 <amrith> but without knowing how others will deal with the version, or react to it, or how operators will use it, or how it will be operationalized in an upgrade (rolling or otherwise) it is hard to provide any feedback. 18:23:26 <amrith> that was the intent of my meta comments. 18:23:35 <vkmc> yeah, that's true 18:23:45 <amrith> also pmackinn's point, about references, I'd provided a list of references that relate to this subject. 18:23:53 <vkmc> will add some examples of this in a new draft 18:23:59 <amrith> some are more detailed than this spec, others provide directions that are contrary to this spec. 18:24:18 <vkmc> which reference are you referring to? 18:24:19 <pmackinn> foiled again by the damn guestagent 18:24:26 <amrith> for example, your observation that when a requirement is bumped you do't need to bump version flies in the face of our observation with oslo.context. 18:24:33 <amrith> because that object is part of an rpc message. 18:24:52 <amrith> vkmc, please see my comment 18:24:52 <amrith> May 13 10:29 AM 18:25:09 <vkmc> checking it now 18:25:31 <vgnbkr> For any of this to work, implementing versioning for oslo_messaging is a necessary precondition. Why don't we just do that first, then move on from there? 18:25:47 <amrith> so, since we're about to timeout here, what are the action items? 18:25:55 <amrith> vgnbkr, would you add that comment to the review please. 18:26:05 <vgnbkr> OK. 18:26:11 <amrith> it is a very important thing that I guess I've alluded to but never articulated as succinctly 18:26:13 <amrith> thanks 18:26:35 <amrith> johnma, what action items or other comments do you have at this stage. 18:26:49 <amrith> anybody else ... please put comments in the spec 18:26:55 <amrith> or vkmc, should they wait for a new version? 18:27:08 <amrith> thx vgnbkr 18:27:16 <vkmc> please add all the questions/concerns in the current version and I'll address those 18:27:23 <amrith> thanks vkmc 18:27:25 <johnma> I will add my comments in the spec amrith 18:27:29 <vkmc> thanks amrith 18:27:37 <amrith> thanks johnma, before we move on, anything further to add from anyone 18:28:06 <amrith> ok, peterstac, you are up. [peterstac] Locality https://review.openstack.org/#/c/298994/ ... 15 minutes 18:28:12 <amrith> #topic [peterstac] Locality https://review.openstack.org/#/c/298994/ 18:28:28 <peterstac> I think I've addressed all the concerns on the spec online 18:28:47 <peterstac> Just wanted to know if there was anything else 18:28:48 <SlickNik> vkmc / amrith: FWIW this has come up before, but was incomplete. 18:29:09 <SlickNik> dan had some notes here: https://wiki.openstack.org/wiki/Trove-rpc-versioning 18:29:11 <vkmc> SlickNik, yeah I'm aware :) 18:29:16 <SlickNik> #link https://wiki.openstack.org/wiki/Trove-rpc-versioning 18:29:18 <vkmc> thanks for the link 18:29:41 <SlickNik> np — sorry peterstac — moving on. 18:29:48 <peterstac> SlickNik, np ;) 18:30:26 <amrith> peterstac, I haven't looked recently but did you change the command line argument to --hint? 18:30:47 <amrith> I hope it is still --locality 18:30:48 <peterstac> no, since it's only a hint when it gets sent to Nova 18:31:06 <tellesnobrega> peterstac, I just comment on the spec, looks fine by me 18:31:26 <peterstac> I saw that tellesnobrega, thx! 18:31:38 <tellesnobrega> i can't speak for flavio and he is probably going to review tomorrow or friday 18:31:51 <tellesnobrega> but seems like it is good to go 18:32:02 <amrith> peterstac, we may have talked about this already but so apologies. did you answer the question re: database change? 18:32:53 <amrith> I see the answer. thanks 18:32:58 <peterstac> I added it to the 'alternatives' section as an option 18:33:29 <peterstac> I still think that unless we see an obvious performance issue that we should let Nova track it, not us 18:33:42 <amrith> I will re-read and I think (based on my last reading) +2 18:34:16 <amrith> that's all I had, thanks peterstac 18:34:22 <peterstac> ok, thx 18:35:03 <amrith> i believe that you've addressed all the comments that flavio raised. pmackinn you had some questions at summit, right? 18:35:29 <pmackinn> amrith, uh i'm good 18:36:04 <amrith> anybody else ... 18:36:06 <SlickNik> peterstac: so the creation of the server group is internal and not dictated by the user of the feature (at least for now)? 18:36:13 <peterstac> right 18:36:20 <peterstac> we manage that all under-the-covers 18:36:31 <peterstac> (like secgroups) 18:37:00 <SlickNik> okay , cool 18:37:30 <amrith> #action [all] review https://review.openstack.org/#/c/298994/5 18:37:38 <amrith> peterstac, anything else you'd like to add 18:37:47 <peterstac> no, I think I'm good 18:37:55 <amrith> ok, anyone else ... 18:38:15 <amrith> #topic Persist Error Messages https://review.openstack.org/#/c/313780/ 18:38:20 <amrith> peterstac, you are up (15m) 18:38:30 <peterstac> This one has one remaining issue afaik - should we return/save a stack trace in the fault info 18:39:06 <peterstac> (There was another concern about security, but I think that belongs on the notification impl if it exists) 18:39:32 <peterstac> Right now we return a message and the stack trace 18:39:56 <peterstac> There's a concern that some OPs don't want end-users seeing stack traces (and I understand that) 18:39:58 <amrith> As a point of reference peterstac what does Nova do (WWND?) 18:39:58 <SlickNik> maybe, we could conditionally return the stack trace if the caller is an admin? 18:40:27 <peterstac> that's what I suggested on the spec, but it's recent so I haven't seen any feedback yet 18:40:34 <peterstac> would everyone be ok with that? 18:40:49 <amrith> I wouldn't, not until I know what the precedent is. 18:41:01 <SlickNik> not sure what nova does — I've seen stack traces before, but I'm not sure they're still doing it. 18:41:09 <amrith> they still do 18:41:16 <amrith> saw them last week, was very helpful 18:41:48 <amrith> (helped figure out that nova was out of quota, and what quota thing nova puked on) 18:41:50 <peterstac> I see them sometimes and sometimes not - maybe they're doing the same thing so that only admin sees stack traces? 18:42:04 <SlickNik> I suspect it might be only admin — would be good to find out for sure. 18:42:14 <peterstac> ah, amrith, with this feature Trove will show you that :D 18:42:40 <amrith> ok, so are we agreed that admin's will see a stack trace? if so, will the stack trace be sanitized with mask_password() 18:42:56 <SlickNik> peterstac: ++ have had to take a look at the logs too many times to only find that. 18:43:50 <SlickNik> amrith: I think it's probably a good idea 18:44:10 <peterstac> amrith, that was my point - since I'm persisting the notification messages, if there's a prob we should fix it there 18:44:43 <amrith> ok so let me say it this way 18:44:48 <peterstac> (i.e. out of scope of this spec) 18:44:55 <amrith> #agreed that we will persist stack traces and only show them to admins 18:45:07 <peterstac> ok, done 18:45:10 <amrith> #agreed that we will sanitize the stack traces and error messages that we persist using mask_password 18:45:24 <SlickNik> ++ 18:45:27 <amrith> anything further on these? 18:45:33 <peterstac> what about notifications, then? 18:46:19 <amrith> I would do the same thing 18:46:28 <amrith> unless you feel that it will make the notifications less useful 18:46:37 <amrith> I don't think it will 18:46:58 <amrith> didn't the notifications change merge or am I thinking of something else? 18:47:36 <peterstac> yes it merged 18:47:40 <peterstac> #link https://review.openstack.org/#/c/227870/ 18:48:24 <amrith> so what was the question :) 18:48:45 <peterstac> But there would only be a problem with a password, etc. if someone printed it out in a log message 18:48:56 <peterstac> (hopefully we'd catch that in review) 18:49:01 <amrith> mask_password() tries to catch those 18:49:13 <amrith> but it is a best effort ... 18:49:27 <peterstac> a stack trace shouldn't ever have anything sensitive ... 18:49:39 <amrith> famous last words. 18:49:51 <vgnbkr> If anyone printed a password in a LOG/exception message, the review would have caught it, right? 18:50:06 <amrith> s/would/should/ 18:50:22 <amrith> anything else to add on this spec? 18:50:44 <amrith> peterstac, before we move on, anything else to add? 18:51:18 <amrith> johnma, vkmc, cp16net, SlickNik, you ok with this (modulo anything else you find as you review) 18:51:27 <amrith> same question for the previous specs as well 18:51:46 <peterstac> nope, I'll push up another patchset shortly 18:51:47 <peterstac> thx! 18:51:52 <cp16net> i like the idea of the error message like nova :) 18:52:16 <amrith> sounds good. thanks peterstac 18:52:24 <amrith> #topic Open Discussion 18:52:36 <amrith> I had a quick one ... 18:52:47 <amrith> I will be cutting a new trove release 18:52:53 <amrith> so far I've tagged the server and the client 18:52:57 <amrith> I need to also tag the dashboard 18:53:09 <amrith> this is somewhat urgent for mitaka 18:53:15 <amrith> since keystoneclient released 3.0.0 18:53:22 <amrith> and that causes some grief for mitaka 18:53:36 <amrith> #link https://review.openstack.org/#/c/318191/1 18:53:43 <amrith> if anyone wants to see what I'm talking about 18:54:01 <amrith> that's all I had 18:54:10 <amrith> anyone else have anything for Open Discussion 18:54:14 <SlickNik> amrith / peterstac: good with the error messages (comment from above) 18:54:22 <amrith> thx SlickNik 18:55:20 <amrith> hearing none ... 18:55:39 <amrith> ... #endmeeting? 18:56:05 <amrith> #endmeeting