[openstack-dev] Hierarchicical Multitenancy Discussion
Telles Nobrega
tellesnobrega at gmail.com
Tue Feb 18 17:53:08 UTC 2014
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",
"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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140218/96968ac3/attachment-0001.html>
More information about the OpenStack-dev
mailing list