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