Re: [openstack-dev] [openstack-infra] [CI] [tempest] Tempest tests failing with SSH timeout.

[Abhishek Shrivastava]

Hi Ramy,

Thanks for the suggestion but since I am not including the neutron project,
so downloading and including it will require any additional configuration
in devstack-gate or not?

On Sat, Jul 18, 2015 at 11:41 PM, Asselin, Ramy  wrote:

>  We ran into this issue as well. I never found the root cause, but I
> found a work-around: Use neutron-networking instead of the default
> nova-networking.
>
>
>
> If you’re using devstack-gate, it’s as  simple as:
>
> export DEVSTACK_GATE_NEUTRON=1
>
>
>
> Then run the job as usual.
>
>
>
> Ramy
>
>
>
> *From:* Abhishek Shrivastava [mailto:abhis...@cloudbyte.com]
> *Sent:* Friday, July 17, 2015 9:15 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [openstack-infra] [CI] [tempest] Tempest tests
> failing with SSH timeout.
>
>
>
> Hi Folks,
>
>
>
> In my CI I see the following tempest tests failure for a past couple of
> days.
>
> ·
> tempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario
>  [361.274316s] ... FAILED
>
> ·
> tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
>  [320.122458s] ... FAILED
>
> ·
> tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern
>  [317.399342s] ... FAILED
>
> ·
> tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_compute_with_volumes
>  [257.858272s] ... FAILED
>
>  The failure logs are always the same every time, i.e;
>
>
>
>  *03:34:09* 2015-07-17 03:21:13,256 9505 ERROR
> [tempest.scenario.manager] (TestVolumeBootPattern:test_volume_boot_pattern) 
> Initializing SSH connection to 172.24.5.1 failed. Error: Connection to the 
> 172.24.5.1 via SSH timed out.
>
> *03:34:09* User: cirros, Password: None
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
> Traceback (most recent call last):
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   
> File "tempest/scenario/manager.py", line 312, in get_remote_client
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager
>  linux_client.validate_authentication()
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   
> File "tempest/common/utils/linux/remote_client.py", line 62, in 
> validate_authentication
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager
>  self.ssh_client.test_connection_auth()
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   
> File 
> "/opt/stack/new/tempest/.tox/all/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
>  line 151, in test_connection_auth
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager
>  connection = self._get_ssh_connection()
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   
> File 
> "/opt/stack/new/tempest/.tox/all/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
>  line 87, in _get_ssh_connection
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager
>  password=self.password)
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
> SSHTimeout: Connection to the 172.24.5.1 via SSH timed out.
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
> User: cirros, Password: None
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager
>
> *03:34:09* 2015-07-17 03:21:14,377 9505 INFO [tempest_lib.common.re
>
>
>
> Because of these every job is failing, so if someone can help me regarding 
> this please do reply.
>
>
>
> --
>
>   *Thanks & Regards,*
>
> *Abhishek*
>
> *Cloudbyte Inc. *
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 


*Thanks & Regards,*
*Abhishek*
*Cloudbyte Inc. *
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] 'routed' network type, DHCP agent + devstack support - review requested

[Neil Jerram]

Hi Neutron folk!

I'd like to give an update on and encourage wide review of my work on
a type of network that connects VMs through IP routing instead of
through bridging and tunneling at L2.  I believe the core Neutron
pieces of this are now complete and ready for detailed review and
potential merging.

The change at [1] creates and describes a new 'routed' value for
provider:network_type.  It means that a compute host handles data
to/from the relevant TAP interfaces by routing it, and specifically
that those TAP interfaces are not bridged.  It is the job of a
particular mechanism driver and agent implementation to set up the
required routing rules, and my team's Calico project [2] is one
example of that, although not the only possible example.

The DHCP agent needs enhancement to provide DHCP service to routed TAP
interfaces, and the change for that is at [3].

A devstack plugin is included in the Calico repository at [4]. Using
this it is possible to see 'routed' networking in action, using the
Calico mechanism driver and agent, simply by running devstack with the
following in local.conf:

  enable_plugin calico https://github.com/Metaswitch/calico routed

Demonstration steps once stack.sh completes are suggested at [5].

[1] https://review.openstack.org/#/c/198439/
[2] http://projectcalico.org/
[3] https://review.openstack.org/#/c/197578/
[4] https://github.com/Metaswitch/calico/tree/routed
[5] https://github.com/Metaswitch/calico/blob/routed/devstack/README.rst

FYI I also plan to propose a networking-calico project (or continue
proposing, given [6]), to contain the Calico mechanism driver and
devstack plugin pieces that are currently in [4], so that all of
Calico's OpenStack-specific code is under the Neutron big tent.  But I
believe that can be decoupled from review of the core Neutron changes
proposed above.

[6] https://review.openstack.org/#/c/194709/

Please do let me know if you have thoughts or comments on this.

Many thanks,
 Neil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper

[Peng Zhao]

Thanks Jay.


Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I 
just think bay isn't a must in this case, and we don't need nova to provision 
BM hosts, which makes things more complicated imo.


Peng
 


-- Original --
From:  "Jay Lau";
Date:  Sun, Jul 19, 2015 10:36 AM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper

 
Hong Bin,


I have some online discussion with Peng, seems hyper is now integrating with 
Kubernetes and also have plan integrate with mesos for scheduling. Once mesos 
integration finished, we can treat mesos+hyper as another kind of bay.


Thanks


2015-07-19 4:15 GMT+08:00 Hongbin Lu :
   
Peng,
 
 
 
Several questions Here. You mentioned that HyperStack is a single big “bay”. 
Then, who is doing the multi-host scheduling, Hyper or something else? Were you 
 suggesting to integrate Hyper with Magnum directly? Or you were suggesting to 
integrate Hyper with Magnum indirectly (i.e. through k8s, mesos and/or Nova)?
 
 
 
Best regards,
 
Hongbin
 
 
  
From: Peng Zhao [mailto:p...@hyper.sh] 
 Sent: July-17-15 12:34 PM
 To: OpenStack Development Mailing List (not for usage questions)
 
Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal with 
Hyper



 
 
 
  
Hi, Adrian, Jay and all,
 
  
 
 
  
There could be a much longer version of this, but let me try to explain in a 
minimalist way.
 
  
 
 
  
Bay currently has two modes: VM-based, BM-based. In both cases, Bay helps to 
isolate different tenants' containers. In other words, bay is single-tenancy. 
For BM-based bay, the single tenancy is a worthy tradeoff, given the 
performance  merits of LXC vs VM. However, for a VM-based bay, there is no 
performance gain, but single tenancy seems a must, due to the lack of isolation 
in container. Hyper, as a hypervisor-based substitute for container, brings the 
much-needed isolation, and therefore  enables multi-tenancy. In HyperStack, we 
don't really need Ironic to provision multiple Hyper bays. On the other hand,  
the entire HyperStack cluster is a single big "bay". Pretty similar to how Nova 
works.
 
  
 
 
  
Also, HyperStack is able to leverage Cinder, Neutron for SDS/SDN functionality. 
So when someone submits a Docker Compose app, HyperStack would launch HyperVMs 
and call Cinder/Neutron to setup the volumes and network. The architecture is  
quite simple.
 
  
 
 
  
Here are a blog I'd like to recommend: 
https://hyper.sh/blog/post/2015/06/29/docker-hyper-and-the-end-of-guest-os.html
 
 

  
 
 
  
Let me know your questions.
 
  
 
 
  
Thanks,
 
  
Peng
 
  
 
 
 

  
-- Original --
 
   
From:  "Adrian Otto";
 
  
Date:  Thu, Jul 16, 2015 11:02 PM
 
  
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 
 
  
Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetalwith Hyper
 
 
  
 
 
 
Jay, 
  
 
 
  
Hyper is a substitute for a Docker host, so I expect it could work equally well 
for all of the current bay types. Hyper’s idea of a “pod” and a Kubernetes 
“pod” are similar, but different. I’m not yet convinced  that integrating Hyper 
host creation direct with Magnum (and completely bypassing nova) is a good 
idea. It probably makes more sense to implement use nova with the ironic dirt 
driver to provision Hyper hosts so we can use those as substitutes for Bay 
nodes  in our various Bay types. This would fit in the place were we use Fedora 
Atomic today. We could still rely on nova to do all of the machine instance 
management and accounting like we do today, but produce bays that use Hyper 
instead of a Docker host. Everywhere  we currently offer CoreOS as an option we 
could also offer Hyper as an alternative, with some caveats. 
 
  
 
 
  
There may be some caveats/drawbacks to consider before committing to a Hyper 
integration. I’ll be asking those of Peng also on this thread, so keep an eye 
out.
 
  
 
 
  
Thanks,
 
  
 
 
  
Adrian
 
 

 
 

On Jul 16, 2015, at 3:23 AM, Jay Lau  wrote:
 
 
 
 

 
Thanks Peng, then I can see two integration points for Magnum and Hyper:
 
 
1) Once Hyper and k8s integration finished, we can deploy k8s in two mode: 
docker and hyper mode, the end user can select which mode they want to use. For 
such case, we do not need  to create a new bay but may need some enhancement 
for current k8s bay
 
 
2) After mesos and hyper integration,  we can treat mesos and hyper as a new 
bay to magnum. Just like what we are doing now for mesos+marathon.
 
 
Thanks!
 
 

 
 
  
2015-07-16 17:38 GMT+08:00 Peng Zhao :
 

  
Hi Jay,
 
  
 
 
  
Yes, we are working with the community to integrate Hyper with Mesos and K8S. 
Since Hyper uses Pod as the default job unit, it is quite easy to integrate  
with K8S. Mesos takes a bit more efforts, but still straightforward.
 
  
 
 
  
We expect to finish both i

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper

[Peng Zhao]

Hi Jay,


My idea is that if someone wants an IaaS solution, go Nova+Cinder+Neutron. For 
private CaaS solution, K8S/Mesos+Cinder+Neutron(libnetwork?)+Docker, for public 
CaaS, go K8S/Mesos+Cinder+Neutron+Hyper.


By doing this, we could clearly deliver the message to the community and 
market. What you suggested is more of a hybrid cluster. It is of course a valid 
case, though I think it should be a more advanced stage. 


Currently, most CaaS are deployed on some IaaS, and viewed by many as an 
extension of IaaS. With HyperStack, we could redefine the cloud by introducing 
a native, secure, multi-tenant CaaS. And all of these can be done in the 
OpenStack framework. 


Best,
Peng
 
-- Original --
From:  "Jay Lau";
Date:  Sun, Jul 19, 2015 10:32 AM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper

 
Hi Peng,


Please check some of my understandings in line.


Thanks


2015-07-18 0:33 GMT+08:00 Peng Zhao :
Hi, Adrian, Jay and all,


There could be a much longer version of this, but let me try to explain in a 
minimalist way.


Bay currently has two modes: VM-based, BM-based. In both cases, Bay helps to 
isolate different tenants' containers. In other words, bay is single-tenancy. 
For BM-based bay, the single tenancy is a worthy tradeoff, given the 
performance merits of LXC vs VM. However, for a VM-based bay, there is no 
performance gain, but single tenancy seems a must, due to the lack of isolation 
in container. Hyper, as a hypervisor-based substitute for container, brings the 
much-needed isolation, and therefore enables multi-tenancy. In HyperStack, we 
don't really need Ironic to provision multiple Hyper bays. On the other hand,  
the entire HyperStack cluster is a single big "bay". Pretty similar to how Nova 
works.
IMHO, only creating one big bay might not fit into Magnum user scenario well, 
what you mentioned that put the entire HyperStack as a single big bay is more 
like a public cloud case. But for some private cloud  cases, there are 
different users and tenants, and different  tenants might want to set up their 
own HyperStack bay on their own resources.



Also, HyperStack is able to leverage Cinder, Neutron for SDS/SDN functionality. 
So when someone submits a Docker Compose app, HyperStack would launch HyperVMs 
and call Cinder/Neutron to setup the volumes and network. The architecture is 
quite simple. 

This is cool! 



Here are a blog I'd like to recommend: 
https://hyper.sh/blog/post/2015/06/29/docker-hyper-and-the-end-of-guest-os.html
 
Let me know your questions.


Thanks,
Peng


-- Original --
From:  "Adrian Otto";
Date:  Thu, Jul 16, 2015 11:02 PM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetalwith  
Hyper



 
 Jay, 
 
 Hyper is a substitute for a Docker host, so I expect it could work equally 
well for all of the current bay types. Hyper’s idea of a “pod” and a Kubernetes 
“pod” are similar, but different. I’m not yet convinced that integrating Hyper 
host creation  direct with Magnum (and completely bypassing nova) is a good 
idea. It probably makes more sense to implement use nova with the ironic dirt 
driver to provision Hyper hosts so we can use those as substitutes for Bay 
nodes in our various Bay types. This would  fit in the place were we use Fedora 
Atomic today. We could still rely on nova to do all of the machine instance 
management and accounting like we do today, but produce bays that use Hyper 
instead of a Docker host. Everywhere we currently offer CoreOS as an  option we 
could also offer Hyper as an alternative, with some caveats. 
 
 
 There may be some caveats/drawbacks to consider before committing to a Hyper 
integration. I’ll be asking those of Peng also on this thread, so keep an eye 
out.
 
 
 Thanks,
 
 
 Adrian
 
   On Jul 16, 2015, at 3:23 AM, Jay Lau  wrote:
 
 Thanks Peng, then I can see two integration points for Magnum and Hyper:
 
 
 1) Once Hyper and k8s integration finished, we can deploy k8s in two mode: 
docker and hyper mode, the end user can select which mode they want to use. For 
such case, we do not need to create a new bay but may need some enhancement for 
current k8s bay
 
 
 2) After mesos and hyper integration,  we can treat mesos and hyper as a new 
bay to magnum. Just like what we are doing now for mesos+marathon.
 
 
 Thanks!
 
 
 2015-07-16 17:38 GMT+08:00 Peng Zhao  :
Hi Jay,
 
 
 Yes, we are working with the community to integrate Hyper with Mesos and K8S. 
Since Hyper uses Pod as the default job unit, it is quite easy to integrate 
with K8S. Mesos takes a bit more efforts, but still straightforward.
 
 
 We expect to finish both integration in v0.4 early August.
 
 
 Best,
  Peng
 
 
   -
 Hyper 

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper

[Adrian Otto]

Peng,

You are not the first to think this way, and it's one of the reasons we did not 
integrate Containers with OpenStack in a meaningful way a full year earlier. 
Please pay attention closely.

1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 
1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will 
get killed. Operators matter.

2) Cloud Operators need a consistent way to bill for the IaaS services the 
provide. Nova emits all of the RPC messages needed to do this. Having a second 
nova that does this slightly differently is a really annoying problem that will 
make Operators hate the software. It's better to use nova, have things work 
consistently, and plug in virt drivers to it.

3) Creation of a host is only part of the problem. That's the easy part. Nova 
also does a bunch of other things too. For example, say you want to live 
migrate a guest from one host to another. There is already functionality in 
Nova for doing that.

4) Resources need to be capacity managed. We call this scheduling. Nova has a 
pluggable scheduler to help with the placement of guests on hosts. Magnum will 
not.

5) Hosts in a cloud need to integrate with a number of other services, such as 
an image service, messaging, networking, storage, etc. If you only think in 
terms of host creation, and do something without nova, then you need to 
re-integrate with all of these things.

Now, I probably left out examples of lots of other things that Nova does. What 
I have mentioned us enough to make my point that there are a lot of things that 
Magnum is intentionally NOT doing that we expect to get from Nova, and I will 
block all code that gratuitously duplicates functionality that I believe 
belongs in Nova. I promised our community I would not duplicate existing 
functionality without a very good reason, and I will keep that promise.

