Re: [openstack-dev] [nova] Priority resizing instance on same host

[Jesse Pretorius]

On Thursday, February 12, 2015, Rui Chen  wrote:
>
> Currently, resizing instance cause migrating from the host that the
> instance run on to other host, but maybe the current host is suitable for
> new flavor. Migrating will lead to copy image between hosts if no shared
> storage, it waste time.
> I think that priority resizing instance on the current host may be
> better if the host is suitable.
> The logic like this:
>
> if CONF.allow_resize_to_same_host:
> filte current host
> if suitable:
>resize on current host
> else:
>select a host
>resize on the host
>
> I don't know whether there have been some discussion about this
> question. Please let me know what do you think. If the idea is no problem,
> maybe I can register a blueprint to implement it.
>

But the nova.conf flag for that already exists?

What I would suggest, however, is that some logic is put in to determine
whether the disk size remains the same while the cpu/ram size is changing -
if so, then resize the instance on the host without the disk snapshot and
copy.


-- 
Jesse Pretorius
mobile: +44 7586 906045
email: jesse.pretor...@gmail.com
skype: jesse.pretorius
__
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] Priority resizing instance on same host

[Rui Chen]

Hi:

Currently, resizing instance cause migrating from the host that the
instance run on to other host, but maybe the current host is suitable for
new flavor. Migrating will lead to copy image between hosts if no shared
storage, it waste time.
I think that priority resizing instance on the current host may be
better if the host is suitable.
The logic like this:

if CONF.allow_resize_to_same_host:
filte current host
if suitable:
   resize on current host
else:
   select a host
   resize on the host

I don't know whether there have been some discussion about this
question. Please let me know what do you think. If the idea is no problem,
maybe I can register a blueprint to implement it.

Best Regards.
__
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] [Manila]Question about gateway-mediated-with-ganesha

[Deepak Shetty]

On Thu, Feb 12, 2015 at 7:32 AM, Li, Chen  wrote:

>  Yes,  I’m asking about plans for gateway-mediated-with-ganesha.
>
> I want to know what would you do to achieve “*And later the Ganesha core
> would be extended to use the infrastructure used by generic driver to
> provide network separated multi-tenancy. The core would manage Ganesha
> service running in the service VMs, and the VMs themselves that reside in
> share networks.*”
>
> Because after I studied current infrastructure of generic driver,  I guess
> directly use it for Ganesha would now work.
>

You may be right, but we cannot be sure until we test, qualify, validate
against a real setup. Also there is no infrastrucutre to run Ganesha in
service VM, so the major work would be to bundle Ganesha and make it
available as a service VM image and use that image instead of the existing
service VM image. Csaba and Ramana (in CC) can comment more on this.


>  This is what I have learned from code:
>
>
>
> Manila create service_network and service_subnet based on configurations
> in manila.conf:
>
> *service_network_name =  manila_service_network*
>
> service_network_cidr =  10.254.0.0/16
>

So even if the service_network or service_subnet is not created, this
information from the conf file can be used by the network admin to
bridge/connect the service network (whenever it comes up) with the
host/provider network.


>  service_network_division_mask = 28
>
>
>
> service_network is created when manila-share service start.
>
> service_subnet is created when manila-share service  get a share create
> command, and no share-server exists for current share-network.
>
> ð  Service_subnet create at the same time as share-server created.
>

Thanks for clarifying.

thanx,
deepak
__
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] Feature Freeze Exception Request (libvirt vhostuser vif driver)

[Nikola Đipanov]

On 02/09/2015 11:04 AM, Czesnowicz, Przemyslaw wrote:
> Hi,  
> 
>  
> 
> I would like to request FFE for vhostuser vif driver.
> 
>  
> 
> 2 reviews :
> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/libvirt-vif-vhost-user,n,z
> 
>  
> 
> BP: https://blueprints.launchpad.net/nova/+spec/libvirt-vif-vhost-user
> 
> Spec: https://review.openstack.org/138736
> 
>  
> 
> Blueprint was approved but it’s status was changed because of FF.
> 
> Vhostuser is a Qemu feature that allows fastpath into the VM for
> userspace vSwitches.
> 
> The changes are small and mostly contained to libvirt driver.
> 
> Vhostuser support was proposed for Juno by Snabb switch guys but didn’t
> make it,
> 
> this implementation supports their usecase as well .
>

The patches are really non-invasive, and extremely contained, and have
had several reviews. I cannot come up with a good reason to keep it out.

This is also interesting for the NFV use-cases (mainly) so I'd like to
see it happen on that account too - and thus will be happy to sponsor it.

N.

__
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] [congress][Policy][Copper]Collaboration between OpenStack Congress and OPNFV Copper

[SULLIVAN, BRYAN L]

Hi Tim,

See one issue I had when installing congress, below. I'm not sure where to 
report this as it seems just a bug in the readme.rst at 
https://github.com/stackforge/congress
 and in the prepare_devstack.sh script.

The readme references creating a localrc and adding the line below to it:
ENABLED_SERVICES=congress,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,n-cauth,horizon,mysql,rabbit,sysstat,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta,n-novnc,n-xvnc,q-lbaas,ceilometer-acompute,ceilometer-acentral,ceilometer-anotification,ceilometer-collector,ceilometer-alarm-evaluator,ceilometer-alarm-notifier,ceilometer-api,s-proxy,s-object,s-container,s-account

But localrc has been deprecated for local.conf AFAICT, and stack.sh failed with 
errors (urllib3:... connection pool is full, discarding connection...) until I:
-  Moved "enable_service congress" into the [local|localrc] section 
of local.conf
-  Did not include the "ENABLED_SERVICES" line above
(it seems to be redundant, not necessary if you are only enabling the default 
services, and I think caused the errors in stack.sh)

I think prepare_devstack.sh needs to be updated to put "enable_service 
congress" into the [local|localrc] section of local.conf rather than creating 
localrc (at least when there is a local.conf in the devstack directory).

Thanks,
Bryan Sullivan | Service Standards | AT&T

From: SULLIVAN, BRYAN L
Sent: Wednesday, February 11, 2015 9:04 PM
To: 'Tim Hinrichs'; 'OpenStack Development Mailing List (not for usage 
questions)'
Cc: HU, BIN; 'Rodriguez, Iben'; 'Howard Huang'
Subject: RE: [openstack-dev] [congress][Policy][Copper]Collaboration between 
OpenStack Congress and OPNFV Copper

Hi Tim,

It would be great to meet with members of the Congress project if possible at 
our meetup in Santa Rosa. I plan by then to have a basic understanding of 
Congress and some test driver apps / use cases to demo at the meetup. The goal 
is to assess the current state of Congress support for the use cases on the 
OPNFV wiki: https://wiki.opnfv.org/copper/use_cases

I would be doing the same with ODL but I'm not as far on getting ready with it. 
So the opportunity to discuss the use cases under Copper and the other 
policy-related projects
(fault management, resource 
management, resource 
scheduler) 
with Congress experts would be great.

Once we understand the gaps in what we are trying to build in OPNFV, the goal 
for our first OPNFV release is to create blueprints for new work in Congress. 
We might also just find some bugs and get directly involved in Congress to 
address them, or start a collaborative development project in OPNFV for that. 
TBD

Thanks,
Bryan Sullivan | Service Standards | AT&T

From: Tim Hinrichs [mailto:thinri...@vmware.com]
Sent: Wednesday, February 11, 2015 10:22 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: SULLIVAN, BRYAN L; HU, BIN; Rodriguez, Iben; Howard Huang
Subject: Re: [openstack-dev] [congress][Policy][Copper]Collaboration between 
OpenStack Congress and OPNFV Copper

Hi Zhipeng,

We'd be happy to meet.  Sounds like fun!

I don't know of anyone on the Congress team who is planning to attend the LF 
collaboration summit.  But we might be able to send a couple of people if it's 
the only real chance to have a face-to-face.  Otherwise, there are a bunch of 
us in and around Palo Alto.  And of course, phone/google hangout/irc are fine 
options as well.

Tim



On Feb 11, 2015, at 8:59 AM, Zhipeng Huang 
mailto:zhipengh...@gmail.com>> wrote:

Hi Congress Team,

As you might already knew, we had a project in OPNFV covering deployment policy 
called 
Copper,
 in which we identify Congress as one of the upstream projects that we need to 
put our requirement to. Our team has been working on setting up a simple 
openstack environment with congress integrated that could demo simple use cases 
for policy deployment.

Would it possible for you guys and our team to find a time do an 
Copper/Congress interlock meeting, during which Congress Team could introduce 
how to best integrate congress with "vanilla" openstack? Will some of you 
attend LF Collaboration Summit?

Thanks a lot :)

--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of

Re: [openstack-dev] [Manila]Question about gateway-mediated-with-ganesha

[Li, Chen]

Yes,  I’m asking about plans for gateway-mediated-with-ganesha.
I want to know what would you do to achieve “And later the Ganesha core would 
be extended to use the infrastructure used by generic driver to provide network 
separated multi-tenancy. The core would manage Ganesha service running in the 
service VMs, and the VMs themselves that reside in share networks.”
Because after I studied current infrastructure of generic driver,  I guess 
directly use it for Ganesha would now work.
This is what I have learned from code:

Manila create service_network and service_subnet based on configurations in 
manila.conf:

service_network_name =  manila_service_network

service_network_cidr =  10.254.0.0/16

service_network_division_mask = 28

service_network is created when manila-share service start.
service_subnet is created when manila-share service  get a share create 
command, and no share-server exists for current share-network.

ð  Service_subnet create at the same time as share-server created.

Yes, it can be pre-created, manila would check if subnet with no name already 
exist.

Thanks.
-chen


From: Deepak Shetty [mailto:dpkshe...@gmail.com]
Sent: Thursday, February 12, 2015 2:09 PM
To: Li, Chen
Cc: OpenStack Development Mailing List (not for usage questions) 
(openstack-dev@lists.openstack.org)
Subject: Re: [openstack-dev] [Manila]Question about 
gateway-mediated-with-ganesha



On Thu, Feb 12, 2015 at 6:41 AM, Li, Chen 
mailto:chen...@intel.com>> wrote:
Hi Deepak,


>  When you say VM, its confusing, whether you are referring to service VM or

>  tenant VM. Since you are also saying share-server, I presume you mean

>  service VM!


>  IIUC each share-server VM (also called service VM) is serving all VMs

>  created by a tenant. In other words, generic driver creates 1 service VM

>  per tenant, and hence serves all the VMs (tenant VMs) created by that tenant

>  Manila experts on the list can correct me if I am wrong here. Generic

>  driver creates service VM (if not already present for that tenant) as part

>  of creating a new share and connect the tenant network to the service VM

>  network via neutron router (creates ports on the router which helps connect

>  the 2 different subnets), thus the tenant VMs can ping/access the service

>  VM. There is no question and/or need to have 2 service VMs talk to each

>  other, because they are serving different tenants, thus they need to be

>  isolated!

Sorry for the bad expression, yes, I mean service VM.

I don’t agree with “each share-server VM (also called service VM) is serving 
all VMs created by a tenant”.
Because from my practices , 1 service VM is created for 1 share-network.
A share-network -> A service VM -> shares which are created with the same 
“share-network”.

You are probably right, I don't remember the insides of share-network now, but 
I always created 1 share-network, so i always had the notion of 1 service VM 
per tenant.

A tenant(the tenant concept in keystone) can has more than one share-networks, 
even a same neutron network & subnet can be “registered” to several 
share-networks if user do want to do that.
Actually, I didn’t see strong connections between manila shares and tenant (the 
concept in keystone), but this is other topics then.

But, I think I get your point about service VMs need to be isolated.
I agree with that.


>  Typically GlusterFS will be deployed on storage nodes (by storage admin)

>  that are NOT part of openstack. So having the share-server talk/connect

>  with GlusterFS is equivalent to saying "Allow openstack VM to talk with

>  non-openstack nodes", in other words "Connect the neutron network to

>  non-neutron network (also called provider/host network)".




This is the part I disagree.

What exactly do you disagree here ?






>  This is achieved by ensuring your openstack Network node is configured to

>  forward tenant traffic to provider network, which involves neutron skills

>  and some neutron black magic :)

>  To know what this involves, pls see section "Setup devstack networking to

>  allow Nova VMs access external/provider network" in my blog @

>  http://dcshetty.blogspot.in/2015/01/using-glusterfs-native-driver-in.html





>  This should be taken care by your openstack network admin who should

>  configure the openstack network node to allow this to happen, this isn't a

>  Manila / GlusterFS driver responsibility, rather its an openstack

>  deployment option thats taken care by the network admins during openstack

>  deployment.






What I want to do is enable GluserFS with Manila with Ganesha in my environment.
I’m working as a cloud admin.
So, what I expecting is,

1.   I need to prepare a GlusterFS cluster

2.   I need to prepare images and other stuff for service VM

Right now, i think all we support is running Ganesha inside the GlusterFS 
server node only. I don't think we have qualified
the scenario where Ganesha is running in service VM. The Blueprin

Re: [openstack-dev] [Manila]Question about gateway-mediated-with-ganesha

[Deepak Shetty]

On Thu, Feb 12, 2015 at 6:41 AM, Li, Chen  wrote:

>  Hi Deepak,
>
>
>
> Ø  When you say VM, its confusing, whether you are referring to service
> VM or
>
> Ø  tenant VM. Since you are also saying share-server, I presume you mean
>
> Ø  service VM!
>
>
>
> Ø  IIUC each share-server VM (also called service VM) is serving all VMs
>
> Ø  created by a tenant. In other words, generic driver creates 1 service
> VM
>
> Ø  per tenant, and hence serves all the VMs (tenant VMs) created by that
> tenant
>
> Ø  Manila experts on the list can correct me if I am wrong here. Generic
>
> Ø  driver creates service VM (if not already present for that tenant) as
> part
>
> Ø  of creating a new share and connect the tenant network to the service
> VM
>
> Ø  network via neutron router (creates ports on the router which helps
> connect
>
> Ø  the 2 different subnets), thus the tenant VMs can ping/access the
> service
>
> Ø  VM. There is no question and/or need to have 2 service VMs talk to each
>
> Ø  other, because they are serving different tenants, thus they need to be
>
> Ø  isolated!
>
>
>
> Sorry for the bad expression, yes, I mean service VM.
>
>
>
> I don’t agree with “each share-server VM (also called service VM) is
> serving all VMs created by a tenant”.
>
> Because from my practices , 1 service VM is created for 1 share-network.
>
> A share-network -> A service VM -> shares which are created with the same
> “share-network”.
>

You are probably right, I don't remember the insides of share-network now,
but I always created 1 share-network, so i always had the notion of 1
service VM per tenant.


>  A tenant(the tenant concept in keystone) can has more than one
> share-networks, even a same neutron network & subnet can be “registered”
> to several share-networks if user do want to do that.
>
> Actually, I didn’t see strong connections between manila shares and
> tenant (the concept in keystone), but this is other topics then.
>
>
>
> But, I think I get your point about service VMs need to be isolated.
>
> I agree with that.
>
>
>
> Ø  Typically GlusterFS will be deployed on storage nodes (by storage admin)
>
> Ø  that are NOT part of openstack. So having the share-server talk/connect
>
> Ø  with GlusterFS is equivalent to saying "Allow openstack VM to talk with
>
> Ø  non-openstack nodes", in other words "Connect the neutron network to
>
> Ø  non-neutron network (also called provider/host network)".
>
>
>
>
>
> This is the part I disagree.
>

What exactly do you disagree here ?


>
>
>
>
> Ø  This is achieved by ensuring your openstack Network node is configured to
>
> Ø  forward tenant traffic to provider network, which involves neutron skills
>
> Ø  and some neutron black magic :)
>
> Ø  To know what this involves, pls see section "Setup devstack networking to
>
> Ø  allow Nova VMs access external/provider network" in my blog @
>
> Ø  http://dcshetty.blogspot.in/2015/01/using-glusterfs-native-driver-in.html
>
>
>
>
>
> Ø  This should be taken care by your openstack network admin who should
>
> Ø  configure the openstack network node to allow this to happen, this isn't a
>
> Ø  Manila / GlusterFS driver responsibility, rather its an openstack
>
> Ø  deployment option thats taken care by the network admins during openstack
>
> Ø  deployment.
>
>
>
>
>
>
>
> What I want to do is enable GluserFS with Manila with Ganesha in my
> environment.
>
> I’m working as a cloud admin.
>
> So, what I expecting is,
>
> 1.   I need to prepare a GlusterFS cluster
>
> 2.   I need to prepare images and other stuff for service VM
>

Right now, i think all we support is running Ganesha inside the GlusterFS
server node only. I don't think we have qualified
the scenario where Ganesha is running in service VM. The Blueprint talks
about doing this in near future.

Ccing Csaba and Ramana who are the right folks to comment more on this.



>  3.   I need to configure my GluserFS cluster’s information (IPs,
> volumes) into manila.conf
>
>
>
> ð  All things can work if I start Manila now, Yeah !
>
> The only thing I know is manila would create VMs to connect to my
> GlusterFS cluster.
>
>
>
>
>
> Currently, the neutron network & subnet where service VMs work is created
> by Manila.
>
> Manila called them service_network & service_subnet.
>
> So, I don’t think it is possible for me to configure the network before I
> create shares.
>

service_network and service_subnet is pre-created i thought ? Even if it
isn't you can bridge the service_network with provider network after the
service_network is created (Ideally it should have been pre-created)


>
>
> Another problem is there is no router I can used to let service_network
> connected to GlusterFS cluster.
>
> Because service_subnet are already connected to user’s router ( if
> connect_share_server_to_tenant_network = False)
>

If you read my blog, it talks about connecting tenant network to GlusterFS
cluster which is on the host/provider network
For your case, it maps to connecting ser

Re: [openstack-dev] [Manila]Question about gateway-mediated-with-ganesha

[Li, Chen]

Hi Deepak,


Ø  When you say VM, its confusing, whether you are referring to service VM or

Ø  tenant VM. Since you are also saying share-server, I presume you mean

Ø  service VM!


Ø  IIUC each share-server VM (also called service VM) is serving all VMs

Ø  created by a tenant. In other words, generic driver creates 1 service VM

Ø  per tenant, and hence serves all the VMs (tenant VMs) created by that tenant

Ø  Manila experts on the list can correct me if I am wrong here. Generic

Ø  driver creates service VM (if not already present for that tenant) as part

Ø  of creating a new share and connect the tenant network to the service VM

Ø  network via neutron router (creates ports on the router which helps connect

Ø  the 2 different subnets), thus the tenant VMs can ping/access the service

Ø  VM. There is no question and/or need to have 2 service VMs talk to each

Ø  other, because they are serving different tenants, thus they need to be

Ø  isolated!

Sorry for the bad expression, yes, I mean service VM.

I don’t agree with “each share-server VM (also called service VM) is serving 
all VMs created by a tenant”.
Because from my practices , 1 service VM is created for 1 share-network.
A share-network -> A service VM -> shares which are created with the same 
“share-network”.
A tenant(the tenant concept in keystone) can has more than one share-networks, 
even a same neutron network & subnet can be “registered” to several 
share-networks if user do want to do that.
Actually, I didn’t see strong connections between manila shares and tenant (the 
concept in keystone), but this is other topics then.

But, I think I get your point about service VMs need to be isolated.
I agree with that.


Ø  Typically GlusterFS will be deployed on storage nodes (by storage admin)

Ø  that are NOT part of openstack. So having the share-server talk/connect

Ø  with GlusterFS is equivalent to saying "Allow openstack VM to talk with

Ø  non-openstack nodes", in other words "Connect the neutron network to

Ø  non-neutron network (also called provider/host network)".




This is the part I disagree.





Ø  This is achieved by ensuring your openstack Network node is configured to

Ø  forward tenant traffic to provider network, which involves neutron skills

Ø  and some neutron black magic :)

Ø  To know what this involves, pls see section "Setup devstack networking to

Ø  allow Nova VMs access external/provider network" in my blog @

Ø  http://dcshetty.blogspot.in/2015/01/using-glusterfs-native-driver-in.html





Ø  This should be taken care by your openstack network admin who should

Ø  configure the openstack network node to allow this to happen, this isn't a

Ø  Manila / GlusterFS driver responsibility, rather its an openstack

Ø  deployment option thats taken care by the network admins during openstack

Ø  deployment.






What I want to do is enable GluserFS with Manila with Ganesha in my environment.
I’m working as a cloud admin.
So, what I expecting is,

1.   I need to prepare a GlusterFS cluster

2.   I need to prepare images and other stuff for service VM

3.   I need to configure my GluserFS cluster’s information (IPs, volumes) 
into manila.conf



ð  All things can work if I start Manila now, Yeah !
The only thing I know is manila would create VMs to connect to my GlusterFS 
cluster.


Currently, the neutron network & subnet where service VMs work is created by 
Manila.
Manila called them service_network & service_subnet.
So, I don’t think it is possible for me to configure the network before I 
create shares.

Another problem is there is no router I can used to let service_network 
connected to GlusterFS cluster.
Because service_subnet are already connected to user’s router ( if 
connect_share_server_to_tenant_network = False)

Thanks.
-chen

From: Deepak Shetty [mailto:dpkshe...@gmail.com]
Sent: Thursday, February 12, 2015 1:24 PM
To: Li, Chen
Subject: Fwd: [openstack-dev] [Manila]Question about 
gateway-mediated-with-ganesha

Li Chen,
   Fwdign it to you , since u didn't recieve the below mail to your outlook. 
Hope you get this one!
While responding pls Cc the openstack-dev list, so that the discussion can 
continue on the public list

thanx,
deepak
-- Forwarded message --
From: Deepak Shetty mailto:dpkshe...@gmail.com>>
Date: Wed, Feb 11, 2015 at 2:31 PM
Subject: Re: [openstack-dev] [Manila]Question about 
gateway-mediated-with-ganesha
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>



On Tue, Feb 10, 2015 at 1:51 AM, Li, Chen 
mailto:chen...@intel.com>> wrote:
Hi list,

I’m trying to understand how manila use NFS-Ganesha, and hope to figure out 
what I need to do to use it if all patches been merged (only one patch is under 
reviewing,  right ?).

I have read:
https://wiki.openstack.org/wiki/Manila/Networking/Gateway_mediated
https://blueprints.launchpad.net/manila/+spec/gateway-mediated-with-ganesha

From documents, it is s

Re: [openstack-dev] openstack/requirements failure

[Manickam, Kanagaraj]

Thanks Ben Nemec. 
I have proposed the changes https://review.openstack.org/154989.

-Original Message-
From: Ben Nemec [mailto:openst...@nemebean.com] 
Sent: Wednesday, February 11, 2015 11:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] openstack/requirements failure

