22:00:59 <adrian_otto> #startmeeting containers
22:01:00 <openstack> Meeting started Tue Dec 16 22:00:59 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:01:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:01:04 <openstack> The meeting name has been set to 'containers'
22:01:35 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers Our Agenda
22:01:39 <adrian_otto> #topic Roll Call
22:01:43 <adrian_otto> Adrian Otto
22:01:50 <sdake> \o/ yay containers ftw
22:01:50 <hblixt> Henrik Blixt
22:01:59 <adrian_otto> whoot sdake
22:02:12 <yuanying-alt> OTSUKA, Yuanying
22:02:56 <hongbin> Hongbin Lu (first time here)
22:03:07 <adrian_otto> welcome hongbin
22:04:07 <adrian_otto> #topic Announcements
22:04:10 <sdake> prad around?
22:04:17 <Slower> imain
22:04:43 <adrian_otto> 1) Diga has told me that his employer has authorized him to begin working full time on OpenStack, and he will be focusing all of his energy on Magnum.
22:04:57 <sdake> yay more full time devs!
22:05:07 <adrian_otto> indeed, much to celebrate!
22:05:35 <adrian_otto> 2) We have a planned milestone for Dec 19 approaching
22:05:43 <sdake> about that milestone
22:05:56 <sdake> i'd like to discuss moving it perhaps later in the agenda
22:05:56 <adrian_otto> sdake: you have the floor
22:06:09 <adrian_otto> ok, we can do it at the end
22:06:16 <sdake> cool
22:06:23 <adrian_otto> any other announcements from team members?
22:08:04 <adrian_otto> ok, next up
22:08:25 <adrian_otto> #topic Blueprint Review
22:09:08 <adrian_otto> #link https://blueprints.launchpad.net/magnum/milestone-1 Milestone 1 BPs
22:09:38 <sdake> rest api, I'd call that done
22:09:56 <sdake> needs some tidy, but that will come over time
22:10:04 <adrian_otto> ok, not all of these are implemented yet… the API.. there are two BP's for what appears to be the same effort.
22:10:25 <sdake> which ones?
22:10:39 <adrian_otto> I am seeing https://blueprints.launchpad.net/magnum/+spec/magnum-api-service and https://blueprints.launchpad.net/magnum/+spec/magnum-api-service-containers
22:11:12 <sdake> the s econd is essentially to implement the backend of the container rest api
22:11:43 <adrian_otto> I see. That's marked as not started. Is that right?
22:11:46 <sdake> ie: https://blueprints.launchpad.net/magnum/+spec/magnum-backend-docker-api
22:11:58 <sdake> there isa  patch up for review with -1 on the check
22:12:34 <sdake> sorry the blueprint is actually https://blueprints.launchpad.net/magnum/+spec/magnum-backend-docker
22:13:16 <sdake> I think the easy solution is to can https://blueprints.launchpad.net/magnum/+spec/magnum-api-service-containers
22:13:25 <adrian_otto> has the topic of using Zaqar been discussed on the ML?
22:13:48 <sdake> adrian_otto I thin kthe idea is to use the rest api that docker exposes directly
22:14:02 <sdake> so we dont need agents, the agent is the docker rest api
22:14:17 <adrian_otto> ok.
22:14:31 <dims> sdake: apologies, i could not make it today :)
22:14:53 <sdake> I superceeded https://blueprints.launchpad.net/magnum/+spec/magnum-api-service-containers adrian_otto
22:14:59 <sdake> since its a dupe
22:15:06 <adrian_otto> ok, tx
22:15:40 <sdake> I marked https://blueprints.launchpad.net/magnum/+spec/magnum-rest-api as done
22:15:48 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/backend-bay-heat-kube Implement a backend bay using larsks heat-kubernetes heat template
22:16:04 <adrian_otto> that's marked as Essential and Not Started
22:16:06 <sdake> this is done: https://blueprints.launchpad.net/magnum/+spec/db-object-definitions
22:16:20 <sdake> adrian_otto that is part of the bay implementation
22:16:24 <sdake> should be done this week
22:16:27 <sdake> it is definately started
22:16:49 <adrian_otto> ok, so no PR's reference it?
22:17:08 <sdake> I marked https://blueprints.launchpad.net/magnum/+spec/db-object-definitions as done
22:17:12 <adrian_otto> maybe next time you do a commit you might add a ref there
22:17:15 <sdake> since we have our object defintions
22:17:24 <adrian_otto> ok, sweet
22:17:32 <sdake> ya, we should probably as a tem start using "implements blueprint: "XXX
22:17:56 <adrian_otto> exactly
22:18:06 <sdake> I marked https://blueprints.launchpad.net/magnum/+spec/db-composite-container as implemented
22:18:14 <adrian_otto> at least that way we'll get the status auto-switched to Started
22:18:28 <sdake> I marked https://blueprints.launchpad.net/magnum/+spec/db-port-mapping as done
22:18:35 <sdake> all the db stuff is done - but needs refining
22:19:45 <adrian_otto> is https://blueprints.launchpad.net/magnum/+spec/implement-backend-rpc needed considering remarks earlier about Zaqar?
22:19:52 <sdake> I marked https://blueprints.launchpad.net/magnum/+spec/implement-backend-rpc as implemented
22:19:55 <adrian_otto> since the first agent is Docker?
22:20:13 <sdake> the rpc backend is implemented in "magnum-conductor" process
22:20:33 <adrian_otto> what RPC mesages are we using?
22:20:38 <adrian_otto> this for usage?
22:20:48 <sdake> the rest api sends messages to the conductor to do the actual work
22:20:53 <sdake> this is how we implement horizontal scalability
22:20:57 <sdake> vs the rest api doing all the work
22:21:07 <adrian_otto> oh, I see
22:21:11 <sdake> the conductor communicates with the ReST API in either kubernetes or docker to do the job
22:21:20 <sdake> so no need for zaqar that I can see atm
22:21:40 <adrian_otto> that's only useful if you have a queue based agent in the guest
22:21:48 <sdake> if you pull the current milestone list (recommended) I think that represents the current state o the database
22:21:53 <adrian_otto> in that case a multi-tenant queue service would be indeal
22:21:56 <sdake> right, ID ont think we need dan agent
22:22:11 <sdake> and agent's are generally frowned upon and cause havoc with various distros/etc :)
22:22:50 <adrian_otto> yep
22:23:09 <adrian_otto> ok, planning to advance topics now
22:23:50 <adrian_otto> before I do, are there any open work items that require team discussion?
22:24:08 <sdake> I'd like to discuss a baymodle object
22:24:12 <sdake> baymodel object
22:24:16 <sdake> I have a review in teh queue for i t
22:24:22 <adrian_otto> link us
22:24:27 <sdake> I think it will make using magnum a whole lot easier, but less is more, and i prefer less objects int he system
22:24:39 <sdake> basically its a template for what the bay should be
22:24:45 <sdake> when you create a bay, you sepcify a bay model
22:24:49 <sdake> thiink of it as a nova flavor
22:24:53 <sdake> anyone object to the idea?
22:25:13 <yuanying-alt> Nova flavor is setup by admin
22:25:14 <adrian_otto> #link https://review.openstack.org/141890 baymodel
22:25:29 <yuanying-alt> but is baymodel setup by tenant user, ok?
22:25:34 <sdake> right
22:25:43 <sdake> baymodel created by tenant
22:26:00 <yuanying-alt> Ok, another question
22:26:23 <yuanying-alt> if we only use larks/heat-kube
22:26:47 <sdake> I think we will want more models to support other disteros beside fedora atomic
22:26:51 <adrian_otto> the idea is you register your model, and all bays created confirm with it… or you can register many, and you specify which to use?
22:27:02 <adrian_otto> s/confirm/conform/
22:27:05 <sdake> you register many
22:27:10 <sdake> and when you createa bay, you select a model
22:27:18 <sdake> one model is fedora-atomic
22:27:21 <sdake> another model is fedora-cloud
22:27:28 <sdake> and the backends in coductor ifgure out what to do with it
22:27:37 <sdake> how to create the baremetal or virt  ays
22:27:51 <yuanying-alt> baymodel has baymodel_type?
22:28:03 <sdake> it does not at  the moment, what is the baymodel_type property?
22:28:06 <sdake> virt vs baremetal?
22:28:11 <sdake> it has as "flavor" atm
22:28:12 <yuanying-alt> yes
22:28:19 <sdake> flavor = virt or baremetal
22:28:28 <sdake> flavor  = m1.small, or baremetal etc
22:28:44 <sdake> if baremetal, ironci is used for full baremetal deployment
22:28:52 <sdake> if m1.small the m1.small nova virt is used
22:28:58 <adrian_otto> we would reference glance to match flavors based on the value?
22:29:22 <sdake> the heat template that launches the scheband would take a parameter of flvaor
22:29:28 <sdake> the flavor would come from teh bay flavor
22:29:29 <adrian_otto> actually, where are flavors defined/// in nova?
22:29:32 <sdake> the bay flavor is storedi nt he bay object
22:29:44 <sdake> flavors are defnied in nova, baymodel defined in magnum
22:30:09 <sdake> the altnerative is we jam a mimlion parameters into bay-create for storing the info
22:30:14 <adrian_otto> ok, we should give come consideration to making it work the same way
22:30:15 <sdake> so its not templatable and repeatable :(
22:30:20 <yuanying-alt> each heat template parameter is different, so baymodel shoud have a diffeent parameter.
22:30:22 <adrian_otto> sounds like it is the same
22:31:03 <sdake> how about this, lets do bay model, and if it doesn't work out, we can depreacate it
22:31:09 <sdake> either that, or vote :)
22:31:41 <adrian_otto> I have no objections to trying it
22:31:44 <sdake> the rest of the objects in magnum are required, bay model is a user optimization
22:31:56 <sdake> it makes using magnum easier
22:32:11 <yuanying-alt> yes agreed.
22:32:30 <sdake> cool, well I had it working, and nwo its not, not sure why
22:32:34 <sdake> so I'll need to debug it a bit
22:32:43 <adrian_otto> ok
22:33:22 <adrian_otto> any chance you could put tests in for it?
22:33:28 <sdake> yes of course
22:33:30 <adrian_otto> tx
22:33:36 <sdake> sepaking of testsxz
22:33:48 <sdake> I think after milestone #1, we should as a review team reject patches whithout tests
22:33:57 <sdake> our code base is getting larger , 8k lines of code
22:34:01 <sdake> and our test coverage is pretty weak
22:34:18 <adrian_otto> yes, we will need a hardening phase
22:34:32 <sdake> I think hardening should happen during phase 2, where we crank out a bunch of unit tests
22:34:38 <sdake> to give good coverage to the code base
22:34:43 <sdake> but I may stand alone there :)
22:34:51 <sdake> rather milestone #2
22:35:01 <adrian_otto> I'll suggest that Diga help out with that
22:35:52 <dims> sdake: +1 to try bay model out
22:35:58 <sdake> dims cool
22:36:08 <dims> yes we definitely need more tests
22:36:17 <sdake> our test coverage is terrible
22:36:37 <adrian_otto> sdake: you had remarks about our target date before. Did you want to touch on that now?
22:36:41 <dims> and split unit vs functional as we talked about last time
22:36:47 <sdake> agree dims
22:36:54 <adrian_otto> +1 tests
22:36:58 <sdake> we had set date of 19th
22:37:01 <sdake> atleast unit dtests to bergin with
22:37:17 <adrian_otto> #topic Target date
22:37:21 <sdake> but this kind of lines of with christmas
22:37:36 <sdake> and I thnkk our #1 objective with milestone #1 is to attract new developers to contribute to the code base
22:37:49 <sdake> our #2 objective is to present something that works, even if a bit short of unit tests
22:38:02 <adrian_otto> agreed
22:38:03 <sdake> I think a date in the new year would better fit these objectives
22:38:26 <sdake> if we crank out something on the 23rd, realistically nobody is goingt o look at it
22:38:27 <adrian_otto> ok, what would be an appropriate target?
22:39:00 <sdake> I like January 13th
22:39:05 <sdake> with a freeze around Jan 9th
22:39:16 <adrian_otto> maybe 2015-10-04 as the final call?
22:39:20 <sdake> or freeze eaerlier
22:39:22 <adrian_otto> 01
22:39:27 <adrian_otto> not 10
22:39:32 <dims> i was going to suggest the same gives a solid week in Jan
22:39:56 <sdake> so freeze jan 5th, then have a week of testing, then release on tuesday jan 13th
22:40:25 <adrian_otto> ok, I've been really slammed the past few weeks, but approaching the holidays I expect things to quiet down so that I'll be able to get a lot of reviews done
22:40:30 <dims> sounds good
22:41:01 <sdake> red hat has a shut down and I'm going to try to unplug from the 19th to the 5th of jan
22:41:06 <sdake> so don't expect much from me during that period ;)
22:41:19 <dims> sdake: slacker :)
22:41:27 <adrian_otto> ok, enjoy your time away sdake
22:41:57 <dims> have a good vacation everyone!
22:42:19 <sdake> so 13th of january for milestone #1 tag and release then?
22:42:42 <sdake> should we vote, or we good on the date
22:43:04 <dims> +1
22:43:10 <yuanying-alt> +1
22:43:10 <sdake> +1
22:43:33 <adrian_otto> #agreed Our Milestone-1 target date is now 2014-01-13
22:43:59 <adrian_otto> #topic Open Discussion
22:44:08 <sdake> core team expansion
22:44:32 <hongbin> Hi, all. I have several things to discuss. Is it a good time to start?
22:44:38 <sdake> I'd like to get to the point where we are following the full openstafck process
22:44:45 <sdake> whiuch  is two +2 reviews before patches go in
22:44:49 <dims> right
22:44:57 <sdake> with our current core team, some folks have not really been doing reviews on teh core team
22:45:18 <sdake> whiel a bunch of other devs have come in and helped on the code base and review process
22:45:39 <sdake> I propose we finalize a new list of the core team or atleast new members we wantto add at milestone #1
22:45:49 <sdake> we should funnel those through adrian_otto
22:45:56 <sdake> and make sure the candidate is actually interested
22:46:18 <sdake> and then we can vote on ml
22:46:26 <sdake> any opposition?
22:46:30 <adrian_otto> ok, I'll accept nominations, so just direct message me at @adrian_otto and I will relay nominations to the ML for voting
22:46:43 <adrian_otto> I suggest we wait until after M1 completes to prune the list
22:46:52 <sdake> we should probably wait until the 14th to propose nominations asw ell
22:46:57 <sdake> maek sure folks are in after the new year
22:47:00 <sdake> agree on prune
22:47:05 <adrian_otto> we can add at any time
22:47:10 <sdake> since companies business objectives change and what not
22:47:18 <sdake> and folks may change their minds between now and new year
22:47:20 <dims> +1 on prune after M1
22:47:34 <sdake> probably m2 makes sense for prune
22:48:13 <sdake> ok i'll stop dominating the agenda :) all yours hongbin
22:48:20 <hongbin> thanks
22:48:36 <hongbin> first, I am looking for several features from magnum
22:48:44 <hongbin> 1. OpenVZ support
22:48:55 <hongbin> 2. OpenVSwitch integration
22:49:00 <sdake> that is in the spec
22:49:05 <sdake> we are using neutron for openvswitch integration
22:49:08 <hongbin> 3. multi-region/multi-cloud support
22:49:24 <hongbin> k
22:49:45 <sdake> multi-regon seems a bit far off, we have to write unit and functional test cases for example to get through the incubation process
22:49:52 <adrian_otto> #3 is a hum dinger, but should actually be posssibe with federated auth
22:50:20 <dims> hongbin: are you a user or will be helping with dev?
22:50:33 <hongbin> I can part-time contribute to
22:50:41 <adrian_otto> excellent
22:50:53 <hongbin> I am also a user :)
22:51:02 <dims> nice!
22:51:07 <dims> helps both ways :)
22:51:11 <sdake> like adouble win :)
22:51:13 <hongbin> sure
22:51:34 <hongbin> Yes, in the short term, I need the OpenVZ support
22:51:42 <hongbin> since docker don't support live migration
22:52:39 <hongbin> sorry, if I kill the meeting
22:53:16 <adrian_otto> hongbin: thanks for sharing your wish list. That will help us manage our upcoming work priorities.
22:53:19 <sdake> I think at this point our next step is to merge adrian's original spec
22:53:22 <sdake> and iterate on that
22:53:24 <sdake> with things like this
22:53:42 <adrian_otto> keep in mind that Magnum is early stage, and that current focus is to get some basics working
22:53:44 <sdake> so a couple cores can +2/+a it
22:54:04 <hongbin> k
22:54:15 <hongbin> thanks all.
22:54:15 <dims> and need someone who has done openvz before...not sure who in the current group is willing to work it
22:54:32 <hongbin> I can work with it.
22:54:36 <adrian_otto> I can make time to incorporate feedback on the spec, and submit a new patchset for it.
22:54:50 <sdake> I think lets merge it as is adrian_otto and then iterate from there
22:54:55 <adrian_otto> hongbin: is the spec something you have seen?
22:54:58 <sdake> since we have a  basic architecture and gaols in palce
22:55:11 <hongbin> no sure which spec
22:55:32 <adrian_otto> #link https://review.openstack.org/136103 Magnum Spec
22:55:52 <hongbin> adrian_otto: yes I saw that
22:55:57 <adrian_otto> I'd like to get your input on the use cases, and we can see about potentially expanding them to meet your needs
22:56:11 <hongbin> k
22:56:27 <adrian_otto> sdake: you can upgrade your vote to +2 on that
22:56:32 <sdake> just did
22:56:33 <sdake> dims ?
22:56:44 <adrian_otto> and Slower, you can vote, and +A right?
22:56:58 <dims> done
22:57:14 <sdake> dims hit +a too :) your the 2nd reviewer
22:57:33 <dims> sdake: will do at the end of the meeting
22:57:40 <sdake> tia
22:57:49 <dims> just in case someone else wants to +2 as well
22:58:07 <sdake> 2 should be minimum for specchanges, but we dont need more imo
22:58:22 <adrian_otto> ok, so that's merging… so let's submit patches against that to discuss new use cases as we learn about them
22:59:06 <adrian_otto> tanks everyone for attending today. We have another minute left. An parting thoughts?
22:59:14 <adrian_otto> s/An/Any/
22:59:23 <sdake> sherman ftw ;-)
23:00:09 <adrian_otto> Okay, enjoy your week, and we'll regroup again at UTC1600 on Dec 23.
23:00:14 <adrian_otto> #endmeeting