Error Rock-ons Dont work

[phillxnet (Philip Guyton)]

@scrosler Hello again.
Re:

@scrosler

It appears you left something out, I think? See here:

Yes, indeed. Our 15.3 work is far newer given we have now released rpms for 15.1 & 15.2 for their entire supported cycle, come November. And have yet to finalise our ‘focus’ to the 15.3 variant. We have a pending issue in that repo to ‘up’ the Readme thus:

https://github.com/rockstor/rockstor-installer/issues/81

Which would be a good opportunity to move the example commands along some. We actually started the transition on Leap 15.0 !!

@scrosler

However when installing and getting to the “Edit rockstor.kiwi” you only have a command for 15.2, not 15.3.

You can get away with zero edits to the rockstor.kiwi. Nice if you do as you get a nicely named installer file but it’s not required. I recently clarified this in the Readme. Just specify the 15.3 profile instead of the 15.2 and ideally use a Leap 15.3 host to do the build on. But again a Leap 15.2 install will currently happily create a 15.3 profile.

@scrosler

just forget that section when they last updated for 15.3?

Not forgotten just awaiting the contribution / time for the doc/Readme changes. All in good time.

@scrosler

I assume I can download a 15.2 ISO, but using the logic of this thread uses … it seems it would be useless to even install on 15.2?

There are no official public downloads as of yet (but soon). Hence folks using the rockstor-install repo Recipe which is the exact same way we are building our current closed beta installers for testing before we finally release pre-built installers.

@scrosler

… how Rockstor is moving forward without looking back,

I’m not sure that fair actually. We are about to provide a workaround for our 2017 installer. That’s a fairly good show I’d say. And we released updates for it 3.9.2-57 (stable channel) which was April 2020:

Release 3.9.2-57 · rockstor/rockstor-core

And only stopped when an included upstream library in CentOS became completely unworkable and broke our ability to build. And by then the “Built on openSUSE” endeavour was well underway (just as well it would seem).

@scrosler

So I am not sure if this 15.2 vs 15.3 is indeed even relevant?

Use either a 15.2 or 15.3 openSUSE Leap install to build a 15.3 profile by substituting the 15.3 profile name in the 15.2 example. That all.

@scrosler

Is it all possible to just wget the json file and place it where it needs to be for digestion or does it not work like that.

No unfortunately. That is an ‘index’ and there is then one additional json for each Rock-on. See:

GitHub - rockstor/rockon-registry: hosted registry for Rock-ons

Note also that you can have a local repo, intended for local development but interesting never-the-less. See the readme in that repo. It’s how folks develop Rock-ons before submitting them to that repo.

@scrosler

Secondly, what line of code sends the request to rockstor.com? Could we just edit that line of code, send it to a sudo server and get it https’ed?

Just addressed by @Flox as I was typing this it seems. The venerable and all that

@scrosler

Could I do something like this here or would that be just too simple for this situtaion?

Again I think @Flox has just posted a work around here and from what I’ve seen previously of it it’s quite neat. Essentially the old CentOS patched requests just needs a leg-up. All irrelevant in v4 for now at least.

Also if you are interested in how the Rock-ons internals work see @Flox exemplary technical wiki entries here:

Rock-on framework implementation

Note: this document will be split in several posts in order to fit within characters’ limit. Make sure to browse the second post as well for more information . Preambule This is a wikified post documenting how Rockstor implements the rock-on framework, and should thus be considered a live document expected to be updated as necessary. As a user documentation already exists on how to use the framework (see link below), however, this write-up intends to first summarize the overall rock-on …

No reverse engineering necessary . Thanks again to @Flox for re-vamping and maintaining our Rock-ons and doc by the way. Also have you seen the rock-nets ?

@scrosler

I like to dig into things too!

Then you might like to take a look at our ‘workings’. All that runs on folks machines in Rockstor is open source. Again no reverse engineering necessary. Although our continued efforts and infrastructure costs dependant our our Stable release and support model. So theirs that.

@scrosler

Oh and one final suggestion. … post a script for us depending on the Leap version we are installing on. Ideally the script would be a copy and paste from the GitHub instructions

Agreed. Fancy submitting a pull request containing these scripts. But note that the actual build process is essentially a single kiwi-ng command !! And our main aim in the repo is to inform and facilitate. Those that struggle with this as-is are also those who are likely to just resource a pre-build installer. But building your own is super empowering and something I personally am really pleased we have achieved. But yes, our instructions need work However we now have 6 possible targets (2 OS * 3 machine targets (across 2 architectures)). So the script would need to account for that. But again scope for improvement as always.

Thanks for your enthusiasm and I think you will find straight forward engineering far more rewarding than the reverse kind. That way everybody wins which is key in an open source environment.

Hope that helps. And do take a look at our various code repositories. Almost all code is now black formatted (on the Python front) and fairly well documented/self documenting. We have a fair bit of technical debt but we are a small team so are always limited by people resources.