Thiery - Most operators are busy fighting operational battles, scale out etc.
It is often an all-hands-on-the-deck job. I don’t think we should just measure
by contributors getting work done. The work is often silent, and lags behind
the dev cycle.
Subbu
On May 4, 2015, at 9:25 AM, Thierry
Hi Arvind,
This seems to be covering one of the use cases listed by
https://wiki.openstack.org/wiki/Blueprint-VPC. Others to isolate between VPCs
include shared resources like networks, images, roles, and other configuration.
Subbu
On May 8, 2014, at 7:55 PM, Tiwari, Arvind
We should perhaps clarify that these etherpads are about deployment/operations
of OpenStack discussed under
https://wiki.openstack.org/wiki/Summit/Juno/Etherpads#Ops, and not Fuel.
Subbu
On May 12, 2014, at 2:33 PM, Vladimir Kuklin vkuk...@mirantis.com wrote:
Guys
It would be awesome if
Hope this is not too late to ask this question, but isn't this extra code just
fat finger mistakes?
IME, most provisioning on cloud happens via automated tools, and it seems
counter-productive to design a feature for manual operations.
Thx,
Subbu
On Mar 13, 2014, at 12:42 PM, Boris Pavlovic
Harshad,
Thanks for clarifying.
We started looking at this as some our customers/partners were interested in
get AWS API compatibility. We have this blueprint and code review pending for
long time now. We will know based on this thread wether the community is
interested. But I assumed
Harshad,
This is great. At least there is consensus on what it is and what it is not. I
would leave it to others to discuss merits of a an AWS compat VPC API for
Icehouse.
Perhaps this is a good topic to discuss at the Juno design summit.
Subbu
On Feb 16, 2014, at 10:15 AM, Harshad Nakil
True. The domain hierarchy isn't useful to capture resource sharing across a
VPC. For instance, if a VPC admin would like to scope certain networks or
images to a projects managed within a VPC, there isn't an abstraction today.
Subbu
On Feb 14, 2014, at 11:42 AM, Martin, JC
Harshad,
Curious to know if there is a broad interest in an AWS compatible API in the
community? To clarify, a clear incremental path from an AWS compatible API to
an OpenStack model is not clear.
Subbu
On Feb 15, 2014, at 10:04 PM, Harshad Nakil hna...@contrailsystems.com wrote:
I agree
Hope this thread isn't dead.
Mike - thanks for highlighting some really key issues at scale.
On a related note, can someone from the Ceilometer comment about the store and
forward requirement? Currently scaling RabbitMQ is non-trivial. Though cells
help make the problem smaller, as Paul
At work we're currently looking at related use cases, and access keys are
useful without keystone actually managing passwords. The only issue with
https://blueprints.launchpad.net/keystone/+spec/access-key-authentication is
that it requires client side code changes, which is a non-starter in
10 matches
Mail list logo
