16:02:22 <adrian_otto> #startmeeting containers
16:02:22 <openstack> Meeting started Tue Mar 31 16:02:22 2015 UTC and is due to finish in 60 minutes.  The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:25 <openstack> The meeting name has been set to 'containers'
16:02:28 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-03-31_1600_UTC Our Agenda
16:02:33 <adrian_otto> #topic Roll Call
16:02:34 <diga_> Digambar Patil
16:02:36 <adrian_otto> Adrian Otto
16:02:37 <apmelton> o/
16:02:40 <sdake> o/
16:02:51 <hongbin> o/
16:03:26 <sew1> o/
16:03:30 <sew1> Steven Wilson
16:03:41 <thomasem> Thomas Maddox
16:03:47 <adrian_otto> sdake: before I get to the announcements section, are you willing to chair on 4/7 at 2200 UTC? I will be out on that day.
16:03:52 <juggler> Perry
16:03:58 <sdake> adrian_otto ack wfm
16:04:02 <adrian_otto> tx
16:04:41 <Tango|2> hi
16:04:54 <sdake> hey tango
16:04:58 <sdake> just the cat I wanted to talk to :)
16:05:03 <sdake> can you hit me up after the meeting
16:05:07 <Tango|2> Hi Steve
16:05:14 <Tango|2> sure
16:05:21 <adrian_otto> hello diga, apmelton, hongbin, sew1, thomasem, juggler, sdake, Tango|2
16:05:29 <adrian_otto> #topic Announcements
16:05:59 <adrian_otto> 1) I will be away on 2015-04-07, so sdake has agreed to char for us for our team meeting on that day.
16:06:07 <adrian_otto> 2) Elections
16:06:23 <adrian_otto> we will be part of the OpenStack elections for PTL, so we will not be conducting our own election.
16:06:34 <adrian_otto> 3) Design Summit
16:06:55 <adrian_otto> Magnum will have it's own "track?" at the Vancouver Design Summit
16:07:33 <adrian_otto> soon there will be a call for topics, so keep an eye out for that. I am open to proposals from all of you. I know that container networking would be a good one to put high on the priority list
16:07:47 <adrian_otto> any questions about the announcements above?
16:07:51 <sdake> agree on container networking
16:08:01 <sdake> election dates
16:08:12 <sdake> when are they ?
16:08:22 <suro-patz> adrian_otto: I want to volunteer for the container networking
16:08:41 <adrian_otto> #link https://wiki.openstack.org/wiki/PTL_Elections_April_2015 Election Details
16:08:43 <sdake> suro-patz y ou have to know what your volunteering for first :)
16:08:52 <adrian_otto> sdake: the above link has the specifics about that
16:08:54 <juggler> sdake lol
16:08:56 <suro-patz> if you guys can put more description of the problem it will be better
16:09:05 <sdake> adrian_otto I know the dates was for benefit of others ;) thanks
16:09:22 <sdake> suro-patz we dont have a better description :)
16:09:23 <adrian_otto> suro-patz: yes, that will be a big deal to get right
16:10:09 <adrian_otto> we will need to do a focusing exercise to put a label on our long term vision, and an incremental plan to advance us toward it in small steps
16:10:32 <adrian_otto> but at a very high level, we want it to be easy to link containers across a network in a way that is consistent with other tools
16:11:18 <diga_> yes, that is required now onwards
16:11:32 <adrian_otto> any other announcements from team members?
16:11:52 <sdake> I got one
16:11:56 <adrian_otto> I will mention for those of you who missed the last meeting...
16:11:58 <sdake> sorry to cross-spam :)
16:12:06 <adrian_otto> sdake: just one sec
16:12:27 <adrian_otto> Magnum has joined the OpenStack projects list, and has moved from the stackforge git namespace to the openstack git namespace.
16:12:40 <adrian_otto> if you have any questions about that, please see me, and I'd be happy to help.
16:12:45 <adrian_otto> sdake: all yours.
16:12:47 <sdake> The kolla effort (containerize openstack) has created a new irc channel #kolla - please join if you have interest in containerizing openstack
16:12:55 <sdake> also python-magnumclient has moved as well :)
16:13:16 <adrian_otto> yes! I should not treat it as a stepchild
16:13:36 <adrian_otto> #topic Review Action Items
16:14:05 <adrian_otto> 1) ACTION: adrian_otto to check to see if Magnum may participate in the April 4 - April 11: PTL elections. (http://eavesdrop.openstack.org/meetings/containers/2015/containers.2015-03-24-22.00.log.html#l-261, 22:51:25)
16:14:13 <adrian_otto> Status: Completed. See above.
16:14:23 <diga_> sure sdake
16:14:29 <adrian_otto> #topic Blueprint/Task Review
16:14:56 <adrian_otto> this is the section where we can discuss any blueprint or bug/task ticket
16:15:15 <adrian_otto> we have a new blueprint worth mentioning. diga, do you want to present it?
16:16:15 <diga_> adrian_otto: you know that work, I think you can initiate
16:16:30 <adrian_otto> ok, getting the link. one sec
16:17:03 <diga_> https://blueprints.launchpad.net/magnum/+spec/add-glance-image-properties-supporthttps://blueprints.launchpad.net/magnum/+spec/add-glance-image-properties-support
16:17:19 <diga_> type mstake - https://blueprints.launchpad.net/magnum/+spec/add-glance-image-properties-support
16:17:23 <diga_> see this
16:17:45 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/add-glance-image-properties-support Add Glance Image Properties support for Magnum
16:18:28 <adrian_otto> ok, so this is a follow-on from last weeks conversation about BayModel, and expansions on that concept to support multiple bay types
16:18:47 <sdake> diga_ looks good to me +2 :)
16:18:56 <adrian_otto> apmelton has a WIP review up for some work he is doing in this area
16:19:03 <sdake> defintiion need to go to approved
16:19:17 <adrian_otto> diga agreed to check in with apmelton
16:19:29 <diga_> thanks sdake
16:19:51 <adrian_otto> I'm not worried about duplicate work, but if you both know what each is doing, maybe we can avoid nonproductive overlap
16:19:54 <diga_> yes adrian_otto
16:19:58 <apmelton> agreed
16:20:04 <adrian_otto> diga_ and apmelton do you need anything from the team?
16:20:40 <apmelton> I think the integration point for these pieces is around the cluster_type option, and I haven't really touched that
16:20:40 <diga_> I think both of us know our area of work
16:20:45 <sdake> question diga
16:20:47 <diga_> not for now
16:20:55 <adrian_otto> ok, feel free to raise this up if you need further input
16:20:58 <sdake> once this patch is in, coreos will support what exactly?
16:21:10 <sdake> the container api or the pod api?
16:21:36 <adrian_otto> sdake: it will allow you to run kubernetes pods (bays) on coreos nodes
16:21:57 <diga_> yes
16:21:58 <adrian_otto> I don't think this reaches the container api
16:22:10 <sdake> sweet!
16:22:13 <diga_> my internet is bit slow :)
16:22:14 <sdake> i'm super excited to try it out
16:22:40 <sdake> didn't know coreos integretaed k8s directly
16:22:43 <sdake> or the template configured it - which is a pita typically :)
16:22:44 <adrian_otto> there is support for coreos in there now, but we want to improve it further before pushing it
16:23:18 <sdake> #link https://blueprints.launchpad.net/magnum/+spec/simplify-api-model
16:23:40 <sdake> this blueprint will require moving things that are in the api handlers into the rpc handlers
16:23:43 <adrian_otto> aha, yes.
16:23:47 <sdake> things like "which data to print out"
16:23:47 <sdake> etc
16:23:56 <sdake> so ai'm good with it, but it breaks abstraction a bit
16:24:19 <adrian_otto> explain more about the breakage?
16:24:38 <adrian_otto> we'll still have the same abstractions, we are just consolidating the parts they have in common, right?
16:24:40 <sdake> sec let me find example
16:25:10 <sdake> same abstractions, storing in their same places in the db, but with one api
16:25:54 <sdake> for example this needs to come  from the rpc server
16:25:56 <sdake> https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/pod.py#L72
16:26:00 <adrian_otto> that's fine with me. Does anyone else have concerns about that?
16:26:14 <sdake> there are *many* more exmples
16:26:20 <sdake> but it means our rpc api will become a bit more complex
16:26:40 <adrian_otto> are there other approaches we should consider?
16:27:10 <sdake> not sure - might be able to walk the object list - not certain how the versioned jobjects interacts with the rest api
16:27:11 <adrian_otto> having a complex RPC API really only means that it's more difficult to extend Magnum as a Magnum developer
16:27:13 <sdake> they are meant to be a 1:1 mapping
16:27:25 <sdake> well we are talking 2-3 more extra calls
16:27:35 <sdake> so its not deadly
16:27:54 <sdake> for example I need a "get_fields_unset" api call
16:28:02 <sdake> (I think?)
16:28:27 <sdake> another option is to store those fields in the db
16:28:59 <apmelton> so the point of this is to unset fields for non-detail calls?
16:28:59 <hongbin> sdake: maybe store them under 'extra' field
16:29:01 <sdake> I"m not sure, I'll have to sort it out
16:29:02 <apmelton> like list calls?
16:29:14 <sdake> apmelton right
16:29:24 <sdake> but there are other parts of the api which are model specific
16:29:36 <adrian_otto> so wait a sec
16:29:40 <sdake> and only the parser (in the rpc handler) knows about
16:29:54 <adrian_otto> the reason we are contemplating this to begin with is to simplify the object model, right?
16:30:05 <sdake> the api model
16:30:12 <sdake> the object model as is rocks
16:30:13 <adrian_otto> and to get that simplification, we need to add complexity to the RPC API
16:30:31 <adrian_otto> are we actually reducing the overall complexity, or just moving it around?
16:30:47 <adrian_otto> api, model, thanks.
16:30:48 <sdake> moving it around away from where the user sees it to where they dont see it (abstraction)
16:31:05 <adrian_otto> ok, so net benefit to API users
16:32:31 <sdake> I just want to be cleear upfront
16:32:32 <adrian_otto> ok, I'm happy with that. Any further discussion on this sub-topic?
16:32:40 <sdake> after digging into this problem for awhile
16:32:46 <sdake> I am not sure if it is even possible to do - and maintain versioned objectss support
16:32:57 <sdake> imo versioned objects is more important then simplifiying the pai
16:32:58 <sdake> api
16:33:05 <adrian_otto> agreed
16:33:17 <apmelton> +1
16:33:21 <sdake> so if Iget to the point when I know it wont work
16:33:25 <sdake> we may have to abandon the spec
16:33:34 <sdake> I'm just not sure yet
16:33:41 <adrian_otto> ok, cool
16:34:05 <juggler> re
16:34:19 <sdake> I wanted to talk about tango|2's blueprint
16:34:30 <adrian_otto> ok
16:35:00 <sdake> #link https://blueprints.launchpad.net/magnum/+spec/external-lb
16:35:08 <Tango|2> yep
16:35:24 <sdake> can you give us a progress update - at the summit it sounded like k8s changed how all this works
16:35:31 <sdake> sorry midcycle
16:35:56 <sdake> and I've heard that from others as well
16:37:02 <Tango|2> I am just starting on this, had to clear a number of things on my plate before diving into Magnum
16:37:09 <adrian_otto> oh, I failed to mention that Mark Collier (re) introduced me to the project manager for Kubernetes, Greg Mcluckie. We are having a concall on Friday morning on the topic of Kubernetes and OpenStack working together better.
16:37:25 <adrian_otto> if there is anything I can bring to the agenda to help us, please let me know.
16:37:41 <Tango|2> but you did mention that it changes, so I am going through the new details
16:38:54 <Tango|2> My plate is clear now, so I will be focusing on the blueprint
16:39:04 <adrian_otto> ok, Tango|2 is there any chance you will have a look at it before friday morning?
16:39:27 <Tango|2> yes, I am working on it now
16:39:32 <adrian_otto> I can probably connect you directly with the person(s) working on that in k8s
16:39:40 <adrian_otto> in case you have any questions
16:39:41 <Tango|2> that would be very helpful
16:39:46 <diga_> adrian_otto: good to know
16:39:51 <sdake> #google-containers irc channel is best way to reach the devs
16:39:51 <adrian_otto> ok, I'll be sure to ask about that
16:40:16 <sdake> i recommend everyone add it to their irc clients ;)
16:40:33 <adrian_otto> thanks sdake. Good suggestion.
16:40:47 <juggler> +1 sdake
16:41:01 <adrian_otto> We have a bunch of blueprints in New status
16:41:17 <adrian_otto> I plan to start looking through all those this week
16:41:37 <adrian_otto> so if there are ones you take an interest in, please subscribe and we can start fleshing them out a bit
16:41:39 <sdake> adrian_otto I added the secure kubernetes blueprint to the cycle
16:41:44 <sdake> but it looks like it got unadded
16:41:49 <sdake> a yahoo cat was going to work on it
16:41:51 <adrian_otto> hummm
16:42:16 <adrian_otto> ok, I will put that one at the top of my list
16:42:20 <sdake> has to do with adding tls support to client/server
16:42:26 <sdake> seems essential to me
16:42:33 <sdake> if we have the bandwidth to do the job
16:42:57 <adrian_otto> yeah, that's a good one
16:43:17 <sdake> he was looking for a 40-80 hr blueprint to work on
16:43:21 <sdake> and that seemed to fit the bill :)
16:43:22 <adrian_otto> does it also include some solution the key management?
16:43:40 <sdake> we have to add the client keys to the db in some way
16:43:44 <adrian_otto> generating the client cert, and putting the corresponding parts on the remote?
16:43:51 <sdake> and automate the key transfer is python-k8sclient
16:44:02 <sdake> not sure if madhuri knows if tl supported in the work she is doing or not
16:44:19 <adrian_otto> madhuri should be at our next meeting, I think.
16:44:21 <sdake> adrian_otto yup that is my thinking of how it shoud work
16:44:35 <sdake> ya middle of night for her - but like her work so far!
16:44:43 <adrian_otto> yes, that would be a solid feature
16:44:55 <sdake> if tl/if tls
16:45:04 <adrian_otto> sdake: +1 she has been doing very good work
16:45:47 <adrian_otto> ok, I'm planning to enter OpenDiscussion in a moment, but before we do, are there any other work items that need team discussion today?
16:46:35 <adrian_otto> #topic Open Discussion
16:46:56 <sdake> so lets just congratulate ourselves one more time for incubation 2.0 :)
16:47:04 * adrian_otto applause
16:47:04 <sdake> its so huge, its not even funny :)
16:47:06 <apmelton> \o/
16:47:28 <juggler> yea!
16:47:31 <sdake> next step is tagging
16:47:32 <thomasem> winning!
16:47:34 <apmelton> http://i.imgur.com/YqhPmjQ.gif
16:47:45 <thomasem> ^^ +1
16:47:55 <sdake> apmelton epic movie :)
16:48:03 <sdake> anchorman ftw
16:48:16 <apmelton> :D
16:48:34 <adrian_otto> I am happy to see new contributors streaming in… we now have 35 engineers who have merged code in our repo… representing 19+ affiliations
16:49:12 <adrian_otto> that's reviewers… let me revise for committers
16:49:21 <diga_> its a party time for magnum team :)
16:49:49 <adrian_otto> 32 engineers from 17+ affiliations
16:50:23 <adrian_otto> and the trend I am seing is that these are not just OpenStack contributors migrating over from other projects… these are new contributors joining the OpenStack ecosystem
16:50:43 <sdake> growing openstack atc = winning :)
16:50:54 <diga_> :)
16:51:35 <adrian_otto> so for all of you who have joined us recently, we are happy to have you!
16:52:13 <adrian_otto> how do you all feel we are doing with review throughput
16:52:30 <adrian_otto> do you feel like you are getting helpful feedback on your work in a timely fashion?
16:52:40 <apmelton> definitely
16:52:55 <juggler> yes
16:53:13 <sdake> review throughput is very fast in this project
16:53:17 <adrian_otto> and are we efficiently merging code that you think is ready? (not putting you through revision patchset hell)
16:53:21 <sdake> fastest I have ever seen in any project
16:53:39 <diga_> agreed
16:54:00 <sdake> I have something a bit controversial
16:54:02 <sdake> to discuss
16:54:18 <sdake> I'm finding it harder and harder to keep track of development
16:54:26 <sdake> the way projects solve these problems is through the specs process
16:54:33 <adrian_otto> yes, I think it's healthy, but we can still check for areas to improve
16:54:40 <sdake> I think its too early in magnum's lifecycle to do spec
16:54:50 <sdake> but we might want to think about it towards the end of liberty
16:55:38 <adrian_otto> sdake, so one idea might be to have a weekly review of merged code in the team meeting, or on the ML
16:55:47 <sdake> so around l3 - possibly introduce specs
16:55:57 <sdake> with the idea we will do specs in M
16:55:58 <adrian_otto> so you could get some picture of what's happening week by week if you're not doing reviews every day
16:55:59 <sdake> just a thought :)
16:56:10 <sdake> I do reviews every day
16:56:22 <adrian_otto> so what's the visibility you feel is missing?
16:56:27 <sdake> and can't keep up with development - this causes the core reviewers to lose context
16:56:34 <adrian_otto> is it that we merge it before you see it?
16:56:36 <sdake> the reviews happen so fast I miss ones that hit the repo
16:56:44 <adrian_otto> ok, I understand
16:57:07 <adrian_otto> so what about a summary?
16:57:16 <sdake> sounds like a pita to maintain :)
16:57:23 <sdake> I can live with it for now
16:57:29 <sdake> but I expect by end of liberty we will have 100atcs
16:57:35 <sdake> one hundred that is
16:57:50 <sdake> and that was hard to handle for heat
16:57:57 <sdake> (the context maintenance)
16:58:11 <sdake> in retrospect I wish for heat we had a specs process when our atcs hit the 100 mark
16:58:24 <adrian_otto> and that slows down velocity
16:58:35 <sdake> specs does slow down veloicty
16:58:40 <sdake> so not proposing for liberty
16:58:41 <adrian_otto> I will think on that further
16:58:45 <sdake> but possiby end of liberty
16:58:49 <sdake> ya everyone giveit some thought
16:58:56 <adrian_otto> ok, we can talka bout that at the summit too maybe
16:59:08 <adrian_otto> we have a few minutes left
17:00:26 <adrian_otto> our next meeting is 2015-04-07 at 2200 UTC. sdake will chair. Enjoy!
17:00:30 <adrian_otto> #endmeeting