Let's find a good way to fit Hyper with OpenStack in a way that best leverages 
what exists today, and is least likely to be rejected. Please note that the 
proposal needs to be changed from where it is today to achieve this fit.

My fist suggestion is to find a way to make a nova virt driver for Hyper, which 
could allow it to be used with all of our current Bay types in Magnum.

Thanks,

Adrian


 Original message 
From: Peng Zhao 
Date: 07/19/2015 5:36 AM (GMT-08:00)
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper

Thanks Jay.

Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I 
just think bay isn't a must in this case, and we don't need nova to provision 
BM hosts, which makes things more complicated imo.

Peng


-- Original --
From:  "Jay Lau";
Date:  Sun, Jul 19, 2015 10:36 AM
To:  "OpenStack Development Mailing List (not for usage 
questions)";
Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper

Hong Bin,

I have some online discussion with Peng, seems hyper is now integrating with 
Kubernetes and also have plan integrate with mesos for scheduling. Once mesos 
integration finished, we can treat mesos+hyper as another kind of bay.

Thanks

2015-07-19 4:15 GMT+08:00 Hongbin Lu 
mailto:hongbin...@huawei.com>>:
Peng,

Several questions Here. You mentioned that HyperStack is a single big “bay”. 
Then, who is doing the multi-host scheduling, Hyper or something else? Were you 
suggesting to integrate Hyper with Magnum directly? Or you were suggesting to 
integrate Hyper with Magnum indirectly (i.e. through k8s, mesos and/or Nova)?

Best regards,
Hongbin

From: Peng Zhao [mailto:p...@hyper.sh]
Sent: July-17-15 12:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal with 
Hyper

Hi, Adrian, Jay and all,

There could be a much longer version of this, but let me try to explain in a 
minimalist way.

Bay currently has two modes: VM-based, BM-based. In both cases, Bay helps to 
isolate different tenants' containers. In other words, bay is single-tenancy. 
For BM-based bay, the single tenancy is a worthy tradeoff, given the 
performance merits of LXC vs VM. However, for a VM-based bay, there is no 
performance gain, but single tenancy seems a must, due to the lack of isolation 
in container. Hyper, as a hypervisor-based substitute for container, brings the 
much-needed isolation, and therefore enables multi-tenancy. In HyperStack, we 
don't really need Ironic to provision multiple Hyper bays. On the other hand,  
the entire HyperStack cluster is a single big "bay". Pretty similar to how Nova 
works.

Also, HyperStack is able to leverage Cinder, Neutron for SDS/SDN functionality. 
So when someone submits a Docker Compose app, HyperStack would launch HyperVMs 
and call Cinder/Neutron to setup the volumes and network. The architecture is 
quite simp

Re: [openstack-dev] [openstack-infra] [CI] [tempest] Tempest tests failing with SSH timeout.

[Asselin, Ramy]

Just the export I mentioned:
export DEVSTACK_GATE_NEUTRON=1
Devstack-gate scripts will do the right thing when it sees that set. You can 
see plenty of examples here [1].

Ramy

[1] 
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/devstack-gate.yaml#n467

From: Abhishek Shrivastava [mailto:abhis...@cloudbyte.com]
Sent: Sunday, July 19, 2015 2:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [openstack-infra] [CI] [tempest] Tempest tests 
failing with SSH timeout.

Hi Ramy,

Thanks for the suggestion but since I am not including the neutron project, so 
downloading and including it will require any additional configuration in 
devstack-gate or not?

On Sat, Jul 18, 2015 at 11:41 PM, Asselin, Ramy 
mailto:ramy.asse...@hp.com>> wrote:
We ran into this issue as well. I never found the root cause, but I found a 
work-around: Use neutron-networking instead of the default nova-networking.

If you’re using devstack-gate, it’s as  simple as:
export DEVSTACK_GATE_NEUTRON=1

Then run the job as usual.

Ramy

From: Abhishek Shrivastava 
[mailto:abhis...@cloudbyte.com]
Sent: Friday, July 17, 2015 9:15 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [openstack-infra] [CI] [tempest] Tempest tests failing 
with SSH timeout.

Hi Folks,

In my CI I see the following tempest tests failure for a past couple of days.

•
tempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario
 [361.274316s] ... FAILED

•
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
 [320.122458s] ... FAILED

•
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern
 [317.399342s] ... FAILED

•
tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_compute_with_volumes
 [257.858272s] ... FAILED

The failure logs are always the same every time, i.e;



03:34:09 2015-07-17 03:21:13,256 9505 ERROR[tempest.scenario.manager] 
(TestVolumeBootPattern:test_volume_boot_pattern) Initializing SSH connection to 
172.24.5.1 failed. Error: Connection to the 172.24.5.1 via SSH timed out.

03:34:09 User: cirros, Password: None

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
Traceback (most recent call last):

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   File 
"tempest/scenario/manager.py", line 312, in get_remote_client

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
linux_client.validate_authentication()

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   File 
"tempest/common/utils/linux/remote_client.py", line 62, in 
validate_authentication

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
self.ssh_client.test_connection_auth()

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   File 
"/opt/stack/new/tempest/.tox/all/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
 line 151, in test_connection_auth

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
connection = self._get_ssh_connection()

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   File 
"/opt/stack/new/tempest/.tox/all/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
 line 87, in _get_ssh_connection

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
password=self.password)

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
SSHTimeout: Connection to the 172.24.5.1 via SSH timed out.

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager User: 
cirros, Password: None

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager

03:34:09 2015-07-17 03:21:14,377 9505 INFO 
[tempest_lib.common.re



Because of these every job is failing, so if someone can help me regarding this 
please do reply.

--
[https://docs.google.com/uc?export=download&id=0Byq0j7ZjFlFKV3ZCWnlMRXBCcU0&revid=0Byq0j7ZjFlFKa2V5VjdBSjIwUGx6bUROS2IrenNwc0kzd2IwPQ]
Thanks & Regards,
Abhishek
Cloudbyte Inc.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
[https://docs.google.com/uc?export=download&id=0Byq0j7ZjFlFKV3ZCWnlMRXBCcU0&revid=0Byq0j7ZjFlFKa2V5VjdBSjIwUGx6bUROS2IrenNwc0kzd2IwPQ]
Thanks & Regards,
Abhishek
Cloudbyte Inc.
__
OpenStack Development M

Re: [openstack-dev] [openstack-infra] [CI] [tempest] Tempest tests failing with SSH timeout.

[Abhishek Shrivastava]

Hi Ramy,

Thanks for the suggestion. One more thing I need to ask, as I have have
setup one more CI so is there any way that we can decide that only required
projects should get downloaded and installed during devstack installation
dynamically. As I see no such things that can be done to devstack-gate
scripts so the following scenario can be achieved.

On Sun, Jul 19, 2015 at 8:38 PM, Asselin, Ramy  wrote:

>  Just the export I mentioned:
>
> export DEVSTACK_GATE_NEUTRON=1
>
> Devstack-gate scripts will do the right thing when it sees that set. You
> can see plenty of examples here [1].
>
>
>
> Ramy
>
>
>
> [1]
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/devstack-gate.yaml#n467
>
>
>
> *From:* Abhishek Shrivastava [mailto:abhis...@cloudbyte.com]
> *Sent:* Sunday, July 19, 2015 2:24 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [openstack-infra] [CI] [tempest] Tempest
> tests failing with SSH timeout.
>
>
>
> Hi Ramy,
>
>
>
> Thanks for the suggestion but since I am not including the neutron
> project, so downloading and including it will require any additional
> configuration in devstack-gate or not?
>
>
>
> On Sat, Jul 18, 2015 at 11:41 PM, Asselin, Ramy 
> wrote:
>
>  We ran into this issue as well. I never found the root cause, but I
> found a work-around: Use neutron-networking instead of the default
> nova-networking.
>
>
>
> If you’re using devstack-gate, it’s as  simple as:
>
> export DEVSTACK_GATE_NEUTRON=1
>
>
>
> Then run the job as usual.
>
>
>
> Ramy
>
>
>
> *From:* Abhishek Shrivastava [mailto:abhis...@cloudbyte.com]
> *Sent:* Friday, July 17, 2015 9:15 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [openstack-infra] [CI] [tempest] Tempest tests
> failing with SSH timeout.
>
>
>
> Hi Folks,
>
>
>
> In my CI I see the following tempest tests failure for a past couple of
> days.
>
> ·
> tempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario
>  [361.274316s] ... FAILED
>
> ·
> tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
>  [320.122458s] ... FAILED
>
> ·
> tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern
>  [317.399342s] ... FAILED
>
> ·
> tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_compute_with_volumes
>  [257.858272s] ... FAILED
>
>  The failure logs are always the same every time, i.e;
>
>
>
>  *03:34:09* 2015-07-17 03:21:13,256 9505 ERROR
> [tempest.scenario.manager] (TestVolumeBootPattern:test_volume_boot_pattern) 
> Initializing SSH connection to 172.24.5.1 failed. Error: Connection to the 
> 172.24.5.1 via SSH timed out.
>
> *03:34:09* User: cirros, Password: None
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
> Traceback (most recent call last):
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   
> File "tempest/scenario/manager.py", line 312, in get_remote_client
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager
>  linux_client.validate_authentication()
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   
> File "tempest/common/utils/linux/remote_client.py", line 62, in 
> validate_authentication
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager
>  self.ssh_client.test_connection_auth()
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   
> File 
> "/opt/stack/new/tempest/.tox/all/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
>  line 151, in test_connection_auth
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager
>  connection = self._get_ssh_connection()
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   
> File 
> "/opt/stack/new/tempest/.tox/all/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
>  line 87, in _get_ssh_connection
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager
>  password=self.password)
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
> SSHTimeout: Connection to the 172.24.5.1 via SSH timed out.
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
> User: cirros, Password: None
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager
>
> *03:34:09* 2015-07-17 03:21:14,377 9505 INFO [tempest_lib.common.re
>
>
>
> Because of these every job is failing, so if someone can help me regarding 
> this please do reply.
>
>
>
> --
>
>   *Thanks & Regards,*
>
> *Abhishek*
>
> *Cloudbyte Inc. *
>
>
> __
> OpenStack Development Mailing List (not for usage question

Re: [openstack-dev] [tc][all] Tags, explain like I am five?

[Jay Pipes]

On 07/15/2015 03:27 PM, John Griffith wrote:

It's relatively limited right now I think, and part of the reason for
that is we've tried to ensure that the information that we put on tags
is subjective


I think you mean "objective" here, and throughout this, not 
"subjective". We try as much as possible for the tag definitions to have 
a clear list of requirements -- preferably driven by some data source 
like a script that queries stackalytics -- that can be used in applying 
the tag to a project.


>, and at the same time doesn't give any false impression

that something is "good" or "bad".  We just wanted to have tags to
easily convey some general information about a project to help people
gain at least a little insight into a project, how it's managed, what
sort of community is contributing to it etc.

As we move into things like the "compute starter kit" it gets a bit less
subjective, but not really too much.


It got a bit *more* subjective, not less subjective :) Or perhaps you 
meant "prescriptive"?


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Exposing provider networks in network_data.json

[Jim Rollenhagen]

On Sat, Jul 18, 2015 at 08:39:23PM +0800, Sam Stoelinga wrote:
> +1 on Kevin Benton's comments.
> Ironic should have integration with switches where the switches are SDN
> compatible. The individual bare metal node should not care which vlan,
> vxlan or other translation is programmed at the switch. The individual bare
> metal nodes just knows I have 2 nics and and these are on Neutron network
> x. The SDN controller is responsible for making sure the baremetal node
> only has access to Neutron Network x through changing the switch
> configuration dynamically.
> 
> Making an individual baremetal have access to several vlans and let the
> baremetal node configure a vlan tag at the baremetal node itself is a big
> security risk and should not be supported. Unless an operator specifically
> configures a baremetal node to be vlan trunk.

Right, trunking is the main use case here, and I think we should support
it. :)

To be clear, I'm not advocating that we always send the VLAN to the
instance. I agree that this patch isn't the right way to do it. But I
do think we need to consider that there are cases where we do need to
expose the VLAN, and we should support this.

For a little background, this patch came from code that is running in
production today, where we're trunking two VLANs down to the host -- it
isn't a theoretical use case.

// jim

> 
> Sam Stoelinga
> 
> On Sat, Jul 18, 2015 at 5:10 AM, Kevin Benton  wrote:
> 
> > > which requires VLAN info to be pushed to the host. I keep hearing "bare
> > metal will never need to know about VLANs" so I want to quash that ASAP.
> >
> > That's leaking implementation details though if the bare metal host only
> > needs to be on one network. It also creates a security risk if the bare
> > metal node is untrusted.
> >
> > If the tagging is to make it so it can access multiple networks, then that
> > makes sense for now but it should ultimately be replaced by the vlan trunk
> > ports extension being worked on this cycle that decouples the underlying
> > network transport from what gets tagged to the VM/bare metal.
> > On Jul 17, 2015 11:47 AM, "Jim Rollenhagen" 
> > wrote:
> >
> >> On Fri, Jul 17, 2015 at 10:56:36AM -0600, Kevin Benton wrote:
> >> > Check out my comments on the review. Only Neutron knows whether or not
> >> an
> >> > instance needs to do manual tagging based on the plugin/driver loaded.
> >> >
> >> > For example, Ironic/bare metal ports can be bound by neutron with a
> >> correct
> >> > driver so they shouldn't get the VLAN information at the instance level
> >> in
> >> > those cases. Nova has no way to know whether Neutron is configured this
> >> way
> >> > so Neutron should have an explicit response in the port binding
> >> information
> >> > indicating that an instance needs to tag.
> >>
> >> Agree. However, I just want to point out that there are neutron drivers
> >> that exist today[0] that support bonded NICs with trunked VLANs, which
> >> requires VLAN info to be pushed to the host. I keep hearing "bare metal
> >> will never need to know about VLANs" so I want to quash that ASAP.
> >>
> >> As far as Neutron sending the flag to decide whether the instance should
> >> tag packets, +1, I think that should work.
> >>
> >> // jim
> >> >
> >> > On Fri, Jul 17, 2015 at 9:51 AM, Jim Rollenhagen <
> >> j...@jimrollenhagen.com>
> >> > wrote:
> >> >
> >> > > On Fri, Jul 17, 2015 at 01:06:46PM +0100, John Garbutt wrote:
> >> > > > On 17 July 2015 at 11:23, Sean Dague  wrote:
> >> > > > > On 07/16/2015 06:06 PM, Sean M. Collins wrote:
> >> > > > >> On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote:
> >> > > > >>> So it looks like there is a missing part in this feature. There
> >> > > should
> >> > > > >>> be a way to "hide" this information if the instance does not
> >> require
> >> > > to
> >> > > > >>> configure vlan interfaces to make network functional.
> >> > > > >>
> >> > > > >> I just commented on the review, but the provider network API
> >> extension
> >> > > > >> is admin only, most likely for the reasons that I think someone
> >> has
> >> > > > >> already mentioned, that it exposes details of the phyiscal
> >> network
> >> > > > >> layout that should not be exposed to tenants.
> >> > > > >
> >> > > > > So, clearly, under some circumstances the network operator wants
> >> to
> >> > > > > expose this information, because there was the request for that
> >> > > feature.
> >> > > > > The question in my mind is what circumstances are those, and what
> >> > > > > additional information needs to be provided here.
> >> > > > >
> >> > > > > There is always a balance between the private cloud case which
> >> wants to
> >> > > > > enable more self service from users (and where the users are
> >> often also
> >> > > > > the operators), and the public cloud case where the users are
> >> outsiders
> >> > > > > and we want to hide as much as possible from them.
> >> > > > >
> >> > > > > For instance, would an additional attribute on a provider networ

Re: [openstack-dev] [openstack-infra] [CI] [tempest] Tempest tests failing with SSH timeout.

[Asselin, Ramy]

There are two ways that I know of to customize what services are run:

1.  Setup your own feature matrix [1]

2.  Override enabled services [2]

Option 2 is probably what you’re looking for.

[1] 
http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate-wrap.sh#n152
[2] 
http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate.sh#n76

From: Abhishek Shrivastava [mailto:abhis...@cloudbyte.com]
Sent: Sunday, July 19, 2015 10:37 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [openstack-infra] [CI] [tempest] Tempest tests 
failing with SSH timeout.

Hi Ramy,

Thanks for the suggestion. One more thing I need to ask, as I have have setup 
one more CI so is there any way that we can decide that only required projects 
should get downloaded and installed during devstack installation dynamically. 
As I see no such things that can be done to devstack-gate scripts so the 
following scenario can be achieved.

On Sun, Jul 19, 2015 at 8:38 PM, Asselin, Ramy 
mailto:ramy.asse...@hp.com>> wrote:
Just the export I mentioned:
export DEVSTACK_GATE_NEUTRON=1
Devstack-gate scripts will do the right thing when it sees that set. You can 
see plenty of examples here [1].

Ramy

[1] 
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/devstack-gate.yaml#n467

From: Abhishek Shrivastava 
[mailto:abhis...@cloudbyte.com]
Sent: Sunday, July 19, 2015 2:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [openstack-infra] [CI] [tempest] Tempest tests 
failing with SSH timeout.

Hi Ramy,

Thanks for the suggestion but since I am not including the neutron project, so 
downloading and including it will require any additional configuration in 
devstack-gate or not?

On Sat, Jul 18, 2015 at 11:41 PM, Asselin, Ramy 
mailto:ramy.asse...@hp.com>> wrote:
We ran into this issue as well. I never found the root cause, but I found a 
work-around: Use neutron-networking instead of the default nova-networking.

If you’re using devstack-gate, it’s as  simple as:
export DEVSTACK_GATE_NEUTRON=1

Then run the job as usual.

Ramy

From: Abhishek Shrivastava 
[mailto:abhis...@cloudbyte.com]
Sent: Friday, July 17, 2015 9:15 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [openstack-infra] [CI] [tempest] Tempest tests failing 
with SSH timeout.

Hi Folks,

In my CI I see the following tempest tests failure for a past couple of days.

•
tempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario
 [361.274316s] ... FAILED

•
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
 [320.122458s] ... FAILED

•
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern
 [317.399342s] ... FAILED

•
tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_compute_with_volumes
 [257.858272s] ... FAILED

The failure logs are always the same every time, i.e;



03:34:09 2015-07-17 03:21:13,256 9505 ERROR[tempest.scenario.manager] 
(TestVolumeBootPattern:test_volume_boot_pattern) Initializing SSH connection to 
172.24.5.1 failed. Error: Connection to the 172.24.5.1 via SSH timed out.

03:34:09 User: cirros, Password: None

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
Traceback (most recent call last):

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   File 
"tempest/scenario/manager.py", line 312, in get_remote_client

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
linux_client.validate_authentication()

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   File 
"tempest/common/utils/linux/remote_client.py", line 62, in 
validate_authentication

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
self.ssh_client.test_connection_auth()

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   File 
"/opt/stack/new/tempest/.tox/all/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
 line 151, in test_connection_auth

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
connection = self._get_ssh_connection()

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   File 
"/opt/stack/new/tempest/.tox/all/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
 line 87, in _get_ssh_connection

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
password=self.password)

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
SSHTimeout: Connection to the 172.24.5.1 via SSH timed out.

03:34:09 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager User: 
cirros, Password: None

03:34:09

Re: [openstack-dev] Barbican : Unable to store the secret when Barbican was Integrated with SafeNet HSM

[Asha Seshagiri]

Hi John ,

Thanks  for pointing me to the right script.
I appreciate your help .

I tried running the script with the following command :

[root@HSM-Client bin]# python pkcs11-key-generation --library-path
{/usr/lib/libCryptoki2_64.so} --passphrase {test123} --slot-id 1  mkek
--length 32 --label 'an_mkek'
Traceback (most recent call last):
  File "pkcs11-key-generation", line 120, in 
main()
  File "pkcs11-key-generation", line 115, in main
kg = KeyGenerator()
  File "pkcs11-key-generation", line 38, in __init__
ffi=ffi
  File "/root/barbican/barbican/plugin/crypto/pkcs11.py", line 315, in
__init__
self.lib = self.ffi.dlopen(library_path)
  File "/usr/lib64/python2.7/site-packages/cffi/api.py", line 127, in dlopen
lib, function_cache = _make_ffi_library(self, name, flags)
  File "/usr/lib64/python2.7/site-packages/cffi/api.py", line 572, in
_make_ffi_library
backendlib = _load_backend_lib(backend, libname, flags)
  File "/usr/lib64/python2.7/site-packages/cffi/api.py", line 561, in
_load_backend_lib
return backend.load_library(name, flags)
*OSError: cannot load library {/usr/lib/libCryptoki2_64.so}:
{/usr/lib/libCryptoki2_64.so}: cannot open shared object file: No such file
or directory*

*Unable to run the script since the library libCryptoki2_64.so cannot be
opened.*

Tried the following solution  :

   -  vi /etc/ld.so.conf
   - Added both the paths of ld.so.conf in the  /etc/ld.so.conf file got
from the command find / -name libCryptoki2_64.so
   - /usr/safenet/lunaclient/lib/libCryptoki2_64.so
  - /usr/lib/libCryptoki2_64.so
   - sudo ldconfig
   - ldconfig -p

But the above solution failed and am geting the same error.

Any help would highly be apprecited.
Thanks in advance!

Thanks and Regards,
Asha Seshagiri

On Sat, Jul 18, 2015 at 11:12 PM, John Vrbanac 
wrote:

>  Asha,
>
> It looks like you don't have your mkek label correctly configured. Make
> sure that the mkek_label and hmac_label values in your config correctly
> reflect the keys that you've generated on your HSM.
>
> The plugin will cache the key handle to the mkek and hmac when the plugin
> starts, so if it cannot find them, it'll fail to load the plugin altogether.
>
>
>  If you need help generating your mkek and hmac, refer to
> http://docs.openstack.org/developer/barbican/api/quickstart/pkcs11keygeneration.html
> for instructions on how to create them using a script.
>
>
>  As far as who uses HSMs, I know we (Rackspace) use them with Barbican.
>
>
> John Vrbanac
>  --
> *From:* Asha Seshagiri 
> *Sent:* Saturday, July 18, 2015 8:47 PM
> *To:* openstack-dev
> *Cc:* Reller, Nathan S.
> *Subject:* [openstack-dev] Barbican : Unable to store the secret when
> Barbican was Integrated with SafeNet HSM
>
>  Hi All ,
>
>  I have configured Barbican to integrate with SafeNet  HSM.
> Installed safenet client libraries , registered the barbican machine to
> point to HSM server  and also assigned HSM partition.
>
>  The following were the changes done in barbican.conf file
>
>
>  # = Secret Store Plugin ===
> [secretstore]
> namespace = barbican.secretstore.plugin
> enabled_secretstore_plugins = store_crypto
>
>  # = Crypto plugin ===
> [crypto]
> namespace = barbican.crypto.plugin
> enabled_crypto_plugins = p11_crypto
>
>  [p11_crypto_plugin]
> # Path to vendor PKCS11 library
> library_path = '/usr/lib/libCryptoki2_64.so'
> # Password to login to PKCS11 session
> login = 'test123'
> # Label to identify master KEK in the HSM (must not be the same as HMAC
> label)
> mkek_label = 'an_mkek'
> # Length in bytes of master KEK
>  mkek_length = 32
> # Label to identify HMAC key in the HSM (must not be the same as MKEK
> label)
> hmac_label = 'my_hmac_label'
>   # HSM Slot id (Should correspond to a configured PKCS11 slot). Default:
> 1
> slot_id = 1
>
>  Unable to store the secret when Barbican was integrated with HSM.
>
>  [root@HSM-Client crypto]# curl -X POST -H
> 'content-type:application/json' -H 'X-Project-Id:12345' -d '{"payload":
> "my-secret-here", "payload_content_type": "text/plain"}'
> http://localhost:9311/v1/secrets
> *{"code": 500, "description": "Secret creation failure seen - please
> contact site administrator.", "title": "Internal Server
> Error"}[root@HSM-Client crypto]#*
>
>
> Please find the logs below :
>
>  2015-07-18 17:15:32.642 29838 ERROR barbican.plugin.util.utils
> [req-354affce-b3d6-41fd-b050-5e5c604004eb - 12345 - - -] Problem seen
> creating plugin: 'p11_crypto'
> 2015-07-18 17:15:32.642 29838 ERROR barbican.plugin.util.utils Traceback
> (most recent call last):
> 2015-07-18 17:15:32.642 29838 ERROR barbican.plugin.util.utils   File
> "/root/barbican/barbican/plugin/util/utils.py", line 42, in
> instantiate_plugins
> 2015-07-18 17:15:32.642 29838 ERROR barbican.plugin.util.utils
> plugin_instance = ext.plugin(*invoke_args, **invoke_kwargs)
> 2015-07-18 17:15:32.642 29838 ERROR barbican.plu

Re: [openstack-dev] 7/17 state of the gate (you know, fires)

[Thierry Carrez]

Matt Riedemann wrote:
> 
> I think we're good now, let the rechecks begin!

Thanks so much for driving this, Matt. Don't burn out working on
weekends on it, though :)

