Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
On 9/6/2016 2:48 PM, Martin Millnert wrote: Hi, Goal: I'd like to replicate the industry standard of providing a on-by- default (UI) option to auto-assign a floating IP to a newly launched instance. It must be toggleable however (to follow industry standard). Floating IPs aren't required in OpenStack deployments, and anyone running with cells v1 (Rackspace, GoDaddy, NeCTAR, CERN) doesn't use or support them, at least without patching Nova. So I'm not sure what 'industry standard' is being referred to here. With openstackclient I'm hoping the feature could be added through e.g "--auto-assign-floating-ip", where it is unspecified where the stateful glue logic actually resides. Scenario: We use Horizon as UI and OpenContrail as VPC provider, where our virtual networks by default really are private networks, e.g. following actual industry standard VPC behaviour. Our users are today required to themselves perform the Assign Floating IP operation [1] operation before their instance has achieved what 98% of users desire. So this is both unexpected for users and likewise far from industry standard (defaults should make a happy user). Problem: Recognizing that deployments are different, and this probably won't satisfy 100% of deployments architecture, there is furthermore the unfortunate situation of: - nova: we're not adding anything Correct, nova provides the APIs to do this already, something sitting on top just needs to use them to orchestrate your use case. - horizon: UI's not a brain I'm aware of the "--get-me-a-network" effort which is admirable. I haven't been on top of its progress, but from what I understand today it hasn't seen the light of day yet. Any update aligned with my goal would be helpful. The get-me-a-network work is complete with the 2.37 API microversion in Nova and the 6.0.0 python-novaclient release. You can test it out today. However, it does not allocate and auto-assign a floating IP. So how can one solve an OpenStack cross-project problem like this, possibly without having to implement an artificial superintelligence first? Orchestrate on top of Nova's APIs, either in your own CLI, or UI, or maybe even Heat would support this. For any operators around who've dealt with this, and possibly run a proprietary UI: Have you perchance added an ... "instance launch orchestrator" that takes arguments to this dear instance orchestration platform, seeing that Nova in fact *isn't* an "instance launch orchestrator" (at least not moddable)? We're at the point where we want this so much that we'll do it regardless of upstream, but I can't for the life of me think that we're alone with the use case. Regards, Martin Millnert [1] http://developer.openstack.org/api-ref/networking/v2/index.html?exp anded=create-floating-ip-detail __ 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 -- Thanks, Matt Riedemann __ 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
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
Hi Matt, On Tue, 2016-09-06 at 16:39 -0500, Matt Riedemann wrote: > Floating IPs aren't required in OpenStack deployments, and anyone > running with cells v1 (Rackspace, GoDaddy, NeCTAR, CERN) doesn't use > or > support them, at least without patching Nova. So I'm not sure what > 'industry standard' is being referred to here. Nod. There are many models, I acknowledge that as well. When referring to 'industry standard', I refer to e.g. default EC2 VPC or GCE non- legacy network behaviour. I didn't mean to imply that this model is the only one, not even the best one, just the most widely used one at large. > > Problem: > > - nova: we're not adding anything > > Correct, nova provides the APIs to do this already, something sitting > on top just needs to use them to orchestrate your use case. It exists in terms of multiple calls, yes. My e-mail is about what the best multi-project solution to improving the total logic required to achieve the goal, within OpenStack. It's not clear the answer is to improve Nova's server create API, but it is one very obvious candidate solution. > The get-me-a-network work is complete with the 2.37 API microversion > in Nova and the 6.0.0 python-novaclient release. You can test it out > today. > However, it does not allocate and auto-assign a floating IP. I'd argue that what a typical user is most interested in is not, in fact, in "having a network", but, "having internet access". Nova has the POST /servers 'fixed_ip' and 'networks' keys. Neither one of them, as you point out, deals with auto-allocating-and-assigning FIPs, which is fine in and of itself - Rome wasn't built in one day either. I.e. today, A) 'networks=auto' != "get me online", B) 'networks=auto' == "get me an openstack network interface". B is a subset of A, but A is not a subset of B. Assuming, 1) 'networks' is definitely meant to mean just what it's called, and does today, and 2) "get me online" is a desirable feature, then it is actually the case that we're missing an option like "public_ip=auto" or similar to complete the picture. In the deployments you mention above, it'd have virtually nothing to do. In others, for example FIP, it'd have only little to do. Then, the combination networks=auto, public_ip(v4)=auto would equal "getmeonline". > > So how can one solve an OpenStack cross-project problem like this, > > possibly without having to implement an artificial > > superintelligence > > first? > > Orchestrate on top of Nova's APIs, either in your own CLI, or UI, or > maybe even Heat would support this. Right, the total amount of options are thus: 1) Introduce a new, custom API service to proxy for Nova, and fork Horizon to handle it, 2) Patch Nova and do UI fixes in Horizon, but do not submit it upstream, 3) Patch Nova and do UI fixes in Horizon, and submit it upstream, 4) Make Horizon stateful and do UI changes, but do not submit it upstream, 5) Make Horizon stateful and do UI changes, and submit it upstream I'm sure there are more enumerations of this, but Heat is not one of them. :-) To me, from the above, option 3 seems the one that involves the least amount of complexity, which already there is a good indication of being the right choice. Best regards, Martin __ 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
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
On Wed, Sep 7, 2016, at 04:31 AM, Martin Millnert wrote: > Hi Matt, > > On Tue, 2016-09-06 at 16:39 -0500, Matt Riedemann wrote: > > Floating IPs aren't required in OpenStack deployments, and anyone > > running with cells v1 (Rackspace, GoDaddy, NeCTAR, CERN) doesn't use > > or > > support them, at least without patching Nova. So I'm not sure what > > 'industry standard' is being referred to here. > > Nod. There are many models, I acknowledge that as well. When referring > to 'industry standard', I refer to e.g. default EC2 VPC or GCE non- > legacy network behaviour. I didn't mean to imply that this model is the > only one, not even the best one, just the most widely used one at > large. > > > > Problem: > > > - nova: we're not adding anything > > > > Correct, nova provides the APIs to do this already, something sitting > > on top just needs to use them to orchestrate your use case. > > It exists in terms of multiple calls, yes. My e-mail is about what the > best multi-project solution to improving the total logic required to > achieve the goal, within OpenStack. It's not clear the answer is to > improve Nova's server create API, but it is one very obvious candidate > solution. > > > The get-me-a-network work is complete with the 2.37 API microversion > > in Nova and the 6.0.0 python-novaclient release. You can test it out > > today. > > However, it does not allocate and auto-assign a floating IP. > > I'd argue that what a typical user is most interested in is not, in > fact, in "having a network", but, "having internet access". > > Nova has the POST /servers 'fixed_ip' and 'networks' keys. Neither one > of them, as you point out, deals with auto-allocating-and-assigning > FIPs, which is fine in and of itself - Rome wasn't built in one day > either. > > I.e. today, > A) 'networks=auto' != "get me online", > B) 'networks=auto' == "get me an openstack network interface". > > B is a subset of A, but A is not a subset of B. > > Assuming, > 1) 'networks' is definitely meant to mean just what it's called, and does > today, and > 2) "get me online" is a desirable feature, > > then it is actually the case that we're missing an option like > "public_ip=auto" or similar to complete the picture. > In the deployments you mention above, it'd have virtually nothing to do. > In others, for example FIP, it'd have only little to do. > > Then, the combination networks=auto, public_ip(v4)=auto would equal > "getmeonline". > > > > So how can one solve an OpenStack cross-project problem like > this, > > > possibly without having to implement an artificial > > > superintelligence > > > first? > > > > Orchestrate on top of Nova's APIs, either in your own CLI, or UI, or > > maybe even Heat would support this. > > Right, the total amount of options are thus: > 1) Introduce a new, custom API service to proxy for Nova, and fork > Horizon to handle it, I would change this slightly and say that my preference would be to have a new API service which can handle cross project orchestration needs. Things like what you're discussing, or creating a volume and booting from it, and many other things that require a client to touch multiple services. I believe there's a gap here that Heat doesn't fill and that encourages people to think that adding orchestration to Nova is the right thing to do. > 2) Patch Nova and do UI fixes in Horizon, but do not submit it > upstream, > 3) Patch Nova and do UI fixes in Horizon, and submit it upstream, > 4) Make Horizon stateful and do UI changes, but do not submit it > upstream, > 5) Make Horizon stateful and do UI changes, and submit it upstream > > I'm sure there are more enumerations of this, but Heat is not one of > them. :-) > > To me, from the above, option 3 seems the one that involves the least > amount of complexity, which already there is a good indication of being > the right choice. > > Best regards, > Martin > > __ > 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 __ 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
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
On 09/07/2016 03:31 AM, Martin Millnert wrote: > Hi Matt, > > On Tue, 2016-09-06 at 16:39 -0500, Matt Riedemann wrote: >> Floating IPs aren't required in OpenStack deployments, and anyone >> running with cells v1 (Rackspace, GoDaddy, NeCTAR, CERN) doesn't use >> or >> support them, at least without patching Nova. So I'm not sure what >> 'industry standard' is being referred to here. > > Nod. There are many models, I acknowledge that as well. When referring > to 'industry standard', I refer to e.g. default EC2 VPC or GCE non- > legacy network behaviour. I didn't mean to imply that this model is the > only one, not even the best one, just the most widely used one at > large. It's a terrible networking choice. NAT is a terrible model for doing networking on the Internet. One of the things I'm most proud of about OpenStack is that we allow people to make clouds that are not inherently broken like AWS and GCE are. THAT SAID "I would like to boot a VM that has a public IP" is a very clear use case, and it's very hard to achieve across OpenStack clouds. If you want to gouge your eyes out, go read the giant pile of code in the shade library which implements this. So - yes please on the feature - although it should be called "--auto-assign-public-ip" or "--auto-assign-external-ip" or something, not floating - because part of the problem is actually knowing whether or not the cloud requires floating ips or doesn't. However, as I mentioned, it's a GIANT amount of code to get this 'right'. We've gone thought a ton of iterations on it over the last 2 years - I recommend strongly not starting from scratch. >>> Problem: >>> - nova: we're not adding anything >> >> Correct, nova provides the APIs to do this already, something sitting >> on top just needs to use them to orchestrate your use case. > > It exists in terms of multiple calls, yes. My e-mail is about what the > best multi-project solution to improving the total logic required to > achieve the goal, within OpenStack. It's not clear the answer is to > improve Nova's server create API, but it is one very obvious candidate > solution. It would be the nicest thing, but it would also require nova to learn a lot more about neutron than it currently needs to know. >> The get-me-a-network work is complete with the 2.37 API microversion >> in Nova and the 6.0.0 python-novaclient release. You can test it out >> today. >> However, it does not allocate and auto-assign a floating IP. > > I'd argue that what a typical user is most interested in is not, in > fact, in "having a network", but, "having internet access". Yes, this is correct. > Nova has the POST /servers 'fixed_ip' and 'networks' keys. Neither one > of them, as you point out, deals with auto-allocating-and-assigning > FIPs, which is fine in and of itself - Rome wasn't built in one day > either. > > I.e. today, > A) 'networks=auto' != "get me online", > B) 'networks=auto' == "get me an openstack network interface". > > B is a subset of A, but A is not a subset of B. > > Assuming, > 1) 'networks' is definitely meant to mean just what it's called, and does > today, and > 2) "get me online" is a desirable feature, > > then it is actually the case that we're missing an option like > "public_ip=auto" or similar to complete the picture. > In the deployments you mention above, it'd have virtually nothing to do. In > others, for example FIP, it'd have only little to do. > > Then, the combination networks=auto, public_ip(v4)=auto would equal > "getmeonline". Yes. This is, in fact, how the shade create_server API works. >>> So how can one solve an OpenStack cross-project problem like > this, >>> possibly without having to implement an artificial >>> superintelligence >>> first? >> >> Orchestrate on top of Nova's APIs, either in your own CLI, or UI, or >> maybe even Heat would support this. > > Right, the total amount of options are thus: > 1) Introduce a new, custom API service to proxy for Nova, and fork > Horizon to handle it, > 2) Patch Nova and do UI fixes in Horizon, but do not submit it > upstream, > 3) Patch Nova and do UI fixes in Horizon, and submit it upstream, > 4) Make Horizon stateful and do UI changes, but do not submit it > upstream, > 5) Make Horizon stateful and do UI changes, and submit it upstream > > I'm sure there are more enumerations of this, but Heat is not one of > them. :-) > > To me, from the above, option 3 seems the one that involves the least > amount of complexity, which already there is a good indication of being > the right choice. I think the complexity in 3 should not be understated... but please don't fork and not submit upstream... :) Monty __ 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
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
On the flip side, so is "I want my vm on a private network and I want a floating ip to attach it to the public network." As some clouds don't support it. Thanks, Kevin From: Monty Taylor [mord...@inaugust.com] Sent: Wednesday, September 07, 2016 8:55 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP On 09/07/2016 03:31 AM, Martin Millnert wrote: > Hi Matt, > > On Tue, 2016-09-06 at 16:39 -0500, Matt Riedemann wrote: >> Floating IPs aren't required in OpenStack deployments, and anyone >> running with cells v1 (Rackspace, GoDaddy, NeCTAR, CERN) doesn't use >> or >> support them, at least without patching Nova. So I'm not sure what >> 'industry standard' is being referred to here. > > Nod. There are many models, I acknowledge that as well. When referring > to 'industry standard', I refer to e.g. default EC2 VPC or GCE non- > legacy network behaviour. I didn't mean to imply that this model is the > only one, not even the best one, just the most widely used one at > large. It's a terrible networking choice. NAT is a terrible model for doing networking on the Internet. One of the things I'm most proud of about OpenStack is that we allow people to make clouds that are not inherently broken like AWS and GCE are. THAT SAID "I would like to boot a VM that has a public IP" is a very clear use case, and it's very hard to achieve across OpenStack clouds. If you want to gouge your eyes out, go read the giant pile of code in the shade library which implements this. So - yes please on the feature - although it should be called "--auto-assign-public-ip" or "--auto-assign-external-ip" or something, not floating - because part of the problem is actually knowing whether or not the cloud requires floating ips or doesn't. However, as I mentioned, it's a GIANT amount of code to get this 'right'. We've gone thought a ton of iterations on it over the last 2 years - I recommend strongly not starting from scratch. >>> Problem: >>> - nova: we're not adding anything >> >> Correct, nova provides the APIs to do this already, something sitting >> on top just needs to use them to orchestrate your use case. > > It exists in terms of multiple calls, yes. My e-mail is about what the > best multi-project solution to improving the total logic required to > achieve the goal, within OpenStack. It's not clear the answer is to > improve Nova's server create API, but it is one very obvious candidate > solution. It would be the nicest thing, but it would also require nova to learn a lot more about neutron than it currently needs to know. >> The get-me-a-network work is complete with the 2.37 API microversion >> in Nova and the 6.0.0 python-novaclient release. You can test it out >> today. >> However, it does not allocate and auto-assign a floating IP. > > I'd argue that what a typical user is most interested in is not, in > fact, in "having a network", but, "having internet access". Yes, this is correct. > Nova has the POST /servers 'fixed_ip' and 'networks' keys. Neither one > of them, as you point out, deals with auto-allocating-and-assigning > FIPs, which is fine in and of itself - Rome wasn't built in one day > either. > > I.e. today, > A) 'networks=auto' != "get me online", > B) 'networks=auto' == "get me an openstack network interface". > > B is a subset of A, but A is not a subset of B. > > Assuming, > 1) 'networks' is definitely meant to mean just what it's called, and does > today, and > 2) "get me online" is a desirable feature, > > then it is actually the case that we're missing an option like > "public_ip=auto" or similar to complete the picture. > In the deployments you mention above, it'd have virtually nothing to do. In > others, for example FIP, it'd have only little to do. > > Then, the combination networks=auto, public_ip(v4)=auto would equal > "getmeonline". Yes. This is, in fact, how the shade create_server API works. >>> So how can one solve an OpenStack cross-project problem like > this, >>> possibly without having to implement an artificial >>> superintelligence >>> first? >> >> Orchestrate on top of Nova's APIs, either in your own CLI, or UI, or >> maybe even Heat would support this. > > Right, the total amount of options are thus: > 1) Introduce a new, custom API service to proxy for Nova, and fork >
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
On 09/07/2016 11:27 AM, Fox, Kevin M wrote: > On the flip side, so is "I want my vm on a private network and I want a > floating ip to attach it to the public network." > > As some clouds don't support it. Yes. I'd categorize the main things possible as: "I want a VM on a public network" "I want a VM on a private network" "I want a VM on both a public and private network" For both instances of "public network" - there are: "I want a public IP and do not care how that happens" "I specifically want a floating IP" "I specifically want a non-floating IP" I'd argue though that the on the clouds where you have the option of a direct attached public IP and also of getting a floating IP, the people from the: "I want a VM on both a public and private network" camp who explicitly want a floating and not a fixed public IP are users whom a "give me an auto public ip" feature is likely not going to serve without making that feature too complex. It is already completely possible for a user to create a server without an auto function, and then to select a floating ip if that is a construct they desire. With using an auto function, the user is effectively saying: "I want a public IP and do not care how that happens" which is the use case that is not possible today unless you happen to be a shade user. > > From: Monty Taylor [mord...@inaugust.com] > Sent: Wednesday, September 07, 2016 8:55 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance > with Floating IP > > On 09/07/2016 03:31 AM, Martin Millnert wrote: >> Hi Matt, >> >> On Tue, 2016-09-06 at 16:39 -0500, Matt Riedemann wrote: >>> Floating IPs aren't required in OpenStack deployments, and anyone >>> running with cells v1 (Rackspace, GoDaddy, NeCTAR, CERN) doesn't use >>> or >>> support them, at least without patching Nova. So I'm not sure what >>> 'industry standard' is being referred to here. >> >> Nod. There are many models, I acknowledge that as well. When referring >> to 'industry standard', I refer to e.g. default EC2 VPC or GCE non- >> legacy network behaviour. I didn't mean to imply that this model is the >> only one, not even the best one, just the most widely used one at >> large. > > It's a terrible networking choice. NAT is a terrible model for doing > networking on the Internet. One of the things I'm most proud of about > OpenStack is that we allow people to make clouds that are not inherently > broken like AWS and GCE are. > > THAT SAID > > "I would like to boot a VM that has a public IP" > > is a very clear use case, and it's very hard to achieve across OpenStack > clouds. If you want to gouge your eyes out, go read the giant pile of > code in the shade library which implements this. > > So - yes please on the feature - although it should be called > "--auto-assign-public-ip" or "--auto-assign-external-ip" or something, > not floating - because part of the problem is actually knowing whether > or not the cloud requires floating ips or doesn't. > > However, as I mentioned, it's a GIANT amount of code to get this > 'right'. We've gone thought a ton of iterations on it over the last 2 > years - I recommend strongly not starting from scratch. > >>>> Problem: >>>> - nova: we're not adding anything >>> >>> Correct, nova provides the APIs to do this already, something sitting >>> on top just needs to use them to orchestrate your use case. >> >> It exists in terms of multiple calls, yes. My e-mail is about what the >> best multi-project solution to improving the total logic required to >> achieve the goal, within OpenStack. It's not clear the answer is to >> improve Nova's server create API, but it is one very obvious candidate >> solution. > > It would be the nicest thing, but it would also require nova to learn a > lot more about neutron than it currently needs to know. > >>> The get-me-a-network work is complete with the 2.37 API microversion >>> in Nova and the 6.0.0 python-novaclient release. You can test it out >>> today. >>> However, it does not allocate and auto-assign a floating IP. >> >> I'd argue that what a typical user is most interested in is not, in >> fact, in "having a network", but, "having internet access". > > Yes, this is correct. > >> Nova has the POST /servers
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
Right. I use floating ip's because I need the flexibility to have an ip out last the vm its attached to. auto floating ip's are in the "just put this on the network, I don't care what happens when I need to delete my vm" kind of thing. which just having public ip's also could also solve. Thanks, Kevin From: Monty Taylor [mord...@inaugust.com] Sent: Wednesday, September 07, 2016 10:00 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP On 09/07/2016 11:27 AM, Fox, Kevin M wrote: > On the flip side, so is "I want my vm on a private network and I want a > floating ip to attach it to the public network." > > As some clouds don't support it. Yes. I'd categorize the main things possible as: "I want a VM on a public network" "I want a VM on a private network" "I want a VM on both a public and private network" For both instances of "public network" - there are: "I want a public IP and do not care how that happens" "I specifically want a floating IP" "I specifically want a non-floating IP" I'd argue though that the on the clouds where you have the option of a direct attached public IP and also of getting a floating IP, the people from the: "I want a VM on both a public and private network" camp who explicitly want a floating and not a fixed public IP are users whom a "give me an auto public ip" feature is likely not going to serve without making that feature too complex. It is already completely possible for a user to create a server without an auto function, and then to select a floating ip if that is a construct they desire. With using an auto function, the user is effectively saying: "I want a public IP and do not care how that happens" which is the use case that is not possible today unless you happen to be a shade user. > ________________ > From: Monty Taylor [mord...@inaugust.com] > Sent: Wednesday, September 07, 2016 8:55 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance > with Floating IP > > On 09/07/2016 03:31 AM, Martin Millnert wrote: >> Hi Matt, >> >> On Tue, 2016-09-06 at 16:39 -0500, Matt Riedemann wrote: >>> Floating IPs aren't required in OpenStack deployments, and anyone >>> running with cells v1 (Rackspace, GoDaddy, NeCTAR, CERN) doesn't use >>> or >>> support them, at least without patching Nova. So I'm not sure what >>> 'industry standard' is being referred to here. >> >> Nod. There are many models, I acknowledge that as well. When referring >> to 'industry standard', I refer to e.g. default EC2 VPC or GCE non- >> legacy network behaviour. I didn't mean to imply that this model is the >> only one, not even the best one, just the most widely used one at >> large. > > It's a terrible networking choice. NAT is a terrible model for doing > networking on the Internet. One of the things I'm most proud of about > OpenStack is that we allow people to make clouds that are not inherently > broken like AWS and GCE are. > > THAT SAID > > "I would like to boot a VM that has a public IP" > > is a very clear use case, and it's very hard to achieve across OpenStack > clouds. If you want to gouge your eyes out, go read the giant pile of > code in the shade library which implements this. > > So - yes please on the feature - although it should be called > "--auto-assign-public-ip" or "--auto-assign-external-ip" or something, > not floating - because part of the problem is actually knowing whether > or not the cloud requires floating ips or doesn't. > > However, as I mentioned, it's a GIANT amount of code to get this > 'right'. We've gone thought a ton of iterations on it over the last 2 > years - I recommend strongly not starting from scratch. > >>>> Problem: >>>> - nova: we're not adding anything >>> >>> Correct, nova provides the APIs to do this already, something sitting >>> on top just needs to use them to orchestrate your use case. >> >> It exists in terms of multiple calls, yes. My e-mail is about what the >> best multi-project solution to improving the total logic required to >> achieve the goal, within OpenStack. It's not clear the answer is to >> improve Nova's server create API, but it is one very obvious candidate >> solution. > > It would be the nicest thing, but it would also require nova
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
This is exactly what something like Minstral would be fantastic for. Multi-project workflow. Rather than try and build logic like this directly into nova, looks at extending something like Minstral with a basic easy to call task. __ 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
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
I've typically used heat to do this too. As it has a nice way out of the box to to undo the actions it does. Thanks, Kevin From: Adrian Turjak [adri...@catalyst.net.nz] Sent: Wednesday, September 07, 2016 2:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP This is exactly what something like Minstral would be fantastic for. Multi-project workflow. Rather than try and build logic like this directly into nova, looks at extending something like Minstral with a basic easy to call task. __ 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
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
Heat is a bit of overkill for something as tiny as this. I was mainly responding to Andrew Laski's comment talking about a service exactly like Minstral, for smaller cross project orchestration of finite tasks. On 8/09/2016 10:12 AM, "Fox, Kevin M" wrote: > > I've typically used heat to do this too. As it has a nice way out of the box to to undo the actions it does. > > Thanks, > Kevin > > From: Adrian Turjak [adri...@catalyst.net.nz] > Sent: Wednesday, September 07, 2016 2:34 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP > > This is exactly what something like Minstral would be fantastic for. Multi-project workflow. > > Rather than try and build logic like this directly into nova, looks at extending something like Minstral with a basic easy to call task. __ 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
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: > This is exactly what something like Minstral would be fantastic for. > Multi-project workflow. > Rather than try and build logic like this directly into nova, looks > at extending something like Minstral with a basic easy to call task. I have API- and code-reading homework to do here - but based on input on IRC, and efforts thus far, the ideal solution is not really to bolt a humongous piece of logic onto Nova. Rather it is appears to be first and foremost Neutron that need a little bit more intelligence regarding its virtual networks and the intentions of its operators. From what I can tell, Mistral is a very useful project for scheduling recurring tasks or similar, which there is a definite need of in a mature deployment. But I disagree with the "solve it with a new project"-approach here: 1) "launch my instance" is as core as it gets in OpenStack, 2) "launch my instance with Internet" is approximately identically as core, just a bit difficult for $reasons and not fully supported today, 3) core functionality should IMO require as few API calls as possible, to as few components as possible, while keeping REST data models etc. intact, [1][2] 4) there are timing concerns with adding Internet to an instance today in OpenStack, since it in some cases needs to happen somewhere between the events "network port created" and "instance launched", in order for the instance to actually have Internet when it boots, 5) Scheduling "Launch instance with Internet" or "Add Internet to instance" via something like Mistral would additionally either, A) add a significant delay to the boot time, or B) not even fulfill the objective of having Internet once instance powers on, 6) To replicate the logic of shade's "get me online" functions, a large amount of code is required, and depending on how you go about it, you also risk duplicating logic already in e.g. Nova or Neutron. Best regards, Martin [1] "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery [2] https://tools.ietf.org/rfcdiff?url2=draft-heitz-idr-large-community -02.txt (example of commendable improvement almost unheard of within the IETF) __ 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
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote: > On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: > > This is exactly what something like Minstral would be fantastic for. > > Multi-project workflow. > > Rather than try and build logic like this directly into nova, looks > > at extending something like Minstral with a basic easy to call task. > > I have API- and code-reading homework to do here - but based on input > on IRC, and efforts thus far, the ideal solution is not really to bolt > a humongous piece of logic onto Nova. Rather it is appears to be first > and foremost Neutron that need a little bit more intelligence regarding > its virtual networks and the intentions of its operators. > > From what I can tell, Mistral is a very useful project for scheduling > recurring tasks or similar, which there is a definite need of in a > mature deployment. > > But I disagree with the "solve it with a new project"-approach here: > > 1) "launch my instance" is as core as it gets in OpenStack, > > 2) "launch my instance with Internet" is approximately identically as > core, just a bit difficult for $reasons and not fully supported today, > > 3) core functionality should IMO require as few API calls as possible, > to as few components as possible, while keeping REST data models etc. > intact, [1][2] I agree that it should require as few API calls as possible but maybe we disagree about what core functionality is. Or to put it another way, what is core functionality depends on your perspective. I subscribe to the plumbing and porcelain approach (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) and believe that Nova should be part of the plumbing. So while I fully agree with a small number of API calls to do simple tasks I don't believe that orchestrating network setups is core functionality in Nova but is core to OpenStack. > > 4) there are timing concerns with adding Internet to an instance today > in OpenStack, since it in some cases needs to happen somewhere between > the events "network port created" and "instance launched", in order for > the instance to actually have Internet when it boots, > > 5) Scheduling "Launch instance with Internet" or "Add Internet to > instance" via something like Mistral would additionally either, A) add > a significant delay to the boot time, or B) not even fulfill the > objective of having Internet once instance powers on, > > 6) To replicate the logic of shade's "get me online" functions, a > large amount of code is required, and depending on how you go about it, > you also risk duplicating logic already in e.g. Nova or Neutron. > > Best regards, > Martin > > [1] "A designer knows he has achieved perfection not when there is > nothing left to add, but when there is nothing left to take away." > -- Antoine de Saint-Exupery > [2] https://tools.ietf.org/rfcdiff?url2=draft-heitz-idr-large-community > -02.txt (example of commendable improvement almost unheard of within > the IETF) > > __ > 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 __ 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
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
On Wed, Sep 7, 2016, at 06:33 PM, Adrian Turjak wrote: > Heat is a bit of overkill for something as tiny as this. I agree. And though it's been a while since I've looked at Heat I didn't get the impression that it was designed for this sort of usage: a simple API call that orchestrates networking and instance setup that then allows you to interact with Nova/Neutron directly for further actions. > I was mainly responding to Andrew Laski's comment talking about a > service exactly like Minstral, for smaller cross project orchestration > of finite tasks. > On 8/09/2016 10:12 AM, "Fox, Kevin M" wrote: > > > > I've typically used heat to do this too. As it has a nice way out > > of the box to to undo the actions it does. > > > > Thanks, > > Kevin > > > > From: Adrian Turjak [adri...@catalyst.net.nz] > > Sent: Wednesday, September 07, 2016 2:34 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch > > instance with Floating IP > > > > This is exactly what something like Minstral would be fantastic > > for. Multi-project workflow. > > > > Rather than try and build logic like this directly into nova, looks > > at extending something like Minstral with a basic easy to call > > task. > - > > 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 __ 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
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
Interesting. It kind of sounds like your proposing a sort of... openstack standard library api api? (yes, double apis) Where you can build up an api using other api calls and users can rely on those standard overarching api's to be there? Thanks, Kevin From: Andrew Laski [and...@lascii.com] Sent: Wednesday, September 07, 2016 4:34 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote: > On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: > > This is exactly what something like Minstral would be fantastic for. > > Multi-project workflow. > > Rather than try and build logic like this directly into nova, looks > > at extending something like Minstral with a basic easy to call task. > > I have API- and code-reading homework to do here - but based on input > on IRC, and efforts thus far, the ideal solution is not really to bolt > a humongous piece of logic onto Nova. Rather it is appears to be first > and foremost Neutron that need a little bit more intelligence regarding > its virtual networks and the intentions of its operators. > > From what I can tell, Mistral is a very useful project for scheduling > recurring tasks or similar, which there is a definite need of in a > mature deployment. > > But I disagree with the "solve it with a new project"-approach here: > > 1) "launch my instance" is as core as it gets in OpenStack, > > 2) "launch my instance with Internet" is approximately identically as > core, just a bit difficult for $reasons and not fully supported today, > > 3) core functionality should IMO require as few API calls as possible, > to as few components as possible, while keeping REST data models etc. > intact, [1][2] I agree that it should require as few API calls as possible but maybe we disagree about what core functionality is. Or to put it another way, what is core functionality depends on your perspective. I subscribe to the plumbing and porcelain approach (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) and believe that Nova should be part of the plumbing. So while I fully agree with a small number of API calls to do simple tasks I don't believe that orchestrating network setups is core functionality in Nova but is core to OpenStack. > > 4) there are timing concerns with adding Internet to an instance today > in OpenStack, since it in some cases needs to happen somewhere between > the events "network port created" and "instance launched", in order for > the instance to actually have Internet when it boots, > > 5) Scheduling "Launch instance with Internet" or "Add Internet to > instance" via something like Mistral would additionally either, A) add > a significant delay to the boot time, or B) not even fulfill the > objective of having Internet once instance powers on, > > 6) To replicate the logic of shade's "get me online" functions, a > large amount of code is required, and depending on how you go about it, > you also risk duplicating logic already in e.g. Nova or Neutron. > > Best regards, > Martin > > [1] "A designer knows he has achieved perfection not when there is > nothing left to add, but when there is nothing left to take away." > -- Antoine de Saint-Exupery > [2] https://tools.ietf.org/rfcdiff?url2=draft-heitz-idr-large-community > -02.txt (example of commendable improvement almost unheard of within > the IETF) > > __ > 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 __ 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 __ 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
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
Double api sounds a little terrifying when really there are probably so many different ways you can already solve this using the services we already have. The thing I don't get is Martin's requirement that "an instance must have internet on boot" and that to do that he must have a floating ip assigned to it. Internet on boot I can understand because of preconfigured images and snapshots starting internal services and tasks on boot, but why is floating ip on boot such a hard requirement? Is adding a floating ip before boot even possible with Nova right now (I ask as I've never looked into it)? Unless I'm missing something, you can easily setup a private network with internet access, boot your instance on that, and then add a floating ip. The instance will have internet on boot, and then be given a floating ip. Does that not solve your problem and can that not be orchestrated with the current range of services/tools we have? On 08/09/16 12:41, Fox, Kevin M wrote: > Interesting. It kind of sounds like your proposing a sort of... openstack > standard library api api? (yes, double apis) Where you can build up an api > using other api calls and users can rely on those standard overarching api's > to be there? > > Thanks, > Kevin > > From: Andrew Laski [and...@lascii.com] > Sent: Wednesday, September 07, 2016 4:34 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance > with Floating IP > > On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote: >> On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: >>> This is exactly what something like Minstral would be fantastic for. >>> Multi-project workflow. >>> Rather than try and build logic like this directly into nova, looks >>> at extending something like Minstral with a basic easy to call task. >> I have API- and code-reading homework to do here - but based on input >> on IRC, and efforts thus far, the ideal solution is not really to bolt >> a humongous piece of logic onto Nova. Rather it is appears to be first >> and foremost Neutron that need a little bit more intelligence regarding >> its virtual networks and the intentions of its operators. >> >> From what I can tell, Mistral is a very useful project for scheduling >> recurring tasks or similar, which there is a definite need of in a >> mature deployment. >> >> But I disagree with the "solve it with a new project"-approach here: >> >> 1) "launch my instance" is as core as it gets in OpenStack, >> >> 2) "launch my instance with Internet" is approximately identically as >> core, just a bit difficult for $reasons and not fully supported today, >> >> 3) core functionality should IMO require as few API calls as possible, >> to as few components as possible, while keeping REST data models etc. >> intact, [1][2] > I agree that it should require as few API calls as possible but maybe we > disagree about what core functionality is. Or to put it another way, > what is core functionality depends on your perspective. > > I subscribe to the plumbing and porcelain approach > (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) > and believe that Nova should be part of the plumbing. So while I fully > agree with a small number of API calls to do simple tasks I don't > believe that orchestrating network setups is core functionality in Nova > but is core to OpenStack. > >> 4) there are timing concerns with adding Internet to an instance today >> in OpenStack, since it in some cases needs to happen somewhere between >> the events "network port created" and "instance launched", in order for >> the instance to actually have Internet when it boots, >> >> 5) Scheduling "Launch instance with Internet" or "Add Internet to >> instance" via something like Mistral would additionally either, A) add >> a significant delay to the boot time, or B) not even fulfill the >> objective of having Internet once instance powers on, >> >> 6) To replicate the logic of shade's "get me online" functions, a >> large amount of code is required, and depending on how you go about it, >> you also risk duplicating logic already in e.g. Nova or Neutron. >> >> Best regards, >> Martin >> >> [1] "A designer knows he has achieved perfection not when there is >> nothing left to add, but when there is nothing left to take away." >> -- Antoine de Saint-Exupery >> [2] https://tools.ietf.org/rfcdiff?url2=draft-heitz-idr-large-community &
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
Why don't you just pre-create the port and associate the floating IP before booting the instance? On Wed, Sep 7, 2016 at 5:58 PM, Adrian Turjak wrote: > Double api sounds a little terrifying when really there are probably so > many different ways you can already solve this using the services we > already have. > > The thing I don't get is Martin's requirement that "an instance must > have internet on boot" and that to do that he must have a floating ip > assigned to it. Internet on boot I can understand because of > preconfigured images and snapshots starting internal services and tasks > on boot, but why is floating ip on boot such a hard requirement? Is > adding a floating ip before boot even possible with Nova right now (I > ask as I've never looked into it)? > > Unless I'm missing something, you can easily setup a private network > with internet access, boot your instance on that, and then add a > floating ip. The instance will have internet on boot, and then be given > a floating ip. Does that not solve your problem and can that not be > orchestrated with the current range of services/tools we have? > > On 08/09/16 12:41, Fox, Kevin M wrote: > > Interesting. It kind of sounds like your proposing a sort of... > openstack standard library api api? (yes, double apis) Where you can build > up an api using other api calls and users can rely on those standard > overarching api's to be there? > > > > Thanks, > > Kevin > > > > From: Andrew Laski [and...@lascii.com] > > Sent: Wednesday, September 07, 2016 4:34 PM > > To: openstack-dev@lists.openstack.org > > Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch > instance with Floating IP > > > > On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote: > >> On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: > >>> This is exactly what something like Minstral would be fantastic for. > >>> Multi-project workflow. > >>> Rather than try and build logic like this directly into nova, looks > >>> at extending something like Minstral with a basic easy to call task. > >> I have API- and code-reading homework to do here - but based on input > >> on IRC, and efforts thus far, the ideal solution is not really to bolt > >> a humongous piece of logic onto Nova. Rather it is appears to be first > >> and foremost Neutron that need a little bit more intelligence regarding > >> its virtual networks and the intentions of its operators. > >> > >> From what I can tell, Mistral is a very useful project for scheduling > >> recurring tasks or similar, which there is a definite need of in a > >> mature deployment. > >> > >> But I disagree with the "solve it with a new project"-approach here: > >> > >> 1) "launch my instance" is as core as it gets in OpenStack, > >> > >> 2) "launch my instance with Internet" is approximately identically as > >> core, just a bit difficult for $reasons and not fully supported today, > >> > >> 3) core functionality should IMO require as few API calls as possible, > >> to as few components as possible, while keeping REST data models etc. > >> intact, [1][2] > > I agree that it should require as few API calls as possible but maybe we > > disagree about what core functionality is. Or to put it another way, > > what is core functionality depends on your perspective. > > > > I subscribe to the plumbing and porcelain approach > > (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) > > and believe that Nova should be part of the plumbing. So while I fully > > agree with a small number of API calls to do simple tasks I don't > > believe that orchestrating network setups is core functionality in Nova > > but is core to OpenStack. > > > >> 4) there are timing concerns with adding Internet to an instance today > >> in OpenStack, since it in some cases needs to happen somewhere between > >> the events "network port created" and "instance launched", in order for > >> the instance to actually have Internet when it boots, > >> > >> 5) Scheduling "Launch instance with Internet" or "Add Internet to > >> instance" via something like Mistral would additionally either, A) add > >> a significant delay to the boot time, or B) not even fulfill the > >> objective of having Internet
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
On 09/07/2016 07:34 PM, Andrew Laski wrote: > > > On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote: >> On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: >> 3) core functionality should IMO require as few API calls as possible, >> to as few components as possible, while keeping REST data models etc. >> intact, [1][2] > > I agree that it should require as few API calls as possible but maybe we > disagree about what core functionality is. Or to put it another way, > what is core functionality depends on your perspective. > > I subscribe to the plumbing and porcelain approach > (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) > and believe that Nova should be part of the plumbing. So while I fully > agree with a small number of API calls to do simple tasks I don't > believe that orchestrating network setups is core functionality in Nova > but is core to OpenStack. Personally, I think that the role of Nova is to give you a functional compute unit. If you can't talk to that over the network, that doesn't seem very functional to me. For complicated setups it's fine that you need to do complicated things, but "I would like a working server with network" doesn't feel like it's a complicated ask from the user. And more importantly, if there isn't some firm line there, the ability to do that between clouds is going to be somewhat limited, because exactly how you need to configure each cloud's neutron manually to work with their physical network setup is going to be different. You end up with the shade situation now, which isn't a great user experience. I do get the concern about Nova scope creep into orchestration. However it's not like "orchestration" has a bright line anywhere. And I think that basic working networking for requested computes isn't something we should require another service for. -Sean -- Sean Dague http://dague.net __ 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
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
On Thu, Sep 8, 2016, at 05:48 AM, Kevin Benton wrote: > Why don't you just pre-create the port and associate the floating IP > before booting the instance? Right. It's not difficult to do at all but there's a strong desire to have this be encompassed in a single API call. I think that's a great idea, but I don't think it belongs in Nova. > > On Wed, Sep 7, 2016 at 5:58 PM, Adrian Turjak > wrote: >> Double api sounds a little terrifying when really there are >> probably so >> many different ways you can already solve this using the services we >> already have. >> >> The thing I don't get is Martin's requirement that "an instance must >> have internet on boot" and that to do that he must have a >> floating ip >> assigned to it. Internet on boot I can understand because of >> preconfigured images and snapshots starting internal services >> and tasks >> on boot, but why is floating ip on boot such a hard requirement? Is >> adding a floating ip before boot even possible with Nova right >> now (I >> ask as I've never looked into it)? >> >> Unless I'm missing something, you can easily setup a private network >> with internet access, boot your instance on that, and then add a >> floating ip. The instance will have internet on boot, and then >> be given >> a floating ip. Does that not solve your problem and can that not be >> orchestrated with the current range of services/tools we have? >> >> >> On 08/09/16 12:41, Fox, Kevin M wrote: >> > Interesting. It kind of sounds like your proposing a sort of... >> > openstack standard library api api? (yes, double apis) Where you >> > can build up an api using other api calls and users can rely on >> > those standard overarching api's to be there? >> > >> > Thanks, >> > Kevin >> > >> > From: Andrew Laski [and...@lascii.com] >> > Sent: Wednesday, September 07, 2016 4:34 PM >> > To: openstack-dev@lists.openstack.org >> > Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch >> > instance with Floating IP >> > >> > On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote: >> >> On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: >> >>> This is exactly what something like Minstral would be fantastic >> >>> for. >> >>> Multi-project workflow. >> >>> Rather than try and build logic like this directly into nova, >> >>> looks >> >>> at extending something like Minstral with a basic easy to call >> >>> task. >> >> I have API- and code-reading homework to do here - but based on >> >> input >> >> on IRC, and efforts thus far, the ideal solution is not really to >> >> bolt >> >> a humongous piece of logic onto Nova. Rather it is appears to be >> >> first >> >> and foremost Neutron that need a little bit more intelligence >> >> regarding >> >> its virtual networks and the intentions of its operators. >> >> >> >> From what I can tell, Mistral is a very useful project for >> >> scheduling >> >> recurring tasks or similar, which there is a definite need of >> >> in a >> >> mature deployment. >> >> >> >> But I disagree with the "solve it with a new project"-approach >> >> here: >> >> >> >> 1) "launch my instance" is as core as it gets in OpenStack, >> >> >> >> 2) "launch my instance with Internet" is approximately >> >> identically as >> >> core, just a bit difficult for $reasons and not fully supported >> >> today, >> >> >> >> 3) core functionality should IMO require as few API calls as >> >> possible, >> >> to as few components as possible, while keeping REST data models >> >> etc. >> >> intact, [1][2] >> > I agree that it should require as few API calls as possible but >> > maybe we >> > disagree about what core functionality is. Or to put it another >> > way, >> > what is core functionality depends on your perspective. >> > >> > I subscribe to the plumbing and porcelain approach >> > (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) >> > and believe that Nova should be pa
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
On Thu, Sep 8, 2016, at 07:18 AM, Sean Dague wrote: > On 09/07/2016 07:34 PM, Andrew Laski wrote: > > > > > > On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote: > >> On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: > >> 3) core functionality should IMO require as few API calls as possible, > >> to as few components as possible, while keeping REST data models etc. > >> intact, [1][2] > > > > I agree that it should require as few API calls as possible but maybe we > > disagree about what core functionality is. Or to put it another way, > > what is core functionality depends on your perspective. > > > > I subscribe to the plumbing and porcelain approach > > (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) > > and believe that Nova should be part of the plumbing. So while I fully > > agree with a small number of API calls to do simple tasks I don't > > believe that orchestrating network setups is core functionality in Nova > > but is core to OpenStack. > > Personally, I think that the role of Nova is to give you a functional > compute unit. If you can't talk to that over the network, that doesn't > seem very functional to me. For complicated setups it's fine that you > need to do complicated things, but "I would like a working server with > network" doesn't feel like it's a complicated ask from the user. I'd really like to agree here, however it seems that it is actually a somewhat complicated ask from the user due to the diverse network setups used in practice. But I was responding to the idea of booting an instance with a floating-ip which to me goes beyond setting up a simple default network for an instance. And I think therein lies the problem, there seems to be some disagreement as to what a simple default network setup should be. > > And more importantly, if there isn't some firm line there, the ability > to do that between clouds is going to be somewhat limited, because > exactly how you need to configure each cloud's neutron manually to work > with their physical network setup is going to be different. > > You end up with the shade situation now, which isn't a great user > experience. > > I do get the concern about Nova scope creep into orchestration. However > it's not like "orchestration" has a bright line anywhere. And I think > that basic working networking for requested computes isn't something we > should require another service for. > > -Sean > > -- > Sean Dague > http://dague.net > > __ > 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 __ 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
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
On Wed, Sep 7, 2016, at 08:41 PM, Fox, Kevin M wrote: > Interesting. It kind of sounds like your proposing a sort of... openstack > standard library api api? (yes, double apis) Where you can build up an > api using other api calls and users can rely on those standard > overarching api's to be there? What I was thinking was just a service that can interact with multiple projects for simple API requests. If we take the example from elsewhere in this thread of pre-creating a port, assigning a floating-ip to it, and then booting an instance with that port that's currently multiple calls to two different services. I would love to see a service that can take all of that info in one request and then make the multiple calls necessary on behalf of the user. I additionally would expect it to be able to list resources, delete resources, whatever the user needs. My grand idea would be that users do not interact with Nova/Cinder/Neutron directly unless they have specific complex needs and instead use a new API proxy/orchestration service. For a long time it's been said that this should be handled for a user on the client side. That works great for users who wish to use a client that does that, but there are many users out there who do not use something like openstackclient, for various reasons. > > Thanks, > Kevin > > From: Andrew Laski [and...@lascii.com] > Sent: Wednesday, September 07, 2016 4:34 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch > instance with Floating IP > > On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote: > > On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: > > > This is exactly what something like Minstral would be fantastic for. > > > Multi-project workflow. > > > Rather than try and build logic like this directly into nova, looks > > > at extending something like Minstral with a basic easy to call task. > > > > I have API- and code-reading homework to do here - but based on input > > on IRC, and efforts thus far, the ideal solution is not really to bolt > > a humongous piece of logic onto Nova. Rather it is appears to be first > > and foremost Neutron that need a little bit more intelligence regarding > > its virtual networks and the intentions of its operators. > > > > From what I can tell, Mistral is a very useful project for scheduling > > recurring tasks or similar, which there is a definite need of in a > > mature deployment. > > > > But I disagree with the "solve it with a new project"-approach here: > > > > 1) "launch my instance" is as core as it gets in OpenStack, > > > > 2) "launch my instance with Internet" is approximately identically as > > core, just a bit difficult for $reasons and not fully supported today, > > > > 3) core functionality should IMO require as few API calls as possible, > > to as few components as possible, while keeping REST data models etc. > > intact, [1][2] > > I agree that it should require as few API calls as possible but maybe we > disagree about what core functionality is. Or to put it another way, > what is core functionality depends on your perspective. > > I subscribe to the plumbing and porcelain approach > (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) > and believe that Nova should be part of the plumbing. So while I fully > agree with a small number of API calls to do simple tasks I don't > believe that orchestrating network setups is core functionality in Nova > but is core to OpenStack. > > > > > 4) there are timing concerns with adding Internet to an instance today > > in OpenStack, since it in some cases needs to happen somewhere between > > the events "network port created" and "instance launched", in order for > > the instance to actually have Internet when it boots, > > > > 5) Scheduling "Launch instance with Internet" or "Add Internet to > > instance" via something like Mistral would additionally either, A) add > > a significant delay to the boot time, or B) not even fulfill the > > objective of having Internet once instance powers on, > > > > 6) To replicate the logic of shade's "get me online" functions, a > > large amount of code is required, and depending on how you go about it, > > you also risk duplicating logic already in e.g. Nova or Neutron. > > > > Best regards, > > Martin > > > > [1] "A designer knows he has achieved perfection not when there is > > nothing left to add, but when there is nothing left to
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
Hi Adrian, On Thu, 2016-09-08 at 12:58 +1200, Adrian Turjak wrote: > Double api sounds a little terrifying when really there are probably so > many different ways you can already solve this using the services we > already have. > > The thing I don't get is Martin's requirement that "an instance must > have internet on boot" Instances cannot be guaranteed to not require Internet... so it must be there from scratch, or things like for example Ubuntu's entropy download for ssh-generation in cloud-init will fail. > and that to do that he must have a floating ip > assigned to it. That's one of the networking models we have for public IP. > Internet on boot I can understand because of > preconfigured images and snapshots starting internal services and tasks > on boot, but why is floating ip on boot such a hard requirement? Is > adding a floating ip before boot even possible with Nova right now (I > ask as I've never looked into it)? >From what I understand, current calls for assigning floating IP requires not just the server, but a network port to exist. I assume "server create" finishes off with "server start". > Unless I'm missing something, you can easily setup a private network > with internet access, boot your instance on that, and then add a > floating ip. The instance will have internet on boot, and then be given > a floating ip. Does that not solve your problem and can that not be > orchestrated with the current range of services/tools we have? Our private networks are private networks, there is no Internet access from them without a floating IP, i.e. no source NAT. It's the VPC model. If our private networks were to, by default, not actually be private networks, and have source NAT to the Internet, then, yes, that'd solve that particular problem, at the expense of no longer having private networks. Best, Martin > On 08/09/16 12:41, Fox, Kevin M wrote: > > Interesting. It kind of sounds like your proposing a sort of... openstack > > standard library api api? (yes, double apis) Where you can build up an api > > using other api calls and users can rely on those standard overarching > > api's to be there? > > > > Thanks, > > Kevin > > ________________________ > > From: Andrew Laski [and...@lascii.com] > > Sent: Wednesday, September 07, 2016 4:34 PM > > To: openstack-dev@lists.openstack.org > > Subject: Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance > > with Floating IP > > > > On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote: > >> On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: > >>> This is exactly what something like Minstral would be fantastic for. > >>> Multi-project workflow. > >>> Rather than try and build logic like this directly into nova, looks > >>> at extending something like Minstral with a basic easy to call task. > >> I have API- and code-reading homework to do here - but based on input > >> on IRC, and efforts thus far, the ideal solution is not really to bolt > >> a humongous piece of logic onto Nova. Rather it is appears to be first > >> and foremost Neutron that need a little bit more intelligence regarding > >> its virtual networks and the intentions of its operators. > >> > >> From what I can tell, Mistral is a very useful project for scheduling > >> recurring tasks or similar, which there is a definite need of in a > >> mature deployment. > >> > >> But I disagree with the "solve it with a new project"-approach here: > >> > >> 1) "launch my instance" is as core as it gets in OpenStack, > >> > >> 2) "launch my instance with Internet" is approximately identically as > >> core, just a bit difficult for $reasons and not fully supported today, > >> > >> 3) core functionality should IMO require as few API calls as possible, > >> to as few components as possible, while keeping REST data models etc. > >> intact, [1][2] > > I agree that it should require as few API calls as possible but maybe we > > disagree about what core functionality is. Or to put it another way, > > what is core functionality depends on your perspective. > > > > I subscribe to the plumbing and porcelain approach > > (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) > > and believe that Nova should be part of the plumbing. So while I fully > > agree with a small number of API calls to do simple tasks I don't > > believe that orchestrating network setups is core functionality in Nova > > bu
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
On 09/08/2016 09:04 AM, Andrew Laski wrote: > > > On Thu, Sep 8, 2016, at 07:18 AM, Sean Dague wrote: >> On 09/07/2016 07:34 PM, Andrew Laski wrote: >>> >>> >>> On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote: On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: 3) core functionality should IMO require as few API calls as possible, to as few components as possible, while keeping REST data models etc. intact, [1][2] >>> >>> I agree that it should require as few API calls as possible but maybe we >>> disagree about what core functionality is. Or to put it another way, >>> what is core functionality depends on your perspective. >>> >>> I subscribe to the plumbing and porcelain approach >>> (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) >>> and believe that Nova should be part of the plumbing. So while I fully >>> agree with a small number of API calls to do simple tasks I don't >>> believe that orchestrating network setups is core functionality in Nova >>> but is core to OpenStack. >> >> Personally, I think that the role of Nova is to give you a functional >> compute unit. If you can't talk to that over the network, that doesn't >> seem very functional to me. For complicated setups it's fine that you >> need to do complicated things, but "I would like a working server with >> network" doesn't feel like it's a complicated ask from the user. > > I'd really like to agree here, however it seems that it is actually a > somewhat complicated ask from the user due to the diverse network setups > used in practice. > > But I was responding to the idea of booting an instance with a > floating-ip which to me goes beyond setting up a simple default network > for an instance. And I think therein lies the problem, there seems to be > some disagreement as to what a simple default network setup should be. I agree that floating-ip auto allocation may be over that line, as floating ips are specifically constructs that are designed to not be tied to servers for the lifecycle of the server. Their value comes in having the floating ip last longer than the server. But, there is also something here about wanting to make sure you have publicly accessable servers (which don't require floating ips specifically). There seems to be a space about sane default networking for users. Get-me-a-network worked through part of it. There might be a good follow on for some more standard models of "I really want internet accessible system". Neutron is not limited to granting this via floating ips like Nova Net was. -Sean -- Sean Dague http://dague.net __ 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
Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP
> > On Sep 8, 2016, at 3:11 PM, Sean Dague wrote: > > On 09/08/2016 09:04 AM, Andrew Laski wrote: >> >> >> On Thu, Sep 8, 2016, at 07:18 AM, Sean Dague wrote: >>> On 09/07/2016 07:34 PM, Andrew Laski wrote: On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote: > On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: > 3) core functionality should IMO require as few API calls as possible, > to as few components as possible, while keeping REST data models etc. > intact, [1][2] I agree that it should require as few API calls as possible but maybe we disagree about what core functionality is. Or to put it another way, what is core functionality depends on your perspective. I subscribe to the plumbing and porcelain approach (https://urldefense.proofpoint.com/v2/url?u=https-3A__git-2Dscm.com_book_en_v2_Git-2DInternals-2DPlumbing-2Dand-2DPorcelain&d=CwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=NWKhA-J2KIQGEiKTb4wFudlx1am5gBxyHPlNT1SsaLk&s=gPL9-f0Ias_WpPgP27BaMtNJszadrz57swhz6bBDoQY&e= ) and believe that Nova should be part of the plumbing. So while I fully agree with a small number of API calls to do simple tasks I don't believe that orchestrating network setups is core functionality in Nova but is core to OpenStack. >>> >>> Personally, I think that the role of Nova is to give you a functional >>> compute unit. If you can't talk to that over the network, that doesn't >>> seem very functional to me. For complicated setups it's fine that you >>> need to do complicated things, but "I would like a working server with >>> network" doesn't feel like it's a complicated ask from the user. >> >> I'd really like to agree here, however it seems that it is actually a >> somewhat complicated ask from the user due to the diverse network setups >> used in practice. >> >> But I was responding to the idea of booting an instance with a >> floating-ip which to me goes beyond setting up a simple default network >> for an instance. And I think therein lies the problem, there seems to be >> some disagreement as to what a simple default network setup should be. > > I agree that floating-ip auto allocation may be over that line, as > floating ips are specifically constructs that are designed to not be > tied to servers for the lifecycle of the server. Their value comes in > having the floating ip last longer than the server. > > But, there is also something here about wanting to make sure you have > publicly accessable servers (which don't require floating ips specifically). > /me chimes in late because still unearthing from a lot of work travel Just to piggyback on a lot of what’s been said here, I completely agree that getting external connectivity to an instance is tricky today due to the variety of networking models in use. That that’s both a strength (in that we have a rich enough platform to accommodate lots of different models to suit lots of different use cases) and a weakness (in that we end up having conversations like this and don’t have an interoperable way for users of multiple clouds to get external connectivity). As a matter of fact, this very issue was recently mentioned to the Board as one of the top interoperability issues that the DefCore Committee sees in the wild today: https://github.com/openstack/defcore/blob/master/doc/source/periodic_reports/fall_2016.rst#issue-3-external-network-connectivity For what it’s worth, the DefCore Committee debated adding floating IP’s to the interoperability Guidelines that products have to follow in order to use the OpenStack name/trademark last fall, and ended up rejecting the idea—mostly for the reasons listed in this thread (e.g. there are a lot of other models and a lot of clouds don’t actually use floating IP’s so they actually aren’t interoperable, etc). Also worth pointing out: the idea of having an administrative setting to auto-boot instances with a publicly accessible IP (whether that’s on a provider network or whether instances are auto-allocated a floating IP or whatever) is possibly less than ideal from an interoperability point of view, because end users tend to not have good ways of discovering administratively-set config settings. At a minimum we'd want users to able to programmatically discover which position that knob was set to. > There seems to be a space about sane default networking for users. > Get-me-a-network worked through part of it. There might be a good follow > on for some more standard models of "I really want internet accessible > system". Neutron is not limited to granting this via floating ips like > Nova Net was. +1. Get-me-a-network made it easier to get an instance booted up and attached to “a" network while alleviating part of the complexity (e.g. various underlying network models) of doing so. What DefCore is seeing from an interoperability perspe
