<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Yes, [1] can be done without [2] and [3]. </div><div>As you are well aware [2] is now merged with group policy discussions. </div>
<div>IMHO all or nothing approach will not get us anywhere. </div><div>By the time we line up all our ducks in row. New features/ideas/blueprints will keep Emerging. <br><br>Regards<div>-Harshad</div><div><br></div></div>
<div><br>On Feb 16, 2014, at 2:30 AM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">It seems this work item is made of several blueprints, some of which are not yet approved. This is true at least for the Neutron blueprint regarding policy extensions.<div>
<br></div><div>Since I first looked at this spec I've been wondering why nova has been selected as an endpoint for network operations rather than Neutron, but this probably a design/implementation details whereas JC here is looking at the general approach.</div>
<div><br></div><div>Nevertheless, my only point here is that is seems that features like this need an "all-or-none" approval.</div><div>For instance, could the VPC feature be considered functional if blueprint [1] is implemented, but not [2] and [3]?</div>
<div><br></div><div>Salvatore</div><div><br></div><div>[1] <a href="https://blueprints.launchpad.net/nova/+spec/aws-vpc-support">https://blueprints.launchpad.net/nova/+spec/aws-vpc-support</a></div><div>[2] <a href="https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron">https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron</a></div>
<div>[3] <a href="https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy">https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy</a></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 11 February 2014 21:45, Martin, JC <span dir="ltr"><<a href="mailto:jch.martin@gmail.com" target="_blank">jch.martin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ravi,<br>
<br>
It seems that the following Blueprint<br>
<a href="https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support" target="_blank">https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support</a><br>
<br>
has been approved.<br>
<br>
However, I cannot find a discussion with regard to the merit of using project vs. domain, or other mechanism for the implementation.<br>
<br>
I have an issue with this approach as it prevents tenants within the same domain sharing the same VPC to have projects.<br>
<br>
As an example, if you are a large organization on AWS, it is likely that you have a large VPC that will be shred by multiple projects. With this proposal, we loose that capability, unless I missed something.<br>
<br>
JC<br>
<div><div class="h5"><br>
On Dec 19, 2013, at 6:10 PM, Ravi Chunduru <<a href="mailto:ravivsn@gmail.com">ravivsn@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
> We had some internal discussions on role of Domain and VPCs. I would like to expand and understand community thinking of Keystone domain and VPCs.<br>
><br>
> Is VPC equivalent to Keystone Domain?<br>
><br>
> If so, as a public cloud provider - I create a Keystone domain and give it to an organization which wants a virtual private cloud.<br>
><br>
> Now the question is if that organization wants to have departments wise allocation of resources it is becoming difficult to visualize with existing v3 keystone constructs.<br>
><br>
> Currently, it looks like each department of an organization cannot have their own resource management with in the organization VPC ( LDAP based user management, network management or dedicating computes etc.,) For us, Openstack Project does not match the requirements of a department of an organization.<br>
><br>
> I hope you guessed what we wanted - Domain must have VPCs and VPC to have projects.<br>
><br>
> I would like to know how community see the VPC model in Openstack.<br>
><br>
> Thanks,<br>
> -Ravi.<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OpenStack-dev mailing list</span><br><span><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></span><br>
<span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></body></html>