On 02/11/2015 11:33 AM, Manickam, Kanagaraj wrote:
> Hi
> 
> In horizon I am trying to increase the python-heatclient>=0.3.0 as part of 
> the review https://review.openstack.org/#/c/154952/ and its failed with 
> following error:
> 
> 
> "Requirement python-heatclient>=0.3.0 does not match openstack/requirements 
> value python-heatclient>=0.2.9"
> More details at 
> https://jenkins03.openstack.org/job/gate-horizon-requirements/110/console
> 
> Could anyone help me to resolve this issue? Thanks.

Requirements changes have to be proposed to global requirements first.
There's a full explanation here:
http://git.openstack.org/cgit/openstack/requirements/tree/README.rst


__
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] [congress][Policy][Copper]Collaboration between OpenStack Congress and OPNFV Copper

[SULLIVAN, BRYAN L]

Hi Tim,

It would be great to meet with members of the Congress project if possible at 
our meetup in Santa Rosa. I plan by then to have a basic understanding of 
Congress and some test driver apps / use cases to demo at the meetup. The goal 
is to assess the current state of Congress support for the use cases on the 
OPNFV wiki: https://wiki.opnfv.org/copper/use_cases

I would be doing the same with ODL but I'm not as far on getting ready with it. 
So the opportunity to discuss the use cases under Copper and the other 
policy-related projects
(fault management, resource 
management, resource 
scheduler) 
with Congress experts would be great.

Once we understand the gaps in what we are trying to build in OPNFV, the goal 
for our first OPNFV release is to create blueprints for new work in Congress. 
We might also just find some bugs and get directly involved in Congress to 
address them, or start a collaborative development project in OPNFV for that. 
TBD

Thanks,
Bryan Sullivan | Service Standards | AT&T

From: Tim Hinrichs [mailto:thinri...@vmware.com]
Sent: Wednesday, February 11, 2015 10:22 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: SULLIVAN, BRYAN L; HU, BIN; Rodriguez, Iben; Howard Huang
Subject: Re: [openstack-dev] [congress][Policy][Copper]Collaboration between 
OpenStack Congress and OPNFV Copper

Hi Zhipeng,

We'd be happy to meet.  Sounds like fun!

I don't know of anyone on the Congress team who is planning to attend the LF 
collaboration summit.  But we might be able to send a couple of people if it's 
the only real chance to have a face-to-face.  Otherwise, there are a bunch of 
us in and around Palo Alto.  And of course, phone/google hangout/irc are fine 
options as well.

Tim



On Feb 11, 2015, at 8:59 AM, Zhipeng Huang 
mailto:zhipengh...@gmail.com>> wrote:

Hi Congress Team,

As you might already knew, we had a project in OPNFV covering deployment policy 
called 
Copper,
 in which we identify Congress as one of the upstream projects that we need to 
put our requirement to. Our team has been working on setting up a simple 
openstack environment with congress integrated that could demo simple use cases 
for policy deployment.

Would it possible for you guys and our team to find a time do an 
Copper/Congress interlock meeting, during which Congress Team could introduce 
how to best integrate congress with "vanilla" openstack? Will some of you 
attend LF Collaboration Summit?

Thanks a lot :)

