17:01:53 <ruhe> #startmeeting murano
17:01:53 <openstack> Meeting started Tue Apr 22 17:01:53 2014 UTC and is due to finish in 60 minutes.  The chair is ruhe. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:57 <openstack> The meeting name has been set to 'murano'
17:02:18 <ruhe> #topic Roll call
17:02:36 <ruhe> ruslan kamaldinov
17:02:48 <tsufiev_> o/
17:02:50 <ativelkov> o/
17:02:52 <gokrokve> georgy Orkovkertskhov
17:02:53 <dteselkin_> Dmitry Teselkin
17:02:59 <ativelkov> Alexander Tivelkov
17:03:01 <tsufiev_> hm... Timur Sufiev
17:03:02 <sergmelikyan> Serg Melikyan
17:03:05 <sjmc7> Steve McLellan
17:03:19 <ankurrr> Ankur Rishi
17:03:31 <SergeyLukjanov> hey folks, IMO it's better to add nickname to real name to meeting logs or keep irc's real name in actual state
17:03:55 <ruhe> great, seems that we the critical mass here
17:04:07 <ruhe> #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda
17:04:18 <ruhe> #topic Action Items Review
17:04:42 <ruhe> #link http://eavesdrop.openstack.org/meetings/murano/2014/murano.2014-04-15-17.03.txt
17:05:02 <ruhe> first one is on me - ruhe file a BP to track conversion of existing apps to the new DSL
17:05:20 <ruhe> i failed this one. will add a new AI
17:05:33 <ruhe> #action  ruhe file a BP to track conversion of existing apps to the new DSL
17:05:40 <sergmelikyan> ruhe, sorry, you did asked me to do this and I totally forgot :( Sorry (
17:05:50 <ruhe> sergmelikyan: ah, right
17:05:52 <ruhe> #undo
17:05:52 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x388a650>
17:06:06 <sergmelikyan> I had started working on transferring applications to new DSL and converted Apache today
17:06:10 <ruhe> #action sergmelikyan file a BP to track conversion of existing apps to the new DSL
17:06:23 <ruhe> next AI is also on me - setup infrastructure for dev-docs building and publishing
17:07:00 <ruhe> now we can build our docs with 'tox -e docs' and there is a patch on review in infra to push docs to murano-api.readthedocs.org
17:07:26 <ruhe> also, i have a patch with basic developer documentation:
17:07:35 <ruhe> #link https://review.openstack.org/#/c/88107/
17:07:44 <ruhe> you can see how it would like here:
17:07:50 <ruhe> #link http://murano-api.readthedocs.org/en/latest/
17:07:51 <katyafervent2> that's cool!
17:08:01 <sjmc7> ah, very cool
17:08:13 <ruhe> next AI is - sergmelikyan don't forget about and schedule a bug scrub day
17:08:32 <sergmelikyan> ruhe, scheduled by tnurlygayanov to tomorrow
17:08:43 <ruhe> sergmelikyan: at what time (UTC)?
17:09:13 <ativelkov> 16:00 UTC afair
17:09:14 <sergmelikyan> 16:00?
17:09:27 <ruhe> #info bug scrub scheduled for Wednesday 16:00 UTC
17:09:44 <ruhe> next AI is: slagun file a bug about missing "advanced networking"
17:09:52 <slagun> done
17:10:02 <ativelkov> And I am already working on it
17:10:14 <ruhe> #link https://bugs.launchpad.net/murano/+bug/1308921
17:10:24 <ruhe> #info advanced networking re-assigned to ativelkov
17:10:39 <ruhe> next AI is - slagun implement "advanced networking" in 0.5
17:10:46 <ruhe> that'll be an AI for ativelkov :)
17:11:03 <ativelkov> yup
17:11:04 <ruhe> i don't think we need to track it in the meeting logs. everybody's aware
17:11:19 <ruhe> #topic Release status
17:11:30 <ruhe> #link https://launchpad.net/murano/+milestone/0.5
17:11:53 <ruhe> all the features (except for adv. networking) are implemented AFAIK
17:12:01 <ruhe> gokrokve: what about billing UI?
17:12:23 <gokrokve> As soon as I can deploy something I will do it.
17:12:37 <ruhe> gokrokve: any estimates for the actual work?
17:13:08 <gokrokve> It should be pretty straight forward as all components are here. Just need to see actual data to represent it correctly.
17:13:14 <gokrokve> So couple days.
17:13:35 <ruhe> gokrokve: good
17:14:29 <ruhe> i hope we'll find more about missing bugs tomorrow on the bug scrub
17:14:53 <tsufiev_> missing bugs = bugs yet to be found :)?
17:14:57 <ruhe> would anyone like to add something about release status?
17:15:27 <ruhe> tsufiev_: i'd say - critical bugs to be fixed in this release
17:15:42 <ruhe> ok, let's move on
17:15:54 <ruhe> #topic Voting for the proper term 'Application being deployed/configured in an Environment'
17:16:00 <ruhe> tsufiev_: your turn
17:16:11 <tsufiev_> can i start the voting?
17:16:38 <ruhe> tsufiev_: only i can do it
17:16:57 <ruhe> but before we start, i'd like to be sure that everyone understands what we're voting for
17:17:09 <sjmc7> yes please
17:17:10 <tsufiev_> so far we invented the following alternatives for an 'Application inside an Environment': Service, Application Deployment, Solution, Component
17:17:47 <tsufiev_> ruhe, ok, i'll copy-paste note from the Agenda...
17:17:57 <tsufiev_> Currently we have an 'Application' as entity in AppCatalog. Using an OOP analogy it is like a Class, while instances of that class are being added to an Environment - for later deployment. 'Class instance' entity is now called 'Service' - but that is a legacy of times when Murano aimed to deploy Windows services only. So that term should be remade.
17:18:44 <tsufiev_> so, back to the voting options... has anyone coined some new term?
17:18:45 <katyafervent2> Application draft?
17:18:49 <ativelkov> more important: Application are not "just any classes", they are specific classes
17:18:56 <igormarnat_> So we can consider adding Daemon to the list, right, since we had services for windows?
17:19:04 <tsufiev_> katyafervent2, thanks, added
17:19:13 <ativelkov> they are not drafts: once they are deployed, at least
17:19:38 <tsufiev_> to me, the 'Component' option seems a good fit
17:19:41 <sjmc7> Daemon is not a very user-friendly term
17:19:44 <tsufiev_> thanks to ativelkov :)
17:19:55 <sergmelikyan> sjmc7, +1
17:19:55 <sjmc7> i think i also like 'Component' from that list
17:19:58 <igormarnat_> Well, it's well know in Linux, right
17:20:05 <ativelkov> Daemon is something very *nix'y
17:20:10 <igormarnat_> Yep
17:20:50 <tsufiev_> i think, if there are no other alternatives, we can start voting
17:21:01 <slagun> I suggest using both words interchangeably depending on particular application and context. All services are applications and most of applications in the cloud are services. We have app-catalog but sometimes word "service" is more appropriate
17:21:11 <ruhe> tsufiev_: can you give me a list of options?
17:21:30 <sjmc7> an 'application' might consist of multiple services in the software sense
17:21:35 <ativelkov> service is a kind of running application
17:21:57 <slagun> service is an applications that serves someone
17:22:02 <tsufiev_> ruhe, 'Service', 'Application', 'Application Deployment', 'Solution', 'Application Draft', 'Component', 'Daemon'
17:22:07 <ativelkov> MySQL is a service, that's true. But the network - which is a part of environment and may be a 1sty class citizen of a catalog - is not a service
17:22:18 <tsufiev_> folks, did i miss something?
17:22:37 <sergmelikyan> tsufiev_, I think we could start voting :)
17:22:38 <slagun> tsufiev_ you've missed my option "both/all"
17:22:43 <ativelkov> Brick
17:22:47 <ruhe> #startvote How should we name 'Application being deployed/configured in an Environment'? Service, Application, Application Deployment, Solution, Application Draft, Component, Daemon
17:22:47 <openstack> Begin voting on: How should we name 'Application being deployed/configured in an Environment'? Valid vote options are Service, Application, Application, Deployment, Solution, Application, Draft, Component, Daemon.
17:22:48 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
17:23:06 <sergmelikyan> #vote Component
17:23:06 <ankurrr> #vote Application Deployment
17:23:06 <openstack> ankurrr: Application Deployment is not a valid option. Valid options are Service, Application, Application, Deployment, Solution, Application, Draft, Component, Daemon.
17:23:10 <tsufiev_> #vote Component
17:23:14 <katyafervent2> # Component
17:23:16 <ativelkov> #vote Component
17:23:17 <dteselkin_> #vote Component
17:23:19 <igormarnat_> #vote Application
17:23:24 <sjmc7> Application is in there twice..
17:23:32 <sjmc7> #vote Component
17:24:00 <ankurrr> Ah, one of them is supposed to be "Application Deployment".  I think that's why "Application" is in there twice
17:24:02 <ruhe> sjmc7: right. i had to wrap it in quotes. but we'll count vote from ankurrr manually
17:24:05 <tsufiev_> ruhe, i suspect there should be 'Application Deployment'... but seems it doesn't matter anyway )
17:24:19 <ruhe> #endvote
17:24:20 <openstack> Voted on "How should we name 'Application being deployed/configured in an Environment'?" Results are
17:24:21 <openstack> Application (1): igormarnat_
17:24:22 <openstack> Component (5): dteselkin_, tsufiev_, sjmc7, ativelkov, sergmelikyan
17:24:39 <slagun> my option is missing. And there are components and there are applications. Components are not applications and applications are not components
17:24:54 <katyafervent2> I missed vote :)
17:25:13 <ativelkov> Applications are components of composed environments
17:25:15 <ruhe> katyafervent2: the result of the vote is clear anyway
17:25:17 <ruhe> #info How should we name 'Application being deployed/configured in an Environment'? Answer: Component
17:25:17 <igormarnat_> Anyway, seems component won, so
17:25:22 <ativelkov> composite*
17:25:23 <ruhe> let's move on
17:25:25 <sjmc7> we can stick with the vote for now and do it again another day? :)
17:25:27 <slagun> If you call MySQL a component that would not make sense
17:25:53 <ruhe> sjmc7: sure, anyone can bring this vote on every meeting :)
17:25:57 <ruhe> #topic Drafting plan for the next release cycle
17:26:22 <ruhe> so, we have a bunch of blueprints and valuable feedback from sjmc7 and his team
17:26:33 <ativelkov> We hame like 35 minutes left, I guess we will not make it ) But let's just do a first part
17:26:44 <ruhe> i guess we can walk through each item and discuss it from high-level perspective
17:26:59 <sjmc7> ok, ruhe. i've tried to include blueprint links where applicable
17:27:35 <ruhe> my goal - is to have an understanding if each of this features is applicable to murano and where BPs can be extended with more details
17:27:40 <ruhe> #link https://blueprints.launchpad.net/murano/+spec/packages-without-classes
17:28:18 <sjmc7> ruhe - you want me to give explanation? or people ask questions?
17:28:46 <ruhe> sjmc7: we discussed this list during the day. i guess people might have questions
17:28:52 <sjmc7> shoot
17:28:59 <ruhe> ativelkov, sergmelikyan: what's your feedback on this one?
17:29:01 <igormarnat_> ruhe: I have one more goal
17:29:15 <igormarnat_> We also need to discuss an approach to tosca
17:29:16 <ativelkov> So, this eventually suggests us to store kinda "hyperlinks" in the catalog, right?
17:29:33 <sjmc7> ativelkov - yes
17:29:46 <sjmc7> but also allow API intergration
17:29:54 <ruhe> igormarnat_: that's a very good goal
17:29:56 <sjmc7> with services outside of a stack
17:30:02 <ruhe> igormarnat_: i support it
17:30:19 <ativelkov> This worries me a little as this slightly blurs our mission: we want to be an application catalog for OpenStack, and hyperlinks are not applications :)
17:30:48 <sjmc7> true :)  the links are to applications which are, for the most part, running in other clouds
17:30:50 <ankurrr> perhaps we could include a way to turn it on and off
17:31:08 <gokrokve> ativelkov: There was an idea to work with trove and other servises and expose apps provisioned by other services.
17:31:22 <ativelkov> gokrokve: that is different
17:31:46 <ruhe> gokrokve: that is covered in https://blueprints.launchpad.net/murano/+spec/call-api-from-workflows
17:31:51 <ativelkov> that idea suggest to have a runnable code (MuranoPL, TOSCA etc) to run the interaction with that services
17:32:27 <ativelkov> But this suggests just to have a catalog records without anything runnable underneath
17:32:30 <sjmc7> the longer term goal is to integrate those kinds of catalog listings in the same way
17:32:44 <slagun> Having packages without classes looks a little bit like an attempt to turn Murano into advertising network
17:32:46 <ativelkov> I understand the reasons for that
17:32:52 <tsufiev_> ativelkov, the main point i see here is to have an Application package which hasn't 'deploy' interface - so it cannot be added to any environment
17:33:08 <ativelkov> tsufiev_: This is perfectly fine techically
17:33:16 <ruhe> my view on this BP - it has a real-world use-case, so we need to have it. realworld use-cases should drive OpenStack projects
17:33:31 <sergmelikyan> I am not sure how correctly implement this blueprint, but I grok this use-case and agree that this is valuable.  I don't know for now, how to implement this without hard-coding this feature to all Murano components. I am not sure that new 'package type' is a valid extension point.
17:33:33 <ativelkov> Actually, I believe that the "Deploy" button should be dynamic anyway
17:33:50 <tsufiev_> ativelkov, yes, i understand, that your concern here is more conceptual than technical
17:34:12 <sjmc7> i agree this is a conceptual argument. on the other hand, what goes INTO a catalog is the responsibility of an admin
17:34:16 <tsufiev_> it's not 'how?' but rather 'why?'
17:34:25 <sjmc7> so the functionality being present doesn't necessarily mean it must be used
17:34:32 <ativelkov> I.e. when the user looks to the app details, the UI makes a call to the API which will tell if the application can be deployed
17:34:44 <ativelkov> And the logic which makes this decision may be quite different
17:34:54 <ativelkov> It actually may be even MuranoPL-code!
17:35:06 <sergmelikyan> I think we can discuss technical implementation a little bit more, but not on this meeting. I see that all core members agree that this is valuable feature
17:35:08 <ativelkov> For such "links" this logic will simply return "false" )
17:35:25 <sjmc7> i'm happy to argue this one later if there are still people who don't feel comfortable with it
17:35:26 <sergmelikyan> And we can plan to have this in near feature/
17:35:29 <ativelkov> I think we just need to pick a proper terminology here
17:35:54 <ativelkov> We just need to call this smth like "external applications" or something like that
17:36:09 <sjmc7> ativelkov - yes, i agree we'll need a different name
17:36:12 <ativelkov> to keep our catalog full of applications and nothing else)
17:36:13 <gokrokve> What will be the action when user ads such hyperlink app to the environment?
17:36:18 <ruhe> ativelkov: how would you answer this question "If you forget about technical implementation. Would you like to see this feature in Murano?"
17:36:43 <ativelkov> gokrokve: there will be no way to add it. There will be just info box
17:36:45 <sjmc7> gokrokve - you wouldn't add it to an environment
17:36:46 <tsufiev_> gokrokve, nothing should happen :)
17:37:14 <gokrokve> it sounds strange :-)
17:37:14 <ativelkov> ruhe: let me be precise: I am ok if we add it )
17:38:06 <ruhe> so, it seems like almost everybody is ok with this feature. but we need more discussions about actual implementation. agree?
17:38:20 <tsufiev_> also, we can regulate with AppCatalog preferences, whether such 'Apps' should be shown or not
17:38:47 <ativelkov> The idea behind this may be much bigger: say, "The current version of the Application is external, so please follow the external link to deploy it... BUT we are likely to make it deployable in future"
17:39:20 <tsufiev_> ativelkov, +1
17:39:27 <sjmc7> ativelkov - yes, in some cases, there may be multiple possibilities (deploy yourself, use a third-party cloud service)
17:39:28 <ativelkov> So this may be thought of as a placeholder in the catalog
17:39:46 <tsufiev_> 'Future App' :)
17:39:50 <tsufiev_> or 'Promise'
17:40:05 <ativelkov> Good. Seems like we are in agreement
17:40:20 <ruhe> sjmc7: i guess you can start drafting a document with high-level implementation details
17:40:20 <ativelkov> ruhe, please go on
17:40:28 <sjmc7> ok ruhe
17:40:45 <ruhe> the next one is "credentials store"
17:40:47 <ruhe> #link https://blueprints.launchpad.net/murano/+spec/3rd-party-credential-storage
17:40:47 <sjmc7> the next one is a later extensiopn of this
17:40:56 <sjmc7> we could possibly skip this in the interests of time
17:41:26 <ruhe> barbican is was comes to my mind when we speak about "credentials storage"
17:41:30 <sjmc7> ruhe - agreed
17:41:31 <ruhe> *is what
17:41:57 <sjmc7> this one may be as simple as a call to barbican
17:42:17 <ruhe> sergmelikyan: ativelkov: tsufiev_: any comments on this one?
17:42:29 <tsufiev_> nope
17:42:31 <ativelkov> There are two options here
17:42:40 <ativelkov> 1) store predefined credentials
17:42:47 <ativelkov> Then it is Barbican
17:43:01 <ativelkov> 2) Generate a credential pair during the deployment
17:43:12 <sjmc7> i'm thinking 1) for this, ativelkov
17:43:18 <sjmc7> for our specific use case
17:43:30 <sjmc7> but being able to get to them from a catalog entry
17:43:32 <ativelkov> Then there should be a barbican client class
17:43:35 <sjmc7> yep
17:43:49 <ativelkov> From MuranoPL point of view it is an easy deal
17:43:49 <sjmc7> so technically i think this one is very simple
17:44:06 <ativelkov> Yes, while we are still on MuranoPL.
17:44:17 <sergmelikyan> First one may be also a wrapper around Barbican to provide to the applications data in specific format. For example set of credentials for sendgrid raise then a generic secret from barbica
17:44:37 <ativelkov> Yes, but that are impl details already
17:44:44 <ativelkov> I believe we agree that the feature is needed
17:45:19 <ativelkov> I just want to point that we need to keep compatibility in mind and not to add anything which will not be possible to implment with TOSCA
17:45:58 <ruhe> ativelkov: TOSCA is just a way to describe application. i think it should be feasible in TOSCA too
17:46:11 <ruhe> but, let's move on
17:46:12 <ruhe> #info we need https://blueprints.launchpad.net/murano/+spec/3rd-party-credential-storage ; barbican seems like a perfect fit
17:46:19 <sjmc7> ok
17:46:30 <ruhe> Additional author/supplier information
17:46:33 <ruhe> #link https://blueprints.launchpad.net/murano/+spec/additional-author-information
17:46:47 <sjmc7> this will involve probably a DB model and some UI work
17:47:00 <ativelkov> Yes, but I want to clarify
17:47:01 <sjmc7> does not affect workflow
17:47:03 <sjmc7> sure
17:47:37 <ativelkov> So, this "supplier" is not the package author, it is more like "the author of the packaged software", right?
17:48:12 <sjmc7> ativelkov - yeah, that's a reasonable way to look at it
17:48:12 <tsufiev_> the idea that we need to change DB model for each such UI change seems a bit awkward to me
17:48:13 <gokrokve> Also I think it will be great to think about app package signature verification.
17:48:32 <ativelkov> gokrokve: very good point, I wanted to say exactly this
17:48:37 <sjmc7> tsufiev_ - a supplier may apply to multiple packages
17:48:41 <tsufiev_> so we could think in direction of making DB model more flexible
17:48:52 <ativelkov> We had a plan to introduce a concept of package signing
17:49:03 <gokrokve> cool
17:49:14 <tsufiev_> sjmc7, yes, i understand... i agree that some db entity is needed...
17:49:19 <ativelkov> like, the author signs the package using PGP or some similar technology, and the catalog verifies the signature
17:49:21 <sergmelikyan> It is very valuable, and ativelkov you had great example about this information from books management software - author name may be written differently in the package but should point to details about same author.
17:49:25 <sjmc7> ok. again, we can discuss technical details perhaps later
17:50:05 <ativelkov> Yes, I agree that the feature is needed, but some concepts has to be defined before goint to the design
17:50:14 <sjmc7> agrred
17:50:17 <ruhe> sjmc7: i'd suggest to create and link an etherpad (etherpad.openstack.org) document to each blueprint
17:50:24 <sjmc7> ruhe - yep, sure
17:50:24 <ruhe> that's what we need for all our blueprints
17:50:59 <ruhe> #info agreed to include https://blueprints.launchpad.net/murano/+spec/additional-author-information in the feature list; more technical discussions needed
17:51:06 <ativelkov> because this introduces kind of double authorship, and this may cause confusion when we start implementing other features related to authorship
17:51:12 <ruhe> also i think this one fits into TOSCA
17:51:38 <ativelkov> ruhe: this actually has nothing to do with it as it is just a catalog-related feature
17:51:49 <sjmc7> ativelkov - i'll draw up a design and we can discuss it. and yes, it is catalog only
17:52:03 <ativelkov> sjmc7: sure
17:52:24 <ruhe> ativelkov: TOSCA has something similar to package description format
17:52:26 <ruhe> next one is - Support for contacting 3rd-party APIs https://blueprints.launchpad.net/murano/+spec/call-api-from-workflows
17:52:49 <sjmc7> sergmelikyan already pointed out this was proposed previously
17:52:53 <ativelkov> This was always part of initial design
17:53:01 <sergmelikyan> ruhe how we will integrate our packages with TOSCA packages is another hard questions :(
17:53:09 <ruhe> sergmelikyan: agree
17:53:09 <sjmc7> so consider it a plus 1 for that feature from us
17:53:18 <ruhe> ok, let's move on then
17:53:35 <ruhe> we can jump through the rest of the topics now :)
17:53:47 <ruhe> * Better unit test coverage
17:54:00 <ativelkov> Better is better then worse :)
17:54:02 <ruhe> we can shoot anyone who disagrees with that :)
17:54:10 <sjmc7> :) the reason i added it
17:54:34 <sjmc7> is that there were a number of bugs that would've been easier to fix with tests there, and it will help incubation chances
17:54:37 <sjmc7> not as a criticism
17:54:48 <ativelkov> sjmc7: +100
17:54:57 <ativelkov> we see a lot of regression recently
17:55:00 <ruhe> i hope we'll have all the need infrastructure to build and publish test coverage results
17:55:00 <sjmc7> yes
17:55:12 <ruhe> next one is:
17:55:13 <ruhe> * Permission policies in line with other openstack services (https://blueprints.launchpad.net/murano/+spec/policy-checks-in-api)
17:56:22 <sjmc7> the idea there is that it's an openstack-standard way of defining who can perform certain operations if an admin doesn't like the default
17:56:34 <ativelkov> Yes, this is needed indeed
17:56:54 <ativelkov> But some of the RBAC-related stuff should go to Glance
17:57:07 <ruhe> if there is a standard for this, then i don't see any obstacles
17:57:42 <ativelkov> So, we'll just need to decide what should be done in Murano and what should be Glancy
17:57:58 <sjmc7> ativelkov - yep
17:58:23 <ruhe> next one is:
17:58:24 <ruhe> * User documentation
17:58:28 <ruhe> and it's a must have
17:58:36 <sjmc7> yeah, again, consider it a big +1
17:58:50 <ruhe> the next one is:
17:58:50 <sjmc7> we'd like to be involved with it
17:58:51 <ruhe> * Ceilometer integration
17:59:04 <sjmc7> and again, i think ceilometer  was already proposed (or even done?)
17:59:16 <ativelkov> proposed, yes, not done yet
17:59:23 <ativelkov> ...1 minute, folks )
17:59:23 <sjmc7> so another +1
17:59:25 <ruhe> yeah ceilometer is on the roamdap
17:59:39 <ruhe> but we could have a discussion about current approach to statistics
17:59:49 <sjmc7> last one was some cosmetic UI stuff, we can discuss that separately
17:59:54 <sjmc7> and that's all i had
18:00:26 <ruhe> sjmc7: great list. we can start technical conversations now
18:00:26 <tsufiev_> sjmc7, let's schedule some time for it
18:00:45 <ruhe> also we'll need to map some of these features on TOSCA
18:00:46 <sjmc7> ok. i will create etherpads and my thoughts, and we can go from there
18:01:08 <gokrokve> It's time to finish :-)
18:01:09 <ruhe> last minute
18:01:20 <ruhe> #endmeeting