17:01:16 <serg_melikyan> #startmeeting murano
17:01:17 <openstack> Meeting started Tue Feb  3 17:01:16 2015 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:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:21 <openstack> The meeting name has been set to 'murano'
17:01:31 <serg_melikyan> Hi folks :)
17:01:49 <katyafervent> Hi
17:02:20 <RadekPospisil> hi
17:02:27 <hmunfru> hi
17:03:21 <serg_melikyan> #topic Action Items Review
17:03:33 <serg_melikyan> Let's start with action items :)
17:04:29 <serg_melikyan> We have only one action item, assigned to the katyafervent
17:04:33 <serg_melikyan> #1 katyafervent, research more about log/exception localization
17:04:54 <serg_melikyan> katyafervent: do you had a chance to research this matter?
17:05:04 <katyafervent> let's move this AI for the next meeting
17:05:40 <katyafervent> I think I'll write message to ML with the result of research
17:05:57 <serg_melikyan> Ok
17:06:14 <serg_melikyan> #action katyafervent, research more about log/exception localization
17:07:11 <serg_melikyan> #topic New API calls naming voting
17:08:08 <serg_melikyan> We are talking about new this specification -> https://review.openstack.org/141334 proposed by hmunfru
17:08:38 <katyafervent> And blueprint is here https://blueprints.launchpad.net/murano/+spec/blueprint-template
17:09:05 <katyafervent> btw, provide the status update - not it's on review
17:09:15 <katyafervent> * now
17:10:18 <serg_melikyan> #startvote How we should name this entity? environment-templates, environment-snapshot, environment-blueprint
17:10:19 <openstack> Begin voting on: How we should name this entity? Valid vote options are environment-templates, environment-snapshot, environment-blueprint.
17:10:20 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
17:10:33 <serg_melikyan> Let's vote for term
17:10:54 <katyafervent> serg_melikyan, could you paste options here please
17:11:10 <serg_melikyan> I did that -> Begin voting on: How we should name this entity? Valid vote options are environment-templates, environment-snapshot, environment-blueprint.
17:11:13 <katyafervent> Oh, I see :)
17:11:26 <StanLagun> #vote environment-templates
17:11:29 <hmunfru> #vote environment-templates
17:11:38 <serg_melikyan> #vote environment-templates
17:11:57 <katyafervent> #vote environment-templates
17:12:10 <serg_melikyan> though I agree that term is used very often, but it is very common thing
17:12:30 <pashkin> #vote environment-templates
17:12:31 <StanLagun> serg_melikyan: the same is true for all of those terms
17:12:35 <katyafervent> That's why we should not miss environments everywhere
17:12:56 <serg_melikyan> katyafervent: mm?
17:13:32 <katyafervent> not use 'template', but 'environment template'
17:13:41 <StanLagun> serg_melikyan: I think she meant to say we should call them "environment templates", not just templates
17:13:47 <hmunfru> ok
17:13:59 <katyafervent> should we add environments_templates to API url or templates will be enough?
17:14:13 <serg_melikyan> I believe it depends on the context,
17:14:28 <StanLagun> katyafervent: environment-templates (dash, not underscore)
17:14:40 <serg_melikyan> environments_templates <- no underscore in API URIs
17:15:09 <serg_melikyan> #endvote
17:15:10 <openstack> Voted on "How we should name this entity?" Results are
17:15:11 <openstack> environment-templates (5): katyafervent, pashkin, hmunfru, serg_melikyan, StanLagun
17:15:12 <katyafervent> we already use underscore, heat also uses underscore
17:15:37 <serg_melikyan> katyafervent: I can't say that I am happy with that
17:15:48 <katyafervent> but the question is should we use 'environments-templates' in url or just templates?
17:16:25 <serg_melikyan> I would say just templates
17:16:55 <StanLagun> serg_melikyan: what if we will want to have another type of templates?
17:17:01 <serg_melikyan> hmunfru: what do you think?
17:17:06 <StanLagun> can we have /environments/templates/ ?
17:17:12 <serg_melikyan> StanLagun: in API?
17:17:19 <StanLagun> yes
17:17:27 <serg_melikyan> Maybe we will have another type of environments then>
17:17:53 <serg_melikyan> environment/templates? I think it is not a bad option
17:18:02 <katyafervent> +1 from my side
17:18:07 <tartinette> hi
17:18:25 <katyafervent> hi tartinette!
17:18:37 <StanLagun> tartinette: hi!
17:19:24 <serg_melikyan> Looks like Henar got disconnected
17:19:28 <serg_melikyan> :(
17:19:51 <RadekPospisil> IMO /env..s/template is not so RESTish - it expresses some 'dependency' between resources environment and template ....
17:20:36 <StanLagun> RadekPospisil: you're right
17:21:04 <RadekPospisil> I like more /template only....
17:22:40 <katyafervent> what about /templates/environment so we will be able to add different types of templates in the future
17:23:05 <RadekPospisil> ok with /templates/environment
17:23:09 <StanLagun> +1
17:24:04 <serg_melikyan> It maybe premature
17:25:06 <RadekPospisil> can we do some API versioning like keystone has ? i.e., /v1, /v2,.... so it will be easier to evolve the API
17:25:58 <serg_melikyan> for sure, one of the biggest challenges for Kilo is to at least design v2 API :(
17:26:18 <StanLagun> we already have this versioning scheme
17:26:32 <RadekPospisil> ok, good to know :-)
17:26:55 <katyafervent> Guys, lets leave templates as it is, continue to discuss in review
17:27:20 <serg_melikyan> +1
17:27:27 <katyafervent> and if topic will still be actual, vote on the next meeting
17:27:52 <hmunfru> so keep template instead of enviornment-tempmlaet
17:28:01 <katyafervent> so let's move on to the next topic :)
17:28:14 <katyafervent> hmunfru, yeah
17:29:05 <serg_melikyan> hmunfru: environment templates, as a term for overall feature, and templates as URI
17:29:39 <serg_melikyan> #topic Kilo-2 Status
17:29:56 <serg_melikyan> katyafervent: I think this topic is proposed by you
17:30:05 <serg_melikyan> can you update us?
17:31:12 <katyafervent> the main progress is in YAQL, StanLagun did upload new versoin
17:32:05 <katyafervent> but this commit need to be updated a bit and specification should be uploaded
17:32:17 <katyafervent> we plan to finish with yaql in a week
17:32:37 <katyafervent> category management support is ready and waiting for a review
17:33:24 <katyafervent> adding timeouts to the murano agent is also implemented and now on review
17:33:56 <katyafervent> But we didn't started to plan versioning support
17:34:31 <katyafervent> and didn't accept any single specification
17:34:45 <katyafervent> which is bad
17:35:06 <serg_melikyan> true, we are not up to speed with K2 :(
17:35:36 <serg_melikyan> But looks like at least we are reviewing commits faster then specs
17:36:14 <serg_melikyan> I hope we will move in the next release to the proper scheme, where we will write all specs for L and submit them before end of K1.
17:36:17 <serg_melikyan> *L1
17:36:33 <katyafervent> and that's not right, should we create AI on reviewing more specs?
17:37:09 <serg_melikyan> katyafervent: how it will help? I don't think we are not doing that because we sitting and doing nothing
17:38:00 <serg_melikyan> It's just too expensive in terms of time, we are communicating faster about implementation in code
17:38:27 <serg_melikyan> But, we anyway need specifications in place - they are documentation for features
17:39:10 <katyafervent> it's not the right way to accepting features. specifications should describe implementation
17:39:28 <serg_melikyan> right, but we agreed to go that way for K
17:40:27 <katyafervent> Ok, what's next in our agenda
17:41:44 <serg_melikyan> #topic Check several BPs for validity
17:41:56 <serg_melikyan> #1 https://blueprints.launchpad.net/murano/+spec/ability-to-specify-url-for-services-definitions
17:42:52 <serg_melikyan> I think it is pretty valid BP, packages may be uploaded somewhere and ability to specify URI is pretty helpful
17:42:54 <katyafervent> do we need this features? If yes, need to set estimates
17:43:14 <serg_melikyan> katyafervent: we don't need to set estimates, we have tons of valid BPs
17:43:30 <katyafervent> ok, lets proposed it for L?
17:43:48 <serg_melikyan> We have someone who is willing to implement that BP?
17:43:57 <serg_melikyan> I would just remove milestone
17:44:51 <katyafervent> let's set it for 'future' series
17:44:56 <StanLagun> serg_melikyan: that BP seems like a wrong thing for me
17:45:10 <serg_melikyan> We are usually discuss Roadmap of the next release closer to the Summit date, and chose what and who is going to implement
17:45:27 <serg_melikyan> StanLagun: why?
17:46:17 <StanLagun> packages must be immutable. There must be no way to change any files inside uploaded packages. That is for user story #1
17:47:40 <serg_melikyan> I think that is pretty outdated BP, and it is should be converted to a BP about uploading packages to the catalog via URL
17:47:56 <StanLagun> It also may be wrong to tell murano to download package from somewhere. Otherwise it may be used for DDoS attacks or pointed to a terabyte file URL
17:48:24 <StanLagun> or just to pass network quotas
17:48:35 <katyafervent> So what's the decision?
17:48:51 <StanLagun> and packages may be really big
17:49:12 <StanLagun> I vote for rejecting that BP at all
17:50:36 <serg_melikyan> Timur Nurlygayanov proposed this BP more than one year ago, and no new updates about it since then
17:50:47 <katyafervent> I agree, that this feature is not super useful
17:51:10 <katyafervent> Any objections to reject it?
17:51:29 <katyafervent> Next blueprint is https://blueprints.launchpad.net/murano/+spec/docker-registry-in-murano
17:52:22 <katyafervent> Support docker registry and expose Docker apps in Murano Catalog
17:53:10 <serg_melikyan> It is very sketchy BP, I don't think we need to do anything with it at all. I would wait more details from Georgy.
17:53:43 <katyafervent> Is that blueprint adds Docker server and Docker apps?
17:53:43 <serg_melikyan> Let's just ask about more details in work  items?
17:53:59 <serg_melikyan> katyafervent: I don't know
17:54:11 <katyafervent> I agree, need to describe what exactly should be changed
17:55:05 <serg_melikyan> Not so much time left, let's move other two BPs to the next meeting?
17:56:16 <serg_melikyan> katyafervent: https://wiki.openstack.org/wiki/Blueprints
17:56:20 <katyafervent> ok
17:56:27 <serg_melikyan> #topic OpenDiscussion
18:01:13 <serg_melikyan> #endmeeting