[openstack-dev] Hierarchicical Multitenancy Discussion
Adam Young
ayoung at redhat.com
Thu Feb 20 01:58:18 UTC 2014
On 02/18/2014 02:28 PM, Vishvananda Ishaya wrote:
>
> On Feb 18, 2014, at 11:04 AM, Adam Young <ayoung at redhat.com
> <mailto:ayoung at redhat.com>> wrote:
>
>> On 02/18/2014 12:53 PM, Telles Nobrega wrote:
>>> Hello everyone,
>>>
>>> Me and Raildo were responsible to implement Hierarchical Projects in
>>> Keystone.
>>>
>>> Here is our first prototype:
>>> https://github.com/tellesnobrega/keystone_hierarchical_projects
>>>
>>> We want to have it tested with Vishy's implementation this week.
>>>
>>> Here is a guide on how to test the implementation:
>>>
>>> 1. Start a devstack using the keystone code;
>>> 2. Create a new project using the following body:
>>> {
>>> "project": {
>>> "description": "test_project",
>>> "domain_id": "default",
>>> "parent_project_id": "$parent_project_id",
>>> "enabled": true,
>>> "name": "test_project"
>>> }
>>> }
>>>
>>> 3. Give an user a role in the project;
>>> 4. Get a token for "test_project" and check that the hierarchy is
>>> there like the following:
>>> {
>>> "token": {
>>> "methods": [
>>> "password"
>>> ],
>>> "roles": [
>>> {
>>> "id": "c60f0d7461354749ae8ac8bace3e35c5",
>>> "name": "admin"
>>> }
>>> ],
>>> "expires_at": "2014-02-18T15:52:03.499433Z",
>>> "project": {
>>> "hierarchical_ids": "
>>> openstack.
>>> 8a4ebcf44ebc47e0b98d3d5780c1f71a.de2a7135b01344cd82a02117c005ce47",
>>
>> These should be names, not Ids. There is going to be a need to move
>> projecst around inside the hierarchy, and the ID stays the same.
>> Lets get this right up front.
>
> Can you give more detail here? I can see arguments for both ways of
> doing this but continuing to use ids for ownership is an easier
> choice. Here is my thinking:
>
> 1. all of the projects use ids for ownership currently so it is a
> smaller change
That does not change. It is the hierarchy that is labeled by name.
> 2. renaming a project in keystone would not invalidate the ownership
> hierarchy (Note that moving a project around would invalidate the
> hierarchy in both cases)
>
Renaming would not change anything.
I would say the rule should be this: Ids are basically uuids, and are
immutable. Names a mutable. Each project has a parent Id. A project
can either be referenced directly by ID, oir hierarchically by name. In
addition, you can navigate to a project by traversing the set of ids,
but you need to know where you are going. THus the array
['abcd1234',fedd3213','3e3e3e3e'] would be a way to find a project, but
the project ID for the lead node would still be just '3e3e3e3e'.
> OTOTH the advantage of names is it makes displaying the ownership much
> easier on the service side.
>
> Vish
>
>>
>>> "hierarchy": "test1",
>>> "domain": {
>>> "id": "default",
>>> "name": "Default"
>>> },
>>> "id": "de2a7135b01344cd82a02117c005ce47",
>>> "name": "test1"
>>> },
>>> "extras": {},
>>> "user": {
>>> "domain": {
>>> "id": "default",
>>> "name": "Default"
>>> },
>>> "id": "895864161f1e4beaae42d9392ec105c8",
>>> "name": "admin"
>>> },
>>> "issued_at": "2014-02-18T14:52:03.499478Z"
>>> }
>>> }
>>>
>>> Openstack is the root project of the tree, it can be seen also when
>>> getting a token for the admin project or other default project in
>>> Devstack.
>>>
>>> Hope to hear your feedbacks soon.
>>>
>>> Thanks
>>>
>>>
>>> On Mon, Feb 17, 2014 at 6:09 AM, Vinod Kumar Boppanna
>>> <vinod.kumar.boppanna at cern.ch <mailto:vinod.kumar.boppanna at cern.ch>>
>>> wrote:
>>>
>>> Dear Vish,
>>>
>>> I will change the concept of parsing roles upto leaf node to
>>> parsing the roles to the top upto the level 1. But i have small
>>> doubt and i want to confirm with you before doing this change.
>>>
>>> If there are lets say 10 levels in the hierarchy and the user is
>>> getting authenticated at level 9. Should i check the roles
>>> starting from level 9 upto level 1. Ofcourse, the difference
>>> here is (compared to what i put in the wiki page) that, only
>>> roles at each level (if different) needs to be added to scope
>>> and no need of adding the project name and role individually. Is
>>> this ok, considering the fact that the more deeper in the
>>> hierarchy the user is getting authenticated, the more time
>>> needed to parse upto the level 1.
>>>
>>> I will wait for your response and then modify the POC accordingly.
>>>
>>> Thanks & Regards,
>>> Vinod Kumar Boppanna
>>> ________________________________________
>>> From: openstack-dev-request at lists.openstack.org
>>> <mailto:openstack-dev-request at lists.openstack.org>
>>> [openstack-dev-request at lists.openstack.org
>>> <mailto:openstack-dev-request at lists.openstack.org>]
>>> Sent: 16 February 2014 22:21
>>> To: openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>
>>> Subject: OpenStack-dev Digest, Vol 22, Issue 45
>>>
>>> Send OpenStack-dev mailing list submissions to
>>> openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> or, via email, send a message with subject or body 'help' to
>>> openstack-dev-request at lists.openstack.org
>>> <mailto:openstack-dev-request at lists.openstack.org>
>>>
>>> You can reach the person managing the list at
>>> openstack-dev-owner at lists.openstack.org
>>> <mailto:openstack-dev-owner at lists.openstack.org>
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of OpenStack-dev digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>> 1. Re: [Nova][VMWare] VMwareVCDriver related to resize/cold
>>> migration (Gary Kotton)
>>> 2. [Neutron]Do you think tanent_id should be verified (Dong Liu)
>>> 3. Re: [Nova][VMWare] VMwareVCDriver related to resize/cold
>>> migration (Jay Lau)
>>> 4. [neutron][policy] Using network services with network
>>> policies (Mohammad Banikazemi)
>>> 5. Re: [Nova][VMWare] VMwareVCDriver related to resize/cold
>>> migration (Jay Lau)
>>> 6. Re: [keystone] role of Domain in VPC definition (Harshad
>>> Nakil)
>>> 7. Re: VPC Proposal (Harshad Nakil)
>>> 8. Re: VPC Proposal (Allamaraju, Subbu)
>>> 9. Re: VPC Proposal (Harshad Nakil)
>>> 10. Re: VPC Proposal (Martin, JC)
>>> 11. Re: [keystone] role of Domain in VPC definition
>>> (Allamaraju, Subbu)
>>> 12. Re: [keystone] role of Domain in VPC definition (Harshad
>>> Nakil)
>>> 13. Re: [keystone] role of Domain in VPC definition
>>> (Allamaraju, Subbu)
>>> 14. Re: [OpenStack-Infra] [TripleO] promoting devtest_seed and
>>> devtest_undercloud to voting, + experimental queue for
>>> nova/neutron etc. (Robert Collins)
>>> 15. Re: [OpenStack-Infra] [TripleO] promoting devtest_seed and
>>> devtest_undercloud to voting, + experimental queue for
>>> nova/neutron etc. (Robert Collins)
>>> 16. Re: [keystone] role of Domain in VPC definition (Ravi
>>> Chunduru)
>>> 17. Re: VPC Proposal (Ravi Chunduru)
>>> 18. Re: OpenStack-dev Digest, Vol 22, Issue 39 (Vishvananda
>>> Ishaya)
>>> 19. Re: heat run_tests.sh fails with one huge line of
>>> output
>>> (Mike Spreitzer)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Sun, 16 Feb 2014 05:40:05 -0800
>>> From: Gary Kotton <gkotton at vmware.com <mailto:gkotton at vmware.com>>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] [Nova][VMWare] VMwareVCDriver
>>> related to
>>> resize/cold migration
>>> Message-ID: <CF268BE4.465C7%gkotton at vmware.com
>>> <mailto:CF268BE4.465C7%25gkotton at vmware.com>>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> Hi,
>>> There are two issues here.
>>> The first is a bug fix that is in review:
>>> - https://review.openstack.org/#/c/69209/ (this is where they
>>> have the same configuration)
>>> The second is WIP:
>>> - https://review.openstack.org/#/c/69262/ (we need to restore)
>>> Thanks
>>> Gary
>>>
>>> From: Jay Lau <jay.lau.513 at gmail.com
>>> <mailto:jay.lau.513 at gmail.com><mailto:jay.lau.513 at gmail.com
>>> <mailto:jay.lau.513 at gmail.com>>>
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>> questions)" <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>>
>>> Date: Sunday, February 16, 2014 6:39 AM
>>> To: OpenStack Development Mailing List
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>>
>>> Subject: [openstack-dev] [Nova][VMWare] VMwareVCDriver related
>>> to resize/cold migration
>>>
>>> Hey,
>>>
>>> I have one question related with OpenStack
>>> vmwareapi.VMwareVCDriver resize/cold migration.
>>>
>>> The following is my configuration:
>>>
>>> DC
>>> |
>>> |----Cluster1
>>> | |
>>> | |----9.111.249.56
>>> |
>>> |----Cluster2
>>> |
>>> |----9.111.249.49
>>>
>>> Scenario 1:
>>> I started two nova computes manage the two clusters:
>>> 1) nova-compute1.conf
>>> cluster_name=Cluster1
>>>
>>> 2) nova-compute2.conf
>>> cluster_name=Cluster2
>>>
>>> 3) Start up two nova computes on host1 and host2 separately
>>> 4) Create one VM instance and the VM instance was booted on
>>> Cluster2 node 9.111.249.49
>>> | OS-EXT-SRV-ATTR:host | host2 |
>>> | OS-EXT-SRV-ATTR:hypervisor_hostname | domain-c16(Cluster2) |
>>> 5) Cold migrate the VM instance
>>> 6) After migration finished, the VM goes to VERIFY_RESIZE
>>> status, and "nova show" indicates that the VM now located on
>>> host1:Cluster1
>>> | OS-EXT-SRV-ATTR:host | host1 |
>>> | OS-EXT-SRV-ATTR:hypervisor_hostname | domain-c12(Cluster1) |
>>> 7) But from vSphere client, it indicates the the VM was still
>>> running on Cluster2
>>> 8) Try to confirm the resize, confirm will be failed. The root
>>> cause is that nova compute on host2 has no knowledge of
>>> domain-c12(Cluster1)
>>>
>>> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp File
>>> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line
>>> 2810, in do_confirm_resize
>>> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp migration=migration)
>>> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp File
>>> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line
>>> 2836, in _confirm_resize
>>> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp network_info)
>>> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp File
>>> "/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py", line
>>> 420, in confirm_migration
>>> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp _vmops =
>>> self._get_vmops_for_compute_node(instance['node'])
>>> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp File
>>> "/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py", line
>>> 523, in _get_vmops_for_compute_node
>>> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp resource =
>>> self._get_resource_for_node(nodename)
>>> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp File
>>> "/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py", line
>>> 515, in _get_resource_for_node
>>> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp raise exception.NotFound(msg)
>>> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp NotFound: NV-3AB798A The resource
>>> domain-c12(Cluster1) does not exist
>>> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp
>>>
>>>
>>> Scenario 2:
>>>
>>> 1) Started two nova computes manage the two clusters, but the
>>> two computes have same nova conf.
>>> 1) nova-compute1.conf
>>> cluster_name=Cluster1
>>> cluster_name=Cluster2
>>>
>>> 2) nova-compute2.conf
>>> cluster_name=Cluster1
>>> cluster_name=Cluster2
>>>
>>> 3) Then create and resize/cold migrate a VM, it can always succeed.
>>>
>>>
>>> Questions:
>>> For multi-cluster management, does vmware require all nova
>>> compute have same cluster configuration to make sure resize/cold
>>> migration can succeed?
>>>
>>> --
>>> Thanks,
>>>
>>> Jay
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/0b71a846/attachment-0001.html>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Sun, 16 Feb 2014 22:52:01 +0800
>>> From: Dong Liu <willowd878 at gmail.com <mailto:willowd878 at gmail.com>>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: [openstack-dev] [Neutron]Do you think tanent_id should be
>>> verified
>>> Message-ID: <26565D39-5372-48A5-8299-34DDE6C3394D at gmail.com
>>> <mailto:26565D39-5372-48A5-8299-34DDE6C3394D at gmail.com>>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> Hi stackers:
>>>
>>> I found that when creating network subnet and other resources,
>>> the attribute tenant_id
>>> can be set by admin tenant. But we did not verify that if the
>>> tanent_id is real in keystone.
>>>
>>> I know that we could use neutron without keystone, but do you
>>> think tenant_id should
>>> be verified when we using neutron with keystone.
>>>
>>> thanks
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 3
>>> Date: Sun, 16 Feb 2014 23:01:17 +0800
>>> From: Jay Lau <jay.lau.513 at gmail.com <mailto:jay.lau.513 at gmail.com>>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] [Nova][VMWare] VMwareVCDriver
>>> related to
>>> resize/cold migration
>>> Message-ID:
>>>
>>> <CAFyztAFqTUqTZzzW6BkH6-9_kye9ZGm8yhZe3hMUoW1xFfQM7A at mail.gmail.com
>>> <mailto:CAFyztAFqTUqTZzzW6BkH6-9_kye9ZGm8yhZe3hMUoW1xFfQM7A at mail.gmail.com>>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Thanks Gary, clear now. ;-)
>>>
>>>
>>> 2014-02-16 21:40 GMT+08:00 Gary Kotton <gkotton at vmware.com
>>> <mailto:gkotton at vmware.com>>:
>>>
>>> > Hi,
>>> > There are two issues here.
>>> > The first is a bug fix that is in review:
>>> > - https://review.openstack.org/#/c/69209/ (this is where they
>>> have the
>>> > same configuration)
>>> > The second is WIP:
>>> > - https://review.openstack.org/#/c/69262/ (we need to restore)
>>> > Thanks
>>> > Gary
>>> >
>>> > From: Jay Lau <jay.lau.513 at gmail.com
>>> <mailto:jay.lau.513 at gmail.com>>
>>> > Reply-To: "OpenStack Development Mailing List (not for usage
>>> questions)" <
>>> > openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> > Date: Sunday, February 16, 2014 6:39 AM
>>> > To: OpenStack Development Mailing List
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> > Subject: [openstack-dev] [Nova][VMWare] VMwareVCDriver related to
>>> > resize/cold migration
>>> >
>>> > Hey,
>>> >
>>> > I have one question related with OpenStack
>>> vmwareapi.VMwareVCDriver
>>> > resize/cold migration.
>>> >
>>> > The following is my configuration:
>>> >
>>> > DC
>>> > |
>>> > |----Cluster1
>>> > | |
>>> > | |----9.111.249.56
>>> > |
>>> > |----Cluster2
>>> > |
>>> > |----9.111.249.49
>>> >
>>> > *Scenario 1:*
>>> > I started two nova computes manage the two clusters:
>>> > 1) nova-compute1.conf
>>> > cluster_name=Cluster1
>>> >
>>> > 2) nova-compute2.conf
>>> > cluster_name=Cluster2
>>> >
>>> > 3) Start up two nova computes on host1 and host2 separately
>>> > 4) Create one VM instance and the VM instance was booted on
>>> Cluster2 node
>>> > 9.111.249.49
>>> > | OS-EXT-SRV-ATTR:host | host2 |
>>> > | OS-EXT-SRV-ATTR:hypervisor_hostname |
>>> > domain-c16(Cluster2) |
>>> > 5) Cold migrate the VM instance
>>> > 6) After migration finished, the VM goes to VERIFY_RESIZE
>>> status, and
>>> > "nova show" indicates that the VM now located on host1:Cluster1
>>> > | OS-EXT-SRV-ATTR:host | host1 |
>>> > | OS-EXT-SRV-ATTR:hypervisor_hostname |
>>> > domain-c12(Cluster1) |
>>> > 7) But from vSphere client, it indicates the the VM was still
>>> running on
>>> > Cluster2
>>> > 8) Try to confirm the resize, confirm will be failed. The root
>>> cause is
>>> > that nova compute on host2 has no knowledge of
>>> domain-c12(Cluster1)
>>> >
>>> > 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp File
>>> > "/usr/lib/python2.6/site-packages/nova/compute/manager.py",
>>> line 2810, in
>>> > do_confirm_resize
>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp
>>> > migration=migration)
>>> > 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp File
>>> > "/usr/lib/python2.6/site-packages/nova/compute/manager.py",
>>> line 2836, in
>>> > _confirm_resize
>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp
>>> > network_info)
>>> > 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp File
>>> >
>>> "/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py", line
>>> 420,
>>> > in confirm_migration
>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp
>>> > _vmops = self._get_vmops_for_compute_node(instance['node'])
>>> > 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp File
>>> >
>>> "/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py", line
>>> 523,
>>> > in _get_vmops_for_compute_node
>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp
>>> > resource = self._get_resource_for_node(nodename)
>>> > 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp File
>>> >
>>> "/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py", line
>>> 515,
>>> > in _get_resource_for_node
>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp
>>> > raise exception.NotFound(msg)
>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp
>>> > NotFound: NV-3AB798A The resource domain-c12(Cluster1) does
>>> not exist
>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp
>>> >
>>> >
>>> > *Scenario 2:*
>>> >
>>> > 1) Started two nova computes manage the two clusters, but the
>>> two computes
>>> > have same nova conf.
>>> > 1) nova-compute1.conf
>>> > cluster_name=Cluster1
>>> > cluster_name=Cluster2
>>> >
>>> > 2) nova-compute2.conf
>>> > cluster_name=Cluster1
>>> > cluster_name=Cluster2
>>> >
>>> > 3) Then create and resize/cold migrate a VM, it can always
>>> succeed.
>>> >
>>> >
>>> > *Questions:*
>>> > For multi-cluster management, does vmware require all nova
>>> compute have
>>> > same cluster configuration to make sure resize/cold migration
>>> can succeed?
>>> >
>>> > --
>>> > Thanks,
>>> >
>>> > Jay
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>>
>>>
>>> --
>>> Thanks,
>>>
>>> Jay
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/a5a2ed40/attachment-0001.html>
>>>
>>> ------------------------------
>>>
>>> Message: 4
>>> Date: Sun, 16 Feb 2014 10:27:41 -0500
>>> From: Mohammad Banikazemi <mb at us.ibm.com <mailto:mb at us.ibm.com>>
>>> To: "OpenStack Development Mailing List \(not for usage questions\)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: [openstack-dev] [neutron][policy] Using network
>>> services with
>>> network policies
>>> Message-ID:
>>>
>>> <OF456914EA.334156E1-ON85257C81.0051DB09-85257C81.0054EF2C at us.ibm.com
>>> <mailto:OF456914EA.334156E1-ON85257C81.0051DB09-85257C81.0054EF2C at us.ibm.com>>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>>
>>> During the last IRC call we started talking about network
>>> services and how
>>> they can be integrated into the group Policy framework.
>>>
>>> In particular, with the "redirect" action we need to think how
>>> we can
>>> specify the network services we want to redirect the traffic
>>> to/from. There
>>> has been a substantial work in the area of service chaining and
>>> service
>>> insertion and in the last summit "advanced service" in VMs were
>>> discussed.
>>> I think the first step for us is to find out the status of those
>>> efforts
>>> and then see how we can use them. Here are a few questions that
>>> come to
>>> mind.
>>> 1- What is the status of service chaining, service insertion and
>>> advanced
>>> services work?
>>> 2- How could we use a service chain? Would simply referring to
>>> it in the
>>> action be enough? Are there considerations wrt creating a
>>> service chain
>>> and/or a service VM for use with the Group Policy framework that
>>> need to be
>>> taken into account?
>>>
>>> Let's start the discussion on the ML before taking it to the
>>> next call.
>>>
>>> Thanks,
>>>
>>> Mohammad
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/efff7427/attachment-0001.html>
>>>
>>> ------------------------------
>>>
>>> Message: 5
>>> Date: Sun, 16 Feb 2014 23:29:49 +0800
>>> From: Jay Lau <jay.lau.513 at gmail.com <mailto:jay.lau.513 at gmail.com>>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] [Nova][VMWare] VMwareVCDriver
>>> related to
>>> resize/cold migration
>>> Message-ID:
>>>
>>> <CAFyztAFCc1NH5nz00Dii3dhL3AN8RjPLb3D65aFMRGfyQiJGKA at mail.gmail.com
>>> <mailto:CAFyztAFCc1NH5nz00Dii3dhL3AN8RjPLb3D65aFMRGfyQiJGKA at mail.gmail.com>>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Hi Gary,
>>>
>>> One more question, when using VCDriver, I can use it in the
>>> following two
>>> ways:
>>> 1) start up many nova computes and those nova computes manage
>>> same vcenter
>>> clusters.
>>> 2) start up many nova computes and those nova computes manage
>>> different
>>> vcenter clusters.
>>>
>>> Do we have some best practice for above two scenarios or else
>>> can you
>>> please provide some best practise for VCDriver? I did not get
>>> much info
>>> from admin guide.
>>>
>>> Thanks,
>>>
>>> Jay
>>>
>>>
>>> 2014-02-16 23:01 GMT+08:00 Jay Lau <jay.lau.513 at gmail.com
>>> <mailto:jay.lau.513 at gmail.com>>:
>>>
>>> > Thanks Gary, clear now. ;-)
>>> >
>>> >
>>> > 2014-02-16 21:40 GMT+08:00 Gary Kotton <gkotton at vmware.com
>>> <mailto:gkotton at vmware.com>>:
>>> >
>>> >> Hi,
>>> >> There are two issues here.
>>> >> The first is a bug fix that is in review:
>>> >> - https://review.openstack.org/#/c/69209/ (this is where they
>>> have the
>>> >> same configuration)
>>> >> The second is WIP:
>>> >> - https://review.openstack.org/#/c/69262/ (we need to restore)
>>> >> Thanks
>>> >> Gary
>>> >>
>>> >> From: Jay Lau <jay.lau.513 at gmail.com
>>> <mailto:jay.lau.513 at gmail.com>>
>>> >> Reply-To: "OpenStack Development Mailing List (not for usage
>>> questions)"
>>> >> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> >> Date: Sunday, February 16, 2014 6:39 AM
>>> >> To: OpenStack Development Mailing List
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>
>>> >> >
>>> >> Subject: [openstack-dev] [Nova][VMWare] VMwareVCDriver related to
>>> >> resize/cold migration
>>> >>
>>> >> Hey,
>>> >>
>>> >> I have one question related with OpenStack
>>> vmwareapi.VMwareVCDriver
>>> >> resize/cold migration.
>>> >>
>>> >> The following is my configuration:
>>> >>
>>> >> DC
>>> >> |
>>> >> |----Cluster1
>>> >> | |
>>> >> | |----9.111.249.56
>>> >> |
>>> >> |----Cluster2
>>> >> |
>>> >> |----9.111.249.49
>>> >>
>>> >> *Scenario 1:*
>>> >> I started two nova computes manage the two clusters:
>>> >> 1) nova-compute1.conf
>>> >> cluster_name=Cluster1
>>> >>
>>> >> 2) nova-compute2.conf
>>> >> cluster_name=Cluster2
>>> >>
>>> >> 3) Start up two nova computes on host1 and host2 separately
>>> >> 4) Create one VM instance and the VM instance was booted on
>>> Cluster2
>>> >> node 9.111.249.49
>>> >> | OS-EXT-SRV-ATTR:host | host2 |
>>> >> | OS-EXT-SRV-ATTR:hypervisor_hostname |
>>> >> domain-c16(Cluster2) |
>>> >> 5) Cold migrate the VM instance
>>> >> 6) After migration finished, the VM goes to VERIFY_RESIZE
>>> status, and
>>> >> "nova show" indicates that the VM now located on host1:Cluster1
>>> >> | OS-EXT-SRV-ATTR:host | host1 |
>>> >> | OS-EXT-SRV-ATTR:hypervisor_hostname |
>>> >> domain-c12(Cluster1) |
>>> >> 7) But from vSphere client, it indicates the the VM was still
>>> running on
>>> >> Cluster2
>>> >> 8) Try to confirm the resize, confirm will be failed. The
>>> root cause is
>>> >> that nova compute on host2 has no knowledge of
>>> domain-c12(Cluster1)
>>> >>
>>> >> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp File
>>> >> "/usr/lib/python2.6/site-packages/nova/compute/manager.py",
>>> line 2810, in
>>> >> do_confirm_resize
>>> >> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp
>>> >> migration=migration)
>>> >> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp File
>>> >> "/usr/lib/python2.6/site-packages/nova/compute/manager.py",
>>> line 2836, in
>>> >> _confirm_resize
>>> >> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp
>>> >> network_info)
>>> >> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp File
>>> >>
>>> "/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py", line
>>> 420,
>>> >> in confirm_migration
>>> >> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp
>>> >> _vmops = self._get_vmops_for_compute_node(instance['node'])
>>> >> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp File
>>> >>
>>> "/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py", line
>>> 523,
>>> >> in _get_vmops_for_compute_node
>>> >> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp
>>> >> resource = self._get_resource_for_node(nodename)
>>> >> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp File
>>> >>
>>> "/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py", line
>>> 515,
>>> >> in _get_resource_for_node
>>> >> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp
>>> >> raise exception.NotFound(msg)
>>> >> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp
>>> >> NotFound: NV-3AB798A The resource domain-c12(Cluster1) does
>>> not exist
>>> >> 2014-02-16 07:10:17.166 12720 TRACE
>>> nova.openstack.common.rpc.amqp
>>> >>
>>> >>
>>> >> *Scenario 2:*
>>> >>
>>> >> 1) Started two nova computes manage the two clusters, but the two
>>> >> computes have same nova conf.
>>> >> 1) nova-compute1.conf
>>> >> cluster_name=Cluster1
>>> >> cluster_name=Cluster2
>>> >>
>>> >> 2) nova-compute2.conf
>>> >> cluster_name=Cluster1
>>> >> cluster_name=Cluster2
>>> >>
>>> >> 3) Then create and resize/cold migrate a VM, it can always
>>> succeed.
>>> >>
>>> >>
>>> >> *Questions:*
>>> >> For multi-cluster management, does vmware require all nova
>>> compute have
>>> >> same cluster configuration to make sure resize/cold migration
>>> can succeed?
>>> >>
>>> >> --
>>> >> Thanks,
>>> >>
>>> >> Jay
>>> >>
>>> >> _______________________________________________
>>> >> OpenStack-dev mailing list
>>> >> OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > Thanks,
>>> >
>>> > Jay
>>> >
>>>
>>>
>>>
>>> --
>>> Thanks,
>>>
>>> Jay
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/e7da9e73/attachment-0001.html>
>>>
>>> ------------------------------
>>>
>>> Message: 6
>>> Date: Sun, 16 Feb 2014 08:01:14 -0800
>>> From: Harshad Nakil <hnakil at contrailsystems.com
>>> <mailto:hnakil at contrailsystems.com>>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] [keystone] role of Domain in VPC
>>> definition
>>> Message-ID: <-4426752061342328447 at unknownmsgid>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Yes, [1] can be done without [2] and [3].
>>> As you are well aware [2] is now merged with group policy
>>> discussions.
>>> IMHO all or nothing approach will not get us anywhere.
>>> By the time we line up all our ducks in row. New
>>> features/ideas/blueprints
>>> will keep Emerging.
>>>
>>> Regards
>>> -Harshad
>>>
>>>
>>> On Feb 16, 2014, at 2:30 AM, Salvatore Orlando
>>> <sorlando at nicira.com <mailto:sorlando at nicira.com>> wrote:
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Nevertheless, my only point here is that is seems that features
>>> like this
>>> need an "all-or-none" approval.
>>> For instance, could the VPC feature be considered functional if
>>> blueprint
>>> [1] is implemented, but not [2] and [3]?
>>>
>>> Salvatore
>>>
>>> [1] https://blueprints.launchpad.net/nova/+spec/aws-vpc-support
>>> [2]
>>> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
>>> [3]
>>> https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy
>>>
>>>
>>> On 11 February 2014 21:45, Martin, JC <jch.martin at gmail.com
>>> <mailto:jch.martin at gmail.com>> wrote:
>>>
>>> > Ravi,
>>> >
>>> > It seems that the following Blueprint
>>> > https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support
>>> >
>>> > has been approved.
>>> >
>>> > However, I cannot find a discussion with regard to the merit
>>> of using
>>> > project vs. domain, or other mechanism for the implementation.
>>> >
>>> > I have an issue with this approach as it prevents tenants
>>> within the same
>>> > domain sharing the same VPC to have projects.
>>> >
>>> > 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.
>>> >
>>> > JC
>>> >
>>> > On Dec 19, 2013, at 6:10 PM, Ravi Chunduru <ravivsn at gmail.com
>>> <mailto:ravivsn at gmail.com>> wrote:
>>> >
>>> > > Hi,
>>> > > 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.
>>> > >
>>> > > Is VPC equivalent to Keystone Domain?
>>> > >
>>> > > If so, as a public cloud provider - I create a Keystone
>>> domain and give
>>> > it to an organization which wants a virtual private cloud.
>>> > >
>>> > > 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.
>>> > >
>>> > > 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.
>>> > >
>>> > > I hope you guessed what we wanted - Domain must have VPCs
>>> and VPC to
>>> > have projects.
>>> > >
>>> > > I would like to know how community see the VPC model in
>>> Openstack.
>>> > >
>>> > > Thanks,
>>> > > -Ravi.
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > OpenStack-dev mailing list
>>> > > OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> > >
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/9258cf27/attachment-0001.html>
>>>
>>> ------------------------------
>>>
>>> Message: 7
>>> Date: Sun, 16 Feb 2014 08:47:19 -0800
>>> From: Harshad Nakil <hnakil at contrailsystems.com
>>> <mailto:hnakil at contrailsystems.com>>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] VPC Proposal
>>> Message-ID:
>>>
>>> <CAL7PBMchfaSkX8amUAEe8X_fs9OM6ZLGJx_fNB2SUCJWPaGNFA at mail.gmail.com
>>> <mailto:CAL7PBMchfaSkX8amUAEe8X_fs9OM6ZLGJx_fNB2SUCJWPaGNFA at mail.gmail.com>>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Comments Inline
>>>
>>> Regards
>>> -Harshad
>>>
>>>
>>> On Sat, Feb 15, 2014 at 11:39 PM, Allamaraju, Subbu
>>> <subbu at subbu.org <mailto:subbu at subbu.org>> wrote:
>>>
>>> > Harshad,
>>> >
>>> > Curious to know if there is a broad interest in an AWS
>>> compatible API in
>>> > the community?
>>>
>>>
>>> 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 that community was
>>> interested as the
>>> blueprint was approved and code review has no -1(s) for long
>>> time now.
>>>
>>>
>>> > To clarify, a clear incremental path from an AWS compatible
>>> API to an
>>> > OpenStack model is not clear.
>>> >
>>>
>>> In my mind AWS compatible API does not need new openstack model.
>>> As more
>>> discussion happen on JC's proposal and implementation becomes
>>> clear we will
>>> know how incremental is the path. But at high level there two major
>>> differences
>>> 1. New first class object will be introduced which effect all
>>> components
>>> 2. more than one project can be supported within VPC.
>>> But it does not change AWS API(s). So even in JC(s) model if you
>>> want AWS
>>> API then we will have to keep VPC to project mapping 1:1, since
>>> the API
>>> will not take both VPC ID and project ID.
>>>
>>> As more users want to migrate from AWS or IaaS providers who
>>> want compete
>>> with AWS should be interested in this compatibility.
>>>
>>> There also seems to be terminology issue here Whats is
>>> definition of "VPC"
>>> if we assume what AWS implements is "VPC"
>>> then what JC is proposing "VOS" or "VDC" (virtual openstack or
>>> virtual DC)
>>> as all or most of current openstack features are available to
>>> user in this
>>> new Abstraction. I actually like this new abstraction.
>>>
>>>
>>> > Subbu
>>> >
>>> > On Feb 15, 2014, at 10:04 PM, Harshad Nakil
>>> <hnakil at contrailsystems.com <mailto:hnakil at contrailsystems.com>>
>>> > wrote:
>>> >
>>> > >
>>> > > I agree with problem as defined by you and will require more
>>> fundamental
>>> > changes.
>>> > > Meanwhile many users will benefit from AWS VPC api
>>> compatibility.
>>> >
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/5f655f01/attachment-0001.html>
>>>
>>> ------------------------------
>>>
>>> Message: 8
>>> Date: Sun, 16 Feb 2014 09:04:36 -0800
>>> From: "Allamaraju, Subbu" <subbu at subbu.org <mailto:subbu at subbu.org>>
>>> To: Harshad Nakil <hnakil at contrailsystems.com
>>> <mailto:hnakil at contrailsystems.com>>
>>> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] VPC Proposal
>>> Message-ID: <641D4BA6-DFB2-4D3E-8D67-48F711ADC1B5 at subbu.org
>>> <mailto:641D4BA6-DFB2-4D3E-8D67-48F711ADC1B5 at subbu.org>>
>>> Content-Type: text/plain; charset=iso-8859-1
>>>
>>> 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
>>> that community was interested as the blueprint was approved and
>>> code review has no -1(s) for long time now.
>>>
>>> Makes sense. I would leave it to others on this list to chime in
>>> if there is sufficient interest or not.
>>>
>>> > To clarify, a clear incremental path from an AWS compatible
>>> API to an OpenStack model is not clear.
>>> >
>>> > In my mind AWS compatible API does not need new openstack
>>> model. As more discussion happen on JC's proposal and
>>> implementation becomes clear we will know how incremental is the
>>> path. But at high level there two major differences
>>> > 1. New first class object will be introduced which effect all
>>> components
>>> > 2. more than one project can be supported within VPC.
>>> > But it does not change AWS API(s). So even in JC(s) model if
>>> you want AWS API then we will have to keep VPC to project
>>> mapping 1:1, since the API will not take both VPC ID and project ID.
>>> >
>>> > As more users want to migrate from AWS or IaaS providers who
>>> want compete with AWS should be interested in this compatibility.
>>>
>>> IMHO that's a tough sell. Though an AWS compatible API does not
>>> need an OpenStack abstraction, we would end up with two
>>> independent ways of doing similar things. That would OpenStack
>>> repeating itself!
>>>
>>> Subbu
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 9
>>> Date: Sun, 16 Feb 2014 09:12:54 -0800
>>> From: Harshad Nakil <hnakil at contrailsystems.com
>>> <mailto:hnakil at contrailsystems.com>>
>>> To: "Allamaraju, Subbu" <subbu at subbu.org <mailto:subbu at subbu.org>>
>>> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] VPC Proposal
>>> Message-ID: <516707826958554641 at unknownmsgid>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> IMHO I don't see two implementations. Since right now we have only
>>> one. As a community if we decide to add new abstractions then we
>>> will
>>> have to change software in every component where the new abstraction
>>> makes difference. That's normal software development process.
>>> Regards
>>> -Harshad
>>>
>>>
>>> > On Feb 16, 2014, at 9:03 AM, "Allamaraju, Subbu"
>>> <subbu at subbu.org <mailto:subbu at subbu.org>> wrote:
>>> >
>>> > 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 that community was interested as the blueprint was
>>> approved and code review has no -1(s) for long time now.
>>> >
>>> > Makes sense. I would leave it to others on this list to chime
>>> in if there is sufficient interest or not.
>>> >
>>> >> To clarify, a clear incremental path from an AWS compatible
>>> API to an OpenStack model is not clear.
>>> >>
>>> >> In my mind AWS compatible API does not need new openstack
>>> model. As more discussion happen on JC's proposal and
>>> implementation becomes clear we will know how incremental is the
>>> path. But at high level there two major differences
>>> >> 1. New first class object will be introduced which effect all
>>> components
>>> >> 2. more than one project can be supported within VPC.
>>> >> But it does not change AWS API(s). So even in JC(s) model if
>>> you want AWS API then we will have to keep VPC to project
>>> mapping 1:1, since the API will not take both VPC ID and project ID.
>>> >>
>>> >> As more users want to migrate from AWS or IaaS providers who
>>> want compete with AWS should be interested in this compatibility.
>>> >
>>> > IMHO that's a tough sell. Though an AWS compatible API does
>>> not need an OpenStack abstraction, we would end up with two
>>> independent ways of doing similar things. That would OpenStack
>>> repeating itself!
>>> >
>>> > Subbu
>>> >
>>> >
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 10
>>> Date: Sun, 16 Feb 2014 09:25:02 -0800
>>> From: "Martin, JC" <jch.martin at gmail.com
>>> <mailto:jch.martin at gmail.com>>
>>> To: "OpenStack Development Mailing List \(not for usage questions\)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] VPC Proposal
>>> Message-ID: <B1A58385-DC10-48EF-AA8E-90176F576A40 at gmail.com
>>> <mailto:B1A58385-DC10-48EF-AA8E-90176F576A40 at gmail.com>>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> Harshad,
>>>
>>> I tried to find some discussion around this blueprint.
>>> Could you provide us with some notes or threads ?
>>>
>>> Also, about the code review you mention. which one are you
>>> talking about :
>>> https://review.openstack.org/#/c/40071/
>>> https://review.openstack.org/#/c/49470/
>>> https://review.openstack.org/#/c/53171
>>>
>>> because they are all abandoned.
>>>
>>> Could you point me to the code, and update the BP because it
>>> seems that the links are not correct.
>>>
>>> Thanks,
>>>
>>> JC
>>> On Feb 16, 2014, at 9:04 AM, "Allamaraju, Subbu"
>>> <subbu at subbu.org <mailto:subbu at subbu.org>> wrote:
>>>
>>> > 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 that community was interested as the blueprint was
>>> approved and code review has no -1(s) for long time now.
>>> >
>>> > Makes sense. I would leave it to others on this list to chime
>>> in if there is sufficient interest or not.
>>> >
>>> >> To clarify, a clear incremental path from an AWS compatible
>>> API to an OpenStack model is not clear.
>>> >>
>>> >> In my mind AWS compatible API does not need new openstack
>>> model. As more discussion happen on JC's proposal and
>>> implementation becomes clear we will know how incremental is the
>>> path. But at high level there two major differences
>>> >> 1. New first class object will be introduced which effect all
>>> components
>>> >> 2. more than one project can be supported within VPC.
>>> >> But it does not change AWS API(s). So even in JC(s) model if
>>> you want AWS API then we will have to keep VPC to project
>>> mapping 1:1, since the API will not take both VPC ID and project ID.
>>> >>
>>> >> As more users want to migrate from AWS or IaaS providers who
>>> want compete with AWS should be interested in this compatibility.
>>> >
>>> > IMHO that's a tough sell. Though an AWS compatible API does
>>> not need an OpenStack abstraction, we would end up with two
>>> independent ways of doing similar things. That would OpenStack
>>> repeating itself!
>>> >
>>> > Subbu
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 11
>>> Date: Sun, 16 Feb 2014 09:49:17 -0800
>>> From: "Allamaraju, Subbu" <subbu at subbu.org <mailto:subbu at subbu.org>>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] [keystone] role of Domain in VPC
>>> definition
>>> Message-ID: <1756EFC4-ABAF-4377-B44A-219F34C3ABFA at subbu.org
>>> <mailto:1756EFC4-ABAF-4377-B44A-219F34C3ABFA at subbu.org>>
>>> Content-Type: text/plain; charset=iso-8859-1
>>>
>>> Harshad,
>>>
>>> But the key question that Ravi brought up remains though. A
>>> project is a very small administrative container to manage
>>> policies and resources for VPCs. We've been experimenting with
>>> VPCs on OpenStack (with some mods) at work for nearly a year,
>>> and came across cases where hundreds/thousands of apps in equal
>>> number of projects needing to share resources and policies, and
>>> project to VPC mapping did not cut.
>>>
>>> I was wondering if there was prior discussion around the mapping
>>> of AWS VPC model to OpenStack concepts like projects and
>>> domains. Thanks for any pointers.
>>>
>>> Subbu
>>>
>>> On Feb 16, 2014, at 8:01 AM, Harshad Nakil
>>> <hnakil at contrailsystems.com <mailto:hnakil at contrailsystems.com>>
>>> wrote:
>>>
>>> > Yes, [1] can be done without [2] and [3].
>>> > As you are well aware [2] is now merged with group policy
>>> discussions.
>>> > IMHO all or nothing approach will not get us anywhere.
>>> > By the time we line up all our ducks in row. New
>>> features/ideas/blueprints will keep Emerging.
>>> >
>>> > Regards
>>> > -Harshad
>>> >
>>> >
>>> > On Feb 16, 2014, at 2:30 AM, Salvatore Orlando
>>> <sorlando at nicira.com <mailto:sorlando at nicira.com>> wrote:
>>> >
>>> >> 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.
>>> >>
>>> >> 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.
>>> >>
>>> >> Nevertheless, my only point here is that is seems that
>>> features like this need an "all-or-none" approval.
>>> >> For instance, could the VPC feature be considered functional
>>> if blueprint [1] is implemented, but not [2] and [3]?
>>> >>
>>> >> Salvatore
>>> >>
>>> >> [1] https://blueprints.launchpad.net/nova/+spec/aws-vpc-support
>>> >> [2]
>>> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
>>> >> [3]
>>> https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy
>>> >>
>>> >>
>>> >> On 11 February 2014 21:45, Martin, JC <jch.martin at gmail.com
>>> <mailto:jch.martin at gmail.com>> wrote:
>>> >> Ravi,
>>> >>
>>> >> It seems that the following Blueprint
>>> >> https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support
>>> >>
>>> >> has been approved.
>>> >>
>>> >> However, I cannot find a discussion with regard to the merit
>>> of using project vs. domain, or other mechanism for the
>>> implementation.
>>> >>
>>> >> I have an issue with this approach as it prevents tenants
>>> within the same domain sharing the same VPC to have projects.
>>> >>
>>> >> 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.
>>> >>
>>> >> JC
>>> >>
>>> >> On Dec 19, 2013, at 6:10 PM, Ravi Chunduru <ravivsn at gmail.com
>>> <mailto:ravivsn at gmail.com>> wrote:
>>> >>
>>> >> > Hi,
>>> >> > 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.
>>> >> >
>>> >> > Is VPC equivalent to Keystone Domain?
>>> >> >
>>> >> > If so, as a public cloud provider - I create a Keystone
>>> domain and give it to an organization which wants a virtual
>>> private cloud.
>>> >> >
>>> >> > 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.
>>> >> >
>>> >> > 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.
>>> >> >
>>> >> > I hope you guessed what we wanted - Domain must have VPCs
>>> and VPC to have projects.
>>> >> >
>>> >> > I would like to know how community see the VPC model in
>>> Openstack.
>>> >> >
>>> >> > Thanks,
>>> >> > -Ravi.
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > OpenStack-dev mailing list
>>> >> > OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> >> >
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> OpenStack-dev mailing list
>>> >> OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >>
>>> >> _______________________________________________
>>> >> OpenStack-dev mailing list
>>> >> OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 12
>>> Date: Sun, 16 Feb 2014 10:15:11 -0800
>>> From: Harshad Nakil <hnakil at contrailsystems.com
>>> <mailto:hnakil at contrailsystems.com>>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] [keystone] role of Domain in VPC
>>> definition
>>> Message-ID: <4920517322402852354 at unknownmsgid>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> As said I am not disagreeing with you or Ravi or JC. I also
>>> agree that
>>> Openstack VPC implementation will benefit from these proposals.
>>> What I am saying is it is not required AWS VPC API compatibility at
>>> this point. Which is what our blueprint is all about. We are not
>>> defining THE "VPC".
>>> Let me ask you what changes in AWS API when you go to other model?
>>> The argument is you want multiple projects in VPC. That's great.
>>> But I
>>> don't understand how I would specify it if my code was written
>>> to use
>>> AWS API.
>>> The argument you want multiple external networks per VPC I don't
>>> know
>>> how to specify using AWS API
>>> So list goes on.
>>>
>>> May be I am missing something. If you don't want AWS compatibility
>>> then that's different issue all together. And should be discussed as
>>> such.
>>>
>>> Regards
>>> -Harshad
>>>
>>>
>>> > On Feb 16, 2014, at 9:51 AM, "Allamaraju, Subbu"
>>> <subbu at subbu.org <mailto:subbu at subbu.org>> wrote:
>>> >
>>> > Harshad,
>>> >
>>> > But the key question that Ravi brought up remains though. A
>>> project is a very small administrative container to manage
>>> policies and resources for VPCs. We've been experimenting with
>>> VPCs on OpenStack (with some mods) at work for nearly a year,
>>> and came across cases where hundreds/thousands of apps in equal
>>> number of projects needing to share resources and policies, and
>>> project to VPC mapping did not cut.
>>> >
>>> > I was wondering if there was prior discussion around the
>>> mapping of AWS VPC model to OpenStack concepts like projects and
>>> domains. Thanks for any pointers.
>>> >
>>> > Subbu
>>> >
>>> >> On Feb 16, 2014, at 8:01 AM, Harshad Nakil
>>> <hnakil at contrailsystems.com <mailto:hnakil at contrailsystems.com>>
>>> wrote:
>>> >>
>>> >> Yes, [1] can be done without [2] and [3].
>>> >> As you are well aware [2] is now merged with group policy
>>> discussions.
>>> >> IMHO all or nothing approach will not get us anywhere.
>>> >> By the time we line up all our ducks in row. New
>>> features/ideas/blueprints will keep Emerging.
>>> >>
>>> >> Regards
>>> >> -Harshad
>>> >>
>>> >>
>>> >>> On Feb 16, 2014, at 2:30 AM, Salvatore Orlando
>>> <sorlando at nicira.com <mailto:sorlando at nicira.com>> wrote:
>>> >>>
>>> >>> 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.
>>> >>>
>>> >>> 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.
>>> >>>
>>> >>> Nevertheless, my only point here is that is seems that
>>> features like this need an "all-or-none" approval.
>>> >>> For instance, could the VPC feature be considered functional
>>> if blueprint [1] is implemented, but not [2] and [3]?
>>> >>>
>>> >>> Salvatore
>>> >>>
>>> >>> [1] https://blueprints.launchpad.net/nova/+spec/aws-vpc-support
>>> >>> [2]
>>> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
>>> >>> [3]
>>> https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy
>>> >>>
>>> >>>
>>> >>> On 11 February 2014 21:45, Martin, JC <jch.martin at gmail.com
>>> <mailto:jch.martin at gmail.com>> wrote:
>>> >>> Ravi,
>>> >>>
>>> >>> It seems that the following Blueprint
>>> >>> https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support
>>> >>>
>>> >>> has been approved.
>>> >>>
>>> >>> However, I cannot find a discussion with regard to the merit
>>> of using project vs. domain, or other mechanism for the
>>> implementation.
>>> >>>
>>> >>> I have an issue with this approach as it prevents tenants
>>> within the same domain sharing the same VPC to have projects.
>>> >>>
>>> >>> 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.
>>> >>>
>>> >>> JC
>>> >>>
>>> >>>> On Dec 19, 2013, at 6:10 PM, Ravi Chunduru
>>> <ravivsn at gmail.com <mailto:ravivsn at gmail.com>> wrote:
>>> >>>>
>>> >>>> Hi,
>>> >>>> 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.
>>> >>>>
>>> >>>> Is VPC equivalent to Keystone Domain?
>>> >>>>
>>> >>>> If so, as a public cloud provider - I create a Keystone
>>> domain and give it to an organization which wants a virtual
>>> private cloud.
>>> >>>>
>>> >>>> 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.
>>> >>>>
>>> >>>> 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.
>>> >>>>
>>> >>>> I hope you guessed what we wanted - Domain must have VPCs
>>> and VPC to have projects.
>>> >>>>
>>> >>>> I would like to know how community see the VPC model in
>>> Openstack.
>>> >>>>
>>> >>>> Thanks,
>>> >>>> -Ravi.
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> OpenStack-dev mailing list
>>> >>>> OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> >>>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> OpenStack-dev mailing list
>>> >>> OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> >>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >>>
>>> >>> _______________________________________________
>>> >>> OpenStack-dev mailing list
>>> >>> OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> >>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >> _______________________________________________
>>> >> OpenStack-dev mailing list
>>> >> OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 13
>>> Date: Sun, 16 Feb 2014 10:31:42 -0800
>>> From: "Allamaraju, Subbu" <subbu at subbu.org <mailto:subbu at subbu.org>>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] [keystone] role of Domain in VPC
>>> definition
>>> Message-ID: <7CD9E46E-FC0A-431B-836F-9BD02B0E417A at subbu.org
>>> <mailto:7CD9E46E-FC0A-431B-836F-9BD02B0E417A at subbu.org>>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> 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
>>> <hnakil at contrailsystems.com <mailto:hnakil at contrailsystems.com>>
>>> wrote:
>>>
>>> > As said I am not disagreeing with you or Ravi or JC. I also
>>> agree that
>>> > Openstack VPC implementation will benefit from these proposals.
>>> > What I am saying is it is not required AWS VPC API
>>> compatibility at
>>> > this point. Which is what our blueprint is all about. We are not
>>> > defining THE "VPC".
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 14
>>> Date: Mon, 17 Feb 2014 08:20:09 +1300
>>> From: Robert Collins <robertc at robertcollins.net
>>> <mailto:robertc at robertcollins.net>>
>>> To: Sean Dague <sean at dague.net <mailto:sean at dague.net>>
>>> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>,
>>> "<openstack-infra at lists.openstack.org
>>> <mailto:openstack-infra at lists.openstack.org>>"
>>> <openstack-infra at lists.openstack.org
>>> <mailto:openstack-infra at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] [OpenStack-Infra] [TripleO] promoting
>>> devtest_seed and devtest_undercloud to voting, +
>>> experimental queue
>>> for nova/neutron etc.
>>> Message-ID:
>>> <CAJ3HoZ1LC1WqayW3o3RaPxfLC0G-Lb9zxHKftPDW=t8wnubCtQ at mail.gmail.com
>>> <mailto:t8wnubCtQ at mail.gmail.com>>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> On 15 February 2014 09:58, Sean Dague <sean at dague.net
>>> <mailto:sean at dague.net>> wrote:
>>>
>>> >> Lastly, I'm going to propose a merge to infra/config to put our
>>> >> undercloud story (which exercises the seed's ability to
>>> deploy via
>>> >> heat with bare metal) as a check experimental job on our
>>> dependencies
>>> >> (keystone, glance, nova, neutron) - if thats ok with those
>>> projects?
>>> >>
>>> >> -Rob
>>> >>
>>> >
>>> > My biggest concern with adding this to check experimental, is the
>>> > experimental results aren't published back until all the
>>> experimental
>>> > jobs are done.
>>>
>>> If we add a new pipeline - https://review.openstack.org/#/c/73863/ -
>>> then we can avoid that.
>>>
>>> > We've seen really substantial delays, plus a 5 day complete
>>> outage a
>>> > week ago, on the tripleo cloud. I'd like to see that much more
>>> proven
>>> > before it starts to impact core projects, even in experimental.
>>>
>>> I believe that with a new pipeline it won't impact core projects
>>> at all.
>>>
>>> The outage, FWIW, was because I deleted the entire cloud, at the
>>> same
>>> time that we had a firedrill with some other upstream-of-us issue (I
>>> forget the exact one). The multi-region setup we're aiming for
>>> should
>>> mitigate that substantially :)
>>>
>>>
>>> -Rob
>>>
>>>
>>> --
>>> Robert Collins <rbtcollins at hp.com <mailto:rbtcollins at hp.com>>
>>> Distinguished Technologist
>>> HP Converged Cloud
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 15
>>> Date: Mon, 17 Feb 2014 08:25:04 +1300
>>> From: Robert Collins <robertc at robertcollins.net
>>> <mailto:robertc at robertcollins.net>>
>>> To: "James E. Blair" <jeblair at openstack.org
>>> <mailto:jeblair at openstack.org>>
>>> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>,
>>> "<openstack-infra at lists.openstack.org
>>> <mailto:openstack-infra at lists.openstack.org>>"
>>> <openstack-infra at lists.openstack.org
>>> <mailto:openstack-infra at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] [OpenStack-Infra] [TripleO] promoting
>>> devtest_seed and devtest_undercloud to voting, +
>>> experimental queue
>>> for nova/neutron etc.
>>> Message-ID:
>>>
>>> <CAJ3HoZ0me0xfeGArVSqLkC0SPpJwaTeK+hNYoePDdh_2FR_K9w at mail.gmail.com
>>> <mailto:CAJ3HoZ0me0xfeGArVSqLkC0SPpJwaTeK%2BhNYoePDdh_2FR_K9w at mail.gmail.com>>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> On 15 February 2014 12:21, James E. Blair <jeblair at openstack.org
>>> <mailto:jeblair at openstack.org>> wrote:
>>>
>>> > You won't end up with -1's everywhere, you'll end up with jobs
>>> stuck in
>>> > the queue indefinitely, as we saw when the tripleo cloud failed
>>> > recently. What's worse is that now that positive check
>>> results are
>>> > required for enqueuing into the gate, you will also not be
>>> able to merge
>>> > anything.
>>>
>>> Ok. So the cost of voting [just in tripleo] would be that a)
>>> [tripleo]
>>> infrastructure failures and b) breakage from other projects - both
>>> things that can cause checks to fail, would stall all tripleo
>>> landings
>>> until rectified, or until voting is turned off via a change to
>>> config
>>> which makes this infra's problem.
>>>
>>> Hmm - so from a tripleo perspective, I think we're ok with this -
>>> having a clear indication that 'this is ok' is probably more
>>> important
>>> to us right now than the more opaque thing we have now where we have
>>> to expand every jenkins comment to be sure.
>>>
>>> But- will infra be ok, if we end up having a firedrill 'please make
>>> this nonvoting' change to propose?
>>>
>>> -Rob
>>>
>>> --
>>> Robert Collins <rbtcollins at hp.com <mailto:rbtcollins at hp.com>>
>>> Distinguished Technologist
>>> HP Converged Cloud
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 16
>>> Date: Sun, 16 Feb 2014 11:38:57 -0800
>>> From: Ravi Chunduru <ravivsn at gmail.com <mailto:ravivsn at gmail.com>>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] [keystone] role of Domain in VPC
>>> definition
>>> Message-ID:
>>> <CAEgw6yuopjDfeF2vmAXtjiiA+Fz14=tbZcKV+m3eviLb=Xf5tQ at mail.gmail.com
>>> <mailto:Xf5tQ at mail.gmail.com>>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> I agree with JC that we need to pause and discuss VPC model with in
>>> openstack before considering AWS compatibility. As Subbu said,
>>> We need this
>>> discussion in Juno summit and get consensus.
>>>
>>> Thanks,
>>> -Ravi.
>>>
>>>
>>> On Sun, Feb 16, 2014 at 10:31 AM, Allamaraju, Subbu
>>> <subbu at subbu.org <mailto:subbu at subbu.org>> wrote:
>>>
>>> > 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
>>> <hnakil at contrailsystems.com <mailto:hnakil at contrailsystems.com>>
>>> > wrote:
>>> >
>>> > > As said I am not disagreeing with you or Ravi or JC. I also
>>> agree that
>>> > > Openstack VPC implementation will benefit from these proposals.
>>> > > What I am saying is it is not required AWS VPC API
>>> compatibility at
>>> > > this point. Which is what our blueprint is all about. We
>>> are not
>>> > > defining THE "VPC".
>>> >
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>>
>>> --
>>> Ravi
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/2ef6cc51/attachment-0001.html>
>>>
>>> ------------------------------
>>>
>>> Message: 17
>>> Date: Sun, 16 Feb 2014 11:54:54 -0800
>>> From: Ravi Chunduru <ravivsn at gmail.com <mailto:ravivsn at gmail.com>>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] VPC Proposal
>>> Message-ID:
>>>
>>> <CAEgw6ysbaY6-8w_VOme5mU1k29v0dy42mvuRkTsTR7XXKw6CMg at mail.gmail.com
>>> <mailto:CAEgw6ysbaY6-8w_VOme5mU1k29v0dy42mvuRkTsTR7XXKw6CMg at mail.gmail.com>>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> IMO, VPC means to have managed set of resources not just limited to
>>> networks but also projects.
>>> I feel its not about incrementally starting with AWS
>>> compatibility, But
>>> doing it right with AWS compatibility into consideration.
>>>
>>> Thanks,
>>> -Ravi.
>>>
>>>
>>> On Sun, Feb 16, 2014 at 8:47 AM, Harshad Nakil
>>> <hnakil at contrailsystems.com
>>> <mailto:hnakil at contrailsystems.com>>wrote:
>>>
>>> > Comments Inline
>>> >
>>> > Regards
>>> > -Harshad
>>> >
>>> >
>>> > On Sat, Feb 15, 2014 at 11:39 PM, Allamaraju, Subbu
>>> <subbu at subbu.org <mailto:subbu at subbu.org>>wrote:
>>> >
>>> >> Harshad,
>>> >>
>>> >> Curious to know if there is a broad interest in an AWS
>>> compatible API in
>>> >> the community?
>>> >
>>> >
>>> > 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 that community was
>>> interested as the
>>> > blueprint was approved and code review has no -1(s) for long
>>> time now.
>>> >
>>> >
>>> >> To clarify, a clear incremental path from an AWS compatible
>>> API to an
>>> >> OpenStack model is not clear.
>>> >>
>>> >
>>> > In my mind AWS compatible API does not need new openstack
>>> model. As more
>>> > discussion happen on JC's proposal and implementation becomes
>>> clear we will
>>> > know how incremental is the path. But at high level there two
>>> major
>>> > differences
>>> > 1. New first class object will be introduced which effect all
>>> components
>>> > 2. more than one project can be supported within VPC.
>>> > But it does not change AWS API(s). So even in JC(s) model if
>>> you want AWS
>>> > API then we will have to keep VPC to project mapping 1:1,
>>> since the API
>>> > will not take both VPC ID and project ID.
>>> >
>>> >
>>>
>>>
>>>
>>> > As more users want to migrate from AWS or IaaS providers who
>>> want compete
>>> > with AWS should be interested in this compatibility.
>>> >
>>> > There also seems to be terminology issue here Whats is
>>> definition of "VPC"
>>> > if we assume what AWS implements is "VPC"
>>> > then what JC is proposing "VOS" or "VDC" (virtual openstack or
>>> virtual DC)
>>> > as all or most of current openstack features are available to
>>> user in this
>>> > new Abstraction. I actually like this new abstraction.
>>> >
>>> >
>>> >> Subbu
>>> >>
>>> >> On Feb 15, 2014, at 10:04 PM, Harshad Nakil
>>> <hnakil at contrailsystems.com <mailto:hnakil at contrailsystems.com>>
>>> >> wrote:
>>> >>
>>> >> >
>>> >> > I agree with problem as defined by you and will require more
>>> >> fundamental changes.
>>> >> > Meanwhile many users will benefit from AWS VPC api
>>> compatibility.
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> OpenStack-dev mailing list
>>> >> OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>>
>>>
>>> --
>>> Ravi
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/745d6d7d/attachment-0001.html>
>>>
>>> ------------------------------
>>>
>>> Message: 18
>>> Date: Sun, 16 Feb 2014 12:08:15 -0800
>>> From: Vishvananda Ishaya <vishvananda at gmail.com
>>> <mailto:vishvananda at gmail.com>>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] OpenStack-dev Digest, Vol 22, Issue 39
>>> Message-ID: <91C14EC4-02F8-4DFC-9145-08BE2DA249AD at gmail.com
>>> <mailto:91C14EC4-02F8-4DFC-9145-08BE2DA249AD at gmail.com>>
>>> Content-Type: text/plain; charset="windows-1252"
>>>
>>>
>>> On Feb 15, 2014, at 4:36 AM, Vinod Kumar Boppanna
>>> <vinod.kumar.boppanna at cern.ch
>>> <mailto:vinod.kumar.boppanna at cern.ch>> wrote:
>>>
>>> >
>>> > Dear Vish,
>>> >
>>> > I completely agree with you. Its like a trade off between
>>> getting re-authenticated (when in a hierarchy user has different
>>> roles at different levels) or parsing the entire hierarchy till
>>> the leaf and include all the roles the user has at each level in
>>> the scope.
>>> >
>>> > I am ok with any one (both has some advantages and
>>> dis-advantages).
>>> >
>>> > But one point i didn't understand why should we parse the tree
>>> above the level where the user gets authenticated (as you
>>> specified in the reply). Like if user is authenticated at level
>>> 3, then do we mean that the roles at level 2 and level 1 also
>>> should be passed?
>>> > Why this is needed? I only see either we pass only the role at
>>> the level the user is getting authenticated or pass the roles at
>>> the level till the leaf starting from the level the user is
>>> getting authenticated.
>>>
>>>
>>> This is needed because in my proposed model roles are inherited
>>> down the heirarchy. That means if you authenticate against
>>> ProjA.ProjA2 and you have a role like ?netadmin? in ProjA, you
>>> will also have it in ProjA2. So it is necessary to walk up the
>>> tree to find the full list of roles.
>>>
>>> Vish
>>>
>>> >
>>> > Regards,
>>> > Vinod Kumar Boppanna
>>> > ________________________________________
>>> > Message: 21
>>> > Date: Fri, 14 Feb 2014 10:13:59 -0800
>>> > From: Vishvananda Ishaya <vishvananda at gmail.com
>>> <mailto:vishvananda at gmail.com>>
>>> > To: "OpenStack Development Mailing List (not for usage questions)"
>>> > <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> > Subject: Re: [openstack-dev] Hierarchicical Multitenancy
>>> Discussion
>>> > Message-ID: <4508B18F-458B-4A3E-BA66-22F9FA47EAC0 at gmail.com
>>> <mailto:4508B18F-458B-4A3E-BA66-22F9FA47EAC0 at gmail.com>>
>>> > Content-Type: text/plain; charset="windows-1252"
>>> >
>>> > Hi Vinod!
>>> >
>>> > I think you can simplify the roles in the hierarchical model
>>> by only passing the roles for the authenticated project and
>>> above. All roles are then inherited down. This means it isn?t
>>> necessary to pass a scope along with each role. The scope is
>>> just passed once with the token and the project-admin role (for
>>> example) would be checking to see that the user has the
>>> project-admin role and that the project_id prefix matches.
>>> >
>>> > There is only one case that this doesn?t handle, and that is
>>> when the user has one role (say member) in ProjA and
>>> project-admin in ProjA2. If the user is authenticated to ProjA,
>>> he can?t do project-adminy stuff for ProjA2 without
>>> reauthenticating. I think this is a reasonable sacrifice
>>> considering how much easier it would be to just pass the parent
>>> roles instead of going through all of the children.
>>> >
>>> > Vish
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> -------------- next part --------------
>>> A non-text attachment was scrubbed...
>>> Name: signature.asc
>>> Type: application/pgp-signature
>>> Size: 455 bytes
>>> Desc: Message signed with OpenPGP using GPGMail
>>> URL:
>>> <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/7c320704/attachment-0001.pgp>
>>>
>>> ------------------------------
>>>
>>> Message: 19
>>> Date: Sun, 16 Feb 2014 16:20:52 -0500
>>> From: Mike Spreitzer <mspreitz at us.ibm.com
>>> <mailto:mspreitz at us.ibm.com>>
>>> To: "OpenStack Development Mailing List \(not for usage questions\)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Subject: Re: [openstack-dev] heat run_tests.sh fails with one huge
>>> line of output
>>> Message-ID:
>>>
>>> <OF81356D12.13A4D038-ON85257C81.0073FA5A-85257C81.00754456 at us.ibm.com
>>> <mailto:OF81356D12.13A4D038-ON85257C81.0073FA5A-85257C81.00754456 at us.ibm.com>>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> Kevin, I changed no code, it was a fresh DevStack install.
>>>
>>> Robert Collins <robertc at robertcollins.net
>>> <mailto:robertc at robertcollins.net>> wrote on 02/16/2014 05:33:59
>>> AM:
>>> > A) [fixed in testrepository trunk] the output from subunit.run
>>> > discover .... --list is being shown verbatim when an error
>>> happens,
>>> > rather than being machine processed and the test listings elided.
>>> >
>>> > To use trunk - in your venv:
>>> > bzr branch lp:testrepository
>>> > pip install testrepository
>>> >
>>> > B) If you look at the end of that wall of text you'll see 'Failed
>>> > imports' in there, and the names after that are modules that
>>> failed
>>> > to import - for each of those if you try to import it in python,
>>> > you'll find the cause, and there's likely just one cause.
>>>
>>> Thanks Robert, I tried following your leads but got nowhere,
>>> perhaps I
>>> need a few more clues.
>>>
>>> I am not familiar with bzr (nor baz), and it wasn't obvious to
>>> me how to
>>> fit that into my workflow --- which was:
>>> (1) install DevStack
>>> (2) install libmysqlclient-dev
>>> (3) install flake8
>>> (4) cd /opt/stack/heat
>>> (5) ./run_tests.sh
>>>
>>> I guessed that your (A) would apply if I use a venv and go
>>> between (1) the
>>> `python tools/install_venv.py` inside run_tests.sh and (2) the
>>> invocation
>>> inside run_tests.sh of its run_tests function. So I manually
>>> invoked
>>> `python tools/install_venv.py`, then entered that venv, then
>>> issued your
>>> commands of (A) (discovered I needed to install bzr and did so),
>>> then
>>> exited that venv, then invoked heat's `run_tests -V -u` to use
>>> the venv
>>> thus constructed. It still produced one huge line of output.
>>> Here I
>>> attach a typescript of that:
>>>
>>>
>>>
>>> You will see that the huge line still ends with something about
>>> import
>>> error, and now lists one additional package ---
>>> heat.tests.test_neutron_firewalld. I then tried your (B),
>>> testing manual
>>> imports. All worked except for the last, which failed because
>>> there is
>>> indeed no such thing (why is there a spurrious 'd' at the end of the
>>> package name?). Here is a typescript of that:
>>>
>>>
>>>
>>> Thanks,
>>> Mike
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/2f7188ae/attachment.html>
>>> -------------- next part --------------
>>> An embedded and charset-unspecified text was scrubbed...
>>> Name: testlog.txt
>>> URL:
>>> <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/2f7188ae/attachment.txt>
>>> -------------- next part --------------
>>> An embedded and charset-unspecified text was scrubbed...
>>> Name: testlog2.txt
>>> URL:
>>> <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/2f7188ae/attachment-0001.txt>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> End of OpenStack-dev Digest, Vol 22, Issue 45
>>> *********************************************
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> --
>>> ------------------------------------------
>>> Telles Mota Vidal Nobrega
>>> Bsc in Computer Science at UFCG
>>> Software Engineer at PulsarOpenStack Project - HP/LSD-UFCG
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140219/1d957f45/attachment-0001.html>
More information about the OpenStack-dev
mailing list