Open Stack

Vish, I tried making the repo a little better.
Here it is:
https://github.com/tellesnobrega/nova/tree/multitenancy
https://github.com/tellesnobrega/keystone/tree/hierarchical_projects
https://github.com/tellesnobrega/devstack/tree/multitenancy
https://github.com/tellesnobrega/python-keystoneclient/tree/multitenancy

Hope to hear from you soon.



On Fri, Mar 7, 2014 at 3:22 PM, Raildo Mascena <raildom at gmail.com> wrote:

> Hello,
>
> First, I realized that there was no meeting today, was there a problem, or
> change in schedule?
>
> I would like to know if anyone has tested/Reviewed on the prototype that
> we implemented Telles and I, what did you think? I would like to know if
> there is any other functionality that can help.
>
> Thank you in advance.
>
>
> 2014-02-26 1:14 GMT-03:00 Adam Young <ayoung at redhat.com>:
>
>>  On 02/20/2014 05:18 PM, Vishvananda Ishaya wrote:
>>
>>
>>  On Feb 19, 2014, at 5:58 PM, Adam Young <ayoung at redhat.com> wrote:
>>
>>  On 02/18/2014 02:28 PM, Vishvananda Ishaya wrote:
>>
>>
>>  On Feb 18, 2014, at 11:04 AM, Adam Young <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.
>>
>>
>>  The issue is that we are storing the hierarchy of ownership in nova. We
>> can either store the hierarchy by id or by name. Note that we are not
>> adding a new field for this hierarchy but using the existing ownership
>> field (which is called project_id in nova). My point is that if we use ids,
>> then this field would be backwards compatible. If we decide to use name
>> instead (which has some advantages for display purposes), then we would
>> need some kind of db sync migration which modifies all of the fields from
>> id -> 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'.
>>
>>
>>  As I mention above, all of this makes sense inside of keystone, but
>> doesn't address the problem of how we are storing the hierarchy on the nova
>> side. The owner field in nova can be:
>>
>>  1) abcd1234.fedd3213.3e3e3e3e
>>
>>  or it can be:
>>
>>  2) orga.proja.suba
>>
>>
>> Owner should be separate from project.  But that is an aside.  I think
>> you are mixing two ideas together.  Lets sit down at the summit to clear
>> this up, but the Ids should not be hierarchical, the names should, and if
>> you mess with that, it is going to be, well, a mess....
>>
>> We have a lot going on getting ready for Icehouse 3, and I don't want to
>> be rushed on this, as we will have to live with it for a long time.  Nova
>> is not the only consumer of projects, and we need to make something that
>> works across the board.
>>
>>
>>
>>  To explicitly state the tradeoffs
>>
>>  1 is backwards compatible +
>>
>> We are actually doing something like this for domain users:  userid@@domainid
>> where both are UUIDs (or possible userid comes out of ldap) but the
>> hierarchy there is only two level.  It is necessary there because one part
>> is assigned by keysotne (domain id) and one part by LDAP or the remote IdP.
>>
>> 1 doesn't need to be updated if a project is renamed +
>>
>> But it does need to be redone of the project gets moved in the hierarchy,
>> and we have a pre-existing feature request for that.
>>
>>  1 is not user friendly (need to map ids to names to display to the
>> user) -
>>
>> You need to walk the tree to generate the "good" name.  But that can also
>> be used to navigate.  Path names like URLs are unsurprising.  Hieriarch IDs
>> are not.
>>
>>
>>  both need to be updated if a project is moved in the hierarchy
>>
>> Notif the project only knows its local name.
>>
>> Owner can continue to be the short id.  You onlky need to map to
>> translate for readability.  Its like SQL:  use a view to denormalize.
>>
>>
>>  Vish
>>
>>
>>
>>  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> 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 [
>>> openstack-dev-request at lists.openstack.org]
>>> Sent: 16 February 2014 22:21
>>> To: 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
>>>
>>> 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
>>>
>>> You can reach the person managing the list at
>>>         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>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>         <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>
>>> 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>>
>>> 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
>>> -------------- 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>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>         <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>
>>> 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>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>         <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>
>>> 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>:
>>>
>>> > 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>
>>> > Reply-To: "OpenStack Development Mailing List (not for usage
>>> questions)" <
>>> > 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>
>>> > 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
>>> > 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>
>>> To: "OpenStack Development Mailing List \(not for usage questions\)"
>>>         <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>
>>> 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>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>         <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>
>>> 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>:
>>>
>>> > Thanks Gary, clear now. ;-)
>>> >
>>> >
>>> > 2014-02-16 21:40 GMT+08:00 Gary Kotton <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>
>>> >> Reply-To: "OpenStack Development Mailing List (not for usage
>>> questions)"
>>> >> <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
>>> >> >
>>> >> 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
>>> >> 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>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>         <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>
>>> 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> 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> 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
>>> > > 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
>>> >
>>>
>>> _______________________________________________
>>> 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/20140216/9258cf27/attachment-0001.html
>>> >
>>>
>>> ------------------------------
>>>
>>> Message: 7
>>> Date: Sun, 16 Feb 2014 08:47:19 -0800
>>> From: Harshad Nakil <hnakil at contrailsystems.com>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>         <openstack-dev at lists.openstack.org>
>>>  Subject: Re: [openstack-dev] VPC Proposal
>>> Message-ID:
>>>         <
>>> 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>
>>> 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>
>>> > 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
>>> > 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>
>>> To: Harshad Nakil <hnakil at contrailsystems.com>
>>> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
>>>         <openstack-dev at lists.openstack.org>
>>> Subject: Re: [openstack-dev] VPC Proposal
>>> Message-ID: <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>
>>> To: "Allamaraju, Subbu" <subbu at subbu.org>
>>> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
>>>         <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>
>>> 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>
>>> To: "OpenStack Development Mailing List \(not for usage questions\)"
>>>         <openstack-dev at lists.openstack.org>
>>> Subject: Re: [openstack-dev] VPC Proposal
>>> Message-ID: <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>
>>> 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
>>> > 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>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>         <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>
>>> 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>
>>> 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>
>>> 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> 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> 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
>>> >> > 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
>>> >>
>>> >> _______________________________________________
>>> >> 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
>>> > 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>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>         <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>
>>> 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> 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>
>>> 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> 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>
>>> 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
>>> >>>> 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
>>> >>>
>>> >>> _______________________________________________
>>> >>> 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
>>> >> 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
>>>
>>>
>>>
>>>  ------------------------------
>>>
>>> Message: 13
>>> Date: Sun, 16 Feb 2014 10:31:42 -0800
>>> From: "Allamaraju, Subbu" <subbu at subbu.org>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>         <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>
>>> 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>
>>> 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>
>>> To: Sean Dague <sean at dague.net>
>>> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
>>>         <openstack-dev at lists.openstack.org>,
>>>         "<openstack-infra at lists.openstack.org>"
>>>         <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>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> On 15 February 2014 09:58, Sean Dague <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>
>>> Distinguished Technologist
>>> HP Converged Cloud
>>>
>>>
>>>
>>> ------------------------------
>>>
>>>  Message: 15
>>> Date: Mon, 17 Feb 2014 08:25:04 +1300
>>> From: Robert Collins <robertc at robertcollins.net>
>>> To: "James E. Blair" <jeblair at openstack.org>
>>> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
>>>         <openstack-dev at lists.openstack.org>,
>>>         "<openstack-infra at lists.openstack.org>"
>>>         <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>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> On 15 February 2014 12:21, James E. Blair <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>
>>> Distinguished Technologist
>>> HP Converged Cloud
>>>
>>>
>>>
>>> ------------------------------
>>>
>>>  Message: 16
>>> Date: Sun, 16 Feb 2014 11:38:57 -0800
>>> From: Ravi Chunduru <ravivsn at gmail.com>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>         <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>
>>> 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>
>>> 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>
>>> > 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
>>> > 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>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>         <openstack-dev at lists.openstack.org>
>>>  Subject: Re: [openstack-dev] VPC Proposal
>>> Message-ID:
>>>         <
>>> 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>wrote:
>>>
>>> > Comments Inline
>>> >
>>> > Regards
>>> > -Harshad
>>> >
>>> >
>>> > On Sat, Feb 15, 2014 at 11:39 PM, Allamaraju, Subbu <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>
>>> >> 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
>>> >> 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
>>> >
>>> >
>>>
>>>
>>>  --
>>> 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>
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>         <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>
>>> Content-Type: text/plain; charset="windows-1252"
>>>
>>>
>>> On Feb 15, 2014, at 4:36 AM, Vinod Kumar Boppanna <
>>> 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>
>>> > To: "OpenStack Development Mailing List (not for usage questions)"
>>> >        <openstack-dev at lists.openstack.org>
>>>  > Subject: Re: [openstack-dev] Hierarchicical Multitenancy Discussion
>>>  > Message-ID: <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
>>> > 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>
>>> To: "OpenStack Development Mailing List \(not for usage questions\)"
>>>         <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>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> Kevin, I changed no code, it was a fresh DevStack install.
>>>
>>> Robert Collins <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
>>> 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
>>> 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 listOpenStack-dev at lists.openstack.orghttp://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
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://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
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://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
>>
>>
>
>
> --
> Raildo Mascena
> Bacharel em Ciência da Computação - UFCG
> Desenvolvedor no Laboratório de Sistemas Distribuidos - UFCG
>
> _______________________________________________
> OpenStack-dev mailing list
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140314/c767d387/attachment.html>