May 2022 - openstack-discuss - lists.openstack.org

[Tripleo] Support of PTP in Openstack Train
by Anirudh Gupta 06 May '22

06 May '22

Hi Team, I have installed Undercloud with Openstack Train Release successfully. I need to enable PTP service while deploying the overcloud for which I have included the service in my deployment openstack overcloud deploy --templates \ -n /home/stack/templates/network_data.yaml \ -r /home/stack/templates/roles_data.yaml \ -e /home/stack/templates/environment.yaml \ -e /home/stack/templates/environments/network-isolation.yaml \ -e /home/stack/templates/environments/network-environment.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml \ * -e /usr/share/openstack-tripleo-heat-templates/environments/services/ptp.yaml \* -e /home/stack/templates/ironic-config.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \ -e /home/stack/containers-prepare-parameter.yaml But it gives the following error 2022-05-06 11:30:10.707655 | 5254001f-9952-7fed-4a6d-000000002fde | FATAL | Wait for puppet host configuration to finish | overcloud-controller-0 | error={"ansible_job_id": "5188783868.37685", "attempts": 3, "changed": true, "cmd": "set -o pipefail; puppet apply --modulepath=/etc/puppet/modules:/opt/stack/puppet-modules:/usr/share/openstack-puppet/modules --detailed-exitcodes --summarize --color=false /var/lib/tripleo-config/puppet_step_config.pp 2>&1 | logger -s -t puppet-user", "delta": "0:00:04.440700", "end": "2022-05-06 11:30:12.685508", "failed_when_result": true, "finished": 1, "msg": "non-zero return code", "rc": 1, "start": "2022-05-06 11:30:08.244808", "stderr": "<13>May 6 11:30:08 puppet-user: Warning: The function 'hiera' is deprecated in favor of using 'lookup'. See https://puppet.com/docs/puppet/6.14/deprecated_language.html\n<13>May 6 11:30:08 puppet-user: (file & line not available)\n<13>May 6 11:30:08 puppet-user: Warning: /etc/puppet/hiera.yaml: Use of 'hiera.yaml' version 3 is deprecated. It should be converted to version 5\n<13>May 6 11:30:08 puppet-user: (file: /etc/puppet/hiera.yaml)\n<13>May 6 11:30:08 puppet-user: Warning: Undefined variable '::deploy_config_name'; \n<13>May 6 11:30:08 puppet-user: (file & line not available)\n<13>May 6 11:30:08 puppet-user: Warning: Unknown variable: '::deployment_type'. (file: /etc/puppet/modules/tripleo/manifests/profile/base/database/mysql/client.pp, line: 89, column: 8)\n<13>May 6 11:30:08 puppet-user: error: Could not connect to controller: Connection refused\n<13>May 6 11:30:08 puppet-user: Error: Evaluation Error: Error while evaluating a Function Call, Could not find class ::tripleo::profile::base::time::ptp for overcloud-controller-0.localdomain (file: /var/lib/tripleo-config/puppet_step_config.pp, line: 41, column: 1) on node overcloud-controller-0.localdomain", "stderr_lines": ["<13>May 6 11:30:08 puppet-user: Warning: The function 'hiera' is deprecated in favor of using 'lookup'. See https://puppet.com/docs/puppet/6.14/deprecated_language.html", "<13>May 6 11:30:08 puppet-user: (file & line not available)", "<13>May 6 11:30:08 puppet-user: Warning: /etc/puppet/hiera.yaml: Use of 'hiera.yaml' version 3 is deprecated. It should be converted to version 5", "<13>May 6 11:30:08 puppet-user: (file: /etc/puppet/hiera.yaml)", "<13>May 6 11:30:08 puppet-user: Warning: Undefined variable '::deploy_config_name'; ", "<13>May 6 11:30:08 puppet-user: (file & line not available)", "<13>May 6 11:30:08 puppet-user: Warning: Unknown variable: '::deployment_type'. (file: /etc/puppet/modules/tripleo/manifests/profile/base/database/mysql/client.pp, line: 89, column: 8)", "<13>May 6 11:30:08 puppet-user: error: Could not connect to controller: Connection refused", "<13>May 6 11:30:08 puppet-user: *Error: Evaluation Error: Error while evaluating a Function Call, Could not find class ::tripleo::profile::base::time::ptp for overcloud-controller-0.localdomain (file: /var/lib/tripleo-config/puppet_step_config.pp, line: 41, column: 1) on node* overcloud-controller-0.localdomain"], "stdout": "", "stdout_lines": []} Can someone please help in resolving this issue? Regards Anirudh Gupta

