July 2019 - openstack-discuss - lists.openstack.org

[rdo] [packstack] failing to setup Stein with Openvswitch/VXLAN networking
by Bernd Bausch 01 Aug '19

01 Aug '19

Trying to set up a Stein cloud with Packstack. I want the Openvswitch mech driver and VXLAN type driver. A few weeks ago, the following invocation was successful: |sudo packstack --debug --allinone --default-password pw \ --os-neutron-ovs-bridge-interfaces=br-ex:eth0 \ --os-neutron-ml2-tenant-network-types=vxlan \ --os-neutron-ml2-mechanism-drivers=openvswitch \ --os-neutron-ml2-type-drivers=vxlan,flat \ --os-neutron-l2-agent=openvswitch \ --provision-demo-floatrange=10.1.1.0/24\ --provision-demo-allocation-pools '["start=10.1.1.10,end=10.1.1.50"]'\ --os-heat-install=y --os-heat-cfn-install=y||| Now, it fails during network setup. My network connection to the Packstack server is severed, and it turns out that its only network interface /eth0 /has no IP address and is down. No bridge exists. In the /network.pp.finished /file, I find various /ovs-vsctl /commands including /add-br/, and a command /ifdown eth0 /which fails with exit code 1 (no error message from the /ifdown /command is logged). *Can somebody recommend the options required to successfully deploy a Stein cloud based on the Openvswitch and VXLAN drivers?* Thanks much, Bernd || ||

2 3

[dev][nova][glance][cinder] introducing 'compressed' image container_format
by Ma, Zheng 01 Aug '19

01 Aug '19

