It'd be good to use a static (bookmarkable) URL for the provider
details pages. If, for example, I'm an openstack user, I don't want to
have to click through several pages of general purpose information
(including the list of all the providers, etc) every time I want to look
up the latest openstack images. I want to bookmark a page that gives me
the latest openstack images.
For the managed cloud services, most users are going to use the
images already published by Debian to the specific cloud they're
interested in. Most people aren't going to download the raw images as
shown in the openstack example we currently have. So we'll need to think
about how we want to present the provider-specific details in a way
that'll be most familiar to somebody working with that provider's
services on a daily basis. That will likely differ somewhat based on the
"on using a static (bookmarkable) URL for the provider", this was already planned in our backlog. So for the example given the URL=finder.debian.org the path for open stack, it will be finder.debian.org/open-stack.
The idea for this problem is that we will provide one API route that OpenStack will use to update the generated image to finder application. The only thing that is important to us is this data from Open Stack for example when a new image is uploaded returns some ID to be placed in the metadata file?
In your "provider details", I can see the name, zone, version, etc., though
what's really missing is the image ID and the API URL. I guess an
example output of your table would be:
Name Zone Version Code Name Arch Releasedebian-stretch-9.9.0 Eu1 9.9.0 Stretch amd64 ?
What will you put under "Release" that's not covered in "Code Name" and
To me, it's missing these fields (just an example):
Provider name: Infomaniak Network SAProvider Home page: http://www.infomaniak.comAPI URL: https://eu1.cloud.infomaniak.chImage ID: de5a9652-8af5-410d-adf7-055e5a45a85eFormat: qcow2Image type: Base image (more on this below...)
I don't really like the fact that you are against "cloud providers'
logo" because you believe it does promotion. Indeed, we're already
providing images for GCE, Google and AWS, which will have a huge
exposure (because they have their respective sections). I don't think it
is nice to provider non-free providers a better exposure than their
free-software based counterpart.
Also, you have to make sure that providers have automation to update the
Another thing: we may soon provide specialized image, containing some
kind of application. Let me explain. In Buster, we have Octavia. This is
a "load balancer as a service". I managed to make a debian based image
for this, containing the Octavia agent, and some other tweakings, so
that the image can be used directly by Octavia. I'd love to make this an
official Debian image soon.
This is just an example, but I'm convinced their will be others, for
example for OpenStack Trove (DB as a Service) and maybe more.
In such case, we may want to make it explicite which type of image we're
talking about. For example "Base image" or "Octavia HAProxy Amphora".
I think that shows better details about one specific image, we will update this on our prototype.
In this case, we can remove Release and leave just Code name, but just to clarify the finder will only store images details about public cloud providers but we still consider the output fields.
This is a thing that we are getting feedback to see which model will be mode interactive with users, but we note your point of view on this topic.
For images generated on CI/CD the final job will update automatically the finder, for public providers that build their own images when they publish one new image they will need to post the metadata on the finder API that we will provide for each provider.
Just like explained before you will have the finder API to publish these custom images and you can change it type when you publish your images.
We will update that to just cover Arm64, Amd64 for now.
I'm not sure where you want to go with that "architecture" knobs on the home page. In most cases (GCE, Azure at least) it will be the only amd64, and then it looks silly. AWS just recently added arm64, but that is a detail you only need to know later.
What IMHO would make more sense is a version selection for Stretch, Buster, Bullseye and/or Beta-Images.
Also, we want to update all the new images at once, so last updated on the single items makes not much sense.
All that you said makes complete sense for now. So we will remove architecture knobs on the home page and replace for version selection for Stretch, Buster, Bullseye and/or Beta-Images, also we will remove the last updated timer.