- openSUSE Cloud

[opensuse-cloud] [openstack] Upgrade single-control-node environment to high availability
by Eugen Block 27 Aug '20

27 Aug '20

Hi all, I published the first part of my blog series about our openstack upgrade [1]. The rest will follow shortly after the other drafts have been reviewed. Comments and questions are welcome. :-) Best regards, Eugen http://heiterbiswolkig.blogs.nde.ag/2020/08/27/openstack-ha-upgrade-part1/ -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

1 0

[opensuse-cloud] What's the decision for openstack build service?
by FuLong Wang 24 Aug '20

24 Aug '20

Hello Everyone, I have found that we are still running the build service for OpenStack project (Train Release) recently. I'm wondering if our community will continue the build service for future OpenStack releases, such as Ussuri and Vitctoria? As i know, still have many users want to run OpenStack on OpenSuSE/SuSE platform. If we have decided to not go any further, then can the end users have the chance to build on their own? I mean, can we still provide the source RPMs for OpenStack and dependency? Appreciate if any clarifications. Cheers! -- FuLong Wang fulwang(a)linux.vnet.ibm.com IBM Systems Lab _______________________________________________ -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

4 6

[opensuse-cloud] What will happen to OpenStack on OpenSUSE next?
by opensuse＠wolke7.net 29 Dec '19

29 Dec '19

Dear Sir or Madam, I'm a SUSE lover, and I'm studying Openstack recently and what to try it on OpenSUSE. But after the sudden news that SUSE dropped SUSE Cloud for strategy, I want to ask, how about Openstack on OpenSUSE, will we drop it also for next release? SUSE staff will continue to contribute to Openstack for OpenSUSE? Thank you -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

1 0

[opensuse-cloud] cloud-init unable to render network config from config drive
by Eugen Block 07 Oct '19

07 Oct '19

Hi all, I hope this list is not dead yet ;-) Once again I'm struggling with cloud-init, it seems like a neverending story to me. It may be related to our outdated Ocata environment. We have two different scenarios we need to cover in our environment, instances are launched either in provider networks (with config drive) or in self-service networks where they receive their metadata from neutron metadata service. With Leap 15 images (cloud-init version 18.2) this still worked fine for us. With a fresh Leap 15.1 (cloud-init 19.1) image it doesn't work anymore, I get this error when I launch an instance with config drive: > Unable to render networking. Network config is likely broken: No > available network renderers found. Searched through list: ['eni', > 'sysconfig', 'netplan'] We did not change anything in our cloud environment and I can't figure out what cloud-init would need in order to process the network settings via config drive. Can anyone shed some light, please? Thanks and best regards, Eugen -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

1 2

[opensuse-cloud] Nova imports flat images from base file despite ceph backend
by Eugen Block 10 Oct '18

10 Oct '18

