22:00:07 <adrian_otto> #startmeeting Solum Team Meeting
22:00:08 <openstack> Meeting started Tue Sep  2 22:00:07 2014 UTC and is due to finish in 60 minutes.  The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:11 <openstack> The meeting name has been set to 'solum_team_meeting'
22:00:14 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2014-09-02_2200_UTC Our Agenda
22:00:20 <adrian_otto> #topic Roll Call
22:00:23 <adrian_otto> Adrian Otto
22:00:28 <dimtruck> Dimitry Ushakov
22:00:30 <datsun180b> Ed Cranford
22:00:32 <muralia> murali allada
22:00:37 <james_li> james li
22:00:43 <gpilz1> Gilbert Pilz
22:00:51 <AnishKarmarkar> Anish Karmarkar
22:00:57 <devkulkarni> Devdatta Kulkarni
22:00:58 <adrian_otto> Anish!
22:01:05 * AnishKarmarkar waves
22:01:40 <adrian_otto> welcome everyone. I'll just wait a moment for a few more of us to arrive.
22:01:47 <Roshan> Roshan Agrawal
22:02:51 <PaulCzar> o/
22:02:51 <roshanagr> Roshan Agrawal
22:03:22 <adrian_otto> okay, let's begin.
22:03:30 <adrian_otto> welcome asalkeld
22:03:38 <adrian_otto> #topic Announcements
22:03:46 <adrian_otto> Any announcements from team members?
22:04:25 <adrian_otto> are any other team members coming to the OpenStack Silicon Valley event on 9/16?
22:04:34 <gpilz1> I will be attending
22:04:46 <adrian_otto> oh, good. I'll see you there.
22:04:51 <adrian_otto> #topic Review Action Items
22:04:54 <adrian_otto> (none)
22:05:00 <adrian_otto> #topic Blueprint/Task Review
22:05:07 <adrian_otto> Does anyone have specific tasks or reviews they would like to discuss with the team today?
22:05:32 <gpilz1> https://review.openstack.org/#/c/117056/
22:05:59 <gpilz1> I need some help figuring out how to fix the flake8/pep8 tests
22:06:12 <gpilz1> AFAICT the failures have nothing to do with my code
22:06:14 <adrian_otto> getting stuck here http://logs.openstack.org/56/117056/4/check/gate-solum-pep8/c3650a6/console.html.gz#_2014-08-29_22_22_10_060
22:06:16 <datsun180b> gpilz1: i can help you with that
22:06:26 <gpilz1> thanks Ed
22:06:33 <datsun180b> we also need to get ravi's private github repo changes in
22:06:38 <adrian_otto> sweet, thanks datsun180b
22:07:11 <datsun180b> most of our problems are zuul jobs are 5 hours old, assumedly because of the demand on the dsvm job resources
22:07:16 <adrian_otto> datsun180b: can you help me document the resolution to gpilz concerns so we can publish it as a developer FAQ?
22:07:28 <datsun180b> adrian_otto: cloning his review now
22:07:28 <adrian_otto> I know that several of us have tripped on that before
22:07:56 <adrian_otto> so it would be nice to have a resource to turn to next time we get snagged on that
22:08:22 <datsun180b> i tried earlier last week to pull the sanity checks out of the pep8 tox environment
22:08:45 <datsun180b> but ravi clued me in on bigger devstack changes i'd need to make, so i backed out because i've got other things cooking
22:09:08 <datsun180b> were we to revisit that, that may relieve some testing/troubleshooting pressure
22:09:36 <datsun180b> pep8 failing because solum.cfg.sample is different doesn't make sense to me
22:10:14 <adrian_otto> tx
22:10:38 <adrian_otto> okay, so which reviews for Ravi's work need additional review work?
22:11:03 <datsun180b> #link https://review.openstack.org/#/c/105605/ is the big one
22:11:05 <adrian_otto> I see two open
22:11:17 <datsun180b> technically we have all the checkmarks we need
22:11:24 <datsun180b> thanks to you in fact
22:11:41 <adrian_otto> ok, so I think we can let the gate system advance taht
22:11:48 <adrian_otto> any others?
22:12:08 <adrian_otto> I'm going to scour that whole open list
22:12:21 <adrian_otto> does anyone ahve open reviews they plan to abandon?
22:12:44 <adrian_otto> apparently now core reviewers have the ability to abandon a patch for you
22:12:58 <PaulCzar> okay,  I need people to re-review this - https://review.openstack.org/#/c/102646/
22:13:21 <adrian_otto> so if we have things that are getting stale, we'll comment on them, arrange for rebase, and if it's not something you care about, abandon
22:13:23 <PaulCzar> I think I addressed all the comments in it ... but it was ages ago and I've since been distracted by other things
22:13:28 <adrian_otto> PaulCzar: ok, looking
22:14:02 <adrian_otto> DIP == DIB in that commit message?
22:14:18 <PaulCzar> oh yeah
22:14:32 <PaulCzar> so there's at least one typo I still need to fix ;)
22:14:40 <datsun180b> you've got red on you
22:14:52 <adrian_otto> so there are a bunch of comments on here
22:15:11 <roshanagr> Are there any downsides to always deploying to Docker, even if it is a VM deployment.
22:15:47 <PaulCzar> roshanagr: it gives us a standard package format ... otherwise we need to do things differently on VMs vs Docker
22:15:55 <adrian_otto> roshanagr: there is a very slight performance penalty to using a container (due to the cgroup and namespace data structures in the kernel), but it should be extremely minimal
22:16:01 <roshanagr> i.e. functionally, would we get to parity with Docker inside VM, when compared to natively inside VM
22:16:33 <roshanagr> PaulCzar: standard package format makes sense , and is good
22:17:08 <roshanagr> Adrian_otto: slight performance penalty should be fine as well. as long as we don't compromize on feature parity
22:17:26 <roshanagr> Feature parity is something I am most concerned about
22:17:31 <adrian_otto> PaulCzar: curious… if someone uses our Dockerfile language pack… can they specify the run arguments to get things like bind mounts, and env variables? I did not think so, but that could potentially be limiting.
22:17:57 <adrian_otto> it's not any more restrictive that a VM, right?
22:18:22 <adrian_otto> but more restrictive than running Docker on your own
22:18:53 <PaulCzar> adrian_otto: correct,  we still launch the docker container, so we choose the args etc
22:19:14 <roshanagr> can I take any VM based workload, and run it inside Docker, without a bunch of rework
22:19:27 <adrian_otto> have we contemplated a way to take "run" arguments in a Pipeline job, or plan file?
22:19:50 <PaulCzar> adrian_otto:  yeah,  with a custom heat template they could add run arguments to docker-in-VM
22:20:02 <PaulCzar> which we wouldn't give them on nova-docker because of trust etc
22:20:17 <adrian_otto> roshanagr: bundling the app is required. So instead of bundling into an OS specific packaging format, you are bundling into a Docker container image
22:20:22 <PaulCzar> roshanagr: what do you even mean by a VM workload?
22:20:53 <roshanagr> lets say I have a chef cookbook that runs inside a VM. will it just work inside a docker image
22:20:56 <adrian_otto> Solum helps automate this, but if you want something exotic to happen on startup, that could be a constraint, hence my question about runtime args
22:21:12 <adrian_otto> roshanagr: yes, it should
22:21:45 <adrian_otto> provided you extend a base image where the chef utilities can run
22:21:48 <PaulCzar> roshanagr: in theory yes ... in practice not 100%.   but a chef cookbook isn't an application,  so would solum even run it ?
22:22:45 <adrian_otto> PaulCzar: which things are you thinking of when you refer to "in practice" above?
22:22:46 <roshanagr> PaulCzar: you are right, we won't run Chef in the runtime.
22:24:06 <roshanagr> +1 to adrian_otto's question
22:24:10 <PaulCzar> adrian_otto: if the chef cookbook tries to do something with services ( containers don't have a pid 1 )  or tries to work with devices or other things that namespaces doesn't allow inside the container then it will fail
22:24:41 <PaulCzar> but if we don't plan to run chef in the runtime,  then the question is moot
22:24:44 <adrian_otto> so in other words if the recipe tries to do something stupid
22:25:13 <adrian_otto> well
22:25:16 <adrian_otto> come to think of it
22:25:21 <PaulCzar> it comes down to the fact that chef cookbooks and solum do the same job ...   describe the infrastructure to run an application
22:25:22 <asalkeld> starting a service is not really stupid
22:25:27 <adrian_otto> things like sysctl will not work
22:25:42 <adrian_otto> depending on the distribution, so that's a legitimate concern
22:26:03 <adrian_otto> asalkeld: agreed
22:26:48 <asalkeld> I use supervisord, but not easy to translate init scripts
22:26:57 <roshanagr> I have another concern: how will windoes support work if we took the current approach
22:27:03 <roshanagr> windows
22:27:05 <adrian_otto> roshanagr: did this provide clarity, or did it make matters even more murky?
22:27:11 <PaulCzar> roshanagr: support for windows is just as hard either way
22:28:15 <adrian_otto> approximating container functionality in windows will require special handling regardless. I agree with PaulCzar on that for sure.
22:28:27 <roshanagr> adrian_otto: I am unclear if the current implementation approach (Docker inside VM) is going to impose any restrictions. + we need to plan for Windows
22:28:40 <roshanagr> windows without containers may not be as hard
22:28:54 <roshanagr> Windows VM, no containers.
22:29:09 <PaulCzar> roshanagr: we can have multiple ways to do it down the track and just make it a config option to choose between them
22:29:10 <adrian_otto> if it is an OS image based runtime, then it may not matter
22:29:52 <PaulCzar> or have solum understand that if the LP is windows based it gets handled differently
22:30:24 <adrian_otto> we have some code to deploy an app into a DU, and that logic could be unique to the DU's image type.
22:30:52 <roshanagr> PaulCzar, adrian_otto: as long as you are aware of the implications, I am fine. We will need to natively support Windows at some point, as well as support migration of existing VM based workloads
22:31:06 <PaulCzar> migration of existing VM based workloads ?
22:31:23 <devkulkarni> +1
22:31:47 <roshanagr> yes, if I have a cloud app that is on VM, moving that to Solum PaaS
22:32:13 <PaulCzar> if it's already on a VM you don't need solum ?   I think I must be missing something here
22:32:24 <adrian_otto> you can specify a glance image to use in your Pipeline
22:32:46 <adrian_otto> so if you wanted to hook up a CI/CD pipeline for an existing app, that's certainly possible
22:33:12 <adrian_otto> as long as there is a buildpack that can build runnable DU's from the supplied image and source
22:33:36 <roshanagr> PaulCzar: the app is on VM, consuming IaaS. Now the app developer wants to move the app to Solum
22:33:54 <adrian_otto> so for windows VM's that may require further refinement of the .Net LP
22:33:59 <PaulCzar> roshanagr: so, they point solum at their github ...  test it ...  delete VM
22:34:31 <roshanagr> PaulCzar: right, that is the experience we would want.
22:34:46 <PaulCzar> roshanagr:  so the fact that it's running on a VM is irrelevent to us
22:35:23 <roshanagr> PaulCzar: ok
22:35:40 <adrian_otto> any other feature discussion before we move to open discussion?
22:35:56 <adrian_otto> #topic Open Discussion
22:36:52 <adrian_otto> the containers service has a codename now. Magnum == OpenStack Containers Service
22:38:06 <PaulCzar> surely magnum has TM issues ?
22:38:38 <adrian_otto> yes, as did all other ideas
22:39:10 <adrian_otto> so that is subject to change upon legal dispute
22:39:32 <PaulCzar> as long as we're going in eyes wide open :)
22:40:54 <adrian_otto> ok, any other topics for today?
22:41:04 <adrian_otto> if not, we can wrap up
22:41:46 <adrian_otto> ok, thanks everyone. Or next meeting is 2014-09-09 at 1600 UTC.
22:41:49 <adrian_otto> #endmeeting