initial pass at arch diagrams both abstract and implementation #1245
Conversation
|
It might be helpful to add numbered labels to arrows- e.g This ofcourse has a downside in that it implies a certain directionality. Overall I think the numbered arrows might be useful. |
| create_feedstock = GithubActions(label='create feedstock repo') | ||
| autotick = GithubActions(label='autotick bot') | ||
|
|
||
| anaconda_server = Storage(label='Anaconda Servers') |
There was a problem hiding this comment.
I'm not sure if this is too much detail but I think this should contain more detail about how the channel is implemented. Perhaps three components:
- anaconda.org
- CDN mirroring with repodata patches being an input
- The publicly visible channel
There was a problem hiding this comment.
This is all stuff anaconda maintains and so we shouldn't have it here. To us anaconda.org is a free service with a big latency for uploads.
There was a problem hiding this comment.
I think it's useful to be here so someone can look at this and understand what is might be wrong with conda-forge for a given symptom. Questions and issues with the CDN sync common enough that I think it's worthwhile acknowledging it exists in the conda-forge documentation. Again, I don't feel that strongly about it if others disagree.
There was a problem hiding this comment.
sure - we can put a big anaconda box around things
There was a problem hiding this comment.
I'm actually not certain of the anaconda structure. I'm happy to put it in if someone can tell me what the pieces are and how they connect (on the implementation diagram, I think as a concept the channel is just a sink for all of our stuff and a source for users (and ourselves I guess))
|
|
||
| staged_recipes >> cis >> staged_recipes | ||
| staged_recipes >> linter >> staged_recipes | ||
| staged_recipes >> create_feedstock >> new_feedstock >> cis >> validation >> anaconda_server |
There was a problem hiding this comment.
I'm not sure if package validation needed for the conceptual diagram as I see it as more of an implementation detail. Perhaps "Anaconda Servers" should be "conda channel"?
There was a problem hiding this comment.
We maintain the validation with infrastructure we control so it needs to be here.
There was a problem hiding this comment.
I agree it needs to be the "Conda-Forge Implementation" diagram but I'm not sure it needs to be in the "Conda-Forge Conceptual" diagram though I don't feel that strongly about it if others disagree.
There was a problem hiding this comment.
Hmm, validation might be an independent concept, since it isn't formally owned by any of the other pieces. Also the fact that we validate our packages is important to the running of conda-forge, since is a barrier to some potential attacks. I would call the implementation detail that this is run off of the heroku server for instance. I'm happy to be turned around on this though.
The idea is to capture all the moving pieces at both in an abstract,
service oriented way and from an implementation perspective.
CC: @beckermr @kruttik-lab49 @k504866430