Re: [Nix-dev] Gratuitous generations

2015-03-31 Thread Christian Theune
Hi,

> On 30 Mar 2015, at 15:07, Eelco Dolstra  wrote:
> 
> We could add an option to suppress creating a new generation if nothing has 
> changed.

I read some code and I have a suggestion - tell me if I’m missing something 
obvious, because this looks really simple.

In createGeneration we already look at the existing generations
https://github.com/NixOS/nix/blob/master/src/nix-env/profiles.cc#L77 


Looking at the generation links, I can see this in my profiles directory:

lrwxr-xr-x   1 ctheune  wheel60B Mar 17 17:15 default-30-link -> 
/nix/store/ywgj0k27h2c6ly7l40afbqxncis858c1-user-environment
lrwxr-xr-x   1 ctheune  wheel60B Mar 17 17:16 default-31-link -> 
/nix/store/ywgj0k27h2c6ly7l40afbqxncis858c1-user-environment
lrwxr-xr-x   1 ctheune  wheel60B Mar 17 17:16 default-32-link -> 
/nix/store/ywgj0k27h2c6ly7l40afbqxncis858c1-user-environment

So. How about adapting createGeneration to not create a new generation if it 
targets the same environment as the previous one? Maybe with an option?

Would this be the right point to change this? Am I missing something? Looks 
quite simple to me (minus my C++ writing abilities being basically nonexisting).

If this path looks OK to you then I’d be happy to bash my head against the C++ 
to learn something.

Christian

—
Christian Theune · c...@flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Gratuitous generations

2015-03-31 Thread phreedom
On Tuesday, March 31, 2015 11:42:15 you wrote:
> Ah, I didn't know about that option!  That sounds good; where does it copy
> it to, though?  It isn't clear to me from the docs.

/nix/var/nix/profiles/system*/configuration.nix
It's a bit easier to access when dealing with old/multiple profiles.


> On Tue, Mar 31, 2015 at 8:02 AM,  wrote:
> > On Monday, March 30, 2015 16:16:36 Ryan Trinkle wrote:
> > > Ah, great point!  This line worked perfectly for me:
> > > 
> > > environment.etc."nixos/current/configuration.nix".text =
> > 
> > builtins.readFile
> > 
> > > ./configuration.nix;
> > 
> > I have been using this option: system.copySystemConfiguration = true;
> > 
> > Placing the current config "closer" to /etc/nixos/configuration.nix makes
> > it
> > easier to run diff against the active profile. copySystemConfiguration's
> > location
> > makes it easier to dig older profiles. Maybe it's a good idea to use both
> > locations?
> > 
> > > On Mon, Mar 30, 2015 at 4:10 PM, Michael Raskin <7c6f4...@mail.ru>
> > 
> > wrote:
> > > > >On Mon, Mar 30, 2015 at 9:47 PM, Ryan Trinkle  > > > 
> > > > wrote:
> > > > >> On a somewhat related note, is there any way to see the exact
> > > > >> configuration.nix for a particular generation?  It would be great
> > 
> > to be
> > 
> > > > able
> > > > 
> > > > >> to diff generations against each other (e.g.: to figure out whether
> > 
> > a
> > 
> > > > >> channel update caused a problem or whether it was my own change).
> > > > >
> > > > >You are not the first one to request this feature.
> > > > >They are a few issues in the way, but I will open an issue and do it
> > > > >as soon as I am done with the httpd rewrite.
> > > > 
> > > > In the meantime just adding /etc/ entry that is a copy of
> > > > /etc/nixos/configuration.nix should work…
> > 
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Gratuitous generations

2015-03-31 Thread Ryan Trinkle
Ah, I didn't know about that option!  That sounds good; where does it copy
it to, though?  It isn't clear to me from the docs.

On Tue, Mar 31, 2015 at 8:02 AM,  wrote:

