16:00:31 <hongbin> #startmeeting containers
16:00:32 <openstack> Meeting started Tue Nov 17 16:00:31 2015 UTC and is due to finish in 60 minutes.  The chair is hongbin. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:36 <openstack> The meeting name has been set to 'containers'
16:00:40 <hongbin> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-11-17_1600_UTC
16:00:42 <eliqiao> o/
16:00:46 <hongbin> #topic Roll Call
16:00:48 <dane_leblanc> o/
16:00:48 <rlrossit> o/
16:00:52 <Kennan> o/
16:00:52 <rpothier> o/
16:00:52 <dimtruck> o/
16:00:54 <yolanda> o/
16:00:54 <eliqiao> o/
16:01:00 <vilobhmm1> o/
16:01:00 <muralia1> o/
16:01:08 <bradjones> o/
16:01:15 <eghobo> o/
16:01:33 <Tango> o/
16:01:53 <hongbin> Thanks for joining the meeting eliqiao dane_leblanc rlrossit Kennan rpothier dimtruck yolanda vilobhmm1 muralia1 eghobo Tango
16:02:04 <muralia1> hi everyone
16:02:10 <juggler> o/
16:02:13 <Kennan> hi
16:02:29 <hongbin> #topic Announcements
16:02:35 <tbh> o/
16:02:41 <hongbin> Adrian Otto is travelling this week. Hongbin Lu is the temp chair.
16:02:54 <hongbin> any other announcements from team member?
16:03:25 <hongbin> K. Let's move on
16:03:30 <hongbin> #topic Container Networking Subteam Update (daneyon)
16:04:03 <hongbin> It looks daneyon is not here
16:04:48 <hongbin> K. Let's move on for now
16:04:58 <hongbin> #topic Magnum UI Subteam Update (bradjones)
16:05:01 <bradjones> hi
16:05:12 <bradjones> biggest addition this week is the containers create
16:05:27 <bradjones> #link https://review.openstack.org/#/c/242410/
16:05:41 <bradjones> needs another +2 so if someone can get round to that, will be appreciated
16:06:03 <bradjones> still blocked on the BayModel work waiting for next release of the python-magnumclient
16:06:20 <bradjones> although it has been blocked for a while so I might just remove the code the is dependent on the new version
16:06:30 <bradjones> and we can put it back in as another patch at a later date
16:06:34 <bradjones> just to keep things moving
16:06:43 <bradjones> that's all from me
16:06:48 <hongbin> bradjones: K. I can follow up with Adrian for the release of magnumclient
16:06:56 <bradjones> hongbin: thanks
16:07:11 <hongbin> #action hongbin follow up with Adrian Otto for the release of python-mangumclient
16:07:26 <hongbin> Any question for bradjones ?
16:07:52 <Tango> Is there a road map?
16:08:03 <Tango> on what's planned for mitaka?
16:08:32 <bradjones> Tango: not yet, although that would be a sensible thing to sit down and figure out
16:08:45 <bradjones> I can take on that
16:08:56 <Tango> Sounds good, thanks bradjones:
16:09:10 <bradjones> no problem
16:09:25 <hongbin> Thanks bradjones
16:09:33 <hongbin> Let's move on
16:09:37 <hongbin> #topic Review Action Items
16:09:41 <hongbin> none
16:09:49 <hongbin> #topic Blueprint/Bug Review
16:09:56 <hongbin> 1) Essential Blueprint Updates
16:10:11 <hongbin> We are working on identifying a list of essential blueprint for Mitaka
16:10:21 <hongbin> #link https://etherpad.openstack.org/p/mitaka-magnum-planning
16:10:55 <hongbin> If you have features that needs to included in Mitaka, please create a bp and add it to the eterpad
16:11:14 <hongbin> The eterpad will be presented to the PTL (Adrian Otto) to review
16:11:33 <hongbin> Any further discussion for this topic?
16:12:13 <eliqiao> hongbin: when will feaure frezze?
16:12:29 <eliqiao> hongbin: do we have a feature freeze?
16:12:43 <hongbin> eliqiao: we don't have feature freeze for liberty
16:12:50 <hongbin> eliqiao: not sure yet for Mitaka
16:13:03 <hongbin> eliqiao: we will decide before the release
16:13:12 <eliqiao> hongbin: okay, thx.
16:13:17 <muralia1> do any of these blueprints cover the issue where heat redeploys the entire stack with updates? or should i create a new one for it?
16:13:52 <hongbin> muralia1: please feel free to create a bp for it. I don't think it is covered
16:13:58 <muralia1> ok
16:14:03 <Tango> muralia1: Can you elaborate?
16:14:18 <Kennan> seems stack-update has been implemented before
16:14:41 <muralia1> tango: this has mainly to do with the token thats passed in for TLS. when that changes over time, heat redeploys the entire stack.
16:15:23 <hongbin> muralia1: A solution is to switch to SoftwareDeployment resource in Heat
16:15:54 <Tango> muralia1: ok, this seems related to one of my problem, I would like to follow up on this.
16:16:00 <hongbin> muralia1: SoftwareDeployment is designed for this use case (not replacing the server when the configs update)
16:16:17 <muralia1> hongbin, tango:  ah, i'd like to discuss that with you some more. maybe after the meeting?
16:16:27 <hongbin> muralia1: sure
16:16:34 <Tango> muralia1: yep
16:16:38 <Kennan> muralia1: like to hear the details, maybe bp related
16:16:50 <muralia1> my approach is different right now. so lets talk.
16:17:20 <Kennan> ok. will check chats later. as time is late in china. muralia1
16:17:32 <muralia1> sure
16:17:48 <hongbin> Thx. Any other blueprint related discussion?
16:18:31 <hongbin> K. Let's move on to the next session
16:18:39 <hongbin> #topic Open Discussion
16:18:53 <hongbin> We have several items to discuss in this session
16:19:02 <hongbin> Let's discuss them one by one
16:19:09 <hongbin> 1) Continue Networking Subteam meetings? (daneyon)
16:20:05 <hongbin> Again, it looks daneyon is not here. Anyone else want to discuss this topic?
16:20:23 * eliqiao zzzz~~~
16:20:30 <Tango> It seems daneyon is the only implementing network feature so far.
16:20:45 <Tango> Is there more work down the road?
16:20:53 <Kennan> Tango: did they hold weekly meeting ? I think so
16:21:06 <Tango> or is the work winding down?
16:21:45 <dane_leblanc> There's probably more work, but it can probably be covered in this Magnum/container meeting
16:22:17 <Kennan> hi dane_leblanc: are you working on that network part?
16:22:29 <Kennan> noticed you also have related patch
16:22:31 <dane_leblanc> Partly... helping Daneyone some
16:23:16 <Tango> ok, so maybe we can discuss during the normal Magnum meeting for now, and reconvene the submeeting if needed.
16:23:40 <Tango> but leaving that to daneyon to decide
16:24:08 <hongbin> Tango: agree. It really depends on daneyon
16:24:26 <Kennan> +1
16:24:28 <hongbin> If he needs the submeeting, we could continue to do that.
16:24:51 <hongbin> #action hongbin follows up with Daneyon for the submeeting discussion
16:25:03 <hongbin> OK. Next one
16:25:10 <hongbin> 2) Do we support Docker 1.9? Stability vs Latest Features (daneyon)
16:25:41 <hongbin> Anyone else want to discuss this topic (besides Daneyon)?
16:25:48 <Kennan> I like to involve docker 1.9, most related with docker volume support
16:26:10 <Kennan> but also docker 1.9 seems have issue in docker community, I not sure if it is well supported in k8s
16:26:20 <Tango> It's probably a good idea to have one stable image and one image for latest features
16:26:32 <eliqiao> Tango: +1
16:26:34 <Kennan> yes, Tango: like to build it
16:26:37 <Kennan> if possible
16:26:46 <Tango> And migrate the latest one to stable over time
16:27:58 <hongbin> Tango: could we consider the *-5 image is the stable one?
16:28:25 <eliqiao> hongbin: seems it's the only one we supported.
16:28:42 <Tango> hongbin: I think so.  Maybe we should have a naming scheme so that it's easy to identify which is which
16:28:54 <Kennan> yes, only if atomic have release newer
16:28:56 <eliqiao> better to have CI test some specify iamge.
16:29:11 <Tango> Then people won't wonder which is stable and which is latest
16:29:45 <eliqiao> Tango: I remember that we can add version in atomic image ?
16:29:56 <hongbin> Tango: Sure. Maybe we could document it: like which one is table, which one is cutting-edge
16:29:57 <eliqiao> Tango: such as /etc/release ..
16:30:18 <Tango> eliqiao: That's a good idea
16:30:43 <juggler> hongbin: You mean table or stable?
16:30:51 <hongbin> juggler: yes :)
16:30:57 <Tango> hongbin: Right, maybe in a Readme file on the fedora site
16:31:09 <daneyon_> o/
16:31:15 <Kennan> do we need build build new image to enable /etc/release ? or just edit heat templates for magnum specific tags
16:31:19 <hongbin> Hey daneyon_
16:31:37 <juggler> yes means..table or stable? :)
16:31:51 <hongbin> juggler: stable
16:31:56 <juggler> thx
16:32:00 <Tango> Kennan: Not sure what you mean
16:32:24 <Kennan> right now, the 5-image notb have /etc/release
16:32:27 <Kennan> right?
16:32:47 <Tango> Kennan: Right
16:32:49 <Kennan> if we have /etc/release, do we need build new image ?  Tango:
16:33:02 <hongbin> Tango: eliqiao : To be clear, enable /etc/release can discover the version inside the image right?
16:33:26 <hongbin> Tango: eliqiao: I think what is missing is discovery the version outside the image (e.g. in glance)
16:33:26 <eliqiao> hongbin: yes.
16:33:41 <Tango> Kennan: I guess I can just edit the current image without changing the binaries.
16:34:17 <Tango> Kennan: /etc/release is just text, right?
16:34:58 <Kennan> a directory
16:35:05 <Kennan> a file
16:35:24 <Tango> ok, I will look into this
16:35:40 <hongbin> Thx Tango
16:35:44 <Kennan> not very sure. Tango: like to know
16:36:04 <hongbin> Personally, I am OK with a new image for docker 1.9
16:36:23 <hongbin> Anyone wants to work on that could submit a review
16:36:36 <hongbin> Then, we could download the patch to test the new image
16:36:38 <Kennan> hongbin: do you mean build new image for 1.9?
16:36:57 <hongbin> Kennan: That is my understanding
16:37:10 <Kennan> I like ot try, will check with Tango:
16:37:17 <Kennan> seems Tango knows more about it
16:37:36 <hongbin> We have a stable image for docker 1.8. We need to build a new image if we want to upgrade to 1.9.
16:37:47 <Tango> Egor suggested building a new one with Kubernetes 1.1 with Docker 1.9.  I am looking into this.
16:38:17 <Kennan> OK if Tango is working on this I 'd like to follow his further progress
16:38:30 <hongbin> OK. Any further discussion on this topic?
16:38:49 <hongbin> Let's move on
16:38:51 <hongbin> 3) Issue on browsing history of renamed file/folder (hongbin)
16:39:14 <hongbin> I want to raise the issue that Github doesn't support full history of renamed file
16:39:38 <eliqiao> hongbin: it's related with this patch #link https://review.openstack.org/245680
16:39:44 <hongbin> eliqiao: yes
16:39:53 <eliqiao> daneyon_: just commented , he want to do rename.
16:40:27 <hongbin> So, here is the issue. If you rename a file with "git mv", the history of the file get disconnected somehow
16:40:45 <hongbin> You can browse a history of a file using "git log ..."
16:41:00 <hongbin> That won't work if the file renamed
16:41:34 <hongbin> In CLI, you can work around by using "git log --follow ..."
16:41:44 <hongbin> That is not supported in Github
16:42:10 <hongbin> The question I am going to ask is if we should avoid rename file?
16:42:14 <Kennan> hongbin: what's other projects do with that? I think rename is common action
16:42:49 <eliqiao> Kennan: hongbin they just do the rename.
16:42:52 <hongbin> Kennan: I am not sure other projects. Renaming is definietly a common action
16:43:12 <eliqiao> at leaset, nova does.
16:43:21 <hongbin> eliqiao: ack
16:43:26 <daneyon_> IMO renaming a file or dir should be done if it makes good sense.
16:43:33 <eliqiao> s/leaset/least
16:43:55 <Tango> Should we ask around to see if there is a work-around?
16:44:27 <Tango> This is a pretty fundamental problem, hard to see that everyone just lives with it
16:44:53 <daneyon_> renaming is definitly a common issue that we need to support.
16:45:28 <hongbin> Sure, we could ask for advice from other projects
16:45:50 <hongbin> Then, let's defer this topic for now?
16:45:59 <Kennan> hi https://github.com/openstack/magnum/commits/master/magnum/templates
16:46:03 <Tango> We can follow up next week
16:46:06 <vilobhmm1> yes we should do that…may be a mailing list thread would be better
16:46:10 <vilobhmm1> hongbin : ^^
16:46:14 <juggler> stumbled upon this...maybe it might be mildly useful? *shrug* https://silverdrs.wordpress.com/2014/06/09/why-git-is-sometimes-more-gitty-than-any-other-git-you-are-about-to-ever-encounter/
16:46:24 <Kennan> seems I can find history not sure if it is what you said the issue
16:46:27 <hongbin> vilobhmm1: sure
16:47:01 <hongbin> #action hongbin starts a ML to discuss the renamed file issue
16:47:14 <hongbin> Let's move on. We have several other things to discuss
16:47:22 <hongbin> 4) Optimize fedora-atomic images used for tests: generate a dib image (yolanda, mordred)
16:47:29 <yolanda> hi
16:47:35 <mordred> heya
16:47:35 <hongbin> Hi yolanda
16:47:49 <yolanda> so we were working last week on adding integration between shade and magnum
16:48:11 <yolanda> and we found a problem, that is , enabling magnum plugin in devstack, requires to download that fedora atomic image, that is over 800mb
16:48:30 <yolanda> that causes the testing to be quite expensive, and we were wondering about how to optimize it
16:48:47 <mordred> yup. downloading 800M images over the open internet == recipe for failure
16:49:22 <yolanda> mordred proposed to generate the image using diskimage builder, so wanted to raise the topic here
16:49:45 <Tango> yolanda: You mean building the image dynamically?
16:49:48 <mordred> yah. greghaynes_ and yolanda have both volunteered to do the work on dib to enable it to do the job
16:49:51 <Kennan> I remembered Tango mentioned that before in summit, try disimage build with ubutu
16:50:02 <mordred> Tango: more, be able to generate it in infra and upload it to tarballs.o.o
16:50:14 <mordred> so that it's in a better position for us to be able to cache it or distribute it to our cloud regions or whatnot
16:50:34 <Tango> mordred: We discussed this at the last design summit.  I opened a BP:  https://blueprints.launchpad.net/magnum/+spec/ubuntu-image-build
16:50:36 <mordred> this would be in-line with how the other 'we need an image' projects like sahara and trove deal with their images
16:50:42 <mordred> Tango: sweet!
16:50:52 <Kennan> mordred: do you mean build fedora-atomic?
16:50:53 <yolanda> checking
16:50:55 <Kennan> or other os diso
16:51:00 <mordred> Kennan: either
16:51:04 <mordred> Kennan: and both
16:51:15 <mordred> we'd like for diskimage-builder to be _able_ to build both
16:51:27 <Kennan> I think many heat tempaltes work with fedora-atomic only(except mesos)
16:51:29 <mordred> because then it'll make the discussion about how to structure jobs a bit easier
16:51:43 <Kennan> if support other os, heat templates need changes
16:51:44 <mordred> yah. well, there is no reason dib can't make atomic images
16:51:53 <mordred> oh - wait - lemme be clearer
16:51:58 <mordred> we want to make dib able to create either
16:52:17 <mordred> whether magnum uses fedora atomic or ubuntu is not a thing we have an opinion on
16:52:39 <Kennan> mordred: good
16:52:39 <daneyon_> will dib be able to create a coreos image too?
16:52:48 <mordred> we just want to help enable that discussion - and to help enable making sure all th etooling can run in infra that you need
16:52:56 <Tango> mordred: The reason I am thinking about switching to Ubuntu is because the process for building the atomic image is very complex
16:52:58 <mordred> daneyon_: I don't see why not
16:53:13 <yolanda> one thing we will need is to have the requirements , in terms of content, of that image. Is that documented somehow? i mean, include etc, flannel, ec
16:53:30 <daneyon_> Tango what is the process for building the coreos image?
16:53:51 <Tango> We don't have one for coreos image, we just download from their site
16:54:09 <hongbin> daneyon_: CoreOS feature is done by another folk (called diga)
16:54:28 <daneyon_> I think it's important that magnum have good support for a micro os. Since atomic is a PITA, I'm +1 on shifting focus to coreos.
16:54:40 <eghobo> coreos image are immutable by default, you cannot build them ;)
16:54:42 <mordred> cool. so, at least at this point - if we do work on enabling this stuff in dib
16:54:50 <Tango> yolanda: I can help providing the details in the image.
16:54:56 <mordred> it's at least not a thing people are here opposed to
16:54:59 <mordred> yeah?
16:55:01 <yolanda> Tango, thanks
16:55:16 <mordred> eghobo: I disagree. the coreos people have to build their base images somehow
16:55:22 <Tango> mordred: Not at all, in fact that's the direction we want to go
16:55:26 <mordred> eghobo: they are, after all, just bytes on disk
16:55:27 <Kennan> glad to try ubuntu images when dib made it
16:55:31 <mordred> Tango: WOOT! yay for collaboratoin
16:55:42 <juggler> indeed
16:55:59 <daneyon_> Since we are struggling a bit right now to support multiple base os's, I think we should focus on 1 until we can better support multiple. I think it should be a micro os.
16:56:04 <eghobo> mordred: we can talk about it, i still cannot figure out how to build one ;)
16:56:31 <mordred> eghobo: :)
16:56:41 <mordred> eghobo: yah - I mean, I don't know _how_ :)
16:57:27 * mordred mainly wants for the artifact that magnum needs to boot to be something that can be cached/downloaded from infra servers to reduce chance of internet connectivity test failures
16:57:30 <hongbin> Sound like the direction is to figure out how to build atomic image with dib?
16:57:47 <mordred> hongbin: yah. I think there are a few parallel directions:
16:57:54 <mordred> hongbin: a) figure out how to build atomic image with dib
16:58:08 <mordred> hongbin: b) figure out what is needed in an ubuntu image built with db
16:58:09 <daneyon_> eghobo I don't necessarily care to build the coreos image or other images. I want to make sure we do a great job of supporting the image.
16:58:12 <mordred> hongbin: c) figure out coreos
16:58:12 <eghobo> mordred: I started CoreOS one, it will be basic from CoreOS with couple executable, all other pieces in containers
16:58:27 <hongbin> mordred: Thanks for the summary :)
16:58:47 <hongbin> We have 2 min left
16:58:48 <mordred> eghobo: so, for coreos, you'd use the downloaded coreos microimage right? that is small enough I could imagine us pre-caching it on image
16:58:52 * mordred goes to check on that
16:59:28 <mordred> coreos download is 186M
16:59:34 <mordred> which is certainly better than 800M
16:59:38 <daneyon_> mordred +1 on pre caching the image
17:00:02 <mordred> so, if magnum decides to use coreos instead of atomic, I think we can just talk about pre-caching
17:00:03 <eghobo> mordred: correct, but CoreOS cloud image is 400M
17:00:13 <hongbin> We are running out of time. Let's wrap up. Overflow at the #openstack-containers channel
17:00:15 <mordred> eghobo: that's fine - we only have to cache the bzipped thing
17:00:20 <daneyon_> lets move the discussion to the magnum irc channel
17:00:26 <Kennan> I think we not decice to use coreos now
17:00:34 <daneyon_> bye!
17:00:38 <hongbin> All. Thanks for joining hte meeting. Our next meeting is next week the same time
17:00:42 <hongbin> #endmeeting