16:00:04 <adrian_otto> #startmeeting containers
16:00:05 <openstack> Meeting started Tue Aug 19 16:00:04 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:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:09 <openstack> The meeting name has been set to 'containers'
16:00:10 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2014-08-19_1600_UTC Our Agenda
16:00:15 <adrian_otto> #topic Roll Call
16:00:17 <adrian_otto> Adrian Otto
16:00:28 <apmelton> Andrew Melton
16:00:29 <thomasem> Thomas Maddox
16:00:51 <adrian_otto> hi guys
16:00:59 <dguryanov> Hi
16:01:18 <diga> Hi
16:01:27 <thomasem> howdy
16:01:35 <sew> o/
16:01:45 <mtesauro> o/
16:02:28 <adrian_otto> looks like we have a niced size group in attendance today.
16:02:53 <adrian_otto> let's begin
16:02:59 <adrian_otto> #topic Announcements
16:03:34 <adrian_otto> First of all, we have an agenda item to cover the details and progress on our spec submission for an OpenStack containers service, so we will get to that in just a moment.
16:03:56 <adrian_otto> are there any other announcements from team members?
16:04:19 <diga> Hello guys, this is first meeting on containers for openstack
16:04:23 <adrian_otto> we had no action items assigned last week, so I will skip that point in our agenda
16:04:28 <adrian_otto> diga: welcome!!
16:04:46 <adrian_otto> do you want to take a moment to introduce yourself to the team? Totally optional.
16:04:56 <diga> working in docker since a month & interested to contribute to nova-docker
16:05:24 <adrian_otto> excellent. We are happy to have you, diga!
16:05:32 <diga> yeah
16:05:40 <adrian_otto> ok, so to the main event
16:05:44 <adrian_otto> #topic Discuss Specs for OpenStack Containers Service
16:05:47 <diga> Thanks you adrian
16:06:07 <adrian_otto> so for anyone who missed the email to openstack-dev, it is here:
16:06:09 <adrian_otto> #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/043113.html Email Thread
16:06:43 <adrian_otto> the proposal was initially submitted to nova-specs (in accordance from guidacne from the Nova team)
16:06:55 <adrian_otto> it is here, and I would appreciate your review and input to refine it:
16:06:56 <adrian_otto> #link https://review.openstack.org/114044 Spec Proposal
16:07:03 <erw> o/
16:07:13 <adrian_otto> we do have a couple of open questions, from Mr. Herve, which we can discuss today.
16:07:20 <adrian_otto> erw: welcome!
16:07:39 <adrian_otto> I also submitted a request for a Stackforge repo. That is here:
16:07:40 <apmelton> adrian_otto: I added a bit to the spec etherpad, will move those over to the spec review
16:07:40 <adrian_otto> #link https://review.openstack.org/115328 Stackforge Repo Review
16:07:50 <adrian_otto> apmelton: thanks!
16:08:29 <adrian_otto> so, I'd like to get impressions for the team about how we are doing, and get a sense if you agree we are on the right track, or if we should do some steering.
16:09:22 <adrian_otto> thoughts?
16:09:25 <diga> Good
16:09:51 <diga> guys i'll go through all our specs
16:10:14 <diga> for the start
16:10:22 <adrian_otto> digatx
16:10:28 <adrian_otto> diga: tx
16:10:38 <diga> Welcome
16:11:02 <adrian_otto> I'll give you all a moment to scan through as I know I just dumped a bunch of text on you.
16:11:02 <dguryanov> Will it be possible to create privileged container using containers service?
16:11:19 <adrian_otto> dguryanov: yes.
16:11:31 <thomasem> Yes, that's currently the only way that works since we can't nest unprivileged yet, afaik.
16:11:33 <dguryanov> Thanks
16:11:39 <adrian_otto> the only short term caveat is that if you choose to use nova-docker as your virt driver
16:12:03 <adrian_otto> in that case. we need additional kernel features for container nesting that are in flight
16:12:30 <adrian_otto> erw, do you have additional comments on this subject?
16:12:46 <erw> adrian_otto: not really.
16:12:56 <erw> adrian_otto: I concur ? :)
16:13:00 <adrian_otto> :-)
16:13:04 <adrian_otto> fair enough
16:13:25 <sew> we're able to nest plain old lxc containers in unprivileged containers
16:13:30 <sew> just not docker containers
16:13:53 <thomasem> sew: Oh, right! Thanks for the correction. :)
16:13:59 <adrian_otto> sew, yeah, the difference is the filesystem mount requiring CAP_SYS_ADMIN right?
16:15:09 <sew> we got past that, but john hopper was not able to solve permission issues wrt auplink
16:15:16 <adrian_otto> if anyone has a link to patches that change the capabilities code in the Linux kernel to allow for the unprivileged nesting, I would like to record that somewhere for the Team so we can keep track of it, and advocate for getting it in.
16:15:49 <adrian_otto> sew… humm.
16:16:06 <sew> we see behavior like this user:  https://gist.github.com/garthk/8555808
16:17:20 <adrian_otto> ok.
16:17:35 <funzo> adrian_otto: sorry, got caught up in some other stuff
16:17:47 <adrian_otto> do we know anyone who understands auplink well enough to address that?
16:17:54 <adrian_otto> hi funzo
16:18:28 <dguryanov> What about interacting with cinder using containers API? I think we should add a call to mount cinder volume to a given mountpoint
16:19:12 <dguryanov> So the one could use baremetal host as instances and request mounting cinder volumes to containers
16:19:41 <adrian_otto> dguryanov: good question. That's something we could probably do using the agent.
16:19:52 <adrian_otto> actually wait
16:20:03 <adrian_otto> maybe not, depending on how the network topology is set up
16:20:20 <apmelton> dguryanov: the way I see it, the cinder volume would need to be exposed to the container group and from there the container
16:20:43 <adrian_otto> we might need to have something in nova-compute add it to the host, and then find a way to expose them to containers
16:20:59 <adrian_otto> right
16:21:24 <adrian_otto> we should capture this on a backlog.
16:21:42 <adrian_otto> we should have a wishlist bug queue where we can land stuff like this.
16:21:51 <dguryanov> So first you should use attach_volume from nova api - cinder volume appear as /dev/sdb, for example
16:21:52 * adrian_otto feels an action item swelling
16:22:20 <adrian_otto> #action adrian_otto to create an LP project, and bug tracker for containers.
16:22:32 <funzo> so use the ironic driver, then use nova attach-volume, then have the containers API be able to use the attached volume?
16:22:33 <dguryanov> And how to mount it to /my_storage inside a container ?
16:24:44 <adrian_otto> ok, let's table this for now, and come back to it
16:25:03 <adrian_otto> #link https://review.openstack.org/#/c/114044/2/specs/kilo/containers-service.rst review comments
16:25:17 <adrian_otto> line 212
16:26:01 <adrian_otto> my thoughts on the API are that it would be really great to have compatibility with existing tools for containers
16:26:39 <adrian_otto> and because we will have different backends, that having a way to run some variants of the API on the front-end would be handy
16:26:50 <adrian_otto> Heat had this same concern
16:27:18 <adrian_otto> when it was struggling with whether to have the Heat native API, or the AWS one, or both, and others
16:27:43 <adrian_otto> the solution chosen in that case was that we'd have a common base API that other variants could be bound to.
16:28:09 <adrian_otto> I am not suggesting that we pin the base API to Docker's API
16:28:15 <thomasem> It'd just be an easier translation for Docker.
16:28:26 <adrian_otto> but I'd like us to consider having that as the first top-level API that we expose for clients
16:28:49 <adrian_otto> and tool makers can select the API option that makes the most sense
16:29:10 <adrian_otto> if we get too opinionated about this, we risk getting bypassed completely
16:29:29 <dguryanov> I don't think it's possible to have the same API as docker
16:29:40 <dguryanov> because containers will use resources from openstack
16:29:41 <adrian_otto> so I'd like to find a way to strike a healthy balance, where we are providing additional value and simplicity
16:29:47 <dguryanov> like images, volumes, networking
16:30:18 <adrian_otto> dguryanov: I think image integration can be done, as evidenced by recent work in nova-docker
16:30:19 <dguryanov> So there should be an API call to connect container to openstack
16:30:33 <apmelton> even if it was possible to use the same API, maintaining compatibility is going to be a huge pain
16:30:35 <dguryanov> to openstack's virtual network with given ID
16:30:44 <adrian_otto> and I am not convinced that differences in networking or volumes would influence the API much
16:30:47 <apmelton> and maintaining all of the cruft that already exists in the docker api
16:31:19 <thomasem> ^^ that's one concern. I would prefer we didn't inherit like deprecated things
16:31:48 <thomasem> In an effort to support tooling that requires older versions
16:31:56 <adrian_otto> apmelton: I acknowledge that trying to keep API's synchronized for compatibility is a chore. The question is if it's worth it.
16:32:52 <thomasem> I originally thought Docker's API was to be used as a reference point... a starting point, but not the ultimate API to implement for a v1.0 or something.
16:33:13 <adrian_otto> thomasem: consider if we just invent a new API, our interoperability challenges are worse.
16:33:35 <apmelton> adrian_otto: our interoperability challenges with docker are worse
16:33:42 <adrian_otto> thomasem: my idea is that it be our first implementation, and that we iterate on a base API from taht
16:33:55 <adrian_otto> keeping the Docker implementation as a binding to that more complete base API
16:34:24 <apmelton> my issue with that is the docker implementation has a ton of cruft that we have to maintain
16:34:45 <adrian_otto> apmelton: ok, I recognize that there is stuff you don't like in there
16:34:55 <adrian_otto> let's consider for a moment that we catalog, and address that stuff
16:35:05 <thomasem> I'd rather set the expectation immediately that the container service API won't always adhere to the existing Docker API.
16:35:24 <adrian_otto> and that we make no attempt to do backward compatibility to old clients, just whatever the recent release is of prevailing popular tools.
16:35:40 <dguryanov> I think we should explicitly list all API calls, which we are going to implement in containers service
16:35:59 <adrian_otto> and if we hear "it does not work with docker 0.0.0.0.1" we can respond with "upgrade to 1.1.x" or whatever
16:36:33 <thomasem> And how will we handle features that other technologies provide that docker doesn't in the future?
16:36:50 <adrian_otto> thomasem: add them to the base API
16:36:57 <adrian_otto> the coker binding does not implement them
16:37:04 <adrian_otto> s/coker/docker/
16:37:12 <thomasem> Okay. So, really we're not following the Docker API around, just using it as a starting 'sane' point.
16:37:35 <adrian_otto> but perhaps an LXC centric user can use another binding, or the tooling can just integrate with the base API directly
16:38:00 <apmelton> my issue is this, the docker api is not a base API, it is very opinionated
16:38:05 <adrian_otto> thomasem: yes, I'm suggesting we use that as the starting point
16:38:19 <adrian_otto> apmelton: agreed
16:38:30 <adrian_otto> the base API will iterate considerable away from that
16:38:53 <adrian_otto> my advice is not to get too deep into engineering a grand unification API at step 1.
16:41:21 <apmelton> at the mid-cycle it was discussed that docker cli support would be provided by plugins to docker that could talk to our api
16:41:35 * adrian_otto1 was disconnected for a moment there
16:42:09 <adrian_otto1> I hope the other idles off before I need to do the endmeeting command
16:42:16 <thomasem> Lol
16:42:35 <thomasem> Oh, yes. apmelton, I was just thinking of the REST endpoints, but the datatypes and what-not - I didn't think about that.
16:43:15 <adrian_otto1> apmelton: yes, we could do that regardless
16:43:27 <thomasem> wrt apmelton's comment on the spec
16:43:36 <adrian_otto1> I thought the question is what should be the first version of the base API
16:44:09 <apmelton> from my understanding at the mid-cycle, our first version was going to be very simple
16:44:24 <adrian_otto1> yes.
16:44:32 <apmelton> that it was not going to support many of the things that docker supported
16:45:03 <adrian_otto1> do you have a sense of which things make sense to omit?
16:45:54 <adrian_otto1> I think we are in complete agreement that we want an iterative approach starting simple, and building on that.
16:46:17 <apmelton> for a beta release, everything except create container and delete container
16:46:49 <apmelton> create container should contain simple things like environment variables
16:47:00 <apmelton> and maybe process listing and signals
16:48:01 <adrian_otto1> ok
16:48:27 <adrian_otto1> so what should our next steps be with respect to an API proposal?
16:49:36 <adrian_otto1> or maybe asking another way, what would you like to see in the proposal that would cause you to vote +1 on it
16:50:16 <apmelton> I'd like to see the beginnings of an api definition
16:50:25 <apmelton> REST endpoints and data types
16:50:32 <dguryanov> Let's create etherpad page for it
16:50:45 <thomasem> Is there already and etherpad for collaborating on the API spec?
16:50:59 <thomasem> Like we had for container service, agent, host relay
16:51:00 <adrian_otto1> let's make one now. one sec
16:51:28 <adrian_otto1> I found an old one at https://etherpad.openstack.org/p/containers-service-api
16:52:04 <thomasem> hmmm
16:52:35 <adrian_otto> Apparently the Nova team disliked this approach a year ago
16:52:47 <adrian_otto> I don't have specifics about what the actual objections were
16:53:14 <thomasem> Yeah, I don't know either.
16:53:45 <apmelton> I'd be interested to know if they disliked the idea of the service, or the api itself
16:53:57 <adrian_otto> but let's each look at this, and share our thoughts. Should we use it, or do we need to start again?
16:54:02 <apmelton> back then, the containers service was proposed as something completely separate right?
16:54:13 <adrian_otto> I am going to proceed to open discussion
16:54:25 <adrian_otto> we can continue this discussion, or take new topics
16:54:34 <adrian_otto> #topic Open Discussion
16:57:26 <adrian_otto> crickets
16:57:30 <thomasem> This would need some changes to support the nested nature of the service. Also, some top-level attributes probably need to be deeper to group appropriate things together
16:57:35 * apmelton is looking over the etherpad
16:58:25 <apmelton> thomasem: do you mean containers nested in container groups?
16:58:30 <thomasem> yeah
16:59:20 <apmelton> i'm not sure that's necessary, especially considering we'd like the end user to not have to worry about container groups if they don't want to
16:59:42 <thomasem> So, we wouldn't return to them the container group UUID?
16:59:49 <thomasem> to use if they want it?
17:00:03 <adrian_otto> ok, we timed out for today
17:00:13 <adrian_otto> let's continue in #openstack-containers
17:00:16 <adrian_otto> thanks everyone
17:00:20 <adrian_otto> #endmeeting