You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by James DeFelice <ja...@gmail.com> on 2015/05/11 21:15:59 UTC

Re: Virtual Floating specific, or non-specific IP(v4/v6), addresses for tasks

Kubernetes services v2 leverages a "portal net", from which IPs are
allocated for service instances. It would be great if the kubernetes-mesos
framework could allocate this network (currently expressed as a CIDR range)
from an offer.

On Wed, Apr 29, 2015 at 11:49 AM, Ian Downes <id...@twitter.com.invalid>
wrote:

> This is something we're interested in exploring as well. Can we ensure the
> design thinking get circulated to the community early on? I agree there
> will be many different requirements and it would be helpful to understand
> those from the onset.
>
> Ian
>
> On Tue, Apr 28, 2015 at 5:48 PM, Christos Kozyrakis <
> christos@mesosphere.io>
> wrote:
>
> > Hi Joe,
> >
> > 100% agreed, we need something like this.
> >
> > We are working on an open-source design for networking for Mesos with
> > Project Calico (using project calico and in collaboration with
> Metaswitch)
> > but you can imagine also using OVS or your favorite vSwitch or vRouter.
> > It's difficult to imagine that there will be a one size fits all here but
> > we should be able to reuse most logic regardless of the network
> > virtualization scheme used.
> >
> > We can exchange design notes if you want. From the point of view of the
> > Mesos community, the most important part to get right is to identify what
> > are the new requirements for the Mesos master or slave code to support
> such
> > efforts. From our point of view, the major missing piece is some way to
> > support express pools of IPs as globally managed resources and connect
> them
> > to offers given to frameworks. Niklas is looking into the design details
> of
> > that.
> >
> > Cheers
> > Christos
> >
> >
> >
> >
> > On Tue, Apr 28, 2015 at 5:18 PM, Joe Stein <jo...@stealth.ly> wrote:
> >
> > > Hi Mesos community, there is a lot of work in progress around virtual
> > > routers and custom allocator(s) to enable for every task to have one or
> > > more specific, or non-specific IP(v4/v6) addresses assigned to it (long
> > > lived for the life of that task on that cluster). The goal is for every
> > > mesos task to get a leased IP that it will _ALWAYS_ have. This means we
> > can
> > > use standard ports :) since every task will be bound to its own IP.
> > >
> > > Essentially we are working on a control plane for the virtual router
> (on
> > > each slave) and a data plane for task to get the IP and a custom
> > allocator
> > > to manage it. This work is being done by a bunch of folks/companies as
> > Open
> > > Source under Cisco Cloud.
> > >
> > > So, I wanted to send a quick note (before we circulate the design we
> have
> > > been working on and get coding) if folks would find this interesting?
> > Have
> > > already done it? Would like to contribute and help? Any thing else?
> > >
> > > One thing also (which came out of this collaboration but not just for
> > this
> > > feature) is that we are thinking of creating some callback mechanism
> for
> > > the allocator module so we can write in Python or Go the business logic
> > for
> > > allocator modules. Not sure if folks have done this or are interested
> in
> > > such a thing or have thought about it at all.
> > >
> > > Thanks!
> > >
> > > ~ Joe Stein
> > > - - - - - - - - - - - - - - - - -
> > >
> > >   http://www.stealth.ly
> > > - - - - - - - - - - - - - - - - -
> > >
> >
>



-- 
James DeFelice
585.241.9488 (voice)
650.649.6071 (fax)

Re: Virtual Floating specific, or non-specific IP(v4/v6), addresses for tasks

Posted by Joe Stein <jo...@stealth.ly>.
Awesome! I think the community collaboration will help to make sure
components are built in a way that is most reusable for different uses
cases even if they all can't be delivered at first. It also helps bring to
the surface items like "global resources", "bandwidth as a resource", etc
that in of itself are not related to "floating ip" but when we build them
for the "floating ip" they can be reusable elsewhere.

Thanks for helping to organize this, looking forward to it.

~ Joe Stein
- - - - - - - - - - - - - - - - -

  http://www.stealth.ly
- - - - - - - - - - - - - - - - -

On Wed, May 13, 2015 at 4:22 PM, Niklas Nielsen <ni...@mesosphere.io>
wrote:

