Re: [openstack-dev] [neutron] Changes to the core team
+1 for Doug, he does a great job! Thanks, Oleg On Fri, Jan 16, 2015 at 9:59 AM, Salvatore Orlando sorla...@nicira.com wrote: I agree with the proposed changes. I would also like to take a chance to thank Sumit for the effort he has put in this project over several years - he has been in the core team since the project's inception and has been a witness of all its developments - both the good and the bad ones! Salvatore On 16 January 2015 at 04:38, Henry Gessau ges...@cisco.com wrote: On Thu, Jan 15, 2015, Kyle Mestery mest...@mestery.com wrote: As part of the change, I'd like to propose Doug Wiegley as a new Neutron core reviewer. Doug has been actively reviewing code across not only all the Neutron projects, but also other projects such as infra. His help and work in the services split in December were the reason we were so successful in making that happen. Doug has also been instrumental in the Neutron LBaaS V2 rollout, as well as helping to merge code in the other neutron service repositories. +1 for Doug. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel]When will fuel support centos 7?
So what's the difficulty of supporting centos ? If i want to help to make it happen, do you have some advice? On Thu Jan 15 2015 at 8:33:20 PM Mike Scherbakov mscherba...@mirantis.com wrote: CentOS 7 is not considered as essential / critical priority blueprint for Fuel 6.1. There is a plan to support new version of CentOS, and I know some folks started a research/move in this direction in some areas, such as l23network puppet module for instance. It would be great to see help to make it happen in Fuel 7.0, if not in 6.1. On Thu, Jan 15, 2015 at 3:22 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi, Yes, we do have a plan for CentOS 7, but as far as I know it was postponed to MOS 7.0. That means we will not have Cent OS 7 in upcoming release. - Igor On Thu, Jan 15, 2015 at 1:16 PM, me,apporc appleorchard2...@gmail.com wrote: Hi, Do we have plan for centos 7 ? Regards, apporc __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Changes to the core team
Dear all, +1 for Doug. Thank you, Tina On Jan 16, 2015, at 4:07 PM, Oleg Bondarev obonda...@mirantis.commailto:obonda...@mirantis.com wrote: +1 for Doug, he does a great job! Thanks, Oleg On Fri, Jan 16, 2015 at 9:59 AM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: I agree with the proposed changes. I would also like to take a chance to thank Sumit for the effort he has put in this project over several years - he has been in the core team since the project's inception and has been a witness of all its developments - both the good and the bad ones! Salvatore On 16 January 2015 at 04:38, Henry Gessau ges...@cisco.commailto:ges...@cisco.com wrote: On Thu, Jan 15, 2015, Kyle Mestery mest...@mestery.commailto:mest...@mestery.com wrote: As part of the change, I'd like to propose Doug Wiegley as a new Neutron core reviewer. Doug has been actively reviewing code across not only all the Neutron projects, but also other projects such as infra. His help and work in the services split in December were the reason we were so successful in making that happen. Doug has also been instrumental in the Neutron LBaaS V2 rollout, as well as helping to merge code in the other neutron service repositories. +1 for Doug. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core
+1 On 01/14/2015 07:34 PM, Robert Collins wrote: +1 On 15 Jan 2015 07:15, Clint Byrum cl...@fewbar.com mailto:cl...@fewbar.com wrote: Hello! It has been a while since we expanded our review team. The numbers aren't easy to read with recent dips caused by the summit and holidays. However, I believe James has demonstrated superb review skills and a commitment to the project that shows broad awareness of the project. Below are the results of a meta-review I did, selecting recent reviews by James with comments and a final score. I didn't find any reviews by James that I objected to. https://review.openstack.org/#/c/133554/ -- Took charge and provided valuable feedback. +2 https://review.openstack.org/#/c/114360/ -- Good -1 asking for better commit message and then timely follow-up +1 with positive comments for more improvement. +2 https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec. 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this is only really about 7 - 10 working days and acceptable. +2 https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of recent change with alternatives to the approach submitted as patches. https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in agreement with everyone else. +1 https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with consideration for other reviewers. +2 https://review.openstack.org/#/c/113983/ -- Thorough spec review with grammar pedantry noted as something that would not prevent a positive review score. +2 All current tripleo-core members are invited to vote at this time. Thank you! __ 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] [Fuel] [nailgun] [UI] network_check_status fleild for environments
+1, It will be very helpful to warn user. Not all configurations (which can be set via UI/CLI w/o yaml editing) are supported by network checker. It should be taken into account. And we could recommend to run the check when user-defined configuration is uploaded but warn that given configuration might be not supported by network checker. Agree, this should be done on backend. Aleksey Kasatkin On Thu, Jan 15, 2015 at 10:54 PM, Lukasz Oles lo...@mirantis.com wrote: Big +1, it would save me a lot of debugging time :) On Thu, Jan 15, 2015 at 5:20 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Folks, I want to discuss possibility to add network verification status field for environments. There are 2 reasons for this: 1) One of the most frequent reasons of deployment failure is wrong network configuration. In the current UI network verification is completely optional and sometimes users are even unaware that this feature exists. We can warn the user before the start of deployment if network check failed of wasn't performed. 2) Currently network verification status is partially tracked by status of the last network verification task. Sometimes its results become stale, and the UI removes the task. There are a few cases when the UI does this, like changing network settings, adding a new node, etc (you can grep removeFinishedNetworkTasks to see all the cases). This definitely should be done on backend. What is your opinion on this? -- Vitaly Kramskikh, 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 -- Łukasz Oleś __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] libvirt memory ballooning [nova]
On Fri, Jan 16, 2015 at 10:10:34AM +0530, Vikash Kumar wrote: All, There is blueprint for enabling libvirt memory ballooning https://blueprints.launchpad.net/nova/+spec/libvirt-memory-ballooning in openstack nova. I think for Hyper-V , its already in place. Can we discuss about the design and implementation and target for L release? I think you'll need to write a full spec for this one. The balloon device will open up alot of questions about how it should be used what use cases it will help with its relation to other mechanisms for memory limiting. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] Hands-on documentation
Hi, I've been asked to implement Ironic instead of other PXE deployment engines (Cobbler, Foreman). I have a few questions, though: a - is it production ready? b - is it capable of replacing solutions such as the ones mentioned above? c - is there some more hands-on documentation that would help me install and configure it? Cheers, Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to debug test cases in Openstack
Hi, You have a pdb statement somewhere in your test case. Follow this to run a single test with pdb. https://wiki.openstack.org/wiki/Testr Cheers, Ajaya Cheers, Ajaya On Fri, Jan 16, 2015 at 11:07 AM, Abhishek Talwar/HYD/TCS abhishek.tal...@tcs.com wrote: Hi, I have been trying to debug the test cases in OpenStack, but I am not getting successful with it. So if someone can help me with that. The last response from the dev-list was to use $ ./run_tests.sh -d [test module path] but this gives bDb quit error. So kindly help me this. -- Thanks and Regards Abhishek Talwar =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI
Hi Ramy,
Still couldn't get my custom code to execute between installing devstack
and starting tests... i'll try with some custom scripts and skip devstack-*
scripts.
Meanwhile i see another issue:
2015-01-16 11:02:26,283 DEBUG zuul.IndependentPipelineManager: Finished
queue processor: patch (changed: False)
2015-01-16 11:02:26,283 DEBUG zuul.Scheduler: Run handler sleeping
2015-01-16 11:06:06,873 DEBUG zuul.Gearman: Looking for lost builds
2015-01-16 11:11:06,873 DEBUG zuul.Gearman: Looking for lost builds
2015-01-16 11:16:06,874 DEBUG zuul.Gearman: Looking for lost builds
2015-01-16 11:21:06,874 DEBUG zuul.Gearman: Looking for lost builds
2015-01-16 11:26:06,875 DEBUG zuul.Gearman: Looking for lost builds
2015-01-16 11:31:06,875 DEBUG zuul.Gearman: Looking for lost builds
2015-01-16 11:36:06,876 DEBUG zuul.Gearman: Looking for lost builds
2015-01-16 11:41:06,876 DEBUG zuul.Gearman: Looking for lost builds
2015-01-16 11:46:06,877 DEBUG zuul.Gearman: Looking for lost builds
Zuul is stuck in Looking for lost builds and it misses comments so it
doesn't trigger jobs on patches.
Any idea how to fix this? (other than restart it every 30 mins, in which
case it misses the results of running jobs so it doesn't post the results).
Thanks,
Eduard
On Fri, Jan 16, 2015 at 1:43 AM, Asselin, Ramy ramy.asse...@hp.com wrote:
Hi Eduard,
Glad you’re making progress.
$BASE/new/devstack/ is available at the time pre_test_hook is called, so
you should be able to make all the changes you need there.
The sample shows how to configure the driver using local.conf devstack
hooks.
See here for more details: [1] [2]
Regarding test, you can do both.
Cinder requires you run tempest.api.volume[3]
And you can setup a 2nd job that runs your internal functional tests as
well.
Ramy
[1] http://docs.openstack.org/developer/devstack/configuration.html
[2] http://docs.openstack.org/developer/devstack/plugins.html
[3]
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Third_Party_CI_Requirements
*From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
*Sent:* Thursday, January 15, 2015 4:57 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help
setting up CI
Hi Ramy,
The issue with disconnect/abort no longer happens, so i guess it was some
issues with networking.
Regarding the ssh keys i finally used Jenkins Configuration Provider
Plugin to inject ssh keys as a pre-build step, then i added a manual
execution step to scp the logs to the server, so now everything appears to
be working.
Now for the REAL tests:
looking at
https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7
it seems i need to put the code to install my third party libs in the
pre_test_hook which appears in devstack-vm-gate-wrap.sh to be executing
BEFORE installing devstack. The problem is we need our third party libs
to be installed (actually configured) AFTER installing devstack, since they
install on top of devstack and do some configuration on devstack.
How could i integrate my code into devstack-vm-gate-wrap.sh so that my
libs are installed after devstack but before running tempest.
Also, as a side question, do i need to run all the test (since they
already run in dsvm-tempest-full) or can i run only our internal
functionality tests? (in this case i don't need devstack-vm-gate-wrap.sh
and i can run custom code directly from jenkins job).
Thanks,
Eduard
On Wed, Jan 14, 2015 at 6:49 PM, Asselin, Ramy ramy.asse...@hp.com
wrote:
Double check your ssh public/private key, authorized keys configuration
in the slave log server.
They should all match up. No passwords should be requested.
Try doing a manual scp as Jenkins user from the slave to the log server
(as Jenkins user there too).
Regarding manually setting up the publisher, I don’t know. Jenkins Job
Builder configuration I referenced below should work correctly.
Ramy
*From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
*Sent:* Wednesday, January 14, 2015 6:56 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help
setting up CI
Hi Ramy,
I think i managed to setup SCP plugin and updated zuul.conf but it only
uploads the console.html not the logs
I have an SCP site pointing to the apache server and the root location is
/srv/static, and in the dsvm job manually added a post-build step, Publish
Artifacts to SCP Repository, with source: logs/** and destination
logs/${LOG_PATH} and also checked Copy Console Log.
The destination path is created, but it only contains console.html.
I tried to manually scp the directory, but the jenkins user in the
devstack_slave asks for a password when trying to ssh to apache
Re: [openstack-dev] How to debug test cases in Openstack
On Fri, Jan 16, 2015 at 11:07:07AM +0530, Abhishek Talwar/HYD/TCS wrote: Hi, I have been trying to debug the test cases in OpenStack, but I am not getting successful with it. So if someone can help me with that. The last response from the dev-list was to use $ ./run_tests.sh -d [test module path] but this gives bDb quit error. There are several ways to execute UT, you can use tox or run_tests.sh or for a more specific test I prefer to enter in the venv and to use nose. s. So kindly help me this. -- Thanks and Regards Abhishek Talwar =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI
Hi eduard, can you post the whole zuul.log or debug.log after the zuul and zuul-merger restart along with your layout.yaml did you test the connection of gearman pulgin in jenkins ? thanks On Fri, Jan 16, 2015 at 4:20 PM, Eduard Matei eduard.ma...@cloudfounders.com wrote: Hi Ramy, Still couldn't get my custom code to execute between installing devstack and starting tests... i'll try with some custom scripts and skip devstack-* scripts. Meanwhile i see another issue: 2015-01-16 11:02:26,283 DEBUG zuul.IndependentPipelineManager: Finished queue processor: patch (changed: False) 2015-01-16 11:02:26,283 DEBUG zuul.Scheduler: Run handler sleeping 2015-01-16 11:06:06,873 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:11:06,873 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:16:06,874 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:21:06,874 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:26:06,875 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:31:06,875 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:36:06,876 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:41:06,876 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:46:06,877 DEBUG zuul.Gearman: Looking for lost builds Zuul is stuck in Looking for lost builds and it misses comments so it doesn't trigger jobs on patches. Any idea how to fix this? (other than restart it every 30 mins, in which case it misses the results of running jobs so it doesn't post the results). Thanks, Eduard On Fri, Jan 16, 2015 at 1:43 AM, Asselin, Ramy ramy.asse...@hp.com wrote: Hi Eduard, Glad you’re making progress. $BASE/new/devstack/ is available at the time pre_test_hook is called, so you should be able to make all the changes you need there. The sample shows how to configure the driver using local.conf devstack hooks. See here for more details: [1] [2] Regarding test, you can do both. Cinder requires you run tempest.api.volume[3] And you can setup a 2nd job that runs your internal functional tests as well. Ramy [1] http://docs.openstack.org/developer/devstack/configuration.html [2] http://docs.openstack.org/developer/devstack/plugins.html [3] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Third_Party_CI_Requirements *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com] *Sent:* Thursday, January 15, 2015 4:57 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI Hi Ramy, The issue with disconnect/abort no longer happens, so i guess it was some issues with networking. Regarding the ssh keys i finally used Jenkins Configuration Provider Plugin to inject ssh keys as a pre-build step, then i added a manual execution step to scp the logs to the server, so now everything appears to be working. Now for the REAL tests: looking at https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7 it seems i need to put the code to install my third party libs in the pre_test_hook which appears in devstack-vm-gate-wrap.sh to be executing BEFORE installing devstack. The problem is we need our third party libs to be installed (actually configured) AFTER installing devstack, since they install on top of devstack and do some configuration on devstack. How could i integrate my code into devstack-vm-gate-wrap.sh so that my libs are installed after devstack but before running tempest. Also, as a side question, do i need to run all the test (since they already run in dsvm-tempest-full) or can i run only our internal functionality tests? (in this case i don't need devstack-vm-gate-wrap.sh and i can run custom code directly from jenkins job). Thanks, Eduard On Wed, Jan 14, 2015 at 6:49 PM, Asselin, Ramy ramy.asse...@hp.com wrote: Double check your ssh public/private key, authorized keys configuration in the slave log server. They should all match up. No passwords should be requested. Try doing a manual scp as Jenkins user from the slave to the log server (as Jenkins user there too). Regarding manually setting up the publisher, I don’t know. Jenkins Job Builder configuration I referenced below should work correctly. Ramy *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com] *Sent:* Wednesday, January 14, 2015 6:56 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI Hi Ramy, I think i managed to setup SCP plugin and updated zuul.conf but it only uploads the console.html not the logs I have an SCP site pointing to the apache server and the root location is /srv/static, and in the dsvm job manually added a post-build step, Publish Artifacts to SCP
[openstack-dev] [Trove][Cassandra] Cassandra clustering implementation progress
Hello to All. I'd like to notify those of you who's interested in clustering implementation in Trove that i've made big progress with Cassandra clustering implementation. There are couple patches that may be useful for those of you who want to verify given implementation: - python-troveclient patchset https://review.openstack.org/#/c/145801/ - trove-integration patchset https://review.openstack.org/#/c/146098/ - trove patches: - API https://review.openstack.org/#/c/146145/ - Taskmanager + Guestagent + Integration testing https://review.openstack.org/#/c/146146/ There are couple tasks were left for discussions: 1. Infra gate job - on regular basis or experimental ? 2. Given integration testing covers minimum case - cluster provisioning. Additional tests would be proposed later. If there's any question, feel free to ask. Thanks. Kind regards, Denis M. IRC: denis_makogon dmako...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Openstack][dev][Zuul] Merge Failed Error in CI - GitPython Error
Hi stackers, i'm running CI for openstack cinder patches, when zuul reads a new patch from gerrit, it tries to merge the patch to it's own cinder repo @/var/lib/zuul/git/openstack/cinder and returns the comment to gerrit saying hence it is failing to issue the tempest-job in jenkins via gearman !!! on checking the trace the error seems to come from GitPython 0.3.2.1 the zuul/merger-debug log snapshot ref - http://paste.openstack.org/show/158218/ *raise ValueError(Failed to parse line: %r % line) * *ValueError: Failed to parse line: 'Total 9 (delta 7), reused 9 (delta 7)'*' is this a problem of python git ? i'm using ubuntu 12.04 and git 1.7 thanks regards, punith s cloudbyte.com -- regards, punith s cloudbyte.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] [nova][gate][stable] How eventlet 0.16.1 broke the gate
On 15/01/15 23:41, Sean Dague wrote: On 01/15/2015 06:25 PM, Joe Gordon wrote: We can side step the dependency graphing and ordering issue by looking at the list of curently installed packages via pip freeze and not installing dependencies (pip install --no-deps) After looking into this further here are the known issues: * Partial capping won't work [0], so we need to pin all dependencies, we can generate this list per file via pip install -r and pip freeze, but this doesn't address the issue of apt-get vs pip install. For example in the stable gate we use suds 0.4.1 but only suds 0.4.0 is available via pip. * Not all packages are installed in are standard dsvm-tempest env, so using pip-freeze from that isn't enough * We need to run this per requirements file and move to using pip install --no-deps everywhere. As the global-requirements sync wouldn't work the first time since files don't list all transient dependencies yet. So that's basically writing our own dependency system entirely, and skipping pip's (vs. fudging around pip's issues). I expect that's going to go poorly in the OpenStack ecosystem realm because a lot of very repetitive manual analysis will need to be done on each project. And if we want to bump a cap, regenerating all the graphs becomes another manual process. Pip's loose dependency processing where each entry is treated as an entirely separate resolution with no consideration of previous or later constraints came up recently in a discussion at work. Looking around I discovered someone had already started working on a solution, which involves moving the current requirements to a 'requirements.in' file and then compiling that to requirements.txt, which would contain only fully pinned packages in the correct order for pip to install them without needing to add any special options. Might be worth seeing if that could be developed further: http://nvie.com/posts/better-package-management/ https://github.com/nvie/pip-tools/tree/future * We can still break if a package version is removed from pypi * in pip-freeze we sometimes install versions lower then our minimum version (python-libvirt!) That's because python-libvirt is not in any requirements.txt file, so we're taking the system version. -Sean Regards, Darragh Bailey Nothing is foolproof to a sufficiently talented fool - Unknown __ OpenStack Development Mailing List (not for 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][client] new client implementation ideas
Hi all,
I have created etherpad page
https://etherpad.openstack.org/p/fuelclient-implementation-ideas
On Wed, Jan 14, 2015 at 12:38 PM, Konstantin Danilov kdani...@mirantis.com
wrote:
Igor,
Yep, I knew that you start to rewrite fuel-client, but it seemd for me
that this ideas is not for
https://etherpad.openstack.org/p/fuelclient-redesign document because it's
implementation details. Should I create a new notepad for it?
On Wed, Jan 14, 2015 at 11:58 AM, Igor Kalnitsky ikalnit...@mirantis.com
wrote:
Hi, Konstantin,
Thank you for sharing ideas. Your yet-one-more implementation of
fuel-client one more time confirms that currently we have completely
unusable implementation.
Just for your information: we have plans for python-fuelclient
refactoring [1]. The main point of this blueprint is to provide
fuelclient which will be useful as both: library and cli. Please, do
not hesitate share your ideas in blueprint or in the working ehterpad
[2].
- Igor
[1]: https://review.openstack.org/#/c/135915/
[2]: https://etherpad.openstack.org/p/fuelclient-redesign
On Wed, Jan 14, 2015 at 12:38 PM, Konstantin Danilov
kdani...@mirantis.com wrote:
Hi all,
We are working on fuel certification script
https://github.com/stgleb/fuel-web
and have yet-one-more implementation of fuel-client, which cover very
small
of Fuel API, yet we have some ideas, which you might be interesting in.
1) high-level primitives for REST operations.
a) GET/PUT/POST/etc function, which returns closure, bonded to url
and
method
class Cluster(RestObj):
Class represents Cluster in Fuel
add_node_call = PUT('api/nodes')
start_deploy = PUT('api/clusters/{id}/changes')
get_status = GET('api/clusters/{id}')
delete = DELETE('api/clusters/{id}')
GET(url_template) returns function/class method, which accepts
set
of parameters,
format part of them into url_template to obtain final url and
pass
other parameters
as data in http request. E.g.
get_some_objs = GET('some/objects/{cluster_id}/really_get')
get_some_objs(cluster_id=12, kind=db objects) will result in
HTTP request GET '/some/objects/12/really_get' data =
{'kind':'db objects'}
in case of class method it also extracts missing format
parameters
from self.__dict__.
E.g.
node = Node.get_all()[0]
nnode = node.get() takes id from node.id
b) Auto generate API for strict restfull cases, e.g.
class Node(RestfulObj):
Represents node in Fuel
__url__ = '/api/nodes/{id}'
==
class Node(RestObj):
Represents node in Fuel
get_all = GET('/api/nodes')
get = GET('/api/nodes/{id}')
delete = DELETE('/api/nodes/{id}')
create = POST('/api/nodes/{id}')
2) API for create cluster from yaml description. Allow to deploy whole
openstack cluster from single yaml file. We being asking a lot whenever
this
call would be available in fuel client
by different team/persons.
https://github.com/stgleb/fuel-web/blob/sertification-script/certification_script/certification_script/cert_script.py#L165
3) I have a semi-implemented ideas for future-based API for background
tasks
(e.g. cluster deployment)
Code is available in repo and we would be glad to help you to merge it
to
new fuel-client
--
Kostiantyn Danilov aka koder.ua
Principal software engineer, Mirantis
skype:koder.ua
http://koder-ua.blogspot.com/
http://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
--
Kostiantyn Danilov aka koder.ua
Principal software engineer, Mirantis
skype:koder.ua
http://koder-ua.blogspot.com/
http://mirantis.com
--
Kostiantyn Danilov aka koder.ua
Principal software engineer, Mirantis
skype:koder.ua
http://koder-ua.blogspot.com/
http://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] [heat] Remove deprecation properties
On Thu, Dec 25, 2014 at 01:52:43PM +0400, Sergey Kraynev wrote: Hi all. In the last time we got on review several patches, which removes old deprecation properties [1],A and one mine [2]. The aim is to delete deprecated code and redundant tests. It looks simple, but the main problem, which we met, is backward compatibility. F.e. user has created resource (FIP) with old property schema, i.e. using SUBNET_ID instead of SUBNET. On first look nothing bad will not happen, because: FWIW I think it's too soon to remove the Neutron subnet_id/network_id properties, they were only deprecated in Juno [1], and it's evident that users are still using them on icehouse [2] I thought the normal deprecation cycle was at least two releases, but I can't recall where I read that. Considering the overhead of maintaining these is small, I'd favour leaning towards giving more time for users to update their templates, rather then breaking them via very aggresive removal of deprecated interfaces. I'd suggest some or all of the following: - Add a planned for removal in $release to the SupportStatus string associated with the deprecation, so we can document the planned removal. - Wait for at least two releases between deprecation and removal, and announce the interfaces which will be removed in the release notes for the release before removal e.g: - Deprecated in Juno - Announce planned removal in Kilo release notes - Remove in J [1] https://review.openstack.org/#/c/82853/ [2] http://lists.openstack.org/pipermail/openstack/2015-January/011156.html 1. handle_delete use resource_id and any changes in property schema does not affect other actions. 2. If user want to use old template, he will get adequate error message, that this property is not presented in schema. After that he just should switch to new property and update stack using this new property. In the same time we have one big issues for shadow dependencies, which is actual for neutron resources. The simplest approach will not be worked [3], due to old properties was deleted from property_schema. Why is it bad ? - we will get again all bugs related with such dependencies. - how to make sure:A A A - create stack with old property (my template [4]) A A - open horizon, and look on topology A A - download patch [2] and restart engine A A - reload horizon page with topology A A - as result it will be different A I have some ideas about how to solve this, but none of them is not enough good for me: A - getting such information from self.properties.data is bad, because we will skip all validations mentioned in properties.__getitem__ A - renaming old key in data to new or creating copy with new key is not correct for me, because in this case we actually change properties (resource representation) invisibly from user. A - as possible we may leave old deprecated property and mark it something like (removed), which will have similar behavior such as for implemented=False. I do not like it, because it means, that we never remove this support code, because wants to be compatible with old resources. (User may be not very lazy to do simple update or something else ...) - last way, which I have not tried yet, is usingA _stored_properties_data forA extraction necessary information. So now I have the questions: Should we support such case with backward compatibility?A If yes, how will be better to do it for us and user? May be we should create some strategy forA removingA A deprecated properties ? Yeah, other than the process issues I mentioned above, Angus has pointed out some technical challenges which may mean property removal breaks existing stacks. IMHO this is something we *cannot* do - folks must be able to upgrade heat over multiple versions without breaking their stacks. As you say, delete may work, but it's likely several scenarios around update will break if the stored stack definition doesn't match the schema of the resource, and maintaining the internal references to removed or obsolete properties doesn't seem like a good plan long term. Could we provide some sort of migration tool, which re-writes the definition of existing stacks (via a special patch stack update maybe?) before upgrading heat? Steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Empty role - status
Hi Andrew, What you described is exactly what we were going to do [1], and everybody understand all of the cons which you described. Also if you take a look at the blueprint it's not about plugins at all. Scope of improvements was reduced for the current release and Role as a plugin was postponed. [1] https://blueprints.launchpad.net/fuel/+spec/role-as-a-plugin [2] https://blueprints.launchpad.net/fuel/+spec/blank-role-node On Thu, Jan 15, 2015 at 11:17 PM, Andrew Woodward xar...@gmail.com wrote: [from another thread] On Wed, Jan 14, 2015 at 2:24 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Guys, We want to introduce an empty role as a basis for plugins. For instance, the user select nodes, assign empty role and names it somehow like CONTRAIL. In this step, vanilla fuel will just provision a node (since it's an empty role) and the plugin (in post hooks) can select all empty roles with node.name == CONTRAIL and deploy some stuff on that node. Obviously, it's hackish. But it's a simple approach that requires a minimum time. In future, we'll introduce pluggable roles, but that's another story. So far from the review we simply added an role with a base OS, this provides a nearly useless experience for plugin developers. This is heavy on hacking even for plugin-devs issues: 1) you get one role 2) you have to come up with some random way to identify nodes from each other if you do. We can't set hostname, and node.name in the nailgun is never in astute.yaml (which is a tech debt that we have code to fix) 3) disk layout is fixed, and uselessly small, plugin-author will have a lot of rework to do here 4) multiple plugins that need roles will effectively fight with each other We can add roles in the releases API as it is, a plugin should be able to leverage this, the only gap currently is [1] which is not an API currently (new from granular deployments). Because of this, it would be more useful to just call these API's during installing the plugin. Worse case, the plugin author can do this themselves if we add the install_script support [2] [1] https://review.openstack.org/#/c/147230/2/nailgun/nailgun/orchestrator/graph_configuration.py [2] https://review.openstack.org/#/c/137301/ On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin ada...@mirantis.com wrote: Answers inline. On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L e...@mirantis.com wrote: Hi, Empty role is ready [1], thanks to granular deployment feature I didn't have to hardcode some hacks in Astute again. But there are several things which I want to mention/discuss: 1. in the patch you can see the name of the role and its description I would like to ask you to verify it and provide some other options if you have any 2. we have a minor problem with the progress bar, we will figure out how to fix it in Astute with Vladimir S. 3. and the biggest problem is an old bug [2], the bug is Ubuntu specific and it doesn't allow us to make efficient partitioning schema, e.g. it means that we cannot allocate root partition for all of the disks (provisioning will fail), the current workaround is to allocate root partition with minimal size (about 15G) and leave the rest of the space as is (unallocated). As far as I can see from the bug it's not so easy to fix the problem, actually image based provisioning fixes the problem, but it's not an option for the current release. Maybe you have some other ideas how to fix this problem? I would leave it as is - 15 GB. A user or plugin can adjust it for its needs. Thanks, [1] https://review.openstack.org/#/c/147230/ [2] https://bugs.launchpad.net/fuel/+bug/1278964 __ OpenStack Development Mailing 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 -- Andrew Mirantis Ceph community __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [Fuel] Empty role - status
The whole-disk allocator we use for ceph-osd should be proper to work around this problem in a way. Our current constraint for Ubuntu is it cannot be allocated on several disks, as far as I remember for ceph-osd Fuel allocates from 1 to N disks, and it doesn't allocate any other volumes on the same disk with Ceph's volumes. So I don't see how it can help here. On Thu, Jan 15, 2015 at 11:47 PM, Andrew Woodward xar...@gmail.com wrote: On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin ada...@mirantis.com wrote: Answers inline. On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L e...@mirantis.com wrote: Hi, Empty role is ready [1], thanks to granular deployment feature I didn't have to hardcode some hacks in Astute again. But there are several things which I want to mention/discuss: 1. in the patch you can see the name of the role and its description I would like to ask you to verify it and provide some other options if you have any 2. we have a minor problem with the progress bar, we will figure out how to fix it in Astute with Vladimir S. 3. and the biggest problem is an old bug [2], the bug is Ubuntu specific and it doesn't allow us to make efficient partitioning schema, e.g. it means that we cannot allocate root partition for all of the disks (provisioning will fail), the current workaround is to allocate root partition with minimal size (about 15G) and leave the rest of the space as is (unallocated). As far as I can see from the bug it's not so easy to fix the problem, actually image based provisioning fixes the problem, but it's not an option for the current release. Maybe you have some other ideas how to fix this problem? I would leave it as is - 15 GB. A user or plugin can adjust it for its needs. Seriously? NO the 15G Min / Max 50G min for the OS allocation is too small for a default value and not using the rest of the disk. While the user may easily change this (by the way, most users don't they expect better allocations), how do you expect the plugin-dev to deal with this? The way this seams to push the plugin-dev is to do it pre-deployment via code. We know already working with the disk allocation is very painful, why are we pushing them to 'duplicate' code. We need proper support of dynamically adding roles so they can re-use our code Is [2] the correct bug for the ubuntu OS volume issue? It's clearly talking about small root disk values being wrong for all real deployments. I'll try to look for the proper bug w/regards to ubuntu OS, but the gist is the limitation is that the OS volume can not span multiple disks. The whole-disk allocator we use for ceph-osd should be proper to work around this problem in a way. Thanks, [1] https://review.openstack.org/#/c/147230/ [2] https://bugs.launchpad.net/fuel/+bug/1278964 __ OpenStack Development Mailing 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 -- Andrew Mirantis Ceph community __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for 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] [Scale] [UI] Improvements to handle 200+ nodes
It's also should be mentioned that these are several changes to do on backend in order for UI to work faster, not on UI itself. For example, these are: - Custom filters, as Vitaly mentioned - Pagination of collections - PATCH requests support - Probably both short and /full representations for some entities On Fri, Jan 16, 2015 at 8:48 AM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Folks, Currently Fuel UI can handle large amounts of nodes due to a recent refactoring - rendering and operations with nodes became much faster. But that large amount of nodes also requires UX improvement, I'd love to hear your ideas and opinions on these proposals: Introduce compact node representation and let users switch between standart and compact view. Compact view will display only node name and status and will allow to display 4-8 nodes in a row instead of only one. Currently it is only possible to filter node by names. Filtering feature could be extended to allow filtering by other parameters: status, roles, manufacturer, RAM, disk space. There are 2 options (I'd like to hear which one you prefer): Form-based filter (beside a single input for name there will be controls for other parameters) Query language-based filter (like one used in Gerrit) Add ability to add arbitrary tags with values to nodes and also allow filtering by them. -- Vitaly Kramskikh, 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 -- 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] [fuel][client] new client implementation ideas
Konstantin,
thank you for your ideas, I think we will definitely want to use something like
that. Lets discuss some nits in the etherpad you’ve created.
- romcheg
16 січ. 2015 о 13:03 Konstantin Danilov kdani...@mirantis.com написав(ла):
Hi all,
I have created etherpad page
https://etherpad.openstack.org/p/fuelclient-implementation-ideas
https://etherpad.openstack.org/p/fuelclient-implementation-ideas
On Wed, Jan 14, 2015 at 12:38 PM, Konstantin Danilov kdani...@mirantis.com
mailto:kdani...@mirantis.com wrote:
Igor,
Yep, I knew that you start to rewrite fuel-client, but it seemd for me that
this ideas is not for
https://etherpad.openstack.org/p/fuelclient-redesign
https://etherpad.openstack.org/p/fuelclient-redesign document because it's
implementation details. Should I create a new notepad for it?
On Wed, Jan 14, 2015 at 11:58 AM, Igor Kalnitsky ikalnit...@mirantis.com
mailto:ikalnit...@mirantis.com wrote:
Hi, Konstantin,
Thank you for sharing ideas. Your yet-one-more implementation of
fuel-client one more time confirms that currently we have completely
unusable implementation.
Just for your information: we have plans for python-fuelclient
refactoring [1]. The main point of this blueprint is to provide
fuelclient which will be useful as both: library and cli. Please, do
not hesitate share your ideas in blueprint or in the working ehterpad
[2].
- Igor
[1]: https://review.openstack.org/#/c/135915/
https://review.openstack.org/#/c/135915/
[2]: https://etherpad.openstack.org/p/fuelclient-redesign
https://etherpad.openstack.org/p/fuelclient-redesign
On Wed, Jan 14, 2015 at 12:38 PM, Konstantin Danilov
kdani...@mirantis.com mailto:kdani...@mirantis.com wrote:
Hi all,
We are working on fuel certification script
https://github.com/stgleb/fuel-web https://github.com/stgleb/fuel-web
and have yet-one-more implementation of fuel-client, which cover very small
of Fuel API, yet we have some ideas, which you might be interesting in.
1) high-level primitives for REST operations.
a) GET/PUT/POST/etc function, which returns closure, bonded to url and
method
class Cluster(RestObj):
Class represents Cluster in Fuel
add_node_call = PUT('api/nodes')
start_deploy = PUT('api/clusters/{id}/changes')
get_status = GET('api/clusters/{id}')
delete = DELETE('api/clusters/{id}')
GET(url_template) returns function/class method, which accepts set
of parameters,
format part of them into url_template to obtain final url and pass
other parameters
as data in http request. E.g.
get_some_objs = GET('some/objects/{cluster_id}/really_get')
get_some_objs(cluster_id=12, kind=db objects) will result in
HTTP request GET '/some/objects/12/really_get' data =
{'kind':'db objects'}
in case of class method it also extracts missing format parameters
from self.__dict__.
E.g.
node = Node.get_all()[0]
nnode = node.get() takes id from node.id http://node.id/
b) Auto generate API for strict restfull cases, e.g.
class Node(RestfulObj):
Represents node in Fuel
__url__ = '/api/nodes/{id}'
==
class Node(RestObj):
Represents node in Fuel
get_all = GET('/api/nodes')
get = GET('/api/nodes/{id}')
delete = DELETE('/api/nodes/{id}')
create = POST('/api/nodes/{id}')
2) API for create cluster from yaml description. Allow to deploy whole
openstack cluster from single yaml file. We being asking a lot whenever this
call would be available in fuel client
by different team/persons.
https://github.com/stgleb/fuel-web/blob/sertification-script/certification_script/certification_script/cert_script.py#L165
https://github.com/stgleb/fuel-web/blob/sertification-script/certification_script/certification_script/cert_script.py#L165
3) I have a semi-implemented ideas for future-based API for background tasks
(e.g. cluster deployment)
Code is available in repo and we would be glad to help you to merge it to
new fuel-client
--
Kostiantyn Danilov aka koder.ua http://koder.ua/
Principal software engineer, Mirantis
skype:koder.ua http://koder.ua/
http://koder-ua.blogspot.com/ http://koder-ua.blogspot.com/
http://mirantis.com http://mirantis.com/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments
Hi, 1) +1 for warning 2) I don't think that we should delete tasks, it's a history which can be useful, for example for stats feature, also it's useful for debugging, but each task should have created_at and updated_at fields, and from api you will be able to get the latest tasks for specific env. Thanks, On Thu, Jan 15, 2015 at 7:20 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Folks, I want to discuss possibility to add network verification status field for environments. There are 2 reasons for this: 1) One of the most frequent reasons of deployment failure is wrong network configuration. In the current UI network verification is completely optional and sometimes users are even unaware that this feature exists. We can warn the user before the start of deployment if network check failed of wasn't performed. 2) Currently network verification status is partially tracked by status of the last network verification task. Sometimes its results become stale, and the UI removes the task. There are a few cases when the UI does this, like changing network settings, adding a new node, etc (you can grep removeFinishedNetworkTasks to see all the cases). This definitely should be done on backend. What is your opinion on this? -- Vitaly Kramskikh, 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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Remove deprecation properties
Steve, Thanks for the feedback. On 16 January 2015 at 15:09, Steven Hardy sha...@redhat.com wrote: On Thu, Dec 25, 2014 at 01:52:43PM +0400, Sergey Kraynev wrote: Hi all. In the last time we got on review several patches, which removes old deprecation properties [1],A and one mine [2]. The aim is to delete deprecated code and redundant tests. It looks simple, but the main problem, which we met, is backward compatibility. F.e. user has created resource (FIP) with old property schema, i.e. using SUBNET_ID instead of SUBNET. On first look nothing bad will not happen, because: FWIW I think it's too soon to remove the Neutron subnet_id/network_id properties, they were only deprecated in Juno [1], and it's evident that users are still using them on icehouse [2] I thought the normal deprecation cycle was at least two releases, but I can't recall where I read that. Considering the overhead of maintaining these is small, I'd favour leaning towards giving more time for users to update their templates, rather then breaking them via very aggresive removal of deprecated interfaces. Honestly I thought, that we use 1 release cycle, but I have not any objections to do it after two releases. Will be glad to know what is desired deprecation period. I'd suggest some or all of the following: - Add a planned for removal in $release to the SupportStatus string associated with the deprecation, so we can document the planned removal. - Wait for at least two releases between deprecation and removal, and announce the interfaces which will be removed in the release notes for the release before removal e.g: - Deprecated in Juno - Announce planned removal in Kilo release notes - Remove in J I like this idea, IMO it will make our deprecation process clear. [1] https://review.openstack.org/#/c/82853/ [2] http://lists.openstack.org/pipermail/openstack/2015-January/011156.html 1. handle_delete use resource_id and any changes in property schema does not affect other actions. 2. If user want to use old template, he will get adequate error message, that this property is not presented in schema. After that he just should switch to new property and update stack using this new property. In the same time we have one big issues for shadow dependencies, which is actual for neutron resources. The simplest approach will not be worked [3], due to old properties was deleted from property_schema. Why is it bad ? - we will get again all bugs related with such dependencies. - how to make sure:A A A - create stack with old property (my template [4]) A A - open horizon, and look on topology A A - download patch [2] and restart engine A A - reload horizon page with topology A A - as result it will be different A I have some ideas about how to solve this, but none of them is not enough good for me: A - getting such information from self.properties.data is bad, because we will skip all validations mentioned in properties.__getitem__ A - renaming old key in data to new or creating copy with new key is not correct for me, because in this case we actually change properties (resource representation) invisibly from user. A - as possible we may leave old deprecated property and mark it something like (removed), which will have similar behavior such as for implemented=False. I do not like it, because it means, that we never remove this support code, because wants to be compatible with old resources. (User may be not very lazy to do simple update or something else ...) - last way, which I have not tried yet, is usingA _stored_properties_data forA extraction necessary information. So now I have the questions: Should we support such case with backward compatibility?A If yes, how will be better to do it for us and user? May be we should create some strategy forA removingA A deprecated properties ? Yeah, other than the process issues I mentioned above, Angus has pointed out some technical challenges which may mean property removal breaks existing stacks. IMHO this is something we *cannot* do - folks must be able to upgrade heat over multiple versions without breaking their stacks. As you say, delete may work, but it's likely several scenarios around update will break if the stored stack definition doesn't match the schema of the resource, and maintaining the internal references to removed or obsolete properties doesn't seem like a good plan long term. Could we provide some sort of migration tool, which re-writes the definition of existing stacks (via a special patch stack update maybe?) before upgrading heat? Yeah, I thought about it. Probably it's good solution for upgrading. However one thing stops me to start doing it right now: If we upgrade
Re: [openstack-dev] libvirt memory ballooning [nova]
- Original Message -
From: Vikash Kumar vikash.ku...@oneconvergence.com
To: openstack-dev openstack-dev@lists.openstack.org
All,
There is blueprint for enabling libvirt memory ballooning
https://blueprints.launchpad.net/nova/+spec/libvirt-memory-ballooning in
openstack nova. I think for Hyper-V , its already in place. Can we discuss
about the design and implementation and target for L release?
Regards,
Vikash
Yes, Hyper-V support for roughly equivalent functionality was added under this
blueprint:
https://blueprints.launchpad.net/nova/+spec/hyper-v-dynamic-memory
This added a configuration variable dynamic_memory_ratio for setting the ratio
between the total RAM assigned to an instance and its startup RAM amount:
cfg.FloatOpt('dynamic_memory_ratio',
default=1.0,
help='Enables dynamic memory allocation (ballooning)
when '
'set to a value greater than 1. The value expresses '
'the ratio between the total RAM assigned to an '
'instance and its startup RAM amount. For example a '
'ratio of 2.0 for an instance with 1024MB of RAM '
'implies 512MB of RAM allocated at startup')
It doesn't appear that any logic was added to the scheduler to factor this in
during placement though [1]. I think a Libvirt driver implementation to support
memory ballooning would make sense, and is probably overdue, but there are a
few issues to consider. In particular as Dan mentioned how would this interplay
with other constructs for handling guest RAM including the 'normal' RAM
overcommit functionality and also how to ensure that guests which don't support
exercising the memory balloon (lack of installed driver/agent) are handled
correctly.
Thanks,
Steve
[1] https://review.openstack.org/#/c/38791/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] User self registration and management
The VO code exists already, as does a public demo (see my original email for details). I gave demos to the Keystone core in Paris last November. How soon this gets incorporated into core depends upon public/user demand. So far, it seems that few people have recognised the value of this service, probably because they are not using federated Keystone seriously. Once they do, I believe that the need for user self registration to roles and privileges will become immediately apparent regards David On 15/01/2015 23:28, Adrian Turjak wrote: Typo fix, see below. On 16/01/15 12:26, Adrian Turjak wrote: Hello David, We are definitely assessing the option, although even switching Keystone to be backed by an LDAP service might also work, and not be a switch to a fully federated system. I believe Keystone has had LDAP support since Havana, and that was an option we had looked at. It also might be a terrible option, we don't know yet, and would still mean dealing with LDAP directly anyway for user management. What seems weird though with a federated Keystone system though is that you still have to store role and group information in Keystone so that has to be propagate through somehow, or be automated in some way still via an external service. We don't at present have any concrete plans, and until now a pressing need to do so hasn't come up, although there were always plans to. As for the VO roles blueprint, how likely is that to be merged into master, and are there any implementations of it? I assume the VO entities mentioned in the proposal would be in Keystone, yes? We need a solution in the next few months (ideally sooner), but while building a quick hack of a service along Keystone could likely be done quickly , that wouldn't be a good long term solution. Cheers, -Adrian On 15/01/15 21:20, David Chadwick wrote: Hi Adrian Morgan is right in saying that an external IdP would solve many of your user management problems, but then of course, you will be using federated keystone which you seem reluctant to do :-) However, if you have an IdP under your full control then you can allow users to self register and reset their passwords. The next problem you will then face, is user authorisation - as opposed to user authentication. The VO roles blueprint that we have worked on addresses the authorisation problem. So when you are ready for this, let me know regards David On 15/01/2015 00:42, Morgan Fainberg wrote: On Jan 13, 2015, at 9:06 PM, Adrian Turjak adri...@catalyst.net.nz wrote: Hello openstack-dev, I'm wondering if there is any interest or need for an open-source user registration and management service for people using OpenStack. We're currently at a point where we need a way for users to sign up themselves, choose their own password, and request new users to be added to their project. There doesn't seem to be anything out there, and most vendors seem to have built their own systems to handle this or even their own dashboard systems that do. Horizon is built around the client tools, and your own personal token, so it can't handle creating new users. Plus Keystone doesn't really have any good way of handling temporary (unapproved) users and projects. The suggested approach seems to be to build a service to sit along Keystone, have it's own admin creds so it can create new users, and also store temp user data locally until the user is approved. Unless we can find a suitable solution for us quickly, we're likely to be developing such a service. It would ideally have a pluggable approval workflow, allowing new user requests, new project requests, creation of clients in external client database/ERP systems. Plus it would have a password reset-token system for having new users supply their password once they are approved, which would also allow existing users to request password resets. Part of our requirements are easy to integrate into Horizon, fitting neatly into the OpenStack ecosystem along other services, and being easy to update/alter once we have hierarchical multi-tenancy and if it makes some things easier. I've written up a proposal to help us define our requirements, and a copy of that is attached, and on etherpad: https://etherpad.openstack.org/p/User_Management_Service Plus I've attached a couple of diagrams, which are sadly not UML, but should give you some idea of two of the primary use cases. Is this useful to anyone? Is this entirely the wrong approach? If it is a useful service is there any interest in collaboration? Thanks for any feedback. Cheers, -Adrian Turjak I have an alternative recommendation (rather than using Keystone’s API and user-management). Keystone’s user management is lacking a lot of features a full fledged IDP (identity provider) would have. “Password reset”, “password complexity”, “password reuse”, failed login locking, etc. I would recommend that you implement this
[openstack-dev] [Fuel][plugins] Generic linux role and priorities
Hi all, I've figured out that generic linux role had been implemended ( https://blueprints.launchpad.net/fuel/+spec/blank-role-node). It seems very important feature in terms of further extension for puggable architecture. In order to implement more complex plugins (e.g. for Zabbix or another monitoring system) we need to change role priorities (e.g. to deploy some node types before OpenStack Cluster). Are there any plans to implement custom roles prioritization? Thanks in advance. -- Kind regards Dmitry Ukov IT 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] [Murano][Heat][Mistral] Use and adoption of YAQL
Dmitri, we are working hard towards stable YAQL 1.0 which is expected to be released during Kilo cycle. It is going to have proper documentation and high unit test coverage which can also serve as a documentation source. YAQL has already migrated to StackForge and adopted OpenStack development process and tools but the work is still in progress. Any help from Mistral team and/or other YAQL adopters is appreciated. Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis sla...@mirantis.com On Thu, Jan 15, 2015 at 10:54 PM, Dmitri Zimine dzim...@stackstorm.com wrote: Folks, We use YAQL in Mistral for referencing variables, expressing conditions, etc. Murano is using it extensively, I saw Heat folks thought of using it, at least once :) May be others... We are learning that YAQL incredibly powerful comparing to alternatives like Jinja2 templates used in salt / ansible. But with lack of documentation, it becomes one of adoption blockers to Mistral (we got very vocal user feedback on this). This is pretty much all the docs I can offer our users on YAQL so far. Not much. http://yaql.readthedocs.org/en/latest/ https://github.com/ativelkov/yaql/blob/master/README.rst https://murano.readthedocs.org/en/latest/murano_pl/murano_pl.html#yaql Are there any plans to fix it? Are there interest from other projects to use YAQL? Cheers, DZ. __ OpenStack Development Mailing 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][plugins] Generic linux role and priorities
Hi Dmitry, We have plans to implement role as a plugin [1], but it was decided to reduce the scope for 6.1 release and the feature was postponed. As a workaround you can use pre deployment hook to perform some actions before any node is deployed. Thanks, [1] https://blueprints.launchpad.net/fuel/+spec/role-as-a-plugin On Fri, Jan 16, 2015 at 5:32 PM, Dmitry Ukov du...@mirantis.com wrote: Hi all, I've figured out that generic linux role had been implemended ( https://blueprints.launchpad.net/fuel/+spec/blank-role-node). It seems very important feature in terms of further extension for puggable architecture. In order to implement more complex plugins (e.g. for Zabbix or another monitoring system) we need to change role priorities (e.g. to deploy some node types before OpenStack Cluster). Are there any plans to implement custom roles prioritization? Thanks in advance. -- Kind regards Dmitry Ukov IT 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 __ OpenStack Development Mailing 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] volume dictionary
Hi,
I am working on the Nova side of Add volume multi-attach support
https://review.openstack.org/#/c/143114/5.
I see a problem with the volume dictionary in nova code while running unit
tests (with the multiattach patches).
ERROR:
--
I get the following error by running the unit test
nova.tests.functional.test_api_samples.VolumesSampleJsonTest.test_volumes_index
/
nova.tests.functional.test_api_samples.VolumesSampleJsonTest.test_volumes_detail:
NoMatch: Extra list items in template:
{u'status': u'in-use', u'displayDescription': u'%(volume_desc)s',
u'availabilityZone': u'zone1:host1',
u'displayName': u'%(volume_name)s', u'attachments': [{u'device': u'/',
u'serverId': u'%(uuid)s', u'id': u'%(uuid)s',
u'volumeId': u'%(uuid)s'}], u'volumeType': u'Backup', u'snapshotId': None,
u'size': 100, u'id': u'%(uuid)s',
u'createdAt': u'%(strtime)s', u'metadata': {}}
Extra list items in Response:
{u'status': u'in-use', u'displayDescription': u'Volume Description',
u'availabilityZone': u'zone1:host1',
u'displayName': u'Volume Name', u'attachments': [{}], u'volumeType': u'Backup',
u'snapshotId': None,
u'size': 100, u'id': u'a26887c6-c47b-4654-abb5-dfadf7d3f803', u'createdAt':
u'2008-12-01T11:01:55.00', u'metadata': {}}
Nova can't find e.g. the key instance_uuid in the volume dictionary if the
attachments key is empty.
CONFUSION:
-
There are different types of volume dictionaries in the code and I am a bit
confused which one I should use for multiattach..
It looks like in one case there are keys like instance_uuid or mountpoint
outside of the attachments dict,
in another case these keys are outside and inside of the attachments. In
another case just inside the attachment dict.
Does anybody has a clue about this?
/Tobi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI
Hi Punith, That's the whole log :) Not a lot happening after restart, just default initialization. Zuul-merger is not restarted. Layout.yaml is default. Gearman plugin tested in Jenkins, reports success. I disabled now the restart job to see how long it will Look for lost builds. Have a nice weekend, Eduard On Fri, Jan 16, 2015 at 1:15 PM, Punith S punit...@cloudbyte.com wrote: Hi eduard, can you post the whole zuul.log or debug.log after the zuul and zuul-merger restart along with your layout.yaml did you test the connection of gearman pulgin in jenkins ? thanks On Fri, Jan 16, 2015 at 4:20 PM, Eduard Matei eduard.ma...@cloudfounders.com wrote: Hi Ramy, Still couldn't get my custom code to execute between installing devstack and starting tests... i'll try with some custom scripts and skip devstack-* scripts. Meanwhile i see another issue: 2015-01-16 11:02:26,283 DEBUG zuul.IndependentPipelineManager: Finished queue processor: patch (changed: False) 2015-01-16 11:02:26,283 DEBUG zuul.Scheduler: Run handler sleeping 2015-01-16 11:06:06,873 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:11:06,873 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:16:06,874 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:21:06,874 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:26:06,875 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:31:06,875 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:36:06,876 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:41:06,876 DEBUG zuul.Gearman: Looking for lost builds 2015-01-16 11:46:06,877 DEBUG zuul.Gearman: Looking for lost builds Zuul is stuck in Looking for lost builds and it misses comments so it doesn't trigger jobs on patches. Any idea how to fix this? (other than restart it every 30 mins, in which case it misses the results of running jobs so it doesn't post the results). Thanks, Eduard On Fri, Jan 16, 2015 at 1:43 AM, Asselin, Ramy ramy.asse...@hp.com wrote: Hi Eduard, Glad you’re making progress. $BASE/new/devstack/ is available at the time pre_test_hook is called, so you should be able to make all the changes you need there. The sample shows how to configure the driver using local.conf devstack hooks. See here for more details: [1] [2] Regarding test, you can do both. Cinder requires you run tempest.api.volume[3] And you can setup a 2nd job that runs your internal functional tests as well. Ramy [1] http://docs.openstack.org/developer/devstack/configuration.html [2] http://docs.openstack.org/developer/devstack/plugins.html [3] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Third_Party_CI_Requirements *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com] *Sent:* Thursday, January 15, 2015 4:57 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI Hi Ramy, The issue with disconnect/abort no longer happens, so i guess it was some issues with networking. Regarding the ssh keys i finally used Jenkins Configuration Provider Plugin to inject ssh keys as a pre-build step, then i added a manual execution step to scp the logs to the server, so now everything appears to be working. Now for the REAL tests: looking at https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7 it seems i need to put the code to install my third party libs in the pre_test_hook which appears in devstack-vm-gate-wrap.sh to be executing BEFORE installing devstack. The problem is we need our third party libs to be installed (actually configured) AFTER installing devstack, since they install on top of devstack and do some configuration on devstack. How could i integrate my code into devstack-vm-gate-wrap.sh so that my libs are installed after devstack but before running tempest. Also, as a side question, do i need to run all the test (since they already run in dsvm-tempest-full) or can i run only our internal functionality tests? (in this case i don't need devstack-vm-gate-wrap.sh and i can run custom code directly from jenkins job). Thanks, Eduard On Wed, Jan 14, 2015 at 6:49 PM, Asselin, Ramy ramy.asse...@hp.com wrote: Double check your ssh public/private key, authorized keys configuration in the slave log server. They should all match up. No passwords should be requested. Try doing a manual scp as Jenkins user from the slave to the log server (as Jenkins user there too). Regarding manually setting up the publisher, I don’t know. Jenkins Job Builder configuration I referenced below should work correctly. Ramy *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com] *Sent:* Wednesday, January 14, 2015 6:56 AM *To:* OpenStack Development Mailing List (not for usage questions)
[openstack-dev] [Murano] Review Day on Monday
Hi Team, I would like to announce another Review Day schedule on Monday (Jan 19). During New Year Christmas holidays our CI was broken, and queue with change-requests is now quote long. And what is more important, many patches and specs related to Policy Guided Fulfillment are need to be reviewed, we had not so much time to review them, and I propose to do it on Monday. -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com +7 (495) 640-4904, 0261 +7 (903) 156-0836 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments
Evgeniy, Yes, we shouldn't delete tasks, but for now it is the only way to mark verification results as obsolete and remove them. When we implement this new field, we can easily get rid of task deletion in favour of setting this field. 2015-01-16 15:58 GMT+03:00 Evgeniy L e...@mirantis.com: Hi, 1) +1 for warning 2) I don't think that we should delete tasks, it's a history which can be useful, for example for stats feature, also it's useful for debugging, but each task should have created_at and updated_at fields, and from api you will be able to get the latest tasks for specific env. Thanks, On Thu, Jan 15, 2015 at 7:20 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Folks, I want to discuss possibility to add network verification status field for environments. There are 2 reasons for this: 1) One of the most frequent reasons of deployment failure is wrong network configuration. In the current UI network verification is completely optional and sometimes users are even unaware that this feature exists. We can warn the user before the start of deployment if network check failed of wasn't performed. 2) Currently network verification status is partially tracked by status of the last network verification task. Sometimes its results become stale, and the UI removes the task. There are a few cases when the UI does this, like changing network settings, adding a new node, etc (you can grep removeFinishedNetworkTasks to see all the cases). This definitely should be done on backend. What is your opinion on this? -- Vitaly Kramskikh, 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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Vitaly Kramskikh, Fuel UI Tech Lead, 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] [horizon] static files handling, bower/
On Jan 15, 2015, at 7:27 PM, Michael Krotscheck krotsch...@gmail.com wrote: I think Oracle's got enough money to support Node.js on SPARC. How is money relevant here? Well, normally the argument I've received is We don't have the time/resources/insert-other-fiscally-motivated-reason to support/work on node. Ergo, money. But then, given Oracle's conduct around the whole Java ridiculousness I'm not exactly favorably disposed towards anything or anyone associated with them. They'd get a lot more respect if they open-sourced Solaris. Which actually reminds me of something: Infra only tests against Debian, CentOS, and Fedora. It does not test Solaris. So, no offense, but I don't care about your SPARC servers. ... that Node.js is an issue because we can not use it. Not because we don't WANT to use it. This is an important distinction that you seem to have missed. I haven't missed it, I just made the assumption that if someone wants to use a tool, they would be busy porting that tool rather than arguing on a list about it. Case and point: I wanted to use javascript in OpenStack Infra, so I did a ton of legwork to bring node, npm, bower, karma, jasmine, protractor, and grunt into the infra toolchain. So let me reframe this argument a bit: If you refuse to allow us frontend developers to use node, npm, and bower, then I expect you to reciprocate and no longer use the python executable or pip to write your code, and you can only debug using wsgi. Since those fill equivalent roles in our various languages-du-jour, it seems like a perfectly fair exchange. Deal? I'm sorry, what? Python is fully supported on Solaris (both x86 and SPARC). This discussion has nothing whatsoever to do with the 'language-du-jour'. It has everything to do with it: There are javascript engineers that want to use their tools, just like there are python engineers that want to user their tools. You're saying we can't use javascript tools because of SPARC's lack of support. I'm merely asking that our python engineers reciprocate and abandon your own tools out of solidarity. After all, we're all in this together, right? We are, and as this conversation has veered off in a destructive direction, I think we should back up and look at the compromise Radomir posted [1] to see if that solves the original technical problem we all have. Does having the requirements specified in a JSON file, without requiring a specific build tool to install the files, solve the packaging, testing, and deployment issue on platforms where node.js isn’t supported natively right now? Doug [1] http://lists.openstack.org/pipermail/openstack-dev/2015-January/054538.html Michael __ OpenStack Development Mailing 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][client][IMPORTANT] Making Fuel Client a separate project
Hi Fuelers, this is another status update. - OpenStack-CI is now running pep8 checks [1] for patches to python-fuelclient. - The script for running python tests in on review [2] and some guys are requested to test it and give some feedback - Fuel CI is now allowed to vote on python-fuelclient [3] so the next stage it to merge both run_test.sh [2] and Jenkins job to FuelCI [4] - It’s now planned to finish this migration on Tuesday next week, so it will be possible to build ISO from python-fuelclient repo Stay tuned. References: 1. Run pep8 jobs for python-fuelclient https://review.openstack.org/#/c/147801 https://review.openstack.org/#/c/147801 2. Run Python tests https://review.openstack.org/#/c/146950 https://review.openstack.org/#/c/146950 3. Allow FuelCI voting on python-fuelclient https://review.openstack.org/#/c/147429 https://review.openstack.org/#/c/147429 4. Add verify-python-fuelclient https://review.fuel-infra.org/#/c/1989 https://review.fuel-infra.org/#/c/1989 - romcheg 13 січ. 2015 о 15:58 Roman Prykhodchenko m...@romcheg.me написав(ла): Folks, this is another status update. The patch for moving python-fuelclient to a separate project has been merged. At the moment Stackforge repository, a Gerrit project and all Gerrit groups have been created. There are two guys in the core group: I and Dmitri Pyzhov (dpyz...@mirantis.com mailto:dpyz...@mirantis.com). You can obtain the sources from https://github.com/stackforge/python-fuelclient https://github.com/stackforge/python-fuelclient. I kindly ask authors of all changes to Fuel Client to start moving them to the new project. At the moment I’m working on enabling the same testing process in FuelCI, testing in OpenStack CI will be enabled later because that requires some refactoring of the existing tests in python-fuelclient. Stay tuned. - romcheg 12 січ. 2015 о 12:44 Roman Prykhodchenko m...@romcheg.me mailto:m...@romcheg.me написав(ла): Hi folks! This is a status update. Right now the patch for creating a new project on Stackforge is blocked by a bug in Zuul [1] which is actually a bug in python-daemon, the patch for this is already published [2] and waiting for being approved. After the patch is merged and all projects and groups are created I will file a request to perform initial setup of core groups. Once they are created it will be possible to land new patches. Meanwhile OSCI team is working [3] on adjusting build system to use python-fuelclient from PyPi [4]. Stay tuned for further updates. References: Zuul’s tests fail with dependencies error https://storyboard.openstack.org/#!/story/2000107 https://storyboard.openstack.org/#!/story/2000107 Pin python-daemon2.0 https://review.openstack.org/#/c/146350/ https://review.openstack.org/#/c/146350/ Create repositories for python-fuelclient package https://bugs.launchpad.net/fuel/+bug/1409673 https://bugs.launchpad.net/fuel/+bug/1409673 python-fuelclient on PyPi https://pypi.python.org/pypi/python-fuelclient https://pypi.python.org/pypi/python-fuelclient 9 січ. 2015 о 15:14 Roman Prykhodchenko m...@romcheg.me mailto:m...@romcheg.me написав(ла): Hi folks, according to the Fuel client refactoring plan [1] it’s necessary to move it out to a separate repository on Stackforge. The process of doing that consists of two major steps: - Landing a patch [2] to project-config for creating a new Stackforge project - Creating an initial core group for python-fuelclient - Moving all un-merged patches from fuel-web to python-fuelclient gerrit repo The first step of this process has already been started so I kindly ask all fuelers to DO NOT MERGE any new patches to fuel-web IF THEY DO touch fuelclient folder. After the project is set up I will let everyone know about that and will tell what to do after that so I encourage all interested people to check this thread once in a while. # References: 1. Re-thinking Fuel Client https://review.openstack.org/#/c/145843 https://review.openstack.org/#/c/145843 2. Add python-fuelclient to Stackforge https://review.openstack.org/#/c/145843 https://review.openstack.org/#/c/145843 - romcheg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using
Re: [openstack-dev] [horizon] static files handling, bower/
On 1/16/15 9:08 AM, Doug Hellmann wrote: We are, and as this conversation has veered off in a destructive direction, I think we should back up and look at the compromise Radomir posted [1] to see if that solves the original technical problem we all have. Does having the requirements specified in a JSON file, without requiring a specific build tool to install the files, solve the packaging, testing, and deployment issue on platforms where node.js isn’t supported natively right now? For Solaris, yes. We can make that work. Thanks, Radomir for the suggestion. -Drew __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to debug test cases in Openstack
On 01/16/2015 12:37 AM, Abhishek Talwar/HYD/TCS wrote: Hi, I have been trying to debug the test cases in OpenStack, but I am not getting successful with it. So if someone can help me with that. The last response from the dev-list was to use $ ./run_tests.sh -d [test module path] but this gives bDb quit error. Depends on the project. The majority of the projects have moved over to using tox. In Keystone, tox will run everything, which might be to much; tox -epy27 is usually what I run for unit tests and tox -epep8 explicitly for pep8 testing. To run a specific file full of tests: tox -e py27 test_v3_auth works as does tox -e py27 keysteon.tests.test_v3_auth.TestPKIZTokenAPIs So kindly help me this. -- Thanks and Regards Abhishek Talwar =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for 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] static files handling, bower/
Does having the requirements specified in a JSON file, without requiring a specific build tool to install the files, solve the packaging, testing, and deployment issue on platforms where node.js isn’t supported natively right now? We only support what we test. Unless I missed something, there are no platforms, relevant to horizon and openstack, in where nodejs is not supported natively. - Fedora 18 and later have a native nodejs package, infra offers versions 20/21. - CentOS delivers a native package via EPEL as of version 5. Infra includes the EPEL repository and offers CentOS 6/7. - Debian offers it as of Wheezy, Ubuntu as of Trusty. Infra's in the process of deprecating most of our Precise nodes, which I believe we're only keeping around for our python3.3 jobs (3.4 is already on trusty). Horizon only tests Python 2.7. Michael __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to debug test cases in Openstack
Abhishek, In addition to the tips above, i put up a post for using py.test and testtools.run as well here: https://davanum.wordpress.com/2015/01/13/quickly-running-a-single-openstack-nova-test/ -- dims On Fri, Jan 16, 2015 at 11:44 AM, Adam Young ayo...@redhat.com wrote: On 01/16/2015 12:37 AM, Abhishek Talwar/HYD/TCS wrote: Hi, I have been trying to debug the test cases in OpenStack, but I am not getting successful with it. So if someone can help me with that. The last response from the dev-list was to use $ ./run_tests.sh -d [test module path] but this gives bDb quit error. Depends on the project. The majority of the projects have moved over to using tox. In Keystone, tox will run everything, which might be to much; tox -epy27 is usually what I run for unit tests and tox -epep8 explicitly for pep8 testing. To run a specific file full of tests: tox -e py27 test_v3_auth works as does tox -e py27 keysteon.tests.test_v3_auth.TestPKIZTokenAPIs So kindly help me this. -- Thanks and Regards Abhishek Talwar =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] How to debug test cases in Openstack
Also note this script from the oslotest library: https://github.com/openstack/oslotest/blob/master/tools/oslo_debug_helper It was added specifically to allow debugging with pdb. I've never actually used it though. :-) -Ben On 01/16/2015 10:56 AM, Davanum Srinivas wrote: Abhishek, In addition to the tips above, i put up a post for using py.test and testtools.run as well here: https://davanum.wordpress.com/2015/01/13/quickly-running-a-single-openstack-nova-test/ -- dims On Fri, Jan 16, 2015 at 11:44 AM, Adam Young ayo...@redhat.com wrote: On 01/16/2015 12:37 AM, Abhishek Talwar/HYD/TCS wrote: Hi, I have been trying to debug the test cases in OpenStack, but I am not getting successful with it. So if someone can help me with that. The last response from the dev-list was to use $ ./run_tests.sh -d [test module path] but this gives bDb quit error. Depends on the project. The majority of the projects have moved over to using tox. In Keystone, tox will run everything, which might be to much; tox -epy27 is usually what I run for unit tests and tox -epep8 explicitly for pep8 testing. To run a specific file full of tests: tox -e py27 test_v3_auth works as does tox -e py27 keysteon.tests.test_v3_auth.TestPKIZTokenAPIs So kindly help me this. -- Thanks and Regards Abhishek Talwar =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver
On Wed, Jan 14, 2015 at 6:16 PM, Neil Jerram neil.jer...@metaswitch.com wrote: Maxime Leroy maxime.le...@6wind.com writes: Ok, thank you for the details. I will look how to implement this feature. Hi Maxime, Did you have time yet to start looking at this? My team now has a use case that could be met by using vif_plug_script, so I would be happy to help with writing the spec for that. Would that be of interest to you? Thanks, Neil Hi Neil, I have planned to look later how to implement this new feature. As we are in feature freeze for Nova and Neutron, there is no hurry right now. I think we need to have these 2 news specs ready before the next summit. Of course, any help is welcome ! ;) I have just created an etherpad to write the spec for Nova: https://etherpad.openstack.org/p/nova_vif_plug_script_spec Feel free to modify it. Thanks, Maxime __ OpenStack Development Mailing List (not for 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] static files handling, bower/
On Jan 16, 2015, at 11:33 AM, Drew Fisher drew.fis...@oracle.com wrote: On 1/16/15 9:08 AM, Doug Hellmann wrote: We are, and as this conversation has veered off in a destructive direction, I think we should back up and look at the compromise Radomir posted [1] to see if that solves the original technical problem we all have. Does having the requirements specified in a JSON file, without requiring a specific build tool to install the files, solve the packaging, testing, and deployment issue on platforms where node.js isn’t supported natively right now? For Solaris, yes. We can make that work. Thanks, Radomir for the suggestion. Great! 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] [horizon] static files handling, bower/
Doug, there still is one open question. Distributing JavaScript libraries via system packages is unusual. Because of that, most of the JavaScript libraries used by horizon don't have existing packages. Who will create and maintain the packages for these JavaScript libraries for production? For example, most of the libraries aren't available as debian or ubuntu packages. Updating a JavaScript dependency, such as angular, would mean each of the system packages needs to be updated as well as the Horizon project. Would would this process look like with packages on different systems needing updates? Using bower for development and system packages for production doesn't appear to be ready to start using. On Fri, Jan 16, 2015 at 12:09 PM, Doug Hellmann d...@doughellmann.com wrote: On Jan 16, 2015, at 11:33 AM, Drew Fisher drew.fis...@oracle.com wrote: On 1/16/15 9:08 AM, Doug Hellmann wrote: We are, and as this conversation has veered off in a destructive direction, I think we should back up and look at the compromise Radomir posted [1] to see if that solves the original technical problem we all have. Does having the requirements specified in a JSON file, without requiring a specific build tool to install the files, solve the packaging, testing, and deployment issue on platforms where node.js isn’t supported natively right now? For Solaris, yes. We can make that work. Thanks, Radomir for the suggestion. Great! Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Review Day on Monday
Hi, I will join to review on Monday from US time zone. I hope someone will be in IRC to chat. Thanks Georgy On Fri, Jan 16, 2015 at 7:45 AM, Serg Melikyan smelik...@mirantis.com wrote: Hi Team, I would like to announce another Review Day schedule on Monday (Jan 19). During New Year Christmas holidays our CI was broken, and queue with change-requests is now quote long. And what is more important, many patches and specs related to Policy Guided Fulfillment are need to be reviewed, we had not so much time to review them, and I propose to do it on Monday. -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com +7 (495) 640-4904, 0261 +7 (903) 156-0836 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Remove deprecation properties
Hi, Murano uses Heat templates with almost all available resources. Neutron resources are definitely used. I think Murano can update our Heat resources handling properly, but there are at least two scenarios which should be considered: 1) Murano generated stacks are long lasting. Murano uses stack update to modify stacks so it is expected that stack update process is not affected by Heat upgrade and resource schema deprecation. 2) Murano uses application packages which contain HOT snippets. Application authors heavily rely on backward compatibility so that applications written on Icehouse version should work on later OpenStack versions. If it is not the case there should be some mechanism to automatically translate old resource schema to a new one. I hope all the changes will be documented somewhere. I think it will be good to have a wiki page with a list of schema versions and changes. This will help Heat users to modify their templates accordingly. Another potential issue I see is the fact that it is quite often when multiple versions of OpenStack are used in data centers. Like previous version in production and new versions of OpenStack are in stage and Dev environment which are used to prepare for production upgrade and current development. If these different versions of OpenStack will require different version of Heat templates it might be a problem as instead of upgrading just infrastructure services one will need to synchronously upgrade different external components which rely on Heat templates. Thanks Georgy On Fri, Jan 16, 2015 at 5:10 AM, Sergey Kraynev skray...@mirantis.com wrote: Steve, Thanks for the feedback. On 16 January 2015 at 15:09, Steven Hardy sha...@redhat.com wrote: On Thu, Dec 25, 2014 at 01:52:43PM +0400, Sergey Kraynev wrote: Hi all. In the last time we got on review several patches, which removes old deprecation properties [1],A and one mine [2]. The aim is to delete deprecated code and redundant tests. It looks simple, but the main problem, which we met, is backward compatibility. F.e. user has created resource (FIP) with old property schema, i.e. using SUBNET_ID instead of SUBNET. On first look nothing bad will not happen, because: FWIW I think it's too soon to remove the Neutron subnet_id/network_id properties, they were only deprecated in Juno [1], and it's evident that users are still using them on icehouse [2] I thought the normal deprecation cycle was at least two releases, but I can't recall where I read that. Considering the overhead of maintaining these is small, I'd favour leaning towards giving more time for users to update their templates, rather then breaking them via very aggresive removal of deprecated interfaces. Honestly I thought, that we use 1 release cycle, but I have not any objections to do it after two releases. Will be glad to know what is desired deprecation period. I'd suggest some or all of the following: - Add a planned for removal in $release to the SupportStatus string associated with the deprecation, so we can document the planned removal. - Wait for at least two releases between deprecation and removal, and announce the interfaces which will be removed in the release notes for the release before removal e.g: - Deprecated in Juno - Announce planned removal in Kilo release notes - Remove in J I like this idea, IMO it will make our deprecation process clear. [1] https://review.openstack.org/#/c/82853/ [2] http://lists.openstack.org/pipermail/openstack/2015-January/011156.html 1. handle_delete use resource_id and any changes in property schema does not affect other actions. 2. If user want to use old template, he will get adequate error message, that this property is not presented in schema. After that he just should switch to new property and update stack using this new property. In the same time we have one big issues for shadow dependencies, which is actual for neutron resources. The simplest approach will not be worked [3], due to old properties was deleted from property_schema. Why is it bad ? - we will get again all bugs related with such dependencies. - how to make sure:A A A - create stack with old property (my template [4]) A A - open horizon, and look on topology A A - download patch [2] and restart engine A A - reload horizon page with topology A A - as result it will be different A I have some ideas about how to solve this, but none of them is not enough good for me: A - getting such information from self.properties.data is bad, because we will skip all validations mentioned in properties.__getitem__ A - renaming old key in data to new or creating copy with new key is not correct for me, because in this case we actually change properties (resource representation) invisibly from user.
Re: [openstack-dev] [horizon] static files handling, bower/
On Jan 16, 2015, at 12:55 PM, Matthew Farina m...@mattfarina.com wrote: Doug, there still is one open question. Distributing JavaScript libraries via system packages is unusual. Because of that, most of the JavaScript libraries used by horizon don't have existing packages. Who will create and maintain the packages for these JavaScript libraries for production? For example, most of the libraries aren't available as debian or ubuntu packages. Updating a JavaScript dependency, such as angular, would mean each of the system packages needs to be updated as well as the Horizon project. Would would this process look like with packages on different systems needing updates? Using bower for development and system packages for production doesn't appear to be ready to start using. We have, so far, relied on the distributors to build packages in whatever way works for their tools. What is it about JavaScript libraries that makes packaging them “unusual”? If we’re going to continue to rely on distributors to handle the packaging, the next step is to get some of the distribution packagers to chime in on what else might be useful to make their jobs easier. We’ve collaborated in the past by adding features or writing some of our own tools (that’s part of what led to pbr being created for python packages, for example). This thread is fairly long, so you might want to start a new one with an appropriate subject line to attract the right input. Was there a spec for this work? If not, that would be useful to have. On Fri, Jan 16, 2015 at 12:09 PM, Doug Hellmann d...@doughellmann.com mailto:d...@doughellmann.com wrote: On Jan 16, 2015, at 11:33 AM, Drew Fisher drew.fis...@oracle.com mailto:drew.fis...@oracle.com wrote: On 1/16/15 9:08 AM, Doug Hellmann wrote: We are, and as this conversation has veered off in a destructive direction, I think we should back up and look at the compromise Radomir posted [1] to see if that solves the original technical problem we all have. Does having the requirements specified in a JSON file, without requiring a specific build tool to install the files, solve the packaging, testing, and deployment issue on platforms where node.js isn’t supported natively right now? For Solaris, yes. We can make that work. Thanks, Radomir for the suggestion. Great! Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Neutron ML2][VMWare]NetworkNotFoundForBridge: Network could not be found for bridge br-int
neophy,
It seems like there are left overs that fuel was using in the config
that would not be present when you installed neutron fresh. I'd
compare the config files and start backing out bits you dont need. I'd
start with the lines refrencing br-int, you dont need them on nodes
that aren't using the ovs agent.
Poke me on IRC if you need more help
Xarses (GMT-8)
On Fri, Jan 9, 2015 at 1:08 PM, Foss Geek thefossg...@gmail.com wrote:
Dear All,
I am trying to integrate Openstack + vCenter + Neutron + VMware dvSwitch ML2
Mechanism driver.
I deployed a two node openstack environment (controller + compute with KVM)
with Neutron VLAN + KVM using fuel 5.1. Again I installed nova-compute using
yum in controller node and configured nova-compute in controller to point
vCenter. I am also using Neutron VLAN with VMware dvSwitch ML2 Mechanism
driver. My vCenter is properly configured as suggested by the doc:
https://www.mirantis.com/blog/managing-vmware-vcenter-resources-mirantis-openstack-5-0-part-1-create-vsphere-cluster/
I am able to create network from Horizon and I can see the same network
created in vCenter. When I try to create a VM I am getting the below error
in Horizon.
Error: Failed to launch instance test-01: Please try again later [Error:
No valid host was found. ].
Here is the error message from Instance Overview tab:
Instance Overview
Info
Name
test-01
ID
309a1f47-83b6-4ab4-9d71-642a2000c8a1
Status
Error
Availability Zone
nova
Created
Jan. 9, 2015, 8:16 p.m.
Uptime
0 minutes
Fault
Message
No valid host was found.
Code
500
Details
File /usr/lib/python2.6/site-packages/nova/scheduler/filter_scheduler.py,
line 108, in schedule_run_instance raise exception.NoValidHost(reason=)
Created
Jan. 9, 2015, 8:16 p.m
Getting the below error in nova-all.log:
183Jan 9 20:16:23 node-18 nova-api 2015-01-09 20:16:23.135 31870 DEBUG
keystoneclient.middleware.auth_token
[req-c9ec0973-ff63-4ac3-a0f7-1d2d7b7aa470 ] Authenticating user token
__call__
/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:676
183Jan 9 20:16:23 node-18 nova-api 2015-01-09 20:16:23.136 31870 DEBUG
keystoneclient.middleware.auth_token
[req-c9ec0973-ff63-4ac3-a0f7-1d2d7b7aa470 ] Removing headers from request
environment:
X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User-Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role
_remove_auth_headers
/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:733
183Jan 9 20:16:23 node-18 nova-api 2015-01-09 20:16:23.137 31870 DEBUG
keystoneclient.middleware.auth_token
[req-c9ec0973-ff63-4ac3-a0f7-1d2d7b7aa470 ] Returning cached token
_cache_get
/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:1545
183Jan 9 20:16:23 node-18 nova-api 2015-01-09 20:16:23.138 31870 DEBUG
keystoneclient.middleware.auth_token
[req-c9ec0973-ff63-4ac3-a0f7-1d2d7b7aa470 ] Storing token in cache store
/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:1460
183Jan 9 20:16:23 node-18 nova-api 2015-01-09 20:16:23.139 31870 DEBUG
keystoneclient.middleware.auth_token
[req-c9ec0973-ff63-4ac3-a0f7-1d2d7b7aa470 ] Received request from user:
4564fea80fa14e1daed160afa074d389 with project_id :
dd32714d9009495bb51276e284380d6a and roles: admin,_member_
_build_user_headers
/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:996
183Jan 9 20:16:23 node-18 nova-api 2015-01-09 20:16:23.141 31870 DEBUG
routes.middleware [req-05089e83-e4c1-4d90-b7c5-065226e55d91 ] Matched GET
/dd32714d9009495bb51276e284380d6a/servers/309a1f47-83b6-4ab4-9d71-642a2000c8a1
__call__ /usr/lib/python2.6/site-packages/routes/middleware.py:100
183Jan 9 20:16:23 node-18 nova-api 2015-01-09 20:16:23.142 31870 DEBUG
routes.middleware [req-05089e83-e4c1-4d90-b7c5-065226e55d91 ] Route path:
'/{project_id}/servers/:(id)', defaults: {'action': u'show', 'controller':
nova.api.openstack.wsgi.Resource object at 0x43e2550} __call__
/usr/lib/python2.6/site-packages/routes/middleware.py:102
183Jan 9 20:16:23 node-18 nova-api 2015-01-09 20:16:23.142 31870 DEBUG
routes.middleware [req-05089e83-e4c1-4d90-b7c5-065226e55d91 ] Match dict:
{'action': u'show', 'controller': nova.api.openstack.wsgi.Resource object
at 0x43e2550, 'project_id': u'dd32714d9009495bb51276e284380d6a', 'id':
u'309a1f47-83b6-4ab4-9d71-642a2000c8a1'} __call__
/usr/lib/python2.6/site-packages/routes/middleware.py:103
183Jan 9 20:16:23 node-18 nova-api 2015-01-09 20:16:23.143 31870 DEBUG
nova.api.openstack.wsgi [req-05089e83-e4c1-4d90-b7c5-065226e55d91 None]
Calling method 'bound method Controller.show of
nova.api.openstack.compute.servers.Controller object at 0x4204290'
(Content-type='None', Accept='application/json') _process_stack
Re: [openstack-dev] [neutron] Changes to the core team
+1 On Thu, Jan 15, 2015 at 3:31 PM, Kyle Mestery mest...@mestery.com wrote: The last time we looked at core reviewer stats was in December [1]. In looking at the current stats, I'm going to propose some changes to the core team. Reviews are the most important part of being a core reviewer, so we need to ensure cores are doing reviews. The stats for the 90 day period [2] indicate some changes are needed for core reviewers who are no longer reviewing on pace with the other core reviewers. First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has been a core reviewer for a long time, and his past contributions are very much thanked by the entire OpenStack Neutron team. If Sumit jumps back in with thoughtful reviews in the future, we can look at getting him back as a Neutron core reviewer. But for now, his stats indicate he's not reviewing at a level consistent with the rest of the Neutron core reviewers. As part of the change, I'd like to propose Doug Wiegley as a new Neutron core reviewer. Doug has been actively reviewing code across not only all the Neutron projects, but also other projects such as infra. His help and work in the services split in December were the reason we were so successful in making that happen. Doug has also been instrumental in the Neutron LBaaS V2 rollout, as well as helping to merge code in the other neutron service repositories. I'd also like to take this time to remind everyone that reviewing code is a responsibility, in Neutron the same as other projects. And core reviewers are especially beholden to this responsibility. I'd also like to point out that +1/-1 reviews are very useful, and I encourage everyone to continue reviewing code even if you are not a core reviewer. Existing neutron cores, please vote +1/-1 for the addition of Doug to the core team. Thanks! Kyle [1] http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html [2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] no team meeting 19 Jan
Monday 19 Jan is a holiday for some here in the US, so let’s skip meeting this week. We’ll reconvene on 26 Jan at the usual time. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Next week's meeting is cancelled (and some other notes)
Folks: It's a holiday in the US next Monday [1], so I'm going to cancel the weekly Neutron team meeting. We'll reconvene per the normal schedule [2] next on Tuesday, January 27 (my birthday!) at 1400 UTC. One thing I'd like to mention here is on the topic of reviewing code. When reviewing code in Neutron, please make sure you're looking at approved BPs for reviews. In this case, we should be actively reviewing Kilo-2 BPs [3]. The links to the reviews are in the BPs themselves. Until someone builds a better integrated dashboard for gerrit that takes into account the LP priority, this is the best I can offer you. But I encourage people to please prioritize their reviews by looking at BPs approved rather than just popping gerrit up and starting at the top of what it presents you. Thanks, have a great weekend everyone! Kyle [1] http://en.wikipedia.org/wiki/Martin_Luther_King,_Jr._Day [2] https://wiki.openstack.org/wiki/Network/Meetings [3] https://launchpad.net/neutron/+milestone/kilo-2 __ OpenStack Development Mailing List (not for 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]When will fuel support centos 7?
Hi, Frankly speaking, Fuel team cares about stability and production readiness. That requires a lot of testing, some modification to the packages before releasing Fuel with CentOS 7 support. At the moment Fuel Team is focusing on Ubuntu 14.04 as it's targeted to 6.1. CentOS 7.0 is targeted to Fuel 7.0. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Fri, Jan 16, 2015 at 9:04 AM, me,apporc appleorchard2...@gmail.com wrote: So what's the difficulty of supporting centos ? If i want to help to make it happen, do you have some advice? On Thu Jan 15 2015 at 8:33:20 PM Mike Scherbakov mscherba...@mirantis.com wrote: CentOS 7 is not considered as essential / critical priority blueprint for Fuel 6.1. There is a plan to support new version of CentOS, and I know some folks started a research/move in this direction in some areas, such as l23network puppet module for instance. It would be great to see help to make it happen in Fuel 7.0, if not in 6.1. On Thu, Jan 15, 2015 at 3:22 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi, Yes, we do have a plan for CentOS 7, but as far as I know it was postponed to MOS 7.0. That means we will not have Cent OS 7 in upcoming release. - Igor On Thu, Jan 15, 2015 at 1:16 PM, me,apporc appleorchard2...@gmail.com wrote: Hi, Do we have plan for centos 7 ? Regards, apporc __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for 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] Next week's meeting is cancelled (and some other notes)
It’s not pretty, but if the topic has been set correctly, this finds everything open with a Kilo-2 blueprint: https://review.openstack.org/#/q/project:openstack/neutron+status:open+(topic:bp/wsgi-pecan-switch+OR+topic:bp/plugin-interface-perestroika+OR+topic:bp/reorganize-unit-test-tree+OR+topic:bp/restructure-l2-agent+OR+topic:bp/rootwrap-daemon-mode+OR+topic:bp/retargetable-functional-testing+OR+topic:bp/refactor-iptables-firewall-driver+OR+topic:bp/vsctl-to-ovsdb+OR+topic:bp/lbaas-api-and-objmodel-improvement+OR+topic:bp/restructure-l3-agent+OR+topic:bp/neutron-ovs-dvr-vlan+OR+topic:bp/allow-specific-floating-ip-address+OR+topic:bp/ipset-manager-refactor+OR+topic:bp/agent-child-processes-status+OR+topic:bp/extra-dhcp-opts-ipv4-ipv6+OR+topic:bp/ipsec-strongswan-driver+OR+topic:bp/ofagent-bridge-setup+OR+topic:bp/arp-spoof-patch-ebtables+OR+topic:bp/report-ha-router-master+OR+topic:bp/conntrack-in-security-group+OR+topic:bp/allow-mac-to-be-updated+OR+topic:bp/specify-router-ext-ip+OR+topic:bp/a10-lbaas-v2-driver+OR+topic:bp/brocade-vyatta-fwaas-plugin+OR+topic:bp/netscaler-lbaas-v2-driver+OR+topic:bp/ofagent-sub-driver+OR+topic:bp/ml2-cisco-nexus-mechdriver-providernet+OR+topic:bp/ofagent-flow-based-tunneling+OR+topic:bp/ml2-ovs-portsecurity+OR+topic:bp/fwaas-cisco+OR+topic:bp/freescale-fwaas-plugin+OR+topic:bp/rpc-docs-and-namespace),n,z From: Kyle Mestery mest...@mestery.commailto:mest...@mestery.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, January 16, 2015 at 1:33 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [neutron] Next week's meeting is cancelled (and some other notes) Folks: It's a holiday in the US next Monday [1], so I'm going to cancel the weekly Neutron team meeting. We'll reconvene per the normal schedule [2] next on Tuesday, January 27 (my birthday!) at 1400 UTC. One thing I'd like to mention here is on the topic of reviewing code. When reviewing code in Neutron, please make sure you're looking at approved BPs for reviews. In this case, we should be actively reviewing Kilo-2 BPs [3]. The links to the reviews are in the BPs themselves. Until someone builds a better integrated dashboard for gerrit that takes into account the LP priority, this is the best I can offer you. But I encourage people to please prioritize their reviews by looking at BPs approved rather than just popping gerrit up and starting at the top of what it presents you. Thanks, have a great weekend everyone! Kyle [1] http://en.wikipedia.org/wiki/Martin_Luther_King,_Jr._Day [2] https://wiki.openstack.org/wiki/Network/Meetings [3] https://launchpad.net/neutron/+milestone/kilo-2 __ OpenStack Development Mailing List (not for 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] Next week's meeting is cancelled (and some other notes)
I'm pretty sure you just destroyed everyone's vision with that. On Fri, 2015-01-16 at 21:23 +, Doug Wiegley wrote: It’s not pretty, but if the topic has been set correctly, this finds everything open with a Kilo-2 blueprint: https://review.openstack.org/#/q/project:openstack/neutron+status:open +(topic:bp/wsgi-pecan-switch+OR+topic:bp/plugin-interface-perestroika +OR+topic:bp/reorganize-unit-test-tree+OR +topic:bp/restructure-l2-agent+OR+topic:bp/rootwrap-daemon-mode+OR +topic:bp/retargetable-functional-testing+OR +topic:bp/refactor-iptables-firewall-driver+OR+topic:bp/vsctl-to-ovsdb +OR+topic:bp/lbaas-api-and-objmodel-improvement+OR +topic:bp/restructure-l3-agent+OR+topic:bp/neutron-ovs-dvr-vlan+OR +topic:bp/allow-specific-floating-ip-address+OR +topic:bp/ipset-manager-refactor+OR +topic:bp/agent-child-processes-status+OR +topic:bp/extra-dhcp-opts-ipv4-ipv6+OR +topic:bp/ipsec-strongswan-driver+OR+topic:bp/ofagent-bridge-setup+OR +topic:bp/arp-spoof-patch-ebtables+OR+topic:bp/report-ha-router-master +OR+topic:bp/conntrack-in-security-group+OR +topic:bp/allow-mac-to-be-updated+OR+topic:bp/specify-router-ext-ip+OR +topic:bp/a10-lbaas-v2-driver+OR+topic:bp/brocade-vyatta-fwaas-plugin +OR+topic:bp/netscaler-lbaas-v2-driver+OR+topic:bp/ofagent-sub-driver +OR+topic:bp/ml2-cisco-nexus-mechdriver-providernet+OR +topic:bp/ofagent-flow-based-tunneling+OR +topic:bp/ml2-ovs-portsecurity+OR+topic:bp/fwaas-cisco+OR +topic:bp/freescale-fwaas-plugin+OR +topic:bp/rpc-docs-and-namespace),n,z From: Kyle Mestery mest...@mestery.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Friday, January 16, 2015 at 1:33 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: [openstack-dev] [neutron] Next week's meeting is cancelled (and some other notes) Folks: It's a holiday in the US next Monday [1], so I'm going to cancel the weekly Neutron team meeting. We'll reconvene per the normal schedule [2] next on Tuesday, January 27 (my birthday!) at 1400 UTC. One thing I'd like to mention here is on the topic of reviewing code. When reviewing code in Neutron, please make sure you're looking at approved BPs for reviews. In this case, we should be actively reviewing Kilo-2 BPs [3]. The links to the reviews are in the BPs themselves. Until someone builds a better integrated dashboard for gerrit that takes into account the LP priority, this is the best I can offer you. But I encourage people to please prioritize their reviews by looking at BPs approved rather than just popping gerrit up and starting at the top of what it presents you. Thanks, have a great weekend everyone! Kyle [1] http://en.wikipedia.org/wiki/Martin_Luther_King,_Jr._Day [2] https://wiki.openstack.org/wiki/Network/Meetings [3] https://launchpad.net/neutron/+milestone/kilo-2 __ OpenStack Development Mailing 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] [barbican] Retiring python-barbicanclient 2.x
Hi openstack-dev@, The barbican team would like to retire the 2.x branch of python-barbicanclient in favor of the 3.x branch: https://review.openstack.org/#/c/146231/ The 3.x branch of python-barbicanclient represents a major improvement of the Barbican client. The main breaking change between the 2.x and 3.x clients is the adoption of Keystone Sessions exclusively for authentication, so all python-barbicanclient specific authentication mechanisms from 2.x were removed. The 3.x branch also includes a few changes to the Secret and Order models to make them more usable. Specifically, both Orders and Secrets hold a handle to their respective EntityManager, so you don’t have to juggle two different objects to work with a single entity. e.g. Storing a secret can now be done by calling Secret.store() on the secret instance. Thanks, -Douglas Mendizábal Douglas Mendizábal IRC: redrobot PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C __ OpenStack Development Mailing 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] Project Idea: IDS integration.
Hello, Neutron developers. My name is Mario and I am a Masters student in Networking and Security. I am considering the possibility of integrating IDS technology to Neutron as part of my Masters project. As there are many flavors of open ID[P]S out there and those might follow different philosophies, my approach would be developing a Neutron plugin that might cover IDS integration as a service and also a driver (or more, depending on time constraints) to cover the specifics of an IDS. Following the nature of Neutron and OpenStack projects these drivers would be developed for Free and Open Software IDSs and the plugin would be as vendor-agnostic as possible. In order to achieve that the plugin would have to deal with the need for logging and alerting. The time window I have for the development of this project goes from February to the end of June and I would be able to allocate around 5h a week to it. Now, I would like to know your opinion on this idea, given that you know the project inside out and you are the ones making it happen day after day. Do you think there is usefulness on bringing that functionality inside the Neutron project (as a plugin)? I'd prefer do something that contributes to it rather than a one-shot piece of software that will be stored on a shelf. I'd like to know if you think that what I am proposing is possible in terms of time and features or if it seems to be just the delusion of an ignorant. Do you think the component should also have the capability to change security-related policies, like load-balancing and firewall rules as to react to identified threats? I would appreciate any insight you could give me about this idea, or any other I could help with instead. Thank you for your attention, Mario __ OpenStack Development Mailing 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] sos-ci for cinder scst
Hi *,* localconf.base file in sos-ci/sos-ci/tempates have *CINDER_BRANCH = master* *volume_driver=cinder.volume.drivers.solidfire.SolidFireDriver* similarly in our localconf.base file,we have *CINDER_BRANCH = master[[post-config|$CINDER_CONF]] [lvmdriver-1] iscsi_helper=scstadminvolume_driver = cinder.volume.drivers.lvm.LVMISCSIDriver* when sos-ci launch instance and try to install devstack with *CINDER_BRANCH=gerrit event patch reference*,cinder-volume service is unable to start. Because our code is not in master for this local.conf to be run by LVMISCSIDriver. As far we know,we should not give* CINDER_BRANCH=refs/changes/78/145778/1* in our localconf.base,because sos-ci is setting CINDER_BRANCH with gerrit event stream events patch reference. Regards Nikesh __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
