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
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
Jarret Raim wrote:
>>I'm presuming that this is our last opportunity for API review - if
>>this isn't the right occasion to bring this up, ignore me!
>
> I wouldn't agree here. The barbican API will be evolving over time as we
> add new functionality. We will, of course, have to deal with backwar
Given the issues we continue to face with achieving stable APIs, I
hope there will be some form of formal API review before we approve
any new OpenStack APIs. When we release an API, it should mean that
we're committing to support that API _forever_.
Glancing at the specification, I noticed some
2014 at 10:39 PM, Vishvananda Ishaya
wrote:
>
> 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
>> th
ier to have more advanced sharing policies (e.g.
when we have hierarchical projects)
Thank you to everyone for helping me get to what IMHO is a much better
solution than the one I started with!
Justin
On Tue, Jan 28, 2014 at 4:38 AM, John Garbutt wrote:
> On 27 January 2014 14:52, Justin
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
>
> 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
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
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
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
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
ome, so decided to hold off on this feature for now.
> Curiously one option discussed was to add a '/base64' extension to the URI.
> Hence this feature could similarly be open for debate.
>
> BTW, we do have a Python client library available for interaction with
> Barbican as wel
e are?
(The API ref I'm looking at is here:
https://github.com/cloudkeep/barbican/wiki/Blueprint%3A-MIME-Type-Revamp )
Justin
---
Justin Santa Barbara
Founder, FathomDB
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> I think that there is a new driver
> for amazon compatibility that has shown up recently: Netflix's efforts
> to make their software stack Open Source[1]
> ...
> There are a couple of approaches here: one is to change the the other
> open source software to use openstack apis natively. I think
In the nova API, how is server listing with all_tenants supposed to work
with Keystone domains? If I'm an admin of Domain1, I'm probably not an
admin of Domain2. So, presumably all_tenants in a Domain1 project should
list all projects under Domain1, but not those under Domain2.
But I thought no
19 matches
Mail list logo
