Re: [openstack-dev] [Fuel] Rabbitmq 3.4.0 upgrade for the 6.1 release, is it worth it?
-1 for upgrading it in 6.1. Known devil is better than unknown angel :) In 7.0 we can try 3.5.0 with updated Erlang. ~thanks -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Wed, Apr 29, 2015 at 12:20 PM, Davanum Srinivas dsrini...@mirantis.com wrote: Bogdan, Pacemaker, corosync etc, we picked vivid packages right? So don't we test what's in vivid for this too? Apparently it's 3.4.3-2 per [0]. I agree, we should not do this in 6.1, However, we should start testing this ASAP. Another data point, Alexander Nevenchannyy pointed out to me that 3.5.0 came with an updated Erlang that has the following fix: OTP-11497 To prevent a race condition if there is a short communication problem when node-down and node-up events are received. They are now stored and later checked if the node came up just before mnesia flagged the node as down. (Thanks to Jonas Falkevik ) which seems interesting as well. thanks, dims [0] https://launchpad.net/ubuntu/vivid/+package/rabbitmq-server [1] http://www.erlang.org/download/otp_src_17.0.readme On Wed, Apr 29, 2015 at 4:04 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote: Hello. There are several concerns why we have to upgrade RabbitMQ to 3.4.0 [0]: 1) At least two bugfixes related to the current high-load issue with MQ [1]: - 26404 prevent queue synchronisation from hanging if there is a very short partition just as it starts (since 3.1.0) - 26368 prevent autoheal from hanging when loser shuts down before the winner learns it is the winner (since 3.1.0) 2) We should as well check how the new 'pause-if-all-down' option works for split brain recovery. 3) We should address the 'force_boot' recommendations from this mail thread [2] to speed up the MQ cluster assemble time. The question is - is it worth it to do this in the 6.1 release scope? I vote to postpone this for the 7.0 dev cycle as the impact of such changes might be unpredictable. [0] https://www.rabbitmq.com/release-notes/README-3.4.0.txt [1] https://bugs.launchpad.net/fuel/+bug/1447619 [2] http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg51625.html -- Best regards, Bogdan Dobrelya, Skype #bogdando_at_yahoo.com Irc #bogdando __ OpenStack Development Mailing List (not for 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] Rabbitmq 3.4.0 upgrade for the 6.1 release, is it worth it?
I’m -1 for it. Considering how much time we needed to troubleshoot the problems already, I don’t think we have time to properly test the upgrade. On 29 Apr 2015, at 12:37, Sergii Golovatiuk sgolovat...@mirantis.com wrote: -1 for upgrading it in 6.1. Known devil is better than unknown angel :) In 7.0 we can try 3.5.0 with updated Erlang. ~thanks -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Wed, Apr 29, 2015 at 12:20 PM, Davanum Srinivas dsrini...@mirantis.com wrote: Bogdan, Pacemaker, corosync etc, we picked vivid packages right? So don't we test what's in vivid for this too? Apparently it's 3.4.3-2 per [0]. I agree, we should not do this in 6.1, However, we should start testing this ASAP. Another data point, Alexander Nevenchannyy pointed out to me that 3.5.0 came with an updated Erlang that has the following fix: OTP-11497 To prevent a race condition if there is a short communication problem when node-down and node-up events are received. They are now stored and later checked if the node came up just before mnesia flagged the node as down. (Thanks to Jonas Falkevik ) which seems interesting as well. thanks, dims [0] https://launchpad.net/ubuntu/vivid/+package/rabbitmq-server [1] http://www.erlang.org/download/otp_src_17.0.readme On Wed, Apr 29, 2015 at 4:04 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote: Hello. There are several concerns why we have to upgrade RabbitMQ to 3.4.0 [0]: 1) At least two bugfixes related to the current high-load issue with MQ [1]: - 26404 prevent queue synchronisation from hanging if there is a very short partition just as it starts (since 3.1.0) - 26368 prevent autoheal from hanging when loser shuts down before the winner learns it is the winner (since 3.1.0) 2) We should as well check how the new 'pause-if-all-down' option works for split brain recovery. 3) We should address the 'force_boot' recommendations from this mail thread [2] to speed up the MQ cluster assemble time. The question is - is it worth it to do this in the 6.1 release scope? I vote to postpone this for the 7.0 dev cycle as the impact of such changes might be unpredictable. [0] https://www.rabbitmq.com/release-notes/README-3.4.0.txt [1] https://bugs.launchpad.net/fuel/+bug/1447619 [2] http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg51625.html -- Best regards, Bogdan Dobrelya, Skype #bogdando_at_yahoo.com Irc #bogdando -- Tomasz 'Zen' Napierala Product Engineering - Poland __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Infiniband support in Fuel
Hi, Sylwester, Fuel-plugin-mellanox is in development stage now, so no one can use it. I think, a longer MAC field may be helpful for other plugin developers in future. On Tue, Apr 28, 2015 at 12:50 AM, Sylwester Brzeczkowski sbrzeczkow...@mirantis.com wrote: We have a bug in fuel [1] which concerns infiniband support. It's mostly about expanding the size of mac field in db from 17 to 59. But I've email Aviram Bar-Haim who was working on for infiniband support [2] for fuel-plugin-mellanox [3] and he said that they use eIPoIB mac (mapping between ETH to IB) instead of IB Guid so it fits to our current mac field size. Does anyone have ever used fuel-plugin-mellanox with IB? I'm trying to find out if the bug is still valid? [1] https://bugs.launchpad.net/fuel/+bug/1398882 [2] https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/db/sqlalchemy/models/node.py#L103 [3] https://github.com/stackforge/fuel-plugin-mellanox Regards -- *Sylwester Brzeczkowski* Junior Python Software Engineer Product Development-Core : Product Engineering __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andrey Danin ada...@mirantis.com skype: gcon.monolake __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Core Reviewer Update
Great news!!! Welcome. On Wed, Apr 29, 2015 at 11:54 AM, Matthias Runge mru...@redhat.com wrote: On 29/04/15 00:57, David Lyle wrote: Thank you all for your contributions and welcome to the team! David Yes! Thanks a lot. You'll all make a great addition to the team. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards, Tihomir Trifonov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Core Reviewer Update
On 04/29/2015 12:57 AM, David Lyle wrote: I am pleased to announce the addition of Doug Fish, Rob Cresswell and Travis Tripp to the Horizon Core Reviewer team. Doug Fish has been an active reviewer and participant in Horizon for a few releases now. He represents a strong customer focus and has provided high quality reviews. Rob Cresswell has been providing a high number of quality reviews, an active contributor and an active participant in the community. Travis Tripp has been contributing to Horizon for the past couple of releases, an active participant in the community, a critical angularJS reviewer, and played a significant role in driving the angular based launch instance work in Kilo. Thank you all for your contributions and welcome to the team! Welcome! -- Radomir Dopieralski __ OpenStack Development Mailing List (not for 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] [Nova] [Cinder] [tc] Should Openstack project maintained by core team keep only API/DB in the future?
On 28 April 2015 at 21:59, Kevin Benton blak...@gmail.com wrote: The concern is that having broken drivers out there that claim to work with an OpenStack project end up making the project look bad. It's similar to a first time Linux user experiencing frequent kernel panics because they are using hardware with terrible drivers. They aren't going to recognize the distinction and will just assume the project is bad. It's also worth noting that the upstream kernel recommends getting your driver into their code base, precisely because it receives suitable care and critique there. The linux kernel accepts but does not encourage out-of-tree drivers (once the driver is of a suitable quality) and there are periodic pushes by certain upstream developers to pull new drivers into the kernel proper. I would love to see OpenStack upstream acting more like a resource to support users and developers Who do you think we are supporting? Users and developers are our *only* target audience... I'm quite confused what you're trying to achieve... and to suggest that we want anything other than the best product for end users and an healthy productive environment for developers is quite disingenuous. We have tough third party CI requirements in Cinder precisely because we found not having them lead to broken drivers, unmaintained code and a terrible end user experience, together with a dev environment where we couldn't make certain necessary design overhauls because we had no idea what that broke. __ OpenStack Development Mailing List (not for 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] Rabbitmq 3.4.0 upgrade for the 6.1 release, is it worth it?
Alexei, actually we do not insist this should b done for the MOS 6.1. That was the question to the audience if someone is having other idea. All these discussions have roots in the bug https://bugs.launchpad.net/fuel/+bug/1447619 - we have found the issue with RabbitMQ cluster behaviour under the networking load and Bogdan, Alexei Khivin and Alex Nevenchannyy found that it possibly might be fixed upgrading the RabbitMQ (trying it now). And actually this RabbitMQ release contains lots of crucial bug fixes even without mentioned by Bogdan. For 6.1 the found workaround might be used, section in the docs written, etc. The question to the company is if that will be enough and what are we going to do with it in future. Cheers, Dina On Wed, Apr 29, 2015 at 11:24 AM, Alexei Sheplyakov asheplya...@mirantis.com wrote: Hi, Given that - MOS 6.1 should be released in a few weeks - rabbitmq is kind of a heart of OpenStack upgrading rabbitmq in MOS 6.1 seems to be an extremely bad idea. There will be always some bugs (both known and unknown), but we can't keep updating various components forever and should stop at some moment (which is presumably called `soft code freeze'). Best regards, Alexei On Wed, Apr 29, 2015 at 11:04 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote: Hello. There are several concerns why we have to upgrade RabbitMQ to 3.4.0 [0]: 1) At least two bugfixes related to the current high-load issue with MQ [1]: - 26404 prevent queue synchronisation from hanging if there is a very short partition just as it starts (since 3.1.0) - 26368 prevent autoheal from hanging when loser shuts down before the winner learns it is the winner (since 3.1.0) 2) We should as well check how the new 'pause-if-all-down' option works for split brain recovery. 3) We should address the 'force_boot' recommendations from this mail thread [2] to speed up the MQ cluster assemble time. The question is - is it worth it to do this in the 6.1 release scope? I vote to postpone this for the 7.0 dev cycle as the impact of such changes might be unpredictable. [0] https://www.rabbitmq.com/release-notes/README-3.4.0.txt [1] https://bugs.launchpad.net/fuel/+bug/1447619 [2] http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg51625.html -- Best regards, Bogdan Dobrelya, Skype #bogdando_at_yahoo.com Irc #bogdando -- Best regards, Dina Belova Software Engineer Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Speed Up RabbitMQ Recovering
Hi! Thank you very much Vladimir and Bogdan! Thanks for the fast respond and rich information. I backported MySQL and RabbitMQ ocf patches from stable/6.0 and tested again. A full reassemble takes about 5mins, this improves a lot. Adding the force_load trick I mentioned in the previous email, it takes about 4mins. I get that there is not really a RabbitMQ master instance because queue masters spreads to all the RabbitMQ instances. The pacemaker master is an abstract one. However there is still an mnesia node from which other mnesia nodes sync table schema. The exception timeout_waiting_for_tables in log is actually reported by mnesia. By default, it places a mark on the last alive mnesia node, and other nodes have to sync table from it (http://www.erlang.org/doc/apps/mnesia/Mnesia_chap7.html#id78477). RabbitMQ clustering inherits the behavior, and the last RabbitMQ instance shutdown must be the first instance to start. Otherwise it produces timeout_waiting_for_tables (http://www.rabbitmq.com/clustering.html#transcript search for the last node to go down). The 1 minute difference is because without force_load, the abstract master determined by pacemaker during a promote action may not be the last RabbitMQ instance shut down in the last start action. So there is chance for rabbitmqctl start_app to wait 30s and trigger a RabbitMQ exception timeout_waiting_for_tables. We may able to see table timeout and mnesa resetting for once during a reassemble process on some of the RabbitMQ instances, but it only introduces 30s of wait, which is acceptable for me. I also inspect the RabbitMQ resource agent code in latest master branch. There are timeout wrapper and other improvements which are great. It does not change the master promotion process much, so it may still run into the problems I described. Please see the inline reply below. on 2015/04/28/ 21:15, Bogdan Dobrelya wrote: Hello, Hello, Zhou I using Fuel 6.0.1 and find that RabbitMQ recover time is long after power failure. I have a running HA environment, then I reset power of all the machines at the same time. I observe that after reboot it usually takes 10 minutes for RabittMQ cluster to appear running master-slave mode in pacemaker. If I power off all the 3 controllers and only start 2 of them, the downtime sometimes can be as long as 20 minutes. Yes, this is a known issue [0]. Note, there were many bugfixes, like [1],[2],[3], merged for MQ OCF script, so you may want to try to backport them as well by the following guide [4] [0] https://bugs.launchpad.net/fuel/+bug/1432603 [1] https://review.openstack.org/#/c/175460/ [2] https://review.openstack.org/#/c/175457/ [3] https://review.openstack.org/#/c/175371/ [4] https://review.openstack.org/#/c/170476/ I have a little investigation and find out there are some possible causes. 1. MySQL Recovery Takes Too Long [1] and Blocking RabbitMQ Clustering in Pacemaker The pacemaker resource p_mysql start timeout is set to 475s. Sometimes MySQL-wss fails to start after power failure, and pacemaker would wait 475s before retry starting it. The problem is that pacemaker divides resource state transitions into batches. Since RabbitMQ is master-slave resource, I assume that starting all the slaves and promoting master are put into two different batches. If unfortunately starting all RabbitMQ slaves are put in the same batch as MySQL starting, even if RabbitMQ slaves and all other resources are ready, pacemaker will not continue but just wait for MySQL timeout. Could you please elaborate the what is the same/different batches for MQ and DB? Note, there is a MQ clustering logic flow charts available here [5] and we're planning to release a dedicated technical bulletin for this. [5] http://goo.gl/PPNrw7 Batch is a pacemaker concept I found when I was reading its documentation and code. There is a batch-limit: 30 in the output of pcs property list --all. The pacemaker official documentation explanation is that it's The number of jobs that the TE is allowed to execute in parallel. From my understanding, pacemaker maintains cluster states, and when we start/stop/promote/demote a resource, it triggers a state transition. Pacemaker puts as many as possible transition jobs into a batch, and process them in parallel. The problem is that pacemaker can only promote a resource after it detects the resource is started. During a full reassemble, in the first transition batch, pacemaker starts all the resources including MySQL and RabbitMQ. Pacemaker issues resource agent start invocation in parallel and reaps the results. For a multi-state resource agent like RabbitMQ, pacemaker needs the start result reported in the first batch, then transition engine and policy engine decide if it has to retry starting or promote, and put this new transition job into a new batch. I see improvements to put individual commands inside a timeout wrapper in RabbitMQ resource agent, and a bug created yesterday
Re: [openstack-dev] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFSSA iSCSI Driver
The CI is now looking healthy, thanks. On 28 April 2015 at 21:59, Diem Tran diem.t...@oracle.com wrote: Dear Cinder team, A patchset has been uploaded to request re-integration of Oracle ZFSSA iSCSI Cinder driver to 2 branches: master and stable/kilo: https://review.openstack.org/#/c/178319 Here are some success reports of the Oracle ZFSSA iSCSI CI: https://review.openstack.org/#/c/175809/ https://review.openstack.org/#/c/176802/ https://review.openstack.org/#/c/176930/ https://review.openstack.org/#/c/174291/ https://review.openstack.org/#/c/175077/ https://review.openstack.org/#/c/176543/ The complete reports list can be found here: https://review.openstack.org/#/q/reviewer:%22Oracle+ZFSSA+CI%22,n,z Please let me know if you have any question. Thanks, Diem. On 04/21/2015 01:38 PM, Diem Tran wrote: On 04/21/2015 01:01 PM, Mike Perez wrote: On 09:57 Apr 21, Mike Perez wrote: On 15:47 Apr 20, Diem Tran wrote: Hi Mike, Oracle ZFSSA iSCSI CI is now reporting test results. It is configured to run against the ZFSSA iSCSI driver. You can see the results here: https://review.openstack.org/#/q/reviewer:%22Oracle+ZFSSA+CI%22,n,z Below are some patchsets that the CI reports: https://review.openstack.org/#/c/168424/ https://review.openstack.org/#/c/168419/ https://review.openstack.org/#/c/175247/ https://review.openstack.org/#/c/175077/ https://review.openstack.org/#/c/163706/ I would like to kindly request you and the core team to get the Oracle ZFSSA iSCSI driver re-integrated back to the Cinder code base. If there is anything else you need from the CI and the driver, please do let me know. This was done on 4/8: https://review.openstack.org/#/c/170770/ My mistake this was only the NFS driver. The window to have drivers readded in Kilo has long past. Please see: http://lists.openstack.org/pipermail/openstack-dev/2015-March/059990.html This will have to be readded in Liberty only at this point. Thank you for your reply. Could you please let me know the procedure needed for the driver to be readded to Liberty? Specifically, will you be the one who upload the revert patchset, or it is the driver maintainer's responsibility? Diem. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Trove] Trove Meeting on 29 April canceled
Hey folks: There's not much to discuss on the agenda for this week [1] , so I'm going to go ahead and cancel the Trove weekly meeting for this week. We will have the Trove meeting next week on Wednesday, May 6th. Thanks, Nikhil [1] https://wiki.openstack.org/wiki/Meetings/TroveMeeting __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] Rabbitmq 3.4.0 upgrade for the 6.1 release, is it worth it?
Hello. There are several concerns why we have to upgrade RabbitMQ to 3.4.0 [0]: 1) At least two bugfixes related to the current high-load issue with MQ [1]: - 26404 prevent queue synchronisation from hanging if there is a very short partition just as it starts (since 3.1.0) - 26368 prevent autoheal from hanging when loser shuts down before the winner learns it is the winner (since 3.1.0) 2) We should as well check how the new 'pause-if-all-down' option works for split brain recovery. 3) We should address the 'force_boot' recommendations from this mail thread [2] to speed up the MQ cluster assemble time. The question is - is it worth it to do this in the 6.1 release scope? I vote to postpone this for the 7.0 dev cycle as the impact of such changes might be unpredictable. [0] https://www.rabbitmq.com/release-notes/README-3.4.0.txt [1] https://bugs.launchpad.net/fuel/+bug/1447619 [2] http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg51625.html -- Best regards, Bogdan Dobrelya, Skype #bogdando_at_yahoo.com Irc #bogdando __ OpenStack Development Mailing List (not for 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] Question for the TC candidates
Stefano Maffulli wrote: I've long come to the conclusion that it is what it is: at the size we're at, we can't expect every voter to be fully informed about all the issues. Better titles and a sort of TL;DR first paragraph in blog posts are very helpful. But in order to write those, the author needs to have more training as a communicator and more time. It's just a hard problem. Devil is in the details. We moved from an in-meeting voting system to an async in-Gerrit voting system, so most of the time the decision is actually made between meetings, when critical mass of voters is reached. Meeting summaries may or may not represent accurately the opinion of all members. Do we need to go through the extra pain of approving meeting minutes at the next meeting ? For the Juno/Kilo cycles we just had periodic reports when something significant was achieved, posted as authored blogposts on the OpenStack blog by a rotation of authors. I understand how that may not be regular enough, and I think the next membership will have to revisit how we communicate the work of the TC out. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] time based auto scaling
On Wed, Apr 29 2015, ZhiQiang Fan wrote: However, current ceilometer only provide time constraint alarm, which will only evaluate but not guarantee it will be triggered. And heat cannot provide something like timer, but just can wait for the signal. So I propose to add a new type of alarm, which will definitely send a signal to action when it is evaluated (with or without repeat, it will work well with time constraint) Any suggestion? I've proposed exactly that around 18-24 years go I think during a summit, and nobody was really interested back then and was worried to have yet another cron system – though OpenStack didn't have one. I still think it's a good idea and it will be a nice addition to the alarming system, so if you want to write a spec for that I'll be all yours. :) -- 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] [Horizon] Core Reviewer Update
On 29/04/15 00:57, David Lyle wrote: Thank you all for your contributions and welcome to the team! David Yes! Thanks a lot. You'll all make a great addition to the team. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Problem in loading image in sahara open stack
Sonal, According for this guide http://docs.openstack.org/developer/glance/statuses.html smthg should be wrong with uploading. Try to check your glance or ping glance team. Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2015-04-28 17:16 GMT+03:00 Nikolay Starodubtsev nstarodubt...@mirantis.com : Hi Sonal, Am I right and you can't just upload an image to glance image-registry? Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2015-04-28 16:28 GMT+03:00 Sonal Singh sonal.si...@aricent.com: Hi, I have installed Sahara openstack using devstack. Now I am going to make multi node cluster in Sahara. For this I have made 1 master node and 4 worker node now when I am going to launch this cluster, I need shara-juno-vanilla image. For this I have downloaded this image. Now when I am trying to launch this image in image storage of openstack, its status is hanged in queued state or getting killed but not coming in active state. Please find the below snapshot: Can you please provide me any solution regarding this. Any help will be highly appreciated. Thanks Regards Sonal DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. __ OpenStack Development Mailing 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] after change the system time backward, swift upload file return 409 conflict
After changed the system time from 4-20 to 4-5, upload file to swift returned 409 conflict, this file had been uploaded to swift at 4-20, the 409 conflict is caused by the fact that swift compares the request time against the disk_file's X-Timestamp, if the request time is older than the file's X-Timestamp, swift will return a 409 response. My question is that why swift compares the two timestamp, and how I can upload file to swift successfully? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Core Reviewer Update
On 04/29/2015 12:57 AM, David Lyle wrote: I am pleased to announce the addition of Doug Fish, Rob Cresswell and Travis Tripp to the Horizon Core Reviewer team. Doug Fish has been an active reviewer and participant in Horizon for a few releases now. He represents a strong customer focus and has provided high quality reviews. Rob Cresswell has been providing a high number of quality reviews, an active contributor and an active participant in the community. Travis Tripp has been contributing to Horizon for the past couple of releases, an active participant in the community, a critical angularJS reviewer, and played a significant role in driving the angular based launch instance work in Kilo. Thank you all for your contributions and welcome to the team! David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Welcome Doug, Rob and Travis, and thanks for all your contributions so far! -- Regards, Ana Krivokapic Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
Hello We are facing an issue with Congress devstack installation in our gate job testing murano-congress integration (policy enforcement) [1] . Congress devstack scripts install stevedore==1.4.0 as a dependency of python-muranoclient without specified version [2]. However heat requirement in stable/kilo is stevedore=1.3.0,1.4.0 so heat engine is unable to start. Is possible to fix by specifying murano client version not to be in confilct with heat requirements? [1] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/murano.yaml#L42 [2] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 [3] https://github.com/openstack/heat/blob/stable/kilo/requirements.txt#L47 Filip __ OpenStack Development Mailing 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, persistant configaration when openstack nodes(controller/compute/...) reboot
Hi, I have some questions on devstack, can anyone answer it. * Why devstack didn't start services automatically when openstack nodes reboots. * How to re-create the devstack, suchthat whenever nodes reboot , it 'll configured as previous configuration (i.e bringing up all the services as usual ). Thanks and Regards, Raghavendrachari kamsali | Software Engineer II | Embedded Computing Artesyn Embedded Technologies | 5th Floor, Capella Block, The V, Madhapur| Hyderabad, AP 500081 India T +91-40-66747059 | M +919705762153 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
Hi Filip, In thirdparty-requirements for stable/kilo python-muranoclient should have following version: python-muranoclient=0.5.6,0.6.0. But I am not sure that this will fix the issue, since we don't clearly know why stevedore==1.4.0 is installed. I see that python-keystoneclient does not have cap for stevedore in stable/kilo, but still not 100% that it is a reason why 1.4.0 is installed. [1] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 On Wed, Apr 29, 2015 at 3:46 PM, Filip Blaha filip.bl...@hp.com wrote: Hello We are facing an issue with Congress devstack installation in our gate job testing murano-congress integration (policy enforcement) [1] . Congress devstack scripts install stevedore==1.4.0 as a dependency of python-muranoclient without specified version [2]. However heat requirement in stable/kilo is stevedore=1.3.0,1.4.0 so heat engine is unable to start. Is possible to fix by specifying murano client version not to be in confilct with heat requirements? [1] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/murano.yaml#L42 [2] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz [3] https://github.com/openstack/heat/blob/stable/kilo/requirements.txt#L47 Filip __ OpenStack Development Mailing 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] Rabbitmq 3.4.0 upgrade for the 6.1 release, is it worth it?
I am 100% against the upgrade, folks. We need to ensure that user can use different network for GRE segmentation for high-load cases and mention this in Installation and Operations Guides - there is no time for it. On Wed, Apr 29, 2015 at 2:33 PM, Tomasz Napierala tnapier...@mirantis.com wrote: I’m -1 for it. Considering how much time we needed to troubleshoot the problems already, I don’t think we have time to properly test the upgrade. On 29 Apr 2015, at 12:37, Sergii Golovatiuk sgolovat...@mirantis.com wrote: -1 for upgrading it in 6.1. Known devil is better than unknown angel :) In 7.0 we can try 3.5.0 with updated Erlang. ~thanks -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Wed, Apr 29, 2015 at 12:20 PM, Davanum Srinivas dsrini...@mirantis.com wrote: Bogdan, Pacemaker, corosync etc, we picked vivid packages right? So don't we test what's in vivid for this too? Apparently it's 3.4.3-2 per [0]. I agree, we should not do this in 6.1, However, we should start testing this ASAP. Another data point, Alexander Nevenchannyy pointed out to me that 3.5.0 came with an updated Erlang that has the following fix: OTP-11497 To prevent a race condition if there is a short communication problem when node-down and node-up events are received. They are now stored and later checked if the node came up just before mnesia flagged the node as down. (Thanks to Jonas Falkevik ) which seems interesting as well. thanks, dims [0] https://launchpad.net/ubuntu/vivid/+package/rabbitmq-server [1] http://www.erlang.org/download/otp_src_17.0.readme On Wed, Apr 29, 2015 at 4:04 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote: Hello. There are several concerns why we have to upgrade RabbitMQ to 3.4.0 [0]: 1) At least two bugfixes related to the current high-load issue with MQ [1]: - 26404 prevent queue synchronisation from hanging if there is a very short partition just as it starts (since 3.1.0) - 26368 prevent autoheal from hanging when loser shuts down before the winner learns it is the winner (since 3.1.0) 2) We should as well check how the new 'pause-if-all-down' option works for split brain recovery. 3) We should address the 'force_boot' recommendations from this mail thread [2] to speed up the MQ cluster assemble time. The question is - is it worth it to do this in the 6.1 release scope? I vote to postpone this for the 7.0 dev cycle as the impact of such changes might be unpredictable. [0] https://www.rabbitmq.com/release-notes/README-3.4.0.txt [1] https://bugs.launchpad.net/fuel/+bug/1447619 [2] http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg51625.html -- Best regards, Bogdan Dobrelya, Skype #bogdando_at_yahoo.com Irc #bogdando -- Tomasz 'Zen' Napierala Product Engineering - Poland -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [sahara][CDH] Is it possible to add CDH5.4 into Kilo release now?
Kilo is closed to everything but critical bugs at this point. Going forward, this change probably counts as a new feature and is forbidden as a backport to Kilo too. So Liberty is the earliest opportunity. https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes Trev On Wed, 2015-04-29 at 04:49 +, Chen, Ken wrote: Hi all, Currently Cloudera has already release CDH5.4.0 version. I have already registered a bp and submitted two patches for it (https://blueprints.launchpad.net/sahara/+spec/cdh-5-4-support) . However, they are for master stream, and Cloudera hope it can be added to the latest release version of Sahara (Kilo release) so that they can give better support to their customers. I am not sure whether it is possible to do this at this stage? -Ken __ OpenStack Development Mailing 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] [oslo] oslo error while changing the the topic of plugin.
All, I changed the topic of firewall plugin and configured the agent to listen on same topic. But i am getting this error while publishing the message. 2015-04-29 18:12:55.464 31761 ERROR oslo.messaging._drivers.impl_rabbit [req-97302491-1a34-45c1-931c-1115fc1b0674 ] Failed to publish message to topic 'my_fw_agent': Exchange.declare: (406) PRECONDITION_FAILED - cannot redeclare exchange 'oc_fw_agent_fanout' in vhost '/' with different type, durable, internal or autodelete value 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit Traceback (most recent call last): 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py, line 655, in ensure 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit return method() 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py, line 752, in _publish 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit publisher = cls(self.conf, self.channel, topic=topic, **kwargs) 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py, line 393, in __init__ 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit None, type='fanout', **options) 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py, line 326, in __init__ 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit self.reconnect(channel) 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py, line 334, in reconnect 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit routing_key=self.routing_key) 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/kombu/messaging.py, line 82, in __init__ 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit self.revive(self._channel) 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/kombu/messaging.py, line 216, in revive 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit self.declare() 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/kombu/messaging.py, line 102, in declare 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit self.exchange.declare() 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/kombu/entity.py, line 166, in declare 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit nowait=nowait, passive=passive, 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/amqp/channel.py, line 620, in exchange_declare 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit (40, 11), # Channel.exchange_declare_ok 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/amqp/abstract_channel.py, line 69, in wait 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit return self.dispatch_method(method_sig, args, content) 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/amqp/abstract_channel.py, line 87, in dispatch_method 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit return amqp_method(self, args) 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/amqp/channel.py, line 241, in _close 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit reply_code, reply_text, (class_id, method_id), ChannelError, 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit PreconditionFailed: Exchange.declare: (406) PRECONDITION_FAILED - cannot redeclare exchange 'oc_fw_agent_fanout' in vhost '/' with different type, durable, internal or autodelete value 2015-04-29 18:12:55.464 31761 TRACE oslo.messaging._drivers.impl_rabbit 2015-04-29 18:12:55.465 31761 INFO oslo.messaging._drivers.impl_rabbit [req-97302491-1a34-45c1-931c-1115fc1b0674 ] Delaying reconnect for 1.0 seconds.. -- Regards, Vikash __ OpenStack Development Mailing List (not for 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] Rabbitmq 3.4.0 upgrade for the 6.1 release, is it worth it?
Agree with Vova and Tomasz. It's too late and risky for 6.1, in my opinion. Best, -jay On 04/29/2015 07:55 AM, Vladimir Kuklin wrote: I am 100% against the upgrade, folks. We need to ensure that user can use different network for GRE segmentation for high-load cases and mention this in Installation and Operations Guides - there is no time for it. On Wed, Apr 29, 2015 at 2:33 PM, Tomasz Napierala tnapier...@mirantis.com mailto:tnapier...@mirantis.com wrote: I’m -1 for it. Considering how much time we needed to troubleshoot the problems already, I don’t think we have time to properly test the upgrade. On 29 Apr 2015, at 12:37, Sergii Golovatiuk sgolovat...@mirantis.com mailto:sgolovat...@mirantis.com wrote: -1 for upgrading it in 6.1. Known devil is better than unknown angel :) In 7.0 we can try 3.5.0 with updated Erlang. ~thanks -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Wed, Apr 29, 2015 at 12:20 PM, Davanum Srinivas dsrini...@mirantis.com mailto:dsrini...@mirantis.com wrote: Bogdan, Pacemaker, corosync etc, we picked vivid packages right? So don't we test what's in vivid for this too? Apparently it's 3.4.3-2 per [0]. I agree, we should not do this in 6.1, However, we should start testing this ASAP. Another data point, Alexander Nevenchannyy pointed out to me that 3.5.0 came with an updated Erlang that has the following fix: OTP-11497 To prevent a race condition if there is a short communication problem when node-down and node-up events are received. They are now stored and later checked if the node came up just before mnesia flagged the node as down. (Thanks to Jonas Falkevik ) which seems interesting as well. thanks, dims [0] https://launchpad.net/ubuntu/vivid/+package/rabbitmq-server [1] http://www.erlang.org/download/otp_src_17.0.readme On Wed, Apr 29, 2015 at 4:04 AM, Bogdan Dobrelya bdobre...@mirantis.com mailto:bdobre...@mirantis.com wrote: Hello. There are several concerns why we have to upgrade RabbitMQ to 3.4.0 [0]: 1) At least two bugfixes related to the current high-load issue with MQ [1]: - 26404 prevent queue synchronisation from hanging if there is a very short partition just as it starts (since 3.1.0) - 26368 prevent autoheal from hanging when loser shuts down before the winner learns it is the winner (since 3.1.0) 2) We should as well check how the new 'pause-if-all-down' option works for split brain recovery. 3) We should address the 'force_boot' recommendations from this mail thread [2] to speed up the MQ cluster assemble time. The question is - is it worth it to do this in the 6.1 release scope? I vote to postpone this for the 7.0 dev cycle as the impact of such changes might be unpredictable. [0] https://www.rabbitmq.com/release-notes/README-3.4.0.txt [1] https://bugs.launchpad.net/fuel/+bug/1447619 [2] http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg51625.html -- Best regards, Bogdan Dobrelya, Skype #bogdando_at_yahoo.com http://bogdando_at_yahoo.com Irc #bogdando -- Tomasz 'Zen' Napierala Product Engineering - Poland -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru http://www.mirantis.ru/ vkuk...@mirantis.com mailto:vkuk...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Core Reviewer Update
Welcome! 发件人: David Lyle [mailto:dkly...@gmail.com] 发送时间: 2015年4月29日 6:58 收件人: OpenStack Development Mailing List 主题: [openstack-dev] [Horizon] Core Reviewer Update I am pleased to announce the addition of Doug Fish, Rob Cresswell and Travis Tripp to the Horizon Core Reviewer team. Doug Fish has been an active reviewer and participant in Horizon for a few releases now. He represents a strong customer focus and has provided high quality reviews. Rob Cresswell has been providing a high number of quality reviews, an active contributor and an active participant in the community. Travis Tripp has been contributing to Horizon for the past couple of releases, an active participant in the community, a critical angularJS reviewer, and played a significant role in driving the angular based launch instance work in Kilo. Thank you all for your contributions and welcome to the team! David __ OpenStack Development Mailing List (not for 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]Nova can't detach volume in init host routine
hi, hao, First, thanks for your bug and patch, I thinks it's really a problem we should fix. I forward your suggestions about the workaround with Dan Smith and Joe Gordon.to get more feedback. 1.Raise exception to make to set vm status to error,and user can re-perform a delete action to clean up successfully. 2.Add full set of cinder admin credentials in nova.conf(just like what neutron does with nova) and make sure nova can clean up in init_host On Tue, Apr 28, 2015 at 8:21 PM, hao wang sxmatch1...@gmail.com wrote: Hi, everyone There is a Nova bug: https://bugs.launchpad.net/nova/+bug/1408865. https://review.openstack.org/#/c/147042/ The bug Scenario is: 1. create a vm using bootable volume. 2. delete this vm 3. restart service nova-compute when vm's task state is deleting. When nova-compute is up, vm became deleted successful, but the bootable volume is still in-use state and can't delete it using cinder delete volume. solve method: Add init=True in _delete_instance when init_host, and raise exception when EndpointNotFound exists. It will set vm's status to error and make user can re-issue a delete. Is this method ok? Or cinder could do something to fix this bug? I need your suggestion to push this work forward. Thanks. wanghao -- Best Wishes For You! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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
[openstack-dev] [all] Question for the TC candidates
Again my apologies for the incorrect format - since I am still not receiving the messages from this thread. Please see my comments with the abstracts within (unfortunately not necessarily in the correct order) I think that the point here was that Doug mentioned that there was communication / I believe all of the posts were on the main OpenStack foundation blog // under the technical committee tag [1], and they also went to // planet.openstack.org for folks who subscribe to the entire community // feed. // / Doug - evidently this is not working as it should. As Chris said as well - the posts are not tagged and are not regular. Regarding this /For outgoing communication, during Kilo (and possibly Juno) we tried //blogging meeting summaries. Did folks notice? Were the posts useful?/ They were not noticed - because they didn't really happen. / We do not always resolve all issues in a week, so we won't // always have a conclusion to report. Ongoing discussions are tracked // either here on the mailing list or in gerrit, and I'm not sure we // want to try to duplicate that information to summarize it./ I do think that a regular update from the TC should be published. Should it be very week - probably not - because of the reason above - but at least once a month. Excerpts from Chris Dent's message of 2015-04-27 17:32:12 +0100: / The only way I've been able to get any sense of what the TC might be // up to is by watching the governance project on gerrit and that tends // to be too soon and insufficiently summarized and thus a fair bit of // work to separate the details from the destinations./ If the audience that you are planning on communicating with is: not the developers themselves and those who are already heavily involved in the community - I think this certainly is not the place to publicize changes. Do you seriously expect people who are trying to find information (not as a regular code contributor) about what is going on to start delving through Gerrit? Not going to happen. Does this mean that the TC has to change the way they make decisions? The TC should do what what they find works for them. But they also need to take into consideration that there are others who are interested in the information - but have no idea how to access it. We need make this more accessible - to those who are not like us. Excerpts from Chris Dent's message of 2015-04-27 23:20:39 +0100: / _Summaries_ are critical as it is important that the information is // digested and contextualized so its relevance can be more clear. I // know that I can read the IRC logs but I suspect most people don't // want to make the time for that. / Amen to that!! On Tue, 28 Apr 2015, Doug Hellmann wrote: OTOH, I'm not sure a strict weekly summary is going to be that useful. We do not always resolve all issues in a week, so we won't always have a conclusion to report. Ongoing discussions are tracked either here on the mailing list or in gerrit, and I'm not sure we want to try to duplicate that information to summarize it. So we need to find a balance, and I agree that we need to continue posting summaries. Again, Amen to that! Excerpts from Jeremy Stanley's message of 2015-04-28 16:21:17 +: / On 2015-04-28 16:30:21 +0100 (+0100), Chris Dent wrote: // [...] // What's important to avoid is the blog postings being only reporting of // conclusions. They also need to be invitations to participate in the // discussions. Yes, the mailing list, gerrit and meeting logs have some // of the ongoing discussions but often, without a nudge, people won't // know. // [...] // // Perhaps better visibility for the meeting agenda would help? As in // these are the major topics we're planning to cover in the upcoming // meeting, everyone is encouraged to attend sort of messaging? // Blogging that might be a bit obnoxious, not really sure (I'm one of // those luddites who prefer mailing lists to blogs so tend not to // follow the latter anyway). / I am not sure that you want people chiming in every single TC meeting - that will become quite chaotic. Excerpts from Chris Dent's message of Tue Apr 28 15:30:21 UTC 2015 I'm not trying to suggest that the TC is trying to keep people in the dark, rather that it always takes more effort than anyone would like to make sure things are lit. I don't think that anyone is implying that you are saying that the TC is keeping it to themselves. I for one would also like to see more communication coming out of the TC. And yes it does take effort. Excerpts from Chris Dent's message of Tue Apr 28 18:11:44 UTC 2015 I wouldn't have joined the commentary on the blogging issue if there hadn't already been a fair bit of talk about how fixing the feedback loop was one of the roads to improving. Also, critically, when Doug (who I can see is just trying to point out the current picture of reality so I'm not criticizing him, in fact I'd
Re: [openstack-dev] [all] Question for the TC candidates
On 29 April 2015 at 20:48, Thierry Carrez thie...@openstack.org wrote: Stefano Maffulli wrote: I've long come to the conclusion that it is what it is: at the size we're at, we can't expect every voter to be fully informed about all the issues. Better titles and a sort of TL;DR first paragraph in blog posts are very helpful. But in order to write those, the author needs to have more training as a communicator and more time. It's just a hard problem. Devil is in the details. We moved from an in-meeting voting system to an async in-Gerrit voting system, so most of the time the decision is actually made between meetings, when critical mass of voters is reached. Meeting summaries may or may not represent accurately the opinion of all members. Do we need to go through the extra pain of approving meeting minutes at the next meeting ? For the Juno/Kilo cycles we just had periodic reports when something significant was achieved, posted as authored blogposts on the OpenStack blog by a rotation of authors. I understand how that may not be regular enough, and I think the next membership will have to revisit how we communicate the work of the TC out. Most organisations of this size have a secretary whose job is to communicate with various folk, both in and out of the org. Perhaps the TC should elect / ask for a volunteer on of its members to be the TC secretary and be responsible for providing some push (vs pull) insight into the current state of things. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for 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] Proposed Liberty release schedule
Thierry Carrez wrote: Thierry Carrez wrote: [...] In summary, here is the proposed Liberty common schedule: liberty-1: June 25th liberty-2: July 30th liberty-3: September 3rd final release: October 15th Let me know if you see issues with it, like crazy holidays somewhere that would ruin it. No feedback, so I'm planning to officialize it this week after the TC and Cross-project meeting. Speak now or forever hold your peace ! OK, here it is: https://wiki.openstack.org/wiki/Liberty_Release_Schedule -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Why ceilometer do notoffer run_tests.sh script?
On Wed, 29 Apr 2015, Luo Gangyi wrote: Yes, we can do as you said. But still a bit weird using database in unit tests :) As stated elsewhere they aren't really unit tests, they're just tests. Those tests which rely on external services are being moved to another directory: It's used for the scenario tests on different db backend. Will be moved into functional test though. https://review.openstack.org/#/c/160827/ Once that split is complete there will be a directory for unit and directory for functional and it will be possible to run just the unit tests. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
On 04/29/2015 12:33 PM, neil.jer...@metaswitch.com wrote: Thanks Russell and Kyle for explaining. I think I get the picture now, in particular of how these backend projects are mostly under separate management, but at the same time subject to PTL oversight and 'part of the wider Neutron effort'. May I drill down further on what is anticipated, though, by considering what this might mean for my own project, Calico? I don't mean to self-advertise, but it's obviousl, the example that I know best! :-) Calico is a (potential) way of using Neutron for networking in an OpenStack deployment. But it's also broader than that, because it also targets (non-OpenStack-based) container systems. So it wouldn't be right to propose moving the whole of project Calico to be one of these Neutron backend projects. Right. Calico itself is something separate. It's analagous to OpenDaylight, OVN, or others. There's a separate project elsewhere implementing the core of the technology. What makes sense to be in Neutron is just the plugin/driver/agents needed to integrate Neutron with that technology. When Calico is used with Neutron, it takes the form of an ML2 mechanism driver. So perhaps that mechanism driver might be what would go into a networking-calico project? However, Yes. - the wonderful workings of the entry_points mechanism, combined with the existence of a stable API for mechanism drivers, mean that we don't strongly need to do that; and Right, you certainly don't have to. It's optional. You have to do things the OpenStack way when it comes to your processes. You submit to TC and Neutron PTL oversight. The benefit is that you're more closely associated with OpenStack and the Neutron project. I also hope that the groups included in the larger Neutron effort officially make some increased effort to collaborate with each other and the core Neutron project. - on its non-OpenStack-facing side, our mechanism driver's implementation shares common code with other pieces in the wider Calico project. That's not a big deal. Your driver can have custom dependencies. Presumably there's still some separation between what's Neutron driver code, and what's calico library code. So it's not really compelling to move the mechanism driver to a networking-calico project either - even though we do want to advertise and evangelise about Calico working with Neutron. Well, it's up to you, but I'm not convinced there's a technical reason not to do it based on the above description. I'm not really here to push one way or the other. I just want to help guide a discussion and understanding. So what then could go into a networking-calico project? Perhaps some OpenStack ecosystem documentation about using Calico in OpenStack, and/or perhaps some utilities that were specific to both Calico and the OpenStack environment? Perhaps I'm going down an unnecessary rabbit hole with this musing - but I'd really appreciate further comments and/or corrections to my understanding so far. I would guess that what I've raised might apply similarly to other big networking projects, for example Open Daylight. Many thanks, Neil PS. As I'm just about to send this, I wonder if our DHCP agent modifications might be a good example... Something that is definitely OpenStack-specific, but not yet clear if and how our changes should be folded into the main Neutron code. Perhaps that is the kind of thing that you have in mind? These modifications sound like a separate issue. If you have modifications to the DHCP agent, it makes sense to work with others in the Neutron team to figure out how to make it generic enough that the changes could be accepted. I suppose the alternative is carrying your own DHCP agent, and it sounds like that's what you're doing now. However, I think collaboration around this to either upstream your changes or at least figure out what code can be shared is ideal, wherever that makes sense. If you continue with your own agent that is OpenStack specific, that's something that makes sense to be in a networking-calico repo, IMO. -- Russell Bryant __ OpenStack Development Mailing List (not for 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] Question for the TC candidates
On 04/29/15 17:28, Doug Hellmann wrote: Excerpts from Maish Saidel-Keesing's message of 2015-04-29 12:59:35 +0300: Again my apologies for the incorrect format - since I am still not receiving the messages from this thread. Please see my comments with the abstracts within (unfortunately not necessarily in the correct order) I think that the point here was that Doug mentioned that there was communication / I believe all of the posts were on the main OpenStack foundation blog // under the technical committee tag [1], and they also went to // planet.openstack.org for folks who subscribe to the entire community // feed. // / Doug - evidently this is not working as it should. As Chris said as well - the posts are not tagged and are not regular. The lack of tags is an oversight, and should be easy to correct. Regarding this /For outgoing communication, during Kilo (and possibly Juno) we tried //blogging meeting summaries. Did folks notice? Were the posts useful?/ They were not noticed - because they didn't really happen. I don't think that's a fair characterization of the effort put into writing the posts. If you didn't see them because they didn't go to the right channel, that's one thing. If you didn't see them because there weren't enough of them, then I think we have different goals. I'm not sure it's as useful to publish on a schedule as it is to publish at meaningful milestones. Perhaps I came across too strong, that was not my intention. The posts were there, maybe not as publicized as well as they could have been, and not as frequent as they could have been, which is why I think it is great that Chris brought this up. If we take this week's meeting [1] as an example, we made some clarifications to existing rules for teams that want to join as official OpenStack projects [2]; we tweaked the description of the Congress project [3] to try to convey what it is for; we approved 5 repos as part of existing projects [4][5][6][7][8]; we updated the PTLs for projects [9]; and then we discussed the cross-project track at the summit. It's not clear those things warrant blog posts. Maybe they do, but aside from the summit planning, and possibly the meeting rule clarification, the others seem trivial enough that they would be noise in a channel we should preserve for communicating more important changes. I honestly don't know. If I was going to write a blog post about that meeting, which topics would you want me to have included? [1] http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-04-28-20.02.log.html [2] https://review.openstack.org/175427 [3] https://review.openstack.org/169480 [4] https://review.openstack.org/175620 [5] https://review.openstack.org/172802 [6] https://review.openstack.org/175610 [7] https://review.openstack.org/177070 [8] https://review.openstack.org/176338 [9] https://review.openstack.org/175007 I do not know either, that is something that should be agreed upon. Excerpts from Chris Dent's message of 2015-04-27 17:32:12 +0100: / The only way I've been able to get any sense of what the TC might be // up to is by watching the governance project on gerrit and that tends // to be too soon and insufficiently summarized and thus a fair bit of // work to separate the details from the destinations./ If the audience that you are planning on communicating with is: not the developers themselves and those who are already heavily involved in the community - I think this certainly is not the place to publicize changes. Do you seriously expect people who are trying to find information (not as a regular code contributor) about what is going on to start delving through Gerrit? We have two audiences. The contributors who elect us, and the broader community of deployers, users, etc. I think all of us do what we can individually to engage with that broader community, through meetups, our own blogs, and other channels. I don't expect them to use or read gerrit, or even necessarily subscribe to this list. On the other hand, the developer electorate is quite capable of subscribing to notices about changes happening in the governance repository and it does seem reasonable that if they really want to watch the minutia of TC's deliberations that they *would* take advantage of that capability. That's not to say it should be the only way we communicate, just that the option is there for those interested in using it. I don't think that we are talking about the developer electorate here, they already know how this works. It is trying to make this accessible to those others that are not aware of the intricacies of OpenStack. Not going to happen. Does this mean that the TC has to change the way they make decisions? The TC should do what what they find works for them. But they also need to take into consideration that there are others who are interested in the information - but have no idea how to access it. We need make this more accessible - to those who are not like us.
Re: [openstack-dev] [Fuel] Infiniband support in Fuel
Hi everybody, does anybody besides Mellanox need this? If not and while it's already solved issue for Mellanox itself - let's just close the bug as won't fix for now. On Wed, Apr 29, 2015 at 11:16 AM, Andrey Danin ada...@mirantis.com wrote: Hi, Sylwester, Fuel-plugin-mellanox is in development stage now, so no one can use it. I think, a longer MAC field may be helpful for other plugin developers in future. On Tue, Apr 28, 2015 at 12:50 AM, Sylwester Brzeczkowski sbrzeczkow...@mirantis.com wrote: We have a bug in fuel [1] which concerns infiniband support. It's mostly about expanding the size of mac field in db from 17 to 59. But I've email Aviram Bar-Haim who was working on for infiniband support [2] for fuel-plugin-mellanox [3] and he said that they use eIPoIB mac (mapping between ETH to IB) instead of IB Guid so it fits to our current mac field size. Does anyone have ever used fuel-plugin-mellanox with IB? I'm trying to find out if the bug is still valid? [1] https://bugs.launchpad.net/fuel/+bug/1398882 [2] https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/db/sqlalchemy/models/node.py#L103 [3] https://github.com/stackforge/fuel-plugin-mellanox Regards -- *Sylwester Brzeczkowski* Junior Python Software Engineer Product Development-Core : Product Engineering __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andrey Danin ada...@mirantis.com skype: gcon.monolake __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
Excerpts from Brant Knudson's message of 2015-04-29 09:17:08 -0500: On Wed, Apr 29, 2015 at 9:11 AM, Sean Dague s...@dague.net wrote: On 04/29/2015 10:05 AM, Sean Dague wrote: On 04/29/2015 09:29 AM, Filip Blaha wrote: Hi Serg I checked devstack log [1] and it seems that stevedore==1.4.0 was installed due to congress 2015-04-29 11:12:16.120 http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_16_120 | Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 It is last entry in log mentioning installation stevedore [1] http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz Not, it was installed due to keystonemiddleware - http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_02_13_727 Actually, it's more insideous than this. It's installed at 1.4.0 there, then it's downgraded to 1.3.0 when glance is installed, and then it's pushed back to 1.4.0 because of: http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_08_418 pip install -U should not be used in the general case, only in *very* specific cases. Whatever is hardcoding -U is the source of your problem. -Sean -- Sean Dague http://dague.net There's a review posted to update keystonemiddleware's requirements: https://review.openstack.org/#/c/173972/ . It was broken for a while after the branch was created due to pycadf installing oslo.messaging. For some reason it's working now even without the pycadf changes, but Doug H has a -2 on it. I'd like to know what the reqs are supposed to be for all the stable/kilo libraries -- I assumed we wanted them all to match global-requirements. We're in the process of figuring out how we want to deal with the caps. Adding caps to the requirements of libraries introduces challenges, so we're considering removing those and having applications cap all of their transitive dependencies. We need more time to think about it, and we're going to have a summit session in a couple of weeks, so we're not going to land patches now that we might have to undo later on. We also want to be mindful that changing the requirements of the library may involve breaking semver if we release a new stable version, and we only want to do that once per library if we do it at all. Doug I think all of our tox.ini's have -U: http://git.openstack.org/cgit/openstack/nova/tree/tox.ini#n6 - Brant __ OpenStack Development Mailing 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][stable] managing library requirements in stable/kilo it was worth its own thread.
tl;dr: Please do not approve any requirements changes to libraries in stable branches. We're in the process of figuring out how we want to deal with the caps. Adding caps to the requirements of libraries introduces challenges, so we're considering removing those and having applications cap all of their transitive dependencies. We need more time to think about it, and we're going to have a summit session in a couple of weeks, so we're not going to land patches now that we might have to undo later on. We also want to be mindful that changing the requirements of the library may involve breaking semver if we release a new stable version, and we only want to do that once per library if we do it at all. 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] [Fuel] Infiniband support in Fuel
Hello, If all is ok, let's move bug to 7.0 and fix it with netaddr as it was proposed in comments to the ticket. - Igor On Wed, Apr 29, 2015 at 6:29 PM, Nikolay Markov nmar...@mirantis.com wrote: Hi everybody, does anybody besides Mellanox need this? If not and while it's already solved issue for Mellanox itself - let's just close the bug as won't fix for now. On Wed, Apr 29, 2015 at 11:16 AM, Andrey Danin ada...@mirantis.com wrote: Hi, Sylwester, Fuel-plugin-mellanox is in development stage now, so no one can use it. I think, a longer MAC field may be helpful for other plugin developers in future. On Tue, Apr 28, 2015 at 12:50 AM, Sylwester Brzeczkowski sbrzeczkow...@mirantis.com wrote: We have a bug in fuel [1] which concerns infiniband support. It's mostly about expanding the size of mac field in db from 17 to 59. But I've email Aviram Bar-Haim who was working on for infiniband support [2] for fuel-plugin-mellanox [3] and he said that they use eIPoIB mac (mapping between ETH to IB) instead of IB Guid so it fits to our current mac field size. Does anyone have ever used fuel-plugin-mellanox with IB? I'm trying to find out if the bug is still valid? [1] https://bugs.launchpad.net/fuel/+bug/1398882 [2] https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/db/sqlalchemy/models/node.py#L103 [3] https://github.com/stackforge/fuel-plugin-mellanox Regards -- Sylwester Brzeczkowski Junior Python Software Engineer Product Development-Core : Product Engineering __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andrey Danin ada...@mirantis.com skype: gcon.monolake __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Question for the TC candidates
Excerpts from Maish Saidel-Keesing's message of 2015-04-29 18:28:45 +0300: On 04/29/15 17:28, Doug Hellmann wrote: Taking as given that we should be open and communicate more, I would like to ask a concrete question. It seems like there is a general sense of concern about communication, but I want to make sure it's not related to ongoing discussions. Is there something specific that happened over the last year that was a surprise, or that was not communicated well? Something we could address in the short term with a blog post or email discussion? How about the fact that the definition of an ATC was changed [1] for a free Summit pass? [2] I could be wrong, but I don't think that was a TC decision. I believe that was set at the foundation level, since they organize the event. Perhaps part of clearing up communication for the next cycle will need to be explaining who is responsible for different aspects of the community. 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] [Neutron] A big tent home for Neutron backend code
Thanks Russell and Kyle for explaining. I think I get the picture now, in particular of how these backend projects are mostly under separate management, but at the same time subject to PTL oversight and 'part of the wider Neutron effort'. May I drill down further on what is anticipated, though, by considering what this might mean for my own project, Calico? I don't mean to self-advertise, but it's obviously the example that I know best! :-) Calico is a (potential) way of using Neutron for networking in an OpenStack deployment. But it's also broader than that, because it also targets (non-OpenStack-based) container systems. So it wouldn't be right to propose moving the whole of project Calico to be one of these Neutron backend projects. When Calico is used with Neutron, it takes the form of an ML2 mechanism driver. So perhaps that mechanism driver might be what would go into a networking-calico project? However, - the wonderful workings of the entry_points mechanism, combined with the existence of a stable API for mechanism drivers, mean that we don't strongly need to do that; and - on its non-OpenStack-facing side, our mechanism driver's implementation shares common code with other pieces in the wider Calico project. So it's not really compelling to move the mechanism driver to a networking-calico project either - even though we do want to advertise and evangelise about Calico working with Neutron. So what then could go into a networking-calico project? Perhaps some OpenStack ecosystem documentation about using Calico in OpenStack, and/or perhaps some utilities that were specific to both Calico and the OpenStack environment? Perhaps I'm going down an unnecessary rabbit hole with this musing - but I'd really appreciate further comments and/or corrections to my understanding so far. I would guess that what I've raised might apply similarly to other big networking projects, for example Open Daylight. Many thanks, Neil PS. As I'm just about to send this, I wonder if our DHCP agent modifications might be a good example... Something that is definitely OpenStack-specific, but not yet clear if and how our changes should be folded into the main Neutron code. Perhaps that is the kind of thing that you have in mind? Original Message From: Russell Bryant Sent: Tuesday, 28 April 2015 18:57 To: openstack-dev@lists.openstack.org Reply To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code On 04/28/2015 01:17 PM, Neil Jerram wrote: Apologies for commenting so late, but I'm not clear on the concept of bringing all possible backend projects back inside Neutron. I think my question is similar to what Henry and Mathieu are getting at below - viz: We just recently decided to move a lot of vendor-specific ML2 mechanism driver code _out_ of the Neutron tree; and I thought that the main motivation for that was that it wasn't reasonably possible for most Neutron developers to understand, review and maintain that code to the same level as they can with the Neutron core code. How then does it now make sense to bring a load of vendor-specific code back into the Neutron fold? Has some important factor changed? Or have I misunderstood what is now being proposed? The suggestion is to recognize that these are all part of the larger Neutron effort. It is *not* to suggest that the same group of developers needs to be reviewing all of it. It's mostly an organizational thing. The way teams operate should not change too much. -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [sahara][CDH] Is it possible to add CDH5.4 into Kilo release now?
Trevor, yup, that's correct. Adding new plugin version support is the new feature and there is no way to backport it to stable/kilo branch (Kilo release). Thanks. On Wed, Apr 29, 2015 at 4:04 PM, Trevor McKay tmc...@redhat.com wrote: Kilo is closed to everything but critical bugs at this point. Going forward, this change probably counts as a new feature and is forbidden as a backport to Kilo too. So Liberty is the earliest opportunity. https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes Trev On Wed, 2015-04-29 at 04:49 +, Chen, Ken wrote: Hi all, Currently Cloudera has already release CDH5.4.0 version. I have already registered a bp and submitted two patches for it (https://blueprints.launchpad.net/sahara/+spec/cdh-5-4-support) . However, they are for master stream, and Cloudera hope it can be added to the latest release version of Sahara (Kilo release) so that they can give better support to their customers. I am not sure whether it is possible to do this at this stage? -Ken __ OpenStack Development Mailing 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 -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Question for the TC candidates
On 2015-04-29 12:59:35 +0300 (+0300), Maish Saidel-Keesing wrote: [...] Excerpts from Jeremy Stanley's message of 2015-04-28 16:21:17 +: / On 2015-04-28 16:30:21 +0100 (+0100), Chris Dent wrote: // [...] // What's important to avoid is the blog postings being only reporting of // conclusions. They also need to be invitations to participate in the // discussions. Yes, the mailing list, gerrit and meeting logs have some // of the ongoing discussions but often, without a nudge, people won't // know. // [...] // // Perhaps better visibility for the meeting agenda would help? As in // these are the major topics we're planning to cover in the upcoming // meeting, everyone is encouraged to attend sort of messaging? // Blogging that might be a bit obnoxious, not really sure (I'm one of // those luddites who prefer mailing lists to blogs so tend not to // follow the latter anyway). / I am not sure that you want people chiming in every single TC meeting - that will become quite chaotic. [...] As a constituent, I feel it's not only my right but also my duty to address the TC on relevant topics if I'm concerned they're not considering certain aspects/implications of what's being deliberated. Arbitrary, off-topic banter from random lurkers is of course unwelcome because it adds unnecessary noise and slows down the meeting, but I do think people who have concerns should be encouraged to participate (keeping to the agenda of course) as long as it's constructive and not preventing the TC from holding a productive meeting. I also attend meetings of the Foundation Board, even though I'm not a board member. As with any government, if you elect people, you should certainly engage with them in appropriate venues. Sometimes that means being present for their public assemblies (be they physical or virtual) so you can participate in those discussions. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] [discoverd] Announcing ironic-discoverd 1.1.0; future plans
Hi folks! A bit earlier than expected to to my PTO I'm announcing ironic-discoverd 1.1.0. Download it from PyPI: https://pypi.python.org/pypi/ironic-discoverd We've spent substantial amount of time polishing existing features and fixing bugs. Highlights are: * New config options for tuning which ports get added to Ironic and which get deleted: add_ports and keep_ports. * New supported CLI tool based on OpenStackClient. * Discoverd now tries its best to update node introspection state, even if ramdisk data processing fails on an early step. * Support for receiving logs from the ramdisk. * In-tree devstack plugin, see https://etherpad.openstack.org/p/DiscoverdDevStack * Finished support for setting IPMI credentials during discovery. This is still an experimental feature, but it works in our testing, so it's worth trying. * Support for oslo.i18n. See https://github.com/stackforge/ironic-discoverd/blob/stable/1.1/RELEASES.rst for more detailed change log and https://bugs.launchpad.net/ironic-discoverd/+milestone/1.1.0 for list of finished blueprints and fixed bugs. Report bugs to launchpad as well: https://bugs.launchpad.net/ironic-discoverd. Now to the future plans. First of all, I suggest starting following Ironic release schedule. For now that means to release twice a year, not 4 times like it is now. My personal interest right now is to improve our ramdisk. I've started an effort to rewrite our ramdisk in Python, based on what we have downstream: https://blueprints.launchpad.net/ironic-discoverd/+spec/python-ramdisk-code Unfortunately, it's more than hard to add Python scripts to our current DIB ramdisks, so the next step would be to adopt IPA as a basis. I'm still not 100% sure how do it, but I plan on figuring out after PTO (and on the summit). Initial thoughts are in https://blueprints.launchpad.net/ironic-discoverd/+spec/long-running-ramdisks. There are more things we can do in the next release: https://bugs.launchpad.net/ironic-discoverd/+milestone/1.2.0 Feel free to propose whatever you think it useful. Cheers, Dmitry __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
So, summarizing some chatter on #openstack-dev: Action item for unblocking the gate job: 1. Remove the -U in the shell script that installs thirdparty-requirements.txt in congress' repo. If that's not enough: 2. make sure congress' stable/kilo requirements.txt/test-requirements.txt is sync'ed with the global stable/kilo. -- dims On Wed, Apr 29, 2015 at 11:32 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Brant Knudson's message of 2015-04-29 09:17:08 -0500: On Wed, Apr 29, 2015 at 9:11 AM, Sean Dague s...@dague.net wrote: On 04/29/2015 10:05 AM, Sean Dague wrote: On 04/29/2015 09:29 AM, Filip Blaha wrote: Hi Serg I checked devstack log [1] and it seems that stevedore==1.4.0 was installed due to congress 2015-04-29 11:12:16.120 http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_16_120 | Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 It is last entry in log mentioning installation stevedore [1] http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz Not, it was installed due to keystonemiddleware - http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_02_13_727 Actually, it's more insideous than this. It's installed at 1.4.0 there, then it's downgraded to 1.3.0 when glance is installed, and then it's pushed back to 1.4.0 because of: http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_08_418 pip install -U should not be used in the general case, only in *very* specific cases. Whatever is hardcoding -U is the source of your problem. -Sean -- Sean Dague http://dague.net There's a review posted to update keystonemiddleware's requirements: https://review.openstack.org/#/c/173972/ . It was broken for a while after the branch was created due to pycadf installing oslo.messaging. For some reason it's working now even without the pycadf changes, but Doug H has a -2 on it. I'd like to know what the reqs are supposed to be for all the stable/kilo libraries -- I assumed we wanted them all to match global-requirements. We're in the process of figuring out how we want to deal with the caps. Adding caps to the requirements of libraries introduces challenges, so we're considering removing those and having applications cap all of their transitive dependencies. We need more time to think about it, and we're going to have a summit session in a couple of weeks, so we're not going to land patches now that we might have to undo later on. We also want to be mindful that changing the requirements of the library may involve breaking semver if we release a new stable version, and we only want to do that once per library if we do it at all. Doug I think all of our tox.ini's have -U: http://git.openstack.org/cgit/openstack/nova/tree/tox.ini#n6 - Brant __ OpenStack Development Mailing 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 -- 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] [all] Question for the TC candidates
On 2015-04-29 11:48:36 -0400 (-0400), Doug Hellmann wrote: Excerpts from Maish Saidel-Keesing's message of 2015-04-29 18:28:45 +0300: [...] How about the fact that the definition of an ATC was changed [1] for a free Summit pass? [2] I could be wrong, but I don't think that was a TC decision. I believe that was set at the foundation level, since they organize the event. [...] Yes, that was a decision made by the event organizers at the OpenStack Foundation, primarily to reduce the planning problems associated with people who exercise the free registration but then don't attend the event. It also allowed them to keep the number of free passes down to a reasonable couple thousands of contributors. To be clear, that decision did not involve the TC at all. Also there has been an effort not to call them ATC passes because the definition of ATC is necessarily tied to the technical committee electorate. Instead these are complimentary passes offered by the OpenStack Foundation for current contributors to make it easier for them to get involved in planning sessions at the Design Summit (which runs in parallel to the conference). While it also gets them access to the conference sessions and expo hall, there are many like me who don't take advantage of that since the Design Summit itself occupies pretty much all of their available time anyway. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Core Reviewer Update
Thank you for the warm welcome, everyone! I'm excited to be on the team and am really looking forward to everything coming in Liberty! -Travis On 4/29/15, 6:16 AM, Ana Krivokapić akriv...@redhat.com wrote: On 04/29/2015 12:57 AM, David Lyle wrote: I am pleased to announce the addition of Doug Fish, Rob Cresswell and Travis Tripp to the Horizon Core Reviewer team. Doug Fish has been an active reviewer and participant in Horizon for a few releases now. He represents a strong customer focus and has provided high quality reviews. Rob Cresswell has been providing a high number of quality reviews, an active contributor and an active participant in the community. Travis Tripp has been contributing to Horizon for the past couple of releases, an active participant in the community, a critical angularJS reviewer, and played a significant role in driving the angular based launch instance work in Kilo. Thank you all for your contributions and welcome to the team! David _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Welcome Doug, Rob and Travis, and thanks for all your contributions so far! -- Regards, Ana Krivokapic Software Engineer OpenStack team Red Hat Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for 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] A big tent home for Neutron backend code
My take on the “where does it fit” yardstick: Does it stand on its own and add value? Then consider it a standalone project, *or* part of neutron if you and neutron agree that it fits. Does it *require* neutron to be useful? Then consider having it under the neutron umbrella/stadium/tent/yurt. Thanks, doug On Apr 29, 2015, at 10:33 AM, neil.jer...@metaswitch.com wrote: Thanks Russell and Kyle for explaining. I think I get the picture now, in particular of how these backend projects are mostly under separate management, but at the same time subject to PTL oversight and 'part of the wider Neutron effort'. May I drill down further on what is anticipated, though, by considering what this might mean for my own project, Calico? I don't mean to self-advertise, but it's obviously the example that I know best! :-) Calico is a (potential) way of using Neutron for networking in an OpenStack deployment. But it's also broader than that, because it also targets (non-OpenStack-based) container systems. So it wouldn't be right to propose moving the whole of project Calico to be one of these Neutron backend projects. When Calico is used with Neutron, it takes the form of an ML2 mechanism driver. So perhaps that mechanism driver might be what would go into a networking-calico project? However, - the wonderful workings of the entry_points mechanism, combined with the existence of a stable API for mechanism drivers, mean that we don't strongly need to do that; and - on its non-OpenStack-facing side, our mechanism driver's implementation shares common code with other pieces in the wider Calico project. So it's not really compelling to move the mechanism driver to a networking-calico project either - even though we do want to advertise and evangelise about Calico working with Neutron. So what then could go into a networking-calico project? Perhaps some OpenStack ecosystem documentation about using Calico in OpenStack, and/or perhaps some utilities that were specific to both Calico and the OpenStack environment? Perhaps I'm going down an unnecessary rabbit hole with this musing - but I'd really appreciate further comments and/or corrections to my understanding so far. I would guess that what I've raised might apply similarly to other big networking projects, for example Open Daylight. Many thanks, Neil PS. As I'm just about to send this, I wonder if our DHCP agent modifications might be a good example... Something that is definitely OpenStack-specific, but not yet clear if and how our changes should be folded into the main Neutron code. Perhaps that is the kind of thing that you have in mind? Original Message From: Russell Bryant Sent: Tuesday, 28 April 2015 18:57 To: openstack-dev@lists.openstack.org Reply To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code On 04/28/2015 01:17 PM, Neil Jerram wrote: Apologies for commenting so late, but I'm not clear on the concept of bringing all possible backend projects back inside Neutron. I think my question is similar to what Henry and Mathieu are getting at below - viz: We just recently decided to move a lot of vendor-specific ML2 mechanism driver code _out_ of the Neutron tree; and I thought that the main motivation for that was that it wasn't reasonably possible for most Neutron developers to understand, review and maintain that code to the same level as they can with the Neutron core code. How then does it now make sense to bring a load of vendor-specific code back into the Neutron fold? Has some important factor changed? Or have I misunderstood what is now being proposed? The suggestion is to recognize that these are all part of the larger Neutron effort. It is *not* to suggest that the same group of developers needs to be reviewing all of it. It's mostly an organizational thing. The way teams operate should not change too much. -- Russell Bryant __ OpenStack Development Mailing 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] [nova] [docs] Scheduler filters documentation
A good comment has been provided to https://review.openstack.org/#/c/177824/1 by saying that the reference docs [1] are duplicate to the Nova devref section [2] As I also think it is error-prone to keep two separate informations about how Scheduler filters, I would like to discuss on how we could make sure both are in sync. Since the developers owe to provide how to use the filters they write, my preference goes to keep updating the Nova devref page each time a filter behaviour is changed or a new filter is created and consequently make sure that the reference docs is pointing to that devref page, using an iframe or whatever else. Of course, each time that a behavioural change is provided, that's also the developer's duty to provide a DocImpact tag in order to make sure that docs people are aware of the change. Thoughts ? -Sylvain [1] http://docs.openstack.org/juno/config-reference/content/section_compute-scheduler.html#aggregate-instanceextraspecsfilter [2] http://docs.openstack.org/developer/nova/devref/filter_scheduler.html#filtering __ OpenStack Development Mailing List (not for 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] Question for the TC candidates
On Wed, 2015-04-29 at 12:59 +0300, Maish Saidel-Keesing wrote: Again my apologies for the incorrect format - since I am still not receiving the messages from this thread. let me know if you want me to investigate this further. Doug - evidently this is not working as it should. As Chris said as well - the posts are not tagged and are not regular. I'd like to move the conversation to practical examples because in theory we all agree that communication is key and can be improved. In practice, that's hard and it's better to talk about specific examples. They were not noticed - because they didn't really happen. I sense that they happened until there were things fairly easy to communicate. Are there been significant discussions in TC meetings? Yes, the big tent and the accompanying tag system is the only one I can think of. Were they worth a blog post? Yes. Was that blog post easy to write? No because the topic has been under development for quite some time with not enough clear roadmap to write a summary for wider consumption. If a blog post comes out saying something half-baked over a change so important, the TC members will be distracted by noise from people not involved enough to understand the challenges. There is always a fine balance to strike between being open and being effective. Considering that all TC members are volunteers with day jobs, get busier and busier as the release approaches, I'm really not surprised that the TC has scheduled time to present the progress on the 'big tent' and tags in person at events (the operators summit in PHL) and in Vancouver. IMHO the topic is getting clear enough to be summarized in 500-700 words blog post only in the past weeks... The thing is that tags and big tent have been discussed widely *outside* of the TC, I think nobody interested in the OpenStack governance issues may have missed the fact that such conversation was happening. They may have missed the *details* but not missed the existence of the conversation itself. what other topic has the TC discussed and decided upon that have you not seen announced? If the audience that you are planning on communicating with is: not the developers themselves and those who are already heavily involved in the community - I think this certainly is not the place to publicize changes. Do you seriously expect people who are trying to find information (not as a regular code contributor) about what is going on to start delving through Gerrit? Maybe we should document better how to get notifications of new discussions on the governance repository. I could also start including the proposals pending for review in the newsletter so people can at least skim through the commit titles weekly. If you check the latest changes though you'll see how much of that is really not important: https://review.openstack.org/#/q/project:openstack/governance,n,z the important ones I find in 2015: https://review.openstack.org/150604 Add the release naming process https://review.openstack.org/159930 Add IRC channel policies a few new project teams added and the tag-stuff, like https://review.openstack.org/145740 Move from program-based structure to project-based https://review.openstack.org/149961 Introduce tag attributes https://review.openstack.org/145734 Add template for project taxonomy tags definition /stef __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Question for the TC candidates
Excerpts from Chris Dent's message of 2015-04-29 18:45:54 +0100: On Wed, 29 Apr 2015, Doug Hellmann wrote: Taking as given that we should be open and communicate more, I would like to ask a concrete question. It seems like there is a general sense of concern about communication, but I want to make sure it's not related to ongoing discussions. Is there something specific that happened over the last year that was a surprise, or that was not communicated well? Something we could address in the short term with a blog post or email discussion? I don't know about others, but for me it has been a general concern and nothing specific. In fact until this subthread went (mildly) boom OK, that's good. I think it's a general concern for the TC, too, in that we do recognize we need to communicate about what we're doing. Knowing that there have been some issues with how that played out in the past is helpful. I had just kind of assumed it was a well known concern and no one would be surprised by it being an issue of import for the coming cycle and beyond. Oh, I'm not surprised, I'm just taking advantage of the opportunity of it having come up and me having time to address it. :-) For what it's worth, I'm not reading this discussion as us disagreeing in any way. We made some reasonable starts at publicizing our ongoing work, but it's clear we can do better from a technical standpoint (tagging posts) and from a volume standpoint (publishing more often). I'm interested in having more input into how best to improve communication, so I keep asking questions and I'm glad you're all still answering. :-) It sounds like you and I are and have been mostly on the same page, finding data, exploring the options, etc. I think it has been pretty productive, at least in the sense that we know more than we did before. +1 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] [Congress] [Murano] Congress devstack installation is failing in murano gate job
Perfect. thanks Ruslan. -- dims On Wed, Apr 29, 2015 at 2:47 PM, Ruslan Kamaldinov rkamaldi...@mirantis.com wrote: On Wed, Apr 29, 2015 at 6:46 PM, Davanum Srinivas dava...@gmail.com wrote: So, summarizing some chatter on #openstack-dev: Action item for unblocking the gate job: 1. Remove the -U in the shell script that installs thirdparty-requirements.txt in congress' repo. This patch to Congress stable/kilo resolved the issue with failing job gate-murano-congress-devstack-dsvm: https://review.openstack.org/#/c/178777/ If that's not enough: 2. make sure congress' stable/kilo requirements.txt/test-requirements.txt is sync'ed with the global stable/kilo. -- 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 -- 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] [all] Question for the TC candidates
On 04/29/15 21:59, Stefano Maffulli wrote: On Wed, 2015-04-29 at 18:28 +0300, Maish Saidel-Keesing wrote: How about the fact that the definition of an ATC was changed [1] for a free Summit pass? [2] This was not a decision of the TC, it was a decision of the Foundation staff. The definition of ATC has *not* changed, that's embedded in the bylaws. I stand corrected. (more than once :) ) Thanks for the clarification Stefano, Doug and Jeremy. And who gets the pass hasn't changed much either: people who are *actively* committing code and documentation to OpenStack have received an invite. Previously we have considered *actively* committing code and docs == ATC. For this cycle the Foundation staff started considering better ways to identify those that actually contribute to the design discussions. The details of who gets a free invite may change again in the future because we want to keep the Open promises, without compromising the event. HTH stef -- Best Regards, Maish Saidel-Keesing __ OpenStack Development Mailing List (not for 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] [docs] Scheduler filters documentation
On 4/29/2015 2:08 PM, Sylvain Bauza wrote: A good comment has been provided to https://review.openstack.org/#/c/177824/1 by saying that the reference docs [1] are duplicate to the Nova devref section [2] As I also think it is error-prone to keep two separate informations about how Scheduler filters, I would like to discuss on how we could make sure both are in sync. Since the developers owe to provide how to use the filters they write, my preference goes to keep updating the Nova devref page each time a filter behaviour is changed or a new filter is created and consequently make sure that the reference docs is pointing to that devref page, using an iframe or whatever else. Of course, each time that a behavioural change is provided, that's also the developer's duty to provide a DocImpact tag in order to make sure that docs people are aware of the change. Thoughts ? -Sylvain [1] http://docs.openstack.org/juno/config-reference/content/section_compute-scheduler.html#aggregate-instanceextraspecsfilter [2] http://docs.openstack.org/developer/nova/devref/filter_scheduler.html#filtering __ OpenStack Development Mailing 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'd prefer to see the scheduler filter docs be maintained in the nova devref where they are close to the source, versioned, and reviewed by the nova team when there are scheduler filter changes or new filters added. I doubt many nova developers/reviewers get over to reviewing changes to the config reference docs. Then if possible have the config reference docs repo refer to the nova devref docs as the primary source of information on the filters. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [docs] Scheduler filters documentation
On Apr 29, 2015, at 2:30 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: I'd prefer to see the scheduler filter docs be maintained in the nova devref where they are close to the source, versioned, and reviewed by the nova team when there are scheduler filter changes or new filters added. For now, I think this is best. When and if the scheduler is a separate entity, it will need its own docs; nova will still need to document *its* filters, but not *how to* filter. -- Ed Leafe signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On Apr 29, 2015, at 1:34 PM, Adam Lawson alaw...@aqorn.com wrote: Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community who are not allowed to vote. Operators meaning Admins, Architects, etc. It sounds like this is something most TC candidates want which most would agree is a good thing. At least I think so. ; ) I think that the reason may be that historically the people on the TC have come from the dev side of things, and as a result the ops side has been ignored (or not given sufficient attention). Since this is something that we are now all aware of, and since developing OpenStack is kind of worthless if it can't be deployed and run well, this is the area we more or less agree needs improvement. How we might go about improving it is where you may see differences. -- Ed Leafe signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for 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] Question for the TC candidates
On Wed, 29 Apr 2015, Doug Hellmann wrote: Taking as given that we should be open and communicate more, I would like to ask a concrete question. It seems like there is a general sense of concern about communication, but I want to make sure it's not related to ongoing discussions. Is there something specific that happened over the last year that was a surprise, or that was not communicated well? Something we could address in the short term with a blog post or email discussion? I don't know about others, but for me it has been a general concern and nothing specific. In fact until this subthread went (mildly) boom I had just kind of assumed it was a well known concern and no one would be surprised by it being an issue of import for the coming cycle and beyond. For what it's worth, I'm not reading this discussion as us disagreeing in any way. We made some reasonable starts at publicizing our ongoing work, but it's clear we can do better from a technical standpoint (tagging posts) and from a volume standpoint (publishing more often). I'm interested in having more input into how best to improve communication, so I keep asking questions and I'm glad you're all still answering. :-) It sounds like you and I are and have been mostly on the same page, finding data, exploring the options, etc. I think it has been pretty productive, at least in the sense that we know more than we did before. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tc] Who is allowed to vote for TC candidates
So I started replying to Doug's email in a different thread but didn't want to hi-jack that so I figured I'd present my question as a more general question about how voting is handled for the TC. Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community who are not allowed to vote. Operators meaning Admins, Architects, etc. It sounds like this is something most TC candidates want which most would agree is a good thing. At least I think so. ; ) Is it be feasible to start allowing the operator community to also cast votes for TC candidates? Is the TC *only* addressing technical concerns that are relevant to the development community? Since the TC candidates are embracing the idea of representing more than just the developer community, it would /seem/ the voters electing the TC members should include the communities being represented. If the TC only addresses developer concerns, it would seem they become at risk of losing touch with the operator/architecture/user concerns because the operator community voice is never heard in the voting booth. Perhaps this bumps into how it used to be versus how it should be. I don't know. Just struck me as incongruent with the platform of almost every candidate - broadening representation while the current rules prohibit that level of co-participation. Thoughts? *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 __ OpenStack Development Mailing List (not for 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, persistant configaration when openstack nodes(controller/compute/...) reboot
On Wed, Apr 29, 2015 at 5:20 AM, Kamsali, RaghavendraChari (Artesyn) raghavendrachari.kams...@artesyn.com wrote: · Why devstack didn’t start services automatically when openstack nodes reboots. · How to re-create the devstack, suchthat whenever nodes reboot , it ‘ll configured as previous configuration (i.e bringing up all the services as usual ). DevStack is really not meant to operate this way, as devstack is not running the OpenStack projects as system services. From the FAQ[0] Q: Can I use DevStack for production? A: No. We mean it. Really. DevStack makes some implementation choices that are not appropriate for production deployments. We warned you! [0]http://docs.openstack.org/developer/devstack/faq.html -Christopher __ OpenStack Development Mailing List (not for 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] A big tent home for Neutron backend code
On 04/29/2015 01:25 PM, Doug Wiegley wrote: My take on the “where does it fit” yardstick: Does it stand on its own and add value? Then consider it a standalone project, *or* part of neutron if you and neutron agree that it fits. Does it *require* neutron to be useful? Then consider having it under the neutron umbrella/stadium/tent/yurt. ...arena/coliseum/dome... That's a nice summary. Thanks. :-) -- Russell Bryant __ OpenStack Development Mailing List (not for 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] Question for the TC candidates
On Wed, 2015-04-29 at 18:28 +0300, Maish Saidel-Keesing wrote: How about the fact that the definition of an ATC was changed [1] for a free Summit pass? [2] This was not a decision of the TC, it was a decision of the Foundation staff. The definition of ATC has *not* changed, that's embedded in the bylaws. And who gets the pass hasn't changed much either: people who are *actively* committing code and documentation to OpenStack have received an invite. Previously we have considered *actively* committing code and docs == ATC. For this cycle the Foundation staff started considering better ways to identify those that actually contribute to the design discussions. The details of who gets a free invite may change again in the future because we want to keep the Open promises, without compromising the event. HTH stef __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
On Wed, Apr 29, 2015 at 6:46 PM, Davanum Srinivas dava...@gmail.com wrote: So, summarizing some chatter on #openstack-dev: Action item for unblocking the gate job: 1. Remove the -U in the shell script that installs thirdparty-requirements.txt in congress' repo. This patch to Congress stable/kilo resolved the issue with failing job gate-murano-congress-devstack-dsvm: https://review.openstack.org/#/c/178777/ If that's not enough: 2. make sure congress' stable/kilo requirements.txt/test-requirements.txt is sync'ed with the global stable/kilo. -- 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] [tc] Who is allowed to vote for TC candidates
Excerpts from Adam Lawson's message of 2015-04-29 11:34:40 -0700: So I started replying to Doug's email in a different thread but didn't want to hi-jack that so I figured I'd present my question as a more general question about how voting is handled for the TC. Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community who are not allowed to vote. Operators meaning Admins, Architects, etc. It sounds like this is something most TC candidates want which most would agree is a good thing. At least I think so. ; ) I'm going to nitpick on terminology a bit. The TC is elected by *technical contributors*, not developers, as described in the charter: http://governance.openstack.org/reference/charter.html#voters-for-tc-seats-atc The easy measure of whether someone is an ATC is the first rule listed there: Individual Members who committed a change to a repository under ‘’any’’ of the official OpenStack Project Teams (as defined above) over the last two 6-month release cycles are automatically considered ATC. That's the rule most of us remember, and think of when we think of ATC, but not everyone who does that is a developer and landing a patch is not the only way to become an ATC, as the next sentence shows: Specific contributors who did not have a change recently accepted in one of the OpenStack projects but nevertheless feel their contribution to the OpenStack project is technical in nature (bug triagers, technical documentation writers...) can exceptionally apply for ATC either by sending an email to the TC chair or by being nominated by an existing ATC via email to the TC chair. We have a not-very-long list of folks who have that status in http://git.openstack.org/cgit/openstack/governance/tree/reference/extra-atcs Is it be feasible to start allowing the operator community to also cast votes for TC candidates? Is the TC *only* addressing technical concerns that are relevant to the development community? Since the TC candidates are embracing the idea of representing more than just the developer community, it would /seem/ the voters electing the TC members should include the communities being represented. If the TC only addresses developer concerns, it would seem they become at risk of losing touch with the operator/architecture/user concerns because the operator community voice is never heard in the voting booth. The TC represents the contributors to the project. That term can be defined very broadly, as explained above, but I don't think we want it to be completely open-ended because the issues the TC tries to resolve *are* from the contributors' perspectives, and not every user or deployer's perspective. That's not to say those groups don't have valid concerns, or that the TC would ignore them, just that the TC is not specifically organized to represent them. I would rather we explore more ways to identify people we consider to be contributors than to change the existing voting rules to allow more people. I think it will amount to the same change in the electorate, and I like the idea of adding more contributors to the project more than just adding more voters. :-) Doug Perhaps this bumps into how it used to be versus how it should be. I don't know. Just struck me as incongruent with the platform of almost every candidate - broadening representation while the current rules prohibit that level of co-participation. Thoughts? *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 __ OpenStack Development Mailing List (not for 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] A big tent home for Neutron backend code
On Wed, Apr 22, 2015 at 12:30 PM, Kyle Mestery mest...@mestery.com wrote: On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant rbry...@redhat.com wrote: Hello! A couple of things I've been working on lately are project governance issues as a TC member and also implementation of a new virtual networking alternative with a Neutron driver. So, naturally I started thinking about how the Neutron driver code fits in to OpenStack governance. Thanks for starting this conversation Russell. There are basically two areas with a lot of movement related to this issue. 1) Project governance has moved to a big tent model [1]. The vast majority of projects that used to be in Stackforge are being folded in I think the phrase 'vast majority' is misleading, there are still a lot of projects on stackforge. to a larger definition of the OpenStack project. Projects making this move meet the following criteria as being one of us: http://governance.openstack.org/reference/new-projects-requirements.html Official project teams are tracked in this file along with the git repos they are responsible for: http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml which is also reflected here: http://governance.openstack.org/reference/projects/ The TC has also been working through defining a system to help differentiate efforts by using a set of tags [4]. So far, we have tags describing the release handling for a repository, as well as a tag for team diversity. We've also had a lot of discussion about tags to help describe maturity, but that is still a work in progress. 2) In Neutron, some fairly significant good changes are being made to help scale the development process. Advanced services were split out into their own repos [2]. Most of the plugin and driver code has also been split out into repos [3]. In terms of project teams, the Neutron team is defined as owning the following repos: http://governance.openstack.org/reference/projects/neutron.html - openstack/neutron - openstack/neutron-fwaas - openstack/neutron-lbaas - openstack/neutron-vpnaas - openstack/neutron-specs - openstack/python-neutronclient The advanced services split is reflected by the fwaas, lbaas, and vpnaas repos. We also have a large set of repositories related to Neutron backend code: http://git.openstack.org/cgit/?q=stackforge%2Fnetworking - stackforge/networking-arista - stackforge/networking-bagpipe-l2 - stackforge/networking-bgpvpn - stackforge/networking-bigswitch - stackforge/networking-brocade - stackforge/networking-cisco - stackforge/networking-edge-vpn - stackforge/networking-hyperv - stackforge/networking-ibm - stackforge/networking-l2gw - stackforge/networking-midonet - stackforge/networking-mlnx - stackforge/networking-nec - stackforge/networking-odl - stackforge/networking-ofagent - stackforge/networking-ovn - stackforge/networking-ovs-dpdk - stackforge/networking-plumgrid - stackforge/networking-portforwarding - stackforge/networking-vsphere Note that not all of these are equivalent. This is just a list of stackforge/networking-*. In some cases there is a split between code in the Neutron tree and in this repo. In those cases, a shim is in the Neutron tree, but most of the code is in the external repo. It's also possible to have all of the code in the external repo. There's also a big range of maturity. Some are quite mature and are already used in production. networking-ovn as an example is quite new and being developed in parallel with OVN in the Open vSwitch project. So, my question is: Where should these repositories live in terms of OpenStack governance and project teams? Here are a few paths I think we could take, along with some of my initial thoughts on pros/cons. a) Adopt these as repositories under the Neutron project team. In this case, I would see them operating with their own review teams as they do today to avoid imposing additional load on the neutron-core or neutron-specs-core teams. However, by being a part of the Neutron team, the backend team would submit to oversight by the Neutron PTL. Out of your options proposed, this seems like the most logical one to me. I don't really see this imposing a ton of strain on the existing core reviewer team, because we'll keep whatever core reviewer teams are already in the networking-foo projects. There are some other details to work out to ensure expectations are clearly set for everyone involved. If this is the path that makes sense, we can work through those as a next step. Pros: + Seems to be the most natural first choice Saying something is your first choice isn't a real benefit. It is implying some sort of benefit but I cannot define what the benefit actually is. Cons: - A lot of changes have been made precisely because Neutron has gotten so big. A single project team/PTL may not be able
Re: [openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
Yes. Installed version is 1.4.0 and from that log it seems that it was caused by congress scripts sudo pip install -U -r /opt/stack/new/congress/thirdparty-requirements.txt Filip On 04/29/2015 03:56 PM, Serg Melikyan wrote: Sean, Filip, Exact versions of installed libraries may be found here: http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/pip-freeze.txt.gz stevedore==1.4.0 On Wed, Apr 29, 2015 at 4:38 PM, Filip Blaha filip.bl...@hp.com wrote: sorry I sent wrong link http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz In this log is : Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 Filip On 04/29/2015 03:21 PM, Sean Dague wrote: I just looked at this run (linked in this message) - http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz stevedore==1.3.0 is installed, never 1.4 The failure is completely unrelated to anything there - http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz#_2015-04-12_14_06_25_237 On 04/29/2015 09:12 AM, Serg Melikyan wrote: Hi Filip, In thirdparty-requirements for stable/kilo python-muranoclient should have following version: python-muranoclient=0.5.6,0.6.0. But I am not sure that this will fix the issue, since we don't clearly know why stevedore==1.4.0 is installed. I see that python-keystoneclient does not have cap for stevedore in stable/kilo, but still not 100% that it is a reason why 1.4.0 is installed. [1] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 On Wed, Apr 29, 2015 at 3:46 PM, Filip Blaha filip.bl...@hp.com mailto:filip.bl...@hp.com wrote: Hello We are facing an issue with Congress devstack installation in our gate job testing murano-congress integration (policy enforcement) [1] . Congress devstack scripts install stevedore==1.4.0 as a dependency of python-muranoclient without specified version [2]. However heat requirement in stable/kilo is stevedore=1.3.0,1.4.0 so heat engine is unable to start. Is possible to fix by specifying murano client version not to be in confilct with heat requirements? [1] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/murano.yaml#L42 [2] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz [3] https://github.com/openstack/heat/blob/stable/kilo/requirements.txt#L47 Filip __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
On 04/29/2015 09:29 AM, Filip Blaha wrote: Hi Serg I checked devstack log [1] and it seems that stevedore==1.4.0 was installed due to congress 2015-04-29 11:12:16.120 http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_16_120| Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 It is last entry in log mentioning installation stevedore [1] http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz Not, it was installed due to keystonemiddleware - http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_02_13_727 Filip On 04/29/2015 03:12 PM, Serg Melikyan wrote: Hi Filip, In thirdparty-requirements for stable/kilo python-muranoclient should have following version: python-muranoclient=0.5.6,0.6.0. But I am not sure that this will fix the issue, since we don't clearly know why stevedore==1.4.0 is installed. I see that python-keystoneclient does not have cap for stevedore in stable/kilo, but still not 100% that it is a reason why 1.4.0 is installed. [1] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 On Wed, Apr 29, 2015 at 3:46 PM, Filip Blaha filip.bl...@hp.com mailto:filip.bl...@hp.com wrote: Hello We are facing an issue with Congress devstack installation in our gate job testing murano-congress integration (policy enforcement) [1] . Congress devstack scripts install stevedore==1.4.0 as a dependency of python-muranoclient without specified version [2]. However heat requirement in stable/kilo is stevedore=1.3.0,1.4.0 so heat engine is unable to start. Is possible to fix by specifying murano client version not to be in confilct with heat requirements? [1] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/murano.yaml#L42 [2] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz [3] https://github.com/openstack/heat/blob/stable/kilo/requirements.txt#L47 Filip __ 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 -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
Serg, The congress stable/kilo requirements: http://git.openstack.org/cgit/openstack/congress/tree/requirements.txt?h=stable/kilo#n13 Do not match the global stable/kilo requirements: http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt?h=stable/kilo#n123 So let's get that fixed first. It may help unblock gate-murano-congress-devstack-dsvm stable/kilo job. -- dims On Wed, Apr 29, 2015 at 9:56 AM, Serg Melikyan smelik...@mirantis.com wrote: Sean, Filip, Exact versions of installed libraries may be found here: http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/pip-freeze.txt.gz stevedore==1.4.0 On Wed, Apr 29, 2015 at 4:38 PM, Filip Blaha filip.bl...@hp.com wrote: sorry I sent wrong link http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz In this log is : Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 Filip On 04/29/2015 03:21 PM, Sean Dague wrote: I just looked at this run (linked in this message) - http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz stevedore==1.3.0 is installed, never 1.4 The failure is completely unrelated to anything there - http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz#_2015-04-12_14_06_25_237 On 04/29/2015 09:12 AM, Serg Melikyan wrote: Hi Filip, In thirdparty-requirements for stable/kilo python-muranoclient should have following version: python-muranoclient=0.5.6,0.6.0. But I am not sure that this will fix the issue, since we don't clearly know why stevedore==1.4.0 is installed. I see that python-keystoneclient does not have cap for stevedore in stable/kilo, but still not 100% that it is a reason why 1.4.0 is installed. [1] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 On Wed, Apr 29, 2015 at 3:46 PM, Filip Blaha filip.bl...@hp.com mailto:filip.bl...@hp.com wrote: Hello We are facing an issue with Congress devstack installation in our gate job testing murano-congress integration (policy enforcement) [1] . Congress devstack scripts install stevedore==1.4.0 as a dependency of python-muranoclient without specified version [2]. However heat requirement in stable/kilo is stevedore=1.3.0,1.4.0 so heat engine is unable to start. Is possible to fix by specifying murano client version not to be in confilct with heat requirements? [1] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/murano.yaml#L42 [2] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz [3] https://github.com/openstack/heat/blob/stable/kilo/requirements.txt#L47 Filip __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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] [Congress] [Murano] Congress devstack installation is failing in murano gate job
I just looked at this run (linked in this message) - http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz stevedore==1.3.0 is installed, never 1.4 The failure is completely unrelated to anything there - http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz#_2015-04-12_14_06_25_237 On 04/29/2015 09:12 AM, Serg Melikyan wrote: Hi Filip, In thirdparty-requirements for stable/kilo python-muranoclient should have following version: python-muranoclient=0.5.6,0.6.0. But I am not sure that this will fix the issue, since we don't clearly know why stevedore==1.4.0 is installed. I see that python-keystoneclient does not have cap for stevedore in stable/kilo, but still not 100% that it is a reason why 1.4.0 is installed. [1] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 On Wed, Apr 29, 2015 at 3:46 PM, Filip Blaha filip.bl...@hp.com mailto:filip.bl...@hp.com wrote: Hello We are facing an issue with Congress devstack installation in our gate job testing murano-congress integration (policy enforcement) [1] . Congress devstack scripts install stevedore==1.4.0 as a dependency of python-muranoclient without specified version [2]. However heat requirement in stable/kilo is stevedore=1.3.0,1.4.0 so heat engine is unable to start. Is possible to fix by specifying murano client version not to be in confilct with heat requirements? [1] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/murano.yaml#L42 [2] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz [3] https://github.com/openstack/heat/blob/stable/kilo/requirements.txt#L47 Filip __ 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 -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
Hi Serg I checked devstack log [1] and it seems that stevedore==1.4.0 was installed due to congress 2015-04-29 11:12:16.120 http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_16_120| Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 It is last entry in log mentioning installation stevedore [1] http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz Filip On 04/29/2015 03:12 PM, Serg Melikyan wrote: Hi Filip, In thirdparty-requirements for stable/kilo python-muranoclient should have following version: python-muranoclient=0.5.6,0.6.0. But I am not sure that this will fix the issue, since we don't clearly know why stevedore==1.4.0 is installed. I see that python-keystoneclient does not have cap for stevedore in stable/kilo, but still not 100% that it is a reason why 1.4.0 is installed. [1] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 On Wed, Apr 29, 2015 at 3:46 PM, Filip Blaha filip.bl...@hp.com mailto:filip.bl...@hp.com wrote: Hello We are facing an issue with Congress devstack installation in our gate job testing murano-congress integration (policy enforcement) [1] . Congress devstack scripts install stevedore==1.4.0 as a dependency of python-muranoclient without specified version [2]. However heat requirement in stable/kilo is stevedore=1.3.0,1.4.0 so heat engine is unable to start. Is possible to fix by specifying murano client version not to be in confilct with heat requirements? [1] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/murano.yaml#L42 [2] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz [3] https://github.com/openstack/heat/blob/stable/kilo/requirements.txt#L47 Filip __ 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
Re: [openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
sorry I sent wrong link http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz In this log is : Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 Filip On 04/29/2015 03:21 PM, Sean Dague wrote: I just looked at this run (linked in this message) - http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz stevedore==1.3.0 is installed, never 1.4 The failure is completely unrelated to anything there - http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz#_2015-04-12_14_06_25_237 On 04/29/2015 09:12 AM, Serg Melikyan wrote: Hi Filip, In thirdparty-requirements for stable/kilo python-muranoclient should have following version: python-muranoclient=0.5.6,0.6.0. But I am not sure that this will fix the issue, since we don't clearly know why stevedore==1.4.0 is installed. I see that python-keystoneclient does not have cap for stevedore in stable/kilo, but still not 100% that it is a reason why 1.4.0 is installed. [1] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 On Wed, Apr 29, 2015 at 3:46 PM, Filip Blaha filip.bl...@hp.com mailto:filip.bl...@hp.com wrote: Hello We are facing an issue with Congress devstack installation in our gate job testing murano-congress integration (policy enforcement) [1] . Congress devstack scripts install stevedore==1.4.0 as a dependency of python-muranoclient without specified version [2]. However heat requirement in stable/kilo is stevedore=1.3.0,1.4.0 so heat engine is unable to start. Is possible to fix by specifying murano client version not to be in confilct with heat requirements? [1] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/murano.yaml#L42 [2] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz [3] https://github.com/openstack/heat/blob/stable/kilo/requirements.txt#L47 Filip __ 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
Re: [openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
Sean, Filip, Exact versions of installed libraries may be found here: http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/pip-freeze.txt.gz stevedore==1.4.0 On Wed, Apr 29, 2015 at 4:38 PM, Filip Blaha filip.bl...@hp.com wrote: sorry I sent wrong link http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz In this log is : Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 Filip On 04/29/2015 03:21 PM, Sean Dague wrote: I just looked at this run (linked in this message) - http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz stevedore==1.3.0 is installed, never 1.4 The failure is completely unrelated to anything there - http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz#_2015-04-12_14_06_25_237 On 04/29/2015 09:12 AM, Serg Melikyan wrote: Hi Filip, In thirdparty-requirements for stable/kilo python-muranoclient should have following version: python-muranoclient=0.5.6,0.6.0. But I am not sure that this will fix the issue, since we don't clearly know why stevedore==1.4.0 is installed. I see that python-keystoneclient does not have cap for stevedore in stable/kilo, but still not 100% that it is a reason why 1.4.0 is installed. [1] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 On Wed, Apr 29, 2015 at 3:46 PM, Filip Blaha filip.bl...@hp.com mailto:filip.bl...@hp.com wrote: Hello We are facing an issue with Congress devstack installation in our gate job testing murano-congress integration (policy enforcement) [1] . Congress devstack scripts install stevedore==1.4.0 as a dependency of python-muranoclient without specified version [2]. However heat requirement in stable/kilo is stevedore=1.3.0,1.4.0 so heat engine is unable to start. Is possible to fix by specifying murano client version not to be in confilct with heat requirements? [1] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/murano.yaml#L42 [2] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz [3] https://github.com/openstack/heat/blob/stable/kilo/requirements.txt#L47 Filip __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
On 04/29/2015 10:05 AM, Sean Dague wrote: On 04/29/2015 09:29 AM, Filip Blaha wrote: Hi Serg I checked devstack log [1] and it seems that stevedore==1.4.0 was installed due to congress 2015-04-29 11:12:16.120 http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_16_120| Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 It is last entry in log mentioning installation stevedore [1] http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz Not, it was installed due to keystonemiddleware - http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_02_13_727 Actually, it's more insideous than this. It's installed at 1.4.0 there, then it's downgraded to 1.3.0 when glance is installed, and then it's pushed back to 1.4.0 because of: http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_08_418 pip install -U should not be used in the general case, only in *very* specific cases. Whatever is hardcoding -U is the source of your problem. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Question for the TC candidates
Excerpts from Maish Saidel-Keesing's message of 2015-04-29 12:59:35 +0300: Again my apologies for the incorrect format - since I am still not receiving the messages from this thread. Please see my comments with the abstracts within (unfortunately not necessarily in the correct order) I think that the point here was that Doug mentioned that there was communication / I believe all of the posts were on the main OpenStack foundation blog // under the technical committee tag [1], and they also went to // planet.openstack.org for folks who subscribe to the entire community // feed. // / Doug - evidently this is not working as it should. As Chris said as well - the posts are not tagged and are not regular. The lack of tags is an oversight, and should be easy to correct. Regarding this /For outgoing communication, during Kilo (and possibly Juno) we tried //blogging meeting summaries. Did folks notice? Were the posts useful?/ They were not noticed - because they didn't really happen. I don't think that's a fair characterization of the effort put into writing the posts. If you didn't see them because they didn't go to the right channel, that's one thing. If you didn't see them because there weren't enough of them, then I think we have different goals. I'm not sure it's as useful to publish on a schedule as it is to publish at meaningful milestones. If we take this week's meeting [1] as an example, we made some clarifications to existing rules for teams that want to join as official OpenStack projects [2]; we tweaked the description of the Congress project [3] to try to convey what it is for; we approved 5 repos as part of existing projects [4][5][6][7][8]; we updated the PTLs for projects [9]; and then we discussed the cross-project track at the summit. It's not clear those things warrant blog posts. Maybe they do, but aside from the summit planning, and possibly the meeting rule clarification, the others seem trivial enough that they would be noise in a channel we should preserve for communicating more important changes. I honestly don't know. If I was going to write a blog post about that meeting, which topics would you want me to have included? [1] http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-04-28-20.02.log.html [2] https://review.openstack.org/175427 [3] https://review.openstack.org/169480 [4] https://review.openstack.org/175620 [5] https://review.openstack.org/172802 [6] https://review.openstack.org/175610 [7] https://review.openstack.org/177070 [8] https://review.openstack.org/176338 [9] https://review.openstack.org/175007 Excerpts from Chris Dent's message of 2015-04-27 17:32:12 +0100: / The only way I've been able to get any sense of what the TC might be // up to is by watching the governance project on gerrit and that tends // to be too soon and insufficiently summarized and thus a fair bit of // work to separate the details from the destinations./ If the audience that you are planning on communicating with is: not the developers themselves and those who are already heavily involved in the community - I think this certainly is not the place to publicize changes. Do you seriously expect people who are trying to find information (not as a regular code contributor) about what is going on to start delving through Gerrit? We have two audiences. The contributors who elect us, and the broader community of deployers, users, etc. I think all of us do what we can individually to engage with that broader community, through meetups, our own blogs, and other channels. I don't expect them to use or read gerrit, or even necessarily subscribe to this list. On the other hand, the developer electorate is quite capable of subscribing to notices about changes happening in the governance repository and it does seem reasonable that if they really want to watch the minutia of TC's deliberations that they *would* take advantage of that capability. That's not to say it should be the only way we communicate, just that the option is there for those interested in using it. Not going to happen. Does this mean that the TC has to change the way they make decisions? The TC should do what what they find works for them. But they also need to take into consideration that there are others who are interested in the information - but have no idea how to access it. We need make this more accessible - to those who are not like us. Yes, I don't think anyone is arguing against that point. The question remains, though: How? Is a blog post a useful medium, or should we be doing something else? Excerpts from Jeremy Stanley's message of 2015-04-28 16:21:17 +: / On 2015-04-28 16:30:21 +0100 (+0100), Chris Dent wrote: // [...] // What's important to avoid is the blog postings being only reporting of // conclusions. They also need to be invitations to participate in the // discussions. Yes, the mailing list, gerrit and meeting logs
Re: [openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
On 04/29/2015 10:17 AM, Brant Knudson wrote: On Wed, Apr 29, 2015 at 9:11 AM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: On 04/29/2015 10:05 AM, Sean Dague wrote: On 04/29/2015 09:29 AM, Filip Blaha wrote: Hi Serg I checked devstack log [1] and it seems that stevedore==1.4.0 was installed due to congress 2015-04-29 11:12:16.120 http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_16_120| Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 It is last entry in log mentioning installation stevedore [1] http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz Not, it was installed due to keystonemiddleware - http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_02_13_727 Actually, it's more insideous than this. It's installed at 1.4.0 there, then it's downgraded to 1.3.0 when glance is installed, and then it's pushed back to 1.4.0 because of: http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_08_418 pip install -U should not be used in the general case, only in *very* specific cases. Whatever is hardcoding -U is the source of your problem. -Sean -- Sean Dague http://dague.net There's a review posted to update keystonemiddleware's requirements: https://review.openstack.org/#/c/173972/ . It was broken for a while after the branch was created due to pycadf installing oslo.messaging. For some reason it's working now even without the pycadf changes, but Doug H has a -2 on it. I'd like to know what the reqs are supposed to be for all the stable/kilo libraries -- I assumed we wanted them all to match global-requirements. I think all of our tox.ini's have -U: http://git.openstack.org/cgit/openstack/nova/tree/tox.ini#n6 tox is different then system level install -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Question for the TC candidates
Thank you for your honest and forthright reply, Chris. I shall respond inline. On 04/28/2015 02:11 PM, Chris Dent wrote: On Tue, 28 Apr 2015, Anita Kuno wrote: At present, I am beginning to wonder to what degree you are being honest with us? Is you intention to know the candidates or to communicate your dissatisfaction with the current blog post situation? You'll note that I didn't have anything to say about the blog situation until this week, after the emails with voting links were already out (I've already voted). That's on purpose. I didn't want to cloud my genuine desire to know the candidates with other issues nor distract this thread for its original purpose until everyone who wanted to had a chance to have their say. There's been another issue (about downstream) that I've not responded to because of exactly this. Thank you for holding your actions true to your original intent, Chris, I appreciate that. One of the issues affecting elections is that our electorate is growing so quickly, fewer people in the electorate feel involved. I appreciate that you withheld your commentary until after you had voted, however voting is still open. I wouldn't have joined the commentary on the blogging issue if there hadn't already been a fair bit of talk about how fixing the feedback loop was one of the roads to improving. Also, critically, when Doug (who I can see is just trying to point out the current picture of reality so I'm not criticizing him, in fact I'd like to laud his efforts in pursuit of write it down which he has mentioned many times) pointed out the existing situation there were, effectively, bugs: * disconnected taxonomy in the presentation of the blogs * misconceptions about the frequency of postings If we can clear up those preconceptions then we can find the stable state from which improvements can be made. I too would like to laud Doug in his efforts to clarify and improve the situation. However I wonder if perhaps the conversation could have taken place in its own thread where others, who possibly didn't want to be seen as weighing in on the candidate's statements thread had thoughts to share on this topic? It is true that I have dissatisfaction about the visibility of the TC and I think a lot of the candidates have made it clear that they are concerned with that issue too. That's great! I am glad that you are feeling your concerns are being addressed. It is detrimental to our overall electoral process if folks cloak personal points of disagreement in the guise of open discussion. I would think that disagreements are in fact exactly the reason for having open discussion and such discussion is one of the best ways to know where people stand. I didn't, however, have that in mind when I responded to clarify things with Doug. Clarifying disagreements and working towards consensus in a respectful way are indeed the purpose of having open discussion. My point is that if our approach to learning about the candidates becomes a platform for folks with personal points of grievance to come to the fore that actually undermines the open discussion process. Apparently my efforts to be lighthearted about that didn't quite play as I planned, and for that I apologize. Thank you, Chris. As I was looking for blog postings I found so _few_ that I assumed any statements of there's 3 here and 4 over there[1] (covering the last greater than a year) were similarly lighthearted. I guess my expectations are way off? I do encourage people who feel that they are unable to understand or access the TC and its activities in a meaningful way to communicate their needs so that the current TC can address those needs. Should there be an attempt to do so and the attempt is dismissed or ignored then it is fair game for a new field of candidates to weigh in. I do continue to hope that candidate statements and responses are helpful to the electorate and that they cast their ballot without feeling that doing so is an indication about their feelings regarding a secondary issue. I can't let this go without making yet another comment. I feel like I should just leave it alone because apparently I'm in deep water You aren't in deep water. I asked if you were being honest. You are indicating in both word choice and tone that you are, I appreciate and respect that, thank you. but: In what fashion is the effectiveness of TC communication a secondary issue? It is difficult for the current field of 19 candidates to discuss TC communication effectively as less than 25% of current candidates had any ability to influence the current situation. Sure if you like we can all say I'll do better but that is not nearly as effective as bringing up the issue with the folks whose decisions created the situation in the first place. I propose that in future should such issues arise that they move to their own thread so that all concerned with that issue feel free to
Re: [openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
Hi Sean! This package installed due keystonemiddleware just first time. It was uninstalled later [1] And installed again [2] [1] http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_04_07_855 [2] http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_12_603 2015-04-29 17:06 GMT+03:00 Filip Blaha filip.bl...@hp.com: Yes. Installed version is 1.4.0 and from that log it seems that it was caused by congress scripts sudo pip install -U -r /opt/stack/new/congress/thirdparty-requirements.txt Filip On 04/29/2015 03:56 PM, Serg Melikyan wrote: Sean, Filip, Exact versions of installed libraries may be found here:http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/pip-freeze.txt.gz stevedore==1.4.0 On Wed, Apr 29, 2015 at 4:38 PM, Filip Blaha filip.bl...@hp.com filip.bl...@hp.com wrote: sorry I sent wrong link http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz In this log is : Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 Filip On 04/29/2015 03:21 PM, Sean Dague wrote: I just looked at this run (linked in this message) -http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz stevedore==1.3.0 is installed, never 1.4 The failure is completely unrelated to anything there -http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz#_2015-04-12_14_06_25_237 On 04/29/2015 09:12 AM, Serg Melikyan wrote: Hi Filip, In thirdparty-requirements for stable/kilo python-muranoclient should have following version: python-muranoclient=0.5.6,0.6.0. But I am not sure that this will fix the issue, since we don't clearly know why stevedore==1.4.0 is installed. I see that python-keystoneclient does not have cap for stevedore in stable/kilo, but still not 100% that it is a reason why 1.4.0 is installed. [1]https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 On Wed, Apr 29, 2015 at 3:46 PM, Filip Blaha filip.bl...@hp.commailto:filip.bl...@hp.com filip.bl...@hp.com wrote: Hello We are facing an issue with Congress devstack installation in our gate job testing murano-congress integration (policy enforcement) [1] . Congress devstack scripts install stevedore==1.4.0 as a dependency of python-muranoclient without specified version [2]. However heat requirement in stable/kilo is stevedore=1.3.0,1.4.0 so heat engine is unable to start. Is possible to fix by specifying murano client version not to be in confilct with heat requirements? [1] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/murano.yaml#L42 [2] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz [3] https://github.com/openstack/heat/blob/stable/kilo/requirements.txt#L47 Filip __ 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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
On Wed, Apr 29, 2015 at 9:11 AM, Sean Dague s...@dague.net wrote: On 04/29/2015 10:05 AM, Sean Dague wrote: On 04/29/2015 09:29 AM, Filip Blaha wrote: Hi Serg I checked devstack log [1] and it seems that stevedore==1.4.0 was installed due to congress 2015-04-29 11:12:16.120 http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_16_120 | Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 It is last entry in log mentioning installation stevedore [1] http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz Not, it was installed due to keystonemiddleware - http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_02_13_727 Actually, it's more insideous than this. It's installed at 1.4.0 there, then it's downgraded to 1.3.0 when glance is installed, and then it's pushed back to 1.4.0 because of: http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_08_418 pip install -U should not be used in the general case, only in *very* specific cases. Whatever is hardcoding -U is the source of your problem. -Sean -- Sean Dague http://dague.net There's a review posted to update keystonemiddleware's requirements: https://review.openstack.org/#/c/173972/ . It was broken for a while after the branch was created due to pycadf installing oslo.messaging. For some reason it's working now even without the pycadf changes, but Doug H has a -2 on it. I'd like to know what the reqs are supposed to be for all the stable/kilo libraries -- I assumed we wanted them all to match global-requirements. I think all of our tox.ini's have -U: http://git.openstack.org/cgit/openstack/nova/tree/tox.ini#n6 - Brant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Congress] [Murano] Congress devstack installation is failing in murano gate job
Sean, yes. It is installed multiple times but the last is congress which installs 1.4.0. When devstack installed without congress there is no such issue and heat works Filip On 04/29/2015 04:11 PM, Sean Dague wrote: On 04/29/2015 10:05 AM, Sean Dague wrote: On 04/29/2015 09:29 AM, Filip Blaha wrote: Hi Serg I checked devstack log [1] and it seems that stevedore==1.4.0 was installed due to congress 2015-04-29 11:12:16.120 http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_16_120| Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 It is last entry in log mentioning installation stevedore [1] http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz Not, it was installed due to keystonemiddleware - http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_02_13_727 Actually, it's more insideous than this. It's installed at 1.4.0 there, then it's downgraded to 1.3.0 when glance is installed, and then it's pushed back to 1.4.0 because of: http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_08_418 pip install -U should not be used in the general case, only in *very* specific cases. Whatever is hardcoding -U is the source of your problem. -Sean __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [docs] Scheduler filters documentation
On 04/29/2015 03:41 PM, Ed Leafe wrote: On Apr 29, 2015, at 2:30 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: I'd prefer to see the scheduler filter docs be maintained in the nova devref where they are close to the source, versioned, and reviewed by the nova team when there are scheduler filter changes or new filters added. For now, I think this is best. When and if the scheduler is a separate entity, it will need its own docs; nova will still need to document *its* filters, but not *how to* filter. So, the config-ref docs are auto-generated continually via automation scripts from the help text of options. And, IMO, this is A Good Thing. In this case, the end user of this information is the cloud admin -- the person who creates flavors and tags compute nodes with capability extra specs. The target audience for this information is not really the Nova developer. Now, if there are sections of the devref that need to inform the *developer* about some weird intricacies of the scheduler filters (and frankly, this is kind of one of them), then I think it's OK to have slightly duplicate information. It depends on the target audience. In this particular case, I think it's fine to duplicate a little. Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
On 2015-04-29 16:46:13 -0700 (-0700), Joe Gordon wrote: On Wed, Apr 22, 2015 at 12:30 PM, Kyle Mestery mest...@mestery.com wrote: On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant rbry...@redhat.com [...] 1) Project governance has moved to a big tent model [1]. The vast majority of projects that used to be in Stackforge are being folded in I think the phrase 'vast majority' is misleading, there are still a lot of projects on stackforge. [...] Even the word majority is incorrect, at least for the moment. Ignoring openstack-attic and stackforge-attic, of the 627 non-retired git repositories hosted in our infrastructure, 55% are stackforge and 45% are openstack.*. ssh -p 29418 review.openstack.org gerrit ls-projects \ |cut -d/ -f1|sort|uniq -c The majority (by any sense of the word) are currently still squarely stackforge. Once all the chef cookbooks and puppet modules switch then the percentages there invert, but I have to agree with Joe that it's by no means vast even then. If all the fuel repos also move then that brings us to a 60/40 split in favor of openstack. Maybe that starts to count as vast? Regardless, the stackforge/networking-.* repos only make up 3% of the total count. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] [cross-project] Any Openstack partitioning movements in this summit?
Hi, Nova cell has emerged for several release cycles, with the mission of scalability. Now there are claims of Neutron cell. Maybe similar Cinder/Ceilometer partition demands would appear in the future. So I wander if cross-project Openstack partitioning would go into the our sight in the near term, with the following topics for example: a) Any other value for partitioning besides scalability? e.g. fault domain isolation, heterogeneous integration... b) Which projects need partitioning besides Nova? Cidner/Neutron/Ceilometer/Glance/Keystone? c) Standalone partition design and deploy for each project, or some collaboration is need across them? e.g. Can a host belong to one Nova partition and another Cinder partition? d) Concept clarifying and instructions on different partition granularity, e.g. Cell, Available Zone, Aggregator... e) Interface choice between parent and child partitions, internal RPC or external REST, or some other protocols? Best Regards __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
On Thu, Apr 30, 2015 at 2:44 AM, Russell Bryant rbry...@redhat.com wrote: On 04/29/2015 01:25 PM, Doug Wiegley wrote: My take on the “where does it fit” yardstick: Does it stand on its own and add value? Then consider it a standalone project, *or* part of neutron if you and neutron agree that it fits. Does it *require* neutron to be useful? Then consider having it under the neutron umbrella/stadium/tent/yurt. ...arena/coliseum/dome... That's a nice summary. Thanks. :-) -- Russell Bryant By this definition, nearly all standalone SDN controller would not be classified as neutron tent (including OVN by its design doc), because they are not born for neutron at all. It seems that the only exception is ofagent. While most hardware MD can be treated as under neutron tent, for they just do one thing: driver hardware on behalf on neutron. __ OpenStack Development Mailing List (not for 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] [cross-project] Any Openstack partitioning movements in this summit?
Hi Ioy, Sounds like an interesting topic, especially for the item c) :) Look forward to this discussion at the summit On Thu, Apr 30, 2015 at 9:32 AM, loy wolfe loywo...@gmail.com wrote: Hi, Nova cell has emerged for several release cycles, with the mission of scalability. Now there are claims of Neutron cell. Maybe similar Cinder/Ceilometer partition demands would appear in the future. So I wander if cross-project Openstack partitioning would go into the our sight in the near term, with the following topics for example: a) Any other value for partitioning besides scalability? e.g. fault domain isolation, heterogeneous integration... b) Which projects need partitioning besides Nova? Cidner/Neutron/Ceilometer/Glance/Keystone? c) Standalone partition design and deploy for each project, or some collaboration is need across them? e.g. Can a host belong to one Nova partition and another Cinder partition? d) Concept clarifying and instructions on different partition granularity, e.g. Cell, Available Zone, Aggregator... e) Interface choice between parent and child partitions, internal RPC or external REST, or some other protocols? Best Regards __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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] [QA] Meeting Thursday April 30th at 22:00 UTC
Hi everyone, Just a quick reminder that the weekly OpenStack QA team IRC meeting will be tomorrow Thursday, April 16th at 22:00 UTC in the #openstack-meeting channel. The agenda for tomorrow's meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Anyone is welcome to add an item to the agenda. To help people figure out what time 22:00 UTC is in other timezones tomorrow's meeting will be at: 18:00 EDT 07:00 JST 07:30 ACST 00:00 CEST 17:00 CDT 15:00 PDT -Matt Treinish pgp6E7p2DSl0X.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] [Nova] [Cinder] [tc] Should Openstack project maintained by core team keep only API/DB in the future?
On Wed, Apr 29, 2015 at 12:34 PM, Fox, Kevin M kevin@pnnl.gov wrote: Yes, ml2 was created since each of the drivers used to be required to do everything themselves and it was decided it would be far better for everyone to share the common bits. Thats what ml2s about. Its not about implementing an sdn +1. I totally agree that we should keep the common bits like ML2, however this is not the same as what the reference implementation splitting spec suggested. The intention of spec is no common implementation bits any more, leaving only API/DB. Thanks, Kevin From: loy wolfe Sent: Tuesday, April 28, 2015 6:16:03 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [Nova] [Cinder] [tc] Should Openstack project maintained by core team keep only API/DB in the future? On Wed, Apr 29, 2015 at 2:59 AM, Kevin Benton blak...@gmail.com wrote: The concern is that having broken drivers out there that claim to work with an OpenStack project end up making the project look bad. It's similar to a first time Linux user experiencing frequent kernel panics because they are using hardware with terrible drivers. They aren't going to recognize the distinction and will just assume the project is bad. I think the focal point is not about device driver for the real backend such as OVS/LB or HW TOR, but ML2 vs. external SDN controllers which are also claimed to be backends by some people. Again analogy with Linux, which has socket layer exposing the API, common tcp/ip stack and common netdev skbuff, and each NIC has its own device driver (real backend). While it make sense to discuss whether those backend device driver should be splitted out of tree, there was no consideration that the common middle stacks should be splitted for equal footing with some other external implementations. Things are slimiar with Nova Cinder. we may have all kinds of virt driver and volume driver, but only one common scheduling compute/volume manager implementation. For Neutron it is necessary to support hundreds of real backends, but does it really benefit customers to equal footing the ML2 with a bunch of other external SDN controllers? Best Regards I would love to see OpenStack upstream acting more like a resource to support users and developers I'm not sure what you mean here. The purpose of 3rd party CI requirements is to signal stability to users and to provide feedback to the developers. On Tue, Apr 28, 2015 at 4:18 AM, Luke Gorrie l...@tail-f.com wrote: On 28 April 2015 at 10:14, Duncan Thomas duncan.tho...@gmail.com wrote: If we allow third party CI to fail and wait for vendors to fix their stuff, experience has shown that they won't, and there'll be broken or barely functional drivers out there, and no easy way for the community to exert pressure to fix them up. Can't the user community exert pressure on the driver developers directly by talking to them, or indirectly by not using their drivers? How come OpenStack upstream wants to tell the developers what is needed before the users get a chance to take a look? I would love to see OpenStack upstream acting more like a resource to support users and developers (e.g. providing 3rd party CI hooks upon requst) and less like gatekeepers with big sticks to wave at people who don't drop their own priorities and Follow The Process. __ OpenStack Development Mailing 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 Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Infiniband support in Fuel
Hi, At my point we need to fix it 6.1. As during whole lifecycle of 6.1 someone may create own plugin for infiniband. If it's not required now, it may be required later. Extending column in table should not be a big problem. If we drop the feature, the documentation should be updated accordingly. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Wed, Apr 29, 2015 at 5:48 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hello, If all is ok, let's move bug to 7.0 and fix it with netaddr as it was proposed in comments to the ticket. - Igor On Wed, Apr 29, 2015 at 6:29 PM, Nikolay Markov nmar...@mirantis.com wrote: Hi everybody, does anybody besides Mellanox need this? If not and while it's already solved issue for Mellanox itself - let's just close the bug as won't fix for now. On Wed, Apr 29, 2015 at 11:16 AM, Andrey Danin ada...@mirantis.com wrote: Hi, Sylwester, Fuel-plugin-mellanox is in development stage now, so no one can use it. I think, a longer MAC field may be helpful for other plugin developers in future. On Tue, Apr 28, 2015 at 12:50 AM, Sylwester Brzeczkowski sbrzeczkow...@mirantis.com wrote: We have a bug in fuel [1] which concerns infiniband support. It's mostly about expanding the size of mac field in db from 17 to 59. But I've email Aviram Bar-Haim who was working on for infiniband support [2] for fuel-plugin-mellanox [3] and he said that they use eIPoIB mac (mapping between ETH to IB) instead of IB Guid so it fits to our current mac field size. Does anyone have ever used fuel-plugin-mellanox with IB? I'm trying to find out if the bug is still valid? [1] https://bugs.launchpad.net/fuel/+bug/1398882 [2] https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/db/sqlalchemy/models/node.py#L103 [3] https://github.com/stackforge/fuel-plugin-mellanox Regards -- Sylwester Brzeczkowski Junior Python Software Engineer Product Development-Core : Product Engineering __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andrey Danin ada...@mirantis.com skype: gcon.monolake __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [cross-project] Any Openstack partitioning movements in this summit?
Hi, Loy, +100. Really interesting topic. Cascading[1] has holistic thinking on the question list, and one cross project topic is just submitted yesterday: a) Any other value for partitioning besides scalability? e.g. fault domain isolation, heterogeneous integration... Sure, each cascaded OpenStack(Nova,Cinder,Neutron,Ceilometer,Glance..) as one fault domain isolation, and can integrate different back-end ( hypervisor, storage,SDN controller, data-plane... ) in different cascaded OpenStack. b) Which projects need partitioning besides Nova? Cidner/Neutron/Ceilometer/Glance/Keystone? Nova,Cinder,Neutron,Ceilometer need partitioning, Glance is optional, and KeyStone can be shared service or federated service. c) Standalone partition design and deploy for each project, or some collaboration is need across them? e.g. Can a host belong to one Nova partition and another Cinder partition? Collaboration is required across these projects. Just think about the availability zone concept in Cinder and Nova, currently there is no mandatory relationship for the AZ concept between Nova and Cinder. If you deploy Ceph like server-SAN as storage backend, it's rather weird that compute-node in one AZ, but the server-san built upon these nodes in another AZ. They must be coordinated with each other. d) Concept clarifying and instructions on different partition granularity, e.g. Cell, Available Zone, Aggregator... Currently Cells concept only inside Nova. Availability Zone only in Nova and Cinder, Aggregator is a concept only in Nova too. It seems that only Cascading has holistic thinking in the OpenStack as a whole. e) Interface choice between parent and child partitions, internal RPC or external REST, or some other protocols? Cascading using external RESTful API (i.e current OpenStack API), the benefit is to ease maintenance for each partitioning, and different version partitioning integration. == Cross Project Session = I just applied one cross-project session topic to talk about the portioning through OpenStack cascading, the session title is Technical vision for OpenStack to be ubiquitous cloud service. Why I use this title? For I want to introduce the holistic vision and cascading first, then we have a basis to discuss the partitioning. If there is other session to discuss the partitioning, it's also ok. [1]OpenStack cascading: https://wiki.openstack.org/wiki/OpenStack_cascading_solution Best Regards Chaoyi Huang ( Joe Huang ) -Original Message- From: loy wolfe [mailto:loywo...@gmail.com] Sent: Thursday, April 30, 2015 9:33 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [all] [cross-project] Any Openstack partitioning movements in this summit? Hi, Nova cell has emerged for several release cycles, with the mission of scalability. Now there are claims of Neutron cell. Maybe similar Cinder/Ceilometer partition demands would appear in the future. So I wander if cross-project Openstack partitioning would go into the our sight in the near term, with the following topics for example: a) Any other value for partitioning besides scalability? e.g. fault domain isolation, heterogeneous integration... b) Which projects need partitioning besides Nova? Cidner/Neutron/Ceilometer/Glance/Keystone? c) Standalone partition design and deploy for each project, or some collaboration is need across them? e.g. Can a host belong to one Nova partition and another Cinder partition? d) Concept clarifying and instructions on different partition granularity, e.g. Cell, Available Zone, Aggregator... e) Interface choice between parent and child partitions, internal RPC or external REST, or some other protocols? Best Regards __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for 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]Nova can't detach volume in init host routine
Thanks for Lingxian! 2015-04-29 20:31 GMT+08:00 Lingxian Kong anlin.k...@gmail.com: hi, hao, First, thanks for your bug and patch, I thinks it's really a problem we should fix. I forward your suggestions about the workaround with Dan Smith and Joe Gordon.to get more feedback. 1.Raise exception to make to set vm status to error,and user can re-perform a delete action to clean up successfully. 2.Add full set of cinder admin credentials in nova.conf(just like what neutron does with nova) and make sure nova can clean up in init_host On Tue, Apr 28, 2015 at 8:21 PM, hao wang sxmatch1...@gmail.com wrote: Hi, everyone There is a Nova bug: https://bugs.launchpad.net/nova/+bug/1408865. https://review.openstack.org/#/c/147042/ The bug Scenario is: 1. create a vm using bootable volume. 2. delete this vm 3. restart service nova-compute when vm's task state is deleting. When nova-compute is up, vm became deleted successful, but the bootable volume is still in-use state and can't delete it using cinder delete volume. solve method: Add init=True in _delete_instance when init_host, and raise exception when EndpointNotFound exists. It will set vm's status to error and make user can re-issue a delete. Is this method ok? Or cinder could do something to fix this bug? I need your suggestion to push this work forward. Thanks. wanghao -- Best Wishes For You! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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 -- Best Wishes For You! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][L2-Gateway] l2-gateway-connection-create problems
Hi all. I'm interesting in L2 gateway project. For a testing purpose I've installed a devstack in a VirtualBox environment. My objective is to use L2 gateway to connect a virtual machine in openstack with a virtual machine in Virtualbox. I created a virtual gateway with neutron-l2gw l2-gateway-create gw1 --device name='7aec3b21ea4b,interface_names=port1;port2' where 7aec3b21ea4b is the datapath id of br-ex bridge. Then creating a new connection with command neutron-l2gw l2-gateway-connection-create gw1 private --default-segmentation-id=100. I obtained this error: L2 Gateway Device 7aec3b21ea4b could not be found. I tried then many others configuration, without success and with the same error. The problem is that I don't understand what is the correct settings for --device option. Should you explain me what I have to set for device for my case? Thanks -- Daniel Depaoli CREATE-NET Research Center Smart Infrastructures Area Junior Research Engineer __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
