16:00:12 <adrian_otto> #startmeeting Solum Team Meeting
16:00:13 <openstack> Meeting started Tue Nov 12 16:00:12 2013 UTC and is due to finish in 60 minutes.  The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:16 <openstack> The meeting name has been set to 'solum_team_meeting'
16:00:24 <adrian_otto> #topic Pre-Announcements
16:00:25 <adrian_otto> 1) Roll Call will not need your company affiliation in #openstack-meeting-alt as that is not customary here.
16:00:25 <adrian_otto> You can simply respond with a hello of some sort. Responding at roll call is optional.
16:00:56 <adrian_otto> #topic Roll Call
16:01:05 <adrian_otto> Good morning!
16:01:22 <coolsvap> Hey, Swapnil Kulkarni(coolsvap) here
16:01:36 <gokrokve_> Good morning! Georgy from Mirantis is here
16:01:40 <tomblank> Tom Blankenship, Rackspace
16:01:59 <uri1803> Hi folks, Uri Cohen, GigaSpaces
16:02:24 <jwforres> hi, Jessica Forrester
16:02:29 <claytonc> Clayton Coleman
16:02:47 <paulczar> Paul Czarkowski, Rackspace
16:02:58 <muralia> Murali Allada, Rackspace
16:03:52 <alexheneveld> alex heneveld, cloudsoft
16:04:36 <adrian_otto> would you all like to have an informal ODS retrospective during our open discussion today?
16:05:01 <claytonc> }1
16:05:04 <claytonc> +1
16:05:04 <muralia> Yes.
16:05:18 <uri1803> +1
16:05:23 <danmcp_mtg> Dan McPherson, Red Hat
16:05:25 <alexheneveld> +1
16:05:32 <sapuri> Sandeep Puri, Cisco
16:05:38 <gokrokve_> +1
16:05:41 <Subbu_> Subbu Allamaraju, eBay
16:05:46 <adrian_otto> okay, I will raise that for discussion right before open discussion
16:05:59 <devkulkarni1> Devdatta Kulkarni, Rackspace
16:06:45 <adrian_otto> okay, let's proceed.
16:07:03 <adrian_otto> anyone else may chime in at any time.
16:07:06 <adrian_otto> #topic Review action items from prior meeting
16:07:06 * adrian_otto adrian_otto to create a breakout session index on the wiki (adrian_otto, 16:58:01)
16:07:06 <adrian_otto> Status: completed: https://wiki.openstack.org/wiki/Solum/BreakoutMeetings
16:07:29 <adrian_otto> that was the only action item
16:07:31 <adrian_otto> #topic Announcements
16:07:44 <adrian_otto> 1) Mirantis is joining the Solum team. Please welcome them.
16:08:08 <funzo> welcome!
16:08:18 <muralia> Welcome folks!
16:08:24 <adrian_otto> we have gokrokve_ here with us this morning
16:08:39 <rajdeep> Welcome, even though i am also new!
16:08:45 <coolsvap> Hello!
16:08:45 <gokrokve_> Thank you!
16:08:49 <adrian_otto> rajdeep: welcome!
16:08:56 <gokrokve_> We plan to have more folks from Mirantis here.
16:09:48 <adrian_otto> great!
16:09:49 <Subbu_> adrian_otto: small typo on the wiki - it is referring to #solum channel
16:10:00 <Subbu_> Was that intentional>
16:10:02 <Subbu_> ?
16:10:02 <adrian_otto> oh, my
16:10:09 <adrian_otto> which page is that appearing on?
16:10:15 <Subbu_> https://wiki.openstack.org/wiki/Solum/BreakoutMeetings
16:10:31 <adrian_otto> actually, that's right, those will be in #solum
16:10:46 <noorul> Hello
16:10:57 <tnurlygayanov> Hello )
16:11:03 <Subbu_> k
16:11:04 <adrian_otto> because the #openstack-meeting-alt channel is used for regularly scheduled meetings
16:11:07 <stanlagun> hello :)
16:11:23 <adrian_otto> and I did not want to interfere with any others
16:11:36 <adrian_otto> Subbu_: will taht be okay, do you think?
16:11:56 <Subbu_> makes sense. less conflicts
16:12:12 <adrian_otto> okay, so here is our next announcement:
16:12:17 <adrian_otto> 2) Solum API Deep Dive schedules for this week:
16:12:17 <adrian_otto> PART I: Wednesday 2013-11-13 1:00 PM US/Pacific (2100 UTC)
16:12:17 <adrian_otto> #link http://www.worldtimebuddy.com/?qm=1&lid=8,0,4726206&h=8&date=2013-11-13&sln=13-14
16:12:17 <adrian_otto> PART II: Friday 2013-11-15 1:00 PM US/Pacific (2100 UTC)
16:12:17 <adrian_otto> #link http://www.worldtimebuddy.com/?qm=1&lid=8,0,4726206&h=8&date=2013-11-15&sln=13-14
16:13:02 <rajdeep> looks very asia unfriendly time
16:13:04 <rajdeep> :(
16:13:05 <adrian_otto> as discussed above, these will be in #solum and are intended for those who are interested in this topic to spend more focused time on it
16:13:24 <adrian_otto> the timeslot was selected from a croudsourced poll.
16:13:33 <funzo> adrian_otto: is the plan for the deep dive to do part of it on IRC so folks can participate that aren't in the office?
16:13:34 <adrian_otto> sorry for those of you on the other side of the globe.
16:13:46 <rajdeep> ok np
16:14:06 <adrian_otto> fungi: they are IRC meetings. What did you mean?
16:14:15 <funzo> adrian_otto: didn't realize that
16:14:20 <stanlagun> It is midnight for most of Mirantis folks
16:14:24 <adrian_otto> oh, yes, you can participate by IRC.
16:14:54 <adrian_otto> stanlagun: sorry about that. We secured the timeslots before we knew you would be joining us.
16:15:19 <adrian_otto> we used a tool called Doodle, which we will use again when we select future meeting times.
16:15:41 <adrian_otto> so if you see a link to Doodle anywhere in the ML, be sure to participate in that so we can accommodate your preferences.
16:15:52 <adrian_otto> next announcement...
16:16:12 <adrian_otto> 3) My deepest apologies for the confusion on the meeting time. My calendar emitted a rouge meeting invite.
16:16:12 <adrian_otto> PLEASE *delete* all appearances of "Solum Team Meeting" or "Solum Weekly Meeting" from you calendars. I will find a way to start fresh.
16:16:55 <adrian_otto> those of us in attendance already got the right time.
16:17:07 <adrian_otto> so my apologies to those of you reading this from transcripts.
16:17:27 <adrian_otto> okay, next we will move into blueprints
16:17:37 <adrian_otto> I have a few that were carried over from a prior agenda:
16:18:06 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Solum
16:18:22 <adrian_otto> #topic Git Deploy Blueprint
16:18:30 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/git-integration
16:18:43 <adrian_otto> Present child blueprints and identify any ready for approval.
16:18:55 <adrian_otto> (do we actually have anything new on this to discuss)
16:18:57 <adrian_otto> ?
16:19:15 <rajdeep> one question : what if developer is not using git as a source control
16:19:16 <adrian_otto> we also have...
16:19:25 <adrian_otto> rajdeep: good question
16:19:34 <adrian_otto> they will be able to bypass that
16:19:53 <adrian_otto> they will have a few options, including using the REST API directly
16:19:58 <adrian_otto> using a CLI tool
16:20:06 <adrian_otto> using an IDE plugin, or another UI
16:20:12 <noorul> adrian_otto: Is this blueprint taken to mailing list?
16:20:22 <stanlagun> hg? TFS?
16:20:27 <claytonc> there has also been discussion about pluggable source
16:20:31 <claytonc> Git is the initial focus
16:20:32 <adrian_otto> yes, we can discuss this on ML.
16:20:40 <gokrokve_> Will the git commit pass a gerrit review before?
16:20:46 <alexheneveld> did y'all get the chance to discuss this at all in HK?
16:20:53 <claytonc> but the desire would be to abstract that detail to a source provider
16:21:00 <adrian_otto> gokrokve_: we have not discussed that yet, but we might use Gerrit in Solum
16:21:11 <gokrokve_> Is it supposed that there will be some specific development process?
16:21:11 <adrian_otto> Gerrit would host the git repo in that case
16:21:15 <funzo> it would be a good idea to implement a gate, that could be jenkins or gerrit or whatever
16:21:17 <rajdeep> i guess wrapper is a better approach and pluggin git, svn , TFS
16:21:35 <kraman> alexheneveld not everyone was present in HK. A lot of the design discussion will also take place at F2F
16:21:42 <claytonc> funzo: that's a good point - there are probably two source flows: a) pushes to a repo, b) flows from a gate
16:21:58 <sapuri> any review tool (like gerrit) probably should not have tight coupling - more likely an optional coupling
16:22:04 <alexheneveld> k thx adrian_otto - as some of you know my 2p is that this will be easier if we split it into smaller parts
16:22:04 <funzo> claytonc: +1
16:22:06 <claytonc> sapuri: absolutely
16:22:10 <adrian_otto> we have not sorted out how best to support the gating use case
16:22:25 <alexheneveld> code repo and build on one side ... deploy and run on the other
16:22:26 <adrian_otto> but we will certainly allow a deployment artifact to bypass the build and go straight to deployment
16:22:31 <rajdeep> sapuri +1, many enterprise developers find gerrit cumbersone
16:22:37 <adrian_otto> so if you want to run your own Jenkins, you can do that
16:23:27 <kraman> if we keep the seperation clean and just have git invoke REST API when it is ready to push out code. might make it more flexible for other source controls as well
16:23:29 <adrian_otto> we have room for this on the Design Workshop agenda, so we can revisit it then too
16:23:39 <stanlagun> What is gonna be in that git for short-term plans? Python projects? Or do you plan on building C++ apps etc?
16:23:54 <devkulkarni1> kraman: +1
16:24:02 <claytonc> stanlagun: that is intended to be generic
16:24:14 <claytonc> see the language packs discussion in the wiki
16:24:26 <alexheneveld> kraman: +1
16:24:27 <sapuri> kraman: +1
16:24:37 <coolsvap> claytonc: +1
16:25:15 <adrian_otto> I should have mentioned the Design Workshop in the announcements section, sorry. Here is the registration link if you plan to attend in person in San Francisco on Nov 19+20:
16:25:19 <adrian_otto> #link https://www.eventbrite.com/event/9130831563
16:26:28 <alexheneveld> I will be with you all in spirit.
16:26:56 <adrian_otto> we will be in #solum too
16:27:02 <Subbu_> thx for the link
16:27:09 <adrian_otto> and we are discussing how we might also use Google Hangout for some of it
16:27:22 <coolsvap> adrian_otto : +1 :)
16:27:47 <adrian_otto> my understanding is that there are 3 meeting rooms so we can have concurrent meetings
16:27:49 <coolsvap> for #solum & hangout, I will be on lookout for its announcement
16:27:52 <alexheneveld> great
16:28:02 <uri1803_> +1 for hangout
16:28:25 <stanlagun> +1 for hangout too
16:28:45 <noorul> I am trying to understand a use case for DU Count > 1
16:28:52 <adrian_otto> ok, we have a few more blueprints to touch on
16:29:00 <claytonc> noorul: php and python parts of an app
16:29:02 <claytonc> that's one
16:29:05 <gokrokve_> Regarding Jenkins, do you see it inside solum to make actual build or it should be outside?
16:29:07 <claytonc> there was a long ML discussion on that a while back
16:29:17 <adrian_otto> #topic Shell Access Blueprint
16:29:23 <claytonc> noorul: about whether it was a good idea
16:29:26 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/shell-access-to-du
16:29:50 <claytonc> so on ssh key distribution specifically, had a long discussion with adam young at design summit
16:30:15 <claytonc> one concrete point of statement from keystone was that they don't plan on being a key distribution / change management system (even though they might implement ceilometer notifications for credential added / removed)
16:30:35 <claytonc> so an integrator wishing to implement ssh access and distribute keys would need to build something on top of keystone to do that
16:30:42 <adrian_otto> Cloud Keep (barbican) may be a good fir for that
16:30:53 <coolsvap> claytonc : +1
16:30:55 <adrian_otto> s/fir/fit/
16:31:23 <claytonc> adrian_otto: the one integration point that might complicate it is the many to many relationship of keys (user a has 10 keys, user b has 10 keys, they can overlap occassionally for machine system keys)
16:31:37 <claytonc> would be good to talk about barbican on ML or in a breakout related to this topic
16:31:38 <adrian_otto> #link https://github.com/cloudkeep
16:31:48 <funzo> adrian_otto: yeah, I heard folks talking about barbican being the key distribution of choice
16:32:08 <sapuri> claytonc: +1 - on many to many
16:32:12 <adrian_otto> in a nutshell, it's a central place where you can store secrets
16:32:15 <stanlagun> Do you plan to support Windows as well?
16:32:37 <kraman> Same here. barbican was suggested as best way to distribute keys to applications as well. But that will depend on the container APIs to some extent
16:32:37 <funzo> stanlagun: as guests?
16:32:48 <stanlagun> yep
16:33:01 <claytonc> noorul: maybe we should write up examples of multi DU on ML and try to counter example each one (about why it's a bad idea or not)
16:33:01 <alexheneveld> ssh seems like a special case of the need to expose a management interface for DU's in some cases
16:33:04 <funzo> stanlagun: in theory if using instances, that would be possible
16:33:12 <adrian_otto> stanlagun: it's not explicitly mentioned as a goal, but language agnostic is. I see no reason why Windows could not be supported if there were a language pack for it.
16:33:30 <claytonc> alexheneveld: good point - there are operations above and beyond ssh
16:33:48 <alexheneveld> (and also for services) -- many will have a management dashboard for which barbican (or similar) would make sense for credential mgmt
16:33:49 <claytonc> however SSH typically has specific key authorization needs that you can avoid via other management points - i think the key aspect is what makes it special
16:34:11 <Subbu_> interesting discussion about windows - it further lowers the common denominator :)
16:34:12 <kraman> alexheneveld: on openshift its used a lot during development and some during production to be able to log in and see what the processes are actually doing. cant run strace etc without shell access
16:34:19 <adrian_otto> so do we have a desire to break this BP up into more child BP's that we can assign as work items?
16:34:36 <stanlagun> This depends on overall architecture. Window might be very different. No SSH connectivity, np GNU toolstack etc
16:34:42 <alexheneveld> +1 claytonc - nice if user can supply a public key / credential where that is possible
16:34:48 <gokrokve_> What about HTTPS\CLI option? It is mentioned in BP.
16:34:57 <funzo> stanlagun: definitely more complicated issues to think about re containers
16:35:31 <alexheneveld> i'd like to make sure what we build doesn't rule windows out -- but do any of us want to endure that pain now :)
16:35:59 * funzo slowly takes one baby step back.
16:36:02 <stanlagun> Well you can never be sure until you try one
16:36:19 <adrian_otto> my guidance on this is to keep windows in mind, and focus initially on the language types that will run on *nix
16:36:20 <claytonc> alexheneveld: stanlagun a good way to think about it is that we should allow the mechanism by which you deploy to be plugged enough so that you can pass the appropriate info to start a windows instance and configure it
16:36:32 <claytonc> (via heat)
16:36:44 <claytonc> what adrian said
16:37:01 <funzo> +1
16:37:13 <stanlagun> Windows is where all of your futures would be most interesting because there are not many solutions for that OS. If you can handle windows Linux wouldn't going to be a problem either
16:37:13 <adrian_otto> and we should consider windows compat as a key criteria when evaluating options for the design
16:37:15 <alexheneveld> kraman: absolutely we must be able to set up ssh access for many DU's.  (though there could be some where it isn't ... e.g. if it's running in a multi-tenant JVM or OSGi framework...)
16:37:44 <adrian_otto> not necessarily implementing both tracks.
16:37:46 <claytonc> alexheneveld: kraman possibly DU's have a set of capabilities that are intrinsic to what they are (containers, multitenant jvm, windows)
16:37:49 <alexheneveld> i'm just saying we want to be able to expose *other* types of management endpoints which will also require credential mgmt
16:38:08 <adrian_otto> alexheneveld: indeed
16:38:30 <adrian_otto> ok, let's proceed to our next BP
16:38:39 <adrian_otto> #topic WSGI Framework Discussion
16:38:39 <adrian_otto> Pecan+WSME vs. Falcon
16:38:47 <tnurlygayanov> how user will connect to the different instances via ssh? only one session for one host?
16:38:47 <adrian_otto> #link https://review.openstack.org/#q,topic:bp/rest-api-base,n,z
16:38:52 <kraman> alexheneveld yes, ssh or just shell access seup should be optional and up to cloud provider
16:39:30 <kraman> tnurlygayanov: that needs to be worked out still
16:39:41 <alexheneveld> yep - a bunch of different capabilities of various types of {DU's, lang packs, services, kumquats}
16:40:25 <stanlagun> thats why I mentioned Windows in the first place as there is no SSH there
16:40:27 <adrian_otto> ok, I offered this guidance last week: http://lists.openstack.org/pipermail/openstack-dev/2013-November/018430.html
16:40:55 <muralia> adrian_otto: Have we decided to go with Pecan+WSME? What were some of the discussions you had with others at the summit in this regard?
16:41:00 <rajdeep> supporting multiple OS will complicate things a lot
16:41:02 <adrian_otto> I am seeking input on Falcon, as I have suggested we proceed with Pecan+WSME
16:41:05 <funzo> adrian_otto: so are we just going with falcon if that's what's in the patch
16:41:09 <rajdeep> not sure how man paas can do that today
16:41:11 <funzo> ah
16:41:26 <adrian_otto> look at the review topic linked above
16:41:39 <adrian_otto> we have a patch for Falcon, and another for Pecan+WSME
16:42:02 <adrian_otto> at: https://review.openstack.org/#q,topic:bp/rest-api-base,n,z
16:42:17 <funzo> i see
16:43:12 <muralia> I'd like to hear more about the discussions that were had with the community around Falcon vs Pecan+wsme at the summit
16:43:56 <sapuri> adrian_otto: no opinion on either, i like your suggestion in the mailing list that, we should pick what other openstack projects are using, as a starting point
16:44:21 <kraman> muralia: most projects are switching or are planning to switch to Pecan+WSME
16:44:30 <adrian_otto> I discussed it at length with Kurt Griffiths,
16:44:41 <adrian_otto> who is a key contributor to Falcon
16:45:15 <claytonc> the documentation angle and the separation of API abstraction slightly from the underlying domain model abstraction were the factors that convinced me that pecan+wsme was the better choice for a general, control-plane API.
16:45:29 <adrian_otto> and a number of PTL's on OpenStack projects
16:45:53 <kraman> claytonc: +1
16:45:57 <adrian_otto> Jay Pipes has good criticisms of Webob and WSME
16:46:18 <stanlagun> Pecan (0.3.2)  7,111 req/sec Falcon (0.1.7) with Cython (0.19.1) - 52,858  req/sec according to off site
16:46:25 <adrian_otto> I also sourced input from Clayton, and others from RH
16:47:14 <adrian_otto> stanlagun: I see that performance difference as acceptable, from the perspective of a large scale cloud operator.
16:47:31 <adrian_otto> control plane API's just don't see request rates that high
16:47:44 <alexheneveld> everyone seems in violent agreement, but for the order of magnitude difference wrt pecan
16:47:57 <adrian_otto> and if they are, that means you have a service with a ton of usage, and can use horizontal scale out to address it
16:47:57 <claytonc> as a practical example, in openshift we see control plane traffic that is roughly 1-2 req/sec per ten thousand active applications
16:48:28 <alexheneveld> however +1 adrian_otto claytonc -- for the requests this will be handling raw throughput is less important than maintainability
16:48:31 <claytonc> scale that up to ten million active active applications you're talking 1k req/s which is achievable using tens of python servers
16:48:37 <adrian_otto> claytonc: we see similar use patterns in our existing systems that offer Web UI capability
16:48:43 <muralia> I personally find falcon to be easier to use and less bulky. But I do buy into the separation of domain and api models. Performance is not really the issue.
16:49:23 <alexheneveld> the higher throughput might be needed for the language pack, but falcon could still be used in language pack
16:49:50 <kraman> adrian_otto: Webob used the be a problem but no longer an issue based on discussions during summit.
16:50:02 <stanlagun> agree. I also would like Pecan more. The only concern with performance here is it is good to have common approach for all projects and for some of them performance can be an issue
16:50:05 <adrian_otto> in the absence of any new key drawback, I wold like to mark a decision in the direction of Pecan+WSME, and revisit it as needed. If it turns out that we have a real performance concern at some point, we can evaluate a tear out of Pecan+WSME, or other optimization options.
16:50:10 <kraman> alexheneveld: the language packs can use any api or language they wish. doesnt have to be the same as solum
16:50:43 <Subbu_> As long as the control plane is stateless, and gets zero traffic from running hosts, we can handle. We had issues some OpenStack components like neutro which get traffic from data plane.
16:50:44 <alexheneveld> kraman: +1
16:50:50 <alexheneveld> adrian_otto: +1 ... enough talk
16:50:54 <adrian_otto> any objections prior to advancing the topic?
16:50:59 <coolsvap> adrian, kamran : +1
16:51:03 <claytonc> +1
16:51:06 <tomblank> +1
16:51:10 <stanlagun> +1
16:51:10 <muralia> +1
16:51:14 <kraman> +1
16:51:19 <claytonc> Subbu_: would recommend that data plane traffic into solum be a separate scalable component anyway
16:51:19 <RRaj> +1
16:51:19 <funzo> doit
16:51:32 <adrian_otto> #agreed we will use Pecan+WSME as the WSGI Framework for solum, to be revisited as-needed.
16:51:39 <claytonc> that's a good addendum to adrian's comment - pecan is for control plane traffic
16:52:00 <adrian_otto> claytonc: agreed 100%
16:52:16 <adrian_otto> #topic ODS Retrospective
16:52:32 <adrian_otto> The HKG summit was full of a lot of energy
16:53:20 <RRaj> Missed the summit - was there Solum discussion/session?
16:53:23 <adrian_otto> about 99% of it toward Solum was positive. I expected more controversy. It seems that random bloggers have more criticisms than the core of the OpenStack community.
16:53:34 <adrian_otto> oh, in summary of events:
16:53:44 <adrian_otto> I had a Lightning Talk on day 1
16:53:53 <adrian_otto> Unconference sessions on Day 2 and 3
16:54:03 <RRaj> Nice
16:54:04 <adrian_otto> a Panel on Day 1 where Solum came up a bit
16:54:25 <adrian_otto> and an Panel on Day 4
16:54:36 <claytonc> the best piece of criticism I heard was about whether Solum inside OpenStack drives people out of openstack or brings them in (relating this back to heat discussions that occurred previously).  My argument there was that we are growing the space of potential people who can be involved in openstack (language authors, development tool frameworks, CI/CD, containers) more than we are hurting
16:54:39 <kraman> We also had a design session on Container support on day 4
16:54:42 <noorul> http://www.forbes.com/sites/benkepes/2013/11/04/breaking-sorry-rackspace-et-al-ubuntu-to-offer-openstack-hosted-cloudfoundry-based-paas/
16:54:42 <adrian_otto> it was mentioned in the RedHat keynote
16:54:57 <noorul> I saw that the other day
16:55:12 <adrian_otto> I see all the Cloud Foundry buzz as irrelevant
16:55:47 <alexheneveld> i do not think the bloggers are "random" ... everyone has their agenda #ignore
16:55:51 <adrian_otto> the question really is about will Solum have the support it needs from community contributors to make it a valuable addition to the OpenStack ecosystem
16:56:13 <adrian_otto> and that's clearly a yes.
16:56:34 <adrian_otto> there was one question that Clint Byrum raised in the Friday panel
16:56:38 <Subbu_> running code
16:56:40 <sapuri> adrian_otto: +1
16:56:42 <claytonc> adrian_otto: that's what I was referring to above
16:56:50 <coolsvap> adrian: I agree, have seen a lot of community interest in Solum in ODS
16:56:55 <adrian_otto> about Heat being a disruptive force, and that Solum may also be disruptive
16:57:02 <rajdeep> i had one question on messaging layer
16:57:16 <adrian_otto> upon reflection, I did think of a better response
16:57:31 <adrian_otto> that disruptive forces generally result in an overall improvement
16:57:39 <adrian_otto> but can cause short term setbacks
16:58:12 <adrian_otto> the long term gain is a certainty in my mind. Developers will become more productive using cloud technology when our vision is achieved.
16:58:23 <claytonc> i'd also make the point that up until now openstack has focused mostly on administration and resource allocation - but IT is larger than it.  I see openstack as helping IT organizations deliver value to their companies, and application lifecycle is a huge component of that
16:58:23 <adrian_otto> and that's a good thing.
16:58:33 <alexheneveld> on that note adrian_otto open source is a huge disruptor ... typically decimates a market when there is an open source solution
16:58:39 <alexheneveld> but is ultimately a good thing (imho :) )
16:58:39 <adrian_otto> I need to hit on open discussion too
16:58:44 <adrian_otto> as we are running low on time
16:58:50 <adrian_otto> #topic Open Discussion
16:59:15 <noorul> adrian_otto: Is this still worked on http://lists.solum.io/pipermail/solum/2013-October/000130.html ?
16:59:26 <alexheneveld> rajdeep: messaging?
16:59:33 <alexheneveld> (or take to ML)
16:59:44 <rajdeep> ok i will ask there
16:59:52 <adrian_otto> noorul: I will need an update from Roshan on that one.
17:00:07 <adrian_otto> I think that task is still pending
17:00:15 <kraman> If anyone is interested in looking at what it will take to better integrate containers into Nova (or perhaps create a new service), please add your email to https://etherpad.openstack.org/p/docker-nova-hkg around line 70
17:00:17 <adrian_otto> #endmeeting