18:00:08 #startmeeting trove 18:00:08 Meeting started Wed Nov 9 18:00:08 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:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:12 The meeting name has been set to 'trove' 18:00:18 #agenda https://wiki.openstack.org/wiki/Meetings/TroveMeeting#Topics_for_Discussion 18:00:27 o/ 18:00:32 ./ 18:00:35 o/ 18:00:40 o/ 18:00:47 o/ 18:00:48 o/ 18:00:57 o/ 18:01:15 let's give folks a couple of minutes to come in 18:01:37 #topic Review status 18:01:45 #link https://docs.google.com/spreadsheets/d/1vJxNaoR3VVNS1Cpiz7U--1zyJRZ6ybMxzJoayrjdduo/edit?usp=sharing 18:02:25 a slight up-tick in reviews but we still have a number of outstanding changes. 18:02:32 ./ 18:02:37 o/ 18:02:41 I'm not so concerned about the new patches count; I know there were a lot of DNM's this past week 18:02:47 I had almost a dozen myself 18:03:09 o/ 18:03:20 and a couple of others had these as well. so I'm not so concerned about the third graph. Still insufficient reviews to keep up with the pace of patches that we have, however. 18:03:38 We did have some issues during the week. such as the busted gate. and that may have contributed to some of this 18:03:49 but now that the gate is fixed. I hope we can start to pick up the momentum 18:04:33 Next week will be the Ocata-1 milestone 18:04:35 #link https://releases.openstack.org/ocata/schedule.html 18:04:39 That is week R-14. 18:04:39 +1 hope we pick up review velocity now that the hate is fixed. 18:04:53 And the week after that (R-13, Nov 21-25) is the deadline for trove specs 18:04:54 s/hate/gate 18:05:12 so let's start looking at specs as a priority in the coming week. 18:05:22 thx SlickNik; yes. must do that 18:06:01 any other thoughts ... 18:07:35 #topic Merge these changes as a priority 18:08:13 so in the agenda there is a list of (7) reviews that are still awaiting reviews and merge. 18:08:24 now that the gate is fixed, let's take a minute to go over them 18:08:40 with respect to #7 there are some questions in the review about whether the approach is appropriate or not. 18:09:18 In addition, here is a list of specs that should be reviewed; 388100 18:09:18 , 391871 18:09:18 , 392990, 18:09:19 392991, 18:09:19 392989, and 18:09:19 389760 18:10:05 trevormc submitted 391871 Spec for openstack client support 18:10:30 pmalik_, has three Implement couchbase cluster provisioning 18:10:30 , Datastore-specific API controllers 18:10:30 , and Add support for Oslo Policies to Trove 18:10:41 mvandijk proposed Security group improvements 18:10:49 thats a WIP 18:10:55 oh, ok 18:11:02 not for now mvandijk ? 18:11:03 as in, I want feedback 18:11:16 but I don't expect it to merge any time soon 18:11:26 so, for ocata? 18:11:51 no push it back 18:11:56 OK, done 18:12:05 so, the ones I said minus mvandijk :) 18:12:22 they've been starred and show up on the dashboard. 18:12:30 please take some time to review these and post comments 18:12:53 again, please remember that without timely reviews we'll all get stuck with a crunch at the end. 18:13:12 any question, comments, suggestions? 18:13:55 #topic Abandon old reviews 18:14:07 let me pass the baton over to SlickNik who took this action item last week. 18:14:10 SlickNik, ... 18:14:32 So — last week I put a message in the reviews we were considering for abandonment. 18:14:51 "Hello there! This patch has been stagnant for a while, and has been identified as a candidate for abandonment. It was discussed at the weekly Trove meeting on 11/2 during a review clean-up. If there is no update to this patch (even a comment with some thing like "This is still work in progress" counts as an update) this patch will likely be abandoned during the next Trove meeting on 11/9. As the patch author, you will still 18:15:08 very friendly! 18:15:37 he's from washington 18:16:07 if he was from NY, it'd have been "hey bozo, this one's been dead for a while, clean it up or I'm going to flush it" 18:16:07 :) 18:16:17 I got a couple of replies. After the meeting, I plan to go ahead and abandon all of the reviews that don't have a reply or the reviewer hasn't reached out to me in some way. 18:16:27 +1 18:17:14 Sounds good. 18:17:25 anything further on these reviews ... anybody ... 18:18:30 #action SlickNik to abandon reviews that we were considering for abandonment that still don't have updates 18:18:39 thanks SlickNik 18:18:48 and hearing no further comments 18:18:51 #topic Open Discussion 18:19:46 Hi all, both please see that https://review.openstack.org/#/c/391732/, Morgan say that need a spec, for this comment is right? If we need I should hurry up maybe... 18:20:26 songjian, I think the issue is whether we really need a trove flavor-list command. 18:20:45 and rather than adding one column at a time, figure out what exactly the value of a trove flavor-list command is 18:20:53 and provide the information that people would like to see in that output. 18:21:13 and if we have flavor-list, should we have flavor-add? -delete? -update? 18:21:25 at least, that's what I took vgnbkr's comment to mean 18:21:27 right - with the upcoming switch to support for trove in the openstack client, it might make sense to drop it altogether 18:21:31 and that makes sense. 18:21:39 trevormc ^^ 18:21:51 yeah that's the approach my spec is taking now 18:22:14 does anyone know of other projects than nova that have a flavor-list command? 18:22:47 Does any project other than Sahara create instances? 18:23:04 yes, several have service vm's. octavia, manila. 18:23:13 but I was also thinking of things like the container projects 18:23:23 that have a need to define flavors (maybe)? 18:24:13 Not that I know of. 18:24:42 quick scan says no one else has such a command 18:24:59 neutron flavor-list 18:25:00 so maybe just leave the existing command as is, make no more changes, and not have one in the openstack command? 18:25:11 good point, did not think to look at neutron 18:25:34 but hasn't neutron moved to openstack cli 18:25:53 yes they deprecated their cli 18:25:59 well 18:26:00 at least the patch is in review right now 18:26:17 ok, what does netron flavor-list do? 18:26:42 i haven't used it but the description says "List Neutron service flavors" 18:26:46 #link https://wiki.openstack.org/wiki/Neutron/FlavorFramework 18:26:59 so this is something different; it isn't compute flavors, the way we regard them. 18:27:13 right... my mistake :( 18:27:27 what say johnma SlickNik peterstac 18:27:29 Plus, that's more like our association of flavours to datastores. 18:28:09 My understanding is that the original purpose of trove flavours was to know out fields - at the point we put almost all of them back in, what's the point? 18:28:18 s/know/knock/ 18:28:34 I don't see the need to keep enhancing the command at this point ... 18:29:00 Well, so the original reason flavor list was necessary was dependent on the model of trove deployment. 18:29:04 OK, is there any interest in a notion of a Trove flavor scheme that is a layer of indirection to nova's flavors? 18:29:47 SlickNik, I'm not sure what you just said. 18:30:07 If you deployed Trove on a completely different Nova environment that was blocked off, and users couldn't get to — you needed to expose the flavors somehow through the Trove API. 18:30:22 velly good point 18:30:52 and if I took that idea further, with a private cinder, some cinder commands too. 18:31:03 and swift, ... 18:31:11 etc., 18:31:20 What does "blocked off" mean? 18:31:29 vgnbkr, this is the privte nova 18:31:30 for trove 18:31:44 like an independent nova; not the compute endpoint from the keystone service catalog 18:31:47 vgnbkr: No API access to Nova. 18:31:48 but one that is private to trove 18:31:57 so you can't run nova list and see your nova instances 18:32:04 see your trove instances 18:32:27 How would the user not have access to Nova? Is this the single tenant thing? 18:32:28 one of the many "prevent users from taking emergency snapshot of vm ..." 18:32:42 the endpoint would be on a walled off network 18:32:46 the trove controller could get to it 18:32:53 but the human requesting things of trove cannot 18:34:38 So you would have a completely different set of compute nodes for Trove instances? 18:35:58 yes 18:36:24 Wow. $$$$ 18:36:29 vgnbkr: different from what? If you had a different exposed Nova for your cloud, yes — you could potentially configure it to have a different set of flavors from the ones that trove exposes. 18:37:02 Different from the set of compute nodes that would host the web servers that access the database, for example. 18:37:14 and I believe that SlickNik is intimately familiar with a cloud that used to deploy in this way 18:38:50 Yeah, both the RAX and HPE public DBaaS services used to be deployed this way. 18:40:54 ok, so back to the question ... sounds like having flavor-list makes sense for these users. now the question is this, what columns should we show? 18:42:47 I thought the original set made sense, though I am working on a spec that would make disk and ephemeral relevant. 18:43:24 I don't know that swap makes sense - why would you use swap? 18:44:18 so maybe a spec as you suggested originally? 18:45:14 amrith, Yes, my suggestion in the changeset was because I didn't see how exposing swap made sense in a cloud environment. 18:45:40 Maybe it does - if someone thinks so, let's have a discussion. 18:45:41 any other suggestions on this question? 18:47:52 Need to read carefully... 18:48:23 #agreed have a spec for whether we want flavor-list command, and by extension flavor-*, and what to show/expose 18:48:29 ok, any other topics for open discussion 18:49:57 nope — that's all I had 18:50:04 going once ... 18:50:45 going once 18:51:06 do we want a hacking rule for i18n? 18:51:17 trevormc, please say more 18:51:28 It makes sense now with added changes in shell's troveclient. 18:51:36 is there one? 18:52:19 I don't know if we should be asking people to add i18n in reviews if there isn't a hacking rule in the project. 18:52:25 Now that the help strings in troveclient are i8n, there should be a rule for it. 18:53:47 neutron_lib has a set of hacking rules for i18n, is that something we should import or reimplement? 18:54:06 anyone else have thoughts on this? 18:54:14 agree,maybe we need a rule to clear that 18:54:57 If someone has time they could look into it. May not be worth spending weeks on, but if it's easy ... 18:55:52 sounds reasonable to me. what's the next step? a change, a spec, an etherpad? 18:57:11 If it's just a matter of taking something that neutron is already doing, I wouldn't think a spec necessary. We already know we want to i8n stuff. 18:57:56 trevormc, sound good to you? submit a patch with the proposed changes? 18:58:10 amrith, yep sounds good 18:59:09 #action [trevormc] submit changes with new i18n hacking rule 18:59:13 anything else 19:00:13 #endmeeting