Re: [openstack-dev] [kolla] Building Kolla containers with 3rd party vendor drivers

[Paul Bourke]

> Operators that need one or more of these “additional drivers” will be 
provided
> with documentation on how the code in the “additional drivers” path 
can be
> used to build their own containers. This documentation will also 
detail how

> to combine more than one 3rd party drivers into their own container.

Yes this sounds fine. We already have a 'contrib' directory [0], so I 
think this would align with what you're suggesting.


-Paul

[0] https://github.com/openstack/kolla/tree/master/contrib

On 11/05/18 18:02, Sandhya Dasu (sadasu) wrote:

Hi Paul,
 I am happy to use the changes you proposed to
  https://github.com/openstack/kolla/blob/master/kolla/common/config.py

I was under the impression that this was disallowed for drivers that weren’t
considered “reference drivers”. If that is no longer the case, I am happy to go
this route and abandon the approach I took in my diffs in:
https://review.openstack.org/#/c/552119/.

I agree with the reasoning that Kolla cannot possibly maintain a large
number of neutron-server containers, one per plugin.

To support operators that want to build their own images, I was hoping that
we could come up with a mechanism by which the 3rd party driver owners
provide the code (template-override.j2 or Dockerfile.j2 as the case maybe)
to build their containers. This code can definitely live out-of-tree with the
drivers themselves.

Optionally, we could have them reside in-tree in Kolla in a separate directory,
say “additional drivers”. Kolla will not be responsible for building a container
per driver or for building a huge (neutron-server) container containing all
interested drivers.

Operators that need one or more of these “additional drivers” will be provided
with documentation on how the code in the “additional drivers” path can be
used to build their own containers. This documentation will also detail how
to combine more than one 3rd party drivers into their own container.

I would like the community’s input on what approach best aligns with Kolla’s
and the larger OpenStack community’s goals.

Thanks,
Sandhya

On 5/11/18, 5:35 AM, "Paul Bourke"  wrote:

 Hi Sandhya,
 
 Thanks for starting this thread. I've moved it to the mailing list so

 the discussion can be available to anyone else who is interested, I hope
 you don't mind.
 
 If your requirement is to have third party plugins (such as Cisco) that

 are not available on tarballs.openstack.org, available in Kolla, then
 this is already possible.
 
 Using the Cisco case as an example, you would simply need to submit the

 following patch to
 https://github.com/openstack/kolla/blob/master/kolla/common/config.py
 
 """

  'neutron-server-plugin-networking-cisco': {
  'type': 'git',
  'location': ('https://github.com/openstack/networking-cisco')},
 """
 
 This will then include that plugin as part of the future neutron-server

 builds.
 
 If the requirement is to have Kolla publish a neutron-server container

 with *only* the Cisco plugin, then this is where it gets a little more
 tricky. Sure, we can go the route that's proposed in your patch, but we
 end up then maintaining a massive number of neutron-server containers,
 one per plugin. It also does not address then the issue of what people
 want to do when they want a combination or mix of plugins together.
 
 So right now I feel Kolla takes a middle ground, where we publish a

 neutron-server container with a variety of common plugins. If operators
 have specific requirements, they should create their own config file and
 build their own images, which we expect any serious production setup to
 be doing anyway.
 
 -Paul
 
 On 10/05/18 18:12, Sandhya Dasu (sadasu) wrote:

 > Yes, I think there is some misunderstanding on what I am trying to 
accomplish here.
 >
 > I am utilizing existing Kolla constructs to prove that they work for 3rd 
party out of tree vendor drivers too.
 > At this point, anything that a 3rd party vendor driver does (the way 
they build their containers, where they publish it and how they generate config) 
is completely out of scope of Kolla.
 >
 > I want to use the spec as a place to articulate and discuss best 
practices and figure out what part of supporting 3rd party vendor drivers can stay 
within the Kolla tree and what should be out.
 > I have witnessed many discussions on this topic but they only take away 
I get is “there are ways to do it but it can’t be part of Kolla”.
 >
 > Using the existing kolla constructs of template-override, plugin-archive 
and config-dir, let us say the 3rd party vendor builds a container.
 > OpenStack TC does not want these containers to be part of 
tarballs.openstack.org. Kolla publishes its containers to DockerHub under the 
Kolla project.
 > If these 3rd party 

