On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam
sumitnaiksa...@gmail.com wrote:
Several people have been requesting that we resume the Advanced
Services' meetings [1] to discuss some of the topics being mentioned
in this thread. Perhaps it might help people to have a focussed
discussion on the topic of advanced services' spin-out prior to the
design summit session [2] in Paris. So I propose that we resume our
weekly IRC meetings starting this Wednesday (Oct 29th), 17.30 UTC on
#openstack-meeting-3.
Given how important this is to Neutron in general, I would prefer NOT
to see this discussed in the Advanced Services meeting, but rather in
the regular Neutron meeting. These are the types of things which need
broader oversight and involvement. Lets please discuss this in the
regular Neutron meeting, which is an on-demand meeting format, rather
than in a sub-team meeting.
Thanks,
~Sumit.
[1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices
[2]
http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VE3Ukot4r4y
On Sun, Oct 26, 2014 at 7:55 PM, Sridar Kandaswamy (skandasw)
skand...@cisco.com wrote:
Hi Doug:
On 10/26/14, 6:01 PM, Doug Wiegley do...@a10networks.com wrote:
Hi Brandon,
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
I agree with this sentiment. I¹d just like to pull-up to the decision
level, and if we can get some consensus on how we move forward, we can
bring a concrete plan to the summit instead of 40 minutes of Kumbaya. We
love each other. Check. Things are going to change sometime. Check. We
might spin-out someday. Check. Now, let¹s jump to the interesting part.
3. The main reason a spin out makes sense from Neutron is that the scope
for Neutron is too large for the attention advances services needs from
the Neutron Core. If all of advanced services spins out, I see that
There is merit here, but consider the sorts of things that an advanced
services framework should be doing:
- plugging into neutron ports, with all manner of topologies
- service VM handling
- plugging into nova-network
- service chaining
- applying things like security groups to services
Š this is all stuff that Octavia is talking about implementing itself in a
basically defensive manner, instead of leveraging other work. And there
are specific reasons for that. But, maybe we can at least take steps to
not be incompatible about it. Or maybe there is a hierarchy of Neutron -
Services - LB, where we¹re still spun out, but not doing it in a way that
we have to re-implement the world all the time. It¹s at least worth a
conversation or three.
In total agreement and I have heard these sentiments in multiple
conversations across multiple players.
It would be really fruitful to have a constructive conversation on this
across the services, and there are
enough similar issues to make this worthwhile.
Thanks
Sridar
Thanks,
Doug
On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com wrote:
Good questions Doug. My answers are as follows:
1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the scope
for Neutron is too large for the attention advances services needs from
the Neutron Core. If all of advanced services spins out, I see that
repeating itself within an advanced services project. More and more
advanced services will get added in and the scope will become too
large. There would definitely be benefits to it though, but I think we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
Yes the brunt of the time will not be spent on the API, but since it
seemed like an opportunity to kill two birds with one stone, I figured
it warranted a discussion.
Thanks,
Brandon
On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
Hi all,
Before we get into the details of which API goes where, I¹d like to see
us
answer the questions of:
1. Are we spinning out?
2. When?
3. With or without the rest of advanced services?
4. Do we want to wait until we (the royal ³we² of ³the Neutron team²)
have
had the Paris summit discussions on vendor split-out and adv. services
spinout before we answer those questions? (Yes, that question is
leading.)
To me, the ³where does the API live² is an implementation detail, and
not
where the time will need to be spent.
For the record, my answers are:
1. Yes.
2. I don¹t know.
3. I don¹t know; this needs some serious discussion.
4. Yes.
Thanks,
doug
On 10/24/14, 3:47 PM, Brandon Logan

On Sun, Oct 26, 2014 at 8:01 PM, Doug Wiegley do...@a10networks.com wrote:
Hi Brandon,
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
I agree with this sentiment. I’d just like to pull-up to the decision
level, and if we can get some consensus on how we move forward, we can
bring a concrete plan to the summit instead of 40 minutes of Kumbaya. We
love each other. Check. Things are going to change sometime. Check. We
might spin-out someday. Check. Now, let’s jump to the interesting part.
I think we all know we want to spin these out, as Doug says we just
need to have a plan around how we make that happen. I'm in agreement
with Doug's sentiment above.
3. The main reason a spin out makes sense from Neutron is that the scope
for Neutron is too large for the attention advances services needs from
the Neutron Core. If all of advanced services spins out, I see that
There is merit here, but consider the sorts of things that an advanced
services framework should be doing:
- plugging into neutron ports, with all manner of topologies
- service VM handling
- plugging into nova-network
- service chaining
- applying things like security groups to services
… this is all stuff that Octavia is talking about implementing itself in a
basically defensive manner, instead of leveraging other work. And there
are specific reasons for that. But, maybe we can at least take steps to
not be incompatible about it. Or maybe there is a hierarchy of Neutron -
Services - LB, where we’re still spun out, but not doing it in a way that
we have to re-implement the world all the time. It’s at least worth a
conversation or three.
Doug, can you document this on the etherpad for the services spinout
[1]? I've added some brief text at the top on what the objective for
this session is, but documenting more along the lines of what you have
here would be good.
Thanks,
Kyle
[1] https://etherpad.openstack.org/p/neutron-services
Thanks,
Doug
On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com wrote:
Good questions Doug. My answers are as follows:
1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the scope
for Neutron is too large for the attention advances services needs from
the Neutron Core. If all of advanced services spins out, I see that
repeating itself within an advanced services project. More and more
advanced services will get added in and the scope will become too
large. There would definitely be benefits to it though, but I think we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
Yes the brunt of the time will not be spent on the API, but since it
seemed like an opportunity to kill two birds with one stone, I figured
it warranted a discussion.
Thanks,
Brandon
On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
Hi all,
Before we get into the details of which API goes where, I’d like to see
us
answer the questions of:
1. Are we spinning out?
2. When?
3. With or without the rest of advanced services?
4. Do we want to wait until we (the royal “we” of “the Neutron team”)
have
had the Paris summit discussions on vendor split-out and adv. services
spinout before we answer those questions? (Yes, that question is
leading.)
To me, the “where does the API live” is an implementation detail, and
not
where the time will need to be spent.
For the record, my answers are:
1. Yes.
2. I don’t know.
3. I don’t know; this needs some serious discussion.
4. Yes.
Thanks,
doug
On 10/24/14, 3:47 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
With the recent talk about advanced services spinning out of Neutron,
and the fact most of the LBaaS community has wanted LBaaS to spin out
of
Neutron, I wanted to bring up a possibility and gauge interest and
opinion on this possibility.
Octavia is going to (and has) an API. The current thinking is that an
Octavia driver will be created in Neutron LBaaS that will make a
requests to the Octavia API. When LBaaS spins out of Neutron, it will
need a standalone API. Octavia's API seems to be a good solution to
this. It will support vendor drivers much like the current Neutron
LBaaS does. It has a similar API as Neutron LBaaS v2, but its not an
exact duplicate. Octavia will be growing more mature in stackforge at
a
higher velocity than an Openstack project, so I expect by the time Kilo
comes around it's API will be very mature.
Octavia's API doesn't have to be called Octavia either. It can be

Hi Kyle:
Are you scheduling an on-demand meeting, or are you proposing that the
agenda for next neutron meeting include this as an on-demand item?
Regards,
Mandeep
On Mon, Oct 27, 2014 at 6:56 AM, Kyle Mestery mest...@mestery.com wrote:
On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam
sumitnaiksa...@gmail.com wrote:
Several people have been requesting that we resume the Advanced
Services' meetings [1] to discuss some of the topics being mentioned
in this thread. Perhaps it might help people to have a focussed
discussion on the topic of advanced services' spin-out prior to the
design summit session [2] in Paris. So I propose that we resume our
weekly IRC meetings starting this Wednesday (Oct 29th), 17.30 UTC on
#openstack-meeting-3.
Given how important this is to Neutron in general, I would prefer NOT
to see this discussed in the Advanced Services meeting, but rather in
the regular Neutron meeting. These are the types of things which need
broader oversight and involvement. Lets please discuss this in the
regular Neutron meeting, which is an on-demand meeting format, rather
than in a sub-team meeting.
Thanks,
~Sumit.
[1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices
[2]
http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VE3Ukot4r4y
On Sun, Oct 26, 2014 at 7:55 PM, Sridar Kandaswamy (skandasw)
skand...@cisco.com wrote:
Hi Doug:
On 10/26/14, 6:01 PM, Doug Wiegley do...@a10networks.com wrote:
Hi Brandon,
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
I agree with this sentiment. I¹d just like to pull-up to the decision
level, and if we can get some consensus on how we move forward, we can
bring a concrete plan to the summit instead of 40 minutes of Kumbaya.
We
love each other. Check. Things are going to change sometime. Check.
We
might spin-out someday. Check. Now, let¹s jump to the interesting
part.
3. The main reason a spin out makes sense from Neutron is that the
scope
for Neutron is too large for the attention advances services needs
from
the Neutron Core. If all of advanced services spins out, I see that
There is merit here, but consider the sorts of things that an advanced
services framework should be doing:
- plugging into neutron ports, with all manner of topologies
- service VM handling
- plugging into nova-network
- service chaining
- applying things like security groups to services
Š this is all stuff that Octavia is talking about implementing itself
in a
basically defensive manner, instead of leveraging other work. And there
are specific reasons for that. But, maybe we can at least take steps to
not be incompatible about it. Or maybe there is a hierarchy of Neutron
-
Services - LB, where we¹re still spun out, but not doing it in a way
that
we have to re-implement the world all the time. It¹s at least worth a
conversation or three.
In total agreement and I have heard these sentiments in multiple
conversations across multiple players.
It would be really fruitful to have a constructive conversation on this
across the services, and there are
enough similar issues to make this worthwhile.
Thanks
Sridar
Thanks,
Doug
On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
Good questions Doug. My answers are as follows:
1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the
scope
for Neutron is too large for the attention advances services needs from
the Neutron Core. If all of advanced services spins out, I see that
repeating itself within an advanced services project. More and more
advanced services will get added in and the scope will become too
large. There would definitely be benefits to it though, but I think we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
Yes the brunt of the time will not be spent on the API, but since it
seemed like an opportunity to kill two birds with one stone, I figured
it warranted a discussion.
Thanks,
Brandon
On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
Hi all,
Before we get into the details of which API goes where, I¹d like to
see
us
answer the questions of:
1. Are we spinning out?
2. When?
3. With or without the rest of advanced services?
4. Do we want to wait until we (the royal ³we² of ³the Neutron team²)
have
had the Paris summit discussions on vendor split-out and adv.
services
spinout

On Mon, Oct 27, 2014 at 11:48 AM, Mandeep Dhami dh...@noironetworks.com wrote:
Hi Kyle:
Are you scheduling an on-demand meeting, or are you proposing that the
agenda for next neutron meeting include this as an on-demand item?
Per my email to the list recently [1], the weekly rotating Neutron
meeting is now an on-demand agenda, rather than a rollup of sub-team
status. I'm saying this particular topic (advanced services spinout)
will be discussed in Paris, and it's worth adding it to the weekly
Neutron meeting [2] agenda in the on-demand section. This is a pretty
large topic with many interested parties, thus the attention in the
broader neutron meeting.
Thanks,
Kyle
[1] http://lists.openstack.org/pipermail/openstack-dev/2014-October/048328.html
[2] https://wiki.openstack.org/wiki/Network/Meetings
Regards,
Mandeep
On Mon, Oct 27, 2014 at 6:56 AM, Kyle Mestery mest...@mestery.com wrote:
On Mon, Oct 27, 2014 at 12:15 AM, Sumit Naiksatam
sumitnaiksa...@gmail.com wrote:
Several people have been requesting that we resume the Advanced
Services' meetings [1] to discuss some of the topics being mentioned
in this thread. Perhaps it might help people to have a focussed
discussion on the topic of advanced services' spin-out prior to the
design summit session [2] in Paris. So I propose that we resume our
weekly IRC meetings starting this Wednesday (Oct 29th), 17.30 UTC on
#openstack-meeting-3.
Given how important this is to Neutron in general, I would prefer NOT
to see this discussed in the Advanced Services meeting, but rather in
the regular Neutron meeting. These are the types of things which need
broader oversight and involvement. Lets please discuss this in the
regular Neutron meeting, which is an on-demand meeting format, rather
than in a sub-team meeting.
Thanks,
~Sumit.
[1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices
[2]
http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VE3Ukot4r4y
On Sun, Oct 26, 2014 at 7:55 PM, Sridar Kandaswamy (skandasw)
skand...@cisco.com wrote:
Hi Doug:
On 10/26/14, 6:01 PM, Doug Wiegley do...@a10networks.com wrote:
Hi Brandon,
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see
the
harm in opinions being discussed before the summit, during the
summit,
and more thoroughly after the summit.
I agree with this sentiment. I¹d just like to pull-up to the decision
level, and if we can get some consensus on how we move forward, we can
bring a concrete plan to the summit instead of 40 minutes of Kumbaya.
We
love each other. Check. Things are going to change sometime. Check.
We
might spin-out someday. Check. Now, let¹s jump to the interesting
part.
3. The main reason a spin out makes sense from Neutron is that the
scope
for Neutron is too large for the attention advances services needs
from
the Neutron Core. If all of advanced services spins out, I see that
There is merit here, but consider the sorts of things that an advanced
services framework should be doing:
- plugging into neutron ports, with all manner of topologies
- service VM handling
- plugging into nova-network
- service chaining
- applying things like security groups to services
Š this is all stuff that Octavia is talking about implementing itself
in a
basically defensive manner, instead of leveraging other work. And
there
are specific reasons for that. But, maybe we can at least take steps
to
not be incompatible about it. Or maybe there is a hierarchy of Neutron
-
Services - LB, where we¹re still spun out, but not doing it in a way
that
we have to re-implement the world all the time. It¹s at least worth a
conversation or three.
In total agreement and I have heard these sentiments in multiple
conversations across multiple players.
It would be really fruitful to have a constructive conversation on this
across the services, and there are
enough similar issues to make this worthwhile.
Thanks
Sridar
Thanks,
Doug
On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
Good questions Doug. My answers are as follows:
1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the
scope
for Neutron is too large for the attention advances services needs
from
the Neutron Core. If all of advanced services spins out, I see that
repeating itself within an advanced services project. More and more
advanced services will get added in and the scope will become too
large. There would definitely be benefits to it though, but I think
we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before

Hi Jay,
Let’s add that as an agenda item at our Weekly IRC meeting. Can you make
this timeslot?
https://wiki.openstack.org/wiki/Octavia#Meetings
Thanks,
Doug
On 10/27/14, 11:27 AM, Jay Pipes jaypi...@gmail.com wrote:
Sorry for top-posting, but where can the API working group see the
proposed Octavia API specification or documentation? I'd love it if the
API WG could be involved in reviewing the public REST API.
Best,
-jay
On 10/27/2014 10:01 AM, Kyle Mestery wrote:
On Sun, Oct 26, 2014 at 8:01 PM, Doug Wiegley do...@a10networks.com
wrote:
Hi Brandon,
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
I agree with this sentiment. I’d just like to pull-up to the decision
level, and if we can get some consensus on how we move forward, we can
bring a concrete plan to the summit instead of 40 minutes of Kumbaya.
We
love each other. Check. Things are going to change sometime. Check.
We
might spin-out someday. Check. Now, let’s jump to the interesting
part.
I think we all know we want to spin these out, as Doug says we just
need to have a plan around how we make that happen. I'm in agreement
with Doug's sentiment above.
3. The main reason a spin out makes sense from Neutron is that the
scope
for Neutron is too large for the attention advances services needs
from
the Neutron Core. If all of advanced services spins out, I see that
There is merit here, but consider the sorts of things that an advanced
services framework should be doing:
- plugging into neutron ports, with all manner of topologies
- service VM handling
- plugging into nova-network
- service chaining
- applying things like security groups to services
… this is all stuff that Octavia is talking about implementing itself
in a
basically defensive manner, instead of leveraging other work. And
there
are specific reasons for that. But, maybe we can at least take steps
to
not be incompatible about it. Or maybe there is a hierarchy of
Neutron -
Services - LB, where we’re still spun out, but not doing it in a way
that
we have to re-implement the world all the time. It’s at least worth a
conversation or three.
Doug, can you document this on the etherpad for the services spinout
[1]? I've added some brief text at the top on what the objective for
this session is, but documenting more along the lines of what you have
here would be good.
Thanks,
Kyle
[1] https://etherpad.openstack.org/p/neutron-services
Thanks,
Doug
On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
Good questions Doug. My answers are as follows:
1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the
scope
for Neutron is too large for the attention advances services needs
from
the Neutron Core. If all of advanced services spins out, I see that
repeating itself within an advanced services project. More and more
advanced services will get added in and the scope will become too
large. There would definitely be benefits to it though, but I think
we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
Yes the brunt of the time will not be spent on the API, but since it
seemed like an opportunity to kill two birds with one stone, I figured
it warranted a discussion.
Thanks,
Brandon
On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
Hi all,
Before we get into the details of which API goes where, I’d like to
see
us
answer the questions of:
1. Are we spinning out?
2. When?
3. With or without the rest of advanced services?
4. Do we want to wait until we (the royal “we” of “the Neutron team”)
have
had the Paris summit discussions on vendor split-out and adv.
services
spinout before we answer those questions? (Yes, that question is
leading.)
To me, the “where does the API live” is an implementation detail, and
not
where the time will need to be spent.
For the record, my answers are:
1. Yes.
2. I don’t know.
3. I don’t know; this needs some serious discussion.
4. Yes.
Thanks,
doug
On 10/24/14, 3:47 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
With the recent talk about advanced services spinning out of
Neutron,
and the fact most of the LBaaS community has wanted LBaaS to spin
out
of
Neutron, I wanted to bring up a possibility and gauge interest and
opinion on this possibility.
Octavia is going to (and has) an API. The current thinking is that
an
Octavia driver will be created in Neutron LBaaS that will make a
requests to the Octavia

Yup, can do! :)
-jay
On 10/27/2014 01:55 PM, Doug Wiegley wrote:
Hi Jay,
Let’s add that as an agenda item at our Weekly IRC meeting. Can you make
this timeslot?
https://wiki.openstack.org/wiki/Octavia#Meetings
Thanks,
Doug
On 10/27/14, 11:27 AM, Jay Pipes jaypi...@gmail.com wrote:
Sorry for top-posting, but where can the API working group see the
proposed Octavia API specification or documentation? I'd love it if the
API WG could be involved in reviewing the public REST API.
Best,
-jay
On 10/27/2014 10:01 AM, Kyle Mestery wrote:
On Sun, Oct 26, 2014 at 8:01 PM, Doug Wiegley do...@a10networks.com
wrote:
Hi Brandon,
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
I agree with this sentiment. I’d just like to pull-up to the decision
level, and if we can get some consensus on how we move forward, we can
bring a concrete plan to the summit instead of 40 minutes of Kumbaya.
We
love each other. Check. Things are going to change sometime. Check.
We
might spin-out someday. Check. Now, let’s jump to the interesting
part.
I think we all know we want to spin these out, as Doug says we just
need to have a plan around how we make that happen. I'm in agreement
with Doug's sentiment above.
3. The main reason a spin out makes sense from Neutron is that the
scope
for Neutron is too large for the attention advances services needs
from
the Neutron Core. If all of advanced services spins out, I see that
There is merit here, but consider the sorts of things that an advanced
services framework should be doing:
- plugging into neutron ports, with all manner of topologies
- service VM handling
- plugging into nova-network
- service chaining
- applying things like security groups to services
… this is all stuff that Octavia is talking about implementing itself
in a
basically defensive manner, instead of leveraging other work. And
there
are specific reasons for that. But, maybe we can at least take steps
to
not be incompatible about it. Or maybe there is a hierarchy of
Neutron -
Services - LB, where we’re still spun out, but not doing it in a way
that
we have to re-implement the world all the time. It’s at least worth a
conversation or three.
Doug, can you document this on the etherpad for the services spinout
[1]? I've added some brief text at the top on what the objective for
this session is, but documenting more along the lines of what you have
here would be good.
Thanks,
Kyle
[1] https://etherpad.openstack.org/p/neutron-services
Thanks,
Doug
On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
Good questions Doug. My answers are as follows:
1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the
scope
for Neutron is too large for the attention advances services needs
from
the Neutron Core. If all of advanced services spins out, I see that
repeating itself within an advanced services project. More and more
advanced services will get added in and the scope will become too
large. There would definitely be benefits to it though, but I think
we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
Yes the brunt of the time will not be spent on the API, but since it
seemed like an opportunity to kill two birds with one stone, I figured
it warranted a discussion.
Thanks,
Brandon
On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
Hi all,
Before we get into the details of which API goes where, I’d like to
see
us
answer the questions of:
1. Are we spinning out?
2. When?
3. With or without the rest of advanced services?
4. Do we want to wait until we (the royal “we” of “the Neutron team”)
have
had the Paris summit discussions on vendor split-out and adv.
services
spinout before we answer those questions? (Yes, that question is
leading.)
To me, the “where does the API live” is an implementation detail, and
not
where the time will need to be spent.
For the record, my answers are:
1. Yes.
2. I don’t know.
3. I don’t know; this needs some serious discussion.
4. Yes.
Thanks,
doug
On 10/24/14, 3:47 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
With the recent talk about advanced services spinning out of
Neutron,
and the fact most of the LBaaS community has wanted LBaaS to spin
out
of
Neutron, I wanted to bring up a possibility and gauge interest and
opinion on this possibility.
Octavia is going to (and has) an API. The current thinking is that
an
Octavia driver will be created in Neutron LBaaS that will make a
requests to the Octavia API. When

Hi Jay,
Just so you have some information on the API before the meeting here is
the spec for it:
https://review.openstack.org/#/c/122338/
I'm sure there is a lot of details that might be missing but it should
give you a decent idea. Sorry for the markup/markdown being dumb if you
try to build with spinx. Probably easier to just read the raw .rst
file.
Thanks,
Brandon
On Mon, 2014-10-27 at 14:05 -0400, Jay Pipes wrote:
Yup, can do! :)
-jay
On 10/27/2014 01:55 PM, Doug Wiegley wrote:
Hi Jay,
Let’s add that as an agenda item at our Weekly IRC meeting. Can you make
this timeslot?
https://wiki.openstack.org/wiki/Octavia#Meetings
Thanks,
Doug
On 10/27/14, 11:27 AM, Jay Pipes jaypi...@gmail.com wrote:
Sorry for top-posting, but where can the API working group see the
proposed Octavia API specification or documentation? I'd love it if the
API WG could be involved in reviewing the public REST API.
Best,
-jay
On 10/27/2014 10:01 AM, Kyle Mestery wrote:
On Sun, Oct 26, 2014 at 8:01 PM, Doug Wiegley do...@a10networks.com
wrote:
Hi Brandon,
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
I agree with this sentiment. I’d just like to pull-up to the decision
level, and if we can get some consensus on how we move forward, we can
bring a concrete plan to the summit instead of 40 minutes of Kumbaya.
We
love each other. Check. Things are going to change sometime. Check.
We
might spin-out someday. Check. Now, let’s jump to the interesting
part.
I think we all know we want to spin these out, as Doug says we just
need to have a plan around how we make that happen. I'm in agreement
with Doug's sentiment above.
3. The main reason a spin out makes sense from Neutron is that the
scope
for Neutron is too large for the attention advances services needs
from
the Neutron Core. If all of advanced services spins out, I see that
There is merit here, but consider the sorts of things that an advanced
services framework should be doing:
- plugging into neutron ports, with all manner of topologies
- service VM handling
- plugging into nova-network
- service chaining
- applying things like security groups to services
… this is all stuff that Octavia is talking about implementing itself
in a
basically defensive manner, instead of leveraging other work. And
there
are specific reasons for that. But, maybe we can at least take steps
to
not be incompatible about it. Or maybe there is a hierarchy of
Neutron -
Services - LB, where we’re still spun out, but not doing it in a way
that
we have to re-implement the world all the time. It’s at least worth a
conversation or three.
Doug, can you document this on the etherpad for the services spinout
[1]? I've added some brief text at the top on what the objective for
this session is, but documenting more along the lines of what you have
here would be good.
Thanks,
Kyle
[1] https://etherpad.openstack.org/p/neutron-services
Thanks,
Doug
On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
Good questions Doug. My answers are as follows:
1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the
scope
for Neutron is too large for the attention advances services needs
from
the Neutron Core. If all of advanced services spins out, I see that
repeating itself within an advanced services project. More and more
advanced services will get added in and the scope will become too
large. There would definitely be benefits to it though, but I think
we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
Yes the brunt of the time will not be spent on the API, but since it
seemed like an opportunity to kill two birds with one stone, I figured
it warranted a discussion.
Thanks,
Brandon
On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
Hi all,
Before we get into the details of which API goes where, I’d like to
see
us
answer the questions of:
1. Are we spinning out?
2. When?
3. With or without the rest of advanced services?
4. Do we want to wait until we (the royal “we” of “the Neutron team”)
have
had the Paris summit discussions on vendor split-out and adv.
services
spinout before we answer those questions? (Yes, that question is
leading.)
To me, the “where does the API live” is an implementation detail, and
not

Hi all,
Before we get into the details of which API goes where, I’d like to see us
answer the questions of:
1. Are we spinning out?
2. When?
3. With or without the rest of advanced services?
4. Do we want to wait until we (the royal “we” of “the Neutron team”) have
had the Paris summit discussions on vendor split-out and adv. services
spinout before we answer those questions? (Yes, that question is leading.)
To me, the “where does the API live” is an implementation detail, and not
where the time will need to be spent.
For the record, my answers are:
1. Yes.
2. I don’t know.
3. I don’t know; this needs some serious discussion.
4. Yes.
Thanks,
doug
On 10/24/14, 3:47 PM, Brandon Logan brandon.lo...@rackspace.com wrote:
With the recent talk about advanced services spinning out of Neutron,
and the fact most of the LBaaS community has wanted LBaaS to spin out of
Neutron, I wanted to bring up a possibility and gauge interest and
opinion on this possibility.
Octavia is going to (and has) an API. The current thinking is that an
Octavia driver will be created in Neutron LBaaS that will make a
requests to the Octavia API. When LBaaS spins out of Neutron, it will
need a standalone API. Octavia's API seems to be a good solution to
this. It will support vendor drivers much like the current Neutron
LBaaS does. It has a similar API as Neutron LBaaS v2, but its not an
exact duplicate. Octavia will be growing more mature in stackforge at a
higher velocity than an Openstack project, so I expect by the time Kilo
comes around it's API will be very mature.
Octavia's API doesn't have to be called Octavia either. It can be
separated out and it can be called Openstack LBaaS, and the rest of
Octavia (the actual brains of it) will just be another driver to
Openstack LBaaS, which would retain the Octavia name.
This is my PROS and CONS list to using Octavia's API as the spun out
LBaaS:
PROS
1. Time will need to be spent on a spun out LBaaS's API anyway. Octavia
will already have this done.
2. Most of the same people working on Octavia have worked on Neutron
LBaaS v2.
3. It's out of Neutron faster, which is good for Neutron and LBaaS.
CONS
1. The Octavia API is dissimilar enough from Neutron LBaaS v2 to be yet
another version of an LBaaS API.
2. The Octavia API will also have a separate Operator API which will
most likely only work with Octavia, not any vendors.
The CONS are easily solvable, and IMHO the PROS greatly outweigh the
CONS.
This is just my opinion though and I'd like to hear back from as many as
possible. Add on to the PROS and CONS if wanted.
If it is direction we can agree on going then we can add as a talking
point in the advanced services spin out meeting:
http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.
VEq66HWx3UY
Thanks,
Brandon
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Good questions Doug. My answers are as follows:
1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the scope
for Neutron is too large for the attention advances services needs from
the Neutron Core. If all of advanced services spins out, I see that
repeating itself within an advanced services project. More and more
advanced services will get added in and the scope will become too
large. There would definitely be benefits to it though, but I think we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
Yes the brunt of the time will not be spent on the API, but since it
seemed like an opportunity to kill two birds with one stone, I figured
it warranted a discussion.
Thanks,
Brandon
On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
Hi all,
Before we get into the details of which API goes where, I’d like to see us
answer the questions of:
1. Are we spinning out?
2. When?
3. With or without the rest of advanced services?
4. Do we want to wait until we (the royal “we” of “the Neutron team”) have
had the Paris summit discussions on vendor split-out and adv. services
spinout before we answer those questions? (Yes, that question is leading.)
To me, the “where does the API live” is an implementation detail, and not
where the time will need to be spent.
For the record, my answers are:
1. Yes.
2. I don’t know.
3. I don’t know; this needs some serious discussion.
4. Yes.
Thanks,
doug
On 10/24/14, 3:47 PM, Brandon Logan brandon.lo...@rackspace.com wrote:
With the recent talk about advanced services spinning out of Neutron,
and the fact most of the LBaaS community has wanted LBaaS to spin out of
Neutron, I wanted to bring up a possibility and gauge interest and
opinion on this possibility.
Octavia is going to (and has) an API. The current thinking is that an
Octavia driver will be created in Neutron LBaaS that will make a
requests to the Octavia API. When LBaaS spins out of Neutron, it will
need a standalone API. Octavia's API seems to be a good solution to
this. It will support vendor drivers much like the current Neutron
LBaaS does. It has a similar API as Neutron LBaaS v2, but its not an
exact duplicate. Octavia will be growing more mature in stackforge at a
higher velocity than an Openstack project, so I expect by the time Kilo
comes around it's API will be very mature.
Octavia's API doesn't have to be called Octavia either. It can be
separated out and it can be called Openstack LBaaS, and the rest of
Octavia (the actual brains of it) will just be another driver to
Openstack LBaaS, which would retain the Octavia name.
This is my PROS and CONS list to using Octavia's API as the spun out
LBaaS:
PROS
1. Time will need to be spent on a spun out LBaaS's API anyway. Octavia
will already have this done.
2. Most of the same people working on Octavia have worked on Neutron
LBaaS v2.
3. It's out of Neutron faster, which is good for Neutron and LBaaS.
CONS
1. The Octavia API is dissimilar enough from Neutron LBaaS v2 to be yet
another version of an LBaaS API.
2. The Octavia API will also have a separate Operator API which will
most likely only work with Octavia, not any vendors.
The CONS are easily solvable, and IMHO the PROS greatly outweigh the
CONS.
This is just my opinion though and I'd like to hear back from as many as
possible. Add on to the PROS and CONS if wanted.
If it is direction we can agree on going then we can add as a talking
point in the advanced services spin out meeting:
http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.
VEq66HWx3UY
Thanks,
Brandon
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Hi Brandon,
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
I agree with this sentiment. I’d just like to pull-up to the decision
level, and if we can get some consensus on how we move forward, we can
bring a concrete plan to the summit instead of 40 minutes of Kumbaya. We
love each other. Check. Things are going to change sometime. Check. We
might spin-out someday. Check. Now, let’s jump to the interesting part.
3. The main reason a spin out makes sense from Neutron is that the scope
for Neutron is too large for the attention advances services needs from
the Neutron Core. If all of advanced services spins out, I see that
There is merit here, but consider the sorts of things that an advanced
services framework should be doing:
- plugging into neutron ports, with all manner of topologies
- service VM handling
- plugging into nova-network
- service chaining
- applying things like security groups to services
… this is all stuff that Octavia is talking about implementing itself in a
basically defensive manner, instead of leveraging other work. And there
are specific reasons for that. But, maybe we can at least take steps to
not be incompatible about it. Or maybe there is a hierarchy of Neutron -
Services - LB, where we’re still spun out, but not doing it in a way that
we have to re-implement the world all the time. It’s at least worth a
conversation or three.
Thanks,
Doug
On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com wrote:
Good questions Doug. My answers are as follows:
1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the scope
for Neutron is too large for the attention advances services needs from
the Neutron Core. If all of advanced services spins out, I see that
repeating itself within an advanced services project. More and more
advanced services will get added in and the scope will become too
large. There would definitely be benefits to it though, but I think we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
Yes the brunt of the time will not be spent on the API, but since it
seemed like an opportunity to kill two birds with one stone, I figured
it warranted a discussion.
Thanks,
Brandon
On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
Hi all,
Before we get into the details of which API goes where, I’d like to see
us
answer the questions of:
1. Are we spinning out?
2. When?
3. With or without the rest of advanced services?
4. Do we want to wait until we (the royal “we” of “the Neutron team”)
have
had the Paris summit discussions on vendor split-out and adv. services
spinout before we answer those questions? (Yes, that question is
leading.)
To me, the “where does the API live” is an implementation detail, and
not
where the time will need to be spent.
For the record, my answers are:
1. Yes.
2. I don’t know.
3. I don’t know; this needs some serious discussion.
4. Yes.
Thanks,
doug
On 10/24/14, 3:47 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
With the recent talk about advanced services spinning out of Neutron,
and the fact most of the LBaaS community has wanted LBaaS to spin out
of
Neutron, I wanted to bring up a possibility and gauge interest and
opinion on this possibility.
Octavia is going to (and has) an API. The current thinking is that an
Octavia driver will be created in Neutron LBaaS that will make a
requests to the Octavia API. When LBaaS spins out of Neutron, it will
need a standalone API. Octavia's API seems to be a good solution to
this. It will support vendor drivers much like the current Neutron
LBaaS does. It has a similar API as Neutron LBaaS v2, but its not an
exact duplicate. Octavia will be growing more mature in stackforge at
a
higher velocity than an Openstack project, so I expect by the time Kilo
comes around it's API will be very mature.
Octavia's API doesn't have to be called Octavia either. It can be
separated out and it can be called Openstack LBaaS, and the rest of
Octavia (the actual brains of it) will just be another driver to
Openstack LBaaS, which would retain the Octavia name.
This is my PROS and CONS list to using Octavia's API as the spun out
LBaaS:
PROS
1. Time will need to be spent on a spun out LBaaS's API anyway.
Octavia
will already have this done.
2. Most of the same people working on Octavia have worked on Neutron
LBaaS v2.
3. It's out of Neutron faster, which is good for Neutron and LBaaS.
CONS
1. The Octavia

Hi Doug:
On 10/26/14, 6:01 PM, Doug Wiegley do...@a10networks.com wrote:
Hi Brandon,
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
I agree with this sentiment. I¹d just like to pull-up to the decision
level, and if we can get some consensus on how we move forward, we can
bring a concrete plan to the summit instead of 40 minutes of Kumbaya. We
love each other. Check. Things are going to change sometime. Check. We
might spin-out someday. Check. Now, let¹s jump to the interesting part.
3. The main reason a spin out makes sense from Neutron is that the scope
for Neutron is too large for the attention advances services needs from
the Neutron Core. If all of advanced services spins out, I see that
There is merit here, but consider the sorts of things that an advanced
services framework should be doing:
- plugging into neutron ports, with all manner of topologies
- service VM handling
- plugging into nova-network
- service chaining
- applying things like security groups to services
Š this is all stuff that Octavia is talking about implementing itself in a
basically defensive manner, instead of leveraging other work. And there
are specific reasons for that. But, maybe we can at least take steps to
not be incompatible about it. Or maybe there is a hierarchy of Neutron -
Services - LB, where we¹re still spun out, but not doing it in a way that
we have to re-implement the world all the time. It¹s at least worth a
conversation or three.
In total agreement and I have heard these sentiments in multiple
conversations across multiple players.
It would be really fruitful to have a constructive conversation on this
across the services, and there are
enough similar issues to make this worthwhile.
Thanks
Sridar
Thanks,
Doug
On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com wrote:
Good questions Doug. My answers are as follows:
1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the scope
for Neutron is too large for the attention advances services needs from
the Neutron Core. If all of advanced services spins out, I see that
repeating itself within an advanced services project. More and more
advanced services will get added in and the scope will become too
large. There would definitely be benefits to it though, but I think we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
Yes the brunt of the time will not be spent on the API, but since it
seemed like an opportunity to kill two birds with one stone, I figured
it warranted a discussion.
Thanks,
Brandon
On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
Hi all,
Before we get into the details of which API goes where, I¹d like to see
us
answer the questions of:
1. Are we spinning out?
2. When?
3. With or without the rest of advanced services?
4. Do we want to wait until we (the royal ³we² of ³the Neutron team²)
have
had the Paris summit discussions on vendor split-out and adv. services
spinout before we answer those questions? (Yes, that question is
leading.)
To me, the ³where does the API live² is an implementation detail, and
not
where the time will need to be spent.
For the record, my answers are:
1. Yes.
2. I don¹t know.
3. I don¹t know; this needs some serious discussion.
4. Yes.
Thanks,
doug
On 10/24/14, 3:47 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
With the recent talk about advanced services spinning out of Neutron,
and the fact most of the LBaaS community has wanted LBaaS to spin out
of
Neutron, I wanted to bring up a possibility and gauge interest and
opinion on this possibility.
Octavia is going to (and has) an API. The current thinking is that an
Octavia driver will be created in Neutron LBaaS that will make a
requests to the Octavia API. When LBaaS spins out of Neutron, it will
need a standalone API. Octavia's API seems to be a good solution to
this. It will support vendor drivers much like the current Neutron
LBaaS does. It has a similar API as Neutron LBaaS v2, but its not an
exact duplicate. Octavia will be growing more mature in stackforge at
a
higher velocity than an Openstack project, so I expect by the time
Kilo
comes around it's API will be very mature.
Octavia's API doesn't have to be called Octavia either. It can be
separated out and it can be called Openstack LBaaS, and the rest of
Octavia (the actual brains of it) will just be another driver to
Openstack LBaaS, which would retain the Octavia name.
This is my

Several people have been requesting that we resume the Advanced
Services' meetings [1] to discuss some of the topics being mentioned
in this thread. Perhaps it might help people to have a focussed
discussion on the topic of advanced services' spin-out prior to the
design summit session [2] in Paris. So I propose that we resume our
weekly IRC meetings starting this Wednesday (Oct 29th), 17.30 UTC on
#openstack-meeting-3.
Thanks,
~Sumit.
[1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices
[2]
http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VE3Ukot4r4y
On Sun, Oct 26, 2014 at 7:55 PM, Sridar Kandaswamy (skandasw)
skand...@cisco.com wrote:
Hi Doug:
On 10/26/14, 6:01 PM, Doug Wiegley do...@a10networks.com wrote:
Hi Brandon,
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
I agree with this sentiment. I¹d just like to pull-up to the decision
level, and if we can get some consensus on how we move forward, we can
bring a concrete plan to the summit instead of 40 minutes of Kumbaya. We
love each other. Check. Things are going to change sometime. Check. We
might spin-out someday. Check. Now, let¹s jump to the interesting part.
3. The main reason a spin out makes sense from Neutron is that the scope
for Neutron is too large for the attention advances services needs from
the Neutron Core. If all of advanced services spins out, I see that
There is merit here, but consider the sorts of things that an advanced
services framework should be doing:
- plugging into neutron ports, with all manner of topologies
- service VM handling
- plugging into nova-network
- service chaining
- applying things like security groups to services
Š this is all stuff that Octavia is talking about implementing itself in a
basically defensive manner, instead of leveraging other work. And there
are specific reasons for that. But, maybe we can at least take steps to
not be incompatible about it. Or maybe there is a hierarchy of Neutron -
Services - LB, where we¹re still spun out, but not doing it in a way that
we have to re-implement the world all the time. It¹s at least worth a
conversation or three.
In total agreement and I have heard these sentiments in multiple
conversations across multiple players.
It would be really fruitful to have a constructive conversation on this
across the services, and there are
enough similar issues to make this worthwhile.
Thanks
Sridar
Thanks,
Doug
On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com wrote:
Good questions Doug. My answers are as follows:
1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the scope
for Neutron is too large for the attention advances services needs from
the Neutron Core. If all of advanced services spins out, I see that
repeating itself within an advanced services project. More and more
advanced services will get added in and the scope will become too
large. There would definitely be benefits to it though, but I think we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session. I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.
Yes the brunt of the time will not be spent on the API, but since it
seemed like an opportunity to kill two birds with one stone, I figured
it warranted a discussion.
Thanks,
Brandon
On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
Hi all,
Before we get into the details of which API goes where, I¹d like to see
us
answer the questions of:
1. Are we spinning out?
2. When?
3. With or without the rest of advanced services?
4. Do we want to wait until we (the royal ³we² of ³the Neutron team²)
have
had the Paris summit discussions on vendor split-out and adv. services
spinout before we answer those questions? (Yes, that question is
leading.)
To me, the ³where does the API live² is an implementation detail, and
not
where the time will need to be spent.
For the record, my answers are:
1. Yes.
2. I don¹t know.
3. I don¹t know; this needs some serious discussion.
4. Yes.
Thanks,
doug
On 10/24/14, 3:47 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
With the recent talk about advanced services spinning out of Neutron,
and the fact most of the LBaaS community has wanted LBaaS to spin out
of
Neutron, I wanted to bring up a possibility and gauge interest and
opinion on this possibility.
Octavia is going to (and has) an API. The current thinking is that an
Octavia driver will be created in Neutron LBaaS that will make a
requests to the Octavia API. When LBaaS spins out of Neutron,

+1 to this, eh!
Though it sounds more like you're talking about spinning the Octavia user
API out of Octavia to become it's own thing (ie. Openstack LBaaS), and
then ensuring a standardized driver interface that vendors (including
Octavia) will interface with. It's sort of a half-dozen of one, six of the
other kind of deal.
To the pros, I would add: Spin out from Neutron ensures that LBaaS uses
clean interfaces to the networking layer, and separation of concerns here
means that Neutron and LBaaS can evolve independently. (And testing and
failure modes, etc. all become easier with separation of concerns.)
One other thing to consider (not sure if pro or con): I know at Atlanta
there was a lot of talk around using the Neutron flavor framework to allow
for multiple vendors in a single installation as well as differentiated
product offerings for Operators. If / when LBaaS is spun out of Neutron,
LBaaS will still probably have need for something like Neutron flavors,
even if it isn't an equivalent implementation. (Noting of course, that no
implementation of Neutron flavors actually presently exists. XD )
Stephen
On Fri, Oct 24, 2014 at 2:47 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
With the recent talk about advanced services spinning out of Neutron,
and the fact most of the LBaaS community has wanted LBaaS to spin out of
Neutron, I wanted to bring up a possibility and gauge interest and
opinion on this possibility.
Octavia is going to (and has) an API. The current thinking is that an
Octavia driver will be created in Neutron LBaaS that will make a
requests to the Octavia API. When LBaaS spins out of Neutron, it will
need a standalone API. Octavia's API seems to be a good solution to
this. It will support vendor drivers much like the current Neutron
LBaaS does. It has a similar API as Neutron LBaaS v2, but its not an
exact duplicate. Octavia will be growing more mature in stackforge at a
higher velocity than an Openstack project, so I expect by the time Kilo
comes around it's API will be very mature.
Octavia's API doesn't have to be called Octavia either. It can be
separated out and it can be called Openstack LBaaS, and the rest of
Octavia (the actual brains of it) will just be another driver to
Openstack LBaaS, which would retain the Octavia name.
This is my PROS and CONS list to using Octavia's API as the spun out
LBaaS:
PROS
1. Time will need to be spent on a spun out LBaaS's API anyway. Octavia
will already have this done.
2. Most of the same people working on Octavia have worked on Neutron
LBaaS v2.
3. It's out of Neutron faster, which is good for Neutron and LBaaS.
CONS
1. The Octavia API is dissimilar enough from Neutron LBaaS v2 to be yet
another version of an LBaaS API.
2. The Octavia API will also have a separate Operator API which will
most likely only work with Octavia, not any vendors.
The CONS are easily solvable, and IMHO the PROS greatly outweigh the
CONS.
This is just my opinion though and I'd like to hear back from as many as
possible. Add on to the PROS and CONS if wanted.
If it is direction we can agree on going then we can add as a talking
point in the advanced services spin out meeting:
http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VEq66HWx3UY
Thanks,
Brandon
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev