18:03:36 <daneyon_> #startmeeting container-networking
18:03:37 <openstack> Meeting started Thu Jul 16 18:03:36 2015 UTC and is due to finish in 60 minutes.  The chair is daneyon_. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:03:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:03:40 <openstack> The meeting name has been set to 'container_networking'
18:03:47 <daneyon_> suro-patz thx
18:03:51 <s3wong> hello again :-)
18:03:57 <daneyon_> #topic roll call
18:04:02 <daneyon_> o/
18:04:05 <suro-patz> o/
18:04:06 <sicarie> o/
18:04:09 <s3wong> o/
18:04:15 <hongbin> o/
18:04:19 <SourabhP> o/
18:04:33 <Tango|2> o/
18:05:11 <daneyon_> thx all for joining
18:05:15 <daneyon_> #topic Continue the collaborative brainstorm session in etherpad
18:05:24 <daneyon_> #link https://etherpad.openstack.org/p/magnum-native-docker-network
18:05:53 <daneyon_> I have spent a good amount of time the last few days in the proposed change section
18:06:23 <daneyon_> Lets spend the next 15 min reviewing the Problem description and proposed change sections
18:07:04 <daneyon_> Please review Example 2 in the Problem description section
18:08:35 <daneyon_> please also review the Design Principles, alternatives and data model sections
18:08:44 <daneyon_> I just started on the data model impact
18:09:27 <daneyon_> Those with a longer history with Magnum, I could really use your input on how the proposed changes will effect the data model
18:10:54 <eghobo> o/
18:11:25 <suro-patz> the CIDR used in network_backend, is it going to be public or private?
18:11:56 <suro-patz> daneyon_
18:12:34 <suro-patz> we should provide an option to create a backend_network object/instance
18:12:59 <suro-patz> and refer the same during baymodel creation
18:13:40 <daneyon_> suro-patz can u pls elaborate on the object/instance?
18:13:58 <daneyon_> it may be better to do so in the ep
18:14:25 <suro-patz> I meant we could have 'magnum network_backend-create' with various options of KV pairs
18:14:48 <suro-patz> that way we can use the same backend, if required, to create various baymodels
18:15:58 <daneyon_> suro-patz take a look at where i talk about labels in the proposed changes section
18:15:58 <Tango|2> You mean something like a model to represent the backend network, that can be shared/reused?
18:16:12 <suro-patz> Tango|2
18:16:31 <daneyon_> all, I am still debating whether adding the network_backend or just using labels to pass everything
18:17:05 <hongbin> I think network_backend makes sense
18:17:17 <suro-patz> if we instantiate it becomes clear compartmentalization by individual instance and reference
18:17:30 <daneyon_> then labels are used to pass in metadata/config to the backend
18:17:50 <daneyon_> labels can be used for other purposes for similar reasons outside of network_backend
18:18:01 <suro-patz> else to access the the flannel params of a baymodel, baymodel will be the container of all the attributes
18:18:23 <daneyon_> it seems like labels are becoming the standard way to pass md to docker daemon/containers/images, k8s, etc..
18:18:59 <hongbin> daneyon_: It is better to design the lable for general purpose
18:19:09 <daneyon_> i think so
18:19:22 <hongbin> For example, it can be used by the whole template, not just network
18:19:43 <daneyon_> i wonder if general purpose labels should be a different spec that the network spec depends on????
18:19:59 <hongbin> Maybe a different BP
18:20:07 <Tango|2> Sounds like it if we want to generalize
18:20:12 <daneyon_> hongbin right. I called that out in the changes section of the ep spec.
18:20:46 <daneyon_> I would like labels to be a top level object that is utilized by the entire magnum system
18:21:35 <Tango|2> So to use labels, the keys would be well defined constant documented somewhere?
18:22:03 <daneyon_> the propsed changes section identifies 6 major changes
18:22:22 <daneyon_> pls review 1-6 and let me know what you think
18:22:29 <daneyon_> am i missing somehting?
18:22:31 <suro-patz> To me the modeling looks very similar the way we have it for —coe kubernetes'
18:23:07 <daneyon_> I will pull out labels, create a seperate bp and have the net spec refer to the labels bp as a dependency
18:23:26 <hongbin> sounds good
18:24:14 <hongbin> Another question, are we going to have another network_backend called neutron, or not?
18:24:23 <daneyon_> without labels, we could support multiple network backends but just not be able to configure the backens until labels is implemented
18:25:01 <daneyon_> hongbin at this point I am unsure.
18:25:31 <hongbin> daneyon_: K. It may need a bit research to figure it out
18:25:39 <daneyon_> i see container networking and openstack networking as 2 entities and I am still trying to identify the integration point
18:25:51 <SourabhP> hongbin: what does network_backend called neutron represent? An integration point?
18:26:09 <daneyon_> their is 1 example that i have been thinking of that points to neutron integration
18:26:13 <daneyon_> vlans
18:26:17 <SourabhP> daneyon_: there’s a neutron networking sub-project called Kuryr that’s been proposed for integration
18:26:24 <daneyon_> their is a neutron bp to implement vm-aware vlan's
18:27:14 <daneyon_> if we want to map these vm vlan's to containers to extend the vlan-based isolation into the container, then we will need the container network to intgrate with the neutron network
18:27:35 <SourabhP> https://github.com/celebdor/neutron-docker-plugin
18:27:37 <daneyon_> however, I don;t see vlan-based isolation being that important
18:27:57 <daneyon_> because of vxlan annd other prefered overlays/isolation mechanisms
18:28:40 <daneyon_> SourabhP thx for sharing
18:28:53 <daneyon_> #link https://github.com/celebdor/neutron-docker-plugin
18:29:20 <daneyon_> SourabhP can u pls add it to the ep with a brief description?
18:29:44 <daneyon_> SourabhP i'll spend time diving in after the meeting, OK?
18:30:17 <SourabhP> daneyon_: yes, will do. The relevant discussion happened on the openstack-dev ML.
18:30:21 <daneyon_> SourabhP do you want to take a few min and discuss the project?
18:30:50 <daneyon_> SourabhP it would be helpful to add a pointer to the ML discussion in the ep too
18:31:11 <SourabhP> daneyon_: I haven’t yet studied it in much detail yet. I will add the relevant links.
18:31:23 <daneyon_> OK, thx
18:32:05 <daneyon_> #action everyone on the subteam to review the neutron-docker-plugin project
18:33:08 <s3wong> seems to only have document but no code
18:33:24 <daneyon_> I could really use some help from someone to understand the Data model impact from network_backend
18:33:47 <daneyon_> yup
18:34:08 <daneyon_> I believe Antoni has been on the magnum irc channel
18:35:04 <daneyon_> this is the home stretch to submit the spec
18:35:27 <daneyon_> I will be spending most of my time to complete the initial draft and submit it.
18:35:46 <hongbin> The data model makes sense to me.
18:36:02 <daneyon_> #action danehans to submit draft network spec on July 22, 2015
18:36:16 <hongbin> Just one point, we don't have to use different heat template for different network backends
18:36:32 <daneyon_> hongbin should i elaborate on anything?
18:37:00 <hongbin> We may use a single heat template for all network backend.
18:37:41 <daneyon_> pls look at line 250, where SourabhP discussed registering network_backends
18:38:08 <daneyon_> again, this could be a seperate bp, as I could see the need for magnum to have an overall plugin registration/mgt process
18:39:54 <daneyon_> making networking in M pluggable is going to have an impact on the heat templates
18:40:09 <daneyon_> for example> flannel can not longer be embedded
18:40:15 <daneyon_> no
18:40:57 <hongbin> Actually I am thinking of the integration point
18:41:17 <daneyon_> i see cloud-config is being used to explicitly setup flannel and flannel is embedded in the TL k8s yml's
18:41:18 <hongbin> An option is a Heat resource to abstract out different network backends
18:41:35 <daneyon_> does anyone see any issues with making networking pluggable within the heat templates?
18:41:56 <suro-patz> daneyon_ +1
18:42:14 <Tango|2> +1
18:42:19 <hongbin> This could avoiding splitting templates for different backend
18:42:52 <daneyon_> hongbin that is what i'm thinking too
18:43:19 <Tango|2> It will probably take some experimenting to arrive at a good template design
18:43:32 <daneyon_> all, pls add your ideas to 5 in proposed changes section
18:43:48 <daneyon_> Tango|2 agreed
18:44:12 <daneyon_> I think the best 1st step is removing flannel from the core k8s templates
18:44:19 <daneyon_> this is similar to what Docker did with libnetwork
18:44:40 <daneyon_> provide the same functionality, but in a seperate library
18:44:52 <Tango|2> Yep, that would be a good exercise to see how to refactor further
18:46:10 <daneyon_> I would like to take a quick vote then
18:46:57 <daneyon_> on seperating flannel from core templates as one of the 1st steps
18:47:06 <daneyon_> from the spec for #5
18:47:54 <Tango|2> So does this imply having an option that's not flannel?
18:48:16 <Tango|2> or just refactoring?
18:48:19 <daneyon_> yes.. this is what the magnum networking model is all about
18:48:52 <daneyon_> magnum should have the ability to support various container networking tools and techniques
18:49:11 <daneyon_> this is the batteries included but replaceable.
18:49:13 <suro-patz> btw, kubernetes can do multihost networking with flannel, of its own, by allocating individual subnet on each host, and adding route for other subnets
18:49:35 <daneyon_> although flannel will be pulled from core k8s templaates, it will continue to be the default
18:50:06 <sicarie> +1 for me then - sensible default that's able to be swapped out
18:50:15 <suro-patz> daneyon_: do we have a need to keep flannel as default? As kube can do by itself
18:50:16 <daneyon_> so if a user creates a new baymodel, specifies the coe=kubernetes and does not specify a network_backend, flannel will be chosen
18:50:19 <daneyon_> make sense?
18:50:30 <SourabhP> +1
18:50:31 <daneyon_> suro-patz pls see above
18:50:47 <Tango|2> +1
18:51:32 <daneyon_> hongbin does the above make sense to you too?
18:51:43 <suro-patz> I agree to refactor and make flannel optional, but I am saying it need not be default
18:51:48 <hongbin> daneyon_: Yes, definite
18:52:00 <Tango|2> Do we know if anyone has tried a different overlay network with Kubernetes?
18:52:05 <daneyon_> OK, I think we are in agreement.
18:52:20 <daneyon_> Does anyone -1 this approach?
18:52:25 <daneyon_> pls speak up if so.
18:52:46 <daneyon_> Otherwise, feel free to add to the spec sections in the etherpad
18:53:26 <daneyon_> hongbin and all what do you think about having to register plugins?
18:53:57 <daneyon_> If so, I think it may make sense to have as a seperate bp
18:54:31 <hongbin> daneyon_: don't follow sorry
18:54:41 <daneyon_> I could see the network plugin framework be adopted as a larger effort across magnum and other plugins for storage, etc.. would follow the same registration process
18:54:46 <sicarie> +1 to separate bp - it sounds like there's other stuff going on there that may need to be aligned with other efforts
18:55:03 <daneyon_> hongbin look at line 250 of the ep
18:55:25 <s3wong> sure, let's punt that to another spec (and when Magnum has a more generic framework)
18:55:46 <daneyon_> i think registering plugins make sense, i just think it should be a seperate bp bc it has a wider impact than just the network spec
18:56:03 <Tango|2> We should bring this up for discussion on the ML
18:56:11 <daneyon_> will do
18:56:35 <daneyon_> SourabhP do you want to start the plugin registration ML thread or would you like me to?
18:57:04 <SourabhP> daneyon_: pls go ahead
18:57:34 <daneyon_> #action danehans to start a ML discussion related to plugin registration and an overall plugin framework
18:57:41 <daneyon_> we are winding down the meeting
18:57:59 <daneyon_> i really appreciate everyone's participation
18:58:17 <sicarie> almost unrelated news: http://googlecloudplatform.blogspot.tw/2015/07/Containers-Private-Cloud-Google-Sponsors-OpenStack-Foundation.html
18:58:27 <Tango|2> Do we need another meeting to finalize ?
18:58:57 <daneyon_> +1 or -1 to meet at the same bat time on the same bat channel next week?
18:59:05 <daneyon_> +1
18:59:06 <sicarie> +1
18:59:08 <hongbin> +1
18:59:11 <SourabhP> +1
18:59:11 <dane_leblanc> +1
18:59:11 <Tango|2> +1
18:59:12 <s3wong> +1
18:59:21 <daneyon_> will do
18:59:36 <daneyon_> lets keep in touch on the magnum irc channel
18:59:50 <daneyon_> thank you for your time!
19:00:03 <daneyon_> and see you all back here next week
19:00:15 <daneyon_> #endmeeting