Re: [openstack-dev] [kolla] Building Kolla containers with 3rd party vendor drivers

[Sandhya Dasu (sadasu)]

Hi Paul,
I am happy to use the changes you proposed to
 https://github.com/openstack/kolla/blob/master/kolla/common/config.py

I was under the impression that this was disallowed for drivers that weren’t
considered “reference drivers”. If that is no longer the case, I am happy to go
this route and abandon the approach I took in my diffs in:
https://review.openstack.org/#/c/552119/.

I agree with the reasoning that Kolla cannot possibly maintain a large
number of neutron-server containers, one per plugin.

To support operators that want to build their own images, I was hoping that
we could come up with a mechanism by which the 3rd party driver owners
provide the code (template-override.j2 or Dockerfile.j2 as the case maybe)
to build their containers. This code can definitely live out-of-tree with the
drivers themselves.

Optionally, we could have them reside in-tree in Kolla in a separate directory, 
say “additional drivers”. Kolla will not be responsible for building a container
per driver or for building a huge (neutron-server) container containing all
interested drivers.

Operators that need one or more of these “additional drivers” will be provided
with documentation on how the code in the “additional drivers” path can be
used to build their own containers. This documentation will also detail how
to combine more than one 3rd party drivers into their own container.

I would like the community’s input on what approach best aligns with Kolla’s
and the larger OpenStack community’s goals.

Thanks,
Sandhya

On 5/11/18, 5:35 AM, "Paul Bourke"  wrote:

Hi Sandhya,

Thanks for starting this thread. I've moved it to the mailing list so 
the discussion can be available to anyone else who is interested, I hope 
you don't mind.

If your requirement is to have third party plugins (such as Cisco) that 
are not available on tarballs.openstack.org, available in Kolla, then 
this is already possible.

Using the Cisco case as an example, you would simply need to submit the 
following patch to 
https://github.com/openstack/kolla/blob/master/kolla/common/config.py

"""
 'neutron-server-plugin-networking-cisco': {
 'type': 'git',
 'location': ('https://github.com/openstack/networking-cisco')},
"""

This will then include that plugin as part of the future neutron-server 
builds.

If the requirement is to have Kolla publish a neutron-server container 
with *only* the Cisco plugin, then this is where it gets a little more 
tricky. Sure, we can go the route that's proposed in your patch, but we 
end up then maintaining a massive number of neutron-server containers, 
one per plugin. It also does not address then the issue of what people 
want to do when they want a combination or mix of plugins together.

So right now I feel Kolla takes a middle ground, where we publish a 
neutron-server container with a variety of common plugins. If operators 
have specific requirements, they should create their own config file and 
build their own images, which we expect any serious production setup to 
be doing anyway.

-Paul

On 10/05/18 18:12, Sandhya Dasu (sadasu) wrote:
> Yes, I think there is some misunderstanding on what I am trying to 
accomplish here.
> 
> I am utilizing existing Kolla constructs to prove that they work for 3rd 
party out of tree vendor drivers too.
> At this point, anything that a 3rd party vendor driver does (the way they 
build their containers, where they publish it and how they generate config) is 
completely out of scope of Kolla.
> 
> I want to use the spec as a place to articulate and discuss best 
practices and figure out what part of supporting 3rd party vendor drivers can 
stay within the Kolla tree and what should be out.
> I have witnessed many discussions on this topic but they only take away I 
get is “there are ways to do it but it can’t be part of Kolla”.
> 
> Using the existing kolla constructs of template-override, plugin-archive 
and config-dir, let us say the 3rd party vendor builds a container.
> OpenStack TC does not want these containers to be part of 
tarballs.openstack.org. Kolla publishes its containers to DockerHub under the 
Kolla project.
> If these 3rd party vendor drivers publish to Dockerhub they will have to 
publish under a different project. So, an OpenStack installation that needs 
these drivers will have to pull images from 2 or more Dokerhub projects?!
> 
> Or do you prefer if the OpenStack operator build their own images using 
the out-of-tree Dockerfile for that vendor?
> 
> Again, should the config changes to support these drivers be part of the 
kolla-ansible repo or should they be out-of-tree?
> 
> It is hard to have this type of discussion on IRC so I started this email 
thread.
> 
> Thanks,
> 