> On Monday, March 30, 2015 16:16:36 Ryan Trinkle wrote:
> > Ah, great point!  This line worked perfectly for me:
> >
> > environment.etc."nixos/current/configuration.nix".text =
> builtins.readFile
> > ./configuration.nix;
>
> I have been using this option: system.copySystemConfiguration = true;
>
> Placing the current config "closer" to /etc/nixos/configuration.nix makes
> it
> easier to run diff against the active profile. copySystemConfiguration's
> location
> makes it easier to dig older profiles. Maybe it's a good idea to use both
> locations?
>
> > On Mon, Mar 30, 2015 at 4:10 PM, Michael Raskin <7c6f4...@mail.ru>
> wrote:
> > > >On Mon, Mar 30, 2015 at 9:47 PM, Ryan Trinkle  >
> > >
> > > wrote:
> > > >> On a somewhat related note, is there any way to see the exact
> > > >> configuration.nix for a particular generation?  It would be great
> to be
> > >
> > > able
> > >
> > > >> to diff generations against each other (e.g.: to figure out whether
> a
> > > >> channel update caused a problem or whether it was my own change).
> > > >
> > > >You are not the first one to request this feature.
> > > >They are a few issues in the way, but I will open an issue and do it
> > > >as soon as I am done with the httpd rewrite.
> > >
> > > In the meantime just adding /etc/ entry that is a copy of
> > > /etc/nixos/configuration.nix should work…
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Gratuitous generations

2015-03-31 Thread phreedom
On Monday, March 30, 2015 16:16:36 Ryan Trinkle wrote:
> Ah, great point!  This line worked perfectly for me:
> 
> environment.etc."nixos/current/configuration.nix".text = builtins.readFile
> ./configuration.nix;

I have been using this option: system.copySystemConfiguration = true;

Placing the current config "closer" to /etc/nixos/configuration.nix makes it 
easier to run diff against the active profile. copySystemConfiguration's 
location 
makes it easier to dig older profiles. Maybe it's a good idea to use both 
locations?

> On Mon, Mar 30, 2015 at 4:10 PM, Michael Raskin <7c6f4...@mail.ru> wrote:
> > >On Mon, Mar 30, 2015 at 9:47 PM, Ryan Trinkle 
> > 
> > wrote:
> > >> On a somewhat related note, is there any way to see the exact
> > >> configuration.nix for a particular generation?  It would be great to be
> > 
> > able
> > 
> > >> to diff generations against each other (e.g.: to figure out whether a
> > >> channel update caused a problem or whether it was my own change).
> > >
> > >You are not the first one to request this feature.
> > >They are a few issues in the way, but I will open an issue and do it
> > >as soon as I am done with the httpd rewrite.
> > 
> > In the meantime just adding /etc/ entry that is a copy of
> > /etc/nixos/configuration.nix should work…

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Gratuitous generations

2015-03-30 Thread Ryan Trinkle
Ah, great point!  This line worked perfectly for me:

environment.etc."nixos/current/configuration.nix".text = builtins.readFile
./configuration.nix;


On Mon, Mar 30, 2015 at 4:10 PM, Michael Raskin <7c6f4...@mail.ru> wrote:

> >On Mon, Mar 30, 2015 at 9:47 PM, Ryan Trinkle 
> wrote:
> >> On a somewhat related note, is there any way to see the exact
> >> configuration.nix for a particular generation?  It would be great to be
> able
> >> to diff generations against each other (e.g.: to figure out whether a
> >> channel update caused a problem or whether it was my own change).
> >
> >You are not the first one to request this feature.
> >They are a few issues in the way, but I will open an issue and do it
> >as soon as I am done with the httpd rewrite.
>
> In the meantime just adding /etc/ entry that is a copy of
> /etc/nixos/configuration.nix should work…
>
>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Gratuitous generations

