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
On Mon, Mar 21, 2011 at 5:42 PM, Brian Schott bfsch...@gmail.com 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
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
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 thie...@openstack.org wrote:
Hello everyone,
As a
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,
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
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 :
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
On Tue, Mar 22, 2011 at 10:41 AM, Ed Leafe e...@leafe.com 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
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)
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
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
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
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,
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
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
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
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
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 vishvana...@gmail.commailto:vishvana...@gmail.com
Date: Tue, 22 Mar 2011 12:44:21 -0700
To: Justin Santa Barbara jus...@fathomdb.commailto:jus...@fathomdb.com
Cc: Paul
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
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 images
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
+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
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 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
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
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 use
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
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,
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
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.
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
35 matches
Mail list logo
