17:01:41 <kzaitsev_mb> #startmeeting murano
17:01:42 <openstack> Meeting started Tue Jul 28 17:01:41 2015 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:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:46 <openstack> The meeting name has been set to 'murano'
17:02:09 <Nikolay_St> hii
17:02:18 <kzaitsev_mb> hi all =)
17:02:30 <freerunner> hey ;)
17:02:30 <katyafervent> 0/
17:02:31 <xiangxinyong> hello
17:02:36 <kzaitsev_mb> todays agenda #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda/Archive/2015-07-28/
17:02:38 <mgershen> Hi
17:02:39 <FilipBlaha> Hi
17:02:54 <stan_lagun> o/
17:04:27 <kzaitsev_mb> we had a couple of AI from prevous time. 1st we asked stan_lagun to coordinate yaql release with mistrall guys. I think ativelkov covered that in his email and stan_lagun would cover that in status update =)
17:05:11 <kzaitsev_mb> 2d: Nikolay_St create a draft of the log guideline spec.
17:05:38 <stan_lagun> kzaitsev_mb: tell when its time for status updates :)
17:05:49 <kzaitsev_mb> and he did it with #link https://review.openstack.org/#/c/205200/
17:06:04 <kzaitsev_mb> so let's move to the status update for yaql then =)
17:06:17 <kzaitsev_mb> #topic Migrating to yaql 1.0 status. (slagun)
17:06:26 <stan_lagun> there are 2 news: good and the bad
17:06:31 <kzaitsev_mb> so how are we doing there stan_lagun ?
17:07:00 <kzaitsev_mb> should we vote on which to start with? =)
17:07:36 <stan_lagun> the bad news is that yaql migration affected how MuranoPL objects were constructed and initialized. We had previously mostly not working new() and buggy object initialization that was hard to fix. Now I was forced to do that and it took additional time
17:08:22 <stan_lagun> the good news is that this quest is almost completed and most of our unit tests are green already with small minor issues left to fix
17:08:32 <stan_lagun> so the final version is going to be really soon
17:09:16 <kzaitsev_mb> good to hear that, you're still optimistic =)
17:09:39 <kzaitsev_mb> So we're going to have rc2, right?
17:10:03 <stan_lagun> rc2 is for yaql, not for dsl migration
17:10:14 <katyafervent> when?
17:10:26 <katyafervent> what do you think, when we will have rc2?
17:10:50 <stan_lagun> but yes, there are 3 commits over yaql rc1 that are waiting for code review. I don't know if there will be more commits to yaql. Probably not
17:11:12 <stan_lagun> and those commits are bug-fixes
17:11:29 <kzaitsev_mb> Correct me if I'm worng. the plan is: rc2 yaql. commits to murano (synced with mistral), that fail. commits to infra to bump yaql version. finally recheck and merge commits to murano.
17:11:30 <stan_lagun> so there is a feature freeze for yaql 1.0.0
17:12:15 <kzaitsev_mb> stan_lagun: ativelkov: am I correct with the order of things to come?
17:12:37 <ativelkov> kzaitsev_mb: not exactly
17:12:38 <stan_lagun> kzaitsev_mb: step 0: QA verification of everything from code in commits on code review. Correct otherwise
17:13:11 <ativelkov> There should be a formal YAQL 1.0 release before the commits to infra
17:13:59 <ativelkov> The idea is to minimize the window when all the active murano patches get broken
17:14:03 <stan_lagun> rc2 should become the release
17:14:25 <kzaitsev_mb> ok. then. We can set up a test-new-yaql-murano week, what do you think? =)
17:14:30 <ativelkov> stan_lagun: the codebase - yes. But that will be a different tag and a different tarballk
17:15:23 <kzaitsev_mb> and encourage everyone to download a couple of apps and deploy them with new yaql to search for bugs and stuff?
17:16:16 <ativelkov> kzaitsev_mb: sounds like a good plan
17:16:44 <stan_lagun> kzaitsev_mb: well, apps need to be retested. There might be incompatibilities though I tried hard to avoid them. The only question is if it is going to be QAs work or entires team
17:17:37 <kzaitsev_mb> #action kzaitsev_mb as soon as yaql and muranopl is ready — write an email to encourage murano team and murano users to test new yaql
17:17:40 <kzaitsev_mb> ok then
17:18:13 <kzaitsev_mb> sound like a decent plan, let's hope we'll have new yaql by the end of the week =)
17:18:47 <stan_lagun> the main trick will be to build new murano because it will require unreleased yaql, client, dashboard and engine (all from commits on review)
17:19:34 <kzaitsev_mb> stan_lagun: I'll provide instructions, yep
17:20:02 <kzaitsev_mb> #topic Cloud Foundry Service Broker status (Nikolay_St)
17:20:06 <Nikolay_St> hi all
17:20:07 <kzaitsev_mb> let's move in
17:20:19 <kzaitsev_mb> Nikolay_St: so, what's our status with CF integration?
17:20:28 <Nikolay_St> ok
17:20:42 <kzaitsev_mb> s/move in/move on/
17:20:47 <Nikolay_St> code is ready for review
17:21:01 <kzaitsev_mb> but? =)
17:21:13 <kzaitsev_mb> (cause there should be some 'but', I believe)
17:21:30 <Nikolay_St> but we don't have a lab to test that everything works as expected
17:21:58 <Nikolay_St> we are interested in specific field 'parameters' that appeared at CF service broker API v2.5
17:22:33 <Nikolay_St> the latest stackato image (on which I tested the concepts) has only v2.4 API and don't support 'parameters'
17:23:12 <Nikolay_St> so, we need to wait until the new stackato image will be delievered or we can install CF itself
17:23:20 <kzaitsev_mb> ok, that is a bummer. not really sure, if I can think of any real solution, since you're already in contact with pivotal AFAIK
17:23:27 <Nikolay_St> but we need some extra resources for it:(
17:23:30 <Nikolay_St> sure
17:23:55 <Nikolay_St> the main idea is that the code is ready for review
17:24:06 <Nikolay_St> #link: https://review.openstack.org/#/c/196820/
17:24:18 <Nikolay_St> #link: https://review.openstack.org/#/c/202011/
17:24:27 <kzaitsev_mb> so if anyone by any chance can share a latest CF lab with service broker API v2.5 — we would be eternally gratefull =))
17:24:53 <kzaitsev_mb> if not — we'll have to wait for the stackato image =)
17:25:05 <Nikolay_St> if you want to try how it works you can contact me) and I'll give an instructions about little hacks for the current stackato ;)
17:25:10 <Nikolay_St> that's all from my side
17:25:13 <Nikolay_St> or
17:25:19 <Nikolay_St> I moved bp for liberty-3
17:25:46 <Nikolay_St> s/or/oh/
17:26:03 <kzaitsev_mb> right. since L2 is like what, today/tomorrow? =)
17:26:14 <kzaitsev_mb> Thursday at best )
17:26:32 <kzaitsev_mb> ok, thanks Nikolay_St keep us updated
17:26:48 <kzaitsev_mb> #topic Support for heat environments and files status (mgershen)
17:27:13 <mgershen> So there are 3 things I like to discuss
17:27:38 <mgershen> 1- The files feature implementation is going well and waiting for review
17:27:44 <mgershen> #link: https://review.openstack.org/#/c/205853/
17:28:03 <mgershen> It might have a chance to get in L-2
17:28:25 <mgershen> 2- The concatenate env id to stack name feature needs approval and can be found here:
17:28:33 <mgershen> #link: https://blueprints.launchpad.net/murano/+spec/concatenate-env-id-to-stack-name
17:29:00 <mgershen> I already discussed possible implementation with stan_lagun. It seems simple, should a spec be written anyway?
17:30:25 <kzaitsev_mb> mgershen: well, we do not have strict rules on writing specs
17:30:44 <katyafervent> I think blueprint is enough for the small feature
17:30:56 <katyafervent> that's for sure
17:31:24 <mgershen> great :D
17:31:54 <kzaitsev_mb> mgershen: usually if a feature is small to medium — you should file a BP. if it's big — you should file a BP and consider a spec. If it is difficult to implement — you should definitelly file a spec. And if it alters API somehow — that's also a nice indicator, that a spec is required/preferred
17:32:17 <kzaitsev_mb> I read that somewhere on nova wiki, I think
17:33:00 <kzaitsev_mb> so, feel free to just file a BP, and pls mention smelykian (our PTL) as approver =)
17:33:25 <mgershen> #link: https://blueprints.launchpad.net/murano/+spec/concatenate-env-id-to-stack-name
17:33:35 <mgershen> OK
17:34:03 <kzaitsev_mb> mgershen: also, what do you think about new tag feature of heat?
17:34:26 <kzaitsev_mb> wouldn't using it solve the problem?
17:34:53 <mgershen> I think it will be nice to leverage all features in heat
17:35:06 <kzaitsev_mb> mgershen: take a look at #link https://blueprints.launchpad.net/murano/+spec/tag-murano-heat-stacks
17:37:08 <kzaitsev_mb> Seems like tagging should allow searching and hiding stack, created by murano, but would not allow to determine which stack belongs to which env. Unless we tag stack with env-ids =)
17:37:50 <kzaitsev_mb> Although this might be a bit more work, than your option, so we might want to do both =)
17:37:51 <mgershen> I think it is not enough for us, because our customers sometimes login to OpenStack and expect to see the stacks there.
17:37:53 <stan_lagun> kzaitsev_mb: stack description contains env id
17:38:35 <mgershen> I would like to concatenate env id to stack name
17:39:31 <kzaitsev_mb> mgershen: I personally have no objections to your idea, just remembered, that there is a related BP.
17:39:35 <mgershen> If the user gives stack description in the template there is no env_id in the stack description
17:40:28 <mgershen> kzaitsev_mb: thank you, I will and I will take this to my team here :)
17:41:11 <kzaitsev_mb> mgershen: so yep, would be nice if you look a bit into tags, casue they seem like they might be benefitial for your situation =)
17:41:18 <kzaitsev_mb> mgershen: you only listed 2 of 3 items
17:41:33 <kzaitsev_mb> so what's 3d? =)
17:41:34 <mgershen> yes, thank you :)
17:41:45 <mgershen> 3- The environments feature didn't pass spec review yet. With feature freeze getting closer I want to change what was agreed and not return the Heat environments names at the first step. In my company we plan to get them by downloading the package and searching there.
17:42:15 <mgershen> current spec is here:
17:42:19 <mgershen> #link: https://review.openstack.org/#/c/202610/
17:42:30 <mgershen> any objections?
17:44:00 <stan_lagun> mgershen: I believe this spec is obsolete as we agreed not to introduce API changes. Aren't we?
17:45:16 <mgershen> #link https://review.openstack.org/#/c/198559/
17:45:45 <mgershen> stan_lagun, the link up here is the obsolete one.
17:46:04 <mgershen> we said no API changes for support for Heat files
17:46:32 <stan_lagun> mgershen: no API changes required for any of your specs
17:46:53 <mgershen> The user still needs to pass the environment name somehow, and we are using a RESTful API
17:47:16 <stan_lagun> is this still an issue lets discuss it on #murano
17:48:25 <stan_lagun> mgershen: The way to pass environment is the same way as all Heat stack parameters passed. This can be just another parameter from API's PoV
17:48:28 <mgershen> OK, but no objections for dropping the UI APi part
17:49:44 <mgershen> stan_lagun: I see what you are saying, yes can be part of the POST body
17:50:05 <kzaitsev_mb> #info decided to further discuss environments feature in murano and to drop API changes from it as well
17:51:00 <kzaitsev_mb> but generally there are no strong objections to implementing it, as far as I understand
17:52:23 <stan_lagun> no objections for the idea and use case. But we need to agree on implementation details
17:52:48 <kzaitsev_mb> ok agreed on that then.
17:53:06 <mgershen> great :)
17:53:12 <kzaitsev_mb> #topic Open Discussion
17:53:27 <kzaitsev_mb> Any news you guys would want to share? =)
17:55:02 <kzaitsev_mb> I'm slowly linting our js code-base (like 1 file a day), which takes 5-10 minutes of my time a day =). Think the job would be green by the end of next week
17:55:20 <kzaitsev_mb> Or maybe by next meeting if we're lucky enough =)
17:55:34 <kzaitsev_mb> fell free to join #link https://etherpad.openstack.org/p/murano-escleanup
17:55:46 <ativelkov> There is a news item from my side
17:55:53 <kzaitsev_mb> need to get xiangxinyong to attend our meetings =)
17:56:03 <xiangxinyong> year i am here
17:56:09 <ativelkov> It seems like the "major refactoring" of Glance V3 is taking longer than I expected
17:56:44 <xiangxinyong> kzaitsev:should js code-base be fixed in L2?
17:56:48 <kzaitsev_mb> oh great! =)
17:56:57 <kzaitsev_mb> xiangxinyong: nope, I think L3 would be fine
17:57:17 <xiangxinyong> understood
17:57:29 <kzaitsev_mb> ativelkov: so does it mean that we'll not be able to move to artifacts in L ?
17:57:54 <ativelkov> kzaitsev_mb: nope, it means thatthe murano plugin for Glance AR will be implemented using the existing framework and API, i.e. with using what we currently have in glance master branch
17:58:34 <kzaitsev_mb> got it. Would it be much pain to re-write it later?
17:58:50 <ativelkov> So, the transition will happen, but probably we'll need to rewrite the plugin from scratch when the API refactoring is made
17:58:59 <kzaitsev_mb> bummer
17:59:02 <ativelkov> not that much pain.
17:59:28 <ativelkov> Anyway, it's better than taking a risk to wait till all thes stuff is done there
17:59:49 <kzaitsev_mb> ativelkov: let's add a status update on glance v3 as an item for next meeting, what do you think?
17:59:55 <ativelkov> Yup
18:00:24 <kzaitsev_mb> ok #action kzaitsev_mb add a status update on transition to glance v3 to agnda for next meeting
18:00:27 <ativelkov> BTW, I'll be on a trip next week, not sure if I'll be able to participate in this meeting
18:00:39 <kzaitsev_mb> well I'll ping you then =)
18:00:57 <mgershen> ativelkov: have fun :)
18:01:04 <kzaitsev_mb> ok, seems we're out of time. Thanks everyone for joining us today! =)
18:01:31 <kzaitsev_mb> #endmeeting