toolshed/organising
toolshed/organising
8
1
Fork 0
Code Issues 120 Pull Requests Releases Activity

Support multiple app catalogues #139

New Issue
Open
opened 2021-09-09 13:03:39 +00:00 by decentral1se · 6 comments
decentral1se commented 2021-09-09 13:03:39 +00:00
Owner
Copy Link

So folks don't have to rely on https://recipes.coopcloud.tech.

Will support using own set of releases, recipes etc.

Could support multiple? "official" / "custom" / etc. Unsure.

So folks don't have to rely on https://recipes.coopcloud.tech. Will support using own set of releases, recipes etc. Could support multiple? "official" / "custom" / etc. Unsure.
femmefaytale added the
enhancement
 label 2021-09-09 13:26:43 +00:00
decentral1se added this to the (deleted) milestone 2021-09-09 14:23:34 +00:00
decentral1se commented 2023-02-18 22:55:06 +00:00
Author
Owner
Copy Link

coop-cloud/organising#321 is related.

https://git.coopcloud.tech/coop-cloud/organising/issues/321 is related.
decentral1se commented 2023-02-18 23:01:34 +00:00
Author
Owner
Copy Link

Some points while they're flying around in my head:

  • This could fit into coop-cloud/organising#303 perhaps? You could specify which catalogue you want to target and read from there? This might be easy to specify a new catalogue but not multiple?

  • We could support ~/.abra/cataogues.d/... where people can just clone in some directory that has a convention of catalogue.json or something. Then ask abra to merge all those files and present the catalogue internally? How do we deal with conflicting versions though?

  • abra still internally polls git.coopcloud.tech for the recipes listing to build the catalogue on abra catalogue generate and also elsewhere, i believe. this would need a investigation to see how to consolidate catalogue reading into once place that is then pluggable for new catalogues? Unknown.

Some points while they're flying around in my head: - This could fit into https://git.coopcloud.tech/coop-cloud/organising/issues/303 perhaps? You could specify which catalogue you want to target and read from there? This might be easy to specify a new catalogue but not multiple? - We could support `~/.abra/cataogues.d/...` where people can just clone in some directory that has a convention of `catalogue.json` or something. Then ask `abra` to merge all those files and present the catalogue internally? How do we deal with conflicting versions though? - `abra` still internally polls git.coopcloud.tech for the recipes listing to build the catalogue on `abra catalogue generate` and also elsewhere, i believe. this would need a investigation to see how to consolidate catalogue reading into once place that is then pluggable for new catalogues? Unknown.
decentral1se commented 2023-02-18 23:03:10 +00:00
Author
Owner
Copy Link

Some hardcoded stuff 5739758c3a/pkg/config/env.go (L23-L26) 😬

Some hardcoded stuff https://git.coopcloud.tech/coop-cloud/abra/src/commit/5739758c3a93d724500bd3ca1263d30f13361d3e/pkg/config/env.go#L23-L26 😬
cas commented 2023-02-18 23:10:48 +00:00
Member
Copy Link

Like from the high level, we need:

  • A way to generate and maintain independent catalogs (with abra catalog generate or
    whatever)
  • A way of listing them for abra - as suggested above it could be a repo you checkout, but we could also do a sort of metacatalog or like have a catalog descriptor json that says where to get the json from (git or a url or whatever), similar to how apt does it.
  • Define what a catalog is, exactly, from the perspective of a separate organization (a list of repositories for recipes, with versions(tags) ultimately but maybe tightening it down so that running your own catalog wouldn't be too complicated)
  • The logic behind how we select which version of a given recipe (do we simply rank the catalogs and fill the request in rank order, or do we look at the versions across catalogs and take the highest by default unless otherwise specified) - in any case the user needs to be able to list every version of a given recipe which would show which catalog it comes from, and also select any version of a recipe and any version of a recipe+catalog (so i want to use version 1.0 from the cassowary catalog, or i want to use version 0.7 from the coopcloud catalog, there needs to be a way to do that even if the same version appears in multiple catalogs).
  • And still, the local checkout/local version/uncommitted stuff in recipes can override anything to do with that with --chaos at all times.
Like from the high level, we need: - A way to generate and maintain independent catalogs (with abra catalog generate or whatever) - A way of listing them for abra - as suggested above it could be a repo you checkout, but we could also do a sort of metacatalog or like have a catalog descriptor json that says where to get the json from (git or a url or whatever), similar to how apt does it. - Define what a catalog is, exactly, from the perspective of a separate organization (a list of repositories for recipes, with versions(tags) ultimately but maybe tightening it down so that running your own catalog wouldn't be too complicated) - The logic behind how we select which version of a given recipe (do we simply rank the catalogs and fill the request in rank order, or do we look at the versions across catalogs and take the highest by default unless otherwise specified) - in any case the user needs to be able to list every version of a given recipe which would show which catalog it comes from, and also select any version of a recipe and any version of a recipe+catalog (so i want to use version 1.0 from the cassowary catalog, or i want to use version 0.7 from the coopcloud catalog, there needs to be a way to do that even if the same version appears in multiple catalogs). - And still, the local checkout/local version/uncommitted stuff in `recipes` can override anything to do with that with --chaos at all times.
🚀 1
decentral1se added this to the (deleted) project 2023-06-08 09:33:31 +00:00
decentral1se commented 2024-03-28 16:23:48 +00:00
Author
Owner
Copy Link

Re-discussed this with @p4u1 again today and coop-cloud/organising#303 definitely seems like a prerequisite for getting this done because we need to be able to define the alternate catalogues URLs (Git or otherwise).

Re-discussed this with @p4u1 again today and https://git.coopcloud.tech/coop-cloud/organising/issues/303 definitely seems like a prerequisite for getting this done because we need to be able to define the alternate catalogues URLs (Git or otherwise).
basebuilder modified the milestone from (deleted) to (deleted) 2024-04-15 07:07:48 +00:00
decentral1se commented 2024-07-26 10:36:45 +00:00
Author
Owner
Copy Link

This is now a current (unreleased) "work-around" which does not go as far as a full separate catalogue but does enable it I think.

[This](https://docs.coopcloud.tech/operators/handbook/#remote-recipes) is now a current (unreleased) "work-around" which does not go as far as a full separate catalogue but does enable it I think.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
abra
Everything to do with abra
abra-gandi
Abra Gandi plugin
awaiting-feedback
Ping/pong on comms
backups
bug
Something is not working
build
Go build related issues
ci/cd
Getting the robots into the mix
community organising
Opening this thing up
contributing
Contributors stuff
coopcloud.tech
Our main website
democracy
Democratic decision making
design
Design thinking required
documentation
Let's write things together
duplicate
This issue or pull request already exists
enhancement
New feature
finance
Money things
funding
Anything related to grant funding
good first issue
Easy start with development
help wanted
Need some help
installer
Installation related issues
kadabra
performance
Performance related
proposal
Large change which requires feedback & decisin making
question
More information is needed
recipes.coopcloud.tech
Our recipes catalogue
security
Securing our shit
test
Unit or integration test suite
wontfix
This won't be fixed
No Label
enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
3wordchant abra-bot ammaratef45 Apfelwurm carla cas decentral1se fauno kawaiipunk knoflook lambdabundesverband moritz p4u1 simon trav val yksflip
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: toolshed/organising#139
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?