Hello Nova developers, Cinder is working on a feature that will allow it to compress volumes uploaded to Glance [0,1]. We are proposing a new container_format for Glance named 'compressed' [2]. The idea is that a consumer of a 'compressed' image would read the file to determine the kind of compression and take appropriate action (either successfully decompress to find a payload that matches the image's disk_format, or fail with 'unsupported container_format'). Our preliminary testing with a raw image with container_format == compressed, disk_format == raw is that Nova boots a VM from the image but the VM appears to be unusable. Nova seems taking it as a real RAW image as disk_format indicates. So we want to open a discussion about handling this. Thanks! [0] cinder spec patch https://review.opendev.org/#/c/652275/ [1] cinder code implementation https://review.opendev.org/#/c/668825 [2] glance spec patch https://review.opendev.org/#/c/670454/

2 1

[all] Pycharm Licences
by ʂʍɒρƞįł Ҟưȴķɒʁʉɨ 31 Jul '19

31 Jul '19

I have renewed the Pycharm licenses for community contributors until July 29, 2020. For everyone who is using it will be updated automatically. Please do not request again for renewal. Best Regards, Swapnil

2 1

[swift] Shanghai PTG attendance and etherpad
by tim＠swiftstack.com 31 Jul '19

31 Jul '19

你好! Most teams sent out emails two or three weeks ago with etherpads to start estimating headcount and coming up with discussion topics. I was a little slow, but here's Swift's: https://etherpad.openstack.org/p/swift-ptg-shanghai We're thinking of doing something a little different from our previous PTGs and hackathons and want to offer a kind of extended onboarding session. If you're new to Swift, this is a great opportunity to learn more about - how Swift works, - how to write applications against Swift, - how to deploy and operate your own Swift cluster, or - how to do upstream development for Swift. Interested? We'd love to hear from you and meet you! If there are any other aspects of Swift you'd like to learn about or dive deeper on, feel free to add them! I'll try to develop some materials based on people's level of interest so it won't all be off-the-cuff :-) Of course, there will also be more-traditional design discussions going on. (I don't think I could stop this if I tried -- it seems *any time* there are three or more Swift contributors around, there are going to be design discussions happening!) If you know you want to talk about some upcoming features or other work, please update the Development Topics at the bottom. 在上海见到您们! Tim

1 0

[openstack-ansible] office hours update
by Mohammed Naser 31 Jul '19

31 Jul '19

Hey everyone, Here is the update of what happened during the OpenStack Ansible office hours this week. We thought there was an issue with the logic that determines nova_cinder_rbd_inuse running on localhost and setting the fact only on localhost (and not the host that’s it’s running it on). So the variable ‘nova_cinder_rbd_inuse’ was always set to false on these hosts. The issue was a missing rbd configuration in nova.conf and that issue has been fixed. Thanks for tuning in and thanks for Tiffanie for taking care of the basic meeting logistics! Regards, 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

[tripleo][charms][helm][kolla][ansible][puppet][chef] Deployment tools capabilities v0.1.0
by Thierry Carrez 31 Jul '19

31 Jul '19

Hi, deployment tools teams, As mentioned here last month[1], we are working to improve the information present on the deployment tools pages on the OpenStack website, and we need your help! After the Forum session on this topic in Denver[2], a workgroup worked on producing a set of base capabilities that can be asserted by the various deployment tools we have. You can find version 0.1.0 of those capabilities here: https://opendev.org/osf/openstack-map/src/branch/master/deployment_tools_ca… As an example, I pushed a change that makes every deployment tool assert the capability to deploy keystone ("components:keystone" tag) at: https://review.opendev.org/#/c/669648/ Now it's your turn. Please have a look at the list of the capabilities above, and propose a change to add those that are relevant to your deployment tool in the following file: https://opendev.org/osf/openstack-map/src/branch/master/deployment_tools.ya… Capabilities are all of the form "category:tag" (components:keystone, starts-from:os-installed, technology:puppet...). Once all deployment projects have completed that task, we'll add the capabilities to the rendered page on the website and allow for basic searching for tools with matching capability. Now, capabilities go only so far in describing your deployment tool. I also encourage you to improve in the same file the "desc" field: that one is directly displayed on the site.Uuse it to describe in more details how your deployment tool actually works and what makes it unique, beyond basic capabilities tags. Please feel free to use this thread (or personal email) if you have questions on this. And thanks in advance for your help! [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006964.html [2] https://etherpad.openstack.org/p/DEN-deployment-tools-capabilities -- Thierry Carrez (ttx)

1 1

Re: [User-committee] [all][uc] Train UC Election Season
by Ian Y. Choi 31 Jul '19

31 Jul '19

+ openstack-discuss mailing list for broader announce of Train UC Election :) - Ed & Ian Ed Leafe wrote on 7/31/2019 11:20 PM: > Hello All! > > The User Committee (UC) election is coming! > > The OpenStack User Committee [1] is one of the governing bodies of the OpenStack project to serve the user community of OpenStack, representing them to the broader community. > > If you are not aware of UC election, please see the details first: > > Election details: > https://governance.openstack.org/uc/reference/uc-election-aug2019.html > > Please read the stipulations and timelines for candidates and electorate contained in this governance documentation. Note that the nomination period begins soon! (August 5). > > There will be further announcements posted to the mailing list as action is required from the electorate or candidates. This email is for information purposes only. > > If you have any questions which you feel affect others please reply to this email thread. > > If you have any questions that you which to discuss in private please email any of the election officials [2] so that we may address your concerns. > > Thank you, > > - Ed & Ian > > [1] https://governance.openstack.org/uc/reference/charter.html > [2] https://governance.openstack.org/uc/reference/uc-election-aug2019.html#offi… > > > _______________________________________________ > User-committee mailing list > User-committee(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee

1 0

[dev][keystone][keystonemiddleware] Keystone CADF notifications for rabbitmq
by Ondřej Duchoň 31 Jul '19

31 Jul '19

