17:03:15 <ativelkov> #startmeeting murano
17:03:15 <openstack> Meeting started Tue Feb  4 17:03:15 2014 UTC and is due to finish in 60 minutes.  The chair is ativelkov. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:03:19 <openstack> The meeting name has been set to 'murano'
17:03:23 <katyafervent> Hi!
17:03:24 <ativelkov> Hi there
17:03:45 <sergmelikyan> \o/
17:04:04 <ativelkov> Our agenda is here: https://wiki.openstack.org/wiki/Meetings/MuranoAgenda#Agenda
17:05:01 <ativelkov> Also, I'd like to propose two additional items there: I want to touch repo reorganization again, and also we need to discuss the formal core team limits
17:05:31 <ativelkov> So, we have quite a lot of topics to discuss, let's try not to waste the time
17:05:44 <ativelkov> #topic AI review
17:06:05 <ativelkov> stanlagun to update the DSL description according to the implemented PoC
17:06:24 <ativelkov> stanlagun - any updates on that?
17:06:52 <stanlagun> No docs yet
17:07:00 <stanlagun> But I expect them this week
17:07:17 <ativelkov> #info No docs on DSL yet, expect to have them this week
17:07:27 <ativelkov> stan, then this AI remains on you
17:07:34 <stanlagun> yep
17:07:34 <ativelkov> #action stanlagun to update the DSL description according to the implemented PoC
17:07:51 <ativelkov> tnurlygayanov to help stanlagun with DSL Engine & YAML workflow unit tests
17:09:30 <gokrokve_> Hi. We have some idea about explicit events support in DSL.
17:10:05 <gokrokve_> Stan, where is your code? I want to check if I can add this to DSL.
17:10:14 <ativelkov> gokrokve_: let's wait till we start discussing it, just couple of minutes to complete with AIs
17:10:33 <ativelkov> tnurlygayanov - any updates on unit tests for the new DSL engine?
17:11:43 <ativelkov> probably he is away, stanlagun, could you comment on this as well?
17:12:54 <ativelkov> We have missing men )
17:12:54 <igormarnat_> Let's move on then, since folks are out
17:13:00 <stanlagun> I think there is no progress on this. I was budy implementing DSL features
17:13:32 <ativelkov> OK, we need to imrove our testing efforts on this. DSL is a crusial component for our success, it should be well-covered
17:13:47 <stanlagun> agree
17:13:48 <ativelkov> Moving on
17:13:50 <ativelkov> ativelkov to write to ML about repository re-organization
17:13:58 <ativelkov> I did, we've got some valuable feedback
17:14:28 <ativelkov> We need to discuss the technical details of this reorganization, I suggest doing it on today's meeting
17:14:41 <ativelkov> ativelkov to schedule a meeting with Dmitry
17:15:10 <ativelkov> Dmitry stands for Dmitry Meytin here
17:15:24 <ativelkov> Yes, I've scheduled a meeting - it is on the next wednesday,
17:15:27 <igormarnat_> Meeting about repos, or?
17:15:42 <ativelkov> igormarnat_: it is about DSL
17:16:12 <ativelkov> They want to contribute but want to discuss the DSL design first
17:16:22 <igormarnat_> Ok.
17:16:43 <ativelkov> #indo The DSL meeting is scheduled on Feb, 12 on 7 am PST
17:16:55 <ativelkov> We are done with the AI's, I hope
17:17:02 <ativelkov> one remain to be cleared
17:17:11 <ativelkov> #action tnurlygayanov to help stanlagun with DSL Engine & YAML workflow unit tests
17:17:15 <ativelkov> Let's proceed
17:17:29 <ativelkov> #topic Status for release 0.4.1
17:17:42 <ativelkov> katyafervent, could you share an update please?
17:17:53 <katyafervent> ativelkov, sure
17:18:32 <katyafervent> We are testing Floating IP auto-assignment  feature and fixing bugs
17:19:01 <katyafervent> Today we had bug scrub where we described all bugs that are left
17:19:04 <ativelkov> Any ETA?
17:19:32 <ativelkov> bug scrub - for this particular kilestone or a global one?
17:19:32 <katyafervent> We plan to release on the 6th of February as expected
17:19:42 <katyafervent> for a current release
17:19:53 <ativelkov> #info 0.4.1 is on track, release planned for Feb, 6
17:19:57 <katyafervent> but we postpone some for the future
17:20:00 <ativelkov> Good, thanks
17:20:22 <ativelkov> This means that we need to have a full bug triage after we deliver this one
17:20:26 <katyafervent> So now we need to test everything in a hard way :)
17:20:48 <katyafervent> yes, but there are just few bugs left)
17:20:48 <ativelkov> What do you mean by a hard way?
17:21:23 <katyafervent> That we have not a lot of time before release, need to test better
17:21:47 <katyafervent> Any questions?
17:22:04 <ativelkov> It either mean we are very good, or we didn't do enough testing. I hope the former but assume the latter
17:22:34 <ativelkov> No questions, thanks Katya
17:22:37 <igormarnat_> Katya meant we need to test like hell
17:22:55 <ativelkov> #action all test 0.4.1 like hell
17:22:59 <ativelkov> :)
17:23:10 <gokrokve_> We need BTFH.
17:23:17 <ativelkov> BTFH?
17:23:20 <igormarnat_> OMG
17:23:40 <ativelkov> what does it mean?
17:23:58 <ativelkov> googling says "Bastard Technicians from Hell" but I don't want to think what may it mean
17:23:59 <sergmelikyan> OMG
17:24:27 <sergmelikyan> ativelkov, you didn't read that old piece of art?
17:24:36 * sergmelikyan searching for links
17:24:38 <ativelkov> probably not )
17:24:39 <stanlagun> We definitely need Bastard Technicians from Hell
17:25:05 <ativelkov> Cool, in openstack you always have chances to learn something new
17:25:10 <gokrokve_> I meant Tester here
17:25:22 <ativelkov> let's move on, guys )
17:25:24 <sergmelikyan> http://bofh.ntk.net/BOFH/
17:25:45 <ativelkov> #topic Glance activities review
17:25:59 <ativelkov> So, some quick update on this
17:26:45 <ativelkov> #info It was decided that Glance will move towards being an "Artifact repository" usable by other projects - and Murano will store its Application packages there
17:27:19 <igormarnat_> What is the timeframe?
17:27:22 <ativelkov> #info The changes will be made to Glance's V2 API - appropriate additional will be made
17:27:36 <ativelkov> additions*
17:27:42 <ativelkov> So, that is not v3 or something
17:27:51 <ativelkov> igormarnat_: J-release
17:28:30 <ativelkov> #The plan is to have the artifact-repository ready AND actively used by other project by the release time of OpenStack Juno
17:28:53 <ativelkov> Which means that first mvp should be ready at about J1-J2
17:29:02 <ativelkov> so the projects can adopt it
17:29:49 <gokrokve_> We will nedd to submit more granular BP for this work.
17:29:56 <ativelkov> #info the artifact repository will be implemented as pluggable addition to the core glance, so different projects will be have their artifact repository logic implemented as plugins
17:30:15 <gokrokve_> Add data model and DB part. Add BP for API. Add BP for plugin interface.
17:30:18 <ativelkov> #action ativelkov and gokrokve_ to submit more BPs to Glance
17:30:27 <ativelkov> We'll work on this with Gosha
17:31:25 <ativelkov> Meawhile, this timing means that the upcoming releses (0.5 and probably 0.6 or whatever it is called) will have to use our own homemda metadata repo
17:32:04 <ativelkov> This means that we will continue improving our Simplified Metatada Repository - to add new DSL support there, and some simple DB etc
17:32:19 <gokrokve_> Which we can use for prototyping correct interfaces for Glance too.
17:32:28 <igormarnat_> I.e., 0.5 functionality
17:32:29 <ativelkov> "homemda" stands for "home-made"
17:32:37 <ativelkov> igormarnat_: yes
17:33:02 <ativelkov> #info Simplified Metadata Repository to be imporved to support 0.5 and AppCatalog MVP
17:33:42 <igormarnat_> BTW, speaking of MVP
17:33:42 <gokrokve_> Heh. There is an AI on me to defiine MVP requirements. It is still work in progress.
17:33:50 <igormarnat_> Yes
17:33:50 <ativelkov> #action ativelkov to update project roadmap to reflect the metadata repository req's
17:34:02 <igormarnat_> You need tp describe MVP in BPs
17:34:11 <ativelkov> Yes, igormarnat_, that's on me
17:34:46 <katyafervent> we do have bp for MVP, need to extend it
17:34:46 <ativelkov> I have this in more to-do list, there are too much presentation activities right now, have to prioritise that. Will do this week
17:35:59 <ativelkov> #action ativelkov - create more MVP-releated blueprints
17:36:06 <ativelkov> OK, should we move on?
17:36:15 <igormarnat_> ye
17:36:26 <ativelkov> #topic New DSL status
17:36:43 <ativelkov> stanlagun, a quick update please?
17:37:37 <stanlagun> DSL is almost ready. We have working/deploying ActiveDirectory service written on new DSL
17:37:59 <ativelkov> working/deploying means that Heat integration is migrated to the new engine?
17:38:15 <stanlagun> Several important features left before it would be 100% complete
17:38:16 <stanlagun> yes
17:38:30 <stanlagun> It produces correct Heat stack and Agent plans
17:38:38 <igormarnat_> What are the missing features?
17:38:53 <ativelkov> What about advanced networking? Does it use some code from there? Or it just picks a random network to join?
17:39:06 <stanlagun> 1. serialization of results
17:39:30 <stanlagun> 2. Make it not do the whole deployment from scratch every time
17:39:57 <stanlagun> 3. documentation :)
17:40:03 <ativelkov> 4. Unit tests?
17:40:28 <gokrokve_> Stan, is this available somewhere to look at?
17:40:31 <stanlagun> yep. Need to invent how to test YAML scripts as well
17:40:32 <ativelkov> #info DSL is almost ready. We have working/deploying ActiveDirectory service written on new DSL
17:40:57 <stanlagun> No advanced networking as for now
17:41:10 <stanlagun> Basically this is AD that we started Murano with
17:41:12 <ativelkov> gokrokve_: https://github.com/istalker2/MuranoDsl afaik
17:41:14 <gokrokve_> By the way. There is a parallel conversation in #heat about Autoscaling.
17:41:28 <ativelkov> #link https://github.com/istalker2/MuranoDsl
17:41:36 <stanlagun> https://github.com/istalker2/MuranoDsl/blob/master/meta/com.mirantis.murano.services.windows.activeDirectory.ActiveDirectory/manifest.yaml
17:41:36 <gokrokve_> Looks like Icehouse Heat will not include any major changes in resource autoscaling.
17:42:01 <ativelkov> Then this means that we will have to implement Murano-driven autoscaling
17:42:04 <gokrokve_> Sounds like we will need to implement this as a part of Murano DSL, with events support.
17:42:13 <gokrokve_> yep
17:42:16 <ativelkov> We'll be able (hopefully) to trasition to Heat when they are ready
17:42:28 <ativelkov> New DSL engine supports events by design
17:42:46 <ativelkov> Workflow actions are actually event handlers
17:42:48 <gokrokve_> Juno time frame. Sergey M. can actually pick up this BP and start moving it forward.
17:43:09 <gokrokve_> Cool. I definitely should take a look.
17:43:45 <ativelkov> #info Heat is not going to introduce new Autoscaling in Icehouse, need to make a homebrew solution
17:44:10 <ativelkov> gokrokve_: we definetly need to review the new engine
17:45:01 <ativelkov> #topic Dynamic UI to display Service descriptions
17:45:14 <ativelkov> A quick topic I wanted to point your attention to
17:45:33 <ativelkov> There is a new blueprint
17:45:37 <ativelkov> #link http://blueprints.launchpad.net/murano/+spec/dynamic-fields-on-service-details
17:45:59 <ativelkov> I want this thing to be implemented in 0.5
17:46:10 <ativelkov> Need your input on possible implementation ideas
17:46:49 <ativelkov> This is required to simplify MS SQL Cluster deployment from user's perspective
17:46:58 <ativelkov> and probably other apps as well
17:47:23 <ativelkov> Did anybody review this BP?
17:47:26 <katyafervent> That's a good bp
17:47:51 <gokrokve_> By the way, what was a feedback from customer after MSSQL demo?
17:48:00 <gokrokve_> Do they like it?
17:48:42 <ativelkov> Yes, they did. They have rise a number of questions, mostly about supportability (they've asked if we had partnership with MS) and the amount of training required tu support murano and its apps
17:48:59 <ativelkov> (sorry for typos)
17:49:33 <ativelkov> However, there was no formal follow-up from John. Probably we should ping him
17:49:57 <ativelkov> So, about the blueprint
17:50:16 <katyafervent> ativelkov, what do you want to discuss?)
17:50:18 <ativelkov> katyafervent: could you please add your thoughts and suggestions on possible implementations to the BPs whiteboard?
17:50:38 <katyafervent> Ok, I will think about it
17:50:52 <ativelkov> #action katyafervent to comment the blueprint on dynamic service descriptions
17:50:58 <ativelkov> OK, wrapping up
17:51:03 <ativelkov> #topic open discussion
17:51:21 <ativelkov> We have 9 minutes left, and two open topics to discuss
17:51:35 <ativelkov> First is the repository reorganization
17:52:12 <ativelkov> sergmelikyan, the question is mostly to you: do we have any technical problems which prevent us from merging murano-api, murano-conductor and murano-repository into a single git repo?
17:52:57 <sergmelikyan> ativelkov, except no real reason to do it - no. Also, I have doubts about Conductor - since no common code between conductor and API are exist
17:53:52 <sergmelikyan> Merging API & Repository looks like good idea (If they will be rewritten to common framework like Pecan)
17:54:10 <igormarnat_> Did you guys discussed changes in schedule for 0.5 given additional MVP reqs?
17:54:34 <igormarnat_> Are there any?
17:54:35 <ativelkov> sergmelikyan, there were couple of reasons. We may think about API decoupling (as it was suggested in ML), but having a single repo for all the main services looks like a standard practice in openstack
17:54:56 <ativelkov> igormarnat_: we din't discuss yet, but the slight schedule slip is more then likely
17:55:19 <ativelkov> as soon as BPs and roadmap is updated, we'll update the schedule as well
17:56:15 <ativelkov> sergmelikyan, speaking about the common code - some really do exists: the DTOs which are present in murano-common
17:56:21 <sergmelikyan> ativelkov, but I don't agree on maintainability reasons that you was talking about. That is common practice since many projects emerged very early when Zuul was not so powerful. Now adding a new repo really easy and fully automated procedure
17:56:29 <stanlagun> we also would need to be able to run unit tests on several projects in single repo separately. And what is even more important to allow install them on different machnines so that number of API servers != number of repositories
17:57:30 <sergmelikyan> stanlagun, for example API and Repository may be merged in a single Python package, but have 2 different entry-points.
17:57:52 <ativelkov> It looks like we need more disscussion and probably some voting on this topic, as we are not close to any agreement
17:58:17 <sergmelikyan> ativelkov, agree. Sorry, had no time to reply to your mail.
17:58:18 <ativelkov> and we have 3 minutes left, so it is unlikely that we reach one anytime soon :)
17:58:37 <ativelkov> Yes, let's continue the discussion in the ML
17:58:41 <sergmelikyan> Ok
17:58:49 <ativelkov> will return to this topic next time
17:59:20 <ativelkov> #agreed continue to discuss repo reorganization in ML
17:59:31 <ativelkov> Any other urgent issues to discuss?
17:59:47 <igormarnat_> Not from me
17:59:53 <ativelkov> Then thanks everybody for joining
18:00:07 <igormarnat_> TTYL. o/
18:00:08 <ativelkov> A quick announcement for those of you who are in the Bay Area
18:00:19 <ativelkov> We have a meetup tomorrow, will speak about Murano
18:00:35 <ativelkov> http://www.meetup.com/openstack/
18:00:42 <ativelkov> Will be happy to see you there
18:00:44 <ativelkov> thanks
18:00:47 <ativelkov> #endmeeting