> We are several folks (organizations and companies) that are working on
> Mesos Networking (which is awesome btw!)
>
> I revived our ticket on per-container IP and I think we have the critical
> mass to start a *community meeting* on this :)
> I suggest we fill in more thoughts and ideas in the suggested architecture
> doc [1] and join a hangout *Tuesday 10AM PST*.
>
> Thoughts or objections? If not, I will be following up with an invite.
>
> Cheers,
> Niklas
>
> [1]
>
> https://docs.google.com/document/d/17mXtAmdAXcNBwp_JfrxmZcQrs7EO6ancSbejrqjLQ0g/edit
>
>
> On 11 May 2015 at 12:15, James DeFelice <ja...@gmail.com> wrote:
>
> > Kubernetes services v2 leverages a "portal net", from which IPs are
> > allocated for service instances. It would be great if the
> kubernetes-mesos
> > framework could allocate this network (currently expressed as a CIDR
> range)
> > from an offer.
> >
> > On Wed, Apr 29, 2015 at 11:49 AM, Ian Downes <idownes@twitter.com.invalid
> >
> > wrote:
> >
> > > This is something we're interested in exploring as well. Can we ensure
> > the
> > > design thinking get circulated to the community early on? I agree there
> > > will be many different requirements and it would be helpful to
> understand
> > > those from the onset.
> > >
> > > Ian
> > >
> > > On Tue, Apr 28, 2015 at 5:48 PM, Christos Kozyrakis <
> > > christos@mesosphere.io>
> > > wrote:
> > >
> > > > Hi Joe,
> > > >
> > > > 100% agreed, we need something like this.
> > > >
> > > > We are working on an open-source design for networking for Mesos with
> > > > Project Calico (using project calico and in collaboration with
> > > Metaswitch)
> > > > but you can imagine also using OVS or your favorite vSwitch or
> vRouter.
> > > > It's difficult to imagine that there will be a one size fits all here
> > but
> > > > we should be able to reuse most logic regardless of the network
> > > > virtualization scheme used.
> > > >
> > > > We can exchange design notes if you want. From the point of view of
> the
> > > > Mesos community, the most important part to get right is to identify
> > what
> > > > are the new requirements for the Mesos master or slave code to
> support
> > > such
> > > > efforts. From our point of view, the major missing piece is some way
> to
> > > > support express pools of IPs as globally managed resources and
> connect
> > > them
> > > > to offers given to frameworks. Niklas is looking into the design
> > details
> > > of
> > > > that.
> > > >
> > > > Cheers
> > > > Christos
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Apr 28, 2015 at 5:18 PM, Joe Stein <jo...@stealth.ly>
> > wrote:
> > > >
> > > > > Hi Mesos community, there is a lot of work in progress around
> virtual
> > > > > routers and custom allocator(s) to enable for every task to have
> one
> > or
> > > > > more specific, or non-specific IP(v4/v6) addresses assigned to it
> > (long
> > > > > lived for the life of that task on that cluster). The goal is for
> > every
> > > > > mesos task to get a leased IP that it will _ALWAYS_ have. This
> means
> > we
> > > > can
> > > > > use standard ports :) since every task will be bound to its own IP.
> > > > >
> > > > > Essentially we are working on a control plane for the virtual
> router
> > > (on
> > > > > each slave) and a data plane for task to get the IP and a custom
> > > > allocator
> > > > > to manage it. This work is being done by a bunch of folks/companies
> > as
> > > > Open
> > > > > Source under Cisco Cloud.
> > > > >
> > > > > So, I wanted to send a quick note (before we circulate the design
> we
> > > have
> > > > > been working on and get coding) if folks would find this
> interesting?
> > > > Have
> > > > > already done it? Would like to contribute and help? Any thing else?
> > > > >
> > > > > One thing also (which came out of this collaboration but not just
> for
> > > > this
> > > > > feature) is that we are thinking of creating some callback
> mechanism
> > > for
> > > > > the allocator module so we can write in Python or Go the business
> > logic
> > > > for
> > > > > allocator modules. Not sure if folks have done this or are
> interested
> > > in
> > > > > such a thing or have thought about it at all.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > ~ Joe Stein
> > > > > - - - - - - - - - - - - - - - - -
> > > > >
> > > > >   http://www.stealth.ly
> > > > > - - - - - - - - - - - - - - - - -
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > James DeFelice
> > 585.241.9488 (voice)
> > 650.649.6071 (fax)
> >
>