(yes I realize the irony of posting that on a Sunday)

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all] Tags, explain like I am five?

[Anita Kuno]

On 07/16/2015 05:13 AM, Thierry Carrez wrote:
> anyone with a stake in the game and their cat will upvote or
> downvote for no reason

I think we are overloaded on skewed information already and I'm not in
support of a structure that would likely offer gamed information.

Thanks,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel][Plugins] additionnal categories for plugins

[Samuel Bartel]

Hi all,

I think we are missing a category for plugins. I was thinking to following
plugins
-TLS plugin related to security. For example everything related to tls
access to the dashboard/vnc and apis
-Plugin to deploy freezer with fuel in order to achieve abckup and restore
(on going)
-plugin to setup availaiblity zones (on going)

The actual categories are :
montiroing
storage
storage-cinder
storage-glance
network
hypervisor

these plugins are not matching to any of those categories.
Shoul we let the category field empty as requested in fuel plugin
documentation or can we consider to add additionnal categories?

Regards

Samuel
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder]Question for availability_zone of cinder

[Duncan Thomas]

So this has come up a few times. My question is, does having one node
serving several backends really form multiple AZs? Not really, the c-vol
node becomes a single point of failure.

There might be value in moving the AZ setting into the per-backend
configurables, if it doesn't work there already, for testing if nothing
else, but I do worry that it encorages people to misunderstand or worse
intentionally fake multiple AZs.


On 19 July 2015 at 05:19, hao wang  wrote:

> Hi  stackers,
>
> I found now cinder only can configure one storage_availability_zone for
> cinder-volume. If using multi-backend in one cinder-volume node, could we
> have different AZ for each backend? So that we can specify each backend as
> a AZ and create volume in this AZ.
>
> Regards,
> Wang Hao
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
-- 
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Barbican : Unable to store the secret when Barbican was Integrated with SafeNet HSM

[John Vrbanac]

Don't include the curly brackets on the script arguments. The documentation is 
just using them to indicate that those are placeholders for real values.


John Vrbanac

From: Asha Seshagiri 
Sent: Sunday, July 19, 2015 2:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Reller, Nathan S.
Subject: Re: [openstack-dev] Barbican : Unable to store the secret when 
Barbican was Integrated with SafeNet HSM

Hi John ,

Thanks  for pointing me to the right script.
I appreciate your help .

I tried running the script with the following command :

[root@HSM-Client bin]# python pkcs11-key-generation --library-path 
{/usr/lib/libCryptoki2_64.so} --passphrase {test123} --slot-id 1  mkek --length 
32 --label 'an_mkek'
Traceback (most recent call last):
  File "pkcs11-key-generation", line 120, in 
main()
  File "pkcs11-key-generation", line 115, in main
kg = KeyGenerator()
  File "pkcs11-key-generation", line 38, in __init__
ffi=ffi
  File "/root/barbican/barbican/plugin/crypto/pkcs11.py", line 315, in __init__
self.lib = self.ffi.dlopen(library_path)
  File "/usr/lib64/python2.7/site-packages/cffi/api.py", line 127, in dlopen
lib, function_cache = _make_ffi_library(self, name, flags)
  File "/usr/lib64/python2.7/site-packages/cffi/api.py", line 572, in 
_make_ffi_library
backendlib = _load_backend_lib(backend, libname, flags)
  File "/usr/lib64/python2.7/site-packages/cffi/api.py", line 561, in 
_load_backend_lib
return backend.load_library(name, flags)
OSError: cannot load library {/usr/lib/libCryptoki2_64.so}: 
{/usr/lib/libCryptoki2_64.so}: cannot open shared object file: No such file or 
directory

Unable to run the script since the library libCryptoki2_64.so cannot be opened.

Tried the following solution  :

  *vi /etc/ld.so.conf
  *   Added both the paths of ld.so.conf in the  /etc/ld.so.conf file got  from 
the command find / -name libCryptoki2_64.so
 *   /usr/safenet/lunaclient/lib/libCryptoki2_64.so
 *   /usr/lib/libCryptoki2_64.so
  *   sudo ldconfig
  *   ldconfig -p

But the above solution failed and am geting the same error.

Any help would highly be apprecited.
Thanks in advance!

Thanks and Regards,
Asha Seshagiri

On Sat, Jul 18, 2015 at 11:12 PM, John Vrbanac 
mailto:john.vrba...@rackspace.com>> wrote:

Asha,

It looks like you don't have your mkek label correctly configured. Make sure 
that the mkek_label and hmac_label values in your config correctly reflect the 
keys that you've generated on your HSM.

The plugin will cache the key handle to the mkek and hmac when the plugin 
starts, so if it cannot find them, it'll fail to load the plugin altogether.


If you need help generating your mkek and hmac, refer to 
http://docs.openstack.org/developer/barbican/api/quickstart/pkcs11keygeneration.html
 for instructions on how to create them using a script.


As far as who uses HSMs, I know we (Rackspace) use them with Barbican.


John Vrbanac

From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Sent: Saturday, July 18, 2015 8:47 PM
To: openstack-dev
Cc: Reller, Nathan S.
Subject: [openstack-dev] Barbican : Unable to store the secret when Barbican 
was Integrated with SafeNet HSM

Hi All ,

I have configured Barbican to integrate with SafeNet  HSM.
Installed safenet client libraries , registered the barbican machine to point 
to HSM server  and also assigned HSM partition.

The following were the changes done in barbican.conf file


# = Secret Store Plugin ===
[secretstore]
namespace = barbican.secretstore.plugin
enabled_secretstore_plugins = store_crypto

# = Crypto plugin ===
[crypto]
namespace = barbican.crypto.plugin
enabled_crypto_plugins = p11_crypto

[p11_crypto_plugin]
# Path to vendor PKCS11 library
library_path = '/usr/lib/libCryptoki2_64.so'
# Password to login to PKCS11 session
login = 'test123'
# Label to identify master KEK in the HSM (must not be the same as HMAC label)
mkek_label = 'an_mkek'
# Length in bytes of master KEK
mkek_length = 32
# Label to identify HMAC key in the HSM (must not be the same as MKEK label)
hmac_label = 'my_hmac_label'
# HSM Slot id (Should correspond to a configured PKCS11 slot). Default: 1
slot_id = 1