Hi list, this week I noticed something strange in our cloud (Ocata on Leap 42.3). We use Ceph as backend for nova, glance and cinder, everything really works like a charm. But from time to time we've noticed that some instances take much longer to launch than others. So I wanted to take a look what's happening, turned on debug logs and found that in some cases (I have no idea how to reproduce yet) there is an image downloaded to /var/lib/nova/instances/_base which then is used to import it back to Ceph, that is obviously the reason for the delay. The problem is that this new instance is not CoW, it's a flat rbd image. Here are some relevant logs (instance_id: 65567fc1-017f-45dc-b0ee-570c44146119, image_id: 0da1ba0f-c504-45ea-b138-16026aec022b) ---cut here--- [...] 2018-10-04 11:46:39.189 10293 DEBUG nova.compute.manager [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] [instance: 65567fc1-017f-45dc-b0ee-570c44146119] Start spawning the instance on the hypervisor. _build_and_run_instance /usr/lib/python2.7/site-packages/nova/compute/manager.py:1929 [...] 2018-10-04 11:46:39.192 10293 INFO nova.virt.libvirt.driver [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] [instance: 65567fc1-017f-45dc-b0ee-570c44146119] Creating image 2018-10-04 11:46:39.220 10293 DEBUG nova.virt.libvirt.storage.rbd_utils [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] rbd image 65567fc1-017f-45dc-b0ee-570c44146119_disk does not exist __init__ /usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:77 2018-10-04 11:46:39.241 10293 DEBUG nova.virt.libvirt.storage.rbd_utils [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] rbd image 65567fc1-017f-45dc-b0ee-570c44146119_disk does not exist __init__ /usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:77 2018-10-04 11:46:39.245 10293 DEBUG oslo_concurrency.lockutils [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] Lock "3c60237fbf59101d3411c4f795d0a72b82752e0b" acquired by "nova.virt.libvirt.imagebackend.fetch_func_sync" :: waited 0.001s inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:270 2018-10-04 11:46:39.246 10293 DEBUG oslo_concurrency.lockutils [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] Lock "3c60237fbf59101d3411c4f795d0a72b82752e0b" released by "nova.virt.libvirt.imagebackend.fetch_func_sync" :: held 0.001s inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:282 2018-10-04 11:46:39.266 10293 DEBUG nova.virt.libvirt.storage.rbd_utils [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] rbd image 65567fc1-017f-45dc-b0ee-570c44146119_disk does not exist __init__ /usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:77 2018-10-04 11:46:39.269 10293 DEBUG oslo_concurrency.processutils [req-85d728c3-5da1-4b37-add7-b956b4b2bb3d df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] Running cmd (subprocess): rbd import --pool images /var/lib/nova/instances/_base/3c60237fbf59101d3411c4f795d0a72b82752e0b 65567fc1-017f-45dc-b0ee-570c44146119_disk --image-format=2 --id openstack --conf /etc/ceph/ceph.conf execute /usr/lib/python2.7/site-packages/oslo_concurrency/processutils.py:355 [...] # no parent data control:~ # rbd info images/65567fc1-017f-45dc-b0ee-570c44146119_disk rbd image '65567fc1-017f-45dc-b0ee-570c44146119_disk': size 6144 MB in 1536 objects order 22 (4096 kB objects) block_name_prefix: rbd_data.c8f88a6b8b4567 format: 2 features: layering, exclusive-lock, object-map flags: create_timestamp: Thu Oct 4 11:46:39 2018 ---cut here--- ################################################################### For comparison I moved the respective base file and tried to spawn a new instance from the same glance image: ---cut here--- [...] 2018-10-04 10:30:29.412 2336 DEBUG nova.compute.manager [req-942ba103-1932-4adf-b9b2-670e1a2fc126 df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] [instance: 91d0b930-97b0-4dd0-81b4-929599b7c997] Start spawning the instance on the hypervisor. _build_and_run_instance /usr/lib/python2.7/site-packages/nova/compute/manager.py:1929 [...] 2018-10-04 10:30:29.415 2336 INFO nova.virt.libvirt.driver [req-942ba103-1932-4adf-b9b2-670e1a2fc126 df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] [instance: 91d0b930-97b0-4dd0-81b4-929599b7c997] Creating image 2018-10-04 10:30:29.435 2336 DEBUG nova.virt.libvirt.storage.rbd_utils [req-942ba103-1932-4adf-b9b2-670e1a2fc126 df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] rbd image 91d0b930-97b0-4dd0-81b4-929599b7c997_disk does not exist __init__ /usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:77 2018-10-04 10:30:29.455 2336 DEBUG nova.virt.libvirt.storage.rbd_utils [req-942ba103-1932-4adf-b9b2-670e1a2fc126 df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] rbd image 91d0b930-97b0-4dd0-81b4-929599b7c997_disk does not exist __init__ /usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:77 2018-10-04 10:30:29.492 2336 DEBUG oslo_concurrency.lockutils [req-942ba103-1932-4adf-b9b2-670e1a2fc126 df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] Lock "3c60237fbf59101d3411c4f795d0a72b82752e0b" acquired by "nova.virt.libvirt.imagebackend.fetch_func_sync" :: waited 0.035s inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:270 2018-10-04 10:30:29.527 2336 DEBUG nova.virt.libvirt.imagebackend [req-942ba103-1932-4adf-b9b2-670e1a2fc126 df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] Image locations are: [{u'url': u'rbd://655cb05a-435a-41ba-83d9-8549f7c36167/images/0da1ba0f-c504-45ea-b138-16026aec022b/snap', u'metadata': {}}, {'url': u'rbd://655cb05a-435a-41ba-83d9-8549f7c36167/images/0da1ba0f-c504-45ea-b138-16026aec022b/snap', 'metadata': {}}] clone /usr/lib/python2.7/site-packages/nova/virt/libvirt/imagebackend.py:903 2018-10-04 10:30:29.681 2336 DEBUG nova.virt.libvirt.imagebackend [req-942ba103-1932-4adf-b9b2-670e1a2fc126 df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] Selected location: {u'url': u'rbd://655cb05a-435a-41ba-83d9-8549f7c36167/images/0da1ba0f-c504-45ea-b138-16026aec022b/snap', u'metadata': {}} clone /usr/lib/python2.7/site-packages/nova/virt/libvirt/imagebackend.py:912 2018-10-04 10:30:29.682 2336 DEBUG nova.virt.libvirt.storage.rbd_utils [req-942ba103-1932-4adf-b9b2-670e1a2fc126 df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] cloning images/0da1ba0f-c504-45ea-b138-16026aec022b@snap to None/91d0b930-97b0-4dd0-81b4-929599b7c997_disk clone /usr/lib/python2.7/site-packages/nova/virt/libvirt/storage/rbd_utils.py:236 [...] # instance has parent data control:~ # rbd info images/91d0b930-97b0-4dd0-81b4-929599b7c997_disk rbd image '91d0b930-97b0-4dd0-81b4-929599b7c997_disk': size 8192 MB in 1024 objects order 23 (8192 kB objects) block_name_prefix: rbd_data.c8abcb6b8b4567 format: 2 features: layering, exclusive-lock, object-map flags: create_timestamp: Thu Oct 4 10:30:29 2018 parent: images/0da1ba0f-c504-45ea-b138-16026aec022b@snap overlap: 6144 MB ---cut here--- Why is there a local copy of the image in the first place? Obviously nova doesn't need that and creates clones successfully without them. The directory /var/lib/nova/instances/_base only contains 6 images. I would be thankful for any explanation for this behaviour. Regards, Eugen

