Deleted build history after downgrade to LTS

[corneil....@gmail.com]

We decided to move onto LTS after some of the recent instability.

We were on 1.599 and moved to 1.596.1

We stopped Jenkins, deleted the files in JENKINS_HOME/updates and replaced the war.

When Jenkins came up again all the build history was missing. The build directories are all empty.

None of the documentation I read about moving to LTS indicated that this may happen.

I would expect that system to preserve build history and report the fact that it has problems reading the files rather than just deleting it.

Is this expected behaviour?

Regards

Corneil

[Baptiste Mathus]

https://wiki.jenkins-ci.org/display/JENKINS/JENKINS-24380+Migration

Cheers

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CACPng9aOB0aTkobfZ1SJiqj%2B%2BanY4kvSd%3DnkBH%3DpZq7DsyLTuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[corneil....@gmail.com]

I would suggest adding this link to the LTS page.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CANWgJS5ESrzxHy8WOeLKXY%3Di3iNJ9yiWfgLq72r8DS85QdGc0A%40mail.gmail.com.

[Daniel Beck]

On 09.03.2015, at 08:54, corneil....@gmail.com wrote:

> I would suggest adding this link to the LTS page.

This has nothing to do with the LTS release line.

[Les Mikesell]

It is something I'd want to know if I were considering installing the
latest LTS release with the idea that it would have fewer
regressions,..

--
Les Mikesell
lesmi...@gmail.com

[Daniel Beck]

On 09.03.2015, at 16:26, Les Mikesell <lesmi...@gmail.com> wrote:

> It is something I'd want to know if I were considering installing the
> latest LTS release with the idea that it would have fewer
> regressions,..

The problem was that he _downgraded_ from latest weekly to latest LTS. LTS does not yet contain this change, and besides that, _upgrading_ worked.

[Les Mikesell]

On Mon, Mar 9, 2015 at 10:58 AM, Daniel Beck <m...@beckweb.net> wrote:
>
>> It is something I'd want to know if I were considering installing the
>> latest LTS release with the idea that it would have fewer
>> regressions,..
>
> The problem was that he _downgraded_ from latest weekly to latest LTS. LTS does not yet contain this change, and besides that, _upgrading_ worked.
>

Yes, exactly. Would you not want to know that before installing the
latest LTS which is known to cause this issue? In fact it seems
somewhat odd to introduce this scenario without considering the effect
on people switch to LTS - which I'd expect to be a likely situation.

--
Les Mikesell
lesmi...@gmail.com

[Baptiste Mathus]

I tend to disagree. People using LTS are somehow conservative and would be at risk to get confused: "so, in the end, is that LTS safe, or is it going to screw up my data?". 

We could indeed add information in the LTS changelog that is going to change *in the future*, but I personally think it's just better to leave it clean for non-advanced user.

If you install bleeding edge version, better read the changelog in general. And if you don't and it crashes, then read the changelog. 

In this case, it was not a lot of versions of difference so not even much to read.

What I agree on, though, is that we may want to add some kind of disclaimer in the main changelog, and on the download link (latest and greatest one) to warn users that it may be (very) unstable and depending on their situation they may prefer trying LTS.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAOAgVpz4sFUz4Bx40FdGGEW75DOCUEF7eGtyN%3D%3D5C-Zzj9UxUg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[Les Mikesell]

On Mon, Mar 9, 2015 at 11:53 AM, Baptiste Mathus <bma...@batmat.net> wrote:
> I tend to disagree. People using LTS are somehow conservative and would be
> at risk to get confused: "so, in the end, is that LTS safe, or is it going
> to screw up my data?".

Yes, when you know that LTS is going to screw up data, it only seems
reasonable to post it in a visible place.

> We could indeed add information in the LTS changelog that is going to change
> *in the future*, but I personally think it's just better to leave it clean
> for non-advanced user.

I thought the point of even having LTS was to be able to avoid known
issues to the extent possible. So when an issue affecting it becomes
known, the ideal thing would be to _fix_ the by-then-known problem,
but if that is too much to ask, warning about it would seem
appropriate.

> If you install bleeding edge version, better read the changelog in general.
> And if you don't and it crashes, then read the changelog.
> In this case, it was not a lot of versions of difference so not even much to
> read.

But when you want to get away from the crashes of the bleeding edge
version and back off to LTS in hopes of doing better you probably
won't be happy when it eats your existing data...

> What I agree on, though, is that we may want to add some kind of disclaimer
> in the main changelog, and on the download link (latest and greatest one) to
> warn users that it may be (very) unstable and depending on their situation
> they may prefer trying LTS.

There is an issue in general with breaking changes in stored data
formats and one-way migration. And this is hardly a unique case.
Switching to LTS is a likely, but not the only thing that may make you
need to go backwards. It would be nicer if such breaking changes had
a way to convert back - or at least there was a 'big-picture' of what
versions (including plugins) could deal with the storage formats of
what other versions. For example, installing the latest svn plugin
broke all of my stored credentials and I had to back the plugin out
and restore the credential files from a backup. Where can I look to
know what to expect in situations like that?