1 0

[TripleO] gate blocker please hold rechecks tripleo-heat-templates (openstack-tox-tht)
by Marios Andreou 06 May '22

06 May '22

Hello we have a gate blocker for tripleo-heat-templates affecting master and stable/wallaby at https://bugs.launchpad.net/tripleo/+bug/1971703 If you have failing openstack-tox-tht please hold recheck until we find some resolution thank you! marios

2 1

[charms] OpenStack Charms Yoga release is now available
by Peter Matulis 06 May '22

06 May '22

Version naming for OpenStack Charms releases has changed from being time-based (YY.MM) to one that is based on the newly-supported OpenStack release. Individual charms will also no longer be developed to work with every supported OpenStack release. Instead, each charm will leverage Charmhub tracks, each of which will determine a supported scenario. See the following resource for details: https://docs.openstack.org/charm-guide/latest/project/charm-delivery.html --- The Yoga release of the OpenStack Charms is now available. This release brings several new features to the existing OpenStack Charms deployments for Queens, Stein, Ussuri, Victoria, Wallaby, Xena, Yoga and many stable combinations of Ubuntu + OpenStack. Please see the release notes for full details: https://docs.openstack.org/charm-guide/latest/release-notes/yoga.html == Highlights == * OpenStack Yoga OpenStack Yoga is now supported on Ubuntu 20.04 LTS (via UCA) and Ubuntu 22.04 LTS natively. * vTPM support Virtual Trusted Platform Module (vTPM) devices are now supported on Compute nodes. TPM can be used to enhance computer security and privacy. * Glance storage backend: Cinder iSCSI/FC Cinder iSCSI/FC is now supported as a storage backend for Glance. * Cloud operational improvements Improvements have been implemented at the operational level through the addition of actions and configuration options to the current set of stable charms. * Tech-preview charms This release comes with three new charms, all currently in tech-preview: - cinder-nimblestorage Provides a NimbleStorage storage backend for Cinder. - cinder-solidfire Provides a SolidFire storage backend for Cinder. - nova-compute-nvidia-vgpu Provides Nvidia vGPU support for Nova. * Documentation updates Documentation highlights include: - More cloud operations - Improvements to the upgrade pages - Tutorial for deploying OpenStack - Pages for vTPM and vGPU - Charmhub information - Guidelines and resources for software and documentation contributions == OpenStack Charms team == The OpenStack Charms team can be contacted on the #openstack-charms IRC channel on OFTC or in the Juju user forum: https://discourse.charmhub.io/c/juju/ == Thank you == Lots of thanks to the 55 contributors below who squashed 120 bugs, enabled new features, and improved the documentation! Alex Kavanagh Andy Wu Anna Savchenko Aqsa Malik Arif Ali Aurelien Lourot Bartlomiej Poniecki-Klotz Bayani Carbone Billy Olsen Chris MacNaughton Corey Bryant Cornellius Metto David Ames Diko Parvanov Dmitrii Shcherbakov Edin Sarajlic Edward Hope-Morley Erlon R. Felipe Reyes Frode Nordahl Gustavo Sanchez Hemanth Nakkina Hervé Beraud James Lin James Page James Troup James Vaughn Jeff Hillman jiangzhilin Joe Guo Jorge Merlino José Pekkarinen Juan Pablo Liam Young Linda Guo Luciano Lo Giudice Marcin Wilk Martin Kalcok Nicholas Malacarne Nobuto Murata Olivier Dufour-Cuvillier Paul Goins Pedro Castillo Peter Matulis Robert Gildein Rodrigo Barbieri Samuel Walladge Shayan Patel Simon Deziel Tianqi Xiao Yoshi Kadokawa Zeeshan Ali Zhang Hua Dongdong Tao Tiago Pasqualini -- OpenStack Charms Team