Unable to store the secret when Barbican was integrated with HSM.

[root@HSM-Client crypto]# curl -X POST -H 'content-type:application/json' -H 
'X-Project-Id:12345' -d '{"payload": "my-secret-here", "payload_content_type": 
"text/plain"}' http://localhost:9311/v1/secrets
{"code": 500, "description": "Secret creation failure seen - please contact 
site administrator.", "title": "Internal Server Error"}[root@HSM-Client crypto]#


Please find the logs below :

2015-07-18 17:15:32.642 29838 ERROR barbican.plugin.util.utils 
[req-354affce-b3d6-41fd-b050-5e5c604004eb - 12345 - - -] Problem seen creating 
plugin: 'p11_crypto'
2015-07-18 17:15:32.642 29838 ERROR barbican.plugin.util

Re: [openstack-dev] [tc][all] Tags, explain like I am five?

[Ed Leafe]

On Jul 16, 2015, at 4:13 AM, Thierry Carrez  wrote:

> I don't really like the idea of a popularity contest to define "HA" or
> "scales" -- anyone with a stake in the game and their cat will upvote or
> downvote for no reason. I prefer to define HA in clear terms and have
> some group maintain the tag across the set of projects.

Hmmm… I was thinking of concepts like restaurant or movie reviews: since those 
depend on the tastes of the reviewer, they may or may not match your tastes. So 
we might consider tags that are backed by different groups of operators, each 
of whom may have a completely different environment. New operators coming into 
OpenStack will soon recognize which tags are relevant to their environment, and 
give them much more credence when it comes to evaluating the state of the 
various projects.

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Openstack][Horizon] Sharable Angular mock

[Chen, Shaoquan]

Currently random mock objects are created inside of spec files to make writing 
unit tests easier. This approach works but has some drawback:

  *   mocks are not sharable between specs.
  *   mocks are usually too simple.
  *   mocks may not be consistent between spec files.
  *   mocks are not tested theme self.
  *   hard to maintain and manage.

In order to make it easy for developers to write high quality unit tests and 
e2e test, we want a set of high-quality mock objects. To make its easy to 
maintain:

  *   mocks should reside in ``.mock.js`` files and be loaded only in test 
runner page
  *   mocks should be loaded after production code files, before spec code 
files.
  *   mocks should be sharable between specs.
  *   mocks are not belong to specs, they should have a 1:1 relationship with 
the object it try to mock.
  *   mocks should be at a level as low as possible, maybe where JavaScript 
cannot reach directly.
  *   mocks must be tested theme self.
  *   mocks should be easy to find, use and manage.

I drafted a simple BP at 
https://blueprints.launchpad.net/horizon/+spec/horizon-angular-mocks to 
summaries the issue existing in Horizon IMO and how I could see to fix them. I 
also setup two patches to prove the concept at:

  *   https://review.openstack.org/#/c/202817/
  *   https://review.openstack.org/#/c/202830/

This mock is for the window object and another could be OpenStackHtttpBackend 
which mimic all the behaviors of Horizon Web services. As you can see, the 
window mock object can be easily applied to a bug Tyr fixed recently so that 
the spec code do not need to create an inline mock object. Because those shared 
mock are independent from specs, they can be more neutral and can have much 
more features than a over simplified mock for a specific test.

Please let me know if this interested you.

Thanks,
Sean

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum]

[Kai Qiang Wu]

My thoughts:

I think we'd better check what google will do after such official
announcement. As community changes fast, and we'd really welcome someone to
contributing it consistently and actively.



Thanks


Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

Follow your heart. You are miracle!



From:   "Daneyon Hansen (danehans)" 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   07/18/2015 12:46 AM
Subject:[openstack-dev]  [magnum]



All,

Does anyone have insight into Google's plans for contributing to containers
within OpenStack?

http://googlecloudplatform.blogspot.tw/2015/07/Containers-Private-Cloud-Google-Sponsors-OpenStack-Foundation.html

Regards,
Daneyon Hansen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel][puppet] The state of collaboration: 5 weeks

[Emilien Macchi]

I'm currently in holidays but I could not resist to take some time and
reply.

On 07/18/2015 06:32 PM, Dmitry Borodaenko wrote:
> It has been 5 weeks since Emilien has asked Fuel developers to
> contribute more
> actively to Puppet OpenStack project [0]. We had a lively discussion on
> openstack-dev, myself and other Fuel developers proposed some concrete
> steps
> that could be done to reconcile the two projects, the whole thread was
> reported
> and discussed on Linux Weekly News [1], and the things were looking up.
> 
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2015-June/066544.html
> [1] https://lwn.net/Articles/648331/
> 
> And now, 5 weeks later, Emilien has reported to the Technical Committee
> that
> there has been no progress on reconciliation between Fuel and Puppet
> OpenStack,
> and used his authority as a PTL to request that the Fuel's proposal to join
> OpenStack [2] is rejected.

1) What you're writing here is not correct.
Please read again my first comment on the Governance patch:

"They are making progress and I'm sure they are doing their best."

I've been following all your actions since our *thread*, and so far all
of this seems good to me, I'm honestly satisfied to know that you guys
have plans.

2) The word 'authority' is also wrong. I'm not part of TC and my vote
does not count at all for the final decision. If Fuel has to be an
OpenStack project, TC is free to vote by themselves without me and it
seems they already negatively voted before my thoughts.

3) I -1 the governance patch because to me, it seems too early for
having Fuel part of OpenStack. We ran that discussion 5 weeks ago, a lot
of actions have been taken for I hope TC will wait for actual results
(mainly highlighted in the review itself).
Let me quote my first comment on the patch that clearly show I'm not
against the idea:
"I sincerely hope they'll realize what they plan to do, which is being
part of our community like other projects already succeed to do."


> [2] https://review.openstack.org/199232
> 
> In further comments on the same review, Emilien has claimed that there's
> "clearly less" contribution to Puppet OpenStack from Fuel developers than
> before, and even brought up an example of a review in puppet-horizon
> that was
> proposed and then abandoned by Fuel team [3]. Jay went as far as calling
> that
> example "an obvious failure of working with the upstream Puppet-OpenStack
> community".

Andrew took the best metric in your advantage... the review metric,
which is something given to anyone having signed the CLA.

I would rather focus on patchset, commits, bug fix, IRC, ML etc... which
really show collaboration in a group.
And I honestly think it's making progress, even though the numbers.

> [3] https://review.openstack.org/198119
> 
> Needless to say, I found all these claims deeply disturbing, and had to
> look
> closely into what's going on.
> 
> The case of the puppet-horizon commit has turned out to be surprisingly
> obvious.
> 
> Even before looking into the review comments, I could see a technical
> reason
> for abandoning the commit: if there is a bug in a component, fixing that
> bug in
> the package is preferrable to fixing it in puppet, because it allows
> anybody to
> benefit from the fix, not just the people deploying that package with
> puppet.

You are not providing official Ubuntu packaging, but your own packages
mainly used by Fuel, while Puppet OpenStack modules are widely used by
OpenStack community.
Fixing that bug in Fuel packaging is the shortest & easiest way for you
to fix that, while we are really doing something wrong in puppet-horizon
about the 'compress' option.
So Fuel is now fixed and puppet-horizon broken.

> And if you do look at the review in question, you'll find that
> immediately (14
> minutes, and that at 6pm on Friday night!) after Jay has asked in the
> comments
> to the review why it was abandoned, the commit author from the Fuel team
> has
> explained that this patch was a workaround for a packaging problem, and
> that
> this was pointed out in the review by a Horizon core reviewer more than
> a week
> ago, and later corroborated by a Puppet OpenStack core reviewer. Further
> confirming that fixing this in the package instead of in puppet-horizon
> was an
> example of Fuel developers agreeing with other Puppet OpenStack
> contributors
> and doing the right thing.

This kind of bug has to be fixed between Horizon & Puppet team, and not
with some "workaround" in packaging tool.
We don't really want "workarounds" I guess, do we?

> Emilien has clearly found this case important enough to report to the
> TC, and
> yet didn't find it important enough to simply ask Fuel developers why they
> chose to abandon the commit. I guess you can call that an obvious
> failure to
> work together.
> 
> Looking further into Fuel team's reviews for puppet-horizon, I found
> another
> equally disturbing example [4].
> 
> [4] https://review.openstack.org/190548
> 
> Here's w

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper

[Kai Qiang Wu]

Hi Peng,

As @Adrian pointed it out:

My fist suggestion is to find a way to make a nova virt driver for Hyper,
which could allow it to be used with all of our current Bay types in
Magnum.


I remembered you or other guys in your company proposed one bp about nova
virt driver for Hyper. What's the status of the bp now?
Is it accepted by nova projects or cancelled ?


Thanks

Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

Follow your heart. You are miracle!



From:   Adrian Otto 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   07/19/2015 11:18 PM
Subject:Re: [openstack-dev] [magnum][bp] Power Magnum to run on
metal   withHyper



Peng,

You are not the first to think this way, and it's one of the reasons we did
not integrate Containers with OpenStack in a meaningful way a full year
earlier. Please pay attention closely.

1) OpenStack's key influences care about two personas: 1.1) Cloud Operators
1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea
will get killed. Operators matter.

2) Cloud Operators need a consistent way to bill for the IaaS services the
provide. Nova emits all of the RPC messages needed to do this. Having a
second nova that does this slightly differently is a really annoying
problem that will make Operators hate the software. It's better to use
nova, have things work consistently, and plug in virt drivers to it.

3) Creation of a host is only part of the problem. That's the easy part.
Nova also does a bunch of other things too. For example, say you want to
live migrate a guest from one host to another. There is already
functionality in Nova for doing that.

4) Resources need to be capacity managed. We call this scheduling. Nova has
a pluggable scheduler to help with the placement of guests on hosts. Magnum
will not.

5) Hosts in a cloud need to integrate with a number of other services, such
as an image service, messaging, networking, storage, etc. If you only think
in terms of host creation, and do something without nova, then you need to
re-integrate with all of these things.

Now, I probably left out examples of lots of other things that Nova does.
What I have mentioned us enough to make my point that there are a lot of
things that Magnum is intentionally NOT doing that we expect to get from
Nova, and I will block all code that gratuitously duplicates functionality
that I believe belongs in Nova. I promised our community I would not
duplicate existing functionality without a very good reason, and I will
keep that promise.

Let's find a good way to fit Hyper with OpenStack in a way that best
leverages what exists today, and is least likely to be rejected. Please
note that the proposal needs to be changed from where it is today to
achieve this fit.

My fist suggestion is to find a way to make a nova virt driver for Hyper,
which could allow it to be used with all of our current Bay types in
Magnum.

Thanks,

Adrian


 Original message 
From: Peng Zhao 
Date: 07/19/2015 5:36 AM (GMT-08:00)
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal
withHyper

Thanks Jay.

Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I
just think bay isn't a must in this case, and we don't need nova to
provision BM hosts, which makes things more complicated imo.

Peng


-- Original --
From:  "Jay Lau";
Date:  Sun, Jul 19, 2015 10:36 AM
To:  "OpenStack Development Mailing List (not for usage
questions)";
Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal
withHyper

Hong Bin,

I have some online discussion with Peng, seems hyper is now integrating
with Kubernetes and also have plan integrate with mesos for scheduling.
Once mesos integration finished, we can treat mesos+hyper as another kind
of bay.

Thanks

2015-07-19 4:15 GMT+08:00 Hongbin Lu :
  Peng,





  Several questions Here. You mentioned that HyperStack is a single big
  “bay”. Then, who is doing the multi-host scheduling, Hyper or something
  else? Were you suggesting to integrate Hyper with Magnum directly? Or you
  were suggesting to integrate Hyper with Magnum indirectly (i.e. through
  k8s, mesos and/or Nova)?





  Best regards,


  Hongbin





  From: Peng Zhao [mailto:p...@hyper.sh]
  Sent: July-17-15 12:34 PM
  To: OpenStack Development Mailing List (not for usage questions)


  Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal
  with Hyper





  Hi, Adrian, Jay and all,

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper

[Jay Lau]

The nova guys propose move Hyper to Magnum but not Nova as Hyper cannot fit
into nova virt driver well.

As Hyper is now integrating with Kubernetes, I think that the integration
point may be creating a kubernetes hyper bay with ironic driver.

Thanks

2015-07-20 10:00 GMT+08:00 Kai Qiang Wu :

> Hi Peng,
>
> As @Adrian pointed it out:
>
> *My fist suggestion is to find a way to make a nova virt driver for Hyper,
> which could allow it to be used with all of our current Bay types in
> Magnum.*
>
>
> I remembered you or other guys in your company proposed one bp about nova
> virt driver for Hyper. What's the status of the bp now?
> Is it accepted by nova projects or cancelled ?
>
>
> Thanks
>
> Best Wishes,
>
> 
> Kai Qiang Wu (吴开强  Kennan）
> IBM China System and Technology Lab, Beijing
>
> E-mail: wk...@cn.ibm.com
> Tel: 86-10-82451647
> Address: Building 28(Ring Building), ZhongGuanCun Software Park,
> No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
> 100193
>
> 
> Follow your heart. You are miracle!
>
> [image: Inactive hide details for Adrian Otto ---07/19/2015 11:18:02
> PM---Peng, You are not the first to think this way, and it's one o]Adrian
> Otto ---07/19/2015 11:18:02 PM---Peng, You are not the first to think this
> way, and it's one of the reasons we did not integrate Cont
>
> From: Adrian Otto 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 07/19/2015 11:18 PM
> Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal
> withHyper
> --
>
>
>
> Peng,
>
> You are not the first to think this way, and it's one of the reasons we
> did not integrate Containers with OpenStack in a meaningful way a full year
> earlier. Please pay attention closely.
>
> 1) OpenStack's key influences care about two personas: 1.1) Cloud
> Operators 1.2) Cloud Consumers. If you only think in terms of 1.2, then
> your idea will get killed. Operators matter.
>
> 2) Cloud Operators need a consistent way to bill for the IaaS services the
> provide. Nova emits all of the RPC messages needed to do this. Having a
> second nova that does this slightly differently is a really annoying
> problem that will make Operators hate the software. It's better to use
> nova, have things work consistently, and plug in virt drivers to it.
>
> 3) Creation of a host is only part of the problem. That's the easy part.
> Nova also does a bunch of other things too. For example, say you want to
> live migrate a guest from one host to another. There is already
> functionality in Nova for doing that.
>
> 4) Resources need to be capacity managed. We call this scheduling. Nova
> has a pluggable scheduler to help with the placement of guests on hosts.
> Magnum will not.
>
> 5) Hosts in a cloud need to integrate with a number of other services,
> such as an image service, messaging, networking, storage, etc. If you only
> think in terms of host creation, and do something without nova, then you
> need to re-integrate with all of these things.
>
> Now, I probably left out examples of lots of other things that Nova does.
> What I have mentioned us enough to make my point that there are a lot of
> things that Magnum is intentionally NOT doing that we expect to get from
> Nova, and I will block all code that gratuitously duplicates functionality
> that I believe belongs in Nova. I promised our community I would not
> duplicate existing functionality without a very good reason, and I will
> keep that promise.
>
> Let's find a good way to fit Hyper with OpenStack in a way that best
> leverages what exists today, and is least likely to be rejected. Please
> note that the proposal needs to be changed from where it is today to
> achieve this fit.
>
> My fist suggestion is to find a way to make a nova virt driver for Hyper,
> which could allow it to be used with all of our current Bay types in Magnum.
>
> Thanks,
>
> Adrian
>
>
>  Original message 
> From: Peng Zhao 
> Date: 07/19/2015 5:36 AM (GMT-08:00)
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal
> withHyper
>
> Thanks Jay.
>
> Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos.
> I just think bay isn't a must in this case, and we don't need nova to
> provision BM hosts, which makes things more complicated imo.
>
> Peng
>
>
> -- Original --
> *From: * "Jay Lau";
> *Date: * Sun, Jul 19, 2015 10:36 AM
> *To: * "OpenStack Development Mailing List (not for usage questions)"<
> openstack-dev@lists.openstack.org>;
> *Subject: * Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal
> withHyper
>
> Hong Bin,
>
> I have some 

