Re: [openstack-dev] [NFV][Telco] pxe-boot

[Monty Taylor]

On 11/25/2014 05:33 PM, Angelo Matarazzo wrote:
> 
> Hi all,
> my team and I are working on pxe boot feature very similar to the
> "Discless VM" one  in Active blueprint list[1]
> The blueprint [2] is no longer active and we created a new spec [3][4].
> 
> Nova core reviewers commented our spec and the first and the most
> important objection is that there is not a compelling reason to provide
> this kind of feature : booting from network.

Why not just work with the Ironic project, who already have OpenStack
code to deal with PXE booting, and already does it in a way that's
driven by nova.

> Aside from the specific implementation, I think that some members of
> TelcoWorkingGroup could be interested in  and provide a use case.
> I would also like to add this item to the agenda of next meeting
> 
> Any thought?
> 
> Best regards,
> Angelo
> 
> [1] https://wiki.openstack.org/wiki/TelcoWorkingGroup#Active_Blueprints
> [2] https://blueprints.launchpad.net/nova/+spec/libvirt-empty-vm-boot-pxe
> [3] https://blueprints.launchpad.net/nova/+spec/boot-order-for-instance
> [4] https://review.openstack.org/#/c/133254/
> 
> ___
> 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

Re: [openstack-dev] [NFV][Telco] pxe-boot

[Steve Gordon]

- Original Message -
> From: "Angelo Matarazzo" 
> To: "OpenStack Development Mailing" , 
> openstack-operat...@lists.openstack.org
> 
> 
> Hi all,
> my team and I are working on pxe boot feature very similar to the
> "Discless VM" one  in Active blueprint list[1]
> The blueprint [2] is no longer active and we created a new spec [3][4].
> 
> Nova core reviewers commented our spec and the first and the most
> important objection is that there is not a compelling reason to
> provide this kind of feature : booting from network.
> 
> Aside from the specific implementation, I think that some members of
> TelcoWorkingGroup could be interested in  and provide a use case.
> I would also like to add this item to the agenda of next meeting
> 
> Any thought?

We did discuss this today, and granted it is listed as a blueprint someone in 
the group had expressed interest in at a point in time - though I don't believe 
any further work was done. The general feeling was that there isn't anything 
really NFV or Telco specific about this over and above the more generic use 
case of legacy applications. Are you able to further elaborate on the reason 
it's NFV or Telco specific other than because of who is requesting it in this 
instance?

Thanks!

-Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [NFV][Telco] pxe-boot

[Pasquale Porreca]

The use case we were thinking about is a Network Function (e.g. IMS 
Nodes) implementation in which the high availability is based on 
OpenSAF. In this scenario there is an Active/Standby cluster of 2 System 
Controllers (SC) plus several Payloads (PL) that boot from network, 
controlled by the SC. The logic of which service to deploy on each 
payload is inside the SC.


In OpenStack both SCs and PLs will be instances running in the cloud, 
anyway the PLs should still boot from network under the control of the 
SC. In fact to use Glance to store the image for the PLs and keep the 
control of the PLs in the SC, the SC should trigger the boot of the PLs 
with requests to Nova/Glance, but an application running inside an 
instance should not directly interact with a cloud infrastructure 
service like Glance or Nova.


We know that it is yet possible to achieve network booting in OpenStack 
using an image stored in Glance that acts like a pxe client, anyway this 
workaround has some drawbacks, mainly due to the fact it won't be 
possible to choose the specific virtual NIC on which the network boot 
will happen, causing DHCP requests to flow on networks where they don't 
belong to and possible delays in the boot of the instances.


On 11/27/14 00:32, Steve Gordon wrote:

- Original Message -

From: "Angelo Matarazzo" 
To: "OpenStack Development Mailing" , 
openstack-operat...@lists.openstack.org


Hi all,
my team and I are working on pxe boot feature very similar to the
"Discless VM" one  in Active blueprint list[1]
The blueprint [2] is no longer active and we created a new spec [3][4].