3 5

[opensuse-cloud] Devstack support for Leap 15.0
by Antonio Ojea 09 Oct '18

09 Oct '18

Hi all, Just good news for the openSUSE cloud community, Devstack supports openSUSE Leap 15.0 since this patch [1] got merged today. Cheers, A.Ojea [1] https://review.openstack.org/#/c/576798/ -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

1 0

[opensuse-cloud] Networking provided via meta-data does not work
by Ben Howard 02 Oct '18

02 Oct '18

Hello from DigtialOcean! I am the engineer at DigitalOcean that is responsible for making distributions work on our cloud. I have been attempting to work with community members to try and get OpenSUSE on DigitalOcean, but those efforts have failed. The root of the problem is that DigitalOcean (like a few others clouds) does not have DHCP. To get around this we have implemented both ConfigDrive and our DataSource that handles how to configure a network in Cloud-init. On other distributions, this method works just fine. However the OpenSUSE Cloud-init distribution module does NOT handle configuring networking when the network configuration comes from either the ConfigDrive or DigitalOcean Cloud-init datasources. To whit: CONSOLE: 2017-11-01 14:47:22,468 - __init__.py[WARNING]: apply_network_config is not currently implemented for distribution '<class 'cloudinit.distros.opensuse.Distro'>'. Attempting to use apply_network /var/log/cloud-init.log Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/cloudinit/distros/__init__.py", line 346, in _bring_up_interface (_out, err) = util.subp(cmd) File "/usr/lib/python2.7/site-packages/cloudinit/util.py", line 1849, in subp cmd=args) ProcessExecutionError: Unexpected error while running command. Command: ['ifup', 'eth0'] Exit code: 162 Reason: - Stdout: eth0 setup-in-progress Stderr: - (That was taken from a OpenSUSE LEAP 42.3 image booted on DigitalOcean). Anyhow, this is blocking bringing OpenSUSE to DigitalOcean. If someone would like to work with me to produce upstream images that work -- and can configure networking, I would love the help. I can give free instances (just ping me off list with your DigitalOcean account). Thanks, Ben -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

3 7

[opensuse-cloud] Queens packages for openSUSE and SLES available
by Thomas Bechtold 06 Mar '18

06 Mar '18

Hi, Queens packages for openSUSE and SLES are now available at: http://download.opensuse.org/repositories/Cloud:/OpenStack:/Queens/ We maintain + test the packages for SLES 12SP3 and openSUSE Leap 42.3. If you find issues, please do not hesitate to report them to opensuse-cloud at opensuse.org or to https://bugzilla.opensuse.org/ Thanks and have a lot of fun, Tom -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

1 0

Fwd: [opensuse-cloud] Since upgrade to Ocata cinder-volume causes high CPU load
by Dirk Müller 27 Oct '17

27 Oct '17

