This week there were a number of updates released (see the newsletter). This comment came back from Brian Sletten...
It deserved a complete answer, and may be of general interest, so here''s my reply...
Sorry for the pain. Here''s the back story.
In one line - we''re still working out the best production processes with the repository model.
My intention was that when we shipped 4.0.0 it would be around for 6 months with all updates going in the 1060-NetKernel-SE/4.0.0/ repository branch. So during this first 6 months I planned to work through any user-side issues with the Apposite client (like the lack of support for "select all updates") and, most importantly, put in place a distro-upgrade feature.
To upgrade the distro needs a few things. First a repository resource pointing to the new distro repository branch, second PKI signing/verification that the upgrade is legitimate (without a lot of care this could be a very bad security hole), third apposite-client needs to look for the upgrade flag, verify it and present a stateful option to the user to choose to upgrade. Finally when user chooses to upgrade, it needs to do a repo reconciliation, upgrade old stuff and install any new stuff that is now part of the distro.
All of this is not so difficult - it just needs some tweaks to the model, our repository master builder application and the apposite client. All of which have to be synchronized and then tested in a dummy repo before going to production with it. (Testing this stuff is actually hard since there are so many variables and you need try out lots of scenarios). But we didn''t want to rush a distro upgrade feature out without first getting real world knowledge of the production use of the repository with the 4.0.0 distro.
That was the plan. Unfortunately, we realised with work on new tools and extra enterprise features, that we had to update the boot infrastructure - even down as low as the shell scripts. So we put out the 4.0.1 build - which provides a "boot root" that is good for the long-term.
So we put out the 4.0.1 distro, which for the necessity of consistency points to the 1060-NetKernel-SE/4.0.1/ repository branch.
Since then, all package updates have been targeted at the 4.0.1 repository branch. This is both a consistency/stability requirement (we know that updates will be stable as a whole), but also the process of
managing two independent releases is too expensive and error prone (you can only automate so far, knowledge of what has to be released where requires a human editorial role).
I should have explained this more clearly in the newsletters!
The relationship between an NK instance and the set of possible repos it can use is quite powerful but it needs some more explanation - I''m planning to do some screencasts to show how it works in production and to reveal a new tool "ARP - Apposite Repository Publisher" - which is an end-user package manager and repository builder application.
In production the end-to-end apposite tool chain is working really well for us - we can release a new package, publish to a repository and get it onto a production server in about 2 minutes.
Sorry for the inconvenience - bear with us.
P.
PS The other tip here is that its always a good idea to install an apposite update first - since its getting smoother and more convenient with each release (I hope!)
PPS Since the modules and address spaces of NK are so malleable - you can actually do a distro "update" by hand: simply change the repository branch from 4.0.0 to 4.0.1, sync and select all updates (I''ve done this on a couple of servers). The only real issue is that you''ll be on the old boot infrastructure and may not get all new modules, since in 4.0.1 they are core and not marked as updates.
|
Ok, I was going to try that but didn''t think I should have to. Am I doing something wrong? Why does this distro/path not
get updated?
|
It deserved a complete answer, and may be of general interest, so here''s my reply...
Sorry for the pain. Here''s the back story.
In one line - we''re still working out the best production processes with the repository model.
My intention was that when we shipped 4.0.0 it would be around for 6 months with all updates going in the 1060-NetKernel-SE/4.0.0/ repository branch. So during this first 6 months I planned to work through any user-side issues with the Apposite client (like the lack of support for "select all updates") and, most importantly, put in place a distro-upgrade feature.
To upgrade the distro needs a few things. First a repository resource pointing to the new distro repository branch, second PKI signing/verification that the upgrade is legitimate (without a lot of care this could be a very bad security hole), third apposite-client needs to look for the upgrade flag, verify it and present a stateful option to the user to choose to upgrade. Finally when user chooses to upgrade, it needs to do a repo reconciliation, upgrade old stuff and install any new stuff that is now part of the distro.
All of this is not so difficult - it just needs some tweaks to the model, our repository master builder application and the apposite client. All of which have to be synchronized and then tested in a dummy repo before going to production with it. (Testing this stuff is actually hard since there are so many variables and you need try out lots of scenarios). But we didn''t want to rush a distro upgrade feature out without first getting real world knowledge of the production use of the repository with the 4.0.0 distro.
That was the plan. Unfortunately, we realised with work on new tools and extra enterprise features, that we had to update the boot infrastructure - even down as low as the shell scripts. So we put out the 4.0.1 build - which provides a "boot root" that is good for the long-term.
So we put out the 4.0.1 distro, which for the necessity of consistency points to the 1060-NetKernel-SE/4.0.1/ repository branch.
Since then, all package updates have been targeted at the 4.0.1 repository branch. This is both a consistency/stability requirement (we know that updates will be stable as a whole), but also the process of
managing two independent releases is too expensive and error prone (you can only automate so far, knowledge of what has to be released where requires a human editorial role).
I should have explained this more clearly in the newsletters!
The relationship between an NK instance and the set of possible repos it can use is quite powerful but it needs some more explanation - I''m planning to do some screencasts to show how it works in production and to reveal a new tool "ARP - Apposite Repository Publisher" - which is an end-user package manager and repository builder application.
In production the end-to-end apposite tool chain is working really well for us - we can release a new package, publish to a repository and get it onto a production server in about 2 minutes.
Sorry for the inconvenience - bear with us.
P.
PS The other tip here is that its always a good idea to install an apposite update first - since its getting smoother and more convenient with each release (I hope!)
PPS Since the modules and address spaces of NK are so malleable - you can actually do a distro "update" by hand: simply change the repository branch from 4.0.0 to 4.0.1, sync and select all updates (I''ve done this on a couple of servers). The only real issue is that you''ll be on the old boot infrastructure and may not get all new modules, since in 4.0.1 they are core and not marked as updates.
