Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin
On Wed, Mar 25, 2015 at 11:29 AM, Deepak Shetty dpkshe...@gmail.com wrote:
On Wed, Mar 25, 2015 at 12:58 AM, Ian Wienand iwien...@redhat.com wrote:
On 03/24/2015 03:17 PM, Deepak Shetty wrote:
For eg: Look at [1]
[1]
https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/settings
I would like ability to change these while I use the enable_plugin
apporach to setup devstack w/ GlusterFS per my local glusterfs setup
So I think the plugin should do
CINDER_ENABLED_BACKENDS=${CINDER_ENABLED_BACKENDS:-glusterfs:glusterfs,lvm:lvm1}
i.e. provide a default only if the variable is unset.
Bah! That was easy, i should have figured that myself :)
Thanks for catching that
This seems like one of those traps for new players and is one
concern I have with devstack plugins -- that authors keep having to
find out lessons learned independently. I have added a note on this
to the documentation in [1].
-i
[1] https://review.openstack.org/#/c/167375/
Great, i +1'ed it.
Also i posted patch to fix settings file @
https://review.openstack.org/167494
Ian,
Looks like usign bash default in settings file of plugin is not working,
in my patch it didn't use glusterfs driver, it used LVM (default)
I think whats happening here is that by the time settings file is sourced,
CINDER_ENABLED_BACKENDS is already set to lvm by lib/cinder
so settings file's default value is never taken
IIUC there are 3 scenarios (taking CINDER_ENABLED_BACKENDS as example var) :
1) localrc doesn't have CINDER_ENABLED_BACKENDS and enable_plugin
- Here we want the lib/cinder's default value to be taken
- this should work fine
2) localrc doesn't have CINDER_ENABLED_BACKENDS but has enable_plugin
glusterfs
- Here we want the plugin's default values to be taken, but its not as
lib/cinder already initialized CINDER_ENABLED_BACKENDS to use lvm backend
- Thus broken
3) localrc has both CINDER_ENABLED_BACKENDS and enable_plugin glusterfs
specified
- Here we want CINDER_ENABLED_BACKENDS present in my localrc to be
chosen
- This will work as by the time settings file is sourced
CINDER_ENABLED_BACKENDS is already initialised to my value in localrc
So #2 scenario would need some changes in stack.sh handling of plugin code ?
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] [devstack] Overriding settings file for devstack plugin
On Wed, Mar 25, 2015 at 12:58 AM, Ian Wienand iwien...@redhat.com wrote:
On 03/24/2015 03:17 PM, Deepak Shetty wrote:
For eg: Look at [1]
[1]
https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/settings
I would like ability to change these while I use the enable_plugin
apporach to setup devstack w/ GlusterFS per my local glusterfs setup
So I think the plugin should do
CINDER_ENABLED_BACKENDS=${CINDER_ENABLED_BACKENDS:-glusterfs:glusterfs,lvm:lvm1}
i.e. provide a default only if the variable is unset.
Bah! That was easy, i should have figured that myself :)
Thanks for catching that
This seems like one of those traps for new players and is one
concern I have with devstack plugins -- that authors keep having to
find out lessons learned independently. I have added a note on this
to the documentation in [1].
-i
[1] https://review.openstack.org/#/c/167375/
Great, i +1'ed it.
Also i posted patch to fix settings file @
https://review.openstack.org/167494
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
[openstack-dev] [depfreeze][horizon] Update to Django-1.7.x
Hello, I'm requesting an exception to bump Django to Django-1.7.x (or better). Rationale: Django-1.8 is expected to be released during the next days. Once it's released, Django-1.6.x will become unsupported by its upstream. Unfortunately that's the latest version we're gating against and that's the version frozen for kilo, or in other words: When Kilo is released, it relies on a version, not supported any more. Review is at https://review.openstack.org/#/c/155353/ -- Matthias Runge mru...@redhat.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] Cinder Third-Party CI: adding Mellanox CI to Wiki
On Wed, Mar 25, 2015 at 12:41 PM, Lenny Verkhovsky len...@mellanox.com wrote: Hi All, Please add Mellanox Cinder CI to this page https://wiki.openstack.org/wiki/Cinder/third-party-ci-status Lenny, You should be able to edit and add this yourself, once you login with your ID on that page thanx, deepak Driver name: iSER-LIO, iSER-ISCSI Contact: Lenny Verkhovsky cinder...@mellanox.com Status: voting and reporting Issues: none Reference https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_Cinder_CI Thanks. *Lenny Verkhovsky* SW Engineer, Mellanox Technologies www.mellanox.com Office:+972 74 712 9244 Mobile: +972 54 554 0233 Fax:+972 72 257 9400 __ 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 Third-Party CI: adding Mellanox CI to Wiki
Hi All, Please add Mellanox Cinder CI to this page https://wiki.openstack.org/wiki/Cinder/third-party-ci-status Driver name: iSER-LIO, iSER-ISCSI Contact: Lenny Verkhovsky cinder...@mellanox.com Status: voting and reporting Issues: none Reference https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_Cinder_CI Thanks. Lenny Verkhovsky SW Engineer, Mellanox Technologies www.mellanox.comhttp://www.mellanox.com Office:+972 74 712 9244 Mobile: +972 54 554 0233 Fax:+972 72 257 9400 __ 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] VLAN trunking network for NFV
Guo, AFAIU, the guest will tag frames with VLAN, then the host won't remove this tag ASA the underlying host uses an overlay encapsulation (VXLAN or GRE) to encapsulate the entire frame, including the VLAN submitted by the guest. This will be only compatible with LinuxBridge running on the host, since OVS overwrites VLAN tags with its own VLAN tags to isolate traffic of one network on a host. Linuxbridge isolate the traffic by dedicating a bridge per network. However I'm not sure that the compatibility matrix proposed in the spec is accurate since LB doesn't seem to support GRE encapsulation. The question raised in this thread is more about how the Linuxbridge implementation in Neutron can evolve. It is currently not tested by the CI, is it? Does it mean that evolution of this kind of implementation should be blocked? The next step of the spin out of drivers might move LB and OVS MD out of Neutron tree. Will there be any volunteer to support the LinuxBridge implementation? If not, does it mean that LB implementation will be deprecated? On Wed, Mar 25, 2015 at 1:48 AM, Guo, Ruijing ruijing@intel.com wrote: I am trying to understand how guest os use trunking network. If guest os use bridge like Linuxbride and OVS, how we launch it and how libvirt to support it? Thanks, -Ruijing *From:* Ian Wells [mailto:ijw.ubu...@cack.org.uk] *Sent:* Wednesday, March 25, 2015 2:18 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron] VLAN trunking network for NFV That spec ensures that you can tell what the plugin is doing. You can ask for a VLAN transparent network, but the cloud may tell you it can't make one. The OVS driver in Openstack drops VLAN tagged packets, I'm afraid, and the spec you're referring to doesn't change that. The spec does ensure that if you try and create a VLAN trunk on a cloud that uses the OVS driver, you'll be told you can't. in the future, the OVS driver can be fixed, but that's how things stand at present. Fixing the OVS driver really involves getting in at the OVS flow level - can be done, but we started with the basics. If you want to use a VLAN trunk using the current code, I recommend VXLAN or GRE along with the Linuxbridge driver, both of which support VLAN transparent networking. If they're configured and you ask for a VLAN trunk you'll be told you got one. -- Ian. On 24 March 2015 at 09:43, Daniele Casini daniele.cas...@dektech.com.au wrote: Hi all: in reference to the following specification about the creation of VLAN trunking network for NFV https://review.openstack.org/#/c/136554/3/specs/kilo/nfv-vlan-trunks.rst I would like to better understand how the tagged traffic will be realized. In order to explain myself, I report the following use case: A VNF is deployed in one VM, which has a trunk port carrying traffic for two VLANs over a single link able to transport more than one VLAN through a single integration-bridge (br-int) port. So, How does br-int manage the VLAN-ID? In other words, what are the action performed by the br-int when a VM forwards traffic to another host? Does it put an additional tag or replace the existing one keeping the match with a table or something like that? Thank you very much. Daniele __ 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] Cinder Third-Party CI: adding Mellanox CI to Wiki
Thanks, done, I thought it need’s community approval. Have a great day… Lenny Verkhovsky SW Engineer, Mellanox Technologies www.mellanox.comhttp://www.mellanox.com Office:+972 74 712 9244 Mobile: +972 54 554 0233 Fax:+972 72 257 9400 From: Deepak Shetty [mailto:dpkshe...@gmail.com] Sent: Wednesday, March 25, 2015 9:22 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Murad Awawdeh Subject: Re: [openstack-dev] Cinder Third-Party CI: adding Mellanox CI to Wiki On Wed, Mar 25, 2015 at 12:41 PM, Lenny Verkhovsky len...@mellanox.commailto:len...@mellanox.com wrote: Hi All, Please add Mellanox Cinder CI to this page https://wiki.openstack.org/wiki/Cinder/third-party-ci-status Lenny, You should be able to edit and add this yourself, once you login with your ID on that page thanx, deepak Driver name: iSER-LIO, iSER-ISCSI Contact: Lenny Verkhovsky cinder...@mellanox.commailto:cinder...@mellanox.com Status: voting and reporting Issues: none Reference https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_Cinder_CI Thanks. Lenny Verkhovsky SW Engineer, Mellanox Technologies www.mellanox.comhttp://www.mellanox.com Office:+972 74 712 9244 Mobile: +972 54 554 0233 Fax:+972 72 257 9400 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] Meters vs. Metrics
On Tue, Mar 24 2015, Tim Bell wrote: Can we keep it consistent ? The APIs have meter in them, so do the CLIs so we should really stick to that convention. It should be consistent already, as picked terms years ago. Meters represents a set of samples with the same meter_name. There's no metrics in Ceilometer. If Gnocchi is using metrics, I feel it should change to use meters or a V3 API proposed that changes it all. Gnocchi is using metrics to differ from Ceilometer's meters because they are not the same concept. -- Julien Danjou // Free Software hacker // http://julien.danjou.info signature.asc 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
Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers
This project looks very interesting and i might give it a go by installing
standalone. I have a question though: are there any plans to expose the
current output as part of Horizon or any other UI ?
Thx,
Dani
On Wed, Mar 25, 2015 at 5:15 AM, Zhou, Zhenzan zhenzan.z...@intel.com
wrote:
Just found it has been supported, e.g.
openstack congress driver schema show ceilometer
So here is the way to check data source drivers:
For supported data source drivers:
1. openstack congress driver list
2. openstack congress driver schema show ds-name
For enabled data source drivers:
1. openstack congress datasource list
2. openstack congress datasource schema show ds-name
BR
Zhou Zhenzan
*From:* Zhou, Zhenzan [mailto:zhenzan.z...@intel.com]
*Sent:* Wednesday, March 25, 2015 12:24 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Congress] Info on Currently Supported
Data Drivers
Hi,
The ‘driver list’ sub command could provide supported data source drivers,
but we cannot show its schema if it’s NOT LOADED. So we still have to check
the code for the schema. My point is that we could support show schemas for
any supported data source drivers, even it’s not loaded.
zhenzan@zhenzan-openstack:~$ openstack congress driver list
++--+
| id |
description |
++--+
| ceilometer | Datasource driver that interfaces with
ceilometer. |
| plexxi | Datasource driver that interfaces with
PlexxiCore. |
| swift | Datasource driver that interfaces with
swift.|
| neutronv2 | Datasource driver that interfaces with OpenStack
Networking aka Neutron. |
| nova | Datasource driver that interfaces with OpenStack
Compute aka nova. |
| murano | Datasource driver that interfaces with
murano|
| keystone | Datasource driver that interfaces with
keystone. |
| cloudfoundryv2 | Datasource driver that interfaces with
cloudfoundry |
| ironic | Datasource driver that interfaces with OpenStack bare
metal aka ironic. |
| cinder | Datasource driver that interfaces with OpenStack
cinder. |
| vcenter| Datasource driver that interfaces with
vcenter |
| glancev2 | Datasource driver that interfaces with OpenStack Images
aka Glance. |
++--+
zhenzan@zhenzan-openstack:~$ openstack congress datasource schema show
ceilometer
ERROR: openstack Resource ceilometer not found (HTTP 404)
BR
Zhou Zhenzan
*From:* Pierre-Emmanuel Ettori [mailto:pe.ett...@gmail.com
pe.ett...@gmail.com]
*Sent:* Wednesday, March 25, 2015 11:54 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Congress] Info on Currently Supported
Data Drivers
Hi Zhenzan,
Actually I believe the command that Tim is looking for is:
openstack congress datasource list
Please let us know if you are running into any issue.
Thanks
Pierre
On Tue, Mar 24, 2015 at 8:39 PM Tim Hinrichs thinri...@vmware.com wrote:
Hi Zhenzan,
I don't have the CLI in front of me, but check out the 'driver' commands.
The command you're looking for is something like the following.
$ openstack congress driver list
Tim
--
*From:* Zhou, Zhenzan zhenzan.z...@intel.com
*Sent:* Tuesday, March 24, 2015 7:39 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Congress] Info on Currently Supported
Data Drivers
Hi,
To check LOADED(or ENABLED) data source drivers for a running system, you
can use congress cli. Maybe we could add a command to list SUPPORTED data
source drivers?
zhenzan@zhenzan-openstack:~$ openstack congress datasource list
+--+---+-+--+-+
| id | name | enabled | type |
config
|
+--+---+-+--+-+
| 20a33403-e8d0-440a-b36f-0383bfcfd06f | cinder| True| None |
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden',
u'auth_url':
Re: [openstack-dev] [depfreeze][horizon] Update to Django-1.7.x
On 03/25/2015 05:04 AM, Thierry Carrez wrote: Matthias Runge wrote: I'm requesting an exception to bump Django to Django-1.7.x (or better). Rationale: Django-1.8 is expected to be released during the next days. Once it's released, Django-1.6.x will become unsupported by its upstream. Unfortunately that's the latest version we're gating against and that's the version frozen for kilo, or in other words: When Kilo is released, it relies on a version, not supported any more. Review is at https://review.openstack.org/#/c/155353/ Could you make this one Depends on https://review.openstack.org/#/c/167515/ so that we check that all Django 1.7 related issues are fixed ? I don't think it was ever sufficiently explained why horizon now needs django nose to compile it's message catalog (which is where it is failing) when moving to 1.7. http://logs.openstack.org/53/155353/7/check/check-tempest-dsvm-full/961c75f/logs/devstacklog.txt.gz#_2015-03-20_19_25_51_098 That seems to mean that nose is no longer a test only requirement, but a hard requirement for installation. While we can work around that in the gate, I think this might bite some real users here. And I'd rather know why this need changed. -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
Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin
On 03/25/2015 03:16 AM, Deepak Shetty wrote:
On Wed, Mar 25, 2015 at 11:29 AM, Deepak Shetty dpkshe...@gmail.com
mailto:dpkshe...@gmail.com wrote:
On Wed, Mar 25, 2015 at 12:58 AM, Ian Wienand iwien...@redhat.com
mailto:iwien...@redhat.com wrote:
On 03/24/2015 03:17 PM, Deepak Shetty wrote:
For eg: Look at [1]
[1]
https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/settings
I would like ability to change these while I use the enable_plugin
apporach to setup devstack w/ GlusterFS per my local glusterfs setup
So I think the plugin should do
CINDER_ENABLED_BACKENDS=${CINDER_ENABLED_BACKENDS:-glusterfs:glusterfs,lvm:lvm1}
i.e. provide a default only if the variable is unset.
Bah! That was easy, i should have figured that myself :)
Thanks for catching that
This seems like one of those traps for new players and is one
concern I have with devstack plugins -- that authors keep having to
find out lessons learned independently. I have added a note on this
to the documentation in [1].
-i
[1] https://review.openstack.org/#/c/167375/
Great, i +1'ed it.
Also i posted patch to fix settings file @
https://review.openstack.org/167494
Ian,
Looks like usign bash default in settings file of plugin is not
working, in my patch it didn't use glusterfs driver, it used LVM (default)
I think whats happening here is that by the time settings file is
sourced, CINDER_ENABLED_BACKENDS is already set to lvm by lib/cinder
so settings file's default value is never taken
IIUC there are 3 scenarios (taking CINDER_ENABLED_BACKENDS as example var) :
1) localrc doesn't have CINDER_ENABLED_BACKENDS and enable_plugin
- Here we want the lib/cinder's default value to be taken
- this should work fine
2) localrc doesn't have CINDER_ENABLED_BACKENDS but has enable_plugin
glusterfs
- Here we want the plugin's default values to be taken, but its not
as lib/cinder already initialized CINDER_ENABLED_BACKENDS to use lvm backend
- Thus broken
3) localrc has both CINDER_ENABLED_BACKENDS and enable_plugin glusterfs
specified
- Here we want CINDER_ENABLED_BACKENDS present in my localrc to be
chosen
- This will work as by the time settings file is sourced
CINDER_ENABLED_BACKENDS is already initialised to my value in localrc
So #2 scenario would need some changes in stack.sh handling of plugin code ?
Right, so this code runs late enough that you don't get to change the
defaults. I think that's ok.
I would instead do the following:
1) CINDER_ENABLED_BACKENDS+=,glusterfs:glusterfs
or
2) CINDER_ENABLED_BACKENDS=glusterfs:glusterfs
in the plugin.
Clearly, if you've enabled the plugin, you want glusterfs. I think that
in most cases you probably only want glusterfs as your backend, so
option #2 seems sensible.
-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
Re: [openstack-dev] [kolla] Re: Why we didn't use k8s in kolla?
Hello, So if I understand correctly Kubernetes was avoided since there is no control point and using fig/docker-compose would get you a top to the bottom deployment that easy to control. At this point is there any reasons not using something like ansible+docker plugin instead? I have used extensively fig back in the days for an internal project of mine and quickly come to its limitations with regard to caching and redeployment (was keeping having to do fig ps -q|xargs -r docker stop || true ) Cheers, Chmouel On Sun, Mar 22, 2015 at 4:50 PM, Steven Dake (stdake) std...@cisco.com wrote: FenghuaFeng, Ccing openstack-dev 1. Kubernetes doesn’t offer a control or integration point. We have that now with docker-compose. 2. Kubernetes doesn’t offer super privileged containers. We need that in order to operate an OpenStack environment. Regards -steve From: 449171342 449171...@qq.com Date: Sunday, March 22, 2015 at 1:47 AM To: Steven Dake std...@cisco.com Subject: Why we didn't use k8s in kolla? __ 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] creating stable branches for all libraries, Oslo, client, and other
Am 24/03/15 um 22:22 schrieb Joe Gordon: On Tue, Mar 24, 2015 at 1:13 PM, Doug Hellmann d...@doughellmann.com wrote: We have a cross-project spec up for review discussing a change in the release process precipitated by the fact that we are now capping library versions in stable branch test configurations. We’ve talked about it a couple of times at the cross-project meetings, but we also want to make sure it is widely seen because it will affect the way bug fixes need to be managed in client libraries (new releases of clients won’t automatically make it into stable branches, and we will need to maintain stable branches of the clients with back-ports for critical fixes). Here is a real case where the correct fix is a stable branch for a client: https://bugs.launchpad.net/python-glanceclient/+bug/1423165 In case someone would like to read a bit about how this bug manifested itself for us from an operators point of view: http://blog.offenerstapel.de/blog/2015/03/25/openstack-gone-wild/ __ 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] VLAN trunking network for NFV
Today: You need to ensure that your cloud is using a suitable networking config - with ML2, use Linuxbridge and either VXLAN or GRE. If you're using either OVS or VLAN you won't get a trunking network. A tenant can't tell this, so they can't easily tell that all or any networks are VLAN trunks without testing the network. Tomorrow (i.e. on trunk, or when Kilo is released): You can use the vlan_transparent flag on a network to explicitly request a trunk. The dataplane code hasn't changed, so the cloud will report that the network is a trunk if you're using ML2 with Linuxbridge and GRE or VXLAN, and will report you can't have a trunk if you use OVS or VLAN. This means that you are no more likely to get a trunk if you ask for one - you still need a suitable configuration - but your application will immediately know if it works or not (the old alternative was pretty much to start it and see if it works, which wasn't helpful). ML2 now has a reference implementation of this; other plugins (to the best of my knowledge) don't support the flag. When they do, then any plugin or driver can theoretically be written to behave differently if you have ask for a trunk; for instance, in the future we can change the code to program OVS differently if you want a trunk, or change ML2 to use a trunk-safe VXLAN overlay even though VLAN networks are also available in a system. No driver does this today. -- Ian. On 24 March 2015 at 17:48, Guo, Ruijing ruijing@intel.com wrote: I am trying to understand how guest os use trunking network. If guest os use bridge like Linuxbride and OVS, how we launch it and how libvirt to support it? Thanks, -Ruijing *From:* Ian Wells [mailto:ijw.ubu...@cack.org.uk] *Sent:* Wednesday, March 25, 2015 2:18 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron] VLAN trunking network for NFV That spec ensures that you can tell what the plugin is doing. You can ask for a VLAN transparent network, but the cloud may tell you it can't make one. The OVS driver in Openstack drops VLAN tagged packets, I'm afraid, and the spec you're referring to doesn't change that. The spec does ensure that if you try and create a VLAN trunk on a cloud that uses the OVS driver, you'll be told you can't. in the future, the OVS driver can be fixed, but that's how things stand at present. Fixing the OVS driver really involves getting in at the OVS flow level - can be done, but we started with the basics. If you want to use a VLAN trunk using the current code, I recommend VXLAN or GRE along with the Linuxbridge driver, both of which support VLAN transparent networking. If they're configured and you ask for a VLAN trunk you'll be told you got one. -- Ian. On 24 March 2015 at 09:43, Daniele Casini daniele.cas...@dektech.com.au wrote: Hi all: in reference to the following specification about the creation of VLAN trunking network for NFV https://review.openstack.org/#/c/136554/3/specs/kilo/nfv-vlan-trunks.rst I would like to better understand how the tagged traffic will be realized. In order to explain myself, I report the following use case: A VNF is deployed in one VM, which has a trunk port carrying traffic for two VLANs over a single link able to transport more than one VLAN through a single integration-bridge (br-int) port. So, How does br-int manage the VLAN-ID? In other words, what are the action performed by the br-int when a VM forwards traffic to another host? Does it put an additional tag or replace the existing one keeping the match with a table or something like that? Thank you very much. Daniele __ 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] [Ceilometer] Meters vs. Metrics
On Wed, Mar 25 2015, Tim Bell wrote: Unfortunately, this is a cause of confusion for the users. Do you have a reference to the differences in the concepts ? There's a glossary here: http://docs.openstack.org/developer/ceilometer/glossary.html The ceilometer doc does also have this confusion in some places, for example, http://docs.openstack.org/developer/ceilometer/measurements.html mixes the terms. Agreed, that's a bug, it should be meter. -- Julien Danjou ;; Free Software hacker ;; http://julien.danjou.info signature.asc 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] [OpenStack-Infra] [cinder] Status of Huawei Volume CI
Hello Cinder team, * Huawei Volume CI has been reporting since Decemberapp:ds:December 20 th 2014. Now it runs * two tempest jobs for Huawei 18000 iSCSI driver and Huawei 18000 FC driver. * Considering that our drivers have been moved for the upstream, I have added some * code to ensureapp:ds:ensure the jobs run against the real storage backend when building devstack. * * And now the CI is reporting much more stably and will keep running and reporting from now on. * Below is a link shows the recentlyapp:ds:recently posted results from the CI: https://review.openstack.org/#/q/reviewer:%22Huawei+Volume+CI%22,n,z I kindly request that you accept our CI result and consider re-integrating our 18000 iSCSI and 18000 FC drivers back in Kilo RC. If there is any concern, please let us know. 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
Re: [openstack-dev] [Ceilometer] Meters vs. Metrics
Hi All, Thanks for the heads up regarding to this inconsistency of terms in the docs. I will open a bug for it and target both Ceilometer and OS Manuals to get it corrected everywhere. Best Regards, Ildikó -Original Message- From: Julien Danjou [mailto:jul...@danjou.info] Sent: Wednesday, March 25, 2015 1:14 PM To: Tim Bell Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ceilometer] Meters vs. Metrics On Wed, Mar 25 2015, Tim Bell wrote: Unfortunately, this is a cause of confusion for the users. Do you have a reference to the differences in the concepts ? There's a glossary here: http://docs.openstack.org/developer/ceilometer/glossary.html The ceilometer doc does also have this confusion in some places, for example, http://docs.openstack.org/developer/ceilometer/measurements.html mixes the terms. Agreed, that's a bug, it should be meter. -- Julien Danjou ;; Free Software hacker ;; http://julien.danjou.info __ 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] [kolla] Re: Why we didn't use k8s in kolla?
From: Chmouel Boudjnah chmo...@chmouel.commailto:chmo...@chmouel.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, March 25, 2015 at 5:36 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [kolla] Re: Why we didn't use k8s in kolla? Hello, So if I understand correctly Kubernetes was avoided since there is no control point and using fig/docker-compose would get you a top to the bottom deployment that easy to control. That is one reason we stopped using kubernetes. The second was it didn’t offer super privileged container support, which we absolutely require. Your right on the rationale for fig/docker-compose. At this point is there any reasons not using something like ansible+docker plugin instead? I have used extensively fig back in the days for an internal project of mine and quickly come to its limitations with regard to caching and redeployment (was keeping having to do fig ps -q|xargs -r docker stop || true ) Your right fig/docker compose seems to have problems when something from docker daemon doesn’t do what it expects. The bugs are really docker daemon bugs, for example, see: https://github.com/docker/compose/issues/812 As far as ansible, I think it would be fantastic to use ansible to deploy kolla containers, and if I were making a deployment tool today, this is precisely what I’d do. Whether ansible used docker directly by looking at our fig files, or compose, would be up to the author. I think using fig would be preferrable in case the composition needed to change for some technical reason. Regards -steve Cheers, Chmouel On Sun, Mar 22, 2015 at 4:50 PM, Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com wrote: FenghuaFeng, Ccing openstack-dev 1. Kubernetes doesn’t offer a control or integration point. We have that now with docker-compose. 2. Kubernetes doesn’t offer super privileged containers. We need that in order to operate an OpenStack environment. Regards -steve From: 449171342 449171...@qq.commailto:449171...@qq.com Date: Sunday, March 22, 2015 at 1:47 AM To: Steven Dake std...@cisco.commailto:std...@cisco.com Subject: Why we didn't use k8s in kolla? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [OpenStack-Infra] [cinder] Status of Huawei Volume CI
I checked 3 random ones and I couldn't see any log files. Ramy https://review.openstack.org/#/c/144409/ Patch Set 6: Build succeeded. - huawei-iscsi-dsvm-tempest-full ... Mar 1 11:54 PM http://125.70.13.170:8088/huawei-iscsi-dsvm-tempest-full/357 Not found http://125.70.13.170:8088/huawei-fc-dsvm-tempest-full/26 Not found Both links fail to show any logs https://review.openstack.org/#/c/164692/ Huawei Volume CI check Mar 22, 2015 1:37 PM huawei-iscsi-dsvm-tempest-fullhttp://125.70.13.170:8088/huawei-iscsi-dsvm-tempest-full/414 FAILURE in 12m 54s huawei-fc-dsvm-tempest-fullhttp://125.70.13.170:8088/huawei-fc-dsvm-tempest-full/99 FAILURE in 11m 03s Both links fail to show any logs https://review.openstack.org/#/c/167080/ Huawei Volume CI check Mar 24, 2015 6:47 AM huawei-iscsi-dsvm-tempest-fullhttp://125.70.13.170:8088/huawei-iscsi-dsvm-tempest-full/432 UNSTABLE in 15m 32s huawei-fc-dsvm-tempest-fullhttp://125.70.13.170:8088/huawei-fc-dsvm-tempest-full/122 SUCCESS in 17m 09s Both links fail to show any logs From: liuxinguo [mailto:liuxin...@huawei.com] Sent: Wednesday, March 25, 2015 5:45 AM To: OpenStack Development Mailing List (not for usage questions); openstack-in...@lists.openstack.org Cc: Fanyaohong Subject: [openstack-dev] [OpenStack-Infra] [cinder] Status of Huawei Volume CI Hello Cinder team, *Huawei Volume CI has been reporting since Decemberapp:ds:December 20 th 2014. Now it runs *two tempest jobs for Huawei 18000 iSCSI driver and Huawei 18000 FC driver. *Considering that our drivers have been moved for the upstream, I have added some *code to ensureapp:ds:ensure the jobs run against the real storage backend when building devstack. * *And now the CI is reporting much more stably and will keep running and reporting from now on. *Below is a link shows the recentlyapp:ds:recently posted results from the CI: https://review.openstack.org/#/q/reviewer:%22Huawei+Volume+CI%22,n,z I kindly request that you accept our CI result and consider re-integrating our 18000 iSCSI and 18000 FC drivers back in Kilo RC. If there is any concern, please let us know. 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
Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware )
From: Jordan Pittier jordan.pitt...@scality.commailto:jordan.pitt...@scality.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, March 25, 2015 at 1:47 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware ) Hi On Wed, Mar 25, 2015 at 12:39 PM, Sean Dague s...@dague.netmailto:s...@dague.net wrote: Currently Citrix, HyperV, and VMWare CI systems reporting on Nova patches have a different formatting than the standard that Jenkins and other systems are using: * test-name-no-spaces http://link.to/resulthttps://urldefense.proofpoint.com/v2/url?u=http-3A__link.to_resultd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiEs=5SS-txUrD3o8KS3QIaCL3XMBbeCYK5CjmzmuxDda7Oce= : [SUCCESS|FAILURE] some comment about the test I don't want to talk for Citrix, HyperV or VMWare but the standard only work if you use Zuul in your CI. I am using a setup based on a Jenkins plugin called gerrit-trigger and there's no way to format the message the way it's expected... This means these systems don't show up in the CI rollup block - http://dl.dropbox.com/u/6514884/screenshot_158.pnghttps://urldefense.proofpoint.com/v2/url?u=http-3A__dl.dropbox.com_u_6514884_screenshot-5F158.pngd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiEs=nIjYwznh1_8aVBSz-XVEJrpNaMsDfqyekOQ2IhiHTo8e= Current the Vmware CI will vote +1 iff the patch has passed on the CI. We can investigate adding this to the CI rollup block. I'd really like that to change. The CI rollup block has been extremely useful in getting the test results of a patch above the fold, and the ability to dig into them clearly. I feel like if any CI system isn't reporting in standard format that's parsible by that, we should probably turn it off. I do not think that we should turn this off. They have value. It would be nice if things were all of the same format, which I guess that this is the intension of the mail. Lets all try and make an effort to work towards this goal. What's fair warning to get these systems postings into the standard format? It realistically should be a very quick change by them, but will help quite a lot in reviewing code. -Sean -- Sean Dague http://dague.nethttps://urldefense.proofpoint.com/v2/url?u=http-3A__dague.netd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiEs=zvLmRDIA_kZRg-RYLMhXhNfvNXq3Ni_9LKyJYxD5Nioe= __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [devstack] Overriding settings file for devstack plugin
On Wed, Mar 25, 2015 at 5:58 AM, Deepak Shetty dpkshe...@gmail.com wrote: Sorry, hit send before i could complete back to square one (unless we modify lib/cinder to *not* use default for CINDER_ENABLED_BACKENDS if 'CINDER_ENABLED_BACKENDS=' specified in localrc) You could safely set CINDER_ENABLED_BACKENDS=; in local.conf to avoid the :- default setting. dt -- Dean Troyer dtro...@gmail.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] [devstack] Overriding settings file for devstack plugin
On Wed, Mar 25, 2015 at 7:30 PM, Dean Troyer dtro...@gmail.com wrote: I wasn't clear, let me try again: CINDER_ENABLED_BACKENDS=; set the value to the separator character semi-colon. That evaluates to not-empty for the shell :- but has no entries so is still effectively null for the cinder config code. Ah, i didn't notice the semi-colon :) I guess this should work, so #1 (per sean's suggested options) seems to be the way to go for now 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] CI report formatting (citrix / hyperv / vmware )
On 25 March 2015 at 14:21, Sean Dague s...@dague.net wrote: On 03/25/2015 09:03 AM, Gary Kotton wrote: From: Jordan Pittier jordan.pitt...@scality.com mailto:jordan.pitt...@scality.com Reply-To: OpenStack List openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: Wednesday, March 25, 2015 at 1:47 PM To: OpenStack List openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware ) Hi On Wed, Mar 25, 2015 at 12:39 PM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: Currently Citrix, HyperV, and VMWare CI systems reporting on Nova patches have a different formatting than the standard that Jenkins and other systems are using: * test-name-no-spaces http://link.to/result https://urldefense.proofpoint.com/v2/url?u=http-3A__link.to_resultd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiEs=5SS-txUrD3o8KS3QIaCL3XMBbeCYK5CjmzmuxDda7Oce= : [SUCCESS|FAILURE] some comment about the test I don't want to talk for Citrix, HyperV or VMWare but the standard only work if you use Zuul in your CI. I am using a setup based on a Jenkins plugin called gerrit-trigger and there's no way to format the message the way it's expected... FWIW I help maintain one the VMware CIs (the one voting on neutron and network-related patches for devstack and tempest). We use gerrit-trigger too (mostly out of lazyness, no other real reason), but we're able to format the message posted back to gerrit. For posting back votes we use the gerrit review command to post the message in the standard format. I think the same process is adopted also by the CI voting on nova. However, the job result string is not being posted. I will double check with the respective owners. Salvatore This means these systems don't show up in the CI rollup block - http://dl.dropbox.com/u/6514884/screenshot_158.png https://urldefense.proofpoint.com/v2/url?u=http-3A__dl.dropbox.com_u_6514884_screenshot-5F158.pngd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiEs=nIjYwznh1_8aVBSz-XVEJrpNaMsDfqyekOQ2IhiHTo8e= Current the Vmware CI will vote +1 iff the patch has passed on the CI. We can investigate adding this to the CI rollup block. I'd really like that to change. The CI rollup block has been extremely useful in getting the test results of a patch above the fold, and the ability to dig into them clearly. I feel like if any CI system isn't reporting in standard format that's parsible by that, we should probably turn it off. I do not think that we should turn this off. They have value. It would be nice if things were all of the same format, which I guess that this is the intension of the mail. Lets all try and make an effort to work towards this goal. Right, honestly, I don't want these turned off, I want them reporting in a more standard format. But I do think if they don't report in a standard format it will cause problems and add to them being ignored. -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
[openstack-dev] [release] oslo.messaging 1.8.1
We are pleased to announce the release of: oslo.messaging 1.8.1: Oslo Messaging API This is a Kilo-series patch release, fixing several bugs. For more details, please see the git log history below and: http://launchpad.net/oslo.messaging/+milestone/1.8.1 Please report issues through launchpad: http://bugs.launchpad.net/oslo.messaging Changes in oslo.messaging 1.8.0..1.8.1 -- 57fad97 Publish tracebacks only on debug level b5f91b2 Reconnect on connection lost in heartbeat thread ac8bdb6 cleanup connection pool return ee18dc5 rabbit: Improves logging db99154 fix up verb tense in log message 64bdd80 rabbit: heartbeat implementation 9b14d1a Add support for multiple namespaces in Targets Diffstat (except docs and test files) - oslo_messaging/_drivers/amqp.py | 44 ++- oslo_messaging/_drivers/amqpdriver.py| 15 +- oslo_messaging/_drivers/impl_qpid.py | 2 +- oslo_messaging/_drivers/impl_rabbit.py | 346 --- oslo_messaging/rpc/dispatcher.py | 2 +- oslo_messaging/target.py | 9 +- 11 files changed, 541 insertions(+), 70 deletions(-) __ 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] CI report formatting (citrix / hyperv / vmware )
On 03/25/2015 09:03 AM, Gary Kotton wrote: From: Jordan Pittier jordan.pitt...@scality.com mailto:jordan.pitt...@scality.com Reply-To: OpenStack List openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: Wednesday, March 25, 2015 at 1:47 PM To: OpenStack List openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware ) Hi On Wed, Mar 25, 2015 at 12:39 PM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: Currently Citrix, HyperV, and VMWare CI systems reporting on Nova patches have a different formatting than the standard that Jenkins and other systems are using: * test-name-no-spaces http://link.to/result https://urldefense.proofpoint.com/v2/url?u=http-3A__link.to_resultd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiEs=5SS-txUrD3o8KS3QIaCL3XMBbeCYK5CjmzmuxDda7Oce= : [SUCCESS|FAILURE] some comment about the test I don't want to talk for Citrix, HyperV or VMWare but the standard only work if you use Zuul in your CI. I am using a setup based on a Jenkins plugin called gerrit-trigger and there's no way to format the message the way it's expected... This means these systems don't show up in the CI rollup block - http://dl.dropbox.com/u/6514884/screenshot_158.png https://urldefense.proofpoint.com/v2/url?u=http-3A__dl.dropbox.com_u_6514884_screenshot-5F158.pngd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiEs=nIjYwznh1_8aVBSz-XVEJrpNaMsDfqyekOQ2IhiHTo8e= Current the Vmware CI will vote +1 iff the patch has passed on the CI. We can investigate adding this to the CI rollup block. I'd really like that to change. The CI rollup block has been extremely useful in getting the test results of a patch above the fold, and the ability to dig into them clearly. I feel like if any CI system isn't reporting in standard format that's parsible by that, we should probably turn it off. I do not think that we should turn this off. They have value. It would be nice if things were all of the same format, which I guess that this is the intension of the mail. Lets all try and make an effort to work towards this goal. Right, honestly, I don't want these turned off, I want them reporting in a more standard format. But I do think if they don't report in a standard format it will cause problems and add to them being ignored. -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
Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin
On Wed, Mar 25, 2015 at 6:04 AM, Deepak Shetty dpkshe...@gmail.com wrote: Had a question here, why is this source in the end ? More often than not, you will want the variables defined by the other plugins (including the built-ins), this is really the first case we've had to deviate from that. The right solution is to add an 'override_plugins' phase that runs before the built-ins are sourced so you can override the built-in defaults. dt -- Dean Troyer dtro...@gmail.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] [devstack] Overriding settings file for devstack plugin
On Wed, Mar 25, 2015 at 6:58 PM, Dean Troyer dtro...@gmail.com wrote: On Wed, Mar 25, 2015 at 5:58 AM, Deepak Shetty dpkshe...@gmail.com wrote: Sorry, hit send before i could complete back to square one (unless we modify lib/cinder to *not* use default for CINDER_ENABLED_BACKENDS if 'CINDER_ENABLED_BACKENDS=' specified in localrc) You could safely set CINDER_ENABLED_BACKENDS=; in local.conf to avoid the :- default setting. Per the comment from yamamoto [1] it seems :- stands for unset or empty, so it won't work (IIUC) [1]: https://review.openstack.org/#/c/167375/1/doc/source/plugins.rst 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] [Neutron] VLAN trunking network for NFV
- Original Message - *From:* Ian Wells [mailto: ijw.ubuntu at cack.org.uk ] *Sent:* Wednesday, March 25, 2015 2:18 AM That spec ensures that you can tell what the plugin is doing. You can ask for a VLAN transparent network, but the cloud may tell you it can't make one. If you want to use a VLAN trunk using the current code, I recommend VXLAN or GRE along with the Linuxbridge driver, both of which support VLAN transparent networking. If they're configured and you ask for a VLAN trunk you'll be told you got one. The linuxbridge agent does not support GRE. I tried sending tagged packets over linuxbridge+VxLAN and it did not work - I didn't look into it any further. This was a strong premise of the spec when it was under discussion, that we at least some part of the reference implementation (LB + VXLAN was cited) that works. If it doesn't, I think it's problematic to introduce new API without a reference implementation. I also tried over linuxbridge+FLAT - this works when the physical switch ports are trunks - they would need to permit all VLAN ids to be fully VLAN transparent. I think linuxbridge+VLAN would work too, as along as the switch ports are also configured for Q-in-Q. Currently the linuxbridge mechanism driver cannot know if a Neutron network is VLAN transparent or not. __ 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] 回复：[kolla] Re: Why we didn't use k8s in kolla?
From: 449171342 449171...@qq.commailto:449171...@qq.com Date: Tuesday, March 24, 2015 at 9:58 PM To: Steven Dake std...@cisco.commailto:std...@cisco.com Cc: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: 回复：[kolla] Re: Why we didn't use k8s in kolla? TKS，I have aanather question . DId kolla is a isolate project work together with TriplleO or kolla is part of it? At the moment we are a separate project. I’d prefer that multiple deployment systems integrate with Kolla. Some in the community have discussed creating a deployment tool as well to deploy Kolla containers if there is little community uptake on our work. Regards -steve ---原始邮件--- 发件人: Steven Dake (stdake)std...@cisco.commailto:std...@cisco.com 发送时间: 2015年03月22日 23:50:17 收件人: 449171342449171...@qq.commailto:449171...@qq.com; 抄送: OpenStack Development Mailing List (not for usage questions)openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org; 主题: [kolla] Re: Why we didn't use k8s in kolla? FenghuaFeng, Ccing openstack-dev 1. Kubernetes doesn’t offer a control or integration point. We have that now with docker-compose. 2. Kubernetes doesn’t offer super privileged containers. We need that in order to operate an OpenStack environment. Regards -steve From: 449171342 449171...@qq.commailto:449171...@qq.com Date: Sunday, March 22, 2015 at 1:47 AM To: Steven Dake std...@cisco.commailto:std...@cisco.com Subject: Why we didn't use k8s in kolla? __ 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] Overriding settings file for devstack plugin
I wasn't clear, let me try again: CINDER_ENABLED_BACKENDS=; set the value to the separator character semi-colon. That evaluates to not-empty for the shell :- but has no entries so is still effectively null for the cinder config code. dt On Wed, Mar 25, 2015 at 8:47 AM, Deepak Shetty dpkshe...@gmail.com wrote: On Wed, Mar 25, 2015 at 6:58 PM, Dean Troyer dtro...@gmail.com wrote: On Wed, Mar 25, 2015 at 5:58 AM, Deepak Shetty dpkshe...@gmail.com wrote: Sorry, hit send before i could complete back to square one (unless we modify lib/cinder to *not* use default for CINDER_ENABLED_BACKENDS if 'CINDER_ENABLED_BACKENDS=' specified in localrc) You could safely set CINDER_ENABLED_BACKENDS=; in local.conf to avoid the :- default setting. Per the comment from yamamoto [1] it seems :- stands for unset or empty, so it won't work (IIUC) [1]: https://review.openstack.org/#/c/167375/1/doc/source/plugins.rst 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 -- Dean Troyer dtro...@gmail.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-dev] [release] oslo.messaging 1.9.0
We are content to announce the release of: oslo.messaging 1.9.0: Oslo Messaging API This is the first release of the library for the Liberty development cycle. For more details, please see the git log history below and: http://launchpad.net/oslo.messaging/+milestone/1.9.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.messaging Changes in oslo.messaging 1.8.0..1.9.0 -- 8da14f6 Use the oslo_utils stop watch in decaying timer ec1fb8c Updated from global requirements 84c0d3a Remove 'UNIQUE_ID is %s' logging 9f13794 rabbit: fix ipv6 support 3f967ef Create a unique transport for each server in the functional tests 23dfb6e Publish tracebacks only on debug level 53fde06 Add pluggability for matchmakers b92ea91 Make option [DEFAULT]amqp_durable_queues work cc618a4 Reconnect on connection lost in heartbeat thread f00ec93 Imported Translations from Transifex 0dff20b cleanup connection pool return 2d1a019 rabbit: Improves logging 0ec536b fix up verb tense in log message b9e134d rabbit: heartbeat implementation 72a9984 Fix changing keys during iteration in matchmaker heartbeat cf365fe Minor improvement 5f875c0 ZeroMQ deployment guide 410d8f0 Fix a couple typos to make it easier to read. 3aa565b Tiny problem with notify-server in simulator 0f87f5c Fix coverage report generation 3be95ad Add support for multiple namespaces in Targets 513ce80 tools: add simulator script 0124756 Deprecates the localcontext API ce7d5e8 Update to oslo.context eaa362b Remove obsolete cross tests script 1958f6e Fix the bug redis do not delete the expired keys 9f457b4 Properly distinguish between server index zero and no server 0006448 Adjust tests for the new namespace Diffstat (except docs and test files) - .coveragerc| 7 + openstack-common.conf | 6 +- .../locale/de/LC_MESSAGES/oslo.messaging.po| 48 ++- .../locale/en_GB/LC_MESSAGES/oslo.messaging.po | 48 ++- .../locale/fr/LC_MESSAGES/oslo.messaging.po| 40 ++- oslo.messaging/locale/oslo.messaging.pot | 50 ++- oslo_messaging/_drivers/amqp.py| 55 +++- oslo_messaging/_drivers/amqpdriver.py | 15 +- oslo_messaging/_drivers/common.py | 20 +- oslo_messaging/_drivers/impl_qpid.py | 4 +- oslo_messaging/_drivers/impl_rabbit.py | 357 ++--- oslo_messaging/_drivers/impl_zmq.py| 32 +- oslo_messaging/_drivers/matchmaker.py | 2 +- oslo_messaging/_drivers/matchmaker_redis.py| 7 +- oslo_messaging/localcontext.py | 16 + oslo_messaging/notify/dispatcher.py| 4 +- oslo_messaging/notify/middleware.py| 2 +- oslo_messaging/openstack/common/_i18n.py | 45 +++ oslo_messaging/openstack/common/versionutils.py| 253 +++ oslo_messaging/rpc/dispatcher.py | 6 +- oslo_messaging/target.py | 9 +- requirements-py3.txt | 13 +- requirements.txt | 15 +- setup.cfg | 6 + test-requirements-py3.txt | 4 +- test-requirements.txt | 4 +- tools/simulator.py | 207 tox.ini| 3 +- 43 files changed, 1673 insertions(+), 512 deletions(-) Requirements updates diff --git a/requirements-py3.txt b/requirements-py3.txt index 05cb050..4ec18c6 100644 --- a/requirements-py3.txt +++ b/requirements-py3.txt @@ -5,5 +5,6 @@ -oslo.config=1.9.0 # Apache-2.0 -oslo.serialization=1.2.0 # Apache-2.0 -oslo.utils=1.2.0 # Apache-2.0 -oslo.i18n=1.3.0 # Apache-2.0 -stevedore=1.1.0 # Apache-2.0 +oslo.config=1.9.3,1.10.0 # Apache-2.0 +oslo.context=0.2.0,0.3.0 # Apache-2.0 +oslo.serialization=1.4.0,1.5.0 # Apache-2.0 +oslo.utils=1.4.0,1.5.0 # Apache-2.0 +oslo.i18n=1.5.0,1.6.0 # Apache-2.0 +stevedore=1.3.0,1.4.0 # Apache-2.0 @@ -21 +22 @@ kombu=2.5.0 -oslo.middleware=0.3.0 # Apache-2.0 +oslo.middleware=1.0.0,1.1.0 # Apache-2.0 diff --git a/requirements.txt b/requirements.txt index 3b49a53..ec5fef6 100644 --- a/requirements.txt +++ b/requirements.txt @@ -7,5 +7,6 @@ pbr=0.6,!=0.7,1.0 -oslo.config=1.9.0 # Apache-2.0 -oslo.utils=1.2.0 # Apache-2.0 -oslo.serialization=1.2.0 # Apache-2.0 -oslo.i18n=1.3.0 # Apache-2.0 -stevedore=1.1.0 # Apache-2.0 +oslo.config=1.9.3,1.10.0 # Apache-2.0 +oslo.context=0.2.0,0.3.0 # Apache-2.0 +oslo.utils=1.4.0,1.5.0 # Apache-2.0 +oslo.serialization=1.4.0,1.5.0 #
Re: [openstack-dev] [cinder]Driver broken
Hey, From http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9/console.html : Running ` python setup.py testr --testr-args='--subunit --concurrency 1 test_openvstorage'` == Totals == Ran: 10 tests in 2. sec. - Passed: 10 - Skipped: 0 - Expected Fail: 0 - Unexpected Success: 0 - Failed: 0 Sum of execute time for each test: 0.4477 sec. So his CI did run :) Jordan On Wed, Mar 25, 2015 at 4:31 PM, Asselin, Ramy ramy.asse...@hp.com wrote: Hi Eduard, Your third party ci reported success on that patch. The tempest volume tests include attached detaches. Seems your CI is not running them? http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9/console.html *CloudFounders OpenvStorage CI check* *Mar 10, 2015 9:14 AM* openvstorage-cinder-functionality http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9 SUCCESS in 37m 16s Ramy *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com] *Sent:* Wednesday, March 25, 2015 8:05 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* [openstack-dev] [cinder]Driver broken Hi, Just reported an issue: https://bugs.launchpad.net/cinder/+bug/1436367 Seems to be related to https://review.openstack.org/#/c/85847/ which introduced another parameter to be passed to the driver, but our driver didn't get updated so detach_volume fails for us. How can we get this fixed asap? Thanks, Eduard __ 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]Driver broken
On 03/25/2015 11:44 AM, Jordan Pittier wrote: Hey, From http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9/console.html : Running ` python setup.py testr --testr-args='--subunit --concurrency 1 test_openvstorage'` == Totals == Ran: 10 tests in 2. sec. - Passed: 10 - Skipped: 0 - Expected Fail: 0 - Unexpected Success: 0 - Failed: 0 Sum of execute time for each test: 0.4477 sec. So his CI did run :) Jordan Part of the process of running a CI is to be able to answer questions about your own system. As a operator of a system maintaining a driver, Eduard, the solution for fixing your driver is to offer a patch to fix it. Thanks, Anita. On Wed, Mar 25, 2015 at 4:31 PM, Asselin, Ramy ramy.asse...@hp.com wrote: Hi Eduard, Your third party ci reported success on that patch. The tempest volume tests include attached detaches. Seems your CI is not running them? http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9/console.html *CloudFounders OpenvStorage CI check* *Mar 10, 2015 9:14 AM* openvstorage-cinder-functionality http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9 SUCCESS in 37m 16s Ramy *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com] *Sent:* Wednesday, March 25, 2015 8:05 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* [openstack-dev] [cinder]Driver broken Hi, Just reported an issue: https://bugs.launchpad.net/cinder/+bug/1436367 Seems to be related to https://review.openstack.org/#/c/85847/ which introduced another parameter to be passed to the driver, but our driver didn't get updated so detach_volume fails for us. How can we get this fixed asap? Thanks, Eduard __ 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] [cinder]Driver broken
Hi, Indeed our CI runs, and it reported SUCCESS, but it didn't run the tempest tests, only the openvstorage tests (my bad, looking into it as we speak). Meanwhile i'll create a patch to fix this. Thanks, Eduard __ 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] Beyond IRC (was Re: Cinder Third-Party CI: what next?)
On Tue, 2015-03-24 at 21:21 -0400, Doug Hellmann wrote: ·A separate mailing list for project review requests I'm skeptical about this being effective: just another source of incoming email that needs to be filtered out (at which point a mailman topic would have the same effect). Yes, email notifications scale poorly for really active reviewers. Between gerrit and launchpad, there is already a lot of notification email being filtered out of inboxes. I actually do rely on email notifications for review duties. I use filtering that moves the messages into dedicated folders per repository, and I use threading in those folders. When I see a review merge (or when I see it abandoned), I select the whole thread and delete it; otherwise I follow changes made to a review and determine whether I need to re-review it based on whether votes to that point have been +'s or -'s. I even subscribe to a couple of projects and check out new reviews submitted there. This is actually partly to blame for me being such a prolific reviewer in nova and novaclient :) -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace __ 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] Info on Currently Supported Data Drivers
Hi Dani, We do have an interface in Horizon that you’ll get if you install via devstack (except that you can’t create rules quite yet—that’s under active development). If you install it standalone, you won’t get the Horizon interface, but you can still use the CLI or the restful API. Let us know if you want help getting it setup. And if you hit any bumps, we’d love to hear about them so we can smooth them out. Tim On Mar 25, 2015, at 3:28 AM, Daniel Comnea comnea.d...@gmail.commailto:comnea.d...@gmail.com wrote: This project looks very interesting and i might give it a go by installing standalone. I have a question though: are there any plans to expose the current output as part of Horizon or any other UI ? Thx, Dani On Wed, Mar 25, 2015 at 5:15 AM, Zhou, Zhenzan zhenzan.z...@intel.commailto:zhenzan.z...@intel.com wrote: Just found it has been supported, e.g. openstack congress driver schema show ceilometer So here is the way to check data source drivers: For supported data source drivers: 1. openstack congress driver list 2. openstack congress driver schema show ds-name For enabled data source drivers: 1. openstack congress datasource list 2. openstack congress datasource schema show ds-name BR Zhou Zhenzan From: Zhou, Zhenzan [mailto:zhenzan.z...@intel.commailto:zhenzan.z...@intel.com] Sent: Wednesday, March 25, 2015 12:24 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers Hi, The ‘driver list’ sub command could provide supported data source drivers, but we cannot show its schema if it’s NOT LOADED. So we still have to check the code for the schema. My point is that we could support show schemas for any supported data source drivers, even it’s not loaded. zhenzan@zhenzan-openstack:~$ openstack congress driver list ++--+ | id | description | ++--+ | ceilometer | Datasource driver that interfaces with ceilometer. | | plexxi | Datasource driver that interfaces with PlexxiCore. | | swift | Datasource driver that interfaces with swift. | | neutronv2 | Datasource driver that interfaces with OpenStack Networking aka Neutron. | | nova | Datasource driver that interfaces with OpenStack Compute aka nova. | | murano | Datasource driver that interfaces with murano | | keystone | Datasource driver that interfaces with keystone. | | cloudfoundryv2 | Datasource driver that interfaces with cloudfoundry | | ironic | Datasource driver that interfaces with OpenStack bare metal aka ironic. | | cinder | Datasource driver that interfaces with OpenStack cinder. | | vcenter| Datasource driver that interfaces with vcenter | | glancev2 | Datasource driver that interfaces with OpenStack Images aka Glance. | ++--+ zhenzan@zhenzan-openstack:~$ openstack congress datasource schema show ceilometer ERROR: openstack Resource ceilometer not found (HTTP 404) BR Zhou Zhenzan From: Pierre-Emmanuel Ettori [mailto:pe.ett...@gmail.com] Sent: Wednesday, March 25, 2015 11:54 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers Hi Zhenzan, Actually I believe the command that Tim is looking for is: openstack congress datasource list Please let us know if you are running into any issue. Thanks Pierre On Tue, Mar 24, 2015 at 8:39 PM Tim Hinrichs thinri...@vmware.commailto:thinri...@vmware.com wrote: Hi Zhenzan, I don't have the CLI in front of me, but check out the 'driver' commands. The command you're looking for is something like the following. $ openstack congress driver list Tim From: Zhou, Zhenzan zhenzan.z...@intel.commailto:zhenzan.z...@intel.com Sent: Tuesday, March 24, 2015 7:39 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers Hi, To check LOADED(or ENABLED) data source drivers for a running system, you can use congress cli. Maybe we could add a command to list SUPPORTED data source drivers? zhenzan@zhenzan-openstack:~$ openstack congress datasource list
Re: [openstack-dev] [cinder]Driver broken
Hi Eduard, Your third party ci reported success on that patch. The tempest volume tests include attached detaches. Seems your CI is not running them? http://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9/console.html CloudFounders OpenvStorage CI check Mar 10, 2015 9:14 AM openvstorage-cinder-functionalityhttp://packages.cloudfounders.com/ci_logs/47/85847/47/check/openvstorage-cinder-functionality/b073fb9 SUCCESS in 37m 16s Ramy From: Eduard Matei [mailto:eduard.ma...@cloudfounders.com] Sent: Wednesday, March 25, 2015 8:05 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [cinder]Driver broken Hi, Just reported an issue: https://bugs.launchpad.net/cinder/+bug/1436367 Seems to be related to https://review.openstack.org/#/c/85847/ which introduced another parameter to be passed to the driver, but our driver didn't get updated so detach_volume fails for us. How can we get this fixed asap? Thanks, Eduard __ 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] [os-ansible-deployment] Nominating Nolan Brubaker for core team
Greetings, I would like to nominate Nolan Brubaker (palendae on IRC) for the os-ansible-deployment-core team. Nolan has been involved with the project for the last few months and has been an active reviewer with solid reviews. IMHO, I think he is ready to receive core powers on the repository. References: [ https://review.openstack.org/#/q/project:stackforge/os-ansible-deployment+reviewer:%22nolan+brubaker%253Cnolan.brubaker%2540rackspace.com%253E%22,n,z ] Please respond with +1/-1s or any other concerns. As a reminder, we are using the voting process outlined at [ https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess ] to add members to our core team. — Kevin Carter __ 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] How to do once off/infrequent meetings?
I was looking at using the meetings service (https://wiki.openstack.org/wiki/Meetings) to run and log a meeting on a stackforge project (git-upstream - http://git.openstack.org/cgit/stackforge/git-upstream), which seems to focus on reoccurring meetings. So I'm wondering how best to register an adhoc meeting, I'm sure there may be others in the future, but the project isn't at the point where it would be useful to run a regular meeting. I'm happy enough to just run this through the standard IRC channel in this case, but I figured it might be better if I found out if it was possible to use the meetings service? btw, if anyone is interested in the project git-upstream the discussion/meeting is happening tomorrow in the #git-upstream IRC channel @5pm UTC. -- Regards, Darragh Bailey Systems Software Engineer Hewlett Packard Galway Ltd. +353 91 75-4674 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. smime.p7s Description: S/MIME Cryptographic 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] [barbican] Using KMIP with Barbican (Utkarsh Simha)
Hi Utkarsh, Specifying kmip_plugin in the barbican-api.conf is the correct way to configure the plugin. In my previous debugging experience, I've found that I get CryptoPluginNotFound if an error occurred during the plugin's __init__ method. For the KMIP plugin, this means the key file permissions were not set to 400 or the PyKMIP KMIPProxy object could not be created with the configuration options set. To debug this further, we'll need to log at the logs for more clues. Hope this helps! Kaitlin Farr Johns Hopkins University Applied Physics Laboratory -- Date: Mon, 23 Mar 2015 16:56:43 +0530 From: Utkarsh Simha utkarshsi...@gmail.com To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [barbican] Using KMIP with Barbican Message-ID: CAHYfr2UcytKpNRrzsv+-jkkVmxEwz=rhcs2ybuj3bgmu8vd...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Hello! I was wondering how it is possible to use an external Key Management Server with Barbican? I have configured the barbican-api.conf file for the KMIP Plugin and also set enabled_crypto_plugins to kmip_plugin, but it says CryptoPluginNotFound Any help is appreciated! Thank you :) -- 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
[openstack-dev] [Openstack-operators] [Neutron] allow_overlapping_ips (was: Deprecating the use_namespaces option ...)
Yesterday, I got looking at another option that I had completely forgotten about. It is allow_overlapping_ips, set in neutron.conf and defaults to False. It appears that when it is False, Neutron doesn't allow any overlapping IPs throughout the deployment, across all networks. My guess is that the vast majority of deployments will set this to True as a matter of course. My suspicion is that this option is related to the use_namespaces option because if namespaces are not used, then isolating routing domains would not be possible on the network node. However, there may be other reasons for needing this option. I'm not yet proposing this option be deprecated. I'm asking for feedback from operators and others who might be using the default value of False. Carl On Tue, Mar 24, 2015 at 1:21 PM, Assaf Muller amul...@redhat.com wrote: Note that https://review.openstack.org/#/c/166888/ has been merged. This means that the option has been deprecated for K and will be removed in L. Anyone using the non-default value of False will be looking at errors in his logs. - Original Message - On 3/23/2015 3:56 AM, Miguel Ángel Ajo wrote: I see you point Van, In the other hand, removing it, cleans up lot of conditional code parts (moving parts at the other side), and also the non-netns case is not tested by upstream CI, AFAIK, so it could be broken anytime and we would not notice it. Miguel Ángel Ajo On Monday, 23 de March de 2015 at 9:25, Van Leeuwen, Robert wrote: I think there are valid reasons to not use namespaces: * Fewer moving parts == less can potentialy fail * Troubleshooting is easier due to less places to look / need no familiarity with namespaces tools * If I remember correctly setting up a namespace can get really slow when you have a lot of them on a single machine IMHO, those shouldn’t be valid reasons anymore, since they were due iproute, or sudo issues that have been corrected long ago, and all distros installing neutron are supporting netns at this Well, you exactly made my point: There is lots that can and will go wrong with more moving parts. That they are fixed at the moment does not mean that there will not be a new bug in the future… Cheers, Robert van Leeuwen ___ OpenStack-operators mailing list openstack-operat...@lists.openstack.org mailto:openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators __ 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 FWIW we were doing CI without namespaces before Kilo simply due to RHEL 6.5 not having the support w/o a kernel patch. Since Kilo dropped py26 support we moved to RHEL 7* for py27 and that has namespace support so it's no longer an issue for us. -- Thanks, Matt Riedemann __ 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] [os-ansible-deployment] Nominating Nolan Brubaker for core team
Great proposal, Nolan will be an asset to the core team. +1 -- Hugh Saunders On 25 March 2015 at 15:24, Kevin Carter kevin.car...@rackspace.com wrote: Greetings, I would like to nominate Nolan Brubaker (palendae on IRC) for the os-ansible-deployment-core team. Nolan has been involved with the project for the last few months and has been an active reviewer with solid reviews. IMHO, I think he is ready to receive core powers on the repository. References: [ https://review.openstack.org/#/q/project:stackforge/os-ansible-deployment+reviewer:%22nolan+brubaker%253Cnolan.brubaker%2540rackspace.com%253E%22,n,z ] Please respond with +1/-1s or any other concerns. As a reminder, we are using the voting process outlined at [ https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess ] to add members to our core team. — Kevin Carter __ 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] CI report formatting (citrix / hyperv / vmware )
On 03/25/2015 11:18 AM, Jordan Pittier wrote: On Wed, Mar 25, 2015 at 2:44 PM, Salvatore Orlando sorla...@nicira.com wrote: On 25 March 2015 at 14:21, Sean Dague s...@dague.net wrote: On 03/25/2015 09:03 AM, Gary Kotton wrote: From: Jordan Pittier jordan.pitt...@scality.com mailto:jordan.pitt...@scality.com Reply-To: OpenStack List openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: Wednesday, March 25, 2015 at 1:47 PM To: OpenStack List openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware ) Hi On Wed, Mar 25, 2015 at 12:39 PM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: Currently Citrix, HyperV, and VMWare CI systems reporting on Nova patches have a different formatting than the standard that Jenkins and other systems are using: * test-name-no-spaces http://link.to/result https://urldefense.proofpoint.com/v2/url?u=http-3A__link.to_resultd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiEs=5SS-txUrD3o8KS3QIaCL3XMBbeCYK5CjmzmuxDda7Oce= : [SUCCESS|FAILURE] some comment about the test I don't want to talk for Citrix, HyperV or VMWare but the standard only work if you use Zuul in your CI. I am using a setup based on a Jenkins plugin called gerrit-trigger and there's no way to format the message the way it's expected... FWIW I help maintain one the VMware CIs (the one voting on neutron and network-related patches for devstack and tempest). We use gerrit-trigger too (mostly out of lazyness, no other real reason), but we're able to format the message posted back to gerrit. For posting back votes we use the gerrit review command to post the message in the standard format. Ok. I managed to find a way. It's possible. For future reference, on the job configuration, there's a field called URL to post. The correct value is literally * $JOB_NAME $BUILD_URL. Sorry for the noise guys. I can't find myself an excuse not to report results in the expected format anymore. Thank you, Jordan. Are you able to update the documentation consumed by third party folk using the Jenkins Gerrit trigger plugin? http://ci.openstack.org/third_party.html#the-jenkins-gerrit-trigger-plugin-way http://git.openstack.org/cgit/openstack-infra/system-config/tree/doc/source/third_party.rst#n212 Since I seem to be the only one doing anything by way of turning systems off and having them turned back on again, I would really be grateful in future of any conversation that doesn't include adding more responsibilities to my list. I'm understanding of the reasoning that unless threatened with being disabled most systems won't take any conversation about their behaviour seriously but I really am at my limit of what I can accomplish here. My list is very heavy as it is, I'm not in favour of adding more to it. Thanks for taking my perspective into consideration, Anita. I think the same process is adopted also by the CI voting on nova. However, the job result string is not being posted. I will double check with the respective owners. Salvatore This means these systems don't show up in the CI rollup block - http://dl.dropbox.com/u/6514884/screenshot_158.png https://urldefense.proofpoint.com/v2/url?u=http-3A__dl.dropbox.com_u_6514884_screenshot-5F158.pngd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiEs=nIjYwznh1_8aVBSz-XVEJrpNaMsDfqyekOQ2IhiHTo8e= Current the Vmware CI will vote +1 iff the patch has passed on the CI. We can investigate adding this to the CI rollup block. I'd really like that to change. The CI rollup block has been extremely useful in getting the test results of a patch above the fold, and the ability to dig into them clearly. I feel like if any CI system isn't reporting in standard format that's parsible by that, we should probably turn it off. I do not think that we should turn this off. They have value. It would be nice if things were all of the same format, which I guess that this is the intension of the mail. Lets all try and make an effort to work towards this goal. Right, honestly, I don't want these turned off, I want them reporting in a more standard format. But I do think if they don't report in a standard format it will cause problems and add to them being ignored. -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-dev] [cinder]Driver broken
Hi, Just reported an issue: https://bugs.launchpad.net/cinder/+bug/1436367 Seems to be related to https://review.openstack.org/#/c/85847/ which introduced another parameter to be passed to the driver, but our driver didn't get updated so detach_volume fails for us. How can we get this fixed asap? Thanks, Eduard __ 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] CI report formatting (citrix / hyperv / vmware )
On Wed, Mar 25, 2015 at 2:44 PM, Salvatore Orlando sorla...@nicira.com wrote: On 25 March 2015 at 14:21, Sean Dague s...@dague.net wrote: On 03/25/2015 09:03 AM, Gary Kotton wrote: From: Jordan Pittier jordan.pitt...@scality.com mailto:jordan.pitt...@scality.com Reply-To: OpenStack List openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: Wednesday, March 25, 2015 at 1:47 PM To: OpenStack List openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware ) Hi On Wed, Mar 25, 2015 at 12:39 PM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: Currently Citrix, HyperV, and VMWare CI systems reporting on Nova patches have a different formatting than the standard that Jenkins and other systems are using: * test-name-no-spaces http://link.to/result https://urldefense.proofpoint.com/v2/url?u=http-3A__link.to_resultd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiEs=5SS-txUrD3o8KS3QIaCL3XMBbeCYK5CjmzmuxDda7Oce= : [SUCCESS|FAILURE] some comment about the test I don't want to talk for Citrix, HyperV or VMWare but the standard only work if you use Zuul in your CI. I am using a setup based on a Jenkins plugin called gerrit-trigger and there's no way to format the message the way it's expected... FWIW I help maintain one the VMware CIs (the one voting on neutron and network-related patches for devstack and tempest). We use gerrit-trigger too (mostly out of lazyness, no other real reason), but we're able to format the message posted back to gerrit. For posting back votes we use the gerrit review command to post the message in the standard format. Ok. I managed to find a way. It's possible. For future reference, on the job configuration, there's a field called URL to post. The correct value is literally * $JOB_NAME $BUILD_URL. Sorry for the noise guys. I can't find myself an excuse not to report results in the expected format anymore. I think the same process is adopted also by the CI voting on nova. However, the job result string is not being posted. I will double check with the respective owners. Salvatore This means these systems don't show up in the CI rollup block - http://dl.dropbox.com/u/6514884/screenshot_158.png https://urldefense.proofpoint.com/v2/url?u=http-3A__dl.dropbox.com_u_6514884_screenshot-5F158.pngd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=EtHYlIXfK33bYsGf2k8XbFtgWlkcm_VdZCrFHTLEdiEs=nIjYwznh1_8aVBSz-XVEJrpNaMsDfqyekOQ2IhiHTo8e= Current the Vmware CI will vote +1 iff the patch has passed on the CI. We can investigate adding this to the CI rollup block. I'd really like that to change. The CI rollup block has been extremely useful in getting the test results of a patch above the fold, and the ability to dig into them clearly. I feel like if any CI system isn't reporting in standard format that's parsible by that, we should probably turn it off. I do not think that we should turn this off. They have value. It would be nice if things were all of the same format, which I guess that this is the intension of the mail. Lets all try and make an effort to work towards this goal. Right, honestly, I don't want these turned off, I want them reporting in a more standard format. But I do think if they don't report in a standard format it will cause problems and add to them being ignored. -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 __ 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-operators] [Neutron] allow_overlapping_ips (was: Deprecating the use_namespaces option ...)
This is a nice option for smaller deployments that didn't need the complexity of NAT. From a custom L3 plugin perspective, it also eliminated any single points of failure pretty easily since no NAT state had to be distributed. However, it was difficult to use with tenant self-service since one tenant could create a subnet that ate up the whole routing space. It basically required that the networking was done by an admin or that the entire deployment was shared by a group of users trusted to do the right thing. My main interest in the IPAM work was to support fully routable deployments like this. Once IPAM has a workflow that covers tenant subnet allocation from a subnet pool shared by the whole deployment, I think deprecation of the allow_overlapping_ips option makes perfect sense since the operator can just create a single global subnet pool to simulate it. On Wed, Mar 25, 2015 at 8:29 AM, Carl Baldwin c...@ecbaldwin.net wrote: Yesterday, I got looking at another option that I had completely forgotten about. It is allow_overlapping_ips, set in neutron.conf and defaults to False. It appears that when it is False, Neutron doesn't allow any overlapping IPs throughout the deployment, across all networks. My guess is that the vast majority of deployments will set this to True as a matter of course. My suspicion is that this option is related to the use_namespaces option because if namespaces are not used, then isolating routing domains would not be possible on the network node. However, there may be other reasons for needing this option. I'm not yet proposing this option be deprecated. I'm asking for feedback from operators and others who might be using the default value of False. Carl On Tue, Mar 24, 2015 at 1:21 PM, Assaf Muller amul...@redhat.com wrote: Note that https://review.openstack.org/#/c/166888/ has been merged. This means that the option has been deprecated for K and will be removed in L. Anyone using the non-default value of False will be looking at errors in his logs. - Original Message - On 3/23/2015 3:56 AM, Miguel Ángel Ajo wrote: I see you point Van, In the other hand, removing it, cleans up lot of conditional code parts (moving parts at the other side), and also the non-netns case is not tested by upstream CI, AFAIK, so it could be broken anytime and we would not notice it. Miguel Ángel Ajo On Monday, 23 de March de 2015 at 9:25, Van Leeuwen, Robert wrote: I think there are valid reasons to not use namespaces: * Fewer moving parts == less can potentialy fail * Troubleshooting is easier due to less places to look / need no familiarity with namespaces tools * If I remember correctly setting up a namespace can get really slow when you have a lot of them on a single machine IMHO, those shouldn’t be valid reasons anymore, since they were due iproute, or sudo issues that have been corrected long ago, and all distros installing neutron are supporting netns at this Well, you exactly made my point: There is lots that can and will go wrong with more moving parts. That they are fixed at the moment does not mean that there will not be a new bug in the future… Cheers, Robert van Leeuwen ___ OpenStack-operators mailing list openstack-operat...@lists.openstack.org mailto:openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators __ 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 FWIW we were doing CI without namespaces before Kilo simply due to RHEL 6.5 not having the support w/o a kernel patch. Since Kilo dropped py26 support we moved to RHEL 7* for py27 and that has namespace support so it's no longer an issue for us. -- Thanks, Matt Riedemann __ 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
Re: [openstack-dev] Beyond IRC (was Re: Cinder Third-Party CI: what next?)
On 03/25/2015 12:14 PM, Kevin L. Mitchell wrote: On Tue, 2015-03-24 at 21:21 -0400, Doug Hellmann wrote: ·A separate mailing list for project review requests I'm skeptical about this being effective: just another source of incoming email that needs to be filtered out (at which point a mailman topic would have the same effect). Yes, email notifications scale poorly for really active reviewers. Between gerrit and launchpad, there is already a lot of notification email being filtered out of inboxes. I actually do rely on email notifications for review duties. I use filtering that moves the messages into dedicated folders per repository, and I use threading in those folders. When I see a review merge (or when I see it abandoned), I select the whole thread and delete it; otherwise I follow changes made to a review and determine whether I need to re-review it based on whether votes to that point have been +'s or -'s. I even subscribe to a couple of projects and check out new reviews submitted there. This is actually partly to blame for me being such a prolific reviewer in nova and novaclient :) One thing I have learned from my experiences at many mid-cycles is there is no one size fits all review workflow. I'm glad email works for you. Others don't read a single email gerrit emits. So advising someone that their review would get more attention by using email is not necessarily true. I would get attention from a portion of reviewers and would be totally ignored by others. Projects are all different in their workflows and this includes their review workflows. To understand how any given project prioritizes reviews one must attend the project weekly meeting, participate in discussions, ask questions, listen and follow advice given. All projects genuinely want to help developers succeed. Folks pay more attention to those wanting to participate when they take the trouble to find out what currently exists. Thanks Kevin, Anita. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [openstack][Mistral] DSL improvements - certain and incubating
Folks, we are discussing DSL improvements, based on Mistral field use and lessons learned. Please join: comment on the document welcome, extra ideas, preferably based on your experience writing Mistral workflows. The summary is in the doc, it contains two sections: 1) certain improvements, which we have complete clarity, agreed, and just need to do 2) incubating: ideas with more or less clear use case, where we however do not have a certain, agreed solution. https://docs.google.com/a/stackstorm.com/document/d/1Gy6V9YBt8W4llyErO_itHetkF1oNYv4ka-_5LdFKA18/edit Regards, Dmitri. __ 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]Driver broken
This is a real defect related to the multiattach patch that I worked on. I have posted a fix for your driver. https://review.openstack.org/#/c/167683/ Walt Hi, Just reported an issue: https://bugs.launchpad.net/cinder/+bug/1436367 Seems to be related to https://review.openstack.org/#/c/85847/ which introduced another parameter to be passed to the driver, but our driver didn't get updated so detach_volume fails for us. How can we get this fixed asap? Thanks, Eduard __ 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]Driver broken
Thanks, Indeed, our CI doesn't test this code path, we focused mainly on our internal functionality tests (which don't test for this), and the tempest tests are not running. This will be fixed asap. Thanks everyone, Eduard __ 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-operators] [Neutron] allow_overlapping_ips
Kevin Benton blak...@gmail.com writes: This is a nice option for smaller deployments that didn't need the complexity of NAT. From a custom L3 plugin perspective, it also eliminated any single points of failure pretty easily since no NAT state had to be distributed. However, it was difficult to use with tenant self-service since one tenant could create a subnet that ate up the whole routing space. It basically required that the networking was done by an admin or that the entire deployment was shared by a group of users trusted to do the right thing. My main interest in the IPAM work was to support fully routable deployments like this. Once IPAM has a workflow that covers tenant subnet allocation from a subnet pool shared by the whole deployment, I think deprecation of the allow_overlapping_ips option makes perfect sense since the operator can just create a single global subnet pool to simulate it. I'm not defending allow_overlapping_ips, but I'm afraid I don't understand your point. In the future where IPAM has a workflow that covers tenant subnet allocation from a subnet pool shared by the whole deployment and the operator [creates] a single global subnet pool, what will prevent a tenant from allocating a very large subnet of that address space? Thanks, Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers
Hi Dani, the Horizon integration is pretty simple to set up manually for the standalone install. You'd need to copy some files from your congress directory to your horizon one. Set these two environment variables: $ CONGRESS_HORIZON_DIR=/path/to/congress/contrib/horizon $ HORIZON_DIR=/path/to/horizon Then run the cp commands from function _congress_setup_horizon on lines 271 through 276 here, inclusive: https://github.com/stackforge/congress/blob/master/contrib/devstack/lib/con gress#L271 And then restart the Apache server. You should now see a Policy section under the Admin dashboard. As Tim mentioned, the data is currently view-only in Horizon. I'll be in the Congress IRC channel (#congress) later if you have questions. -Original Message- From: Tim Hinrichs thinri...@vmware.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Wednesday, March 25, 2015 at 8:08 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Congress] Info on Currently Supported DataDrivers Hi Dani, We do have an interface in Horizon that you¹ll get if you install via devstack (except that you can¹t create rules quite yet‹that¹s under active development). If you install it standalone, you won¹t get the Horizon interface, but you can still use the CLI or the restful API. Let us know if you want help getting it setup. And if you hit any bumps, we¹d love to hear about them so we can smooth them out. Tim On Mar 25, 2015, at 3:28 AM, Daniel Comnea comnea.d...@gmail.com wrote: This project looks very interesting and i might give it a go by installing standalone. I have a question though: are there any plans to expose the current output as part of Horizon or any other UI ? Thx, Dani On Wed, Mar 25, 2015 at 5:15 AM, Zhou, Zhenzan zhenzan.z...@intel.com wrote: Just found it has been supported, e.g. openstack congress driver schema show ceilometer So here is the way to check data source drivers: For supported data source drivers: 1. openstack congress driver list 2. openstack congress driver schema show ds-name For enabled data source drivers: 1. openstack congress datasource list 2. openstack congress datasource schema show ds-name BR Zhou Zhenzan From: Zhou, Zhenzan [mailto:zhenzan.z...@intel.com] Sent: Wednesday, March 25, 2015 12:24 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers Hi, The Œdriver list¹ sub command could provide supported data source drivers, but we cannot show its schema if it¹s NOT LOADED. So we still have to check the code for the schema. My point is that we could support show schemas for any supported data source drivers, even it¹s not loaded. zhenzan@zhenzan-openstack:~$ openstack congress driver list ++ --+ | id | description | ++ --+ | ceilometer | Datasource driver that interfaces with ceilometer. | | plexxi | Datasource driver that interfaces with PlexxiCore. | | swift | Datasource driver that interfaces with swift. | | neutronv2 | Datasource driver that interfaces with OpenStack Networking aka Neutron. | | nova | Datasource driver that interfaces with OpenStack Compute aka nova. | | murano | Datasource driver that interfaces with murano | | keystone | Datasource driver that interfaces with keystone. | | cloudfoundryv2 | Datasource driver that interfaces with cloudfoundry | | ironic | Datasource driver that interfaces with OpenStack bare metal aka ironic. | | cinder | Datasource driver that interfaces with OpenStack cinder. | | vcenter| Datasource driver that interfaces with vcenter | | glancev2 | Datasource driver that interfaces with OpenStack Images aka Glance. | ++ --+ zhenzan@zhenzan-openstack:~$ openstack congress datasource schema show ceilometer ERROR: openstack Resource ceilometer not found (HTTP 404) BR Zhou Zhenzan From: Pierre-Emmanuel Ettori [mailto:pe.ett...@gmail.com] Sent: Wednesday, March 25, 2015 11:54 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers Hi Zhenzan, Actually I believe the command that Tim is looking for is: openstack congress datasource list Please let us know if you are running into any issue. Thanks Pierre On Tue, Mar
Re: [openstack-dev] [Openstack-operators] [Neutron] allow_overlapping_ips
Yes, sorry I should have specified that. Salvatore is right that this depends on the quota mechanism to prevent them from exhausting the entire pool. On Wed, Mar 25, 2015 at 10:09 AM, Neil Jerram neil.jer...@metaswitch.com wrote: Salvatore Orlando sorla...@nicira.com writes: On 25 March 2015 at 17:36, Neil Jerram neil.jer...@metaswitch.com wrote: Kevin Benton blak...@gmail.com writes: This is a nice option for smaller deployments that didn't need the complexity of NAT. From a custom L3 plugin perspective, it also eliminated any single points of failure pretty easily since no NAT state had to be distributed. However, it was difficult to use with tenant self-service since one tenant could create a subnet that ate up the whole routing space. It basically required that the networking was done by an admin or that the entire deployment was shared by a group of users trusted to do the right thing. My main interest in the IPAM work was to support fully routable deployments like this. Once IPAM has a workflow that covers tenant subnet allocation from a subnet pool shared by the whole deployment, I think deprecation of the allow_overlapping_ips option makes perfect sense since the operator can just create a single global subnet pool to simulate it. I'm not defending allow_overlapping_ips, but I'm afraid I don't understand your point. In the future where IPAM has a workflow that covers tenant subnet allocation from a subnet pool shared by the whole deployment and the operator [creates] a single global subnet pool, what will prevent a tenant from allocating a very large subnet of that address space? For this specific item - shared subnet pools come with a quota mechanism, which ensure each tenant won't get more than a given share of the pool. This mechanism is still under review [1], we hope to be able to complete the review for the Kilo release. [1] https://review.openstack.org/#/c/165264/ Ah, so the new allocation_quota is an important factor here too. Many thanks for explaining that! Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Group Based Policy project proposal
Hi All, The GBP PTL elections [1] were completed earlier, hence we have removed the GBP project proposal [2] from WIP (originally posted on March 5th). We would request the TC to take note and consider this proposal during the next meeting. The team will be happy to answer questions and provide more information via ML, and/or IRC on the #openstack-gbp channel. Thanks, ~Sumit, IRC: SumitNaiksatam (on behalf of GBP-team). [1] http://lists.openstack.org/pipermail/openstack-dev/2015-March/059317.html [2] https://review.openstack.org/#/c/161902 On Thu, Mar 5, 2015 at 11:11 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Hi All, The OpenStack Group Based Policy team of contributors has submitted a proposal [1] to add “Group Based Policy” as a project in the OpenStack namespace in accordance with the new governance changes [2]. We would request the TC to take note and consider this proposal during the next meeting. The team will be happy to answer questions and provide more information via ML, and/or IRC on the #openstack-gbp channel. Thanks, ~Sumit, IRC: SumitNaiksatam (on behalf of GBP-team). [1] https://review.openstack.org/#/c/161902 [2] http://governance.openstack.org/reference/new-projects-requirements.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
Re: [openstack-dev] [Openstack-operators] [Neutron] allow_overlapping_ips (was: Deprecating the use_namespaces option ...)
Kevin, Thank you for your valuable insight here. Comments inline... On Wed, Mar 25, 2015 at 10:09 AM, Kevin Benton blak...@gmail.com wrote: This is a nice option for smaller deployments that didn't need the complexity of NAT. From a custom L3 plugin perspective, it also eliminated any single points of failure pretty easily since no NAT state had to be distributed. Good to know. However, it was difficult to use with tenant self-service since one tenant could create a subnet that ate up the whole routing space. It basically required that the networking was done by an admin or that the entire deployment was shared by a group of users trusted to do the right thing. Sounds like subnet allocation with the associated quota mechanism would fit the bill here. In fact, subnet pools were designed with exactly this kind deployment in mind. Especially for ipv6. My main interest in the IPAM work was to support fully routable deployments like this. Once IPAM has a workflow that covers tenant subnet allocation from a subnet pool shared by the whole deployment, I think deprecation of the allow_overlapping_ips option makes perfect sense since the operator can just create a single global subnet pool to simulate it. This is exactly where I was thinking of going with this. I think Ryan is going to -- or has already -- made subnet pools mutually exclusive with the allow_overlapping_ips=False because I didn't even want to think about making the two modes interoperable. It sounds like that might be an acceptable thing to do given this feedback. Carl __ 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-operators] [Neutron] allow_overlapping_ips
On 25 March 2015 at 17:36, Neil Jerram neil.jer...@metaswitch.com wrote: Kevin Benton blak...@gmail.com writes: This is a nice option for smaller deployments that didn't need the complexity of NAT. From a custom L3 plugin perspective, it also eliminated any single points of failure pretty easily since no NAT state had to be distributed. However, it was difficult to use with tenant self-service since one tenant could create a subnet that ate up the whole routing space. It basically required that the networking was done by an admin or that the entire deployment was shared by a group of users trusted to do the right thing. My main interest in the IPAM work was to support fully routable deployments like this. Once IPAM has a workflow that covers tenant subnet allocation from a subnet pool shared by the whole deployment, I think deprecation of the allow_overlapping_ips option makes perfect sense since the operator can just create a single global subnet pool to simulate it. I'm not defending allow_overlapping_ips, but I'm afraid I don't understand your point. In the future where IPAM has a workflow that covers tenant subnet allocation from a subnet pool shared by the whole deployment and the operator [creates] a single global subnet pool, what will prevent a tenant from allocating a very large subnet of that address space? For this specific item - shared subnet pools come with a quota mechanism, which ensure each tenant won't get more than a given share of the pool. This mechanism is still under review [1], we hope to be able to complete the review for the Kilo release. [1] https://review.openstack.org/#/c/165264/ Thanks, Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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-operators] [Neutron] allow_overlapping_ips
Salvatore Orlando sorla...@nicira.com writes: On 25 March 2015 at 17:36, Neil Jerram neil.jer...@metaswitch.com wrote: Kevin Benton blak...@gmail.com writes: This is a nice option for smaller deployments that didn't need the complexity of NAT. From a custom L3 plugin perspective, it also eliminated any single points of failure pretty easily since no NAT state had to be distributed. However, it was difficult to use with tenant self-service since one tenant could create a subnet that ate up the whole routing space. It basically required that the networking was done by an admin or that the entire deployment was shared by a group of users trusted to do the right thing. My main interest in the IPAM work was to support fully routable deployments like this. Once IPAM has a workflow that covers tenant subnet allocation from a subnet pool shared by the whole deployment, I think deprecation of the allow_overlapping_ips option makes perfect sense since the operator can just create a single global subnet pool to simulate it. I'm not defending allow_overlapping_ips, but I'm afraid I don't understand your point. In the future where IPAM has a workflow that covers tenant subnet allocation from a subnet pool shared by the whole deployment and the operator [creates] a single global subnet pool, what will prevent a tenant from allocating a very large subnet of that address space? For this specific item - shared subnet pools come with a quota mechanism, which ensure each tenant won't get more than a given share of the pool. This mechanism is still under review [1], we hope to be able to complete the review for the Kilo release. [1] https://review.openstack.org/#/c/165264/ Ah, so the new allocation_quota is an important factor here too. Many thanks for explaining that! Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [Neutron] allow_overlapping_ips (was: Deprecating the use_namespaces option ...)
The allow_overlapping_ips configuration option in it's current form was mainly used to cover older distros that did not support namespaces as you have mentioned. That's why in its current form this option operates across all networks of all tenants. That is, if the option is set to false, overlapping IPs are not allowed even across tenants. If the option is to be redefined/reimplemented/interpreted as allowing or disallowing overlapping IPs within the scope of a single tenant, then I think that would be useful to some. Mohammad From: Carl Baldwin c...@ecbaldwin.net To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 03/25/2015 11:37 AM Subject:[openstack-dev] [Openstack-operators] [Neutron] allow_overlapping_ips (was: Deprecating the use_namespaces option ...) Yesterday, I got looking at another option that I had completely forgotten about. It is allow_overlapping_ips, set in neutron.conf and defaults to False. It appears that when it is False, Neutron doesn't allow any overlapping IPs throughout the deployment, across all networks. My guess is that the vast majority of deployments will set this to True as a matter of course. My suspicion is that this option is related to the use_namespaces option because if namespaces are not used, then isolating routing domains would not be possible on the network node. However, there may be other reasons for needing this option. I'm not yet proposing this option be deprecated. I'm asking for feedback from operators and others who might be using the default value of False. Carl On Tue, Mar 24, 2015 at 1:21 PM, Assaf Muller amul...@redhat.com wrote: Note that https://review.openstack.org/#/c/166888/ has been merged. This means that the option has been deprecated for K and will be removed in L. Anyone using the non-default value of False will be looking at errors in his logs. - Original Message - On 3/23/2015 3:56 AM, Miguel Ángel Ajo wrote: I see you point Van, In the other hand, removing it, cleans up lot of conditional code parts (moving parts at the other side), and also the non-netns case is not tested by upstream CI, AFAIK, so it could be broken anytime and we would not notice it. Miguel Ángel Ajo On Monday, 23 de March de 2015 at 9:25, Van Leeuwen, Robert wrote: I think there are valid reasons to not use namespaces: * Fewer moving parts == less can potentialy fail * Troubleshooting is easier due to less places to look / need no familiarity with namespaces tools * If I remember correctly setting up a namespace can get really slow when you have a lot of them on a single machine IMHO, those shouldn’t be valid reasons anymore, since they were due iproute, or sudo issues that have been corrected long ago, and all distros installing neutron are supporting netns at this Well, you exactly made my point: There is lots that can and will go wrong with more moving parts. That they are fixed at the moment does not mean that there will not be a new bug in the future… Cheers, Robert van Leeuwen ___ OpenStack-operators mailing list openstack-operat...@lists.openstack.org mailto:openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators __ 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 FWIW we were doing CI without namespaces before Kilo simply due to RHEL 6.5 not having the support w/o a kernel patch. Since Kilo dropped py26 support we moved to RHEL 7* for py27 and that has namespace support so it's no longer an issue for us. -- Thanks, Matt Riedemann __ 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
Re: [openstack-dev] [Openstack] Cinder-service connectivity issues
Based on the checkin times in your post, it looks like time is out of sync between your nodes. The one reporting down is reporting time in the future. I would install ntp and make sure the clocks are in sync. Vish On Mar 25, 2015, at 2:33 AM, Kamsali, RaghavendraChari (Artesyn) raghavendrachari.kams...@artesyn.com wrote: Please find attachment log (c-api) , when I execute command cinder create 1. From: Kamsali, RaghavendraChari (Artesyn) [mailto:raghavendrachari.kams...@artesyn.com] Sent: Wednesday, March 25, 2015 1:39 PM To: Ritesh Nanda Cc: openstack-dev@lists.openstack.org; openst...@lists.openstack.org Subject: Re: [Openstack] Cinder-service connectivity issues FYI, From: Ritesh Nanda [mailto:riteshnand...@gmail.com] Sent: Wednesday, March 25, 2015 1:09 PM To: Kamsali, RaghavendraChari [ENGINEERING/IN] Cc: openst...@lists.openstack.org; openstack-dev@lists.openstack.org Subject: Re: [Openstack] Cinder-service connectivity issues Can you run cinder-scheduler , volume service in debug mode and paste the logs. Regards, Ritesh On Wed, Mar 25, 2015 at 12:10 AM, Kamsali, RaghavendraChari (Artesyn) raghavendrachari.kams...@artesyn.com wrote: Hi, My setup is shown below having three networks (management, storage, data/virtual) . image001.png Am facing issue when I bring up the setup as shown above scenario , could anyone help me to figure out did I configured incorrectly or doing anything wrong . On Controller Node SERVICES ENABLED: (c-sch,c-api) Management- 192.168.21.108 Storage- 10.130.98.97 Cinder_configarations : my_ip : 10.130.98.97 (also tried 19.2168.21.108) glance_host:10.130.98.97 (also tried 192.168.21.108) iscsi_ip_address: 10.130.98.97 (also tried 192.168.21.108) image002.jpg image003.jpg On Storage Node SERVICES ENABLED: (c-vol) Management - 192.1689.21.107 Stroage - 10.130.98.136 my_ip : 10.130.98.97 (also tried 19.2168.21.108) glance_host:10.130.98.97 (also tried 192.168.21.108) iscsi_ip_address: 10.130.98.97 (also tried 192.168.21.108) lvmdriver-1.iscsi_ip_address : 10.130.98.136 (also tried 192.168.21.107) image004.jpg Thanks and Regards, Raghavendrachari kamsali | Software Engineer II | Embedded Computing Artesyn Embedded Technologies | 5th Floor, Capella Block, The V, Madhapur| Hyderabad, AP 500081 India ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -- With Regards Ritesh Nanda cinder-create-1.txt__ 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] [Murano] python-muranoclient 0.5.6 released
Today we released python-muranoclient 0.5.6 [1], this release includes fixes for 8 bugs, including 5 high bugs. This version also includes support for number of a new features introduced in Kilo: * Murano Repository (blueprint [2], spec [3]) * Environment Template Catalog (blueprint [4], spec [5]) * Category Management (blueprint [4], spec [5]) Changes to increase number of python-muranoclient in requirements.txt are proposed: * murano: https://review.openstack.org/167583 * murano-dashboard: https://review.openstack.org/167580 Unfortunately not all PyPI mirrors on OpenStack infrastructure are synced with official PyPI mirrors, once they will be synced jobs will become green and change-requests ready to merge. References: [1] https://launchpad.net/python-muranoclient/kilo/0.5.6 [2] https://blueprints.launchpad.net/murano/+spec/muranoclient-marketplace-support [3] https://review.openstack.org/161471 [4] https://blueprints.launchpad.net/murano/+spec/environment-template [5] http://murano-specs.readthedocs.org/en/latest/specs/kilo/blueprint-template.html [6] https://blueprints.launchpad.net/murano/+spec/enable-category-management [7] https://review.openstack.org/139630 -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.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-dev] Barbican : Unable to install Barbican on CentOS due to Import Error
Hi , When I tried installing barbican using the command bin/barbican.sh install , I got the following error : *ImportError: No module named pecan* Traceback (most recent call last): File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 247, in loadapp return loadobj(APP, uri, name=name, **kw) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 272, in loadobj return context.create() File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 710, in create return self.object_type.invoke(self) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 144, in invoke **context.local_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/util.py, line 55, in fix_call val = callable(*args, **kw) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/urlmap.py, line 25, in urlmap_factory app = loader.get_app(app_name, global_conf=global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 350, in get_app name=name, global_conf=global_conf).create() File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 362, in app_context APP, name=name, global_conf=global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 450, in get_context global_additions=global_additions) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 559, in _pipeline_app_context APP, pipeline[-1], global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 458, in get_context section) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 517, in _context_from_explicit value = import_string(found_expr) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 22, in import_string return pkg_resources.EntryPoint.parse(x= + s).load(False) File build/bdist.linux-x86_64/egg/pkg_resources/__init__.py, line 2320, in load File build/bdist.linux-x86_64/egg/pkg_resources/__init__.py, line 2326, in resolve File /root/barbican/barbican/api/__init__.py, line 22, in module import pecan ImportError: No module named pecan OOPS ! failed loading app in worker 1 (pid 27606) :( trying again... worker respawning too fast !!! i have to sleep a bit (2 seconds)... OOPS ! failed loading app in worker 1 (pid 27607) :( trying again... worker respawning too fast !!! i have to sleep a bit (2 seconds)... Respawned uWSGI worker 1 (new pid: 27608) Respawned uWSGI worker 1 (new pid: 27609) Loading paste environment: config:/etc/barbican/barbican-api-paste.ini Loading paste environment: config:/etc/barbican/barbican-admin-paste.ini Traceback (most recent call last): File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 247, in loadapp return loadobj(APP, uri, name=name, **kw) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 271, in loadobj global_conf=global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 296, in loadcontext global_conf=global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 320, in _loadconfig return loader.get_context(object_type, name, global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 450, in get_context global_additions=global_additions) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 559, in _pipeline_app_context APP, pipeline[-1], global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 458, in get_context section) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 517, in _context_from_explicit value = import_string(found_expr) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 22, in import_string return pkg_resources.EntryPoint.parse(x= + s).load(False) Any help would be appreciated! Thanks in advance ! -- *Thanks and Regards,* *Asha Seshagiri* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Nominate Irina Povolotskaya for fuel-docs core
+1 On Wed, Mar 25, 2015 at 12:17 PM, Christopher Aedo ca...@mirantis.com wrote: +1 from me, this is a great suggestion. -Christopher On Wed, Mar 25, 2015 at 12:10 PM, Dmitry Borodaenko dborodae...@mirantis.com wrote: Fuelers, I'd like to nominate Irina Povolotskaya for the fuel-docs-core team. She has contributed thousands of lines of documentation to Fuel over the past several months, and has been a diligent reviewer: http://stackalytics.com/?user_id=ipovolotskayarelease=allproject_type=allmodule=fuel-docs I believe it's time to grant her core reviewer rights in the fuel-docs repository. Core reviewer approval process definition: https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess -- Dmitry Borodaenko __ 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 -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] Nominate Irina Povolotskaya for fuel-docs core
Fuelers, I'd like to nominate Irina Povolotskaya for the fuel-docs-core team. She has contributed thousands of lines of documentation to Fuel over the past several months, and has been a diligent reviewer: http://stackalytics.com/?user_id=ipovolotskayarelease=allproject_type=allmodule=fuel-docs I believe it's time to grant her core reviewer rights in the fuel-docs repository. Core reviewer approval process definition: https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess -- Dmitry Borodaenko __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Nominate Irina Povolotskaya for fuel-docs core
+1 from me, this is a great suggestion. -Christopher On Wed, Mar 25, 2015 at 12:10 PM, Dmitry Borodaenko dborodae...@mirantis.com wrote: Fuelers, I'd like to nominate Irina Povolotskaya for the fuel-docs-core team. She has contributed thousands of lines of documentation to Fuel over the past several months, and has been a diligent reviewer: http://stackalytics.com/?user_id=ipovolotskayarelease=allproject_type=allmodule=fuel-docs I believe it's time to grant her core reviewer rights in the fuel-docs repository. Core reviewer approval process definition: https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess -- Dmitry Borodaenko __ 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] [glance] image-create failed vcender backend
Hi,colleagues. I've faced with an issue https://bugs.launchpad.net/glance/+bug/1436034 during mos 6.0 with vcenter deployment for customer. could you help me do debug and fix issue. Thanks -- Sergiy Lystopad __ 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] Nominate Igor Malinovskiy for core team
On 18.03.2015 20:04, Ben Swartzlander wrote: Igor (u_glide on IRC) joined the Manila team back in December and has done a consistent amount of reviews and contributed significant new core features in the last 2-3 months. I would like to nominate him to join the Manila core reviewer team. +1 __ 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] [oslo] stable-maint for oslo.vmware
Excerpts from Vipin Balachandran's message of 2015-03-25 10:50:17 +: Doug, Please add me to the stable maintenance team for oslo.vmware. fungi created the oslo-vmware-stable-maint group (thanks!) and I've added oslo-stable-maint and Vipin to it so we can manage stable backports for oslo.vmware. Doug Thanks, Vipin -Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: Tuesday, March 24, 2015 2:08 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [oslo] stable-maint for oslo.vmware Gary pinged me on IRC earlier today and I missed him, so I’m sending this to the list in case someone else wants to volunteer. It sounds like there are some stable branch changes for oslo.vmware that need attention. Does someone on the oslo.vmware team want to volunteer to be on a stable-maintenance team for the library? 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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Nominate Irina Povolotskaya for fuel-docs core
+1 definately On 25 Mar 2015, at 20:10, Dmitry Borodaenko dborodae...@mirantis.com wrote: Fuelers, I'd like to nominate Irina Povolotskaya for the fuel-docs-core team. She has contributed thousands of lines of documentation to Fuel over the past several months, and has been a diligent reviewer: http://stackalytics.com/?user_id=ipovolotskayarelease=allproject_type=allmodule=fuel-docs I believe it's time to grant her core reviewer rights in the fuel-docs repository. Core reviewer approval process definition: https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess -- Dmitry Borodaenko __ 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 -- Tomasz 'Zen' Napierala Product Engineering - Poland __ 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]Reviews for #164308 - Expand valid server group name character set
On 3/25/2015 3:01 PM, Jennifer Mulsow wrote: Would anyone be willing to review https://review.openstack.org/#/c/164308/ (Expand valid server group name character set)? It has a few +1s, but there hasn't been any activity on it in a couple days. Thank you, Jennifer Mulsow Cloud Systems Software Development IBM Systems Technology Group __ 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 mailing list is not a place for requesting reviews, so please don't do it. There are many changes out there [1] so be patient. [1] http://russellbryant.net/openstack-stats/nova-openreviews.html -- Thanks, Matt Riedemann __ 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]Reviews for #164308 - Expand valid server group name character set
Would anyone be willing to review https://review.openstack.org/#/c/164308/ (Expand valid server group name character set)? It has a few +1s, but there hasn't been any activity on it in a couple days. Thank you, Jennifer Mulsow Cloud Systems Software Development IBM Systems Technology Group__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Nominate Irina Povolotskaya for fuel-docs core
+1 from me On Wed, Mar 25, 2015 at 12:35 PM, Mike Scherbakov mscherba...@mirantis.com wrote: +1 On Wed, Mar 25, 2015 at 12:17 PM, Christopher Aedo ca...@mirantis.com wrote: +1 from me, this is a great suggestion. -Christopher On Wed, Mar 25, 2015 at 12:10 PM, Dmitry Borodaenko dborodae...@mirantis.com wrote: Fuelers, I'd like to nominate Irina Povolotskaya for the fuel-docs-core team. She has contributed thousands of lines of documentation to Fuel over the past several months, and has been a diligent reviewer: http://stackalytics.com/?user_id=ipovolotskayarelease=allproject_type=allmodule=fuel-docs I believe it's time to grant her core reviewer rights in the fuel-docs repository. Core reviewer approval process definition: https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess -- Dmitry Borodaenko __ 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 -- Mike Scherbakov #mihgen __ 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] [Murano] Announcing Bug-Scrub Day on March 27
Hi folks, As we agreed on last community meeting we announce this Friday (March 27) as Bug-Scrub Day. This day would be dedicated for cleaning-up our bugs in launchpad [1]. By cleaning-up we mean triaging bugs and assigning them on the next milestone - kilo-rc1. We encourage you to join us in order to take and fix some bugs in Murano, help to identify verify issues, and correctly assign priorities. P.S. Bug-Scrub Day is 24h event, in order to span across the globe with all our contributors, but we expect to have most of the contributors in #murano channel on FreeNode starting from 9 am UTC. References: [1] https://bugs.launchpad.net/murano -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com +7 (495) 640-4904, 0261 +7 (903) 156-0836 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Nominate Irina Povolotskaya for fuel-docs core
+1 On Wed, Mar 25, 2015 at 8:10 PM, Dmitry Borodaenko dborodae...@mirantis.com wrote: Fuelers, I'd like to nominate Irina Povolotskaya for the fuel-docs-core team. She has contributed thousands of lines of documentation to Fuel over the past several months, and has been a diligent reviewer: http://stackalytics.com/?user_id=ipovolotskayarelease=allproject_type=allmodule=fuel-docs I believe it's time to grant her core reviewer rights in the fuel-docs repository. Core reviewer approval process definition: https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess -- Dmitry Borodaenko __ 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 -- Łukasz Oleś __ 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] [infra] What do people think of YAPF (like gofmt, for python)?
I am excited by the release of YAPF [1], a gofmt-like too for python. I think it has the potential to simplify style enforcement, and as much as I appreciate our current hacking checks, I’d be much happier not requiring developers to manually conform to them. Maybe we can consider automation in a manner similar to that employed by the go codereview tool [2]? Cheers, Maru 1: https://github.com/google/yapf 2: https://godoc.org/golang.org/x/review/git-codereview#hdr-Gofmt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Barbican : Unable to install Barbican on CentOS due to Import Error
Hi John, Thanks a lot for your response :) I followed the instructions from https://github.com/cloudkeep/barbican/wiki/Barbican-Quick-Start-Guide There were few packages that were missing .Please find the Additional steps below : - pip install pecan - will install pecan - pip install alembic - will install alembic - yum install openldap-devel - pip install python-ldap Thanks and Regards, Asha Seshagiri On Wed, Mar 25, 2015 at 5:17 PM, John Wood john.w...@rackspace.com wrote: Hello Asha, It seems like your installer script might be crashing for some reason. You might need to execute the steps in the installer script manually to stand things up, such as the pip install step here: https://github.com/openstack/barbican/blob/master/bin/barbican.sh#L87 Please let us know if that helps. Thanks, John From: Asha Seshagiri asha.seshag...@gmail.com Date: Wednesday, March 25, 2015 at 2:24 PM To: openstack-dev openstack-dev@lists.openstack.org Cc: John Wood john.w...@rackspace.com, Douglas Mendizabal douglas.mendiza...@rackspace.com, Reller, Nathan S. nathan.rel...@jhuapl.edu Subject: Barbican : Unable to install Barbican on CentOS due to Import Error Hi , When I tried installing barbican using the command bin/barbican.sh install , I got the following error : *ImportError: No module named pecan* Traceback (most recent call last): File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 247, in loadapp return loadobj(APP, uri, name=name, **kw) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 272, in loadobj return context.create() File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 710, in create return self.object_type.invoke(self) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 144, in invoke **context.local_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/util.py, line 55, in fix_call val = callable(*args, **kw) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/urlmap.py, line 25, in urlmap_factory app = loader.get_app(app_name, global_conf=global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 350, in get_app name=name, global_conf=global_conf).create() File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 362, in app_context APP, name=name, global_conf=global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 450, in get_context global_additions=global_additions) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 559, in _pipeline_app_context APP, pipeline[-1], global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 458, in get_context section) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 517, in _context_from_explicit value = import_string(found_expr) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 22, in import_string return pkg_resources.EntryPoint.parse(x= + s).load(False) File build/bdist.linux-x86_64/egg/pkg_resources/__init__.py, line 2320, in load File build/bdist.linux-x86_64/egg/pkg_resources/__init__.py, line 2326, in resolve File /root/barbican/barbican/api/__init__.py, line 22, in module import pecan ImportError: No module named pecan OOPS ! failed loading app in worker 1 (pid 27606) :( trying again... worker respawning too fast !!! i have to sleep a bit (2 seconds)... OOPS ! failed loading app in worker 1 (pid 27607) :( trying again... worker respawning too fast !!! i have to sleep a bit (2 seconds)... Respawned uWSGI worker 1 (new pid: 27608) Respawned uWSGI worker 1 (new pid: 27609) Loading paste environment: config:/etc/barbican/barbican-api-paste.ini Loading paste environment: config:/etc/barbican/barbican-admin-paste.ini Traceback (most recent call last): File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 247, in loadapp return loadobj(APP, uri, name=name, **kw) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 271, in loadobj global_conf=global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 296, in loadcontext global_conf=global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 320, in _loadconfig return loader.get_context(object_type, name, global_conf) File
Re: [openstack-dev] Barbican : Unable to install Barbican on CentOS due to Import Error
Hello Asha, It seems like your installer script might be crashing for some reason. You might need to execute the steps in the installer script manually to stand things up, such as the pip install step here: https://github.com/openstack/barbican/blob/master/bin/barbican.sh#L87 Please let us know if that helps. Thanks, John From: Asha Seshagiri asha.seshag...@gmail.commailto:asha.seshag...@gmail.com Date: Wednesday, March 25, 2015 at 2:24 PM To: openstack-dev openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: John Wood john.w...@rackspace.commailto:john.w...@rackspace.com, Douglas Mendizabal douglas.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com, Reller, Nathan S. nathan.rel...@jhuapl.edumailto:nathan.rel...@jhuapl.edu Subject: Barbican : Unable to install Barbican on CentOS due to Import Error Hi , When I tried installing barbican using the command bin/barbican.sh install , I got the following error : ImportError: No module named pecan Traceback (most recent call last): File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 247, in loadapp return loadobj(APP, uri, name=name, **kw) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 272, in loadobj return context.create() File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 710, in create return self.object_type.invoke(self) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 144, in invoke **context.local_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/util.py, line 55, in fix_call val = callable(*args, **kw) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/urlmap.py, line 25, in urlmap_factory app = loader.get_app(app_name, global_conf=global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 350, in get_app name=name, global_conf=global_conf).create() File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 362, in app_context APP, name=name, global_conf=global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 450, in get_context global_additions=global_additions) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 559, in _pipeline_app_context APP, pipeline[-1], global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 458, in get_context section) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 517, in _context_from_explicit value = import_string(found_expr) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 22, in import_string return pkg_resources.EntryPoint.parse(x= + s).load(False) File build/bdist.linux-x86_64/egg/pkg_resources/__init__.py, line 2320, in load File build/bdist.linux-x86_64/egg/pkg_resources/__init__.py, line 2326, in resolve File /root/barbican/barbican/api/__init__.py, line 22, in module import pecan ImportError: No module named pecan OOPS ! failed loading app in worker 1 (pid 27606) :( trying again... worker respawning too fast !!! i have to sleep a bit (2 seconds)... OOPS ! failed loading app in worker 1 (pid 27607) :( trying again... worker respawning too fast !!! i have to sleep a bit (2 seconds)... Respawned uWSGI worker 1 (new pid: 27608) Respawned uWSGI worker 1 (new pid: 27609) Loading paste environment: config:/etc/barbican/barbican-api-paste.ini Loading paste environment: config:/etc/barbican/barbican-admin-paste.ini Traceback (most recent call last): File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 247, in loadapp return loadobj(APP, uri, name=name, **kw) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 271, in loadobj global_conf=global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 296, in loadcontext global_conf=global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 320, in _loadconfig return loader.get_context(object_type, name, global_conf) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 450, in get_context global_additions=global_additions) File /root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 559, in _pipeline_app_context APP, pipeline[-1], global_conf) File
Re: [openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?
Unsure, I've always been iff on auto-tools like that. Especially with things like: https://github.com/google/yapf/issues/10 But maybe in time... IMHO the hacking rules aren't that much to learn and are good to know anyway. -Josh Maru Newby wrote: I am excited by the release of YAPF [1], a gofmt-like too for python. I think it has the potential to simplify style enforcement, and as much as I appreciate our current hacking checks, I’d be much happier not requiring developers to manually conform to them. Maybe we can consider automation in a manner similar to that employed by the go codereview tool [2]? Cheers, Maru 1: https://github.com/google/yapf 2: https://godoc.org/golang.org/x/review/git-codereview#hdr-Gofmt __ 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] [infra] What do people think of YAPF (like gofmt, for python)?
On 03/25/2015 05:50 PM, Maru Newby wrote: I am excited by the release of YAPF [1], a gofmt-like too for python. I think it has the potential to simplify style enforcement, and as much as I appreciate our current hacking checks, I’d be much happier not requiring developers to manually conform to them. Maybe we can consider automation in a manner similar to that employed by the go codereview tool [2]? I played with it for a few minutes and although it's configurable, it's still pretty limited in terms of expressiveness. That said - although I do appreciate the theory of auto-formatting (seriously, one less thing, right?) I think it would be problematic for us. You can't ship git hooks in a git repo, so we can't help our users know to run it before pushing. In a world where getting set up in openstack is already non-trivial, I think requiring 2500 developers to add a new git hook to every repo that they do something with would be a bit of a disaster. When you combine that with the people who won't know, will make a patch, send it up, and have it rejected --- oy. Chaos. git review is used by a ton of people who write in non-python. I think adding openstack-specific style enforcement to it would make it way less generally useful. In general, if you find it interesting, there's certainly nothing wrong with tracking it and poking at it from time to time. But I honestly think that the logistical issue is pretty large, and one that the payoff from solving would not be worth the effort. Monty __ 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] [release] taskflow 0.8.0
We are stoked to announce the release of: taskflow 0.8.0: Taskflow structured state management library. For more details, please see the git log history below and: http://launchpad.net/taskflow/+milestone/0.8.0 Please report issues through launchpad: http://bugs.launchpad.net/taskflow/ Notable changes * The default engine storage is now always using a in-memory backend instead of just using local objects and caching results and data in those. This will help make the engine storage backend more uniform and require less customizations to use. * Large refactoring of backend path 'like' implementations (zookeeper, directory/file based and the in-memory backend). * New ``EventTimeListener`` that records when state changes happen (useful for gathering data about how long your workflows take, and how long the tasks in them take). * Support for python 3.3 has been removed (as it is no longer tested and 3.4 is the stable 3.x release that is being tested against). * Jobboards now have a trash() method that can be used to 'trash' jobs that should not be operated on (and can be used to look at for later analysis or for deleting). * Conductors now have entrypoints that should be used for loading (instead of accessing the direct conductor classes). The fetch() method of ``taskflow.conductors.backends`` should be used to retrieve your desired conductor object. * A new map/reduce functor task which has many potential uses. * Removal of ``taskflow.types.timing.StopWatch`` (it has now been moved to the oslo.utils library where it can be shared to a larger audience); a proxy object will still exist in ``taskflow.types.timing`` but using the new location in ``oslo.utils.timeutils`` should be preferred instead. * Usage of new debtcollector library functions. * Better WBE send/receive data validation (using jsonschema). * Atom provides/requires/optional/save_as now use an ordered dict or ordered set by default so that any specified ordering is capable of being maintained. Changes in taskflow 0.7.1..0.8.0 NOTE: Skipping requirement commits... cdcb248 Adding test to improve CaptureListener coverage cd54139 Prefer posixpath to os.path f815480 By default use a in memory backend (when none is provided) dc2fdaf Allow using shallow copy instead of deep copy 7d79e52 Move to the newer debtcollector provided functions 6723a18 Move to using the oslo.utils stop watch 579500d Ensure thread-safety of persistence dir backend 658d1f9 Ensure we are really setup before being connected 765037d Ensure docstring on storage properties f7b3c23 Expose the storage backend being used da73113 Use iteration instead of list(s) when extracting scopes dd33ec7 Use binary/encode decode helper routines in dir backend 6db6363 Rename memory backend filesystem - fake filesystem 3579410 Always return scope walker instances from `fetch_scopes_for` 374d91d Give the GC a break 6671ce4 Use the class name instead of the TYPE property in __str__ ebe3d6d Just use the class name instead of TYPE constant 5d2fb53 Attempt to extract traceback from exception ac2b1be Use compatible map and update map/reduce task docs d1742b1 Update engine docs with new validation stage a1f9321 Ensure we register deregister conductor listeners 87d6f58 Rename attribute '_graph' to '_execution_graph' 7e052e0 Add a log statement pre-validation that dumps graph info 5209961 Have this example exit non-zero if incorrect results bf5164e Use a collections.namedtuple for the request work unit 0e952e6 Some small wbe engine doc tweaks c1f0200 Add newline to avoid sphinx warning 526f287 Allow passing 'many_handler' to fetch_all function 12c28bb Ensure event time listener is in listeners docs 8602118 Add a in-memory backend dumping example 0a2928f Added a map and a reduce task 6529c1e Restructure the in-memory node usage f6e2074 Switch to non-namespaced module imports 5996c8f Allow the storage unit to use the right scoping strategy 94eb978 Just use the local conf variable 844c2c6 Put underscore in-front of alchemist helper 9f64c47 lazy loading for logbooks and flowdetails 646ca59 Allow backend connection config (via fetch) to be a string ad133ad Add + use failure json schema validation 67f0f51 Use ordered[set/dict] to retain ordering f0de22c Allow injected atom args to be persisted 8e62483 add _listeners_from_job method to Conductor base b9b6576 update uses of TimingListener to DurationListener 7d3ae77 Added EventTimeListner to record when events occur 8c08869 added update_flow_metadata method to Storage class 1478f52 Retain nested causes where/when we can 1f4e596 Denote issue 17911 has been merged/accepted 3e8eb91 Persistence backend refactor c22c62d Remove support for 3.3 00ab628 Writers can now claim a read lock in ReaderWriterLock 47c0269 Add another probabilistic rw-lock test 20fdbba Add + use read/write lock decorators 89087fd Add no double writers thread test d302b52 Use condition context manager
[openstack-dev] Fwd: a question regarding the current status of image community visibility support on glance
Hello everyone I recently came across one glance related pending blueprint ( https://review.openstack.org/#/c/124050/). It raised our interest as we also want to implement this community visibility for images through glance. However, after cherry picking the code change ( https://review.openstack.org/#/c/136374/), I was not able to get the expected result. Instead, I got the following error: su@ubuntu:/opt/stack/glance/glance/db/sqlalchemy/migrate_repo/versions$ glance image-update --visibility private 4adda55e-fa6e-4605-aa42-aa5faabc04b8 usage: glance [--version] [-d] [-v] [--get-schema] [--timeout TIMEOUT] [--no-ssl-compression] [-f] [--os-image-url OS_IMAGE_URL] [--os-image-api-version OS_IMAGE_API_VERSION] [--profile HMAC_KEY] [-k] [--os-cert OS_CERT] [--cert-file OS_CERT] [--os-key OS_KEY] [--key-file OS_KEY] [--os-cacert ca-certificate-file] [--ca-file OS_CACERT] [--os-username OS_USERNAME] [--os-user-id OS_USER_ID] [--os-user-domain-id OS_USER_DOMAIN_ID] [--os-user-domain-name OS_USER_DOMAIN_NAME] [--os-project-id OS_PROJECT_ID] [--os-project-name OS_PROJECT_NAME] [--os-project-domain-id OS_PROJECT_DOMAIN_ID] [--os-project-domain-name OS_PROJECT_DOMAIN_NAME] [--os-password OS_PASSWORD] [--os-tenant-id OS_TENANT_ID] [--os-tenant-name OS_TENANT_NAME] [--os-auth-url OS_AUTH_URL] [--os-region-name OS_REGION_NAME] [--os-auth-token OS_AUTH_TOKEN] [--os-service-type OS_SERVICE_TYPE] [--os-endpoint-type OS_ENDPOINT_TYPE] subcommand ... glance: error: unrecognized arguments: --visibility 4adda55e-fa6e-4605-aa42-aa5faabc04b8 Could any of you kindly give me some hints regarding how to get the issue fixed (if it is fixable)? Or anywhere I can change to code to enable the function mentioned in the blueprint? Any response will be highly appreciated! -- Su Zhang __ 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] FCoE support in openstack
Hi, I saw openstack cinder already supported iscsi FC and didn’t support FCoE. Any plan to support it? Is there any BP to cover it? If not, I may draft for it. Thanks, -Ruijing __ 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] Meters vs. Metrics
-Original Message- From: Julien Danjou [mailto:jul...@danjou.info] Sent: 25 March 2015 08:55 To: Tim Bell Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ceilometer] Meters vs. Metrics On Tue, Mar 24 2015, Tim Bell wrote: Can we keep it consistent ? The APIs have meter in them, so do the CLIs so we should really stick to that convention. It should be consistent already, as picked terms years ago. Meters represents a set of samples with the same meter_name. There's no metrics in Ceilometer. Unfortunately, this is a cause of confusion for the users. Do you have a reference to the differences in the concepts ? The ceilometer doc does also have this confusion in some places, for example, http://docs.openstack.org/developer/ceilometer/measurements.html mixes the terms. Existing meters --- For the list of existing metrics see the tables under the Measurements page of Ceilometer in the Cloud Administrator Guide. Tim If Gnocchi is using metrics, I feel it should change to use meters or a V3 API proposed that changes it all. Gnocchi is using metrics to differ from Ceilometer's meters because they are not the same concept. -- Julien Danjou // Free Software hacker // http://julien.danjou.info __ 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] CI report formatting (citrix / hyperv / vmware )
Currently Citrix, HyperV, and VMWare CI systems reporting on Nova patches have a different formatting than the standard that Jenkins and other systems are using: * test-name-no-spaces http://link.to/result : [SUCCESS|FAILURE] some comment about the test This means these systems don't show up in the CI rollup block - http://dl.dropbox.com/u/6514884/screenshot_158.png I'd really like that to change. The CI rollup block has been extremely useful in getting the test results of a patch above the fold, and the ability to dig into them clearly. I feel like if any CI system isn't reporting in standard format that's parsible by that, we should probably turn it off. What's fair warning to get these systems postings into the standard format? It realistically should be a very quick change by them, but will help quite a lot in reviewing code. -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
Re: [openstack-dev] [nova] CI report formatting (citrix / hyperv / vmware )
Hi On Wed, Mar 25, 2015 at 12:39 PM, Sean Dague s...@dague.net wrote: Currently Citrix, HyperV, and VMWare CI systems reporting on Nova patches have a different formatting than the standard that Jenkins and other systems are using: * test-name-no-spaces http://link.to/result : [SUCCESS|FAILURE] some comment about the test I don't want to talk for Citrix, HyperV or VMWare but the standard only work if you use Zuul in your CI. I am using a setup based on a Jenkins plugin called gerrit-trigger and there's no way to format the message the way it's expected... This means these systems don't show up in the CI rollup block - http://dl.dropbox.com/u/6514884/screenshot_158.png I'd really like that to change. The CI rollup block has been extremely useful in getting the test results of a patch above the fold, and the ability to dig into them clearly. I feel like if any CI system isn't reporting in standard format that's parsible by that, we should probably turn it off. What's fair warning to get these systems postings into the standard format? It realistically should be a very quick change by them, but will help quite a lot in reviewing code. -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
[openstack-dev] [swift] swift memory usage in centos7 devstack jobs
Hi, We've been having an issue with Centos 7 jobs and the host running out of memory. After some investigation; one likely angle seems to be the memory usage by swift. See [1] for some more details; but the short story is that the various swift processes -- even just sitting around freshly installed from devstack before anything happens -- take up twice as much space on centos as ubuntu --- swift (% total system memory) --- ubuntu 6.6% centos 12% In general memory usage is higher on centos, but this one is an outlier. Unfortunately, the main difference between the two appears to be heap allocations (see comments in [1]) which doesn't give a lot of clues. The end result is that the host ends up just plain running out of memory; the OOM killer kicks in and then everything starts collapsing. I had the host sending me telemetry while it was running; the last entry before things fell over was [2] and we can see that it's not just one thing that comes along and sucks up memory, but death by a thousand cuts. I think the Centos 7 job is struggling to fit into the 8gb available so we're susceptible to finding memory issues first. Any swift people have some ideas on this? Thanks -i [1] https://etherpad.openstack.org/p/oom-in-rax-centos7-CI-job [2] http://paste.openstack.org/show/196769/ __ 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] a question regarding the current status of image community visibility support
I figured out that after I cherry picked the code at https://review.openstack.org/#/c/136374/, I will encounter a 500 error while using glance api 2.0. Could anyone possibly let me know how to get this error around? Here is my log: 2015-03-25 22:04:54.088 WARNING oslo_config.cfg [req-d197339f-dd73-4ad4-88b4-3194d0e23570 8e50cb1c63294e528502abcbdeed8b50 87ab685d55af4882b9af51e3d28 6ab0b] Option sql_connection from group DEFAULT is deprecated. Use option connection from group database. 2015-03-25 22:04:54.104 DEBUG oslo_db.sqlalchemy.session [req-d197339f-dd73-4ad4-88b4-3194d0e23570 8e50cb1c63294e528502abcbdeed8b50 87ab685d55af4882b9 af51e3d286ab0b] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_ AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION from (pid=63674) _check_effective_sql_mode /usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/session.p y:513 2015-03-25 22:04:54.156 INFO eventlet.wsgi.server [req-d197339f-dd73-4ad4-88b4-3194d0e23570 8e50cb1c63294e528502abcbdeed8b50 87ab685d55af4882b9af51e3d 286ab0b] Traceback (most recent call last): File /usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py, line 427, in handle_one_response result = self.application(self.environ, start_response) File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 130, in __call__ resp = self.call_func(req, *args, **self.kwargs) File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 195, in call_func return self.func(req, *args, **kwargs) File /opt/stack/glance/glance/common/wsgi.py, line 486, in __call__ response = req.get_response(self.application) File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1320, in send application, catch_exc_info=False) File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1284, in call_application app_iter = application(self.environ, start_response) File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 130, in __call__ resp = self.call_func(req, *args, **self.kwargs) File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 195, in call_func return self.func(req, *args, **kwargs) File /usr/local/lib/python2.7/dist-packages/osprofiler/web.py, line 99, in __call__ return request.get_response(self.application) File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1320, in send application, catch_exc_info=False) File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1284, in call_application app_iter = application(self.environ, start_response) File /usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py, line 634, in __call__ return self._call_app(env, start_response) File /usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py, line 554, in _call_app return self._app(env, _fake_start_response) File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 130, in __call__ resp = self.call_func(req, *args, **self.kwargs) File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 195, in call_func return self.func(req, *args, **kwargs) File /opt/stack/glance/glance/common/wsgi.py, line 486, in __call__ response = req.get_response(self.application) File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1320, in send application, catch_exc_info=False) File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1284, in call_application app_iter = application(self.environ, start_response) File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 130, in __call__ resp = self.call_func(req, *args, **self.kwargs) File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 195, in call_func return self.func(req, *args, **kwargs) File /opt/stack/glance/glance/common/wsgi.py, line 486, in __call__ response = req.get_response(self.application) File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1320, in send application, catch_exc_info=False) File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1284, in call_application app_iter = application(self.environ, start_response) File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 130, in __call__ resp = self.call_func(req, *args, **self.kwargs) File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 195, in call_func return self.func(req, *args, **kwargs) File /opt/stack/glance/glance/common/wsgi.py, line 486, in __call__ response = req.get_response(self.application) File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1320, in send application, catch_exc_info=False) File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1284, in call_application app_iter = application(self.environ, start_response) File
Re: [openstack-dev] [glance] image-create failed vcender backend
Hi Sergiy I have commented on the bug, please take a look. Thanks Sabari On Wed, Mar 25, 2015 at 1:58 PM, Sergiy Lystopad slysto...@mirantis.com wrote: Hi,colleagues. I've faced with an issue https://bugs.launchpad.net/glance/+bug/1436034 during mos 6.0 with vcenter deployment for customer. could you help me do debug and fix issue. Thanks -- Sergiy Lystopad __ 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] Fwd: a question regarding the current status of image community visibility support on glance
visibility is an attribute of glance v2, so please try: glance --os-image-api-version 2 image-update --visibility private 4adda55e-fa6e-4605-aa42-aa5faabc04b8 On 26/03/15 11:50, Su Zhang wrote: Hello everyone I recently came across one glance related pending blueprint (https://review.openstack.org/#/c/124050/). It raised our interest as we also want to implement this community visibility for images through glance. However, after cherry picking the code change (https://review.openstack.org/#/c/136374/), I was not able to get the expected result. Instead, I got the following error: su@ubuntu:/opt/stack/glance/glance/db/sqlalchemy/migrate_repo/versions$ glance image-update --visibility private 4adda55e-fa6e-4605-aa42-aa5faabc04b8 usage: glance [--version] [-d] [-v] [--get-schema] [--timeout TIMEOUT] [--no-ssl-compression] [-f] [--os-image-url OS_IMAGE_URL] [--os-image-api-version OS_IMAGE_API_VERSION] [--profile HMAC_KEY] [-k] [--os-cert OS_CERT] [--cert-file OS_CERT] [--os-key OS_KEY] [--key-file OS_KEY] [--os-cacert ca-certificate-file] [--ca-file OS_CACERT] [--os-username OS_USERNAME] [--os-user-id OS_USER_ID] [--os-user-domain-id OS_USER_DOMAIN_ID] [--os-user-domain-name OS_USER_DOMAIN_NAME] [--os-project-id OS_PROJECT_ID] [--os-project-name OS_PROJECT_NAME] [--os-project-domain-id OS_PROJECT_DOMAIN_ID] [--os-project-domain-name OS_PROJECT_DOMAIN_NAME] [--os-password OS_PASSWORD] [--os-tenant-id OS_TENANT_ID] [--os-tenant-name OS_TENANT_NAME] [--os-auth-url OS_AUTH_URL] [--os-region-name OS_REGION_NAME] [--os-auth-token OS_AUTH_TOKEN] [--os-service-type OS_SERVICE_TYPE] [--os-endpoint-type OS_ENDPOINT_TYPE] subcommand ... glance: error: unrecognized arguments: --visibility 4adda55e-fa6e-4605-aa42-aa5faabc04b8 Could any of you kindly give me some hints regarding how to get the issue fixed (if it is fixable)? Or anywhere I can change to code to enable the function mentioned in the blueprint? Any response will be highly appreciated! -- Su Zhang __ 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 -- Cheers Best regards, Fei Long Wang (王飞龙) -- Senior Cloud Software Engineer Tel: +64-48032246 Email: flw...@catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington -- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] VLAN trunking network for NFV
*From:* Ian Wells [mailto:ijw.ubuntu at cack.org.uk] *Sent:* Wednesday, March 25, 2015 2:18 AM That spec ensures that you can tell what the plugin is doing. You can ask for a VLAN transparent network, but the cloud may tell you it can't make one. If you want to use a VLAN trunk using the current code, I recommend VXLAN or GRE along with the Linuxbridge driver, both of which support VLAN transparent networking. If they're configured and you ask for a VLAN trunk you'll be told you got one.The linuxbridge agent does not support GRE.I tried sending tagged packets over linuxbridge+VxLAN and it did not work - I didn't look into it any further.I also tried over linuxbridge+FLAT - this works when the physical switch ports are trunks - they would need to permit all VLAN ids to be fully VLAN transparent. I think linuxbridge+VLAN would work too, as along as the switch ports are also configured for Q-in-Q.Currently the linuxbridge mechanism driver cannot know if a Neutron network is VLAN transparent or not. __ 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] Overriding settings file for devstack plugin
On Wed, Mar 25, 2015 at 3:58 PM, Sean Dague s...@dague.net wrote:
On 03/25/2015 03:16 AM, Deepak Shetty wrote:
On Wed, Mar 25, 2015 at 11:29 AM, Deepak Shetty dpkshe...@gmail.com
mailto:dpkshe...@gmail.com wrote:
On Wed, Mar 25, 2015 at 12:58 AM, Ian Wienand iwien...@redhat.com
mailto:iwien...@redhat.com wrote:
On 03/24/2015 03:17 PM, Deepak Shetty wrote:
For eg: Look at [1]
[1]
https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/settings
I would like ability to change these while I use the
enable_plugin
apporach to setup devstack w/ GlusterFS per my local glusterfs
setup
So I think the plugin should do
CINDER_ENABLED_BACKENDS=${CINDER_ENABLED_BACKENDS:-glusterfs:glusterfs,lvm:lvm1}
i.e. provide a default only if the variable is unset.
Bah! That was easy, i should have figured that myself :)
Thanks for catching that
This seems like one of those traps for new players and is one
concern I have with devstack plugins -- that authors keep having
to
find out lessons learned independently. I have added a note on
this
to the documentation in [1].
-i
[1] https://review.openstack.org/#/c/167375/
Great, i +1'ed it.
Also i posted patch to fix settings file @
https://review.openstack.org/167494
Ian,
Looks like usign bash default in settings file of plugin is not
working, in my patch it didn't use glusterfs driver, it used LVM
(default)
I think whats happening here is that by the time settings file is
sourced, CINDER_ENABLED_BACKENDS is already set to lvm by lib/cinder
so settings file's default value is never taken
IIUC there are 3 scenarios (taking CINDER_ENABLED_BACKENDS as example
var) :
1) localrc doesn't have CINDER_ENABLED_BACKENDS and enable_plugin
- Here we want the lib/cinder's default value to be taken
- this should work fine
2) localrc doesn't have CINDER_ENABLED_BACKENDS but has enable_plugin
glusterfs
- Here we want the plugin's default values to be taken, but its not
as lib/cinder already initialized CINDER_ENABLED_BACKENDS to use lvm
backend
- Thus broken
3) localrc has both CINDER_ENABLED_BACKENDS and enable_plugin glusterfs
specified
- Here we want CINDER_ENABLED_BACKENDS present in my localrc to be
chosen
- This will work as by the time settings file is sourced
CINDER_ENABLED_BACKENDS is already initialised to my value in localrc
So #2 scenario would need some changes in stack.sh handling of plugin
code ?
Right, so this code runs late enough that you don't get to change the
defaults. I think that's ok.
I would instead do the following:
1) CINDER_ENABLED_BACKENDS+=,glusterfs:glusterfs
or
2) CINDER_ENABLED_BACKENDS=glusterfs:glusterfs
in the plugin.
Clearly, if you've enabled the plugin, you want glusterfs. I think that
in most cases you probably only want glusterfs as your backend, so
option #2 seems sensible.
#1 is needed for multi-backend testing
#2 is needed for single-backend testing
#2 is what we currently, we blindly override the var, but that forces the
devstack user to
use the config given in the plugin, I wanted a way to either use plugin
config or override it
I think #1 is better, since it gives the power in localrc to do:
1) CINDER_ENABLED_BACKENDS=
This will ensure lib/cinder doesn't populate it and plugin adds
glusterfs:glusterfs for single backend
2) No mention of CINDER_ENABLED_BACKENDS in localrc
This will make it CINDER_ENABLED_BACKENDS=lvm:lvm-driver1,
glusterfs:glusterfs for multi-backend
Also for vars in settings file that are backend specific (hence not touched
by lib/cinder):
GLUSTERFS_LOOPBACK_DISK_SIZE CINDER_GLUSTERFS_SHARES
They can remain as :
GLUSTERFS_LOOPBACK_DISK_SIZE=${GLUSTERFS_LOOPBACK_DISK_SIZE:-8G}
CINDER_GLUSTERFS_SHARES=${CINDER_GLUSTERFS_SHARES:-127.0.0.1:
/vol1;127.0.0.1:/vol2}
(as mentioned in the patch @
https://review.openstack.org/#/c/167494/1/devstack/settings)
This will give the end user the ability to change loopback size and/or
gluster server IPs
based on the needs of his/her local setup
Agree ?
If yes, then we must mention this in the plugin.rst in a nice way for other
plugin writers to
understand properly :) ?
thanx,
deepak
-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
Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin
On 03/25/2015 09:28 PM, Sean Dague wrote: I would instead do the following: 1) CINDER_ENABLED_BACKENDS+=,glusterfs:glusterfs This is what I was about to suggest. I'd be willing to believe ordering could still get tangled depending on exactly what you want -- I think at that point best to follow up in a bug and we can pull apart the specifics. -i __ 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] [oslo] stable-maint for oslo.vmware
Doug, Please add me to the stable maintenance team for oslo.vmware. Thanks, Vipin -Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: Tuesday, March 24, 2015 2:08 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [oslo] stable-maint for oslo.vmware Gary pinged me on IRC earlier today and I missed him, so I’m sending this to the list in case someone else wants to volunteer. It sounds like there are some stable branch changes for oslo.vmware that need attention. Does someone on the oslo.vmware team want to volunteer to be on a stable-maintenance team for the library? 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 __ 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] Overriding settings file for devstack plugin
On Wed, Mar 25, 2015 at 4:20 PM, Deepak Shetty dpkshe...@gmail.com wrote:
On Wed, Mar 25, 2015 at 3:58 PM, Sean Dague s...@dague.net wrote:
On 03/25/2015 03:16 AM, Deepak Shetty wrote:
On Wed, Mar 25, 2015 at 11:29 AM, Deepak Shetty dpkshe...@gmail.com
mailto:dpkshe...@gmail.com wrote:
On Wed, Mar 25, 2015 at 12:58 AM, Ian Wienand iwien...@redhat.com
mailto:iwien...@redhat.com wrote:
On 03/24/2015 03:17 PM, Deepak Shetty wrote:
For eg: Look at [1]
[1]
https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/settings
I would like ability to change these while I use the
enable_plugin
apporach to setup devstack w/ GlusterFS per my local
glusterfs setup
So I think the plugin should do
CINDER_ENABLED_BACKENDS=${CINDER_ENABLED_BACKENDS:-glusterfs:glusterfs,lvm:lvm1}
i.e. provide a default only if the variable is unset.
Bah! That was easy, i should have figured that myself :)
Thanks for catching that
This seems like one of those traps for new players and is one
concern I have with devstack plugins -- that authors keep
having to
find out lessons learned independently. I have added a note on
this
to the documentation in [1].
-i
[1] https://review.openstack.org/#/c/167375/
Great, i +1'ed it.
Also i posted patch to fix settings file @
https://review.openstack.org/167494
Ian,
Looks like usign bash default in settings file of plugin is not
working, in my patch it didn't use glusterfs driver, it used LVM
(default)
I think whats happening here is that by the time settings file is
sourced, CINDER_ENABLED_BACKENDS is already set to lvm by lib/cinder
so settings file's default value is never taken
IIUC there are 3 scenarios (taking CINDER_ENABLED_BACKENDS as example
var) :
1) localrc doesn't have CINDER_ENABLED_BACKENDS and enable_plugin
- Here we want the lib/cinder's default value to be taken
- this should work fine
2) localrc doesn't have CINDER_ENABLED_BACKENDS but has enable_plugin
glusterfs
- Here we want the plugin's default values to be taken, but its not
as lib/cinder already initialized CINDER_ENABLED_BACKENDS to use lvm
backend
- Thus broken
3) localrc has both CINDER_ENABLED_BACKENDS and enable_plugin glusterfs
specified
- Here we want CINDER_ENABLED_BACKENDS present in my localrc to be
chosen
- This will work as by the time settings file is sourced
CINDER_ENABLED_BACKENDS is already initialised to my value in localrc
So #2 scenario would need some changes in stack.sh handling of plugin
code ?
Right, so this code runs late enough that you don't get to change the
defaults. I think that's ok.
I would instead do the following:
1) CINDER_ENABLED_BACKENDS+=,glusterfs:glusterfs
or
2) CINDER_ENABLED_BACKENDS=glusterfs:glusterfs
in the plugin.
Clearly, if you've enabled the plugin, you want glusterfs. I think that
in most cases you probably only want glusterfs as your backend, so
option #2 seems sensible.
#1 is needed for multi-backend testing
#2 is needed for single-backend testing
#2 is what we currently, we blindly override the var, but that forces the
devstack user to
use the config given in the plugin, I wanted a way to either use plugin
config or override it
I think #1 is better, since it gives the power in localrc to do:
1) CINDER_ENABLED_BACKENDS=
This will ensure lib/cinder doesn't populate it and plugin adds
glusterfs:glusterfs for single backend
My bad here, lib/cinder uses :- which IIUC means empty or unset, use default
so with #1 or #2 there isn't a way to provide ability to use plugin config
or override it , both ?
back to square one.
thanx,
deepak
2) No mention of CINDER_ENABLED_BACKENDS in localrc
This will make it CINDER_ENABLED_BACKENDS=lvm:lvm-driver1,
glusterfs:glusterfs for multi-backend
Also for vars in settings file that are backend specific (hence not
touched by lib/cinder):
GLUSTERFS_LOOPBACK_DISK_SIZE CINDER_GLUSTERFS_SHARES
They can remain as :
GLUSTERFS_LOOPBACK_DISK_SIZE=${GLUSTERFS_LOOPBACK_DISK_SIZE:-8G}
CINDER_GLUSTERFS_SHARES=${CINDER_GLUSTERFS_SHARES:-127.0.0.1:
/vol1;127.0.0.1:/vol2}
(as mentioned in the patch @
https://review.openstack.org/#/c/167494/1/devstack/settings)
This will give the end user the ability to change loopback size and/or
gluster server IPs
based on the needs of his/her local setup
Agree ?
If yes, then we must mention this in the plugin.rst in a nice way for
other plugin writers to
understand properly :) ?
thanx,
deepak
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
Re: [openstack-dev] [Neutron] [TripleO] [Ironic] Deprecating the use_namespaces option - Now's the time to speak up!
Thanks for your interest; following is a description of what Calico does in this area. Just to be clear, this is for interest and information only and I don't mean to suggest that this has any bearing on the use_namespaces deprecation discussion (especially since that change is now merged).Calico doesn't use namespaces because it transports VM IP data between compute hosts by routing it, instead of bridging and tunnelling it. The routing between compute hosts is established in the default namespace by BGP clients (BIRD), so to connect with that the TAP interfaces from VMs need to sit in the default namespace too.Then the question arises of how to provide DHCP for those TAP interfaces - unbridged, and in the default namespace. Calico does this by running dnsmasq in the default namespace, using dnsmasq's --bridge-interfaces option to treat those TAP interfaces as aliases of the dummy interface on which the DHCP context and subnet gateway IP address are provisioned.Now, to set all that up - i.e. to provision the dummy interface; create the config files that dnsmasq needs, and update those as VMs are added or removed; launch dnsmasq; etc. - is a lot of extra value, that neutron-dhcp-agent provides, and it's currently (in Icehouse and Juno) a relatively small patch on neutron-dhcp-agent to do all those things with the tweaks that Calico needs.I hope that makes sense, and is of some interest. Please do feel free to ask any further questions.Regards, NeilFrom: Miguel Ángel AjoSent: Monday, 23 March 2015 06:59To: OpenStack Development Mailing List (not for usage questions)Reply To: OpenStack Development Mailing List (not for usage questions)Cc: openstack-operat...@lists.openstack.orgSubject: Re: [openstack-dev] [Neutron] [TripleO] [Ironic]Deprecating the use_namespaces option - Now's the time to speak up!Looking at project Calico, I don’t know if what they do is similar to what the people fromtriple-o ironic do with the neutron-dhcp-agent. I believe we should ask thembefore deprecation.I added their tags to the subject. AFAIK TripleO/Ironic was patching neutron-dhcp-agent too.For project Calico, why do you need no netns and why do you patch it?Kevin, thanks for pointing that out.Best,Miguel Ángel Ajo On Monday, 23 de March de 2015 at 7:34, Miguel Ángel Ajo wrote: +1 for deprecation if people don’t have use cases / good reasons to keep it, I don’t know and I can’t think of any, but that doesn’t mean they don’t exist. Miguel Ángel Ajo On Monday, 23 de March de 2015 at 2:34, shihanzhang wrote: +1 todeprecate this optionAt 2015-03-21 02:57:09, "Assaf Muller" amul...@redhat.com wrote: Hello everyone, The use_namespaces option in the L3 and DHCP Neutron agents controls if you can create multiple routers and DHCP networks managed by a single L3/DHCP agent, or if the agent manages only a single resource. Are the setups out there *not* using the use_namespaces option? I'm curious as to why, and if it would be difficult to migrate such a setup to use namespaces. I'm asking because use_namespaces complicates Neutron code for what I gather is an option that has not been relevant for years. I'd like to deprecate the option for Kilo and remove it in Liberty. Assaf Muller, Cloud Networking Engineer Red Hat __ 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __OpenStack Development Mailing List (not for usage questions)Unsubscribe:
Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin
On Wed, Mar 25, 2015 at 4:24 PM, Deepak Shetty dpkshe...@gmail.com wrote:
On Wed, Mar 25, 2015 at 4:20 PM, Deepak Shetty dpkshe...@gmail.com
wrote:
On Wed, Mar 25, 2015 at 3:58 PM, Sean Dague s...@dague.net wrote:
On 03/25/2015 03:16 AM, Deepak Shetty wrote:
On Wed, Mar 25, 2015 at 11:29 AM, Deepak Shetty dpkshe...@gmail.com
mailto:dpkshe...@gmail.com wrote:
On Wed, Mar 25, 2015 at 12:58 AM, Ian Wienand iwien...@redhat.com
mailto:iwien...@redhat.com wrote:
On 03/24/2015 03:17 PM, Deepak Shetty wrote:
For eg: Look at [1]
[1]
https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/settings
I would like ability to change these while I use the
enable_plugin
apporach to setup devstack w/ GlusterFS per my local
glusterfs setup
So I think the plugin should do
CINDER_ENABLED_BACKENDS=${CINDER_ENABLED_BACKENDS:-glusterfs:glusterfs,lvm:lvm1}
i.e. provide a default only if the variable is unset.
Bah! That was easy, i should have figured that myself :)
Thanks for catching that
This seems like one of those traps for new players and is one
concern I have with devstack plugins -- that authors keep
having to
find out lessons learned independently. I have added a note
on this
to the documentation in [1].
-i
[1] https://review.openstack.org/#/c/167375/
Great, i +1'ed it.
Also i posted patch to fix settings file @
https://review.openstack.org/167494
Ian,
Looks like usign bash default in settings file of plugin is not
working, in my patch it didn't use glusterfs driver, it used LVM
(default)
I think whats happening here is that by the time settings file is
sourced, CINDER_ENABLED_BACKENDS is already set to lvm by lib/cinder
so settings file's default value is never taken
IIUC there are 3 scenarios (taking CINDER_ENABLED_BACKENDS as example
var) :
1) localrc doesn't have CINDER_ENABLED_BACKENDS and enable_plugin
- Here we want the lib/cinder's default value to be taken
- this should work fine
2) localrc doesn't have CINDER_ENABLED_BACKENDS but has enable_plugin
glusterfs
- Here we want the plugin's default values to be taken, but its not
as lib/cinder already initialized CINDER_ENABLED_BACKENDS to use lvm
backend
- Thus broken
3) localrc has both CINDER_ENABLED_BACKENDS and enable_plugin glusterfs
specified
- Here we want CINDER_ENABLED_BACKENDS present in my localrc to be
chosen
- This will work as by the time settings file is sourced
CINDER_ENABLED_BACKENDS is already initialised to my value in localrc
So #2 scenario would need some changes in stack.sh handling of plugin
code ?
Right, so this code runs late enough that you don't get to change the
defaults. I think that's ok.
I would instead do the following:
1) CINDER_ENABLED_BACKENDS+=,glusterfs:glusterfs
or
2) CINDER_ENABLED_BACKENDS=glusterfs:glusterfs
in the plugin.
Clearly, if you've enabled the plugin, you want glusterfs. I think that
in most cases you probably only want glusterfs as your backend, so
option #2 seems sensible.
#1 is needed for multi-backend testing
#2 is needed for single-backend testing
#2 is what we currently, we blindly override the var, but that forces the
devstack user to
use the config given in the plugin, I wanted a way to either use plugin
config or override it
I think #1 is better, since it gives the power in localrc to do:
1) CINDER_ENABLED_BACKENDS=
This will ensure lib/cinder doesn't populate it and plugin adds
glusterfs:glusterfs for single backend
My bad here, lib/cinder uses :- which IIUC means empty or unset, use
default
so with #1 or #2 there isn't a way to provide ability to use plugin config
or override it , both ?
back to square one.
Sorry, hit send before i could complete
back to square one (unless we modify lib/cinder to *not* use default for
CINDER_ENABLED_BACKENDS
if 'CINDER_ENABLED_BACKENDS=' specified in localrc)
thanx,
deepak
thanx,
deepak
2) No mention of CINDER_ENABLED_BACKENDS in localrc
This will make it CINDER_ENABLED_BACKENDS=lvm:lvm-driver1,
glusterfs:glusterfs for multi-backend
Also for vars in settings file that are backend specific (hence not
touched by lib/cinder):
GLUSTERFS_LOOPBACK_DISK_SIZE CINDER_GLUSTERFS_SHARES
They can remain as :
GLUSTERFS_LOOPBACK_DISK_SIZE=${GLUSTERFS_LOOPBACK_DISK_SIZE:-8G}
CINDER_GLUSTERFS_SHARES=${CINDER_GLUSTERFS_SHARES:-127.0.0.1:
/vol1;127.0.0.1:/vol2}
(as mentioned in the patch @
https://review.openstack.org/#/c/167494/1/devstack/settings)
This will give the end user the ability to change loopback size and/or
gluster server IPs
based on the needs of his/her local setup
Agree ?
If yes, then we must mention this in the plugin.rst in a nice way for
other plugin
Re: [openstack-dev] [depfreeze][horizon] Update to Django-1.7.x
On 25/03/15 11:34, Sean Dague wrote: Could you make this one Depends on https://review.openstack.org/#/c/167515/ so that we check that all Django 1.7 related issues are fixed ? I don't think it was ever sufficiently explained why horizon now needs django nose to compile it's message catalog (which is where it is failing) when moving to 1.7. http://logs.openstack.org/53/155353/7/check/check-tempest-dsvm-full/961c75f/logs/devstacklog.txt.gz#_2015-03-20_19_25_51_098 We're getting nearer here, thank you! --compilemessages is called with test settings, which is wrong imo. The question is, why it has not hit us earlier. In any case, django_nose is not a runtime dep. I can see, why this is run at the gate as part of tests, though. Matthias __ 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] Overriding settings file for devstack plugin
On Wed, Mar 25, 2015 at 3:58 PM, Sean Dague s...@dague.net wrote:
On 03/25/2015 03:16 AM, Deepak Shetty wrote:
On Wed, Mar 25, 2015 at 11:29 AM, Deepak Shetty dpkshe...@gmail.com
mailto:dpkshe...@gmail.com wrote:
On Wed, Mar 25, 2015 at 12:58 AM, Ian Wienand iwien...@redhat.com
mailto:iwien...@redhat.com wrote:
On 03/24/2015 03:17 PM, Deepak Shetty wrote:
For eg: Look at [1]
[1]
https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/settings
I would like ability to change these while I use the
enable_plugin
apporach to setup devstack w/ GlusterFS per my local glusterfs
setup
So I think the plugin should do
CINDER_ENABLED_BACKENDS=${CINDER_ENABLED_BACKENDS:-glusterfs:glusterfs,lvm:lvm1}
i.e. provide a default only if the variable is unset.
Bah! That was easy, i should have figured that myself :)
Thanks for catching that
This seems like one of those traps for new players and is one
concern I have with devstack plugins -- that authors keep having
to
find out lessons learned independently. I have added a note on
this
to the documentation in [1].
-i
[1] https://review.openstack.org/#/c/167375/
Great, i +1'ed it.
Also i posted patch to fix settings file @
https://review.openstack.org/167494
Ian,
Looks like usign bash default in settings file of plugin is not
working, in my patch it didn't use glusterfs driver, it used LVM
(default)
I think whats happening here is that by the time settings file is
sourced, CINDER_ENABLED_BACKENDS is already set to lvm by lib/cinder
so settings file's default value is never taken
IIUC there are 3 scenarios (taking CINDER_ENABLED_BACKENDS as example
var) :
1) localrc doesn't have CINDER_ENABLED_BACKENDS and enable_plugin
- Here we want the lib/cinder's default value to be taken
- this should work fine
2) localrc doesn't have CINDER_ENABLED_BACKENDS but has enable_plugin
glusterfs
- Here we want the plugin's default values to be taken, but its not
as lib/cinder already initialized CINDER_ENABLED_BACKENDS to use lvm
backend
- Thus broken
3) localrc has both CINDER_ENABLED_BACKENDS and enable_plugin glusterfs
specified
- Here we want CINDER_ENABLED_BACKENDS present in my localrc to be
chosen
- This will work as by the time settings file is sourced
CINDER_ENABLED_BACKENDS is already initialised to my value in localrc
So #2 scenario would need some changes in stack.sh handling of plugin
code ?
Right, so this code runs late enough that you don't get to change the
defaults. I think that's ok.
Had a question here, why is this source in the end ?
plugin config is something that should be allowed to be overridden, thus
this should
be sourced in the beginning and then anything in localrc will override what
the plugin
sets/unsets
That ways if someone wants to use plugin config, just enable the plugin.
if they want to override, enable plugin and override the env specific parts
Am i thinkign wrong ?
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] [glance] a question regarding the current status of image community visibility support
Su,
The patch you are referring to is a work-in-progress patch. It only partially
implements the feature, and as one of the comments in the patch indicates, it's
defining an Integer column in the database that might be replaced by an enum.
So even if it were a full implementation, it would be dangerous to apply it to
your local glance (unless you just wanted to use it in devstack or something).
Since you're interested in the feature, it would be helpful if you'd put a
comment on the spec [1] to register your interest. It's been talked about for
a long time and could use a groundswell of support to land it in the Liberty
release.
cheers,
brian
[1] https://review.openstack.org/#/c/124050/
On 3/25/15, 9:07 PM, Su Zhang
westlif...@gmail.commailto:westlif...@gmail.com wrote:
Ian,
Thanks for your response!
I understand the situation that this specification is not accepted as of now.
However, given the fact that someone has already implemented this feature,
could you possibly let me know if there is a way for me to apply such feature
locally?
Thanks,
Su
On Wed, Mar 25, 2015 at 6:02 PM, Ian Cordasco
ian.corda...@rackspace.commailto:ian.corda...@rackspace.com wrote:
That specification wasn’t accepted for Kilo. This discussion should be
taken to the mailing list anyway (openstack-dev).
On 3/25/15, 19:32, Su Zhang
westlif...@gmail.commailto:westlif...@gmail.com wrote:
Thanks for your response Fei Long!
I switched my environment to glance v2.
However, I am encountering anther error saying that community is not
one of the valid visibility values.
Here is the running script in debug mode:
su@ubuntu:/opt/stack/glance/glance$ glance --debug image-update
--visibility community 4adda55e-fa6e-4605-aa42-aa5faabc04b8
curl -g -i -X GET -H 'User-Agent: python-glanceclient' -H 'Content-Type:
application/octet-stream' -H 'Accept-Encoding: gzip, deflate, compress'
-H 'Accept: */*' -H 'X-Auth-Token:
{SHA1}6ebf15bd27a056d97e4b66d5e6f1a4f27305b7b3'
http://172.16.152.171:9292/v2/schemas/image
HTTP/1.1 200 OK
date: Thu, 26 Mar 2015 00:21:17 GMT
content-length: 3867
content-type: application/json; charset=UTF-8
x-openstack-request-id: req-req-44ea8ad6-12e9-4a0b-9d93-2127b9f4b4f8
{additionalProperties: {type: string}, name: image, links:
[{href: {self}, rel: self}, {href: {file}, rel:
enclosure}, {href: {schema}, rel: describedby}], properties:
{status: {enum: [queued, saving, active,
killed, deleted, pending_delete], type: string, description:
Status of the image (READ-ONLY)}, tags: {items: {type: string,
maxLength: 255}, type: array, description: List of strings
related to the image}, kernel_id: {pattern:
^([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-
9a-fA-F]){12}$, type: string, description: ID of image stored in
Glance that should be used as the kernel when booting an AMI-style
image., is_base: false}, container_format:
{enum: [null, ami, ari, aki, bare, ovf, ova], type:
[null, string], description: Format of the container}, min_ram:
{type: integer, description: Amount of ram (in MB) required to
boot image.}, ramdisk_id: {pattern:
^([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-
9a-fA-F]){12}$,
type: string, description: ID of image stored in Glance that
should be used as the ramdisk when booting an AMI-style image.,
is_base: false}, locations: {items: {required: [url,
metadata], type: object, properties: {url: {type:
string, maxLength: 255}, metadata: {type: object}}}, type:
array, description: A set of URLs to access the image file kept in
external store}, visibility: {enum: [public, private], type:
string, description: Scope of image
accessibility}, updated_at: {type: string, description: Date
and time of the last image modification (READ-ONLY)}, owner: {type:
[null, string], description: Owner of the image, maxLength:
255}, file: {type: string, description:
(READ-ONLY)}, min_disk: {type: integer, description: Amount
of disk space (in GB) required to boot image.}, virtual_size: {type:
[null, integer], description: Virtual size of image in bytes
(READ-ONLY)}, id: {pattern:
^([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-
9a-fA-F]){12}$,
type: string, description: An identifier for the image}, size:
{type: [null, integer], description: Size of image file in bytes
(READ-ONLY)}, instance_uuid: {type: string, description: ID of
instance used to create this image.,
is_base: false}, os_distro: {type: string, description:
Common name of operating system distribution as specified in
http://docs.openstack.org/trunk/openstack-compute/admin/content/adding-ima
ges.html
http://docs.openstack.org/trunk/openstack-compute/admin/content/adding-im
ages.html, is_base: false}, name: {type: [null, string],
description: Descriptive name for the image, maxLength: 255},
checksum: {type: [null, string], description:
md5 hash of image contents. (READ-ONLY), maxLength: 32},
created_at: {type: string, description: Date and time of
Re: [openstack-dev] [Fuel] Nominate Irina Povolotskaya for fuel-docs core
+1 Best Regards, Sergii Golovatiuk On 25 Mar 2015, at 12:10, Dmitry Borodaenko dborodae...@mirantis.com wrote: Fuelers, I'd like to nominate Irina Povolotskaya for the fuel-docs-core team. She has contributed thousands of lines of documentation to Fuel over the past several months, and has been a diligent reviewer: http://stackalytics.com/?user_id=ipovolotskayarelease=allproject_type=allmodule=fuel-docs I believe it's time to grant her core reviewer rights in the fuel-docs repository. Core reviewer approval process definition: https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess -- Dmitry Borodaenko __ 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] [neutron] request for SFE
Neutron cores, I request SFE for the fix: https://review.openstack.org/147032/ https://bugs.launchpad.net/neutron/+bug/1408488 I believe there is consensus that this change is valuable through the discussion on the thread [1]. This change adds a configuration option to keep backward compatibility. (note that the opinion for the implementation was divided among reviewers. it is latest conclusion.) A string for translation is a help text of the configuration option. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-March/059714.html PS. I am not familiar with SFE procedure. Should I raise this to openstack-i18n mailing-list ? Thanks. -- Itsuro ODA o...@valinux.co.jp __ 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