[openstack-dev] [Neutron] HELP CONFIRM OR DISCUSS:create a port when network contain ipv4 subnets and ipv6 subnets, allocate ipv6 address to the port.

[zhaobo]

Hi ,
Could anyone please check the bug below?
https://bugs.launchpad.net/neutron/+bug/1467791


This bug description:
When the created network contains one ipv4 subnet and an ipv6 subnet which 
turned on slaac or stateless.
When I create a port use cmd like:
neutron port-create --fixed-ip subnet_id=$[ipv4_subnet_id] $[network_id/name]
The specified fixed-ip is ipv4_subnet, but the returned port contained the ipv6 
subnet.




If user just want a port with ipv4 , why returned port had allocated an ipv6 
address.
And I know this is an design behavior from 
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/multiple-ipv6-prefixes.html#proposed-change
But we are still confused about this operation.


Thank you anyone could help for confirm this issue , and wish you return the 
message asap.


ZhaoBo__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum][bp] Power Magnum to runon metal withHyper

[Peng Zhao]

It looks like that Nova team has no plan to accept either nova-docker driver or 
nova-hyper. The focus of Nova is "Server-like" instance, not App-centric 
container. That is fine. It's the best to let Nova be Nova, and build sth. else 
for container. After all, different use cases, different needs, different 
solutions.
 
Peng


-- Original --
From:  "Kai Qiang Wu";
Date:  Mon, Jul 20, 2015 10:00 AM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to runonmetal   
withHyper

 
 
Hi Peng,
 
 As @Adrian pointed it out:
 
 My fist suggestion is to find a way to make a nova virt driver for Hyper, 
which could allow it to be used with all of our current Bay types in Magnum. 
 
 
 I remembered you or other guys in your company proposed one bp about nova virt 
driver for Hyper. What's the status of the bp now?
 Is it accepted by nova projects or cancelled ?
 
 
 Thanks
 
 Best Wishes,
 

 Kai Qiang Wu (吴开强  Kennan）
 IBM China System and Technology Lab, Beijing
 
 E-mail: wk...@cn.ibm.com
 Tel: 86-10-82451647
 Address: Building 28(Ring Building), ZhongGuanCun Software Park,  
  No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 
100193
 

 Follow your heart. You are miracle! 
 
 Adrian Otto ---07/19/2015 11:18:02 PM---Peng, You are not the first to think 
this way, and it's one of the reasons we did not integrate Cont
 
 From:  Adrian Otto 
 To:"OpenStack Development Mailing List (not for usage questions)" 

 Date:  07/19/2015 11:18 PM
 Subject:   Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal   
withHyper
 


 
 
 Peng,
 
 You are not the first to think this way, and it's one of the reasons we did 
not integrate Containers with OpenStack in a meaningful way a full year 
earlier. Please pay attention closely.
 
 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 
1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will 
get killed. Operators matter.
 
 2) Cloud Operators need a consistent way to bill for the IaaS services the 
provide. Nova emits all of the RPC messages needed to do this. Having a second 
nova that does this slightly differently is a really annoying problem that will 
make Operators hate the software. It's better to use nova, have things work 
consistently, and plug in virt drivers to it.
 
 3) Creation of a host is only part of the problem. That's the easy part. Nova 
also does a bunch of other things too. For example, say you want to live 
migrate a guest from one host to another. There is already functionality in 
Nova for doing that.
 
 4) Resources need to be capacity managed. We call this scheduling. Nova has a 
pluggable scheduler to help with the placement of guests on hosts. Magnum will 
not.
 
 5) Hosts in a cloud need to integrate with a number of other services, such as 
an image service, messaging, networking, storage, etc. If you only think in 
terms of host creation, and do something without nova, then you need to 
re-integrate with all of these things.
 
 Now, I probably left out examples of lots of other things that Nova does. What 
I have mentioned us enough to make my point that there are a lot of things that 
Magnum is intentionally NOT doing that we expect to get from Nova, and I will 
block all code that gratuitously duplicates functionality that I believe 
belongs in Nova. I promised our community I would not duplicate existing 
functionality without a very good reason, and I will keep that promise.
 
 Let's find a good way to fit Hyper with OpenStack in a way that best leverages 
what exists today, and is least likely to be rejected. Please note that the 
proposal needs to be changed from where it is today to achieve this fit.
 
 My fist suggestion is to find a way to make a nova virt driver for Hyper, 
which could allow it to be used with all of our current Bay types in Magnum.
 
 Thanks,
 
 Adrian
 
 
  Original message 
 From: Peng Zhao  
 Date: 07/19/2015 5:36 AM (GMT-08:00) 
 To: "OpenStack Development Mailing List (not for usage questions)" 
 
 Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper 
 
 Thanks Jay.
 
 Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I 
just think bay isn't a must in this case, and we don't need nova to provision 
BM hosts, which makes things more complicated imo.
 
 Peng
  
 
 -- Original --
 From:  "Jay Lau";
 Date:  Sun, Jul 19, 2015 10:36 AM
 To:  "OpenStack Development Mailing List (not for usage 
questions)"; 
 Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper
  
 Hong Bin,
 
 I have some online discussion with Peng, seems hyper is now in

Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper

[Peng Zhao]

Adrian,


Let's say someone creates a Hyper bay. The bay will be sth. like 
BM+Hyper+Cinder+Neutron+k8s/mesos/swarm. This is exactly a mini HyperStack. 
What nova does in this scenario is to provision the Hyper+BM hosts. Things like 
LiveMigration, Multi-tenancy, Billing, VPC, Volume, etc., are handled by 
HyperStack, not nova. Therefore, a second core besides nova is inevitable. 
Speaking of duplication, HyperStack leverages Cinder and Neutron, which 
protects ROI.


Looking at the overall puzzle, one of the biggest missing pieces is a solution 
of the native CaaS. And HyperStack wants to fill that gap. Hyper bay is a valid 
case, but more for someone who wants to provides CaaS within their IaaS (nova) 
platform. 


We plan to present a working beta of HyperStack on Tokyo summit. The next step 
is to integrate HyperStack with bay for more advanced deployment.


Best,
Peng
 
-- Original --
From:  "Adrian Otto";
Date:  Sun, Jul 19, 2015 11:11 PM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal  
withHyper

 
 Peng,
 
 
 You are not the first to think this way, and it's one of the reasons we did 
not integrate Containers with OpenStack in a meaningful way a full year 
earlier. Please pay attention closely.
 
 
 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 
1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will 
get killed. Operators matter.
 
 
 2) Cloud Operators need a consistent way to bill for the IaaS services the 
provide. Nova emits all of the RPC messages needed to do this. Having a second 
nova that does this slightly differently is a really annoying problem that will 
make Operators hate  the software. It's better to use nova, have things work 
consistently, and plug in virt drivers to it.
 
 
 3) Creation of a host is only part of the problem. That's the easy part. Nova 
also does a bunch of other things too. For example, say you want to live 
migrate a guest from one host to another. There is already functionality in 
Nova for doing that.
 
 
 4) Resources need to be capacity managed. We call this scheduling. Nova has a 
pluggable scheduler to help with the placement of guests on hosts. Magnum will 
not.
 
 
 5) Hosts in a cloud need to integrate with a number of other services, such as 
an image service, messaging, networking, storage, etc. If you only think in 
terms of host creation, and do something without nova, then you need to 
re-integrate with all of  these things.
 
 
 Now, I probably left out examples of lots of other things that Nova does. What 
I have mentioned us enough to make my point that there are a lot of things that 
Magnum is intentionally NOT doing that we expect to get from Nova, and I will 
block all code  that gratuitously duplicates functionality that I believe 
belongs in Nova. I promised our community I would not duplicate existing 
functionality without a very good reason, and I will keep that promise.
 
 
 Let's find a good way to fit Hyper with OpenStack in a way that best leverages 
what exists today, and is least likely to be rejected. Please note that the 
proposal needs to be changed from where it is today to achieve this fit.
 
 
 My fist suggestion is to find a way to make a nova virt driver for Hyper, 
which could allow it to be used with all of our current Bay types in Magnum.
 
 
 Thanks,
 
 
 Adrian
 
 
  Original message 
 From: Peng Zhao  
 Date: 07/19/2015 5:36 AM (GMT-08:00) 
 To: "OpenStack Development Mailing List (not for usage questions)" 
 
 Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper 
 
 Thanks Jay.
 
 
 Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I 
just think bay isn't a must in this case, and we don't need nova to provision 
BM hosts, which makes things more complicated imo.
 
 
 Peng
   
 
 
  -- Original --
  From:  "Jay Lau";
 Date:  Sun, Jul 19, 2015 10:36 AM
 To:  "OpenStack Development Mailing List (not for usage 
questions)"; 
 
 Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper
 
  
   Hong Bin,
 
 
 I have some online discussion with Peng, seems hyper is now integrating with 
Kubernetes and also have plan integrate with mesos for scheduling. Once mesos 
integration finished, we can treat mesos+hyper as another kind of bay.
 
 
 Thanks
 
 
 2015-07-19 4:15 GMT+08:00 Hongbin Lu :

Peng,
 
 
 
Several questions Here. You mentioned that HyperStack is a single big “bay”. 
Then, who is doing the multi-host scheduling, Hyper or something else? Were you 
suggesting to integrate Hyper with  Magnum directly? Or you were suggesting to 
integrate Hyper with Magnum indirectly (i.e. through k8s, mesos and/or Nova)?
 
 
 
Best regards,
 
Hongbin
 
 
  
From: Peng Zhao [mailto:p...@hyper.sh] 
 Sent: July-17-15 12:34 PM
 To: 

[openstack-dev] periodic-stable job reports (was Re: [Openstack-stable-maint] Stable check of $THINGS failed)

[James Polley]

As exciting as these emails are, I find them a bit unexciting. They don't
give me any context to let me know whether this was a one-off or if
something has been broken for a while.

Long term, having a dashboard (see https://review.openstack.org/#/c/192253/
for the spec) will help us get better visibility into what these jobs are
doing.

But purely to scratch my own itch to get a better handle on what's
happening right now, I grabbed some code Derek H has been using for a
dashboard for the TripleO jobs and bashed at it a bit to make it a bit more
generic. I've put the reports up at http://bruce.jamezpolley.com/reports/

This is *not* a first draft of the dashboard described in the spec, nor a
prototype; it's purely something I pulled together to help me understand
what data we can already pull out of Jenkins to help show the history of
our jobs. But since I've got it online, I figured I may as well share it in
case it's useful to anyone else as well.

If you think having some kind of dashboard would be more useful than these
emails, please go check out that spec so that we can start to make progress
towards something useful.

On Sun, Jul 19, 2015 at 4:22 PM A mailing list for the OpenStack Stable
Branch test reports.  wrote:

> Build failed.
>
> - periodic-ironic-docs-juno
> http://logs.openstack.org/periodic-stable/periodic-ironic-docs-juno/943be60/
> : FAILURE in 5m 51s
> - periodic-ironic-python26-juno
> http://logs.openstack.org/periodic-stable/periodic-ironic-python26-juno/0d25bc4/
> : FAILURE in 6m 36s
> - periodic-ironic-python27-juno
> http://logs.openstack.org/periodic-stable/periodic-ironic-python27-juno/b8bcec1/
> : FAILURE in 6m 51s
> - periodic-ironic-docs-kilo
> http://logs.openstack.org/periodic-stable/periodic-ironic-docs-kilo/47ee329/
> : SUCCESS in 6m 06s
> - periodic-ironic-python27-kilo
> http://logs.openstack.org/periodic-stable/periodic-ironic-python27-kilo/c426b36/
> : SUCCESS in 8m 17s
>
> ___
> Openstack-stable-maint mailing list
> openstack-stable-ma...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova-scheduler] Scheduler sub-group IRC meeting - cancel this week

[Dugger, Donald D]

As discussed at the last meeting we'll cancel this week (blame it on travel for 
the mid-cycle meetup).

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper

[Peng Zhao]

Adrian,


Let's say someone creates a Hyper bay. The bay will be sth. like 
BM+Hyper+Cinder+Neutron+k8s/mesos/swarm. This is exactly a mini HyperStack. 
What nova does in this scenario is to provision the Hyper+BM hosts. Things like 
LiveMigration, Multi-tenancy, Billing, VPC, Volume, etc., are handled by 
HyperStack, not nova. Therefore, a second core besides nova is inevitable. 
Speaking of duplication, HyperStack leverages Cinder and Neutron, which 
protects ROI.


Looking at the overall puzzle, one of the biggest missing pieces is a solution 
of the native CaaS. And HyperStack wants to fill that gap. Hyper bay is a valid 
case, but more for someone who wants to provides CaaS within their IaaS (nova) 
platform.


We plan to present a working beta of HyperStack on Tokyo summit. The next step 
is to integrate HyperStack with bay for more advanced deployment.


Best,
Peng


 
-- Original --
From:  "Adrian Otto";
Date:  Sun, Jul 19, 2015 11:11 PM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal  
withHyper

 
 Peng,
 
 
 You are not the first to think this way, and it's one of the reasons we did 
not integrate Containers with OpenStack in a meaningful way a full year 
earlier. Please pay attention closely.
 
 
 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 
1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will 
get killed. Operators matter.
 
 
 2) Cloud Operators need a consistent way to bill for the IaaS services the 
provide. Nova emits all of the RPC messages needed to do this. Having a second 
nova that does this slightly differently is a really annoying problem that will 
make Operators hate  the software. It's better to use nova, have things work 
consistently, and plug in virt drivers to it.
 
 
 3) Creation of a host is only part of the problem. That's the easy part. Nova 
also does a bunch of other things too. For example, say you want to live 
migrate a guest from one host to another. There is already functionality in 
Nova for doing that.
 
 
 4) Resources need to be capacity managed. We call this scheduling. Nova has a 
pluggable scheduler to help with the placement of guests on hosts. Magnum will 
not.
 
 
 5) Hosts in a cloud need to integrate with a number of other services, such as 
an image service, messaging, networking, storage, etc. If you only think in 
terms of host creation, and do something without nova, then you need to 
re-integrate with all of  these things.
 
 
 Now, I probably left out examples of lots of other things that Nova does. What 
I have mentioned us enough to make my point that there are a lot of things that 
Magnum is intentionally NOT doing that we expect to get from Nova, and I will 
block all code  that gratuitously duplicates functionality that I believe 
belongs in Nova. I promised our community I would not duplicate existing 
functionality without a very good reason, and I will keep that promise.
 
 
 Let's find a good way to fit Hyper with OpenStack in a way that best leverages 
what exists today, and is least likely to be rejected. Please note that the 
proposal needs to be changed from where it is today to achieve this fit.
 
 
 My fist suggestion is to find a way to make a nova virt driver for Hyper, 
which could allow it to be used with all of our current Bay types in Magnum.
 
 
 Thanks,
 
 
 Adrian
 
 
  Original message 
 From: Peng Zhao  
 Date: 07/19/2015 5:36 AM (GMT-08:00) 
 To: "OpenStack Development Mailing List (not for usage questions)" 
 
 Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper 
 
 Thanks Jay.
 
 
 Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I 
just think bay isn't a must in this case, and we don't need nova to provision 
BM hosts, which makes things more complicated imo.
 
 
 Peng
   
 
 
  -- Original --
  From:  "Jay Lau";
 Date:  Sun, Jul 19, 2015 10:36 AM
 To:  "OpenStack Development Mailing List (not for usage 
