Skip to content

Changes

Page history
Update High Fidelity Prototype authored by Arthur Diniz's avatar Arthur Diniz
Show whitespace changes
Inline Side-by-side
High-Fidelity-Prototype.md
View page @ c1dc3775
......@@ -40,10 +40,9 @@ cloud provider.
Hi Noah, in response to your feedback:
1. "on using a static (bookmarkable) URL for the provider", this was already
planned in our backlog. So for example given the URL=finder.debian.org the path for open stack it will be finder.debian.org/open-stack.
1. "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.
2. The ideia for this problem it 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?
2. 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?
Thanks for your feedback!
......@@ -53,7 +52,7 @@ Thanks for your feedback!
## From: Thomas Goirand <zigo@debian.org>
1. In your "provider details", I can see name, zone, version, etc., though
1. 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:
......@@ -112,15 +111,15 @@ images... :)
### Answer to Thomas Goirand <zigo@debian.org>
Hi Thomas, in response to your feedback:
1. I think that show better details about onde specific image, we will update this on our prototype.
1. I think that shows better details about one specific image, we will update this on our prototype.
2. In this case we can remove Release and leave just Code name, but just to clarify the finder will only stores images details about public cloud providers but we still consider the output fields.
2. 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.
3. This is a thing that we are getting feedback to see witch model will be mode interactive with users, but we note your point of view on this topic.
3. 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.
4. 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.
5. Just like explained before you will have the finder API to publish this custom images and you can change the it type when you publish your images.
5. 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.
6. We will update that to just cover Arm64, Amd64 for now.
......@@ -128,17 +127,17 @@ Thanks for your feedback!
## From: Bastian Blank <waldi@debian.org>
1. 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 only amd64, and then it looks silly. AWS just recently added arm64, but that is a detail you only need to know later.
1. 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.
2. What IMHO would make more sense is a version selection for Stretch, Buster, Bullseye and/or Beta-Images.
3. Also we want to update all the new images at once, so last updated on the single items makes not much sense.
3. Also, we want to update all the new images at once, so last updated on the single items makes not much sense.
### Answer Bastian Blank <waldi@debian.org>
Hi Bastian, in response to your feedback:
All that you said makes completely 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 last updated timer.
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.
Thanks for your feedback!