- openstack-discuss - lists.openstack.org

Re: [nova][dev] Any VMware resource pool and shares kind of feature available in openstack nova?
by Sanjay K 05 Mar '19

05 Mar '19

Hello Chris, Thank you for your reply. To give you more clarity on my question, let me describe my goal which I am trying to achieve through openstack nova. scenario 1- say in a compute node, I have some development and production VMs hosted. So in that compute node, production VMs will have more priority than development VMs to contend for compute resources (RAM, vcpus, disk etc). case 2. when both prod and dev VMs are on a compute node, if one user reboots one production VM which was in shutdown/not-running state, the compute node should take this VM resource allocation as priority and readjust/redistribute resources among other existing VMs so that this VM should get the adequate or more resources for which it was initially created with. If it does not find the required resources on that compute, it should migrate or launch this VM on a different compute node based on user consent or just after giving some notification to user that this VM is started on a different compute. case 3. when multiple users simultaneously starts some dev and prod VMs, the production VMs should always get the resources allocated first from the compute. Then the other low priority VMs should get their resources share. In my case, the development and production VMs belong to different subnets. If I know correctly, there is no way nova is doing resource allocation dynamically to VMs once they are hosted on a compute node. It just takes the filters and weights to decide which compute the instance should run. I think the above decision can be handled before filtering and weighing phase kicks in to decide how much resource one VM should be given to. I find the preemptible instances feature useful after going through the discussions/videos, but not sure as of now whether it will solve my cases completely. Please lee me know what you think. thank you for precious inputs. best rgds

2 1

[virtualbmc] Serial console support in virtualbmc
by Lars Kellogg-Stedman 05 Mar '19

05 Mar '19

Hey folks, I wanted serial-over-lan support in virtualbmc so that I can use it for testing while working on getting nova-serialproxy support into tripleo. It turns out that sol support had shown up early in 2018 [1], but was subsequently pulled [2] due to a file descriptor leak. I've tried to rewrite the sol implementation to avoid the file descriptor leak; you can see my work so far in: https://review.openstack.org/#/c/640888/4 It Works For Me at this point. If this is something that interests you I would welcome your feedback. The change is currently marked WIP because there are numerous unit tests that need to be rewritten. [1]: https://review.openstack.org/#/c/482853/ [2]: https://review.openstack.org/#/c/566646/ -- Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ |

1 0

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

05 Mar '19

