Hello everyone,
As a reminder, our weekly team meeting will take place at 21:00 UTC
this Tuesday in #openstack-meeting on IRC. This is our last meeting
before FeatureFreeze.
I'll probably be stuck in travel, soren has accepted to chair the
meeting this time.
Check out how that time translates fo
On Mon, Mar 21, 2011 at 5:42 PM, Brian Schott wrote:
> 1.a.) Not yet, but our branch unit tests (when we get there) will certainly
> test the architecture-related columns we added to instances, instance_types,
> and compute_node tables.
>
> 1.b) Is that a unit test responsibility or an integrati
hello ,everyone ,thanks for your reply to my previous question. Acturally i
wanna know whether the open-source IaaS management platform is suitable for
providing IaaS service for our customers. Before that ,we have to do some basic
tests about function and performance and capability. Now I reall
hello ,everyone ,i am freshman in this team and from china. Team meeting will
be hold at 21:00 UTC and in China will be at 05：00 am，it is too early for us ,
is there another meeting by daylight?
At 2011-03-22 17:12:12，"Thierry Carrez" wrote:
>Hello everyone,
>
>As a reminder, our weekly tea
I know that creiht is looking at this for Rackspace. Chuck, anything to add
to this discussion?
John
-Original Message-
From: openstack-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf
Of Adam Johnson
Sent: Monday,
2011/3/22 michael_chin1979
> hello ,everyone ,i am freshman in this team and from china. Team meeting
> will be hold at 21:00 UTC and in China will be at 05：00 am，it is too early
> for us , is there another meeting by daylight?
>
Michael,
I've been traveling to Korea and Singapore and have bee
I want to get some input from all of you on what you think is the best
way to approach this problem: the RS API requires that every instance have a
unique ID, and we are currently creating these IDs by use of an auto-increment
field in the instances table. The introduction of zones compl
Hey John,
Wasn't the plan that Rackspace would use API extensions to refine the volumes
API and then move towards getting the API into nova core long term. Perhaps the
extension could even live in the nova source code but just not be considered
part of the version spec?
Just wondering if there
the IDs must be strictly numericalish numbers, with nothing smelling
of something like a string in there, i take it?
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~opens
On 3/22/11 11:40 AM, Ed Leafe wrote:
I want to get some input from all of you on what you think is the best
way to approach this problem: the RS API requires that every instance have a
unique ID, and we are currently creating these IDs by use of an auto-increment
field in the instances
On Mar 22, 2011, at 1:11 PM, Jon Slenk wrote:
> the IDs must be strictly numericalish numbers, with nothing smelling
> of something like a string in there, i take it?
Well, since they are defined as: `id` int(11) NOT NULL AUTO_INCREMENT,
I would say the chance of a stringish thing slippi
On Tue, Mar 22, 2011 at 10:41 AM, Ed Leafe wrote:
> Well, since they are defined as: `id` int(11) NOT NULL AUTO_INCREMENT,
> I would say the chance of a stringish thing slipping in is pretty small. :)
if the schema cannot be changed (which might be worth reconsidering
since it seems to be
I think _if_ we want to stick with straight numbers, the following are the
'traditional' choices:
1) "Skipping" - so zone1 would allocate numbers 1,3,5, zone2 numbers 2,4,6.
Requires that you know in advance how many zones there are.
2) Prefixing - so zone0 would get 0xxx, zone1 1xx.
3) C
Also, I should note that there seems to be merges pending to make the
v1.1 api use urls as instance identifiers in api calls, rather than
integer id's...
I'm not sure of the impact of that with the v1.0 compat, but that is
something to think of.
--
--
-Monsyne Dragon
Confidentiality N
On Tue, Mar 22, 2011 at 12:40:21PM -0400, Ed Leafe wrote:
> The two obvious solutions are a) a single, shared database and b) using
> a UUID instead of an integer for the ID. Both of these approaches have been
> discussed and rejected, so let's not bring them back up now.
We shouldn't dism
On Mar 22, 2011, at 1:45 PM, Jon Slenk wrote:
> if the schema cannot be changed (which might be worth reconsidering
> since it seems to be a bit of a root cause of trouble) then maybe you
> have to reserve the last 4 or 5 digits of the id to be the zone id,
> and then autoincrement on top of that?
On Tue, Mar 22, 2011 at 10:48:09AM -0700, Justin Santa Barbara wrote:
>We can square the circle however - if we want numbers, let's use UUIDs -
>they're 128 bit numbers, and won't in practice collide. I'd still prefer
>strings though...
If we use a number/uuid without a zone prefix, t
Totally agree with Eric.
Two questions that I think can help us move forward:
1. Is the decision to stick with integers still valid? Can someone that
was there give us the reason for the decision? Is it documented anywhere?
2. If "we must have integers" means that we get 128 bit 'rand
I think Dragon got it right. We need a zone identifier prefix on the IDs. I
think we need to get away from numbers. I don't see any reason why they need
to be numbers. But, even if they did, you can pick very large numbers and
reserve some bits for zone ID.
- Chris
On Mar 22, 2011, at 10
Without fixing the integer ID problem, I'd vote for reserving some bits for
zone ID. I don't like the idea assigning ranges to zones. But I think the
right answer is to fix the integer ID problem.
On Mar 22, 2011, at 11:28 AM, Ed Leafe wrote:
> On Mar 22, 2011, at 1:45 PM, Jon Slenk wrote:
>
I know you don't want to resurrect a past discussion. But, UUIDs are
designed to solve these kind of problems, frankly. The decision to go
with integer IDs is a poor one, and will be negatively affecting the
scalability and architecture of our systems well into the future.
I'd love to see a discus
Hi Adam,
We have just begun an R&D effort for building a scalable block storage
service with commodity hardware. We are still working more on the back end
specifics for this, so we haven't spent much time looking at the end user
apis yet. We are open to hearing feedback on that front though, and
I agree with the sentiment that integers aren't the way to go long term.
The current spec of the api does introduce some interesting problems to
this discussion. All can be solved. The spec calls for the api to return
an id and a password upon instance creation. This means the api isn't
asynchronou
There are many existing volume solutions. Some are in production use (AoE,
iSCSI). There are enterprise-class SAN providers (Solaris, HP/LeftHand
SANs). There are existing projects to build 'cloud' storage solutions that
are shaping up very well (SheepDog, RBD).
It's great that you're thinking
On Mar 22, 2011, at 2:53 PM, Jay Pipes wrote:
> I know you don't want to resurrect a past discussion. But, UUIDs are
> designed to solve these kind of problems, frankly. The decision to go
> with integer IDs is a poor one, and will be negatively affecting the
> scalability and architecture of our
The API spec doesn't seem to preclude us from doing a fully-synchronous
method if we want to (it just reserves the option to do an async
implementation). Obviously we should make scheduling fast, but I think
we're fine doing synchronous scheduling. It's still probably going to be
much faster than
The main issue that drove integers is backwards compatibility to the ec2_api
and existing ec2 toolsets. People seemed very opposed to the idea of having
two separate ids in the database, one for ec2 and one for the underlying
system. If we want to move to another id scheme that doesn't fit in
With this, are we saying EC2API wouldn't be able to use the child zones in the
same way as the OSAPI?
From: Vishvananda Ishaya mailto:vishvana...@gmail.com>>
Date: Tue, 22 Mar 2011 12:44:21 -0700
To: Justin Santa Barbara mailto:jus...@fathomdb.com>>
Cc: Paul Voccio mailto:paul.voc...@rackspace.co
EC2 uses xsd:string for their instance id. I can't find any additional
guarantees.
Here's a (second hand) quote from Amazon:
http://serverfault.com/questions/58401/is-the-amazon-ec2-instance-id-unique-forever
"Instance ids are unique. You'll never receive a duplicate id. However, the
current for
On Mar 22, 2011, at 3:20 PM, Paul Voccio wrote:
> This means the api isn't
> asynchronous if it has to wait for the zone to create the id. From page 46
> of the API Spec states the following:
>
> "Note that when creating a server only the server ID and the admin
> password are guaranteed to be re
> However, if we don't have documentation of the decision, then I vote that it
> never happened, and instance ids are strings. We've always been at war with
> Eastasia, and all ids have always been strings.
This approach might help us in fixing some of the nastier bits of the openstack
api image
On Tue, Mar 22, 2011 at 3:29 PM, Ed Leafe wrote:
> On Mar 22, 2011, at 2:53 PM, Jay Pipes wrote:
>
>> I know you don't want to resurrect a past discussion. But, UUIDs are
>> designed to solve these kind of problems, frankly. The decision to go
>> with integer IDs is a poor one, and will be negativ
Yes, that is what they say, Unfortunately all of the ec2 tools expect the
current format that they are using to various degrees.
Some just need the proper prefix (euca2ools)
Others need the prefix + hex (elasticfox, irrc)
Others allow a string but limit it to 11 chars, etc.
So to keep compatibi
Let's take a leadership position here and go with strings; we're not
breaking Amazon's API. AWS will have to make the same changes when they
reach our scale and ambition :-)
We should also start engaging with client tools, because we're never going
to be 100% EC2 compatible. At the least, our en
+1
Sounds like some IPV6 discussions back when the standards were being debated.
We could debate bit-allocation forever. Why can't we use UUIDs?
http://tools.ietf.org/html/rfc4122
"""
2. Motivation
One of the main reasons for using UUIDs is that no centralized
authority is required to
Seems resonable
+1 to design summit discussion
Vish
On Mar 22, 2011, at 1:06 PM, Justin Santa Barbara wrote:
> Let's take a leadership position here and go with strings; we're not breaking
> Amazon's API. AWS will have to make the same changes when they reach our
> scale and ambition :-)
>
We did discuss this time at great length when we set up the meeting in the
first place. At the time, there were a few people from Japan who said that
they would rather have the meeting early so that it was before their morning
commute rather than during, which is why it’s _quite_ so antisocial
I'd like to point out that while I agree with moving to strings (and
using UUIDs as internal identifiers), this is a discussion for the
summit, and under no circumstances should anyone get the impression
that a change to the identifier will be occurring for Cactus!
-jay
On Tue, Mar 22, 2011 at 4:
It's always possible to switch weeks. One week something convenient
for Europe/East coast US, the next week, something convenient for
Asia/West coast US.
That way, nobody feels left out.
-jay
On Tue, Mar 22, 2011 at 4:14 PM, Ewan Mellor wrote:
> We did discuss this time at great length when we
On Tue, Mar 22, 2011 at 3:21 PM, Justin Santa Barbara
wrote:
> So: When can we expect volume support in nova? If I repackaged my volumes
> API as an extension, can we get it merged into Cactus?
I would personally support this.
Wasn't one of the ideas of the extensions API to provide a bit of a
I am happy to do a first pass over the volume API. I can do it as an
extension or not, whatever is more likely to be merged.
My personal feeling is that we shouldn't use extensions for something this
core, but we can do a 'full lifecycle' if we want: I'll write it as an
extension, we work on it a
See responses inline:
On Tue, Mar 22, 2011 at 2:21 PM, Justin Santa Barbara
wrote:
> There are many existing volume solutions. Some are in production use (AoE,
> iSCSI). There are enterprise-class SAN providers (Solaris, HP/LeftHand
> SANs). There are existing projects to build 'cloud' storage
Describing full Volume API as an extension may work in the short term. Long
term though we're moving towards having a suite of APIs. From this perspective
adding an extension to OpenStack Compute API seems a little strange to me. But
it could work short term, my concern is that we should real
I remember reading this a while ago. Not saying we have to do this. This is
probably why zones are independent and ids are not unique across zones in EC2.
This could be handled in the ec2 api service for compatibility. We could just
XOR the top half and the bottom half of a UUID and get a
On Mar 22, 2011, at 3:33 PM, Justin Santa Barbara wrote:
> The thing I don't like about the extension promotion process is that it
> breaks clients when the volume API is promoted
Promotion only occurs between version changes in the API, that is when we're
moving from say 1.1 to 2.0. Version
See my previous response to Justin's email as to why UUIDs alone are
not sifficient.
-Eric
On Tue, Mar 22, 2011 at 04:06:14PM -0400, Brian Schott wrote:
> +1
> Sounds like some IPV6 discussions back when the standards were being debated.
> We could debate bit-allocation forever. Why can't we u
Hey Chuck,
Thanks for the response. We are very interested in this project as
well, and may want to contribute. We're currently evaluating options
such as Sheepdog and others to see if they fit the bill. In order to
fully evaluate these options, it would be great to have *some* API
support in t
Good discussion. I need to understand a bit more about how cross org
boundary bursting is envisioned to work before assessing the implications
on server id format.
Say a user hits the http://servers.myos.com api on zone A, which then
calls out to http://servers.osprovider.com api in zone B, which
Hey Adam,
As far as I understand it, there is already basic volume support within
nova, and that there are currently some suggested changes for the current
API. We are planning to fit within that API as much as possible, and work
with the community to make any changes that may need to be made (an
> Pure numeric ids will not work in a federated model at scale.
>
Agreed
> Maybe I'm missing something, but I don't see how you could inject a
> collision ID downstream - you can just shoot yourself in your own foot.
I think that you can get away with it only in simple hierarchical
structures.
Ed,
I spoke with Jorge earlier today and this is still treated as the instance
id. That instance can fail or succeed, but the id of what you call to
retrieve that status never changes.
pvo
On 3/22/11 2:55 PM, "Ed Leafe" wrote:
>On Mar 22, 2011, at 3:20 PM, Paul Voccio wrote:
>
>> This means t
Sounds great,
We are basing our developments off of Justin's API work, just wanted
to get a consensus from the community on his approach, and see how we
can get it in as an optional component so that people can start
getting their hands dirty.
We're also interested in the snapshots support as wel
Hi Erik,
You bring up some really great points and possible solutions. Comments
inline:
On Wed, Mar 23, 2011 at 01:02:55AM +, Erik Carlin wrote:
> I assume the lowest zone (zone D) is responsible for assigning the id?
Yes, the zone that actually contains the running VM should be the
fully qu
After reading Thierry's blog post on what he expects from the Nova PTL, I
started to consider what I think the PTL's job should be. As I see it, a
Project Technical Lead has three main responsibilities:
* Internal Project Communication
- minimize duplication of work
- facilitate collaborati
54 matches
Mail list logo
