Hi all:
When use multi-node installation with vlan mode, the vlan configuration is
in switch or in nova control node? And what's the vlan configuration process?
I read this article : http://dodeeric.louvrex.net/?p=225
begin
In the VLAN network
Does OpenStack Currently supports VirtualBox ?
I've taken a look at the code and I can see that there's currently no
drivers for VirtualBox on the virt/ directory and the current libvirt driver
doesn't support VirtualBox as well.
I've searched the web a little bit and I can see this
http://bazaar
First, y'all need to remember that it isn't just AWS... it's N systems that
back-end OS API over time.
Ewan, I understand your intent, but it is a bit myopic:
1) Done right, the only time I need native IDs is when I have a complex
situation which needs debugging. It isn't the norm (or if it i
> 1) Done right, the only time I need native IDs is when I have a complex
> situation which needs debugging. It isn't the norm (or if it is, we've
> failed) -- so really I ONLY need native IDs when it's all gone pear shaped.
Speak for yourself! I debug complex situations every day. Sure, I do
--===0750798016==
Content-Type: multipart/alternative;
boundary="_6abaf1ef-d2a2-4ada-8b4e-26e595ae6038_"
--_6abaf1ef-d2a2-4ada-8b4e-26e595ae6038_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Hi all:
=20
When use multi-node
2011/7/11 Ewan Mellor :
> No, not string vs guid. Current AWS IDs are 32 bits. Being a small key
> space, this means that you either need to allocate them incrementally
> (implying a distributed transaction across the incrementer)
This is only a real problem if you insist on generating them in r
2011/7/11 Todd Deshane :
> On Fri, Jul 8, 2011 at 4:52 PM, Soren Hansen wrote:
>> 2011/7/7 Todd Deshane :
>>> The Kronos audience will not use this RPM, but instead will want
>>> Debian packages. So at that point, we could either extend the Makefile
>>> and add Debian packaging information or alte
I'm still stewing on this but at first blush this seems like an artificial
abstraction. What do we really gain from having another layer above the service
api's? Can't they just live at the service api?
For example:
nova.compute.api:create_instance()
vs.
nova.business_layer:create_instance()
Ugh, sorry, burned again by outlook web. Let me continue ...
I'm still stewing on this but at first blush this seems like an artificial
abstraction. What do we really gain from having another layer above the service
api's? Can't they just live at the service api?
For example:
nova.compute.api:
Alex,
Only the private switch needs to support 802.1q, and you configure the name
of the tags when you run nova-manage network create, by adding a fourth
argument, usually a number that is your vlan tag. For each network you
create in one command, the number you give it is iterated by one, so if
On Mon, Jul 11, 2011 at 12:27:16PM +0200, Soren Hansen wrote:
> 2011/7/11 Ewan Mellor :
> > No, not string vs guid. Current AWS IDs are 32 bits. Being a small key
> > space, this means that you either need to allocate them incrementally
> > (implying a distributed transaction across the increment
2011/7/11 Eric Day :
> On Mon, Jul 11, 2011 at 12:27:16PM +0200, Soren Hansen wrote:
>> 2011/7/11 Ewan Mellor :
>> > No, not string vs guid. Current AWS IDs are 32 bits. Being a small key
>> > space, this means that you either need to allocate them incrementally
>> > (implying a distributed trans
> 1) Done right, the only time I need native IDs is when I have a complex
> situation which needs debugging. It isn't the norm (or if it is, we've
> failed) -- so really I ONLY need native IDs when it's all gone pear shaped.
As the human presentation interface, sure, but the *automated* contr
Perhaps. That sometimes happens when trying to make a very nuanced point :-).
I spent a lot of time hacking at nova-compute and the schemas for the
heterogeneous instance types blueprint and noticed a lot of EC2-isms buried
down in the code. Even though I've been using the EC2 interface mostl
On Jul 11, 2011, at 11:28 AM, Eric Day wrote:
>> This is only a real problem if you insist on generating them in real
>> time rather than pre-allocate them. Each compute node could have pool
>> of thousands of ID's it could use as it pleased. That would still
>> allow for millions of compute nodes
On Mon, Jul 11, 2011 at 06:31:14PM +0200, Soren Hansen wrote:
> >> This is only a real problem if you insist on generating them in real
> >> time rather than pre-allocate them. Each compute node could have pool
> >> of thousands of ID's it could use as it pleased. That would still
> >> allow for mi
Ed,
Thanks for the succinct summary.
On Jul 11, 2011, at 12:05 PM, Ed Leafe wrote:
> If we decide to move to a full UUID design with EC2 API as a
> first-class citizen, then we have the question of how to represent the
> 32-character UUID in the 8-character EC2 ID format. Our choices th
How is
nova--
any different than:
----
Where // (or some subset of them) are reserved/regulated?
-S
This email may include confidential information. If you received it in error,
please delete it.
___
Mai
At the risk of making things more complicated, we should anticipate an eventual
Cloud API standard which could be any solution from EC2/OpenStack/OCCI/... and
a set of legacy interfaces for backwards compatibility. This, as far as I see,
pushes us strongly towards the multiple APIs as a present
Ahhh.. OK. The namespace is embedded in the instance ID depending on the type,
so it should be sufficient to:
GET /servers/
Regardless, uuid is sufficient and globally unique.
This doesn't consider authentication. I'd assumed that username and realm and
the like had been handled by REST-based
On Mon, Jul 11, 2011 at 05:17:05PM +, Sandy Walsh wrote:
> How is
>
> nova--
>
> any different than:
>
> ----
>
> Where // (or some subset of them) are reserved/regulated?
Nothing, if -- is a full UUID. If we compare to
swift,
Eric,
I've heard this argument before, but I don't understand how can't be
injected as well to cause collisions. UUIDs can't be trusted when user
generated. As long as the UUIDs are generated consistently across all
OpenStack deployments (using the same UUID type and consistent policy on an
+1
I think the work really lives with formalizing the contracts at the
nova.[service].api level and pushing the discrepancies into the respective
public API's.
-S
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces
Hi Edier,
Can you check the command:
sudo kvm-ok
And see if vt is enabled in the BIOS? I had similar issue before, and there
might also be some logs in the nova-compute.log as well. Try search bios and
see if u find anything there.
Shang Wu
Edier Zapata 於 2011/7/12 上午12:08 寫道：
> Hi,
> I i
Hi Brian,
I think there may be a disconnect somewhere, perhaps we have different
deployments in mind or something. In my opinion, it seems we should
take the fully distributed, multi-tentant route to allow peering of
deployments. So whether we use UUIDs or not, the goal is to:
* Have account leve
On Jul 11, 2011, at 2:04 PM, Eric Day wrote:
>> How is
>>
>> nova--
>>
>> any different than:
>>
>> ----
>>
>> Where // (or some subset of them) are reserved/regulated?
>
> Nothing, if -- is a full UUID. If we compare to
> swift,
On Mon, Jul 11, 2011 at 7:14 AM, Soren Hansen wrote:
> 2011/7/11 Todd Deshane :
>> On Fri, Jul 8, 2011 at 4:52 PM, Soren Hansen wrote:
>>> 2011/7/7 Todd Deshane :
The Kronos audience will not use this RPM, but instead will want
Debian packages. So at that point, we could either extend t
On Jul 11, 2011, at 12:01 PM, Ed Leafe wrote:
> On Jul 11, 2011, at 2:04 PM, Eric Day wrote:
>
>>> How is
>>>
>>> nova--
>>>
>>> any different than:
>>>
>>> ----
>>>
>>> Where // (or some subset of them) are reserved/regulated?
>>
>> Nothing, if D
Won't an IPv6 address do that by it's very nature?
-S
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of
Chris Behrens [chris.behr...@rackspace.com]
Sent: M
On Jul 11, 2011, at 12:37 PM, Ed Leafe wrote:
> On Jul 11, 2011, at 3:24 PM, Chris Behrens wrote:
>
>>> It's a shame that the ipv6 proposal was never more fully considered.
>>> That would handle the uniqueness, with the added benefit of providing
>>> simple zone routing via DNS, with the e
We did discuss using IPV6 addresses as IDs months ago (IRC and email),
but I don't remember why we decided not to. It may have been due to
current adoption. I think it was pvo who originally had the idea.
-Eric
On Mon, Jul 11, 2011 at 07:24:39PM +, Chris Behrens wrote:
>
> On Jul 11, 2011, a
On Jul 11, 2011, at 3:24 PM, Chris Behrens wrote:
>> It's a shame that the ipv6 proposal was never more fully considered.
>> That would handle the uniqueness, with the added benefit of providing simple
>> zone routing via DNS, with the exact same 128-bit/32 char size.
>
> I don't I remembe
If you're referring to encoding zone information, yes it would. I was trying
to ask more generally as well. IPv6 would be a very good solution, IMO.
- Chris
On Jul 11, 2011, at 12:47 PM, Sandy Walsh wrote:
> Won't an IPv6 address do that by it's very nature?
>
> -S
>
> _
I kind of like the IPv6 idea myself. How would it work with a service
provider that, for example, assigns a /96 address for an instance? If the
user can change the IP address, would that mean that the instance ID would
change as well? Or should we just keep with the original /96 (::0) address?
On Jul 11, 2011, at 4:03 PM, Glen Campbell wrote:
> I kind of like the IPv6 idea myself. How would it work with a service
> provider that, for example, assigns a /96 address for an instance? If the
> user can change the IP address, would that mean that the instance ID would
> change as well? Or sh
I believe we discussed this in the December timeframe. I'm still a fan of
the idea.
On 7/11/11 2:37 PM, "Eric Day" wrote:
>We did discuss using IPV6 addresses as IDs months ago (IRC and email),
>but I don't remember why we decided not to. It may have been due to
>current adoption. I think it wa
What happens when you've shared the primary IPv6 address of a VM with
another VM? To which VM does the primary key point to? I think overloading
the IPv6 address to also mean the primary key is probably a mistake that
will cause serious trouble with network-as-a-service portability.
-C
On Mon,
On Jul 11, 2011, at 4:21 PM, Christopher MacGown wrote:
> What happens when you've shared the primary IPv6 address of a VM with another
> VM? To which VM does the primary key point to? I think overloading the IPv6
> address to also mean the primary key is probably a mistake that will cause
> se
> [Snip summary]
>
> The only question that needs to be considered is where do we move
> from here? Do we accept the limitation that the EC2 API and any tool
> which relies upon that will be only available for single-zone
> deployments, and if you want distributed zones, you must use the OS
>
On Jul 11, 2011, at 6:19 PM, Ewan Mellor wrote:
> Up to now, I have assumed that zones would be used as the construct that
> isolated different service offerings, e.g. VMware vs XenServer or 10G
> networking versus 1G, or whatever. Zones therefore play two roles: they give
> you the architectu
2011/7/11 Ed Leafe :
>> What happens when you've shared the primary IPv6 address of a VM with
>> another VM? To which VM does the primary key point to? I think overloading
>> the IPv6 address to also mean the primary key is probably a mistake that
>> will cause serious trouble with network-as-a-
2011/7/11 Ed Leafe :
> On Jul 11, 2011, at 2:04 PM, Eric Day wrote:
> It's a shame that the ipv6 proposal was never more fully considered. That
> would handle the uniqueness, with the added benefit of providing simple zone
> routing via DNS, with the exact same 128-bit/32 char size.
I can think
Karim:
I'm not aware of anybody currently working on this, other than that old branch
that you linked to.
I don't know know too much about VirtualBox, but since a libvirt VirtualBox
driver exists, I suspect it would be straightforward to add support, it's just
that nobody happens to be worki
Den 11/07/2011 19.08 skrev "Brian Schott" :
> On Jul 11, 2011, at 12:05 PM, Ed Leafe wrote:
> > 2) Use the first 8 chars, and accept an occasional duplicate ID.
> +1 this will be incredibly rare, just return an API error if
request is ambiguous
> > 3) Use the first 8 chars, but add duplication ch
On Jul 11, 2011, at 6:46 PM, Ed Leafe wrote:
>> If so, then I would say that your proposed limitation above is not
>> acceptable. We don't want a situation where tenants have to stop using the
>> EC2 API as soon as their service provider wants to offer a rich set of
>> offerings.
>
> Th
From: Ewan Mellor [ewan.mel...@eu.citrix.com]
> If so, then I would say that your proposed limitation above is not
> acceptable. We don't want a situation where tenants have to stop using the
> EC2 API as soon as their service provider wants to offer a rich set of
> offerings.
Hmm, two concer
I'd add a fairly fundamental rule of ID design is that ID should never, ever
have any meaning except to serve as identifiers. The minute you tie them to
IPv6 values, you are giving them meaning.
On Jul 11, 2011, at 6:49 PM, Soren Hansen wrote:
> 2011/7/11 Ed Leafe :
>> On Jul 11, 2011, at 2:04
___
From: Soren Hansen [so...@linux2go.dk]
> I can think of a number of reasons why using ipv6 addresses are a bad idea.
Sorry for the red-herring on the IPv6 thing. I only mentioned it in terms of
being able to use it for zone-routing. I wasn't proposing usi
> -Original Message-
> From: Sandy Walsh [mailto:sandy.wa...@rackspace.com]
> Sent: 11 July 2011 17:10
> To: Ewan Mellor; Ed Leafe; Eric Day
> Cc: openstack@lists.launchpad.net
> Subject: RE: [Openstack] Cross-zone instance identifiers in EC2 API -
> Is it worth the effort?
>
> From: Ewa
> -Original Message-
> From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
> [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net]
> On Behalf Of Ed Leafe
> Sent: 11 July 2011 16:39
> To: openstack@lists.launchpad.net
> Subject: Re: [Openstack] Cross-zone inst
Hi Jason,
Thanks for sending this out. I like the idea of separating the notion of
creating a network (L2 connectivity) from creating a subnet (L3 addressing)
with nova-manage. This is inline with the Quantum work some of us are
building to create L2 networking as a separate service (
http://www
Hello everyone,
This is the first time that I post on the list so please accept my
apologies if I come in "late" to the conversation.
I understand that Rackspace does not intend to add an EC2
implementation, or rather that it's not of importance to them.
However, this is something that's importa
Hi,
Seems debian/copyright isn't correct and needs some refinement.
I don't think that openwrt-x86-ext2.image and openwrt-x86-vmlinuz should
be in the original sources at all. These are sourceless files, and
cannot fit Debian at all.
Thomas
Original Message
Subject: Bug#633600
>
> 2. Could we not have plain vanilla EC2 at the top-level zone and do all the
> funky stuff under the hood, mapping EC2 artifacts to OS artifacts as needed?
> If EC2 wants 8-character with a prefix, we can map it to our UUID's across
> Zones, but with obvious limitations. If EC2 runs out of s
54 matches
Mail list logo
