openstack team mailing list archive

["Ishimoto, Ryu" <ryu@xxxxxxxxxxx>]

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.

Ryu

On Tue, Mar 29, 2011 at 1:13 AM, Trey Morris <trey.morris@xxxxxxxxxxxxx>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?
>
> -trey
>
>
> On Mon, Mar 28, 2011 at 10:54 AM, Ishimoto, Ryu <ryu@xxxxxxxxxxx> 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
>> now.
>>
>> 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.
>>
>> Thanks,
>> Ryu
>>
>>
>> On Tue, Mar 29, 2011 at 12:47 AM, Trey Morris <trey.morris@xxxxxxxxxxxxx>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.
>>>
>>> -trey
>>>
>>> On Mon, Mar 28, 2011 at 8:17 AM, Jay Pipes <jaypipes@xxxxxxxxx> wrote:
>>>
>>>> On Mon, Mar 28, 2011 at 2:31 AM, Ishimoto, Ryu <ryu@xxxxxxxxxxx> wrote:
>>>> > Hi All,
>>>> > I was looking at the multi-nic
>>>> > blueprint(https://blueprints.launchpad.net/nova/+spec/nova-multi-nic),
>>>> and
>>>> > 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
>>>> mac_addresses
>>>> > 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
>>>> table).
>>>>
>>>> > I was curious to know how Nova usually handles data migration issues
>>>> like
>>>> > 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:
>>>>
>>>>
>>>> http://bazaar.launchpad.net/~glance-core/glance/cactus-trunk/view/head:/glance/registry/db/migrate_repo/versions/003_add_disk_format.py
>>>>
>>>> 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:
>>>> http://code.google.com/p/sqlalchemy-migrate/issues/detail?id=117).
>>>> 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:
>>>>
>>>>
>>>> http://bazaar.launchpad.net/~glance-core/glance/cactus-trunk/view/head:/glance/registry/db/migrate_repo/versions/003_sqlite_upgrade.sql
>>>>
>>>> http://bazaar.launchpad.net/~glance-core/glance/cactus-trunk/view/head:/glance/registry/db/migrate_repo/versions/003_sqlite_downgrade.sql
>>>>
>>>> Cheers,
>>>> jay
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>> 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@xxxxxxxxxxxxx, 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@xxxxxxxxxxxxx, and delete the original message.
> Your cooperation is appreciated.
>
>