questions)"; 
 
 Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper
 
  
   Hong Bin,
 
 
 I have some online discussion with Peng, seems hyper is now integrating with 
Kubernetes and also have plan integrate with mesos for scheduling. Once mesos 
integration finished, we can treat mesos+hyper as another kind of bay.
 
 
 Thanks
 
 
 2015-07-19 4:15 GMT+08:00 Hongbin Lu :

Peng,
 
 
 
Several questions Here. You mentioned that HyperStack is a single big “bay”. 
Then, who is doing the multi-host scheduling, Hyper or something else? Were you 
suggesting to integrate Hyper with  Magnum directly? Or you were suggesting to 
integrate Hyper with Magnum indirectly (i.e. through k8s, mesos and/or Nova)?
 
 
 
Best regards,
 
Hongbin
 
 
  
From: Peng Zhao [mailto:p...@hyper.sh] 
 Sent: July-17-15 12:34 PM
 To:

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metalwithHyper

[Peng Zhao]

Hi, Jay, Adrian and Wu,


I have some problems with my mail server to reply Adrian's message. So let me 
write here.


Let's say someone creates a Hyper bay. The bay will be sth. like 
BM+Hyper+Cinder+Neutron+k8s/mesos/swarm. This is exactly a mini HyperStack. 
What nova does in this scenario is to provision the Hyper+BM hosts. Things like 
LiveMigration, Multi-tenancy, Billing, VPC, Volume, etc., are handled by 
HyperStack, not nova. Therefore, a second core besides nova is inevitable. 
Speaking of duplication, HyperStack leverages Cinder and Neutron, which 
protects ROI.


Looking at the overall puzzle, one of the biggest missing pieces is a solution 
of the native CaaS. And HyperStack wants to fill that gap. Hyper bay is a valid 
case, but more for someone who wants to provides CaaS within their IaaS (nova) 
platform.


We plan to present a working beta of HyperStack on Tokyo summit. The next step 
is to integrate HyperStack with bay for more advanced deployment.


Best,
Peng


 

 
 
-- Original --
From:  "Jay Lau";
Date:  Mon, Jul 20, 2015 11:18 AM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run on metalwithHyper

 
The nova guys propose move Hyper to Magnum but not Nova as Hyper cannot fit 
into nova virt driver well.


As Hyper is now integrating with Kubernetes, I think that the integration point 
may be creating a kubernetes hyper bay with ironic driver.


Thanks


2015-07-20 10:00 GMT+08:00 Kai Qiang Wu :
 
Hi Peng,
 
 As @Adrian pointed it out:
 
 My fist suggestion is to find a way to make a nova virt driver for Hyper, 
which could allow it to be used with all of our current Bay types in Magnum. 
 
 
 I remembered you or other guys in your company proposed one bp about nova virt 
driver for Hyper. What's the status of the bp now?
 Is it accepted by nova projects or cancelled ?
 
 
 Thanks
 
 Best Wishes,
 

 Kai Qiang Wu (吴开强  Kennan）
 IBM China System and Technology Lab, Beijing
 
 E-mail: wk...@cn.ibm.com
 Tel: 86-10-82451647
 Address: Building 28(Ring Building), ZhongGuanCun Software Park,  
  No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 
100193
 

 Follow your heart. You are miracle! 
 
 Adrian Otto ---07/19/2015 11:18:02 PM---Peng, You are not the first to think 
this way, and it's one of the reasons we did not integrate Cont
 
 From:  Adrian Otto 
 To:"OpenStack Development Mailing List (not for usage questions)" 

 Date:  07/19/2015 11:18 PM
 Subject:   Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal   
withHyper
 


 
 
 Peng,
 
 You are not the first to think this way, and it's one of the reasons we did 
not integrate Containers with OpenStack in a meaningful way a full year 
earlier. Please pay attention closely.
 
 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 
1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will 
get killed. Operators matter.
 
 2) Cloud Operators need a consistent way to bill for the IaaS services the 
provide. Nova emits all of the RPC messages needed to do this. Having a second 
nova that does this slightly differently is a really annoying problem that will 
make Operators hate the software. It's better to use nova, have things work 
consistently, and plug in virt drivers to it.
 
 3) Creation of a host is only part of the problem. That's the easy part. Nova 
also does a bunch of other things too. For example, say you want to live 
migrate a guest from one host to another. There is already functionality in 
Nova for doing that.
 
 4) Resources need to be capacity managed. We call this scheduling. Nova has a 
pluggable scheduler to help with the placement of guests on hosts. Magnum will 
not.
 
 5) Hosts in a cloud need to integrate with a number of other services, such as 
an image service, messaging, networking, storage, etc. If you only think in 
terms of host creation, and do something without nova, then you need to 
re-integrate with all of these things.
 
 Now, I probably left out examples of lots of other things that Nova does. What 
I have mentioned us enough to make my point that there are a lot of things that 
Magnum is intentionally NOT doing that we expect to get from Nova, and I will 
block all code that gratuitously duplicates functionality that I believe 
belongs in Nova. I promised our community I would not duplicate existing 
functionality without a very good reason, and I will keep that promise.
 
 Let's find a good way to fit Hyper with OpenStack in a way that best leverages 
what exists today, and is least likely to be rejected. Please note that the 
proposal needs to be changed from where it is today to achieve this fit.
 
 My fist suggestion is to find a way to make 

Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetalwithHyper

[Peng Zhao]

I had some problem with my email server today, so you may see several identical 
messages from me in the ML. Please ignore and sorry about that.


Peng
 
 
-- Original --
From:  "Peng Zhao";
Date:  Mon, Jul 20, 2015 11:41 AM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetalwithHyper

 


Hi, Jay, Adrian and Wu,


I have some problems with my mail server to reply Adrian's message. So let me 
write here.


Let's say someone creates a Hyper bay. The bay will be sth. like 
BM+Hyper+Cinder+Neutron+k8s/mesos/swarm. This is exactly a mini HyperStack. 
What nova does in this scenario is to provision the Hyper+BM hosts. Things like 
LiveMigration, Multi-tenancy, Billing, VPC, Volume, etc., are handled by 
HyperStack, not nova. Therefore, a second core besides nova is inevitable. 
Speaking of duplication, HyperStack leverages Cinder and Neutron, which 
protects ROI.


Looking at the overall puzzle, one of the biggest missing pieces is a solution 
of the native CaaS. And HyperStack wants to fill that gap. Hyper bay is a valid 
case, but more for someone who wants to provides CaaS within their IaaS (nova) 
platform.


We plan to present a working beta of HyperStack on Tokyo summit. The next step 
is to integrate HyperStack with bay for more advanced deployment.


Best,
Peng


 

 
 
-- Original --
From:  "Jay Lau";
Date:  Mon, Jul 20, 2015 11:18 AM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run on metalwithHyper

 
The nova guys propose move Hyper to Magnum but not Nova as Hyper cannot fit 
into nova virt driver well.


As Hyper is now integrating with Kubernetes, I think that the integration point 
may be creating a kubernetes hyper bay with ironic driver.


Thanks


2015-07-20 10:00 GMT+08:00 Kai Qiang Wu :
 
Hi Peng,
 
 As @Adrian pointed it out:
 
 My fist suggestion is to find a way to make a nova virt driver for Hyper, 
which could allow it to be used with all of our current Bay types in Magnum. 
 
 
 I remembered you or other guys in your company proposed one bp about nova virt 
driver for Hyper. What's the status of the bp now?
 Is it accepted by nova projects or cancelled ?
 
 
 Thanks
 
 Best Wishes,
 

 Kai Qiang Wu (吴开强  Kennan）
 IBM China System and Technology Lab, Beijing
 
 E-mail: wk...@cn.ibm.com
 Tel: 86-10-82451647
 Address: Building 28(Ring Building), ZhongGuanCun Software Park,  
  No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 
100193
 

 Follow your heart. You are miracle! 
 
 Adrian Otto ---07/19/2015 11:18:02 PM---Peng, You are not the first to think 
this way, and it's one of the reasons we did not integrate Cont
 
 From:  Adrian Otto 
 To:"OpenStack Development Mailing List (not for usage questions)" 

 Date:  07/19/2015 11:18 PM
 Subject:   Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal   
withHyper
 


 
 
 Peng,
 
 You are not the first to think this way, and it's one of the reasons we did 
not integrate Containers with OpenStack in a meaningful way a full year 
earlier. Please pay attention closely.
 
 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 
1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will 
get killed. Operators matter.
 
 2) Cloud Operators need a consistent way to bill for the IaaS services the 
provide. Nova emits all of the RPC messages needed to do this. Having a second 
nova that does this slightly differently is a really annoying problem that will 
make Operators hate the software. It's better to use nova, have things work 
consistently, and plug in virt drivers to it.
 
 3) Creation of a host is only part of the problem. That's the easy part. Nova 
also does a bunch of other things too. For example, say you want to live 
migrate a guest from one host to another. There is already functionality in 
Nova for doing that.
 
 4) Resources need to be capacity managed. We call this scheduling. Nova has a 
pluggable scheduler to help with the placement of guests on hosts. Magnum will 
not.
 
 5) Hosts in a cloud need to integrate with a number of other services, such as 
an image service, messaging, networking, storage, etc. If you only think in 
terms of host creation, and do something without nova, then you need to 
re-integrate with all of these things.
 
 Now, I probably left out examples of lots of other things that Nova does. What 
I have mentioned us enough to make my point that there are a lot of things that 
Magnum is intentionally NOT doing that we expect to get from Nova, and I will 
block all code that gratuitously duplicates functionality that I believe 
belongs in N

Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper

[Peng Zhao]

Adrian,


Let's say someone creates a Hyper bay. The bay will be sth. like 
BM+Hyper+Cinder+Neutron+k8s/mesos/swarm. This is exactly a mini HyperStack. 
What nova does in this scenario is to provision the Hyper+BM hosts. Things like 
LiveMigration, Multi-tenancy, Billing, etc., are handled by HyperStack, not 
nova. Therefore, a second core besides nova is inevitable. 


Looking at the overall puzzle, one of the biggest missing pieces is a solution 
of the native CaaS. And HyperStack wants to fill that gap. Hyper bay is a valid 
case, but more for someone who wants to provides CaaS within their IaaS (nova) 
platform. 


We plan to present a working beta of HyperStack on Tokyo summit. The next step 
is to integrate HyperStack with bay for more advanced deployment.


Best,
Peng
 
-- Original --
From:  "Adrian Otto";
Date:  Sun, Jul 19, 2015 11:11 PM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal  
withHyper

 
 Peng,
 
 
 You are not the first to think this way, and it's one of the reasons we did 
not integrate Containers with OpenStack in a meaningful way a full year 
earlier. Please pay attention closely.
 
 
 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 
1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will 
get killed. Operators matter.
 
 
 2) Cloud Operators need a consistent way to bill for the IaaS services the 
provide. Nova emits all of the RPC messages needed to do this. Having a second 
nova that does this slightly differently is a really annoying problem that will 
make Operators hate  the software. It's better to use nova, have things work 
consistently, and plug in virt drivers to it.
 
 
 3) Creation of a host is only part of the problem. That's the easy part. Nova 
also does a bunch of other things too. For example, say you want to live 
migrate a guest from one host to another. There is already functionality in 
Nova for doing that.
 
 
 4) Resources need to be capacity managed. We call this scheduling. Nova has a 
pluggable scheduler to help with the placement of guests on hosts. Magnum will 
not.
 
 
 5) Hosts in a cloud need to integrate with a number of other services, such as 
an image service, messaging, networking, storage, etc. If you only think in 
terms of host creation, and do something without nova, then you need to 
re-integrate with all of  these things.
 
 
 Now, I probably left out examples of lots of other things that Nova does. What 
I have mentioned us enough to make my point that there are a lot of things that 
Magnum is intentionally NOT doing that we expect to get from Nova, and I will 
block all code  that gratuitously duplicates functionality that I believe 
belongs in Nova. I promised our community I would not duplicate existing 
functionality without a very good reason, and I will keep that promise.
 
 
 Let's find a good way to fit Hyper with OpenStack in a way that best leverages 
what exists today, and is least likely to be rejected. Please note that the 
proposal needs to be changed from where it is today to achieve this fit.
 
 
 My fist suggestion is to find a way to make a nova virt driver for Hyper, 
which could allow it to be used with all of our current Bay types in Magnum.
 
 
 Thanks,
 
 
 Adrian
 
 
  Original message 
 From: Peng Zhao  
 Date: 07/19/2015 5:36 AM (GMT-08:00) 
 To: "OpenStack Development Mailing List (not for usage questions)" 
 
 Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper 
 
 Thanks Jay.
 
 
 Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I 
just think bay isn't a must in this case, and we don't need nova to provision 
BM hosts, which makes things more complicated imo.
 
 
 Peng
   
 
 
  -- Original --
  From:  "Jay Lau";
 Date:  Sun, Jul 19, 2015 10:36 AM
 To:  "OpenStack Development Mailing List (not for usage 
questions)"; 
 
 Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper
 
  
   Hong Bin,
 
 
 I have some online discussion with Peng, seems hyper is now integrating with 
Kubernetes and also have plan integrate with mesos for scheduling. Once mesos 
integration finished, we can treat mesos+hyper as another kind of bay.
 
 
 Thanks
 
 
 2015-07-19 4:15 GMT+08:00 Hongbin Lu :

Peng,
 
 
 
Several questions Here. You mentioned that HyperStack is a single big “bay”. 
Then, who is doing the multi-host scheduling, Hyper or something else? Were you 
suggesting to integrate Hyper with  Magnum directly? Or you were suggesting to 
integrate Hyper with Magnum indirectly (i.e. through k8s, mesos and/or Nova)?
 
 
 
Best regards,
 
Hongbin
 
 
  
From: Peng Zhao [mailto:p...@hyper.sh] 
 Sent: July-17-15 12:34 PM
 To: OpenStack Development Mailing List (not for usage questions)
 
  Subject: Re: [openstack-dev] [magnu

Re: [openstack-dev] [CI] How to set a proxy for zuul.

[Tang Chen]

Hi Asselin, Abhishek,

Thanks for the reply. :)


On 07/19/2015 02:41 AM, Asselin, Ramy wrote:


HI Abhi & Tang,

Sorry I missed this thread. Let me know if you've resolved your issues.

My repo is undergoing migrations to reuse components in 
openstack-infra/puppet-openstackci.


For single-use-nodes, the file you need has been removed here [1]: But 
I see now that it is still needed, or a different function is needed 
based on this version used by infra: [2]. I will explore a solution.


A couple other notes, please use ci-sandbox  [3] instead of sandbox.



OK.

Zuul use behind a proxy: seems you got past this? Could you share your 
solution?




The root cause is that zuul uses a library named paramiko to create 
connection

with low level socket APIs. And it doesn't provide proxy functionary.

I tried to use tools like proxychain, to redirect the zuul connection to 
go through
my proxy. But it doesn't work. If I use proxychain to run zuul service, 
it doesn't

output anything to the log file, and the service will die soon.

I think, there are two solutions:
1. Add proxy functionality to paramiko.
2. Add proxy functionality to zuul. That means, maybe,
zuul does not use paramiko to create connection, but by itself.

Solution 1 is much simpler, so for now, I just modified the source code 
of paramiko.


I'm using python-socksipy package, and modified
/usr/local/lib/python2.7/dist-packages/paramiko/client.py like this:

diff --git a/client.py b/client.py
index 15ff696..d7225ed 100644
--- a/client.py
+++ b/client.py
@@ -24,6 +24,7 @@ from binascii import hexlify
 import getpass
 import os
 import socket
+import socks
 import warnings
 import pdb