1 0

[neutron] Drivers meeting - Friday 6.5.2022 - cancelled
by Lajos Katona 06 May '22

06 May '22

Hi Neutron Drivers! Due to the lack of agenda, let's cancel tomorrow's drivers meeting. See You on the meeting next week. Lajos Katona (lajoskatona)

1 0

Magnum metrics-server not working
by Oliver Weinmann 05 May '22

05 May '22

Hi, Is the metrics-server broken by default in magnum? I tried for several hours to get it running, but running kubectl top nodes fails. Message: failing or missing response from https://10.100.2.4:8443/apis/metrics.k8s.io/v1beta1: Get "https://10.100.2.4:8443/apis/metrics.k8s.io/v1beta1": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) I also googled a lot but only found similar issues for k8s clusters not deployed via magnum. I remembered from my other cluster that I had to enable enable-aggregator-routing=true in kupe-apiserver and --kubelet-insecure-tls for the metrics-server. But this also doesn’t help. Any help would be highly appreciated. Best regards, Oliver

2 3

RE: Data Center Survival in case of Disaster / HW Failure in DC
by CHALANSONNET Stéphane (Acoss) 05 May '22

05 May '22

Hello, First Openstack isnt VMware.Crtiticals applications need to be design with a multiples regions/AZ aware. Best way was two regions , 2 contrôle plane (keystone , Galera cluster on both (not the same) 2 storage system and application spitted on both is the best pratice 😉 You can do also with two AZ but the control plane is share between two AZ (galezra cluster and RabbitMq ) If you are trying to do the same thing as a streched VMware Cluster on a dual-site it's complicated, i you have 3 sites (low latencies <1ms) you can ! 1.In case of any Sudden Hardware failure of one or more controller node OR Compute node OR Storage Node what will be the immediate redundant recovery setup need to be employed ? => You need to splt control plane throught multiples AZ (3 is the best for Galera cluster and RabbitMQ , 2 if you have HA VMware) => Network compute work with keepalived so also need to split them on two AZ/region, you need . Dhcp , Metadata services are also redundancy on multiples network node => compute : HA OpenStack (like VMware HA) seems to work since Wallaby with Masakari . Actually you need to do the job by yourself if you need to failover instances. The storage is also the bggest problem . You need a streched storage that work with Cinder : Ceph can do the job but you also need three site (quorum on monitor need 2 node alives).Netapp solution seems to work well (trident NFS) 2. In case H/W failure our recovery need to as soon as possible. For example less than30 Minutes after the first failure occurs. Galera Cluster and RabbitMq need to be check first With two sites 30mn is really a big challenge, with 3 site it should good ! 3. Is there setup options like a hot standby or similar setups or what we need to employ ? 2 AZ , 2 storage system and application spitted on both is the best pratice 😉 4. To meet all RTO (< 30 Minutes down time ) and RPO(from the exact point of crash all applications and data must be consistent) . Regards, Stéphane Chalansonnet -----Message d'origine----- De : openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Envoyé : jeudi 5 mai 2022 11:56 À : openstack-discuss(a)lists.openstack.org Objet : openstack-discuss Digest, Vol 43, Issue 12 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Data Center Survival in case of Disaster / HW Failure in DC (KK CHN) 2. [nova][placement] Incomplete Consumers return negative value after upgrade (Jan Wasilewski) 3. Re: [all][tc][Release Management] Improvements in project governance (Slawek Kaplonski) ---------------------------------------------------------------------- Message: 1 Date: Thu, 5 May 2022 14:46:11 +0530 From: KK CHN <kkchn.in(a)gmail.com> To: openstack-discuss(a)lists.openstack.org Subject: Data Center Survival in case of Disaster / HW Failure in DC Message-ID: <CAKgGyB_UmDG+TknDaYLGAuyOnxY8ipSF3qC4tS90T0zHzu6fZg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" List, We are having an old cloud setup with OpenStack Ussuri usng Debian OS, (Qemu KVM ). I know its very old and we can't upgrade to to new versions right now. The Deployment is as follows. A. 3 Controller in (cum compute nodes . VMs are running on controllers too..) in HA mode. B. 6 separate Compute nodes C. 3 separate Storage node with Ceph RBD Question is 1. In case of any Sudden Hardware failure of one or more controller node OR Compute node OR Storage Node what will be the immediate redundant recovery setup need to be employed ? 2. In case H/W failure our recovery need to as soon as possible. For example less than30 Minutes after the first failure occurs. 3. Is there setup options like a hot standby or similar setups or what we need to employ ? 4. To meet all RTO (< 30 Minutes down time ) and RPO(from the exact point of crash all applications and data must be consistent) . 5. Please share your thoughts for reliable crash/fault resistance configuration options in DC. We have a remote DR setup right now in a remote location. Also I would like to know if there is a recommended way to make the remote DR site Automatically up and run ? OR How to automate the service from DR site to meet exact RTO and RPO Any thoughts most welcom. Regards, Krish -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220505…> ------------------------------ Message: 2 Date: Thu, 5 May 2022 11:31:16 +0200 From: Jan Wasilewski <finarffin(a)gmail.com> To: openstack-discuss(a)lists.openstack.org Subject: [nova][placement] Incomplete Consumers return negative value after upgrade Message-ID: <CAN4DDNgG=i8tGpPQW2PUXVUp72T9r4CWDdxmfRg-bX8T1eE5AA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, after an upgrade from Stein to Train, I hit an issue with negative value during upgrade check for placement: # placement-status upgrade check+------------------------------------------------------------------+| Upgrade Check Results |+------------------------------------------------------------------+| Check: Missing Root Provider IDs || Result: Success || Details: None |+------------------------------------------------------------------+| Check: Incomplete Consumers || Result: Warning || Details: There are -20136 incomplete consumers table records for || existing allocations. Run the "placement-manage db || online_data_migrations" command. |+------------------------------------------------------------------+ Seems that negative value is a result that I get such values from tables consumer and allocations: mysql> select count(id), consumer_id from allocations group by consumer_id;...1035 rows in set (0.00 sec) mysql> select count(*) from consumers;+----------+| count(*) |+----------+| 21171 |+----------+1 row in set (0.04 sec) Unfortunately such warning cannot be solved by execution of suggested command( placement-manage db online_data_migrations) as it seems it adds records to consumers table - not to allocations, which looks like to be a problem here. I was following recommendations from this discussion: http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018536… but unfortunately it doesn't solve the issue(even not changing a negative value). I'm just wondering if I skipped something important and you can suggest some (obvious?) solution. Thank you in advance for your time and help. Best regards, Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220505…> ------------------------------ Message: 3 Date: Thu, 05 May 2022 11:55:32 +0200 From: Slawek Kaplonski <skaplons(a)redhat.com> To: openstack-discuss(a)lists.openstack.org Cc: El?d Ill?s <elod.illes(a)est.tech> Subject: Re: [all][tc][Release Management] Improvements in project governance Message-ID: <3198538.44csPzL39Z@p1> Content-Type: text/plain; charset="utf-8" Hi, On ?roda, 20 kwietnia 2022 13:19:10 CEST El?d Ill?s wrote: > Hi, > > At the very same time at the PTG we discussed this on the Release > Management session [1] as well. To release deliverables without > significant content is not ideal and this came up in previous > discussions as well. On the other hand unfortunately this is the most > feasible solution from release management team perspective especially > because the team is quite small (new members are welcome! feel free to > join the release management team! :)). > > To change to independent release model is an option for some cases, > but not for every project. (It is less clear for consumers what > version is/should be used for which series; Fixing problems that comes > up in specific stable branches, is not possible; testing the > deliverable against a specific stable branch constraints is not > possiblel; etc.) > > See some other comments inline. > > [1] https://etherpad.opendev.org/p/april2022-ptg-rel-mgt#L44 > > El?d > > On 2022. 04. 19. 18:01, Michael Johnson wrote: > > Comments inline. > > > > Michael > > > > On Tue, Apr 19, 2022 at 6:34 AM Slawek Kaplonski<skaplons(a)redhat.com> wrote: > >> Hi, > >> > >> > >> During the Zed PTG sessions in the TC room we were discussing some ideas how we can improve project governance. > >> > >> One of the topics was related to the projects which don't really have any changes in the cycle. Currently we are forcing to do new release of basically the same code when it comes to the end of the cycle. > >> > >> Can/Should we maybe change that and e.g. instead of forcing new release use last released version of the of the repo for new release too? > > In the past this has created confusion in the community about if a > > project has been dropped/removed from OpenStack. That said, I think > > this is the point of the "independent" release classification. > Yes, exactly as Michael says. > >> If yes, should we then automatically propose change of the release model to the "independent" maybe? > > Personally, I would prefer to send an email to the discuss list > > proposing the switch to independent. Patches can sometimes get > > merged before everyone gets to give input. Especially since the > > patch would be proposed in the "releases" project and may not be on > > the team's dashboards. > The release process catches libraries only (that had no merged > change), so the number is not that huge, sending a mail seems to be a fair option. > > (The process says: "Evaluate any libraries that did not have any > change merged over the cycle to see if it is time to transition them > to the independent release model > <https://releases.openstack.org/reference/release_models.html#openstack-rela…>. > Note: client libraries (and other libraries strongly tied to another > deliverable) should generally follow their parent deliverable release > model, even if they did not have a lot of activity themselves).") > >> What would be the best way how Release Management team can maybe notify TC about such less active projects which don't needs any new release in the cycle? That could be one of the potential conditions to check project's health by the TC team. > > It seems like this would be a straight forward script to write given > > we already have tools to capture the list of changes included in a > > given release. > > There are a couple of good signals already for TC to catch inactive > projects, like the generated patches that are not merged, for example: > > https://review.opendev.org/q/topic:reno-yoga+is:open > https://review.opendev.org/q/topic:create-yoga+is:open > https://review.opendev.org/q/topic:add-xena-python-jobtemplates+is:ope > n > > (Note that in the past not merged patches caused issues and discussing > with the TC resulted a suggestion to force-merge them to avoid future > issues) > > >> Another question is related to the projects which aren't really active and are broken during the final release time. We had such problem in the last cycle, see [1] for details. Should we still force pushing fixes for them to be able to release or maybe should we consider deprecation of such projects and not to release it at all? > > In the past we have simply not released projects that are broken and > > don't have people actively working on fixing them. It has been a > > signal to the community that if they value the project they need to > > contribute to it. > > Yes, that's a fair point, too, maybe those broken deliverables should > not be released at all. I'm not sure, but that might cause another > issues for release management tooling, though... > > Besides, during our PTG session we came to the conclusion that we need > another step in our process: > * "propose DNM changes on every repository by RequirementsFreeze (5 > weeks before final release) to check that tests are still passing with > the current set of dependencies" > Hopefully this will catch broken things well in advance. > > >> [1]http://lists.openstack.org/pipermail/openstack-discuss/2022-Marc > >> h/027864.html > >> > >> > >> -- > >> > >> Slawek Kaplonski > >> > >> Principal Software Engineer > >> > >> Red Hat > Thx for all inputs in that topic so far. Here is my summary and conclusion of what was said in that thread: * we shouldn't try automatically switch such "inactive" projects to the independent model, and we should continue bumping versions of such projects every cycle as it makes many things easier, * Release Management team will test projects about 5 weeks before final release - that may help us find broken projects which then can be discussed and eventually marked as deprecated to not release broken code finally, * To check potentially inactive projects TC can: * finish script https://review.opendev.org/c/openstack/governance/+/810037[1] and use stats generate by that script to periodically check projects' health, * check projects with no merged generated patches, like: https://review.opendev.org/q/topic:reno-yoga+is:open[2] https://review.opendev.org/q/topic:create-yoga+is:open[3] https://review.opendev.org/q/topic:add-xena-python-jobtemplates+is:open[4] Feel free to add/change anything in that summary if I missed or misunderstood anything there or if You have any idea about other improvements we can do in that area. -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/c/openstack/governance/+/810037 [2] https://review.opendev.org/q/topic:reno-yoga+is:open [3] https://review.opendev.org/q/topic:create-yoga+is:open [4] https://review.opendev.org/q/topic:add-xena-python-jobtemplates+is:open -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220505…> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220505…> ------------------------------ Subject: Digest Footer _______________________________________________ openstack-discuss mailing list openstack-discuss(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss ------------------------------ End of openstack-discuss Digest, Vol 43, Issue 12 *************************************************

1 0

[all][tc][Release Management] Improvements in project governance
by Slawek Kaplonski 05 May '22

05 May '22

Hi, During the Zed PTG sessions in the TC room we were discussing some ideas how we can improve project governance. One of the topics was related to the projects which don't really have any changes in the cycle. Currently we are forcing to do new release of basically the same code when it comes to the end of the cycle. Can/Should we maybe change that and e.g. instead of forcing new release use last released version of the of the repo for new release too? If yes, should we then automatically propose change of the release model to the "independent" maybe? What would be the best way how Release Management team can maybe notify TC about such less active projects which don't needs any new release in the cycle? That could be one of the potential conditions to check project's health by the TC team. Another question is related to the projects which aren't really active and are broken during the final release time. We had such problem in the last cycle, see [1] for details. Should we still force pushing fixes for them to be able to release or maybe should we consider deprecation of such projects and not to release it at all? [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.ht… -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.ht…

4 4

[Kolla-ansible][xena] how to deploy multiple cinder backends?
by wodel youchi 05 May '22

05 May '22

Hi, I want to deploy multiple cinder backends, ceph SSD pool for high performance VMS, ceph SAS pool for normal VMS and NFS share for small VMS and for cinder backup. Could that be done while deploying or it has to be done after the initial deployment? Could you assist me with some examples, sometimes the documentation is not that obvious to understand. Regards.

2 1

[sdk] creating a blank volume with image properties
by John Ratliff 05 May '22

05 May '22

We're standing up a second openstack cluster to do a leapfrog migration upgrade. We are using the same ceph storage backend. I need to create volumes in the new openstack cluster that use the underlying ceph rbd. Currently, we are creating a volume in the new openstack cluster, deleting the rbd created by openstack, and renaming the original rbd to match the new openstack mapping. This process loses the image properties from the original volumes. We are using virtio-scsi for the disk block device, and want to continue doing that in the new cluster. When we create the server using the new volume in the new openstack cluster, it reverts to using virtio-blk (/dev/vda). What can I do to keep using our image properties in the newly created volume? I thought I could just pass volume_image_metadata as an argument to create_volume(), but it doesn't work. I end up with an image that has no image metadata properties. import openstack openstack.enable_logging(debug=False) conn = openstack.connect(cloud="test") v = conn.create_volume( name="testvol", size=5, wait=True, bootable=True, volume_image_metadata={ "hw_scsi_model": "virtio-scsi", "hw_disk_bus": "scsi", "hw_qemu_guest_agent": "yes", "os_require_quiesce": "yes", "hw_rng_model": "virtio", "image_id": "00000000-0000-0000-0000-000000000000", }, ) What can I do to create this openstack volume while preserving my original volume properties? Since we don't care about the image, I thought about creating a blank image that the volume could be based on with those properties, but I'm looking for suggestions. Thanks. --John

2 1

Re: [all][tc] Technical Committee next weekly meeting on May 5, 2022 at 1500 UTC
by Ghanshyam Mann 05 May '22

05 May '22

Hello Everyone, Below is the agenda for Tomorrow's TC IRC meeting schedule at 1500 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting == Agenda for tomorrow's TC meeting == * Roll call * Follow up on past action items * CFN overview from Jie Niu, China Mobile Research Institute (30 min) ** http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028345.ht… * 'tick', 'tock' release cadence (~30 min) ** Legal checks on using 'tick', 'tock' *** https://review.opendev.org/c/openstack/governance/+/840354 ** release notes discussion <rest of the agenda if time permits otherwise we will cover that in the next weekly meeting(12th May onwards)> * Join leadership meeting with Board of Directors * Gate health check ** Fixing Zuul config error in OpenStack *** https://etherpad.opendev.org/p/zuul-config-error-openstack * New ELK service dashboard: e-r service ** https://opensearch.logs.openstack.org/_dashboards/app/discover?security_ten… ** https://review.opendev.org/c/openstack/governance-sigs/+/835838 * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann

1 0