Booster meta data belongs into catalog
heiko-braun opened this issue · 15 comments
Currently the booster meta data resides with each booster, but from my point of view it belongs into the catalog:
name: HTTP CRUD - Wildfly Swarm
description: A simple CRUD application using Wildfly Swarm
versions:
- id: community
name: 2017.9.5 (Community)
- id: redhat
name: 7.0.0.redhat-6 (RHOAR)
All of the above has to kept redundantly in the each booster branch (community/prod) while it's really an overarching concern. I suggest we move this data into the catalog, rather then keeping it with each booster.
The reasoning for this is documented here: https://docs.google.com/document/d/19o6UXVykkCqp2ZxBcS8ZS5AyEz8nIyoNx9liQjCG7AQ/edit#heading=h.z1z4cdkqs18w
But perhaps it's unreasonable to assume that within a single runtime boosters could be using different versions of that runtime? So perhaps we could move them to the metadata file as sub-items of the runtimes?
I think there can be different versions. But why would that prevent us from moving the meta data to the catalog itself? I.e. in [1] it could read:
githubRepo: wildfly-swarm-openshiftio-boosters/wfswarm-rest-http
gitRef: master
id: community
name: 2017.9.5 (Community)
Or am I missing something here?
Ah, I thought the main thing was to get rid of the redundancy, because doing it that way you'd still have multiple "name: 2017.9.5 (Community)" entries in the different .yaml files, right?
Yes, you would still have the entries in different yaml files. The main difference (and motivation) is to keep it close to the catalog, which seems to be the only client to that information. And to me it seems that the point in time when this meta data changes, is when the catalog is updated to new versions of a booster.
In a near future we want to automate the booster-catalog repository maintenance. This would include creating PRs when boosters are tagged but that would make things more difficult if the version is specified inside the catalog, no?
I'm not sure @gastaldi , you mean because you could be upgrading the code to upgrade from eg "name: 2017.9.5 (Community)" to "name: 2017.10.2 (Community)" which then would only mean a change to the booster itself (because you can change the name in the booster.yaml itself) while putting it in the catalog would mean updating the catalog as well, right?
@quintesse yes, that's my point
I think there are two use cases:
a) catalog references boosters that reside within a tag
b) catalog references boosters that reside within a branch
For a) a new release of a booster leads to change to the catalog. For b) not necessarily.
I've been looking at it from the perspective of a) so far.
I think @gastaldi point is only valid for b), no? The question is: Is this actually being used outside catalog.master? I would think that for anything on catalog.next or catalog.free people use tagged boosters (my case a)?
Yeah, that's why I think it is much easier to have this information in a single place (the booster repository) instead of in the catalog.
Easier depends on the point of view. As I said: For people using tagged boosters it's not the case. Here you need to update the catalog anytime you release a new booster. And I am arguing the main case is tagged releases.
See I release rest-http v12 and now have to update both the catalog to reference the tag v12 but also make sure the booster tag contains the meta data that says v12
But I get your point. There are arguments for both cases. Feel free to close this issue
Yes, when we introduce webhooks to the booster repositories we can make the booster-catalog updates automatically, but we would be missing context if the version is another parameter to be changed in the catalog.
I'll close it for now and revisit this if the scenario changes
Thanks for the thoughts @heiko-braun @quintesse