2015-03-30 Thread Michael Raskin
>On Mon, Mar 30, 2015 at 9:47 PM, Ryan Trinkle  wrote:
>> On a somewhat related note, is there any way to see the exact
>> configuration.nix for a particular generation?  It would be great to be able
>> to diff generations against each other (e.g.: to figure out whether a
>> channel update caused a problem or whether it was my own change).
>
>You are not the first one to request this feature.
>They are a few issues in the way, but I will open an issue and do it
>as soon as I am done with the httpd rewrite.

In the meantime just adding /etc/ entry that is a copy of 
/etc/nixos/configuration.nix should work…



___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Gratuitous generations

2015-03-30 Thread Ryan Trinkle
That sounds awesome; thanks!

On Mon, Mar 30, 2015 at 3:51 PM, Nicolas Pierron <
nicolas.b.pier...@gmail.com> wrote:

> Hi Ryan,
>
> On Mon, Mar 30, 2015 at 9:47 PM, Ryan Trinkle 
> wrote:
> > On a somewhat related note, is there any way to see the exact
> > configuration.nix for a particular generation?  It would be great to be
> able
> > to diff generations against each other (e.g.: to figure out whether a
> > channel update caused a problem or whether it was my own change).
>
> You are not the first one to request this feature.
> They are a few issues in the way, but I will open an issue and do it
> as soon as I am done with the httpd rewrite.
>
> --
> Nicolas Pierron
> http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Gratuitous generations

2015-03-30 Thread Nicolas Pierron
Hi Ryan,

On Mon, Mar 30, 2015 at 9:47 PM, Ryan Trinkle  wrote:
> On a somewhat related note, is there any way to see the exact
> configuration.nix for a particular generation?  It would be great to be able
> to diff generations against each other (e.g.: to figure out whether a
> channel update caused a problem or whether it was my own change).

You are not the first one to request this feature.
They are a few issues in the way, but I will open an issue and do it
as soon as I am done with the httpd rewrite.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Gratuitous generations

2015-03-30 Thread Ryan Trinkle
On a somewhat related note, is there any way to see the exact
configuration.nix for a particular generation?  It would be great to be
able to diff generations against each other (e.g.: to figure out whether a
channel update caused a problem or whether it was my own change).


Ryan

On Mon, Mar 30, 2015 at 1:32 PM, Christian Theune 
wrote:

> Hi,
>
> > On 30 Mar 2015, at 15:07, Eelco Dolstra 
> wrote:
> >
> > The reason is to ensure that "nixos-rebuild switch; nixos-rebuild
> rollback"
> > always rolls back to the configuration just before the switch, not to
> some
> > earlier configuration. If "nixos-rebuild switch" is a logical no-op,
> then the
> > rollback should do nothing, too.
> >
> > Note that generations are cheap (they're just symlinks), but we should
> probably
> > filter redundant generations from the GRUB boot menu.
>
> Thanks for the explanation: that was exactly one of the things I noticed
> getting polluted. So, I understand that generations are cheap as technical
> resources but as we’ve seen they may have some mental over head in some
> places. Especially if you can’t see that they changed something - listings
> then quickly become meaningless if you’re trying to build a convergent
> system that wants to consider rebuilds to be not only cheap when nothing
> happens but abundant and with no ill effects to the user. :)
>
> My personal choice would also be that listing generations would show me
> those that actually changed something.
>
> > We could add an option to suppress creating a new generation if nothing
> has changed.
>
> Sounds like an idea to start working on this. If your main concern is to
> avoid accidentally breaking the switch/rollback semantics while providing
> this then maybe at some point the option could be dropped.
>
> Mulling over this: I’m not sure what the clear expectation is on the
> switch/rollback scenario when nothing is changing. Knowing that rolback
> always gets me to the point prior to the last switch (independently whether
> something was changed or not) is a simple rule (which is good). I can also
> see that rollback fixes the last change. This would require users to
> understand when a rebuild introduced a change or not. This would require an
> additional concept to be present, the overhead of that is currently unclear
> to me.
>
> Time for experimentation, I think. :)
>
> As I’m just getting warm with the code base: would you care to give me a
> pointer where I should start staring at some code that this option would be
> relevant at?
>
> Another thought how this could be approached: let rebuild create new
> generations, but offer a cleaning tool that cleans up generations that
> didn’t do anything. However, that would likely require keeping the original
> version and maybe the newest that is a clone (to avoid active system
> breakage). I think I’d personally prefer avoiding to generate superfluous
> generations.
>
> Cheers,
> Christian
>
> —
> Christian Theune · c...@flyingcircus.io · +49 345 219401 0
> Flying Circus Internet Operations GmbH · http://flyingcircus.io
> Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
> HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian.
> Zagrodnick
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Gratuitous generations

