Christopher Allan Webber skribis:
> Ludovic Courtès writes:
>
>> Christopher Allan Webber skribis:
>>
>>> - Should I build the entire derivation of the system I want to run on
>>>the remote machine locally first, then copy that over? (I assume
>>>this is possible, and eventually desira
Ludovic Courtès writes:
> Christopher Allan Webber skribis:
>
>> - Should I build the entire derivation of the system I want to run on
>>the remote machine locally first, then copy that over? (I assume
>>this is possible, and eventually desirable, especially if doing
>>mass deployme
Howdy!
Christopher Allan Webber skribis:
> So yeah, I'm going to start playing around with building some on some of
> these ideas soonish. I could use some advice, though. Assume I'm able
> to build the right scheme representation of the system I want to be run
> remotely on another machine (w
Ludovic Courtès writes:
>> There's a lot of good ideas in this thread. Will be good to make
>> progress on them!
>
> Yup! The need for this tool is becoming stronger, especially now that
> we’re starting to run GuixSD on our build farm machines.
>
> Ludo’.
So yeah, I'm going to start playing ar
Christopher Allan Webber skribis:
> David Thompson writes:
>
>> Hello again Carlos,
>>
>> Carlos Sosa writes:
>>
>>> I like the idea of 'guix deploy', and maybe something to propagates
>>> given configuration files, like 'guix config prepare' and later 'guix
>>> config apply'.
>>>
>>> Now,
David Thompson writes:
> Hello again Carlos,
>
> Carlos Sosa writes:
>
>> I like the idea of 'guix deploy', and maybe something to propagates
>> given configuration files, like 'guix config prepare' and later 'guix
>> config apply'.
>>
>> Now, how can I contribute? work the guix command?
>>
David Thompson writes:
> Hello again Carlos,
>
> Carlos Sosa writes:
>
>> I like the idea of 'guix deploy', and maybe something to propagates
>> given configuration files, like 'guix config prepare' and later 'guix
>> config apply'.
>>
>> Now, how can I contribute? work the guix command?
>>
Quoting Christopher Allan Webber (2015-07-09 14:27:04)
> ...
I'd throw heat[1] into the list of things to read up on, but otherwise
this sounds like fairly good/complete advice.
-Ian
[1]: https://wiki.openstack.org/wiki/Heat
signature.asc
Description: signature
David Thompson writes:
>> As discussed on IRC, I was unsure about OpenStack, but I’ll trust your
>> judgment. Maybe Cyril can comment?
>
> I threw out OpenStack because it's a self-hostable, free software VM
> platform. I'm open to any other platforms that will exercise the full
> range of capab
Hey Pjotr,
On Mon, Jun 1, 2015 at 11:18 AM, Pjotr Prins wrote:
>> There's also unanswered questions like: How should we keep track of
>> state? How do we reconfigure already deployed machines? How do we shut
>> down a deployment and unprovision the resources it used? Basically, how
>> many hoo
> There's also unanswered questions like: How should we keep track of
> state? How do we reconfigure already deployed machines? How do we shut
> down a deployment and unprovision the resources it used? Basically, how
> many hooks does the record type need to cover everything?
The current 'depl
On Wed, May 27, 2015 at 3:41 PM, Ludovic Courtès wrote:
> David Thompson skribis:
>
>> Ludovic Courtès writes:
>>
>>> Perhaps one addition eventually would be to allow IPs to be
>>> automatically allocated and have host name lookup DTRT in each VM.
>>
>> Do you have any idea how we could do that
On Wed, May 27, 2015 at 2:47 PM, Carlos Sosa wrote:
> David Thompson writes:
>
>> Thinking out loud here: Maybe 'guix deploy' can kick off the
>> provisioning for all machines first, and afterwards the OS configs can
>> be altered to include the correct /etc/hosts file.
>
> I like the idea of `
David Thompson skribis:
> Ludovic Courtès writes:
>
>> Perhaps one addition eventually would be to allow IPs to be
>> automatically allocated and have host name lookup DTRT in each VM.
>
> Do you have any idea how we could do that for local VMs? There's no
> daemon managing the provision of the
David Thompson writes:
> Thinking out loud here: Maybe 'guix deploy' can kick off the
> provisioning for all machines first, and afterwards the OS configs can
> be altered to include the correct /etc/hosts file.
I like the idea of `guix deploy` with a minor change where we add
`guix deploy m
Ludovic Courtès writes:
> Perhaps one addition eventually would be to allow IPs to be
> automatically allocated and have host name lookup DTRT in each VM.
Do you have any idea how we could do that for local VMs? There's no
daemon managing the provision of these resources, so I don't know what
s
David Thompson skribis:
> To take it for a spin, add something like this to a file, let's call it
> "deployment.scm":
>
> (use-modules (gnu) (guix gexp))
> (use-service-modules databases)
> (use-package-modules web databases)
>
> (define dummy-fs
> (file-system
>
Hello again Carlos,
Carlos Sosa writes:
> I like the idea of 'guix deploy', and maybe something to propagates
> given configuration files, like 'guix config prepare' and later 'guix
> config apply'.
>
> Now, how can I contribute? work the guix command?
>
> Let me know if you have a specifi
Ludovic Courtès writes:
> David Thompson skribis:
>
>> I should create a "wip-deploy" branch in our git repository that you
>> could submit patches for. I need to do a bit more work to get the very
>> basics working so we have a foundation to build on, though.
>
> That would be nice, feel free t
David Thompson skribis:
> I should create a "wip-deploy" branch in our git repository that you
> could submit patches for. I need to do a bit more work to get the very
> basics working so we have a foundation to build on, though.
That would be nice, feel free to do push a branch whenever you de
ke.
> While it works great, I would prefer any tool that works with Guile
> syntax.
Yes, we should have our own tool for this purpose that has excellent
integration with the rest of the system.
> l...@gnu.org (Ludovic Courtès) writes:
>
>> BTW, I’d prefer something like ‘guix
ke ‘guix deploy’ over ‘guix ops’, but then
> another name would need to be found for the ‘deploy’ sub-command, maybe
> ‘realize’?
I like the idea of 'guix deploy', and maybe something to propagates
given configuration files, like 'guix config prepare' and later
; used to create that deployment.
>>
>> I’m not 100% clear on why this state needs to be stored; it seems more
>> like a cache to me, no? That is, Charon/NixOps can always recreate it
>> from the source Nix expressions.
>
> The state that I am concerned with are the details
needs to be stored; it seems more
> like a cache to me, no? That is, Charon/NixOps can always recreate it
> from the source Nix expressions.
The state that I am concerned with are the details of the resources that
have been provisioned by 'guix ops'. For example, in a system that
it’s best to keep it separate from ; in NixOps
it’s a ‘deployment’ attribute in the OS attribute set.)
> * : Contains a name string and a list of and
> procedures. Procedures in the list should accept an argument
> containing the deployment results of the non-parameterized m
dures. Procedures in the list should accept an argument
containing the deployment results of the non-parameterized machines
and return a .
* Use a simple s-exp deployment state format. Store the state in
$HOME/.config/guix by default.
* Implement a 'guix ops' subcommand roug
26 matches
Mail list logo
