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
>
> 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
tification 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
>
> 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
)
Subject: Re: [openstack-dev] [Nova] bp proposal: discovery of peer instances
through metadata service
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 amou
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, though I
do
Hi Justin,
I can see the value of this, but I'm a bit wary of the metadata service
extending into a general API - for example I can see this extending into a
debate about what information needs to be made available about the instances
(would you always want all instances exposed, all details, e
33 matches
Mail list logo