nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Comments

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

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

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.