22:08:25 <adrian_otto> #startmeeting containers
22:08:26 <openstack> Meeting started Tue Nov 18 22:08:25 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:08:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:08:29 <openstack> The meeting name has been set to 'containers'
22:08:43 <adrian_otto> (fetching link to agenda)
22:09:02 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers Our Agenda
22:09:08 <adrian_otto> #topic Roll Call
22:09:11 <adrian_otto> Adrian Otto
22:09:19 <sdake> hey folks \o/
22:09:22 <jlb13> Jesse Butler
22:09:31 <sdake> daneyon meeting got kicked off now
22:09:40 <dguryanov|3> Dmitry Guryanov
22:10:04 <Yuanying_> Yuanying Otsuka
22:10:40 <dims> o/
22:11:08 <adrian_otto> #topic Announcements
22:11:20 <adrian_otto> none prepared. Announcements from team members?
22:11:26 <sdake> hmm
22:11:42 <sdake> #link https://review.openstack.org/#/c/135436/
22:11:50 <sdake> magnum client import
22:11:58 <adrian_otto> oh, sweet
22:12:04 <sdake> does nothing, but need to start somewhere :)
22:12:28 <adrian_otto> +1
22:12:44 <adrian_otto> any other announcements?
22:13:18 <adrian_otto> #topic Review Action Items
22:13:24 * adrian_otto adrian_otto to attempt to identify Linux kernel patches that could enable use of nested containers in non-privileged mode (http://eavesdrop.openstack.org/meetings/containers/2014/containers.2014-11-11-16.00.log.html#l-40, 16:10:57)
22:13:37 <adrian_otto> incomplete, carrying forward
22:13:44 <adrian_otto> #action adrian_otto to attempt to identify Linux kernel patches that could enable use of nested containers in non-privileged mode (http://eavesdrop.openstack.org/meetings/containers/2014/containers.2014-11-11-16.00.log.html#l-40, 16:10:57)
22:14:14 <adrian_otto> #topic Discuss initial core reviewers for https://github.com/stackforge/magnum
22:14:33 <adrian_otto> ok, so now that we have a repo, it's time to form a group of reviewers to care and feed it
22:15:05 <adrian_otto> currently I'm the only core reviewer in the group, and I'd like to arrange a consensus among team members about who should be in the initial group
22:15:17 <daneyon> +1 sdake
22:15:18 <adrian_otto> since we are starting from a blank slate, we'll need to be willing to adapt this
22:15:56 <adrian_otto> but initially we are looking for contributors who are willing to allocate at least a few hours a day for a while (perhaps 2 months?) to review, and submit patches
22:16:06 <adrian_otto> is that a fair bar to set?
22:16:16 <sdake> yup I think that is a fair requirement
22:16:18 <achanda_> sounds good
22:16:22 <daneyon> fair
22:16:45 <adrian_otto> we can continually review the group membership and adjust it
22:16:48 <sdake> so we should probably see who is actually interested :)
22:16:53 * sdake raises hand
22:17:00 * adrian_otto raises hand
22:17:07 * achanda_ raises hand
22:17:25 * dims raises hand
22:17:25 <adrian_otto> achanda_: what's your LP username?
22:17:46 <achanda_> adrian_otto: abhishek-i
22:17:58 <jlb13> for posterity's sake, i would like to say that i'm absolutely willing to help... but i'm a total noob with all of this. so i'm hoping to learn from you all before i volunteer for critical path jobs.
22:18:01 <sdake> cool so that looks like a solid core team to me :)
22:18:33 <adrian_otto> jlb13: so in that case. I ask that you set up the review queue to email you
22:18:43 <adrian_otto> review the code, and cote on patches with +1 and -1
22:18:53 <jlb13> ok, cool
22:18:54 <daneyon> I'm in the same boat as jlb13
22:18:58 <adrian_otto> once you feel confident, then we can take it from there
22:19:01 <achanda_> me too
22:19:07 <dguryanov|3> Could you, please. setup review queu for me too
22:19:20 <sdake> dguryanov|3 you hae to do that for yourself
22:19:25 <adrian_otto> https://review.openstack.org/#/q/status:open+magnum,n,z
22:19:26 <sdake> its part of the gerrit interface
22:19:28 <adrian_otto> #link https://review.openstack.org/#/q/status:open+magnum,n,z
22:19:29 <sdake> "watched projects"
22:19:37 <dguryanov|3> OK, thanks!
22:19:39 <adrian_otto> right, so set up magnum as a watched project
22:19:59 <adrian_otto> and bookmark the link above for easy access
22:20:27 <adrian_otto> ok, so let's seek an #agreed on the initial list
22:20:59 <daneyon> i'm watching magnum
22:21:07 <adrian_otto> Proposed abhishek-i, sdake, adrian_otto
22:21:14 <adrian_otto> did I miss any?
22:21:19 <sdake> dims
22:21:31 <adrian_otto> Proposed abhishek-i, sdake, adrian_otto, dims
22:21:43 <dims> thanks sdake :)
22:21:52 * sdake watching out for you dims :)
22:22:19 <adrian_otto> and we have jlb13 and daneyon and dguryanov doing reviews with +1/0/-1 participation
22:22:29 <adrian_otto> PR's accepted from everyone
22:23:02 <adrian_otto> some of our contributors are not here today, so I'm willing to revisit this list as often as we want
22:23:31 <adrian_otto> to vote a reviewer in or out of the core group, we will simply email the ML with the subject tag [magnum] and ask for the current cores to vote
22:23:32 <sdake> wfm more core = faster dev
22:23:41 <adrian_otto> simple majority prevails
22:23:59 <adrian_otto> I will do my best to make sure we get throughput with enough of us with +2 power
22:24:10 <adrian_otto> #agreed initial core group will be abhishek-i, sdake, adrian_otto, dims
22:24:12 <sdake> just to be clear adrian_otto, many projects have a -1 = veto on core review vote
22:24:25 <sdake> is that in effect or not in effect (I dont care)
22:24:31 <sdake> just dont want people surprised later :)
22:24:45 <adrian_otto> good question.. here is how I want to deal with it…
22:25:26 <adrian_otto> if there is a core who votes -1, and others who vote +2, then I'd like to signal a conversation in IRC or ML to discuss the point of dispute
22:25:39 <adrian_otto> so if you -1 be ready to compromise
22:26:04 <sdake> i have seen ithappen before and it was unpleasant :)
22:26:13 <sdake> anyway off to more pleasant topics :)
22:26:17 <adrian_otto> discussions, or lack of?
22:26:25 <sdake> discussion after a -1 in public
22:26:27 <sdake> got ugly
22:26:57 <adrian_otto> this early in the project I think we should have a relatively low bar
22:27:05 <adrian_otto> as long as there are unit tests, and func tests
22:27:11 <adrian_otto> let's not get too pedantic about stuff
22:27:12 <sdake> ya who cares imo :)
22:27:43 <adrian_otto> once we have something that works end-to-end we can get more opinionated
22:28:04 <Slower> doh, sorry, thought it was an hour later my time
22:28:12 <adrian_otto> Slower:  np
22:28:23 * Slower is also interested in group membership
22:28:36 <adrian_otto> ok, I will revise the #agreed if there are no objections
22:28:43 <sdake> agree
22:29:08 <adrian_otto> pausing a moment for anyone else
22:29:19 <adrian_otto> ok, you're in.
22:29:21 <adrian_otto> irc://irc.freenode.net:6667/#agreed initial core group will be abhishek-i, sdake, adrian_otto, dims
22:29:24 <dims> +1
22:29:27 <adrian_otto> ack
22:29:41 <adrian_otto> #agreed initial core group will be abhishek-i, sdake, adrian_otto, dims, Slower
22:29:44 <adrian_otto> that's better
22:29:49 <dguryanov|3> Maybe include me to, as former OpenVZ developer :)
22:29:50 <Slower> agreed
22:29:59 <Yuanying_> agreed
22:30:03 <adrian_otto> ok, so the primary goal is to get a POC quality prototype working
22:30:06 <adrian_otto> and iterate on it
22:30:12 <Slower> more the merrier really
22:30:32 <adrian_otto> +dguryanov
22:31:31 <adrian_otto> if you want to use -2 power, be committed to addressing the point of dispute with the committer of the patch
22:31:38 <adrian_otto> don't just block and walk
22:31:53 <dguryanov|3> OK, of course, I understand it
22:31:57 <sdake> ya -2 is a permanent veto, so be nice about those :)
22:32:12 <dguryanov|3> I like fast development process very much too :)
22:32:16 <adrian_otto> dguryanov|3: what is your LP username?
22:32:43 <Slower> especially for a PoC
22:32:48 <dguryanov|3> dguryanov
22:33:06 <sdake> one other  thing, remember takes two +2's to have a +A
22:33:11 <sdake> for t hose folks new to review process
22:33:56 <adrian_otto> #agreed dguryanov, abhishek-i, sdake, aotto, dims, Slower
22:34:13 <achanda_> #agreed
22:34:15 <adrian_otto> ok, so let's advance to the next.
22:36:00 <adrian_otto> #topic Open Discussion
22:36:05 <sdake> about the rest api
22:36:12 <sdake> I extracted this from Eric's work
22:36:15 <sdake> https://github.com/sdake/python-magnumclient/blob/master/magnumclient/magnum.py#L17
22:36:46 <sdake> is this what we are  tryhing to achieve with the magnum service
22:38:00 <adrian_otto> sdake: yes, that looks about right
22:38:04 <sdake> being a bit new to the project :) I'm not sure if there is somethign else planned
22:38:21 <sdake> so next q, natively, or as a wrapper over docker + k8s?
22:38:27 <adrian_otto> "attach" is missing
22:38:28 <sdake> or both?
22:38:37 <sdake> ya that was in the review as impossible to implemenet iiric :)
22:38:38 <Slower> clearly there is more to define eg networking etc
22:38:56 <sdake> slower a pod defines the network
22:39:08 <daneyon> maybe I need to do more homework, but would container create be similar to a docker build?
22:39:08 <adrian_otto> it's not impossible, just not part of an async API
22:39:12 <Slower> sdake: our plan was to build it on top of docker
22:39:25 <sdake> so native then
22:39:29 <sdake> eg, reimplement pods?
22:39:38 <Slower> well I think that is a good question
22:39:50 <adrian_otto> native is my preference
22:39:50 <Slower> we should entertain the idea of doing it on top of k8s
22:40:02 <sdake> if we do native that wfm, but we shoudl consider abstraction to run with k8s as well imo
22:40:11 <Slower> agreed
22:40:29 <adrian_otto> k8s+swarmd -> magnum -> nova
22:40:31 <sdake> daneyon do you have any idea how to implement the networking natively that pods do?
22:40:35 <adrian_otto> that should work
22:40:46 <Slower> do pods offer everything we need for networking? Or do we want to define eg open ports to containers etc.. maybe a qeustion for later
22:40:57 <sdake> slower we are missing a "services" object
22:41:04 <daneyon> sdake: i can dig in and let you know.
22:41:06 <sdake> if we want a true abstraction over k8s and docker
22:41:21 <Slower> well that seems reasonable then
22:41:27 <Slower> I need to look at k8s more
22:41:39 <sdake> eveyrone should have a look if we are implementing pods in the project
22:41:59 <adrian_otto> I wish erw was here
22:42:15 <erw> pong
22:42:16 <adrian_otto> the source code for fig was offered
22:42:18 <Slower> aha!!
22:42:24 <adrian_otto> erw can you elaborate?
22:42:36 <erw> adrian_otto: for Orchardup, specifically
22:42:51 <adrian_otto> right
22:43:00 * erw will read through the meeting notes later btw
22:43:23 <erw> adrian_otto: to be honest, the more I see Magnum progressing, I wonder if the orchard stuff is worthwhile.
22:43:33 <sdake> link to orchard?
22:43:33 <erw> yes, it exists and it does much of the same things...
22:43:41 <daneyon> I would say k8s pods + the kolla networking bits should be enough to get us going from a networking standpoint.
22:43:41 <erw> https://www.orchardup.com/
22:43:47 <adrian_otto> a python project
22:43:58 <adrian_otto> might help, not sure
22:44:00 <sdake> daneyon I think the idea is to make a native implementation though
22:44:22 <sdake> eg, no dependency on k8s
22:44:29 <sdake> eg/ie rather ;)
22:44:43 <daneyon> sdake: i see. I need to dig into the k8s networking code and I'll circle back around.
22:45:06 <sdake> erw in this api, bay create, how is that intended to operate?
22:45:19 <erw> sdake: bay create creates an instance in nova
22:45:20 <sdake> does that create physical hardware?
22:45:30 <sdake> what about r unning on bare metal?
22:45:31 <erw> sdake: possibly creating a pod (which may possibly create a container)
22:45:55 <erw> sdake: instances in nova may be baremetal (Ironic) or near-metal  (nova-docker / lxd / etc)
22:46:41 <sdake> so bay create is an abstraction over all those various types of end platformzsx
22:47:20 <Slower> yeah
22:47:20 <erw> sdake: bay create is specifically for creating the undercloud.
22:48:18 <sdake> so you can identify which pods end up on which hardware?
22:48:28 <adrian_otto> yes
22:48:43 <erw> sdake: the question comes down to does bay-create allow creating pods and containers…. or does container-create possibly create a pod and bay? Possibly the latter.
22:48:45 <sdake> and if you dont care which hardware, what is the api call?  just pod creat e?
22:48:46 <Slower> the scheduling of all this for scalability will be interesting..
22:48:46 <adrian_otto> first implementation can just take a bay id
22:49:26 <Slower> I suspect ultimately we will just ask for a pod, and the scheduling will deal with bays
22:49:29 <adrian_otto> container-create uses a bay if one is specified, otherwise tries to fit in existing ones, or auto-create
22:49:58 <erw> adrian_otto: rather it would use a pod if specified, otherwise it creates a pod. A pod, if a bay is not specified, creates a bay
22:50:00 <erw> right?
22:50:12 <adrian_otto> erw: yes
22:50:12 <Slower> erw: that makes sense to me..
22:50:24 <sdake> interesting approach
22:50:26 <sdake> i like it
22:50:34 <sdake> does something nobody else does, and will make kolla work \!o!/
22:50:35 <adrian_otto> my only twist on that...
22:51:03 <adrian_otto> is that if you don't specify a bay, and a bay already exists with capacity, allow that slack capacity to be used rather than creating new
22:51:10 <erw> sdake: you’re looking at nova+ironic+magnum as an undercloud for kolla?
22:51:25 <Slower> adrian_otto: +1, I think that's the scheduler role..
22:51:26 <sdake> erw magnum i think
22:51:27 <erw> adrian_otto: I think that’s something that needs to be tunable, but yes.
22:51:30 <sdake> not sure what else ;)
22:51:46 <adrian_otto> erw, Slower +1
22:52:11 <sdake> re deployment and bays
22:52:22 <sdake> is there goign to be an agent for bare metal?
22:52:25 <sdake> or just ironic?
22:52:36 <adrian_otto> is container-stop == "docker kill" ?
22:52:38 <erw> adrian_otto: actually, the reason for pods and bays being split was so more than one pod could exist on a bay
22:52:44 <Slower> I think nova-docker will be go-to for bare metal basically
22:53:02 <sdake> nova-docker is single node slower?
22:53:15 <Slower> container in container is still bare metal, I don't think there are any performance issues there?
22:53:18 <sdake> slower pods are painfully diffidcult to implement in the networking model I suspect
22:53:29 <dims> sdake: nova-docker talks to one docker daemon, yes
22:53:39 <erw> adrian_otto: probably ‘docker stop’ which tries to stop kindly (versus ‘kill’ which is SIGKILL)
22:53:46 <sdake> is nova-docker nova + docker backend?
22:53:50 <erw> i.e. SIGTERM vs SIGKILL
22:54:15 <Slower> sdake: I guess that depends.. mmm, I think subcontainers would have their own network namespace with their own virtual interfaces.. are they bridged to teh host directly?  I don't know that..
22:54:20 <adrian_otto> ok, so here is what I think we should set as GOAL-1: container-create, container-stop, container-delete
22:54:21 <dims> sdake: nova-docker is a Nova virt driver that uses docker-py to talk to docker backend
22:54:32 <adrian_otto> get that working end-to-end leveraging docker for now
22:54:45 <adrian_otto> then iterate from that point to become more ambitious
22:55:16 <adrian_otto> thoughts?
22:55:22 <jlb13> maybe need start and restart as well?
22:55:28 <Slower> it is a good point, if subcontainers have to network through the parent it could be painful
22:55:31 <adrian_otto> create+execute
22:55:34 <sdake> so milestone #1 then = rest client + rest server + db + container create/delete/list/show?
22:55:49 <Slower> do we need db?
22:55:55 <sdake> yes a db is mandatory
22:55:58 <adrian_otto> sdake: what if we just skip the client to start with?
22:56:00 <sdake> when is a different question
22:56:02 <erw> I actually question the need for execute, in general
22:56:08 <sdake> adrian_otto how you going to maeke the calls? :)
22:56:09 <adrian_otto> just use docker as the client?
22:56:19 <adrian_otto> hacked to add an auth header
22:56:19 <sdake> we can't do that with pods I dont think
22:56:37 <sdake> tbh that sound smore complicated then just makign a client
22:56:41 <erw> i.e. can ‘docker execute’ just be a special case of  ‘container create’?
22:56:49 <adrian_otto> sdake: good point
22:56:56 <erw> (I have this same question for the docker api itself actually)
22:56:58 <Slower> very good point.. doh!
22:57:06 <dims> +1 to milestone #1 as above
22:57:35 <Slower> sdake: so in the proposed milestone we just do container stuff, no bay/pod apis?
22:57:57 <sdake> slower adrian proposed, wfm - that hsould take 2-3 weeks if we are all working on it
22:58:04 <adrian_otto> rephrased: milestone irc://irc.freenode.net:6667/#1 rest client + rest server + db + container create/delete/list/show
22:58:41 <Slower> I thought the idea was to have an image in the 'bay' that held the rest server?
22:58:43 <sdake> +1 lets set a deadline
22:58:58 * Slower isn't ready to +1 that yet :)
22:59:05 * Slower is slow
22:59:10 <adrian_otto> so, we are closing in on the end of the hour
22:59:12 <sdake> need more minerals!!
22:59:17 <Slower> hehe
22:59:22 <adrian_otto> let's get an ML thread open on milestone 1
22:59:28 <Slower> sounds good to me
22:59:36 <dguryanov|3> +1
22:59:37 <adrian_otto> and let's organize around that
22:59:38 <Slower> or we could switch to #openstack-containers
22:59:49 <sdake> email thread is good
22:59:53 <sdake> maybe we will pick up more contrib
23:00:00 <adrian_otto> thanks everyone for attending today
23:00:04 <erw> +1 on making progress, in general
23:00:11 <daneyon> thanks
23:00:15 <Slower> thanks guys
23:00:16 <adrian_otto> #endmeeting