17:00:39 <serg_melikyan> #startmeeting murano
17:00:40 <openstack> Meeting started Tue Dec 23 17:00:39 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:00:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:43 <openstack> The meeting name has been set to 'murano'
17:00:56 <serg_melikyan> Hi, folks!
17:00:59 <serg_melikyan> o/
17:03:14 <serg_melikyan> I am alone today on this meeting?
17:04:08 <katyafervent> I'm here
17:04:21 <ruhe> o/
17:04:30 <ruhe> sorry, i haven't seen start of the meeting
17:04:56 <serg_melikyan> :)
17:05:09 <serg_melikyan> #topic Action Items Review
17:05:19 <serg_melikyan> #info no action items from previous meeting
17:05:43 <serg_melikyan> #topic Discuss candidate blueprints for the K2
17:06:44 <ruhe> is Stan here today?
17:07:27 <serg_melikyan> We already started K2 with work on the bugs and blueprints moved from the K1, but I think we also to review and assign blueprints to the K2 milestone  start with =
17:07:31 <serg_melikyan> ruhe: nope
17:08:07 <ruhe> serg_melikyan: i agree with your plan
17:09:05 <serg_melikyan> I propose to start doing today and continue on the next week. This should be enough to discuss all blueprint that we plan to implement in K2
17:09:13 <serg_melikyan> *doing this
17:09:39 <ruhe> no objections
17:10:20 <serg_melikyan> And we need to have all specs (at least in draft state) for all Blueprints that we would assign to the K2 until the next meeting
17:10:41 <ruhe> ++
17:11:02 <serg_melikyan> Let's start?
17:11:18 <StanLagun> hello
17:11:57 <ruhe> Hi StanLagun!
17:13:03 <ruhe> serg_melikyan: let's start :)
17:13:20 <serg_melikyan> https://blueprints.launchpad.net/murano/+spec/murano-agent-timeouts
17:13:44 <serg_melikyan> this one is actually moved from the previous milestone and it's lack proper specification
17:14:23 <ruhe> serg_melikyan: who's going to implement this?
17:14:43 <serg_melikyan> I think Dmitry Dovbii is started working on this blueprint
17:15:05 <ruhe> is he around?
17:15:26 <serg_melikyan> No,
17:15:56 <serg_melikyan> I think he is working on his graduation work, he is graduating from university in few weeks.
17:16:28 <serg_melikyan> Probably that is why he is not here today\
17:16:57 <ruhe> ok. graduation is more important :)
17:17:02 <serg_melikyan> I think we can include this blueprint to the K2, and if would not have spec for this BP until next week, we will just remove milestone
17:17:12 <ruhe> agree
17:18:15 <serg_melikyan> #info https://blueprints.launchpad.net/murano/+spec/murano-agent-timeouts will be included to the K2, but will be removed if we would not have specification until next week
17:18:42 <serg_melikyan> #action Dmitry Dovbii, write specification for https://blueprints.launchpad.net/murano/+spec/murano-agent-timeouts
17:19:05 <serg_melikyan> https://blueprints.launchpad.net/murano/+spec/migrate-to-yaql-vnext - is next one
17:19:19 <StanLagun> serg_melikyan, maybe we need to split this blueprint into 2: timeouts and rabbitmq auth server that may be used to also control timeouts
17:19:39 <ruhe> migration to new yaql doesn't seem to be feasible in K2 because yaql is not ready yet
17:19:47 <serg_melikyan> StanLagun: Possibly
17:19:55 <serg_melikyan> ruhe, what do you mean?
17:20:00 <StanLagun> ruhe: this also includes developing yaql 1.0
17:20:24 <StanLagun> so the task is to write new yaql and migrate Murano to it
17:20:27 <ruhe> yeah, how can murano migrate to new yaql, if new yaql is not released yet
17:20:56 <serg_melikyan> StanLagun: I think we need to split migrate-to-yaql-vnext to the two blueprints. One in Murano scope and another one is in YAQL scope
17:21:01 <katyafervent> So we need one more task)
17:21:02 <StanLagun> we can release yaql before K2
17:21:09 <ruhe> there probably should be a separate spec for yaql itself
17:21:14 <serg_melikyan> ruhe: +1
17:21:22 <serg_melikyan> katyafervent: ?
17:21:33 <ruhe> StanLagun: i remember you wanted to create yaql-specs?
17:21:46 <katyafervent> I meant we need to split this blueprint
17:22:14 <StanLagun> ruhe: I will write spec as soon as I finish yaql PoC so that I know exactly what to write there :)
17:22:50 <ruhe> ok
17:23:22 <serg_melikyan> So what about blueprint? Should we postpone it until YAQL will be released?
17:23:45 <ruhe> yeah, i think it should be postponed
17:23:55 <serg_melikyan> other votes?
17:24:18 <StanLagun> We should finish all yaql-related tasks before K2
17:24:23 <StanLagun> including migration
17:25:00 <ruhe> StanLagun: we should, but, when is new yaql going to be released?
17:25:27 <StanLagun> the plan is to develop new yaql and yaql-migration by NY and then we will have 2 weeks to finilize it, write spec, review and make changes according to review
17:26:17 <ruhe> this plan sounds good to me
17:26:41 <StanLagun> ruhe: before K2 so that migration can be released in K2. Another option is to release yaql in K2 and have migration code in gerrit and release it in K3
17:26:50 <serg_melikyan> I would say that we need to start with spec for Murano, to create yaql-specs + write BP + implement it + release YAQL 1.0, and return to the BP implementation in the Murano
17:26:54 <StanLagun> but anyway we need to write everything in K2
17:27:18 <serg_melikyan> Once we will have both specs, we can assign this bp to the milestone
17:27:26 <serg_melikyan> StanLagun: +1
17:28:07 <serg_melikyan> do we agree on this approach?
17:28:26 <ruhe> ok. so the plan it to wait for a spec for yaql, code for new yaql, new release of yaql, a spec for murano to migrate to yaql and then assign that spec to K2. right? :)
17:28:27 <StanLagun> I just cannot write spec before I finish yaql PoC and this is 90% of implementation. I also need to write migration in parallel to make sure new yaql is good for Murano
17:28:51 <serg_melikyan> I would say that we need to wait for specs
17:29:17 <ruhe> StanLagun: btw, would it cause incompatible changes in muranopl?
17:30:31 <StanLagun> ruhe: in theory - yes. In practice nothing is going to break. At least now. And then we will have versioning that would allow us to break things without loosing compatibility
17:31:11 <StanLagun> But after we migrate to yaql 1.0 there would be new features in MuranoPL based on yaql 1.0
17:31:33 <ruhe> StanLagun: then i suggest you to think about making sure that applications on stackforge/murano-apps don't get broken once murano migrates to new version of yaql
17:32:10 <ruhe> maybe versioning should be added first?
17:32:23 <StanLagun> ruhe: I do think of this. But there is no 100% guarantee
17:32:36 <ruhe> serg_melikyan: please let us know if we're taking too much time per to discuss one BP
17:32:42 <StanLagun> Versioning would not help because we cannot use 2 versions of yaql in one project
17:33:27 <serg_melikyan> ruhe: I have only one more BP to discuss
17:33:36 <ruhe> ok
17:33:36 <serg_melikyan> so it's oke
17:34:05 <ruhe> i guess we can move on. we'll discuss details of this BP in spec
17:34:24 <ruhe> at this moment we have general agreement on approach to this
17:36:46 <serg_melikyan> #info we agreed to have two specs for https://blueprints.launchpad.net/murano/+spec/migrate-to-yaql-vnext in yaql-specs and in Murano
17:37:02 <serg_melikyan> #action StanLagun is going to write specs
17:37:16 <serg_melikyan> #action StanLagun is going to write specs for migrate-to-yaql-vnext
17:37:44 <StanLagun> serg_melikyan, but not by the next community meeting
17:37:54 <ruhe> serg_melikyan: jfyi, you can use undo prefixed with #
17:38:19 <serg_melikyan> ruhe: didn't know that, thank you
17:38:49 <serg_melikyan> #undo
17:38:50 <serg_melikyan> #undo
17:38:50 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x28503d0>
17:38:51 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x28509d0>
17:38:58 <serg_melikyan> #action StanLagun is going to write specs for migrate-to-yaql-vnext
17:39:37 <serg_melikyan> https://blueprints.launchpad.net/murano/+spec/murano-versioning
17:40:01 <serg_melikyan> This is really big blueprint/spec
17:40:22 <serg_melikyan> I think we need to define smaller scope to implement in K, and in K2 particularly
17:41:41 <serg_melikyan> ruhe? StanLagun? katyafervent?
17:42:36 <ruhe> i'd prefer to hear from StanLagun first
17:43:23 <StanLagun> agree
17:46:08 <serg_melikyan> #info we agreed to discuss smaller scope for murano-versioning
17:46:45 <serg_melikyan> Any other blueprints that we need to discuss?
17:47:16 <ruhe> is that all work planned for K2?
17:47:24 <serg_melikyan> I will send e-mail with details about todays discussion and agreements.
17:47:44 <serg_melikyan> ruhe: yes, plus tons of bugs that we shifted from k1
17:48:12 <serg_melikyan> plus work on Policy Guided Fullfilment & Chef/Puppet Configuration
17:48:39 <ruhe> serg_melikyan: would it make sense to update https://wiki.openstack.org/wiki/Murano/Roadmap and map each feature with kilo milestone?
17:48:42 <serg_melikyan> But unfortunately Radek and Henar are not on todays meeting
17:48:55 <serg_melikyan> ruhe, thank you for suggestion
17:49:36 <serg_melikyan> #action serg_melikyan will update roadmap mapping BPs to milestones
17:49:47 <serg_melikyan> #topic Open Discussion
17:49:48 <katyafervent2> will we enable category management?
17:50:13 <ruhe> katyafervent2: category management from UI?
17:51:03 <katyafervent2> yes
17:51:17 <ruhe> i personally think that's a very good improvement for UI
17:52:21 <serg_melikyan> katyafervent2: link to the bp?
17:52:31 <katyafervent2> i have a spec for that. this feature will be avaliable for admins only
17:52:55 <katyafervent2> so please approve so we will implement it someday in kilo
17:53:13 <ruhe> #link https://review.openstack.org/#/c/139630/
17:53:32 <serg_melikyan> We will approve them on the next meetings
17:53:40 <katyafervent2> i mean review first and than approve :)
17:53:53 <ruhe> serg_melikyan: i think we owe katyafervent2 a review of this spec
17:54:05 <serg_melikyan> ruhe: for sure
17:54:16 <serg_melikyan> katyafervent2: sorry, will do it ASAP
17:54:21 <ruhe> i don't think we need to wait for next meeting to approve it
17:55:01 <ruhe> katyafervent2: you also have https://review.openstack.org/#/c/137340/ (Remove name field from fields in dynamic UI)
17:55:32 <ruhe> katyafervent2: would you like to implement it in K2 too?
17:56:09 <serg_melikyan> I think it's actually on review
17:56:22 <serg_melikyan> and included to K2 (actually moved from K1)
17:56:29 <ruhe> ah, ok
17:56:48 <ruhe> katyafervent2: any other work you plan to do in k2?
17:59:22 <serg_melikyan> we run out of time :(
17:59:25 <serg_melikyan> #endmeeting