[Openstack] [Quantum] Update policy of device_id

Dan Wendlandt dan at nicira.com
Mon Aug 6 17:06:30 UTC 2012


On Fri, Aug 3, 2012 at 12:33 PM, Nati Ueno <nati.ueno at gmail.com> wrote:

> Hi folks
>
> I report this bug recently.
>
> device_id should not be updated twice
> https://bugs.launchpad.net/quantum/+bug/1031473
>
> Now,  a user can update device_id which may cause problem.
>

Yeah, ideally this field could only be updated by the 'service' user (i.e.,
nova or another openstack service).


>
> This is related to port id spec for nova boot.
> https://bugs.launchpad.net/nova/+bug/1031096
>
> My question is how we should deal with port on the failure or deletion.
>
> My patch will delete the port on failure or deletion
> https://review.openstack.org/#/c/10639/
>
> Another spec could be update port device_id for None.
> But this is depends on how we solve bug 1031473.
>

Updating to empty-string/None is more what I had been thinking of, but I
don't have my head fully wrapped around this.

As I mentioned when we chatted about this in person, Amazon's elastic
network interfaces (ENIs) are similar to quantum ports, and they have a
specific flag that indicates whether the ENI should be deleted when the
instance is deleted or not:
http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/using-eni.html#change_term_behavior

There are some use cases when we would want to keep it around, and just
reattach it to a new virtual server.

Dan



>
> Any thought?
>
> --
> Nachi Ueno
> email:nati.ueno at gmail.com
> twitter:http://twitter.com/nati
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120806/bc142771/attachment.html>


More information about the Openstack mailing list