Re: [openstack-dev] Segmentation Fault in nova-compute service on ARM platform.
Havana is very very old and no longer supported. Why are you porting that release in particular? Michael On Tue, Jul 7, 2015 at 3:51 PM, Pradeep kumar topradeepyaduvan...@gmail.com wrote: Hi Guys, I am porting openstack on arm platform, but while running nova-compute service on it throws segmentaion fault. Below are the logs: 2015-06-05 09:24:12.195 11374 INFO nova.virt.driver [-] Loading compute driver 'libvirt.LibvirtDriver' 2015-06-05 09:24:13.483 11374 INFO nova.openstack.common.rpc.common [req-ba16a115-ed64-4fb5-b13e-f28e03a28b24 None None] Connected to AMQP server on 192.168.1.100:5672 2015-06-05 09:24:13.600 11374 INFO nova.openstack.common.rpc.common [req-ba16a115-ed64-4fb5-b13e-f28e03a28b24 None None] Connected to AMQP server on 192.168.1.100:5672 2015-06-05 09:24:13.808 11374 AUDIT nova.service [-] Starting compute node (version 2013.2.2) Program received signal SIGSEGV, Segmentation fault. 0x76f244d4 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 While tracing the same with gdb: I am getting corrupt stack: (gdb) bt #0 0x76f244d4 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 #1 0x76f2ab78 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0 #2 0x76f2905c in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 #3 0x76f2ab78 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0 #4 0x76eaf690 in ?? () from /usr/lib/libpython2.7.so.1.0 Cannot access memory at address 0x0 #5 0x76eaf690 in ?? () from /usr/lib/libpython2.7.so.1.0 Cannot access memory at address 0x0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) The function PyEval_EvalFrameEx () is present in ceval.c Also I am using havana release of openstack. I am new to openstack just tried openstack nodes on x-86 platform. Any help in order to solve the above issue is appreciated. Regards Pradeep Kumar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Rackspace Australia __ OpenStack Development Mailing 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] Thoughts on ReleaseNoteImpact git commit message tag
While reviewing a change in nova [1] I mentioned that we should have something in the release notes for Liberty on the change. Typically for this I ask that the UpgradeImpact tag is added to the commit message because at the end of a release I search git/gerrit for any commits that have UpgradeImpact in them since the last major release (Kilo in this case) and then we should see if those need mentioning in the release notes upgrade impacts section for Nova (which they usually do). The thing is, UpgradeImpact isn't always appropriate for the change, but DocImpact is used too broadly and as far as I can tell, it's not really for updating release notes [2]. It's for updating stuff found in docs.openstack.org. So we kicked around the idea of a ReleaseNoteImpact tag so that we can search for those at the end of the release in addition to UpgradeImpact. Are any other projects already doing something like this? Or do we just stick with UpgradeImpact? Per the docs [3] it mentions release notes but for configuration changes - which not everything in the release notes for an upgrade impact requires a config change, some are behavior/usage changes. In this specific case in [1], it's actually probably an APIImpact, albeit indirectly. Anyway, just putting this out there to see how other projects are handling tagging changes for inclusion in the release notes. [1] https://review.openstack.org/#/c/189632/ [2] https://wiki.openstack.org/wiki/Documentation/DocImpact [3] http://docs.openstack.org/infra/manual/developers.html#peer-review -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Nova Liberty Midcyle agenda
Hi, It would be great to start writing down ideas of what you want to discuss at the midcycle: https://etherpad.openstack.org/p/liberty-nova-midcycle I have also added a draft agenda, but we will discuss and decide that details on the day, in the usual un-conference style. For more details about the midcycle, please see: https://wiki.openstack.org/wiki/Sprints/NovaLibertySprint Thanks, johnthetubaguy PS There are some plans for some form of remote participation. It may not work out well, but we can give it a try. The plan is to share details in #openstack-nova on the day __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla][tc] Plans for using Pre-2.0 Ansible modules
Steve, We will need some of the modules from the merge-it-all branch of emoty's fork[1]. If it is more convient, you can just grab them all. The ones we require to proceed without triggering Option #4 would be the keystone related modules. That list is as follows: os_auth.py os_keystone_domain.py os_keystone_endpoint.py os_keystone_role.py os_keystone_service.py os_user.py os_user_group.py os_user_role.py I would also suggest to use git-submodule to add these directly to the ansible/library folder for Kolla. Assuming this doesn't still somehow taint the license or violate some stackforge rule. This too would only be temporary until Ansible 2.0. [1] https://github.com/emonty/ansible-modules-core/tree/merge-it-all/cloud/openstack Sam Yaple 864-901-0012 On Fri, Jul 3, 2015 at 1:56 PM, Greg DeKoenigsberg g...@ansible.com wrote: Option 3 sounds fine to me. We hope to have 2.0 out in August, so one hopes you wouldn't have to carry them very long. --g On Fri, Jul 3, 2015 at 2:53 PM, Steven Dake (stdake) std...@cisco.com wrote: Kolla Devs as well as the Technical Committee, I wanted to get the TC’s thoughts on this plan of action as we intend to apply for big tent once our Ansible code has completed implementation. If the approach outlined in this email seems like a blocker and we should just start with #4 instead, it would be immensely helpful to know now. The problem: A whole slew of OpenStack modules exist upstream in the Ansible core directory. Kolla wants to use these modules. These files are licensed under the GPLv3. They will be released with Ansible 2.0 but Ansible 2.0 is not yet available. In the meantime we need these modules to execute our system. The repo in question is: https://github.com/ansible/ansible-modules-core The possible solutions: 1. Mordred suggested just merging the code in our repo, but I thought this might trigger license contamination so I am not hot on this idea. 2. Relicense the upstream modules in ASL short term. Mordred tried this but thinks its not possible because of the varied contributors. 3. Fork the repo In question, remove everything except cloud/openstack directory and turn this into a pip installable library. 4. Make a hacky solution that doesn’t use any upstream modules but gets the job done. For the moment we have settled on #3, that is creating a repo here: https://github.com/sdake/kolla-pre-ansible-2-openstack/ And installing these in the deployment system. Once Ansible 2.0 is available, we would deprecate this model, and rely on Ansible 2.0 exclusively. Thoughts or concerns on this approach? Thanks -steve -- Greg DeKoenigsberg Ansible Community Guy Find out why SD Times named Ansible their #1 Company to Watch in 2015: http://sdtimes.com/companies-watch-2015/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral][Horizon][Tuskar-ui] Mistral Dashboard
Hi, Unless this is a strict requirement for OpenStack projects to move to AngularJS I’d prefer to keep existing framework within Mistral for purely time/resources reason. I believe such a transition will take weeks. I’m not an expert in UI stuff and Horizon specifically so it would be helpful to get input from someone else working in Horizon team. Zhenguo, thanks for bringing this up. Renat Akhmerov @ Mirantis Inc. On 07 Jul 2015, at 13:16, niuzhenguo niuzhen...@huawei.com wrote: Hi folks, As Horizon is moving towards an Angular application, I think it’s high time that we should make a standard for other projects which want to horizon compatible on whether they should based on Angular Dashboard or the current Horizon framework. For new project, I think it makes more sense to build the dashboard on Angular. But for “old” project like Mistral-Dashboard and Tuskar-UI, they works fine with Django framework now, do they have to move towards Angular also, and when that should be done. -zhenguo __ 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
Re: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team
Huge +1 !! On 07/06/2015 12:02 PM, Kevin Benton wrote: Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year has been important in making the reference implementation reliable. Existing cores, please vote +1/-1 for his addition to the team. Cheers! 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html 2. http://stackalytics.com/report/contribution/neutron/30 http://stackalytics.com/report/contribution/neutron/60 http://stackalytics.com/report/contribution/neutron/90 -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] App Catalog IRC meeting minutes - 7/2/2015
On 07/07/15 04:25, Christopher Aedo wrote: * Stale URL checker (gosha) (docaedo, 17:27:48) The docs-tools repository has a tool that does this that can probably be re-purposed. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Mistral][Horizon][Tuskar-ui] Mistral Dashboard
Hi folks, As Horizon is moving towards an Angular application, I think it's high time that we should make a standard for other projects which want to horizon compatible on whether they should based on Angular Dashboard or the current Horizon framework. For new project, I think it makes more sense to build the dashboard on Angular. But for old project like Mistral-Dashboard and Tuskar-UI, they works fine with Django framework now, do they have to move towards Angular also, and when that should be done. -zhenguo __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] How to handle security issues in external repos?
Jeremy Stanley wrote: On 2015-07-06 20:25:25 +0200 (+0200), Henry Gessau wrote: Jeremy, a huge thanks for this fantastic reply! I have taken the liberty of copying your responses directly into Neutron's contributing guide: https://review.openstack.org/187267 I hope you don't mind. Quite the opposite--I'm happy to be able to help! I'll likely rework my E-mail or write something else similar as an addition to some of the documentation the VMT currently maintains, so hopefully in time you can just link to it from within that devref. Some of it sounds like project-team-guide material, too. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Discuss simulated-execution-mode-murano-engine blueprint
Hi Gosha,
In my understanding, the base test class (io.murano.tests.TestFixture)
should have something like assertRaises method, similar to the one in python
--
Regards,
Alexander Tivelkov
On Mon, Jul 6, 2015 at 9:47 PM, Georgy Okrokvertskhov
gokrokvertsk...@mirantis.com wrote:
Hi Kate,
MuraPL has a concept of exceptions. Unit testing will be important to make
sure that workflows behaves correctly in exceptions situations. How will be
this addressed int he testing framework? Will you have some specific
assertions like python unit testing framework?
Thanks
Gosha
On Mon, Jul 6, 2015 at 9:02 AM, Ekaterina Chernova efedor...@mirantis.com
wrote:
Folks,
I have specific topic to discuss: how murano test-fixture will look like
and how it can be run.
The idea is to implement a unit-testing framework, similar to regular
frameworks for python or other languages,
which will allow to define test fixtures in MuranoPL.
A Test fixture is a regular muranoPL class definition, which methods are
the test cases.
When such fixture is included into Murano application package the
deployment of application may be tested without running actual VM's.
Here is how the test fixture may look like:
Namespaces:
=: io.murano.apps.foo.tests
sys: io.murano.system
pckg: io.murano.apps.foo
Extends: io.murano.tests.TestFixture
Name: FooTest
Methods:
initialize:
Body:
*# Object model can be loaded from json file, or provided
directly in murano-pl code as a yaml insertion.*
*# - $.appJson:
new(sys:Resources).json('foo-test-object-model.json')*
- $.appJson:
- ?:
type: io.murano.apps.foo.FooApp
name: my-foo-obj
instance:
?:
type: io.murano.resources.Instance
...
setUp:
Body:
- $.env: $.createEnvironment($.appJson) # creates an
instance of std:Environment
- $.myApp:
$.env.applications.where($.name='my-foo-obj').first()
*# mock instance spawning*
- mock($.myApp.instance, deploy, mockInstanceDeploy,
$this)
- mock(res:Instance, deploy, mockInstanceDeploy, $this)
testFooApp:
Body:
- $.env.deploy()
- $.assertEqual(true, $.myApp.getAttr('deployed'))
mockInstanceDeploy:
Arguments:
- mockContext
Body:
- Return:
* # heat template*
io.murano.tests.TestFixture - is a base class, that contains set of
methods, needed in all the test-cases which inherit it, such as assertEqual
and other similar assertions.
All it contains a $.createEnvironment method which may be called at the
setUp phase (a method being run before each test case) to construct the
object model to run the test against.
Test developer will be able to mock some of the functions or method which
are out of the scope of the current test
(for example, interaction with other applications or classes from the
standard murano library, such as instance.deploy etc).
The mock will allow to override the actual method execution and provide
the expected output of the method.
The actual implementation of mocking requires more thoughtful design,
so I'll create a separate spec for it.
What do you think about the overall idea and the test syntax proposed
above?
On Wed, Jun 3, 2015 at 5:15 PM, Ekaterina Chernova
efedor...@mirantis.com wrote:
Hi all!
I'd like to discuss first implementation thoughts about this [1]
blueprint, that we want to implement in Liberty.
This feature is supposed to increase the speed of application
development.
Now engine interacts with API to get input task and packages.
Items, planned to implement first would enable loading local task and
new package, without API and Rabbit involved.
After that simple testing machinery will be added to MuranoPL: mock
support and simple test-runner.
So user can test application methods as he wants by creating simple
tests.
Deployment parameters, such as heat stack and murano execution
plan outputs
may be set as returned value in tests.
Finally, tests may be placed into a murano package for easier package
verification and later modification.
I'm going to write specification soon. But before, we need to prepare
list of functions, that are needed to
implement simple mocking machinery in MuranoPL.
Please, leave your thoughts here or directly in the blueprint.
Regards, Kate.
[1] -
https://blueprints.launchpad.net/murano/+spec/simulated-execution-mode-murano-engine
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
[openstack-dev] Fwd: Can't add a table to nova DB
Hi all, I want to add a table to nova db and I followed those suggestions: https://stackoverflow.com/questions/19424901/how-to-add-a-table-in-nova-database-openstack/24900366#24900366 but after the synchronization there are no changes in the DB. In order, I've added the structure my new table as a class in models.py, than I've written a migration file and its upgrade and downgrade function and than I've synchronizaed the db. It seems everything goes fine. Can you give some suggestions and tips? Regards, -- Silvia __ OpenStack Development Mailing 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] Build dependency loop: python-os-client-config and python-oslotest
On 07/07/2015 01:31 PM, Doug Hellmann wrote: Excerpts from Thomas Goirand's message of 2015-07-07 19:26:18 +0200: Hi, It seems that the above packages are build-depending on each other. We need this kind of thing to be broken. Can something be done? From looking at the requirements files, it's not obvious why oslotest would have any dependency on python-os-client-config at all. Is it a direct dependency, or does the cycle go through some other package? 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 oslotest deps on os-client-config (runtime) os-client-config deps on oslotest (test) -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Segmentation Fault in nova-compute service on ARM platform.
On 07/07/2015 07:07 AM, Pradeep kumar wrote: Hi michael, I did tried icehouse release but getting same error. I think there is some issue with python code but how to resolve that need some guidance on the same. It is extremely unlikely that anything in the OpenStack code is responsible for a segfault in python. This seems like your python interpreter being broken on your processor / os. I think you will need to solve that much deeper problem. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Plethora of dbase migration questions...
Thanks Salvatore for the responses. See @PCM in-line... On Tue, Jul 7, 2015 at 6:14 AM Salvatore Orlando sorla...@nicira.com wrote: Some comments inline. Salvatore On 6 July 2015 at 20:00, Paul Michali p...@michali.net wrote: Hi, I have some urgent requests about migration that I'm hoping to get some info on. I'm working on a bug where I need to add two (related) fields to a table for VPNaaS. Here's the objectives related to migration... 1) create local_v4_ip and lcoal_v6_ip fields in the vpnservice table 2) for each entry in the vpnservice table: 2.1) Get the router.gw_port.fixed_ips list 2.2) Determine the version of each fixed IP and store the first of each version (if any) into the appropriate new field. I have created a migration file, and I changed the down_revision to be the number of the revision that is the first in the migration chain in the VPN repo. Here are the many questions I have... When I look in the VPN repo, the HEAD file has the version 'kilo', which is not the current head. Shouldn't it the version number of the first file in the migration chain? It should indeed. How are you generating the revision script? Using neutron-db-manage it should be updated automatically [1] @PCM I ran neutron-db-manage, when in the neutron repo, and it assigned some version, but it was not the latest in the neutron-vpnaas repo. I checked the VPN repo and there were a chain of versions, which I used to determine what the head should be and have set the version accordingly. However, in the current repo, head is set to kilo, which appears to be incorrect. The versions are: 5689aa52 kiloHEAD 3ea02b2a773e start_neutron_vpnaas None Should I do a separate commit that fixes the HEAD file, or just fix it as part of the bug fix I'm working on. BTW, at one point, after having correctly set the HEAD and versions in my new migration file, I think I ran neutron-db-manage check_migration, and I think it set the HEAD to my version, but it did that in the neutron repo, and not the VPN repo. I might have been running from the wrong repo? For my commit, I'm assuming I change the HEAD file to use my migration file's version? You can do that manually too, yes. I set HEAD to my migration file, and my file has a down revision of the previous head's revision. If I run 'neutron-db-manage --config-file ../neutron/etc/neutron.conf --config-file ../neutron/etc/neutron/plugins/ml2/ml2_conf.ini check_migration' there is no output so I guess that is OK. As I develop my new migration file, is there a way that I can test it (running neutron-db-migration, maybe)? When I test migrations I usually dump the database, run the migration with neutron-db-manage upgrade HEAD (I think it's not necessary to specify HEAD), and restore the db from the dump if the migration fails. Is there a way to run the migration file under the debugger, as well (importing pdb, for example)? The migration process is just like any python application, so I guess you can debug it with pdb. @PCM Ah, so use neutron-db-manage upgrade HEAD. That was the piece that was missing. I take it there are no specific unit tests of the migration files? In the migration, I can add the columns needed. What's the best way to fill out those fields - using raw SQL queries or create a Session object and access the VpnService object's router object? If the default value for the column is not enough, and you need to specify a value which depends on other values in the same row I would prefer plain SQL statements, but if that become cumbersome I guess it's ok to use sqlalchemy's session. I see there is some op.bind() call and then engine.execute(), but could use some help on the best way to extract the needed queries (I need to access the vpnservice's router, and then access the (Port) gw_port relationship, and from that access the (IPAllocation) fixed_ips list). Perhaps you can point us to the review pages on gerrit, and we can provide detailed comments there. @PCM Yeah, I haven't pushed it up yet. I have a few more changes to make, and should be able to get it up in a few days. The LP bug is 1464387. Essentially, in the vpnservices table, I'm adding an IPv4 and/or IPv6 addresses for the local end of VPN connections that will be established. This is to allow alternative VPN implementation (appliances, separate S/W, H/W, VM based VPN, etc) to specify addresses different than what is available on the Neutron router. However, for the reference implementation, we'll use the Neutron router's fixed_ips list (as is done today), and to handle the migration, I'm thinking the following is needed: 1) create the new columns. 2) Identify the router for that service and obtain it's GW fixed_ips list. 3) Pick first IPv4 address (if any) and IPv6 address (if any), and store in new columns. So I need to form a query and code to do this. Appreciate any advise here on how to
Re: [openstack-dev] Should project name be uppercase or lowercase?
Yuiko Takada wrote: Hi folks, I found the difference between wiki[1] and governance[2]. wiki says Generally the capitalization of the project team names like swift is lowercase. But in governance, written as uppercase like Nova, Swift. How do you think which should we use uppercase vs lowercase for representing project names? My personal take on it is that the project names (or the code repositories) are lowercase: nova, or openstack/nova. The *project team* name is capitalized: the Nova project team. I'm sure that Anne has a pretty strong position on that, though :) -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] oslo.messaging version and RabbitMQ heartbeat support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Le 2015-07-01 15:21, Mike Dorman a écrit : As a follow up to the discussion during the IRC meeting yesterday, please vote for one of these approaches: 1) Make the default for the rabbit_heartbeat_timeout_threshold parameter 60, which matches the default in Kilo oslo.messaging. This will by default enable the RMQ heartbeat feature, which also matches the default in Kilo oslo.messaging. Operators will need to set this parameter to 0 in order to disable the feature, which will be documented in the comments within the manifest. We will reevaluate the default value for the Liberty release, since the oslo.messaging default most likely will change to 0 for that release. Just a small correction: For kilo release, this is 0 not 60 per default since oslo.messaging 1.8.3, because some operators have reported critical issues with heartbeat enabled and some versions of py-amqp and kombu, and because we can't raise anymore the requirements for kilo we have disable it by default. For liberty, we have raise the requirements and we perhaps re-enable heartbeat, if nobody report new issue. Cheers, - --- Mehdi Abaakouk mail: sil...@sileht.net irc: sileht -BEGIN PGP SIGNATURE- Version: OpenPGP.js v.1.20131017 Comment: http://openpgpjs.org wsFcBAEBCAAQBQJVm8SRCRAYkrQvzqrryAAAnaEQAIMVd6FdW593wi87SFlv zP/Jc+bNyivQPynE/o4smgm5feuBqCou/8Zig7p1Ac5wpMGtsmK+wYKkdC03 nQaeSZ7hqlu2EZb2+xdB0sRBm2CZZHNcYIG/NF7E6dYHNfksrT6qeOUM3HBi JLVxBonF1Ch7zFaNhprrd0S9t/0vnXQlvDp+9Co0j5I0MV4hczkpFsQlPcr/ +sphCn65c+GeVkpGuxqYYsOvwvhqi8Xcm414OI5xLVb2N/iR5R1jg3Z4OT0a qhm6Tj6v4tOjAkyFVF4gDI9IxXMUG19IaKzwdAON1czFOgaqPlgWa0dc6dqW BqurTvolBtcr8VUqs0l96/+Wr18u/7ctQtarwYhRMau8GbwYRod2fcV/8vFB wX/gdMHz3hc/bpYTTKX6CqBfn1QInNuNP1nDH8kpcUOMDMPjhL2SvPDVeKRH 15lq6cBO0vRUwZZVjCc8B3OWum4kIC84ji04drzxYq/Ha2SBM9HAjtOg+1rJ s53IPegUT+L8F/9SsLkmX4uRfEu4eGn2rVL3jrss9R3Wy50/3j4MM44nDVDN TH6gAf4/DFdjrwDNuAnMv4FNSNl7mE/enYOtTpQy1Wnj70qwmDluTf9sA9RB fpjf+cctCy6HEUzeSc8lVZmyswh2fipMKf3j6Z0oX2G33JFDKyIiGG1sHbqn i8M/ =RJtG -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Plethora of dbase migration questions...
On Tue, Jul 07, 2015, Salvatore Orlando sorla...@nicira.com wrote: On 7 July 2015 at 14:00, Paul Michali p...@michali.net mailto:p...@michali.net wrote: Thanks Salvatore for the responses. See @PCM in-line... On Tue, Jul 7, 2015 at 6:14 AM Salvatore Orlando sorla...@nicira.com mailto:sorla...@nicira.com wrote: Some comments inline. Salvatore On 6 July 2015 at 20:00, Paul Michali p...@michali.net mailto:p...@michali.net wrote: Hi, I have some urgent requests about migration that I'm hoping to get some info on. I'm working on a bug where I need to add two (related) fields to a table for VPNaaS. Here's the objectives related to migration... 1) create local_v4_ip and lcoal_v6_ip fields in the vpnservice table 2) for each entry in the vpnservice table: 2.1) Get the router.gw_port.fixed_ips list 2.2) Determine the version of each fixed IP and store the first of each version (if any) into the appropriate new field. I have created a migration file, and I changed the down_revision to be the number of the revision that is the first in the migration chain in the VPN repo. Here are the many questions I have... When I look in the VPN repo, the HEAD file has the version 'kilo', which is not the current head. Shouldn't it the version number of the first file in the migration chain? It should indeed. How are you generating the revision script? Using neutron-db-manage it should be updated automatically [1] @PCM I ran neutron-db-manage, when in the neutron repo, and it assigned some version, but it was not the latest in the neutron-vpnaas repo. when you create a revision Alembic automatically assigns it a unique id. However, the neutron migration CLI (neutron-db-manage) then should take care of updating the HEAD file automatically. If this is not happening, that's where the problem should be. I checked the VPN repo and there were a chain of versions, which I used to determine what the head should be and have set the version accordingly. However, in the current repo, head is set to kilo, which appears to be incorrect. The versions are: 5689aa52 kiloHEAD 3ea02b2a773e start_neutron_vpnaas None Should I do a separate commit that fixes the HEAD file, or just fix it as part of the bug fix I'm working on. In order to pass functional tests the HEAD file must point to the topmost revision (5689aa52) BTW, at one point, after having correctly set the HEAD and versions in my new migration file, I think I ran neutron-db-manage check_migration, and I think it set the HEAD to my version, but it did that in the neutron repo, and not the VPN repo. I might have been running from the wrong repo? Yes, probably. neutron-db-manage by default works on the neutron repo. In order to work with a service repo you should specify it on the command line (http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/migration/cli.py#n41). This might also explain why the HEAD is not getting updated in your repo. I have been playing around with this. Unfortunately, --service only works for the upgrade command. It does not work for the revision command, and even less for --autogenerate. I am working on a fix. For my commit, I'm assuming I change the HEAD file to use my migration file's version? You can do that manually too, yes. I set HEAD to my migration file, and my file has a down revision of the previous head's revision. If I run 'neutron-db-manage --config-file ../neutron/etc/neutron.conf --config-file ../neutron/etc/neutron/plugins/ml2/ml2_conf.ini check_migration' there is no output so I guess that is OK. As I develop my new migration file, is there a way that I can test it (running neutron-db-migration, maybe)? When I test migrations I usually dump the database, run the migration with neutron-db-manage upgrade HEAD (I think it's not necessary to specify HEAD), and restore the db from the dump if the migration fails. Is there a way to run the migration file under the debugger, as well (importing pdb, for example)? The migration process is just like any python application, so I guess you can debug it with pdb. @PCM Ah, so use neutron-db-manage upgrade HEAD. That was the piece that was missing. I take it there are no specific unit tests of the migration files? ... and also specify --service vpnaas In the
Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected
Hi, # I'm a native Japanese speaker :-) 2015年7月7日(火) 20:33 Amrith Kumar amr...@tesora.com: Maybe this (the google answer)? www.youtube.com/watch?v=Qvw0A12aOGQ Yeah, this is correct pronunciation. But someone who is a native Japanese speaker should confirm. https://www.youtube.com/watch?v=D9vwge557hY I think this is a casual version and Japanese people are familiar with this. Thanks, -- Masayuki Igawa -amrith P.S. the yahoo answer suggests that you pronounce it as Meh - gee with the emphasis on the meh ;) -Original Message- From: Matthias Runge [mailto:mru...@redhat.com] Sent: Tuesday, July 07, 2015 6:08 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected On Mon, Jul 06, 2015 at 11:48:13PM -0400, Monty Taylor wrote: significant identified problems... but the third in the list, Meiji (明 治) is clear. So please join me in welcoming the latest name to our family ... and if you, like me, are not a native Japanese speaker, in learning two new characters. Could someone provide a hint please, how to pronounce this properly? -- Matthias Runge mru...@redhat.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 -- -- Masayuki Igawa __ OpenStack Development Mailing 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] Plethora of dbase migration questions...
And for the query, it involves several table references (Router, Port, IPAllocation). On Tue, Jul 7, 2015 at 8:00 AM Paul Michali p...@michali.net wrote: Thanks Salvatore for the responses. See @PCM in-line... On Tue, Jul 7, 2015 at 6:14 AM Salvatore Orlando sorla...@nicira.com wrote: Some comments inline. Salvatore On 6 July 2015 at 20:00, Paul Michali p...@michali.net wrote: Hi, I have some urgent requests about migration that I'm hoping to get some info on. I'm working on a bug where I need to add two (related) fields to a table for VPNaaS. Here's the objectives related to migration... 1) create local_v4_ip and lcoal_v6_ip fields in the vpnservice table 2) for each entry in the vpnservice table: 2.1) Get the router.gw_port.fixed_ips list 2.2) Determine the version of each fixed IP and store the first of each version (if any) into the appropriate new field. I have created a migration file, and I changed the down_revision to be the number of the revision that is the first in the migration chain in the VPN repo. Here are the many questions I have... When I look in the VPN repo, the HEAD file has the version 'kilo', which is not the current head. Shouldn't it the version number of the first file in the migration chain? It should indeed. How are you generating the revision script? Using neutron-db-manage it should be updated automatically [1] @PCM I ran neutron-db-manage, when in the neutron repo, and it assigned some version, but it was not the latest in the neutron-vpnaas repo. I checked the VPN repo and there were a chain of versions, which I used to determine what the head should be and have set the version accordingly. However, in the current repo, head is set to kilo, which appears to be incorrect. The versions are: 5689aa52 kiloHEAD 3ea02b2a773e start_neutron_vpnaas None Should I do a separate commit that fixes the HEAD file, or just fix it as part of the bug fix I'm working on. BTW, at one point, after having correctly set the HEAD and versions in my new migration file, I think I ran neutron-db-manage check_migration, and I think it set the HEAD to my version, but it did that in the neutron repo, and not the VPN repo. I might have been running from the wrong repo? For my commit, I'm assuming I change the HEAD file to use my migration file's version? You can do that manually too, yes. I set HEAD to my migration file, and my file has a down revision of the previous head's revision. If I run 'neutron-db-manage --config-file ../neutron/etc/neutron.conf --config-file ../neutron/etc/neutron/plugins/ml2/ml2_conf.ini check_migration' there is no output so I guess that is OK. As I develop my new migration file, is there a way that I can test it (running neutron-db-migration, maybe)? When I test migrations I usually dump the database, run the migration with neutron-db-manage upgrade HEAD (I think it's not necessary to specify HEAD), and restore the db from the dump if the migration fails. Is there a way to run the migration file under the debugger, as well (importing pdb, for example)? The migration process is just like any python application, so I guess you can debug it with pdb. @PCM Ah, so use neutron-db-manage upgrade HEAD. That was the piece that was missing. I take it there are no specific unit tests of the migration files? In the migration, I can add the columns needed. What's the best way to fill out those fields - using raw SQL queries or create a Session object and access the VpnService object's router object? If the default value for the column is not enough, and you need to specify a value which depends on other values in the same row I would prefer plain SQL statements, but if that become cumbersome I guess it's ok to use sqlalchemy's session. I see there is some op.bind() call and then engine.execute(), but could use some help on the best way to extract the needed queries (I need to access the vpnservice's router, and then access the (Port) gw_port relationship, and from that access the (IPAllocation) fixed_ips list). Perhaps you can point us to the review pages on gerrit, and we can provide detailed comments there. @PCM Yeah, I haven't pushed it up yet. I have a few more changes to make, and should be able to get it up in a few days. The LP bug is 1464387. Essentially, in the vpnservices table, I'm adding an IPv4 and/or IPv6 addresses for the local end of VPN connections that will be established. This is to allow alternative VPN implementation (appliances, separate S/W, H/W, VM based VPN, etc) to specify addresses different than what is available on the Neutron router. However, for the reference implementation, we'll use the Neutron router's fixed_ips list (as is done today), and to handle the migration, I'm thinking the following is needed: 1) create the new columns. 2) Identify the router for that service and obtain it's GW
Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected
On 07/07/15 13:55, Masayuki Igawa wrote: https://www.youtube.com/watch?v=D9vwge557hY I think this is a casual version and Japanese people are familiar with this. Thank you! I have an idea now. About the youtube snippet: Is that a commercial? Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Should project name be uppercase or lowercase?
On 7 July 2015 at 13:11, Thierry Carrez thie...@openstack.org wrote: Yuiko Takada wrote: Hi folks, I found the difference between wiki[1] and governance[2]. wiki says Generally the capitalization of the project team names like swift is lowercase. But in governance, written as uppercase like Nova, Swift. How do you think which should we use uppercase vs lowercase for representing project names? My personal take on it is that the project names (or the code repositories) are lowercase: nova, or openstack/nova. The *project team* name is capitalized: the Nova project team. I'm sure that Anne has a pretty strong position on that, though :) This makes entire sense to me. I assumed that when used programmatically (or repositroy names) it should be in lowercase (unless a class name), when in prose it should be uppercase. For a recent documentation change, I put a project names capitalised which feels entirely appropriate as it is a proper noun. However, review requested that it followed documentation convention[0] of using lower case so I amended it to follow. I am interested to hear why the convention in documentation for it to be lower case. [0] https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_project_names -- Kind Regards, Dave Walker __ OpenStack Development Mailing 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 Meiji (明治) - Our next release name has been selected
2015年7月7日(火) 21:14 Matthias Runge mru...@redhat.com: On 07/07/15 13:55, Masayuki Igawa wrote: https://www.youtube.com/watch?v=D9vwge557hY I think this is a casual version and Japanese people are familiar with this. Thank you! I have an idea now. About the youtube snippet: Is that a commercial? Yes, it's a chocolate commercial:-) https://www.meiji.co.jp/ It's a very famous company which make snack foods and medicines in Japan. Thanks, -- Masayuki Igawa Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- Masayuki Igawa __ OpenStack Development Mailing 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] Plethora of dbase migration questions...
On Tue, Jul 07, 2015, Paul Michali p...@michali.net wrote: Thanks Salvatore for the responses. See @PCM in-line... On Tue, Jul 7, 2015 at 6:14 AM Salvatore Orlando sorla...@nicira.com mailto:sorla...@nicira.com wrote: Some comments inline. Salvatore On 6 July 2015 at 20:00, Paul Michali p...@michali.net mailto:p...@michali.net wrote: Hi, I have some urgent requests about migration that I'm hoping to get some info on. I'm working on a bug where I need to add two (related) fields to a table for VPNaaS. Here's the objectives related to migration... 1) create local_v4_ip and lcoal_v6_ip fields in the vpnservice table 2) for each entry in the vpnservice table: 2.1) Get the router.gw_port.fixed_ips list 2.2) Determine the version of each fixed IP and store the first of each version (if any) into the appropriate new field. I have created a migration file, and I changed the down_revision to be the number of the revision that is the first in the migration chain in the VPN repo. Here are the many questions I have... When I look in the VPN repo, the HEAD file has the version 'kilo', which is not the current head. Shouldn't it the version number of the first file in the migration chain? It should indeed. How are you generating the revision script? Using neutron-db-manage it should be updated automatically [1] @PCM I ran neutron-db-manage, when in the neutron repo, and it assigned some version, but it was not the latest in the neutron-vpnaas repo. neutron-db-manage does not handle alembic branches in separate repos very well at all yet. I am working on updating it with https://review.openstack.org/198524 but I have quite a lot left to do. I checked the VPN repo and there were a chain of versions, which I used to determine what the head should be and have set the version accordingly. However, in the current repo, head is set to kilo, which appears to be incorrect. The versions are: 5689aa52 kiloHEAD 3ea02b2a773e start_neutron_vpnaas None Ouch. That is an error, because https://review.openstack.org/190569 should have updated HEAD but didn't. The version sequence (you can see it in any devstack run) is: INFO [alembic.migration] Running upgrade - start_neutron_vpnaas, start neutron-vpnaas chain INFO [alembic.migration] Running upgrade start_neutron_vpnaas - 3ea02b2a773e, add_index_tenant_id INFO [alembic.migration] Running upgrade 3ea02b2a773e - kilo, kilo INFO [alembic.migration] Running upgrade kilo - 5689aa52, fix identifier map fk Should I do a separate commit that fixes the HEAD file, or just fix it as part of the bug fix I'm working on. Yes, you should immediately submit a patch to change HEAD to 5689aa52. BTW, at one point, after having correctly set the HEAD and versions in my new migration file, I think I ran neutron-db-manage check_migration, and I think it set the HEAD to my version, but it did that in the neutron repo, and not the VPN repo. I might have been running from the wrong repo? I working on updating the devref docs for this process. Things have changed quite a bit with the alembic branches in separate repos. For my commit, I'm assuming I change the HEAD file to use my migration file's version? You can do that manually too, yes. I set HEAD to my migration file, and my file has a down revision of the previous head's revision. If I run 'neutron-db-manage --config-file ../neutron/etc/neutron.conf --config-file ../neutron/etc/neutron/plugins/ml2/ml2_conf.ini check_migration' there is no output so I guess that is OK. As I develop my new migration file, is there a way that I can test it (running neutron-db-migration, maybe)? When I test migrations I usually dump the database, run the migration with neutron-db-manage upgrade HEAD (I think it's not necessary to specify HEAD), and restore the db from the dump if the migration fails. Is there a way to run the migration file under the debugger, as well (importing pdb, for example)? The migration process is just like any python application, so I guess you can debug it with pdb. @PCM Ah, so use neutron-db-manage upgrade HEAD. That was the piece that was missing. I take it there are no specific unit tests of the migration files? In the migration, I can add the columns needed. What's the best way to fill out those fields - using raw SQL queries or create a Session object and access the VpnService object's router object? If the default value for the column is not enough, and you need to specify a value which depends on other values in the same row I would prefer plain SQL statements, but if that
[openstack-dev] [mistral][ui] Executions Screen BP
Team, I reviewed “Executions Screen” BP and left my comments. Generally I’m ok with the description. Please have a look. [1] https://blueprints.launchpad.net/mistral/+spec/mistral-dashboard-executions-screen https://blueprints.launchpad.net/mistral/+spec/mistral-dashboard-executions-screen Renat Akhmerov @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [swift] Stategy to port Swift to Python 3
Hi, I have 9 pending patches to fix Python 3 issues in Swift, but they didn't get much attention yet. Most of these patches replace a pattern with a new pattern to add Python 3 support in addition to Python 2 support. https://review.openstack.org/#/q/owner:%22Victor+Stinner%22+status:open+project:openstack/swift,n,z The problem is that these patches are long, and so it's common to get conflicts. It takes me a lot of time just to rebase these patches. Only Replace dict.iteritems() with dict.items() got a +2 yet. I hesitate to simply give up on porting Swift to Python 3, to focus on other projects which are faster to review my Python 3 patches (ceilometer, cinder, glance, keystone, nova). Maybe I took the wrong strategy for Swift. Instead of replacing a pattern in the whole Swift project, I should maybe try to port tests one by one to have shorter patches? My last try fix tox -e py34 in a single patch: https://review.openstack.org/#/c/199034/ Practical issue: it depends on my pyeclib pull request that I sent 3 months ago... If this Swift Fix tox -e py34 patch is merged, my pyeclib pull request is merged, and a new version of pyeclib including my fix is released, it will become possible to make the gate-swift-python34 voting to avoid Python 3 regressions. It should be nice milestone to start with shorter patches. What do you think? Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Should project name be uppercase or lowercase?
On 07/07/2015 11:21 AM, Yuiko Takada wrote: Hi folks, I found the difference between wiki[1] and governance[2]. wiki says Generally the capitalization of the project team names like swift is lowercase. But in governance, written as uppercase like Nova, Swift. It's grammatically incorrect (these are proper names and must be capitalized), but official policy is to lower case IIUC. How do you think which should we use uppercase vs lowercase for representing project names? [1]https://wiki.openstack.org/wiki/Documentation/Conventions [2]http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml Best Regards, Yuiko Takada __ OpenStack Development Mailing 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] Segmentation Fault in nova-compute service on ARM platform.
Hi michael, I did tried icehouse release but getting same error. I think there is some issue with python code but how to resolve that need some guidance on the same. On Jul 7, 2015 11:32 AM, Michael Still mi...@stillhq.com wrote: Havana is very very old and no longer supported. Why are you porting that release in particular? Michael On Tue, Jul 7, 2015 at 3:51 PM, Pradeep kumar topradeepyaduvan...@gmail.com wrote: Hi Guys, I am porting openstack on arm platform, but while running nova-compute service on it throws segmentaion fault. Below are the logs: 2015-06-05 09:24:12.195 11374 INFO nova.virt.driver [-] Loading compute driver 'libvirt.LibvirtDriver' 2015-06-05 09:24:13.483 11374 INFO nova.openstack.common.rpc.common [req-ba16a115-ed64-4fb5-b13e-f28e03a28b24 None None] Connected to AMQP server on 192.168.1.100:5672 2015-06-05 09:24:13.600 11374 INFO nova.openstack.common.rpc.common [req-ba16a115-ed64-4fb5-b13e-f28e03a28b24 None None] Connected to AMQP server on 192.168.1.100:5672 2015-06-05 09:24:13.808 11374 AUDIT nova.service [-] Starting compute node (version 2013.2.2) Program received signal SIGSEGV, Segmentation fault. 0x76f244d4 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 While tracing the same with gdb: I am getting corrupt stack: (gdb) bt #0 0x76f244d4 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 #1 0x76f2ab78 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0 #2 0x76f2905c in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 #3 0x76f2ab78 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0 #4 0x76eaf690 in ?? () from /usr/lib/libpython2.7.so.1.0 Cannot access memory at address 0x0 #5 0x76eaf690 in ?? () from /usr/lib/libpython2.7.so.1.0 Cannot access memory at address 0x0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) The function PyEval_EvalFrameEx () is present in ceval.c Also I am using havana release of openstack. I am new to openstack just tried openstack nodes on x-86 platform. Any help in order to solve the above issue is appreciated. Regards Pradeep Kumar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Rackspace Australia __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Oh yes! It was a bit weird that Miguel, while owning a feature branch, did not have a say in what is merged there. Now it should be more in line with his actual position in the project. Good work, Miguel! On 07/06/2015 01:02 PM, Kevin Benton wrote: Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year has been important in making the reference implementation reliable. Existing cores, please vote +1/-1 for his addition to the team. Cheers! 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.ht ml 2. http://stackalytics.com/report/contribution/neutron/30 http://stackalytics.com/report/contribution/neutron/60 http://stackalytics.com/report/contribution/neutron/90 -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVm7WcAAoJEC5aWaUY1u57RUoH/jIimjwrLqzzq8u0Ix25YGrR CQVkLGbE7j+LtzvKOcFSORp/Y/gwsJ6KF3B7NBqfh1C0fHx/uMVp/tf7/NhuthE0 7+gsMe3yn6oOraYCQHwEDHpxz6r+7dmMfhisknH5k7vsdnwNi5CrnXyr+knxrQ0L jjFvdi3F/+2ztV5LtPJLPoU72d81ATwEEFTH/9vUeFPlBu8okUuXRszPJCWR3MeL PrKeg5G6OH4b4GVC45Q7238rWB7uiwfFLILo9I8qwgJ/LZnKkK12bmk3tUgE3cqP BXxfuMKueJgOvRU0VPpWZwXicf2/pOmdUBv7uX+BeK9hPP5G9i8ITmFblB+doUk= =EuZs -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected
Hello, I think the third name 'Meiji' may arise some historical and political debates in East Asia, as far as I know. Could you share what significant identified problems are on the first two selected from our election? With many thanks, /Ian On Tue, Jul 7, 2015 at 8:55 PM, Masayuki Igawa masayuki.ig...@gmail.com wrote: Hi, # I'm a native Japanese speaker :-) 2015年7月7日(火) 20:33 Amrith Kumar amr...@tesora.com: Maybe this (the google answer)? www.youtube.com/watch?v=Qvw0A12aOGQ Yeah, this is correct pronunciation. But someone who is a native Japanese speaker should confirm. https://www.youtube.com/watch?v=D9vwge557hY I think this is a casual version and Japanese people are familiar with this. Thanks, -- Masayuki Igawa -amrith P.S. the yahoo answer suggests that you pronounce it as Meh - gee with the emphasis on the meh ;) -Original Message- From: Matthias Runge [mailto:mru...@redhat.com] Sent: Tuesday, July 07, 2015 6:08 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected On Mon, Jul 06, 2015 at 11:48:13PM -0400, Monty Taylor wrote: significant identified problems... but the third in the list, Meiji (明 治) is clear. So please join me in welcoming the latest name to our family ... and if you, like me, are not a native Japanese speaker, in learning two new characters. Could someone provide a hint please, how to pronounce this properly? -- Matthias Runge mru...@redhat.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 -- -- Masayuki Igawa __ OpenStack Development Mailing 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] Plethora of dbase migration questions...
On 7 July 2015 at 14:00, Paul Michali p...@michali.net wrote: Thanks Salvatore for the responses. See @PCM in-line... On Tue, Jul 7, 2015 at 6:14 AM Salvatore Orlando sorla...@nicira.com wrote: Some comments inline. Salvatore On 6 July 2015 at 20:00, Paul Michali p...@michali.net wrote: Hi, I have some urgent requests about migration that I'm hoping to get some info on. I'm working on a bug where I need to add two (related) fields to a table for VPNaaS. Here's the objectives related to migration... 1) create local_v4_ip and lcoal_v6_ip fields in the vpnservice table 2) for each entry in the vpnservice table: 2.1) Get the router.gw_port.fixed_ips list 2.2) Determine the version of each fixed IP and store the first of each version (if any) into the appropriate new field. I have created a migration file, and I changed the down_revision to be the number of the revision that is the first in the migration chain in the VPN repo. Here are the many questions I have... When I look in the VPN repo, the HEAD file has the version 'kilo', which is not the current head. Shouldn't it the version number of the first file in the migration chain? It should indeed. How are you generating the revision script? Using neutron-db-manage it should be updated automatically [1] @PCM I ran neutron-db-manage, when in the neutron repo, and it assigned some version, but it was not the latest in the neutron-vpnaas repo. when you create a revision Alembic automatically assigns it a unique id. However, the neutron migration CLI (neutron-db-manage) then should take care of updating the HEAD file automatically. If this is not happening, that's where the problem should be. I checked the VPN repo and there were a chain of versions, which I used to determine what the head should be and have set the version accordingly. However, in the current repo, head is set to kilo, which appears to be incorrect. The versions are: 5689aa52 kiloHEAD 3ea02b2a773e start_neutron_vpnaas None Should I do a separate commit that fixes the HEAD file, or just fix it as part of the bug fix I'm working on. In order to pass functional tests the HEAD file must point to the topmost revision (5689aa52) BTW, at one point, after having correctly set the HEAD and versions in my new migration file, I think I ran neutron-db-manage check_migration, and I think it set the HEAD to my version, but it did that in the neutron repo, and not the VPN repo. I might have been running from the wrong repo? Yes, probably. neutron-db-manage by default works on the neutron repo. In order to work with a service repo you should specify it on the command line ( http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/migration/cli.py#n41 ). This might also explain why the HEAD is not getting updated in your repo. For my commit, I'm assuming I change the HEAD file to use my migration file's version? You can do that manually too, yes. I set HEAD to my migration file, and my file has a down revision of the previous head's revision. If I run 'neutron-db-manage --config-file ../neutron/etc/neutron.conf --config-file ../neutron/etc/neutron/plugins/ml2/ml2_conf.ini check_migration' there is no output so I guess that is OK. As I develop my new migration file, is there a way that I can test it (running neutron-db-migration, maybe)? When I test migrations I usually dump the database, run the migration with neutron-db-manage upgrade HEAD (I think it's not necessary to specify HEAD), and restore the db from the dump if the migration fails. Is there a way to run the migration file under the debugger, as well (importing pdb, for example)? The migration process is just like any python application, so I guess you can debug it with pdb. @PCM Ah, so use neutron-db-manage upgrade HEAD. That was the piece that was missing. I take it there are no specific unit tests of the migration files? ... and also specify --service vpnaas In the migration, I can add the columns needed. What's the best way to fill out those fields - using raw SQL queries or create a Session object and access the VpnService object's router object? If the default value for the column is not enough, and you need to specify a value which depends on other values in the same row I would prefer plain SQL statements, but if that become cumbersome I guess it's ok to use sqlalchemy's session. I see there is some op.bind() call and then engine.execute(), but could use some help on the best way to extract the needed queries (I need to access the vpnservice's router, and then access the (Port) gw_port relationship, and from that access the (IPAllocation) fixed_ips list). Perhaps you can point us to the review pages on gerrit, and we can provide detailed comments there. @PCM Yeah, I haven't pushed it up yet. I have a few more changes to make, and should be able to get it up in a few days. The
[openstack-dev] [neutron] Reading an updated port's fixed IPs in mech driver update_port_postcommit
I think there's something I'm not understanding about how Neutron's DB tables are related, and when one can safely read believed-to-be-committed information from them... My project's mechanism driver is handling a port update in which the fixed IPs are changing; specifically, a second fixed IP has been added to the port. It does this (for a reason I can explain if needed) by calling db.get_port(), in the update_port_postcommit hook. But we observe that the result of db.get_port() does not include the new fixed IP. Even though we're in the postcommit hook, and hence we assume that all the changes for that port have by now been committed. What are we misunderstanding here? My guess is that this is something to do with 'fixed_ips' not being a column directly in the Ports table, but instead calculated from relationships between the port ID and another (IPAllocation) table. We've seen a similar problem in the past with binding:host_id, for which the same is true, i.e. info is in the separate portbindings table. Or could it be that the transaction hasn't really been closed yet, when update_port_postcommit hook is called? (This is with Icehouse-level code, so it could be something that's been fixed...) Many thanks, Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.messaging] [mistral] Acknowledge feature of RabbitMQ in oslo.messaging
Just to clarify: what we’re looking for is how to implement “Work queue” pattern described at [1] with oslo messaging. As Nikolay said, it requires that a message to be acknowledged after it has been processed. [1] http://www.rabbitmq.com/tutorials/tutorial-two-python.html http://www.rabbitmq.com/tutorials/tutorial-two-python.html Renat Akhmerov @ Mirantis Inc. On 07 Jul 2015, at 15:58, Nikolay Makhotkin nmakhot...@mirantis.com wrote: Hi, I am using RabbitMQ as the backend and searched oslo.messaging for message acknowledgement feature but I found only [1] what is wrong using of acknowledgement since it acknowledges incoming message before it has been processed (while it should be done only after processing the message, otherwise we can lost given message if, say, the server suddenly goes down). So, my questions: does oslo.messaging indeed not support correct acknowledgement feature? Or it is impossible to do for oslo.messaging paradighm? Or is it somehow connected with that oslo.messaging has to support a lot of transport types? Can't it be implemented somehow in oslo.messaging? [1] https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/rpc/dispatcher.py#L135 https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/rpc/dispatcher.py#L135 Best Regards, Nikolay @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] [neutron] Plethora of dbase migration questions...
Some comments inline. Salvatore On 6 July 2015 at 20:00, Paul Michali p...@michali.net wrote: Hi, I have some urgent requests about migration that I'm hoping to get some info on. I'm working on a bug where I need to add two (related) fields to a table for VPNaaS. Here's the objectives related to migration... 1) create local_v4_ip and lcoal_v6_ip fields in the vpnservice table 2) for each entry in the vpnservice table: 2.1) Get the router.gw_port.fixed_ips list 2.2) Determine the version of each fixed IP and store the first of each version (if any) into the appropriate new field. I have created a migration file, and I changed the down_revision to be the number of the revision that is the first in the migration chain in the VPN repo. Here are the many questions I have... When I look in the VPN repo, the HEAD file has the version 'kilo', which is not the current head. Shouldn't it the version number of the first file in the migration chain? It should indeed. How are you generating the revision script? Using neutron-db-manage it should be updated automatically [1] For my commit, I'm assuming I change the HEAD file to use my migration file's version? You can do that manually too, yes. I set HEAD to my migration file, and my file has a down revision of the previous head's revision. If I run 'neutron-db-manage --config-file ../neutron/etc/neutron.conf --config-file ../neutron/etc/neutron/plugins/ml2/ml2_conf.ini check_migration' there is no output so I guess that is OK. As I develop my new migration file, is there a way that I can test it (running neutron-db-migration, maybe)? When I test migrations I usually dump the database, run the migration with neutron-db-manage upgrade HEAD (I think it's not necessary to specify HEAD), and restore the db from the dump if the migration fails. Is there a way to run the migration file under the debugger, as well (importing pdb, for example)? The migration process is just like any python application, so I guess you can debug it with pdb. In the migration, I can add the columns needed. What's the best way to fill out those fields - using raw SQL queries or create a Session object and access the VpnService object's router object? If the default value for the column is not enough, and you need to specify a value which depends on other values in the same row I would prefer plain SQL statements, but if that become cumbersome I guess it's ok to use sqlalchemy's session. I see there is some op.bind() call and then engine.execute(), but could use some help on the best way to extract the needed queries (I need to access the vpnservice's router, and then access the (Port) gw_port relationship, and from that access the (IPAllocation) fixed_ips list). Perhaps you can point us to the review pages on gerrit, and we can provide detailed comments there. Appreciate any advise here on how to debug the migration stuff... Paul Michali (pc_m) [1] http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/migration/cli.py#n124 __ OpenStack Development Mailing 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 Meiji (明治) - Our next release name has been selected
On Mon, Jul 06, 2015 at 11:48:13PM -0400, Monty Taylor wrote: significant identified problems... but the third in the list, Meiji (明 治) is clear. So please join me in welcoming the latest name to our family ... and if you, like me, are not a native Japanese speaker, in learning two new characters. Could someone provide a hint please, how to pronounce this properly? -- Matthias Runge mru...@redhat.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] [horizon] Modifying existing dashboards with plugins
On Mon, Jul 06, 2015 at 04:23:29PM -0700, Skyler Berg wrote: I am wondering if there is a way to have plugins modify existing dashboards currently that I am overlooking. If not, should there be? Very briefly: There is currently no way to extend something else other than a dashboard or a panel. It's a known issue, there should be a pluggable way to extend tables etc. -- Matthias Runge mru...@redhat.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] [oslo.messaging] [mistral] Acknowledge feature of RabbitMQ in oslo.messaging
Hi, I am using RabbitMQ as the backend and searched oslo.messaging for message acknowledgement feature but I found only [1] what is wrong using of acknowledgement since it acknowledges incoming message before it has been processed (while it should be done only after processing the message, otherwise we can lost given message if, say, the server suddenly goes down). So, my questions: does oslo.messaging indeed not support correct acknowledgement feature? Or it is impossible to do for oslo.messaging paradighm? Or is it somehow connected with that oslo.messaging has to support a lot of transport types? Can't it be implemented somehow in oslo.messaging? [1] https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/rpc/dispatcher.py#L135 Best Regards, Nikolay @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] OpenStack Meiji (明治) - Our next release name has been selected
Maybe this (the google answer)? www.youtube.com/watch?v=Qvw0A12aOGQ But someone who is a native Japanese speaker should confirm. -amrith P.S. the yahoo answer suggests that you pronounce it as Meh - gee with the emphasis on the meh ;) -Original Message- From: Matthias Runge [mailto:mru...@redhat.com] Sent: Tuesday, July 07, 2015 6:08 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected On Mon, Jul 06, 2015 at 11:48:13PM -0400, Monty Taylor wrote: significant identified problems... but the third in the list, Meiji (明 治) is clear. So please join me in welcoming the latest name to our family ... and if you, like me, are not a native Japanese speaker, in learning two new characters. Could someone provide a hint please, how to pronounce this properly? -- Matthias Runge mru...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] python-cinderclient functional tests
On Mon, Jul 06, 2015 at 09:48:27PM +0300, Ivan Kolodyazhny wrote: Hi all, As you may know, we've got experimental job [1] to run functional tests [2] for python-cinderclient with devstack setup. Functional tests for python-cinderclient is very important because it's almost the only way to test python-cinderclient with Cinder API. For now, we've got only Rally which uses cinderclient to test Cinder. Tempest uses own client for all APIs. Current tests coverage are very low.. That's why I would like to ask everyone to contribute to python-cinderclient. I created etherpad [3] with current progress. You can find me (e0ne) or any other core in #openstack-cinder in IRC. Aslo, what do you think about moving cinderclient functional tests from experimental to non-voting queue to make it more public and run it with every patch to python-cinderclient? +1 I think it is a great idea to move it to non-voting. [1] https://review.openstack.org/#/c/182528/ [2] https://github.com/openstack/python-cinderclient/tree/master/cinderclient/tests/functional [3] https://etherpad.openstack.org/p/cinder-client-functional-tests Regards, Ivan Kolodyazhny __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.messaging] [mistral] Acknowledge feature of RabbitMQ in oslo.messaging
Hi, The RPC API of oslo.messaging do it for you, you don't have to care about acknowledgement (or anything else done by the driver because the underlying used pattern depends of it) . For the Working Queues patterns, I guess what you need is to ensure that the Target doesn't have the server attribute set and use call or cast depending of your needs. It works like this for rabbitmq: * the message is acknowledged from the rabbitmq PoV when the worker start the processing of the message * when it finish it send a message back to the caller with the result of the processing or the raised exception if that doesn't work On the client side, when you use call is wait for the returns. If you don't need to get the result or the exception occurred during the message processing just use cast, it doesn't wait for the return and worker doesn't send it. When RPC is needed, acknowledgement after the message have been processed is not enough reliable to ensure the message have been processed correctly and can lead to stuck message on the queue. Otherwise, the Notification API of oslo.messaging allows to control acknowledgement or requeue of message but does not provide method and endpoint versioning (that allows rolling upgrade for example), and remote executed method are hardcoded to match the notification mechanism of openstack. Cheers, --- Mehdi Abaakouk mail: sil...@sileht.net irc: sileht Le 2015-07-07 12:13, Renat Akhmerov a écrit : Just to clarify: what we’re looking for is how to implement “Work queue” pattern described at [1] with oslo messaging. As Nikolay said, it requires that a message to be acknowledged after it has been processed. [1] http://www.rabbitmq.com/tutorials/tutorial-two-python.html http://www.rabbitmq.com/tutorials/tutorial-two-python.html Renat Akhmerov @ Mirantis Inc. On 07 Jul 2015, at 15:58, Nikolay Makhotkin nmakhot...@mirantis.com wrote: Hi, I am using RabbitMQ as the backend and searched oslo.messaging for message acknowledgement feature but I found only [1] what is wrong using of acknowledgement since it acknowledges incoming message before it has been processed (while it should be done only after processing the message, otherwise we can lost given message if, say, the server suddenly goes down). So, my questions: does oslo.messaging indeed not support correct acknowledgement feature? Or it is impossible to do for oslo.messaging paradighm? Or is it somehow connected with that oslo.messaging has to support a lot of transport types? Can't it be implemented somehow in oslo.messaging? [1] https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/rpc/dispatcher.py#L135 https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/rpc/dispatcher.py#L135 Best Regards, Nikolay @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 Development Mailing 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] Should project name be uppercase or lowercase?
Hi folks, I found the difference between wiki[1] and governance[2]. wiki says Generally the capitalization of the project team names like swift is lowercase. But in governance, written as uppercase like Nova, Swift. How do you think which should we use uppercase vs lowercase for representing project names? [1]https://wiki.openstack.org/wiki/Documentation/Conventions [2] http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml Best Regards, Yuiko Takada __ OpenStack Development Mailing 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] Plethora of dbase migration questions...
2015-07-07 21:39 GMT+09:00 Henry Gessau ges...@cisco.com: On Tue, Jul 07, 2015, Paul Michali p...@michali.net p...@michali.net wrote: Thanks Salvatore for the responses. See @PCM in-line... On Tue, Jul 7, 2015 at 6:14 AM Salvatore Orlando sorla...@nicira.com wrote: Some comments inline. Salvatore On 6 July 2015 at 20:00, Paul Michali p...@michali.netp...@michali.net wrote: Hi, I have some urgent requests about migration that I'm hoping to get some info on. I'm working on a bug where I need to add two (related) fields to a table for VPNaaS. Here's the objectives related to migration... 1) create local_v4_ip and lcoal_v6_ip fields in the vpnservice table 2) for each entry in the vpnservice table: 2.1) Get the router.gw_port.fixed_ips list 2.2) Determine the version of each fixed IP and store the first of each version (if any) into the appropriate new field. I have created a migration file, and I changed the down_revision to be the number of the revision that is the first in the migration chain in the VPN repo. Here are the many questions I have... When I look in the VPN repo, the HEAD file has the version 'kilo', which is not the current head. Shouldn't it the version number of the first file in the migration chain? It should indeed. How are you generating the revision script? Using neutron-db-manage it should be updated automatically [1] @PCM I ran neutron-db-manage, when in the neutron repo, and it assigned some version, but it was not the latest in the neutron-vpnaas repo. neutron-db-manage does not handle alembic branches in separate repos very well at all yet. I am working on updating it with https://review.openstack.org/198524https://review.openstack.org/198524 but I have quite a lot left to do. Yes, at now we have implicit order of running alembic migrations. First run neutron db migration and then advanced service migrations. I do not fully understand how alembic branch mechanism works, but I think we can have a common ancestor and have multiple branches, and each branch can evolve independently. I checked the VPN repo and there were a chain of versions, which I used to determine what the head should be and have set the version accordingly. However, in the current repo, head is set to kilo, which appears to be incorrect. The versions are: 5689aa52 kiloHEAD 3ea02b2a773e start_neutron_vpnaas None Ouch. That is an error, because https://review.openstack.org/190569 https://review.openstack.org/190569 should have updated HEAD but didn't. The version sequence (you can see it in any devstack run) is: INFO [alembic.migration] Running upgrade - start_neutron_vpnaas, start neutron-vpnaas chain INFO [alembic.migration] Running upgrade start_neutron_vpnaas - 3ea02b2a773e, add_index_tenant_id INFO [alembic.migration] Running upgrade 3ea02b2a773e - kilo, kilo INFO [alembic.migration] Running upgrade kilo - 5689aa52, fix identifier map fk It seems we don't have an appropriate check for HEAD revision in at least VPNaaS repo. Paul and I just discussed it. We need to improve the check too. Should I do a separate commit that fixes the HEAD file, or just fix it as part of the bug fix I'm working on. Yes, you should immediately submit a patch to change HEAD to 5689aa52. BTW, at one point, after having correctly set the HEAD and versions in my new migration file, I think I ran neutron-db-manage check_migration, and I think it set the HEAD to my version, but it did that in the neutron repo, and not the VPN repo. I might have been running from the wrong repo? I working on updating the devref docs for this process. Things have changed quite a bit with the alembic branches in separate repos. For my commit, I'm assuming I change the HEAD file to use my migration file's version? You can do that manually too, yes. I set HEAD to my migration file, and my file has a down revision of the previous head's revision. If I run 'neutron-db-manage --config-file ../neutron/etc/neutron.conf --config-file ../neutron/etc/neutron/plugins/ml2/ml2_conf.ini check_migration' there is no output so I guess that is OK. As I develop my new migration file, is there a way that I can test it (running neutron-db-migration, maybe)? When I test migrations I usually dump the database, run the migration with neutron-db-manage upgrade HEAD (I think it's not necessary to specify HEAD), and restore the db from the dump if the migration fails. Is there a way to run the migration file under the debugger, as well (importing pdb, for example)? The migration process is just like any python application, so I guess you can debug it with pdb. @PCM Ah, so use neutron-db-manage upgrade HEAD. That was the piece that was missing. I take it there are no specific unit tests of the migration files? In the migration, I can add the columns needed. What's the
[openstack-dev] [Fuel][Fuel-library] Kilo-based CI jobs enabled in non-voting mode
Hi, everyone, please be aware that we enabled Kilo based-jobs on Fuel CI for commits to fuel-library repository: https://ci.fuel-infra.org/view/kilo/ They run exactly the same tests - centos.ha_nova_vlan, - ubuntu.ha_neutron_vlan - master_node against custom build of Kilo based Fuel ISO (currently it is fuel-gerrit-7.0-208) in non-voting mode. Meanwhile voting jobs: - fuellib_review_pkgs_master_node - master.fuel-library.pkgs.centos.ha_nova_vlan - master.fuel-library.pkgs.ubuntu.ha_neutron_vlan still use Juno-based ISO. -- Aleksandra Fedorova CI Engineer bookwar __ OpenStack Development Mailing 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] Should project name be uppercase or lowercase?
Yuiko Takada wrote: How do you think which should we use uppercase vs lowercase for representing project names? They are proper names. The clear grammatical standard is capitalization. With that in mind, and unless there is some compelling reason for them not to be capitalized (I can't imagine there is one), we should follow that model and conform to the expected behavior. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Cinder as generic volume manager
Hello, I'd like to (mis-)use Cinder outside of OpenStack, i.e. without Nova. I can easily create/manage volumes themselves, Cinder API is pretty friendly here. Now, how can I attach a volume somewhere? Something like 'nova volume-attach server volume', but without Nova and with host (=anything) instead of server (=virtual machine inside OpenStack). I guess I am not the first one to ask for such feature, has anyone tried it? Would it be possible to separate a new library from Nova, which would just attach the volume to the host where it is runnig and mark the volume as 'in-use'? How hard would it be? Jan __ OpenStack Development Mailing 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] [OSSN 0049] Nova ironic driver logs sensitive information while operating in debug mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nova ironic driver logs sensitive information while operating in debug mode - --- ### Summary ### The password and authentication token configuration options for the ironic driver in nova are not marked as secret. The values of these options will be logged to the standard logging output when the controller is run in debug mode. ### Affected Services / Software ### Nova, Ironic, Juno, Kilo ### Discussion ### When using nova with the ironic driver, an operator will need to specify either the password or an authentication token for the ironic admin user's keystone credentials. Under normal circumstances this is not an issue, but when running the API server with logging levels set to include the DEBUG message level these credentials will be exposed in the logs. Logging of configuration values is controlled by the `secret` flag for any oslo configuration option. Without this flag set, the value for a configuration option will be displayed in the logs. In the case of the ironic credentials, these options are not marked as secret. This presents a challenge to any operator who might have increased the log verbosity for the purposes of debugging or extended log collection. Depending on permissions and log storage location, these values could be read by an intruder to the system. The credentials will provide anyone who controls them access to the ironic API server's administrative functions. Additionally, they could be used in conjunction with OpenStack Identity functions to issue new authentication tokens or perform further malicious activity depending on the scope of the administrative account access (for example, modifying account permissions). All nova installations that have values defined for the `admin_password` or `admin_auth_token` options in the `ironic` section, and have set `debug=true` in the `DEFAULT` section of their configuration file will be affected by this issue. ### Recommended Actions ### As of the Liberty-1 release of nova, this issue has been resolved. It has also been backported to the Kilo and Juno stable releases, which can be expected in the 2015.1.1 and 2014.2.4 tags, respectively. Where possible, nova deployments should be updated to one of these releases: Liberty-1, 2015.1.1 (Kilo), or 2014.2.4 (Juno). If updating the nova deployment is not feasible, operators should turn off the debug logging level whenever it is not in use and ensure that log files produced from those debug sessions are stored securely. To disable the debug log level, the nova configuration file should be editted as follows: [DEFAULT] debug = False ### Contacts / References ### This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0049 Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1451931 OpenStack Security ML : openstack-secur...@lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg Oslo Config Special Handling Instructions: http://docs.openstack.org/developer/oslo.config/cfg.html#special-handling-instructions -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVm9gBAAoJEJa+6E7Ri+EVkLAIAJhikdqb4vDycqO/1e1R8L1k W6X/Et2NBGKkPSSMGI1MtJt/QxfqMPqJ/Y0pyyyhnoayvYBJVg12l3hPqTMSnM3N UM4s15mbxJA0wPJrSM8OMVUEpoB30qkDftco/xBnzhC/ClknQwIH3M6G1iWE2Wwk me82RTwta7F2t+u66pPoQ/ByM89YOyuiCSegCKpeCtw+O1qQa5z6zK7gcnhno487 vBPTywoWW/VgQn+zqZGXzXEVFVL0PQ74gXMyF7+6VgG3egJaGwQ9CFx5rmU9fiIr 6+ZSnQTOBhpKv9zVNkg0WGuFAdt/qwuYA9292tCe7xPrSEKtDVLt/Gx6APfRjbU= =fdYf -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [packaging] how to deal with the rename of config files in neutron on upgrade?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/02/2015 06:35 PM, Matt Riedemann wrote: This change in neutron [1] renames the linuxbridge and openvswitch plugin config files. I'm familiar with the %config(noreplace) directive in rpm but I'm not sure if there is a special trick with rpm to rename a config file while not losing the changes in the config file during the upgrade. Is this just something that has to be handled with trickery in the %post macro where we merge the contents together if the old config file exists? Would symbolic links help? Changes like this seem like a potential giant pain in the ass for packagers. [1] https://review.openstack.org/#/c/195277/ Tha change was long overdue. Hopefully, now that the file name is not that misleading, debian packages will avoid loading plugin.ini/ml2_conf.ini for the agents. :) My plan for RDO is to make agents read a config-dir instead of config-files for those files, and populate a config-dir with symlinks pointing to those files that exist on the system. For upgrade scenario, the config-dir will contain links to both files, while for new installations, it will be a single symlink case. And here is the RDO review for your reference: https://review.gerrithub.io/238887 I don't believe those kind of upgrade hacks belong to deployment tools like puppet. Ideally, you would just switch the name of the configuration file and be done with it. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVm8+dAAoJEC5aWaUY1u57+o8IAKOR9Sij61EkdU3jZXivRZSt oRjvACi4uqHdzfYbzY57/mVG999NHJm2Nzkva7b6vvWzltTkHzNIla32tKYUIJjA mjLv5j8ADW10DsHle2EFlJJkEs/uq+Hs+auRLuZmwaWLJt9EeAaPx67w6i4j8/I8 iYsaAWnuM73LoRJQpeODVbeyIi+u4OntybXoFGYxsFfxPlPXKp7+nTgsXd7qRPuj ETEjLiJxc/hsPoD1ItWjuPEjpMg5RV9gTlkH3VDC/xLRINSMqOB/ylE7mcVrh+gb IfR2iEz2iUhJgKyGzjU1zPZLGb3LjafgZzYlUdDSgvnrwqibV4XFj+EtisO11ZI= =dcby -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Segmentation Fault in nova-compute service on ARM platform.
Ohk sean I am Using a platform with low configuration.IF u can help regarding some achitectural changes actually i am stuck at same point from last 7 days. Thanks sean On Jul 7, 2015 5:11 PM, Sean Dague s...@dague.net wrote: On 07/07/2015 07:07 AM, Pradeep kumar wrote: Hi michael, I did tried icehouse release but getting same error. I think there is some issue with python code but how to resolve that need some guidance on the same. It is extremely unlikely that anything in the OpenStack code is responsible for a segfault in python. This seems like your python interpreter being broken on your processor / os. I think you will need to solve that much deeper problem. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Networking-foo projects and release management in the Neutron Stadium
On Mon, Jul 6, 2015 at 10:42 PM, Takashi Yamamoto yamam...@midokura.com wrote: On Tue, Jul 7, 2015 at 10:44 AM, Kyle Mestery mest...@mestery.com wrote: On Mon, Jul 6, 2015 at 5:07 PM, Takashi Yamamoto yamam...@midokura.com wrote: hi, On Tue, Jul 7, 2015 at 2:20 AM, Kyle Mestery mest...@mestery.com wrote: The tl;dr for this email is that the patch referenced here [1] is moving release management tasks for the networking-foo projects into alignment with other Neutron libraries. There is value in having this consolidated into a single place. The longer version is that as plugin backends and new libraries have integrated into the Neutron Stadium, it makes sense to align some release items here. For example, merge commits, tags, and stable branch management aspects are things which are best done by a central team for all networking-foo projects (along with existing projects). In particular, stable releases have some specific requirements [2] which need to be met as stable releases are done here. Ensuring this is following existing processes is part of the reason for this gerrit ACL change. Please comment on the reviews if you have concerns as a networking-foo owner. can you explain how release procedure will be changed? Sure. We'll rely on the release team to help us release these backend libraries and API repositories. These are the same folks doing releases for both clients and oslo libraries. so, basically a maintainer of networking-foo will ask the release team to push a tag? Yes. And the neutron-stable-maint team will handle stable backports as well. Thanks! Kyle [1] https://review.openstack.org/#/c/198749/ [2] https://wiki.openstack.org/wiki/StableBranch __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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 Meiji (明治) - Our next release name has been selected
It is totally understandable that the combination of Japan and Meiji recalls harsh history to some people, especially in East Asia. As a Japanese, I'm sorry for that. I think the release naming process should not cause such friction. Could we just select some other neutral candidate name instead? At Wed, 08 Jul 2015 04:40:58 +, Jaesuk Ahn wrote: Dear OpenStack Community, As Clint mentioned, there is some historical background regarding the name of Meiji. I have been aware of the potential problem with Meiji, however, I have not raise my voice here since it was not the top of the list. However, with current situation, IMHO, it is better to present my concern over this name. It was briefly mentioned in the previous email thread. Once again, please understand that the name Meiji can create some historical debate in East Asia, especially in Korea. Under the name of Emperor Meiji, Japan forcefully colonized Korea. Lots of people in Korea suffered during the colonization. Furthermore, this history is not the one only exists on the book. This is actually very recent event in terms of history. FYI, there is a wiki entry: https://en.wikipedia.org/wiki/Korea_under_Japanese_rule If you look at legacy section in the above wiki entry, you will understand what I am referring to. I am not saying the word Meiji is bad in general. I just want to state that this word can cause very negative feeling to some people in East Asia. I totally value the community's process and rules. I recognize that process to select Meiji itself was not the problem at all. However, I am sincerely asking the community to acknowledge my concern over this name, and please put some effort as a community to avoid any unnecessary debate. Thank you. Best wishes for everyone here in the community. Jaesuk Ahn, Ph.D. member of OpenStack Community and OpenStack Korea User Group. On Wed, Jul 8, 2015 at 2:24 AM Clint Byrum cl...@fewbar.com wrote: http://afe.easia.columbia.edu/main_pop/kpct/kp_meiji.htm There's a summary of what Meiji might mean to historians. I'm not sure if OpenStack needs to be too concerned about this, but I believe this is what Ian is referring to as historical and political debates in East Asia. Seems like a hot-button name for OpenStack to adopt. Excerpts from Ian Y. Choi's message of 2015-07-07 05:40:52 -0700: Hello, I think the third name 'Meiji' may arise some historical and political debates in East Asia, as far as I know. Could you share what significant identified problems are on the first two selected from our election? With many thanks, /Ian On Tue, Jul 7, 2015 at 8:55 PM, Masayuki Igawa masayuki.ig...@gmail.com wrote: Hi, # I'm a native Japanese speaker :-) 2015年7月7日(火) 20:33 Amrith Kumar amr...@tesora.com: Maybe this (the google answer)? www.youtube.com/watch?v=Qvw0A12aOGQ Yeah, this is correct pronunciation. But someone who is a native Japanese speaker should confirm. https://www.youtube.com/watch?v=D9vwge557hY I think this is a casual version and Japanese people are familiar with this. Thanks, -- Masayuki Igawa -amrith P.S. the yahoo answer suggests that you pronounce it as Meh - gee with the emphasis on the meh ;) -Original Message- From: Matthias Runge [mailto:mru...@redhat.com] Sent: Tuesday, July 07, 2015 6:08 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected On Mon, Jul 06, 2015 at 11:48:13PM -0400, Monty Taylor wrote: significant identified problems... but the third in the list, Meiji (明 治) is clear. So please join me in welcoming the latest name to our family ... and if you, like me, are not a native Japanese speaker, in learning two new characters. Could someone provide a hint please, how to pronounce this properly? -- Matthias Runge mru...@redhat.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 -- -- Masayuki Igawa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
