Is there a plan to yum package Atlassian products

[Vas Banagala]

At present upgrade of all Atlassian products on Linux are frught with danger. The reason I say this becuase a lot of files need to be backed upbefore upgrade and copy over after upgrade. There is better ways to do things now like yum package for RHEL, which will not overwrite cutoem files during upgrade. Creating a yum package is not difficult.

[Nic Brough -Adaptavist-]

There are some places that do this, but Atlassian do not, and have no plans to.  They are deliberately keeping the distributions and installs as simple and cross-platform as possible.

As I remember discussing quite recently, I'm afraid "will not overwrite custom files during upgrade" is wrong. 

In most cases, a yum (or deb, or pacman, or zyp, or, or) package would have to be configured to continue to overwrite them, because it would have no choice - it's a vast amount of work to write a system that could read your version and merge in with the changes to the distributed file that the new package needs to put into it.    Next best solution - overwrite the custom files and warn you.

Classic example - two weeks ago I did an upgrade.  The shape of two of the packaged files changed.  The changes I had in my local files needed to be read, fully understood and then applied back into the new versions in a very different way.

[Vas Banagala]

I am disappointed with this decision after seeing a lot of good that has come from Atlassian. The objective should not be just simplicity. The objective should be take the pain out of Systems Administration and reduce risk in installs and updates. For example how good is those other systems we administer to see

install - rpm -i    xxxxxxxx.rpm

upgrade rpm -U  xxxxxxx.rpm and not worry about overwriting custome files.

I dont want to be in a situation of "Next best solution - overwrite the custom files and warn you" which is an ancient technique as muh as zip files are.

Dont undertand what you mean by "Classic example - two weeks ago I did an upgrade. The shape of two of the packaged files changed. The changes I had in my local files needed to be read, fully understood and then applied back into the new versions in a very different way."

I also dont understans why this should not be a consideration moving forward. I value professionalism.

[Nic Brough -Adaptavist-]

I would love to be able to do "apt/rpm/apk/whatever upgrade" and have my systems bump themselves up to the latest version without me having to think.

But. It does not work (yet)

You don't want to be in a situation of "overwrite and warn".  No-one does.  But the current is alternative is "accept current change and completely fail without even any warning".

Which is better?  Something that works but not right, or something that fails miserably and could stuff up everything horribly?

In my example, we recognised that "overwrite and warn" told us that we needed to prepare to adopt the changes.

That's the value of professionalism - my colleague recognised that blind ignorance of local configuration that the installers could not possibly know had been done, meant it would not work.  A package would have left them with a week's worth of damage control.  The fact I have time to post here means that one of my colleagues did the upgrade and did not have to do that damage control.

[Vas Banagala]

Which is better? Something that works but not right, or something that fails miserably and could stuff up everything horribly? --> I understand the current is where things are at and it works with a hevay workload and risk for the Administrator.

It doesnt work, it has to be made towork with backing up a lot of files. I t is better which is agreed. It is not the best.

I have compared with other software vendors which allo us to update without hassel and I love rpm -U and that definitely works too.

With this other system I am not at "blind ignorance of local configuration". When I list files and see

/../../default and default.rpmnew

or

X.system.properties and X.system.properties.rpmnew

I know which files have been customised.

Trust me I have Adminsterd Atlassian and othe camps. Professionalism to me is willingness to improve.

If you are upgrading Crowd, Jira, Confluence and Bitbucket and maintain QA and PROD can you imagine the workload?

[Vas Banagala]

Sorry I forgot to mention that when we are running DC you can convienently multiply the number of nodes to upgrade by about factor of 3.

2 (

[Vas Banagala]

2 (QA and PROD) * 3 (3 NODES PER CLUSTER) * 4 applications = 24 upgrades.

[Nic Brough -Adaptavist-]

I think you are misunderstanding most of what I am saying here.

My team currently spends 40% of its time overseeing or performing upgrades of systems (not just Atlassian ones).

Rpm/Apt/Pacman/Zyp/Dmg/all-the-others - these are great for client and end-user systems.  I'd love to have them work server-side, but they simply can't (unless everyone decides the defaults work for them universally, which they never will)

An off-the-shelf packaging system absolutely has to have "blind ignorance of local configuration".

You say "Trust me I have Adminsterd Atlassian and othe camps. Professionalism to me is willingness to improve."

I'm 100% with you with the second sentence.  But you need to learn that some of the parts of "Professionalism" means "understanding the software you are working with" and "no two clients have exactly the same needs, so a same-for-everyone package cannot work"

>If you are upgrading Crowd, Jira, Confluence and Bitbucket and maintain QA and PROD can you imagine the workload?

Yes.  Did that two weeks ago.  For a LOT more systems.  Took 2 hours.   If I had been able to do "yum upgrade X" on every system, it would have taken us another 16 hours to patch up all the things a package manager could not have dealt with.

I appreciate that you'd like to simplify, but in the real world, for complex software, you can't do it.

[Nic Brough -Adaptavist-]

Oh, and if you're worrying about DC nodes, you can't.  Blindly using packages that don't fully understand the configuration will break instantly.

DC  enables upgrades to be done without affecting other nodes.  Package managers don't understand how to handle clustered nodes, or merge config, so they fail instantly in most cases.  Try again.

[Vas Banagala]

What do you mean by "If I had been able to do "yum upgrade X" on every system, it would have taken us another 16 hours to patch up all the things a package manager could not have dealt with".

What are these things?

[Vas Banagala]

My observation is exactly opposite yours. When we upgrade using rpm package it takes 10 minutes. With zip files it takes about 2 hours

[Vas Banagala]

What is diffent in Jira for example from other web applications that does not yield to rpm package?

[Nic Brough -Adaptavist-]

Nothing.  But other web applications have the same problem.  You can do a yum install, but it's going to overwrite all the config files you need to change to get them running when it needs to.  So why bother?  You're going to have to do all the changes again anyway.

[Vas Banagala]

Thanks Nic. I understand where we are at the moment.