[Openstack] multi-nic blueprint - data migration
ryu at midokura.jp
Tue Mar 29 09:45:42 UTC 2011
ahhh yes, I misread the blueprint, it makes a lot of sense now. Thanks.
Does this mean that when an instance launches, all the MAC
addresses/Networks that belong in the same project get assigned to that
instance? I couldn't find this in the code so I just wanted to verify.
On Tue, Mar 29, 2011 at 1:13 AM, Trey Morris <trey.morris at rackspace.com>wrote:
> Ryu, the new mac_address table is going to associate a mac_address with an
> instance and a network. When the VIFs are created for the instance, they are
> given the mac_address from the table and attached to the network from the
> table. Does that help?
> On Mon, Mar 28, 2011 at 10:54 AM, Ishimoto, Ryu <ryu at midokura.jp> wrote:
>> Thanks, that cleared it up for me.
>> Staying on the topic of multi-nics, I have been trying to understand the
>> direction in which Nova is going in regards to networking, and reading up on
>> the multi-nics blueprint, it certainly seems like it's going in the right
>> direction, but I do have one question:
>> What was the reasoning behind associating networks, and not NICs, to an
>> instance? I understand that each instance NIC would belong to a distinct
>> network, but it just seems more intuitive to imagine that an instance has
>> NICs, and these NICs are connected to networks(or even more intuitively,
>> connected to virtual ports that belong to various networks - Assigning a
>> port to a NIC is like allocating an IP address).
>> One problem I see from my suggestion above is that there is no association
>> between NICs and networks, which means there is no way to select a network
>> to grab an IP address from for each NIC at the time of VM launch. I might
>> be missing something completely here, but why not just let the user manage
>> all this through the management API before the VM launch? Let the user
>> create NICs, Networks(and Ports with IP addresses), and map the NICs to
>> ports. Then pass this list of 'connected' NICs as a parameter to launch a
>> VM. This parameter is optional, and if omitted, it should be treated as
>> launching a single NIC instance, with a new NIC created and associated with
>> the instance on the fly. This prevents it from breaking the way it works
>> If the concept of NICs for instance makes sense to everyone, I would love
>> to help out and look further into what work needs to be done to extend the
>> current multi-nic model into this one.
>> I hope this made sense. I apologize for the length.
>> On Tue, Mar 29, 2011 at 12:47 AM, Trey Morris <trey.morris at rackspace.com>wrote:
>>> I've written a migration to handle moving the data in the current
>>> instances table mac_address column into the new mac_address table before the
>>> column is removed.
>>> I agree with Jay, data should never be discarded when migrating forward.
>>> I don't think there has been a case yet where data is migrated in nova. This
>>> could be the first.
>>> On Mon, Mar 28, 2011 at 8:17 AM, Jay Pipes <jaypipes at gmail.com> wrote:
>>>> On Mon, Mar 28, 2011 at 2:31 AM, Ishimoto, Ryu <ryu at midokura.jp> wrote:
>>>> > Hi All,
>>>> > I was looking at the multi-nic
>>>> > blueprint(https://blueprints.launchpad.net/nova/+spec/nova-multi-nic),
>>>> > in particular:
>>>> > 1) removing mac_address column from the instances table and creating a
>>>> > mac_addresses table. This is for storing which instances own which mac
>>>> > addresses as well as which network each mac is for.
>>>> > What happens(or should happen) to the MAC addresses that are already
>>>> > associated with instances? Will they be migrated to the new
>>>> > table? Or will they be discarded completely?
>>>> Data should never be discarded in situations like this where a column
>>>> is moved to another table's schema (or to be records in another
>>>> > I was curious to know how Nova usually handles data migration issues
>>>> > this.
>>>> No idea whether/if Nova's data migrations have previously needed to
>>>> preserve data in this way. Glance does, however, and you can use the
>>>> following Python changescript to get an idea how to perform this exact
>>>> type of change:
>>>> Note that SQLite has issues if you try to add and drop columns in the
>>>> same changescript and you also have an unrelated column that is
>>>> indexed (see:
>>>> If this is the case, you will need to write SQL-based changescripts
>>>> specfically for SQLite. You can see examples of how this is
>>>> accomplished in Glance for the same DB version here:
>>>> 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
>>> Confidentiality Notice: This e-mail message (including any attached or
>>> embedded documents) is intended for the exclusive and confidential use of the
>>> individual or entity to which this message is addressed, and unless otherwise
>>> expressly indicated, is confidential and privileged information of Rackspace.
>>> Any dissemination, distribution or copying of the enclosed material is prohibited.
>>> If you receive this transmission in error, please notify us immediately by e-mail
>>> at abuse at rackspace.com, and delete the original message.
>>> Your cooperation is appreciated.
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
> individual or entity to which this message is addressed, and unless otherwise
> expressly indicated, is confidential and privileged information of Rackspace.
> Any dissemination, distribution or copying of the enclosed material is prohibited.
> If you receive this transmission in error, please notify us immediately by e-mail
> at abuse at rackspace.com, and delete the original message.
> Your cooperation is appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openstack