@@ -235,6 +236,7 @@ class SSHClient (ClosingContextManager):
 ``gss_deleg_creds`` and ``gss_host`` arguments.
 """

+   """
 if not sock:
 for (family, socktype, proto, canonname, sockaddr) in 
socket.getaddrinfo(hostname, port, socket.AF_UNSPEC, socket.SOCK_STREAM):

 if socktype == socket.SOCK_STREAM:
@@ -251,6 +253,13 @@ class SSHClient (ClosingContextManager):
 except:
 pass
 retry_on_signal(lambda: sock.connect(addr))
+   """
+
+   if not sock:
+   sock = socks.socksocket()
+   sock.setproxy(socks.PROXY_TYPE_SOCKS5, "MY_PROXY_IP", 
MY_PROXY_PORT, username="XXX", password="XXX")


  # This is review.openstack.org
+   addr = ('104.130.159.134', 29418)
+   retry_on_signal(lambda: sock.connect(addr))

 t = self._transport = Transport(sock, gss_kex=gss_kex, 
gss_deleg_creds=gss_deleg_creds)

 t.use_compression(compress=compress)


Of course, this is just a draft. It is only for my case, not for all.


BTW, I'm now working on Fujitsu CI System, and really want to join into 
the development of openstack-infra.
I think the proxy functionality is necessary for many companies. So if 
you are planing to add the proxy support,

I think I can help.

Thanks. :)

Also, feel free to join 3^rd party ci IRC  meetings on freenode [4]. 
It's a great place to ask questions and meet others setting up or 
maintaining these systems.


Thanks,

Ramy

IRC: asselin

[1] 
https://github.com/rasselin/os-ext-testing/commit/dafe822be7813522a6c7361993169da20b37ffb7


[2] 
https://github.com/openstack-infra/project-config/blob/master/zuul/openstack_functions.py


[3] http://git.openstack.org/cgit/openstack-dev/ci-sandbox/

[4] http://eavesdrop.openstack.org/#Third_Party_Meeting

*From:*Abhishek Shrivastava [mailto:abhis...@cloudbyte.com]
*Sent:* Monday, July 13, 2015 11:51 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [CI] How to set a proxy for zuul.

Also if you want to change it you will need to talk with Asselin Ramy 
who is the owner of the repo you followed.


On Tue, Jul 14, 2015 at 12:18 PM, Abhishek Shrivastava 
mailto:abhis...@cloudbyte.com>> wrote:


Basically it is not required, and if you see
/etc/jenkins_jobs/config folder you will find one
dsvm-cinder-tempest.yaml which is to be used basically not
examples.yaml. So its not an issue.

On Tue, Jul 14, 2015 at 12:07 PM, Tang Chen
mailto:tangc...@cn.fujitsu.com>> wrote:

On 07/14/2015 01:46 PM, Abhishek Shrivastava wrote:

Instead of it use reusable_node option.


Thanks. Problem resolved. :)

BTW, single_use_node is written in layout.yaml by default.
If it doesn't exist anymore, do we need a patch to fix it ?

For someone who uses CI for the first time, it is really a
problem..

And also, if I want to post patch for zuul, where should I
post the patch ?

Thanks.




On Tue, Jul 14, 2015 at 9:12 AM, Tang Chen
mailto:tangc...@cn.fujitsu.com>>
wrote:

Hi Abhishek, All,

I found the problem.

 

Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper

[Peng Zhao]

Adrian,


Let's say someone creates a Hyper bay. The bay will be sth. like 
BM+Hyper+Cinder+Neutron+k8s/mesos/swarm. This is exactly a mini HyperStack. 
What nova does in this scenario is to provision the Hyper+BM hosts. Things like 
LiveMigration, Multi-tenancy, Billing, VPC, Volume, etc., are handled by 
HyperStack, not nova. Therefore, a second core besides nova is inevitable. 
Speaking of duplication, HyperStack leverages Cinder and Neutron, which 
protects ROI.


Looking at the overall puzzle, one of the biggest missing pieces is a solution 
of the native CaaS. And HyperStack wants to fill that gap. Hyper bay is a valid 
case, but more for someone who wants to provides CaaS within their IaaS (nova) 
platform.


We plan to present a working beta of HyperStack on Tokyo summit. The next step 
is to integrate HyperStack with bay for more advanced deployment.


Best,
Peng

 
 
-- Original --
From:  "Adrian Otto";
Date:  Sun, Jul 19, 2015 11:11 PM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal  
withHyper

 
 Peng,
 
 
 You are not the first to think this way, and it's one of the reasons we did 
not integrate Containers with OpenStack in a meaningful way a full year 
earlier. Please pay attention closely.
 
 
 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 
1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will 
get killed. Operators matter.
 
 
 2) Cloud Operators need a consistent way to bill for the IaaS services the 
provide. Nova emits all of the RPC messages needed to do this. Having a second 
nova that does this slightly differently is a really annoying problem that will 
make Operators hate  the software. It's better to use nova, have things work 
consistently, and plug in virt drivers to it.
 
 
 3) Creation of a host is only part of the problem. That's the easy part. Nova 
also does a bunch of other things too. For example, say you want to live 
migrate a guest from one host to another. There is already functionality in 
Nova for doing that.
 
 
 4) Resources need to be capacity managed. We call this scheduling. Nova has a 
pluggable scheduler to help with the placement of guests on hosts. Magnum will 
not.
 
 
 5) Hosts in a cloud need to integrate with a number of other services, such as 
an image service, messaging, networking, storage, etc. If you only think in 
terms of host creation, and do something without nova, then you need to 
re-integrate with all of  these things.
 
 
 Now, I probably left out examples of lots of other things that Nova does. What 
I have mentioned us enough to make my point that there are a lot of things that 
Magnum is intentionally NOT doing that we expect to get from Nova, and I will 
block all code  that gratuitously duplicates functionality that I believe 
belongs in Nova. I promised our community I would not duplicate existing 
functionality without a very good reason, and I will keep that promise.
 
 
 Let's find a good way to fit Hyper with OpenStack in a way that best leverages 
what exists today, and is least likely to be rejected. Please note that the 
proposal needs to be changed from where it is today to achieve this fit.
 
 
 My fist suggestion is to find a way to make a nova virt driver for Hyper, 
which could allow it to be used with all of our current Bay types in Magnum.
 
 
 Thanks,
 
 
 Adrian
 
 
  Original message 
 From: Peng Zhao  
 Date: 07/19/2015 5:36 AM (GMT-08:00) 
 To: "OpenStack Development Mailing List (not for usage questions)" 
 
 Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper 
 
 Thanks Jay.
 
 
 Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I 
just think bay isn't a must in this case, and we don't need nova to provision 
BM hosts, which makes things more complicated imo.
 
 
 Peng
   
 
 
  -- Original --
  From:  "Jay Lau";
 Date:  Sun, Jul 19, 2015 10:36 AM
 To:  "OpenStack Development Mailing List (not for usage 
questions)"; 
 
 Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper
 
  
   Hong Bin,
 
 
 I have some online discussion with Peng, seems hyper is now integrating with 
Kubernetes and also have plan integrate with mesos for scheduling. Once mesos 
integration finished, we can treat mesos+hyper as another kind of bay.
 
 
 Thanks
 
 
 2015-07-19 4:15 GMT+08:00 Hongbin Lu :

Peng,
 
 
 
Several questions Here. You mentioned that HyperStack is a single big “bay”. 
Then, who is doing the multi-host scheduling, Hyper or something else? Were you 
suggesting to integrate Hyper with  Magnum directly? Or you were suggesting to 
integrate Hyper with Magnum indirectly (i.e. through k8s, mesos and/or Nova)?
 
 
 
Best regards,
 
Hongbin
 
 
  
From: Peng Zhao [mailto:p...@hyper.sh] 
 Sent: July-17-15 12:34 PM
 To

Re: [openstack-dev] [openstack-infra] [CI] [tempest] Tempest tests failing with SSH timeout.

[Abhishek Shrivastava]

This is ok for the services it will install, but how can we also restrict
the downloading of all the projects(i.e; downloading only required
projects) ?

On Sun, Jul 19, 2015 at 11:39 PM, Asselin, Ramy  wrote:

>  There are two ways that I know of to customize what services are run:
>
>  1.  Setup your own feature matrix [1]
>
> 2.  Override enabled services [2]
>
>
>
> Option 2 is probably what you’re looking for.
>
>
>
> [1]
> http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate-wrap.sh#n152
>
> [2]
> http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate.sh#n76
>
>
>
> *From:* Abhishek Shrivastava [mailto:abhis...@cloudbyte.com]
> *Sent:* Sunday, July 19, 2015 10:37 AM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [openstack-infra] [CI] [tempest] Tempest
> tests failing with SSH timeout.
>
>
>
> Hi Ramy,
>
>
>
> Thanks for the suggestion. One more thing I need to ask, as I have have
> setup one more CI so is there any way that we can decide that only required
> projects should get downloaded and installed during devstack installation
> dynamically. As I see no such things that can be done to devstack-gate
> scripts so the following scenario can be achieved.
>
>
>
> On Sun, Jul 19, 2015 at 8:38 PM, Asselin, Ramy 
> wrote:
>
>  Just the export I mentioned:
>
> export DEVSTACK_GATE_NEUTRON=1
>
> Devstack-gate scripts will do the right thing when it sees that set. You
> can see plenty of examples here [1].
>
>
>
> Ramy
>
>
>
> [1]
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/devstack-gate.yaml#n467
>
>
>
> *From:* Abhishek Shrivastava [mailto:abhis...@cloudbyte.com]
> *Sent:* Sunday, July 19, 2015 2:24 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [openstack-infra] [CI] [tempest] Tempest
> tests failing with SSH timeout.
>
>
>
> Hi Ramy,
>
>
>
> Thanks for the suggestion but since I am not including the neutron
> project, so downloading and including it will require any additional
> configuration in devstack-gate or not?
>
>
>
> On Sat, Jul 18, 2015 at 11:41 PM, Asselin, Ramy 
> wrote:
>
>  We ran into this issue as well. I never found the root cause, but I
> found a work-around: Use neutron-networking instead of the default
> nova-networking.
>
>
>
> If you’re using devstack-gate, it’s as  simple as:
>
> export DEVSTACK_GATE_NEUTRON=1
>
>
>
> Then run the job as usual.
>
>
>
> Ramy
>
>
>
> *From:* Abhishek Shrivastava [mailto:abhis...@cloudbyte.com]
> *Sent:* Friday, July 17, 2015 9:15 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [openstack-infra] [CI] [tempest] Tempest tests
> failing with SSH timeout.
>
>
>
> Hi Folks,
>
>
>
> In my CI I see the following tempest tests failure for a past couple of
> days.
>
> ·
> tempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario
>  [361.274316s] ... FAILED
>
> ·
> tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
>  [320.122458s] ... FAILED
>
> ·
> tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern
>  [317.399342s] ... FAILED
>
> ·
> tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_compute_with_volumes
>  [257.858272s] ... FAILED
>
>  The failure logs are always the same every time, i.e;
>
>
>
>  *03:34:09* 2015-07-17 03:21:13,256 9505 ERROR
> [tempest.scenario.manager] (TestVolumeBootPattern:test_volume_boot_pattern) 
> Initializing SSH connection to 172.24.5.1 failed. Error: Connection to the 
> 172.24.5.1 via SSH timed out.
>
> *03:34:09* User: cirros, Password: None
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager 
> Traceback (most recent call last):
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   
> File "tempest/scenario/manager.py", line 312, in get_remote_client
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager
>  linux_client.validate_authentication()
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   
> File "tempest/common/utils/linux/remote_client.py", line 62, in 
> validate_authentication
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager
>  self.ssh_client.test_connection_auth()
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   
> File 
> "/opt/stack/new/tempest/.tox/all/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
>  line 151, in test_connection_auth
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager
>  connection = self._get_ssh_connection()
>
> *03:34:09* 2015-07-17 03:21:13.256 9505 ERROR tempest.scenario.manager   
> File 
> "/opt/stack/new/tempest/.tox/all/local/lib/p

Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper

[Peng Zhao]

Adrian,


Let's say someone creates a Hyper bay. The bay will be sth. like 
BM+Hyper+Cinder+Neutron+k8s/mesos/swarm. This is exactly a mini HyperStack. 
What nova does in this scenario is to provision the Hyper+BM hosts. Things like 
LiveMigration, Multi-tenancy, Billing, VPC, Volume, etc., are handled by 
HyperStack, not nova. Therefore, a second core besides nova is inevitable. 
Speaking of duplication, HyperStack leverages Cinder and Neutron, which 
protects ROI.


Looking at the overall puzzle, one of the biggest missing pieces is a solution 
of the native CaaS. And HyperStack wants to fill that gap. Hyper bay is a valid 
case, but more for someone who wants to provides CaaS within their IaaS (nova) 
platform.


We plan to present a working beta of HyperStack on Tokyo summit. The next step 
is to integrate HyperStack with bay for more advanced deployment.


Best,
Peng

 
 
-- Original --
From:  "Adrian Otto";
Date:  Sun, Jul 19, 2015 11:11 PM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal  
withHyper

 
 Peng,
 
 
 You are not the first to think this way, and it's one of the reasons we did 
not integrate Containers with OpenStack in a meaningful way a full year 
earlier. Please pay attention closely.
 
 
 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 
1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will 
get killed. Operators matter.
 
 
 2) Cloud Operators need a consistent way to bill for the IaaS services the 
provide. Nova emits all of the RPC messages needed to do this. Having a second 
nova that does this slightly differently is a really annoying problem that will 
make Operators hate  the software. It's better to use nova, have things work 
consistently, and plug in virt drivers to it.
 
 
 3) Creation of a host is only part of the problem. That's the easy part. Nova 
also does a bunch of other things too. For example, say you want to live 
migrate a guest from one host to another. There is already functionality in 
Nova for doing that.
 
 
 4) Resources need to be capacity managed. We call this scheduling. Nova has a 
pluggable scheduler to help with the placement of guests on hosts. Magnum will 
not.
 
 
 5) Hosts in a cloud need to integrate with a number of other services, such as 
an image service, messaging, networking, storage, etc. If you only think in 
terms of host creation, and do something without nova, then you need to 
re-integrate with all of  these things.
 
 
 Now, I probably left out examples of lots of other things that Nova does. What 
I have mentioned us enough to make my point that there are a lot of things that 
Magnum is intentionally NOT doing that we expect to get from Nova, and I will 
block all code  that gratuitously duplicates functionality that I believe 
belongs in Nova. I promised our community I would not duplicate existing 
functionality without a very good reason, and I will keep that promise.
 
 
 Let's find a good way to fit Hyper with OpenStack in a way that best leverages 
what exists today, and is least likely to be rejected. Please note that the 
proposal needs to be changed from where it is today to achieve this fit.
 
 
 My fist suggestion is to find a way to make a nova virt driver for Hyper, 
which could allow it to be used with all of our current Bay types in Magnum.
 
 
 Thanks,
 
 
 Adrian
 
 
  Original message 
 From: Peng Zhao  
 Date: 07/19/2015 5:36 AM (GMT-08:00) 
 To: "OpenStack Development Mailing List (not for usage questions)" 
 
 Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper 
 
 Thanks Jay.
 
 
 Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I 
just think bay isn't a must in this case, and we don't need nova to provision 
BM hosts, which makes things more complicated imo.
 
 
 Peng
   
 
 
  -- Original --
  From:  "Jay Lau";
 Date:  Sun, Jul 19, 2015 10:36 AM
 To:  "OpenStack Development Mailing List (not for usage 
questions)"; 
 
 Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper
 
  
   Hong Bin,
 
 
 I have some online discussion with Peng, seems hyper is now integrating with 
Kubernetes and also have plan integrate with mesos for scheduling. Once mesos 
integration finished, we can treat mesos+hyper as another kind of bay.
 
 
 Thanks
 
 
 2015-07-19 4:15 GMT+08:00 Hongbin Lu :

Peng,
 
 
 
Several questions Here. You mentioned that HyperStack is a single big “bay”. 
Then, who is doing the multi-host scheduling, Hyper or something else? Were you 
suggesting to integrate Hyper with  Magnum directly? Or you were suggesting to 
integrate Hyper with Magnum indirectly (i.e. through k8s, mesos and/or Nova)?
 
 
 
Best regards,
 
Hongbin
 
 
  
From: Peng Zhao [mailto:p...@hyper.sh] 
 Sent: July-17-15 12:34 PM
 To

Re: [openstack-dev] [CI] How to set a proxy for zuul.

[Tang Chen]

On 07/19/2015 02:41 AM, Asselin, Ramy wrote:


HI Abhi & Tang,

Sorry I missed this thread. Let me know if you've resolved your issues.

My repo is undergoing migrations to reuse components in 
openstack-infra/puppet-openstackci.


For single-use-nodes, the file you need has been removed here [1]: But 
I see now that it is still needed, or a different function is needed 
based on this version used by infra: [2]. I will explore a solution.


A couple other notes, please use ci-sandbox  [3] instead of sandbox.



BTW, in /etc/zuul/layout.yaml, it is ci-sandbox.

But in /etc/jenkins_jobs/config/projects.yaml, it is configured to sandbox.

Not a big deal, but for someone who uses CI for the first time, it costs 
some time to solve it.


Thanks. :)

Zuul use behind a proxy: seems you got past this? Could you share your 
solution?


Also, feel free to join 3^rd party ci IRC  meetings on freenode [4]. 
It's a great place to ask questions and meet others setting up or 
maintaining these systems.


Thanks,

Ramy

IRC: asselin

[1] 
https://github.com/rasselin/os-ext-testing/commit/dafe822be7813522a6c7361993169da20b37ffb7


[2] 
https://github.com/openstack-infra/project-config/blob/master/zuul/openstack_functions.py


[3] http://git.openstack.org/cgit/openstack-dev/ci-sandbox/

[4] http://eavesdrop.openstack.org/#Third_Party_Meeting

*From:*Abhishek Shrivastava [mailto:abhis...@cloudbyte.com]
*Sent:* Monday, July 13, 2015 11:51 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [CI] How to set a proxy for zuul.

Also if you want to change it you will need to talk with Asselin Ramy 
who is the owner of the repo you followed.


On Tue, Jul 14, 2015 at 12:18 PM, Abhishek Shrivastava 
mailto:abhis...@cloudbyte.com>> wrote:


Basically it is not required, and if you see
/etc/jenkins_jobs/config folder you will find one
dsvm-cinder-tempest.yaml which is to be used basically not
examples.yaml. So its not an issue.

On Tue, Jul 14, 2015 at 12:07 PM, Tang Chen
mailto:tangc...@cn.fujitsu.com>> wrote:

On 07/14/2015 01:46 PM, Abhishek Shrivastava wrote:

Instead of it use reusable_node option.


Thanks. Problem resolved. :)

BTW, single_use_node is written in layout.yaml by default.
If it doesn't exist anymore, do we need a patch to fix it ?

For someone who uses CI for the first time, it is really a
problem..

And also, if I want to post patch for zuul, where should I
post the patch ?

Thanks.




On Tue, Jul 14, 2015 at 9:12 AM, Tang Chen
mailto:tangc...@cn.fujitsu.com>>
wrote:

Hi Abhishek, All,

I found the problem.

My /etc/zuul/layout/layout.yaml has the following config:

jobs:
  - name: ^dsvm-tempest.*$
parameter-function: single_use_node

But in _parseConfig() in zuul/scheduler.py, it failed
to find single_use_node().

fname =
config_job.get('parameter-function', None)
if fname:
func = config_env.get(fname, None)
if not func:
raise Exception("Unable to find
function %s" % fname)

So projects section was not parsed.

Does anyone know why ?

Thanks.




On 07/14/2015 10:54 AM, Tang Chen wrote:

Hi Abhishek,

I printed the self.layout.projects in
zuul/scheduler.py, it is empty.
So the project was not found.

But I did do the *jenkins-jobs --flush-cache
update* */etc/jenkins_jobs/config/*
And I did configure openstack-dev/sandbox in
layout.yaml.

Do you have any idea what's wrong here ?

Thanks.

On 07/13/2015 05:58 PM, Tang Chen wrote:

On 07/13/2015 04:35 PM, Abhishek Shrivastava
wrote:

Updating jobs using "*sudo jenkins-jobs
--flush-cache update
/etc/jenkins_jobs/config/". *Also update
the myvendor in examples.yaml


Sorry, I updated the jobs, restart the whole
machine. But it still doesn't work.

By the way, there is no vendor in examples.yaml.

It is still this error: Project
openstack-dev/sandbox not found

Anything else should I pay attention to?

Thanks.


On Mon, Jul 13, 20

Re: [openstack-dev] [CI] How to set a proxy for zuul.

[Abhishek Shrivastava]

Hi Tang,



On Mon, Jul 20, 2015 at 11:18 AM, Tang Chen  wrote:

>  Hi Asselin, Abhishek,
>
> Thanks for the reply. :)
>
>
> On 07/19/2015 02:41 AM, Asselin, Ramy wrote:
>
>  HI Abhi & Tang,
>
>
>
> Sorry I missed this thread. Let me know if you’ve resolved your issues.
>
>
>
> My repo is undergoing migrations to reuse components in
> openstack-infra/puppet-openstackci.
>
>
>
> For single-use-nodes, the file you need has been removed here [1]: But I
> see now that it is still needed, or a different function is needed based on
> this version used by infra: [2]. I will explore a solution.
>
>
>
> A couple other notes, please use ci-sandbox  [3] instead of sandbox.
>
>
> OK.
>
>
>
> Zuul use behind a proxy: seems you got past this? Could you share your
> solution?
>
>
> The root cause is that zuul uses a library named paramiko to create
> connection
> with low level socket APIs. And it doesn't provide proxy functionary.
>
> I tried to use tools like proxychain, to redirect the zuul connection to
> go through
> my proxy. But it doesn't work. If I use proxychain to run zuul service, it
> doesn't
> output anything to the log file, and the service will die soon.
>
> I think, there are two solutions:
> 1. Add proxy functionality to paramiko.
> 2. Add proxy functionality to zuul. That means, maybe,
> zuul does not use paramiko to create connection, but by itself.
>
> Solution 1 is much simpler, so for now, I just modified the source code of
> paramiko.
>
> I'm using python-socksipy package, and modified
> /usr/local/lib/python2.7/dist-packages/paramiko/client.py like this:
>
> diff --git a/client.py b/client.py
> index 15ff696..d7225ed 100644
> --- a/client.py
> +++ b/client.py
> @@ -24,6 +24,7 @@ from binascii import hexlify
>  import getpass
>  import os
>  import socket
> +import socks
>  import warnings
>  import pdb
>
> @@ -235,6 +236,7 @@ class SSHClient (ClosingContextManager):
>  ``gss_deleg_creds`` and ``gss_host`` arguments.
>  """
>
> +   """
>  if not sock:
>  for (family, socktype, proto, canonname, sockaddr) in
> socket.getaddrinfo(hostname, port, socket.AF_UNSPEC, socket.SOCK_STREAM):
>  if socktype == socket.SOCK_STREAM:
> @@ -251,6 +253,13 @@ class SSHClient (ClosingContextManager):
>  except:
>  pass
>  retry_on_signal(lambda: sock.connect(addr))
> +   """
> +
> +   if not sock:
> +   sock = socks.socksocket()
> +   sock.setproxy(socks.PROXY_TYPE_SOCKS5, "MY_PROXY_IP",
> MY_PROXY_PORT, username="XXX", password="XXX")
>
>   # This is review.openstack.org
> +   addr = ('104.130.159.134', 29418)
> +   retry_on_signal(lambda: sock.connect(addr))
>
>  t = self._transport = Transport(sock, gss_kex=gss_kex,
> gss_deleg_creds=gss_deleg_creds)
>  t.use_compression(compress=compress)
>
>
> ​Quite a nice explanation +1 for all the things you have done. Just one
more thing to ask, have you made your slave node static?​