--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OpenDaylight, OpenCompute affcienado
__
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] [nova][api] How to handle API changes in contrib/*.py

[Ken'ichi Ohmichi]

Hi Claudiu,

2015-02-03 7:51 GMT+09:00 Claudiu Belu :
>
> There have been some discussion on what nova-api should return after a
> change in the API itself.
>
> So, the change that generated this discussion is an API change to 2.2 is:
> https://review.openstack.org/#/c/140313/23
>
> - **2.2**
>
>   Added Keypair type.
>
>   A user can request the creation of a certain 'type' of keypair (ssh or
> x509).
>
>   If no keypair type is specified, then the default 'ssh' type of keypair is
>   created.
>
> Currently, this change was done on  plugins/v3/keypairs.py, so now, the 2.2
> version will also return the keypair type on keypair-list, keypair-show,
> keypair-create.
>
> Microversioning was used, so this behaviour is valid only if the user
> requests the 2.2 version. Version 2.1 will not accept keypair type as
> argument, nor will return the keypair type.

The above behavior seems reasonable from experience of microversions
discussion.

> Now, the main problem is contrib/keypairs.py, microversioning cannot be
> applied there. The current commit filters the keypair type, it won't be
> returned. But there have been reviews stating that returning the keypair
> type is a "back-compatible change". Before this, there was a review stating
> that keypair type should not be returned.
>
> So, finally, my question is: how should the API change be handled in
> contrib/keypairs.py?

I think v2 API(contrib/keypairs.py) should not return the keypair type
basically.

Before microversions, when adding new parameters which is backwards
*compatible*, we need to add dummy extension for noticing the change
to clients.
For example, you can see server_group_quotas[1] extension which is
almost empty and base extension server_group switches its behavior
based on server_group_quotas extension loading condition. [2]
So if keypair type needs to be returned, we need to add this kind of
dummy extension to v2(under contrib/). but this development manner
makes non-important code.
That is one of reasons why we are implementing microversions for
avoiding dummy extensions.

Thanks
Ken Ohmichi

---
[1]: 
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/server_group_quotas.py
[2]: 
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/server_groups.py#L196

__
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] [congress] following up on releasing kilo milestone 2

[sean roberts]

so
git checkout master
git pull https://git.openstack.org/stackforge/congress.git
dbef982ea72822e0b7acc16da9b6ac89d3cf3530
git tag -s 2015.1.0b2
git push gerrit 2015.1.0b2

On Wed, Feb 11, 2015 at 5:26 PM, James E. Blair  wrote:

> sean roberts  writes:
>
> > At our last meeting I volunteered to figure out what we need to do for
> > milestone 2. Here is what I propose:
> >
> > Repo cleanup:
> > We tag today's release with 2015.1.0b2. This is copying tag the other
> > openstack projects are using. I believe below is the correct syntax. Let
> me
> > know if there is a cleaner way and/or if setting the head pointer to a
> > specific commit is more accurate.
> >
> > git checkout master
> > git pull --ff-only
> > git tag -s 2015.1.0b2
> > git push gerrit 2015.1.0b2
>
> Yes, this matches:
>
>   http://docs.openstack.org/infra/manual/drivers.html#tagging-a-release
>
> But yes, if you want to tag a specific commit instead of the tip of
> master, you can do that.
>
> -Jim
>
> __
> 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
>



-- 

~ 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] [cinder] CURD operation for storage pools in Cinder

[Pradip Mukhopadhyay]

Ok, thanks.

Usecase perspective, it is the under-cloud usecase (the cloud admin
provisioned the underlying storage - which will in turn use to create
cinder). Will there be any other usecase?

What will be the semantic of 'Edit' operation to the pool? Create and
Delete is obvious. But how to define the 'Edit'?




--pradip




On Thu, Feb 12, 2015 at 1:01 AM, Bruns, Curt E 
wrote:

> Hi Duncan and Pradip,
>
> It was Reddy, a colleague of mine at Intel, that expressed interest with
> managing storage pools in Cinder.  We haven’t put a BP out yet, but we
> definitely think it would be useful and we should get a BP in the works.
>
> - Curt
>
> From: Duncan Thomas  duncan.tho...@gmail.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org >>
> Date: Wednesday, February 11, 2015 at 10:38 AM
> To: OpenStack Development Mailing List  >
> Subject: Re: [openstack-dev] [cinder] CURD operation for storage pools in
> Cinder
>
>
> As far as I know, this has not been looked at - you need to use whatever
> management tools your backend provides to do this.
>
> There was somebody from Intel IIRC in Paris with some interest in maybe
> starting something about this, but I don't know that it came to much.
>
> Duncan Thomas
>
> On Feb 11, 2015 6:53 PM, "Pradip Mukhopadhyay"  > wrote:
> Hello,
>
>
>
> Does Cinder already have a blue-print/planned-schedule for supporting (at
> least in API level - may not be python-client/Horizon levels) the
> create/edit/delete operation on the storage pools?
>
> It is understood that the "read" part 'get_pools' is already there.
>
>
> If it is already planned/scheduled - what is the time-frame of having it
> as a part of devstack?
>
>
>
> Thanks in advance,
> Pradip
>
>
>
>
>
>
> __
> 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
>
__
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] Questions about remote replication

[Guo, Ruijing]

Replication should be in 2 backends. You may look at 
http://www.emc.com/collateral/white-papers/h12079-vnx-replication-technologies-overview-wp.pdf

Thanks,
-Ruijing

From: Chenzongliang [mailto:chenzongli...@huawei.com]
Sent: Thursday, February 12, 2015 9:20 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] Questions about remote replication


According to the blueprint 
description(https://blueprints.launchpad.net/cinder/+spec/volume-replication)
The Create volume with the replication enabled:
* the Scheduler selects two hosts for volume placement and sets up the 
replication
The DB entry

When reading the related scheduling module code, I can not found the process 
about this. I want to know where is to implemented this part of flow?If there 
is, whether the two volumes in different backend?

__
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] Fixing stuck volumes - part II

[D'Angelo, Scott]

From: Guo, Ruijing [mailto:ruijing@intel.com]
Sent: Wednesday, February 11, 2015 5:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Fixing stuck volumes - part II

Force is a good idea. I'd like to add 2 comments:


1)  It is option instead of new command. IOW, detach with force option 
instead of force-detach.

> OK with me. I'll leave it to the community to decide which is best.

2)  Can we extend to another command: delete LUN/snapshot with force?

  > We could easily expose 'force-detach' through the cinderclient for 
volumes and snapshots. But it might be confusing for the admin who thinks that 
this is the primary way to clean things up and leave out Nova, which would put 
the volume in a state where it cannot be re-attached.

Thanks,
-Ruijing

From: Vishvananda Ishaya [mailto:vishvana...@gmail.com]
Sent: Thursday, February 12, 2015 8:07 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Fixing stuck volumes - part II


On Feb 11, 2015, at 3:45 PM, D'Angelo, Scott 
mailto:scott.dang...@hp.com>> wrote:

At the cinder mid-cycle it was decided that the best way to fix volumes stuck 
in 'attaching' or 'detaching' was NOT to fix the broken reset-state command. 
The doc string and help message for reset-state have been modified to warn the 
user that the tool only affects Cinder DB and can cause problems. But, 
ultimately, a separate command to 'force-detach' would be better. I've 
abandoned the original BP/spec for reset-state involving the driver.

I have looked at the existing function 'force-detach' in Cinder and it seems to 
work...except that Nova must be involved. Nova uses the BlockDeviceMapping 
table to keep track of attached volumes and, if Nova is not involved, a 
force-detach'ed volume will not be capable of being re-attached.
So, my plan is to submit a blueprint + spec for Novaclient to add a 
'force-detach' command. This is technically fairly simple and only involves 
stripping away the checks for proper state in Nova, and calling Cinder 
force-detach. I don't plan on asking for an exception to feature freeze, unless 
there is optimism from the community that this could possible get in for L.
The existing Cinder force-detach calls terminate_connection() and 
detach_volume().  I assume detach_volume() is covered by the "Volume Detach" 
minimum feature? I see many drivers have terminate_connection(), but not all. I 
believe this will not be a minimum feature, but others may disagree.

If you are going to add a force-detach command to nova, I think it would be 
good to make it detach even if the cinder request fails. Currently if you try 
to detach a volume (or terminate an instance with an attached volume), if 
cinder is down or the volume node where the volume resides is down, nova 
refuses to continue, which is pretty bad user experience.

Vish


thanks,
scottda
scott.dang...@hp.com


__
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] [cinder] Fixing stuck volumes - part II

[D'Angelo, Scott]

From: Vishvananda Ishaya [mailto:vishvana...@gmail.com]
Sent: Wednesday, February 11, 2015 5:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Fixing stuck volumes - part II


On Feb 11, 2015, at 3:45 PM, D'Angelo, Scott 
mailto:scott.dang...@hp.com>> wrote:


At the cinder mid-cycle it was decided that the best way to fix volumes stuck 
in 'attaching' or 'detaching' was NOT to fix the broken reset-state command. 
The doc string and help message for reset-state have been modified to warn the 
user that the tool only affects Cinder DB and can cause problems. But, 
ultimately, a separate command to 'force-detach' would be better. I've 
abandoned the original BP/spec for reset-state involving the driver.

I have looked at the existing function 'force-detach' in Cinder and it seems to 
work...except that Nova must be involved. Nova uses the BlockDeviceMapping 
table to keep track of attached volumes and, if Nova is not involved, a 
force-detach'ed volume will not be capable of being re-attached.
So, my plan is to submit a blueprint + spec for Novaclient to add a 
'force-detach' command. This is technically fairly simple and only involves 
stripping away the checks for proper state in Nova, and calling Cinder 
force-detach. I don't plan on asking for an exception to feature freeze, unless 
there is optimism from the community that this could possible get in for L.
The existing Cinder force-detach calls terminate_connection() and 
detach_volume().  I assume detach_volume() is covered by the "Volume Detach" 
minimum feature? I see many drivers have terminate_connection(), but not all. I 
believe this will not be a minimum feature, but others may disagree.

If you are going to add a force-detach command to nova, I think it would be 
good to make it detach even if the cinder request fails. Currently if you try 
to detach a volume (or terminate an instance with an attached volume), if 
cinder is down or the volume node where the volume resides is down, nova 
refuses to continue, which is pretty bad user experience.

Vish

The only problem with that is, what happens when cinder comes back up? You have 
an user/admin who think that the volume should be available, but cinder DB 
still lists as attaching | detaching and the backend may still be exporting the 
volume to the Nova compute host.
We could expose 'force-detach' through the cinderclient to fix this, but the 
admin/user might think that this is the first place to start, and leave Nova 
out, which results in a volume that cannot be re-attached.
I think that you are right about user experience, but I'm cautious about other 
problems that might result.

thanks,
scottda
scott.dang...@hp.com


__
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] [Ceilometer] Real world experience with Ceilometerdeployments - Feedback requested

[Luo Gangyi]

Hi, maishsk


I have deployed serveral test environment in my company's labs and each 
environment has 20-30 servers.


Here were the problems I have met.


1. MongoDB consumes too much memory. I use cgroups to restrict the memory used. 
but if using hard restriction, MongoDB may be terminated by OOM.‍
2. Billing data and monitoring data share the same table and database. This is 
very inconvenient! Monitoring data is massive and there is no need to backup‍
 monitoring data. On the contrary, billing data is less and important which 
should be backuped. Mixing these two data together makes things becomes 
difficult.
3. It posed too much pressure on MQ when we configured monitoring period into 
2-5 seconds. So we configured the pipeline using UDP channel.


Next month we will build a openstack environment about 100-150 servers. I will 
record my configuration, performance data and problems and I am willing to 
sharethese data and experience in the near future.


--
Luo gangyiluogan...@chinamobile.com



 




-- Original --
From:  "Maish Saidel-Keesing";;
Date:  Thu, Feb 12, 2015 03:37 AM
To:  "openstack-dev"; 
"openstack-operators"; 

Subject:  [openstack-dev] [Ceilometer] Real world experience with 
Ceilometerdeployments - Feedback requested



Is Ceilometer ready for prime time?

I would be interested in hearing from people who have deployed OpenStack 
clouds with Ceilometer, and their experience. Some of the topics I am 
looking for feedback on are:

- Database Size
- MongoDB management, Sharding, replica sets etc.
- Replication strategies
- Database backup/restore
- Overall useability
- Gripes, pains and problems (things to look out for)
- Possible replacements for Ceilometer that you have used instead


If you are willing to share - I am sure it will be beneficial to the 
whole community.

Thanks in Advance


With best regards,


Maish Saidel-Keesing
Platform Architect
Cisco




__
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] [Heat][All] Unicode support to object names

[Qiming Teng]

On Thu, Feb 12, 2015 at 06:04:14PM +0800, Qiming Teng wrote:
> Hi,
> 
> Seeing that there have been some complaints about the Unicode support to
> stack names and resource names in Heat, I have tried to fix it in Heat
> [1]. I have also posted questions regarding logging Unicode but the
> finding was that my devstack environment is not starting 'screen'
> sessions with Unicode support.
> 
> So, here is my question. Do we have some recommended solution to support
> naming objects in Unicode? I know it is a little bit complicated for
> Heat because stack names may appear in URIs of ReST calls. That is
> something we can fix in V2 API, IMO. My question is really about in
> general how each projects are dealing with this problem?
> 
> As a reference, AWS has a rule for 'ResourceName' defined as:
> 
> [\u0020-\uD7FF\uE000-\uFFFD\uD800\uDC00-\uDBFF\uDFFF\r\n\t]*
> 

Sorry, forgot to paste the related patch.
[1] https://review.openstack.org/#/c/143915/


__
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] [Heat][All] Unicode support to object names

[Qiming Teng]

Hi,

Seeing that there have been some complaints about the Unicode support to
stack names and resource names in Heat, I have tried to fix it in Heat
[1]. I have also posted questions regarding logging Unicode but the
finding was that my devstack environment is not starting 'screen'
sessions with Unicode support.

So, here is my question. Do we have some recommended solution to support
naming objects in Unicode? I know it is a little bit complicated for
Heat because stack names may appear in URIs of ReST calls. That is
something we can fix in V2 API, IMO. My question is really about in
general how each projects are dealing with this problem?

As a reference, AWS has a rule for 'ResourceName' defined as:

[\u0020-\uD7FF\uE000-\uFFFD\uD800\uDC00-\uDBFF\uDFFF\r\n\t]*


Thanks.

Regards,
  Qiming


__
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] [congress] following up on releasing kilo milestone 2

[James E. Blair]

sean roberts  writes:

> At our last meeting I volunteered to figure out what we need to do for
> milestone 2. Here is what I propose:
>
> Repo cleanup:
> We tag today's release with 2015.1.0b2. This is copying tag the other
> openstack projects are using. I believe below is the correct syntax. Let me
> know if there is a cleaner way and/or if setting the head pointer to a
> specific commit is more accurate.
>
> git checkout master
> git pull --ff-only
> git tag -s 2015.1.0b2
> git push gerrit 2015.1.0b2

Yes, this matches:

  http://docs.openstack.org/infra/manual/drivers.html#tagging-a-release

But yes, if you want to tag a specific commit instead of the tip of
master, you can do that.

-Jim

__
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] Questions about remote replication

[Chenzongliang]

According to the blueprint 
description(https://blueprints.launchpad.net/cinder/+spec/volume-replication)
The Create volume with the replication enabled:
* the Scheduler selects two hosts for volume placement and sets up the 
replication
The DB entry

When reading the related scheduling module code, I can not found the process 
about this. I want to know where is to implemented this part of flow?If there 
is, whether the two volumes in different backend?

__
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] [congress] following up on releasing kilo milestone 2

[sean roberts]

At our last meeting I volunteered to figure out what we need to do for
milestone 2. Here is what I propose:

Repo cleanup:
We tag today's release with 2015.1.0b2. This is copying tag the other
openstack projects are using. I believe below is the correct syntax. Let me
know if there is a cleaner way and/or if setting the head pointer to a
specific commit is more accurate.

git checkout master
git pull --ff-only
git tag -s 2015.1.0b2
git push gerrit 2015.1.0b2


Launchpad cleanup:
I move all the blueprints and bugs from the juno series and kilo m1 to kilo
m2. I then remove the juno series and kilo m1. I release kilo m2. I upload
the congress tar file kilo m2.

Next Steps:
We target releasing kilo m3 on 19 march and repeating most of the above
steps. I won't be deleting any milestones or series this time. We also
target releasing the congress kilo release on 30 april.

~ 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] [cinder] Fixing stuck volumes - part II

[Guo, Ruijing]

Force is a good idea. I'd like to add 2 comments:


1)  It is option instead of new command. IOW, detach with force option 
instead of force-detach.

2)  Can we extend to another command: delete LUN/snapshot with force?

Thanks,
-Ruijing

From: Vishvananda Ishaya [mailto:vishvana...@gmail.com]
Sent: Thursday, February 12, 2015 8:07 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Fixing stuck volumes - part II


On Feb 11, 2015, at 3:45 PM, D'Angelo, Scott 
mailto:scott.dang...@hp.com>> wrote:


At the cinder mid-cycle it was decided that the best way to fix volumes stuck 
in 'attaching' or 'detaching' was NOT to fix the broken reset-state command. 
The doc string and help message for reset-state have been modified to warn the 
user that the tool only affects Cinder DB and can cause problems. But, 
ultimately, a separate command to 'force-detach' would be better. I've 
abandoned the original BP/spec for reset-state involving the driver.

I have looked at the existing function 'force-detach' in Cinder and it seems to 
work...except that Nova must be involved. Nova uses the BlockDeviceMapping 
table to keep track of attached volumes and, if Nova is not involved, a 
force-detach'ed volume will not be capable of being re-attached.
So, my plan is to submit a blueprint + spec for Novaclient to add a 
'force-detach' command. This is technically fairly simple and only involves 
stripping away the checks for proper state in Nova, and calling Cinder 
force-detach. I don't plan on asking for an exception to feature freeze, unless 
there is optimism from the community that this could possible get in for L.
The existing Cinder force-detach calls terminate_connection() and 
detach_volume().  I assume detach_volume() is covered by the "Volume Detach" 
minimum feature? I see many drivers have terminate_connection(), but not all. I 
believe this will not be a minimum feature, but others may disagree.

If you are going to add a force-detach command to nova, I think it would be 
good to make it detach even if the cinder request fails. Currently if you try 
to detach a volume (or terminate an instance with an attached volume), if 
cinder is down or the volume node where the volume resides is down, nova 
refuses to continue, which is pretty bad user experience.

Vish



thanks,
scottda
scott.dang...@hp.com


__
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] [Congress][Delegation] Google doc for working notes

[Debojyoti Dutta]

Hi Tim: moving our thread to the mailer. Excited to collaborate!



From: Debo~ Dutta 
Date: Wednesday, February 11, 2015 at 4:48 PM
To: Tim Hinrichs 
Cc: "Yathiraj Udupi (yudupi)" , Gokul B Kandiraju <
go...@us.ibm.com>, Prabhakar Kudva , "
ruby.krishnasw...@orange.com" , "
dilik...@in.ibm.com" , Norival Figueira <
nfigu...@brocade.com>, Ramki Krishnan , "Xinyuan Huang
(xinyuahu)" , "Rishabh Jain -X (rishabja - AAP3 INC at
Cisco)" 
Subject: Re: Nova solver scheduler and Congress

Hi Tim

To address your particular questions:

   1. translate some policy language into constraints for the LP/CVP and we
   had left that to congress hoping to integrate when the policy efforts in
   openstack were ready (our initial effort was pre congress)
   2. For migrations: we are currently doing that – its about incremental
   constraints into the same solver. Hence its a small deal ….

Joining forces is a terrific idea. Would love to join the IRC call and see
how we can build cool stuff in the community together. I hope we don’t have
to replicate the vm placement engine while the work that was done in the
community does something very similar (and be adapted)

debo

From: Tim Hinrichs 
Date: Wednesday, February 11, 2015 at 4:43 PM
To: Debo~ Dutta 
Cc: "Yathiraj Udupi (yudupi)" , Gokul B Kandiraju <
go...@us.ibm.com>, Prabhakar Kudva , "
ruby.krishnasw...@orange.com" , "
dilik...@in.ibm.com" , Norival Figueira <
nfigu...@brocade.com>, Ramki Krishnan , "Xinyuan Huang
(xinyuahu)" , "Rishabh Jain -X (rishabja - AAP3 INC at
Cisco)" 
Subject: Re: Nova solver scheduler and Congress

Hi Debo,

The 2 efforts share great similarities, which was why we investigated the
state of solver-scheduler.  From what I understand, (i) solver-scheduler
doesn’t currently have a policy language and (ii) it doesn’t do migrations.
 (I realize these are both in the works.)  We needed both and wanted to
make progress before those were complete.

In the long run, it may make perfect sense to replace our vm-placement
engine with yours.  So joining forces sounds like a good idea.  At the very
*least* we ought to keep up to date with each other’s progress.

I’m starting to wonder if we ought to schedule a (bi-) weekly IRC for this
topic.

Tim

On Feb 11, 2015, at 4:35 PM, Debo Dutta (dedutta)  wrote:

Hi Tim

This looks awesome. Trying to figure out how this approach is different
from the solver scheduler effort we did? We would be happy to fold our
solver scheduler effort into this (that way you also get code up and
running)

Will also respond on the thread.

thx
debo

From: Tim Hinrichs 
Date: Wednesday, February 11, 2015 at 4:11 PM
To: "Yathiraj Udupi (yudupi)" 
Cc: Gokul B Kandiraju , Prabhakar Kudva ,
"ruby.krishnasw...@orange.com" , "
dilik...@in.ibm.com" , Norival Figueira <
nfigu...@brocade.com>, Ramki Krishnan , "Xinyuan Huang
(xinyuahu)" , "Rishabh Jain -X (rishabja - AAP3 INC at
Cisco)" , Debo~ Dutta 
Subject: Re: Nova solver scheduler and Congress

Hi Yathiraj,

The group is getting big enough that we’ve decided to move the entire
discussion to the openstack-dev mailing list.  I sent a note today with the
google doc we’re working on.  We’re trying to include
[Congress][Delegation] in the subject line of relevant posts.  Here’s the
gdoc.

https://docs.google.com/document/d/1ksDilJYXV-5AXWON8PLMedDKr9NpS8VbT0jIy_MIEtI/edit?usp=sharing


Tim

On Feb 10, 2015, at 11:10 AM, Yathiraj Udupi (yudupi) 
wrote:

Hi Tim,

Thanks for your response.  I think Congress will have to appreciate
different APIs interacting with multiple components in the OpenStack
ecosystem.  So I will be happy to help figure out the integration plan in
general from the Congress side.

I will  be very interested and glad to participate in the discussions of
designing these interfaces in Congress.   Please share any preliminary
designs you may have.   I had participated in one of the Congress mid-cycle
meet ups, and I am interested in the upcoming work on these kind of
enforcement aspects (reactive, proactive) of Congress.  In terms of Nova
scheduling via Solver scheduler, it will also help us be ready with the
integration points.

Let’s be in sync.

Thanks,
Yathi.


On 2/10/15, 11:03 AM, "Tim Hinrichs"  wrote:

Hi Yathiraj,

Thanks for the help!

The reason I asked is that we’re trying to figure out the basic interface
for how two policy engines (in general) ought to interact.  We were hoping
Congress and solver-scheduler had very similar APIs, which would make that
interface relatively simple.  But it sounds like the two systems have
pretty different APIs.  So for now we’ll keep working on that interface,
and once we have something wor

Re: [openstack-dev] [cinder] Fixing stuck volumes - part II

[Vishvananda Ishaya]

On Feb 11, 2015, at 3:45 PM, D'Angelo, Scott  wrote:

> At the cinder mid-cycle it was decided that the best way to fix volumes stuck 
> in ‘attaching’ or ‘detaching’ was NOT to fix the broken reset-state command. 
> The doc string and help message for reset-state have been modified to warn 
> the user that the tool only affects Cinder DB and can cause problems. But, 
> ultimately, a separate command to ‘force-detach’ would be better. I’ve 
> abandoned the original BP/spec for reset-state involving the driver.
>  
> I have looked at the existing function ‘force-detach’ in Cinder and it seems 
> to work…except that Nova must be involved. Nova uses the BlockDeviceMapping 
> table to keep track of attached volumes and, if Nova is not involved, a 
> force-detach’ed volume will not be capable of being re-attached.
> So, my plan is to submit a blueprint + spec for Novaclient to add a 
> ‘force-detach’ command. This is technically fairly simple and only involves 
> stripping away the checks for proper state in Nova, and calling Cinder 
> force-detach. I don’t plan on asking for an exception to feature freeze, 
> unless there is optimism from the community that this could possible get in 
> for L.
> The existing Cinder force-detach calls terminate_connection() and 
> detach_volume().  I assume detach_volume() is covered by the “Volume Detach” 
> minimum feature? I see many drivers have terminate_connection(), but not all. 
> I believe this will not be a minimum feature, but others may disagree.

If you are going to add a force-detach command to nova, I think it would be 
good to make it detach even if the cinder request fails. Currently if you try 
to detach a volume (or terminate an instance with an attached volume), if 
cinder is down or the volume node where the volume resides is down, nova 
refuses to continue, which is pretty bad user experience.

Vish

>  
> thanks,
> scottda
> scott.dang...@hp.com
>  
>  
> __
> 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] Cross-Repo Dependencies in Zuul

[Christopher Yeoh]

Wow, this is great! Thank you!

Chris

On Wed, Feb 11, 2015 at 8:56 AM, James E. Blair  wrote:

> Hi,
>
> We have added support for cross-repo dependencies (CRD) in Zuul.  The
> important bits:
>
> * To use them, include "Depends-On: " in the footer of
>   your commit message.  Use the full Change-ID ('I' + 40 characters).
>
> * These are one-way dependencies only -- do not create a cycle.
>
> * This is what all the grey dots and lines are in the check pipeline.
>
> Cross-Repo Dependencies Explained
> =
>
> There are two behaviors that might go by the name "cross-repo
> dependencies".  We call them one-way and multi-way.
>
> Multi-way CRD allow for bidirectional links between changes.  For
> instance, A depends on B and B depends on A.  The theory there is that
> both would be tested together and merged as a unit.  This is _not_ what
> we have implemented in Zuul.  Discussions over the past two years have
> revealed that this type of behavior could cause problems for continuous
> deploments as it means that two components must be upgraded
> simultaneously.  Not supporting this behavior is a choice we have made.
>
> One-way CRD behaves like a directed acyclic graph (DAG), like git
> itself, to indicate a one-way dependency relationship between changes in
> different git repos.  Change A may depend on B, but B may not depend on
> A.  This is what we have implemented in Zuul.
>
> Gate Pipeline
> =
>
> When Zuul sees CRD changes, it serializes them in the usual manner when
> enqueuing them into a pipeline.  This means that if change A depends on
> B, then when they are added to the gate pipeline, B will appear first
> and A will follow.  If tests for B fail, both B and A will be removed
> from the pipeline, and it will not be possible for A to merge until B
> does.
>
> Note that if changes with CRD do not share a change queue (such as the
> "integrated gate" then Zuul is unable to enqueue them together, and the
> first will be required to merge before the second is enqueued.
>
> Check Pipeline
> ==
>
> When changes are enqueued into the check pipeline, all of the related
> dependencies (both normal git-dependencies that come from parent commits
> as well as CRD changes) appear in a dependency graph, as in gate.  This
> means that even in the check pipeline, your change will be tested with
> its dependency.  So changes that were previously unable to be fully
> tested until a related change landed in a different repo may now be
> tested together from the start.
>
> All of the changes are still independent (so you will note that the
> whole pipeline does not share a graph as in gate), but for each change
> tested, all of its dependencies are visually connected to it, and they
> are used to construct the git references that Zuul uses when testing.
> When looking at this graph on the status page, you will note that the
> dependencies show up as grey dots, while the actual change tested shows
> up as red or green.  This is to indicate that the grey changes are only
> there to establish dependencies.  Even if one of the dependencies is
> also being tested, it will show up as a grey dot when used as a
> dependency, but separately and additionally will appear as its own red
> or green dot for its test.
>
> (If you don't see grey dots on the status page, reload the page to get
> the latest version.)
>
> Multiple Changes
> 
>
> A Gerrit change ID may refer to multiple changes (on multiple branches
> of the same project, or even multiple projects).  In these cases, Zuul
> will treat all of the changes with that change ID as dependencies.  So
> if you say that a tempest change Depends-On a change ID that has changes
> in nova master and nova stable/juno, then when testing the tempest
> change, both nova changes will be applied, and when deciding whether the
> tempest change can merge, both changes must merge ahead of it.
>
> A change may depend on more than one Gerrit change ID as well.  So it is
> possible for a change in tempest to depend on a change in devstack and a
> change in nova.  Simply add more "Depends-On:" lines to the footer.
>
> Cycles
> ==
>
> If a cycle is created by use of CRD, Zuul will abort its work very
> early.  There will be no message in Gerrit and no changes that are part
> of the cycle will be enqueued into any pipeline.  This is to protect
> Zuul from infinite loops.  I hope that we can improve this to at least
> leave a message in Gerrit in the future.  But in the meantime, please be
> cognizant of this and do not create dependency cycles with Depends-On
> lines.
>
> Examples
> 
>
> The following two infra changes have been tested together because of the
> Depends-On: line in the commit message of the first:
>
>   https://review.openstack.org/#/c/152508/
>   https://review.openstack.org/#/c/152504/
>
> In fact, you can see earlier test results failing until it was rechecked
> after CRD went into production (aroun

[openstack-dev] [cinder] Fixing stuck volumes - part II

[D'Angelo, Scott]

At the cinder mid-cycle it was decided that the best way to fix volumes stuck 
in 'attaching' or 'detaching' was NOT to fix the broken reset-state command. 
The doc string and help message for reset-state have been modified to warn the 
user that the tool only affects Cinder DB and can cause problems. But, 
ultimately, a separate command to 'force-detach' would be better. I've 
abandoned the original BP/spec for reset-state involving the driver.

I have looked at the existing function 'force-detach' in Cinder and it seems to 
work...except that Nova must be involved. Nova uses the BlockDeviceMapping 
table to keep track of attached volumes and, if Nova is not involved, a 
force-detach'ed volume will not be capable of being re-attached.
So, my plan is to submit a blueprint + spec for Novaclient to add a 
'force-detach' command. This is technically fairly simple and only involves 
stripping away the checks for proper state in Nova, and calling Cinder 
force-detach. I don't plan on asking for an exception to feature freeze, unless 
there is optimism from the community that this could possible get in for L.
The existing Cinder force-detach calls terminate_connection() and 
detach_volume().  I assume detach_volume() is covered by the "Volume Detach" 
minimum feature? I see many drivers have terminate_connection(), but not all. I 
believe this will not be a minimum feature, but others may disagree.

thanks,
scottda
scott.dang...@hp.com


__
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] [QA] Question about EC2 Tempest tests

[Joe Gordon]

On Wed, Feb 11, 2015 at 3:58 AM, Alexandre Levine 
wrote:

>  Yaroslav,
>
> The bug:
> https://bugs.launchpad.net/nova/+bug/1410622
>
> And the review:
> https://review.openstack.org/#/c/152112/
>
> It's recently fixed.
>
>
Note, AFAIK this has not been backported to stable/juno or stable/icehouse
so running trunk EC2 tempest tests against stable/juno nova is still not
working.

In fact to unwedge stable branches we turned these tests off:
https://review.openstack.org/#/c/154575/


> Best regards,
>   Alex Levine
>
>
> On 2/11/15 2:23 PM, Yaroslav Lobankov wrote:
>
> Hello everyone,
>
>  I have some question about EC2 Tempest tests. When I run these tests, I
> regularly have the same error for all tests:
>
>  EC2ResponseError: EC2ResponseError: 400 Bad Request
> 
> AuthFailureSignature not
> provided
>
>  My environment is OpenStack (the Juno release) deployed by Fuel 6.0.
> Tempest is from master branch.
>
>  I found that the issue was related to boto (Tempest installs it into
> virtual environment as a dependency). The last available release of boto is
> 2.36.0.
> When this version of boto is installed, EC2 tests don't work. But if I
> install boto 2.34.0 instead of 2.36.0, all EC2 tests will have success.
>
>  Any thoughts?
>
>  Regards,
> Yaroslav Lobankov.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
>
__
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] [cinder] organizing tempest test development for volume replication

[Jay S. Bryant]

All,

One of the concerns raised with regards to volume migration was the lack 
of tempest testing for the functionality.  Since they I have had some 
interest indicated in helping this effort.  So, to get things started I 
have created an etherpad to track development of such test cases and to 
share thoughts/plans for such work:  [1]


Please let me know if you have any questions with regards to this.

Thanks to anyone who is interested/able to help with this effort!

Jay

[1] https://etherpad.openstack.org/p/replication-tempest-test-dev-planning

__
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] [congress][Policy][Copper]Collaboration between OpenStack Congress and OPNFV Copper

[Zhipeng Huang]

Hi Tim,

Thanks for the quick reply！I also think we should probably have a google
hangout or irc meeting ahead of F2F, do you guys have time before 2/17,
let's have a short session of crash course : )

On Thu, Feb 12, 2015 at 2:22 AM, Tim Hinrichs  wrote:

>  Hi Zhipeng,
>
>  We’d be happy to meet.  Sounds like fun!
>
>  I don’t know of anyone on the Congress team who is planning to attend
> the LF collaboration summit.  But we might be able to send a couple of
> people if it’s the only real chance to have a face-to-face.  Otherwise,
> there are a bunch of us in and around Palo Alto.  And of course,
> phone/google hangout/irc are fine options as well.
>
>  Tim
>
>
>
>   On Feb 11, 2015, at 8:59 AM, Zhipeng Huang 
> wrote:
>
>  Hi Congress Team,
>
>  As you might already knew, we had a project in OPNFV covering deployment
> policy called Copper
> ,
> in which we identify Congress as one of the upstream projects that we need
> to put our requirement to. Our team has been working on setting up a simple
> openstack environment with congress integrated that could demo simple use
> cases for policy deployment.
>
>  Would it possible for you guys and our team to find a time do an
> Copper/Congress interlock meeting, during which Congress Team could
> introduce how to best integrate congress with "vanilla" openstack? Will
> some of you attend LF Collaboration Summit?
>
>  Thanks a lot :)
>
>  --
>  Zhipeng (Howard) Huang
>
>  Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
>  (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
>  OpenStack, OpenDaylight, OpenCompute affcienado
>
> __
> 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
>
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OpenDaylight, OpenCompute affcienado
__
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] [api] Missing the next API WG meeting

[Everett Toews]

I’ll be missing the next API WG meeting [1] as I’m in some all day training. 
Someone else will have to #startmeeting api wg

Cheers,
Everett

[1] https://wiki.openstack.org/wiki/Meetings/API-WG
__
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] [sahara] team meeting Feb 12 1400 UTC

[Andrew Lazarev]

Hi guys,

We'll be having the Sahara team meeting tomorrow at #openstack-meeting-3
channel.

Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meeting&iso=20150212T14

Thanks,
Andrew
__
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] [QA] Meeting Thursday February 12th at 17:00 UTC

[Matthew Treinish]

Hi everyone,

Just a quick reminder that the weekly OpenStack QA team IRC meeting will be
tomorrow Thursday, February 12th at 17:00 UTC in the #openstack-meeting
channel.

The agenda for tomorrow's meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting
Anyone is welcome to add an item to the agenda.

To help people figure out what time 17:00 UTC is in other timezones tomorrow's
meeting will be at:

12:00 EST
02:00 JST
03:30 ACDT
18:00 CET
11:00 CST
9:00 PST

-Matt Treinish


pgptK4PWUUKGH.pgp
Description: PGP signature
__
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] [glance] File-backed glance scrubber queue

[Chris St. Pierre]

I recently proposed a change to glance to turn the file-backed scrubber
queue files into JSON: https://review.openstack.org/#/c/145223/

As I looked into it more, though, it turns out that the file-backed queue
is no longer usable; it was killed by the implementation of this blueprint:
https://blueprints.launchpad.net/glance/+spec/image-location-status

But what's not clear is if the implementation of that blueprint should have
killed the file-backed scrubber queue, or if that was even intended. Two
things contribute to the lack of clarity:

1. The file-backed scrubber code was left in, even though it is unreachable.

2. The ordering of the commits is strange. Namely, commit 66d24bb (
https://review.openstack.org/#/c/67115/) killed the file-backed queue, and
then, *after* that change, 70e0a24 (https://review.openstack.org/#/c/67122/)
updates the queue file format. So it's not clear why the queue file format
would be updated if it was intended that the file-backed queue was no
longer usable.

Can someone clarify what was intended here? If killing the file-backed
scrubber queue was deliberate, then let's finish the job and excise that
code. If not, then let's make sure that code is reachable again, and I'll
resurrect my blueprint to make the queue files suck less.

Either way I'm happy to make the changes, I'm just not sure what the goal
of these changes was, and how to properly proceed.

Thanks for any clarification anyone can offer.

-- 
Chris St. Pierre
__
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] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

[Jay Pipes]

On 02/11/2015 06:34 AM, Attila Fazekas wrote:

- Original Message -

From: "Jay Pipes" 
To: "Attila Fazekas" 
Cc: "OpenStack Development Mailing List (not for usage questions)" 
, "Pavel
Kholkin" 
Sent: Tuesday, February 10, 2015 7:32:11 PM
Subject: Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody 
should know about Galera

On 02/10/2015 06:28 AM, Attila Fazekas wrote:

- Original Message -

From: "Jay Pipes" 
To: "Attila Fazekas" , "OpenStack Development Mailing
List (not for usage questions)"

Cc: "Pavel Kholkin" 
Sent: Monday, February 9, 2015 7:15:10 PM
Subject: Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody
should know about Galera

On 02/09/2015 01:02 PM, Attila Fazekas wrote:

I do not see why not to use `FOR UPDATE` even with multi-writer or
Is the retry/swap way really solves anything here.



Am I missed something ?


Yes. Galera does not replicate the (internal to InnnoDB) row-level locks
that are needed to support SELECT FOR UPDATE statements across multiple
cluster nodes.


Galere does not replicates the row-level locks created by UPDATE/INSERT ...
So what to do with the UPDATE?


No, Galera replicates the write sets (binary log segments) for
UPDATE/INSERT/DELETE statements -- the things that actually
change/add/remove records in DB tables. No locks are replicated, ever.


Galera does not do any replication at UPDATE/INSERT/DELETE time.

$ mysql
use test;
CREATE TABLE test (id integer PRIMARY KEY AUTO_INCREMENT, data CHAR(64));

$(echo 'use test; BEGIN;'; while true ; do echo 'INSERT INTO test(data) VALUES 
("test");'; done )  | mysql

The writer1 is busy, the other nodes did not noticed anything about the above 
pending
transaction, for them this transaction does not exists as long as you do not 
call a COMMIT.

Any kind of DML/DQL you issue without a COMMIT does not happened in the other 
nodes perspective.

Replication happens at COMMIT time if the `write sets` is not empty.


We're going in circles here. I was just pointing out that SELECT ... FOR 
UPDATE will never replicate anything. INSERT/UPDATE/DELETE statements 
will cause a write-set to be replicated (yes, upon COMMIT of the 
containing transaction).


Please see my repeated statements in this thread and others that the 
compare-and-swap technique is dependent on issuing *separate* 
transactions for each SELECT and UPDATE statement...



When a transaction wins a voting, the other nodes rollbacks all transaction
which had a local conflicting row lock.


A SELECT statement in a separate transaction does not ever trigger a 
ROLLBACK, nor will an UPDATE statement that does not match any rows. 
That is IMO how increased throughput is achieved in the compare-and-swap 
technique versus the SELECT FOR UPDATE technique.


-jay

-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] [all][tc] Lets keep our community open, lets fight for it

[Jeremy Stanley]

On 2015-02-11 14:06:23 -0600 (-0600), Brian Curtin wrote:
> If people feel it's a negative or uncomfortable environment, find
> out why and try to do something to improve it. Telling someone
> that there are worse options out there is the opposite of
> fostering an open community.

Fair point--I was merely agreeing that sometimes in an effort to
keep the community healthy it's necessary to discuss topics which
may make some participants uncomfortable and may escalate into
heated debate. I certainly didn't mean to imply that we should
endeavor to be more like any other particular community, only that
we shouldn't be afraid to do so when it's required (and that we're
decidedly tame when we do, compared to a lot of other possible
examples).
-- 
Jeremy Stanley

__
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] Testing NUMA, CPU pinning and large pages

[Steve Gordon]

- Original Message -
> From: "Adrian Hoban" 
> 
> Hi Folks,
> 
> I just wanted to share some details on the Intel CI testing strategy for NFV.
> 
> You will see two Intel CIs commenting:
> #1: Intel-PCI-CI
> - Yongli He and Shane Wang are leading this effort for us.
> - The focus in this environment is on PCIe and SR-IOV specific testing.
> - Commenting back to review.openstack.org has started.

With regards to SR-IOV / PCI specifically it seemed based on 
https://review.openstack.org/#/c/139000/ and 
https://review.openstack.org/#/c/141270/ that there was still some confusion as 
to where the tests should actually live (and I expect the same is true for the 
NUMA, Large Pages, etc. tests). Is this resolved or are there still open 
questions?

Thanks,

Steve

__
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] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

[Jay Pipes]

On 02/11/2015 07:58 AM, Matthew Booth wrote:

On 10/02/15 18:29, Jay Pipes wrote:

On 02/10/2015 09:47 AM, Matthew Booth wrote:

On 09/02/15 18:15, Jay Pipes wrote:

On 02/09/2015 01:02 PM, Attila Fazekas wrote:

I do not see why not to use `FOR UPDATE` even with multi-writer or
Is the retry/swap way really solves anything here.



Am I missed something ?


Yes. Galera does not replicate the (internal to InnnoDB) row-level locks
that are needed to support SELECT FOR UPDATE statements across multiple
cluster nodes.

https://groups.google.com/forum/#!msg/codership-team/Au1jVFKQv8o/QYV_Z_t5YAEJ



Is that the right link, Jay? I'm taking your word on the write-intent
locks not being replicated, but that link seems to say the opposite.


This link is better:

http://www.percona.com/blog/2014/09/11/openstack-users-shed-light-on-percona-xtradb-cluster-deadlock-issues/


Specifically the line:

"The local record lock held by the started transation on pxc1 didn’t
play any part in replication or certification (replication happens at
commit time, there was no commit there yet)."


Thanks, Jay, that's a great article.

Based on that, I think I may have misunderstood what you were saying
before. I currently understand that the behaviour of select ... for
update is correct on Galera, it's just not very efficient. Correct in
this case meaning it aborts the transaction due to a correctly detected
lock conflict.

FWIW, that was pretty much my original understanding, but without the
detail.

To expand: Galera doesn't replicate write intent locks, but it turns out
it doesn't have to for correctness. The reason is that the conflict
between a local write intent lock and a remote write, which is
replicated, will always be detected during or before local certification.


Exactly correct.

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] [all][tc] Lets keep our community open, lets fight for it

[Brian Curtin]

On Wed, Feb 11, 2015 at 1:43 PM, Jeremy Stanley  wrote:
> Also, if there are people on this list who feel like
> discussions here sometimes get negative or uncomfortable, I'm happy
> to point you to free software community mailing lists (more than I
> can count on all my fingers and toes) whose day-to-day interactions
> make the worst of our flame wars (if you can even call them that)
> look like a gradeschool holiday pageant by comparison.

If people feel it's a negative or uncomfortable environment, find out
why and try to do something to improve it. Telling someone that there
are worse options out there is the opposite of fostering an open
community.

__
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] [all][tc] Lets keep our community open, lets fight for it

[Jeremy Stanley]

On 2015-02-11 09:20:34 -0800 (-0800), Clint Byrum wrote:
[...]
> That said, I do want us to talk about uncomfortable things when
> necessary. I think this thread is not something where it will be
> entirely productive to stay 100% positive throughout. We might
> just have to use some negative language along side our positive
> suggestions to make sure people have an efficient way to measure
> their own behavior.

Well said. Also, if there are people on this list who feel like
discussions here sometimes get negative or uncomfortable, I'm happy
to point you to free software community mailing lists (more than I
can count on all my fingers and toes) whose day-to-day interactions
make the worst of our flame wars (if you can even call them that)
look like a gradeschool holiday pageant by comparison. I'm regularly
surprised by how positive and civil we manage to keep things in our
corner of the free software world.
-- 
Jeremy Stanley

__
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] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested

[Maish Saidel-Keesing]

Is Ceilometer ready for prime time?

I would be interested in hearing from people who have deployed OpenStack 
clouds with Ceilometer, and their experience. Some of the topics I am 
looking for feedback on are:


- Database Size
- MongoDB management, Sharding, replica sets etc.
- Replication strategies
- Database backup/restore
- Overall useability
- Gripes, pains and problems (things to look out for)
- Possible replacements for Ceilometer that you have used instead


If you are willing to share - I am sure it will be beneficial to the 
whole community.


Thanks in Advance


With best regards,


Maish Saidel-Keesing
Platform Architect
Cisco




__
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][api] How to handle API changes in contrib/*.py

[Jay Pipes]

Ping. Chris, Alex, Ken, do we have an answer to Claudiu's questions below?

On 02/02/2015 05:51 PM, Claudiu Belu wrote:

Hello!

There have been some discussion on what nova-api should return after
a change in the API itself.

So, the change that generated this discussion is an API change to 2.2
is: https://review.openstack.org/#/c/140313/23

- **2.2**

Added Keypair type.

A user can request the creation of a certain 'type' of keypair (ssh
or x509).

If no keypair type is specified, then the default 'ssh' type of
keypair is created.

Currently, this change was done on *plugins/v3/keypairs.py*, so now,
the 2.2 version will also return the keypair type on keypair-list,
keypair-show, keypair-create.

Microversioning was used, so this behaviour is valid only if the user
 requests the 2.2 version. Version 2.1 will not accept keypair type
as argument, nor will return the keypair type.

Now, the main problem is *contrib/keypairs.py*, microversioning
cannot be applied there. The current commit filters the keypair type,
it won't be returned. But there have been reviews stating that
returning the keypair type is a "back-compatible change". Before
this, there was a review stating that keypair type should not be
returned.

So, finally, my question is: how should the API change be handled in
 *contrib/keypairs.py*?

Best regards,

Claudiu Belu


__



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] [cinder] CURD operation for storage pools in Cinder

[Bruns, Curt E]

Hi Duncan and Pradip,

It was Reddy, a colleague of mine at Intel, that expressed interest with 
managing storage pools in Cinder.  We haven’t put a BP out yet, but we 
definitely think it would be useful and we should get a BP in the works.

- Curt

From: Duncan Thomas mailto:duncan.tho...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, February 11, 2015 at 10:38 AM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [cinder] CURD operation for storage pools in Cinder


As far as I know, this has not been looked at - you need to use whatever 
management tools your backend provides to do this.

There was somebody from Intel IIRC in Paris with some interest in maybe 
starting something about this, but I don't know that it came to much.

Duncan Thomas

On Feb 11, 2015 6:53 PM, "Pradip Mukhopadhyay" 
mailto:pradip.inte...@gmail.com>> wrote:
Hello,



Does Cinder already have a blue-print/planned-schedule for supporting (at least 
in API level - may not be python-client/Horizon levels) the create/edit/delete 
operation on the storage pools?

It is understood that the "read" part 'get_pools' is already there.


If it is already planned/scheduled - what is the time-frame of having it as a 
part of devstack?



Thanks in advance,
Pradip






__
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] [neutron] DVR and l2_population

[Itzik Brown]

Thanks Armando.

Another question:
Every compute node that hosts instances with floating IPs has an IP from 
the external network pool.
If the SNAT is done by the Network Node what is the reason for the 
compute node to have an external IP?


BR,
Itzik

On 02/11/2015 08:13 PM, Armando M. wrote:

L2pop is a requirement.

With the existing agent-based architecture, L2pop is used to update 
the FDB tables on the compute hosts to make east/west traffic possible 
whenever a new port is created or existing one is updated.


Cheers,
Armando

On 10 February 2015 at 23:07, Itzik Brown > wrote:


Hi,

In the Networking guide [1] there is a requirement for l2
population both as
a mechanism driver and in OVS agent when enabling DVR.
Is this is a requirement and if so what is the reason?

Thanks,
Itzik


[1] http://docs.openstack.org/networking-guide/content/ha-dvr.html

__
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


__
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] debtcollector 0.2.0 released

[Joshua Harlow]

The Oslo team is pleased to announce the release of:

debtcollector 0.2.0: A collection of python patterns that help you
collect your technical debt in a non-destructive manner.

For more details, please see the git log history below and:

http://launchpad.net/debtcollector/+milestone/0.2

Please report issues through launchpad:

http://bugs.launchpad.net/debtcollector

Changes in debtcollector 0.1.0..0.2.0
-

497c1b4 Add a removal decorator
7e3f6d4 Add doctested examples into the documentation
f6f967b Add universal wheel tag to setup.cfg

Diffstat (except docs and test files)
-

debtcollector/removals.py   |  94 +
requirements.txt|   1 +
setup.cfg   |   5 +-
8 files changed, 370 insertions(+), 1 deletion(-)

Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 7cc0111..1abdc3e 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8,0 +9 @@ oslo.utils>=1.2.0 # Apache-2.0
+wrapt>=1.7.0 # BSD License


__
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] [all][tc] Lets keep our community open, lets fight for it

[Ben Nemec]

On 02/11/2015 04:52 AM, Daniel P. Berrange wrote:
> On Wed, Feb 11, 2015 at 10:55:18AM +0100, Flavio Percoco wrote:
>> Greetings all,
>>
>> During the last two cycles, I've had the feeling that some of the
>> things I love the most about this community are degrading and moving
>> to a state that I personally disagree with. With the hope of seeing
>> these things improve, I'm taking the time today to share one of my
>> concerns.
>>
>> Since I believe we all work with good faith and we *all* should assume
>> such when it comes to things happening in our community, I won't make
>> names and I won't point fingers - yes, I don't have enough fingers to
>> point based on the info I have. People that fall into the groups I'll
>> mention below know that I'm talking to them.
>>
>> This email is dedicated to the openness of our community/project.
>>
>> ## Keep discussions open
>>
>> I don't believe there's anything wrong about kicking off some
>> discussions in private channels about specs/bugs. I don't believe
>> there's anything wrong in having calls to speed up some discussions.
>> HOWEVER, I believe it's *completely* wrong to consider those private
>> discussions sufficient. If you have had that kind of private
>> discussions, if you've discussed a spec privately and right after you
>> went upstream and said: "This has been discussed in a call and it's
>> good to go", I beg you to stop for 2 seconds and reconsider that. I
>> don't believe you were able to fit all the community in that call and
>> that you had enough consensus.
> 
> With the timezones of our worldwide contributors it is pretty much
> guaranteed that any realtime phone call will have excluded a part
> of our community.
> 
>> Furthermore, you should consider that having private conversations, at
>> the very end, doesn't help with speeding up discussions. We've a
>> community of people who *care* about the project they're working on.
>> This means that whenever they see something that doesn't make much
>> sense, they'll chime in and ask for clarification. If there was a
>> private discussion on that topic, you'll have to provide the details
>> of such discussion and bring that person up to date, which means the
>> discussion will basically start again... from scratch.
> 
> I can see that if people have reached an impass in discussions via
> email or irc, it is sometimes helpful to have a call to break a
> roadblock. I absolutely agree though that the results of any such
> calls should not be presented as a final decision. At the very least
> it is neccessary to describe the rationale for the POV obtained as
> a result of the call, and give the broader community the opportunity
> to put forward counterpoints if required. We should certainly not
> just say 'its good to go' and +A sommething based on a private call.
> 
>> ## Mailing List vs IRC Channel
>>
>> I get it, our mailing list is freaking busy, keeping up with it is
>> hard and time consuming and that leads to lots of IRC discussions. I
>> don't think there's anything wrong with that but I believe it's wrong
>> to expect *EVERYONE* to be in the IRC channel when those discussions
>> happen.
> 
> Again, timezones. It is a physical impossibility for most people to
> be on IRC for more than 8 hours a day, so that's only 1/3 of the day
> that any signle person will likely be on IRC.  And no, expecting
> people to have a permanently connected IRC proxy and then read the
> other 16 hours of logs each morning is not a solution.
> 
> Personally I've stopped joining IRC most the time regardless, because
> I feel I am far more productive when I'm not being interrupted with
> IRC pings every 20 minutes. There should be few things so urgent that
> they can't be dealt with over email. Again because of our timezone
> differences we should be wary of making important decisions in a
> rush - anything remotely non-trivial should have at least a 24 hour
> window to allow people on all timezones a chance to see the point
> and join in discussion.
> 
>> If you are discussing something on IRC that requires the attention of
>> most of your project's community, I highly recommend you to use the
>> mailing list as oppose to pinging everyone independently and fighting
>> with time zones. Using IRC bouncers as a replacement for something
>> that should go to the mailing list is absurd. Please, use the mailing
>> list and don't be afraid of having a bigger community chiming in in
>> your discussion.  *THAT'S A GOOD THING*
>>
>> Changes, specs, APIs, etc. Everything is good for the mailing list.
>> We've fought hard to make this community grow, why shouldn't we take
>> advantage of it?
> 
> There are alot of IRC meetings that take place in the project:
> 
>   https://wiki.openstack.org/wiki/Meetings
> 
> and alot of decisions get made in these meetings. Very rarely do
> the decisions ever get disseminated to the mailing lists. We seem
> to rely on the fact that we have IRC logs of the meetings as a way
> to communicate what

Re: [openstack-dev] [nova] Feature Freeze Exception Request

[Lin Hua Cheng]

+1

The specs has been merged through FFE request, doesn't that mean the BP is
already approved?  Maybe the status of the BP just need to be updated to
reflect the current state.

-Lin

On Wed, Feb 11, 2015 at 9:26 AM, Sajeesh Cimson Sasi 
wrote:

>  Hello,
>I'd like to request a feature freeze exception for the change,
> https://review.openstack.org/#/c/149828/
>This change implements NestedQuotaDriver that does the quota
> management in nested projects.
>
>The specs has been merged :*
> https://review.openstack.org/#/c/129420/
> *
>
>The blueprint was approved.
>
> https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api
>
> But due to Feature Freeze,its status was changed to "Pending
> Approval" .
>
> Keystone already supports nested projects. This change implements the
> quota  management  of those nested projects. Without this
> change(NestedQuotaDriver), Nova will not be able to support nested
> projects,even if they exist in keystone.NestedQuotaDriver is made by adding
> nested quota functionality to the existing DbQuotaDriver. It is a superset
> of DbQuotaDriver and its supports one to N levels of projects.That is,it
> can support nested as well as non-nested projects.
>
> The implementation of NestedQuotaDriver is over and the code is under
> review. All the use cases mentioned in the blue print have been
> implemented. It is supposed to become the default quota driver of nova.To
> avoid any potential risks,it can be deployed as an optional driver in the
> current release(Kilo) and can be made default in the next release(L).
>
> Kindly grant freeze exception for the change.Nested projects are very
> important for large organizations like CERN who are waiting for this code
> to get merged in Kilo.Yahoo also has  expressed keen interest in this
> feature.
>
>   best regards
>sajeesh
>
> __
> 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] [congress][Policy][Copper]Collaboration between OpenStack Congress and OPNFV Copper

[Tim Hinrichs]

Hi Zhipeng,

We’d be happy to meet.  Sounds like fun!

I don’t know of anyone on the Congress team who is planning to attend the LF 
collaboration summit.  But we might be able to send a couple of people if it’s 
the only real chance to have a face-to-face.  Otherwise, there are a bunch of 
us in and around Palo Alto.  And of course, phone/google hangout/irc are fine 
options as well.

Tim



On Feb 11, 2015, at 8:59 AM, Zhipeng Huang 
mailto:zhipengh...@gmail.com>> wrote:

Hi Congress Team,

As you might already knew, we had a project in OPNFV covering deployment policy 
called 
Copper,
 in which we identify Congress as one of the upstream projects that we need to 
put our requirement to. Our team has been working on setting up a simple 
openstack environment with congress integrated that could demo simple use cases 
for policy deployment.

Would it possible for you guys and our team to find a time do an 
Copper/Congress interlock meeting, during which Congress Team could introduce 
how to best integrate congress with "vanilla" openstack? Will some of you 
attend LF Collaboration Summit?

Thanks a lot :)

--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OpenDaylight, OpenCompute affcienado
__
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] [all][tc] Lets keep our community open, lets fight for it

[Ben Nemec]

On 02/11/2015 11:19 AM, Amrith Kumar wrote:
> Stefano,
> 
> You write:
> 
> | This is seriously disturbing.
> | 
> | If you're one of those core reviewers hanging out on a private channel,
> | please contact me privately: I'd love to hear from you why we failed as a
> | community at convincing you that an open channel is the place to be.
> | 
> | No public shaming, please: education first.
> 
> I was going to contact you privately but figured that would be ironic given 
> the conversation we're having. So here is my reply to you in the open, for 
> all to see and respond.
> 
> Let me begin by saying that I agree with a lot of what Flavio wrote. 
> 
> Where he says that decisions and discussions must always be made in the open, 
> he is dead-on.
> 
> Where he says that decisions in private are bad, he is dead-on.
> 
> I beg to differ however on the subject of discussions in private (emphasis: 
> discussions, not decisions). Now that sounds bad but let's leave private IRC 
> channels aside.
> 
> If you and I had a phone call, that's not a bad thing. What is bad if we 
> colluded in some way, and made a decision that we then foisted on the 
> community as a "done deal".
> 
> IRC is a great thing and so is the mailing list. And a lot of conversations 
> are well suited for those mediums. And I read them regularly and I find them 
> useful. However, I will admit that there are times when I just pick up the 
> phone and call a colleague or call some other ATC in OpenStack.
> 
> As Flavio says in his email:
> 
> | > ## Keep discussions open
> | >
> | > I don't believe there's anything wrong about kicking off some
> | > discussions in private channels about specs/bugs. I don't believe
> | > there's anything wrong in having calls to speed up some discussions.
> | > HOWEVER, I believe it's *completely* wrong to consider those private
> | > discussions sufficient.
> 
> Further, there are in fact times when members of a core team can have 
> meaningful discussions about things. Security related bugs are one, on 
> occasion things like people's conduct (when it is marginal) and I can make a 
> list of a couple of more things easily, but I think you see the point.
> 
> Given time-zones, long distance costs, and the like, IRC is a good option as 
> is a private skype call or skype IM. Not everything is suitable for 
> IRC/mailing list and a public forum. And in some cases since a public IRC 
> channel with three parallel conversations going can be noisy, a less 
> cluttered private conversation is invaluable.
> 
> Mostly, I'm very happy to see Flavio's email which ends with this:
> 
>> All the above being said, I'd like to thank everyone who fights for the 
>> openness of our community 
>> and encourage everyone to make that a must have thing in each sub-community. 
>> You don't need to 
>> be core-reviewer or PTL to do so. Speak up and help keeping the community as 
>> open as possible.
> 
> Open decision making and discussion are absolutely the lifeblood of an open 
> source community. And I agree, as an ATC I will fight for the open discussion 
> and decision making. In equal measure, I recognize that I'm human and there 
> are times when a quiet "sidebar" with someone, either on the telephone, or 
> over a glass of suitable beverage can go further and quicker than any extent 
> of public conversation with the exact same participants.
> 
> You write:
> 
> | This is seriously disturbing.
> 
> Yes, what would be seriously disturbing would be if there were decisions 
> being made without the open/public scrutiny.
> 
> There seems to be a leap-of-faith that a private IRC channel implies covert 
> decisions and therefore they should be shutdown. OK, great, the Twenty-First 
> Amendment took the same point of view, see how well that worked out.
> 
> I assure you that later today, tomorrow, and the next day, I will have 
> private conversations with other ATC's. Some will be on the telephone, and 
> some will be on public IRC channels with some totally unique name that you'd 
> never know to guess. But, I will try my best to, and I welcome the feedback 
> when people feel that I deviate from the norm of ensuring public, open 
> discussion and decision making where all are invited to participate.
> 
> Personally, I think the focus on password protected IRC channels is a 
> distraction from the real issue that we need to ensure that the rapidly 
> growing community is one where public discussion and decision making are 
> still "the norm". Let's be adult about it and realize that people will have 
> private conversations. What we need to focus on is ensuring that the 
> community rejects "private decision making".
> 
> There, I said it, and I said it in the open.

Here's my thing though: Some discussions are by nature private.  Phone
calls, hallway talks, etc.  As a rule, I don't have a problem with those
sorts of private conversations because they generally provide a benefit
that more public means don't (namely higher bandwid

Re: [openstack-dev] [neutron] DVR and l2_population

[Armando M.]

L2pop is a requirement.

With the existing agent-based architecture, L2pop is used to update the FDB
tables on the compute hosts to make east/west traffic possible whenever a
new port is created or existing one is updated.

Cheers,
Armando

On 10 February 2015 at 23:07, Itzik Brown  wrote:

> Hi,
>
> In the Networking guide [1] there is a requirement for l2 population both
> as
> a mechanism driver and in OVS agent when enabling DVR.
> Is this is a requirement and if so what is the reason?
>
> Thanks,
> Itzik
>
>
> [1] http://docs.openstack.org/networking-guide/content/ha-dvr.html
>
> __
> 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] [keystone] [nova]

[Adam Young]

On 02/11/2015 12:16 PM, Nikolay Makhotkin wrote:

No, I just checked it. Nova receives trust token and raise this error.

In my script, I see:

http://paste.openstack.org/show/171452/

And as you can see, token from trust differs from direct user's token.


The original user needs to have the appropriate role to perform the 
operation on the specified project.  I see the admin role is created on 
the trust. If the trustor did not have that role, the trustee would not 
be able to exececute the trust and get a token.  It looks like you were 
able to execute the trust and get a token,  but I would like you to 
confirm that, and not just trust the keystone client:  either put debug 
statements in Keystone or call the POST to tokens from curl with the 
appropriate options to get a trust token. In short, make sure you have 
not fooled yourself.  You can also look in the token table inside 
Keystone to see the data for the trust token, or validate the token  via 
curl to see the data in it.  In all cases, there should be an OS-TRUST 
stanza in the token data.



If it is still failing, there might be some issue on the Policy side.  I 
have been assuming that you are running with the default policy for Nova.


http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json

I'm not sure which rule matches for list servers (Nova developer input 
would be appreciated)  but I'm guessing it is executing the rule

|
"admin_or_owner": "is_admin:True or project_id:%(project_id)s",

Since that is the default. I am guessing that the project_id in question 
comes from the token here, as that seems to be common, but if not, it 
might be that the two values are mismatched. Perhaps there Proejct ID 
value from the client env var is sent, and matches what the trustor 
normally works as, not the project in question.  If these two values 
don't match, then, yes, the rule would fail.

|




On Wed, Feb 11, 2015 at 7:55 PM, Adam Young > wrote:


On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote:

Hi !

I investigated trust's use cases and encountered the problem:
When I use auth_token obtained from keystoneclient using trust, I
get *403* Forbidden error: *You are not authorized to perform the
requested action.*

Steps to reproduce:

- Import v3 keystoneclient (used keystone and keystoneclient from
master, tried also to use stable/icehouse)
- Import v3 novaclient
- initialize the keystoneclient:
 keystone = keystoneclient.Client(username=username,
password=password, tenant_name=tenant_name, auth_url=auth_url)

- create a trust:
  trust = keystone.trusts.create(
keystone.user_id,
keystone.user_id,
impersonation=True,
role_names=['admin'],
project=keystone.project_id
  )

- initialize new keystoneclient:
  client_from_trust = keystoneclient.Client(
username=username, password=password,
trust_id=trust.id , auth_url=auth_url,
  )

- create nova client using new token from new client:
  nova = novaclient.Client(
auth_token=client_from_trust.auth_token,
auth_url=auth_url_v2,
project_id=from_trust.project_id,
service_type='compute',
username=None,
api_key=None
  )

- do simple request to nova:
nova.servers.list()

- get the error described above.


Maybe I misunderstood something but what is wrong? I supposed I
just can work with nova like it was initialized using direct token.


From what you wrote here it should work, but since Heat has been
doing stuff like this for a while, I'm pretty sure it is your
setup and not a fundamental problem.

I'd take a look at what is going back and forth on the wire and
make sure the right token is being sent to Nova. If it is the
original users token and not the trust token, then you would see
that error.



-- 
Best Regards,

Nikolay


__
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




--
Best Regards,
Nikolay


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

[openstack-dev] [nova][horizon] Inter-project issue : redundant hyperviosr_hostname

[Manickam, Kanagaraj]

Hi,

Nova provides following REST API to get the details of instances provisioned in 
the given hypervisor.
REST API: /v2/​{tenant_id}​/os-hypervisors/​{hypervisor_hostname}​/servers
Ref: http://developer.openstack.org/api-ref-compute-v2-ext.html

This API is consumed in horizon to report hypervisor’s instances details under 
Admin->Hypervisors panel.
According to the above API, nova never should allow same ‘hypervisor_hostname’ 
for more than
one hypervisors, as ‘hypervisor_hostname’  used as identifier, but it allows. 
Due to this reason,
horizon reports invalid data.

So, this should be fixed on horizon, with the intention that, horizon should 
consume the API
provided by nova as it’s and reports correct information.  To address it, bug 
has been filed in horizon
at https://bugs.launchpad.net/horizon/+bug/1402572 (using work-around, it’s 
being fixed)

This could be fixed at the nova side as well by using ‘hypervisor.id’ as 
identifier instead of ‘hypervisor_hostname’
and use it in horizon and python-novaclient as well.

Now this issue  becomes inter-project related. And I’m looking for help to take 
it forward
to get fixed in kilo release. Could someone please help here?

Thanks
Kanagaraj M
__
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] [devstack] Compute-node-only installation fails

[Sean Dague]

On 02/11/2015 11:32 AM, Clark Boylan wrote:
> On Wed, Feb 11, 2015, at 08:18 AM, Alexander Schmidt wrote:
>> Hi Daniel,
>>
>> with your recent change[1] to error handling in stack.sh, compute
>> node only installations via devstack fail because there is
>> no database selected. A database should not be required on
>> compute nodes.
>>
>> Was this done intentionally? lib/database explicitly says:
>>
>> # If ``DATABASE_TYPE`` is unset here no database was selected
>> # This is not an error as multi-node installs will do this on the
>> compute nodes
>>
>> [1] https://review.openstack.org/#/c/149288/
>>
>> Regards,
>> Alex
>>
>>
>> __
>> 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
> 
> We have been setting DATABASE_TYPE [0] so did not notice. Seems like a
> reasonable work around for now and does not install a database server
> (the enabled services list seems to do that). If the intended behavior
> is to not need to set DATABASE_TYPE we should probably revert the
> devstack change then update devstack-gate's compute node localrc
> generation to remove DATABASE_TYPE so that breakage of the behavior has
> a chance of being caught early.
> 
> [0]
> http://logs.openstack.org/79/136179/5/experimental/check-tempest-dsvm-aiopcpu/6f5193e/logs/10.209.161.148-subnode/localrc.txt.gz

Agree, the fix should be setting a default value.

-Sean

-- 
Sean Dague
http://dague.net

__
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] openstack/requirements failure

[Ben Nemec]

On 02/11/2015 11:33 AM, Manickam, Kanagaraj wrote:
> Hi
> 
> In horizon I am trying to increase the python-heatclient>=0.3.0 as part of 
> the review https://review.openstack.org/#/c/154952/ and its failed with 
> following error:
> 
> 
> "Requirement python-heatclient>=0.3.0 does not match openstack/requirements 
> value python-heatclient>=0.2.9"
> More details at 
> https://jenkins03.openstack.org/job/gate-horizon-requirements/110/console
> 
> Could anyone help me to resolve this issue? Thanks.

Requirements changes have to be proposed to global requirements first.
There's a full explanation here:
http://git.openstack.org/cgit/openstack/requirements/tree/README.rst


__
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][vmware] FFE request for ephemeral disk support

[Gary Kotton]

Hi,
The support for the feature has been in flight for over a year now. There is 
one outstanding patch - the resize of ephemeral disks [I].
The patch is based on a series of patches that address critical issues when 
resizing (which were exposed when we were testing this feature).
I really hope that we can get a FFE of this. At the mid cycle meetup we were 
asked to prioritize the BP's and this was the most important one. It is a 
driver parity feature and has been in review for over a year now :(. The 
changes are isolated to the VMware driver.
Thanks in advance
Gary
[I] https://review.openstack.org/121409
__
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] [all][tc] Lets keep our community open, lets fight for it

[Amrith Kumar]

Stefano,

I was informed (in a private message on IRC) that where I said "Twenty First 
amendment" I should have said "Eighteenth Amendment". The former repealed the 
latter.

My apologies to all who were trying to figure out what I may have meant.

-amrith

P.S. Why I got that in a private message I know not.

| -Original Message-
| From: Amrith Kumar [mailto:amr...@tesora.com]
| Sent: Wednesday, February 11, 2015 12:20 PM
| To: OpenStack Development Mailing List (not for usage questions)
| Subject: Re: [openstack-dev] [all][tc] Lets keep our community open, lets
| fight for it
| 
| Stefano,
| 
| You write:
| 
| | This is seriously disturbing.
| |
| | If you're one of those core reviewers hanging out on a private
| | channel, please contact me privately: I'd love to hear from you why we
| | failed as a community at convincing you that an open channel is the
| place to be.
| |
| | No public shaming, please: education first.
| 
| I was going to contact you privately but figured that would be ironic
| given the conversation we're having. So here is my reply to you in the
| open, for all to see and respond.
| 
| Let me begin by saying that I agree with a lot of what Flavio wrote.
| 
| Where he says that decisions and discussions must always be made in the
| open, he is dead-on.
| 
| Where he says that decisions in private are bad, he is dead-on.
| 
| I beg to differ however on the subject of discussions in private
| (emphasis: discussions, not decisions). Now that sounds bad but let's
| leave private IRC channels aside.
| 
| If you and I had a phone call, that's not a bad thing. What is bad if we
| colluded in some way, and made a decision that we then foisted on the
| community as a "done deal".
| 
| IRC is a great thing and so is the mailing list. And a lot of
| conversations are well suited for those mediums. And I read them regularly
| and I find them useful. However, I will admit that there are times when I
| just pick up the phone and call a colleague or call some other ATC in
| OpenStack.
| 
| As Flavio says in his email:
| 
| | > ## Keep discussions open
| | >
| | > I don't believe there's anything wrong about kicking off some
| | > discussions in private channels about specs/bugs. I don't believe
| | > there's anything wrong in having calls to speed up some discussions.
| | > HOWEVER, I believe it's *completely* wrong to consider those private
| | > discussions sufficient.
| 
| Further, there are in fact times when members of a core team can have
| meaningful discussions about things. Security related bugs are one, on
| occasion things like people's conduct (when it is marginal) and I can make
| a list of a couple of more things easily, but I think you see the point.
| 
| Given time-zones, long distance costs, and the like, IRC is a good option
| as is a private skype call or skype IM. Not everything is suitable for
| IRC/mailing list and a public forum. And in some cases since a public IRC
| channel with three parallel conversations going can be noisy, a less
| cluttered private conversation is invaluable.
| 
| Mostly, I'm very happy to see Flavio's email which ends with this:
| 
| > All the above being said, I'd like to thank everyone who fights for
| > the openness of our community and encourage everyone to make that a
| > must have thing in each sub-community. You don't need to be core-
| reviewer or PTL to do so. Speak up and help keeping the community as open
| as possible.
| 
| Open decision making and discussion are absolutely the lifeblood of an
| open source community. And I agree, as an ATC I will fight for the open
| discussion and decision making. In equal measure, I recognize that I'm
| human and there are times when a quiet "sidebar" with someone, either on
| the telephone, or over a glass of suitable beverage can go further and
| quicker than any extent of public conversation with the exact same
| participants.
| 
| You write:
| 
| | This is seriously disturbing.
| 
| Yes, what would be seriously disturbing would be if there were decisions
| being made without the open/public scrutiny.
| 
| There seems to be a leap-of-faith that a private IRC channel implies
| covert decisions and therefore they should be shutdown. OK, great, the
| Twenty-First Amendment took the same point of view, see how well that
| worked out.
| 
| I assure you that later today, tomorrow, and the next day, I will have
| private conversations with other ATC's. Some will be on the telephone, and
| some will be on public IRC channels with some totally unique name that
| you'd never know to guess. But, I will try my best to, and I welcome the
| feedback when people feel that I deviate from the norm of ensuring public,
| open discussion and decision making where all are invited to participate.
| 
| Personally, I think the focus on password protected IRC channels is a
| distraction from the real issue that we need to ensure that the rapidly
| growing community is one where public discussion and decision making a

Re: [openstack-dev] [cinder] CURD operation for storage pools in Cinder

[Duncan Thomas]

As far as I know, this has not been looked at - you need to use whatever
management tools your backend provides to do this.

There was somebody from Intel IIRC in Paris with some interest in maybe
starting something about this, but I don't know that it came to much.

Duncan Thomas
On Feb 11, 2015 6:53 PM, "Pradip Mukhopadhyay" 
wrote:

> Hello,
>
>
>
> Does Cinder already have a blue-print/planned-schedule for supporting (at
> least in API level - may not be python-client/Horizon levels) the
> create/edit/delete operation on the storage pools?
>
> It is understood that the "read" part 'get_pools' is already there.
>
>
> If it is already planned/scheduled - what is the time-frame of having it
> as a part of devstack?
>
>
>
> Thanks in advance,
> Pradip
>
>
>
>
>
>
> __
> 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] [all][tc] Lets keep our community open, lets fight for it

[Clint Byrum]

Excerpts from Stefano Maffulli's message of 2015-02-11 06:14:39 -0800:
> On Wed, 2015-02-11 at 10:55 +0100, Flavio Percoco wrote:
> > This email is dedicated to the openness of our community/project.
> 
> It's good to have a reminder every now and then. Thank you Flavio for
> caring enough to notice bad patterns and for raising a flag. 
> 
> > ## Keep discussions open
> > 
> > I don't believe there's anything wrong about kicking off some
> > discussions in private channels about specs/bugs. I don't believe
> > there's anything wrong in having calls to speed up some discussions.
> > HOWEVER, I believe it's *completely* wrong to consider those private
> > discussions sufficient. 
> [...]
> 
> Well said. Conversations can happen anywhere and any time, but they
> should stay in open and accessible channels. Consensus needs to be built
> and decisions need to be shared, agreed upon by the community at large
> (and mailing lists are the most accessible media we have). 
> 
> That said, it's is very hard to generalize and I'd rather deal/solve
> specific examples. Sometimes, I'm sure there are episodes when a fast
> decision was needed and a limited amount of people had to carry the
> burden of responsibility. Life is hard, software development is hard and
> general rules sometimes need to be adapted to the reality. Again, too
> much generalization here for what I'm confortable with.
> 
> Maybe it's worth repeating that I'm personally (and in my role)
> available to listen and mediate in cases when communication seems to
> happen behind closed doors. If you think something unhealthy is
> happening, talk to me (confidentiality assured).
> 
> > ## Mailing List vs IRC Channel
> > 
> > I get it, our mailing list is freaking busy, keeping up with it is
> > hard and time consuming and that leads to lots of IRC discussions.
> 
> Not sure I agree with the causality but, the facts are those: traffic on
> the list and on IRC is very high (although not increasing anymore
> [1][2]).
> 
> >  I
> > don't think there's anything wrong with that but I believe it's wrong
> > to expect *EVERYONE* to be in the IRC channel when those discussions
> > happen.
> 
> Email is hard, I have the feeling that the vast majority of people use
> bad (they all suck, no joke) email clients. Lots and lots of email is
> even worse. Most contributors commit very few patches: the investment
> for them to configure their MUA to filter our traffic is too high.
> 
> I have added more topics today to the openstack-dev list[3]. Maybe,
> besides filtering on the receiving end, we may spend some time
> explaining how to use mailman topics? I'll draft something on Ask, it
> may help those that have limited interest in OpenStack.
> 
> What else can we do to make things better?
> 

I am one of those people who has a highly optimized MUA for mailing list
reading. It is still hard. Even with one keypress to kill threads from
view forever, and full text index searching, I still find it takes me
an hour just to filter the "don't want to see" from the "want to see"
threads each day.

The filtering on the list-server side I think is not known by everybody,
and it might be a good idea to socialize it even more, and maybe even
invest in making the UI for it really straight forward for people to
use.

That said, even if you just choose [all], and [yourproject], some
[yourproject] tags are pretty busy.

> > ## Cores are *NOT* special
> > 
> > At some point, for some reason that is unknown to me, this message
> > changed and the feeling of core's being some kind of superheros became
> > a thing. It's gotten far enough to the point that I've came to know
> > that some projects even have private (flagged with +s), password
> > protected, irc channels for core reviewers.
> 
> This is seriously disturbing.
> 
> If you're one of those core reviewers hanging out on a private channel,
> please contact me privately: I'd love to hear from you why we failed as
> a community at convincing you that an open channel is the place to be.
> 
> No public shaming, please: education first.
> 

I really like what you had to say above. I think we can do better and
I don't really blame those who've worked around OpenStack's problems
with their own solution. Whether or not that solution is in fact quite
dangerous for the project as a whole is another matter that we should
consider separately from "why did these people feel a need to isolate
themselves?"

I am confident this community will find a solution that works well
enough that we can move past this swiftly.

__
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/requirements failure

[Manickam, Kanagaraj]

Hi

In horizon I am trying to increase the python-heatclient>=0.3.0 as part of the 
review https://review.openstack.org/#/c/154952/ and its failed with following 
error:


"Requirement python-heatclient>=0.3.0 does not match openstack/requirements 
value python-heatclient>=0.2.9"
More details at 
https://jenkins03.openstack.org/job/gate-horizon-requirements/110/console

Could anyone help me to resolve this issue? Thanks.

Regards
Kanagaraj M
__
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] [devstack] Compute-node-only installation fails

[Daniel P. Berrange]

On Wed, Feb 11, 2015 at 08:32:31AM -0800, Clark Boylan wrote:
> On Wed, Feb 11, 2015, at 08:18 AM, Alexander Schmidt wrote:
> > Hi Daniel,
> > 
> > with your recent change[1] to error handling in stack.sh, compute
> > node only installations via devstack fail because there is
> > no database selected. A database should not be required on
> > compute nodes.
> > 
> > Was this done intentionally? lib/database explicitly says:
> > 
> > # If ``DATABASE_TYPE`` is unset here no database was selected
> > # This is not an error as multi-node installs will do this on the
> > compute nodes
> > 
> > [1] https://review.openstack.org/#/c/149288/
> > 
> > Regards,
> > Alex
> 
> We have been setting DATABASE_TYPE [0] so did not notice. Seems like a
> reasonable work around for now and does not install a database server
> (the enabled services list seems to do that). If the intended behavior
> is to not need to set DATABASE_TYPE we should probably revert the
> devstack change then update devstack-gate's compute node localrc
> generation to remove DATABASE_TYPE so that breakage of the behavior has
> a chance of being caught early.

I posted a revert review for my change

   https://review.openstack.org/#/c/154966/

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] Feature Freeze Exception Request

[Sajeesh Cimson Sasi]

Hello,
   I'd like to request a feature freeze exception for the change,
https://review.openstack.org/#/c/149828/
   This change implements NestedQuotaDriver that does the quota 
management in nested projects.

   The specs has been merged : https://review.openstack.org/#/c/129420/

   The blueprint was approved.
   https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api

But due to Feature Freeze,its status was changed to "Pending 
Approval" .

Keystone already supports nested projects. This change implements the quota  
management  of those nested projects. Without this change(NestedQuotaDriver), 
Nova will not be able to support nested projects,even if they exist in 
keystone.NestedQuotaDriver is made by adding nested quota functionality to the 
existing DbQuotaDriver. It is a superset of DbQuotaDriver and its supports one 
to N levels of projects.That is,it can support nested as well as non-nested 
projects.

The implementation of NestedQuotaDriver is over and the code is under review. 
All the use cases mentioned in the blue print have been implemented. It is 
supposed to become the default quota driver of nova.To avoid any potential 
risks,it can be deployed as an optional driver in the current release(Kilo) and 
can be made default in the next release(L).

Kindly grant freeze exception for the change.Nested projects are very important 
for large organizations like CERN who are waiting for this code to get merged 
in Kilo.Yahoo also has  expressed keen interest in this feature.

  best regards
   sajeesh
__
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] Flavor extra-spec and image metadata documentation

[Anne Gentle]

On Wed, Feb 11, 2015 at 5:15 AM, Daniel P. Berrange 
wrote:

> On Wed, Feb 11, 2015 at 12:03:58PM +0100, Pasquale Porreca wrote:
> > Thank you for all answers.
> > I know that meta data tags are "free" to use with any key/value, still
> > there are some specific values that triggers pieces of code in nova (or
> > maybe even in other components). In particular I am working on one of
> > these key/value, in my case it should enable the
> >
> > 
> >
> > parameter in libvirt. Anyway even if my code is merged, no one will know
> > about it (except myself and the reviewers) if it is not documented
> > somewhere. A DocImpact flag was added to the commit message, but I still
> > don't know how to proper document it. I may create/update existing wiki
> > pages, but I would have preferred an official documentation: I was not
> > able to find the wiki page proposed by Daniel Berrange, even if I had
> > been searching exactly to something similar :(
> > It is very good that there is a work to objectify image meta, anyway is
> > there any recommendation  how to document it in the meanwhile?
>
> For people submitting patches to nova the expectation is simply that they
> add DocImpact and have a commit message that describes the usage of the
> new property. The docs team work from this data.


Technically, DocImpact creates a doc bug for the Launchpad project
indicated in a configuration file. It's not always an indicator for the doc
team to work from, it is the responsibility of each project to take care of
their impactful doc bugs.

For example, there were over 50 new bugs logged last week, and no way for a
centralized doc team to keep up with the incoming DocImpact requests, not
even to triage.

So please, spread the word wide and far that DocImpact is merely a
mechanism to track that further doc work is needed for the feature to be
completed.

Thanks,
Anne


> There's no current formal
> docs that I'd expect you to be editing/updating.
>
> > I would also know if there is any naming convention for image meta and
> > flavor extra-spec keys: in my case I used hw_reboot_timeoutand
> > hw:reboot_timeout respectively, but it is more a bios than hardware
> > feature and they are handled in nova/virt/libvirt/driver.py rather than
> > nova/virt/hardware.py so maybe the name choice was not so good.
>
> In terms of image metadata, broadly speaking, we're aiming to standardize
> on 3 name prefixes in Nova
>
>  'hw' - stuff that affects guest hardware configuration (this includes
> the BIOS settings, since that's hardware firmware)
>  'os' - stuff that affects the guest operating system setup
>  'img' - stuff Nova uses related to managing images
>
> So, your choice of 'hw_reboot_timeout' for image and 'hw:reboot_timeout'
> for the flavour  is correct.
>
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
> :|
>
> __
> 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
>



-- 
Anne Gentle
annegen...@justwriteclick.com
__
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] [all][tc] Lets keep our community open, lets fight for it

[Clint Byrum]

Excerpts from Nikola Đipanov's message of 2015-02-11 05:26:47 -0800:
> On 02/11/2015 02:13 PM, Sean Dague wrote:
> > 
> > If core team members start dropping off external IRC where they are
> > communicating across corporate boundaries, then the local tribal effects
> > start taking over. You get people start talking about the upstream as
> > "them". The moment we get into us vs. them, we've got a problem.
> > Especially when the upstream project is "them".
> > 
> 
> A lot of assumptions being presented as fact here.
> 
> I believe the technical term for the above is 'slippery slope fallacy'.
> 

I don't see that fallacy, though it could descend into that if people
keep pushing in that direction. Where I think Sean did a nice job
stopping short of the slippery slope is that he only identified the step
that is happening _now_, not the next step.

I tend to agree that right now, if core team members are not talking
on IRC to other core members in the open, whether inside or outside
corporate boundaries, then we do see an us vs. them mentality happen.
It's not "I think thats the next step". I have personally seen that
happening and will work hard to stop it. I think Sean has probably seen
his share of it too,  as that is what he described in detail without
publicly shaming anyone or any company (well done Sean).

> We can and _must_ do much better than this on this mailing list! Let's
> drag the discussion level back up!

I'm certain we can always improve, and I appreciate you taking the time
to have a Gandalf moment to stop the Balrog of fallacy from  entering
this thread. We seriously can't let the discussion slip down that
slope.. oh wait.

That said, I do want us to talk about uncomfortable things when
necessary. I think this thread is not something where it will be entirely
productive to stay 100% positive throughout. We might just have to use
some negative language along side our positive suggestions to make sure
people have an efficient way to measure their own behavior.

__
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] [all][tc] Lets keep our community open, lets fight for it

[Amrith Kumar]

Stefano,

You write:

| This is seriously disturbing.
| 
| If you're one of those core reviewers hanging out on a private channel,
| please contact me privately: I'd love to hear from you why we failed as a
| community at convincing you that an open channel is the place to be.
| 
| No public shaming, please: education first.

I was going to contact you privately but figured that would be ironic given the 
conversation we're having. So here is my reply to you in the open, for all to 
see and respond.

Let me begin by saying that I agree with a lot of what Flavio wrote. 

Where he says that decisions and discussions must always be made in the open, 
he is dead-on.

Where he says that decisions in private are bad, he is dead-on.

I beg to differ however on the subject of discussions in private (emphasis: 
discussions, not decisions). Now that sounds bad but let's leave private IRC 
channels aside.

If you and I had a phone call, that's not a bad thing. What is bad if we 
colluded in some way, and made a decision that we then foisted on the community 
as a "done deal".

IRC is a great thing and so is the mailing list. And a lot of conversations are 
well suited for those mediums. And I read them regularly and I find them 
useful. However, I will admit that there are times when I just pick up the 
phone and call a colleague or call some other ATC in OpenStack.

As Flavio says in his email:

| > ## Keep discussions open
| >
| > I don't believe there's anything wrong about kicking off some
| > discussions in private channels about specs/bugs. I don't believe
| > there's anything wrong in having calls to speed up some discussions.
| > HOWEVER, I believe it's *completely* wrong to consider those private
| > discussions sufficient.

Further, there are in fact times when members of a core team can have 
meaningful discussions about things. Security related bugs are one, on occasion 
things like people's conduct (when it is marginal) and I can make a list of a 
couple of more things easily, but I think you see the point.

Given time-zones, long distance costs, and the like, IRC is a good option as is 
a private skype call or skype IM. Not everything is suitable for IRC/mailing 
list and a public forum. And in some cases since a public IRC channel with 
three parallel conversations going can be noisy, a less cluttered private 
conversation is invaluable.

Mostly, I'm very happy to see Flavio's email which ends with this:

> All the above being said, I'd like to thank everyone who fights for the 
> openness of our community 
> and encourage everyone to make that a must have thing in each sub-community. 
> You don't need to 
> be core-reviewer or PTL to do so. Speak up and help keeping the community as 
> open as possible.

Open decision making and discussion are absolutely the lifeblood of an open 
source community. And I agree, as an ATC I will fight for the open discussion 
and decision making. In equal measure, I recognize that I'm human and there are 
times when a quiet "sidebar" with someone, either on the telephone, or over a 
glass of suitable beverage can go further and quicker than any extent of public 
conversation with the exact same participants.

You write:

| This is seriously disturbing.

Yes, what would be seriously disturbing would be if there were decisions being 
made without the open/public scrutiny.

There seems to be a leap-of-faith that a private IRC channel implies covert 
decisions and therefore they should be shutdown. OK, great, the Twenty-First 
Amendment took the same point of view, see how well that worked out.

I assure you that later today, tomorrow, and the next day, I will have private 
conversations with other ATC's. Some will be on the telephone, and some will be 
on public IRC channels with some totally unique name that you'd never know to 
guess. But, I will try my best to, and I welcome the feedback when people feel 
that I deviate from the norm of ensuring public, open discussion and decision 
making where all are invited to participate.

Personally, I think the focus on password protected IRC channels is a 
distraction from the real issue that we need to ensure that the rapidly growing 
community is one where public discussion and decision making are still "the 
norm". Let's be adult about it and realize that people will have private 
conversations. What we need to focus on is ensuring that the community rejects 
"private decision making".

There, I said it, and I said it in the open.

-amrith

--

Amrith Kumar, CTO Tesora (www.tesora.com)

Twitter: @amrithkumar  
IRC: amrith @freenode 
I work on OpenStack Trove (#openstack-trove)



| -Original Message-
| From: Stefano Maffulli [mailto:stef...@openstack.org]
| Sent: Wednesday, February 11, 2015 9:15 AM
| To: openstack-dev@lists.openstack.org
| Subject: Re: [openstack-dev] [all][tc] Lets keep our community open, lets
| fight for it
| 
| On Wed, 2015-02-11 at 10:55 +0100, Flavio Percoco wrote:
| > This email is dedicated t

Re: [openstack-dev] [keystone] [nova]

[Nikolay Makhotkin]

No, I just checked it. Nova receives trust token and raise this error.

In my script, I see:

http://paste.openstack.org/show/171452/

And as you can see, token from trust differs from direct user's token.

On Wed, Feb 11, 2015 at 7:55 PM, Adam Young  wrote:

>  On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote:
>
> Hi !
>
>  I investigated trust's use cases and encountered the problem: When I use
> auth_token obtained from keystoneclient using trust, I get *403*
> Forbidden error:  *You are not authorized to perform the requested
> action.*
>
>  Steps to reproduce:
>
>  - Import v3 keystoneclient (used keystone and keystoneclient from
> master, tried also to use stable/icehouse)
> - Import v3 novaclient
> - initialize the keystoneclient:
>   keystone = keystoneclient.Client(username=username, password=password,
> tenant_name=tenant_name, auth_url=auth_url)
>
>  - create a trust:
>   trust = keystone.trusts.create(
> keystone.user_id,
> keystone.user_id,
> impersonation=True,
> role_names=['admin'],
> project=keystone.project_id
>   )
>
>  - initialize new keystoneclient:
>client_from_trust = keystoneclient.Client(
> username=username, password=password,
> trust_id=trust.id, auth_url=auth_url,
>   )
>
>  - create nova client using new token from new client:
>nova = novaclient.Client(
> auth_token=client_from_trust.auth_token,
> auth_url=auth_url_v2,
> project_id=from_trust.project_id,
> service_type='compute',
> username=None,
> api_key=None
>   )
>
>  - do simple request to nova:
>   nova.servers.list()
>
>  - get the error described above.
>
>
> Maybe I misunderstood something but what is wrong? I supposed I just can
> work with nova like it was initialized using direct token.
>
>
> From what you wrote here it should work, but since Heat has been doing
> stuff like this for a while, I'm pretty sure it is your setup and not a
> fundamental problem.
>
> I'd take a look at what is going back and forth on the wire and make sure
> the right token is being sent to Nova.  If it is the original users token
> and not the trust token, then you would see that error.
>
>
>  --
>  Best Regards,
> Nikolay
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
>


-- 
Best Regards,
Nikolay
__
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] [glance] Metadef-tags create api change request.

[Okuma, Wayne]

Hello,

I would like to change the metadef-tags create API which was checked into Kilo 
(cycle 1).
The python-glanceclient that would support metadef-tags has not been released 
yet and I would like to make this change before doing so.
The details are here: https://review.openstack.org/#/c/154229/

Thanks and Regards,
Wayne

__
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] [vmware][nova] Prevent HA configuration with different hostnames

[Matthew Booth]

On 11/02/15 16:40, Gary Kotton wrote:
> 
> 
> On 2/11/15, 6:35 PM, "Sylvain Bauza"  wrote:
> 
>>
>> Le 11/02/2015 17:04, Gary Kotton a écrit :
>>> I posted a fix that does not break things and supports HA.
>>> https://review.openstack.org/154029
>>
>>
>> Just let's be clear, HA is *not* supported by Nova now.
> 
> That is not correct. It is actually support if the host_ip is the same. If
> the host_ip is not the same then there is an issue when one of the compute
> nodes restarts - it will delete all instances that do not have its host_ip.

FWIW, I suspect you're correct. My patch enforces that.

So, check out the init code from compute manager:

def init_host(self):
"""Initialization for a standalone compute service."""
self.driver.init_host(host=self.host)

The driver is being configured with the Compute service's 'host' config
variable. Let's scan through and look what else uses that:


def _update_resource_tracker(self, context, instance):
"""Let the resource tracker know that an instance has changed
state."""

if (instance['host'] == self.host and
self.driver.node_is_available(instance['node'])):

Instances with the old host value will be ignored by
_update_resource_tracker. That doesn't sound good.

There's _destroy_evacuated_instances(), which you already found :)

There's this in _validate_instance_group_policy:

group_hosts = group.get_hosts(context, exclude=[instance.uuid])
if self.host in group_hosts:
msg = _("Anti-affinity instance group policy was violated.")

You've changed group affinity.

There's _check_instance_build_time:

filters = {'vm_state': vm_states.BUILDING,
   'host': self.host}

Nova won't check instances created by the old host to see if they're stuck.

There's this in _heal_instance_info_cache:

db_instances = objects.InstanceList.get_by_host(
context, self.host, expected_attrs=[], use_slave=True)

This cleanup job won't find instances created by the old host.

There's this in _poll_rebooting_instances:

filters = {'task_state':
   [task_states.REBOOTING,
task_states.REBOOT_STARTED,
task_states.REBOOT_PENDING],
   'host': self.host}

Nova won't poll instances created by the old host.

This is just a cursory flick through. I'm fairly sure this is going to
be a lot of work to fix. My patch just ensures that Nova refuses to
start instead of letting bad things happen. If you ensure that
'self.host' in the above code is the same for all HA nodes I don't see
why it shouldn't work, though. My patch won't prevent that.

Matt

> 
>>
>> The main reason is that compute *nodes* are considered given by the
>> hypervisor (ie. the virt driver ran by the compute manager worker), so
>> if 2 or more hypervisors on two distinct machines are getting the same
>> list of nodes, then you would have duplicates.
> 
> No. There are no duplicates.
> 
>>
>> -Sylvain
>>
>>> On 2/11/15, 5:55 PM, "Matthew Booth"  wrote:
>>>
 On 11/02/15 15:49, Gary Kotton wrote:
> Hi,
> I do not think that that is a healthy solution. That effectively would
> render a cluster down if the compute node goes down. That would be a
> real
> disaster. The ugly work around is setting the host names to be the
> same
> value.
 I don't think that's an ugly work around. I think that's the only
 currently viable solution.

> This is something that we should discuss at the next summit and I
> would
> hope to propose a topic to talk about.
 Sounds like a good plan. However, given that the bug is marked Critical
 I was assuming we wanted a more expedient fix, which is what I've
 proposed.

 Matt

> Thanks
> Gary
>
> On 2/11/15, 5:31 PM, "Matthew Booth"  wrote:
>
>> I just posted this:
>>
>> https://review.openstack.org/#/c/154907/
>>
>> as an alternative fix for critical bug:
>>
>> https://bugs.launchpad.net/nova/+bug/1419785
>>
>> I've just knocked this up quickly for illustration: it obviously
>> needs
>> plenty of cleanup. I have confirmed that it works, though.
>>
>> Before I take it any further, though, I'd like to get some feedback
>> on
>> the approach. I prefer this to the alternative, because the
>> underlying
>> problem is deeper than supporting evacuate. I'd prefer to be honest
>> with
>> the user and just say it ain't gonna work. The alternative would
>> leave
>> Nova running in a broken state, leaving inconsistent state in its
>> wake
>> as it runs.
>>
>> Matt
>>
>> -- 
>> Matthew Booth
>> Red Hat Engineering, Virtualisation Team
>>
>> Phone: +442070094448 (UK)
>> GPG ID:  D33C3490
>> GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
>>
>>

[openstack-dev] [oslo] liberty summit planning

[Doug Hellmann]

As I mentioned at the meeting Monday, we need to start thinking about the 
number and types of rooms we will need for the summit. I’ve started an etherpad 
to collect topics, just like we did for the kilo summit [1]. Please add your 
ideas to the list there so we can review them.

Thanks,
Doug


[1] https://etherpad.openstack.org/p/liberty-oslo-summit-planning
__
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] [TripleO] update on Puppet integration in Kilo

[Dan Prince]

I wanted to take a few minutes to go over the progress we've made with
TripleO Puppet in Kilo so far.

For those unfamilar with the efforts our initial goal was to be able to
use Puppet as the configuration tool for a TripleO deployment stack.
This is largely built around a Heat capability added in Icehouse called
Software Deployments. By making use of use of the Software Deployment
Puppet hook and building our images with a few puppet specific elements
we can integrate with puppet as a configuration tool. There has been no
blueprint on this effort... blueprints seemed a bit ridged for the task
at hand. After demo'ing the proof of concept patches in Paris we've been
tracking progress on an etherpad here:

https://etherpad.openstack.org/p/puppet-integration-in-heat-tripleo

Lots of details in that etherpad. But I would like to highlight a few
things:

As of a week or so all of the code needed to run devtest_overcloud.sh to
completion using Puppet (and Fedora packages) has landed. Several
upstream TripleO developers have been successful in setting up a Puppet
overcloud using this process.

As of last Friday We have a running CI job! I'm actually very excited
about this one for several reasons. First CI is going to be crucial in
completing the rest of the puppet feature work around HA, etc. Second
because this job does require packages... and a fairly recent Heat
release we are using a new upstream packaging tool called Delorean.
Delorean makes it very easy to "go back in time" so if the upstream
packages break for some reason plugging in a stable repo from yesterday,
or 5 minutes ago should be a quick fix... Lots of things to potentially
talk about in this area around CI on various projects.

The puppet deployment is also proving to be quite configurable. We have
a Heat template parameter called 'EnablePackageInstall' which can be
used to enable or disable Yum package installation at deployment time.
So if you want to do traditional image based deployment with images
containing all of your packages you can do that (no Yum repositories
required). Or if you want to roll out images and install or upgrade
packages at deployment time (rather than image build time) you can do
that too... all by simply modifying this parameter. I think this sort of
configurability should prove useful to those who want a bit of choice
with regards to how packages and the like get installed.

Lots of work is still ongoing (documented in the etherpad above for
now). I would love to see multi-distro support for Puppet configuration
w/ TripleO. At present time we are developing and testing w/ Fedora...
but because puppet is used as a configuration tool I would say adding
multi-distro support should be fairly straightforward. Just a couple of
bits in the tripleo-puppet-elements... and perhaps some upstream
packages too (Delorean would be a good fit here for multi-distro too).

Also, the feedback from those in the Puppet community has been
excellent. Emilien Macchi, Yanis Guenene, Spencer Krum, and Colleen
Murphy have all been quite helpful with questions about style, how to
best use the modules, etc.

Likewise, Steve Hardy and Steve Baker have been very helpful in
addressing issues in the Heat templates.

Appreciate all the help and feedback.

Dan


__
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] [Congress][Delegation] Google doc for working notes

[Tim Hinrichs]

Hi all,

A (growing) group of folks are interested in working on the problem of 
delegating policy from Congress to domain-specific policy engines.  We started 
looking at an NFV use case: migrating VMs to reduce energy consumption.  In 
particular we’re looking into building a VM-placement policy engine built on 
top of a linear programming solver.  Here’s a doc with some working notes where 
we’re trying to figure out how to do the translation from Congress policy to 
the linear program.

https://docs.google.com/document/d/1ksDilJYXV-5AXWON8PLMedDKr9NpS8VbT0jIy_MIEtI/edit?usp=sharing

Tim
__
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] [congress][Policy][Copper]Collaboration between OpenStack Congress and OPNFV Copper

[Zhipeng Huang]

Hi Congress Team,

As you might already knew, we had a project in OPNFV covering deployment
policy called Copper , in which we identify
Congress as one of the upstream projects that we need to put our
requirement to. Our team has been working on setting up a simple openstack
environment with congress integrated that could demo simple use cases for
policy deployment.

Would it possible for you guys and our team to find a time do an
Copper/Congress interlock meeting, during which Congress Team could
introduce how to best integrate congress with "vanilla" openstack? Will
some of you attend LF Collaboration Summit?

Thanks a lot :)

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OpenDaylight, OpenCompute affcienado
__
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] [keystone] [nova]

[Adam Young]

On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote:

Hi !

I investigated trust's use cases and encountered the problem: When I 
use auth_token obtained from keystoneclient using trust, I get *403* 
Forbidden error: *You are not authorized to perform the requested action.*


Steps to reproduce:

- Import v3 keystoneclient (used keystone and keystoneclient from 
master, tried also to use stable/icehouse)

- Import v3 novaclient
- initialize the keystoneclient:
 keystone = keystoneclient.Client(username=username, 
password=password, tenant_name=tenant_name, auth_url=auth_url)


- create a trust:
  trust = keystone.trusts.create(
keystone.user_id,
keystone.user_id,
impersonation=True,
role_names=['admin'],
project=keystone.project_id
  )

- initialize new keystoneclient:
  client_from_trust = keystoneclient.Client(
username=username, password=password,
trust_id=trust.id , auth_url=auth_url,
  )

- create nova client using new token from new client:
  nova = novaclient.Client(
auth_token=client_from_trust.auth_token,
auth_url=auth_url_v2,
project_id=from_trust.project_id,
service_type='compute',
username=None,
api_key=None
  )

- do simple request to nova:
nova.servers.list()

- get the error described above.


Maybe I misunderstood something but what is wrong? I supposed I just 
can work with nova like it was initialized using direct token.


From what you wrote here it should work, but since Heat has been doing 
stuff like this for a while, I'm pretty sure it is your setup and not a 
fundamental problem.


I'd take a look at what is going back and forth on the wire and make 
sure the right token is being sent to Nova.  If it is the original users 
token and not the trust token, then you would see that error.




--
Best Regards,
Nikolay


__
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

[openstack-dev] [cinder] CURD operation for storage pools in Cinder

[Pradip Mukhopadhyay]

Hello,



Does Cinder already have a blue-print/planned-schedule for supporting (at
least in API level - may not be python-client/Horizon levels) the
create/edit/delete operation on the storage pools?

It is understood that the "read" part 'get_pools' is already there.


If it is already planned/scheduled - what is the time-frame of having it as
a part of devstack?



Thanks in advance,
Pradip
__
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] [devstack] [third-party] how to use a devstack external plugin in gate testing

[Jaume Devesa]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

I'm working in the same job as Kyle for the midonet plugin, but first
I need to do some changes in devstack. (Sean's review on my patch[1]
has lead me to this conversation).

After talking with Lucas, (Midokura's responsible of Third-party
testing), we have a question about this that involve the third-party
folks: if we get our own Jenkins job that tests devstack with midonet
and we include this job in the Neutron's gate (as non-voting, of
course), that would be considered Neutron Third-party testing?

Can we chat about this on next Monday's third party meeting?

Regards,

[1]: https://review.openstack.org/#/c/152876

El 06/02/15 a las 22:54, Kyle Mestery escribió:

,

OpenStack Development Mailing List (not for usage questions)

OpenStack Development Mailing List (not for usage questions)


- -- 
Jaume Devesa
Software Engineer, Midokura
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJU24bCAAoJEPvO/ogkgqHBFvMQAJAQM83wgOr6WIcRr3hOZthd
d82JVjXRdY282hvu2Eid+n47RdEfwBTbRkJnnKyWW9IcxsO8HX3oEjPct4H33CCB
c8kjQUile7WVQZt2obAT+PMwbub9u1/WTxnzUIUujg6NhKoXmM+f5lEawCh6k1HZ
UqiTIb+8P08m+IhOIAjG95lTENSAX9P4YJA48vTDLtyODYo6kuWYh1TVx5IxvpnU
Min1xMcxYr2mPNZv1P9Hu+cOx9g1ZDPvUEXe03lzR4HqFkisXe2Xi8OK+J778KyT
xCSGoJ19x3pcuDIqUy2LQ5wgv41vuQtd5ASJLx7oaXk/Bsr1CRv6NSK1zYb7zA/C
As4bTwpZQqKCnRfYVrys8cDWS2ZVGH1APQT7AhVL8CnluLPTMwjrbNRzv3gYi5kU
CPh0aGTdt9hsi061k7Th/A2Op7Zz6MAT3fWjscJYSftdX0g+l/UYGpUHCoagynew
KKkNS2BfM1AIvTpyC2zKeV/u53Oup1+htkV+rc8TMHXIztpbvxWVdG/BP9sao2xC
iIFPjkyaL4ZyG20O0R5NzR0gYxjZMutRbxl2iyC8fpLOJRY1DosOg7he3htgAM45
J7VPZp41cW8CmR//2G8hinBC+cW6SZzhNeOogzT89KEn/a0KV5SoMxCy0oLfaDR7
upfUpAWAO1vIgl53ftFj
=yUo7
-END PGP SIGNATURE-

__
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] [devstack] [third-party] how to use a devstack external plugin in gate testing

[Jaume Devesa]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

I'm working in the same job as Kyle for the midonet plugin, but first
I need to do some changes in devstack. (Sean's review on my patch[1]
has lead me to this conversation).

After talking with Lucas, (Midokura's responsible of Third-party
testing), we have a question about this that involve the third-party
folks: if we get our own Jenkins job that tests devstack with midonet
and we include this job in the Neutron's gate (as non-voting, of
course), that would be considered Neutron Third-party testing?

Can we chat about this on next Monday's third party meeting?

Regards,

[1]: https://review.openstack.org/#/c/152876

El 06/02/15 a las 22:54, Kyle Mestery escribió:
> On Fri, Feb 6, 2015 at 1:36 PM, Sean Dague  wrote:
> 
>> For those that didn't notice, on the Devstack team we've started 
>> to push back on new in-tree support for all the features. That's 
>> intentional. We've got an external plugin interface now -
>> 
>> http://docs.openstack.org/developer/devstack/plugins.html#externally-hosted-plugins
>>
>>
>> 
,
>> and have a few projects like the ec2api and glusterfs that are 
>> successfully using it. Our Future direction is to do more of
>> this - https://review.openstack.org/#/c/150789/
>> 
>> The question people ask a lot is 'but, how do I do a gate job 
>> with the external plugin?'.
>> 
>> Starting with the stackforge/ec2api we have an example up on how 
>> to do that: https://review.openstack.org/#/c/153659/
>> 
>> The important bits are as follows:
>> 
>> 1. the git repo that you have your external plugin in *must* be 
>> in gerrit. stackforge is fine, but it has to be hosted in the 
>> OpenStack infrastructure.
>> 
>> 2. The job needs to add your PROJECT to the projects list, i.e.:
>> 
>> export PROJECTS="stackforge/ec2-api $PROJECTS"
>> 
>> 3. The job needs to add a DEVSTACK_LOCAL_CONFIG line for the 
>> plugin enablement:
>> 
>> export DEVSTACK_LOCAL_CONFIG="enable_plugin ec2-api 
>> git://git.openstack.org/stackforge/ec2-api"
>> 
>> Beyond that you can define your devstack job however you like.
>> It can test with Tempest. It can instead use a post_test_hook
>> for functional testing. Whatever is appropriate for your
>> project.
>> 
>> This is awesome Sean! Thanks for the inspiration here. In fact,
>> I just
> pushed a series of patches [1] [2] which do the same for the 
> networking-odl stackforge project.
> 
> Thanks, Kyle
> 
> [1] https://review.openstack.org/#/c/153704/ [2] 
> https://review.openstack.org/#/c/153705/
> 
> -Sean
>> 
>> -- Sean Dague http://dague.net
>> 
>> __
>>
>>
>> 
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
> 

- -- 
Jaume Devesa
Software Engineer, Midokura
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJU24bCAAoJEPvO/ogkgqHBpKMP/0aQoCNgQs/8w8gDjmUxlzI4
BE3e3+bGPKKwBNusc6N1i7ptoqz9WU+Atl38uOvxYabFYig94l639tJxTUQGOGQ8
mSYdq+MNMqr/ExKp2M5SQr4QNeMlB8TqqBTdzwH+HIhNu4Het8aybwlLo4O2XBFQ
zFPVtLCxd9d3LlTyTztHg0oQ2U4vZDwdSLyVytFFrq9orjXFKAl6JRIssR9Kf4t4
Raxm2KTjbukxmo/4jwhJl9c1Cm/y+RmRinyXIrh0ppglP80xaIp0RljqhY3UEQRu
ifgcxEod7HZNTHeTksg7QFMiiT1PO/32fOQPgJbZhX2siAQan3xajcC5g0sDZtoM
3OrhDf9mk6WH/6QkKs235z3HqjWJGEsE5TLGeTHsFA4Je2z45Jn9tT7WJWmvMZiK
wiSHd1NxpIKc+PY7STlcvzZZKmEDg8wyXL+VFdGg5RF1SV9Dmp3PeDcQ8RqyrNLL
myWPC2ZGpWxueD12hQay8WJ8WOLWn/ei0NVmHXhkxZqG+X2s3Ya/cfp1CpIVigpJ
WcqlHtqPHvD4sISATY/qqT4ZPi4NY06fh0IxJ+qfXyn8pOJcpcwjiygS85iWRgEK
4rq/FNYymtpJdDJjpA0eL3DVfffYocCMKos6QIg7aIOvNY9QMzpakRe4BCRzXviA
4Vkp7Dze/fQjdDovnIec
=gbvT
-END PGP SIGNATURE-

__
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] [vmware][nova] Prevent HA configuration with different hostnames

[Gary Kotton]

On 2/11/15, 6:35 PM, "Sylvain Bauza"  wrote:

>
>Le 11/02/2015 17:04, Gary Kotton a écrit :
>> I posted a fix that does not break things and supports HA.
>> https://review.openstack.org/154029
>
>
>Just let's be clear, HA is *not* supported by Nova now.

That is not correct. It is actually support if the host_ip is the same. If
the host_ip is not the same then there is an issue when one of the compute
nodes restarts - it will delete all instances that do not have its host_ip.

>
>The main reason is that compute *nodes* are considered given by the
>hypervisor (ie. the virt driver ran by the compute manager worker), so
>if 2 or more hypervisors on two distinct machines are getting the same
>list of nodes, then you would have duplicates.

No. There are no duplicates.

>
>-Sylvain
>
>> On 2/11/15, 5:55 PM, "Matthew Booth"  wrote:
>>
>>> On 11/02/15 15:49, Gary Kotton wrote:
 Hi,
 I do not think that that is a healthy solution. That effectively would
 render a cluster down if the compute node goes down. That would be a
 real
 disaster. The ugly work around is setting the host names to be the
same
 value.
>>> I don't think that's an ugly work around. I think that's the only
>>> currently viable solution.
>>>
 This is something that we should discuss at the next summit and I
would
 hope to propose a topic to talk about.
>>> Sounds like a good plan. However, given that the bug is marked Critical
>>> I was assuming we wanted a more expedient fix, which is what I've
>>> proposed.
>>>
>>> Matt
>>>
 Thanks
 Gary

 On 2/11/15, 5:31 PM, "Matthew Booth"  wrote:

> I just posted this:
>
> https://review.openstack.org/#/c/154907/
>
> as an alternative fix for critical bug:
>
> https://bugs.launchpad.net/nova/+bug/1419785
>
> I've just knocked this up quickly for illustration: it obviously
>needs
> plenty of cleanup. I have confirmed that it works, though.
>
> Before I take it any further, though, I'd like to get some feedback
>on
> the approach. I prefer this to the alternative, because the
>underlying
> problem is deeper than supporting evacuate. I'd prefer to be honest
> with
> the user and just say it ain't gonna work. The alternative would
>leave
> Nova running in a broken state, leaving inconsistent state in its
>wake
> as it runs.
>
> Matt
>
> -- 
> Matthew Booth
> Red Hat Engineering, Virtualisation Team
>
> Phone: +442070094448 (UK)
> GPG ID:  D33C3490
> GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
>
>
> 
>__
>__
> __
> 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

>>>
>>> -- 
>>> Matthew Booth
>>> Red Hat Engineering, Virtualisation Team
>>>
>>> Phone: +442070094448 (UK)
>>> GPG ID:  D33C3490
>>> GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
>>>
>>> 
>>>
>>>__
>>> 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
>
>
>__
>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] Cross-Repo Dependencies in Zuul

[James E. Blair]

"Sullivan, Jon Paul"  writes:

>> A change may depend on more than one Gerrit change ID as well.  So it is
>> possible for a change in tempest to depend on a change in devstack and a
>> change in nova.  Simply add more "Depends-On:" lines to the footer.
>
> Have you considered a case where changes A and C are in nova, and
> change B is in neutron such that A depends on B depends on C?
>
> And does that create a similar, and uncaught, situation as per the
> Multi-way CRD, where two components will need to be updated
> simultaneously?

That depends.  From the info you provided, I see:

A(nova) -> B(neutron) -> C(nova) 

And there is no cycle, that just means that they are enqueued as C,B,A,
and the git checkouts for those tests will be:

C: nova branch tip+C
B: nova branch tip+C, neutron branch tip+B
A: nova branch tip+C+A, neutron branch tip+B

However, if A is a git parent of C, then there would be a cycle:

  A(nova) -> B(neutron) -> C(nova) -> A(nova)

So Zuul would stop processing that.

-Jim

__
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] Cross-Repo Dependencies in Zuul

[Amrith Kumar]

Thanks, most awesome. Alas, if this was around three weeks ago, I'd still have 
a full head of hair. Now all I have is a lifetime of savings on hairdressing.

-amrith

| -Original Message-
| From: James E. Blair [mailto:cor...@inaugust.com]
| Sent: Wednesday, February 11, 2015 11:33 AM
| To: OpenStack Development Mailing List (not for usage questions)
| Cc: openstack-in...@lists.openstack.org
| Subject: Re: [openstack-dev] Cross-Repo Dependencies in Zuul
| 
| Amrith Kumar  writes:
| 
| > This is awesome news!
| >
| > If I understand correctly, your description of "multiple changes"
| > describes cases where a single change depends on multiple changes. My
| > question is related to one-to-one dependencies in the form A -> B ->
| > C.
| >
| > I'm assuming that this is supported as well in the case where, for
| > example, A and C are in one repository and B is in another repository,
| > yes?
| 
| Yes and yes.  When writing the "multiple changes" section, I was
| describing how you can make A->B and A->C.  If you're curious, that gets
| serialized as B,C,A.
| 
| A->B->C works as well (and of course is serialized as C,B,A).  The
| enqueuing function is recursive, so, well, it works up to the Python stack
| limit.  :)
| 
| -Jim
| 
| __
| 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] [vmware][nova] Prevent HA configuration with different hostnames

[Sylvain Bauza]

Le 11/02/2015 17:04, Gary Kotton a écrit :

I posted a fix that does not break things and supports HA.
https://review.openstack.org/154029



Just let's be clear, HA is *not* supported by Nova now.

The main reason is that compute *nodes* are considered given by the 
hypervisor (ie. the virt driver ran by the compute manager worker), so 
if 2 or more hypervisors on two distinct machines are getting the same 
list of nodes, then you would have duplicates.


-Sylvain


On 2/11/15, 5:55 PM, "Matthew Booth"  wrote:


On 11/02/15 15:49, Gary Kotton wrote:

Hi,
I do not think that that is a healthy solution. That effectively would
render a cluster down if the compute node goes down. That would be a
real
disaster. The ugly work around is setting the host names to be the same
value.

I don't think that's an ugly work around. I think that's the only
currently viable solution.


This is something that we should discuss at the next summit and I would
hope to propose a topic to talk about.

Sounds like a good plan. However, given that the bug is marked Critical
I was assuming we wanted a more expedient fix, which is what I've
proposed.

Matt


Thanks
Gary

On 2/11/15, 5:31 PM, "Matthew Booth"  wrote:


I just posted this:

https://review.openstack.org/#/c/154907/

as an alternative fix for critical bug:

https://bugs.launchpad.net/nova/+bug/1419785

I've just knocked this up quickly for illustration: it obviously needs
plenty of cleanup. I have confirmed that it works, though.

Before I take it any further, though, I'd like to get some feedback on
the approach. I prefer this to the alternative, because the underlying
problem is deeper than supporting evacuate. I'd prefer to be honest
with
the user and just say it ain't gonna work. The alternative would leave
Nova running in a broken state, leaving inconsistent state in its wake
as it runs.

Matt

--
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490



__
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



--
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

__
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



__
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] [all][tc] Lets keep our community open, lets fight for it

[Donald Stufft]

> On Feb 11, 2015, at 11:15 AM, Jeremy Stanley  wrote:
> 
> On 2015-02-11 11:31:13 + (+), Kuvaja, Erno wrote:
> [...]
>> If you don't belong to the group of privileged living in the area
>> and receiving free ticket somehow or company paying your
>> participation you're not included. $600 + travel + accommodation
>> is quite hefty premium to be included, not really FOSS.
> [...]
> 
> Here I have to respectfully disagree. Anyone who uploads a change to
> an official OpenStack source code repository for review and has it
> approved/merged since Juno release day gets a 100% discount comp
> voucher for the full conference and design summit coming up in May.
> In addition, much like a lot of other large free software projects
> do for their conferences, the OpenStack Foundation sets aside
> funding[1] to cover travel and lodging for participants who need it.
> Let's (continue to) make sure this _is_ "really FOSS," and that any
> of our contributors who want to be involved can be involved.
> 
> [1] https://wiki.openstack.org/wiki/Travel_Support_Program

For whatever it's worth, I totally agree that the summits don't make Openstack
"not really FOSS" and I think the travel program is great, but I do just want
to point out (as someone for whom travel is not monetarily dificult, but
logistically) that decision making which requires travel can be exclusive. I
don't personally get too bothered by it but it feels like maybe the fundamental
issue that some are expericing is when there are decisions being made via a
single channel, regardless of if that channel is a phone call, IRC, a mailing
list, or a design summit. The more channels any particular decision involves
the more likely it is nobody is going to feel like they didn't get a chance
to participate.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


__
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] [devstack] Compute-node-only installation fails

[Clark Boylan]

On Wed, Feb 11, 2015, at 08:18 AM, Alexander Schmidt wrote:
> Hi Daniel,
> 
> with your recent change[1] to error handling in stack.sh, compute
> node only installations via devstack fail because there is
> no database selected. A database should not be required on
> compute nodes.
> 
> Was this done intentionally? lib/database explicitly says:
> 
> # If ``DATABASE_TYPE`` is unset here no database was selected
> # This is not an error as multi-node installs will do this on the
> compute nodes
> 
> [1] https://review.openstack.org/#/c/149288/
> 
> Regards,
> Alex
> 
> 
> __
> 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

We have been setting DATABASE_TYPE [0] so did not notice. Seems like a
reasonable work around for now and does not install a database server
(the enabled services list seems to do that). If the intended behavior
is to not need to set DATABASE_TYPE we should probably revert the
devstack change then update devstack-gate's compute node localrc
generation to remove DATABASE_TYPE so that breakage of the behavior has
a chance of being caught early.

[0]
http://logs.openstack.org/79/136179/5/experimental/check-tempest-dsvm-aiopcpu/6f5193e/logs/10.209.161.148-subnode/localrc.txt.gz

Clark

__
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] [devstack] Compute-node-only installation fails

[Daniel P. Berrange]

On Wed, Feb 11, 2015 at 05:18:35PM +0100, Alexander Schmidt wrote:
> Hi Daniel,
> 
> with your recent change[1] to error handling in stack.sh, compute
> node only installations via devstack fail because there is
> no database selected. A database should not be required on
> compute nodes.
> 
> Was this done intentionally? lib/database explicitly says:
> 
> # If ``DATABASE_TYPE`` is unset here no database was selected
> # This is not an error as multi-node installs will do this on the
> compute nodes
> 
> [1] https://review.openstack.org/#/c/149288/

No, obviously that side effect was definitely not intentional. I had a
setup where I needed a database but had forgotten to enable one, and
was just trying to get devstack to detect this upfront. I didn'tmean
to break the valid use case of not having a database at all in the
scenario you mention.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] Cross-Repo Dependencies in Zuul

[James E. Blair]

Amrith Kumar  writes:

> This is awesome news!
>
> If I understand correctly, your description of "multiple changes"
> describes cases where a single change depends on multiple changes. My
> question is related to one-to-one dependencies in the form A -> B ->
> C.
>
> I'm assuming that this is supported as well in the case where, for
> example, A and C are in one repository and B is in another repository,
> yes?

Yes and yes.  When writing the "multiple changes" section, I was
describing how you can make A->B and A->C.  If you're curious, that gets
serialized as B,C,A.

A->B->C works as well (and of course is serialized as C,B,A).  The
enqueuing function is recursive, so, well, it works up to the Python
stack limit.  :)

-Jim

__
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] [all][tc] Lets keep our community open, lets fight for it

[Doug Hellmann]

On Wed, Feb 11, 2015, at 11:15 AM, Jeremy Stanley wrote:
> On 2015-02-11 11:31:13 + (+), Kuvaja, Erno wrote:
> [...]
> > If you don't belong to the group of privileged living in the area
> > and receiving free ticket somehow or company paying your
> > participation you're not included. $600 + travel + accommodation
> > is quite hefty premium to be included, not really FOSS.
> [...]
> 
> Here I have to respectfully disagree. Anyone who uploads a change to
> an official OpenStack source code repository for review and has it
> approved/merged since Juno release day gets a 100% discount comp
> voucher for the full conference and design summit coming up in May.
> In addition, much like a lot of other large free software projects
> do for their conferences, the OpenStack Foundation sets aside
> funding[1] to cover travel and lodging for participants who need it.
> Let's (continue to) make sure this _is_ "really FOSS," and that any
> of our contributors who want to be involved can be involved.
> 
> [1] https://wiki.openstack.org/wiki/Travel_Support_Program

Good reminder, Jeremy.

The travel program is in place to help contributors who wouldn't
otherwise be able to attend. Thanks to the commitment of generous
corporate sponsors, we've had success bringing a range of participants
to the past several summits -- not all of them developers. Everyone who
would like to attend the summit but won't have other sponsorship should
go to the wiki page to submit an application for the Vancouver summit.

Doug

> -- 
> Jeremy Stanley
> 
> __
> 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

[openstack-dev] [devstack] Compute-node-only installation fails

[Alexander Schmidt]

Hi Daniel,

with your recent change[1] to error handling in stack.sh, compute
node only installations via devstack fail because there is
no database selected. A database should not be required on
compute nodes.

Was this done intentionally? lib/database explicitly says:

# If ``DATABASE_TYPE`` is unset here no database was selected
# This is not an error as multi-node installs will do this on the
compute nodes

[1] https://review.openstack.org/#/c/149288/

Regards,
Alex


__
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] [all][tc] Lets keep our community open, lets fight for it

[Doug Hellmann]

On Wed, Feb 11, 2015, at 09:32 AM, Sean Dague wrote:
> On 02/11/2015 09:02 AM, Daniel P. Berrange wrote:
> > On Wed, Feb 11, 2015 at 08:13:05AM -0500, Sean Dague wrote:
> >> On 02/11/2015 05:52 AM, Daniel P. Berrange wrote:
>  ## Mailing List vs IRC Channel
> 
>  I get it, our mailing list is freaking busy, keeping up with it is
>  hard and time consuming and that leads to lots of IRC discussions. I
>  don't think there's anything wrong with that but I believe it's wrong
>  to expect *EVERYONE* to be in the IRC channel when those discussions
>  happen.
> >>>
> >>> Again, timezones. It is a physical impossibility for most people to
> >>> be on IRC for more than 8 hours a day, so that's only 1/3 of the day
> >>> that any signle person will likely be on IRC.  And no, expecting
> >>> people to have a permanently connected IRC proxy and then read the
> >>> other 16 hours of logs each morning is not a solution.
> >>>
> >>> Personally I've stopped joining IRC most the time regardless, because
> >>> I feel I am far more productive when I'm not being interrupted with
> >>> IRC pings every 20 minutes. There should be few things so urgent that
> >>> they can't be dealt with over email. Again because of our timezone
> >>> differences we should be wary of making important decisions in a
> >>> rush - anything remotely non-trivial should have at least a 24 hour
> >>> window to allow people on all timezones a chance to see the point
> >>> and join in discussion.
> >>
> >> IRC is mostly not about discussions, it's about discussion, context,
> >> team building, and trust. And it's a cross organization open forum for 
> >> that.
> >>
> >> If core team members start dropping off external IRC where they are
> >> communicating across corporate boundaries, then the local tribal effects
> >> start taking over. You get people start talking about the upstream as
> >> "them". The moment we get into us vs. them, we've got a problem.
> >> Especially when the upstream project is "them".
> > 
> > It is perfectly possible to communicate effectively over email. Pretty
> > much every single other open source project I've ever contributed to
> > works almost exclusively over email without their being corporate "tribal
> > effects". OpenStack is really the exception here with its obsession on
> > using IRC for so much communication.
> 
> My experiences have been different. While a lot of projects mirrored the
> kernel process which was all mailing list, most of the projects I've
> worked on that haven't been written in C are far more IRC driven.
> 
> Every time I've had to address an issue with a non OpenStack python
> dependency, it's been IRC to get things done, not a mailing list. Most
> of these projects don't have mailing lists. A lot of people come to
> OpenStack from those sorts of project cultures. So I don't think
> OpenStack is an exception in Open Source.
> 
> It was the community norm when I showed up, so it's the norm that I take
> forward.
> 
> The alternative when I got started wasn't even that discussions were
> happening in open IRC, it was that they were happening via completely
> private back channels, often in physical hallways of individual
> companies. IRC was a ton more open than that for sure. And it was a
> transition that people used to physical conversations could make easier
> than moving to email.
> 
> >> So while I agree, I'd personally get a ton more done if I didn't make
> >> myself available to answer questions or help sort out misunderstandings
> >> people were having with things I'm an expert in, doing so would
> >> definitely detrimentally impact the project as a whole. So I find it an
> >> unfortunate decision for a core team member.
> > 
> > It is up to each individual to decide how they can maximise their
> > contribution to the project. I'm still more than happy to answer
> > questions in reviews, or via email, and will join IRC meetings where
> > there is an important topic that directly needs my input. I simply
> > feel that I can maximise the value of my contribution to the project
> > without being on IRC getting direct pings all the time, when the
> > overwhealming majority of those pings can be easily dealt with via
> > email or gerrit.
> 
> Definitely true, to each his/her own. I still consider it unfortunate.
> I've also heard core developers state that they stopped reading the
> mailing list months ago. Which I also find unfortunate.

Unfortunate is putting it mildly.

The #1 issue we have in this project is communicating with each other
about changes that will affect the way the whole project works. We've
put new processes in place over the last year for formalizing reviews of
designs, but that's only one tool among many that we use. The mailing
list is important specifically because it's less rigidly structured, so
conversations can happen more freely. We're too big of a group for any
individual to expect us to seek them out to make sure their voice is
heard. It

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

[Jeremy Stanley]

On 2015-02-11 11:31:13 + (+), Kuvaja, Erno wrote:
[...]
> If you don't belong to the group of privileged living in the area
> and receiving free ticket somehow or company paying your
> participation you're not included. $600 + travel + accommodation
> is quite hefty premium to be included, not really FOSS.
[...]

Here I have to respectfully disagree. Anyone who uploads a change to
an official OpenStack source code repository for review and has it
approved/merged since Juno release day gets a 100% discount comp
voucher for the full conference and design summit coming up in May.
In addition, much like a lot of other large free software projects
do for their conferences, the OpenStack Foundation sets aside
funding[1] to cover travel and lodging for participants who need it.
Let's (continue to) make sure this _is_ "really FOSS," and that any
of our contributors who want to be involved can be involved.

[1] https://wiki.openstack.org/wiki/Travel_Support_Program
-- 
Jeremy Stanley

__
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] [all][tc] Lets keep our community open, lets fight for it

[Stefano Maffulli]

On Wed, 2015-02-11 at 09:32 -0500, Sean Dague wrote:
> Definitely true, to each his/her own. I still consider it unfortunate.
> I've also heard core developers state that they stopped reading the
> mailing list months ago. Which I also find unfortunate.

That's terrible: do you know why they don't read the list anymore? If
you don't know why, could you ask them or (better yet) put me in touch
with them so I can work out a solution for them?

thanks,
stef


__
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] [all][tc] Lets keep our community open, lets fight for it

[Doug Hellmann]

On Wed, Feb 11, 2015, at 09:14 AM, Stefano Maffulli wrote:
> On Wed, 2015-02-11 at 10:55 +0100, Flavio Percoco wrote:
> > This email is dedicated to the openness of our community/project.
> 
> It's good to have a reminder every now and then. Thank you Flavio for
> caring enough to notice bad patterns and for raising a flag. 
> 
> > ## Keep discussions open
> > 
> > I don't believe there's anything wrong about kicking off some
> > discussions in private channels about specs/bugs. I don't believe
> > there's anything wrong in having calls to speed up some discussions.
> > HOWEVER, I believe it's *completely* wrong to consider those private
> > discussions sufficient. 
> [...]
> 
> Well said. Conversations can happen anywhere and any time, but they
> should stay in open and accessible channels. Consensus needs to be built
> and decisions need to be shared, agreed upon by the community at large
> (and mailing lists are the most accessible media we have). 
> 
> That said, it's is very hard to generalize and I'd rather deal/solve
> specific examples. Sometimes, I'm sure there are episodes when a fast
> decision was needed and a limited amount of people had to carry the
> burden of responsibility. Life is hard, software development is hard and
> general rules sometimes need to be adapted to the reality. Again, too
> much generalization here for what I'm confortable with.
> 
> Maybe it's worth repeating that I'm personally (and in my role)
> available to listen and mediate in cases when communication seems to
> happen behind closed doors. If you think something unhealthy is
> happening, talk to me (confidentiality assured).
> 
> > ## Mailing List vs IRC Channel
> > 
> > I get it, our mailing list is freaking busy, keeping up with it is
> > hard and time consuming and that leads to lots of IRC discussions.
> 
> Not sure I agree with the causality but, the facts are those: traffic on
> the list and on IRC is very high (although not increasing anymore
> [1][2]).
> 
> >  I
> > don't think there's anything wrong with that but I believe it's wrong
> > to expect *EVERYONE* to be in the IRC channel when those discussions
> > happen.
> 
> Email is hard, I have the feeling that the vast majority of people use
> bad (they all suck, no joke) email clients. Lots and lots of email is
> even worse. Most contributors commit very few patches: the investment
> for them to configure their MUA to filter our traffic is too high.
> 
> I have added more topics today to the openstack-dev list[3]. Maybe,
> besides filtering on the receiving end, we may spend some time
> explaining how to use mailman topics? I'll draft something on Ask, it
> may help those that have limited interest in OpenStack.
> 
> What else can we do to make things better?
> 
> > ## Cores are *NOT* special
> > 
> > At some point, for some reason that is unknown to me, this message
> > changed and the feeling of core's being some kind of superheros became
> > a thing. It's gotten far enough to the point that I've came to know
> > that some projects even have private (flagged with +s), password
> > protected, irc channels for core reviewers.
> 
> This is seriously disturbing.
> 
> If you're one of those core reviewers hanging out on a private channel,
> please contact me privately: I'd love to hear from you why we failed as
> a community at convincing you that an open channel is the place to be.
> 
> No public shaming, please: education first.

Thanks for stepping in, Stef.

I want to also back what Sean said elsewhere in the thread, though. This
appears to be a serious breach of the openness policies of the project.
I hope the team in question resolves the situation themselves, and
quickly.

Doug

> 
> Cheers,
> stef
> 
> 
> [1] http://activity.openstack.org/dash/browser/mls.html
> [2] http://activity.openstack.org/dash/browser/irc.html
> [3] thanks to Luigi Toscano for highlighting some missing ones
> 
> 
> __
> 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] [vmware][nova] Prevent HA configuration with different hostnames

[Gary Kotton]

I posted a fix that does not break things and supports HA.
https://review.openstack.org/154029

On 2/11/15, 5:55 PM, "Matthew Booth"  wrote:

>On 11/02/15 15:49, Gary Kotton wrote:
>> Hi,
>> I do not think that that is a healthy solution. That effectively would
>> render a cluster down if the compute node goes down. That would be a
>>real
>> disaster. The ugly work around is setting the host names to be the same
>> value.
>
>I don't think that's an ugly work around. I think that's the only
>currently viable solution.
>
>> This is something that we should discuss at the next summit and I would
>> hope to propose a topic to talk about.
>
>Sounds like a good plan. However, given that the bug is marked Critical
>I was assuming we wanted a more expedient fix, which is what I've
>proposed.
>
>Matt
>
>> Thanks
>> Gary
>> 
>> On 2/11/15, 5:31 PM, "Matthew Booth"  wrote:
>> 
>>> I just posted this:
>>>
>>> https://review.openstack.org/#/c/154907/
>>>
>>> as an alternative fix for critical bug:
>>>
>>> https://bugs.launchpad.net/nova/+bug/1419785
>>>
>>> I've just knocked this up quickly for illustration: it obviously needs
>>> plenty of cleanup. I have confirmed that it works, though.
>>>
>>> Before I take it any further, though, I'd like to get some feedback on
>>> the approach. I prefer this to the alternative, because the underlying
>>> problem is deeper than supporting evacuate. I'd prefer to be honest
>>>with
>>> the user and just say it ain't gonna work. The alternative would leave
>>> Nova running in a broken state, leaving inconsistent state in its wake
>>> as it runs.
>>>
>>> Matt
>>>
>>> -- 
>>> Matthew Booth
>>> Red Hat Engineering, Virtualisation Team
>>>
>>> Phone: +442070094448 (UK)
>>> GPG ID:  D33C3490
>>> GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
>>>
>>> 
>>>
>>>__
>>> 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
>> 
>
>
>-- 
>Matthew Booth
>Red Hat Engineering, Virtualisation Team
>
>Phone: +442070094448 (UK)
>GPG ID:  D33C3490
>GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
>
>__
>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] Cross-Repo Dependencies in Zuul

[Amrith Kumar]

This is awesome news!

If I understand correctly, your description of "multiple changes" describes 
cases where a single change depends on multiple changes. My question is related 
to one-to-one dependencies in the form A -> B -> C.

I'm assuming that this is supported as well in the case where, for example, A 
and C are in one repository and B is in another repository, yes?

Thanks,

-amrith

| -Original Message-
| From: James E. Blair [mailto:cor...@inaugust.com]
| Sent: Tuesday, February 10, 2015 5:26 PM
| To: OpenStack Development Mailing List
| Cc: openstack-in...@lists.openstack.org
| Subject: [openstack-dev] Cross-Repo Dependencies in Zuul
| 
| Hi,
| 
| We have added support for cross-repo dependencies (CRD) in Zuul.  The
| important bits:
| 
| * To use them, include "Depends-On: " in the footer of
|   your commit message.  Use the full Change-ID ('I' + 40 characters).
| 
| * These are one-way dependencies only -- do not create a cycle.
| 
| * This is what all the grey dots and lines are in the check pipeline.
| 
| Cross-Repo Dependencies Explained
| =
| 
| There are two behaviors that might go by the name "cross-repo
| dependencies".  We call them one-way and multi-way.
| 
| Multi-way CRD allow for bidirectional links between changes.  For
| instance, A depends on B and B depends on A.  The theory there is that
| both would be tested together and merged as a unit.  This is _not_ what we
| have implemented in Zuul.  Discussions over the past two years have
| revealed that this type of behavior could cause problems for continuous
| deploments as it means that two components must be upgraded
| simultaneously.  Not supporting this behavior is a choice we have made.
| 
| One-way CRD behaves like a directed acyclic graph (DAG), like git itself,
| to indicate a one-way dependency relationship between changes in different
| git repos.  Change A may depend on B, but B may not depend on A.  This is
| what we have implemented in Zuul.
| 
| Gate Pipeline
| =
| 
| When Zuul sees CRD changes, it serializes them in the usual manner when
| enqueuing them into a pipeline.  This means that if change A depends on B,
| then when they are added to the gate pipeline, B will appear first and A
| will follow.  If tests for B fail, both B and A will be removed from the
| pipeline, and it will not be possible for A to merge until B does.
| 
| Note that if changes with CRD do not share a change queue (such as the
| "integrated gate" then Zuul is unable to enqueue them together, and the
| first will be required to merge before the second is enqueued.
| 
| Check Pipeline
| ==
| 
| When changes are enqueued into the check pipeline, all of the related
| dependencies (both normal git-dependencies that come from parent commits
| as well as CRD changes) appear in a dependency graph, as in gate.  This
| means that even in the check pipeline, your change will be tested with its
| dependency.  So changes that were previously unable to be fully tested
| until a related change landed in a different repo may now be tested
| together from the start.
| 
| All of the changes are still independent (so you will note that the whole
| pipeline does not share a graph as in gate), but for each change tested,
| all of its dependencies are visually connected to it, and they are used to
| construct the git references that Zuul uses when testing.
| When looking at this graph on the status page, you will note that the
| dependencies show up as grey dots, while the actual change tested shows up
| as red or green.  This is to indicate that the grey changes are only there
| to establish dependencies.  Even if one of the dependencies is also being
| tested, it will show up as a grey dot when used as a dependency, but
| separately and additionally will appear as its own red or green dot for
| its test.
| 
| (If you don't see grey dots on the status page, reload the page to get the
| latest version.)
| 
| Multiple Changes
| 
| 
| A Gerrit change ID may refer to multiple changes (on multiple branches of
| the same project, or even multiple projects).  In these cases, Zuul will
| treat all of the changes with that change ID as dependencies.  So if you
| say that a tempest change Depends-On a change ID that has changes in nova
| master and nova stable/juno, then when testing the tempest change, both
| nova changes will be applied, and when deciding whether the tempest change
| can merge, both changes must merge ahead of it.
| 
| A change may depend on more than one Gerrit change ID as well.  So it is
| possible for a change in tempest to depend on a change in devstack and a
| change in nova.  Simply add more "Depends-On:" lines to the footer.
| 
| Cycles
| ==
| 
| If a cycle is created by use of CRD, Zuul will abort its work very early.
| There will be no message in Gerrit and no changes that are part of the
| cycle will be enqueued into any pipeline.  This is to protect Zuul f

Re: [openstack-dev] [vmware][nova] Prevent HA configuration with different hostnames

[Matthew Booth]

On 11/02/15 15:49, Gary Kotton wrote:
> Hi,
> I do not think that that is a healthy solution. That effectively would
> render a cluster down if the compute node goes down. That would be a real
> disaster. The ugly work around is setting the host names to be the same
> value.

I don't think that's an ugly work around. I think that's the only
currently viable solution.

> This is something that we should discuss at the next summit and I would
> hope to propose a topic to talk about.

Sounds like a good plan. However, given that the bug is marked Critical
I was assuming we wanted a more expedient fix, which is what I've proposed.

Matt

> Thanks
> Gary
> 
> On 2/11/15, 5:31 PM, "Matthew Booth"  wrote:
> 
>> I just posted this:
>>
>> https://review.openstack.org/#/c/154907/
>>
>> as an alternative fix for critical bug:
>>
>> https://bugs.launchpad.net/nova/+bug/1419785
>>
>> I've just knocked this up quickly for illustration: it obviously needs
>> plenty of cleanup. I have confirmed that it works, though.
>>
>> Before I take it any further, though, I'd like to get some feedback on
>> the approach. I prefer this to the alternative, because the underlying
>> problem is deeper than supporting evacuate. I'd prefer to be honest with
>> the user and just say it ain't gonna work. The alternative would leave
>> Nova running in a broken state, leaving inconsistent state in its wake
>> as it runs.
>>
>> Matt
>>
>> -- 
>> Matthew Booth
>> Red Hat Engineering, Virtualisation Team
>>
>> Phone: +442070094448 (UK)
>> GPG ID:  D33C3490
>> GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
>>
>> __
>> 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
> 


-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

__
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] [keystone] [nova]

[Nikolay Makhotkin]

Hi !

I investigated trust's use cases and encountered the problem: When I use
auth_token obtained from keystoneclient using trust, I get *403* Forbidden
error:  *You are not authorized to perform the requested action.*

Steps to reproduce:

- Import v3 keystoneclient (used keystone and keystoneclient from master,
tried also to use stable/icehouse)
- Import v3 novaclient
- initialize the keystoneclient:
  keystone = keystoneclient.Client(username=username, password=password,
tenant_name=tenant_name, auth_url=auth_url)

- create a trust:
  trust = keystone.trusts.create(
keystone.user_id,
keystone.user_id,
impersonation=True,
role_names=['admin'],
project=keystone.project_id
  )

- initialize new keystoneclient:
  client_from_trust = keystoneclient.Client(
username=username, password=password,
trust_id=trust.id, auth_url=auth_url,
  )

- create nova client using new token from new client:
  nova = novaclient.Client(
auth_token=client_from_trust.auth_token,
auth_url=auth_url_v2,
project_id=from_trust.project_id,
service_type='compute',
username=None,
api_key=None
  )

- do simple request to nova:
  nova.servers.list()

- get the error described above.


Maybe I misunderstood something but what is wrong? I supposed I just can
work with nova like it was initialized using direct token.

-- 
Best Regards,
Nikolay
__
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] [all][PTLs] Stop releasing libraries/clients without capping stable global requirements

[Doug Hellmann]

On Tue, Feb 10, 2015, at 07:12 PM, Joe Gordon wrote:
> Hi,
> 
> As you know a few of us have been spending way too much time digging
> stable/juno out of the ditch its currently in. And just when we thought
> we
> were in the clear a new library was released without a requirements cap
> in
> stable global-requirements and broke stable/juno grenade.  Everytime this
> happens we risk breaking everything. While there is a good long term fix
> in
> progress (pin all of stable/juno
> https://review.openstack.org/#/c/147451/),
> this will take a bit of time to get right and land.
> 
> The  good news is there is a nice easy interim solution. Before releasing
> a
> new library go to stable/juno and stable/icehouse global requirements and
> check if $library has a version cap, if not add one. And once that lands
> go
> ahead and release your library. For example:
> https://review.openstack.org/#/c/154715/2
> __
> 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

The Oslo team has several libraries we're holding for release until this
is resolved. We do have projects blocked on those releases, though, so
if Joe asks you for help with anything related to stable branch
maintenance, please make it a priority so we can get the caps in place.

Doug

__
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] [vmware][nova] Prevent HA configuration with different hostnames

[Gary Kotton]

Hi,
I do not think that that is a healthy solution. That effectively would
render a cluster down if the compute node goes down. That would be a real
disaster. The ugly work around is setting the host names to be the same
value.
This is something that we should discuss at the next summit and I would
hope to propose a topic to talk about.
Thanks
Gary

On 2/11/15, 5:31 PM, "Matthew Booth"  wrote:

>I just posted this:
>
>https://review.openstack.org/#/c/154907/
>
>as an alternative fix for critical bug:
>
>https://bugs.launchpad.net/nova/+bug/1419785
>
>I've just knocked this up quickly for illustration: it obviously needs
>plenty of cleanup. I have confirmed that it works, though.
>
>Before I take it any further, though, I'd like to get some feedback on
>the approach. I prefer this to the alternative, because the underlying
>problem is deeper than supporting evacuate. I'd prefer to be honest with
>the user and just say it ain't gonna work. The alternative would leave
>Nova running in a broken state, leaving inconsistent state in its wake
>as it runs.
>
>Matt
>
>-- 
>Matthew Booth
>Red Hat Engineering, Virtualisation Team
>
>Phone: +442070094448 (UK)
>GPG ID:  D33C3490
>GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
>
>__
>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

[openstack-dev] [vmware][nova] Prevent HA configuration with different hostnames

[Matthew Booth]

I just posted this:

https://review.openstack.org/#/c/154907/

as an alternative fix for critical bug:

https://bugs.launchpad.net/nova/+bug/1419785

I've just knocked this up quickly for illustration: it obviously needs
plenty of cleanup. I have confirmed that it works, though.

Before I take it any further, though, I'd like to get some feedback on
the approach. I prefer this to the alternative, because the underlying
problem is deeper than supporting evacuate. I'd prefer to be honest with
the user and just say it ain't gonna work. The alternative would leave
Nova running in a broken state, leaving inconsistent state in its wake
as it runs.

Matt

-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

__
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] [api] Optional Properties in an Entity

[Brian Rosmaita]

On 2/9/15, 8:44 PM, "Joe Gordon" 
mailto:joe.gord...@gmail.com>> wrote:

On Mon, Feb 9, 2015 at 1:22 PM, Jay Pipes 
mailto:jaypi...@gmail.com>> wrote:
On 01/20/2015 10:54 AM, Brian Rosmaita wrote:
From: Kevin L. Mitchell 
[kevin.mitch...@rackspace.com]
Sent: Monday, January 19, 2015 4:54 PM

When we look at consistency, we look at everything else in OpenStack.
 From the standpoint of the nova API (with which I am the most familiar),
I am not aware of any property that is ever omitted from any payload
without versioning coming in to the picture, even if its value is null.
Thus, I would argue that we should encourage the first situation, where
all properties are included, even if their value is null.

That is not the case for the Images API v2:

"An image is always guaranteed to have the following attributes: id,
status, visibility, protected, tags, created_at, file and self. The other
attributes defined in the image schema below are guaranteed to
be defined, but is only returned with an image entity if they have
been explicitly set." [1]

This was a mistake, IMHO. Having entirely extensible schemas means that there 
is little guaranteed consistency across implementations of the API.

+1, Subtle hard to discover differences between clouds is a pain for 
interchangeability.

Jay and Joe, thanks for weighing in.  I’m still not convinced that the course 
taken in the Images v2 API was a mistake, though.  (I wasn’t involved in its 
initial design, so this isn’t personal, just curiosity.)  Here are a few 
reasons why, maybe someone can set me straight?

(1) Leaving null elements out is parsimonious.
As long as there’s a JSON schema, the client has a good idea what to expect.  
If you include
  “whatever”: null
in the response, I don’t see what that buys you.  If you simply don’t include 
the “whatever” element, the recipient knows it’s not set.  If you do include it 
set to null, you know that it’s not set … and you increased the size of the 
response payload without increasing its informativeness.  Further, even if you 
include the “whatever” element set to null, the client is still going to have 
to check it to handle the null case, so it’s really just a matter of how the 
client checks, not whether it has to check.

(2) Leaving null elements out doesn’t affect interchangeability.
If our convention is that unset elements aren’t included, and we’ve got a JSON 
schema, then everyone knows what’s up.  Further, looking specifically at the 
use cases for images in Glance, different clouds have different sets of image 
properties that they use for specific purposes that may be unique to their 
cloud.  For example, some may put a hyperlink to licensing info in an image 
property, or versioning info, or package lists, or whatever you can fit in 255 
chars.  So a client (intelligent or not) connecting to various clouds can’t 
expect to find the same set of properties defined in every cloud (except for 
the ones guaranteed by contract, which are listed above).  Thus, you’re going 
to have to deal with the problem of non-existent elements when you get to the 
additionalProperties in JSON no matter what.  But as long as you know this, 
you’re OK.  I think it’s a much bigger problem when you’ve got a mixture of 
null, “”, {} and other ways of conveying empty elements in a response.  By 
simply leaving properties out, there’s no question that they’re not set.

(3) A little consistency is a good thing.
Jay mentions that having entirely extensible schemas means that there’s little 
guaranteed consistency across implementations of the API.  In the Images API v2 
case, the schema isn’t entirely extensible, you can add string-valued 
additionalProperties.  So there’s that.  But the bigger picture is that we’re 
in at the infancy of clouds and cloud management, there’s no way we can 
anticipate the set of Image properties that will be sufficient for all 
deployers.  So as long as the consistency guarantees are met for the small set 
of properties they’re guaranteed for, I don’t have a problem with the majority 
of image properties being variable … as long as we know what type each is, 
which we do, they’re all strings.


cheers,
brian

__
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] Cross-Repo Dependencies in Zuul

[Sullivan, Jon Paul]

Firstly, this is a great feature - thanks for getting it implemented!

> -Original Message-
> From: James E. Blair [mailto:cor...@inaugust.com]
> Sent: 10 February 2015 22:26
> To: OpenStack Development Mailing List
> Cc: openstack-in...@lists.openstack.org
> Subject: [openstack-dev] Cross-Repo Dependencies in Zuul
> 
:
snip
:
> 
> Cross-Repo Dependencies Explained
> =
> 
> There are two behaviors that might go by the name "cross-repo
> dependencies".  We call them one-way and multi-way.
> 
> Multi-way CRD allow for bidirectional links between changes.  For
> instance, A depends on B and B depends on A.  The theory there is that
> both would be tested together and merged as a unit.  This is _not_ what
> we have implemented in Zuul.  Discussions over the past two years have
> revealed that this type of behavior could cause problems for continuous
> deploments as it means that two components must be upgraded
> simultaneously.  Not supporting this behavior is a choice we have made.
> 
> One-way CRD behaves like a directed acyclic graph (DAG), like git
> itself, to indicate a one-way dependency relationship between changes in
> different git repos.  Change A may depend on B, but B may not depend on
> A.  This is what we have implemented in Zuul.
> 
:
snip
:
> 
> Multiple Changes
> 
> 
:
snip
:
> 
> A change may depend on more than one Gerrit change ID as well.  So it is
> possible for a change in tempest to depend on a change in devstack and a
> change in nova.  Simply add more "Depends-On:" lines to the footer.

Have you considered a case where changes A and C are in nova, and change B is 
in neutron such that A depends on B depends on C?

And does that create a similar, and uncaught, situation as per the Multi-way 
CRD, where two components will need to be updated simultaneously?

:
snip
:
> 
> -Jim
> 
> 
> __
> 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, 
Jon-Paul Sullivan ☺ Cloud Services - @hpcloud

Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park, Galway.
Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John Rogerson's 
Quay, Dublin 2. 
Registered Number: 361933
 
The contents of this message and any attachments to it are confidential and may 
be legally privileged. If you have received this message in error you should 
delete it from your system immediately and advise the sender.

To any recipient of this message within HP, unless otherwise stated, you should 
consider this message and attachments as "HP CONFIDENTIAL".
__
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 about the plan of L

[Duncan Thomas]

Currently for updates to existing drivers, there isn't currently a fixed
date for updates, however you should aim to have any changes up as early as
possible. Keep an eye on the mailing list for more announcements as plans
become more firm.

On 11 February 2015 at 12:21, liuxinguo  wrote:

>  Our driver have been merged into Kilo before K-1 and have implemented
> many features, so I think our driver is not a new driver.
>
> For these drivers aleady merged in Kilo and if they want add some new
> features, does they should be merged before L-1 too?
>
>
>
> Thanks,
>
> Liu
>
>
>
> Yes, assume NEW drivers have to land in before the L-1 milestone.  This
>
> also includes getting a CI system up and running.
>
>
>
> Walt
>
> >
>
> > Hi,
>
> >
>
> > In Kilo the cinder driver is requested to be merged before K-1, I want
>
> > to ask that in L does the driver will be requested to be merged before
>
> > L-1?
>
> >
>
> > Thanks and regards,
>
> >
>
> > Liu
>
>
>
> __
> 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] [all][tc] Lets keep our community open, lets fight for it

[Sean Dague]

On 02/11/2015 09:02 AM, Daniel P. Berrange wrote:
> On Wed, Feb 11, 2015 at 08:13:05AM -0500, Sean Dague wrote:
>> On 02/11/2015 05:52 AM, Daniel P. Berrange wrote:
 ## Mailing List vs IRC Channel

 I get it, our mailing list is freaking busy, keeping up with it is
 hard and time consuming and that leads to lots of IRC discussions. I
 don't think there's anything wrong with that but I believe it's wrong
 to expect *EVERYONE* to be in the IRC channel when those discussions
 happen.
>>>
>>> Again, timezones. It is a physical impossibility for most people to
>>> be on IRC for more than 8 hours a day, so that's only 1/3 of the day
>>> that any signle person will likely be on IRC.  And no, expecting
>>> people to have a permanently connected IRC proxy and then read the
>>> other 16 hours of logs each morning is not a solution.
>>>
>>> Personally I've stopped joining IRC most the time regardless, because
>>> I feel I am far more productive when I'm not being interrupted with
>>> IRC pings every 20 minutes. There should be few things so urgent that
>>> they can't be dealt with over email. Again because of our timezone
>>> differences we should be wary of making important decisions in a
>>> rush - anything remotely non-trivial should have at least a 24 hour
>>> window to allow people on all timezones a chance to see the point
>>> and join in discussion.
>>
>> IRC is mostly not about discussions, it's about discussion, context,
>> team building, and trust. And it's a cross organization open forum for that.
>>
>> If core team members start dropping off external IRC where they are
>> communicating across corporate boundaries, then the local tribal effects
>> start taking over. You get people start talking about the upstream as
>> "them". The moment we get into us vs. them, we've got a problem.
>> Especially when the upstream project is "them".
> 
> It is perfectly possible to communicate effectively over email. Pretty
> much every single other open source project I've ever contributed to
> works almost exclusively over email without their being corporate "tribal
> effects". OpenStack is really the exception here with its obsession on
> using IRC for so much communication.

My experiences have been different. While a lot of projects mirrored the
kernel process which was all mailing list, most of the projects I've
worked on that haven't been written in C are far more IRC driven.

Every time I've had to address an issue with a non OpenStack python
dependency, it's been IRC to get things done, not a mailing list. Most
of these projects don't have mailing lists. A lot of people come to
OpenStack from those sorts of project cultures. So I don't think
OpenStack is an exception in Open Source.

It was the community norm when I showed up, so it's the norm that I take
forward.

The alternative when I got started wasn't even that discussions were
happening in open IRC, it was that they were happening via completely
private back channels, often in physical hallways of individual
companies. IRC was a ton more open than that for sure. And it was a
transition that people used to physical conversations could make easier
than moving to email.

>> So while I agree, I'd personally get a ton more done if I didn't make
>> myself available to answer questions or help sort out misunderstandings
>> people were having with things I'm an expert in, doing so would
>> definitely detrimentally impact the project as a whole. So I find it an
>> unfortunate decision for a core team member.
> 
> It is up to each individual to decide how they can maximise their
> contribution to the project. I'm still more than happy to answer
> questions in reviews, or via email, and will join IRC meetings where
> there is an important topic that directly needs my input. I simply
> feel that I can maximise the value of my contribution to the project
> without being on IRC getting direct pings all the time, when the
> overwhealming majority of those pings can be easily dealt with via
> email or gerrit.

Definitely true, to each his/her own. I still consider it unfortunate.
I've also heard core developers state that they stopped reading the
mailing list months ago. Which I also find unfortunate.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
__
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