--
Les Mikesell
lesmi...@gmail.com

[Baptiste Mathus]

Le 9 mars 2015 18:22, "Les Mikesell" <lesmi...@gmail.com> a écrit :
>
> On Mon, Mar 9, 2015 at 11:53 AM, Baptiste Mathus <bma...@batmat.net> wrote:
> > I tend to disagree. People using LTS are somehow conservative and would be
> > at risk to get confused: "so, in the end, is that LTS safe, or is it going
> > to screw up my data?".
>
> Yes, when you know that LTS is going to screw up data, it only seems
> reasonable to post it in a visible place.

Ahem. That's the point here. The LTS is not concerned by that change...

>
> > We could indeed add information in the LTS changelog that is going to change
> > *in the future*, but I personally think it's just better to leave it clean
> > for non-advanced user.
>
> I thought the point of even having LTS was to be able to avoid known
> issues to the extent possible. So when an issue affecting it becomes
> known, the ideal thing would be to _fix_ the by-then-known problem,
> but if that is too much to ask, warning about it would seem
> appropriate.

See above.

>
> > If you install bleeding edge version, better read the changelog in general.
> > And if you don't and it crashes, then read the changelog.
> > In this case, it was not a lot of versions of difference so not even much to
> > read.
>
> But when you want to get away from the crashes of the bleeding edge
> version and back off to LTS in hopes of doing better you probably
> won't be happy when it eats your existing data...
>
> > What I agree on, though, is that we may want to add some kind of disclaimer
> > in the main changelog, and on the download link (latest and greatest one) to
> > warn users that it may be (very) unstable and depending on their situation
> > they may prefer trying LTS.
>
> There is an issue in general with breaking changes in stored data
> formats and one-way migration.  And this is hardly a unique case.
> Switching to LTS is a likely, but not the only thing that may make you
> need to go backwards.  It would be nicer if such breaking changes had
> a way to convert back - or at least there

There is. Read the link, did you?

> was a 'big-picture' of what
> versions (including plugins) could deal with the storage formats of
> what other versions.  For example, installing the latest svn plugin
> broke all of my stored credentials and I had to back the plugin out
> and restore the credential files from a backup.   Where can I look to
> know what to expect in situations like that?

https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin in this case, in general. Then depends on your very issue.

Cheers

>
> --
>    Les Mikesell
>      lesmi...@gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAOAgVpysu6H2aJHohXud4YqDKWqAiQbpSm%2B9TO4mGXXApTPoCQ%40mail.gmail.com.

[Daniel Beck]

On 09.03.2015, at 18:22, Les Mikesell <lesmi...@gmail.com> wrote:

> Yes, when you know that LTS is going to screw up data, it only seems
> reasonable to post it in a visible place.

The data was "screwed up" by the regular weekly release, and that was mentioned:

- On the /manage page after the upgrade
- In the changelog, in bold
- In the Jenkins log

Complete with instructions how to revert it.

> So when an issue affecting it becomes
> known, the ideal thing would be to _fix_ the by-then-known problem,
> but if that is too much to ask, warning about it would seem
> appropriate.

There is no "issue affecting it". Again: You get the documentation on the backwards-compatibility-breaking change to build layout when you upgrade. It's not like there's a path to get into this situation where you're never shown any information about this change. It's shown earlier than relevant in this case, but if you ever read it, you'll understand that downgrading is more effort than usual.

I think the basic misunderstanding is that think you can move from any Jenkins version to any other Jenkins version at will, when only upgrades to higher base versions are effectively supported. At least that's what I gather from:

> Yes, exactly. Would you not want to know that before installing the
> latest LTS which is known to cause this issue? In fact it seems
> somewhat odd to introduce this scenario without considering the effect
> on people switch to LTS - which I'd expect to be a likely situation.

Here's the generally supported upgrade paths:
Jenkins 1.XXX -> Jenkins 1.YYY (YYY > XXX): OK!
Jenkins 1.XXX -> Jenkins 1.YYY.z (YYY > XXX): OK!
Jenkins 1.XXX.w -> Jenkins 1.YYY.z (YYY > XXX): OK!
Jenkins 1.XXX -> Jenkins 1.XXX.y: OK!

Going from LTS to a (much) more recent weekly generally works as well, but there may be exceptions.