> Of course, this is just a draft. It is only for my case, not for all.
>
>
> BTW, I'm now working on Fujitsu CI System, and really want to join into
> the development of openstack-infra.
> I think the proxy functionality is necessary for many companies. So if you
> are planing to add the proxy support,
> I think I can help.
>
> Thanks. :)
>
>
>
> Also, feel free to join 3rd party ci IRC  meetings on freenode [4]. It’s
> a great place to ask questions and meet others setting up or maintaining
> these systems.
>
>
>
> Thanks,
>
> Ramy
>
> IRC: asselin
>
>
>
> [1]
> https://github.com/rasselin/os-ext-testing/commit/dafe822be7813522a6c7361993169da20b37ffb7
>
> [2]
> https://github.com/openstack-infra/project-config/blob/master/zuul/openstack_functions.py
>
> [3] http://git.openstack.org/cgit/openstack-dev/ci-sandbox/
>
> [4] http://eavesdrop.openstack.org/#Third_Party_Meeting
>
>
>
>
>
>
>
> *From:* Abhishek Shrivastava [mailto:abhis...@cloudbyte.com
> ]
> *Sent:* Monday, July 13, 2015 11:51 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [CI] How to set a proxy for zuul.
>
>
>
> Also if you want to change it you will need to talk with Asselin Ramy who
> is the owner of the repo you followed.
>
>
>
> On Tue, Jul 14, 2015 at 12:18 PM, Abhishek Shrivastava <
> abhis...@cloudbyte.com> wrote:
>
>  ​Basically it is not required, and if you see /etc/jenkins_jobs/config
> folder you will find one dsvm-cinder-tempest.yaml which is to be used
> basically not examples.yaml. So its not an issue.​
>
>
>
> On Tue, Jul 14, 2015 at 12:07 PM, Tang Chen 
> wrote:
>
>
>
> On 07/14/2015 01:46 PM, Abhishek Shrivastava wrote:
>
>  Instead of it use reusable_node option.
>
>
> Thanks. Problem resolved. :)
>
> BTW, single_use_node is written in layout.yaml by default.
> If it doesn't exist anymore, do we need a patch to fix it ?
>
> For someone who uses CI for the 

Re: [openstack-dev] [CI] How to set a proxy for zuul.

[Tang Chen]

Hi Abhishek,

On 07/20/2015 02:09 PM, Abhishek Shrivastava wrote:

..



Quite a nice explanation +1 for all the things you have done. Just one 
more thing to ask, have you made your slave node static?




Not yet. And I haven't made my nodepool. :)
These are my next step.

But before I start to do that, I'm have to learn how to write a Jenkins 
job.

And make my CI test program work properly.

Thanks.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder]Question for availability_zone of cinder

[hao wang]

Thanks Duncan. I was thinking if we can use volume_type instead of
available_zone totally. I mean whatever you have, one or many c-vol node,
you can just use volume_type to schedule volume creation on different
backends without using AZs at all.  I also think available_zone is useless
if there is only one c-vol node existing. So is it possible that we remove
it from cinder?
Or we should tell admin/users clearly that the available_zone should be
used under multiple c-vol nodes situation.

2015-07-20 6:36 GMT+08:00 Duncan Thomas :

> So this has come up a few times. My question is, does having one node
> serving several backends really form multiple AZs? Not really, the c-vol
> node becomes a single point of failure.
>
> There might be value in moving the AZ setting into the per-backend
> configurables, if it doesn't work there already, for testing if nothing
> else, but I do worry that it encorages people to misunderstand or worse
> intentionally fake multiple AZs.
>
>
> On 19 July 2015 at 05:19, hao wang  wrote:
>
>> Hi  stackers,
>>
>> I found now cinder only can configure one storage_availability_zone for
>> cinder-volume. If using multi-backend in one cinder-volume node, could we
>> have different AZ for each backend? So that we can specify each backend as
>> a AZ and create volume in this AZ.
>>
>> Regards,
>> Wang Hao
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> --
> Duncan Thomas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best Wishes For You!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron]Unit test failed but devstack was okay

[Zhi Chang]

Hi, all.
I write a unit test in devstack and runs all tests okay on my environment. 
Why does Jenkins failed when I upload my patch into review? The patch is 
https://review.openstack.org/#/c/199588/. The failed test was named 
"neutron.tests.unit.plugins.embrane.test_embrane_neutron_plugin.TestEmbraneSubnetsV2.test_subnet_lifecycle_dns_retains_order".
 But it is okay on my environment. Could someone tells me the reason? What 
should I do?




Thanks
Zhi Chang__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova]Need suggestion for fixing bug 1466451(pci_passthrough_whitelist configration)

[Wen Zhi WW Yu]

Hi,

I'm working on bug 1466451, which is about the invalid configuration of
property "pci_passthrough_whitelist" in nova.

My proposal for fixing this issue is:

Before start nova-compute sevice, do a precheck against /etc/nova/nova.conf
file, if the value format of "pci_passthrough_whitelist" doesn't match with
any of following ones, the configuration will be recongnized as invalid:

1. Only "devname":
pci_passthrough_whitelist = {"devname":"eth0",
"physical_network":"physnet1"}
2. Only "address":
pci_passthrough_whitelist = {"address":"*:0a:00.*",
"physical_network":"physnet1"}
3. Only "vendor_id + product_id":
pci_passthrough_whitelist = {"vendor_id":"1137","product_id":"0071",
"physical_network":"physnet1"}
4. "devname" and "address":
pci_passthrough_whitelist = {"devname":"eth0", "address":"*:0a:00.*",
"physical_network":"physnet1"}
5. "devname" and "vendor_id+product_id'":
pci_passthrough_whitelist = {"devname":"eth0",
"vendor_id":"1137","product_id":"0071", "physical_network":"physnet1"}
6. "address" and "vendor_id+product_id'":
pci_passthrough_whitelist = {"address":"*:0a:00.*",
"vendor_id":"1137","product_id":"0071", "physical_network":"physnet1"}
7. All of them:
pci_passthrough_whitelist = {"devname":"eth0", "address":"*:0a:00.*",
"vendor_id":"1137", "product_id":"0071", "physical_network":"physnet1"}

Now I need some suggestion to proceed:

1. Do I need to register a blueprint for fixing this issue?
2. What kind of action is appropriate when the invalid configuration of
pci_passthrough_whitelist is dectected, logging the error or raising the
error?

Thanks in advance!

Best Regards,
Yu WenZhi(余文治）
OpenStack on Power Development, IBM Shanghai
2F, 399 Keyuan Rd, Zhangjiang Chuangxin No. 10 Building, Zhangjiang High
Tech Park Shanghai__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [CI] How to set a proxy for zuul.

[Abhishek Shrivastava]

For writing a Jenkins Job you can refer "*dsvm-cinder-driver.yaml.sample*"
as a reference.

On Mon, Jul 20, 2015 at 12:04 PM, Tang Chen  wrote:

>  Hi Abhishek,
>
> On 07/20/2015 02:09 PM, Abhishek Shrivastava wrote:
>
> ..
>
>
>
>   ​ Quite a nice explanation +1 for all the things you have done. Just
> one more thing to ask, have you made your slave node static?​
>
>
> Not yet. And I haven't made my nodepool. :)
> These are my next step.
>
> But before I start to do that, I'm have to learn how to write a Jenkins
> job.
> And make my CI test program work properly.
>
> Thanks.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 


*Thanks & Regards,*
*Abhishek*
*Cloudbyte Inc. *
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev