package for Open SUSE

[johrstrom]

I'm getting asked about installing on Open SUSE. While I see that you can install RPMs on SUSE systems, I'm not sure if it's very easy to do using el distributions.

[treydock]

OpenSUSE and RHEL are not binary compatible so building OpenSUSE packages would require building OnDemand inside OpenSUSE containers. Is there a particular version of OpenSUSE people want OnDemand packages for?

[johrstrom]

@srasslan please advise - what version of OpenSUSE are you running?

[srasslan]

openSUSE Leap 15.4

[treydock]

@johrstrom @srasslan I don't think OnDemand can support Leap 15.4. It appears like the Ruby version is Ruby 2.5 which OnDemand can't support. The lowest we can support is 2.7 I believe.

[srasslan]

Hi, @treydock @johrstrom
I used snap to install ruby 3.2.2 on open suse Leap 15.4. Help the solution to install open ondemand?
https://snapcraft.io/docs/installing-snap-on-opensuse
https://www.ruby-lang.org/en/news/2018/11/08/snap/
Thanks

[johrstrom]

I used snap to install ruby 3.2.2 on open suse Leap 15.4. Help the solution to install open ondemand?

I'm not entirely sure. IDK if we should be installing/depending on snap & ruby for this platform. I wonder if we did - if that would be unexpected or what.

[dredwilliams]

If we were to install a supported version of ruby in a non-standard location, would we be able to get a packaged open ondemand deployment to recognize it and use it?

BTW -- we need to install on SLES 15.4 -- and the version of ruby currently active on the system is 2.5.9.

[johrstrom]

If we were to install a supported version of ruby in a non-standard location, would we be able to get a packaged open ondemand deployment to recognize it and use it?

I'm not entirely sure. It'd likely have to be a semi-standard location. I.e., we build a docker image with snap + ruby and you use the same location & version as us.

[treydock]

The version we build with would need to match, and generally the paths should match too. Mixing unpackaged and packaged dependencies is rarely a good idea, as we have no way to know if what we built against will work at runtime if the Ruby we build against is not the same Ruby at runtime.

If SLES has no standard way to install a newer Ruby version, then we need to package Ruby into something like a ondemand-ruby RPM. For applications with lots of dependencies, like OnDemand, it's not unheard of to bundle all the dependencies rather than relying on what the OS provides. Historically we've avoided that since what the OS provides has been good enough.

[dredwilliams]

In this environment, modifying the base OS install is something we like to avoid. Packaging it as a separate dependency as you suggested above would be a great option, as long as it could be installed without conflicting with the default installation.

[dredwilliams]

@treydock @johrstrom - Is this something that y'all are going to be working on? My project got delayed (again), but we'll probably be needing do to our install on the SLES systems in the March/April 2024 timeframe.

[johrstrom]

It sounds like we'll have to package and distribute our own Ruby. Or just hope that the right version of ruby is already installed. The latter is easier - but is it actually feasible? IDK. It sounds like we should find the feasibility of the latter (having the right ruby installed out of bounds/before OOD through snap) as a first step.

[dredwilliams]

As reluctant as HPE is to make changes to the HPC base image, I would assume that there will NOT be a newer version of ruby available -- especially in such a short time frame.

[treydock]

It's important the Ruby we build against be the same Ruby at runtime. Some gems are compiled and link to shared libraries so that would need to match and worst case is some things compile with RPATH and in that case the linked libraries paths would have to match.

I think OnDemand will need to start packaging our own version of Ruby along with some other major dependencies like NodeJS. As we support more and more distributions this will become more important, but it's a pretty major undertaking and puts more security patching responsibility on OSC so we have to weigh if that added responsibility is worth it.

[dredwilliams]

Just checking in -- have y'all decided to prepare a SLES compatible package?

[treydock]

I think our goal is to support SLES just not sure if it will make it into 3.1 on initial release but might make it sometime into 3.1.x. To do SLES support correctly we will likely need to provide dependencies like Ruby and NodeJS which is a major shift from how we've handled dependencies in the past. We've historically relied on the OS to provide things like Ruby but providing the dependencies ourselves likely will be good long term as we can support more operating systems even if that OS doesn't necessarily have the correct version of things like Ruby.

[johrstrom]

Yea with 3.1 just around the corner I don't think it'll make it into that release.

To do SLES support correctly we will likely need to provide dependencies like Ruby and NodeJS which is a major shift from how we've handled dependencies in the past.

Do you think we'll provide ruby & node for all distros or just SLES?

[treydock]

Do you think we'll provide ruby & node for all distros or just SLES?

I think we'll start with SLES, and see how that goes and then for like OnDemand 3.2 we'd move to this method for all OSes. This is why I think it might make it into 3.1.x (just not 3.1.0) since it shouldn't affect existing distributions we support.

[dredwilliams]

@treydock @johrstrom - what would the timing look like (approximately, of course) for having a SLES package available? I'm trying to work out the schedule for our project ...

[treydock]

what would the timing look like (approximately, of course) for having a SLES package available? I'm trying to work out the schedule for our project ...

I'm not sure I can give an estimate at this time. OSC is in the process of some major projects that require much of our attention. The complication with time is the fact we'd have to start building Ruby rather than relying on the OS version. Normally adding a new OS would only take a few days. Another complication is figuring out how to generate and serve up repos from our RHEL8 repo host that are seen as valid for SLES.

[heasterday]

Hey OOD folks! My organization, HPC at LANL, is interested in SLES packages for OOD and how we can support this effort. Who is a good person to email to start this discussion?

[johrstrom]

Hey OOD folks! My organization, HPC at LANL, is interested in SLES packages for OOD and how we can support this effort. Who is a good person to email to start this discussion?

Why use email? You can discuss here. This is the repository that would build & package it. I.e., this is the repository that would need modifications.

[heasterday]

Hey OOD folks! My organization, HPC at LANL, is interested in SLES packages for OOD and how we can support this effort. Who is a good person to email to start this discussion?

Why use email? You can discuss here. This is the repository that would build & package it. I.e., this is the repository that would need modifications.

Sorry to be difficult but I would prefer to start with email just while discussing any particular aspects of the support my organization may be able to offer. My hope would be to transition to an open forum like this at a later date.

[johrstrom]

Sorry to be difficult but I would prefer to start with email

OK I guess, you can drop me a line at johrstrom@osc.edu and I'll add anyone else.

while discussing any particular aspects of the support my organization may be able to offer.

I'm not sure what's there to discuss. I will take whatever you have to offer and cannot demand anything from you. I'll happily respond to your email, but if you're eluding to, say, ongoing support for this if you added it, that's entirely up to you. Again, I cannot make demands or terms and conditions on contributors, nor would I want to!

So for example, if you had something for this today that I then merged - by my act of merging it I'm taking responsibility for it as a maintainer. That is, contributions come in, but it's on the maintainers shoulders to then keep it afloat once it's merged. Of course, we'd be happy for any support one way or another, but that's not required or even expected really. Once the code is here, it's our responsibility to keep it going.

Hope that is helpful and not going to discourage you from contributing!