Re: [openstack-dev] [nova] schedule instance based on CPU frequency ?
On 06/30/2015 07:42 AM, ChangBo Guo wrote: CPU frequency is an import performance parameter, currently nova drivers just report cpu_info without frequency. we stored the compute node cpu_info in database with colum compute_nodes.cpu_info, we can add the frequency easily. The usage of cpu frequency I can think is used to schedule to meet applications which need high frequency. add a frequency based filter ? if we need this , I would like to propose a spec for this . Would it be possible to give more details on the type of app that will have this _specific_ requirement. I don't think I have all the details in my head, but it seems to me that the frequency of the hypervisor CPU is just not something that carries enough information for users about how most applications will perform. I would imagine they would either want the fastest or some specialized HW for specific applications. There are two steps to leverage cpu frequency: 1. report cpu frequency and record the value, nova hypervisor-show will include the value . 2. filter compute nodes based cpu frequency. add a new scheduler filter to do that before I start to do these stuff. I would like to your input . Do we need leverage CPU frequency in Nova ? if yes, do we need a new filter or leverage existing filter to use frequency ? I don't think we do personally - but I may not understand what problem this is trying to solve. But even if we do - the most important thing IMHO would be _how_ to expose it to users (do we allow them to request a minimum frequency, or a specific one or something else). API contract is extremely important here because we want to make sure that we are exposing the right semantics for users - as we would want this to be usable to as big a group of people as possible. If it's just about having a high performance tier - can we do this with host aggregates and flavors? These are the questions we want to answer first IMHO. N. -- 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 __ OpenStack Development Mailing 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] gate is wedged
Le 30/06/2015 10:32, Victor Stinner a écrit : Hi, Le 30/06/2015 05:49, Matt Riedemann a écrit : Alternatively, oslo.versionedobjects 0.5.1 is cut after https://review.openstack.org/#/c/196926/ is merged and then we just need haypo's test_db_api fix for the oslo.db 2.0.0 change: https://review.openstack.org/#/c/196719/ I updated my patch Update test_db_api for oslo.db 2.0 (1) to not depend on my Fix Python 3 issues in nova.db.sqlalchemy patch. I should now be easier to fix gates. (1) https://review.openstack.org/#/c/196719/ (2) https://review.openstack.org/#/c/195191/ I suggest to block my Python 3 patch (2) until gates are fixed. Jenkins seems in a pretty bad shape too, by giving UNSTABLE statuses for most of the jobs. http://logs.openstack.org/91/195191/6/check/gate-nova-python27/4a1fdae/console.html#_2015-06-30_05_44_39_393 -Sylvain Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
On Mon, Jun 29 2015, Julien Danjou wrote: FTR today I've copied the members of ceilometer-core to aodh-core. We'll be able to manage to the team independently like we do with Gnocchi, based on who is doing what in the different repositories. Hi team, Aodh has been imported and is now available at: https://git.openstack.org/cgit/openstack/aodh/ You should add it to your review list on Gerrit I guess. I'm pretty clear about the next steps for Aodh and what we need to build, but something is still not clear to me. Do we go ahead and bite the bullet and remove ceilometer-alarming from ceilometer in Liberty? -- Julien Danjou // Free Software hacker // http://julien.danjou.info signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] gate is wedged
Hi, Le 30/06/2015 05:49, Matt Riedemann a écrit : Alternatively, oslo.versionedobjects 0.5.1 is cut after https://review.openstack.org/#/c/196926/ is merged and then we just need haypo's test_db_api fix for the oslo.db 2.0.0 change: https://review.openstack.org/#/c/196719/ I updated my patch Update test_db_api for oslo.db 2.0 (1) to not depend on my Fix Python 3 issues in nova.db.sqlalchemy patch. I should now be easier to fix gates. (1) https://review.openstack.org/#/c/196719/ (2) https://review.openstack.org/#/c/195191/ I suggest to block my Python 3 patch (2) until gates are fixed. Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Fuel-Library] Nominate Aleksandr Didenko for fuel-library core
+1 On Tue, Jun 30, 2015 at 9:34 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote: +1. Alex's doing a great job! On Mon, Jun 29, 2015 at 5:40 PM, Sergey Vasilenko svasile...@mirantis.com wrote: +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] OpenStack CI harddisk failure - jobs are UNSTABLE
static.openstack.org has a harddisk failure for the log volume
which causes jobs to fail with UNSTABLE when uploading log files.
Do not recheck those jobs until you get the green light and and
everything is working again,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] schedule instance based on CPU frequency ?
On Tue, Jun 30, 2015 at 02:42:01PM +0800, ChangBo Guo wrote: CPU frequency is an import performance parameter, currently nova drivers just report cpu_info without frequency. we stored the compute node cpu_info in database with colum compute_nodes.cpu_info, we can add the frequency easily. Is CPU frequency really an accurate metric for determining relative performance of different hardware ? It seems maximum CPU frequency of CPUs has rather plateaued, and chip vendors have been following different avenues to improve performance of their chips such as multicore, multhreads, and various other architectural changes. So I'm not sure that just having a filter that compares CPU frequency is neccessarily going to give useful results. ie faster frequency no longer neccessarily implies faster performance. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] gate is wedged
On 06/30/2015 10:39 AM, Sylvain Bauza wrote:
Le 30/06/2015 10:32, Victor Stinner a écrit :
Hi,
Le 30/06/2015 05:49, Matt Riedemann a écrit :
Alternatively, oslo.versionedobjects 0.5.1 is cut after
https://review.openstack.org/#/c/196926/ is merged and then we just need
haypo's test_db_api fix for the oslo.db 2.0.0 change:
https://review.openstack.org/#/c/196719/
I updated my patch Update test_db_api for oslo.db 2.0 (1) to not
depend on my Fix Python 3 issues in nova.db.sqlalchemy patch. I
should now be easier to fix gates.
(1) https://review.openstack.org/#/c/196719/
(2) https://review.openstack.org/#/c/195191/
I suggest to block my Python 3 patch (2) until gates are fixed.
Jenkins seems in a pretty bad shape too, by giving UNSTABLE statuses for
most of the jobs.
http://logs.openstack.org/91/195191/6/check/gate-nova-python27/4a1fdae/console.html#_2015-06-30_05_44_39_393
Yes, we have a harddisk failure ;(
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] Libvirt - updates backing file permission of qcow2 image on launching instance
Hi All, I am trying to fix a race condition between imagebackend and imagecache in nova (openstack) while creating an instance using qcow2 image backend. On creating a qcow2 image libvirt stores the base/backing file path reference while copying the image at instance disk info. While spawning the instance nova usage this base file reference as a backing file to launch instance. When base file is created in nova image cache directory its owner is set to openstack (a nova user) but on launching the instance from guest.launch, libvirt updates the base/backing file owner from openstack to libvirt-qemu which causes permission error if we try to use that base file later. Can someone please help me to understand why libvirt is updating the owner of base file stored in image cache directory, is it a bug in libvirt or the expected behaviour? Thanks Regards, Ankit Agrawal __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.__ OpenStack Development Mailing 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] gate is wedged
Le 30/06/2015 10:32, Victor Stinner a écrit : I updated my patch Update test_db_api for oslo.db 2.0 (1) ... (1) https://review.openstack.org/#/c/196719/ I updated my patch again to also block oslo.versionedobjects 0.5.0 in requirements. So we can have two patches to fix the bug ;) The patch (1) only fixes the bug, whereas the Python 3 patch fixes many other things (Python 3 support, remove test-requirements-py3.txt, etc.). At the same time, we have issues on the OpenStack infra :-/ 10:48 -!- ChanServ changed the topic of #openstack-infra to: OpenStack CI is down due to hard drive failures Victor __ OpenStack Development Mailing 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] Aodh has been imported, next steps
On Mon, Jun 29 2015, Ildikó Váncsa wrote: I think removing options from the API requires version bump. So if we plan to do this, that should be introduced in v3 as opposed to v2, which should remain the same and maintained for two cycles (assuming that we still have this policy in OpenStack). It this is achievable by removing the old code and relying on the new repo that would be the best, if not then we need to figure out how to freeze the old code. This is not an API change as we're not modifying anything in the API. It's just the endpoint *potentially* split in two. But you can also merge them as they are 2 separate entities (/v2/alarms and /v2/*). So there's no need for a v3 here. As the consensus goes toward removal, I'll work on a patch for that. -- Julien Danjou /* Free Software hacker http://julien.danjou.info */ signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Python 2.6 failed jobs for SQLA-Migrate
Hi, Mike nicely tried to help me to get sqla-migrate to work with sqlalchemy 1.0.6 which is now in Debian. But there's some failures in Python 2.6: https://review.openstack.org/#/c/197144/ Do we still care about them? Can we get them removed from -migrate? IMO, supporting the last SQLA is more important than the old Py 2.6. Thoughts anyone? Cheers, Thomas Goirand (zigo) __ OpenStack Development Mailing 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/01/2015 03:26 AM, Tony Breeds wrote: Hi All, I'm pretty new to this but I'll ask anyway. python-novaclient contains a bash completion script . When installed from pypi this script isn't packaged (and therefore it isn't installed). I created https://review.openstack.org/#/c/196919/ to gather feedback on: a) this this a thing we can/should do ; b) How do we (in the package) handle the case where /etc/bash_completion.d dosn't exist I'm using python-novaclient here but I suspect this applies to all the python0*client repos. Yours Tony. Hi, Please don't do this. This is the kind of job to be done by package maintainers in distribution, because mostly, Python maintainers wouldn't know how to do things correctly. Here we've got a good example: the bash completion scripts are now to be installed in /usr/share/bash-completion/completions and not in /etc. As for the general project config files, I often install them in /usr/share/project-common, and then copy the file in /etc/project in a postinst, so that the file isn't marked as CONFFILE. So please don't attempt to do the work of distributions. We then end up with config files in /usr/etc (as per what happen with Neutron packages), and it's a mess to un-cruft. Cheers, Thomas Goirand (zigo) __ OpenStack Development Mailing 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] Huawei CI's problem have been solved, and is reporting stably now.
Hi Mike, We have solved the problem of Huawei CI, and it is running and reporting stably now. The logs is also ok to access. Following are the very recently patchs it have been posted to: https://review.openstack.org/180873 https://review.openstack.org/186312 https://review.openstack.org/193954 https://review.openstack.org/195027 https://review.openstack.org/163641 https://review.openstack.org/196818 https://review.openstack.org/177054 https://review.openstack.org/184404 https://review.openstack.org/196888 https://review.openstack.org/193937 https://review.openstack.org/195795 https://review.openstack.org/193003 https://review.openstack.org/188328 https://review.openstack.org/194549 https://review.openstack.org/188240 https://review.openstack.org/196966 https://review.openstack.org/194524 https://review.openstack.org/196979 https://review.openstack.org/163641 https://review.openstack.org/195027 https://review.openstack.org/193124 https://review.openstack.org/194532 https://review.openstack.org/180873 https://review.openstack.org/139071 https://review.openstack.org/156939 https://review.openstack.org/196071 https://review.openstack.org/197049 https://review.openstack.org/197065 We will be very appreciate if you can have a consider of remove the -2 review to Huawei driver, thanks! ☺ The following patchs of Huawei driver is still marked as “CI failure”: https://review.openstack.org/#/c/188240/ https://review.openstack.org/#/c/188732/ https://review.openstack.org/#/c/188365/ https://review.openstack.org/#/c/188360/ https://review.openstack.org/#/c/188251/ Thanks, Liu __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][packaging] Adding files to /etc in a package
On Wed, Jul 01, 2015 at 03:55:53AM +0200, Thomas Goirand wrote: Please don't do this. This is the kind of job to be done by package maintainers in distribution, because mostly, Python maintainers wouldn't know how to do things correctly. Here we've got a good example: the bash completion scripts are now to be installed in /usr/share/bash-completion/completions and not in /etc. As for the general project config files, I often install them in /usr/share/project-common, and then copy the file in /etc/project in a postinst, so that the file isn't marked as CONFFILE. So please don't attempt to do the work of distributions. We then end up with config files in /usr/etc (as per what happen with Neutron packages), and it's a mess to un-cruft. Okay so I take you point no problem, but I'm not running distro packages and I still want completions. There must be a way to package the file to at least make it easier to achieve both our goals. Right now I have to manually wget the file from git.o.o which isn't really okay IMO. Could the python package make /usr/share/doc/python-novaclient/tools and ship it there. That would mean that distribution packaging could just take that file and install it in the correct and usful location AND I could just symlink it and we both win. Yours Tony. pgpEiiCxPNc48.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates
For @Tom's suggestion, I +1 about it, maintain a separate heat-coe-templates is very inefficient.[As @HongBin's comments below] Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan） IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Fox, Kevin M kevin@pnnl.gov To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 06/30/2015 11:40 PM Subject:Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates Whats the timeframe? I was really hoping for Liberty but its sounding like thats unlikely? M then? The app catalog really needs conditionals for the same reason. :/ Thanks, Kevin From: Angus Salkeld [asalk...@mirantis.com] Sent: Monday, June 29, 2015 6:56 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates On Tue, Jun 30, 2015 at 8:23 AM, Fox, Kevin M kevin@pnnl.gov wrote: Needing to fork templates to tweak things is a very common problem. Adding conditionals to Heat was discussed at the Summit. ( https://etherpad.openstack.org/p/YVR-heat-liberty-template-format). I want to say, someone was going to prototype it using YAQL, but I don't remember who. I was going to do that, but I would not expect that ready in a very short time frame. It needs some investigation and agreement from others. I'd suggest making you decision based on what we have now. -Angus Would it be reasonable to keep if conditionals worked? Thanks, Kevin From: Hongbin Lu [hongbin...@huawei.com] Sent: Monday, June 29, 2015 3:01 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates Agree. The motivation of pulling templates out of Magnum tree is hoping these templates can be leveraged by a larger community and get more feedback. However, it is unlikely to be the case in practise, because different people has their own version of templates for addressing different use cases. It is proven to be hard to consolidate different templates even if these templates share a large amount of duplicated code (recall that we have to copy-and-paste the original template to add support for Ironic and CoreOS). So, +1 for stopping usage of heat-coe-templates. Best regards, Hongbin -Original Message- From: Tom Cammann [mailto:tom.camm...@hp.com] Sent: June-29-15 11:16 AM To: openstack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Magnum] Continuing with heat-coe-templates Hello team, I've been doing work in Magnum recently to align our templates with the upstream templates from larsks/heat-kubernetes[1]. I've also been porting these changes to the stackforge/heat-coe-templates[2] repo. I'm currently not convinced that maintaining a separate repo for Magnum templates (stackforge/heat-coe-templates) is beneficial for Magnum or the community. Firstly it is very difficult to draw a line on what should be allowed into the heat-coe-templates. We are currently taking out changes[3] that introduced useful autoscaling capabilities in the templates but that didn't fit the Magnum plan. If we are going to treat the heat-coe-templates in that way then this extra repo will not allow organic development of new and old container engine templates that are not tied into Magnum. Another recent change[4] in development is smart autoscaling of bays which introduces parameters that don't make a lot of sense outside of Magnum. There are also difficult interdependency problems between the templates and the Magnum project such as the parameter fields. If a required parameter is added into the template the Magnum code must be also updated in the same commit to avoid functional test failures. This can be avoided using Depends-On: #xx feature of gerrit, but it is an additional overhead and will require some CI setup. Additionally we would have to version the templates, which I assume would be necessary to allow for packaging. This brings with it is own problems. As far as I am aware there are no other people using the heat-coe-templates beyond the Magnum team, if we want independent growth of this repo it will need to be adopted by other people rather than Magnum commiters. I don't see the heat templates as a dependency of Magnum, I see them as a truly fundamental part of Magnum which is going to be very difficult to
[openstack-dev] [Neutron] Issue with neutron-dhcp-agent not recovering known ports cache after restart
Hi folks.. I have a question about neutron dhcp agent restart scenario. It seems like, when the agent restarts, it recovers the known network IDs in cache, but we don't recover the known ports [1]. So if a port that was present before agent restarted, is deleted after agent restart, the agent wont have it in its cache. So port here [2] will be None. So the port will actually never get deleted. Same problem will happen if a port is updated. Has anyone seen these issues? Am I missing something? [1] https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L82-L87 [2] https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L349 __ OpenStack Development Mailing 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][packaging] Adding files to /etc in a package
Hi All, I'm pretty new to this but I'll ask anyway. python-novaclient contains a bash completion script . When installed from pypi this script isn't packaged (and therefore it isn't installed). I created https://review.openstack.org/#/c/196919/ to gather feedback on: a) this this a thing we can/should do ; b) How do we (in the package) handle the case where /etc/bash_completion.d dosn't exist I'm using python-novaclient here but I suspect this applies to all the python0*client repos. Yours Tony. pgpJPOvpqEKtv.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Issue with neutron-dhcp-agent not recovering known ports cache after restart
hi Shraddha Pandhe, I think your analysis is right, I also encountered the same problem， I have filed a bug[1] and commit a patch [2] for this bug. thanks, hanzhang shi [1] https://launchpad.net/bugs/1469615 [2] https://review.openstack.org/#/c/196927/ 在 2015-07-01 08:25:48，Shraddha Pandhe spandhe.openst...@gmail.com 写道： Hi folks.. I have a question about neutron dhcp agent restart scenario. It seems like, when the agent restarts, it recovers the known network IDs in cache, but we don't recover the known ports [1]. So if a port that was present before agent restarted, is deleted after agent restart, the agent wont have it in its cache. So port here [2] will be None. So the port will actually never get deleted. Same problem will happen if a port is updated. Has anyone seen these issues? Am I missing something? [1] https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L82-L87 [2] https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L349 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla][release] Announcing Liberty-1 release of Kolla
On 6/30/15, 18:36, Daniel Comnea comnea.d...@gmail.com wrote: Ian, a while ago it was discussed on operator's mailing list between Kevin, Steve co http://lists.openstack.org/pipermail/openstack-operators/2015-June/007267. html Thanks for that pointer Daniel, I missed that. On Tue, Jun 30, 2015 at 8:28 PM, Ian Cordasco ian.corda...@rackspace.com wrote: On 6/29/15, 23:59, Steven Dake (stdake) std...@cisco.com wrote: The Kolla community is pleased to announce the release of the Kolla Liberty 1 milestone. This release fixes 56 bugs and implements 14 blueprints! Our community developed the following notable features: * A start at source-basedcontainers So how does this now compare to the stackforge/os-ansible-deployment (soon to be openstack/openstack-ansible) project? __ 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-dev] [neutron] dangerous allowed_address_pairs?
Hi All, Would someone help me understand some potentially dangerous interactions between allowed_address_pairs and security groups? My cloud is Icehouse at the moment, but the behaviour seems unchanged in master. [1] Suppose a User wants to build an instance that acts as a router. User creates an instance named ROUTER with an interface that has an allowed_address_pair of 0.0.0.0/0. (to bypass the anti-spoofing security group feature) By default, ROUTER is in the 'default' security group. User also creates an instance named WEB. By default, WEB is in the 'default' security group. The 'default' security group allows inbound traffic from other hosts(and associated allowed_address_pairs) in the 'default' security group. Now, WEB receives all traffic from 0.0.0.0/0 because User didn't realize that allowed_address_pairs associated with ROUTER would effectively change all associated security groups to be fully permissive. Have I missed something? This seems like exceedingly dangerous behaviour. I've already seen two instances of this from my users. [1] https://github.com/openstack/neutron/blob/master/neutron/db/securitygroups_rpc_base.py#L287 Cheers, James -- James Dempsey Senior Cloud Engineer Catalyst IT Limited +64 4 803 2264 -- __ OpenStack Development Mailing 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] weekly meeting #40
We did our meeting, you can read the notes here: http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-06-30-15.00.html Best, On Sun, Jun 28, 2015 at 3:01 PM, Emilien Macchi emil...@redhat.com wrote: Hi everyone, Here's an initial agenda for our weekly meeting next Tuesday at 1500 UTC in #openstack-meeting-4: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150630 Please add additional items you'd like to discuss. -- 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 -- 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
Re: [openstack-dev] [nova] schedule instance based on CPU frequency ?
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. 2015-07-01 2:58 GMT+08:00 Jay Pipes jaypi...@gmail.com: On 06/30/2015 02:42 AM, ChangBo Guo wrote: CPU frequency is an import performance parameter, currently nova drivers just report cpu_info without frequency. we stored the compute node cpu_info in database with colum compute_nodes.cpu_info, we can add the frequency easily. The usage of cpu frequency I can think is used to schedule to meet applications which need high frequency. add a frequency based filter ? if we need this , I would like to propose a spec for this . There are two steps to leverage cpu frequency: 1. report cpu frequency and record the value, nova hypervisor-show will include the value . 2. filter compute nodes based cpu frequency. add a new scheduler filter to do that before I start to do these stuff. I would like to your input . Do we need leverage CPU frequency in Nova ? if yes, do we need a new filter or leverage existing filter to use frequency ? Like Dan B, I question whether CPU frequency really is a useful metric for scheduling decisions. That said, it is already possible to use CPU frequency in the MetricsWeigher scheduler weigher. The compute monitor plugin system is currently being overhauled [1], but the functionality to monitor CPU-related metrics already exists in Nova and can be enabled by doing the following in your nova-compute nova.conf: compute_monitors = ComputeDriverCPUMonitor Note that with the refactoring of the monitoring plugin interface, the above option will change due to using stevedore to load monitor extensions: compute_monitors = nova.compute.monitors.cpu.virt_driver:Monitor In your Nova scheduler nova.conf, you will need to add the following in the [metrics] section of the file: weights_setting = cpu.frequency=10.0 Again, I'm not saying that the above will result in any appreciable enhancement to the scheduler's decision-making, but it will do what you're trying to accomplish :) Best, -jay [1] https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1468012,n,z __ OpenStack Development Mailing 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] dangerous allowed_address_pairs?
Yes, this is expected behavior. Allows address pairs were mainly intended for a few extra IP addresses that the port owns. Using /0 implies that the Neutron port is responsible for all of those addresses. So if you allow traffic from that Neutron port, it allows traffic from /0. The router use-case should probably be documented to use either a separate security group or to disable the security groups completely on the router port using the port-security-enabled flag. http://specs.openstack.org/openstack/neutron-specs/specs/kilo/ml2-ovs-portsecurity.html On Tue, Jun 30, 2015 at 6:42 PM, James Dempsey jam...@catalyst.net.nz wrote: Hi All, Would someone help me understand some potentially dangerous interactions between allowed_address_pairs and security groups? My cloud is Icehouse at the moment, but the behaviour seems unchanged in master. [1] Suppose a User wants to build an instance that acts as a router. User creates an instance named ROUTER with an interface that has an allowed_address_pair of 0.0.0.0/0. (to bypass the anti-spoofing security group feature) By default, ROUTER is in the 'default' security group. User also creates an instance named WEB. By default, WEB is in the 'default' security group. The 'default' security group allows inbound traffic from other hosts(and associated allowed_address_pairs) in the 'default' security group. Now, WEB receives all traffic from 0.0.0.0/0 because User didn't realize that allowed_address_pairs associated with ROUTER would effectively change all associated security groups to be fully permissive. Have I missed something? This seems like exceedingly dangerous behaviour. I've already seen two instances of this from my users. [1] https://github.com/openstack/neutron/blob/master/neutron/db/securitygroups_rpc_base.py#L287 Cheers, James -- James Dempsey Senior Cloud Engineer Catalyst IT Limited +64 4 803 2264 -- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Tricircle]Weekly Meeting 2015.07.01
Hi Team, We will have weekly meeting on Wednesday from UTC1300 to UTC1400 as usual. The main topic would be to discuss https://review.openstack.org/#/c/196564/, and any other business that people are interested :) -- Zhipeng (Howard) Huang Standard Engineer IT Standard Patent/IT Prooduct Line Huawei Technologies Co,. Ltd Email: huangzhip...@huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipe...@uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado __ OpenStack Development Mailing 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] Use devstack/master to install older releases
Hi, I'm trying to use devstack/master to install older releases of swift and keystone; the installation fails with a version conflict on pbr. A little bit of background : I work on a CI that needs to run the swift functional test suite and the swift part of tempest against swift/icehouse, swift/ijuno swift/kilo swift/master. My first approach was to use devstack/icehouse to install swift/icehouse, devstack/juno for swift/juno, etc 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. So I use devstack/master, and set SWIFT_BRANCH and KEYSTONE_BRANCH to stable/icehouse for example. The installation fails because of a version conflict : This https://review.openstack.org/gitweb?p=openstack-dev/devstack.git;a=blob;f=lib/infra;h=3d68e45bd9954a7ce0003d809428c979663d2ede;hb=HEAD#l51 install the last pbr version, whereas keystone requires pdb1.0 : https://github.com/openstack/keystone/blob/stable/icehouse/requirements.txt#L2 I don't now anything about this lib/infra : does it really need to install unconditionally the last pbr ? Is my use case of installing older releases with devstack/master not supported ? Thanks. Emmanuel Cazenave __ OpenStack Development Mailing 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] Security Group API differences between Neutron and Amazon AWS
Good morning, In last week's meeting I had an action item[0] to take a look at the Amazon EC2/VPC API and determine what differences there are between Neutron's and theirs. In some spec reviews, I have been commenting about trying to keep the Neutron security group API from drifting too far from the Amazon EC2 API, since the concept of the security group came from Amazon and I believe that we should not be bolting on more functionality to an Amazon concept. Rather, I would like to see Neutron create new APIs to further differentiate OpenStack from Amazon AWS, since that gives us elbow room to innovate without having to worry about compatibility, and possibly gives us cover on the legal front since there are a lot of court cases flying around about patents on APIs[1]. In many instances, I believe that much of the new functionality that people are seeking to create should be put into the Firewall-As-A-Service API, but that's a discussion for another e-mail. Anyway, over a cup of coffee today I went and did some reading about the differences between the Neutron security group API and Amazon's. Here are my preliminary findings. Amazon's Security Group API comes in two types: * EC2-Classic * EC2-VPC Security groups in the VPC API are documented at: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html There is a useful section on the differences between the EC2-Classic and EC2-VPC. A more in depth documentation for the AWS Security Group API is located here: Data Types: http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_SecurityGroup.html http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_IpPermission.html http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_PrefixListId.html http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_UserIdGroupPair.html API methods: http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupIngress.html http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupEgress.html I used the following for the Security Group API on the Neutron side: http://developer.openstack.org/api-ref-networking-v2-ext.html Overall, the attributes are *named differently* but contain similar concepts. Both Security Group APIs contain: * IP Prefix/CIDR * From port * To port * Protocol One difference is that the AWS API distinguishes between Ingress and Egress at the API endpoint, rather than being an attribute. https://ec2.amazonaws.com/?Action=AuthorizeSecurityGroupEgress https://ec2.amazonaws.com/?Action=AuthorizeSecurityGroupIngress Another difference is that the Neutron Security Group API does have an interesting attribute named remote_group_id that doesn't have any real documentation, but I am making a guess that it possibly matches up to the UserIdGroupPair type in AWS. Perhaps someone could shed some light on that, and then document it (not sure where yet). The AWS API and Neutron also share an attribute that can list an IP prefix to match - remote_prefix_id in Neutron, and PrefixListIds in EC2. However it appears that the PrefixListIds type can contain multiple prefixes. Neutron has an ethertype for selecting IPv4 or IPv6, while Amazon does not, since Amazon does not have IPv6 in EC2 (they do have IPv6 in the elastic loadbalancer product[2]). This is at least my preliminary findings. Do feel free to double check my work and see if there is anything that I have overlooked or made a mistake on. [0]: http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-06-22-21.00.html [1]: https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc. [2]: https://aws.amazon.com/about-aws/whats-new/2011/05/24/elb-ipv6-zoneapex-securitygroups/ -- 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
On Tue, Jun 30 2015, Ildikó Váncsa wrote: Will this be accessible in the same way as currently or it needs changes on client side? You may just need to pass more options to the client to force another endpoint to be used when talking to the alarming part. We could make this change in the client by default though. -- Julien Danjou # Free Software hacker # http://julien.danjou.info signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] Ideas to detect Oslo regressions earlier
Hi, Unfortunately, it looks like each regressions introduced by releases of Oslo libraries are still common :-( We already have tools to detect regressions, but they are run manually. It would be nice to automate these tests and run them more frequently (at least one per week, or even daily?). There are tools to run unit tests of projects like neutronclient or nova on the development version of oslo.* libraries. They take up to 12 hours to run all tests. Example of tools: - tox -e venv -- oslo_run_pre_release_tests in each Oslo project - tools/oslo_run_cross_tests in oslotest To prepare the latest bunch of releases, dims wrote two patches to run nova unit tests and tempest: * https://review.openstack.org/#/c/186413/ * https://review.openstack.org/#/c/186418/ Unfortunately, the stable version of some oslo.* projects were used instead of the development version, and 2 regressions were missed :-/ It would nice to automate a job running cinder, nova and neutron unit tests and tempest on the development versions (git master branch) of all oslo.* projects. We can start with something simple: run tools/oslo_run_cross_tests and send the result by email every day to some people interested by the result (ex: Oslo liaisons, or just me if nobody cares). It would be nice to have a dedicated resource in the OpenStack infra for such job. I proposed to run all tests using Gerrit for each patch send to an Oslo project, but it would use too much resources of the OpenStack infra. Another idea would be to write a check job dedicated to Oslo releases and use Gerrit to prepare a release (at least to tag a version in Git). Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header
On Mon, Jun 29, 2015 at 7:41 PM, Ken'ichi Ohmichi ken1ohmi...@gmail.com wrote: Yeah, I had the same thinking. Based on it, we can remove generic name(compute, identity, etc) from API microversions header. I'm not certain we want to remove the name, but to use the type field as the value of the name in the header. I tend to prefer generic name(compute, identity, etc) because the name seems stable. +1 dt -- Dean Troyer dtro...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Ideas to detect Oslo regressions earlier
Victor, Thanks for bringing this up. All good ideas, i'd recommend any liaisons interested to test what they can towards the end of the week and bring it up on the Monday Oslo meeting and/or log bugs as they find stuff. Since we talk about releases for the week at that meeting, we can do a go or no-go decision for specific libraries and then cut the libraries. For the record, the oslo.db issue was debated before the release and a few reviews were filed. The oslo.versionedobjects definitely something i missed. apologies. Thanks, dims On Tue, Jun 30, 2015 at 8:13 AM, Victor Stinner vstin...@redhat.com wrote: Hi, Unfortunately, it looks like each regressions introduced by releases of Oslo libraries are still common :-( We already have tools to detect regressions, but they are run manually. It would be nice to automate these tests and run them more frequently (at least one per week, or even daily?). There are tools to run unit tests of projects like neutronclient or nova on the development version of oslo.* libraries. They take up to 12 hours to run all tests. Example of tools: - tox -e venv -- oslo_run_pre_release_tests in each Oslo project - tools/oslo_run_cross_tests in oslotest To prepare the latest bunch of releases, dims wrote two patches to run nova unit tests and tempest: * https://review.openstack.org/#/c/186413/ * https://review.openstack.org/#/c/186418/ Unfortunately, the stable version of some oslo.* projects were used instead of the development version, and 2 regressions were missed :-/ It would nice to automate a job running cinder, nova and neutron unit tests and tempest on the development versions (git master branch) of all oslo.* projects. We can start with something simple: run tools/oslo_run_cross_tests and send the result by email every day to some people interested by the result (ex: Oslo liaisons, or just me if nobody cares). It would be nice to have a dedicated resource in the OpenStack infra for such job. I proposed to run all tests using Gerrit for each patch send to an Oslo project, but it would use too much resources of the OpenStack infra. Another idea would be to write a check job dedicated to Oslo releases and use Gerrit to prepare a release (at least to tag a version in Git). Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing 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][ceph] puppet-ceph CI status
On 06/29/2015 11:16 PM, Matt Fischer wrote: Ah, I don't have +2 on that repo, but the lgtm so your original plan is fine. On Mon, Jun 29, 2015 at 5:59 PM, Matt Fischer m...@mattfischer.com mailto:m...@mattfischer.com wrote: I can take a look at these tonight. Maybe also Clayton can review them? Neither of us were involved in the patches to my knowledge. On Jun 29, 2015 5:09 PM, Andrew Woodward xar...@gmail.com mailto:xar...@gmail.com wrote: Hi Recent changes in the puppet modules infra left stackforge/puppet-ceph CI broken. We've resolved the issues in [1][2] However we are short on non-involved core-reviewers. You'll have to sqash the commits because our CI is voting for puppet4 beaker. If this module does not fit for you, you can still patch project-config, otherwise you'll need to fix everything in one single commit. I propose that we leave the patchs open through Wednesday and use lazy consensus and merge it if we don't receive any negative feedback. [1] https://review.openstack.org/#/c/179645/ [2] https://review.openstack.org/#/c/195959/ -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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
[openstack-dev] Why doesn't Gerrit email me?
Apologies if this is an FAQ - I tried a quick search, but that didn't find anything that looked both up to date and authoritative. I keep going back to Gerrit jobs that I've reviewed or commented on, and finding that there have been other comments since mine, but that Gerrit didn't email me about. Does anyone know why that happens? It's really important to my workflow, and to continuing review conversations effectively, that Gerrit emails new comments reliably and in good time. Could I be doing something wrong that is causing this not to happen? Many thanks, Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Why doesn't Gerrit email me?
On Tue, Jun 30 2015, Neil Jerram wrote: Apologies if this is an FAQ - I tried a quick search, but that didn't find anything that looked both up to date and authoritative. I keep going back to Gerrit jobs that I've reviewed or commented on, and finding that there have been other comments since mine, but that Gerrit didn't email me about. Does anyone know why that happens? It's really important to my workflow, and to continuing review conversations effectively, that Gerrit emails new comments reliably and in good time. Could I be doing something wrong that is causing this not to happen? Maybe you need to add the projects you care about in Watched Projects at https://review.openstack.org/#/settings/projects -- Julien Danjou ;; Free Software hacker ;; http://julien.danjou.info signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] oslo.messaging version and RabbitMQ heartbeat support
On 06/23/2015 06:07 PM, Mike Dorman wrote: 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.� +1 We should follow: * what popular distros ship * what we test in our CI (trusty UCA centos7 RDO) 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
Re: [openstack-dev] [oslo] Ideas to detect Oslo regressions earlier
Excerpts from Victor Stinner's message of 2015-06-30 14:13:21 +0200: Hi, Unfortunately, it looks like each regressions introduced by releases of Oslo libraries are still common :-( We already have tools to detect regressions, but they are run manually. It would be nice to automate these tests and run them more frequently (at least one per week, or even daily?). There are tools to run unit tests of projects like neutronclient or nova on the development version of oslo.* libraries. They take up to 12 hours to run all tests. Example of tools: 12 hours was a guess -- I usually run the tests overnight because some of them do tend to run several hours. - tox -e venv -- oslo_run_pre_release_tests in each Oslo project - tools/oslo_run_cross_tests in oslotest To prepare the latest bunch of releases, dims wrote two patches to run nova unit tests and tempest: tempest does run for every patch submitted, so we have the integration test space covered. We don't have the unit test jobs and pep8 jobs automated right now because of the test matrix. Today 73 projects in the openstack/* namespace use oslo.config. Testing all of those for unit test and pep8 regressions (yes, those happen) for one patch to oslo.config would take 146 test nodes. It's possible to run all of the unit tests serially on the same server, using the tools you mention, but that takes longer than our current timeout. We might be able to set up an experimental or periodic job to run those tests, but given the length of time they take we wouldn't want to run them automatically for each patch. * https://review.openstack.org/#/c/186413/ * https://review.openstack.org/#/c/186418/ Unfortunately, the stable version of some oslo.* projects were used instead of the development version, and 2 regressions were missed :-/ Was that related to the --force-reinstall option in the tox.ini file? Why is that there? It would nice to automate a job running cinder, nova and neutron unit tests and tempest on the development versions (git master branch) of all oslo.* projects. We can start with something simple: run I'm not sure what scenario that tests, though. We switched to integration tests of released libraries because we don't want applications to rely on unreleased features. We already run tempest for patches to the libraries as part of the individual gate queues for each library. Why do we need to run tempest with the master branch of all of the libraries at once? tools/oslo_run_cross_tests and send the result by email every day to some people interested by the result (ex: Oslo liaisons, or just me if nobody cares). It would be nice to have a dedicated resource in the OpenStack infra for such job. We have a separate list for the stable-maint job reports. We could create one for these reports, too. I proposed to run all tests using Gerrit for each patch send to an Oslo project, but it would use too much resources of the OpenStack infra. Another idea would be to write a check job dedicated to Oslo releases and use Gerrit to prepare a release (at least to tag a version in Git). I'm working with Thierry and the infra team to design some tools for reviewing release requests: https://review.openstack.org/191193 Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] schedule instance based on CPU frequency ?
2015-06-30 16:38 GMT+08:00 Nikola Đipanov ndipa...@redhat.com: On 06/30/2015 07:42 AM, ChangBo Guo wrote: CPU frequency is an import performance parameter, currently nova drivers just report cpu_info without frequency. we stored the compute node cpu_info in database with colum compute_nodes.cpu_info, we can add the frequency easily. The usage of cpu frequency I can think is used to schedule to meet applications which need high frequency. add a frequency based filter ? if we need this , I would like to propose a spec for this . Would it be possible to give more details on the type of app that will have this _specific_ requirement. I don't think I have all the details in my head, but it seems to me that the frequency of the hypervisor CPU is just not something that carries enough information for users about how most applications will perform. I would imagine they would either want the fastest or some specialized HW for specific applications. There are two steps to leverage cpu frequency: 1. report cpu frequency and record the value, nova hypervisor-show will include the value . 2. filter compute nodes based cpu frequency. add a new scheduler filter to do that before I start to do these stuff. I would like to your input . Do we need leverage CPU frequency in Nova ? if yes, do we need a new filter or leverage existing filter to use frequency ? I don't think we do personally - but I may not understand what problem this is trying to solve. But even if we do - the most important thing IMHO would be _how_ to expose it to users (do we allow them to request a minimum frequency, or a specific one or something else). API contract is extremely important here because we want to make sure that we are exposing the right semantics for users - as we would want this to be usable to as big a group of people as possible. The use case: user want to integrate hardware management with api /os-hypervisors, they want to know more details about hardware, so cpu frequency is good to have. so I think if we can provide it to user, we don't change database schema, just change colume compute_nodes.cpu_info, is it that ok ? If it's just about having a high performance tier - can we do this with host aggregates and flavors? These are the questions we want to answer first IMHO. yes we can host aggregates to solve the schedule. N. -- 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 __ OpenStack Development Mailing 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] Why doesn't Gerrit email me?
On 30/06/15 14:33, Julien Danjou wrote: On Tue, Jun 30 2015, Neil Jerram wrote: Apologies if this is an FAQ - I tried a quick search, but that didn't find anything that looked both up to date and authoritative. I keep going back to Gerrit jobs that I've reviewed or commented on, and finding that there have been other comments since mine, but that Gerrit didn't email me about. Does anyone know why that happens? It's really important to my workflow, and to continuing review conversations effectively, that Gerrit emails new comments reliably and in good time. Could I be doing something wrong that is causing this not to happen? Maybe you need to add the projects you care about in Watched Projects at https://review.openstack.org/#/settings/projects Thanks for the suggestion. I didn't know about that. At the moment, however, I have nothing configured here - and AFAIK I never have had - and I _have_ received emails in the past for most of the Gerrit jobs that I have commented on. Presumably, therefore, there is a default email notification behaviour that doesn't require anything under Watched Projects. I wonder why that would mostly work, but sometimes (apparently) not. Regards, Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Why doesn't Gerrit email me?
On Tue, Jun 30, 2015 at 02:08:45PM +0100, Neil Jerram wrote: Apologies if this is an FAQ - I tried a quick search, but that didn't find anything that looked both up to date and authoritative. I keep going back to Gerrit jobs that I've reviewed or commented on, and finding that there have been other comments since mine, but that Gerrit didn't email me about. Does anyone know why that happens? It's really important to my workflow, and to continuing review conversations effectively, that Gerrit emails new comments reliably and in good time. Could I be doing something wrong that is causing this not to happen? This is probably a silly question, but have you enabled email notifications for all comments in your watched projects? You can create a watch item for a particular project with 'owner:me' in the 'Only If' field to prevent a deluge of comment notifications. Cheers, Louis signature.asc Description: Digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla][release] Announcing Liberty-1 release of Kolla
Ian, The most significant difference would be that Kolla uses image based deployment rather than building from source on each node at runtime allowing for a more consistent and repeatable deployment. On Tue, Jun 30, 2015 at 2:28 PM, Ian Cordasco ian.corda...@rackspace.com wrote: On 6/29/15, 23:59, Steven Dake (stdake) std...@cisco.com wrote: The Kolla community is pleased to announce the release of the Kolla Liberty 1 milestone. This release fixes 56 bugs and implements 14 blueprints! Our community developed the following notable features: * A start at source-basedcontainers So how does this now compare to the stackforge/os-ansible-deployment (soon to be openstack/openstack-ansible) project? __ OpenStack Development Mailing 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] Issue with neutron-dhcp-agent not recovering known ports cache after restart
This looks like a different issue. The problem you have identified is specific to a DHCP agent port being deleted. Shraddha's question seems to be about all ports. All of the port information is synced on startup via sync_state here: https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L147 so there shouldn't be any issues there. On Tue, Jun 30, 2015 at 7:09 PM, shihanzhang ayshihanzh...@126.com wrote: hi Shraddha Pandhe, I think your analysis is right, I also encountered the same problem， I have filed a bug[1] and commit a patch [2] for this bug. thanks, hanzhang shi [1] https://launchpad.net/bugs/1469615 [2] https://review.openstack.org/#/c/196927/ 在 2015-07-01 08:25:48，Shraddha Pandhe spandhe.openst...@gmail.com 写道： Hi folks.. I have a question about neutron dhcp agent restart scenario. It seems like, when the agent restarts, it recovers the known network IDs in cache, but we don't recover the known ports [1]. So if a port that was present before agent restarted, is deleted after agent restart, the agent wont have it in its cache. So port here [2] will be None. So the port will actually never get deleted. Same problem will happen if a port is updated. Has anyone seen these issues? Am I missing something? [1] https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L82-L87 [2] https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L349 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] - breaking changes for plugins/drivers
Hi, We have had at least two breaking changes merge this week for out-of-tree drivers/plugins. These are just the two I noticed that broke the Big Switch CI (the one I keep an eye on since I had set it up): 1. Removed test_lib that changes config files. https://review.openstack.org/#/c/196583/ 2. Removed the loopingcall common util with no deprecation cycle or announcement. https://review.openstack.org/#/c/192999/ I proposed a revert for 1 that merged, but I don't particularly want to keep fighting this. What is our current policy on this? Just change whatever we want and tell plugin maintainers this is just the way things work? -- 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][scheduler] New Scheduler Meeting Time
What Ed said. I've proposed a change to the infra tree that should percolate this time change up through the system but, starting next Mon, 4/6, we'll be talking scheduler at the new time place. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 -Original Message- From: Ed Leafe [mailto:e...@leafe.com] Sent: Tuesday, June 30, 2015 3:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [nova][scheduler] New Scheduler Meeting Time -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 So the poll results are in, and it looks like we have a winner: Mondays at 1400 UTC. It seems that the #openstack-meeting-alt channel is the only one available, so we'll use that. Don Duggar will be updating the wiki and other official resources to reflect this, but I wanted to send something out now so that you can update your calendars. See you Monday! - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJVkxEkAAoJEKMgtcocwZqLGAcP/3HQqJ8zlEjtlLL0yac6+zK/ 05F6puIXuQzpdGV1AZHXKtNqcjdm7a3m4YMgiozaLG7Svoi7dCbWbflapu5XSkDV BHGDUkOM/yLnO1pVnmWGN4c5qdv2o/UxLwlLNmFOCgtoee7J9Gh0wZecUvIM107p ddWqNiQqdn8Nl47X+/L+NdOp9TjjGzgB2cJrjiyHUc8GIq+pm7j/5gCg7Q7RCWvq 6EZzebrMOP6BrVHBMyjnrv7J+9oPMqHtsUonCmBloAQ6frZ/kse3Kxl/DGp8IHMI DxJkl3bROv8heiiRsHwN7Po75Cv3ImAj0O86dER4ACGTkoWUfQZOTXWVnkPc/xxb AeTNFX3KgkOUEJ7XHzqEeHu3VmYqZ7exj2LZCLwI7W5PfhpzD8KbC68HTne9mNla RXYCW0RDcS80p1q9xxSfmJZl88HONrbaoXb3xcGaROhEQFhjQEiNo1cvheR/X9B8 hx5I7zNMErBSnMxRdyA5Vu0mXUC9cyUdYaXCxdoNw4RC7ZAt/u3NxNaovjUMDGv0 Vum/AgozxRlrBmRzIJRE3oegtp+bVkYJ6nDg1PVUrCQ8KKQenFWEErwQeKbK++8J 81chRjsXwrl7fnM4F7nIbGbVzOUD3Bida33DOa6pkOoxHkz2vDHNGhqs5ZfyS44R zTKrXMHrU5XHHOockryS =OjA3 -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Glance] Liberty mid-cycle meetup.
Hi all, As discussed in the earlier Glance weekly meeting, the mid-cycle meetup for Glance would be at Blacksburg, VA from July 28-July30. A tentative schedule and some details have been put in the etherpad. Please fill in your details in the survey and the etherpad so as to help the site manager handle surrounding details. https://etherpad.openstack.org/p/liberty-glance-mid-cycle-meetup Thanks, Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Liberty mid-cycle meet up.
Nikhil any chance we can have remote participation? Based on the agenda folks can remote dial in. Regards, Malini From: Nikhil Komawar [mailto:nik.koma...@gmail.com] Sent: Tuesday, June 30, 2015 9:19 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Glance] Liberty mid-cycle meetup. Hi all, As discussed in the earlier Glance weekly meeting, the mid-cycle meetup for Glance would be at Blacksburg, VA from July 28-July30. A tentative schedule and some details have been put in the etherpad. Please fill in your details in the survey and the etherpad so as to help the site manager handle surrounding details. https://etherpad.openstack.org/p/liberty-glance-mid-cycle-meetup Thanks, Nikhil __ OpenStack Development Mailing 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] Why doesn't Gerrit email me?
Thanks Sean, + Andreas for your similar reply... Yes, I guess that could be it. My company's setup is Exchange, and the IT folk here assure me that any spam emails would be in my Junk folder - and the missing Gerrit emails aren't there. But, maybe that's not the 100% full story, for some reason. Perhaps I should add lots of watched projects as a way of testing my local mail server... :-) But perhaps also worth keeping an open mind about the possibility of Gerrit notification having regressed in some way. Regards, Neil On 30/06/15 15:24, Sean McGinnis wrote: I had issues with our mail server filtering them out as spam or something. It wasn't even at my client, so I couldn't do much about it. I eventually ended up using a new mail provider for my OpenStack emails. At the moment, however, I have nothing configured here - and AFAIK I never have had - and I _have_ received emails in the past for most of the Gerrit jobs that I have commented on. Presumably, therefore, there is a default email notification behaviour that doesn't require anything under Watched Projects. I wonder why that would mostly work, but sometimes (apparently) not. Regards, Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [heat] status of instance_user/admin_user in heat
Heat devs, What is the status of the instance_user config option and the corollary OS::Nova::Server::admin_user field? Our users find it very confusing when Heat creates a VM with a user called ec2-user. While I've told them to explicitly set admin_user, the documentation claims its deprecated since Icehouse. Will it be removed? Along the same lines, instance_user in the config also claims to be deprecated and slated for removal in Kilo, it is also still there in master. So what's the right behavior here? Should I tell heat users that it's safe/recommended to set admin_user or not? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Cross-project meeting today, Tue Jun 30th, 21:00 UTC
Dear PTLs, cross-project liaisons, and interested team members, We'll have a cross-project meeting today at 21:00 UTC, with the following agenda: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda * Team announcements (horizontal, vertical, diagonal) * Translation for non user facing messages (yamamoto) [1] * API WG spec review: Clarifications on state-conflicting requests [2] * Return request ID to caller (tpatil): Spec review [3] If you're from an horizontal team (Release management, QA, Infra, Docs, Security, I18n...) or a vertical team (Nova, Swift, Keystone...) and have something to communicate to the other teams, please attend and use the #info meetbot command to ensure it gets in the meeting summary. If you're interested in chairing a cross-project meeting, please talk to Thierry Carrez (ttx). For more details on this meeting, please see: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting See you there! Thanks, Anne 1. https://review.openstack.org/#/c/185300 2. https://review.openstack.org/#/c/180094 3. https://review.openstack.org/#/c/156508 -- Anne Gentle Rackspace Principal Engineer www.justwriteclick.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] status of instance_user/admin_user in heat
Looks like this change is what I need, but was the code supposed to not set it to ec2-user when instance_user is unset? I've always had it unset and it's always set it to ec2-user, certainly for Ubuntu images anyway, I've not tested others. It's a common misconception. Unset is different from the empty string. If you don't set it, it keeps using the default value, which is ec2-user. If you set it to the empty string, it keeps whatever the image is using. If you don't that you shouldn't need this change. -- Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] OpenStack CI harddisk failure - jobs are UNSTABLE
On 2015-06-30 10:59:24 +0200 (+0200), Andreas Jaeger wrote: static.openstack.org has a harddisk failure for the log volume which causes jobs to fail with UNSTABLE when uploading log files. [...] The log volume was repaired and brought back online at 14:00 UTC. Log links today from before that time may be missing, and changes should be rechecked if fresh job logs are desired for them. -- Jeremy Stanley signature.asc Description: 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] [TripleO] diskimage-builder 1.0.0
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. Cheers, Greg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- James Slagle -- __ OpenStack Development Mailing 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] Why doesn't Gerrit email me?
I'm also experiencing some difficulties with Gerrit email notifications. Around the time Kilo was released it became unreliable. Some notifications are coming after few days, some of them instantly. In particular I'm often receiving comments on a patch in invalid order. -Original Message- From: Louis Taylor [mailto:lo...@kragniz.eu] Sent: Tuesday, June 30, 2015 3:45 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Why doesn't Gerrit email me? On Tue, Jun 30, 2015 at 02:08:45PM +0100, Neil Jerram wrote: Apologies if this is an FAQ - I tried a quick search, but that didn't find anything that looked both up to date and authoritative. I keep going back to Gerrit jobs that I've reviewed or commented on, and finding that there have been other comments since mine, but that Gerrit didn't email me about. Does anyone know why that happens? It's really important to my workflow, and to continuing review conversations effectively, that Gerrit emails new comments reliably and in good time. Could I be doing something wrong that is causing this not to happen? This is probably a silly question, but have you enabled email notifications for all comments in your watched projects? You can create a watch item for a particular project with 'owner:me' in the 'Only If' field to prevent a deluge of comment notifications. Cheers, Louis __ OpenStack Development Mailing 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] Why doesn't Gerrit email me?
On 2015-06-30 14:08:45 +0100 (+0100), Neil Jerram wrote: [...] I keep going back to Gerrit jobs that I've reviewed or commented on, and finding that there have been other comments since mine, but that Gerrit didn't email me about. [...] Looking in our MTA logs for review.openstack.org, I see lots of 550 5.7.1 Message rejected due to content restrictions errors for your address and other addresses at your domain. I recommend having your mailserver administrators review their logs for additional detail. -- Jeremy Stanley signature.asc Description: 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] [Nova] Serial console protocol type setting -- protocol type='telnet'/
Hi team, After I searched around a while and looked into some of the nova source code I could not still figure out how to manage a feature my project requires. I would like to post it here for help, suggestions. Appreciate any inputs! Problem: In my project, I need VMs on openstack support serial console with protocol type='telnet' / instead the default one protocol type='raw' /. I attached the chunk of the xml as below. serial type='tcp' source mode='bind' host='10.0.0.33' service='10002'/ protocol type='raw'/ *-- protocol type='telnet'/* target port='0'/ alias name='serial0'/ /serial console type='tcp' source mode='bind' host='10.0.0.33' service='10002'/ protocol type='raw'/ *-- protocol type='telnet'/ * target type='serial' port='0'/ alias name='serial0'/ /console Thanks, Gene __ OpenStack Development Mailing 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] Why doesn't Gerrit email me?
On 2015-06-30 14:25:27 + (+), Dulko, Michal wrote: I'm also experiencing some difficulties with Gerrit email notifications. Around the time Kilo was released it became unreliable. Some notifications are coming after few days, some of them instantly. In particular I'm often receiving comments on a patch in invalid order. Yes, I spoke with someone else on IRC last week who has an address at your domain and was experiencing similar issues with our mailing lists. There are lots of 452 Too many recipients received this hour errors in our review.openstack.org MTA logs for addresses at that domain. Please follow up with your mailserver administrators to get this resolved. -- Jeremy Stanley signature.asc Description: 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] Hyper-V meeting
Too many people on vacation this week. Postponing the meeting until there is quorum. p Peter J. Pouliot CISSP Microsoft Enterprise Cloud Solutions C:\OpenStack New England Research Development Center 1 Memorial Drive Cambridge, MA 02142 P: 1.(857).4536436 E: ppoul...@microsoft.commailto:ppoul...@microsoft.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Why doesn't Gerrit email me?
I had issues with our mail server filtering them out as spam or something. It wasn't even at my client, so I couldn't do much about it. I eventually ended up using a new mail provider for my OpenStack emails. At the moment, however, I have nothing configured here - and AFAIK I never have had - and I _have_ received emails in the past for most of the Gerrit jobs that I have commented on. Presumably, therefore, there is a default email notification behaviour that doesn't require anything under Watched Projects. I wonder why that would mostly work, but sometimes (apparently) not. Regards, Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support
I have started to put together a working draft of an API here: https://docs.google.com/document/d/1nw5jVn0hjmhlhkZJAohx-gqRkkbVhMMJ79Pogd0ysEk/edit?usp=sharing I would suggest we skip this weeks meeting, and review this doc, and circle back next week? I have opened it for comment, and I will add anyone who sends on their email to the editors list. Thanks, Graham On 24/06/15 15:16, Samuel Bercovici wrote: Great! Thanks you. I have missed this one. *From:*Gandhi, Kunal [mailto:kunalhgan...@gmail.com] *Sent:* Wednesday, June 24, 2015 12:21 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support Hi Sam Yes. we discussed the use cases 2 weeks ago on irc. The IRC logs can be found here http://eavesdrop.openstack.org/meetings/gslb/2015/gslb.2015-06-09-16.00.log.html and the use case document can be found here https://docs.google.com/document/d/1016shVnPaK8l8HxMpjADiYtY2O94p4g7JxjuIA-qv7w/edit?usp=sharing Regards Kunal On Jun 24, 2015, at 12:35 AM, Samuel Bercovici samu...@radware.com mailto:samu...@radware.com wrote: Hi Kunal, Did you also include use cases per our last discussion on IRC? I prefer to start with use cases before we dive into APIs. Thanks, -Sam. -Original Message- From: Gandhi, Kunal [mailto:kunalhgan...@gmail.com] Sent: Wednesday, June 24, 2015 6:47 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support Hi All, I have a very draft for the GSLB API and would like to upload it somewhere for discussion. What is the best place to upload and collaborate the draft ? Since the API docs have a lot of JSON payloads in it, I am not sure whether Google Docs will be appropriate for that. Regards Kunal On Jun 15, 2015, at 10:03 PM, Doug Wiegley doug...@parksidesoftware.com mailto:doug...@parksidesoftware.com wrote: Hi all, We don’t have a rough draft API doc yet, so I’m suggesting that we postpone tomorrow morning’s meeting until next week. Does anyone have any other agenda items, or want the meeting tomorrow? Thanks, doug On Jun 2, 2015, at 10:52 AM, Doug Wiegley doug...@parksidesoftware.com mailto:doug...@parksidesoftware.com wrote: Hi all, The initial meeting logs can be found at http://eavesdrop.openstack.org/meetings/gslb/2015/ , and we will be having another meeting next week, same time, same channel. Thanks, doug On May 31, 2015, at 1:27 AM, Samuel Bercovici samu...@radware.com mailto:samu...@radware.com wrote: Good for me - Tuesday at 1600UTC -Original Message- From: Doug Wiegley [mailto:doug...@parksidesoftware.com] Sent: Thursday, May 28, 2015 10:37 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support On May 28, 2015, at 12:47 PM, Hayes, Graham graham.ha...@hp.com mailto:graham.ha...@hp.com wrote: On 28/05/15 19:38, Adam Harwell wrote: I haven't seen any responses from my team yet, but I know we'd be interested as well - we have done quite a bit of work on this in the past, including dealing with the Designate team on this very subject. We can be available most hours between 9am-6pm Monday-Friday CST. --Adam https://keybase.io/rm_you From: Rakesh Saha rsahaos...@gmail.com mailto:rsahaos...@gmail.com mailto:rsahaos...@gmail.com%20%0b%3cmailto:rsahaos...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org%0b%3cmailto:openstack-dev@lists.openstack.org Date: Thursday, May 28, 2015 at 12:22 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org%0b%3cmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support Hi Kunal, I would like to participate as well. Mon-Fri morning US Pacific time works for me. Thanks, Rakesh Saha On Tue, May 26, 2015 at 8:45 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com mailto:vijay.venkatacha...@citrix.com mailto:vijay.venkatacha...@citrix.com%20%0b%3cmailto:vijay.venkatacha...@citrix.com wrote: We would like to participate as well. __ __ Monday-Friday Morning US time works for me.. __ __ Thanks,
[openstack-dev] [nova] Network issue with libvirt-xen driver, iptables race
Hi all,
We have an issue with the driver libvirt-xen. When a guest is started by
Nova, nova-network is going to do some network setup and call
iptables-{save,restore}, and the Xen toolstack is going to setup the
vif of the guest, via a script, which also update the iptables.
The Xen script is simply calling those commands:
ip link set dev ${dev} down
ip link set dev ${dev} address fe:ff:ff:ff:ff:ff
ip address flush dev ${dev}
brctl addif ${bridge} ${dev}
ip link set dev ${dev} up
iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-in $dev -j
ACCEPT
iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-out $dev -j
ACCEPT
$dev been by default vif$domid.$devid.
Only the call to iptables is an issue and fail fairly often when it looses
the race against iptables-{save,restore}.
It is possible to have Nova asking to run a different script that would not
call iptables. But that script would need to be store somewhere, in the
nova repo would be best.
Any though on that?
Is `iptables` call necessary for the vif with OpenStack?
If so, can nova-network do the update? Or the script called by the Xen
toolstack could take an OpenStack lock before calling iptables?
Bug report: https://bugs.launchpad.net/nova/+bug/1461642
Thanks,
--
Anthony PERARD
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates
Whats the timeframe? I was really hoping for Liberty but its sounding like thats unlikely? M then? The app catalog really needs conditionals for the same reason. :/ Thanks, Kevin From: Angus Salkeld [asalk...@mirantis.com] Sent: Monday, June 29, 2015 6:56 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates On Tue, Jun 30, 2015 at 8:23 AM, Fox, Kevin M kevin@pnnl.govmailto:kevin@pnnl.gov wrote: Needing to fork templates to tweak things is a very common problem. Adding conditionals to Heat was discussed at the Summit. (https://etherpad.openstack.org/p/YVR-heat-liberty-template-format). I want to say, someone was going to prototype it using YAQL, but I don't remember who. I was going to do that, but I would not expect that ready in a very short time frame. It needs some investigation and agreement from others. I'd suggest making you decision based on what we have now. -Angus Would it be reasonable to keep if conditionals worked? Thanks, Kevin From: Hongbin Lu [hongbin...@huawei.commailto:hongbin...@huawei.com] Sent: Monday, June 29, 2015 3:01 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates Agree. The motivation of pulling templates out of Magnum tree is hoping these templates can be leveraged by a larger community and get more feedback. However, it is unlikely to be the case in practise, because different people has their own version of templates for addressing different use cases. It is proven to be hard to consolidate different templates even if these templates share a large amount of duplicated code (recall that we have to copy-and-paste the original template to add support for Ironic and CoreOS). So, +1 for stopping usage of heat-coe-templates. Best regards, Hongbin -Original Message- From: Tom Cammann [mailto:tom.camm...@hp.commailto:tom.camm...@hp.com] Sent: June-29-15 11:16 AM To: openstack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Magnum] Continuing with heat-coe-templates Hello team, I've been doing work in Magnum recently to align our templates with the upstream templates from larsks/heat-kubernetes[1]. I've also been porting these changes to the stackforge/heat-coe-templates[2] repo. I'm currently not convinced that maintaining a separate repo for Magnum templates (stackforge/heat-coe-templates) is beneficial for Magnum or the community. Firstly it is very difficult to draw a line on what should be allowed into the heat-coe-templates. We are currently taking out changes[3] that introduced useful autoscaling capabilities in the templates but that didn't fit the Magnum plan. If we are going to treat the heat-coe-templates in that way then this extra repo will not allow organic development of new and old container engine templates that are not tied into Magnum. Another recent change[4] in development is smart autoscaling of bays which introduces parameters that don't make a lot of sense outside of Magnum. There are also difficult interdependency problems between the templates and the Magnum project such as the parameter fields. If a required parameter is added into the template the Magnum code must be also updated in the same commit to avoid functional test failures. This can be avoided using Depends-On: #xx feature of gerrit, but it is an additional overhead and will require some CI setup. Additionally we would have to version the templates, which I assume would be necessary to allow for packaging. This brings with it is own problems. As far as I am aware there are no other people using the heat-coe-templates beyond the Magnum team, if we want independent growth of this repo it will need to be adopted by other people rather than Magnum commiters. I don't see the heat templates as a dependency of Magnum, I see them as a truly fundamental part of Magnum which is going to be very difficult to cut out and make reusable without compromising Magnum's development process. I would propose to delete/deprecate the usage of heat-coe-templates and continue with the usage of the templates in the Magnum repo. How does the team feel about that? If we do continue with the large effort required to try and pull out the templates as a dependency then we will need increase the visibility of repo and greatly increase the reviews/commits on the repo. We also have a fairly significant backlog of work to align the heat-coe-templates with the templates in heat-coe-templates. Thanks, Tom [1] https://github.com/larsks/heat-kubernetes [2] https://github.com/stackforge/heat-coe-templates [3] https://review.openstack.org/#/c/184687/ [4] https://review.openstack.org/#/c/196505/ __ OpenStack
Re: [openstack-dev] [heat] status of instance_user/admin_user in heat
Looks like this change is what I need, but was the code supposed to not set it to ec2-user when instance_user is unset? I've always had it unset and it's always set it to ec2-user, certainly for Ubuntu images anyway, I've not tested others. On Tue, Jun 30, 2015 at 8:22 AM, Thomas Herve the...@redhat.com wrote: Heat devs, What is the status of the instance_user config option and the corollary OS::Nova::Server::admin_user field? Our users find it very confusing when Heat creates a VM with a user called ec2-user. While I've told them to explicitly set admin_user, the documentation claims its deprecated since Icehouse. Will it be removed? Along the same lines, instance_user in the config also claims to be deprecated and slated for removal in Kilo, it is also still there in master. So what's the right behavior here? Should I tell heat users that it's safe/recommended to set admin_user or not? Hi, It's been deprecated for a while, and will be hidden in the next release (see https://review.openstack.org/#/c/103928/) if everything goes well. As an operator, you shoud set the instance_user configuration value to the empty string, so that your users get the default user from the image. That's the recommanded mode of operation. Cheers, -- Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] status of instance_user/admin_user in heat
Heat devs, What is the status of the instance_user config option and the corollary OS::Nova::Server::admin_user field? Our users find it very confusing when Heat creates a VM with a user called ec2-user. While I've told them to explicitly set admin_user, the documentation claims its deprecated since Icehouse. Will it be removed? Along the same lines, instance_user in the config also claims to be deprecated and slated for removal in Kilo, it is also still there in master. So what's the right behavior here? Should I tell heat users that it's safe/recommended to set admin_user or not? Hi, It's been deprecated for a while, and will be hidden in the next release (see https://review.openstack.org/#/c/103928/) if everything goes well. As an operator, you shoud set the instance_user configuration value to the empty string, so that your users get the default user from the image. That's the recommanded mode of operation. Cheers, -- Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Why doesn't Gerrit email me?
On 06/30/2015 03:08 PM, Neil Jerram wrote:
Apologies if this is an FAQ - I tried a quick search, but that didn't
find anything that looked both up to date and authoritative.
I keep going back to Gerrit jobs that I've reviewed or commented on, and
finding that there have been other comments since mine, but that Gerrit
didn't email me about.
Does anyone know why that happens? It's really important to my
workflow, and to continuing review conversations effectively, that
Gerrit emails new comments reliably and in good time. Could I be doing
something wrong that is causing this not to happen?
It works fine for me - do they end in some mail filter at your side?
Recently I discussed with somebody who found them all in his junk folder ;(
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] OpenStack CI harddisk failure - jobs are UNSTABLE
Thanks a ton fungi! On Tue, Jun 30, 2015 at 10:55 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-06-30 10:59:24 +0200 (+0200), Andreas Jaeger wrote: static.openstack.org has a harddisk failure for the log volume which causes jobs to fail with UNSTABLE when uploading log files. [...] The log volume was repaired and brought back online at 14:00 UTC. Log links today from before that time may be missing, and changes should be rechecked if fresh job logs are desired for them. -- 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 -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing 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][stable] Cinder client broken in Juno
On Mon, Jun 29, 2015 at 11:58 PM, Duncan Thomas duncan.tho...@gmail.com wrote: We already have an environment variable for version... 'auto'? On 30 Jun 2015 07:57, John Griffith john.griffi...@gmail.com wrote: On Mon, Jun 29, 2015 at 8:54 PM, Jay Bryant jsbry...@electronicjungle.net wrote: I too would prefer option 2. Would rather do the pack ports than remove the functionality. Jay On Wed, Jun 24, 2015 at 9:40 AM Gorka Eguileor gegui...@redhat.com wrote: On Tue, Jun 23, 2015 at 08:49:55AM -0700, Mike Perez wrote: There was a bug raised [1] from some large deployments that the Cinder client 1.2.0 and beyond is not working because of version discovery. Unfortunately it's not taking into account of deployments that have a proxy. A little bit unrelated, but volume pagination in Cinder client is also broken due to Version Discovery: https://bugs.launchpad.net/python-cinderclient/+bug/1453755 Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. This is all correctly setup on the deployer's side, this an issue with the server side code of Cinder. There is a patch that allows the deployer to specify a configuration option public_endpoint [2] which was introduced in a patch in Kilo [3]. The problem though is we can't expect people to already be running Kilo to take advantage of this, and it leaves deployers running stable releases of Juno in the dark with clients upgrading and using the latest. Two options: 1) Revert version discovery which was introduced in Kilo for Cinder client. 2) Grant exception on backporting [4] a patch that helps with this problem, and introduces a config option that does not change default behavior. I'm also not sure if this should be considered for Icehouse. +1 to option 2 and I wouldn't be totally against considering it for Icehouse. Cheers, Gorka. [1] - https://launchpad.net/bugs/1464160 [2] - http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html [3] - https://review.openstack.org/#/c/159374/ [4] - https://review.openstack.org/#/c/194719/ -- Mike Perez __ OpenStack Development Mailing 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 I'll echo Jeremy and Dave's statements regarding compatibility, seems really pretty lame that this can't work. If it's not possible to support both scenarios in the client in a reasonable manner without long timeout periods my vote is for a revert and new client version. Sorry, but in my opinion backports to Cinder itself don't cut it in this case. It's unfortunate we got to this point. Why can't we make this a config option in cinderclient itself? Like USE_AUTO_DISCOVERY=True|False with a default of False in the client and just deal with it or as others have asked can't we make all of this smarter? I mean it's sort of odd to have a discovery option that only works with 'new' versions of the API doesn't it? __ OpenStack Development Mailing 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 On Mon, Jun 29, 2015 at 11:58 PM, Duncan Thomas duncan.tho...@gmail.com wrote: We already have an environment variable for version... 'auto'? Which doesn't work unless you're on current Cinder version, which is what I thought the whole point of this thread was all about. I'm proposing we actually make sure
[openstack-dev] Out Of Office
I am currently travelling and am out of the office until Thursday the 9th July, I will be picking up emails periodically. __ OpenStack Development Mailing 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] Why doesn't Gerrit email me?
On 30/06/15 16:14, Jeremy Stanley wrote: On 2015-06-30 14:08:45 +0100 (+0100), Neil Jerram wrote: [...] I keep going back to Gerrit jobs that I've reviewed or commented on, and finding that there have been other comments since mine, but that Gerrit didn't email me about. [...] Looking in our MTA logs for review.openstack.org, I see lots of 550 5.7.1 Message rejected due to content restrictions errors for your address and other addresses at your domain. I recommend having your mailserver administrators review their logs for additional detail. Thanks very much, Jeremy, that's really useful information. Hopefully with this I can get the problem fixed at my end. Regards, Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Heat] Tuskar v. Heat responsibilities
On Mon, Jun 29, 2015 at 04:42:00PM -0400, Jay Dobies wrote: I had originally been thinking of it like slagle describes, from the child up to the parent as well. What I like about that approach is that it achieves a more pluggable model when you think about extensions that aren't accepted or applicable in TripleO upstream. If someone comes along and adds a new ControllerConfig to your above example, they have to edit whatever environment you're talking about that defines the constraints (I'm call it overcloud-something.yaml for now). This becomes a problem from a packaging point of view, especially when you factor in non-TripleO integrators (without revealing too much inside baseball, think partner integrations). How do I add in an extra package (RPM, DEB, whatever) that provides that ControllerConfig and have it picked up as a valid option? We don't want to be editing the overcloud-something.yaml because it's owned by another package and there's the potential for conflicts if multiple extra implementations start stepping on each other. An interface/discovery sort of mechanism, which I agree is more complex, would be easier to work with in those cases. I'm effectively replying to my own e-mail here, but I've expressed these thoughts on the spec and it'd probably be better to continue this train of thought there: https://review.openstack.org/#/c/196656/ Thanks for all the great feedback! So, based on your (and others) feedback, I've revised it to more of a discovery based model, where we add an optional new annotation to HOT: resource_type_mapping: resource_type: OS::TripleO::Controller This is analogous to the subsitution_mappings section defined in TOSCA, but renamed to make it a bit more HOT-ish: This would then be discoverable via heatclient, e.g: heat resource-find-template OS::TripleO::Controller which might return: puppet/controller.yaml docker/controller.yaml ... And heat would enforce type-mapping when validating the resource_registry. We could make heatclient support discovering via local filesystem, URL and Swift bucket (it already supports getting templates via all these). I've also taken a first-pass at the recursive validation spec discussed in my other thread: https://review.openstack.org/#/c/197199/ Thanks for the help defining this so far, any further feedback or ideas much appreciated! :) Steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [os-ansible-deployment] Feedback on Keystone Federation Spec
I've already looked at some of the work, and intend to look at all of it more closely. But I wanted to publicly thank you and the rest of the folks that made this possible (sigmavirus24, dolphm, lbragstad, ken johnston, i'm sure i'm missing others). This is a huge plus for user experience, and will make consumer the federation capabilities of Keystone much easier. Thanks, Steve Martinelli OpenStack Keystone Core Jesse Pretorius jesse.pretor...@gmail.com wrote on 2015/06/30 12:21:51 PM: From: Jesse Pretorius jesse.pretor...@gmail.com To: openstack-dev@lists.openstack.org, openstack-operat...@lists.openstack.org Date: 2015/06/30 12:22 PM Subject: [openstack-dev] [os-ansible-deployment] Feedback on Keystone Federation Spec Hi everyone, There was quite a bit of fanfare around the new federation features in OpenStack Kilo. In the os-ansible-deployment/openstack-ansible project we've been putting together a view on how to implement federation with as little complexity as possible. We've been working on some prototype code which can be seen by looking at the patches on the blueprint whiteboard [1] and have also prepared a spec for the implementation [2]. We'd like to get some feedback from the broader community - from deployers interested in using the feature and from developers/ deployers who've worked with federation. The feedback we'd like to see is both in terms of the spec and the prototype code (which is changing quite frequently as we figure out the bits and pieces). The follow-on to this work will be to specifically add the capability to make use of an ADFS IdP for a Keystone SP. This work will be linked to another blueprint [3] which is still a work in progress. I look forward to the review feedback! [1] https://blueprints.launchpad.net/openstack-ansible/+spec/ keystone-federation [2] https://review.openstack.org/194147 [3] https://blueprints.launchpad.net/openstack-ansible/+spec/ keystone-sp-adfs-idp -- 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 Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [os-ansible-deployment] Feedback on Keystone Federation Spec
Hi everyone, There was quite a bit of fanfare around the new federation features in OpenStack Kilo. In the os-ansible-deployment/openstack-ansible project we've been putting together a view on how to implement federation with as little complexity as possible. We've been working on some prototype code which can be seen by looking at the patches on the blueprint whiteboard [1] and have also prepared a spec for the implementation [2]. We'd like to get some feedback from the broader community - from deployers interested in using the feature and from developers/deployers who've worked with federation. The feedback we'd like to see is both in terms of the spec and the prototype code (which is changing quite frequently as we figure out the bits and pieces). The follow-on to this work will be to specifically add the capability to make use of an ADFS IdP for a Keystone SP. This work will be linked to another blueprint [3] which is still a work in progress. I look forward to the review feedback! [1] https://blueprints.launchpad.net/openstack-ansible/+spec/keystone-federation [2] https://review.openstack.org/194147 [3] https://blueprints.launchpad.net/openstack-ansible/+spec/keystone-sp-adfs-idp -- 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] Out Of Office
I am currently travelling and am out of the office until Thursday the 9th July, I will be picking up emails periodically. __ OpenStack Development Mailing 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 ?
On 06/30/2015 02:42 AM, ChangBo Guo wrote: CPU frequency is an import performance parameter, currently nova drivers just report cpu_info without frequency. we stored the compute node cpu_info in database with colum compute_nodes.cpu_info, we can add the frequency easily. The usage of cpu frequency I can think is used to schedule to meet applications which need high frequency. add a frequency based filter ? if we need this , I would like to propose a spec for this . There are two steps to leverage cpu frequency: 1. report cpu frequency and record the value, nova hypervisor-show will include the value . 2. filter compute nodes based cpu frequency. add a new scheduler filter to do that before I start to do these stuff. I would like to your input . Do we need leverage CPU frequency in Nova ? if yes, do we need a new filter or leverage existing filter to use frequency ? Like Dan B, I question whether CPU frequency really is a useful metric for scheduling decisions. That said, it is already possible to use CPU frequency in the MetricsWeigher scheduler weigher. The compute monitor plugin system is currently being overhauled [1], but the functionality to monitor CPU-related metrics already exists in Nova and can be enabled by doing the following in your nova-compute nova.conf: compute_monitors = ComputeDriverCPUMonitor Note that with the refactoring of the monitoring plugin interface, the above option will change due to using stevedore to load monitor extensions: compute_monitors = nova.compute.monitors.cpu.virt_driver:Monitor In your Nova scheduler nova.conf, you will need to add the following in the [metrics] section of the file: weights_setting = cpu.frequency=10.0 Again, I'm not saying that the above will result in any appreciable enhancement to the scheduler's decision-making, but it will do what you're trying to accomplish :) Best, -jay [1] https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1468012,n,z __ OpenStack Development Mailing 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][stable] Cinder client broken in Juno
Sorry, I don't think I was entirely clear with my proposal - I meant that we release a new current that will default to the old behavior, but allow the new behavior to be tested by explicitly choosing the value 'auto'. This allows people to test their config with version discovery, without breaking normal usage. On 30 Jun 2015 19:28, John Griffith john.griffi...@gmail.com wrote: On Mon, Jun 29, 2015 at 11:58 PM, Duncan Thomas duncan.tho...@gmail.com wrote: We already have an environment variable for version... 'auto'? On 30 Jun 2015 07:57, John Griffith john.griffi...@gmail.com wrote: On Mon, Jun 29, 2015 at 8:54 PM, Jay Bryant jsbry...@electronicjungle.net wrote: I too would prefer option 2. Would rather do the pack ports than remove the functionality. Jay On Wed, Jun 24, 2015 at 9:40 AM Gorka Eguileor gegui...@redhat.com wrote: On Tue, Jun 23, 2015 at 08:49:55AM -0700, Mike Perez wrote: There was a bug raised [1] from some large deployments that the Cinder client 1.2.0 and beyond is not working because of version discovery. Unfortunately it's not taking into account of deployments that have a proxy. A little bit unrelated, but volume pagination in Cinder client is also broken due to Version Discovery: https://bugs.launchpad.net/python-cinderclient/+bug/1453755 Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. This is all correctly setup on the deployer's side, this an issue with the server side code of Cinder. There is a patch that allows the deployer to specify a configuration option public_endpoint [2] which was introduced in a patch in Kilo [3]. The problem though is we can't expect people to already be running Kilo to take advantage of this, and it leaves deployers running stable releases of Juno in the dark with clients upgrading and using the latest. Two options: 1) Revert version discovery which was introduced in Kilo for Cinder client. 2) Grant exception on backporting [4] a patch that helps with this problem, and introduces a config option that does not change default behavior. I'm also not sure if this should be considered for Icehouse. +1 to option 2 and I wouldn't be totally against considering it for Icehouse. Cheers, Gorka. [1] - https://launchpad.net/bugs/1464160 [2] - http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html [3] - https://review.openstack.org/#/c/159374/ [4] - https://review.openstack.org/#/c/194719/ -- Mike Perez __ OpenStack Development Mailing 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 I'll echo Jeremy and Dave's statements regarding compatibility, seems really pretty lame that this can't work. If it's not possible to support both scenarios in the client in a reasonable manner without long timeout periods my vote is for a revert and new client version. Sorry, but in my opinion backports to Cinder itself don't cut it in this case. It's unfortunate we got to this point. Why can't we make this a config option in cinderclient itself? Like USE_AUTO_DISCOVERY=True|False with a default of False in the client and just deal with it or as others have asked can't we make all of this smarter? I mean it's sort of odd to have a discovery option that only works with 'new' versions of the API doesn't it? __ OpenStack Development Mailing 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:
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
Hmm, as it is a change that affects the user, in my opinion it is still an API change. Have we decided about the client, whether the alarming module will have a separate client or we will keep the current ceilometer-client? I guess more the latter one at least as a starting point, I just wanted to double check. Ildikó Sent from my iPad On 30 Jun 2015, at 14:18, Julien Danjou jul...@danjou.info wrote: On Tue, Jun 30 2015, Ildikó Váncsa wrote: Will this be accessible in the same way as currently or it needs changes on client side? You may just need to pass more options to the client to force another endpoint to be used when talking to the alarming part. We could make this change in the client by default though. -- Julien Danjou # Free Software hacker # http://julien.danjou.info __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla][release] Announcing Liberty-1 release of Kolla
On 6/29/15, 23:59, Steven Dake (stdake) std...@cisco.com wrote: The Kolla community is pleased to announce the release of the Kolla Liberty 1 milestone. This release fixes 56 bugs and implements 14 blueprints! Our community developed the following notable features: * A start at source-basedcontainers So how does this now compare to the stackforge/os-ansible-deployment (soon to be openstack/openstack-ansible) project? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [os-ansible-deployment] new features needing reviewers
Hello all, The os-ansible-deployment/OpenStack-Ansible project is gearing up for a couple feature drops and looking for reviews from interested people within the greater deployer/operator/dev community to ensure that we're developing the features/support people are looking for. Ceilometer: This review[0] completes the ceilometer blueprint[1] which adds support for ceilometer throughout the stack. While the change doesn't bring with it a salable mongodb deployment the solution does add ceilometer to OSAD as a first class capability and is tested using mongodb via our gate scripts. That said, if anyone knows of or has an Ansible solution for deploying, managing, and scaling mongodb we'd love to review, contribute, and pull it in as an external dependency when deploying Ceilometer with OSAD. Ceph: This review[2] adds ceph support for the various OpenStack service that can consume ceph. This is not a way to deploy a ceph infrastructure using Ansible, for that we're still recommending the upstream ceph playbooks/roles[3]. Additionally, this is not implementing ceph as a replacement to swift. These reviews are presently targeted at master which is gating on upstream liberty but we're intending to bring these changes into our kilo branch, which is tracking upstream kilo, to be released with the 11.1.0 tag and is scheduled to drop in the next few weeks[4]. We have lots of new goodness coming for 11.1.0 but these two features are largish so we'd appreciate some additional feedback/reviews. If you have some time and are interested in the OSAD project, we'd love to hear from you. -- Kevin Carter [0] https://review.openstack.org/#/c/173067/ [1] https://github.com/stackforge/os-ansible-deployment-specs/blob/master/specs/kilo/implement-ceilometer.rst [2] https://review.openstack.org/#/c/181957/ [3] https://github.com/ceph/ceph-ansible [4] https://launchpad.net/openstack-ansible/+milestone/11.1.0 __ OpenStack Development Mailing 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] schedule instance based on CPU frequency ?
CPU frequency is an import performance parameter, currently nova drivers just report cpu_info without frequency. we stored the compute node cpu_info in database with colum compute_nodes.cpu_info, we can add the frequency easily. The usage of cpu frequency I can think is used to schedule to meet applications which need high frequency. add a frequency based filter ? if we need this , I would like to propose a spec for this . There are two steps to leverage cpu frequency: 1. report cpu frequency and record the value, nova hypervisor-show will include the value . 2. filter compute nodes based cpu frequency. add a new scheduler filter to do that before I start to do these stuff. I would like to your input . Do we need leverage CPU frequency in Nova ? if yes, do we need a new filter or leverage existing filter to use frequency ? -- 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] [cinder][stable] Cinder client broken in Juno
We already have an environment variable for version... 'auto'? On 30 Jun 2015 07:57, John Griffith john.griffi...@gmail.com wrote: On Mon, Jun 29, 2015 at 8:54 PM, Jay Bryant jsbry...@electronicjungle.net wrote: I too would prefer option 2. Would rather do the pack ports than remove the functionality. Jay On Wed, Jun 24, 2015 at 9:40 AM Gorka Eguileor gegui...@redhat.com wrote: On Tue, Jun 23, 2015 at 08:49:55AM -0700, Mike Perez wrote: There was a bug raised [1] from some large deployments that the Cinder client 1.2.0 and beyond is not working because of version discovery. Unfortunately it's not taking into account of deployments that have a proxy. A little bit unrelated, but volume pagination in Cinder client is also broken due to Version Discovery: https://bugs.launchpad.net/python-cinderclient/+bug/1453755 Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. This is all correctly setup on the deployer's side, this an issue with the server side code of Cinder. There is a patch that allows the deployer to specify a configuration option public_endpoint [2] which was introduced in a patch in Kilo [3]. The problem though is we can't expect people to already be running Kilo to take advantage of this, and it leaves deployers running stable releases of Juno in the dark with clients upgrading and using the latest. Two options: 1) Revert version discovery which was introduced in Kilo for Cinder client. 2) Grant exception on backporting [4] a patch that helps with this problem, and introduces a config option that does not change default behavior. I'm also not sure if this should be considered for Icehouse. +1 to option 2 and I wouldn't be totally against considering it for Icehouse. Cheers, Gorka. [1] - https://launchpad.net/bugs/1464160 [2] - http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html [3] - https://review.openstack.org/#/c/159374/ [4] - https://review.openstack.org/#/c/194719/ -- Mike Perez __ OpenStack Development Mailing 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 I'll echo Jeremy and Dave's statements regarding compatibility, seems really pretty lame that this can't work. If it's not possible to support both scenarios in the client in a reasonable manner without long timeout periods my vote is for a revert and new client version. Sorry, but in my opinion backports to Cinder itself don't cut it in this case. It's unfortunate we got to this point. Why can't we make this a config option in cinderclient itself? Like USE_AUTO_DISCOVERY=True|False with a default of False in the client and just deal with it or as others have asked can't we make all of this smarter? I mean it's sort of odd to have a discovery option that only works with 'new' versions of the API doesn't it? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Fuel-Library] Nominate Aleksandr Didenko for fuel-library core
+1. Alex's doing a great job! On Mon, Jun 29, 2015 at 5:40 PM, Sergey Vasilenko svasile...@mirantis.com wrote: +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] [Mistral][Murano] What's the latest/greatest on YAQL?
Hi Dmitri, We share your concerns and migration to the new YAQL is our priority too. Regarding estimates, I would say month in a worst case. On Tue, Jun 30, 2015 at 8:09 AM, Dmitri Zimine dzim...@stackstorm.com wrote: Thanks Stan, This release is few more months. How soon? Are you planning to support 0.2 in the meantime? We are really pressed on this transition to 1.0. For instance. Number 1 user error while dealing with YAQL is using == instead of =. We had this discussion and you and Alex and you suggested it’s easy to redefine. But… … The short is we need to move to 1.0 to do it. Because from what I figured so far, in 0.2 I can’t naively extend the an operator, as it won’t parse. I did make it work on 0.2 but this required a hack in the YAQL library itself, need to add ‘==‘ to both lexer.py and parser.py. At least what I figured. I see the tokens are already generalized in 1.0. It doesn’t seem to worth backporting it to 0.2, but if this is a way, let us know. Mistral is betting on YAQL, please help. DZ. On Jun 26, 2015, at 2:20 AM, Stan Lagun sla...@mirantis.com wrote: The plan is to move to yaql 1.0 this release. Please do not merge yaql 1.0 into Mistral yet. Migration is going to happen really soon Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis sla...@mirantis.com On Fri, Jun 26, 2015 at 8:17 AM, Renat Akhmerov rakhme...@mirantis.com wrote: Yes, it’s a pretty important thing that we’d like to clarify as soon as possible. Any input from Murano team? Renat Akhmerov @ Mirantis Inc. On 26 Jun 2015, at 06:01, Dmitri Zimine dzim...@stackstorm.com wrote: Folks, it’s been some time,what’s the news: * Is Murano moving YAQL 1.0 in this cycle? * What’s your recommendation for this cycle - stay on 0.2.6 or move on? * Any progress on documentation? Thanks, DZ __ 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://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 -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com +7 (495) 640-4904, 0261 +7 (903) 156-0836 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Mistral] Proposing to remove mistral.utils.wf_trace module
Hi, guys,
TL;DR
After implementation of the blueprint[1], now we use olso.log module in
Mistral, just as the same with other projects. However, we still use
mistral.utils.wf_trace module to make some info insertion into log
messages(we want to log execution id or task id during workflow running),
which is a little bit ugly, considering it could be replaced using oslo.log
features itself.
So, I submit the proposal here to bring more people to have an open
discussion, to make sure wo make consensus about that before I start to do
code work.
Below is the long version in rst format:
Problem Description
===
Currently, we have mistral.utils.wf_trace module to get execution-id and
task-id during mistral workflow execution, then insert them to the log, so
there are plenty of wf_trace.info invokings all around our code repo, which
is much more likely a hacking to log module funtionality, and it's not
consistent with most of the log behavior in code writing.
Proposed Change
===
Instead of adding an extra wf_trace module, we make use of the capability
provided by oslo.log. Take an example, we have code as below::
wf_ex = task_ex.workflow_execution
wf_trace.info(task_ex, Task '%s' [%s - %s] % (task_ex.name,
task_ex.state, state))
then, you will see from the log with content below:
``2015-06-26 04:09:50.326 19492 mistral.engine.default_engine INFO Task
'my_task' [WAITING - RUNNING]
(execution_id=c79b656f-f57f-4761-a270-138ee2417e54
task_id=a8935974-5468-de89-b785-138ee241qefd)``
the execution_id and task_i
d are automatically inserted in wf_trace module. With oslo.log, we could
change the log behavior::
wf_ex = task_ex.workflow_execution
LOG.info(Task '%s' [%s - %s] % (task_ex.name, task_ex.state, state),
resource={'type': 'workflow', 'id': wf_ex.id})
and don't forget config *logging_default_format_string* value in
*mistral.conf* to:
``%(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [-]
%(resource)s%(message)s``
so, the log content would be like this:
``2015-06-26 04:09:50.326 19492 mistral.engine.default_engine INFO
[workflow-c79b656f-f57f-4761-a270-138ee2417e54] Task 'my_task' [WAITING -
RUNNING]``
As you could noticed, the task_id is lost, yes, actually, for the time
being, oslo.log don't provide the capability such as recording various
resources at the same time in one line, which I have send an email to
openstack-dev mailing list to ask what oslo team suggest for this issue.
However, IMO, we have enough information for the operators to debug, we
have execution-id, task name, etc, and most importnantly it's a more
general way for logging.
But, if you really don't tolerate this change, we have workaround here
before the oslo.log has a final solution(maybe that will never happen). We
change the code as below::
wf_ex = task_ex.workflow_execution
LOG.info(Task '%s'(%s) [%s - %s] % (task_ex.name, task_ex.id,
task_ex.state, state), resource={'type': 'workflow', 'id': wf_ex.id})
so, the log content would be like this:
``2015-06-26 04:09:50.326 19492 mistral.engine.default_engine INFO
[workflow-c79b656f-f57f-4761-a270-138ee2417e54] Task
'my_task'(a8935974-5468-de89-b785-138ee241qefd) [WAITING - RUNNING]``
Finally, we get rid of the redundant wf_trace module from Mistral, which is
really important for an engineer with OCD :-)
REST API Impact
---
No, it's just an improvement internally
Security Impact
---
No
Other End User Impact
-
No
Performance Impact
--
Absolutely no.
Other Deployer Impact
-
No
Developer Impact
Yes, it will change how the developers want to log something related to
executions or tasks.
Alternatives
Anyway, we could keep the wf_trace module as it is, but it's a very ugly
way.
References
==
https://blueprints.launchpad.net/oslo.log/+spec/app-agnostic-logging-parameters
[1]: https://blueprints.launchpad.net/mistral/+spec/mistral-log-enhancement
--
Regards!
---
Lingxian Kong
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Fuel-Library] Nominate Aleksandr Didenko for fuel-library core
+1 2015-06-30 10:38 GMT+02:00 Evgeniy L e...@mirantis.com: +1 On Tue, Jun 30, 2015 at 9:34 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote: +1. Alex's doing a great job! On Mon, Jun 29, 2015 at 5:40 PM, Sergey Vasilenko svasile...@mirantis.com wrote: +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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][ceph] puppet-ceph CI status
I merged the https://review.openstack.org/#/c/197302/ as we had agreed that once we had enough +1's on the EL7 review we would merge it. The Puppet4 spec tests had already been approved. -- David Moreau Simard Cloud Engineering | Operations On 2015-06-30 07:06 PM, Andrew Woodward wrote: On Tue, Jun 30, 2015 at 6:28 AM Emilien Macchi emil...@redhat.commailto:emil...@redhat.com wrote: On 06/29/2015 11:16 PM, Matt Fischer wrote: Ah, I don't have +2 on that repo, but the lgtm so your original plan is fine. On Mon, Jun 29, 2015 at 5:59 PM, Matt Fischer mailto:m...@mattfischer.comm...@mattfischer.commailto:m...@mattfischer.com mailto:m...@mattfischer.commailto:m...@mattfischer.com wrote: I can take a look at these tonight. Maybe also Clayton can review them? Neither of us were involved in the patches to my knowledge. On Jun 29, 2015 5:09 PM, Andrew Woodward mailto:xar...@gmail.comxar...@gmail.commailto:xar...@gmail.com mailto:xar...@gmail.commailto:xar...@gmail.com wrote: Hi Recent changes in the puppet modules infra left stackforge/puppet-ceph CI broken. We've resolved the issues in [1][2] However we are short on non-involved core-reviewers. You'll have to sqash the commits because our CI is voting for puppet4 beaker. Thanks David squished it up into [3]. The same message applies I'm going to use lazy census here and if we don't have any negative feed back we should just merge it so we get CI back to passing [3] https://review.openstack.org/#/c/197302/ If this module does not fit for you, you can still patch project-config, otherwise you'll need to fix everything in one single commit. I propose that we leave the patchs open through Wednesday and use lazy consensus and merge it if we don't receive any negative feedback. [1] https://review.openstack.org/#/c/179645/ [2] https://review.openstack.org/#/c/195959/ -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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://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 -- Emilien Macchi __ 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][scheduler] New Scheduler Meeting Time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 So the poll results are in, and it looks like we have a winner: Mondays at 1400 UTC. It seems that the #openstack-meeting-alt channel is the only one available, so we'll use that. Don Duggar will be updating the wiki and other official resources to reflect this, but I wanted to send something out now so that you can update your calendars. See you Monday! - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJVkxEkAAoJEKMgtcocwZqLGAcP/3HQqJ8zlEjtlLL0yac6+zK/ 05F6puIXuQzpdGV1AZHXKtNqcjdm7a3m4YMgiozaLG7Svoi7dCbWbflapu5XSkDV BHGDUkOM/yLnO1pVnmWGN4c5qdv2o/UxLwlLNmFOCgtoee7J9Gh0wZecUvIM107p ddWqNiQqdn8Nl47X+/L+NdOp9TjjGzgB2cJrjiyHUc8GIq+pm7j/5gCg7Q7RCWvq 6EZzebrMOP6BrVHBMyjnrv7J+9oPMqHtsUonCmBloAQ6frZ/kse3Kxl/DGp8IHMI DxJkl3bROv8heiiRsHwN7Po75Cv3ImAj0O86dER4ACGTkoWUfQZOTXWVnkPc/xxb AeTNFX3KgkOUEJ7XHzqEeHu3VmYqZ7exj2LZCLwI7W5PfhpzD8KbC68HTne9mNla RXYCW0RDcS80p1q9xxSfmJZl88HONrbaoXb3xcGaROhEQFhjQEiNo1cvheR/X9B8 hx5I7zNMErBSnMxRdyA5Vu0mXUC9cyUdYaXCxdoNw4RC7ZAt/u3NxNaovjUMDGv0 Vum/AgozxRlrBmRzIJRE3oegtp+bVkYJ6nDg1PVUrCQ8KKQenFWEErwQeKbK++8J 81chRjsXwrl7fnM4F7nIbGbVzOUD3Bida33DOa6pkOoxHkz2vDHNGhqs5ZfyS44R zTKrXMHrU5XHHOockryS =OjA3 -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla][release] Announcing Liberty-1 release of Kolla
Ian, a while ago it was discussed on operator's mailing list between Kevin, Steve co http://lists.openstack.org/pipermail/openstack-operators/2015-June/007267.html On Tue, Jun 30, 2015 at 8:28 PM, Ian Cordasco ian.corda...@rackspace.com wrote: On 6/29/15, 23:59, Steven Dake (stdake) std...@cisco.com wrote: The Kolla community is pleased to announce the release of the Kolla Liberty 1 milestone. This release fixes 56 bugs and implements 14 blueprints! Our community developed the following notable features: * A start at source-basedcontainers So how does this now compare to the stackforge/os-ansible-deployment (soon to be openstack/openstack-ansible) project? __ OpenStack Development Mailing 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] [Mistral][Murano] What's the latest/greatest on YAQL?
On 06/30/2015 07:09 AM, Dmitri Zimine wrote: Thanks Stan, This release is few more months. How soon? Are you planning to support 0.2 in the meantime? We are really pressed on this transition to 1.0. For instance. Number 1 user error while dealing with YAQL is using == instead of =. We had this discussion and you and Alex and you suggested it’s easy to redefine. But… … The short is we need to move to 1.0 to do it. Because from what I figured so far, in 0.2 I can’t naively extend the an operator, as it won’t parse. I did make it work on 0.2 but this required a hack in the YAQL library itself, need to add ‘==‘ to both lexer.py and parser.py. At least what I figured. I see the tokens are already generalized in 1.0. It doesn’t seem to worth backporting it to 0.2, but if this is a way, let us know. Mistral is betting on YAQL, please help. DZ. FYI, I'm also looking forward switching to Yaql 1.0 on the packaging level, because 0.2.6 has lost support for Py3 (I added some Py3 patches in Debian for 0.2.4, but 0.2.6 completely broke that...). Cheers, Thomas Goirand (zigo) __ OpenStack Development Mailing 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][cinder][qa] encrypted volumes tests don't actually test encrypted volumes for most backends
On 12:24 Jun 26, Matt Riedemann wrote: snip So the question is, is everyone OK with this and ready to make that change? Thanks for all your work on this Matt. I'm fine with this. I say bite the bullet and we'll see the CI's surface that aren't skipping or failing this test. I will communicate with CI maintainers on the CI list about failures as I've been doing, and reference this thread and the meeting discussion. -- Mike Perez __ OpenStack Development Mailing 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 Tue, Jun 30, 2015 at 7:04 AM, Emmanuel Cazenave 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). Is my use case of installing older releases with devstack/master not supported ? No. Even on master you may have issues trying to run a early cycle project with a late-cycle DevStack. DevStack evolves to meet the needs of the projects as they develop. That Tempest fix is pretty straightforward, with only the one code block move not being a skip this if project is not enabled check. With Icehouse EOL, there will be no additional updates so maintaining that backport in a local private branch should not be a big deal. You will need that anyway to keep using icehouse after we remove that branch from the DevStack repo. dt -- Dean Troyer dtro...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet][ceph] puppet-ceph CI status
On Tue, Jun 30, 2015 at 6:28 AM Emilien Macchi emil...@redhat.com wrote: On 06/29/2015 11:16 PM, Matt Fischer wrote: Ah, I don't have +2 on that repo, but the lgtm so your original plan is fine. On Mon, Jun 29, 2015 at 5:59 PM, Matt Fischer m...@mattfischer.com mailto:m...@mattfischer.com wrote: I can take a look at these tonight. Maybe also Clayton can review them? Neither of us were involved in the patches to my knowledge. On Jun 29, 2015 5:09 PM, Andrew Woodward xar...@gmail.com mailto:xar...@gmail.com wrote: Hi Recent changes in the puppet modules infra left stackforge/puppet-ceph CI broken. We've resolved the issues in [1][2] However we are short on non-involved core-reviewers. You'll have to sqash the commits because our CI is voting for puppet4 beaker. Thanks David squished it up into [3]. The same message applies I'm going to use lazy census here and if we don't have any negative feed back we should just merge it so we get CI back to passing [3] https://review.openstack.org/#/c/197302/ If this module does not fit for you, you can still patch project-config, otherwise you'll need to fix everything in one single commit. I propose that we leave the patchs open through Wednesday and use lazy consensus and merge it if we don't receive any negative feedback. [1] https://review.openstack.org/#/c/179645/ [2] https://review.openstack.org/#/c/195959/ -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Friday 1900UTC etherpad.openstack.org downtime for DB maintenance
Hello, The Infra team will be taking etherpad.openstack.org offline this Friday (July 3rd) at 1900UTC to upgrade the database instance that backs this service. This upgrade will allow us to convert the utf8 character set in the db to one supporting 4 byte characters fixing a major bug discovered during the last summit. Expect total downtime to be about half an hour. Thank you for your patience and as always let us know if you have questions/concerns. Clark __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
