- openSUSE Public Cloud

Leap Micro 6.0 and Leap 16.0 images
by Lubos Kocman 18 Jul '24

18 Jul '24

Hello team I have great news! We've had a meeting with SUSE Public Cloud team regarding ownership of building/publishing Leap Micro 6.X and future Leap releases. Leap Micro 6.X is not bound by any contract, therefore our newly established openSUSE Cloud team can handle image uploads. Leap Micro 6.0 image was not yet uploaded because of a pending bug. But generally this can be the first image uploaded under openSUSE/Geekos credentials. Leap 15.X is bound by a contract (Leap has to be published next to SLES), however the contract will be renewed next year, before Leap 16.0 is Gold (Oct/Nov 2025). We'd like to make an amendment that specifically Leap would be opted out and operated solely by Geekos/openSUSE project (whatever the project name will be). This gives us more opportunities, and perhaps explore deeper monentaization aspects, choose what cloud providers we want to cover etc ... I personally believe that there should be a research "paper" going through options, pros/cons, etc before we go with any particular solution ... Cheers! Lubos -- Best regards Luboš Kocman openSUSE Leap Release Manager

1 0

Re-activating cloud@lists.opensuse.org for the PublicCloud Team
by Neil Hanlon 17 Jun '24

17 Jun '24

Hi Folks, Last week, there was a kickoff meeting[1] for the PublicCloud Team[2], and one of the action items was the creation of a pubic mailing list for communication--which is how we've found this mailing list. We are planning to bring the cloud(a)lists.opensuse.org mailing list back to life, as it has been about four years since the last post, and would like to propose the following: * Turn cloud(a)lists.opensus.org into the Public Cloud Team's mailing list * Keep the old email archives intact for historical purposes * Reset the member list to start fresh with active participants and not overwhelm prior list members with potentially unwanted email Of course, anyone would be welcome to re-join the mailing list, if they wish to stay informed or involved in discussions going forward. If you have any thoughts or concerns about this, please let us know. We also have a Matrix[3] channel, which we welcome you to join. If there is no negative feedback to this posting after two weeks (~July 17th), the above plan will be implemented[4]. Thank you! Very respectfully, Neil Hanlon -- [1] https://etherpad.opensuse.org/p/PublicCloud-20240530 [2] https://en.opensuse.org/openSUSE:PublicCloud_team [3] https://matrix.to/#/#cloud:opensuse.org [4] https://progress.opensuse.org/issues/161282

1 1

[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