[openstack-dev] [kolla] Building Kolla containers with 3rd party vendor drivers

[Paul Bourke]

Hi Sandhya,

Thanks for starting this thread. I've moved it to the mailing list so 
the discussion can be available to anyone else who is interested, I hope 
you don't mind.


If your requirement is to have third party plugins (such as Cisco) that 
are not available on tarballs.openstack.org, available in Kolla, then 
this is already possible.


Using the Cisco case as an example, you would simply need to submit the 
following patch to 
https://github.com/openstack/kolla/blob/master/kolla/common/config.py


"""
'neutron-server-plugin-networking-cisco': {
'type': 'git',
'location': ('https://github.com/openstack/networking-cisco')},
"""

This will then include that plugin as part of the future neutron-server 
builds.


If the requirement is to have Kolla publish a neutron-server container 
with *only* the Cisco plugin, then this is where it gets a little more 
tricky. Sure, we can go the route that's proposed in your patch, but we 
end up then maintaining a massive number of neutron-server containers, 
one per plugin. It also does not address then the issue of what people 
want to do when they want a combination or mix of plugins together.


So right now I feel Kolla takes a middle ground, where we publish a 
neutron-server container with a variety of common plugins. If operators 
have specific requirements, they should create their own config file and 
build their own images, which we expect any serious production setup to 
be doing anyway.


-Paul

On 10/05/18 18:12, Sandhya Dasu (sadasu) wrote:

Yes, I think there is some misunderstanding on what I am trying to accomplish 
here.

I am utilizing existing Kolla constructs to prove that they work for 3rd party 
out of tree vendor drivers too.
At this point, anything that a 3rd party vendor driver does (the way they build 
their containers, where they publish it and how they generate config) is 
completely out of scope of Kolla.

I want to use the spec as a place to articulate and discuss best practices and 
figure out what part of supporting 3rd party vendor drivers can stay within the 
Kolla tree and what should be out.
I have witnessed many discussions on this topic but they only take away I get 
is “there are ways to do it but it can’t be part of Kolla”.

Using the existing kolla constructs of template-override, plugin-archive and 
config-dir, let us say the 3rd party vendor builds a container.
OpenStack TC does not want these containers to be part of 
tarballs.openstack.org. Kolla publishes its containers to DockerHub under the 
Kolla project.
If these 3rd party vendor drivers publish to Dockerhub they will have to 
publish under a different project. So, an OpenStack installation that needs 
these drivers will have to pull images from 2 or more Dokerhub projects?!

Or do you prefer if the OpenStack operator build their own images using the 
out-of-tree Dockerfile for that vendor?

Again, should the config changes to support these drivers be part of the 
kolla-ansible repo or should they be out-of-tree?

It is hard to have this type of discussion on IRC so I started this email 
thread.

Thanks,
Sandhya

On 5/10/18, 5:59 AM, "Paul Bourke (pbourke) (Code Review)" 
 wrote:

 Paul Bourke (pbourke) has posted comments on this change. ( 
https://review.openstack.org/567278 )
 
 Change subject: Building Kolla containers with 3rd party vendor drivers

 ..
 
 
 Patch Set 2: Code-Review-1
 
 Hi Sandhya, after reading the spec most of my thoughts echo Eduardo's. I'm wondering if there's some misunderstanding on how the current plugin functionality works? Feels free to ping me on irc I'd be happy to discuss further - maybe there's still some element of what's there that's not working for your use case.
 
 --

 To view, visit https://review.openstack.org/567278
 To unsubscribe, visit https://review.openstack.org/settings
 
 Gerrit-MessageType: comment

 Gerrit-Change-Id: I681d6a7b38b6cafe7ebe88a1a1f2d53943e1aab2
 Gerrit-PatchSet: 2
 Gerrit-Project: openstack/kolla
 Gerrit-Branch: master
 Gerrit-Owner: Sandhya Dasu 
 Gerrit-Reviewer: Duong Ha-Quang 
 Gerrit-Reviewer: Eduardo Gonzalez 
 Gerrit-Reviewer: Paul Bourke (pbourke) 
 Gerrit-Reviewer: Zuul
 Gerrit-HasComments: No
 



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev