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