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 n
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
> >> Subject: Re: [openstack-dev] [Nova] bp proposal: discovery of peer
> >> instances
> >> through metadata service
> >>
> >> Excerpts from Justin Santa Barbara's message of 2014-01-24 12:29:49 -0800:
> >>> Clint Byrum wrote:
> >>>
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 beli
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
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 messag
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 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 fi
On Jan 29, 2014, at 5:26 AM, Justin Santa Barbara 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 restrictions make it
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 writ
> -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
> throug
> -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
> throug
On Jan 28, 2014, at 12:17 PM, Justin Santa Barbara 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
> agreed.
>
> So I pro
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 27 January 2014 14:52, Justin Santa Barbara 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 pu
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 b
From: Justin Santa 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:
Multic
>>
>> 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 m
> -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 Barbara&#x
>
> 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
Excerpts from Justin Santa Barbara's message of 2014-01-24 12:29:49 -0800:
> Clint Byrum 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 pr
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/?
>
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, so it wou
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
Clint Byrum 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 create a separ
>
> 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
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 is not generally used over
ting to replicate parts of the API itself.
>
>
>
> Just seeing instances launched before me doesn't really help if they've been
> deleted (but are still in the cached values) does it ?
>
>
>
> Since there is some external agent creating these instances, why can&#x
>
> 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,
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.
On Fri, Jan 24, 2014 at 12:55 PM, Day, Phil 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 that does the
to implement policy restrictions in the metadata
> service and starting to replicate parts of the API itself.
>
>
>
> Just seeing instances launched before me doesn't really help if they've been
> deleted (but are still in the cached values) does it ?
>
>
>
&
details, etc) – if not
> we’d end up starting to implement policy restrictions in the metadata
> service and starting to replicate parts of the API itself.
>
>
>
> Just seeing instances launched before me doesn’t really help if they’ve
been
> deleted (but are still in the
k-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 to find (jus
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 usin
34 matches
Mail list logo
