like 'zone' or 'cell' is
simpler and cleaner.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Availability Zone concept, and in hindsight, it was a poor
choice. So we should learn from that mistake and make sure we don't choose a
replacement term that already has a common usage, such as shards segments or
clusters.
-- Ed Leafe
___
Mailing list
On Feb 16, 2012, at 10:02 AM, Anne Gentle wrote:
I'm pleased to point you to http://api.openstack.org.
Collecting OpenStack APIs on one page, built with an API developer in mind.
Sweet! This is a great addition for all OpenStack devs!
-- Ed Leafe
' or
'Galaxy' would be closest analogies. IMO, though, 'Galaxy' is too grandiose a
term, despite the NASA heritage. So +1 to 'Cell'.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe
whether zone support is available or not.
It was my understanding that zones would be transparent to the user; in
fact, we went to great pains to ensure that zone information was *not*
available to the user. Clients would not need to detect if zones exist.
-- Ed Leafe
is that this inevitably descends into bikeshedding, which has been prominently
on display in this thread.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
On Oct 27, 2011, at 8:56 AM, George Reese wrote:
There's a nasty habit within the OpenStack community of trying to boil the
ocean. And here we are navel gazing over feeds and crap when the API can't
yet support the most basic of functionality.
+1
-- Ed Leafe
if there is something funky about
them, and even then you should first reconsider your use cases and design if
you can't remove the funkiness.
-- Ed Leafe
This email may include confidential information. If you received it in error,
please delete
On Oct 11, 2011, at 1:53 PM, Lorin Hochstein wrote:
Ceci n'est pas un pipe. ;)
Exactly!
-- Ed Leafe
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net
of novaclient from the public API part. What you've described
is one of the use cases I pointed out where we would have a need for inter-zone
functionality that should never be exposed to a public API.
-- Ed Leafe
This email may include confidential information. If you received it in error
across zones task that Chris
brought up: that's something that would be useful for OpenStack, but not
applicable to a public API.
-- Ed Leafe
This email may include confidential information. If you received it in error,
please delete
approach to zones, where a parent knew
of its children, but the children were ignorant of their parents. It's sort of
a fractal design: you can drill down the nested zones, and at each level, they
function independently and identically.
-- Ed Leafe
This email may include confidential information
that Chris Behrens started on DB replication: if you want to offer a new
instance_type, you have to somehow propagate that info to all the zones in your
deployment.
-- Ed Leafe
This email may include confidential information. If you received it in error,
please delete
are shared across zones?
-- Ed Leafe
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https
a highly specialized, internally-sourced client, while
'novaclient' would be an independent project managed outside of OpenStack, and
would serve as to keep the API honest. While this would cause some duplication,
the trade-off in cleanliness might be worth it.
-- Ed Leafe
This email may include
, then there would not need to be a separate
service; the scheduler can simply follow up itself.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help
if the request was successful or not,
and takes action if needed. The blueprint for this can be found at
https://blueprints.launchpad.net/nova/+spec/instance-creation-assurance, with
an Etherpad created for ongoing idea exchange at
http://etherpad.openstack.org/instance-creation-assurance
-- Ed Leafe
technique.
-- Ed Leafe
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net
the tools that assume 8 chars break.
2) Use the first 8 chars, and accept an occasional duplicate ID.
3) Use the first 8 chars, but add duplication checking.
-- Ed Leafe
This email may include confidential information. If you received it in error,
please delete
benefit of providing simple
zone routing via DNS, with the exact same 128-bit/32 char size.
-- Ed Leafe
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net/~openstack
? Or should we just keep with the original /96 (::0) address?
The PK for the instance would be the /96 (::0) address.
-- Ed Leafe
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https
a thing of the past with IPv6? I thought we
weren't going to be supporting that in nova.
-- Ed Leafe
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net/~openstack
need this discussion.
-- Ed Leafe
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https
than welcome to contribute.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
the overwhelming advantage of OpenStack but who also needs XML APIs and
would be willing to help develop that piece, then we should support them in
their efforts. That's much more in line with the open source development model.
-- Ed Leafe
, and that number's yours. If
there's a conflict, it will be clear who needs to change their number.
It's a manual process, sure, but this isn't a process that's repeated
all that often.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post
On May 27, 2011, at 11:55 AM, Jay Pipes wrote:
I believe Belinda's even going to start an OpenStack glossary so I know we've
hired the right person.
I suggest the first word in the glossary be metadata. Good luck! ;)
Ooohh.. that's mean!
-- Ed Leafe
Confidentiality Notice
integers.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
the same, but calls that take advantage of this new option
would expect a different result.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More
On May 24, 2011, at 11:05 AM, Sandy Walsh wrote:
Hmm, not sure I like changing the return type based on the input type. Return
types should be consistent.
Agreed, but I liked changing the meaning of PUT even less. :)
-- Ed Leafe
)?
Easy - user-generated reservation IDs would almost certainly result in
duplicates. Imagine if 3rd parties using the API each set up a system that
generated sequential integer reservation IDs...
-- Ed Leafe
___
Mailing list: https
not an
agonizingly slow or expensive operation even if it does involve several
inter-zone HTTP calls, but it isn't the cleanest and most scalable design IMO.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
to GET /servers.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
make it into a tool developed and maintained
by a non-nova developer.
If we go with relying on external versions of the client, we'll
definitely need to at least extend it or replace it for the zone communication
parts.
-- Ed Leafe
On May 11, 2011, at 1:06 PM, Jay Pipes wrote:
Subject says it all. I think Brian's demonstrated that his code
reviews are thoughtful and thorough, and he knows the OpenStack API
controller stuff as well as anyone else I believe.
Definitely! +1
-- Ed Leafe
Confidentiality Notice
into trunk in a few weeks.
There are several implementations for handling each of these parts of the
selection process that were shown at the Design Summit last week; expect more
to follow!
-- Ed Leafe
Confidentiality Notice: This e-mail message (including any attached or
embedded documents
moderate/administer please
let me know.
-1
This looks like every other run-of-the-mill forum circa 1999. The
reason StackOverflow is so popular is largely a reaction to fora like this.
-- Ed Leafe
Confidentiality Notice: This e-mail message (including any attached or
embedded
On May 4, 2011, at 11:26 AM, Everett Toews wrote:
Below is a list of people from this thread who are in favor (or at least
interested in trying) the StackExchange style.
Add me to that list.
-- Ed Leafe
Confidentiality Notice: This e-mail message (including any attached
as you like.
Well, that's a bit of a misnomer ;) The persistent capabilities of a
zone are currently set in FLAG values, no? :)
Capabilities include things such as available disk/memory, cpu type, os
type, etc., and only a few of those would lend themselves to FLAGs.
-- Ed Leafe
be able to select resources based on vm type.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
be aggregated
for more efficient request routing. This will provide the basis for a much more
robust means of specifying a host than just availability zone, which will
probably become just one of many potential attributes that one can select for.
-- Ed Leafe
Confidentiality Notice: This e-mail
On Mar 23, 2011, at 8:46 AM, Ewan Mellor wrote:
We have to accept that, on the scales we care about, any unique ID is going
to be incomprehensible to a human. Rely on your presentation layer, that's
what it's there for!
+1
-- Ed Leafe
effectively ignore the impact of non-spoofed
collisions.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net
be physically separate hardware, but nothing about zones makes that
mandatory.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help
summit, when we've come to a consensus on changing
the API to accept something other than integer identifiers, it should not be
too difficult to retrofit.
Unless someone has a better idea... ;-)
-- Ed Leafe
___
Mailing list: https
and agreed to, but I guess most people missed that
part. :)
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https
or personal, if that's what you meant.
Differing ideas and opposing POVs are wonderful, IMO. Groupthink is
what should be avoided as unhealthy.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack
make the
numeric spaces big enough to avoid overlap, but then we'll have very large ID
values; e.g., 10 or more digits for an instance. Computers won't care, but
people might, so I thought I'd at least bring up this potential objection.
-- Ed Leafe
slipping in is pretty small. :)
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
?
-- Ed Leafe
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
so that different OpenStack
deployments can adjust this to their needs.
-- Ed Leafe
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
Summit.
Can we get back to the original topic? The only reason caching came up
was as an alternative to a single DB to hold all instance information. That was
an implementation solution suggested for multi-cluster/zones, so it is
definitely in scope for Cactus.
-- Ed Leafe
something isn't clear, or if something
could be improved. I will at PyCon for the next few days, so I won't be
continuously available to respond, but I will when I have the chance.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post
to with the '*_rec' name.
But definitely +1 for distinguishing opaque refs and uuids.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack-xenapi
Post to : openstack-xenapi@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
agent (still being
developed), there is no password setting being done.
Alternatively, you could create a separate guest agent that expects a
user's public key, writes that to the VM, and disables SSH, so that your
instances are created with the security scheme that you want.
-- Ed
-based approach, you can create your own agent to work how
you want.
Does *that* clear up things? Or do you still see this as an OpenStack
problem?
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack
.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
and developed, fwiw.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
to be part of the team. Simple.
It should be at *least* N/2, since two core dev approvals are needed on
every merge prop. And it would be nice to be more than N/2, since additional
sets of eyes always catch more potential problems.
-- Ed Leafe
to determine where the instance will be created.
c. The top-level zone then passes the create-instance request to the selected
zone/host.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
of its child
nodes if they knew about that instance. That would repeat until the instance
was found, at which point every upstream server would now know about where to
reach 12345.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
specifics that I can focus on in the talk.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
know much (or anything) about
OpenStack to come away from the talk impressed by the incredible work being
done to make this project happen. I can't do this by myself.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post
other problem.
-- Ed Leafe
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
65 matches
Mail list logo
