[openstack-dev] [nova] Do we need a microversion to return a 501 from GET os-virtual-interfaces?
A GET request from the os-virtual-interfaces API returns a 500 today if neutron is the networking backend. It would be more accurate to return a 501, but do we need a microversion for that? I intend on implementing the method for the neutronv2 API in nova [1] but it will require a microversion and until then, I was thinking it should return a 501 rather than a 500 but don't want to go through the paperwork if that requires a microversion. [1] https://review.openstack.org/#/c/288965/ -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Proposal: changes to our current testing process
Ivan, I agree that our testing needs improvement. Thanks for starting this thread. With regards to adding a hacking check for tests that run too long ... are you thinking that we would have a timer that checks or long running jobs or something that checks for long sleeps in the testing code? Just curious your ideas for tackling that situation. Would be interested in helping with that, perhaps. Thanks! Jay On 03/02/2016 05:25 AM, Ivan Kolodyazhny wrote: Hi Team, Here are my thoughts and proposals how to make Cinder testing process better. I won't cover "3rd party CI's" topic here. I will share my opinion about current and feature jobs. Unit-tests * Long-running tests. I hope, everybody will agree that unit-tests must be quite simple and very fast. Unit tests which takes more than 3-5 seconds should be refactored and/or moved to 'integration' tests. Thanks to Tom Barron for several fixes like [1]. IMO, we it would be good to have some hacking checks to prevent such issues in a future. * Tests coverage. We don't check it in an automatic way on gates. Usually, we require to add some unit-tests during code review process. Why can't we add coverage job to our CI and do not merge new patches, with will decrease tests coverage rate? Maybe, such job could be voting in a future to not ignore it. For now, there is not simple way to check coverage because 'tox -e cover' output is not useful [2]. Functional tests for Cinder We introduced some functional tests last month [3]. Here is a patch to infra to add new job [4]. Because these tests were moved from unit-tests, I think we're OK to make this job voting. Such tests should not be a replacement for Tempest. They even could tests Cinder with Fake Driver to make it faster and not related on storage backends issues. Tempest in-tree tests Sean started work on it [5] and I think it's a good idea to get them in Cinder repo to run them on Tempest jobs and 3-rd party CIs against a real backend. Functional tests for python-brick-cinderclient-ext There are patches that introduces functional tests [6] and new job [7]. Functional tests for python-cinderclient We've got a very limited set of such tests and non-voting job. IMO, we can run them even with Cinder Fake Driver to make them not depended on a storage backend and make it faster. I believe, we can make this job voting soon. Also, we need more contributors to this kind of tests. Integrated tests for python-cinderclient We need such tests to make sure that we won't break Nova, Heat or other python-cinderclient consumers with a next merged patch. There is a thread in openstack-dev ML about such tests [8] and proposal [9] to introduce them to python-cinderclient. Rally tests IMO, it would be good to have new Rally scenarios for every patches like 'improves performance', 'fixes concurrency issues', etc. Even if we as a Cinder community don't have enough time to implement them, we have to ask for them in reviews, openstack-dev ML, file Rally bugs and blueprints if needed. [1] https://review.openstack.org/#/c/282861/ [2] http://paste.openstack.org/show/488925/ [3] https://review.openstack.org/#/c/267801/ [4] https://review.openstack.org/#/c/287115/ [5] https://review.openstack.org/#/c/274471/ [6] https://review.openstack.org/#/c/265811/ [7] https://review.openstack.org/#/c/265925/ [8] http://lists.openstack.org/pipermail/openstack-dev/2016-March/088027.html [9] https://review.openstack.org/#/c/279432/ Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Non-Admin user can show deleted instances using changes-since parameter when calling list API
On 3/5/2016 9:48 AM, Adam Young wrote: On 03/05/2016 12:27 AM, Chris Friesen wrote: On 03/04/2016 03:42 PM, Matt Riedemann wrote: On 3/3/2016 9:14 PM, Zhenyu Zheng wrote: Hm, I found out the reason: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L1139-L1145 here we filtered out parameters like "deleted", and that's why the API behavior is like above mentioned. So should we simple add "deleted" to the tuple or a microversion is needed? Nice find. This is basically the same as the ip6 case which required microversion 2.5 [1]. So I think this is going to require a microversion in Newton to fix it (which means a blueprint and a spec since it's an API change). But it's pretty trivial, the paperwork is the majority of the work. [1] https://review.openstack.org/#/c/179569/ Does it really need a spec given that microversions are documented in the codebase? That almost seems like paperwork for the sake of following the rules rather than to serve any useful purpose. Is anyone really going to argue about the details? I've been lurking on this discussion. I was worried that you were going to try to hard code "admin" somewhere in here. If the only change is that the currently accepted set of params is enforced with the current set of policy rules, just in a slightly different place, it will not break people, and thus I would think no microversion is essential. However, if the the user might need to test which way policy is enforced in order to use the right code path when doing a client call, then a microversion would be needed. Chris __ OpenStack Development Mailing 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 The ip6 case and microversion 2.5 is exactly the same scenario and sets precedent here, so yes we need a microversion which makes it an API change which according to our policy requires a spec. I realize it's trivial, but them's the rules. As far as I can tell, this is latent behavior since forever and no one has freaked out about it before, so I don't think doing things by the book and doing that in Newton is going to cause any problems. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum][magnum-ui] Liaisons for I18n
Adrian, I think Shu Muto was originally proposed to be a magnum-ui liaison, not magnum liaison. Best regards, Hongbin -Original Message- From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: March-04-16 7:27 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum][magnum-ui] Liaisons for I18n Kato, I have confirmed with Shu Muto, who will be assuming our I18n Liaison role for Magnum until further notice. Thanks for raising this important request. Regards, Adrian > On Mar 3, 2016, at 6:53 AM, KATO Tomoyuki wrote: > > I added Magnum to the list... Feel free to add your name and IRC nick, Shu. > > https://wiki.openstack.org/wiki/CrossProjectLiaisons#I18n > >> One thing to note. >> >> The role of i18n liaison is not to keep it well translated. >> The main role is in a project side, >> for example, to encourage i18n related reviews and fixes, or to >> suggest what kind of coding is recommended from i18n point of view. > > Yep, that is a reason why a core reviewer is preferred for liaison. > We sometimes have various requirements: > word ordering (block trans), n-plural form, and so on. > Some of them may not be important for Japanese. > > Regards, > KATO Tomoyuki > >> >> Akihiro >> >> 2016-03-02 12:17 GMT+09:00 Shuu Mutou : >>> Hi Hongbin, Yuanying and team, >>> >>> Thank you for your recommendation. >>> I'm keeping 100% of EN to JP translation of Magnum-UI everyday. >>> I'll do my best, if I become a liaison. >>> >>> Since translation has became another point of review for Magnum-UI, I hope >>> that members translate Magnum-UI into your native language. >>> >>> Best regards, >>> Shu Muto > > __ > OpenStack Development Mailing 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] [magnum-ui] Proposed Core addition, and removal notice
+1 BTW, I am magnum core, not magnum-ui core. Not sure if my vote is counted. Best regards, Hongbin -Original Message- From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: March-04-16 7:29 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [magnum-ui] Proposed Core addition, and removal notice Magnum UI Cores, I propose the following changes to the magnum-ui core group [1]: + Shu Muto - Dims (Davanum Srinivas), by request - justified by reduced activity level. Please respond with your +1 votes to approve this change or -1 votes to oppose. Thanks, Adrian __ OpenStack Development Mailing 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] [tripleo] CI jobs failures
I'm kind of hijacking Dan's e-mail but I would like to propose some technical improvements to stop having so much CI failures. 1/ Stop creating swap files. We don't have SSD, this is IMHO a terrible mistake to swap on files because we don't have enough RAM. In my experience, swaping on non-SSD disks is even worst that not having enough RAM. We should stop doing that I think. 2/ Split CI jobs in scenarios. Currently we have CI jobs for ceph, HA, non-ha, containers and the current situation is that jobs fail randomly, due to performances issues. Puppet OpenStack CI had the same issue where we had one integration job and we never stopped adding more services until all becomes *very* unstable. We solved that issue by splitting the jobs and creating scenarios: https://github.com/openstack/puppet-openstack-integration#description What I propose is to split TripleO jobs in more jobs, but with less services. The benefit of that: * more services coverage * jobs will run faster * less random issues due to bad performances The cost is of course it will consume more resources. That's why I suggest 3/. We could have: * HA job with ceph and a full compute scenario (glance, nova, cinder, ceilometer, aodh & gnocchi). * Same with IPv6 & SSL. * HA job without ceph and full compute scenario too * HA job without ceph and basic compute (glance and nova), with extra services like Trove, Sahara, etc. * ... (note: all jobs would have network isolation, which is to me a requirement when testing an installer like TripleO). 3/ Drop non-ha job. I'm not sure why we have it, and the benefit of testing that comparing to HA. Any comment / feedback is welcome, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Non-Admin user can show deleted instances using changes-since parameter when calling list API
On 03/05/2016 12:27 AM, Chris Friesen wrote: On 03/04/2016 03:42 PM, Matt Riedemann wrote: On 3/3/2016 9:14 PM, Zhenyu Zheng wrote: Hm, I found out the reason: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L1139-L1145 here we filtered out parameters like "deleted", and that's why the API behavior is like above mentioned. So should we simple add "deleted" to the tuple or a microversion is needed? Nice find. This is basically the same as the ip6 case which required microversion 2.5 [1]. So I think this is going to require a microversion in Newton to fix it (which means a blueprint and a spec since it's an API change). But it's pretty trivial, the paperwork is the majority of the work. [1] https://review.openstack.org/#/c/179569/ Does it really need a spec given that microversions are documented in the codebase? That almost seems like paperwork for the sake of following the rules rather than to serve any useful purpose. Is anyone really going to argue about the details? I've been lurking on this discussion. I was worried that you were going to try to hard code "admin" somewhere in here. If the only change is that the currently accepted set of params is enforced with the current set of policy rules, just in a slightly different place, it will not break people, and thus I would think no microversion is essential. However, if the the user might need to test which way policy is enforced in order to use the right code path when doing a client call, then a microversion would be needed. Chris __ OpenStack Development Mailing 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-ansible][security] Security hardening backport to Liberty desirable?
On 4 March 2016 at 16:50, Major Hayden wrote: > Hey folks, > > I have proposed a review[1] which adds the openstack-ansible-security[2] > role to OpenStack-Ansible's Liberty release. I would really appreciate > some feedback from deployers on whether this change is desirable in Liberty. > > The role applies cleanly to Liberty on Ubuntu 14.04 and the role already > has some fairly basic gating. > > The two main questions are: > > 1) Does it make sense to backport the openstack-ansible-security > role/playbook to Liberty? > 2) Should it be applied by default on AIO/gate builds as it is > in Mitaka (master)? > > Thanks! > > [1] https://review.openstack.org/#/c/273257/ > [2] http://docs.openstack.org/developer/openstack-ansible-security/ Hi Major, Liberty is a stable branch and the Mitaka release is just around the corner. I think it's a bit late in the game to add it. Consider, also, that deployers can easily consume the role with their own playbook to execute it if they would like to. *If* a backport is supported by the consuming community and core team, I would only support an opt-in model to allow deployers to make use of the role, but only if they choose to. __ OpenStack Development Mailing 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] [Manila] Concurrent execution of drivers
Are we still going to think of nfs-over-vsock? Never mind. It's just coming from my curiosity. Cheers, S On Fri, Mar 4, 2016 at 11:08 PM, Valeriy Ponomaryov wrote: >> Thanks - so if I understand you correctly, each share instance is >> uniquely associated with a single instance of the driver at one time, >> right? So while I might have two concurrent calls to ensure_share, >> they are guaranteed to be for different shares? > > Yes. > >> Is this true for the whole driver interface? > > Yes. > >> >> Two instances of the >> driver will never both be asked to do operations on the same share at >> the same time? > > > Yes. > > Each instance of a driver will have its own unique list of shares to be > 'ensure'd. > > -- > Kind Regards > Valeriy Ponomaryov > www.mirantis.com > vponomar...@mirantis.com > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Email: shin...@linux.com GitHub: shinobu-x Blog: Life with Distributed Computational System based on OpenSource __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum-ui] Proposed Core addition, and removal notice
＋1, Really good contribution. :) Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan） IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: 大�V元央 To: "OpenStack Development Mailing List (not for usage questions)" Date: 05/03/2016 06:25 pm Subject:Re: [openstack-dev] [magnum-ui] Proposed Core addition, and removal notice +1, welcome Shu. -Yuanying On Sat, Mar 5, 2016 at 09:37 Bradley Jones (bradjone) wrote: +1 Shu has done some great work in magnum-ui and will be a welcome addition to the core team. Thanks, Brad > On 5 Mar 2016, at 00:29, Adrian Otto wrote: > > Magnum UI Cores, > > I propose the following changes to the magnum-ui core group [1]: > > + Shu Muto > - Dims (Davanum Srinivas), by request - justified by reduced activity level. > > Please respond with your +1 votes to approve this change or -1 votes to oppose. > > Thanks, > > Adrian > __ > OpenStack Development Mailing 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] [magnum-ui] Proposed Core addition, and removal notice
+1, welcome Shu. -Yuanying On Sat, Mar 5, 2016 at 09:37 Bradley Jones (bradjone) wrote: > +1 > > Shu has done some great work in magnum-ui and will be a welcome addition > to the core team. > > Thanks, > Brad > > > On 5 Mar 2016, at 00:29, Adrian Otto wrote: > > > > Magnum UI Cores, > > > > I propose the following changes to the magnum-ui core group [1]: > > > > + Shu Muto > > - Dims (Davanum Srinivas), by request - justified by reduced activity > level. > > > > Please respond with your +1 votes to approve this change or -1 votes to > oppose. > > > > Thanks, > > > > Adrian > > > __ > > OpenStack Development Mailing 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