Hello, Here is the 13th update (Feb 27 to Mar 05, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Highlights of the week: * Tripleo has now a seperate os_tempest playbook for running tempest https://git.openstack.org/cgit/openstack/tripleo-quickstart-extras/tree/pla… * Now os_tempest tripleo reuses the skip list provided by existing validate-tempest role Thanks to Arx for working on that, It is much needed! * os_tempest ping test got improved, disabled by default and pinging to localhost fixed, Thanks to odyssey4me, It will be useful for tempest network related debugging. * os_tempest now updates workspace tempest.conf on changes. * Thanks to jrosser for ceph_rgws patch. * We discussed different approach on how to handle os_tempest dependencies Thanks to mnaser & evrardjp for helping on that. Here is the meeting logs: http://eavesdrop.openstack.org/meetings/openstack_ansible_meeting/2019/open… Things got merged: [os_tempest] * Update workspace tempest.conf on changes - https://review.openstack.org/638014 * Do ping test from tempest host and disable it by default - https://review.openstack.org/639728 * Handle ceph_rgws variable being undefined - https://review.openstack.org/639770 [tripleo] * Reuse the validate-tempest skip list in os_tempest - https://review.openstack.org/634380 * Standardize os_tempest playbook and set vars dynamically - https://review.openstack.org/639310 Things in progress: [os_tempest] * os_tempest dependencies: https://review.openstack.org/#/q/topic:ostempest_packaging+(status:open+OR+… * Fix tempest_image_dir default var to user's home tempest-image dir - https://review.openstack.org/640742 * Create tempest related directories from ansible user - https://review.openstack.org/640005 [os_tempest docs update & tripleo] * Document os_tempest configuration options - https://review.openstack.org/639147 * WIP Prepare for manual execution - https://review.openstack.org/640348 * Add os_tempest documentation - https://review.openstack.org/640859 Martin Kopec is working on the docs, feel free to take a look, try & review. Here is the 12th 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-February/003183… Thanks, Chandan Kumar

1 0

[sahara] PTL Non-Candidacy
by Telles Nobrega 05 Mar '19

05 Mar '19

With the PTL self-nomination period starting this week [0], I wanted to say that I won't be running for the role again. Even though being PTL is a great experience I don't believe that it should stay on the same hands for too long. New eyes, new direction, new priorities are a great oppportunity for the growth of a project. With that in mind, I'm here to support anyone who is willing to run for the post. If you're thinking about running and have questions, please don't hesitate to ask. I'm happy to share my experience. If you know someone who would do well in the position, you should encourage them to run. Thanks for all the time you trusted in me on this role, [0] https://releases.openstack.org/stein/schedule.html#t-ptl-nominations -- TELLES NOBREGA SOFTWARE ENGINEER Red Hat Brasil <https://www.redhat.com/> Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo tenobreg(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil pelo Great Place to Work.

1 0

[TripleO] boot from SAN via FCoE
by Tomáš Bredár 05 Mar '19

05 Mar '19

Hi, I'm struggling with an issue, hopefully someone from this list could help me. Problem: I'm deploying OpenStack Queens with TripleO and would like to deploy my overcloud nodes to disks on my SAN environment. I use virtual-connect flexfabric interfaces and this provides FCoE connection to my nodes. In order to see the LUNs from the SAN in Centos I need to install fcoe-utils package and configure the corresponding eth interfaces. For this I need to build the overcloud-full image and the ironic-python-agent image to support this and to be able see the disk drives during introspection. I was looking for an image element for fcoe boot in [1], but there's none. I tried to make my custom one, but with no luck yet. I can't figure out how to make my SAN driver visible via FCoE during introspection. Is there anyone who had a similar issue and solved it? Thanks Tomas [1] https://github.com/openstack/diskimage-builder/tree/master/diskimage_builde…

1 0

[magnum] Ironic and kuryr support
by ali.sanhaji＠orange.com 05 Mar '19

05 Mar '19

Hi, I would have some questions regarding Ironic and kuryr support, thanks. Ironic: In the doc, it is said that "Currently Ironic is not fully supported yet, therefore more details will be provided when this driver has been fully tested." What's the current status of Ironic support to deploy baremetal K8s clusters? Kuryr: I am interested in having kuryr deployed by magnum in order to have K8s and OpenStack workloads communicate in the same networks I have seen a blueprint on it: https://blueprints.launchpad.net/magnum/+spec/integrate-kuryr-kubernetes Is there a possibility to propose a new blueprint explaining the ideas I have with Magnum, Kuryr and Ironic? Thanks Ali Sanhaji _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

1 0

[TripleO] criteria for deprecating services
by Dan Prince 05 Mar '19

05 Mar '19

Recently we've been cleaning house in some of of the TripleO supported services. We removed MongoDB as RDO was also dropping it. I guess we needed to follow suite as our CI is also based on the packages there. For other services (Designate for example) if the RDO packages exist and we already have support do we really need to deprecate them? Having the ability to deploy some of the lesser used but still active OpenStack projects with our deployment framework is nice for developers and users alike. Especially when you want to try out a new services. Rather than debate these things ad-hoc on some of the various reviews I figured it work asking here. Do we have a criteria for when it is appropriate to deprecate a service that is implemented and fully working? Is it costing us that much in terms of CI and resources to keep a few of these services around? Dan

7 10

[nova] NUMA live migration - mostly how it's tested
by Artom Lifshitz 04 Mar '19

04 Mar '19

Hey all, There won't be much new here for those who've reviewed the patches [1] already, but I wanted to address the testing situation. Until recently, the last patch was WIP because I had functional tests but no unit tests. Even without NUMA anywhere, the claims part of the new code could be tested in functional tests. With the new and improved implementation proposed by Dan Smith [2], this is no longer the case. Any test more involved than unit testing will need "real" NUMA instances on "real" NUMA hosts to trigger the new code. Because of that, I've dropped functional testing altogether, have added unit tests, and have taken the WIP tag off. What I've been using for testing is this: [3]. It's a series of patches to whitebox_tempest_plugin, a Tempest plugin used by a bunch of us Nova Red Hatters to automate testing that's outside of Tempest's scope. Same idea as the intel-nfv-ci plugin [4]. The tests I currently have check that: * CPU pin mapping is updated if the destination has an instance pinned to the same CPUs as the incoming instance * emulator thread pins are updated if the destination has a different cpu_shared_set value and the instance has the hw:emulator_threads_policy set to `share` * NUMA node pins are updated for a hugepages instance if the destination has a hugepages instances consuming the same NUMA node as the incoming instance It's not exhaustive by any means, but I've made sure that all iterations pass those 3 tests. It should be fairly easy to add new tests, as most of the necessary scaffolding is already in place. [1] https://review.openstack.org/#/c/634606/ [2] https://review.openstack.org/#/c/634828/28/nova/virt/driver.py@1147 [3] https://review.rdoproject.org/r/#/c/18832/ [4] https://github.com/openstack/intel-nfv-ci-tests/

5 14

Re: [nova] Support adding/changing delete_on_termination in volume attach api
by Brin Zhang(张百林) 04 Mar '19

04 Mar '19

As Matt said, attach the discussion results at the Forum in Berlin(https://etherpad.openstack.org/p/BER-bfv-improvements #52), you can also read it yourself on the etherpad.: 1.Allow updating delete_on_termination for existing attachments: https://review.openstack.org/#/c/580336/ 1.1 How to model this in the API? -- PUT /servers/{server_id}/os-volume_attachments/{volume_id} body={'volumeAttachment': {'delete_on_termination': True}}? -- Note that the PUT route is already used for swap volume. 1.2 This could break Heat if Heat created the volume, the user changed the flag and then nova deletes the volume but Heat expected it to exist. 1.3 Alternative: if you really love the pet, snapshot it. 1.4 Alternative: if we do the spec above, detach the volume and then re-attach with the delete_on_termination flag set to what you want. For the above [1.2], it has been verified in our R&D environment and customer production environment, no abnormalities have occurred, and everything is operating well. I wonder if any friends have encountered the scene mentioned here, does it have a certain impact on this? Changes to the current nova API: a. I want to add the change of [spec 1 ] to update a volume attachment API, and add "block_device_mapping_v2": [{ "volume_id": "763b894f-af35-4e44-bdb8-2ca45db9ecd8", "delete_on_termination": False }] in the request body. b. Add the change of [spec 2] to attach a volume to an instance API, add the "delete_on_termination" field to request body. [spec 1] https://review.openstack.org/#/c/580336/ Support for changing deleted_on_termination after boot [spec 2] https://review.openstack.org/#/c/612949/ Support delete_on_termination in server attach volume Brin Zhang -----邮件原件----- 发件人: Matt Riedemann [mailto:mriedemos@gmail.com] 发送时间: 2019年3月5日 2:04 收件人: openstack-discuss(a)lists.openstack.org 主题: [lists.openstack.org代发]Re: [nova] Support adding/changing delete_on_termination in volume attach api On 3/3/2019 9:20 PM, Brin Zhang wrote: >> Hi all: >> >> Currently, you can set the "delete_on_termination" field to >> the rood disk when creating the server. You can delete the root disk >> when you delete the server. However, this configuration item cannot be >> updated, so here we propose a scheme that can modify the >> "delete_on_termination" configuration item, such as [1]. >> >> In addition, the data volume of the instance should be allowed to be >> set whether it can be deleted when it is deleted to clean up the >> environment and free up storage space, such as [2]. >> >> These are the more consistent and strongly added requirements from our >> various OpenStack users. >> >> Thank you, looking forward to your reply. >> >> [1] https://review.openstack.org/#/c/580336/ >> >> [2] https://review.openstack.org/#/c/612949/ >> >> Brin Zhang >> >As you know we discussed this at the Forum in Berlin (I know you were not there but you know about the notes in the etherpad). Can you summarize the output of those discussions and what, if anything, it changed about the proposed specs? > >The specs are targeted at Stein, and we are closed for new specs in Stein so those will have to be re-targeted to Train. > >Finally, I was thinking about this recently in regards to the root volume attach/detach change that is proposed because that does not change delete_on_termination when attaching a new root volume, so could be a case for [2] above. In other words, I could boot from volume and say delete_on_termination=True for the root volume (maybe because nova creates it and I do not care to preserve it when the server is gone), detach the root volume and attach a new volume, and now want that delete_on_termination flag to be False. So that might further justify this change. > >-- > >Thanks, > >Matt

1 0

[neutron] Multi-segment per host support for routed networks
by David G. Bingham 04 Mar '19

04 Mar '19

Neutron land, Problem: Neutron currently only allows a single network segment per host. This becomes a problem when networking teams want to limit the number of IPs it supports on a segment. This means that at times the number of IPs available to the host is the limiting factor for the number of instances we can deploy on a host. Ref: https://bugs.launchpad.net/neutron/+bug/1764738 Ongoing Work: We are excited in our work add "multi-segment support for routed networks". We currently have a proof of concept here https://review.openstack.org/#/c/623115 that for routed networks effectively: * Removes validation preventing multiple segments. * Injects segment_id into fixed IP records. * Uses the segment_id when creating a bridge (rather than network_id). In effect, it gives each segment its own bridge. It works pretty well for new networks and deployments. For existing routed networks, however, it breaks networking. Please use *caution* if you decide to try it. TODOs: Things TODO before this before it is fully baked: * Need to add code to handle ensuring bridges are also updated/deleted using the segment_id (rather than network_id). * Need to add something (a feature flag?) that prevents this from breaking routed networks when a cloud admin updates to master and is configured for routed networks. * Need to create checker and upgrade migration code that will convert existing bridges from network_id based to segment_id based (ideally live or with little network traffic downtime). Once converted, the feature flag could enable the feature and start using the new code. Need: 1. How does one go about adding a migration tool? Maybe some examples? 2. Will nova need to be notified/upgraded to have bridge related files updated? 3. Is there a way to migrate without (or minimal) downtime? 4. How to repeatably test this migration code? Grenade? Looking for any ideas that can keep this moving :) Thanks a ton, David Bingham (wwriverrat on irc) Kris Lindgren (klindgren on irc) Cloud Engineers at GoDaddy

2 2