Nova core reviewers commented our spec and the first and the most
important objection is that there is not a compelling reason to
provide this kind of feature : booting from network.

Aside from the specific implementation, I think that some members of
TelcoWorkingGroup could be interested in  and provide a use case.
I would also like to add this item to the agenda of next meeting

Any thought?

We did discuss this today, and granted it is listed as a blueprint someone in 
the group had expressed interest in at a point in time - though I don't believe 
any further work was done. The general feeling was that there isn't anything 
really NFV or Telco specific about this over and above the more generic use 
case of legacy applications. Are you able to further elaborate on the reason 
it's NFV or Telco specific other than because of who is requesting it in this 
instance?

Thanks!

-Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [NFV][Telco] pxe-boot

[Joe Gordon]

On Wed, Dec 3, 2014 at 1:16 AM, Pasquale Porreca <
pasquale.porr...@dektech.com.au> wrote:

> The use case we were thinking about is a Network Function (e.g. IMS Nodes)
> implementation in which the high availability is based on OpenSAF. In this
> scenario there is an Active/Standby cluster of 2 System Controllers (SC)
> plus several Payloads (PL) that boot from network, controlled by the SC.
> The logic of which service to deploy on each payload is inside the SC.
>
> In OpenStack both SCs and PLs will be instances running in the cloud,
> anyway the PLs should still boot from network under the control of the SC.
> In fact to use Glance to store the image for the PLs and keep the control
> of the PLs in the SC, the SC should trigger the boot of the PLs with
> requests to Nova/Glance, but an application running inside an instance
> should not directly interact with a cloud infrastructure service like
> Glance or Nova.
>

Why not? This is a fairly common practice.


>
> We know that it is yet possible to achieve network booting in OpenStack
> using an image stored in Glance that acts like a pxe client, anyway this
> workaround has some drawbacks, mainly due to the fact it won't be possible
> to choose the specific virtual NIC on which the network boot will happen,
> causing DHCP requests to flow on networks where they don't belong to and
> possible delays in the boot of the instances.
>
>
> On 11/27/14 00:32, Steve Gordon wrote:
>
>> - Original Message -
>>
>>> From: "Angelo Matarazzo" 
>>> To: "OpenStack Development Mailing" ,
>>> openstack-operat...@lists.openstack.org
>>>
>>>
>>> Hi all,
>>> my team and I are working on pxe boot feature very similar to the
>>> "Discless VM" one  in Active blueprint list[1]
>>> The blueprint [2] is no longer active and we created a new spec [3][4].
>>>
>>> Nova core reviewers commented our spec and the first and the most
>>> important objection is that there is not a compelling reason to
>>> provide this kind of feature : booting from network.
>>>
>>> Aside from the specific implementation, I think that some members of
>>> TelcoWorkingGroup could be interested in  and provide a use case.
>>> I would also like to add this item to the agenda of next meeting
>>>
>>> Any thought?
>>>
>> We did discuss this today, and granted it is listed as a blueprint
>> someone in the group had expressed interest in at a point in time - though
>> I don't believe any further work was done. The general feeling was that
>> there isn't anything really NFV or Telco specific about this over and above
>> the more generic use case of legacy applications. Are you able to further
>> elaborate on the reason it's NFV or Telco specific other than because of
>> who is requesting it in this instance?
>>
>> Thanks!
>>
>> -Steve
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> --
> Pasquale Porreca
>
> DEK Technologies
> Via dei Castelli Romani, 22
> 00040 Pomezia (Roma)
>
> Mobile +39 3394823805
> Skype paskporr
>
>
>
> ___
> 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

Re: [openstack-dev] [NFV][Telco] pxe-boot

[Pasquale Porreca]

Well, one of the main reason to choose an open source product is to 
avoid vendor lock-in. I think it is not
advisableto embed in the software running in an instance a call to 
OpenStack specific services.


On 12/10/14 00:20, Joe Gordon wrote:


