From: ng0 <ng0@pragmatique.xyz>
To: guix-devel@gnu.org
Subject: Re: how to create and test a new service definition
Date: Sun, 14 May 2017 11:48:17 +0000 [thread overview]
Message-ID: <nycvar.YAK.7.76.1705141147530.1140@ybpnyubfg> (raw)
In-Reply-To: <nycvar.YAK.7.76.1705140855500.846@ybpnyubfg>
On Sun, 14 May 2017, ng0 wrote:
> On Sun, 14 May 2017, Catonano wrote:
>
>> 2017-05-13 22:06 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:
>>
>>> Vincent Legoll <vincent.legoll@gmail.com> skribis:
>>>
>>>>> The best way to test your code is to write an ‘operating-system’
>>>>> declaration that uses the new service and to instantiate it in a VM
>>>>> with
>>>>> ‘guix system vm’.
>>>>
>>>> Should that be working properly (out-of-the-box) when you're already in
>>>> a qemu VM (recursive virtualization) ?
>>>>
>>>> I ask because I'm getting:
>>>>
>>>> [...]
>>>> ERROR: qemu failed "qemu-system-x86_64"
>>>
>>> What were the lines above this one? This tool tries to use KVM if it
>>> seems available. Maybe in your case it “seems” to be available (as in
>>> /dev/kvm exists) but is actually unusable?
>>>
>>>>> Once you’ve done that, you can also write an automated test for the new
>>>>> service; see <https://gnu.org/s/guix/news/guixsd-system-tests.html>.
>>>>
>>>> I'm far from there, I have a *really* hard time getting back to guixsd.
>>> For
>>>> instance it took me very long time to find back the GUIX_PACKAGE_PATH
>>>> env var. This looks under-documented, or I don't understand how one is
>>>> to
>>>> work on custom or new packages, etc...
>>>
>>> ‘GUIX_PACKAGE_PATH’ is documented at
>>> <https://www.gnu.org/software/guix/manual/html_node/Package-
>>> Modules.html#index-GUIX_005fPACKAGE_005fPATH>.
>>>
>>> The workflow for defining packages is described at
>>> <https://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html
>>>> ,
>>> and that for contributing them is at
>>> <https://www.gnu.org/software/guix/manual/html_node/
>>> Submitting-Patches.html>.
>>>
>>> There’s probably room for improvement though. What changes/additions
>>> would you suggest?
>>>
>>
>> Let me chime in here: I'd suggest to state the workflow or defining
>> services, as the one or deining packages is stated
>>
>> But I'm not thinking about how to define and use The scheme structures.
>> The
>> examples are enough for that.
>>
>> I'm thinking about things like how to deal with qemu, if you want to test
>> your services in a vm
>>
>> Is there any other way to get your feet wet with services ?
>>
>> George suggested me the trick to link a checked out master branch to
>> .local/guix/profile (or maybe it's the other way around: it's liinking
>> .local/guix/profile to a checked out master branch)
>>
>> Is anyone using this to work on services ? How, exactly ?
>>
>> Thanks
>>
>
> My current way of testing services is usually on bare-metal.
> I had bad experiences with one network based service (gnunet)
> and it being terrible to debug, so I took the QEMU out of there.
> I test things this way which will not break my current generation like
> darkhttpd or the gopherd I submitted as a question.
> Other, potential boot breaking, stuff I test on other systems.
>
> This is also because I never really figured out the best way
> to run network based services in qemu in Guix. I have no issues
> with qemu, but on Guix many months back it behaved unlike the
> qemu I knew from Gentoo.
I have to append to this: I tried debugging darkhttpd with a shared VM
now and it is much more useful to get a bourne-like shell than
a frozen system if you make a syntax error in the container description.
So that's definitely a plus for the VM.
> There is lots of room for services in the documentation.
> There should be a "contributing services" section in chapter 8,
> currently I learn this the way I learned to do packages, by
> repetition and failure until I see how to debug stuff.. which is already
> helping since I am starting to see patterns for debugging with darkhttpd (it
> helped that it simply worked and then randomly broke in further attempts).
>
>
>
>
>
next prev parent reply other threads:[~2017-05-14 11:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-13 10:06 how to create and test a new service definition Vincent Legoll
2017-05-13 14:40 ` Ludovic Courtès
2017-05-13 15:24 ` Vincent Legoll
2017-05-13 20:06 ` Ludovic Courtès
2017-05-14 7:56 ` Catonano
2017-05-14 9:04 ` ng0
2017-05-14 11:48 ` ng0 [this message]
2017-05-14 8:44 ` Vincent Legoll
2017-05-14 9:53 ` Catonano
2017-05-15 13:26 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.YAK.7.76.1705141147530.1140@ybpnyubfg \
--to=ng0@pragmatique.xyz \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.