Re: Virtual Floating specific, or non-specific IP(v4/v6), addresses for tasks

Posted by Niklas Nielsen <ni...@mesosphere.io>.
We are several folks (organizations and companies) that are working on
Mesos Networking (which is awesome btw!)

I revived our ticket on per-container IP and I think we have the critical
mass to start a *community meeting* on this :)
I suggest we fill in more thoughts and ideas in the suggested architecture
doc [1] and join a hangout *Tuesday 10AM PST*.

Thoughts or objections? If not, I will be following up with an invite.

Cheers,
Niklas

[1]
https://docs.google.com/document/d/17mXtAmdAXcNBwp_JfrxmZcQrs7EO6ancSbejrqjLQ0g/edit


On 11 May 2015 at 12:15, James DeFelice <ja...@gmail.com> wrote:

> Kubernetes services v2 leverages a "portal net", from which IPs are
> allocated for service instances. It would be great if the kubernetes-mesos
> framework could allocate this network (currently expressed as a CIDR range)
> from an offer.
>
> On Wed, Apr 29, 2015 at 11:49 AM, Ian Downes <id...@twitter.com.invalid>
> wrote:
>
> > This is something we're interested in exploring as well. Can we ensure
> the
> > design thinking get circulated to the community early on? I agree there
> > will be many different requirements and it would be helpful to understand
> > those from the onset.
> >
> > Ian
> >
> > On Tue, Apr 28, 2015 at 5:48 PM, Christos Kozyrakis <
> > christos@mesosphere.io>
> > wrote:
> >
> > > Hi Joe,
> > >
> > > 100% agreed, we need something like this.
> > >
> > > We are working on an open-source design for networking for Mesos with
> > > Project Calico (using project calico and in collaboration with
> > Metaswitch)
> > > but you can imagine also using OVS or your favorite vSwitch or vRouter.
> > > It's difficult to imagine that there will be a one size fits all here
> but
> > > we should be able to reuse most logic regardless of the network
> > > virtualization scheme used.
> > >
> > > We can exchange design notes if you want. From the point of view of the
> > > Mesos community, the most important part to get right is to identify
> what
> > > are the new requirements for the Mesos master or slave code to support
> > such
> > > efforts. From our point of view, the major missing piece is some way to
> > > support express pools of IPs as globally managed resources and connect
> > them
> > > to offers given to frameworks. Niklas is looking into the design
> details
> > of
> > > that.
> > >
> > > Cheers
> > > Christos
> > >
> > >
> > >
> > >
> > > On Tue, Apr 28, 2015 at 5:18 PM, Joe Stein <jo...@stealth.ly>
> wrote:
> > >
> > > > Hi Mesos community, there is a lot of work in progress around virtual
> > > > routers and custom allocator(s) to enable for every task to have one
> or
> > > > more specific, or non-specific IP(v4/v6) addresses assigned to it
> (long
> > > > lived for the life of that task on that cluster). The goal is for
> every
> > > > mesos task to get a leased IP that it will _ALWAYS_ have. This means
> we
> > > can
> > > > use standard ports :) since every task will be bound to its own IP.
> > > >
> > > > Essentially we are working on a control plane for the virtual router
> > (on
> > > > each slave) and a data plane for task to get the IP and a custom
> > > allocator
> > > > to manage it. This work is being done by a bunch of folks/companies
> as
> > > Open
> > > > Source under Cisco Cloud.
> > > >
> > > > So, I wanted to send a quick note (before we circulate the design we
> > have
> > > > been working on and get coding) if folks would find this interesting?
> > > Have
> > > > already done it? Would like to contribute and help? Any thing else?
> > > >
> > > > One thing also (which came out of this collaboration but not just for
> > > this
> > > > feature) is that we are thinking of creating some callback mechanism
> > for
> > > > the allocator module so we can write in Python or Go the business
> logic
> > > for
> > > > allocator modules. Not sure if folks have done this or are interested
> > in
> > > > such a thing or have thought about it at all.
> > > >
> > > > Thanks!
> > > >
> > > > ~ Joe Stein
> > > > - - - - - - - - - - - - - - - - -
> > > >
> > > >   http://www.stealth.ly
> > > > - - - - - - - - - - - - - - - - -
> > > >
> > >
> >
>
>
>
> --
> James DeFelice
> 585.241.9488 (voice)
> 650.649.6071 (fax)
>