On Wed, Dec 3, 2014 at 1:16 AM, Pasquale Porreca 
> wrote:


The use case we were thinking about is a Network Function (e.g.
IMS Nodes) implementation in which the high availability is based
on OpenSAF. In this scenario there is an Active/Standby cluster of
2 System Controllers (SC) plus several Payloads (PL) that boot
from network, controlled by the SC. The logic of which service to
deploy on each payload is inside the SC.

In OpenStack both SCs and PLs will be instances running in the
cloud, anyway the PLs should still boot from network under the
control of the SC. In fact to use Glance to store the image for
the PLs and keep the control of the PLs in the SC, the SC should
trigger the boot of the PLs with requests to Nova/Glance, but an
application running inside an instance should not directly
interact with a cloud infrastructure service like Glance or Nova.


Why not? This is a fairly common practice.


--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [NFV][Telco] pxe-boot

[Joe Gordon]

On Wed, Dec 10, 2014 at 7:42 AM, Pasquale Porreca <
pasquale.porr...@dektech.com.au> wrote:

>  Well, one of the main reason to choose an open source product is to avoid
> vendor lock-in. I think it is not
> advisable to embed in the software running in an instance a call to
> OpenStack specific services.
>

I'm sorry I don't follow the logic here, can you elaborate.


>
> On 12/10/14 00:20, Joe Gordon wrote:
>
>
> On Wed, Dec 3, 2014 at 1:16 AM, Pasquale Porreca <
> pasquale.porr...@dektech.com.au> wrote:
>
>> The use case we were thinking about is a Network Function (e.g. IMS
>> Nodes) implementation in which the high availability is based on OpenSAF.
>> In this scenario there is an Active/Standby cluster of 2 System Controllers
>> (SC) plus several Payloads (PL) that boot from network, controlled by the
>> SC. The logic of which service to deploy on each payload is inside the SC.
>>
>> In OpenStack both SCs and PLs will be instances running in the cloud,
>> anyway the PLs should still boot from network under the control of the SC.
>> In fact to use Glance to store the image for the PLs and keep the control
>> of the PLs in the SC, the SC should trigger the boot of the PLs with
>> requests to Nova/Glance, but an application running inside an instance
>> should not directly interact with a cloud infrastructure service like
>> Glance or Nova.
>>
>
>  Why not? This is a fairly common practice.
>
>
> --
> Pasquale Porreca
>
> DEK Technologies
> Via dei Castelli Romani, 22
> 00040 Pomezia (Roma)
>
> Mobile +39 3394823805
> Skype paskporr
>
>
> ___
> 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

Re: [openstack-dev] [NFV][Telco] pxe-boot

[Steve Gordon]

- Original Message -
> From: "Pasquale Porreca" 
> To: openstack-dev@lists.openstack.org
> 
> Well, one of the main reason to choose an open source product is to
> avoid vendor lock-in. I think it is not
> 
> advisable to embed in the software running in an instance a call to
> OpenStack specific services.

Possibly a stupid question, but even if PXE boot was supported would the SC not 
still have to trigger the creation of the PL instance(s) via a call to Nova 
anyway (albeit with boot media coming from PXE instead of Glance)?

-Steve

> On 12/10/14 00:20, Joe Gordon wrote:
> On Wed, Dec 3, 2014 at 1:16 AM, Pasquale Porreca <
> pasquale.porr...@dektech.com.au > wrote:
> 
> 
> The use case we were thinking about is a Network Function (e.g. IMS
> Nodes) implementation in which the high availability is based on
> OpenSAF. In this scenario there is an Active/Standby cluster of 2
> System Controllers (SC) plus several Payloads (PL) that boot from
> network, controlled by the SC. The logic of which service to deploy
> on each payload is inside the SC.
> 
> In OpenStack both SCs and PLs will be instances running in the cloud,
> anyway the PLs should still boot from network under the control of
> the SC. In fact to use Glance to store the image for the PLs and
> keep the control of the PLs in the SC, the SC should trigger the
> boot of the PLs with requests to Nova/Glance, but an application
> running inside an instance should not directly interact with a cloud
> infrastructure service like Glance or Nova.
> 
> Why not? This is a fairly common practice.
> --
> Pasquale Porreca
> 
> DEK Technologies
> Via dei Castelli Romani, 22
> 00040 Pomezia (Roma)
> 
> Mobile +39 3394823805
> Skype paskporr
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [NFV][Telco] pxe-boot

