17:00:52 <sergmelikyan> #startmeeting murano
17:00:52 <openstack> Meeting started Tue Sep 29 17:00:52 2015 UTC and is due to finish in 60 minutes.  The chair is sergmelikyan. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:55 <openstack> The meeting name has been set to 'murano'
17:01:04 <sergmelikyan> Hi folks o/
17:01:07 <_ddovbii> hi!
17:01:09 <Nikolay_St> hi
17:01:09 <freerunner> o/
17:01:14 <stan_lagun> hi!
17:01:23 <xiangxinyong> Hello
17:01:23 <kzaitsev_mb> \o/
17:01:46 <ativelkov> o/
17:02:20 <katyafervent> hi
17:02:39 <sergmelikyan> #topic Action Items Review
17:02:53 <sergmelikyan> #1 StanLagun is going to switch working to https://bugs.launchpad.net/bugs/1476687
17:02:53 <openstack> Launchpad bug 1476687 in murano "murano-agent hangs after processing the first request on RHEL6-based distro" [High,Won't fix]
17:03:11 <sergmelikyan> bug is marked as won't fix with explanation
17:03:54 <stan_lagun> thats right
17:04:47 <sergmelikyan> folks, any questions regarding that? It's worries me that we need something in agent that will handle situations like that
17:05:04 <sergmelikyan> stan_lagun: I remember that you was planning to create bp regarding heartbeats
17:05:10 <sergmelikyan> had a chance to do that?
17:05:39 <stan_lagun> I think we will need to implement rabbitmq heartbeats in agent someday
17:05:55 <kzaitsev_mb> I believe we have a bug for that and a commit from me
17:06:02 <stan_lagun> Also there are a lot of things in Unified Agent specification that are not implemented yet
17:06:21 <kzaitsev_mb> #link https://review.openstack.org/#/c/187213/
17:06:57 <sergmelikyan> kzaitsev_mb: yep, I remember, that's why I was curios your if we can combine them, but for that we need something from stan_lagun
17:07:29 <stan_lagun> kzaitsev_mb: your commit just introduces config section. It doesn't enables heartbeats. Also this is on engine<->RabbitMQ and here is agent<->RabbitMQ
17:07:40 <kzaitsev_mb> we can revive that one and alter it as we see fit. the link also has link to the bug #link https://bugs.launchpad.net/murano/+bug/1460037
17:07:40 <openstack> Launchpad bug 1460037 in murano mitaka "Apparently dead connections can pile up in engine/agent rabbitmq" [High,New]
17:08:13 <stan_lagun> sergmelikyan: I don't think we can combine them. The code if very different
17:08:15 <kzaitsev_mb> stan_lagun: like I said, we can revive and alter as we see fit
17:08:30 <sergmelikyan> stan_lagun: I was not talking about code
17:09:11 <sergmelikyan> I also remembered that Kirill was working on something similar and that's why asked for BP from you ) Looks like you didn't had a chance to create one :)
17:09:22 <kzaitsev_mb> and not only it introduces the config section, but also passes the config param down to kombu. =)
17:09:25 <kzaitsev_mb> btw
17:09:42 <kzaitsev_mb> oslo guys were considering adding pika
17:09:57 <kzaitsev_mb> and something else to global req and to oslo.messaging
17:10:04 <stan_lagun> kzaitsev_mb: that is not enough to make it work. Rather the opposite - if we would merge your commit everything will break
17:10:11 <kzaitsev_mb> during yesterdays oslo meeting
17:10:26 <stan_lagun> sergmelikyan: yes, you are right. But we can extend existing bug to fit both cases
17:10:27 <kzaitsev_mb> stan_lagun: that's why it has -WIP =)
17:10:37 <sergmelikyan> kzaitsev_mb: yeah, I heard about switching to Pika, do you have links to reasons behind that?
17:11:03 <sergmelikyan> I would prefere BP rather than bug for this - looks clearly like feature
17:11:13 <kzaitsev_mb> you can read comments section — they're all there )
17:11:36 <stan_lagun> sergmelikyan: do you want separate BPs for 2 cases or one BP with 2 partial implementations?
17:12:17 <kzaitsev_mb> pika and kafka =)
17:12:19 <kzaitsev_mb> yep
17:12:25 <kzaitsev_mb> #link http://eavesdrop.openstack.org/meetings/oslo/2015/oslo.2015-09-28-16.00.log.html
17:12:43 <kzaitsev_mb> how meta — to link for eavesdrop )
17:13:54 <stan_lagun> We used kombu because oslo.messaging uses it. I don't think it is too late to switch to pika now
17:14:05 <sergmelikyan> stan_lagun: cases = engine <> RMQ and agent <RMQ>?
17:14:14 <stan_lagun> sergmelikyan: yes
17:14:34 <sergmelikyan> I think it's one case actually engine <> agent
17:14:40 <kzaitsev_mb> as long as pika/kafka make it into the global-reqs
17:14:49 <kzaitsev_mb> but now that there is some traction around them
17:15:05 <kzaitsev_mb> I'm sure they will do so in M
17:16:54 <kzaitsev_mb> #link https://blueprints.launchpad.net/oslo.messaging/+spec/rabbit-pika
17:17:45 <kzaitsev_mb> and this thread
17:17:48 <kzaitsev_mb> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/075457.html
17:18:02 <sergmelikyan> kzaitsev_mb: thank you
17:18:04 <sergmelikyan> !
17:18:12 <sergmelikyan> let's move to next topic?
17:18:29 <sergmelikyan> #Liberty RC1 (2?)
17:18:37 <sergmelikyan> #topic Liberty RC1 (2?)
17:19:34 <katyafervent> RC1 or RC2 ?
17:19:51 <sergmelikyan> https://launchpad.net/murano-apps/+milestone/liberty-rc2 https://launchpad.net/murano/+milestone/liberty-rc2
17:20:00 <ativelkov> Do we have new bugs reported in RC1 which we gona fix in Rc2?
17:20:13 <sergmelikyan> RC1 was successfully released but it happened after last meeting
17:20:28 <sergmelikyan> RC 2 is on Thursday
17:20:50 <sergmelikyan> ativelkov: we don't have open bugs for murano but few for murano-apps
17:24:13 <sergmelikyan> from the new things we have only https://bugs.launchpad.net/bugs/1498879
17:24:13 <openstack> Launchpad bug 1498879 in murano-apps mitaka "cAdvisor port (4194) is not adding to Security Group in Kubernetes Cluster Package." [Undecided,New]
17:24:33 <sergmelikyan> _ddovbii: can you help here?
17:25:16 <_ddovbii> sergmelikyan: sure! looks strange
17:25:30 <stan_lagun> the bug has a link to the code that does add port 4194 to security group :)
17:25:43 <stan_lagun> Also it used to work
17:26:39 <sergmelikyan> stan_lagun: thats what I am talking about - this thing should be verified first
17:26:53 <sergmelikyan> based on the code it should work
17:28:02 <stan_lagun> Probably something else broke and because of muted exceptions in Parallel block remained unnoticed. I'm going to verify it on 1.0.6 and resolve the bug (most likely with Incomplete)
17:28:22 <stan_lagun> _ddovbii: please check it on 0.15
17:28:59 <_ddovbii> stan_lagun: ok
17:34:19 <sergmelikyan> #topic Open Discussion
17:35:12 <ativelkov> sergmelikyan: I probably missed that, but did we released the murano-client with the version-workaround fix?
17:35:36 <stan_lagun> we haven't decided if we going to release core library with version 0.0.0 or 0.1.0. And the same for MuranoPL package format: 1.0 or 1.1
17:35:55 <kzaitsev_mb> ativelkov and I are going to finally start working on a POC for app-catalog. guess somewhere near the end of this week, when we both have time )
17:36:03 <kzaitsev_mb> just a FYI
17:36:18 <kzaitsev_mb> *POC of a backend
17:36:32 <freerunner> Folks, what do you say, if I commit a few new tests to master branch and backport it to liberty?
17:36:37 <kzaitsev_mb> (not directly related, but still important to note =))
17:36:46 <sergmelikyan> ativelkov: can you tell me more about that? Looks like I am missing something
17:37:19 <ativelkov> sergmelikyan: I mean the fix made by kzaitsev_mb to support the temporary redirrect of app catalog
17:37:47 <sergmelikyan> ativelkov: we didn't actually release client with this fix :(
17:37:53 <kzaitsev_mb> sergmelikyan: ativelkov is speaking about this #link https://review.openstack.org/#/c/225249/ review
17:38:01 <kzaitsev_mb> would we be allowed to?
17:38:03 <sergmelikyan> #action release new version of the client and propose change to global-requirements
17:38:18 <sergmelikyan> kzaitsev_mb: we allowed to release, not sure about global requirements
17:38:36 <ativelkov> I see
17:38:38 <kzaitsev_mb> hope the global-req guys would make an exception
17:38:49 <ativelkov> So yeah, the main concern is the globa-reqs
17:38:49 <kzaitsev_mb> the've released a proposed schedule for M
17:39:18 <kzaitsev_mb> that includes client-release for M. But that rule was not in place for L, so I'm hoping it'll be OK
17:40:26 <katyafervent> I think it's not too late
17:42:50 <freerunner> katyafervent: Requirements already have liberty branch.
17:43:26 <freerunner> katyafervent: And it might be too late to changing it.
17:43:43 <ativelkov> oh
17:44:33 <ativelkov> then yes, usually the stable/* simply cannot accept any new merges until the * is release
17:44:48 <sergmelikyan> ativelkov: but can after
17:44:52 <ativelkov> they have some special ACLs enabled
17:45:02 <ativelkov> yup, as soon as it is a regular stable branch
17:45:39 <ativelkov> but that means that the release of Murano L will not be able to work with the app-catalog, and we'll have to wait for the first post-release refresh
17:46:09 <freerunner> ativelkov: so bad =(
17:46:31 <sergmelikyan> guys, let's see and ask about update of global-reqs
17:47:08 <ativelkov> but that's a question to sergmelikyan: as a big-tent program murano has more control over its release schedule: we may try releasing Murano L several days after the rest of opesntack - after the global-reqs is unfrozen
17:47:43 <ativelkov> I mean not the main murano L, but rather its client
17:50:04 <freerunner> ativelkov: Anyway, the client will capped in global-reqs soon. We should just ask infra guys, when we can do patch into reqs.
17:51:12 <sergmelikyan> folks, let's me think about that
17:51:42 <sergmelikyan> #action think about what can be done regarding community app catalog support in Murano
17:51:57 <ativelkov> Sure. I hope we'll have some clarity on this till the next meeting
17:53:39 <freerunner> One more question I've asked a few minutes ago. ^^
17:54:00 <freerunner> >> [20:36:32]  <freerunner>	Folks, what do you say, if I commit a few new tests to master branch and backport it to liberty?
17:54:22 <kzaitsev_mb> freerunner: I'm conflicted about it =)
17:54:31 <ativelkov> moar tests for the god of tests
17:54:37 <freerunner> kzaitsev_mb: I'm not surprised =)
17:55:56 <freerunner> So, what is the verdict? ;)
17:56:50 <ativelkov> My +1 for having more tests in master. Unsure about the real need to backport them to stable branch
17:57:19 <kzaitsev_mb> definitelly +1 for master. still conflicted about stable )
17:57:24 <Nikolay_St> I agree with ativelkov.
17:57:35 <kzaitsev_mb> well we can add untill we release L
17:57:41 <Nikolay_St> I'm not sure that we really need to backport tests
17:58:02 <kzaitsev_mb> it's not technically backporting, since we didn't release L yet
17:58:21 <ativelkov> as we have RCs, we should have a "proposed" branch, don't we?
17:58:29 <ruhe> i would back-port a test only if this test covers some of back-ported bug fixes
17:58:36 <sergmelikyan> ativelkov: we have
17:58:36 <stan_lagun> guys, lets not skip my question about versioning. We may schedule it to next CM
17:58:43 <sergmelikyan> ruhe: +1
17:58:51 <ativelkov> (it is not supposed to be called proposed anymore, but still, our master should not be liberty)
17:58:54 <sergmelikyan> stan_lagun: sure
17:59:05 <sergmelikyan> we have stable/liberty already
17:59:11 <ativelkov> sergmelikyan: great
17:59:46 <ativelkov> so, anything which gets from master to stable/liberty is a "backport", and we shouldn't do it without a really serious reason (say, critical bug)
18:00:02 <ativelkov> tests are not such a reason
18:00:24 <sergmelikyan> #endmeeting