[glance][interop] standardized image "name" ?
Hi everyone,
Something that I've been dealing with is the fact that regardless of what cloud you're using, the naming structure is very much different. While we aim to be interoperable, if I want to "boot an Debian Stretch server", the image name will probably be different all over the places.
Is there some sort of way we can eliminate this by implementing a standard naming convention which would allow us to use the same images across all systems?
I'm just opening the idea for discussion, I'd love to hear what others think about this.
Mohammed
We're using the name convention like this:
ubuntu-18.04-x86_64
ubuntu-minimal-16.04-x86_64
debian-9-x86_64
<OS>-<Version>-<Arch>
On 8/04/19 9:35 AM, Mohammed Naser wrote:
Hi everyone,
Something that I've been dealing with is the fact that regardless of what cloud you're using, the naming structure is very much different. While we aim to be interoperable, if I want to "boot an Debian Stretch server", the image name will probably be different all over the places.
Is there some sort of way we can eliminate this by implementing a standard naming convention which would allow us to use the same images across all systems?
I'm just opening the idea for discussion, I'd love to hear what others think about this.
Mohammed
I don’t think I have a perfect answer here, but just to add fodder to the discussion: it’s often been suggested in the past that one way of dealing with this is to simply ensure that you can bring your image to any cloud you work with. Thus, rather than relying on an image to be named the same across the clouds you deal with, you can simply provide it yourself on those clouds so you know it’s identical. Many of the caveats to this approach should be fairly obvious (footprint, duplication, quotas, format conversion, etc), but for some workflows it provides the sorts of useful guarantees an end user may want.
At Your Service,
Mark T. Voelker
On Apr 7, 2019, at 5:35 PM, Mohammed Naser mnaser@vexxhost.com wrote:
Hi everyone,
Something that I've been dealing with is the fact that regardless of what cloud you're using, the naming structure is very much different. While we aim to be interoperable, if I want to "boot an Debian Stretch server", the image name will probably be different all over the places.
Is there some sort of way we can eliminate this by implementing a standard naming convention which would allow us to use the same images across all systems?
I'm just opening the idea for discussion, I'd love to hear what others think about this.
Mohammed
-- Mohammed Naser — vexxhost
D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvexxhost.co...
You could use the standard image properties (https://docs.openstack.org/glance/stein/admin/useful-image-properties.html) to find the image using a query
e.g. os_distro=centos, os_version=7 and sort by upload date
Tim
-----Original Message----- From: Mark Voelker mvoelker@vmware.com Date: Monday, 8 April 2019 at 05:45 To: Mohammed Naser mnaser@vexxhost.com Cc: OpenStack Discuss openstack-discuss@lists.openstack.org Subject: Re: [glance][interop] standardized image "name" ?
I don’t think I have a perfect answer here, but just to add fodder to the discussion: it’s often been suggested in the past that one way of dealing with this is to simply ensure that you can bring your image to any cloud you work with. Thus, rather than relying on an image to be named the same across the clouds you deal with, you can simply provide it yourself on those clouds so you know it’s identical. Many of the caveats to this approach should be fairly obvious (footprint, duplication, quotas, format conversion, etc), but for some workflows it provides the sorts of useful guarantees an end user may want.
At Your Service,
Mark T. Voelker
> On Apr 7, 2019, at 5:35 PM, Mohammed Naser mnaser@vexxhost.com wrote: > > Hi everyone, > > Something that I've been dealing with is the fact that regardless of > what cloud you're using, the naming structure is very much different. > While we aim to be interoperable, if I want to "boot an Debian Stretch > server", the image name will probably be different all over the > places. > > Is there some sort of way we can eliminate this by implementing a > standard naming convention which would allow us to use the same images > across all systems? > > I'm just opening the idea for discussion, I'd love to hear what others > think about this. > > Mohammed > > -- > Mohammed Naser — vexxhost > ----------------------------------------------------- > D. 514-316-8872 > D. 800-910-1726 ext. 200 > E. mnaser@vexxhost.com > W. https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvexxhost.co... >
On 08/04/2019 07:14, Tim Bell wrote:
You could use the standard image properties (https://docs.openstack.org/glance/stein/admin/useful-image-properties.html) to find the image using a query
e.g. os_distro=centos, os_version=7 and sort by upload date
Tim
I like the idea of it being discoverable, not defined by using the name - it fits better in my head with the way we are doing interop and allows current clouds to not have to change name formats (which could break other users).
-----Original Message----- From: Mark Voelker mvoelker@vmware.com Date: Monday, 8 April 2019 at 05:45 To: Mohammed Naser mnaser@vexxhost.com Cc: OpenStack Discuss openstack-discuss@lists.openstack.org Subject: Re: [glance][interop] standardized image "name" ?
I don’t think I have a perfect answer here, but just to add fodder to the discussion: it’s often been suggested in the past that one way of dealing with this is to simply ensure that you can bring your image to any cloud you work with. Thus, rather than relying on an image to be named the same across the clouds you deal with, you can simply provide it yourself on those clouds so you know it’s identical. Many of the caveats to this approach should be fairly obvious (footprint, duplication, quotas, format conversion, etc), but for some workflows it provides the sorts of useful guarantees an end user may want. At Your Service, Mark T. Voelker > On Apr 7, 2019, at 5:35 PM, Mohammed Naser <mnaser@vexxhost.com> wrote: > > Hi everyone, > > Something that I've been dealing with is the fact that regardless of > what cloud you're using, the naming structure is very much different. > While we aim to be interoperable, if I want to "boot an Debian Stretch > server", the image name will probably be different all over the > places. > > Is there some sort of way we can eliminate this by implementing a > standard naming convention which would allow us to use the same images > across all systems? > > I'm just opening the idea for discussion, I'd love to hear what others > think about this. > > Mohammed > > -- > Mohammed Naser — vexxhost > ----------------------------------------------------- > D. 514-316-8872 > D. 800-910-1726 ext. 200 > E. mnaser@vexxhost.com > W. https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvexxhost.com&data=02%7C01%7Cmvoelker%40vmware.com%7C35dc7472fc9b465af68908d6bba19d77%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636902700146796905&sdata=ek0QPuY4h0Bvso6dk3c%2BPWovZ4suu89a9Rv0Z1VliIY%3D&reserved=0 >
On 4/8/19 10:10 AM, Graham Hayes wrote:
On 08/04/2019 07:14, Tim Bell wrote:
You could use the standard image properties (https://docs.openstack.org/glance/stein/admin/useful-image-properties.html) to find the image using a query
e.g. os_distro=centos, os_version=7 and sort by upload date
Tim
I like the idea of it being discoverable, not defined by using the name
- it fits better in my head with the way we are doing interop and allows
current clouds to not have to change name formats (which could break other users).
I would love it if we could provide guidance - or maybe even somehow get this in to RefStack or something - that clouds *should* provide that metadata.
At the same time, needing to search for an image (and a flavor) on the cloud makes this:
openstack server boot --image=<image> --flavor=<flavor> foo
a bit harder. Perhaps we could add some parameters ... like:
openstack server boot --image-os=debian --image-version=7
And it would use the latest image matching those or fail if the properties arent' defined on that cloud.
-----Original Message----- From: Mark Voelker mvoelker@vmware.com Date: Monday, 8 April 2019 at 05:45 To: Mohammed Naser mnaser@vexxhost.com Cc: OpenStack Discuss openstack-discuss@lists.openstack.org Subject: Re: [glance][interop] standardized image "name" ?
I don’t think I have a perfect answer here, but just to add fodder to the discussion: it’s often been suggested in the past that one way of dealing with this is to simply ensure that you can bring your image to any cloud you work with. Thus, rather than relying on an image to be named the same across the clouds you deal with, you can simply provide it yourself on those clouds so you know it’s identical. Many of the caveats to this approach should be fairly obvious (footprint, duplication, quotas, format conversion, etc), but for some workflows it provides the sorts of useful guarantees an end user may want. At Your Service, Mark T. Voelker > On Apr 7, 2019, at 5:35 PM, Mohammed Naser <mnaser@vexxhost.com> wrote: > > Hi everyone, > > Something that I've been dealing with is the fact that regardless of > what cloud you're using, the naming structure is very much different. > While we aim to be interoperable, if I want to "boot an Debian Stretch > server", the image name will probably be different all over the > places. > > Is there some sort of way we can eliminate this by implementing a > standard naming convention which would allow us to use the same images > across all systems? > > I'm just opening the idea for discussion, I'd love to hear what others > think about this. > > Mohammed > > -- > Mohammed Naser — vexxhost > ----------------------------------------------------- > D. 514-316-8872 > D. 800-910-1726 ext. 200 > E. mnaser@vexxhost.com > W. https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvexxhost.com&data=02%7C01%7Cmvoelker%40vmware.com%7C35dc7472fc9b465af68908d6bba19d77%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636902700146796905&sdata=ek0QPuY4h0Bvso6dk3c%2BPWovZ4suu89a9Rv0Z1VliIY%3D&reserved=0 >
On 4/8/19 12:41 PM, Monty Taylor wrote:
On 4/8/19 10:10 AM, Graham Hayes wrote:
On 08/04/2019 07:14, Tim Bell wrote:
You could use the standard image properties (https://docs.openstack.org/glance/stein/admin/useful-image-properties.html) to find the image using a query
e.g. os_distro=centos, os_version=7 and sort by upload date
Tim
I like the idea of it being discoverable, not defined by using the name
- it fits better in my head with the way we are doing interop and allows
current clouds to not have to change name formats (which could break other users).
I would love it if we could provide guidance - or maybe even somehow get this in to RefStack or something - that clouds *should* provide that metadata.
At the same time, needing to search for an image (and a flavor) on the cloud makes this:
openstack server boot --image=<image> --flavor=<flavor> foo
a bit harder. Perhaps we could add some parameters ... like:
openstack server boot --image-os=debian --image-version=7
Whohooo! You're still using such an old thing as Wheezy? :)
Cheers,
Thomas Goirand (zigo)
On 2019-04-08 03:39:51 +0000 (+0000), Mark Voelker wrote:
I don’t think I have a perfect answer here, but just to add fodder to the discussion: it’s often been suggested in the past that one way of dealing with this is to simply ensure that you can bring your image to any cloud you work with. Thus, rather than relying on an image to be named the same across the clouds you deal with, you can simply provide it yourself on those clouds so you know it’s identical. Many of the caveats to this approach should be fairly obvious (footprint, duplication, quotas, format conversion, etc), but for some workflows it provides the sorts of useful guarantees an end user may want.
[...]
The other problem this works around is that, even if providers offer similar images under the same names or via the same image property metadata, there's no guarantee that what's on the images is identical (same versions of the same set of packages preinstalled with the same initial configurations, same root filesystem formatting and parameters, et cetera). I too just upload identical images to different providers, even for my personal use, so that I have some increased assurance of parity for the instances I boot there.
On 4/8/19 2:32 PM, Jeremy Stanley wrote:
On 2019-04-08 03:39:51 +0000 (+0000), Mark Voelker wrote:
I don’t think I have a perfect answer here, but just to add fodder to the discussion: it’s often been suggested in the past that one way of dealing with this is to simply ensure that you can bring your image to any cloud you work with. Thus, rather than relying on an image to be named the same across the clouds you deal with, you can simply provide it yourself on those clouds so you know it’s identical. Many of the caveats to this approach should be fairly obvious (footprint, duplication, quotas, format conversion, etc), but for some workflows it provides the sorts of useful guarantees an end user may want.
[...]
The other problem this works around is that, even if providers offer similar images under the same names or via the same image property metadata, there's no guarantee that what's on the images is identical (same versions of the same set of packages preinstalled with the same initial configurations, same root filesystem formatting and parameters, et cetera). I too just upload identical images to different providers, even for my personal use, so that I have some increased assurance of parity for the instances I boot there.
The nice thing, is that Glance provides checksums. Meaning that, if you do:
openstack image show -c checksum -f value \ debian-9.8.2-20190303-openstack-amd64.qcow2
then you can make sure that's the same MD5 than at:
http://cdimage.debian.org/cdimage/openstack/archive/9.8.2-20190303/MD5SUMS
In such case, you know your cloud provider hasn't modified the official Debian image.
It's just a shame that Glance doesn't show MD5 and not sha512 sums by default...
Cheers,
Thomas Goirand (zigo)
On 2019-04-12 00:40:03 +0200 (+0200), Thomas Goirand wrote:
The nice thing, is that Glance provides checksums. Meaning that, if you do:
openstack image show -c checksum -f value \ debian-9.8.2-20190303-openstack-amd64.qcow2
then you can make sure that's the same MD5 than at:
http://cdimage.debian.org/cdimage/openstack/archive/9.8.2-20190303/MD5SUMS
Well, I'm frequently booting from testing/unstable snapshots so even if providers do have them in their catalogs they don't necessarily update them on the same schedules. Thankfully, Glance has become fairly ubiquitous in public OpenStack providers in recent years, so at least I can grab one snapshot and upload it to all the projects/regions I'm using.
In such case, you know your cloud provider hasn't modified the official Debian image.
Well, last I checked, Nova doesn't *actually* verify those checksums, and even if it did the software could still be adjusted by a malicious operator anyway. But you're right, for well-known images it at least means there's probably been no "helpful" modifications made by the provider to "improve" my experience in their environment.
It's just a shame that Glance doesn't show MD5 and not sha512 sums by default...
It's not really that big of a deal. As pointed out, those checksums aren't protecting you from malicious operators (really nothing can, short of maybe executing workloads via homomorphic encryption and storing data with something like Tahoe-LAFS), so they're merely informational. And MD5 is not yet so compromised that I can make a backdoored replacement image which calculates to the same md5sum as an official Debian image unless I've also got control of some of the data being included in that image (and if I had that, I probably wouldn't need to resort to orchestrating checksum collisions to carry out my nefarious plans for World domination anyway).
On 4/12/19 1:28 AM, Jeremy Stanley wrote:
On 2019-04-12 00:40:03 +0200 (+0200), Thomas Goirand wrote:
In such case, you know your cloud provider hasn't modified the official Debian image.
Well, last I checked, Nova doesn't *actually* verify those checksums, and even if it did the software could still be adjusted by a malicious operator anyway.
Oh, what do you mean? I thought it had an option for that...
Cheers,
Thomas Goirand (zigo)
On Fri, Apr 12, 2019 at 09:00:31AM +0200, Thomas Goirand wrote:
On 4/12/19 1:28 AM, Jeremy Stanley wrote:
On 2019-04-12 00:40:03 +0200 (+0200), Thomas Goirand wrote:
In such case, you know your cloud provider hasn't modified the official Debian image.
Well, last I checked, Nova doesn't *actually* verify those checksums, and even if it did the software could still be adjusted by a malicious operator anyway.
Oh, what do you mean? I thought it had an option for that...
Cheers,
Thomas Goirand (zigo)
Hmm, according to the spec, Nova verifies those checksums as of Mitaka [0]. Though Cinder did not get the same enforcement until Rocky [1].
[0] https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/im... [1] https://specs.openstack.org/openstack/cinder-specs/specs/rocky/support-image...
(And specs are always 100% accurate, right?)
On 2019-04-12 09:27:35 -0500 (-0500), Sean McGinnis wrote: [...]
Hmm, according to the spec, Nova verifies those checksums as of Mitaka [0]. Though Cinder did not get the same enforcement until Rocky [1].
[0] https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/im... [1] https://specs.openstack.org/openstack/cinder-specs/specs/rocky/support-image...
(And specs are always 100% accurate, right?)
Neat, I had no idea that had improved in the past few years. At any rate, my main point still stands: if you don't trust the operators of that environment then the checksums are pure theater, since they could disable checksum validation or even just serve you a completely fictional hash from the catalog.
On Fri, 12 Apr 2019, 20:29 Jeremy Stanley, fungi@yuggoth.org wrote:
On 2019-04-12 09:27:35 -0500 (-0500), Sean McGinnis wrote: [...]
Hmm, according to the spec, Nova verifies those checksums as of Mitaka
[0].
Though Cinder did not get the same enforcement until Rocky [1].
[0]
https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/im...
[1]
https://specs.openstack.org/openstack/cinder-specs/specs/rocky/support-image...
(And specs are always 100% accurate, right?)
Neat, I had no idea that had improved in the past few years. At any rate, my main point still stands: if you don't trust the operators of that environment then the checksums are pure theater, since they could disable checksum validation or even just serve you a completely fictional hash from the catalog.
Fictional hash - how true it really is sometimes. Don't trust the checksums. In the cloud I'm using the uploaded image is being automatically converted for a backend storage by a plugin, therefore the checksum us just a trash. And you anyway can't download image back, so you can't do anything with the checksum anyway.
Artem
On 4/12/19 8:06 PM, Jeremy Stanley wrote:
On 2019-04-12 09:27:35 -0500 (-0500), Sean McGinnis wrote: [...]
Hmm, according to the spec, Nova verifies those checksums as of Mitaka [0]. Though Cinder did not get the same enforcement until Rocky [1].
[0] https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/im... [1] https://specs.openstack.org/openstack/cinder-specs/specs/rocky/support-image...
(And specs are always 100% accurate, right?)
Neat, I had no idea that had improved in the past few years. At any rate, my main point still stands: if you don't trust the operators of that environment then the checksums are pure theater, since they could disable checksum validation or even just serve you a completely fictional hash from the catalog.
If you believe your host is capable of such things, you probably should go somewhere else.
Cheers,
Thomas Goirand (zigo)
On 2019-04-14 00:53:47 +0200 (+0200), Thomas Goirand wrote:
On 4/12/19 8:06 PM, Jeremy Stanley wrote:
On 2019-04-12 09:27:35 -0500 (-0500), Sean McGinnis wrote: [...]
Hmm, according to the spec, Nova verifies those checksums as of Mitaka [0]. Though Cinder did not get the same enforcement until Rocky [1].
[0] https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/im... [1] https://specs.openstack.org/openstack/cinder-specs/specs/rocky/support-image...
(And specs are always 100% accurate, right?)
Neat, I had no idea that had improved in the past few years. At any rate, my main point still stands: if you don't trust the operators of that environment then the checksums are pure theater, since they could disable checksum validation or even just serve you a completely fictional hash from the catalog.
If you believe your host is capable of such things, you probably should go somewhere else.
Yes, that was my point in a nutshell. (Well, s/capable/guilty/ as all operators are *capable* of making these alterations, but we mostly expect them to be honest enough not to.) Image checksums reported by the API are no guarantee, regardless of whether they're MD5 or SHA2-512. Either you trust your provider hasn't made alterations or you don't. It's far easier to just fake the checksum in the API than it is to engineer an MD5 hash collision a la second preimage attack, so the fact that the MD5 algorithm is considered cryptographically "weak" these days means very little in this context.
I really need to get caught up on my ML reading.
On 4/11/19 6:40 PM, Thomas Goirand wrote: [snip]
It's just a shame that Glance doesn't show MD5 and not sha512 sums by default...
The Secure Hash Algorithm Support ("multihash") spec [0] for Glance was implemented in Rocky and provides a self-describing secure hash on images (in addition to the 'checksum', which is preserved for backward compatability.) The default is SHA-512. See the Rocky release notes [1] for some implementation details not covered by the spec.
The multihash is displayed in the image-list and image-show API responses since Images API v2.7, and in the glanceclient since 2.12.0.
The glanceclient has been using the secure hash for download verification since 2.13.0, with a fallback to the md5 'checksum' field if the multihash isn't populated. (It also optionally allows fallback to md5 if the algorithm for the secure hash isn't available to the client; this option is off by default.) See the 2.13.0 release notes [2] for details.
[0] https://specs.openstack.org/openstack/glance-specs/specs/rocky/implemented/g... [1] https://docs.openstack.org/releasenotes/glance/rocky.html#new-features [2] https://docs.openstack.org/releasenotes/python-glanceclient/rocky.html#relno...
Cheers,
Thomas Goirand (zigo)
On Thu, Apr 18, 2019 at 1:41 PM Brian Rosmaita rosmaita.fossdev@gmail.com wrote:
I really need to get caught up on my ML reading.
On 4/11/19 6:40 PM, Thomas Goirand wrote: [snip]
It's just a shame that Glance doesn't show MD5 and not sha512 sums by default...
The Secure Hash Algorithm Support ("multihash") spec [0] for Glance was implemented in Rocky and provides a self-describing secure hash on images (in addition to the 'checksum', which is preserved for backward compatability.) The default is SHA-512. See the Rocky release notes [1] for some implementation details not covered by the spec.
The multihash is displayed in the image-list and image-show API responses since Images API v2.7, and in the glanceclient since 2.12.0.
The glanceclient has been using the secure hash for download verification since 2.13.0, with a fallback to the md5 'checksum' field if the multihash isn't populated. (It also optionally allows fallback to md5 if the algorithm for the secure hash isn't available to the client; this option is off by default.) See the 2.13.0 release notes [2] for details.
[0]
https://specs.openstack.org/openstack/glance-specs/specs/rocky/implemented/g... [1] https://docs.openstack.org/releasenotes/glance/rocky.html#new-features [2]
https://docs.openstack.org/releasenotes/python-glanceclient/rocky.html#relno...
Cheers,
Thomas Goirand (zigo)
I'm even much more late on this thread than Brian ever was. But as this clearly did sidetrack a bit from the original, I'm gonna chip in something that could help for the original request:
Original topic/request was the exact first usecase Searchlight team was taking on with metadefs and Searchlight when it spun up within Glance. Image names are what they are, freeform text that doesn't need to be unique and likely will always be something you can get bit of an idea what it might contain but will never be your reliable source of information what that image actually contains. Please people, lets not try to reinvent the wheel with something that's really not sufficient for the purpose and start populating the metadata into the image records instead. That's why there is plenty of metadefs so that information is structured and can be easily parsed/searched by something like searchlight. If you look up for the first Searchlight updates and demo's, finding your specific version of OS from images or specific software stack (F.E. LAMP) preinstalled were there literally from the first release.
Cheers, Erno "jokke_" Kuvaja
On 4/18/19 2:37 PM, Brian Rosmaita wrote:
I really need to get caught up on my ML reading.
On 4/11/19 6:40 PM, Thomas Goirand wrote: [snip]
It's just a shame that Glance doesn't show MD5 and not sha512 sums by default...
The Secure Hash Algorithm Support ("multihash") spec [0] for Glance was implemented in Rocky and provides a self-describing secure hash on images (in addition to the 'checksum', which is preserved for backward compatability.) The default is SHA-512. See the Rocky release notes [1] for some implementation details not covered by the spec.
The multihash is displayed in the image-list and image-show API responses since Images API v2.7, and in the glanceclient since 2.12.0.
That's the thing. "image show --long" continues to display the md5sum instead of the sha512.
Cheers,
Thomas Goirand (zigo)
Hi zigo,
The multihash is displayed in the image-list and image-show API responses since Images API v2.7, and in the glanceclient since 2.12.0.
That's the thing. "image show --long" continues to display the md5sum instead of the sha512.
is there a bug reference for this problem.. ?
Thanks, Dirk
On Fri, May 17, 2019 at 1:49 AM Thomas Goirand zigo@debian.org wrote:
On 4/18/19 2:37 PM, Brian Rosmaita wrote:
The multihash is displayed in the image-list and image-show API responses since Images API v2.7, and in the glanceclient since 2.12.0.
That's the thing. "image show --long" continues to display the md5sum instead of the sha512.
We are gearing up to do a backward-compat-breaking OSC4 release soon, this would be the right time to make this change if someone wants to follow-up on it...
dt
On 4/7/19 5:35 PM, Mohammed Naser wrote:
Hi everyone,
Something that I've been dealing with is the fact that regardless of what cloud you're using, the naming structure is very much different. While we aim to be interoperable, if I want to "boot an Debian Stretch server", the image name will probably be different all over the places.
Is there some sort of way we can eliminate this by implementing a standard naming convention which would allow us to use the same images across all systems?
I'm just opening the idea for discussion, I'd love to hear what others think about this.
Mohammed
Sorry to be late to the discussion. We've had Forum/PTG sessions on this, and while everyone agrees that something needs to be done, it's difficult to standardize on what. The key takeaway has been to use some combination of the common image properties (as Tim suggests). The upside is that these are propagated by the nova image-create action (unless they're ruled out by the nova non_inheritable_image_properties config), and so a user snapshot will have the os_distro and os_version on them, so this info won't be lost by an image rename. (The naming scheme Fei Long describes is a clever way to get this info into the image name, but it has the downside that it will be lost on user snapshots.)
If the current common image properties aren't sufficient, it's easy to extend them because under the hood they're simply custom image properties for which people have agreed on a name and (more or less) what the value should be. For example, a 'description' property was added in the Stein release.
Also, just a reminder that "hidden" images were introduced in Rocky via the 'os_hidden' image property; they allow you to make only your most recent public images show up by default in a users' image-list calls.
cheers, brian
Like this idea! This is definitely one of the pain points for public cloud end users trying to setup multi-cloud implementations.
A combination of the two suggestions, guidelines for naming and properties on the public images would be *good enough* for most of the end users we have as public cloud. What I understand from them is that they are not super interested (again, most of them) in the very detailed differences that might be between images of the same OS and version, and for the rest out there that is important for, this will still be a better experience for them than what we have today.
Tobias
Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg
www.citynetwork.eu | www.citycloud.com
INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED
On 2019-04-11 16:07, Brian Rosmaita wrote:
On 4/7/19 5:35 PM, Mohammed Naser wrote:
Hi everyone,
Something that I've been dealing with is the fact that regardless of what cloud you're using, the naming structure is very much different. While we aim to be interoperable, if I want to "boot an Debian Stretch server", the image name will probably be different all over the places.
Is there some sort of way we can eliminate this by implementing a standard naming convention which would allow us to use the same images across all systems?
I'm just opening the idea for discussion, I'd love to hear what others think about this.
Mohammed
Sorry to be late to the discussion. We've had Forum/PTG sessions on this, and while everyone agrees that something needs to be done, it's difficult to standardize on what. The key takeaway has been to use some combination of the common image properties (as Tim suggests). The upside is that these are propagated by the nova image-create action (unless they're ruled out by the nova non_inheritable_image_properties config), and so a user snapshot will have the os_distro and os_version on them, so this info won't be lost by an image rename. (The naming scheme Fei Long describes is a clever way to get this info into the image name, but it has the downside that it will be lost on user snapshots.)
If the current common image properties aren't sufficient, it's easy to extend them because under the hood they're simply custom image properties for which people have agreed on a name and (more or less) what the value should be. For example, a 'description' property was added in the Stein release.
Also, just a reminder that "hidden" images were introduced in Rocky via the 'os_hidden' image property; they allow you to make only your most recent public images show up by default in a users' image-list calls.
cheers, brian
participants (15)
-
Artem Goncharov
-
Brian Rosmaita
-
Dean Troyer
-
Dirk Müller
-
Erno Kuvaja
-
Feilong Wang
-
Graham Hayes
-
Jeremy Stanley
-
Mark Voelker
-
Mohammed Naser
-
Monty Taylor
-
Sean McGinnis
-
Thomas Goirand
-
Tim Bell
-
Tobias Rydberg