[Pasquale Porreca]

>From my point of view it is not advisable to base some functionalities
of the instances on direct calls to Openstack API. This for 2 main
reasons, the first one: if the Openstack code changes (and we know
Openstack code does change) it will be required to change the code of
the software running in the instance too; the second one: if in the
future one wants to pass to another cloud infrastructure it will be more
difficult to achieve it.

On 12/12/14 01:20, Joe Gordon wrote:
> On Wed, Dec 10, 2014 at 7:42 AM, Pasquale Porreca <
> pasquale.porr...@dektech.com.au> wrote:
> 
>> >  Well, one of the main reason to choose an open source product is to avoid
>> > vendor lock-in. I think it is not
>> > advisable to embed in the software running in an instance a call to
>> > OpenStack specific services.
>> >
> I'm sorry I don't follow the logic here, can you elaborate.
> 
> 

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [NFV][Telco] pxe-boot

[Pasquale Porreca]

It is possible to decide in advance how many PL will be necessary for a
service, so their creation can be decided externally from the SC. Anyway
the role that any PL should assume and so the image to install on each
PL should be decided by the SC.

On 12/12/14 09:54, Steve Gordon wrote:
> - Original Message -
>> > From: "Pasquale Porreca" 
>> > To: openstack-dev@lists.openstack.org
>> > 
>> > Well, one of the main reason to choose an open source product is to
>> > avoid vendor lock-in. I think it is not
>> > 
>> > advisable to embed in the software running in an instance a call to
>> > OpenStack specific services.
> Possibly a stupid question, but even if PXE boot was supported would the SC 
> not still have to trigger the creation of the PL instance(s) via a call to 
> Nova anyway (albeit with boot media coming from PXE instead of Glance)?

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [NFV][Telco] pxe-boot

[Joe Gordon]

On Fri, Dec 12, 2014 at 1:48 AM, Pasquale Porreca <
pasquale.porr...@dektech.com.au> wrote:

> From my point of view it is not advisable to base some functionalities
> of the instances on direct calls to Openstack API. This for 2 main
> reasons, the first one: if the Openstack code changes (and we know
> Openstack code does change) it will be required to change the code of
> the software running in the instance too; the second one: if in the
> future one wants to pass to another cloud infrastructure it will be more
> difficult to achieve it.
>


Thoughts on your two reasons:

1) What happens if OpenStack code changes?

While OpenStack is under very active development we have stable APIs,
especially around something like booting an instance. So the API call to
boot an instance with a specific image *should not* change as you upgrade
OpenStack (unless we deprecate an API, but this will be a slow multi year
process).

2) "if in the future one wants to pass to another cloud infrastructure it
will be more difficult to achieve it."

Why not use something like apache jcloud to make this easier?
https://jclouds.apache.org/





>
> On 12/12/14 01:20, Joe Gordon wrote:
> > On Wed, Dec 10, 2014 at 7:42 AM, Pasquale Porreca <
> > pasquale.porr...@dektech.com.au> wrote:
> >
> >> >  Well, one of the main reason to choose an open source product is to
> avoid
> >> > vendor lock-in. I think it is not
> >> > advisable to embed in the software running in an instance a call to
> >> > OpenStack specific services.
> >> >
> > I'm sorry I don't follow the logic here, can you elaborate.
> >
> >
>
> --
> Pasquale Porreca
>
> DEK Technologies
> Via dei Castelli Romani, 22
> 00040 Pomezia (Roma)
>
> Mobile +39 3394823805
> Skype paskporr
>
> ___
> 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