22:01:42 <sdake> #startmeeting containers
22:01:43 <openstack> Meeting started Tue Aug 25 22:01:42 2015 UTC and is due to finish in 60 minutes.  The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:01:47 <openstack> The meeting name has been set to 'containers'
22:01:51 <sdake> #topic rollcall
22:01:52 <eghobo> o/
22:01:55 <x3k> o/
22:01:55 <sdake> o/ folks :)
22:01:58 <rods> o/
22:01:59 <Tango> o/
22:01:59 <yuanying-alt> o/
22:01:59 <thomasem> o/
22:02:05 <suro-patz> o/
22:02:14 <apmelton> o/
22:02:22 <daneyon> o/
22:02:24 <sdake> i'll wait a couple more mins
22:02:43 <hongbin_> o/
22:03:00 <vilobhmm1> o/
22:03:16 <sdake> nice looks like we have a small army to start :)
22:03:23 <sdake> #topic announcements
22:03:38 <Tango> You are not going to greet everyone like Adrian does?  :)
22:03:50 <sdake> tango tool azy :)
22:04:00 <daneyon> lol
22:04:08 <sdake> Madhuri has a family emergency and will be AFK for 1-4 weeks
22:04:26 <sdake> this means people need to pick up her work if possible
22:04:38 <sdake> yuanying-alt has already agreed to continue on the tls work
22:04:45 <sdake> but we will need more horsepower here ;)
22:04:49 <sdake> #2
22:05:30 <sdake> liberty-3 release is around this time, and rc1 deadline is typically september 25th for 6mo release cycle projects
22:05:44 <sdake> we are not a 6 mo release cycle project so we have freedom to decide our own mielstones
22:05:59 <sdake> but I'd encourage people to think of the drop dead date as september 25th :)
22:06:10 <sdake> i'll speak with adrian about whether he wants to make a rc1 milestone in launchpad
22:06:17 <sdake> with a target of rc1
22:06:38 <sdake> any other announcements from community cats?
22:07:08 <sdake> ok then :)
22:07:20 <sdake> #topic define ODS sessions for Tokyo
22:07:47 <sdake> we need to produce a list of our sessions for Tokyo - last year we got 4 fishbowl sessions and 8 unnamed sessions which are technical in nature
22:07:51 <sdake> the venue this year is smaller in size
22:07:59 <sdake> so we may not get as many sessions
22:08:08 <sdake> but we need to have a count asap
22:08:15 <sdake> so I'd like to spend some time generating our list
22:08:39 <sdake> https://etherpad.openstack.org/p/magnum-tokyo-summit-sessions
22:08:52 <sdake> 12 minute time box until 3:20
22:09:02 <sdake> please brainstorm any sessions you would like to discuss
22:09:08 <sdake> in the etherpad
22:09:17 <sdake> dont worry about sorting into fishbowl vs nonfishbowl
22:09:24 <sdake> adrian or I will do that
22:11:16 <sdake> note we will have another one of thexe sessions snext wednesday to wrap up the sessions
22:12:12 <sdake> if your here please participate ;)
22:12:18 <sdake> add your name to participants list
22:12:24 <sdake> even if you have no sessiont o add
22:12:41 <sdake> this will give us idea who contributed - so we know if we have critical mass for the submissions :)
22:12:43 <muralia> o/
22:12:52 <sdake> line 6 needs attention by folks not in 2-6 :)
22:12:58 <sdake> rather line 7
22:13:38 <sdake> 7 minutes to go :)
22:14:31 <sdake> whoever added line 6 could you define "other options" please :)
22:15:18 <Tango> I don't have one in mind, just to encourage people to think of something other than Manila
22:15:35 <Tango> Maybe I will have some thought later
22:16:38 <sdake> ok ok i can already tell we will have more sessions then we have space for
22:16:43 <sdake> next meeting we will stack rank em
22:16:52 <sdake> or if adrian has some other idea he can do that :)
22:16:59 <sdake> keep brainstorming :)
22:17:18 <sdake> t-3 minutes
22:18:27 <sdake> not eeach of these sessions is 40 minutes in length
22:18:31 <sdake> not/note
22:19:42 <sdake> ok 1 minute left, if you contributse please add your name to line 10
22:20:53 <daneyon> back
22:22:27 <sdake_> #topic networking team update
22:22:44 <sdake_> ok guys the irc bot won't change the topic
22:22:50 <sdake_> because my nick doesn't match
22:22:58 <daneyon> no worries
22:23:01 <sdake_> daneyon can you give a networking subtaem update
22:23:20 <daneyon> I didn't think i was going to make the meeting today, so I provided an update through the ML
22:23:23 <daneyon> #link http://osdir.com/ml/openstack-dev/2015-08/msg01630.html
22:23:39 <sdake_> can you give us the 5 minute tldr versoin :)
22:23:43 <daneyon> Instead of rehashing, i'll give everyone some time to pull the link up and review
22:23:54 <daneyon> ok
22:24:15 <daneyon> In summary, the container networking model spec merged. That was big
22:24:20 <sdake> #topic networking subteam update
22:24:29 <daneyon> #link https://review.openstack.org/#/c/204686/
22:24:32 <sdake> nice job daneyon!!
22:24:42 <daneyon> thanks everyone for your contributions!!!!
22:24:44 <sdake> and nice job all the core reviewers for spending the cycles to review that spec ;)
22:25:00 <sdake> specs are evil evil things but in this case necessary
22:25:01 <daneyon> i have created bp's for each work item in the spec
22:25:11 <daneyon> i have also started to create wip patches for the work items
22:25:25 <sdake> daneyon one question will this work complete before september 25th?
22:25:38 <daneyon> i have seen some of the initial feedback of the patches and will start providing updates to the wip's
22:25:58 <daneyon> sdake I think it's 50/50
22:26:09 <sdake> ok well i would recommend in that case not breaking the implementation that is there
22:26:18 <daneyon> i am working though the labels aspect of the spec
22:26:19 <sdake> and we can push into mitaka if necessary
22:27:05 <daneyon> I am reviewing how other OS projects have similar implementations to see if anything can be used as a model
22:27:05 <sdake> all done?
22:27:23 <daneyon> will do
22:27:24 <daneyon> thx
22:27:31 <sdake> #topic horizon UI update
22:27:39 <sdake> anyone have updates on this work?
22:28:06 <sdake> bradjones seems afk - it hink he is in EMEA so probably fast asleep
22:28:18 <sdake> #topic TLS update
22:28:37 <sdake> yuanying-alt apmelton any updates here?
22:28:47 <apmelton> I've got a little update from the barbican meeting
22:28:54 <sdake> if we complete one piece of work before september 25th, it needs to be this ;)
22:29:16 <apmelton> I asked about where the work stood for being able to create CA's with barbican
22:29:19 <yuanying-alt> I'm not familir with project_config
22:29:21 <apmelton> they pointed me towards https://review.openstack.org/#/c/187236/
22:29:42 <apmelton> and the guy working on it said it'd likely be 3+ weeks
22:30:15 <sdake> ok well we aren't waiting
22:30:21 <sdake> make a solution that doesn't involve barbican plz
22:30:23 <apmelton> so it's definitely looking like magnum as a CA is definitely the best bet
22:30:31 <sdake> 3 weeks is september 25th, we have no time to do integration
22:30:48 <sdake> it doesn't have to be perfect
22:31:07 <sdake> the requirements are secure to the best of our ability and isolates bays from one another
22:31:20 <apmelton> from my understanding of where they were, magnum as a ca is the approach they were taking
22:31:20 <sdake> yuanying-alt what od you need re project-config?
22:31:33 <yuanying-alt> I want to add barbican to gate
22:31:46 <yuanying-alt> but barbican seems something diffrerent
22:31:48 <sdake> as i mentioned madhuri wont be able to contribute to this effort much over the next few weks
22:32:04 <sdake> yuanying you mean to pass functional tests?
22:32:08 <yuanying-alt> yes
22:32:16 <sdake> I can help you get aquainted with the gate after the meeting if you have time
22:32:26 <yuanying-alt> So I think we should modify project-config right?
22:32:34 <yuanying-alt> ok, thanks
22:32:36 <sdake> yuanying-alt possilby
22:32:47 <sdake> #action sdake to walk yuanying-alt through how gating works
22:33:04 <sdake> ok so barbican is off the table as a ca, we need to use magnum as a ca
22:33:16 <sdake> just because barbican wont' be ready in time for our deadlines
22:33:33 <sdake> yuanying-alt does that change your approach?
22:33:59 <yuanying-alt> we want to barbican to store secret not a ca
22:34:12 <sdake> i see so still needed for ca storage then
22:34:16 <sdake> if that part works, that wfm
22:34:30 <sdake> so yuanying-alt apmelton  is working on this project
22:34:35 <apmelton> yuanying-alt: please let me know if you need help anywhere, it'll be very easy to get things on my end reprioritized to help out
22:34:43 <sdake> any person willing to step up and contribute here as well?  This is our #0 priority!
22:35:01 <yuanying-alt> keystone trust is remaining
22:35:14 <yuanying-alt> for implementing tls work
22:35:26 <apmelton> I think muralia has a good idea of what's required for keystone trust
22:35:30 <sdake> i don't recall who was doing that work, but adrian knows the person
22:35:42 <muralia> ya, i was looking into that.
22:35:45 <sdake> muralia areyo u doin gthat work?
22:35:46 <muralia> i can work on that
22:35:47 <hongbin_> I know a guy can possibly work on keystone trust
22:35:51 <sdake> is there a blueprint on it?
22:35:55 <muralia> not yet
22:36:03 <sdake> muralia please file a blueprint today
22:36:09 <muralia> will do.
22:36:15 <sdake> and I'll assign you to it
22:36:27 <sdake> this is a dependency of tls so needs to be pulled in to whatever release we are doing next :)
22:36:35 <muralia> ok
22:36:39 <hongbin_> sdake: wanghua is also working on keystone trust as well
22:36:40 <sdake> and needs to be done sooner rather then later
22:36:45 <sdake> what is the timeline on this?
22:36:52 <hongbin_> he need keystone trust for registryv2 bp
22:37:05 <muralia> i'll sync up with wanghua
22:37:09 <sdake> hongbin_ good to know can you reach out to him to get him to sync with muralia?
22:37:17 <hongbin_> sure
22:37:23 <sdake> no sense two people doing same job
22:37:33 <sdake> any other tls dependencies that need addressing
22:37:35 <sdake> ?
22:37:51 <hongbin_> so for keystone trust
22:37:58 <hongbin_> It can be splitted into two parts
22:38:06 <hongbin_> 1. keystone v3 support
22:38:09 <hongbin_> 2. trust
22:38:23 <hongbin_> We can have two person to work on those items
22:38:27 <sdake> hongbin_ instead of muralia filing a blueprint, could you file two for those two items?
22:38:35 <hongbin_> sure
22:38:46 <sdake> sounds like muralia you could add keystone v3 support?
22:38:48 <muralia> i think there is a v3 client alreay. it just needs to be used. i've also seen a method for generating trusts.
22:39:22 <yuanying-alt> agree
22:39:43 <sdake> doen't api need support for v3?
22:39:53 <hongbin_> It uses v2 right now
22:40:02 <sdake> hongbin when you file those bugs please bring them into the liberty-3 milestone
22:40:07 <sdake> rather those blueprints
22:40:20 <hongbin_> sdake: OK
22:40:43 <sdake> ok any other updates there, ounds like we are blocked on keystone and project-config atm
22:41:31 <sdake> yuanying-alt does tls work outside the  gate - meaning all we have to do is enable barbican support in the gate?
22:41:49 <yuanying-alt> yes
22:41:57 <sdake> well that is fantastic news1
22:42:02 <sdake> 1
22:42:03 <sdake> !
22:42:04 <sdake> shift key bust
22:42:16 <sdake> ok any other discussion on this topic?
22:42:23 <sdake> yuanying-alt i will help you with project config after meeting
22:42:30 <sdake> dont go anywhere plz :)
22:42:31 <yuanying-alt> ok
22:42:43 <yuanying-alt> sure
22:43:06 <sdake> #topic updating to kubernetes 1.0 in our images/heat templates/documentation/devstack
22:43:19 <sdake> Tango where are you with this work?
22:43:30 <sdake> this is also a must have for liberty
22:43:44 <Tango> I built a new image with release 1.0.3 and the recommended version of flannel, etcd
22:43:51 <Tango> and docker 1.7.1
22:44:04 <hongbin_> I am helping Tango for the k8sclient port
22:44:08 <Tango> Docker requires a little tweaking on the storage
22:44:13 <sdake> hongbin_ fantastic!
22:44:19 <apmelton> Tango: is that docker 1.7.1 from docker or redhat?
22:44:24 <sdake> i think we need a blueprint to track this work
22:44:31 <sdake> tango could you file one plz
22:44:40 <Tango> Not sure, I pick up from kojipkj
22:44:49 <sdake> apmelton yes from red hat
22:44:57 <hongbin_> Tango: any problem with the release 1.0?
22:45:04 <Tango> OK, right now it's a bug, but I will open a blueprint
22:45:21 <sdake> ya blueprint makes sense because we will have to do api work too
22:45:24 <sdake> i know i siad bug before
22:45:36 <sdake> my brain wasn't working properly at the time :)
22:45:45 <Tango> The current image was built with a prerelease version, so the new image is more "official", using the latest release
22:46:03 <sdake> tnago does the new image work with the current heat templates, or is work neeeded there?
22:46:07 <sdake> tango that is ^^
22:46:37 <hongbin_> Tango: are you going to build another image or using the *-4 image?
22:46:38 <Tango> There is a couple patches to update the templates.  I am updating the functional test, and adding a test for load balancer
22:47:23 <sdake> ok just so we are clear, priority #1 is tls, priority #2 is running with kubernetes 1.0, priority #3 is everything in the launchpad tracker (from my perspective)
22:47:40 <sdake> adrian may hae a different take
22:47:46 <Tango> hongbin_: I am debugging the new image now, getting docker storage to work.  When it's working, I will pass to sdake to upload and replace the current copy -4
22:47:59 <hongbin_> Tango: get that
22:48:00 <sdake> i'll make a copy -5
22:48:02 <sdake> actually
22:48:09 <daneyon> Tango is their just 1 review for the k8s 1.0 update?
22:48:11 <sdake> so expect the image to be named -5
22:48:17 <Tango> ok sure
22:48:23 <daneyon> I want to make sure my network stuff is implemented with your 1.0 work
22:48:32 <sdake> we need changes to the heat templates, image, devstack, and api code for kuberntes 1.0
22:48:44 <sdake> this is why it needs to be a blueprint
22:48:47 <Tango> daneyon: That's ok, the change is not big
22:48:53 <hongbin_> also the k8sclient needs to be re-generated
22:49:06 <daneyon> do u have a link to the review that you can share?
22:49:26 <daneyon> i want to make sure i'm using the right patch(es) for 1.0
22:49:56 <Tango> daneyon: https://review.openstack.org/#/c/210641/
22:50:02 <daneyon> Tango thx
22:50:08 <Tango> This one will pick up the others
22:50:37 <sdake> #action tango to create a blueprint for the kuberntees 1.0 port and include devstack, image creation, k8sclient regen, heat templates in it
22:50:48 <Tango> will do
22:50:57 <sdake> #topic open discussion
22:51:05 <x3k> I have a question on the topic of versioned objects
22:51:12 <sdake> we have 9 minutes for whatever folks would like to discuss
22:51:18 <x3k> I noticed that right now, when we make changes in magnum/objects, we don't change object version
22:51:18 <hongbin_> sdake: I want to get back to the magnum-ui
22:51:19 <sdake> shoot x3k
22:51:32 <x3k> but the idea of objects is that each change in their fields should be versioned
22:51:36 <sdake> hongbin_ your next up
22:51:39 <x3k> documentation about the change should also be written in a comment inside the object
22:51:46 <x3k> and the obj_make_compatible method should be implemented/updated
22:52:03 <x3k> see an example here: https://github.com/openstack/nova/commit/ad6051bb5c2b62a0de6708cd2d7ac1e3cfd8f1d3#diff-7c6fefb09f0e1b446141d4c8f1ac5458L27
22:52:09 <sdake> x3k can you submit patches for the work if something is missing with a bug or blueprint?
22:52:11 <x3k> so the question is, do you think magnum should support rolling upgrades f.ex. from next release?
22:52:26 <sdake> i thikn rolling upgrades are a big job
22:52:33 <sdake> but that is the end goal yes
22:52:34 <x3k> if yes, I think core reviewers should start checking for these incompatible changes
22:52:38 <sdake> by liberty - who knows :)
22:53:02 <sdake> x3k this is first i've heard about it, perhaps a mailing list thread would be helpful
22:53:11 <sdake> x3k our cr team is spread around the globe
22:53:42 <x3k> sdake, ok, I'll start discussion and maybe submit bug reports
22:53:46 <sdake> a mailing lis tthread would be best to make the core reviewers aware of it
22:54:05 <sdake> #action x3k to start ml thread on versioned objects review objectives
22:54:19 <sdake> hongbin_ your up :)
22:54:31 <x3k> but maybe it's still too early (for fixing this now, in this release)
22:54:46 <sdake> lets get a thead started and make a decision
22:54:52 <hongbin_> Yes, for the mgnum-ui, I saw brad is submitting two patches, but lack of reviews
22:54:57 <sdake> atm there is no decesion because there has been no complaint :)
22:55:10 <hongbin_> magnum-ui has a lot of cores. We need to ping them to review :)
22:55:38 <sdake> sounds like an action for adrian otto :)
22:55:51 <daneyon> lol
22:55:53 <sdake> #action adrian_otto to ping all magnum-ui core reviewers to review bradjones magnum ui patches
22:56:03 <Tango> I have talked to Thai Tran, he will use my environment to try out the patches and help with review
22:56:13 <sdake> tango that would be much appreciated :)
22:56:19 <vilobhmm1> sdake : regarding object from bay have proposed a WIP https://review.openstack.org/#/c/213368/ would like to get feedback on it…if this way seems good I can send out patches for service, pod
22:56:52 <sdake> vilobhmm1 send me an email stdake@cisco.com and I willge tto it tomororw -t he rest of my day is slammed today
22:57:00 <sdake> email = wont lose it or forget :)
22:57:10 <vilobhmm1> sdake : Thanks :) will do.
22:57:30 <sdake> 3 more minutes :)
22:58:39 <sdake> ok if nothing else, keep up the good work, stay focused on tls + kube 1.0 support
22:59:00 <sdake> need to see thoe blueprints filed so we can track them and set them as essential as discussed in the meeting
22:59:15 <Tango> yep
22:59:20 <sdake> please link them in #openstack-containers if you don't have permissions to tag to liberty-3 release
22:59:32 <sdake> ok times out :)
22:59:34 <sdake> thanks folks!
22:59:36 <sdake> #endmeeting