Hi Eugen, 2017-10-18 9:38 GMT+02:00 Eugen Block <eblock(a)nde.ag>: > I compared the Ocata cinder code to Newton and Mitaka, an that function > causing all this traffic to the cluster is indeed new since Ocata. So at > least it's explainable, but how can I configure it properly? Any ideas? If I understand your issue correctly, this is the fix you're looking for: https://review.openstack.org/#/c/508455/ it is already in pike or newer. Is there a particular reason you're staying with Ocata? We could backport it I think, as it is not changing any API, just wondering whether it is worth the effort (if someone wants it, it is..) Greetings, Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-cloud+owner(a)opensuse.org

2 2

[opensuse-cloud] Re: [Openstack-operators] Pike packages for openSUSE and SLES available
by Thomas Bechtold 18 Oct '17

18 Oct '17

Hi Andy, On 15.09.2017 04:25, Andy Wojnarek wrote: > I’m trying to submit a bug, but on https://bugzilla.opensuse.org/, but there does not seem to be a component for OpenStack under any of the products. Indeed. I requested a new component and it should be available in the next 24 hours. > I’m testing a fresh install of Pike on 42.3, and I’m getting neutron database errors: > > 2017-09-14 22:17:47.431 24052 ERROR oslo_messaging.rpc.server DBError: (pymysql.err.InternalError) (1054, u"Unknown column 'subnets.project_id' in 'field list'") [SQL: u'SELECT subnets.project_id AS subnets_project_id, subnets.id AS subnets_id, subnets.name AS subnets_name, subnets.network_id AS subnets_network_id, subnets.segment_id AS subnets_segment_id, subnets.subnetpool_id AS subnets_subnetpool_id, subnets.ip_version AS subnets_ip_version, subnets.cidr AS subnets_cidr, subnets.gateway_ip AS subnets_gateway_ip, subnets.enable_dhcp AS subnets_enable_dhcp, subnets.ipv6_ra_mode AS subnets_ipv6_ra_mode, subnets.ipv6_address_mode AS subnets_ipv6_address_mode, subnets.standard_attr_id AS subnets_standard_attr_id, standardattributes_1.id AS standardattributes_1_id, standardattributes_1.resource_type AS standardattributes_1_resource_type, standardattributes_1.description AS standardattributes_1_description, standardattributes_1.revision_number AS standardattributes_1_revision_number, standardattributes_1.created_at AS standardattributes_1_created_at, standardattributes_1.updated_at AS standardattributes_1_updated_at, subnetpools_1.project_id AS subnetpools_1_project_id, subnetpools_1.id AS subnetpools_1_id, subnetpools_1.name AS subnetpools_1_name, subnetpools_1.ip_version AS subnetpools_1_ip_version, subnetpools_1.default_prefixlen AS subnetpools_1_default_prefixlen, subnetpools_1.min_prefixlen AS subnetpools_1_min_prefixlen, subnetpools_1.max_prefixlen AS subnetpools_1_max_prefixlen, subnetpools_1.shared AS subnetpools_1_shared, subnetpools_1.is_default AS subnetpools_1_is_default, subnetpools_1.default_quota AS subnetpools_1_default_quota, subnetpools_1.hash AS subnetpools_1_hash, subnetpools_1.address_scope_id AS subnetpools_1_address_scope_id, subnetpools_1.standard_attr_id AS subnetpools_1_standard_attr_id, standardattributes_2.id AS standardattributes_2_id, standardattributes_2.resource_type AS standardattributes_2_resource_type, standardattributes_2.description AS standardattributes_2_description, standardattributes_2.revision_number AS standardattributes_2_revision_number, standardattributes_2.created_at AS standardattributes_2_created_at, standardattributes_2.updated_at AS standardattributes_2_updated_at \nFROM subnets LEFT OUTER JOIN subnetpools AS subnetpools_1 ON subnets.subnetpool_id = subnetpools_1.id LEFT OUTER JOIN standardattributes AS standardattributes_1 ON standardattributes_1.id = subnetpools_1.standard_attr_id LEFT OUTER JOIN standardattributes AS standardattributes_2 ON standardattributes_2.id = subnets.standard_attr_id'] > > I confirmed there is no column ‘project_id’ in the subnets table inside the neutron database. Did you sync the neutron database[1]? We do the sync also during a neutron-server restart[2] via systemd but ignore failures here. Maybe you started neutron-server before you configured the database string in neutron.conf ? [1] https://docs.openstack.org/mitaka/networking-guide/migration-database.html [2] https://build.opensuse.org/package/view_file/Cloud:OpenStack:Pike/openstack… Best, Tom N��r��y隊Z)z{.��%��~�{.n�+��Ǩ��r��i�m��0��ޙ��rZ.w�0��Ǩ�

3 4