2015-03-30 Thread Christian Theune
Hi,

> On 30 Mar 2015, at 15:07, Eelco Dolstra  wrote:
> 
> The reason is to ensure that "nixos-rebuild switch; nixos-rebuild rollback"
> always rolls back to the configuration just before the switch, not to some
> earlier configuration. If "nixos-rebuild switch" is a logical no-op, then the
> rollback should do nothing, too.
> 
> Note that generations are cheap (they're just symlinks), but we should 
> probably
> filter redundant generations from the GRUB boot menu.

Thanks for the explanation: that was exactly one of the things I noticed 
getting polluted. So, I understand that generations are cheap as technical 
resources but as we’ve seen they may have some mental over head in some places. 
Especially if you can’t see that they changed something - listings then quickly 
become meaningless if you’re trying to build a convergent system that wants to 
consider rebuilds to be not only cheap when nothing happens but abundant and 
with no ill effects to the user. :)

My personal choice would also be that listing generations would show me those 
that actually changed something.

> We could add an option to suppress creating a new generation if nothing has 
> changed.

Sounds like an idea to start working on this. If your main concern is to avoid 
accidentally breaking the switch/rollback semantics while providing this then 
maybe at some point the option could be dropped.

Mulling over this: I’m not sure what the clear expectation is on the 
switch/rollback scenario when nothing is changing. Knowing that rolback always 
gets me to the point prior to the last switch (independently whether something 
was changed or not) is a simple rule (which is good). I can also see that 
rollback fixes the last change. This would require users to understand when a 
rebuild introduced a change or not. This would require an additional concept to 
be present, the overhead of that is currently unclear to me.

Time for experimentation, I think. :)

As I’m just getting warm with the code base: would you care to give me a 
pointer where I should start staring at some code that this option would be 
relevant at?

Another thought how this could be approached: let rebuild create new 
generations, but offer a cleaning tool that cleans up generations that didn’t 
do anything. However, that would likely require keeping the original version 
and maybe the newest that is a clone (to avoid active system breakage). I think 
I’d personally prefer avoiding to generate superfluous generations.

Cheers,
Christian

—
Christian Theune · c...@flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Gratuitous generations

2015-03-30 Thread Eelco Dolstra
Hi,

On 30/03/15 14:45, Christian Theune wrote:

> last year I experimented with self-managing NixOS installations. One thing
> that I stumbled upon was that regularly triggering nixos-rebuild would create
> new generations even though the config hadn’t changed.
> 
> Is there a way to suppress that or a reason why this can’t be suppressed in
> general?

The reason is to ensure that "nixos-rebuild switch; nixos-rebuild rollback"
always rolls back to the configuration just before the switch, not to some
earlier configuration. If "nixos-rebuild switch" is a logical no-op, then the
rollback should do nothing, too.

Note that generations are cheap (they're just symlinks), but we should probably
filter redundant generations from the GRUB boot menu.

> What I want is to create a simple cronjob that generates Nix OS configuration
> from an upstream “source of truth”, like users, and not think about
> convergence but just trigger nixos-rebuild after updating the config. If
> nothing changed then no new generation should appear IMHO.

We could add an option to suppress creating a new generation if nothing has 
changed.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev