17:00:10 <ativelkov> #startmeeting murano
17:00:10 <openstack> Meeting started Tue Mar 25 17:00:10 2014 UTC and is due to finish in 60 minutes.  The chair is ativelkov. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:14 <openstack> The meeting name has been set to 'murano'
17:00:25 <tsufiev_> hello
17:00:28 <ativelkov> Hi folks. Anybody here for Murano meeting?
17:00:35 <ativelkov> Identify yourself please
17:00:54 <katyafervent2> Hi!
17:01:35 <tsufiev_> not much...
17:01:54 <sergmelikyan> o/
17:02:17 <ativelkov> Less people - faster meeting :)
17:02:24 <ativelkov> We have agenda here
17:02:27 <ativelkov> #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda#Agenda
17:02:38 <ativelkov> Not much agenda items as well, I believe
17:02:45 <dteselkin> Hi!
17:03:03 <tsufiev_> api&formats versioning is missing :(
17:03:18 <tsufiev_> sorry, it is in place
17:03:47 <ativelkov> probably it is becuase I update it not too long ago
17:03:53 <ativelkov> So, let's begin
17:04:20 <ativelkov> #topic AI review
17:04:43 <ativelkov> We didn't make any formal AIs last time
17:05:00 <ativelkov> however we made an important decision: we've decided to get rid of murano-comon repository
17:05:36 <ruhe> murano-common is already merged in murano-api
17:05:47 <katyafervent2> Cool! Thanks ruhe
17:05:51 <ruhe> and i'm working on merging it into murano-agent
17:05:57 <ativelkov> Cool!
17:06:05 <ativelkov> #info murano-common is already merged in murano-api
17:06:13 <ruhe> where i've got stuck a little bit because i need to test that i didn't break anything :)
17:06:27 <ativelkov> #info merging of murano-common into murano-agent is in progress
17:06:44 <ruhe> and our CI is not yet ready to test changes in murano-agent
17:07:32 <ativelkov> ruhe: you mean linux-based one?
17:07:37 <ruhe> ativelkov: yes
17:08:10 <ruhe> i hope we'll create jobs for murano-agent changes in our CI
17:08:18 <ruhe> right after the release
17:09:41 <ativelkov> I would prefer first to have a cloud-init-deployable murano-agent instead of embedding it to image
17:09:54 <ativelkov> This will simplify the development of the agent
17:10:05 <ruhe> ativelkov: agree. that should be the first priority
17:10:06 <sergmelikyan> +1
17:10:30 <ativelkov> and will make sence in having CI on it. Otherwise there is no continuous development at the first place
17:10:46 <ativelkov> Are we agreed on that?
17:11:13 <dteselkin> +1
17:11:16 <ruhe> +1
17:11:28 <tsufiev_> +1
17:11:39 <katyafervent2> +1
17:11:42 <stanlagun> +1
17:12:02 <ativelkov> #agreed to make a priority to create a cloud-init deployable agent after 0.5 is released
17:12:10 <ativelkov> Do we have a blueprint for this change?
17:12:33 <stanlagun> do we know how to do it?
17:12:38 <ruhe> does this agreement include windows-based agent? :)
17:13:10 <ruhe> stanlagun: we're engineers, we'll figure it out ;)
17:13:35 <ativelkov> ruhe: we plan to run python-agent on windows as well
17:13:53 <ruhe> ativelkov: hooray! one agent to rule them all
17:13:54 <ativelkov> It will just need to learn how to execute powershell-based execution plans, afair
17:13:58 <dteselkin> As for windows-agent, testing it on VM will require a powerfull system :)
17:14:22 <stanlagun> as soon as we teach pthon-agent to execute PowerShell
17:14:53 <ruhe> activestate python might have these capabilities
17:15:09 <ativelkov> stanlagun: any estimates on how difficult it may be?
17:15:21 <stanlagun> any python have these capabilities. It is just not that trivial to implement
17:15:30 <dteselkin> We could simply call external powershell.exe application.
17:15:58 <stanlagun> not that simple. My estimation is up to 3 days
17:16:22 <ruhe> stanlagun: 3 days compared to 6 month release cycle sound good to me
17:16:31 <ativelkov> well, "up to 3 days" is quite fine
17:16:43 <ativelkov> it would be a problem it were months
17:16:50 <ativelkov> days is quite ok
17:17:08 <stanlagun> And several days more to turn python-agent into Windows service
17:17:08 <dteselkin> So we should add a new dependecy into our image builder - python
17:17:10 <ativelkov> But I didn't get any answer about blueprint, so I assume there is no BP
17:17:39 <ativelkov> dteselkin: eventual goal of this activity is to avoid using image builder at all
17:17:54 <dteselkin> How will we build windows images then?
17:18:14 <stanlagun> why do we need to build them?
17:18:36 <ativelkov> well, for windows the customers will have to embed cloud-base init into the images, that's true
17:18:50 <ativelkov> but this should be the only thing to embed
17:19:02 <dteselkin> +python
17:19:04 <ativelkov> python should be installable in the same manner as everuthing else
17:19:15 <ativelkov> with cloud-base-init
17:19:18 <dteselkin> cloud-init embeds it's oun python
17:19:24 <dteselkin> *own
17:19:37 <dteselkin> it doesn't install it system-wide
17:19:54 <ruhe> well, in some cases users might prefer to have images with everythin pre-installed. disk-image-builder will do the job for linux images
17:19:58 <stanlagun> can agent use it as well?
17:20:13 <dteselkin> use what ?
17:20:29 <stanlagun> We are not going to drop image builder. But the goal is that it would be optional
17:20:38 <ruhe> stanlagun: +1
17:20:47 <dteselkin> It's ok I think
17:21:26 <ativelkov> So, do we have a volunteer to create a BP for cloud-init-deployable agent?
17:21:36 <ruhe> ativelkov: o/
17:21:40 <ativelkov> thanks
17:21:54 <ativelkov> #action ruhe to create a BP on cloud-init-deployable agent
17:22:42 <ativelkov> dteselkin: if I understand stanlagun's question, he asks if the python which was installed by cloud-init may be made available to other services (i.e. to our agent)?
17:22:45 <ruhe> i'll create the BP, but we'll need to brain-storm possible implementations in a group
17:23:30 <ativelkov> ruhe: sure. The questions is harder then it seems, as the repository for installable artifacts should be available even if the internet connectivity is not present
17:23:51 <ruhe> ativelkov: dteselkin: stanlagun: linux's cloud-init uses system python. actually all the major distros have python pre-installed
17:24:00 <dteselkin> ativelkov, it should be tested. In theory, it's possible, but doesn't look like a good idea
17:24:16 <dteselkin> ruhe, in linux - yes
17:24:28 <dteselkin> But windows doesn't have it preinstalled of course
17:24:31 <ativelkov> ruhe: this mostly concerns windows, as it does not have neither python nor a simple (apt-get like) way to deploy it
17:25:05 <dteselkin> So to have unified agent really unufied I think it's better to add system wide python to windows
17:25:20 <stanlagun> ativelkov: If we inject cloud-init into Windows image we can inject Python as well. Or use cloud-init's one. Lets do a little research on it
17:25:30 <ruhe> eh, windows users are used to perform a lot of manual work. i think they wouldn't complain if they'll have to build images with murano agent by themselves
17:25:32 <ativelkov> ok
17:25:50 <ativelkov> Anyway, we are now way too far in the future
17:25:57 <ativelkov> we still have 0.5 at hand
17:26:07 <ativelkov> Let's proceed with the agenda
17:26:19 <ativelkov> #topic API versioning
17:26:26 <ativelkov> tsufiev_: please lead this
17:26:43 <tsufiev_> ok
17:27:33 <tsufiev_> so, the first and most obvious question: to what extent should each new version of murano components support older formats and apis?
17:28:51 <tsufiev_> or more narrow question: should murano 0.5 dynamic UI processor support v.1 dynamic UI definitions (pre 0.5)?
17:28:51 <stanlagun> I stand for Murano consistency. Dashboard version X guarantee to work with API version X only
17:29:10 <ruhe> at this point i'd prefer to support only one version - current version. across all the projects in the same release
17:29:22 <katyafervent2> +1 to stanlagun
17:29:27 <sergmelikyan> Ruhe, stanlagun +1
17:29:34 <stanlagun> There is no point in supporting old UI forms without supporting XML workflows and old APIs as well
17:29:44 <tsufiev_> for now that seems ok for me, but it can change in future, when there will be much more Murano resources of a certain version
17:30:03 <stanlagun> lets leave it till Murano 1.0
17:30:20 <tsufiev_> will it be ok for current murano customers?
17:30:41 <ruhe> we could think about it from a different point of view - what should be the upgrade path for Murano users? but, indeed, that's a questions for future
17:30:43 <stanlagun> we are breaking backward compatibility anyway
17:30:54 <stanlagun> and probably will do it again in 0.6
17:31:28 <ativelkov> What I suggest is to always have a format classifier in all files
17:31:39 <ativelkov> DSL, UI definitions, object models, etc
17:31:42 <tsufiev_> i agree, breaking dynamic UI format backward compatibility seems minor issue comparing with the dropping out of all workflows :)
17:31:44 <ativelkov> just to fix the format
17:31:56 <stanlagun> Yes. But maybe not Version
17:32:09 <tsufiev_> stanlagun: why not?
17:32:16 <stanlagun> or not just Version
17:32:30 <stanlagun> Maybe MinimumMuranoVersion
17:32:47 <tsufiev_> could you elaborate it a bit?
17:33:40 <stanlagun> Suppose that your form uses some YAQL function that was introduced in version x.y.z. But the format of the form hasn't changed
17:34:09 <ativelkov> MinimumMuranoVersion and similar params should be part of Package metadata
17:34:12 <ativelkov> not for forms
17:34:25 <ativelkov> This is entirely different topic
17:34:27 <stanlagun> Every template should have minimum required Murano version that can handle it
17:34:33 <stanlagun> forms also use YAQL functions
17:34:36 <ativelkov> There shluld also be a Minimum Openstack version )
17:34:55 <stanlagun> Maybe that too for things that depend on OpenStack
17:35:01 <ativelkov> stanlagun: I would suggest to have these constraint on a per-package basis
17:35:03 <tsufiev_> ativelkov: agree, there will be a lot of dependencies )
17:35:14 <ruhe> other approach - document changes and give users clear upgrade path instructions
17:35:16 <stanlagun> ativelkov: agree
17:35:31 <tsufiev_> ativelkov: +1
17:36:02 <tsufiev_> still each file should denote its format version
17:36:10 <ativelkov> but format is format, so there should be a clear format identifyer for each document
17:36:16 <ativelkov> tsufiev_: +1 )
17:37:00 <tsufiev_> will simple numeric format like '1', '2' be enough for us?
17:37:01 <stanlagun> okay until you don't have to support older versions till 1.0
17:37:33 <ativelkov> For packages I've started from 1.0
17:37:35 <stanlagun> tsufiev_: does it really important?
17:37:48 <stanlagun> 1 = 1.0.
17:38:36 <katyafervent2> we can have 1 and 1.1 at the same time
17:38:37 <tsufiev_> stanlagun: it is important, because once we agree on it, we won't change it
17:38:58 <stanlagun> lets assume it is just a number
17:39:28 <tsufiev_> i vote for the integers
17:39:31 <stanlagun> as soon as we would need something ather than 1 we get back on this and discuss on 1.2 vs 2.0
17:39:36 <tsufiev_> keeps things simple
17:39:58 <stanlagun> this is Python. You just non need to think about this
17:40:19 <tsufiev_> stanlagun: but you're right, don't need to bother, cause YAML-parser does it for us
17:40:50 <ruhe> i personally don't care until we really need versioning. we're in active development stage now, and will be for the next 6 months
17:40:53 <stanlagun> yep. So this doesn't affect any code you may write to support it
17:41:10 <ativelkov> Seems we are agreed here
17:41:23 <ativelkov> moving on?
17:41:32 <tsufiev_> yes
17:41:52 <ativelkov> #topic MuranoPL package name
17:42:02 <ativelkov> sergmelikyan: can you lead this?
17:42:16 <sergmelikyan> ativelkov, sure!
17:42:24 <stanlagun> Can you explain the topic?
17:42:43 <sergmelikyan> We selecting name of the package were core of our Murano PL going to be placed.
17:42:45 <stanlagun> Have we discussed MuranoPL namespaces?
17:42:54 <sergmelikyan> stanlagun, not yet
17:43:19 <sergmelikyan> package will have name like muranoapi.<name>
17:44:00 <stanlagun> I thought you were talking about AppCatalog package (zip file)
17:44:11 <sergmelikyan> I suggest name "engine", are there any other suggestions?
17:44:19 <sergmelikyan> Lets select most popular one
17:44:25 <ativelkov> I like "dsl" and "pl"
17:44:26 <stanlagun> engine is already used
17:44:33 <sergmelikyan> *language
17:44:34 <sergmelikyan> sorry
17:44:45 <tsufiev_> +1 for pl
17:44:48 <ruhe> it's a turing-complete language. so... pl
17:45:18 <stanlagun> +1 for dsl. pl is too confusing. Looks like Perl extension
17:45:35 <ativelkov> pl/dsl - same as pl/sql :)
17:45:56 <tsufiev_> stanlagun: lol, haven't thought about perl )
17:46:02 <ruhe> ativelkov: we might get sued by you-know-who :)
17:46:14 <sergmelikyan> but pl in pl/sql is procedure language ;)
17:46:18 <stanlagun> pl/sql without sql is nothing. We should not make an impression that MuranoPL is GP-language like Python
17:46:55 <ativelkov> I would prefer 3-characters naming
17:47:01 <sergmelikyan> ruhe, dsl does not mean not turing-complete language.
17:47:13 <ativelkov> So, we have options "language", "pl", "dsl" - right?
17:47:23 <ativelkov> any other options? I want to make a vote
17:47:29 <stanlagun> mpl
17:47:33 <ruhe> democratic vote agian? :)
17:47:54 <tsufiev_> mpl is nice too
17:47:57 <ativelkov> Yes, I nlike votings
17:48:13 <ativelkov> they are better then fightings )
17:48:38 <ativelkov> #startvote Which name should we choose? pl, dsl, mpl, language
17:48:38 <openstack> Begin voting on: Which name should we choose? Valid vote options are pl, dsl, mpl, language.
17:48:39 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
17:48:54 <ativelkov> #vote dsl
17:49:08 <sergmelikyan> #vote dsl
17:49:08 <katyafervent2> #vote pl
17:49:11 <stanlagun> #vote dsl
17:49:11 <ruhe> #vote abstain
17:49:12 <openstack> ruhe: abstain is not a valid option. Valid options are pl, dsl, mpl, language.
17:49:23 <dteselkin> #vote dsl
17:49:41 <tsufiev_> #vote dsl
17:50:01 <ativelkov> Anybody else?
17:50:16 <ativelkov> #endvote
17:50:17 <openstack> Voted on "Which name should we choose?" Results are
17:50:18 <openstack> dsl (5): tsufiev_, stanlagun, dteselkin, ativelkov, sergmelikyan
17:50:19 <openstack> pl (1): katyafervent2
17:50:30 <ativelkov> #agreed so it is dsl
17:51:00 <stanlagun> we also need to choose murano.dsl vs murano.eninge.dsl
17:51:28 <ruhe> stanlagun: what option do you prefer?
17:51:35 <stanlagun> murano.dsl
17:51:46 <ruhe> then i vote murano.dsl :)
17:52:05 <ativelkov> I like the first one. It is shorter (pep8 <80 hehe) and dsl has its value regardless of the engine which uses it
17:52:21 <ativelkov> No objections?
17:52:56 <ativelkov> #agreed Put dsl package on the top level inside murano
17:53:09 <ativelkov> #topic Open Discussion
17:53:22 <ativelkov> Any open issues or questions to discuss?
17:53:29 <sergmelikyan> package namespaces?
17:54:02 <stanlagun> I think it would be best to ask comunity in ML
17:54:07 <ativelkov> sergmelikyan: please elaborate
17:55:00 <sergmelikyan> All classed declared in MuranoPL should be placed in some namespaces. For now it is org.openstack, e.g. org.openstack.Oject
17:55:03 <stanlagun> org.openstack.murano.Object vs com.mirantis.murano.Objects vs something else
17:55:20 <ativelkov> ah
17:55:21 <ativelkov> I see
17:55:37 <ativelkov> I would prefer it to be org.openstack.murano, however there is a legal issue here
17:55:42 <stanlagun> maybe have just murano.XXX for system classes
17:55:46 <ativelkov> or, there may be a legal issue
17:56:09 <stanlagun> or system.XXX
17:56:25 <ativelkov> I would have it uniform and bound to domains - just to discurouge others from doing something.else
17:56:41 <stanlagun> makes sence
17:56:58 <ativelkov> but the question "Are we allowed to use foundation-owned domain for this
17:57:04 <ativelkov> but the question "Are we allowed to use foundation-owned domain for this" remain open
17:57:17 <stanlagun> The question is who can answer such question
17:57:23 <ativelkov> Foundation
17:57:51 <stanlagun> Do you know to question Foundation?
17:57:53 <ruhe> i'd prefer to avoid OpenStack name in our project until Murano gets official status
17:58:23 <stanlagun> It might be too late to change it then
17:58:54 <ruhe> that's one of the rights projects get when they get integrated status - they can officialy use OpenStack brand
17:59:02 <ruhe> that's how i understand that
17:59:12 <stanlagun> We are going to do everything possible to keep backward compatibility starting from some version (say 1.0)
17:59:13 <ativelkov> That is not the brand usage
17:59:23 <ativelkov> That is just the identifier
17:59:58 <ativelkov> Anyway, we can explain our concerns and as the mailing list for advice. Foundation members monitor it
18:00:08 <stanlagun> Maybe register dedicated murano domain? org.murano-project.system.Object :)
18:00:21 <ativelkov> This is a nice option, btw
18:00:42 <ruhe> who's going to own murano-project.org? Murano foundation? :)
18:00:58 <ativelkov> )
18:00:58 <ruhe> oops, out of time
18:01:08 <ativelkov> oops, yes.
18:01:14 <ativelkov> Ok, continue next time then
18:01:19 <ativelkov> #endmeeting