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