Open CSP on Canasta - Proof of concept

13 views
Skip to first unread message

Jeffrey Wang

unread,
Nov 2, 2022, 8:17:04 PM11/2/22
to Canasta
Hi all,

During the SMWCon 2022 hackathon in Breda, I worked on getting Open CSP working on Canasta. I have created a proof of concept on my GitHub: https://github.com/jeffw16/opencsp-canasta.

This is currently very much just a proof of concept. I have reached out to the Open CSP developers and I'm working with them on developing it further.

Feel free to provide feedback and to submit patches! I'm also happy to answer any questions about this.

By the way, in order to get this into more than just a POC, I've already opened an issue on the Canasta image's GitHub repo that'll get rid of the hacky script running currently necessary: https://github.com/CanastaWiki/Canasta/issues/140.

(For anyone who already has a correct understanding of the relationship of Open CSP and Canasta, feel free to ignore the rest of the email.)

I also want to address proposals from the community for Open CSP and Canasta to merge together. I very much appreciate proposals to collaborate rather than compete, because we achieve more when we put our minds to work on the same time. In case you're wondering why we aren't merging Open CSP and Canasta together, it's because Open CSP and Canasta are (for the most part) not competitors. The tech stack of Canasta provides a simple but powerful platform for Open CSP to run on. Open CSP is built at the application layer and is agnostic of running on a VM versus containers. Because Canasta's tech stack complements Open CSP, we won't be merging together, but we'll continue to pursue a mutually-beneficial relationship.

It is true that the bundled extensions approach Canasta takes does differ from what Open CSP offers. While Canasta provides a large basket of vetted extensions ready for the sysadmin to install with ease, Open CSP provides a carefully curated set of extensions to form a specifically-defined product. That being said, this difference in philosophy does not necessarily mean one is better than the other. Each has its merits and each has its separate use cases. Plus, Canasta's approach to producing derivative images means the default approach can be changed/molded into something custom, like Open CSP, which means there isn't only one "correct" way of doing things.

I am committed to helping Open CSP fluorish on Canasta as long as the Open CSP developers are willing to do the same. So far, I'm happy to report that this does seem to be the case, and the Open CSP developers seem to be on the same page as we (the Canasta developers) are. I believe the Canasta Project should make a good-faith effort to accommodate Open CSP to a reasonable extent. If there are any reasonable changes that should be made to Canasta, such as the issue on GitHub I linked above, then of course we should be making them.

As I said at SMWCon, comparing Open CSP and Canasta is like comparing apples and oranges. We're not the same fruit, but we both taste delicious and you should have both of us together!

TL;DR: Open CSP and Canasta aren't merging because we complement each other. To that end, we'll continue working together.

khush rehna
jeffrey
Reply all
Reply to author
Forward
0 new messages