Re: [openstack-dev] ERROR: openstackclient.shell Exception raised: python-keystoneclient 1.4.0
Rick,
This is a problem of dependency resolution rather than an issue of
keystoneclient specifically. You can see that glanceclient has a cap on
keystoneclient that the installed version doesn't meet.
Dependency resolution has always been a problem but is raising its head again
recently. If you are seeing it and infra isn't it's probably because you are
installing specific versions of libraries that don't play well together. I'd go
and talk to folks in #openstack-infra.
Jamie
- Original Message -
From: Rick Chen rick.c...@prophetstor.com
To: openstack-dev@lists.openstack.org
Sent: Friday, 24 April, 2015 4:27:27 PM
Subject: [openstack-dev] ERROR: openstackclient.shell Exception raised:
python-keystoneclient 1.4.0
HI All:
Recently, our local machine often happened “Failed to launch devstack”.
Does anyone happen below issue in the Opnestack third-part CI devstack
machine? Any workaround or solution to fixed it.
2015-04-24 06:00:18.352 | ERROR: openstackclient.shell Exception raised:
(python-keystoneclient 1.4.0 (/opt/stack/new/python-keystoneclient),
Requirement.parse('python-keystoneclient1.4.0,=1.1.0'),
set(['python-glanceclient']))
pip list | grep keystone
keystone (2015.2.dev88, /opt/stack/new/keystone)
keystonemiddleware (1.5.0)
python-keystoneclient (1.4.0, /opt/stack/new/python-keystoneclient)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation
- Original Message - From: German Eichberger german.eichber...@hp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Saturday, 25 April, 2015 8:55:23 AM Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation Hi Brant, Sorry, for being confusing earlier. We have operations an administrator/operator is performing on behalf of a user, e.g. “Create Loadbalancer X for user tenant-id 123”. Now we are not checking the tenant-id and are wondering how to make the operation more robust with kesyone’s help. Thanks, German Not to speak for Brant, but i think the confusion here is why you are doing this. From my perspective you should never be in a position where the admin has to enter a raw project id like that. I think the problem here is the assumption of an all powerful admin user, and i'd encourage you to change your policy files to scrap that idea. A role is granted on a project and this project is mentioned in the token. If there is some role that is provided that lets you perform operations outside of the project id specified in that token please file a bug and i'd consider marking it a security issue. The X-Service-Token concept will allow for the combination of a user token and a service token to authenticate an action, so the user can ask for an action to be performed on it's behalf via a service - and in which case the user's project id is communicated via the token. In lieu of all this the quick answer is no. If you are taking a project id from the command line and you want to validate its existence then you have to ask keystone, but you should always be getting this information from a token. Jamie From: Brant Knudson [mailto:b...@acm.org] Sent: Friday, April 24, 2015 11:43 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German german.eichber...@hp.com wrote: All, Following up from the last Neutron meeting: If Neutron is performing an operation as an admin on behalf of a user that user's tenant-id (or project-id) isn't validated - in particular an admin can mistype and create object on behalf of non existent users. I am wondering how other projects (e.g. Nova) deal with that and if there is some API support in keystone to save us a round trip (e.g. authenticate admin + validate additional user-id). Not to long ago we got support in the auth_token middleware for a service token in addition to the user's token. The user token is sent in the x-auth-token header and the service token is sent in the x-service-token, and then fields from both tokens are available to the application (e.g., the user project is in HTTP_X_PROJECT_ID and the service token roles are in HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the server for the operation that required the service token to have the 'service' role, and what neutron could do is send the original user token in x-auth-token and send its own token as the service token. This seems to be what you're asking for here. - Brant Thanks, German __ OpenStack Development Mailing 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] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation
Hi, You could call GET project/project_id and verify that the project really exists in Keystone. But again by doing that you would be increasing load on Keystone server. When UUID tokens are being used, an additional call is needed to verify the token. If you add another call to this then it would be too much for Keystone server. So none of the other components as of now do this i.e. verify the existence of the project. I don't know if there are any plans to address this. Cheers, Ajaya On Sat, Apr 25, 2015 at 4:25 AM, Eichberger, German german.eichber...@hp.com wrote: Hi Brant, Sorry, for being confusing earlier. We have operations an administrator/operator is performing on behalf of a user, e.g. “Create Loadbalancer X for user tenant-id 123”. Now we are not checking the tenant-id and are wondering how to make the operation more robust with kesyone’s help. Thanks, German *From:* Brant Knudson [mailto:b...@acm.org] *Sent:* Friday, April 24, 2015 11:43 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German german.eichber...@hp.com wrote: All, Following up from the last Neutron meeting: If Neutron is performing an operation as an admin on behalf of a user that user's tenant-id (or project-id) isn't validated - in particular an admin can mistype and create object on behalf of non existent users. I am wondering how other projects (e.g. Nova) deal with that and if there is some API support in keystone to save us a round trip (e.g. authenticate admin + validate additional user-id). Not to long ago we got support in the auth_token middleware for a service token in addition to the user's token. The user token is sent in the x-auth-token header and the service token is sent in the x-service-token, and then fields from both tokens are available to the application (e.g., the user project is in HTTP_X_PROJECT_ID and the service token roles are in HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the server for the operation that required the service token to have the 'service' role, and what neutron could do is send the original user token in x-auth-token and send its own token as the service token. This seems to be what you're asking for here. - Brant Thanks, German __ OpenStack Development Mailing 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] [magnum] New fedora 21 Atomic images available for testing
Excerpts from Steven Dake (stdake)'s message of 2015-04-23 23:27:00 +: Hi folks, I have spent the last couple of days trying to bring some sanity to the image building process for Magnum. I have found a tool which the Atomic upstream produces which allows a simple repeatable building process for Fedora Atomic images using any upstream repos of our choosing. I put in a kubernetes 0.15 COPR repo in this build. Please test and get back to me either on irc or the ML. The image is available for download from here: https://fedorapeople.org/groups/magnum/fedora-21-atomic-3.qcow2.xzhttps://fedorapeople.org/groups/magnum/ Regards, -steve Hey Steve, Im wondering if youve looked at diskimage-builder for building these images? Theres already a fair amount of openstack projects using this to make disk images and I imagine it wouldnt be too hard for it to build images of the type you need... Cheers, Greg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum] New fedora 21 Atomic images available for testing
On 04/26/2015 02:21 PM, Gregory Haynes wrote: Excerpts from Steven Dake (stdake)'s message of 2015-04-23 23:27:00 +: Hi folks, I have spent the last couple of days trying to bring some sanity to the image building process for Magnum. I have found a tool which the Atomic upstream produces which allows a simple repeatable building process for Fedora Atomic images using any upstream repos of our choosing. I put in a kubernetes 0.15 COPR repo in this build. Please test and get back to me either on irc or the ML. The image is available for download from here: https://fedorapeople.org/groups/magnum/fedora-21-atomic-3.qcow2.xzhttps://fedorapeople.org/groups/magnum/ Regards, -steve Hey Steve, Im wondering if youve looked at diskimage-builder for building these images? Theres already a fair amount of openstack projects using this to make disk images and I imagine it wouldnt be too hard for it to build images of the type you need... Including Infra - which has been migrating to using it for all the image building needs in the gate. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum] New fedora 21 Atomic images available for testing
On 4/26/15, 11:21 AM, Gregory Haynes g...@greghaynes.net wrote: Excerpts from Steven Dake (stdake)'s message of 2015-04-23 23:27:00 +: Hi folks, I have spent the last couple of days trying to bring some sanity to the image building process for Magnum. I have found a tool which the Atomic upstream produces which allows a simple repeatable building process for Fedora Atomic images using any upstream repos of our choosing. I put in a kubernetes 0.15 COPR repo in this build. Please test and get back to me either on irc or the ML. The image is available for download from here: https://fedorapeople.org/groups/magnum/fedora-21-atomic-3.qcow2.xzhttps: //fedorapeople.org/groups/magnum/ Regards, -steve Hey Steve, Im wondering if youve looked at diskimage-builder for building these images? Theres already a fair amount of openstack projects using this to make disk images and I imagine it wouldnt be too hard for it to build images of the type you need... Cheers, Greg Greg, Yes of course I have looked at DIB. DIB does not support Fedora Atomic images. These images don¹t just put files in /etc and /usr/bin etcŠ They place all files in one directory and keep a table mapping the files to the correct location. Please have a look at the disk format by opening the disk via guestmount. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] Need guidance - functional tests and rootwrap
The tox.ini entry for dsvm-fullstack sets OS_ROOTWRAP_CMD=sudo
{envbindir}/neutron-rootwrap {envdir}/etc/neutron/rootwrap.conf (and
something similar for rootwrap-daemon).
Is this the answer you were looking for, or are you saying OS_ROOTWRAP_CMD
doesn't appear to be honoured in your case?
- Gus
On Sat, 25 Apr 2015 at 00:45 Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/24/2015 04:02 PM, Ihar Hrachyshka wrote:
On 04/24/2015 03:48 PM, Paul Michali wrote:
Hi, I'm floundering a bit, and could use some guidance on
this...
For the neutron-vpnaas repo, I am trying to modify the
functional jobs (dsvm-functional and dsvm-functional-sswan) to
act in a similar manner to neutron, where devstack is configured,
but no stacking is performed.
I'm trying to do the same thing and have the jobs doing the
configuration only. Side note: there are two jobs, because there
are currently two reference implementations of VPN drivers, each
of which require a different IPSec package installed.
As part of this setup, in tox.ini, the neutron
deploy_rootwrap.sh script is called which places the rootwrap
filters and config file in the repo's
.tox/dsvm-functional/etc/neutron/ area (or
./tox/dsvm-functional-sswan/etc/neutron/).
Now, the issue I see is that tests trying to run ip commands,
are failing saying that the config file is invalid:
ERROR neutron_vpnaas.services.vpn.common.netns_wrapper [-]
Incorrect configuration file: /etc/neutron/rootwrap.conf
As you can see, this is trying to access the rootwrap.conf in
/etc/neutron and not the one in
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functioanl-sswan/etc/neutron/
.
For Neutron, how is the dsvm-functional job directing the
rootwrap daemon to use the files in the repo's .tox area?
It may be the case that oslo_config.cfg.find_config_files is
involved, doing its dirty config file autodiscovery job. May I ask
you to try out [1] that is designed to avoid it, and report back
with the result?
[1]:
https://review.openstack.org/#/c/172354/1/neutron/tests/base.py
Nah, that won't help for rootwrap. It does not even rely on
oslo.config, and the config file is passed with CLI args. I recommend
checking what's cfg.CONF.AGENT.root_helper_daemon value inside your
failing test cases to see whether tox properly passed
OS_ROOTWRAP_DAEMON_CMD, with {envdir} properly substituted.
Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJVOlbTAAoJEC5aWaUY1u57zkgH+wa5yvVYqglN+B7qpkIfR5QB
5X+6fh9O2KNV8qkDkSKwfRgqs8UouNGOO39zYcgG/QOlqfRKv9ROGkLyNzRihaRg
ynmDSiXVSiW/wnW+R8ymBSFiU30O88jtlBxlwYYUlz1pdbdQxpVUWPspvYrYU95O
zdBkifNEvDpYhb/DySq6dlOJB+VQ2IlnCsBhkZeiKQz/T2fnYDoTNZ05beLZez2s
kntPkYXG11dYRDYQxF76A3fFSboiy2TkX7wl8wK29WQI350gk3Fc/ob0QlMYR0Kf
IcvEHh+g7cvkZkcX3vn3dDTnI9WUorDUjvnvfw8PGvJaB/edniUBjSC6HHmhBv8=
=Pg+J
-END PGP SIGNATURE-
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing 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] Sahara HA discussion
Hi, Sergey we are in the same phase like you, I have noticed that there is a topic in the https://etherpad.openstack.org/p/sahara-liberty-proposed-sessions currently we decide to do the HA on service level (HDFS etc), here is the doc http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/admin_ha.html but I have heard that you will focus on the node level HA? for example. like rebuild a node when one node is failed? 2015-04-23 16:33 GMT+08:00 Sergey Reshetnyak sreshetn...@mirantis.com: Hi Lu I'm going to start working on HA support for Sahara for HDP and CDH plugins. Now I didn't create specs or blueprints about HA. Also I don't have code for HA support. When are you going to start implement HA for CDH? Thanks Sergey 2015-04-20 4:06 GMT+03:00 Lu, Huichun huichun...@intel.com: Hi Sergey Last IRC meeting, I heard that you are currently working on the HA on CDH and HDP, by chance that we just raise a bp about HA, so do you have any bp or spec about this topic? I think it’s interesting about this topic, we can have some discussion. https://blueprints.launchpad.net/sahara/+spec/cdh-ha-support thx Sergey ^^ __ OpenStack Development Mailing 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] [all] Gerrit currently down
Our CI system is currently not processing any events. This means that no
new check or gate jobs get started.
Uploading new patches and reviewing is working fine.
But new patches uploaded will not get checked and patches approved will
not get gated and merge - and recheck will not help either.
We have to wait until somebody with root access to the CI systems can
fix the problem. Somebody from the infra team will tell you once the
systems is up and what needs to be done with any changes changed during
the downtime,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing 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][Keystone] [Nova] How to validate teanant-id for admin operation
On Sunday, April 26, 2015, Jamie Lennox jamielen...@redhat.com wrote: - Original Message - From: German Eichberger german.eichber...@hp.com javascript:; To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org javascript:; Sent: Saturday, 25 April, 2015 8:55:23 AM Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation Hi Brant, Sorry, for being confusing earlier. We have operations an administrator/operator is performing on behalf of a user, e.g. “Create Loadbalancer X for user tenant-id 123”. Now we are not checking the tenant-id and are wondering how to make the operation more robust with kesyone’s help. Thanks, German Not to speak for Brant, but i think the confusion here is why you are doing this. From my perspective you should never be in a position where the admin has to enter a raw project id like that. I think the problem here is the assumption of an all powerful admin user, and i'd encourage you to change your policy files to scrap that idea. A role is granted on a project and this project is mentioned in the token. If there is some role that is provided that lets you perform operations outside of the project id specified in that token please file a bug and i'd consider marking it a security issue. The X-Service-Token concept will allow for the combination of a user token and a service token to authenticate an action, so the user can ask for an action to be performed on it's behalf via a service - and in which case the user's project id is communicated via the token. In lieu of all this the quick answer is no. If you are taking a project id from the command line and you want to validate its existence then you have to ask keystone, but you should always be getting this information from a token. +1 all the above Jamie From: Brant Knudson [mailto:b...@acm.org javascript:;] Sent: Friday, April 24, 2015 11:43 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German german.eichber...@hp.com javascript:; wrote: All, Following up from the last Neutron meeting: If Neutron is performing an operation as an admin on behalf of a user that user's tenant-id (or project-id) isn't validated - in particular an admin can mistype and create object on behalf of non existent users. I am wondering how other projects (e.g. Nova) deal with that and if there is some API support in keystone to save us a round trip (e.g. authenticate admin + validate additional user-id). Not to long ago we got support in the auth_token middleware for a service token in addition to the user's token. The user token is sent in the x-auth-token header and the service token is sent in the x-service-token, and then fields from both tokens are available to the application (e.g., the user project is in HTTP_X_PROJECT_ID and the service token roles are in HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the server for the operation that required the service token to have the 'service' role, and what neutron could do is send the original user token in x-auth-token and send its own token as the service token. This seems to be what you're asking for here. - Brant Thanks, German __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] moving sqlite migration scripts to tests
On 18-Apr-15 02:41, Mike Bayer wrote: On 4/17/15 1:29 PM, Zane Bitter wrote: On 16/04/15 04:05, Anant Patil wrote: Hi, Sometime back we had a discussion on IRC regarding sqlite migration scripts. Since sqlite is mostly used for testing, we were thinking about moving the sqlite migration related code to tests folder and keep the migrate_repo sane (with only production code). There was utility class[1] added recently for helping with sqlite migrations and there were questions on the location of that class. The utility lives in heat/db/sqlalchemy folder and since it is used only for testing, it should probably live somewhere in the tests folder (like tests/migrate_repo? ) along with the sqlite migration scripts. It would be better if we have a separate path for testing code and depending on the configured DB back-end (for example, sqlite), we pass the appropriate path (something like tests/migrate_repo for sqlite) to oslo_migration.db_sync(). If it is okay to assume that sqlite is *always* used for testing, then IMO, we should re-factor the migration scripts. Please help us with your thoughts. [1] https://github.com/openstack/heat/blob/master/heat/db/sqlalchemy/utils.py - Anant You're correct that we can assume SQLite is only used for tests. However, I'm not convinced that we need to change the migration scripts... it's bad enough that we have to write two different migrations in many cases (and totally unclear to me how this is testing anything useful), but having to write them in two different places seems even worse. I'd be more interested in seeing a change whereby we stop doing pointless migrations on an empty SQLite DB prior to testing and just generate it from the model. I think we can rely on the migration tests that run against the actual mariadb/postgresql clients to test the migrations themselves - we effectively already are in many cases. We definitely should be generating to SQLite from the model directly for all projects without using migrations. I'm going to be pushing more for migrating projects from sqlalchemy-migrate to alembic, and while Alembic does do SQLite migrations now, it would be cleaner if we just didn't bother. There are also new features in the oslo.db test base that can allow a schema to be created only once for lots of tests, where the tests themselves run under a transaction that's rolled back during teardown; the table structures stay in place. We should be looking to use that base for most/all of our DB-active tests. cheers, Zane. __ OpenStack Development Mailing 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 +1 for moving to Alembic as it abstracts out the migration logic, and that will help Heat have a cleaner code base for migrations. __ OpenStack Development Mailing 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][Cinder] get voting permissions for Infortrend 3rd-party CI
Dear Sirs, 1. Test 3rd CI connectivity History on ci-sandbox https://review.openstack.org/#/c/177134/ 1st log: http://openstack.infortrend.com/34/177134/1/check/noop-check-communication/75112cd/ 2nd log (recheck): http://openstack.infortrend.com/34/177134/1/check/noop-check-communication/2cd24d7/ 3rd log (recheck test failed case): http://openstack.infortrend.com/34/177134/1/check/noop-check-communication/2444050/ 2. Test 3rd CI tempest with Infortrend Storage History on ci-sandbox https://review.openstack.org/#/c/177182/ log: http://openstack.infortrend.com/82/177182/1/check/dsvm-tempest-ift-cinder-iscsi-volume/4c432ac/ Blueprint: https://blueprints.launchpad.net/cinder/+spec/infortrend-iscsi-fc-volume-driver 3rd party CI wiki: https://wiki.openstack.org/wiki/ThirdPartySystems/Infortrend_Storage_CI Please inform me if anything is incorrect or lost. Thanks a lot! Best Regards, Ryan Chiang SAN Software Design Sec. II #7074 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
