17:01:10 <serg_melikyan> #startmeeting murano
17:01:11 <openstack> Meeting started Tue Dec 30 17:01:10 2014 UTC and is due to finish in 60 minutes.  The chair is serg_melikyan. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:15 <openstack> The meeting name has been set to 'murano'
17:01:43 <serg_melikyan> Hi folks!
17:02:10 <StanLagun> hi
17:02:33 <katyafervent2> hi
17:02:37 <serg_melikyan> Happy Holidays! Not so much time left before New Year, but I hope some us will join today :)
17:04:29 <serg_melikyan> #topic Action Items Review
17:04:50 <serg_melikyan> Meeting Minutes from previous meeting: http://eavesdrop.openstack.org/meetings/murano/2014/murano.2014-12-23-17.00.html
17:05:00 <serg_melikyan> #1 Dmitry Dovbii, write specification for https://blueprints.launchpad.net/murano/+spec/murano-agent-timeouts
17:05:18 <serg_melikyan> I think this action item should be moved to the next meeting
17:05:18 <ruhe> o/
17:05:23 <serg_melikyan> ruhe: o/
17:05:58 <serg_melikyan> any objections?
17:06:10 <ruhe> no objections
17:06:13 <ruhe> but
17:06:21 <ruhe> when shall we have the next irc meeting? :)
17:06:30 <serg_melikyan> On January 13 :)
17:06:34 <ruhe> ok
17:06:49 <serg_melikyan> We are going to skip meeting at Jan 6 due to holidays in Russia
17:06:51 <katyafervent2> yeah, lets wait for Dima
17:06:56 <serg_melikyan> #action Dmitry Dovbii, write specification for https://blueprints.launchpad.net/murano/+spec/murano-agent-timeouts
17:07:32 <ruhe> but, since Dima is not forced to have holidays for 12 days, i'd expect the specification to be ready long before january 13th
17:07:38 <serg_melikyan> #2 StanLagun is going to write specs for migrate-to-yaql-vnext
17:07:45 <serg_melikyan> ruhe: I hope so
17:08:41 <StanLagun> serg_melikyan: at the last meeting I said not to expect it today
17:09:01 <serg_melikyan> I hoped :)
17:09:05 <serg_melikyan> #action StanLagun is going to write specs for migrate-to-yaql-vnext
17:09:26 <serg_melikyan> #3 serg_melikyan will update roadmap mapping BPs to milestones
17:09:44 <serg_melikyan> Have no excuses, missed this AI
17:09:49 <serg_melikyan> #action serg_melikyan will update roadmap mapping BPs to milestones
17:10:25 <serg_melikyan> #topic Approve blueprints for K2
17:11:18 <serg_melikyan> Many blueprint don't have specs yet, and even worse, but I think we should go through blueprint and approve part of them.
17:11:36 <serg_melikyan> Those features was approved for K, and we expect to have complete specs for them before end of the cycle.
17:12:06 <serg_melikyan> Starting from the next cycle, ALL features planned for L would be required to have specs before L
17:13:00 <serg_melikyan> In this cycle I think we can go with only blueprints and specs that are planned or in progress
17:13:05 <ruhe> ++
17:13:38 <serg_melikyan> #1 https://blueprints.launchpad.net/murano/+spec/murano-agent-timeouts
17:13:58 <serg_melikyan> Dima promised spec for this feature and feature itself implemented in K2
17:14:14 <serg_melikyan> I am voting to approve and assign this BP for k2
17:14:39 <serg_melikyan> Who is with me?
17:15:13 <StanLagun> +1
17:15:59 <serg_melikyan> ruhe: what do you think? Another approach is not approve them, but assign. I think when implementation will be ready (k2 or k3) spec will be ready too.
17:16:00 <ruhe> no objections
17:16:32 <ruhe> this particular feature should be relatively simple
17:17:34 <StanLagun> ruhe: this depends on if it is going to be built on custom amqp authentication or not
17:18:16 <serg_melikyan> Second approach with BPs that had no spec yet: set direction to approved, definition to discussion (until spec will be merged) and assign them to k2.
17:18:22 <ruhe> there shouldn't be any custom code and murano should not rely on anything specific to rabbitmq
17:18:58 <serg_melikyan> ruhe: do you like first or second?
17:19:01 <ruhe> some users might decide to use qpid
17:19:16 <StanLagun> ruhe: not for agent communications
17:19:16 <ruhe> serg_melikyan: 2nd makes more sense
17:19:23 <serg_melikyan> ruhe: We can't use qpid for engine <> agent communication
17:19:37 <serg_melikyan> only RabbitMQ
17:19:38 <StanLagun> ruhe: there is no universal solution here. At least I don't know one
17:19:59 <ruhe> i see
17:22:14 <serg_melikyan> We discussed that we will implement simplest part of solution that does not need any features from RabbitMQ - timeouts from engine side. And will research how to implement solution for timeouts from agent part
17:23:09 <serg_melikyan> We agreed on inclusion of this BP to K2?
17:24:42 <serg_melikyan> ruhe, StanLagun, katyafervent
17:25:37 <ruhe> serg_melikyan: i prefer 2nd approach proposed by you
17:26:13 <serg_melikyan> Ok, but we agree to assign https://blueprints.launchpad.net/murano/+spec/murano-agent-timeouts ?
17:26:26 <ruhe> to k2? i agree, yes
17:27:55 <serg_melikyan> #2 https://blueprints.launchpad.net/murano/+spec/migrate-to-yaql-vnext
17:28:00 <serg_melikyan> same question about this one
17:28:56 <ruhe> first comment: i don't like vnext :)
17:29:06 <ruhe> it should be either 0.3 or 1.0
17:29:37 <StanLagun> 1.0
17:30:12 <StanLagun> but there is no 1.0 yet. Thats why vNext
17:30:14 <ruhe> and there should be a spec for yaql 0.3 (or 1.0) before the migration to this new version is targeted in Kilo-2 or Kilo-3
17:30:23 <StanLagun> yes
17:30:56 <ruhe> so, i'd prefer to postpone this BP
17:31:10 <serg_melikyan> Mmm second approach that I described doesn't require spec to be assigned. I was talking about all BPs
17:31:25 <ruhe> also, StanLagun, please, please make sure that 1.0 introduces minimum changes
17:31:31 <StanLagun> we can target blueprint but don't merge anything before spec
17:32:27 <ruhe> +1
17:32:33 <StanLagun> ruhe: 0.3 already introduces a lot of changes. At least for hosting projects. There would also be incompatible changes for end users, but most of the things won't break
17:32:51 <ruhe> target BP, but don't approve it
17:33:07 <serg_melikyan> that was I am talking about :)
17:33:16 <StanLagun> 0.3 is not compatible with 0.2. So 1.0 won't be either
17:33:43 <ruhe> StanLagun: minimum set of incompatible changes would still be a very nice :)
17:34:02 <serg_melikyan> #3 https://blueprints.launchpad.net/murano/+spec/murano-versioning
17:34:16 <serg_melikyan> I am worried, cause I think we would be unable to deliver this in K2
17:34:18 <StanLagun> ruhe: both Mistral and Murano have yaql>=0.2.x,<0.3 in requirements.txt
17:34:32 <serg_melikyan> We even didn't selected minimal scope to implement
17:34:48 <ruhe> StanLagun: yeah, but migration path should be as smooth as possible
17:35:29 <ruhe> StanLagun: what do you think about scope and timeframe for versioning support?
17:36:33 <StanLagun> ruhe: that depends on what is the first LTS version that we going to support. If that is Kilo the scope is very different from if it is Juno
17:37:08 <serg_melikyan> We already discussed that question
17:37:12 <StanLagun> and another thing is when do we plan to redesign core library (release core-library v2.0)
17:37:15 <serg_melikyan> 1) We don't have LTS
17:37:31 <serg_melikyan> 2) We start supporting versioning from Kilo
17:38:14 * serg_melikyan also worried about meeting time
17:38:26 <StanLagun> Then I think we can support minor version changes in Kilo
17:38:47 <StanLagun> i.e. without adapters
17:39:33 <serg_melikyan> StanLagun: do we able to implement this BP in K2, given that K is first version with versioning support?
17:39:51 <serg_melikyan> Can we assign this BP to K2?
17:40:08 <StanLagun> serg_melikyan: this need to be split into several sub-tasks
17:40:44 <serg_melikyan> I know - we had no time to discuss this on this week. That is why I am asking you cause you wrote spec
17:40:54 <StanLagun> for example we can change API/DB to store several versions of single package
17:41:29 <StanLagun> Because of long holidays I'm not sure if we will have enough time in K2
17:41:31 <StanLagun> but we can try
17:42:17 <StanLagun> I think we should start at K2 and finish as soon as possible. But it may be K3 in the end
17:42:33 <serg_melikyan> Ok
17:43:12 <serg_melikyan> #4 https://blueprints.launchpad.net/murano/+spec/enable-category-management
17:44:31 <ruhe> where is corresponing spec?
17:45:30 <serg_melikyan> not yet merged, but submitted
17:45:47 <serg_melikyan> https://review.openstack.org/139630
17:46:04 <serg_melikyan> http://docs-draft.openstack.org/30/139630/3/check/gate-murano-specs-docs/97de63c/doc/build/html/specs/kilo/enable-category-management.html
17:46:25 <ruhe> any reasons not to merge it?
17:48:21 <serg_melikyan> We discussed this today, unfortunately not in comments to review. I have few questions, I will write them in review
17:50:43 <serg_melikyan> Meanwhile we are running out of time :(
17:50:51 <serg_melikyan> I propose to continue this meeting tomorrow
17:51:03 <ruhe> ok
17:51:09 <StanLagun> tomorrow???
17:51:28 <StanLagun> just before midnight? :)
17:51:49 <serg_melikyan> But let's continue discussing enable-category-management :)
17:51:53 <ruhe> what else are you gonna do? celebrate new year?
17:52:16 <serg_melikyan> StanLagun: nope :) Let's do this a little bit earlier in our #murano
17:52:30 <StanLagun> ruhe: no way :)
17:53:36 <serg_melikyan> Guys, we are really slow :)
17:53:45 <serg_melikyan> With this temp we need 4 hours meetings
17:54:00 <serg_melikyan> Once again: #4 https://blueprints.launchpad.net/murano/+spec/enable-category-management
17:54:40 <ruhe> once again: we all owe katyafervent a review, +2, approve this spec, approve code related to this spec. it's been on review for way too long
17:54:49 <serg_melikyan> +1
17:55:27 <ruhe> serg_melikyan: if your comments to the spec are minor, i suggest to approve related BP and target it to K2
17:55:38 <serg_melikyan> #topic Open Discussion
17:55:54 <serg_melikyan> ruhe: yeah, just how to represent this in UI
17:56:25 <ruhe> approve BP, and leave a comment on whiteboard
17:56:45 <ruhe> leave a comment about comments in spec
17:56:53 <serg_melikyan> Righty ho, boss
17:57:01 <ruhe> :) :) :)
17:57:10 <serg_melikyan> %)
17:57:12 <serg_melikyan> :)
17:59:05 <serg_melikyan> #endmeeting