Open Stack

On Thu, Feb 9, 2017 at 10:00 PM, Dan Sneddon <dsneddon at redhat.com> wrote:

> Pete, thanks for mentioning network isolation and segmentation. That's
> my area of interest, since I'm focused on underlay networking for
> TripleO and bare-metal networking in Ironic.
>
> Network isolation is going to be important for several reasons:
>
> 1) Separation of control and data plane in deployments
> 2) Tenant isolation in multi-tenant Ironic BMaaS
> 3) Network Function Virtualization (NFV) use cases
>
> The intention of the isolated networking model for TripleO was to
> separate control and data plane, as well as tenant from administrative
> traffic. A secondary goal was to make this highly configurable and
> customizable. This has been well received by many operators who have
> rigid security isolation requirements (such as PCI-DSS for financial
> transactions), or those who customize their underlay network to
> integrate into an existing networking topology. I'm thinking about how
> to do something similar in Kubernetes, perhaps with Kuryr.
>
> The Harbor project looks very interesting. Do you have any more
> information about how Harbor uses Raven to achieve isolation? Also, are
> you saying that Harbor uses an older (prototype) version of Raven, or
> are you referring to Raven itself as a prototype?
>

I can answer to some of that :-)

Raven was the Python 3 asyncio based prototype my team built back
when I was at Midokura for integrating Kubernetes and Neutron as
something to then upstream to Kuryr with the help of the rest of the
community (taking the lessons learned from the PoC and improving
on it). So yes, Raven itself was a prototype (a quite functional one)
and led to what we know today in Kuryr as the kuryr-kubernetes
controller, which is now almost at the same level of features, missing
just two patches for the service support.

I have to note here, that Pete did some interesting modifications to
Raven like OVN support addition and leveraging the watcher model
to make, IIRC, the cluster services use the native OVN load balancer
rather than neutron-lbaas.

The Kuryr-kubernetes controller is built with pluggability in mind and it
has a system of drivers (using stevedore) for acquiring resources.  This
makes things like what Pete did easier to achieve with the new codebase
and also pick yourself the level of isolation that you want. Let's say that
you want
to have the different OSt components pick different networks or even
projects, you would just need to make a very small driver like [0] or [1]
that could, for example, make an http request to some service that held
a mapping, read some specific annotation, etc.

In terms of isolation for deployments, we are starting discussion about
leveraging the new CNI support for reporting multiple interfaces (still not
implemented in k8s, but playing is fun) so that we can put the pods that
need it both in the control and in the data plane, we'll probably need to
tweak the interface of the drivers so that they can return an iterable.


[0]
https://github.com/openstack/kuryr-kubernetes/blob/master/kuryr_kubernetes/controller/drivers/default_project.py#L39
[1]
https://github.com/openstack/kuryr-kubernetes/blob/master/kuryr_kubernetes/controller/drivers/default_subnet.py#L56

>
> I'll be at the PTG Tuesday through Friday morning. I'm looking forward
> to having some conversations about this topic.
>
> --
> Dan Sneddon         |  Senior Principal OpenStack Engineer
> dsneddon at redhat.com |  redhat.com/openstack
> dsneddon:irc        |  @dxs:twitter
>
> On 02/09/2017 09:56 AM, Pete Birley wrote:
> > Hi Flavio,
> >
> > I've been doing some work on packaging Kuryr for use with K8s as an
> > underlay for OpenStack on Kubernetes. When we met up in Brno the Harbor
> > project I showed you used Tony's old Raven Prototype to provide the
> > network isolation and segmentation in K8s. I've since begun to lay the
> > groundwork for OpenStack-Helm to support similar modes of operation,
> > allowing both service isolation and also combined networking between
> > OpenStack and K8s, where pods and VMs can co-exist on the same Neutron
> > Networks.
> >
> > I'm not sure I will have things fully functional within OpenStack-Helm
> > by the PTG, but it would be great to sit down and work out how we can
> > ensure that not only do we not end up replicating work needlessly, but
> > also find further opportunities to collaborate. I'll be in Atlanta all
> > week, though I think some of the OS-Helm and Kolla-K8s developers will
> > be leaving on Wed, would a particular day/time work best for you?
> >
> >
> > Cheers
> >
> > Pete (portdirect)
> >
> >
> > On Thu, Feb 9, 2017 at 8:57 AM, Flavio Percoco <flavio at redhat.com
> > <mailto:flavio at redhat.com>> wrote:
> >
> >     Greetings,
> >
> >     I was talking with Tony and he mentioned that he's recording a new
> >     demo for
> >     kuryr and, well, it'd be great to also use the containerized version
> >     of TripleO
> >     for the demo.
> >
> >     His plan is to have this demo out by next week and that may be too
> >     tight for the
> >     containerized version of TripleO (it may be not, let's try). That
> >     said, I think
> >     it's still a good opportunity for us to sit down at the PTG and play
> >     with this a
> >     bit further.
> >
> >     So, before we set a date and time for this, I wanted to extend the
> >     invite to
> >     other folks and see if there's some interest. It be great to also
> >     have folks
> >     from Kolla and openstack-helm joining.
> >
> >     Looking forward to hearing ideas and hacking with y'all,
> >     Flavio
> >
> >     --
> >     @flaper87
> >     Flavio Percoco
> >
> >     ____________________________________________________________
> ______________
> >     OpenStack Development Mailing List (not for usage questions)
> >     Unsubscribe:
> >     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >     <http://OpenStack-dev-request@lists.openstack.org?subject:
> unsubscribe>
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> >
> >
> >
> >
> > --
> >
> > Port.direct <https://port.direct>
> >
> >
> >
> > Pete Birley / Director
> > pete at port.direct <mailto:pete at port.direct> / +447446862551
> >
> > *PORT.*DIRECT
> > United Kingdom
> > https://port.direct
> >
> > This e-mail message may contain confidential or legally privileged
> > information and is intended only for the use of the intended
> > recipient(s). Any unauthorized disclosure, dissemination, distribution,
> > copying or the taking of any action in reliance on the information
> > herein is prohibited. E-mails are not secure and cannot be guaranteed to
> > be error free as they can be intercepted, amended, or contain viruses.
> > Anyone who communicates with us by e-mail is deemed to have accepted
> > these risks. Port.direct is not responsible for errors or omissions in
> > this message and denies any responsibility for any damage arising from
> > the use of e-mail. Any opinion and other statement contained in this
> > message and any attachment are solely those of the author and do not
> > necessarily represent those of the company.
> >
> >
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170210/65d7e7fe/attachment.html>