Downgrading often comes with data loss or other incompatibilities (e.g. detached plugins that won't work with the downgraded core), so I don't think this is supported. Couldn't find any reference on it though.

[Les Mikesell]

On Mon, Mar 9, 2015 at 1:41 PM, Daniel Beck <m...@beckweb.net> wrote:
>>
>> So when an issue affecting it becomes
>> known, the ideal thing would be to _fix_ the by-then-known problem,
>> but if that is too much to ask, warning about it would seem
>> appropriate.
>
> There is no "issue affecting it". Again: You get the documentation on the backwards-compatibility-breaking change to build layout when you upgrade. It's not like there's a path to get into this situation where you're never shown any information about this change.

Apparently that wasn't the case for the original poster here.

> It's shown earlier than relevant in this case, but if you ever read it, you'll understand that downgrading is more effort than usual.

So, shouldn't that be pointed out on the LTS page since someone
starting there would very likely be downgrading? Perhaps something
to discourage installation until the version there advances past
whatever it is you are currently running?

--
Les Mikesell
lesmikesell@gmail,com

[Daniel Beck]

On 09.03.2015, at 19:57, Les Mikesell <lesmi...@gmail.com> wrote:

>> There is no "issue affecting it". Again: You get the documentation on the backwards-compatibility-breaking change to build layout when you upgrade. It's not like there's a path to get into this situation where you're never shown any information about this change.
>
> Apparently that wasn't the case for the original poster here.

Well, yes, there's little that can be done when users _choose_ not to read the changelog, or the warnings shown when Jenkins start up.

Or are you asking for the upgrade process to be made more cumbersome by e.g. having to click through the web site?

>> It's shown earlier than relevant in this case, but if you ever read it, you'll understand that downgrading is more effort than usual.
>
> So, shouldn't that be pointed out on the LTS page since someone
> starting there would very likely be downgrading?

I already addressed that downgrading in not supported (the part of your email you didn't quote and respond to), so what should the changelog point out? "Don't downgrade to this LTS release from any version newer than 1.596"?

[Les Mikesell]

On Mon, Mar 9, 2015 at 2:17 PM, Daniel Beck <m...@beckweb.net> wrote:
>
>>> There is no "issue affecting it". Again: You get the documentation on the backwards-compatibility-breaking change to build layout when you upgrade. It's not like there's a path to get into this situation where you're never shown any information about this change.
>>
>> Apparently that wasn't the case for the original poster here.
>
> Well, yes, there's little that can be done when users _choose_ not to read the changelog, or the warnings shown when Jenkins start up.
>

What warnings would you see if installed 1.599 as your first version -
and why would you be concerned about its changelog? And subsequently
after running it, you decide it is too unstable and you need the LTS
version.

> Or are you asking for the upgrade process to be made more cumbersome by e.g. having to click through the web site?

Is LTS an upgrade or not? I think of it that way, but developers
probably do not. But in any case, users should be warned before they
even _think_ about installing a version that will cause pain if they
need to back out the change.

>>> It's shown earlier than relevant in this case, but if you ever read it, you'll understand that downgrading is more effort than usual.
>>
>> So, shouldn't that be pointed out on the LTS page since someone
>> starting there would very likely be downgrading?
>
> I already addressed that downgrading in not supported (the part of your email you didn't quote and respond to), so what should the changelog point out? "Don't downgrade to this LTS release from any version newer than 1.596"?

Is installing the latest available release of LTS a downgrade? But
yes, you should absolutely say on the main LTS page not to install it
as a downgrade from an existing non-LTS version until the LTS release
version number at least matches what you are currently running. I'm
pretty sure that's the way I did it, but I understood the situation
from being on the mail list for some time seeing the version-related
issues people have with jenkins. The point of having an LTS version
should be to help users avoid problems and if it is too much to ask to
explicitly list the known/breaking changes that installing LTS will
trip over, then at least a generic warning should be in order.

--
Les Mikesell
lesmi...@gmail.com

[Daniel Beck]

On 10.03.2015, at 16:27, Les Mikesell <lesmi...@gmail.com> wrote:

> What warnings would you see if installed 1.599 as your first version -
> and why would you be concerned about its changelog? And subsequently
> after running it, you decide it is too unstable and you need the LTS
> version.

True. That's effectively a downgrade to 'older but stable' without seeing the warning.

FWIW I think the web site should be redesigned to make the LTS choice more accessible. For many users, it's the better choice.

> Is LTS an upgrade or not?

It's not. It's a different release line and should probably be called 'cross-grade', but if the choice is up/down, check the three digit part of the version number, and from 599 to 596, it's down.

> Is installing the latest available release of LTS a downgrade? But
> yes, you should absolutely say on the main LTS page not to install it
> as a downgrade from an existing non-LTS version until the LTS release
> version number at least matches what you are currently running. I'm
> pretty sure that's the way I did it, but I understood the situation
> from being on the mail list for some time seeing the version-related
> issues people have with jenkins. The point of having an LTS version
> should be to help users avoid problems and if it is too much to ask to
> explicitly list the known/breaking changes that installing LTS will
> trip over, then at least a generic warning should be in order.

Currently the Jenkins web site does not really help users choose one of the release lines. This should be changed IMO. Information on how to (not) change between these lines would then be a helpful addition.

[Les Mikesell]

On Tue, Mar 10, 2015 at 12:12 PM, Daniel Beck <m...@beckweb.net> wrote:
>
>
> Currently the Jenkins web site does not really help users choose one of the release lines. This should be changed IMO. Information on how to (not) change between these lines would then be a helpful addition.
>

Another somewhat related issue is that most problems that show up on
the mail list relate to the bleeding-edge version so the discussions
of workarounds aren't current when the same change is released in LTS
much later. At which point the answers to new questions tend to be
curt links to issue pages and "well you should have known that...".

--
Les Mikesell
lesmi...@gmail.com