17:01:11 #startmeeting murano 17:01:11 Meeting started Tue Apr 19 17:01:11 2016 UTC and is due to finish in 60 minutes. The chair is kzaitsev_mb. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:16 The meeting name has been set to 'murano' 17:01:40 #topic rollcall 17:01:43 o/ 17:01:43 o/ 17:01:48 o/ 17:01:50 o/ 17:01:51 o/ 17:01:53 o/ 17:01:57 \o/ 17:03:07 our agends is available at 17:03:10 #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda 17:03:44 #topic Action Items Review 17:04:01 I'm a bit hasty today %) 17:04:07 O/ 17:04:10 brobably too much coffee ) 17:05:08 I had an AI to convert an etherpad for murano-contributors-rules into a commit to docs 17:05:14 kzaitsev: it can't be too much =] 17:05:41 but all the preps ate my time =( 17:06:04 so I'm going to move it to next one, 17:06:15 o/ 17:06:42 actually since I'm travelling — may I ask someone to do that? vakovalchuk, oshykhkerimov may I recruit any of you for this? 17:07:02 yes 17:07:16 awesome 17:07:26 let's do it 17:08:05 #action vakovalchuk and oshykhkerimov convert https://etherpad.openstack.org/p/murano-contributors-rules into a commit to docs 17:08:30 thanks guys 17:08:54 ok 17:09:06 #topic Dashboard. Provide region when create environment 17:09:23 #link https://review.openstack.org/#/c/305747/ 17:09:31 Stan put a -2 there 17:10:01 Although I'm not 100% sure that he is right there 17:10:33 I didn't quite understand his point too 17:10:45 tlashchova: do I understand correctly, that this patch adds the currently selected region as the default? 17:11:37 kzaitsev_mb, yes 17:11:43 StanLagun: I get it, that we need a separate UI for choosing a region, but isn't choosing the region user is in right now (in hotizon) a good enough workaround for now? 17:12:08 kzaitsev_mb: we already have it 17:12:23 you can deploy to current region without this commit 17:12:55 with HomeRegion? 17:13:23 but if we choose RegionTwo in horizon, we will still deploy to home region of a user 17:13:25 if you don't specify region than it defaults to home_region which must be set anyway 17:13:55 StanLagun: that's the point of the commit — you can choose a region in horizon's drop-down 17:14:35 we already has thus functionality working. You don't need this commit to make it work - it already does 17:14:59 it doesn't. if you have home_region set — you can't deploy into a different region from horizon 17:15:18 let me explain 17:15:34 home_region is a setting in murano.conf telling which region it belongs to 17:16:05 when you switch regions in horizon you start talking to Murano API in that region which supposed to have home_region configured already 17:16:26 And if you don't provide "region" property explicitly it will be the current region 17:16:39 So you will be deploying to the chosen region 17:16:57 unless you have a home_region set 17:16:58 Thus this commit brings no extra value 17:17:14 not unless 17:17:19 you always have it 17:17:41 home_region must be set for each region independently 17:17:55 it just telling engine where its API live 17:18:34 well, I can think of at least 1 situation — a single murano in RegionOne, configured to talk to both RegionOne and RegionTwo services 17:18:35 so in each region home_region must be set to the name of *that* region 17:18:56 with no murano-api in RegionTwo 17:19:11 that will not work with this commit 17:19:36 because once you switch that dropbox in Horizon you will be talking to murano-api in RegionTwo 17:19:43 there's no way to override it 17:20:32 *if* you don't override murano-api in horizon's setting 17:20:36 unless you register the same endpoint for 2 regions in keystone 17:20:43 or that 17:21:19 I see the point, that for the most time only developers would benefit from this change 17:22:40 ok, I think I can agree on leaving it as is. 17:22:40 My main point was that region property was intent not to duplicate Horizon drop box and we can make it right right from the start 17:24:56 kzaitsev_mb: StanLagun looks like we need additional test for it 17:25:18 We won't backport it to stable/mitaka I believe. And I really hope we will settle on some UI for that during N cycle 17:25:21 Though you convinced me to change my -2 to -1 17:25:33 and at least we need a commit which will include home_region property to murano dashboard 17:25:49 to murano config 17:26:00 And really cleary explanation of how this works :) 17:26:14 I have a feeling that existing documentation is not enough :) 17:26:14 we have both 17:29:06 I still think that there should be a UI solution for it, so that the user would be explicitly aware, that the env is going to be deployed into some region 17:30:23 So I suggest that we abandon this approach and work on a better UI during N 17:30:30 kzaitsev_mb user select region in Horizon dropbox and sees only environments belonging to that region. Why would he require something else if he wants to deploy to that region? 17:31:09 StanLagun: To allow explicitly setting region, even if you have home_region/murano-api set 17:31:25 user is not aware of murano.conf settings 17:31:45 exactly 17:31:46 he expects that env will be deployed to the only region he selected 17:31:57 why do you think so? =) 17:32:47 because if there's only a single point where you select region you usually expect that it's region for everything 17:32:55 why not allow user choose the region and set default to the currently selected one? 17:33:10 and that's what happens if you don't set yourself some weird setup 17:33:53 kzaitsev_mb we should allow it 17:33:58 I think we agree here 17:34:20 We just need to have properly working UI for it 17:34:30 yep =) 17:35:12 So once again — I suggest to abandon this kind of approach and work on better UI for creation during N =) 17:35:26 +1 17:37:02 since there are no objections — I'm going to say 'agreed' here 17:37:33 #agreed https://review.openstack.org/#/c/305747/ and work on better UI for regions during N 17:37:54 ok no more agenda for today 17:38:00 #topic Open Discussion 17:39:02 I have a couple points here: 1st I'll cancel next meeting, since summit =) 17:40:36 sounds reasonable (: 17:40:39 + 17:42:39 2d — I'l probably cancel the meeting after next one, since there're going to be a holidays for european part of our team, I believe 17:42:48 gotta check that more carefully 17:43:11 in any case I'm going to write emails for that to ML soon enough =) 17:43:57 Thank you 17:44:11 also after summit many folks take vacations 17:45:06 exactly 17:45:27 I also wanted to add one thing to for the record 17:45:33 #link https://etherpad.openstack.org/p/murano-newton-priorities 17:46:08 I'm going to use this etherpad as a sync point for our priorities during N-cycle 17:46:58 it's half-baked at this point, but we would work through it during following weeks. 17:47:18 ok nothing more from my side =) 17:51:41 I suggest we save ourselves 10mins of our lives and end a bit early today ;) 17:52:08 as usual see you around in #murano 17:52:20 #endmeeting