On 01/23/2014 11:28 AM, Justin Santa Barbara wrote:
Would appreciate feedback / opinions on this
blueprint:
https://blueprints.launchpad.net/nova/+spec/first-discover-your-peers
The blueprint starts out with:
When running a clustered service on Nova, typically each node needs
to find
Russell Bryant wrote:
So, it seems that at the root of this, you're looking for a
cloud-compatible way for instances to message each other.
No: discovery of peers, not messaging. After discovery, communication
between nodes will then be done directly e.g. over TCP. Examples of
services that
On 02/05/2014 04:45 PM, Justin Santa Barbara wrote:
Russell Bryant wrote:
So, it seems that at the root of this, you're looking for a
cloud-compatible way for instances to message each other.
No: discovery of peers, not messaging. After discovery, communication
I'm saying use messaging as
On 01/27/2014 11:02 AM, Day, Phil wrote:
-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com]
Sent: 24 January 2014 21:09
To: openstack-dev
Subject: Re: [openstack-dev] [Nova] bp proposal: discovery of peer instances
through metadata service
Excerpts from Justin Santa
Russell Bryant wrote:
I'm saying use messaging as the means to implement discovery.
OK. Sorry that I didn't get this before.
1) Marconi isn't widely deployed
Yet.
I think we need to look to the future and decide on the right solution
to the problem.
Agreed 100%. I actually believe
Excerpts from Monty Taylor's message of 2014-02-05 14:57:33 -0800:
On 01/27/2014 11:02 AM, Day, Phil wrote:
-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com]
Sent: 24 January 2014 21:09
To: openstack-dev
Subject: Re: [openstack-dev] [Nova] bp proposal: discovery
Excerpts from Day, Phil's message of 2014-01-27 03:02:17 -0800:
-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com]
Sent: 24 January 2014 21:09
To: openstack-dev
Subject: Re: [openstack-dev] [Nova] bp proposal: discovery of peer instances
through metadata service
Excerpts from Murray, Paul (HP Cloud Services)'s message of 2014-01-27 04:14:44
-0800:
Hi Justin,
My though process is to go back to basics. To perform discovery there is no
getting away from the fact that you have to start with a well-known address
that your peers can access on the
-Original Message-
From: Justin Santa Barbara [mailto:jus...@fathomdb.com]
Sent: 28 January 2014 20:17
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] bp proposal: discovery of peer instances
through metadata service
Thanks
-Original Message-
From: Vishvananda Ishaya [mailto:vishvana...@gmail.com]
Sent: 29 January 2014 03:40
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] bp proposal: discovery of peer instances
through metadata service
On Jan 28
Certainly my original inclination (and code!) was to agree with you Vish, but:
1) It looks like we're going to have writable metadata anyway, for
communication from the instance to the API.
2) I believe the restrictions make it impractical to abuse it as a
message-bus: size-limits, quotas and
On Jan 29, 2014, at 5:26 AM, Justin Santa Barbara jus...@fathomdb.com wrote:
Certainly my original inclination (and code!) was to agree with you Vish, but:
1) It looks like we're going to have writable metadata anyway, for
communication from the instance to the API.
2) I believe the
On 27 January 2014 14:52, Justin Santa Barbara jus...@fathomdb.com wrote:
Day, Phil wrote:
We already have a mechanism now where an instance can push metadata as
a way of Windows instances sharing their passwords - so maybe this
could
build on that somehow - for example each instance
Thanks John - combining with the existing effort seems like the right
thing to do (I've reached out to Claxton to coordinate). Great to see
that the larger issues around quotas / write-once have already been
agreed.
So I propose that sharing will work in the same way, but some values
are visible
On Jan 28, 2014, at 12:17 PM, Justin Santa Barbara jus...@fathomdb.com wrote:
Thanks John - combining with the existing effort seems like the right
thing to do (I've reached out to Claxton to coordinate). Great to see
that the larger issues around quotas / write-once have already been
What worried me most, I think, is that if we make this part of the standard
metadata then everyone would get it, and that raises a couple of concerns:
- Users with lots of instances (say 1000's) but who weren't trying to run any
form of discovery would start getting a lot more metadata
Barbara [mailto:jus...@fathomdb.com]
Sent: 24 January 2014 21:01
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] bp proposal: discovery of peer instances
through metadata service
Murray, Paul (HP Cloud Services) wrote:
Multicast is not generally
Day, Phil wrote:
We already have a mechanism now where an instance can push metadata as
a way of Windows instances sharing their passwords - so maybe this could
build on that somehow - for example each instance pushes the data its
willing to share with other instances owned by the same
: discovery of peer instances
through metadata service
Would appreciate feedback / opinions on this blueprint:
https://blueprints.launchpad.net/nova/+spec/first-discover-your-peers
The idea is: clustered services typically run some sort of gossip protocol, but
need to find (just) one peer to connect
...@fathomdb.com]
Sent: 23 January 2014 16:29
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Nova] bp proposal: discovery of peer instances
through metadata service
Would appreciate feedback / opinions on this blueprint:
https://blueprints.launchpad.net/nova/+spec/first
-dev] [Nova] bp proposal: discovery of peer instances
through metadata service
Would appreciate feedback / opinions on this blueprint:
https://blueprints.launchpad.net/nova/+spec/first-discover-your-peers
The idea is: clustered services typically run some sort of gossip protocol,
but need
On Fri, Jan 24, 2014 at 12:55 PM, Day, Phil philip@hp.com wrote:
I haven't actually found where metadata caching is implemented,
although the constructor of InstanceMetadata documents restrictions that
really only make sense if it is. Anyone know where it is cached?
Here’s the code
Excerpts from Justin Santa Barbara's message of 2014-01-24 07:43:23 -0800:
Good points - thank you. For arbitrary operations, I agree that it would
be better to expose a token in the metadata service, rather than allowing
the metadata service to expose unbounded amounts of API functionality.
Good points - thank you. For arbitrary operations, I agree that it would be
better to expose a token in the metadata service, rather than allowing the
metadata service to expose unbounded amounts of API functionality. We
should therefore also have a per-instance token in the metadata,
service?
Having said that I do like this kind of stuff :)
Paul.
From: Justin Santa Barbara [mailto:jus...@fathomdb.com]
Sent: 24 January 2014 15:43
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] bp proposal: discovery of peer instances
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] bp proposal: discovery of peer instances
through metadata service
Hi Justin,
It’s nice to see someone bringing this kind of thing up. Seeding discovery is a
handy primitive to have.
Multicast
Well if you're on a Neutron private network then you'd only be DDOS-ing
yourself.
In fact I think Neutron allows broadcast and multicast on private
networks, and
as nova-net is going to be deprecated at some point I wonder if this is
reducing
to a corner case ?
Neutron may well re-enable
Clint Byrum cl...@fewbar.com wrote:
Heat has been working hard to be able to do per-instance limited access
in Keystone for a while. A trust might work just fine for what you want.
I wasn't actually aware of the progress on trusts. It would be helpful
except (1) it is more work to have to
Murray, Paul (HP Cloud Services) wrote:
Multicast is not generally used over the internet, so the comment about
removing multicast is not really justified, and any of the approaches that
work there could be used.
I think multicast/broadcast is commonly used 'behind the firewall', but I'm
Fox, Kevin M wrote:
Would it make sense to simply have the neutron metadata service
re-export every endpoint listed in keystone at
/openstack/api/endpoint-name?
Do you mean with an implicit token for read-only access, so the instance
doesn't need a token? That is a superset of my proposal,
Excerpts from Justin Santa Barbara's message of 2014-01-24 12:29:49 -0800:
Clint Byrum cl...@fewbar.com wrote:
Heat has been working hard to be able to do per-instance limited access
in Keystone for a while. A trust might work just fine for what you want.
I wasn't actually aware of
I suppose we disagree on this fundamental point then.
Heat's value-add really does come from solving this exact problem. It
provides a layer above all of the other services to facilitate expression
of higher level concepts. Nova exposes a primitive API, where as Heat is
meant to have a more
Would appreciate feedback / opinions on this blueprint:
https://blueprints.launchpad.net/nova/+spec/first-discover-your-peers
The idea is: clustered services typically run some sort of gossip protocol,
but need to find (just) one peer to connect to. In the physical
environment, this was done
33 matches
Mail list logo