Hello, I am trying to make to work CADF notifying for nova_api and other modules into rabbitmq. I tried to use keystonemiddleware ( https://docs.openstack.org/keystonemiddleware/queens/audit.html) but no notifications appeared. The only thing that is sending CADF notifications into rabbitmq is keystone. I assume that is because keystone has its own notifier. (keystone/notifications.py) Do you have some idea about this problem? Which approach is correct in this case? Thank you for your help, Ondrej

2 1

[kolla] cancelling meeting today
by Michał Nasiadka 31 Jul '19

31 Jul '19

Hello, Since there are no hot topics and the PTL/core team are unavailable for the meeting - it will be cancelled. See you next week on #openstack-kolla -- Michał Nasiadka mnasiadka(a)gmail.com

1 0

Magnum Kubernetes openstack-cloud-controller-manager unable not resolve master node by DNS
by Pawel Konczalski 31 Jul '19

31 Jul '19

Hi, i try to deploy a Kubernetes cluster with OpenStack Magnum but the openstack-cloud-controller-manager pod fails to resolve the master node hostname. Does magnum require further parameter to configure the DNS names of the master and minions? DNS resolution in the VMs works fine. Currently there is no Designate installed in the OpenStack setup. openstack coe cluster template create kubernetes-cluster-template1 \ --image Fedora-AtomicHost-29-20190429.0.x86_64 \ --external-network public \ --dns-nameserver 8.8.8.8 \ --master-flavor m1.kubernetes \ --flavor m1.kubernetes \ --coe kubernetes \ --volume-driver cinder \ --network-driver flannel \ --docker-volume-size 25 openstack coe cluster create kubernetes-cluster1 \ --cluster-template kubernetes-cluster-template1 \ --master-count 1 \ --node-count 2 \ --keypair mykey # kubectl get pods --all-namespaces -o wide NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE kube-system coredns-78df4bf8ff-mjp2c 0/1 Pending 0 36m <none> <none> <none> kube-system heapster-74f98f6489-tgtzl 0/1 Pending 0 36m <none> <none> <none> kube-system kube-dns-autoscaler-986c49747-wrvz4 0/1 Pending 0 36m <none> <none> <none> kube-system kubernetes-dashboard-54cb7b5997-sk5pj 0/1 Pending 0 36m <none> <none> <none> kube-system openstack-cloud-controller-manager-dgk64 0/1 CrashLoopBackOff 11 36m <none> kubernetes-cluster1-vulg5fz6hg2n-master-0 <none> # kubectl -n kube-system logs openstack-cloud-controller-manager-dgk64 Error from server: Get https://kubernetes-cluster1-vulg5fz6hg2n-master-0:10250/containerLogs/kube-…: dial tcp: lookup kubernetes-cluster1-vulg5fz6hg2n-master-0 on 8.8.8.8:53: no such host BR Pawel

2 3

[loci][openstack-helm][tc] Proposal to fold Loci into OpenStack-Helm
by Chris Hoge 31 Jul '19

31 Jul '19

In the interest of consolidating workload, I'm proposing that we roll the Loci project under the governance of OpenStack Helm. Loci is a fairly low-bandwidth project, with the primary consumer of it being OpenStack Helm. By rolling Loci into OSH, we will be able focus shared efforts and increase review velocity for the Loci project. The architecture of OpenStack Helm allows it to be container build-system agnostic, and similarly the architecture of Loci allows it to be deployment tooling agnostic. Neither of these goals will change, as there are users of both projects that aren't using the other. However, as they are the largest consumers for each other's work, this is a natural pairing and both project stand to benefit from a tighter governance coupling. We already share a good proportion of the development team and frequently plan PTG sessions to allow for collaboration. If the community agrees with this approach, we would like to finalize the governance change before the next development cycle to allow for a graceful transition. Thanks, Chris Hoge Loci PTL

2 1

[scientific-sig][cloudkitty][monasca] SIG IRC meeting today - accounting using Monasca and CloudKitty
by Stig Telfer 31 Jul '19

31 Jul '19

Hi All - We have an IRC meeting today at 1100 UTC in channel #openstack-meeting. Everyone is welcome. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_July_31st_2019 <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_July_31st_2019> Today we are looking to gather data on accounting, chargeback and billing, and we have a report on recent investigations using Monasca and CloudKitty together for this purpose. Cheers, Stig

1 0

[mistral] Office hour in ~30 min
by Renat Akhmerov 31 Jul '19

31 Jul '19

Hi, We’ll have an office hour at 8.00 UTC today (in ~30 min) so you’re welcome to join and chat with us. Thanks Renat Akhmerov @Nokia

1 0

[ops][keystone] Does anyone use external auth?
by Colleen Murphy 30 Jul '19

30 Jul '19

Currently, one of the default auth methods for keystone is 'external', meaning keystone offloads authentication to an HTTPD auth module like mod_ssl or mod_auth_kerb and gets the user's identity from the REMOTE_USER variable passed in by the web server: https://docs.openstack.org/keystone/latest/admin/external-authentication.ht… The 'external' auth method existed before federation. The biggest problem with external auth now is that it is effectively single-domain, there's no way to parse anything besides a user identifier from the REMOTE_USER variable, and keystone is barreling full steam ahead to a multidomain world. The 'external' auth method conflicts with the 'mapped' auth method as mentioned in the "Caution" notice in the above document for the same reason. Moreover, we should be able to achieve the same behavior with just federation, e.g. you can create a federated IdP representing your SSL CA, and continue to use mod_ssl with a mapping to properly parse all the attributes coming in from the auth module. We'd like to start discouraging, deprecating, and removing external auth in keystone. So our question to operators is: are you currently using external auth? If so, which HTTPD auth modules are you using? And is it a use case that we can't support with federated auth? Colleen (cmurphy)

2 2

[cinder] lvm_mirrors option seems to be broken
by Mark Lehrer 30 Jul '19

30 Jul '19

I have 4 fast nvme targets that I want to combine using RAID 10 and use with cinder-lvm. Unfortunately, lvm+mdadm is breaking all of my writes down to 4K -- without even increasing the queue depth to match. SSDs hate this workload. I tried bypassing mdadm by seting up LVM RAID10 by hand and got roughly a 10x increase in performance, so I definitely want to use this if possible. However, it looks like maybe the lvm_mirrors code hasn't been kept up to date. I ran into two main problems trying to use it: 1) The algorithm to calculate free space is broken and always returns 0. This means that the scheduler will never even try to use this pool 2) Thin provisioning is getting in the way... with lvm_mirrors enabled the code is apparently trying to create a new LV on top of the thin provisioned LV... and it is using an lvcreate option that appears to be deprecated (--mirrorlog mirrored) I expect I can fix #1, but what is the best way to handle #2? I was thinking that the easiest fix would be to use the mirror options when the thin LV is created, though I haven't tried it by hand yet to see if it works. The advantage here is that this is a one-time setting and the code path to create individual volumes wouldn't need to check lvm_mirrors at all. Thanks, Mark

2 4

[ops] NYC ops meetup sept 3,4 registration site live!
by Chris Morgan 30 Jul '19

30 Jul '19

Registration: https://go.bloomberg.com/attend/invite/open-stack-operators-quarterly-summi… planning etherpad : https://etherpad.openstack.org/p/NYC19-OPS-MEETUP Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

Retiring tc-as-a-service
by Andreas Jaeger 30 Jul '19

30 Jul '19

This repo was imported and never used, I'll start the retirement process for it now. Ofer, one of the initial developer on the project confirmed that the repo is dead, Andreas -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

1 0

[release][infra] Supporting rget in our release process
by corvus＠inaugust.com 30 Jul '19

30 Jul '19

Hi, A colleague at Red Hat is working on an effort to record signatures of release artifacts. Essentially it's a way to help users verify release artifacts (or determine if they have been changed) independent of PGP signatures. You can read about it here: https://github.com/merklecounty/rget#rget It sounds like an interesting and useful effort, and I think we can support it at little cost. If we wanted to do so, I think we would need to do the following things: 1) Generate SHA256SUMS of our release artifacts. These could even include the GPG signature files. 2) Run "rget submit" on the resulting files after publication. That's it. Both of those would be changes to the release publication jobs, and wouldn't require any other changes to our processes. As mentioned in the README this is very early stages and the author, Brandon Philips, welcomes both further testing and feedback on the process in general. Thoughts? -Jim

5 4

Deprecate Aggregate[Core|Ram|Disk]Filters
by Sean Mooney 30 Jul '19

30 Jul '19

Hi all, back in january 2018 we annouced that the behavior of the Aggregate[Core|Ram|Disk]Filters http://lists.openstack.org/pipermail/openstack-dev/2018-January/126283.html form ocata on due to the use of placement you can no longer manage overcomit ratios using aggregate metadata as placement has no access to this data. as a result these filters if you use with placement then they only work if the aggregates enforce lower limits then placement default. if you also limit the responces from placemnet this also does not work as we may not recive any host that satisfy the lower limit in the aggregate metadata even if such host exist in the aggreate. we have a prominent warning https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#… advising operator of the impact of this change as well as this wont fix bug from last November https://bugs.launchpad.net/nova/+bug/1804125 11 months ago we deprecated the non aggreate [Core|Ram|Disk] Filters https://review.opendev.org/#/c/596502/ for several reasons noted in the commit and we furthermore removed the caching scheduler in stien. a few days ago we finally deleted the non aggreagate filters with https://github.com/openstack/nova/commit/78645e61c63bf042453d1f822ae8b3f1ee… but the Aggregate[Core|Ram|Disk]Filters are still present. we had intended to deprecate the Aggregate[Core|Ram|Disk]Filters in ocata when we sent the initial email about the behavior change however we never actully followed up and formally deprecated it in code. similarly when we formally deprecated the [Core|Ram|Disk] Filters we could have deprecated the Aggregate[Core|Ram|Disk]Filters too but we did not. As a result we cannot remove the Aggregate[Core|Ram|Disk]Filters in Train but i have proposed : https://review.opendev.org/673496 To formally deprecate them with the intent of removing them in the U cycle. In the 19.0.0 Stein release initial allocation ratios support was completed which allow managing of the allocation ratios via the placement api in addition to the existing capability to manage allocation ratios via the nova config. https://github.com/openstack/nova-specs/blob/master/specs/stein/implemented… As of the 18.0.0 rocky release nova automatically mirrors ``host-aggregates`` to placement aggregates. https://github.com/openstack/nova-specs/blob/master/specs/rocky/implemented… There is ongoing work in Train to enhance osc-placement to add a 'resource provider inventory update' command to make setting overcommit allocation ratios on a per-aggregate basis easier https://review.opendev.org/#/c/640898/ . These 3 features combined will allow operators to manage Aggreate Resource class allocation ratios in a placement native way. finally in the case the above was not sufficent motivation the AggregateCoreFilter it does not support handeling vCPU and pCPU resouce classes seperatly and will not work with the new cpu resouce tracking spec correctly. https://github.com/openstack/nova-specs/blob/master/specs/train/approved/cp… the AggregateRamFilter also does not understand the difference bewteen hugepage memory and standard memroy which means that even if we were to keep the filters they do not work correctly in all cases and will continue to becomre more broken over time, so i think the time has come to finally do this. regards sean

1 0

Error: python2-uritemplate conflicts with python2-uri-templates-0.6-5.el7.noarch
by Md. Farhad Hasan Khan 30 Jul '19

30 Jul '19

Hi, When I run # yum update and found below conflict: --> Processing Conflict: python2-uritemplate-3.0.0-1.el7.noarch conflicts python2-uri-templates --> Finished Dependency Resolution Error: python2-uritemplate conflicts with python2-uri-templates-0.6-5.el7.noarch You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles -nodigest If I remove python2-uri-templates-0.6-5.el7.noarch than below package ask to remove: Removing: python2-uri-templates noarch 0.6-5.el7 @centos-openstack-rocky 20 k Removing for dependencies: openstack-cinder noarch 1:13.0.5-1.el7 @centos-openstack-rocky 200 k python-cinder noarch 1:13.0.5-1.el7 @centos-openstack-rocky 19 M python2-google-api-client noarch 1.4.2-4.el7 @centos-openstack-rocky 305 k please let help me how can I update. Thanks/Rony

2 3

[qa]Proposing Attila Fazekas (afazekas) to Devstack Core list
by Ghanshyam Mann 30 Jul '19

30 Jul '19

Hello Everyone, I would like to propose to add Attila Fazekas (afazekas) in devstack core list. He has been contributing and reviewing code in devstack since a long time and has deep knowledge of code base. Please reply with your approval or objections. If no objection then till 5th Aug, I will add him in the list. -gmann

1 0

[I18n] project team status update regarding internationalization/translation as July 2019
by Ian Y. Choi 30 Jul '19

30 Jul '19

Hello all, I would like to share current project team status for better visibility into I18n team members, copying to openstack-discuss and user-committee thread: 1. Translation and team effort status There are still lots of translation contribution as you see through Stackalytics: https://www.stackalytics.com/?metric=translations&release=train . The number of translated words is not larger than the previous cycle, but I estimate that it will be similar or a little bit less than the previous cycle since I18n usually contributes translations a lot especially during Soft & Hard StringFreeze periods. Note that I18n team currently sets higher priority on OpenStack user survey translation and project document translations. Such priorities information can be found on Zanata dashboard: https://translate.openstack.org/ . Other progress such as migrating Zanata into other translation platform seems slow - me and Frank are planning to have a virtual sprint. 2. Shanghai Summit & PTG preparation : Frank submitted his presentation including me and Hoarce (China team). Let's wait for final approval on presentation submission. : There should be PTG at Shanghai - please add your name and detail thinking to Etherpad mentioned in http://lists.openstack.org/pipermail/openstack-i18n/2019-July/003436.html . I strongly think to more encourage participation since I expect more participation especially from Chinese translators & contributors. 3. Updating ATC & AUC : Frank previously submitted extra-ATC for Stein through https://review.opendev.org/#/c/633398/ , and this time I would like to submit the stat calculation from 2019-01-26 to 2019-07-25. : All contributors who had commits on openstack/i18n repository will be automatically regarded as Active Technical Contributors [1], and I18n team would like to nominate all translators who contributed translations on OpenStack official repositories (https://governance.openstack.org/tc/reference/projects/ ) >= 300 words as extra-ATCs assuming that their Zanata e-mail IDs are registered as Foundation members. : All translators who contributed >=300 word tranlations to the following projects will be nominated as Active User Contributors [2] assuming that their Zanata e-mail IDs are registered as Foundation members: "contributor-guide, edge-computing, leveraging-containers-openstack, openstack-user-survey, operations-guide". This is new nomination after the decision during Stein PTG with User Committee: Please see [3] and [4] if you would like to follow-up with more information. I will do this nomination for ATC & AUC as PTL just after July 25, although the due of extra ATC is Aug 26-30 [5] since I synced with Foundation that the price of Summit ticket will increase around Aug 7 : processing within the due will be fine, also I set period exactly for six months. 4. Team status : Although I regularly be online during I18n (+Docs) IRC team meetings, I couldn't find enough quorum, and I couldn't proceed more deep conversation with language teams (usually no reply from my e-mails unfortunately). : Current I18n team core members seem busy but when I communicate with them, all they are still very supportive to I18n team projects. I really appreciate their kind help. : Also, I find that some translators are very active comparing to some inactive language coordinators. In this case, would it be a good idea to nominate them as language coordinators? Please share your thoughts. : However, if such lack of team member conversations keep going, then I18n team might decide during upcoming PTG to make translation from an official team status into Special Interest Group [6]. This would mean that there will be no official PTL election and there will be no extra-ATC nomination, although I need to more figure out in details in future. With many thanks, /Ian [1] https://docs.openstack.org/i18n/latest/official_translator.html#atc-status-… [2]https://governance.openstack.org/uc/reference/charter.html#active-user-co… [3] http://lists.openstack.org/pipermail/openstack-i18n/2018-September/003316.h… [4] http://eavesdrop.openstack.org/meetings/uc/2018/uc.2018-10-01-18.02.html [5] https://releases.openstack.org/train/schedule.html [6] https://governance.openstack.org/sigs/

2 2

[TripleO] Transformation squad meeting time
by Kevin Carter 30 Jul '19

30 Jul '19

Hello, I'm writing to get feedback on what the best meeting time would be for all parties interested in participating in the TripleO Transformation Squad efforts. During this weeks meeting, it was raised that the current weekly time, Thursday 13:00 UTC, is less than ideal for a bunch of folks, and we should consider changing it [0]. To ensure we're getting everyone involved in the process, I've created a doodle that will run for one week [1]. In this Doodle, I'd like folks to vote on whatever time works best for them. During the next meeting, 25 Thursday 13:00 UTC, the results of the survey will be announced and the day and time with the highest number of votes will be used for all future meetings. Thank you, and please go vote! [0] http://eavesdrop.openstack.org/meetings/tripleo/2019/tripleo.2019-07-18-13.… [1] https://doodle.com/poll/nkkqnkarhbgp8cxr -- Kevin Carter IRC: kecarter

1 1

[openstack-dev] [neutron] [rally] [osprofiler]
by Miguel Lavalle 29 Jul '19

29 Jul '19

Hi, The Neutron team has been playing lately with Rally scenarios and osprofiler. One example is http://logs.openstack.org/80/671780/1/check/neutron-rally-task/6cc66e4/resu…. As can be seen in this example, we get a lot of trace points from SQLAlchemy with the corresponding SQL statement that was sent the DB. Is there a way we can add information to these trace points to help us relate them to the Neutron code that issued the statement? Cheers Miguel

1 0

[forum][sdk][nova] Closing compute API feature gaps in the openstack CLI - recap
by Matt Riedemann 29 Jul '19

29 Jul '19

I wanted to give a quick recap of this Forum session for those that couldn't attend and also find owners. Please reply to this thread if you'd like to sign up for any specific item. The etherpad [1] has the details. To restate the goal: "Identify the major issues and functional gaps (up through Mitaka 2.25) and prioritize which to work on and what the commands should do." We spent the majority of the time talking about existing issues with compute API functionality in openstack CLI, primarily boot-from-volume, live migration and lack of evacuate support (evacuate as in rebuild on a new target host because the source host is dead, not drain a host with live migrations [2]). We then talked through some of the microversion gaps and picked a few to focus on. Based on that, the agreements and priorities are: **High Priority** 1. Make the boot-from-volume experience better by: a) Support type=image for the --block-device-mapping option. b) Add a --boot-from-volume option which will translate to a root --block-device-mapping using the provided --image value (nova will create the root volume under the covers). Owner: TBD (on either) 2. Fix the "openstack server migrate" command We're going to deprecate the --live option and add a new --live-migration option and a --host option. The --host option can be used for requesting a target host for cold migration (omit the --live/--live-migration option for that). Then in a major release we'll drop the --live option and intentionally not add a --force option (since we don't want to support forcing a target host and bypassing the scheduler). Owner: TBD (I would split the 2.56 cold migration --host support from the new --live-migration option review-wise) **Medium Priority** Start modeling migration resources in the openstack CLI, specifically for microversions 2.22-2.24, but note that the GET /os-migrations API is available since 2.1 (so that's probably easiest to add first). The idea is to have a new command resource like: openstack compute migration (list|delete|set) [--server <server_id>] Owner: TBD (again this is a series of changes) **Low Priority** Closing other feature gaps can be done on an as-needed basis as we've been doing today. Sean Mooney is working on adding evacuate support, and there are patches in flight (see [3]) for other microversion-specific features. I would like to figure out how to highlight these to the OSC core team on a more regular basis, but we didn't really talk about that. I've been trying to be a type of liaison for these patches and go over them before the core team tries to review them to make sure they match the API properly and are well documented. Does the OSC core team have any suggestions on how I can better socialize what I think is ready for core team review? [1] https://etherpad.openstack.org/p/DEN-osc-compute-api-gaps [2] http://www.danplanet.com/blog/2016/03/03/evacuate-in-nova-one-command-to-co… [3] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc -- Thanks, Matt

2 2