Hi Josselin, Josselin Poiret <d...@jpoiret.xyz> writes:
> [[PGP Signed Part:Undecided]] > Hi Edouard, > > Edouard Klein <e...@beaver-labs.com> writes: > >> #+begin_src scheme >> (-> >> (minimal-ovh "ssh-rsa AAASomethingSomething== root@minimal-ovh") >> (http-static-content "sub2.example.com" #:to-dir "/srv/sub2") >> (http-static-content "sub1.example.com" #:to-dir "/srv/sub1/") >> (add-services my-db)) >> #+end_src >> >> The code of the function is on my channel: >> https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/system.scm >> >> After a few months of experience, and positive feedback from my clients, >> my question to you guys is: would you be interested in mainlining this, >> or should I keep my development efforts separate in my channel ? > > I am quite in favor of using operating-system transformations rather > than inheritance, because they're composable! This could be leveraged > to get a nice CLI API as well. > I hadn't thought of that but now that you mention it, starting a basic web server or database, isolated in a container, directly from the command line may come in handy sometimes. This is a good idea ! I'll think about how to achieve this :) In the meantime something like: #+begin_src bash guix system container -e "(begin (use-modules (beaver system)) (http-static-content minimal-container))" --share=somedir=/var/www #+end_src Will spin up such a server. Kind of like python3 -m http.server, but without the security flaws (you get a full blown nginx), and isolated in a way that even if your process gets owned, it's only an unpriviledged user in a container. >> I do think this API is easier than manipulating services, and although >> extendable services are awesome and a very nifty piece of engineering, >> they require quite a good knowledge of scheme and take a while to be >> used to, while this new API, while way less powerful, lowers the barrier >> to entry for newcomers. > > By this, do you mean that there's no way with your syntax to modify a > given service? Is there a reason for this? It does seem to me that it > could probably be done. > I'm not sure I understand your question. What I meant is that my proposal is only syntactic sugar over the existing system, and not meant to replace it. The existing system is actually very good and the way you can define how to collate the instances of a given service type, even if they are instanciated far away from one another, likely by different authors is really clever and well made. I'm talking here about things like how you can easily request that a new user be made for your service, and account-service-type will collate all the users that need to exist, and actually get the job done. Basically what fold-services does. I just want to hide all of this complexity for people who just want to activate one or more instances of a service coded up by somebody else. If by modifying a service you mean the parameters like the port ones listen to, or the directory the data should be put in etc. the functions just take keyword parameters and pass them to the underlying *-configuration scheme record. They are quite easy to edit and compose. Maybe we could even devise a semi-automated way of generating one function for every *-configuration structure that exists. See https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/system.scm#L236 how http-static-content is basically just a wrapper over nginx-server-configuration. If you meant editing the service after the function has run, you then need to inspect the operating-system record and fall back to the original API, by finding the service in the record and editing its members, but that seems complex to me. I'm probably misunderstanding the use case. >> They are an easy way to maintain a declarative whole operating system >> configuration, with a syntax similar enough to docker and ansible that >> sysadmins familiar with it can quickly get up and running, thus exposing >> more people to Guix. >> >> What do you think ? > > You've got me interested :) especially since you already have customer > feedback! > Thanks :) Cheers, Edouard. > Best,