16:05:14 <adrian_otto> #startmeeting Solum Team Meeting
16:05:14 <alcabrera> o/
16:05:14 <openstack> Meeting started Tue Apr  1 16:05:14 2014 UTC and is due to finish in 60 minutes.  The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:05:17 <openstack> The meeting name has been set to 'solum_team_meeting'
16:05:21 <vkmc> Thanks!
16:05:26 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Solum Our Agenda
16:05:34 <adrian_otto> #topic Roll Call
16:05:35 <funzo> o/
16:05:41 <muralia> murali
16:05:45 <stannie> Pierre Padrixe
16:05:45 <tomblank> tom blankenship
16:05:45 <aratim> Arati Mahimane
16:05:46 <adrian_otto> Adrain otto
16:05:51 <funzo> Chris Alfonso
16:05:51 <dmitryme> o/ Dmitry Mescheryakov
16:05:52 <gokrokve> Georgy Okrokvertskhov
16:05:52 <julienvey> Julien Vey
16:05:52 <noorul> Noorul Islam K M
16:05:53 <devkulkarni> Devdatta
16:06:32 <gpilz> Gilbert Pilz
16:07:00 <datsun180b> Ed Cranford
16:07:33 <adrian_otto> Welcome everyone. Feel free to chime in at any time if you have not already to be recorded in attendance.
16:07:42 <adrian_otto> #topic Announcements
16:08:13 <adrian_otto> thanks for a great face-to-face meeting in Raleigh. I'd like to extend special thanks to our co-contributors at RedHat for hosting us.
16:08:52 <adrian_otto> any other announcements from other attendees today?
16:09:24 <adrian_otto> #topic Review Action Items
16:09:34 <adrian_otto> adrian_otto to locate Nova blueprints/reviews on libvirt driver support for Docker
16:10:05 <adrian_otto> I tracked down a lot of information on this. It appears that Docker's current focus is on the Heat Provider for Docker
16:10:37 <adrian_otto> the Nova driver is now in Stackforge, and may be re-introduced into Nova when it meets the testing expectations set for virtualization drivers.
16:10:53 <adrian_otto> we looked into the LXC driver, and found that it is not working out of the box
16:11:07 <funzo> adrian_otto: does that mean the viewpoint of not putting it in nova has changed?
16:11:10 <adrian_otto> our current preferred approach is to use the Docker Nova Driver from Stackforge
16:11:23 <adrian_otto> funzo: good question.
16:11:39 <adrian_otto> I plan to publish a wiki page this week that illustrates why this is our preferred approach
16:11:54 <adrian_otto> it eliminates a lot of complexity with respect to handling Docker on the system side
16:12:00 <funzo> I've heard two perspectives. One from russellb and dan smith that it shouldn't be in nova and then the other of putting in nova. not sure where it landed
16:12:22 <adrian_otto> long term I expect it will be in a dedicated containers service
16:12:32 <funzo> either way, sounds like we have an option to move forward with the heat driver
16:12:41 <adrian_otto> in the mean time, we do have a functional Nova driver
16:13:05 <adrian_otto> and the Heat Provider is a short term alternative if we need features taht Nova is unable to surface because of virt API concerns
16:13:19 <adrian_otto> the bottom line is that nothing is set in stone, adn we have options
16:13:46 <adrian_otto> I learned that the deprecation of the Docker Nova Driver was not an issue about where it belonged
16:13:58 <adrian_otto> but an issue about Nova needing to pass test for the Icehouse release
16:14:07 <russellb> correct
16:14:23 <russellb> we had testing requirements set in place before the docker driver was merged, and the docker driver wasn't able to meet the requirements
16:14:33 <adrian_otto> this will be a topic of conversation in Atlanta where we can debate it constructively
16:14:34 <russellb> so it's in a separate repo while the driver gets worked on, and testing put in place
16:14:45 <russellb> we can consider merging it back in to nova in the future, potentially
16:14:46 <funzo> right on, thanks for the info
16:14:57 <adrian_otto> russellb: are the only ones working on that Repo from Docker Inc?
16:15:17 <russellb> requirements referred to: https://wiki.openstack.org/wiki/HypervisorSupportMatrix/DeprecationPlan
16:15:22 <adrian_otto> as I noticed that it's missing documentation as well
16:15:29 <russellb> it's still brand new, so hard to say
16:15:35 <adrian_otto> #link https://wiki.openstack.org/wiki/HypervisorSupportMatrix/DeprecationPlan
16:15:42 <adrian_otto> russellb: thanks!
16:15:50 <russellb> http://git.openstack.org/cgit/stackforge/nova-docker
16:16:02 <adrian_otto> any more thoughts on this before advancing to the next topic?
16:16:07 <russellb> commits so far are just me and eric (from docker)
16:16:29 <adrian_otto> russellb: thanks
16:16:37 <adrian_otto> ok
16:16:41 <adrian_otto> #topic Mission Statement Review
16:16:49 <adrian_otto> #link https://etherpad.openstack.org/p/solum-mission Mission Statement
16:16:52 <russellb> couple other contributors here: https://review.openstack.org/#/q/status:open+project:stackforge/nova-docker,n,z
16:16:57 <adrian_otto> we worked on this together in Raleigh
16:17:27 <adrian_otto> the current direction is to have a program mission statement that's centric to the OpenStack experience for Application Developers
16:17:53 <adrian_otto> and secondary mission statement(s) for projects an initiatives to support that theme of the program
16:18:05 <adrian_otto> that's where we landed after a few hours of discussion
16:19:18 <adrian_otto> I plan to take a pass through the etherpad, and select a few finalists for voting next week
16:19:38 <adrian_otto> does anyone have new ideas to share regarding the mission statement?
16:20:21 <adrian_otto> ok, next...
16:20:26 <adrian_otto> #topic Review Blueprints: https://launchpad.net/solum/+milestone/milestone-1
16:20:43 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/api Solum API (aotto)
16:21:01 <adrian_otto> my understanding is that the APi is feature complete, with no outstanding defects.
16:21:18 <adrian_otto> does anyone have thoughts or concerns on this one?
16:22:00 <adrian_otto> any objections to marking this as complete?
16:22:53 <adrian_otto> ok, that is now marked as Implemented
16:23:03 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/solum-minimal-cli Command Line Interface for Solum (devdatta-kulkarni)
16:23:18 <devkulkarni> This one also is complete. I will let muralia, stannie talk about it more
16:23:37 <muralia> Yes, it is complete. We are able to create app and assembly
16:23:52 <adrian_otto> ok, that's marked as implemented.
16:23:56 <muralia> there are no blockers on the CLI side for the initial workflow
16:24:01 <gokrokve> By "app" you mean "plan"?
16:24:09 <datsun180b> yes
16:24:15 <muralia> yes, on the cli side its called app/
16:24:23 <gokrokve> Cool.
16:24:36 <stannie> nothing more to add, CLI can be marked as implemented
16:24:43 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/solum-git-pull Pull integration of Solum from an external Git repo (kraman)
16:24:57 <devkulkarni> This one is still being worked on. aratim has the latest..
16:25:28 <devkulkarni> aratim.. any updates from your side on this?
16:25:39 <julienvey> just need to plug the trigger part to the worker part
16:25:40 <adrian_otto> it's in review, correct?
16:25:48 <devkulkarni> yes. it is in review.
16:26:09 <adrian_otto> is there any featurese that is not already submitted for review that is needed for M1?
16:26:10 <devkulkarni> julienvey: cool. thanks.
16:26:35 <julienvey> I don't see the review, do you have a link ?
16:26:36 <devkulkarni> no, everything is either merged or in review.
16:26:43 <adrian_otto> ok, I have marked that as In Review
16:26:47 <datsun180b> all i'm working on is more thorough docs, no code at the moment
16:26:52 <adrian_otto> I think it's actually merged
16:27:06 <devkulkarni> yeah, looks like it is merged
16:27:14 <julienvey> hum
16:27:17 <adrian_otto> #link https://review.openstack.org/#/q/status:open+solum,n,z open reviews
16:27:31 <datsun180b> ^ pin that tab if you use chrome
16:27:40 <julienvey> https://review.openstack.org/#/c/81923/
16:27:44 <aratim> my review got abandoned
16:27:51 <aratim> working on the trigger workflow
16:28:04 <aratim> https://review.openstack.org/#/c/81923/
16:28:21 <adrian_otto> aratim and julienvey: do we need to revive that one?
16:28:44 <julienvey> adrian_otto: yes, it's a simple task
16:28:44 <aratim> yes, I am planning to work on it
16:28:48 <julienvey> aratim: ok
16:28:53 <noorul> It says git push workflow
16:29:37 <julienvey> it is trigger when you do a git push, but it is referenced in solum as the "git pull" workflow
16:29:41 <aratim> It is the workflow which will be triggered when user pushes to git repo
16:29:43 <adrian_otto> git push is out of scope for M1, and pull is in scope
16:29:47 <julienvey> because solum will pull the git repo
16:30:07 <adrian_otto> so this review is in scope, correct julienvey?
16:30:22 <devkulkarni> yes, this is in scope
16:30:28 <julienvey> adrian_otto: yes
16:30:40 <adrian_otto> aratim: can you un-abandon it please?
16:31:02 <aratim> sure
16:31:14 <adrian_otto> tx
16:31:17 <adrian_otto> next one...
16:31:20 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/specify-lang-pack Specify the language pack to be used for app deploy (devdatta-kulkarni)
16:31:41 <devkulkarni> stannie, muralia made great progress on the remaining parts of this
16:31:59 <devkulkarni> stannie, muralia: could you update all on it :)
16:32:17 <muralia> I just pushed a patch for language packs.
16:32:30 <muralia> its currently a non-blocker, as w are using auto in the plan file.
16:32:50 <adrian_otto> https://review.openstack.org/67292 was merged, and that was the one for M1 scope
16:32:51 <stannie> devkulkarni: julienvey added the missing method to POST, PUT, DELETE LP(s)
16:33:01 <muralia> but once my patch gets merged, we'll be able to register new language packs. We need to test it. I think there is some plumbing that needs to be done on the api side
16:33:20 <adrian_otto> so I's it sensible to mark this as Implemented, or should we leave it as in-progress?
16:33:39 <devkulkarni> we can mark it implemented.
16:33:45 <adrian_otto> done
16:33:56 <julienvey> As we discussed at the end of the f2f meeting, I created a blueprint to store LP in glance, but this is out of scope for now
16:33:59 <julienvey> https://blueprints.launchpad.net/solum/+spec/store-language-packs-in-glance
16:34:09 <devkulkarni> julienvey: cool
16:34:14 <adrian_otto> julienvey: excellent!
16:34:29 <adrian_otto> ok, last blueprint for review today:
16:34:30 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/deploy-workflow Workflow outlining deployment of a DU (asalkeld/devdatta-kulkarni)
16:34:38 <devkulkarni> datsun180b should have updates on this..
16:34:57 <datsun180b> well tbh julien's update covered the bases
16:34:58 <devkulkarni> datsun180b: floor is yours :)
16:35:07 <julienvey> stannie and I have a working version of the m1-run through deployment
16:35:16 <julienvey> we fixed the last remaining bugs
16:35:17 <datsun180b> so have i!
16:35:17 <devkulkarni> julienvey, stannie: =1
16:35:20 <devkulkarni> +1
16:35:32 <julienvey> we only tested the nodejs-express plan
16:35:42 <datsun180b> with yesterday's changes merged the 'fiddly bits' i mentioned yesterday seem to have been dissolved properly
16:36:22 <adrian_otto> so it it appropriate to mark this as implmented?
16:36:52 <datsun180b> looking at that bp seems that's exactly what happens
16:37:02 <julienvey> datsun180b: yes
16:37:04 <devkulkarni> yes
16:37:25 <adrian_otto> ok, done
16:37:46 <adrian_otto> I will clean up the remainder of https://launchpad.net/solum/+milestone/milestone-1 today
16:38:10 <noorul> https://review.openstack.org/#/c/84116/
16:38:26 <noorul> Isn't that required for m1 to be complete?
16:38:30 <adrian_otto> a moment of recognition for reaching this point. With some additional docs, we will complete this milestone. Well done everyone!
16:38:45 <devkulkarni> +1
16:38:59 <tomblank> yes, thanks everyone!!  well done...
16:40:03 <adrian_otto> noorul: that is not in the critical path, no. We do want to fix that though, and should have a bug opened for it.
16:40:10 <stannie> noorul: it can work without this fix, since in python code we already removes empty spaces, but it's better to remove empty space from the source sh
16:40:38 <stannie> we managed to get M1 working without this fix with julienvey
16:40:39 <noorul> adrian_otto: stannie ok
16:40:48 <adrian_otto> and just having an open review does not meet my expectations
16:40:58 <adrian_otto> as a review can expire, and we lose sigt of it
16:41:06 <adrian_otto> where a bug will persist until we address the issue
16:41:20 <adrian_otto> s/sigt/sight/
16:41:31 <stannie> but when you see the log when build-app sh is exectuted you see created_glance_id with an empty space which is weird.
16:41:44 <adrian_otto> #action adrian_otto to open a bug for https://review.openstack.org/84116
16:41:45 <stannie> Ok, I am opening the bug adrian_otto
16:42:02 <adrian_otto> stannie, ok, great, thanks
16:42:16 <adrian_otto> next topic
16:42:26 <adrian_otto> #topic Review https://wiki.openstack.org/wiki/UnifiedGuestAgent for use in Solum
16:42:29 <adrian_otto> dmitryme: welcome
16:42:41 <dmitryme> adrian_otto: thank you for introduction
16:42:49 <adrian_otto> #link https://wiki.openstack.org/wiki/UnifiedGuestAgent Unified Guest Agent
16:43:24 <dmitryme> so, the agent is the designed to run on VM and execute commands coming from OpenStack Service
16:43:32 <dmitryme> service like Solum
16:44:03 <noorul> How secure is this?
16:44:15 <dmitryme> the idea is that after you provisioned the app, you probably need to execute commands inside the app
16:44:29 <dmitryme> noorul: security is one of the main concerns
16:44:43 <datsun180b> Trove uses a guest agent model to do things like create databases
16:44:47 <dmitryme> right now the agent is in the design/PoC state
16:45:14 <dmitryme> datsun180b: right, we (Sahara) copied their design initially
16:45:35 <adrian_otto> dmitryme: Are signed payloads contemplated?
16:45:40 <dmitryme> they communicate with the agent via queue: Rabbit or Qpid
16:45:59 <adrian_otto> I did not see any authorization and authentication design discussed
16:46:27 <dmitryme> adrian_otto: regarding authorization, I think last thread covered that a little
16:46:37 <adrian_otto> basically it's a backdoor that can be used for any purpose, which really raises security concern
16:46:43 <dmitryme> right now the main idea is to use Marconi for messaging
16:47:09 <dmitryme> unlike other MQ solutions Marconi has multi-tenancy by design
16:47:26 <dmitryme> multy-tenancy in terms of OpenStack
16:47:52 <adrian_otto> the key question at hand is: Does Solum have a need for a guest agent?
16:47:57 <paulczar> I have concerns about running an agent
16:48:09 <dmitryme> adrian_otto: regarding backdoor, one of the ideas was to permit agent to issue only a limited set of commands
16:48:10 <devkulkarni> dmitryme: what do you need from Solum? specific use-cases? if so, what are the ways for solum folks to contribute these? add to the wiki page/send them to you? is there a working group that meets regularly on this?
16:48:19 <julienvey> adrian_otto: Not right now, I think we should rediscuss it when we need it
16:48:32 <datsun180b> i think the need for an agent depends a lot upon what's running on the instance
16:48:38 <paulczar> it's a bit unusual for the 'application container' concept where you're running a single command in a container rather than a whole OS and its ecosystems
16:48:39 <adrian_otto> we have avoided that approach so far, preferring re-deployment of containers as an alternative to making changes within the guest.
16:48:42 <dmitryme> I had a conversation with Angus yesterday
16:48:52 <dmitryme> he spoke of one of the possible use cases
16:48:58 <datsun180b> and so long as we're focused on stateless services chances i'm not sure about such a need
16:49:10 <dmitryme> let me cite him
16:49:11 <dmitryme> "it might make sense for and app developer to expose some operational commands via the guest, like backup/enable debug"
16:49:12 <adrian_otto> we might use a ceilometer guest to get operational metrics out.
16:50:13 <dmitryme> right now I would like to hear from potential consumers, like Solum, if overall design of RPC over Marconi makes sense for you
16:50:19 <adrian_otto> dmitryme: that's true, that is a valid use case
16:51:09 <dmitryme> my further thinking is to build that RPC on oslo.messaging by implementing Marconi driver for it
16:51:10 <paulczar> backup suggests stateful application,    enable debug would be a change env_variable DEBUG=true,  redeploy
16:51:16 <adrian_otto> dmitryme: do you have additional details about that design for us to consider?
16:51:55 <adrian_otto> paulczar: we may have containers that end up using cinder volumes for stateful apps
16:52:08 <dmitryme> adrian_otto: probably it is a set of operations you would expect from the agent
16:52:16 <adrian_otto> that's not our fist wave of use cases, but we should get there
16:52:32 <paulczar> adrian_otto: I would suggest we use cinder tooling to provide backups for that use case
16:52:58 <adrian_otto> paulczar: I am not suggesting that an agent be offered by default
16:53:00 <paulczar> my preferred approach is that we avoid agent until we hit a use case that absolutely needs it
16:53:07 <dmitryme> say, messaging provides 'cast' (fire and forget) and 'call' (these return result) operations
16:53:10 <noorul> +1
16:53:16 <tomblank> paulczar: +1
16:53:22 <julienvey> paulczar: +1
16:53:27 <adrian_otto> but I can contemplate integration between components with operations that want to interact with a process int he container.
16:53:39 <dmitryme> paulczar: makes sense to me as well
16:54:04 <adrian_otto> dmitryme: let's pause for a poll
16:54:21 <adrian_otto> who would like to revisit guest agents as an option for future consideration?
16:54:35 <adrian_otto> I will vote for that
16:54:36 <adrian_otto> +1
16:54:36 <datsun180b> ++ future
16:54:38 <paulczar> adrian_otto: also if we use LXC or docker then we get opportunities to run things in the container using LXC commands to shell into the container
16:54:39 <noorul> on need basis +1
16:54:45 <muralia> +future.
16:54:51 <paulczar> +1
16:54:53 <gokrokve> +future
16:54:55 <rajdeep> +1 if needed revisit
16:54:56 <devkulkarni> yes, we can discuss it when we really need it
16:55:00 <tomblank> +1 future when we have clear use case(s)
16:55:05 <aratim> +1 future
16:55:21 <adrian_otto> ok, any alternate viewpoints to consider prior to tabling the issue?
16:55:24 <dmitryme> paulczar: did you consider to run Windows apps? It is my understanding that you can not do that with LXC
16:55:56 <paulczar> dmitryme: that's also a 'future' discussion
16:56:10 <adrian_otto> dmitryme: the guest agent is designed for Windows too?
16:56:15 <adrian_otto> the wiki did not mention that.
16:56:18 <dmitryme> paulczar: right, I guess you guys are in the beginning
16:56:21 <paulczar> unless somebody has enough interest in windows to start working on windows integration
16:56:38 <dmitryme> adrian_otto: if it is a python app, then why not?
16:56:56 <adrian_otto> it does not indicate taht it's a python app either
16:57:04 <adrian_otto> I assumed it would be a C++ thing
16:57:42 <dmitryme> adrian_otto: the platform is not fixed
16:57:55 <dmitryme> you can write oslo.messaging agent on any language
16:58:09 <adrian_otto> dmitryme: thanks for including us in the requirements gathering. We will think on this, and reach out to you if we have further guidance.
16:58:27 <dmitryme> adrian_otto: sure, thank you for your attention
16:58:31 <adrian_otto> we can also talk about it in Atlanta
16:58:40 <adrian_otto> #topic Open Discussion
16:59:18 <noorul> Any summary of outcome in Summit?
16:59:30 <julienvey> Angus opened a review for a new version of the API, more 'build-centric', it would be good to have others point of view https://review.openstack.org/#/c/84434/
16:59:49 <dmitryme> regarding Atlanta, I will am not going there, but I will ask my colleague  Ruslan Kamaldinov to talk with people about design and use cases
17:00:11 <adrian_otto> dmitryme: ok
17:00:59 <adrian_otto> noorul: let's follow up in #solum
17:01:03 <adrian_otto> thanks ewveryone
17:01:07 <adrian_otto> everyone
17:01:10 <tomblank> thanks adrian
17:01:13 <adrian_otto> #endmeeting