- openstack-discuss - lists.openstack.org

[tripleo][openstack-ansible] collaboration on os_tempest role update XIV - Mar 13, 2019
by Chandan kumar 13 Mar '19

13 Mar '19

Hello, Here is the 13th update (Mar 06 to Mar 12, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Highlights of the week: * docs for os_tempest role configuration added https://docs.openstack.org/openstack-ansible-os_tempest/latest/user/configu… * Now os_tempest role is less dependent on root user * How os_tempest job is defined in tripleo side docs added https://docs.openstack.org/tripleo-docs/latest/install/basic_deployment/os_… * python-tempestconf is gatted with os_temepst tripleo job * Tripleo can now collect os_tempest realted files at one place in user's home directory under tempest folder. http://logs.openstack.org/76/640976/5/check/tripleo-ci-centos-7-standalone-… Thanks to Arx, Martin Kopec, Marios, Sagi on docs help, tempest log collection, odyssey4me, jrosser on tempest vars cleanup & cloudnull, mnaser on other reviews. Things got merged: [os_tempest] * Create tempest related directories from ansible user - https://review.openstack.org/640005 * Remove tempest_image_dir_owner var - https://review.openstack.org/629419 * Document os_tempest configuration options - https://review.openstack.org/639147 [openstack-ansible] * Set tempest_image_dir to /opt/cache/files in openstack CI - https://review.openstack.org/641308 [python-tempestconf] * Add tripleo-ci-centos-7-standalone-os-tempest job - https://review.openstack.org/640992 [tripleo] * Add os_tempest documentation - https://review.openstack.org/#/c/640859/ * Collect os_tempest files from tempest directory - https://review.openstack.org/#/c/640976/ Things in Progress: [os_tempest] * Fix tempest_image_dir default var to user's home tempest-image dir - https://review.openstack.org/640742 * os_tempest dependencies: https://review.openstack.org/#/q/topic:ostempest_packaging+(status:open+OR+… [tripleo] * Adding tempest .txt files in collect-logs role - https://review.openstack.org/#/c/640358/ What next this week: * make tripleo os_tempest job voting * complete os_tempest dependencies * Some more docs addition on how to run os_tempest role locally with minimal vars. Here is the 13th update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003482.ht… Thanks, Chandan Kumar

1 0

[nova] [openstack-charms] [elections] 'Train' Release PTL Election Kickoff
by Kendall Nelson 13 Mar '19

13 Mar '19

Hello Everyone! Polls for PTL elections are now open and will remain open for you to cast your vote until Mar 19, 2019 23:45 UTC. We are having elections for Nova and OpenStack_Charms. If you are a Foundation individual member and had a commit in one of the program's projects[0] over the Feb 09, 2018 00:00 UTC - Feb 19, 2019 00:00 UTC timeframe (Rocky to Stein) then you are eligible to vote. You should find your email with a link to the Condorcet page to cast your vote in the inbox of your gerrit preferred email[1]. What to do if you don't see the email and have a commit in at least one of the programs having an election: * check the trash or spam folders of your gerrit Preferred Email address, in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from the program project repos[0] and email the election officials. If we can confirm that you are entitled to vote, we will add you to the voters list for the appropriate election. Our democratic process is important to the health of OpenStack, please exercise your right to vote! Candidate statements/platforms can be found linked to Candidate names on this page: https://governance.openstack.org/election/#train-ptl-candidates Happy voting, -Kendall Nelson (diablo_rojo) [0] The list of the program projects eligible for electoral status: https://git.openstack.org/cgit/openstack/governance/plain/reference/project… [1] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent.

1 0

[ptl][I18n][election] PTL Candidacy for Train
by Ian Y. Choi 13 Mar '19

13 Mar '19

Hello, I am writing to announce my PTL candidacy of I18n for Train release. I served the PTL role on Ocata and Pike cycle, and have been great memory with last three release cycles with Frank who did so wonderful PTL activities. During Train cycle, I would like to do and collaborate with team members: * Helping to continue previous nice work (e.g., translation checksite, user-survey translation) * Investigating with Zanata's health and possible alternatives [1] * Communicating with translators and language coordinators * Sharing the voice from OpenStack teams with I18n team * Clean handover to the next PTL or discussing with team's direction (e.g., to a working group) I want to add the fourth part - as Frank wrote non-candicacy [2], it would be so great if the project gets fresh air. I don't think I am the part of fresh air since I also stayed in I18n team a lot like Frank. But it seems that I18n team needs more transition and hand-over period for a new PTL, or more discussion with team members might be needed to think about our team's direction such as changing the team status from an official team to a working group. With many thanks, /Ian [1] https://www.redhat.com/archives/zanata-devel/2019-February/msg00000.html [2] http://lists.openstack.org/pipermail/openstack-i18n/2019-March/003367.html

1 0

[ironic][ceilometer] Does anyone use the sensor data collection?
by Julia Kreger 13 Mar '19

13 Mar '19

Greetings everyone, I've been pondering retooling the metrics collection design in ironic, and I'm extremely curious if anyone actually uses what is presently in ironic in terms of metrics collection integration with ceilometer. The events, if enabled, should be getting funneled under the event_type "hardware.ipmi.metrics.update". If your using it, please contact me off-list. Thanks, -Julia

1 0

[ptl][sdk][election] PTL Candidacy
by Monty Taylor 13 Mar '19

13 Mar '19

Hi everybody! I'd like to run for PTL of OpenStackSDK again. We've been angling for a 1.0 release for the last few cycles and still haven't gotten there. We haven't gotten there because as we continue to merge in the shade logic, we've been finding places where we need to make some fundamental changes to the model. For instance, we made all Resource objects also behave like dicts, so that shade methods could return Resource objects directly. In order to do that, we had to rename the 'update' method on Resource objects to 'commit', since dicts have an update method already. We're currently in the midst of moving a good amount of the shade logic into the Proxy layer, so that uploading an image via the shade api or the proxy api is using the same code. That will be ongoing but should mostly be non-disruptive. I believe we're close enough, and have enough of a co-gating relationship with openstackclient, that this next cycle we need to start the work of shifting openstackclient implemention to openstacksdk from the python clients. Doing this should help us shake out any last remaining model deficiencies. We managed to get several long-standing todo list items done this past cycle. Cinder v3 support landed. Finally. We're also microversioning the Ironic calls, and have a good framework in place to do so with the other services as needed. We got the FairSemaphore feature added to keystoneauth which lets us remove the TaskManager and instead rely on an applications existing concurrency mechanism to handle parallelism while retaining our ability to perform client-side rate limiting. This change was actually inspired by some issues we saw in the field with Nodepool and the extra overhead from the TaskManager thread pool, but should end up facilitating more efficient use of openstacksdk constructs in OpenStack services using eventlet or other non-thread based concurrency systems. We still need to overhaul the caching layer. But once TaskManager is out we should be in a better place to deal with that. I'm sure there will be more things to do too. There always are. In any case, I'd love to keep helping to pushing these rocks uphill. Thanks! Monty

1 0

[stable][EM] Extended Maintenace - Pike
by Elõd Illés 13 Mar '19

13 Mar '19

Hi, As we are nearing to Pike Extended Maintenance (release page [1] shows 2019-03-03 but most probably will happen after Stein release) I have generated the list of open changes and unreleased changes on *stable/pike* for the follows-policy tagged repositories [2] (that seems to have relevant changes). Maybe it is useful for teams, who are planning to do a final release on Pike before moving stable/pike branches to Extended Maintenance. [1] https://releases.openstack.org/ [2] https://etherpad.openstack.org/p/pike-final-release-before-em Thanks, Előd

1 0

[ptl][tripleo][election] PTL Candidacy
by Alex Schultz 13 Mar '19

13 Mar '19

I would like to nominate myself for the TripleO PTL role for the Train cycle. Having previously served as PTL during the Queens and Rocky cycle, I think we should focus on the same items as those cycles. We have done excellent work adding python3 support in TripleO. I would like us to return back to focusing on simplification and improving the user experience. * Simplifying the deployment process I believe we should spend time looking at what actions we can remove or reduce by automating them as part of the deployment process. Let's figure out if we can improve the default installation so that we don't have to specify so much. Additionally I would like to start investigating if we can remove some of the services we currently rely on in the undercloud as part of the deployment. * Reducing duplication and tech debt Continued cleanup after containerization by fully removing the baremetal deployment of services as possible. Cleaning up logging and error handling to improve operators ability to troubleshoot their installations. Thanks, Alex Schultz irc: mwhahaha

3 2

[ptg][openstack-ansible] ptg planning
by Mohammed Naser 13 Mar '19

13 Mar '19

Hi everyone, Just a heads up, we've got an etherpad going, please put your name down if you're attending and if there's any subjects you'd like to bring up. https://etherpad.openstack.org/p/osa-train-ptg Thanks Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 0

[api][neutron] tagging support when creating a resource
by Akihiro Motoki 12 Mar '19

12 Mar '19

Hi API-SIG, neutron and tagging-related folks, This email ask opinions on tagging when creating a resource. We received a feature request to support tagging when creating a resource [1]. Neutron supports bulk creation of resources but the current tagging API recommended by the API-SIG does not define tagging when creating a resource. As a result, if we want to create 100 ports with specific tags, we need 1 (bulk creation) +100 (taggins per resource) API calls. It sounds nice to me to support tagging when creating a resource to address the above problem. What in my mind is to specify 'tags' attribute in a body of POST request like: {'port': {'name': 'foo', 'network_id': <network-id>, 'tags': ['red', 'blue'] } } I don't know the reason why the current API-SIG recommended tagging API does not support this model. The current tagging API defines "tags" as a subresource. Is there any reason this model was adopted? Best Regards, Akihiro Motoki (irc: amotoki) [1] https://bugs.launchpad.net/neutron/+bug/1815933 [RFE] Allow bulk-tagging of resources [2] https://specs.openstack.org/openstack/api-wg/guidelines/tags.html

4 5

Re: [nova][dev][ops] can we get rid of 'project_only' in the DB layer?
by Alex Xu 12 Mar '19

12 Mar '19

sorry, I lost the ML address again. Alex Xu <soulxu(a)gmail.com> 于2019年3月12日周二下午10:55写道： > After review this patch https://review.openstack.org/630769, it probably > leads me get some memory back. > > The reason we don't support user based policy and pass the instance's > context as target is John and Sean mention that we don't have enough test > to ensure all the APIs work correctly for cross the tenant user request. > > Similar to the patch https://review.openstack.org/630769 try to fix, that > patch fix the case admin user to execute a shelve action on normal tenant > user. If we enable a tenant user to execute an action on another tenant's > server, that will extend the case of https://review.openstack.org/630769, > we need ensure it works for that case also. > > So hope I remember correctly, just note at here, in case I forget mention > that in the future. > > melanie witt <melwittt(a)gmail.com> 于2019年2月20日周三下午4:16写道： > >> On Tue, 19 Feb 2019 10:42:32 -0600, Matt Riedemann <mriedemos(a)gmail.com> >> wrote: >> > On 2/18/2019 8:22 PM, melanie witt wrote: >> >> Right, that is the proposal in this email. That we should remove >> >> project_only=True and let the API policy check handle whether or not >> the >> >> user from a different project is allowed to get the instance. >> Otherwise, >> >> users are not able to use policy to control the behavior because it is >> >> hard-coded in the database layer. >> > >> > I think this has always been the long-term goal and I remember a spec >> > from John about it [1] but having said that, the spec was fairly >> > complicated (to me at least) and sounds like there would be a fair bit >> > of auditing of the API code we'd need to do before we can remove the DB >> > API check, which means it's likely not something we can complete at this >> > point in Stein. >> > >> > For example, I think we have a lot of APIs that run the policy check on >> > the context (project_id and user_id) as the target before even pulling >> > the resource from the database, and the resource itself should be the >> > target, right? >> > >> > [1] https://review.openstack.org/#/c/433037/ >> >> Thanks for the link -- I hadn't seen this spec yet. >> >> Yes, Alex just pinged me in #openstack-nova and now I finally understand >> his point that I kept missing before. He tried a test with my WIP patch >> and a user from project A was able to 'nova show' an instance from >> project B, even though the policy was set to 'rule:admin_or_owner'. The >> reason is because when the instance project/user isn't passed as a >> target to the policy check, the policy check for the request context >> project_id won't do anything. There's nothing for it to compare >> project_id with. This is interesting because it makes me wonder, what >> does a policy check like that [2] do then? It will take more learning on >> my part about the policy system to understand it. >> >> -melanie >> >> [2] >> >> https://github.com/openstack/nova/blob/3548cf59217f62966a21ea65a8cb74460643… >> >> >> >> >>

1 0