Oolite Website Domain & Fixing the Expansions Manager

[phkb]

Ummm... old.oolite.space/admin now shows this:

I'm assuming that wasn't expected.

[phkb]

And with a little help from "Translate"...

[phkb]

The Expansion manager fails to pull down the latest catalog. And http://addons.oolite.space/api/1.0/overview redirects to the above page:

[hiran]

The Expansion manager fails to pull down the latest catalog. And http://addons.oolite.space/api/1.0/overview redirects to the above page:

Oolite-Starter is impacted the same way. This is a server side change, and I can neither tell where it came from nor how to fix it.

[hiran]

The Expansion manager fails to pull down the latest catalog. And http://addons.oolite.space/api/1.0/overview redirects to the above page:

Oolite-Starter is impacted the same way. This is a server side change, and I can neither tell where it came from nor how to fix it.

Ha, I think I got it!

Timer said his VPS would regularly copy the catalog from the old server - and if changed push it into the Github hosted oolite-web project.
But what checks were applied?

It seems the old server was deactivated, therefore the response on the web is what we see. And this has been copied into our repository...
https://github.com/OoliteProject/oolite ... index.html

The fix is to deactivate this copy method, restore the last known-good configuration and then think of an alternative of maintaining the catalog.
Timer, if you are working on some web editor for the manifests: We need the solution now...

[phkb]

It seems the old server was deactivated,

The DB is still active and working. I just logged into it to check.

[hiran]

It seems the old server was deactivated,

The DB is still active and working. I just logged into it to check.

That may be the case. But what's the value if the results don't get out because the webserver is offline?

[phkb]

That may be the case. But what's the value if the results don't get out because the webserver is offline?

True.

[hiran]

The Expansion manager fails to pull down the latest catalog. And http://addons.oolite.space/api/1.0/overview redirects to the above page:

The fix is to deactivate this copy method, restore the last known-good configuration and then think of an alternative of maintaining the catalog.
Timer, if you are working on some web editor for the manifests: We need the solution now...

So as a first measure, I configured the user that automatically updates the Github repository to Read-only.
The reason is that currently, whenever Websupport's error page changes it would overwrite whatever good or bad we have in the repository.

The next step is to reconstruct the last known-good state, then think about how we maintain that file.

At the moment we just do not have any web frontend to keep going as we used to. Any ideas how we want to publish expansions in the future?

[hiran]

The Expansion manager fails to pull down the latest catalog. And http://addons.oolite.space/api/1.0/overview redirects to the above page:

The fix is to deactivate this copy method, restore the last known-good configuration and then think of an alternative of maintaining the catalog.
Timer, if you are working on some web editor for the manifests: We need the solution now...

So as a first measure, I configured the user that automatically updates the Github repository to Read-only.
The reason is that currently, whenever Websupport's error page changes it would overwrite whatever good or bad we have in the repository.

The next step is to reconstruct the last known-good state, then think about how we maintain that file.

At the moment we just do not have any web frontend to keep going as we used to. Any ideas how we want to publish expansions in the future?

I performed the next step: bring the repository into the status of the last known-good catalog. However I am not sure by when the change will be visible to the Expansion Managers. Edit: 10 minutes later the change is visible. With that Expansion Managers can again load expansions. Nice

For all OXP authors: At the moment we do not have any web frontend to create/update manifest data. It means the catalog is frozen - nothing can be added, updated or removed. Any ideas how you want to publish expansions in the future?

[hiran]

To be a bit more clear, and maybe introduce distinct terms rather than reusing the same words over and over I created a diagram.



We all know oolite.space, the domain that hosts the website as well as the Manifest Editor and the Expansion Catalog.
From the website we all download the Oolite Game releases that we install on our local computers. When we run it, the simulator allows us to experience Ooniverse.

But when installing expansions, some expansion manager (be it in-game or the OoliteStarter) need to access the expansion catalog to know which expansions are out there ready to be installed. This catalog is the accumulated result of OXP authors adding their bits via the Manifest Editor. The red component which is currently unavailable.

Why is that an issue? In this catalog we have the expansionn name, version, description, ..., the download url. If these items cannot be updated, new expansions cannot be added to the expansion catalog. And existing expansions cannot be updated. This should be an issue to all players, but even more to OXP authors who cannot distribute their product into the broad comunity. Expansions will have to be downloaded and installed manually, rather than using the sophisticated Expansion Managers.

Oh, as long as noone complains this is not an issue, right?

[phkb]

Oh, as long as noone complains this is not an issue, right?

We're kind of in a holding pattern until timer can respond, though, aren't we? Both you and I have raised the issue. Is there anything more to do right now? And believe me, this is a *huge* issue for me. I have at least a dozen OXP's to update/release, and I can't really do any of them until we have a fully working pipeline.

[hiran]

Oh, as long as noone complains this is not an issue, right?

We're kind of in a holding pattern until timer can respond, though, aren't we? Both you and I have raised the issue. Is there anything more to do right now? And believe me, this is a *huge* issue for me. I have at least a dozen OXP's to update/release, and I can't really do any of them until we have a fully working pipeline.

Yes, we could wait for Timer to bring up a new version of the Manifest Editor.
But this solution has it's pitfalls that we all experienced in the past. Thus I'd propose a different approach but implementing it just like that would not be reasonable.

My idea is not about creating a web application 'Manifest Editor'. Instead, I would just maintain a file with URLs, and there already exists a tool that reads the file and generates the Expansion Catalog based on all the manifests found in the expansions. Would that make sense?

[phkb]

My idea is not about creating a web application 'Manifest Editor'. Instead, I would just maintain a file with URLs, and there already exists a tool that reads the file and generates the Expansion Catalog based on all the manifests found in the expansions. Would that make sense?

If that can be done securely, yes, it does make sense. But being careful with our words, when you say "I would just maintain a file", hopefully it is not solely *your* responsibility to keep the list updated. That is, if I want to publish an update to Vimana-X, would you need to push that change to the expansion catalog?

[hiran]

My idea is not about creating a web application 'Manifest Editor'. Instead, I would just maintain a file with URLs, and there already exists a tool that reads the file and generates the Expansion Catalog based on all the manifests found in the expansions. Would that make sense?

If that can be done securely, yes, it does make sense. But being careful with our words, when you say "I would just maintain a file", hopefully it is not solely *your* responsibility to keep the list updated. That is, if I want to publish an update to Vimana-X, would you need to push that change to the expansion catalog?

Hopefully we have a group of people who can modify that file. I do not want to be a single point of failure.
So if we create a new repo in Ooliteproject on Github to host the list of downloads, that file could be used to generate updated expansion catalogues.
Whichever team has access to that repo can maintain it.

Would that be good enough?