Re: [openstack-dev] [Security] Midcycle Announcement
Clark, Robert Graham wrote: The Security Project will be holding it’s mid-cycle meet-up in Seattle 1st to 4^th . [..] Please add it to https://wiki.openstack.org/wiki/Sprints for reference. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Sahara] Why Sahara request user to give username/password for accessing the job binary in Swift ?
Thanks. This is very helpful. A little more questions about how to config: 1. What should be set in [keystone_authtoken] in sahara.conf ? As code at https://github.com/openstack/sahara/blob/master/sahara/utils/proxy.py#L165. Looks like admin_user admin_password admin_tenant_name must be set, and the proxy_domin must be created by the admin_user. But after a clean devstack installation, my sahara.conf only has: [keystone_authtoken] signing_dir = /var/cache/sahara cafile = /opt/stack/data/ca-bundle.pem auth_uri = http://192.168.6.91:5000 project_domain_id = default project_name = service user_domain_id = default password = 123456 username = sahara auth_url = http://192.168.6.91:35357 auth_plugin = password I'm really confused, these configurations all looks very similar. 2. More other configurations must be set ? Such as: [DEFAULT] use_identity_api_v3= True Thanks. -chen -Original Message- From: michael mccune [mailto:m...@redhat.com] Sent: Friday, June 26, 2015 8:55 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Sahara] Why Sahara request user to give username/password for accessing the job binary in Swift ? On 06/25/2015 09:54 PM, Li, Chen wrote: Thanks for the reply. My puzzle here is : I create containers objects by my own, why other users can access them ? As mentioned in your article[1], the domain sahara_proxy is created by user admin in project openstack. But I'm working under user demo in project demo, and other people are in other project with other users. those are good questions Chen. to address your puzzle, if you create containers/objects in your own project then others cannot access them without your credentials. but keep in mind that any user in your project can also view those objects. there are 2 main reasons we created the proxy domain feature 1. increase security. by using proxy domains, sahara is not responsible for storing a user's credentials in its database, or distributing them to the nodes of the cluster. 2. convenience. when creating several job binaries and data sources you will need to enter credentials for each one. this is not necessary with the proxy domain usage. with that being said, it may not be a feature that fits well with your usage pattern. as to the question about admin project versus demo project, the domain is an extra layer of scoping that can be applied to tokens. it does not map 1:1 with projects as it is at a different layer than the project scoping. so, it is possible to have users from different domains accessing the same project, in this case by using trusts. on the security issue, using proxy users also helps to create another layer of separation in the event that an intruder were able to gain the credentials stored in sahara or on the cluster nodes. for example, if not using proxy domains, a user will store their credentials in sahara's database to access their objects. if an intruder learns this information they will have access to everything that the user does. but, if using proxy domains then the only credentials to be gained are those of the proxy user which has its permissions limited by the trust. additionally the trust will be removed when the job is complete. i hope this clears things up =) regards, mike __ OpenStack Development Mailing 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] - Proposing Miguel Angel Ajo for the Control Plane core team
Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year has been important in making the reference implementation reliable. Existing cores, please vote +1/-1 for his addition to the team. Cheers! 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html 2. http://stackalytics.com/report/contribution/neutron/30 http://stackalytics.com/report/contribution/neutron/60 http://stackalytics.com/report/contribution/neutron/90 -- 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] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team
A huge +1 From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, July 6, 2015 at 1:02 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year has been important in making the reference implementation reliable. Existing cores, please vote +1/-1 for his addition to the team. Cheers! 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html 2. http://stackalytics.com/report/contribution/neutron/30https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_report_contribution_neutron_30d=BQMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=wtlrQoPt-2_Vjl5Rdv1KGgEI39ZxWLjLaTIBoLekdAUs=dugIWGpPBq2bNc4K-YDr5xpXa9QNJJBcyuTJQSyqB9Ue= http://stackalytics.com/report/contribution/neutron/60https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_report_contribution_neutron_60d=BQMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=wtlrQoPt-2_Vjl5Rdv1KGgEI39ZxWLjLaTIBoLekdAUs=w_ZyyB6TTx5iVNO4K6Y7XVvHFWUqSKzTGqLpYmx9tM0e= http://stackalytics.com/report/contribution/neutron/90https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_report_contribution_neutron_90d=BQMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=wtlrQoPt-2_Vjl5Rdv1KGgEI39ZxWLjLaTIBoLekdAUs=MWwJYp2X4xncnFCsxCdFCRTvLd9t6cbnbLnwsEgVaxce= -- 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
[openstack-dev] [trove]The patch from 191859 breaks the compatibility with python 2.6
Hi all,
We're deploying trove with python 2.6 in production. And the latest code from
https://review.openstack.org/#/c/191859 has broken the compatible with python
2.6.
The actual code which causes it is in
trove/guestagent/common/operating_system.py and looks like thest. Python 2.6
has syntax error for this list expression.
def list_files_in_directory(root_dir, recursive=False, pattern=None):
return {os.path.abspath(os.path.join(root, name))
for (root, _, files) in os.walk(root_dir, topdown=True)
if recursive or (root == root_dir)
for name in files
if not pattern or re.match(pattern, name)}
It would be great for anyone to fix it for both python 2.6 and 2.7, right?
- tobe__
OpenStack Development Mailing 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] [Security] Midcycle Announcement
-Original Message- From: Thierry Carrez [mailto:thie...@openstack.org] Sent: 06 July 2015 09:12 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Security] Midcycle Announcement Clark, Robert Graham wrote: The Security Project will be holding it's mid-cycle meet-up in Seattle 1st to 4^th . [..] Please add it to https://wiki.openstack.org/wiki/Sprints for reference. Done - Also created an accompanying wiki page: https://wiki.openstack.org/wiki/Sprints/SecurityLibertySprint __ OpenStack Development Mailing 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]Subnet's dns nameserver doesn'torderby input
Sorry, this page is also not found... I found a bug report like my thought: https://bugs.launchpad.net/neutron/+bug/1460786 -- Original -- From: shihanzhangayshihanzh...@126.com; Date: Mon, Jul 6, 2015 05:37 PM To: OpenStack Development Mailing List (not for usage questions)openstack-dev@lists.openstack.org; Subject: Re: [openstack-dev] [Neutron]Subnet's dns nameserver doesn'torderby input hi, Zhi Chang, this link: #https://bugs.launchpad.net/neutron/+bug/1218629 is ok. At 2015-07-06 17:13:12, Zhi Chang chang...@unitedstack.com wrote: Thanks for your reply. Could you send the html link again? This does maybe doesn't exist. Thx Zhi Chang -- Original -- From: Oleg Bondarevobonda...@mirantis.com; Date: Mon, Jul 6, 2015 04:50 PM To: OpenStack Development Mailing List (not for usage questions)openstack-dev@lists.openstack.org; Subject: Re: [openstack-dev] [Neutron]Subnet's dns nameserver doesn't orderby input Hi, Currently there is no dns servers prioritization for subnets in Neutron. There is an opened bug for this: https://bugs.launchpad.net/neutron/+bug/1218629 Thanks, Oleg On Mon, Jul 6, 2015 at 11:21 AM, Zhi Chang chang...@unitedstack.com wrote: Hi, all Subnet's nameserver is out of order. That is to say, cmd neutron subnet-update [subnet-id] dns_nameservers list=true 1.2.3.4 5.6.7.8 and neutron subnet-update [subnet-id] dns_nameservers list=true 5.6.7.8 1.2.3.4 is same. I think that we often have two or more dns nameservers, one is a main nameserver, another is a backup. Therefore, I think we should make difference of the above command. Does anyone have ideas? Thx Zhi Chang __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__ OpenStack Development Mailing 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][packaging] Adding files to /etc in a package
On 07/02/2015 03:59 AM, Thomas Goirand wrote: On 07/02/2015 05:51 AM, Robert Collins wrote: On 2 July 2015 at 13:26, Thomas Goirand z...@debian.org wrote: On 07/02/2015 02:07 AM, Tony Breeds wrote: On Wed, Jul 01, 2015 at 11:07:30PM +, Perry, Sean wrote: BTW, see dh_bash-completion from the debhelper package. When in doubt about packaging on a deb based distro look at the debhelper tools source (which is perl). -Original Message- From: Perry, Sean Sent: Wednesday, July 01, 2015 4:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: RE: [openstack-dev] [all][packaging] Adding files to /etc in a package According to Debian standards (which Ubuntu follows mostly) if a package ships bash completion information that file belongs in /etc/bash_completion.d with a file named after the package. You can look in that dir on an Ubuntu/debian box and see the setup. Right, but I'm talking about python packaging. Which is certainly closely related to system/distribution packaging, but lacks a lot of the machinery to get it right. Correct. Python packaging is made for packaging ... python! Not configuration files and other system bits. I'm with you there. BUT. Python programs use configuration files. And Python programs provide daemons. Its entirely reasonable and expected within the context of a given program that 'sudo make install' or 'sudo setup.py install' or ... any number of variations should make the program be usable by all users of the system that its installing it into. I'm going to presume we agree on that in the rest my reply. You may want to stop here if we don't agree about that. We do agree. The issue being that there's no universal way to do things, and different policy depending on the unix vendor and the way package is designed. Right, so ideally under such a situation the python installer would allow for override of logical constructs, which could just be set in a debian/control or spec file. Perl actually has a quite good model here with their install toolchain - http://perldoc.perl.org/ExtUtils/MakeMaker.html#INSTALL_BASE I think the crux of the problem is that python installers are not system aware at all. They assume they are only libraries and scripts, and the moment it gets more complicated than that the python install toolchain just shrugs and passes the buck. :( It would be really nice to get away from that so that. BASH_COMPLETION_DIR=... python setup.py install Would be the user experience to get things into a specific directory. Realize, this is a much larger effort to teach python installation tools about more than LIB and BIN, which is all they understand today. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] Use devstack/master to install older releases
On 07/01/2015 04:16 AM, Jordan Pittier wrote: Hi, On Wed, Jul 1, 2015 at 12:35 AM, Dean Troyer dtro...@gmail.com mailto:dtro...@gmail.com wrote: On Tue, Jun 30, 2015 at 7:04 AM, Emmanuel Cazenave cont...@emcaz.fr mailto:cont...@emcaz.fr wrote: My first approach was to use devstack/icehouse to install swift/icehouse, devstack/juno for swift/juno, etc This is the only approach that is sane... I am now trying to use devstack/master in every cases because I need this : https://review.openstack.org/#/c/115307/ which allow not to install nova+glance which I don't need at all, and whose installation takes a really long time. We would probably consider a backport of that to DevStack Juno, but Icehouse is effectively EOL and we will be removing that branch soon (days or weeks, not months). I've proposed https://review.openstack.org/#/c/197464/ to backport that patch to Juno. Thanks, +A. -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] [Neutron]Subnet's dns nameserver doesn't order by input
Hi, all Subnet's nameserver is out of order. That is to say, cmd neutron subnet-update [subnet-id] dns_nameservers list=true 1.2.3.4 5.6.7.8 and neutron subnet-update [subnet-id] dns_nameservers list=true 5.6.7.8 1.2.3.4 is same. I think that we often have two or more dns nameservers, one is a main nameserver, another is a backup. Therefore, I think we should make difference of the above command. Does anyone have ideas? Thx Zhi Chang__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat][Oslo] Versioned objects compatibility mode
On Mon, Jun 22, 2015 at 5:40 AM, Jastrzebski, Michal michal.jastrzeb...@intel.com wrote: Hello, I wanted to start discussion about versioned objects backporting for conductor-less projects. In Vancouver we discussed compatibility mode, which works like that: Dan's blog post suggests that Nova already requires two restarts: http://www.danplanet.com/blog/2015/06/26/upgrading-nova-to-kilo-with-minimal-downtime/ I added a bp/spec for this in Heat: https://review.openstack.org/196670 There is also an approved spec in Cinder: https://review.openstack.org/192037 which, to avoid restarts, stores the configuration in the DB. This places a requirement for all services to have a direct access to the database, so it can't be used in all projects. Thang Pham also wrote a Cinder POC implementation: https://review.openstack.org/184404. / 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
[openstack-dev] [Security] Midcycle Announcement
Hi All, The Security Project will be holding it's mid-cycle meet-up in Seattle 1st to 4th. Topic for the mid-cycle include: *A sprint on v2 of the Security Guide *Bootstrapping OpenStack Crypto Tracking and Verification Work *Security Face - building the appropriate web pages for security *Bandit Sprints *Anchor Sprints *Enhancing the developer guidelines If you have an active interest in OpenStack Security and would like to come along please add your name to the etherpad, where you can also add any topics you think we should discuss. https://etherpad.openstack.org/p/security-liberty-midcycle -Rob __ OpenStack Development Mailing 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] Error starting designate (DNSaaS)
Finally, I got to install and start designate when moving to a trusty
Ubuntu image:
*https://vagrantcloud.com/ubuntu/boxes/trusty64
https://vagrantcloud.com/ubuntu/boxes/trusty64*
I did not succeed with precise64 (also Ubuntu):
*http://files.vagrantup.com/precise64.box
http://files.vagrantup.com/precise64.box*
On Thu, Jul 2, 2015 at 6:36 PM, Jaime Fernández jjja...@gmail.com wrote:
Thanks Tim for the info.
I've tried the installation of designate using the recommended guide (
http://docs.openstack.org/developer/designate/install/ubuntu-dev.html) in
a vagrant with ubuntu (precise64 image).
I've found a problem in the same step. However, now the error is different:
$ designate-manage database sync
No handlers could be found for logger oslo_config.cfg
usage: designate [-h] [--config-dir DIR] [--config-file PATH] [--debug]
[--log-config-append PATH] [--log-date-format DATE_FORMAT]
[--log-dir LOG_DIR] [--log-file PATH] [--log-format
FORMAT]
[--nouse-syslog] [--nouse-syslog-rfc-format] [--noverbose]
[--syslog-log-facility SYSLOG_LOG_FACILITY] [--use-syslog]
[--use-syslog-rfc-format] [--verbose] [--version]
[--nodebug]
{powerdns} ...
designate: error: argument category: invalid choice: 'database' (choose
from 'powerdns')
I've tried with master branch and even with stable/kilo branch with the
same result.
I've also noticed that master branch requires a custom installation of
SQLAlchemy to avoid a version conflict:
*pip install SQLAlchemy==0.9.9*
I've contacted to #openstack-dns today and it looks like a dependency
problem. However, all the dependencies were installed successfully. For me
it's too hard to investigate the root of the problem. Tomorrow, I'll try to
pursue this issue again in IRC.
__
OpenStack Development Mailing 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] schedule instance based on CPU frequency ?
I propose a review to add it in cpu_info : https://review.openstack.org/#/c/197829/ 2015-07-03 21:37 GMT+08:00 Sylvain Bauza sba...@redhat.com: Le 03/07/2015 15:25, Jay Pipes a écrit : On 07/03/2015 06:32 AM, Sylvain Bauza wrote: Le 02/07/2015 21:40, Jay Pipes a écrit : On 07/01/2015 12:23 AM, ChangBo Guo wrote: thanks Dan and Jay, we don't need add new scheduler for that :-), what about provide cpu frequency to api /os-hypervisors, that means we can report this value automatically, the value can be used in high level mange tools. Meh, I'm not too big of a fan of the os-hypervisors extension. Actually, one might say I despise that extension :) That said, I suppose it should be possible to include the output of the CPU frequency in the cpu_info field there... Well, IMHO I don't like to have the Hypervisors API to be a Nagios-like view of the hypervisors world and I don't really much benefits of pusing the metrics up to the API. On the other hand, those monitor metrics are already sent as notifications on the bus [1] so a 3rd party tool can easily fetch them without necessarly needing to extend the API. Yeah, the difference here is that CPU frequency really isn't a metric... it's a static thing that doesn't change over time. Which is why I think it's OK to put it in cpu_info. Oh, you're right, it's a very static thing. If it's not a metric, then I would like to see it removed from the CPU monitor and provided in cpu_info then. -Sylvain Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- ChangBo Guo(gcb) __ OpenStack Development Mailing 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]Subnet's dns nameserver doesn't order by input
Hi, Currently there is no dns servers prioritization for subnets in Neutron. There is an opened bug for this: https://bugs.launchpad.net/neutron/+bug/1218629 Thanks, Oleg On Mon, Jul 6, 2015 at 11:21 AM, Zhi Chang chang...@unitedstack.com wrote: Hi, all Subnet's nameserver is out of order. That is to say, cmd neutron subnet-update [subnet-id] dns_nameservers list=true 1.2.3.4 5.6.7.8 and neutron subnet-update [subnet-id] dns_nameservers list=true 5.6.7.8 1.2.3.4 is same. I think that we often have two or more dns nameservers, one is a main nameserver, another is a backup. Therefore, I think we should make difference of the above command. Does anyone have ideas? Thx Zhi Chang __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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]Subnet's dns nameserver doesn't orderby input
Thanks for your reply. Could you send the html link again? This does maybe doesn't exist. Thx Zhi Chang -- Original -- From: Oleg Bondarevobonda...@mirantis.com; Date: Mon, Jul 6, 2015 04:50 PM To: OpenStack Development Mailing List (not for usage questions)openstack-dev@lists.openstack.org; Subject: Re: [openstack-dev] [Neutron]Subnet's dns nameserver doesn't orderby input Hi, Currently there is no dns servers prioritization for subnets in Neutron. There is an opened bug for this: https://bugs.launchpad.net/neutron/+bug/1218629 Thanks, Oleg On Mon, Jul 6, 2015 at 11:21 AM, Zhi Chang chang...@unitedstack.com wrote: Hi, all Subnet's nameserver is out of order. That is to say, cmd neutron subnet-update [subnet-id] dns_nameservers list=true 1.2.3.4 5.6.7.8 and neutron subnet-update [subnet-id] dns_nameservers list=true 5.6.7.8 1.2.3.4 is same. I think that we often have two or more dns nameservers, one is a main nameserver, another is a backup. Therefore, I think we should make difference of the above command. Does anyone have ideas? Thx Zhi Chang __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__ OpenStack Development Mailing 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] [puppet] [Nova] Do we really need to use rabbit_ha_queues parameter?
I have reviewed the git history and looks like we can just fix unit tests for puppet manifests. I'm going to do this. On Fri, Jul 3, 2015 at 1:03 PM, Timur Nurlygayanov tnurlygaya...@mirantis.com wrote: Hi all, I have updated puppet manifests for all OpenStack components to fix the logic of configuration of rabbit_ha_queues parameter [1] but Nova puppet unit tests failed because these tests expect that we will use rabbit_ha_queues=True for one-controller-node installations [2], [3]. Do we have some bugs in Nova which require to use rabbit_ha_queues even for installation with only one OpenStack controller node? Can we just fix unit tests or we have some reasons to use rabbit_ha_queues=True? Probably, we can use rabbit_ha_queues=True by default for any deployments? Thank you! [1] https://review.openstack.org/#/c/197013/ [2] http://logs.openstack.org/13/197013/3/check/gate-puppet-nova-puppet-unit-3.3/df55e9e/console.html [3] http://paste.openstack.org/show/338209/ -- Timur, Senior QA Engineer OpenStack Projects Mirantis Inc -- Timur, Senior QA Engineer OpenStack Projects Mirantis Inc __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron]Subnet's dns nameserver doesn't orderby input
hi, Zhi Chang, this link: #https://bugs.launchpad.net/neutron/+bug/1218629 is ok. At 2015-07-06 17:13:12, Zhi Chang chang...@unitedstack.com wrote: Thanks for your reply. Could you send the html link again? This does maybe doesn't exist. Thx Zhi Chang -- Original -- From: Oleg Bondarevobonda...@mirantis.com; Date: Mon, Jul 6, 2015 04:50 PM To: OpenStack Development Mailing List (not for usage questions)openstack-dev@lists.openstack.org; Subject: Re: [openstack-dev] [Neutron]Subnet's dns nameserver doesn't orderby input Hi, Currently there is no dns servers prioritization for subnets in Neutron. There is an opened bug for this: https://bugs.launchpad.net/neutron/+bug/1218629 Thanks, Oleg On Mon, Jul 6, 2015 at 11:21 AM, Zhi Chang chang...@unitedstack.com wrote: Hi, all Subnet's nameserver is out of order. That is to say, cmd neutron subnet-update [subnet-id] dns_nameservers list=true 1.2.3.4 5.6.7.8 and neutron subnet-update [subnet-id] dns_nameservers list=true 5.6.7.8 1.2.3.4 is same. I think that we often have two or more dns nameservers, one is a main nameserver, another is a backup. Therefore, I think we should make difference of the above command. Does anyone have ideas? Thx Zhi Chang __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] [mistral] Team meeting - 07/06/2015
Hi, This is a reminder that we’ll have a team meeting today at #openstack-meeting at 16.00 UTC. Agenda: Review action items Current status (progress, issues, roadblocks, further plans) Mistral Dashboard plans and blueprints Open discussion Add your own items either by replying to this email or modifying https://wiki.openstack.org/wiki/Meetings/MistralAgenda https://wiki.openstack.org/wiki/Meetings/MistralAgenda. Renat Akhmerov @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] weekly meeting #41
Hey Puppeteers! Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC in #openstack-meeting-4: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150707 Please add additional items you'd like to discuss, See you there -- Emilien Macchi 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] [trove]The patch from 191859 breaks the compatibility with python 2.6
Hi,
Python 2.6 support was dropped in Kilo (for all of OpenStack). The patchset you
mention was just merged last week and will be in Liberty. Trove is no longer
being tested with Python 2.6 so it is likely things like this will continue to
occur going forward.
Regards,
Doug
From: 陈迪豪 chendi...@unitedstack.commailto:chendi...@unitedstack.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, July 6, 2015 at 6:16 AM
To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [trove]The patch from 191859 breaks the compatibility
with python 2.6
Hi all,
We're deploying trove with python 2.6 in production. And the latest code from
https://review.openstack.org/#/c/191859 has broken the compatible with python
2.6.
The actual code which causes it is in
trove/guestagent/common/operating_system.py and looks like thest. Python 2.6
has syntax error for this list expression.
def list_files_in_directory(root_dir, recursive=False, pattern=None):
return {os.path.abspath(os.path.join(root, name))
for (root, _, files) in os.walk(root_dir, topdown=True)
if recursive or (root == root_dir)
for name in files
if not pattern or re.match(pattern, name)}
It would be great for anyone to fix it for both python 2.6 and 2.7, right?
- tobe
__
OpenStack Development Mailing 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] virtual mid-cycle planning
On Fri, 3 Jul 2015, Jeremy Stanley wrote: On 2015-07-03 14:54:28 +0100 (+0100), Chris Dent wrote: Does a virtual mid-cycle count? This one is not quite a sprint. It's a bunch of meetings, held on google hangouts (falling back to other things if it is junk), schedule over a two day period with a strict agenda (forthcoming). [...] Given that meatspace mid-cycle events are listed at https://wiki.openstack.org/wiki/Sprints#Liberty_sprints and the VirtualSprints article is linked from the top of that page, it seems entirely appropriate. Ah, right on, done. I am yet another victim of term overloading. I've added Ceilometer to https://wiki.openstack.org/wiki/VirtualSprints with a link to https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle Ceilometer people: We need people to volunteer to be responsible for sessions. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ OpenStack Development Mailing 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] [keystone][all] Deprecating slash ('/') in project names
I mean project names. You can, for example, create a project today with a name like dev/tests. Em seg, 6 de jul de 2015 às 03:56, Sam Morrison sorri...@gmail.com escreveu: Do you mean project names or project IDs? Sam On 3 Jul 2015, at 12:12 am, Henrique Truta henriquecostatr...@gmail.com wrote: Hi everyone, In Kilo, keystone introduced the concept of Hierarchical Multitenancy[1], which allows cloud operators to organize projects in hierarchies. This concept is evolving in Liberty, with the addition of the Reseller use case[2], where among other features, it’ll have hierarchies of domains by making the domain concept a feature of projects and not a different entity: from now on, every domain will be treated as a project that has the “is_domain” property set to True. Currently, getting a project scoped token can be made by only passing the project name and the domain it belongs to, once project names are unique between domains. However with those hierarchies of projects, in M we intend to remove this constraint in order to make a project name unique only in its level in the hierarchy (project parent). In other words, it won’t be possible to have sibling projects with the same name. For example. the following hierarchy will be valid: A - project with the domain feature /\ B C - “pure” projects, children of A | | A B - “pure” projects, children of B and C respectively Therefore, the cloud user faces some problems when getting a project scoped token by name to projects A or B, since keystone won’t be able to distinguish them only by their names. The best way to solve this problem is providing the full hierarchy, like “A/B/A”, “A/B”, “A/C/B” and so on. To achieve this, we intend to deprecate the “/” character in project names in Liberty and prohibit it in M, removing/replacing this character in a database migration**. Do you have some strong reason to keep using this character in project names? How bad would it be for existing deploys? We’d like to hear from you. Best regards, Henrique ** LDAP as assignment backend does not support Hierarchical Multitenancy. This change will be only applied to SQL backends. [1] http://specs.openstack.org/openstack/keystone-specs/specs/juno/hierarchical_multitenancy.html [2] http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html ___ OpenStack-operators mailing list 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
Re: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team
+1! - Original Message - A huge +1 From: Kevin Benton blak...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Monday, July 6, 2015 at 1:02 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year has been important in making the reference implementation reliable. Existing cores, please vote +1/-1 for his addition to the team. Cheers! 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html 2. http://stackalytics.com/report/contribution/neutron/30 http://stackalytics.com/report/contribution/neutron/60 http://stackalytics.com/report/contribution/neutron/90 -- 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 __ OpenStack Development Mailing 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] - Proposing Miguel Angel Ajo for the Control Plane core team
Big +1 On Mon, Jul 6, 2015 at 3:43 PM, Assaf Muller amul...@redhat.com wrote: +1! - Original Message - A huge +1 From: Kevin Benton blak...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Monday, July 6, 2015 at 1:02 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year has been important in making the reference implementation reliable. Existing cores, please vote +1/-1 for his addition to the team. Cheers! 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html 2. http://stackalytics.com/report/contribution/neutron/30 http://stackalytics.com/report/contribution/neutron/60 http://stackalytics.com/report/contribution/neutron/90 -- 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 __ OpenStack Development Mailing 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][packaging] Adding files to /etc in a package
On 2015-07-06 06:48:09 -0400 (-0400), Sean Dague wrote: [...] Realize, this is a much larger effort to teach python installation tools about more than LIB and BIN, which is all they understand today. There was a recentish thread on distutils-sig which felt like it was headed in the right direction with a plan to lay that groundwork: https://mail.python.org/pipermail/distutils-sig/2015-April/026222.html -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team
+1 On Mon, Jul 6, 2015 at 5:02 AM, Kevin Benton blak...@gmail.com wrote: Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year has been important in making the reference implementation reliable. Existing cores, please vote +1/-1 for his addition to the team. Cheers! 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html 2. http://stackalytics.com/report/contribution/neutron/30 http://stackalytics.com/report/contribution/neutron/60 http://stackalytics.com/report/contribution/neutron/90 -- 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 __ OpenStack Development Mailing 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] [mistral] Task explicit parameters
Hi, I came up with the proposal for “Task explicit parameters” blueprint ([1]) and created an etherpad for discussing it ([2]). [1] https://blueprints.launchpad.net/mistral/+spec/mistral-explicit-task-parameters https://blueprints.launchpad.net/mistral/+spec/mistral-explicit-task-parameters [2] https://etherpad.openstack.org/p/mistral-explicit-task-parameters https://etherpad.openstack.org/p/mistral-explicit-task-parameters Please take a look at leave your comments/questions. Thanks Renat Akhmerov @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team
+1 2015-07-06 19:02 GMT+09:00 Kevin Benton blak...@gmail.com: Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year has been important in making the reference implementation reliable. Existing cores, please vote +1/-1 for his addition to the team. Cheers! 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html 2. http://stackalytics.com/report/contribution/neutron/30 http://stackalytics.com/report/contribution/neutron/60 http://stackalytics.com/report/contribution/neutron/90 -- 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 __ OpenStack Development Mailing 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] [Infra] Meeting Tuesday July 7th at 19:00 UTC
Super I will look forward to meet anyone. Remo Inviato da Outlook On Mon, Jul 6, 2015 at 12:34 PM -0700, Elizabeth K. Joseph l...@princessleia.com wrote: Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday July 7th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend. In case you missed it or would like a refresher, the meeting minutes and full log from our last meeting are available here: Minutes: http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-06-30-19.01.html Minutes (text): http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-06-30-19.01.txt Log: http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-06-30-19.01.log.html -- Elizabeth Krumbach Joseph || Lyz || pleia2 ___ OpenStack-Infra mailing list openstack-in...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra !DSPAM:1,559ad842225361418114895!__ OpenStack Development Mailing 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] [grenade] future direction on partial upgrade support
On 6 July 2015 at 13:13, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-07-06 11:54:45 -0700 (-0700), Armando M. wrote: [...] For what I can tell, Joe was kind to set the infra to start gathering data on the reliability of the multi-node jobs, but they are clearly flaky [1], and currently broken. [...] Well, a check-.* pass rate of 25% is likely explained by running against proposed bad changes (after all these are running in the check pipeline, not the gate). The recent 100% failure we think will be fixed with a new release of glean incorporating https://review.openstack.org/198576 since we recently started exceeding the 64-byte HOST_NAME_MAX on our test platforms. Thanks for the heads-up, Jeremy. That said, the rate is still remarkably higher as a like-for-like comparison. I don't think we have a way to compare the rate on the gate pipeline, if I am not mistaken, but that's besides the point of my attempt at reviving this discussion. Cheers, Armando -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Sahara] Why Sahara request user to give username/password for accessing the job binary in Swift ?
hi chen, responses inline On 07/06/2015 04:38 AM, Li, Chen wrote: Thanks. This is very helpful. A little more questions about how to config: 1. What should be set in [keystone_authtoken] in sahara.conf ? As code at https://github.com/openstack/sahara/blob/master/sahara/utils/proxy.py#L165. Looks like admin_user admin_password admin_tenant_name must be set, and the proxy_domin must be created by the admin_user. But after a clean devstack installation, my sahara.conf only has: [keystone_authtoken] signing_dir = /var/cache/sahara cafile = /opt/stack/data/ca-bundle.pem auth_uri = http://192.168.6.91:5000 project_domain_id = default project_name = service user_domain_id = default password = 123456 username = sahara auth_url = http://192.168.6.91:35357 auth_plugin = password I'm really confused, these configurations all looks very similar. that's a good question, i'm not sure what devstack does by default when creating sahara's configuration. i notice that in my local configuration file i do have values for admin_user, admin_password, and admin_tenant_name, but these were not generated by devstack. i wonder if we have an error or perhaps there are default values for these? as for the proxy domain options, use_domain_for_proxy_users and proxy_user_domain_name, these must be added by the administrator (you) for devstack, and they must be in the DEFAULT section. in devstack you could set these parameters by adjusting your local.conf to contain something like: [[post-config|$SAHARA_CONF_FILE]] [DEFAULT] use_domain_for_proxy_users=True proxy_user_domain_name=sahara_proxy of course, changing sahara_proxy to the name of the proxy domain you have created for use. 2. More other configurations must be set ? Such as: [DEFAULT] use_identity_api_v3= True i think using v3 is a good idea with this feature. i haven't tested it in v2, but i probably should and make some notes to the documentation accordingly. thanks! regards, mike __ OpenStack Development Mailing 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] [TripleO] diskimage-builder 1.0.0
Excerpts from James Slagle's message of 2015-06-30 15:30:49 +: On Mon, Jun 29, 2015 at 8:44 AM, Gregory Haynes g...@greghaynes.net wrote: Hello all, DIB has come a long way and we seem to have a fairly stable interface for the elements and the image creation scripts. As such, I think it's about time we commit to a major version release. Hopefully this can give our users the (correct) impression that DIB is ready for use by folks who want some level of interface stability. AFAICT our bug list does not have any major issues that might require us to break our interface, so I dont see any harm in 'just going for it'. If anyone has input on fixes/features we should consider including before a 1.0.0 release please speak up now. If there are no objections by next week I'd like to try and cut a release then. :) Sounds good to me. I think the stable interfaces also includes the elements expected environment variables. It probably makes sense to document somewhere what the stable interfaces are, so that people doing releases know how to version the release appropriately based on any changes to those interfaces. Should we also remove the deprecated disk-image-get-kernel prior to the 1.0.0? There's a few other deprecations as well (map-packages), but I don't think we ever fully moved off of that in dib itself. Both are great ideas. I've created [1] and [2] for this. 1: https://review.openstack.org/#/c/198810/ 2: https://review.openstack.org/#/c/198814/ __ OpenStack Development Mailing 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] [puppet] First Sprint proposal
Hi, I would like to organize our first sprint for contributing to our Puppet OpenStack modules. It will happen in Red Hat Montreal (Canada) office, during 3 days. If you're interested to participate, please find the slots that may work for you [1]. Any slot suggestion is welcome though. Also, please bring on the etherpad any topics we should work on together [2]. We will groom topics during a meeting and prepare the agenda before the sprint. [1] http://doodle.com/xk2sfgu4xsi4y6n4r46t7u9k [2] https://etherpad.openstack.org/p/puppet-liberty-mid-cycle Regards, -- Emilien Macchi 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
[openstack-dev] [all][api] New API Guidelines ready for cross project review
Hi All, We have 7 API Guidelines that are ready for a final review. 1. Add section clarifying PUT vs PATCH semantics https://review.openstack.org/#/c/183945/ 2. Adding 5xx guidance https://review.openstack.org/#/c/183698/ 3. Adds a small update to tagging guidance https://review.openstack.org/#/c/187891/ 4. Add the description of GET method https://review.openstack.org/#/c/185180/ 5. Adds clarification and example to 500 guidance https://review.openstack.org/#/c/190064/ 6. add subsection around caching behavior and http https://review.openstack.org/#/c/183523/ 7. add section describing method use in http https://review.openstack.org/#/c/189738/ If the API Working Group hasn’t received any further feedback, we’ll merge them on July 13. Thanks, Everett __ OpenStack Development Mailing 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] App Catalog IRC meeting minutes - 7/2/2015
Thanks as always to those of you joining in the conversation regarding the App Catalog. We are working on building a Horizon plugin right now which will allow operators to include a browsable/searchable pane of catalog contents (fetched from http://apps.openstack.org, or your own local version of the App Catalog.) In order to support that quickly, I'm also working on extending the catalog to support additional asset types [1]. If you're interested in helping this work from the Horizon team please join us here on the mailing list or on IRC. In fact, same goes for any other project interested in promoting their things that run on OpenStack. Please join us on #openstack-app-catalog during the week, or next Thursday for our next weekly meeting! [1]: https://blueprints.launchpad.net/app-catalog/+spec/expand-asset-types = #openstack-meeting-3: app-catalog = Meeting started by docaedo at 17:01:05 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-07-02-17.01.log.html . Meeting summary --- * rollcall (docaedo, 17:01:17) * Single YAML file switch status update (docaedo) (docaedo, 17:02:35) * Horizon panel status update (kfox) (docaedo, 17:07:05) * Stale URL checker (gosha) (docaedo, 17:27:48) * Heat template env (kfox) (docaedo, 17:29:57) * Open discussion (docaedo, 17:42:18) Meeting ended at 17:45:20 UTC. People present (lines said) --- * docaedo (61) * kfox (57) * openstack (3) * sgordon (1) * elmiko (1) Generated by `MeetBot`_ 0.1.4 __ OpenStack Development Mailing 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] [grenade] future direction on partial upgrade support
On 2015-07-06 11:54:45 -0700 (-0700), Armando M. wrote: [...] For what I can tell, Joe was kind to set the infra to start gathering data on the reliability of the multi-node jobs, but they are clearly flaky [1], and currently broken. [...] Well, a check-.* pass rate of 25% is likely explained by running against proposed bad changes (after all these are running in the check pipeline, not the gate). The recent 100% failure we think will be fixed with a new release of glean incorporating https://review.openstack.org/198576 since we recently started exceeding the 64-byte HOST_NAME_MAX on our test platforms. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team
O(1) (some of computational complexities achieved after Miguel optimizations) On 6 July 2015 at 09:24, Carl Baldwin c...@ecbaldwin.net wrote: +1! On Mon, Jul 6, 2015 at 4:02 AM, Kevin Benton blak...@gmail.com wrote: Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year has been important in making the reference implementation reliable. Existing cores, please vote +1/-1 for his addition to the team. Cheers! 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html 2. http://stackalytics.com/report/contribution/neutron/30 http://stackalytics.com/report/contribution/neutron/60 http://stackalytics.com/report/contribution/neutron/90 -- 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 __ OpenStack Development Mailing 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] Plethora of dbase migration questions...
Hi, I have some urgent requests about migration that I'm hoping to get some info on. I'm working on a bug where I need to add two (related) fields to a table for VPNaaS. Here's the objectives related to migration... 1) create local_v4_ip and lcoal_v6_ip fields in the vpnservice table 2) for each entry in the vpnservice table: 2.1) Get the router.gw_port.fixed_ips list 2.2) Determine the version of each fixed IP and store the first of each version (if any) into the appropriate new field. I have created a migration file, and I changed the down_revision to be the number of the revision that is the first in the migration chain in the VPN repo. Here are the many questions I have... When I look in the VPN repo, the HEAD file has the version 'kilo', which is not the current head. Shouldn't it the version number of the first file in the migration chain? For my commit, I'm assuming I change the HEAD file to use my migration file's version? I set HEAD to my migration file, and my file has a down revision of the previous head's revision. If I run 'neutron-db-manage --config-file ../neutron/etc/neutron.conf --config-file ../neutron/etc/neutron/plugins/ml2/ml2_conf.ini check_migration' there is no output so I guess that is OK. As I develop my new migration file, is there a way that I can test it (running neutron-db-migration, maybe)? Is there a way to run the migration file under the debugger, as well (importing pdb, for example)? In the migration, I can add the columns needed. What's the best way to fill out those fields - using raw SQL queries or create a Session object and access the VpnService object's router object? I see there is some op.bind() call and then engine.execute(), but could use some help on the best way to extract the needed queries (I need to access the vpnservice's router, and then access the (Port) gw_port relationship, and from that access the (IPAllocation) fixed_ips list). Appreciate any advise here on how to debug the migration stuff... Paul Michali (pc_m) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][lbaas] Proposing Al Miller for neutron-lbaas core team
Since all cores have responded, I’m going to end this early. Welcome to the core team, Al. Thanks, doug On Jul 5, 2015, at 6:27 PM, Kyle Mestery mest...@mestery.com wrote: +1 for Al! On Thu, Jul 2, 2015 at 5:16 PM, Doug Wiegley doug...@parksidesoftware.com mailto:doug...@parksidesoftware.com wrote: Hi all, As the Lieutenant of the advanced services, I would like to nominate Al Miller to be a member of the neutron-lbaas core reviewer team. Review stats are in line with other cores[2] and feedback on patches has been great. Additionally, he has been instrumental in our devstack support and octavia work. Existing cores, please vote +1/-1 for his addition to the team (that’s Brandon, Phil, and Kyle.) Thanks, doug 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy 2. http://stackalytics.com/report/contribution/neutron-lbaas/90 http://stackalytics.com/report/contribution/neutron-lbaas/90 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 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] [devstack] openstack install error with stable/kilo
Hi, FYI I got the same error since Wednesday or Thursday last week. With devstack master. I haven't had the chance to spend some time on it yet. Jordan On Mon, Jul 6, 2015 at 4:32 PM, Danny Choi (dannchoi) dannc...@cisco.com wrote: Hi, I’m trying to run devstack install of stable/kilo on Ubuntu 14.04 and getting the following error. Any suggestion on how to resolve it? 2015-07-06 13:25:08.670 | + recreate_database glance 2015-07-06 13:25:08.670 | + local db=glance 2015-07-06 13:25:08.670 | + recreate_database_mysql glance 2015-07-06 13:25:08.670 | + local db=glance 2015-07-06 13:25:08.670 | + mysql -uroot -pmysql -h127.0.0.1 -e 'DROP DATABASE IF EXISTS glance;' 2015-07-06 13:25:08.678 | + mysql -uroot -pmysql -h127.0.0.1 -e 'CREATE DATABASE glance CHARACTER SET utf8;' 2015-07-06 13:25:08.684 | + /usr/local/bin/glance-manage db_sync 2015-07-06 13:25:09.067 | Traceback (most recent call last): 2015-07-06 13:25:09.067 | File /usr/local/bin/glance-manage, line 6, in module 2015-07-06 13:25:09.067 | from glance.cmd.manage import main 2015-07-06 13:25:09.067 | File /opt/stack/glance/glance/cmd/manage.py, line 47, in module 2015-07-06 13:25:09.067 | from glance.common import config 2015-07-06 13:25:09.067 | File /opt/stack/glance/glance/common/config.py, line 31, in module 2015-07-06 13:25:09.067 | from paste import deploy 2015-07-06 13:25:09.067 | ImportError: cannot import name deploy Thanks, Danny __ OpenStack Development Mailing 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] What are problems of Distributed SNAT?
Hi, There was some discussion a while back on this subject. Some alternatives were captured on etherpad [1] with pros and cons. Sorry for the delay in responding. The initial implementation of DVR went with centralized SNAT to reduce the scope of the effort and because of a lack consensus around which alternative to choose. Carl [1] https://etherpad.openstack.org/p/decentralized-snat On Fri, Jun 26, 2015 at 5:02 AM, Miyagishi, Takanori miyagish...@jp.fujitsu.com wrote: Hi all, I'm Takanori Miyagishi. I and Yushiro Furukawa, my co-worker, are planning to implement Distributed SNAT in Liberty cycle. So, I looking for information about Distributed SNAT implementation. For now, I got some information from openstack-dev ML[1][2][3] and etherpad[4]. Would you please let me know if you have any other information. Best regards, Takanori Miyagishi [1] Fwd: [Neutron][DVR]Neutron distributed SNAT: http://lists.openstack.org/pipermail/openstack-dev/2015-February/056415.html [2] About DVR limit: http://lists.openstack.org/pipermail/openstack-dev/2015-January/054407.html [3] [neutron] dvr l3_snat: http://lists.openstack.org/pipermail/openstack-dev/2014-November/049893.html [4] https://etherpad.openstack.org/p/YVR-nova-network __ OpenStack Development Mailing 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] - Proposing Miguel Angel Ajo for the Control Plane core team
+1! On Mon, Jul 6, 2015 at 4:02 AM, Kevin Benton blak...@gmail.com wrote: Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year has been important in making the reference implementation reliable. Existing cores, please vote +1/-1 for his addition to the team. Cheers! 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html 2. http://stackalytics.com/report/contribution/neutron/30 http://stackalytics.com/report/contribution/neutron/60 http://stackalytics.com/report/contribution/neutron/90 -- 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 __ OpenStack Development Mailing 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] bp and/or spec required for new metadata service API version?
Related to this change [1] which adds a new LIBERTY openstack version to the metadata service API, it's pretty trivial but it's akin to microversions in the nova-api v2.1 code, and we require blueprints and specs for those changes generally. So do we require a blueprint and optionally a spec for this type of change, or is it simple enough as a bug fix on it's own? [1] https://review.openstack.org/#/c/197185/ -- 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
Re: [openstack-dev] [puppet] First Sprint proposal
On 07/06/2015 02:05 PM, Matt Fischer wrote: I think this is a great idea. I'd like to get a firm date on the operators mid-cycle before I vote though. If it overlaps, we can add more slots. Feel free to ping me on IRC for that, I'll update the doodle. Thanks, On Mon, Jul 6, 2015 at 11:31 AM, Emilien Macchi emil...@redhat.com mailto:emil...@redhat.com wrote: Hi, I would like to organize our first sprint for contributing to our Puppet OpenStack modules. It will happen in Red Hat Montreal (Canada) office, during 3 days. If you're interested to participate, please find the slots that may work for you [1]. Any slot suggestion is welcome though. Also, please bring on the etherpad any topics we should work on together [2]. We will groom topics during a meeting and prepare the agenda before the sprint. [1] http://doodle.com/xk2sfgu4xsi4y6n4r46t7u9k [2] https://etherpad.openstack.org/p/puppet-liberty-mid-cycle Regards, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://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 -- Emilien Macchi 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] [Murano][Congress] Application placement use case
Sorry--hit the Send button by accident. Hi Gosha, This definitely sounds like an interesting use case for Congress. Keep in mind that Congress doesn't itself do placement (though we did some experimentation with that [1][2]). Some thoughts. 1. Let's suppose Murano/Congress/etc. allow us to figure out which app should be deployed in which region. Is there a separate Nova for each region that can do the actual scheduling? If not, how would Murano force the app to be deployed in the proper region? 2. Let's assume Murano can force the app to the proper region. One option for using Congress to compute the proper region would be to write policy statements that enumerate the permitted regions for a given application, and then ask Congress for one of those regions. For your suggested policies above, we could write the following datalog statements Solaris is required then select Region_Solaris. permitted_region(app, region_solaris) :- murano:app_requires(app, solaris) A. If Solaris is required then select region_solaris permitted_region(app, region_solaris) :- murano:app_requires(app, solaris) B. If Solaris is required then select less loaded regions from [Region_Solaris1, Region_Solaris2] This one requires additional expressiveness in the language than we currently have (because it asks to minimize over several options). But it would be something like... best_region(app, min(y)) :- permitted_region(app, x), ceilometer:region_load(x, y) [1] Design doc: https://docs.google.com/document/d/1ksDilJYXV-5AXWON8PLMedDKr9NpS8VbT0jIy_MIEtI/edit [2] Slides: https://drive.google.com/a/styra.com/file/d/0ByDz-eYOtswScUFUc1ZrVVhmQlk/view Tim On Thu, Jul 2, 2015 at 7:36 AM Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: Hi, All applications are monolithic so they don't need to be split over multiple regions. It is necessary to have an ability to select a region based on requirements and for now I don't care how they are placed inside the region. I am not sure how region's capabilities will be stored and actually this is a reason why I am asking if Congress will solve this. I can imagine a policy which says if Solaris is required then select Region_Solaris. Or more complex If Solaris is required then select less loaded regions from [Region_Solaris1, Region_Solaris2] In this use case Murano will deploy complex environment which consist of multiple atomic applications with different requirements, so deployment will be across clouds but for whole environment. Imagine IBM MQ on AIX and PowerPC + Oracle DB on Solaris + Microsoft IIS on Windows 2012 HyperV + WebSphere on RHEL KVM. Thanks Gosha On Wed, Jul 1, 2015 at 10:17 PM, ruby.krishnasw...@orange.com wrote: Hi Did you mean placement at “two levels”. First to select the region and then within each region, Nova scheduler will place on hosts. But where will the capabilities of each region (based on which placement decision will be made) be stored? Will each region be queried to obtain this information? Will a single application need to be placed (split across) different regions? Ruby *De :* Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com] *Envoyé :* mercredi 1 juillet 2015 21:26 *À :* OpenStack Development Mailing List *Objet :* [openstack-dev] [Murano][Congress] Application placement use case Hi, I would like to share with the community one of the real use case which we saw while working with one of the Murano customer and ask an advice. This customer has multiple OpenStack regions which are serving for different hypervisors. The reason for that is Oracle OpenStack which is used to work with Solaris on top of SPARC architecture. There are other hypervisors KVM and VMWare which are used. There are multiple applications which should be placed to different regions based on their requirements (OS, Hypervisor, networking restrictions). As there is no single cloud, Nova scheduler can’t be used (at least in my understanding) so we need to have some placement policies to put applications properly. And obviously we don’t want to ask end user about the placement. Right now in Murano we can do this by: 1.Hardcoding placement inside application. This approach will work and does not require any significant change in Murano. But there are obvious limitations like if we have two options for placement which one should be hardcoded. 2.Create special placement scheduler application\class in Murano which will use some logic to place applications properly. This is better approach as nothing is hard coded in applications except their requirements. Applications will just have a workflow to ask placement scheduler for a decision and then will just use this decision. 3.Use some external tool or OpenStack component for placement decision. This is a very generic use case which we saw multiple times. Tools like
Re: [openstack-dev] [puppet] oslo.messaging version and RabbitMQ heartbeat support
On 07/01/2015 09:21 AM, Mike Dorman wrote: As a follow up to the discussion during the IRC meeting yesterday, please vote for one of these approaches: 1) Make the default for the rabbit_heartbeat_timeout_threshold parameter 60, which matches the default in Kilo oslo.messaging. This will by default enable the RMQ heartbeat feature, which also matches the default in Kilo oslo.messaging. Operators will need to set this parameter to 0 in order to disable the feature, which will be documented in the comments within the manifest. We will reevaluate the default value for the Liberty release, since the oslo.messaging default most likely will change to 0 for that release. +1 for #1 2) In addition to #1 above, also add a rabbit_enable_heartbeat parameter, which will default to false. Setting that to true will be needed to explicitly enable the RMQ heartbeat feature, regardless of the value of rabbit_heartbeat_timeout_threshold. By default the RMQ heartbeat feature will be disabled, which may be a marginally safer approach (due to the requirements.txt stuff, see below), but will not match the upstream Kilo oslo.messaging default. This will also turn off the feature for people who have already been “getting it for free” if they do nothing and don’t update their composition module. My vote is for #1. Let’s plan to close the voting by next week’s IRC meeting, so we can come to a final conclusion at that time. Thanks, Mike From: Mike Dorman Reply-To: OpenStack Development Mailing List (not for usage questions) Date: Tuesday, June 23, 2015 at 5:07 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [puppet] oslo.messaging version and RabbitMQ heartbeat support As a follow up to https://review.openstack.org/#/c/194399/ and the meeting discussion earlier today, I’ve determined that everybody (RDU, Ubuntu, Debian) is packaging oslo.messaging 1.8.2 or 1.8.3 with the Kilo build. (This is also the version we get on our internal Anvil-based build.) This is considerably lower than 1.11.0 where the default rabbit_heartbeat_timeout_threshold changes (from 60 to 0.) If we go forward using the default rabbit_heartbeat_timeout_threshold value of 60, that will be the correct default behavior up through oslo.messaging 1.10.x. When people upgrade to 1.11.0 or higher, we’ll no longer match the upstream default behavior. But, it should maintain the _actual_ behavior (heartbeating enabled) for people doing an upgrade. Once Liberty is cut, we should reevaluate to make sure we’re matching whatever the default is at that time. However, the larger problem I see is that oslo.messaging requirements.txt in =1.10.x does not enforce the needed versions of kombu and amqp for heartbeat to work: https://github.com/openstack/oslo.messaging/blob/1.8.2/requirements.txt#L25-L26 This is confusing as heartbeat is enabled by default! I am not sure what the behavior is when heartbeat is enabled with older kombu or amqp. Does anyone know? If it silently fails, maybe we don’t care. But if enabling heartbeat (by default, rabbit_heartbeat_timeout_threshold=60) actively breaks, that would be bad. I see two options here: 1) Make default rabbit_heartbeat_timeout_threshold=60 in the Puppet modules, to strictly follow the upstream default in Kilo. Reevaluate this default value for Liberty. Ignore the kombu/amqp library stuff and hope “it just works itself out naturally.” 2) Add a rabbit_enable_heartbeat parameter to explicitly enable/disable the feature, and default to disable. This goes against the current default behavior, but will match it for oslo.messaging =1.11.0. I think this is the safest path, as we won’t be automatically enabling heartbeat for people who don’t have a new enough kombu or amqp. Personally, I like #1, because I am going to enable this feature, anyway. And I can’t really imagine why one would _not_ want to enable it. But I am fine implementing it either way, I just want to get it done so I can get off my local forks. :) Thoughts? Mike __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Emilien Macchi 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
[openstack-dev] [neutron] Networking-foo projects and release management in the Neutron Stadium
The tl;dr for this email is that the patch referenced here [1] is moving release management tasks for the networking-foo projects into alignment with other Neutron libraries. There is value in having this consolidated into a single place. The longer version is that as plugin backends and new libraries have integrated into the Neutron Stadium, it makes sense to align some release items here. For example, merge commits, tags, and stable branch management aspects are things which are best done by a central team for all networking-foo projects (along with existing projects). In particular, stable releases have some specific requirements [2] which need to be met as stable releases are done here. Ensuring this is following existing processes is part of the reason for this gerrit ACL change. Please comment on the reviews if you have concerns as a networking-foo owner. Thanks! Kyle [1] https://review.openstack.org/#/c/198749/ [2] https://wiki.openstack.org/wiki/StableBranch __ OpenStack Development Mailing 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] - Proposing Miguel Angel Ajo for the Control Plane core team
+1! On Mon, Jul 06, 2015, Kevin Benton blak...@gmail.com wrote: Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year has been important in making the reference implementation reliable. Existing cores, please vote +1/-1 for his addition to the team. Cheers! 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html 2. http://stackalytics.com/report/contribution/neutron/30 http://stackalytics.com/report/contribution/neutron/60 http://stackalytics.com/report/contribution/neutron/90 -- 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] [nova] bp and/or spec required for new metadata service API version?
Le 06/07/2015 19:22, Matt Riedemann a écrit : Related to this change [1] which adds a new LIBERTY openstack version to the metadata service API, it's pretty trivial but it's akin to microversions in the nova-api v2.1 code, and we require blueprints and specs for those changes generally. So do we require a blueprint and optionally a spec for this type of change, or is it simple enough as a bug fix on it's own? [1] https://review.openstack.org/#/c/197185/ IMHO, all changes to internal interfaces (not only REST APIs, including RPC) need a spec, in particular if the payload is changing. We had the same discussion for the Scheduler API where a new field was about to be added to the filter_properties dict. While it's pretty trivial, I think we need to go over all that change to see why it's needed and if it's backwards compatible. My 2cts (EUR of course) -Sylvain __ OpenStack Development Mailing 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][lbaas] Proposing Al Miller for neutron-lbaas core team
I really appreciate the opportunity to participate as a core reviewer and would like to thank everyone who has helped me come up to speed on OpenStack and LBaaS. Al From: Doug Wiegley [mailto:doug...@parksidesoftware.com] Sent: Monday, July 06, 2015 9:22 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Al Miller for neutron-lbaas core team Since all cores have responded, I’m going to end this early. Welcome to the core team, Al. Thanks, doug On Jul 5, 2015, at 6:27 PM, Kyle Mestery mest...@mestery.commailto:mest...@mestery.com wrote: +1 for Al! On Thu, Jul 2, 2015 at 5:16 PM, Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com wrote: Hi all, As the Lieutenant of the advanced services, I would like to nominate Al Miller to be a member of the neutron-lbaas core reviewer team. Review stats are in line with other cores[2] and feedback on patches has been great. Additionally, he has been instrumental in our devstack support and octavia work. Existing cores, please vote +1/-1 for his addition to the team (that’s Brandon, Phil, and Kyle.) Thanks, doug 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy 2. http://stackalytics.com/report/contribution/neutron-lbaas/90 __ 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.orgmailto: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] [mistral] Team meeting minutes - 07/06/2015
Thanks for joining our meeting today! Meeting minutes: http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-07-06-16.01.html http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-07-06-16.01.html Meeting log: http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-07-06-16.01.log.html http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-07-06-16.01.log.html The next meeting will be on July 13 at the same time. Please add agenda items at https://wiki.openstack.org/wiki/Meetings/MistralAgenda https://wiki.openstack.org/wiki/Meetings/MistralAgenda. Renat Akhmerov @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] First Sprint proposal
On 07/06/2015 01:31 PM, Emilien Macchi wrote: Hi, I would like to organize our first sprint for contributing to our Puppet OpenStack modules. It will happen in Red Hat Montreal (Canada) office, during 3 days. If you're interested to participate, please find the slots that may work for you [1]. Any slot suggestion is welcome though. Also, please bring on the etherpad any topics we should work on together [2]. We will groom topics during a meeting and prepare the agenda before the sprint. [1] http://doodle.com/xk2sfgu4xsi4y6n4r46t7u9k Sorry for the 404, here is the right link: http://doodle.com/xk2sfgu4xsi4y6n4 [2] https://etherpad.openstack.org/p/puppet-liberty-mid-cycle 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 -- Emilien Macchi 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] [neutron][lbaas] Proposing Al Miller for neutron-lbaas core team
Great to have you as a LBass core Al! On Mon, Jul 6, 2015 at 1:29 PM Doug Wiegley doug...@parksidesoftware.com wrote: Since all cores have responded, I’m going to end this early. Welcome to the core team, Al. Thanks, doug On Jul 5, 2015, at 6:27 PM, Kyle Mestery mest...@mestery.com wrote: +1 for Al! On Thu, Jul 2, 2015 at 5:16 PM, Doug Wiegley doug...@parksidesoftware.com wrote: Hi all, As the Lieutenant of the advanced services, I would like to nominate Al Miller to be a member of the neutron-lbaas core reviewer team. Review stats are in line with other cores[2] and feedback on patches has been great. Additionally, he has been instrumental in our devstack support and octavia work. Existing cores, please vote +1/-1 for his addition to the team (that’s Brandon, Phil, and Kyle.) Thanks, doug 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy 2. http://stackalytics.com/report/contribution/neutron-lbaas/90 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://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] [puppet] First Sprint proposal
I think this is a great idea. I'd like to get a firm date on the operators mid-cycle before I vote though. On Mon, Jul 6, 2015 at 11:31 AM, Emilien Macchi emil...@redhat.com wrote: Hi, I would like to organize our first sprint for contributing to our Puppet OpenStack modules. It will happen in Red Hat Montreal (Canada) office, during 3 days. If you're interested to participate, please find the slots that may work for you [1]. Any slot suggestion is welcome though. Also, please bring on the etherpad any topics we should work on together [2]. We will groom topics during a meeting and prepare the agenda before the sprint. [1] http://doodle.com/xk2sfgu4xsi4y6n4r46t7u9k [2] https://etherpad.openstack.org/p/puppet-liberty-mid-cycle Regards, -- Emilien Macchi __ OpenStack Development Mailing 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] python-cinderclient functional tests
Hi all, As you may know, we've got experimental job [1] to run functional tests [2] for python-cinderclient with devstack setup. Functional tests for python-cinderclient is very important because it's almost the only way to test python-cinderclient with Cinder API. For now, we've got only Rally which uses cinderclient to test Cinder. Tempest uses own client for all APIs. Current tests coverage are very low.. That's why I would like to ask everyone to contribute to python-cinderclient. I created etherpad [3] with current progress. You can find me (e0ne) or any other core in #openstack-cinder in IRC. Aslo, what do you think about moving cinderclient functional tests from experimental to non-voting queue to make it more public and run it with every patch to python-cinderclient? [1] https://review.openstack.org/#/c/182528/ [2] https://github.com/openstack/python-cinderclient/tree/master/cinderclient/tests/functional [3] https://etherpad.openstack.org/p/cinder-client-functional-tests Regards, Ivan Kolodyazhny __ OpenStack Development Mailing 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][lbaas] Proposing Al Miller for neutron-lbaas core team
Congratulations Al! Well deserved! madhu_ak On Mon, Jul 6, 2015 at 11:55 AM, Brandon Logan brandon.lo...@rackspace.com wrote: congrats Al! On Jul 6, 2015 1:06 PM, Paul Michali p...@michali.net wrote: Great to have you as a LBass core Al! On Mon, Jul 6, 2015 at 1:29 PM Doug Wiegley doug...@parksidesoftware.com wrote: Since all cores have responded, I’m going to end this early. Welcome to the core team, Al. Thanks, doug On Jul 5, 2015, at 6:27 PM, Kyle Mestery mest...@mestery.com wrote: +1 for Al! On Thu, Jul 2, 2015 at 5:16 PM, Doug Wiegley doug...@parksidesoftware.com wrote: Hi all, As the Lieutenant of the advanced services, I would like to nominate Al Miller to be a member of the neutron-lbaas core reviewer team. Review stats are in line with other cores[2] and feedback on patches has been great. Additionally, he has been instrumental in our devstack support and octavia work. Existing cores, please vote +1/-1 for his addition to the team (that’s Brandon, Phil, and Kyle.) Thanks, doug 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy 2. http://stackalytics.com/report/contribution/neutron-lbaas/90 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://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 __ OpenStack Development Mailing 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][neutron] oslo.policy: policy_dirs config option, why deprecated?
Hi, When reading [1], it seems that Doug is implying there will be the ability to collate multiple policy.json files together? It would be good to get this point clarified. Thanks, Armando [1] https://bugs.launchpad.net/oslo.policy/+bug/1428332 On 3 July 2015 at 22:12, Akihiro Motoki amot...@gmail.com wrote: Hi Oslo and Neutron folks, Why is policy_dirs option deprecated in oslo.policy? In Neutron we have multiple repositories which consist of Neutron services and we would like to maintain policy.json separately. policy_dirs option looks useful for this purpose. == Detail == Neutron project now consists of several repositories and they are imported when neutron-server runs. There are cases where it makes sense that each repository manages its policy.json and the neutron-server wants to load all related policy.json files. - advanced services have separate repositories and they evolve their API independently - vendor plugins/drivers in separate repositories (can) have vendor-specific extension API. (It is not a good thing from the point of the current API discussion, but we have now.) An easy way is to put all related policy.json into a single directory lile /etc/neutron/policy.d and specify this to policy_dirs option. Looking at oslo.policy (oslo_policy/opts), we have a comment policy_dirs option will be removed in M cycle. I read the commit message where this message was added but I am not sure why it is a problem. I would like to know the reason of the deprecation and discuss how we can handle our use cases. Thanks, Akihiro __ OpenStack Development Mailing 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] How to handle security issues in external repos?
On 2015-07-06 20:25:25 +0200 (+0200), Henry Gessau wrote: Jeremy, a huge thanks for this fantastic reply! I have taken the liberty of copying your responses directly into Neutron's contributing guide: https://review.openstack.org/187267 I hope you don't mind. Quite the opposite--I'm happy to be able to help! I'll likely rework my E-mail or write something else similar as an addition to some of the documentation the VMT currently maintains, so hopefully in time you can just link to it from within that devref. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] How to handle security issues in external repos?
Jeremy, a huge thanks for this fantastic reply! I have taken the liberty of copying your responses directly into Neutron's contributing guide: https://review.openstack.org/187267 I hope you don't mind. On Fri, Jul 03, 2015, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-07-03 22:01:38 +0200 (+0200), Henry Gessau wrote: [...] The question now arises about what to do when a security issue is found in such an external repository that integrates with Neutron. - How should such security issues be managed? The OpenStack Vulnerability Management Team (VMT) follows a documented process[1] which can basically be reused by any project-team when needed. - Should the OpenStack security team be involved? The OpenStack VMT directly oversees vulnerability reporting and disclosure for a subset[2] of OpenStack source code repositories. However we're still quite happy to answer any questions you might have about vulnerability management for your own projects even if they're not part of that set. Feel free to reach out to us in public or in private. Also, the VMT is an autonomous subgroup of the much larger OpenStack Security project-team[3]. They're a knowledgeable bunch and quite responsive if you want to get their opinions or help with security-related issues (vulnerabilities or otherwise). - Does a CVE need to be filed? It can vary widely. If a commercial distribution such as Red Hat is redistributing a vulnerable version of your software then they may assign one anyway even if you don't request one yourself. Or the reporter may request one; the reporter may even be affiliated with an organization who has already assigned/obtained a CVE before they initiate contact with you. - Do the maintainers need to publish OSSN or equivalent documents? OpenStack Security Advisories (OSSA) are official publications of the OpenStack VMT and only cover VMT-supported software. OpenStack Security Notes (OSSN) are published by editors within the OpenStack Security project-team on more general security topics and may even cover issues in non-OpenStack software commonly used in conjunction with OpenStack, so it's at their discretion as to whether they would be able to accommodate a particular issue with an OSSN. However, these are all fairly arbitrary labels, and what really matters in the grand scheme of things is that vulnerabilities are handled seriously, fixed with due urgency and care, and announced widely--not just on relevant OpenStack mailing lists but also preferably somewhere with broader distribution like the Open Source Security mailing list[4]. The goal is to get information on your vulnerabilities, mitigating measures and fixes into the hands of the people using your software in a timely manner. - Anything else to consider here? [...] The OpenStack VMT is in the process of trying to reinvent itself so that it can better scale within the context of the Big Tent. This includes making sure our policy/process documentation is more consumable and reusable even by project-teams working on software outside the scope of our charter. It's a work in progress, and any input is welcome on how we can make this function well for everyone. [1] https://security.openstack.org/vmt-process.html [2] https://wiki.openstack.org/wiki/Security_supported_projects [3] http://governance.openstack.org/reference/projects/security.html [4] http://oss-security.openwall.org/wiki/mailing-lists/oss-security __ OpenStack Development Mailing 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] [Murano][Congress] Application placement use case
Hi Tim, Thank you for the comprehensive information. From Murano standpoint each OpenStack region is a separate Heat endpoint. So once Murano has a decision about placement it will just use proper Heat endpoint to initiate stack creation process. Murano does not expect that Congress will do actual placement. Murano has a way to do this by itself as it just pushes stack template to the Heat. As I see in your reply there is a clear way to define such policies which is really great. It sounds like there is nothing we need to change in the Congress itself which is also great. I think we have explicit Congress call in Murano, at least it was discussed in Paris. I will check if we have someone in Murano team who can draft a spec for this feature and use case in Murano. Sounds like we have enough information for that. Once again, thank you for the information. Regards, Gosha On Mon, Jul 6, 2015 at 9:13 AM, Tim Hinrichs t...@styra.com wrote: Sorry--hit the Send button by accident. Hi Gosha, This definitely sounds like an interesting use case for Congress. Keep in mind that Congress doesn't itself do placement (though we did some experimentation with that [1][2]). Some thoughts. 1. Let's suppose Murano/Congress/etc. allow us to figure out which app should be deployed in which region. Is there a separate Nova for each region that can do the actual scheduling? If not, how would Murano force the app to be deployed in the proper region? 2. Let's assume Murano can force the app to the proper region. One option for using Congress to compute the proper region would be to write policy statements that enumerate the permitted regions for a given application, and then ask Congress for one of those regions. For your suggested policies above, we could write the following datalog statements Solaris is required then select Region_Solaris. permitted_region(app, region_solaris) :- murano:app_requires(app, solaris) A. If Solaris is required then select region_solaris permitted_region(app, region_solaris) :- murano:app_requires(app, solaris) B. If Solaris is required then select less loaded regions from [Region_Solaris1, Region_Solaris2] This one requires additional expressiveness in the language than we currently have (because it asks to minimize over several options). But it would be something like... best_region(app, min(y)) :- permitted_region(app, x), ceilometer:region_load(x, y) [1] Design doc: https://docs.google.com/document/d/1ksDilJYXV-5AXWON8PLMedDKr9NpS8VbT0jIy_MIEtI/edit [2] Slides: https://drive.google.com/a/styra.com/file/d/0ByDz-eYOtswScUFUc1ZrVVhmQlk/view Tim On Thu, Jul 2, 2015 at 7:36 AM Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: Hi, All applications are monolithic so they don't need to be split over multiple regions. It is necessary to have an ability to select a region based on requirements and for now I don't care how they are placed inside the region. I am not sure how region's capabilities will be stored and actually this is a reason why I am asking if Congress will solve this. I can imagine a policy which says if Solaris is required then select Region_Solaris. Or more complex If Solaris is required then select less loaded regions from [Region_Solaris1, Region_Solaris2] In this use case Murano will deploy complex environment which consist of multiple atomic applications with different requirements, so deployment will be across clouds but for whole environment. Imagine IBM MQ on AIX and PowerPC + Oracle DB on Solaris + Microsoft IIS on Windows 2012 HyperV + WebSphere on RHEL KVM. Thanks Gosha On Wed, Jul 1, 2015 at 10:17 PM, ruby.krishnasw...@orange.com wrote: Hi Did you mean placement at “two levels”. First to select the region and then within each region, Nova scheduler will place on hosts. But where will the capabilities of each region (based on which placement decision will be made) be stored? Will each region be queried to obtain this information? Will a single application need to be placed (split across) different regions? Ruby *De :* Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com] *Envoyé :* mercredi 1 juillet 2015 21:26 *À :* OpenStack Development Mailing List *Objet :* [openstack-dev] [Murano][Congress] Application placement use case Hi, I would like to share with the community one of the real use case which we saw while working with one of the Murano customer and ask an advice. This customer has multiple OpenStack regions which are serving for different hypervisors. The reason for that is Oracle OpenStack which is used to work with Solaris on top of SPARC architecture. There are other hypervisors KVM and VMWare which are used. There are multiple applications which should be placed to different regions based on their requirements (OS, Hypervisor, networking restrictions). As there is no single cloud, Nova
Re: [openstack-dev] [Murano] Discuss simulated-execution-mode-murano-engine blueprint
Hi Kate,
MuraPL has a concept of exceptions. Unit testing will be important to make
sure that workflows behaves correctly in exceptions situations. How will be
this addressed int he testing framework? Will you have some specific
assertions like python unit testing framework?
Thanks
Gosha
On Mon, Jul 6, 2015 at 9:02 AM, Ekaterina Chernova efedor...@mirantis.com
wrote:
Folks,
I have specific topic to discuss: how murano test-fixture will look like
and how it can be run.
The idea is to implement a unit-testing framework, similar to regular
frameworks for python or other languages,
which will allow to define test fixtures in MuranoPL.
A Test fixture is a regular muranoPL class definition, which methods are
the test cases.
When such fixture is included into Murano application package the
deployment of application may be tested without running actual VM's.
Here is how the test fixture may look like:
Namespaces:
=: io.murano.apps.foo.tests
sys: io.murano.system
pckg: io.murano.apps.foo
Extends: io.murano.tests.TestFixture
Name: FooTest
Methods:
initialize:
Body:
*# Object model can be loaded from json file, or provided
directly in murano-pl code as a yaml insertion.*
*# - $.appJson:
new(sys:Resources).json('foo-test-object-model.json')*
- $.appJson:
- ?:
type: io.murano.apps.foo.FooApp
name: my-foo-obj
instance:
?:
type: io.murano.resources.Instance
...
setUp:
Body:
- $.env: $.createEnvironment($.appJson) # creates an
instance of std:Environment
- $.myApp:
$.env.applications.where($.name='my-foo-obj').first()
*# mock instance spawning*
- mock($.myApp.instance, deploy, mockInstanceDeploy, $this)
- mock(res:Instance, deploy, mockInstanceDeploy, $this)
testFooApp:
Body:
- $.env.deploy()
- $.assertEqual(true, $.myApp.getAttr('deployed'))
mockInstanceDeploy:
Arguments:
- mockContext
Body:
- Return:
* # heat template*
io.murano.tests.TestFixture - is a base class, that contains set of
methods, needed in all the test-cases which inherit it, such as assertEqual
and other similar assertions.
All it contains a $.createEnvironment method which may be called at the
setUp phase (a method being run before each test case) to construct the
object model to run the test against.
Test developer will be able to mock some of the functions or method which
are out of the scope of the current test
(for example, interaction with other applications or classes from the
standard murano library, such as instance.deploy etc).
The mock will allow to override the actual method execution and provide
the expected output of the method.
The actual implementation of mocking requires more thoughtful design, so
I'll create a separate spec for it.
What do you think about the overall idea and the test syntax proposed
above?
On Wed, Jun 3, 2015 at 5:15 PM, Ekaterina Chernova efedor...@mirantis.com
wrote:
Hi all!
I'd like to discuss first implementation thoughts about this [1]
blueprint, that we want to implement in Liberty.
This feature is supposed to increase the speed of application development.
Now engine interacts with API to get input task and packages.
Items, planned to implement first would enable loading local task and new
package, without API and Rabbit involved.
After that simple testing machinery will be added to MuranoPL: mock
support and simple test-runner.
So user can test application methods as he wants by creating simple tests.
Deployment parameters, such as heat stack and murano execution
plan outputs
may be set as returned value in tests.
Finally, tests may be placed into a murano package for easier package
verification and later modification.
I'm going to write specification soon. But before, we need to prepare
list of functions, that are needed to
implement simple mocking machinery in MuranoPL.
Please, leave your thoughts here or directly in the blueprint.
Regards, Kate.
[1] -
https://blueprints.launchpad.net/murano/+spec/simulated-execution-mode-murano-engine
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
Re: [openstack-dev] [grenade] future direction on partial upgrade support
Hi, Not sure if we reached any conclusion with this thread, and I would like to resume it so that we don't derail the initial plan set forth by Russell and agreed during the Liberty summit, among other things. If I look at the thread I think this can be summarized as follow. Please correct me if I am wrong: 1. There is a desire for making Grenade more modular by relying on multi-node support. This is beneficial for all the projects that aim at testing partial upgrades. 2. There are a number of steps required to achieve 1. The work required is not overly complicated, but it requires some discipline and good understanding of the overall OpenStack machine to get it to completion. 3. Should this effort be given priority, it can impact stuff that is currently in flight, like the patches from Russell on Neutron partial upgrade, and Dan on improvements for nova-net upgrades. 4. With minor tweaks single-node Grenade can be useful in the interim, while everything gets ported over a more robust multi-node Grenade job configuration. Have we identified a volunteer for activity 1? For what I can tell, Joe was kind to set the infra to start gathering data on the reliability of the multi-node jobs, but they are clearly flaky [1], and currently broken. I have seen nothing else. If I am mistaken, please fill me in. Now, in terms of a resolution for this, would it be fair to say that until we get 1) bootstrapped, Russell and Dan's efforts are a low-hanging fruit worth taking? I would personally think so: after all patches [2,3,4] seem trivial enough: - they don't add much complexity - they are fairly self-contained, and - can be easily swept away with the other grenade 'odd conditionals' in the context of 1. Thoughts? Thanks, Armando [1] http://goo.gl/NPkeZh [2] https://review.openstack.org/#/q/topic:partial-neutron-upgrade,n,z [3] https://review.openstack.org/#/q/topic:neutron-agent-control,n,z [4] https://review.openstack.org/#/c/189478/ https://review.openstack.org/#/c/189478/ On 26 June 2015 at 15:54, Joe Gordon joe.gord...@gmail.com wrote: No On Fri, Jun 26, 2015 at 10:15 AM, Joe Gordon joe.gord...@gmail.com wrote: On Wed, Jun 24, 2015 at 11:44 AM, Joe Gordon joe.gord...@gmail.com wrote: On Wed, Jun 24, 2015 at 11:03 AM, Sean Dague s...@dague.net wrote: On 06/24/2015 01:41 PM, Russell Bryant wrote: On 06/24/2015 01:31 PM, Joe Gordon wrote: On Tue, Jun 16, 2015 at 9:58 AM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: Back when Nova first wanted to test partial upgrade, we did a bunch of slightly odd conditionals inside of grenade and devstack to make it so that if you were very careful, you could just not stop some of the old services on a single node, upgrade everything else, and as long as the old services didn't stop, they'd be running cached code in memory, and it would look a bit like a 2 node worker not upgraded model. It worked, but it was weird. There has been some interest by the Nova team to expand what's not being touched, as well as the Neutron team to add partial upgrade testing support. Both are great initiatives, but I think going about it the old way is going to add a lot of complexity in weird places, and not be as good of a test as we really want. Nodepool now supports allocating multiple nodes. We have a multinode job in Nova regularly testing live migration using this. If we slice this problem differently, I think we get a better architecture, a much easier way to add new configs, and a much more realistic end test. Conceptually, use devstack-gate multinode support to set up 2 nodes, an all in one, and a worker. Let grenade upgrade the all in one, leave the worker alone. I think the only complexity here is the fact that grenade.sh implicitly drives stack.sh. Which means one of: 1) devstack-gate could build the worker first, then run grenade.sh 2) we make it so grenade.sh can execute in parts more easily, so it can hand something else running stack.sh for it.' 3) we make grenade understand the subnode for partial upgrade, so it will run the stack phase on the subnode itself (given credentials). This kind of approach means deciding which services you don't want to upgrade doesn't require devstack changes, it's just a change of the services on the worker. We need a volunteer for taking this on, but I think all the follow on partial upgrade support will be much much easier to do after we have this kind of mechanism in place. I think this is a great approach for the future of partial upgrade support in grenade. I would like to point out step 0 here, is to get tempest passing consistently in multinode. Currently the neutron job is failing consistently, and
Re: [openstack-dev] [nova] bp and/or spec required for new metadata service API version?
On 07/06/15 at 07:37pm, Sylvain Bauza wrote: Le 06/07/2015 19:22, Matt Riedemann a écrit : Related to this change [1] which adds a new LIBERTY openstack version to the metadata service API, it's pretty trivial but it's akin to microversions in the nova-api v2.1 code, and we require blueprints and specs for those changes generally. So do we require a blueprint and optionally a spec for this type of change, or is it simple enough as a bug fix on it's own? [1] https://review.openstack.org/#/c/197185/ At the very least I think a blueprint is warranted with a discussion in the Nova meeting. More reasoning below. IMHO, all changes to internal interfaces (not only REST APIs, including RPC) need a spec, in particular if the payload is changing. We had the same discussion for the Scheduler API where a new field was about to be added to the filter_properties dict. While it's pretty trivial, I think we need to go over all that change to see why it's needed and if it's backwards compatible. I'm not sure I agree that all internal interface changes need a spec, but any external interface should have one. Or at the very least have a blueprint and a discussion on why it doesn't need a spec, just to ensure that more than just two core reviewers are aware of the change. Anything changing an external interface is adding new functionality and is worth a discussion, more so than the interface change itself. For internal interfaces if they're in support of new functionality I think the functionality deserves a spec, at the very least so it's documented. But there are some changes we make that don't need a spec. Increasing the major version of an RPC API being one example, though perhaps an exceptional one. My 2cts (EUR of course) -Sylvain __ OpenStack Development Mailing 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][lbaas] Proposing Al Miller for neutron-lbaas core team
congrats Al! On Jul 6, 2015 1:06 PM, Paul Michali p...@michali.net wrote: Great to have you as a LBass core Al! On Mon, Jul 6, 2015 at 1:29 PM Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com wrote: Since all cores have responded, I'm going to end this early. Welcome to the core team, Al. Thanks, doug On Jul 5, 2015, at 6:27 PM, Kyle Mestery mest...@mestery.commailto:mest...@mestery.com wrote: +1 for Al! On Thu, Jul 2, 2015 at 5:16 PM, Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com wrote: Hi all, As the Lieutenant of the advanced services, I would like to nominate Al Miller to be a member of the neutron-lbaas core reviewer team. Review stats are in line with other cores[2] and feedback on patches has been great. Additionally, he has been instrumental in our devstack support and octavia work. Existing cores, please vote +1/-1 for his addition to the team (that's Brandon, Phil, and Kyle.) Thanks, doug 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy 2. http://stackalytics.com/report/contribution/neutron-lbaas/90 __ 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.orgmailto: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://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] Feedback on Keystone Federation Spec
On 1 July 2015 at 17:05, Adam Young ayo...@redhat.com wrote: I'm going to be doing an Anisble based setup for a Demo based on Ipsilon and FreeIPA. For it, I will need to set up both SAML Federation and SSSD/Kerberos Federation. I suspect that much of the ADFS code is going to be common with the. From your blog post, it does appear that much of the work is similar. We're nailing down the main deployment tooling during the course of the next two weeks with the initial focus on using the Shibboleth SAML federation. I expect that we'll be able to build on that very quickly to also add SSSD/Kerberos, Mellon (SAML) and Open-ID federation as the configurations don't vary all that much and the registration of IdP's in the SP's is very straight forward. I'd like to make sure that the Playbooks for enabling Federation are something that people can use regardless of how they did their initial install (ignoring that it might battle with Puppet for Puppet based installs). The os_keystone role within os-ansible-deployment should be usable independently, although you may need to restrict the tasks run by limiting the tags executed (otherwise it'll expect to deploy from source and all that). If you pop into #openstack-ansible and there will usually be someone there who can assist. -- Jesse Pretorius IRC: odyssey4me __ OpenStack Development Mailing 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] Meeting Tuesday July 7th at 19:00 UTC
Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday July 7th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend. In case you missed it or would like a refresher, the meeting minutes and full log from our last meeting are available here: Minutes: http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-06-30-19.01.html Minutes (text): http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-06-30-19.01.txt Log: http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-06-30-19.01.log.html -- Elizabeth Krumbach Joseph || Lyz || pleia2 __ OpenStack Development Mailing 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] Networking-foo projects and release management in the Neutron Stadium
hi, On Tue, Jul 7, 2015 at 2:20 AM, Kyle Mestery mest...@mestery.com wrote: The tl;dr for this email is that the patch referenced here [1] is moving release management tasks for the networking-foo projects into alignment with other Neutron libraries. There is value in having this consolidated into a single place. The longer version is that as plugin backends and new libraries have integrated into the Neutron Stadium, it makes sense to align some release items here. For example, merge commits, tags, and stable branch management aspects are things which are best done by a central team for all networking-foo projects (along with existing projects). In particular, stable releases have some specific requirements [2] which need to be met as stable releases are done here. Ensuring this is following existing processes is part of the reason for this gerrit ACL change. Please comment on the reviews if you have concerns as a networking-foo owner. can you explain how release procedure will be changed? Thanks! Kyle [1] https://review.openstack.org/#/c/198749/ [2] https://wiki.openstack.org/wiki/StableBranch __ OpenStack Development Mailing 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] [horizon] Modifying existing dashboards with plugins
I am considering making a plugin for Horizon which will add additional information to existing dashboards. For example, the plugin may add a new column to a table in a table in the instances dashboard. I have not found a standard method for plugins to do this. The plugin support I have found only allows for adding new dashboards and panels [1] as far as I can tell. There is currently a way to change any part of openstack_dashboard with a customization module [2]. However, this does not appear to be designed for plugins. Since only one customization module can be specified, it is not a good fit for plugin developers, because users would be limited to one plugin that uses this mechanism. I am wondering if there is a way to have plugins modify existing dashboards currently that I am overlooking. If not, should there be? [1] http://docs.openstack.org/developer/horizon/topics/settings.html#pluggable-settings-label [2] http://docs.openstack.org/developer/horizon/topics/customizing.html#modifying-existing-dashboards-and-panels __ OpenStack Development Mailing 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] [tacker]call _super method for _XtachInterface parent class
hi everyone please review this https://review.openstack.org/#/c/198293/ thanks cing __ OpenStack Development Mailing 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] [grenade] future direction on partial upgrade support
I'd also like to chime in - we've had some discussions on -infra today about the partial upgrade issue, and collected the following notes on an etherpad. https://etherpad.openstack.org/p/neutron-partial-upgrades One of the things identified, was the complexity of the DVR feature in Neutron, and an attempt to simplify the partial upgrade job by not enabling the DVR feature. http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-07-06-21.00.log.html Clark Boylan has proposed a patch to create a new job that runs on multiple nodes, but does not have DVR enabled, in the hopes that having less moving parts will allow the multinode grenade work to continue on a parallel track, with bugfixes or additional work on the Neutron DVR feature not blocking the overall effort. The idea would be eventually to enable DVR, once we have taken care of all the other work that needs to be done. https://review.openstack.org/#/c/198906/ What is everyone's thoughts? -- Sean M. Collins __ OpenStack Development Mailing 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][QoS]- May be the Qos apply to the floatingip?
hi All, By the bp of QoS, The QoS is only used to port and network, I want to know If support to apply it to floatingip? thank you __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Specs process query
On 1 July 2015 at 08:25, Matt Keenan matt.kee...@oracle.com wrote: Hi, In submitting my first ironic spec, I am following the process outlined at: https://wiki.openstack.org/wiki/Ironic/Specs_Process As of Kilo this suggests we also follow: http://lists.openstack.org/pipermail/openstack-dev/2014-August/041960.html This indicates that once a spec is registered before submission of the spec text the registered spec needs to be given the ok. Quick discussion on IRC indicates that this was never adhered to. If it's not going to be adhered to then I'd suggest removing this reference from Specs_Process. cheers Matt Hi Matt, My interpretation of the email you referenced, was to help 'fast-track' two things: 1. new 'features' that didn't require a spec to be written and 2. new 'features' that are out of scope or something that just won't work for whatever reason. I believe it may be true (although I haven't read all the proposed specs) that no one has actually followed that process, but I don't know if that means we should not provide that as a choice. Are you interpreting it as 'You must follow this process' as opposed to 'You could choose to follow this process'? --ruby __ OpenStack Development Mailing 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] Networking-foo projects and release management in the Neutron Stadium
On Mon, Jul 6, 2015 at 5:07 PM, Takashi Yamamoto yamam...@midokura.com wrote: hi, On Tue, Jul 7, 2015 at 2:20 AM, Kyle Mestery mest...@mestery.com wrote: The tl;dr for this email is that the patch referenced here [1] is moving release management tasks for the networking-foo projects into alignment with other Neutron libraries. There is value in having this consolidated into a single place. The longer version is that as plugin backends and new libraries have integrated into the Neutron Stadium, it makes sense to align some release items here. For example, merge commits, tags, and stable branch management aspects are things which are best done by a central team for all networking-foo projects (along with existing projects). In particular, stable releases have some specific requirements [2] which need to be met as stable releases are done here. Ensuring this is following existing processes is part of the reason for this gerrit ACL change. Please comment on the reviews if you have concerns as a networking-foo owner. can you explain how release procedure will be changed? Sure. We'll rely on the release team to help us release these backend libraries and API repositories. These are the same folks doing releases for both clients and oslo libraries. Thanks! Kyle [1] https://review.openstack.org/#/c/198749/ [2] https://wiki.openstack.org/wiki/StableBranch __ OpenStack Development Mailing 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] [trove]The patch from 191859 breaks thecompatibility with python 2.6
Thanks @doug and that saves me days!
It's reasonable and I think we should make the private patch for our
environment. Thanks again.
-tobe from UnitedStack
-- Original --
From: Doug Shelleyd...@tesora.com;
Date: Mon, Jul 6, 2015 07:29 PM
To: openstack-dev@lists.openstack-dev@lists.openstack.org;
Subject: Re: [openstack-dev] [trove]The patch from 191859 breaks
thecompatibility with python 2.6
Hi,
Python 2.6 support was dropped in Kilo (for all of OpenStack). The patchset
you mention was just merged last week and will be in Liberty. Trove is no
longer being tested with Python 2.6 so it is likely things like this will
continue to occur going forward.
Regards,
Doug
From: 陈迪豪 chendi...@unitedstack.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Monday, July 6, 2015 at 6:16 AM
To: OpenStack List openstack-dev@lists.openstack.org
Subject: [openstack-dev] [trove]The patch from 191859 breaks the compatibility
with python 2.6
Hi all,
We're deploying trove with python 2.6 in production. And the latest code from
https://review.openstack.org/#/c/191859 has broken the compatible with python
2.6.
The actual code which causes it is in
trove/guestagent/common/operating_system.py and looks like thest. Python 2.6
has syntax error for this list expression.
def list_files_in_directory(root_dir, recursive=False, pattern=None):
return {os.path.abspath(os.path.join(root, name))
for (root, _, files) in os.walk(root_dir, topdown=True)
if recursive or (root == root_dir)
for name in files
if not pattern or re.match(pattern, name)}
It would be great for anyone to fix it for both python 2.6 and 2.7, right?
- tobe__
OpenStack Development Mailing 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] [puppet] First Sprint proposal
Operators mid-cycle is Aug 17-21 at a TBD location, I voted accordingly. Thanks. On Mon, Jul 6, 2015 at 12:09 PM, Emilien Macchi emil...@redhat.com wrote: On 07/06/2015 02:05 PM, Matt Fischer wrote: I think this is a great idea. I'd like to get a firm date on the operators mid-cycle before I vote though. If it overlaps, we can add more slots. Feel free to ping me on IRC for that, I'll update the doodle. Thanks, On Mon, Jul 6, 2015 at 11:31 AM, Emilien Macchi emil...@redhat.com mailto:emil...@redhat.com wrote: Hi, I would like to organize our first sprint for contributing to our Puppet OpenStack modules. It will happen in Red Hat Montreal (Canada) office, during 3 days. If you're interested to participate, please find the slots that may work for you [1]. Any slot suggestion is welcome though. Also, please bring on the etherpad any topics we should work on together [2]. We will groom topics during a meeting and prepare the agenda before the sprint. [1] http://doodle.com/xk2sfgu4xsi4y6n4r46t7u9k [2] https://etherpad.openstack.org/p/puppet-liberty-mid-cycle Regards, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://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 -- Emilien Macchi __ OpenStack Development Mailing 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] [grenade] future direction on partial upgrade support
Thanks Sean, comments inline. On 6 July 2015 at 16:58, Sean M. Collins s...@coreitpro.com wrote: I'd also like to chime in - we've had some discussions on -infra today about the partial upgrade issue, and collected the following notes on an etherpad. https://etherpad.openstack.org/p/neutron-partial-upgrades One of the things identified, was the complexity of the DVR feature in Neutron, and an attempt to simplify the partial upgrade job by not enabling the DVR feature. The DVR issue is entirely orthogonal to this, but I am willing to play along. http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-07-06-21.00.log.html Clark Boylan has proposed a patch to create a new job that runs on multiple nodes, but does not have DVR enabled, in the hopes that having less moving parts will allow the multinode grenade work to continue on a parallel track, Who is leading the Grenade effort? Is it Clark? with bugfixes or additional work on the Neutron DVR feature not blocking the overall effort. The idea would be eventually to enable DVR, once we have taken care of all the other work that needs to be done. https://review.openstack.org/#/c/198906/ I thought that's what Joe did in [1]. Am I barking up at the wrong tree? What is everyone's thoughts? [1] https://review.openstack.org/#/c/195259/ -- Sean M. Collins __ OpenStack Development Mailing 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] [grenade] future direction on partial upgrade support
On 07/06/2015 09:02 PM, Armando M. wrote: Thanks Sean, comments inline. On 6 July 2015 at 16:58, Sean M. Collins s...@coreitpro.com wrote: I'd also like to chime in - we've had some discussions on -infra today about the partial upgrade issue, and collected the following notes on an etherpad. https://etherpad.openstack.org/p/neutron-partial-upgrades One of the things identified, was the complexity of the DVR feature in Neutron, and an attempt to simplify the partial upgrade job by not enabling the DVR feature. The DVR issue is entirely orthogonal to this, but I am willing to play along. http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-07-06-21.00.log.html Clark Boylan has proposed a patch to create a new job that runs on multiple nodes, but does not have DVR enabled, in the hopes that having less moving parts will allow the multinode grenade work to continue on a parallel track, Who is leading the Grenade effort? Is it Clark? Actually in terms of who stirred the pot, it's me. There were too many people talking in too small of groups for me to stand aside any longer. The grenade job looked like it was going to continue to get blocked without everyone understanding all the factors so I wanted to have folks have a discussion. with bugfixes or additional work on the Neutron DVR feature not blocking the overall effort. The idea would be eventually to enable DVR, once we have taken care of all the other work that needs to be done. https://review.openstack.org/#/c/198906/ I thought that's what Joe did in [1]. Am I barking up at the wrong tree? Joe did smoke tests in that patch yes. Clark's patch just takes a job that was already running full tempest and turned it into two tests one with dvr on and one with dvr off. That is all Clark's patch did. Thanks, Anita. What is everyone's thoughts? [1] https://review.openstack.org/#/c/195259/ -- Sean M. Collins __ OpenStack Development Mailing 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] python-cinderclient functional tests
I support moving it to non-voting from the experimental queue. It will be much more visible that way if something breaks. - Reply message - From: Ivan Kolodyazhny e...@e0ne.info To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Cc: Oleksiy Butenko obute...@mirantis.com, Kyrylo Romanenko kromane...@mirantis.com Subject: [openstack-dev] [Cinder] python-cinderclient functional tests Date: Mon, Jul 6, 2015 1:48 PM Hi all, As you may know, we've got experimental job [1] to run functional tests [2] for python-cinderclient with devstack setup. Functional tests for python-cinderclient is very important because it's almost the only way to test python-cinderclient with Cinder API. For now, we've got only Rally which uses cinderclient to test Cinder. Tempest uses own client for all APIs. Current tests coverage are very low.. That's why I would like to ask everyone to contribute to python-cinderclient. I created etherpad [3] with current progress. You can find me (e0ne) or any other core in #openstack-cinder in IRC. Aslo, what do you think about moving cinderclient functional tests from experimental to non-voting queue to make it more public and run it with every patch to python-cinderclient? [1] https://review.openstack.org/#/c/182528/ [2] https://github.com/openstack/python-cinderclient/tree/master/cinderclient/tests/functional [3] https://etherpad.openstack.org/p/cinder-client-functional-tests Regards, Ivan Kolodyazhny__ OpenStack Development Mailing 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] python-cinderclient functional tests
On 7/6/15 10:28 PM, sean.mcgin...@gmx.com wrote: I support moving it to non-voting from the experimental queue. It will be much more visible that way if something breaks. That makes sense to me. - Reply message - From: Ivan Kolodyazhny e...@e0ne.info To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Cc: Oleksiy Butenko obute...@mirantis.com, Kyrylo Romanenko kromane...@mirantis.com Subject: [openstack-dev] [Cinder] python-cinderclient functional tests Date: Mon, Jul 6, 2015 1:48 PM Hi all, As you may know, we've got experimental job [1] to run functional tests [2] for python-cinderclient with devstack setup. Functional tests for python-cinderclient is very important because it's almost the only way to test python-cinderclient with Cinder API. For now, we've got only Rally which uses cinderclient to test Cinder. Tempest uses own client for all APIs. Current tests coverage are very low.. That's why I would like to ask everyone to contribute to python-cinderclient. I created etherpad [3] with current progress. You can find me (e0ne) or any other core in #openstack-cinder in IRC. Aslo, what do you think about moving cinderclient functional tests from experimental to non-voting queue to make it more public and run it with every patch to python-cinderclient? [1] https://review.openstack.org/#/c/182528/ [2] https://github.com/openstack/python-cinderclient/tree/master/cinderclient/tests/functional [3] https://etherpad.openstack.org/p/cinder-client-functional-tests Regards, Ivan Kolodyazhny __ OpenStack Development Mailing 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] Networking-foo projects and release management in the Neutron Stadium
On Tue, Jul 7, 2015 at 10:44 AM, Kyle Mestery mest...@mestery.com wrote: On Mon, Jul 6, 2015 at 5:07 PM, Takashi Yamamoto yamam...@midokura.com wrote: hi, On Tue, Jul 7, 2015 at 2:20 AM, Kyle Mestery mest...@mestery.com wrote: The tl;dr for this email is that the patch referenced here [1] is moving release management tasks for the networking-foo projects into alignment with other Neutron libraries. There is value in having this consolidated into a single place. The longer version is that as plugin backends and new libraries have integrated into the Neutron Stadium, it makes sense to align some release items here. For example, merge commits, tags, and stable branch management aspects are things which are best done by a central team for all networking-foo projects (along with existing projects). In particular, stable releases have some specific requirements [2] which need to be met as stable releases are done here. Ensuring this is following existing processes is part of the reason for this gerrit ACL change. Please comment on the reviews if you have concerns as a networking-foo owner. can you explain how release procedure will be changed? Sure. We'll rely on the release team to help us release these backend libraries and API repositories. These are the same folks doing releases for both clients and oslo libraries. so, basically a maintainer of networking-foo will ask the release team to push a tag? Thanks! Kyle [1] https://review.openstack.org/#/c/198749/ [2] https://wiki.openstack.org/wiki/StableBranch __ OpenStack Development Mailing 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
[openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected
Hi everybody! Ok. There is nothing more actually useful I can say that isn't in the subject line. As I mentioned previously, the preliminary results from our name election are here: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4983776e190c8dbc As a follow on step, the OpenStack Foundation staff assessed the names chosen for legal risk in the order we ranked them. The first two had significant identified problems... but the third in the list, Meiji (明 治) is clear. So please join me in welcoming the latest name to our family ... and if you, like me, are not a native Japanese speaker, in learning two new characters. Thanks! 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
Re: [openstack-dev] [Cinder] Quobyte Cinder Driver revert?
HI Silvan, A great resource to resolve such issues is the third-party ci meetings [1]. It’s a dedicated time slot to ask questions and get help from other community members such as yourself. Oftentimes, someone else has run into the same issue and already as an answer. Ramy [1] https://wiki.openstack.org/wiki/Meetings/ThirdParty From: Silvan Kaiser [mailto:sil...@quobyte.com] Sent: Friday, July 03, 2015 9:06 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Cinder] Quobyte Cinder Driver revert? Hello again! Ok, now i did find the review [1], sorry i did not earlier. We will solve the CI issues asap in order to provide the requirements to recommit the Quobyte driver. We've been trying to solve the CIs networking issue i wrote about since then but were unable to nail it down completely as we're only a small company and restricted in resources. After the mail from Mike Perez regarding missing reports [2] i had brief contact with him directly via email [3] and once more on the third party mailing list [4]. As i did not receive a message after the replies i did not expect there to be a defined deadline and I did not see information about the impending revert on gerrit, and thus was unable to comment on that. My apologies for that. We're focusing on this with all the team now. Silvan Kaiser [1] https://review.openstack.org/#/c/191192/ [2] http://lists.openstack.org/pipermail/third-party-announce/2015-June/000200.html [3] http://lists.openstack.org/pipermail/third-party-announce/2015-June/000213.html [4] http://lists.openstack.org/pipermail/third-party-announce/2015-June/000214.html 2015-07-03 16:31 GMT+02:00 Silvan Kaiser sil...@quobyte.commailto:sil...@quobyte.com: Hello! I just found the following commit in the cinder log: commit a3f4eed52efce50c2eb1176725bc578272949d7b Merge: 6939b4a e896ae2 Author: Jenkins jenk...@review.openstack.orgmailto:jenk...@review.openstack.org Date: Thu Jul 2 23:14:39 2015 + Merge Revert First version of Cinder driver for Quobyte Is this part of some restructuring work, etc. that i did miss? I could not find a gerrit review for this and had no prior information? I did not see any related information when i did my weekly checks of the cinder weekly meeting logs and am confused to find this commit. We're still working on the CI issues discussed on the CI mailing list and am fully aware that we've to get this stably reporting. This is not a removal because of the CI issues? Best regards Silvan Kaiser -- Dr. Silvan Kaiser Quobyte GmbH Boyenstr. 41 - 10115 Berlin-Mitte - Germany +49-30-814 591 800tel:%2B49-30-814%20591%20800 - www.quobyte.comhttp://www.quobyte.com/http://www.quobyte.com/ Amtsgericht Berlin-Charlottenburg, HRB 149012B Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender -- Dr. Silvan Kaiser Quobyte GmbH Boyenstr. 41 - 10115 Berlin-Mitte - Germany +49-30-814 591 800 - www.quobyte.comhttp://www.quobyte.com/http://www.quobyte.com/ Amtsgericht Berlin-Charlottenburg, HRB 149012B Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender -- Quobyte GmbH Hardenbergplatz 2 - 10623 Berlin - Germany +49-30-814 591 800 - www.quobyte.comhttp://www.quobyte.com/ Amtsgericht Berlin-Charlottenburg, HRB 149012B management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender __ OpenStack Development Mailing 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] [Ironic] ironic-lib library
Thanks everyone for the valuable feedback. Few folks in the Ironic meeting agreed as well releasing often is better idea than git submodules, and we will go ahead with that if no one has any objection. On Wed, Jun 17, 2015 at 9:50 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-06-17 10:10:22 -0400 (-0400), Doug Hellmann wrote: Excerpts from Ramakrishnan G's message of 2015-06-17 12:50:25 +0530: Seems to me like we can keep ironic-lib git repository as a git submodule of the ironic and ironic-python-agent repositories. Any commit in Ironic or Ironic-python-agent can change ironic-lib independently. Also, looks like our CI system supports it by automatically pushing commits in the subscribed projects [1]. Sounds like that should be better instead of making a new release of ironic-lib and waiting for it to be published to make changes in Ironic or Ironic-python-agent. Please don't do this. It's similar to the incubator model used in Oslo, but the benefits there (being able to evolve the API of code formerly tightly coupled to an application) don't apply here. You're writing new code, and can create a library directly. Releasing libraries is easy. We do it often enough that people complain about the extra email. [...] Also, while the software we use does support Git submodules, our infrastructure admins are not supporting use of Git submodules in projects we host for a variety of reasons. The benefits of a submodule over a completely separate Git repository are slim, and usually a sign that you're working around poor design in the involved repos. Further, submodules pose significant potential for confusion among developers, especially those for whom this is their first experience interacting with Git--it's confusing enough--we should strive to keep things as simple as possible for them when the cost of doing so is not particularly high. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Segmentation Fault in nova-compute service on ARM platform.
Hi Guys, I am porting openstack on arm platform, but while running nova-compute service on it throws segmentaion fault. Below are the logs: 2015-06-05 09:24:12.195 11374 INFO nova.virt.driver [-] Loading compute driver 'libvirt.LibvirtDriver' 2015-06-05 09:24:13.483 11374 INFO nova.openstack.common.rpc.common [req-ba16a115-ed64-4fb5-b13e-f28e03a28b24 None None] Connected to AMQP server on 192.168.1.100:5672 2015-06-05 09:24:13.600 11374 INFO nova.openstack.common.rpc.common [req-ba16a115-ed64-4fb5-b13e-f28e03a28b24 None None] Connected to AMQP server on 192.168.1.100:5672 2015-06-05 09:24:13.808 11374 AUDIT nova.service [-] Starting compute node (version 2013.2.2) Program received signal SIGSEGV, Segmentation fault. 0x76f244d4 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 While tracing the same with gdb: I am getting corrupt stack: (gdb) bt #0 0x76f244d4 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 #1 0x76f2ab78 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0 #2 0x76f2905c in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 #3 0x76f2ab78 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0 #4 0x76eaf690 in ?? () from /usr/lib/libpython2.7.so.1.0 Cannot access memory at address 0x0 #5 0x76eaf690 in ?? () from /usr/lib/libpython2.7.so.1.0 Cannot access memory at address 0x0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) The function PyEval_EvalFrameEx () is present in ceval.c Also I am using havana release of openstack. I am new to openstack just tried openstack nodes on x-86 platform. Any help in order to solve the above issue is appreciated. Regards Pradeep Kumar __ OpenStack Development Mailing 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][hyper-v] Instance can't get fixed ip on hyper-v compute node
Hi Claudiu, Thank you very much for the info. I'm going through the steps to have a try. I will give the feedback later if it works. Best regards, Lily Xing(邢莉莉) On Fri, Jun 26, 2015 at 2:06 AM, Claudiu Belu cb...@cloudbasesolutions.com wrote: Hello, ml2 conf file looks fine. nova logs look fine. neutron logs also seem fine, but this worries me a bit: 2015-06-24 20:45:18.556 4116 DEBUG hyperv.neutron.security_groups_driver [req-3786da36-6b03-433d-941e-00327839603c ] Creating port 3 rules prepare_port_filter C:\Program Files (x86)\Cloudbase Solutions\OpenStack\Nova\Python27\lib\site-packages\hyperv\neutron\security_groups_driver.py:54 Can you run this in powershell? # if you have multiple instances spawned. Get-VMNetworkAdapterExtendedAcl -VMName instance-... | ? Action -eq Allow # only one instance Get-VMNetworkAdapterExtendedAcl | ? Action -eq Allow Can you provide the output into a pastebin as well? Now, since you have security groups enabled, there should be a rule that allow DHCP. It should look like this: ParentAdapter : Microsoft.HyperV.PowerShell.VMNetworkAdapter Direction : Inbound Action : Allow LocalIPAddress : ANY RemoteIPAddress: 10.0.0.2 (this might be different for you) LocalPort : 68-68 RemotePort : ANY Protocol : udp Weight : 65480 Stateful : True IdleSessionTimeout : 0 IsolationID: 0 ToRemove : False All the security group rules the Hyper-V Neutron Agent are received from Neutron. This DHCP rule should be amoung them as well by default. If it is not, well, there the issue lies elsewhere, in neutron. Worst case scenario, you can just add the rule: neutron security-group-rule-create --direction ingress --ethertype IPv4 --protocol udp --port-range-min 68 --port-range-max 68 --remote-ip-prefix 10.0.0.2 sg_id Introducing that rule rule should allow DHCP traffic. If that still doesn't solve the issue, the problem might not be the security groups. You could try restarting the neutron-hyperv-agent with enable_security_group=false in the neutron_hyperv_agent.conf file and check if the instances are able to receive an IP. I assume you've checked the troubleshooting section of the page I've linked last time, but just to make sure.. can you check if DHCP is enabled in the subnet the instance was created in? neutron subnet-show subnet_id Then, considering that you went with the 3 NIC Controller and 2 NIC compute node like this: Controller: eth0 - mangement eth1 - vm-data eth2 - external Compute Node: eth0 - management eth1 - vSwitch - vm-data Can you confirm that the Controller eth1 and the Compute Node vSwitch (eth1) are in the same network? Also, Controller eth1, is it promiscuous mode? At this point, we will have to get our hands dirty and do some networking troubleshooting. :) On the Hyper-V Node, run: # $INSTANCE_NAME will be instance- Get-VM -VMName $INSTANCE_NAME | Get-VMConsole In the VM Console, login, and: ifconfig # no assinged IP? then assign it manually (value from OpenStack Controller): sudo ifconfig eth0 $ASSIGNED_IP netmask $NETWORK_NETMASK up ping $DHCP_IP # let it run. On the Controller, run: # both ICMP echo request and ICMP echo reply must be visible, for all commands. sudo tcpdump -vv -eni eth1 icmp sudo tcpdump -vv -eni br-int icmp #get the tap device name sudo ip netns exec qdhcp-$NET_ID ifconfig sudo ip netns exec qdhcp-$NET_ID tcpdump -vv -ni $TAP_NAME If on the first tcpdump you do not see any ping echo request, the traffic is not getting to the Controller. If you see a ping echo request but no ping echo reply, it means that the traffic gets to the Controller, but there is reply sent back. The next commands should reveal where the reply traffic stops. The last tcpdump is the DHCP network namespace. Ideally, there will be both the request and reply messages. Hope this helps find the issue! Best regards, Claudiu Belu -- *From:* Lily.Sing [lily.s...@gmail.com] *Sent:* Thursday, June 25, 2015 8:02 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [neutron][hyper-v] Instance can't get fixed ip on hyper-v compute node Hi Alessandro and Claudiu, Thank you for your quick reply. The version I am running is kilo. Yes I use networking-hyperv. And the windows version is Windows Server 2012 R2. Below are the output for the commands mentioned: Get-VMSwitch Name SwitchType NetAdapterInterfaceDescription -- -- Intel(R) Ethernet Controller X540-AT2 #3 - Virtual Switch External Intel(R) Ethernet Controller X540-AT2 #3 Get-VM | Get-VMNetworkAdapter Name IsManagementOs VMName
Re: [openstack-dev] [Openstack-operators] [keystone][all] Deprecating slash ('/') in project names
Do you mean project names or project IDs? Sam On 3 Jul 2015, at 12:12 am, Henrique Truta henriquecostatr...@gmail.com wrote: Hi everyone, In Kilo, keystone introduced the concept of Hierarchical Multitenancy[1], which allows cloud operators to organize projects in hierarchies. This concept is evolving in Liberty, with the addition of the Reseller use case[2], where among other features, it’ll have hierarchies of domains by making the domain concept a feature of projects and not a different entity: from now on, every domain will be treated as a project that has the “is_domain” property set to True. Currently, getting a project scoped token can be made by only passing the project name and the domain it belongs to, once project names are unique between domains. However with those hierarchies of projects, in M we intend to remove this constraint in order to make a project name unique only in its level in the hierarchy (project parent). In other words, it won’t be possible to have sibling projects with the same name. For example. the following hierarchy will be valid: A - project with the domain feature /\ B C - “pure” projects, children of A | | A B - “pure” projects, children of B and C respectively Therefore, the cloud user faces some problems when getting a project scoped token by name to projects A or B, since keystone won’t be able to distinguish them only by their names. The best way to solve this problem is providing the full hierarchy, like “A/B/A”, “A/B”, “A/C/B” and so on. To achieve this, we intend to deprecate the “/” character in project names in Liberty and prohibit it in M, removing/replacing this character in a database migration**. Do you have some strong reason to keep using this character in project names? How bad would it be for existing deploys? We’d like to hear from you. Best regards, Henrique ** LDAP as assignment backend does not support Hierarchical Multitenancy. This change will be only applied to SQL backends. [1] http://specs.openstack.org/openstack/keystone-specs/specs/juno/hierarchical_multitenancy.html http://specs.openstack.org/openstack/keystone-specs/specs/juno/hierarchical_multitenancy.html [2] http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html ___ OpenStack-operators mailing list 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
[openstack-dev] [designate][lbaas][GSLB] IRC Meeting Tomorrow - 07/Jul/2015 @ 16:00 UTC
Hi All, I have put up an agenda for the meeting tomorrow: https://wiki.openstack.org/wiki/Meetings/GSLB It will be in #openstack-meeting-4 @ 16:00 UTC I sent around a strawman API doc last week - https://docs.google.com/document/d/1nw5jVn0hjmhlhkZJAohx-gqRkkbVhMMJ79Pogd0ysEk/edit?usp=sharing Can everyone have a read before the meeting tomorrow? Thanks, Graham Hayes __ OpenStack Development Mailing 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] mid cycle Sprint dates
I added Congress to the list of Liberty sprints and built a wiki page with basic info: https://wiki.openstack.org/wiki/Sprints/CongressLibertySprint Please RSVP using eventbrite: http://www.eventbrite.com/e/congress-liberty-midcycle-sprint-tickets-17654731778 Tim On Wed, Jul 1, 2015 at 8:58 AM Jeremy Stanley fu...@yuggoth.org wrote: On 2015-07-01 15:40:31 + (+), Tim Hinrichs wrote: We settled on dates and location for the Congress mid cycle sprint: [...] Invoking the spirit of Thierry, please remember to add it to the list at: https://wiki.openstack.org/wiki/Sprints#Liberty_sprints -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [devstack] openstack install error with stable/kilo
Hi, I’m trying to run devstack install of stable/kilo on Ubuntu 14.04 and getting the following error. Any suggestion on how to resolve it? 2015-07-06 13:25:08.670 | + recreate_database glance 2015-07-06 13:25:08.670 | + local db=glance 2015-07-06 13:25:08.670 | + recreate_database_mysql glance 2015-07-06 13:25:08.670 | + local db=glance 2015-07-06 13:25:08.670 | + mysql -uroot -pmysql -h127.0.0.1 -e 'DROP DATABASE IF EXISTS glance;' 2015-07-06 13:25:08.678 | + mysql -uroot -pmysql -h127.0.0.1 -e 'CREATE DATABASE glance CHARACTER SET utf8;' 2015-07-06 13:25:08.684 | + /usr/local/bin/glance-manage db_sync 2015-07-06 13:25:09.067 | Traceback (most recent call last): 2015-07-06 13:25:09.067 | File /usr/local/bin/glance-manage, line 6, in module 2015-07-06 13:25:09.067 | from glance.cmd.manage import main 2015-07-06 13:25:09.067 | File /opt/stack/glance/glance/cmd/manage.py, line 47, in module 2015-07-06 13:25:09.067 | from glance.common import config 2015-07-06 13:25:09.067 | File /opt/stack/glance/glance/common/config.py, line 31, in module 2015-07-06 13:25:09.067 | from paste import deploy 2015-07-06 13:25:09.067 | ImportError: cannot import name deploy Thanks, Danny __ OpenStack Development Mailing 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] [Murano][Congress] Application placement use case
Hi Gosha, This definitely sounds like an interesting use case for Congress. Keep in mind that Congress doesn't itself do placement (though we did some experimentation with that [1][2]). Some thoughts. 1. Let's suppose Murano/Congress/etc. allow us to figure out which app should be deployed in which region. Is there a separate Nova for each region that can do the actual scheduling? If not, how would Murano force the app to be deployed in the proper region? 2. Let's assume Murano can force the app to the proper region. One option for using Congress to compute the proper region would be to write policy statements that enumerate the permitted regions for a given application, and then ask Congress for one of those regions. For your statements above, we could write the following policy statements Solaris is required then select Region_Solaris. Or more complex If Solaris is required then select less loaded regions from [Region_Solaris1, Region_Solaris2] permitted_region(app, region) :- murano:app_requires(app, solaris), [1] Design doc: https://docs.google.com/document/d/1ksDilJYXV-5AXWON8PLMedDKr9NpS8VbT0jIy_MIEtI/edit [2] Slides: https://drive.google.com/a/styra.com/file/d/0ByDz-eYOtswScUFUc1ZrVVhmQlk/view On Thu, Jul 2, 2015 at 7:36 AM Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: Hi, All applications are monolithic so they don't need to be split over multiple regions. It is necessary to have an ability to select a region based on requirements and for now I don't care how they are placed inside the region. I am not sure how region's capabilities will be stored and actually this is a reason why I am asking if Congress will solve this. I can imagine a policy which says if Solaris is required then select Region_Solaris. Or more complex If Solaris is required then select less loaded regions from [Region_Solaris1, Region_Solaris2] In this use case Murano will deploy complex environment which consist of multiple atomic applications with different requirements, so deployment will be across clouds but for whole environment. Imagine IBM MQ on AIX and PowerPC + Oracle DB on Solaris + Microsoft IIS on Windows 2012 HyperV + WebSphere on RHEL KVM. Thanks Gosha On Wed, Jul 1, 2015 at 10:17 PM, ruby.krishnasw...@orange.com wrote: Hi Did you mean placement at “two levels”. First to select the region and then within each region, Nova scheduler will place on hosts. But where will the capabilities of each region (based on which placement decision will be made) be stored? Will each region be queried to obtain this information? Will a single application need to be placed (split across) different regions? Ruby *De :* Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com] *Envoyé :* mercredi 1 juillet 2015 21:26 *À :* OpenStack Development Mailing List *Objet :* [openstack-dev] [Murano][Congress] Application placement use case Hi, I would like to share with the community one of the real use case which we saw while working with one of the Murano customer and ask an advice. This customer has multiple OpenStack regions which are serving for different hypervisors. The reason for that is Oracle OpenStack which is used to work with Solaris on top of SPARC architecture. There are other hypervisors KVM and VMWare which are used. There are multiple applications which should be placed to different regions based on their requirements (OS, Hypervisor, networking restrictions). As there is no single cloud, Nova scheduler can’t be used (at least in my understanding) so we need to have some placement policies to put applications properly. And obviously we don’t want to ask end user about the placement. Right now in Murano we can do this by: 1.Hardcoding placement inside application. This approach will work and does not require any significant change in Murano. But there are obvious limitations like if we have two options for placement which one should be hardcoded. 2.Create special placement scheduler application\class in Murano which will use some logic to place applications properly. This is better approach as nothing is hard coded in applications except their requirements. Applications will just have a workflow to ask placement scheduler for a decision and then will just use this decision. 3.Use some external tool or OpenStack component for placement decision. This is a very generic use case which we saw multiple times. Tools like CIRBA are often used for this. Murano will need an interface to ask these tools. I think about this solution as an extension of 2. I am aware that Murano is working on integration with Congress and I am looking for an opportunity here to address real use case of Murano usage in real customer environment. It will be great to know if OpenStack can offer something here without involving 3rd party tools. I suspect that this is a good use case for Congress, but I would like
Re: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team
Absolutely +1 Edgar From: Kevin Benton Reply-To: OpenStack Development Mailing List (not for usage questions) Date: Monday, July 6, 2015 at 3:02 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year has been important in making the reference implementation reliable. Existing cores, please vote +1/-1 for his addition to the team. Cheers! 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html 2. http://stackalytics.com/report/contribution/neutron/30 http://stackalytics.com/report/contribution/neutron/60 http://stackalytics.com/report/contribution/neutron/90 -- 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] [Murano] Discuss simulated-execution-mode-murano-engine blueprint
Folks,
I have specific topic to discuss: how murano test-fixture will look like
and how it can be run.
The idea is to implement a unit-testing framework, similar to regular
frameworks for python or other languages,
which will allow to define test fixtures in MuranoPL.
A Test fixture is a regular muranoPL class definition, which methods are
the test cases.
When such fixture is included into Murano application package the
deployment of application may be tested without running actual VM's.
Here is how the test fixture may look like:
Namespaces:
=: io.murano.apps.foo.tests
sys: io.murano.system
pckg: io.murano.apps.foo
Extends: io.murano.tests.TestFixture
Name: FooTest
Methods:
initialize:
Body:
*# Object model can be loaded from json file, or provided
directly in murano-pl code as a yaml insertion.*
*# - $.appJson:
new(sys:Resources).json('foo-test-object-model.json')*
- $.appJson:
- ?:
type: io.murano.apps.foo.FooApp
name: my-foo-obj
instance:
?:
type: io.murano.resources.Instance
...
setUp:
Body:
- $.env: $.createEnvironment($.appJson) # creates an instance
of std:Environment
- $.myApp: $.env.applications.where($.name='my-foo-obj').first()
*# mock instance spawning*
- mock($.myApp.instance, deploy, mockInstanceDeploy, $this)
- mock(res:Instance, deploy, mockInstanceDeploy, $this)
testFooApp:
Body:
- $.env.deploy()
- $.assertEqual(true, $.myApp.getAttr('deployed'))
mockInstanceDeploy:
Arguments:
- mockContext
Body:
- Return:
* # heat template*
io.murano.tests.TestFixture - is a base class, that contains set of
methods, needed in all the test-cases which inherit it, such as assertEqual
and other similar assertions.
All it contains a $.createEnvironment method which may be called at the
setUp phase (a method being run before each test case) to construct the
object model to run the test against.
Test developer will be able to mock some of the functions or method which
are out of the scope of the current test
(for example, interaction with other applications or classes from the
standard murano library, such as instance.deploy etc).
The mock will allow to override the actual method execution and provide the
expected output of the method.
The actual implementation of mocking requires more thoughtful design, so
I'll create a separate spec for it.
What do you think about the overall idea and the test syntax proposed above?
On Wed, Jun 3, 2015 at 5:15 PM, Ekaterina Chernova efedor...@mirantis.com
wrote:
Hi all!
I'd like to discuss first implementation thoughts about this [1]
blueprint, that we want to implement in Liberty.
This feature is supposed to increase the speed of application development.
Now engine interacts with API to get input task and packages.
Items, planned to implement first would enable loading local task and new
package, without API and Rabbit involved.
After that simple testing machinery will be added to MuranoPL: mock
support and simple test-runner.
So user can test application methods as he wants by creating simple tests.
Deployment parameters, such as heat stack and murano execution
plan outputs
may be set as returned value in tests.
Finally, tests may be placed into a murano package for easier package
verification and later modification.
I'm going to write specification soon. But before, we need to prepare list
of functions, that are needed to
implement simple mocking machinery in MuranoPL.
Please, leave your thoughts here or directly in the blueprint.
Regards, Kate.
[1] -
https://blueprints.launchpad.net/murano/+spec/simulated-execution-mode-murano-engine
__
OpenStack Development Mailing 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] - Proposing Miguel Angel Ajo for the Control Plane core team
Big +1 On 07/06/2015 06:02 AM, Kevin Benton wrote: Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year has been important in making the reference implementation reliable. Existing cores, please vote +1/-1 for his addition to the team. Cheers! 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html 2. http://stackalytics.com/report/contribution/neutron/30 http://stackalytics.com/report/contribution/neutron/60 http://stackalytics.com/report/contribution/neutron/90 -- 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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
