docs and resources migration

As part of Infrastructure migration to Jetstream, I migrated http://docs.openmrs.org and http://resources.openmrs.org from xsede into S3.

There’s a CDN in front of S3, with a default TTL of 5 minutes. If you want to check the files without CDN, try http://openmrs-docs.s3-website-us-west-2.amazonaws.com/

I updated all builds in https://ci.openmrs.org/browse/JAVADOC to reflect that. If you attempt to use the old script, it should fail with a message.

@raff, are you aware of any other release/build attempting to deploy any javadoc?

Can someone please test Eclipse plugin? (Problems installing Eclipse plugins) I’d think it still works fine.

OCC/Implementation ID is currently not working: (Error while connecting to the implementation server to verify implementation) Would it be possible to host that using a different domain? If I create an html with a redirect, would that work? @burke and @darius

Forgot to link the code: https://github.com/openmrs/openmrs-contrib-itsm-terraform/tree/master/docs

1 Like

Sorry I missed this when I was on leave. Someone just complained about it again and I noticed.

In the openmrs-core code that calls this, we’re using a custom implementation of “HttpClient” that calls java.net.URL.openConnection() and its javadoc doesn’t specify whether this will follow redirects or not. [10 minutes later] I tested this and it seems like it does not follow redirects…

So, we either need to run the code at that actual address (http://resources.openmrs.org/tools/implementationid) or else we need to address this as a bugfix in openmrs-core.

I’m comfortable with the approach of making Cintia’s job easier by allowing the infra team to put a redirect in place for this, and we’ll need to fix this in some openmrs-core maintenance releases. (I only say this because it seems to be a pretty rarely-used feature, if it has been broken since October and nobody has said anything…)

I tried to make https://issues.openmrs.org/browse/ITSM-4059 complete. The first part, the dockerisation, can be done by others.

I think there are two approaches to this:

  1. Simply deploy Implementiation ID to a different domain, e.g. implementation.openmrs.org, and core is changed to use the new ID.
  2. I configure our proxy/CDN to proxy all /tools/* requests this new domain, so it will be transparent (and no redirect).

I’m quite happy to implement #2 if that make users’ jobs easier.

What I’m a little bit worried is that the URL you sent is actually http, not https. Assuming we have the passphrase transmitted over the network, that doesn’t seem ideal.

I suppose even with option #2, it would be better to change the URL to use https straightaway.

It would be nice to fix the http/https security issue while we’re at this. Unfortunately that means that we’d still need to make a change in openmrs-core.

@aramirez, you are the one who specifically ran into this problem, so let’s get your input. Do you need implementation id to be working before your upgrade to 2.x or is it enough to have it work after?

If you need it to work before upgrading to 2.x, would it be straightforward to upgrade all of your servers that need to connect to the implementation id server to the latest in their release line (I guess a new 1.9.13 release, if I remember what you’re running)?

@cintiadr, if Alejandro needs his existing servers to be able to connect without an upgrade then I guess we should do #2 and skip the https fix. But if he does not have this requirement, then I would lean towards #1 plus the https fix.

@darius @cintiadr Ideally before upgrading to 2.X as migrating my whole system to 2.X for now is only contemplated if the new sync module works properly.

@aramirez, so in that case is it easy or hard for you to upgrade your existing systems to 1.9.13 (to be released)?

@darius It is easy as long as the sync module doesn’t break in 1.9.13

Thanks @aramirez.

So, @cintiadr, I think we can do your first proposal (deploy to implementation.openmrs.org) and change openmrs-core, and also switch this to https-only.

(@dkayiwa can you help me remember to create a ticket for this in openmrs-core once Cintia confirms how she’ll do this? Actually I think we should code in the expectation of a redirect, e.g. we hardcode “om.rs/implementationid” instead of the actual tool URL. Or maybe this is not necessary since the Infra team can redirect with a one-liner…)

Sounds good to me.

I updated:

You might not want to use om.rs, as it would be a redirect (301/302), and apparently your code doesn’t follow redirects…

The thing is that my backlog is currently out of control (:D) and for sure I won’t be able to touch it in less than a month. If anyone else could do the dockerisation part, I could deploy it earlier.

Would that be ok?

1 Like

Hi everyone,

@jose007 contacted me, and mentioned that he’s attempting to use this module: https://github.com/openmrs/openmrs-module-cdagenerator

Apparently that module requires Implementation ID to be up and running, is that correct? Is there any way to skip that?

I’m going to mention @dkayiwa and @surangak here as I do have hope at least one of you two would know that (or have an idea of who knows it!) :smiley:

Is that what is being discussed here? docs and resources migration :smile:

Did you just really mean to just link the same topic??? :smiley:

Lolll. I think am getting too old not to have noticed that! :blush:

1 Like

Apparently I had stopped watching this talk category, or maybe I just missed some emails. Anyway, just seeing this now.

I think we agreed earlier that it’s okay to require the dev team to upgrade the openmrs core code to handle redirects.

It is what it is!

@jose007, Is there a post on some other topic that gives more details about the problem you ran into? This module’s latest commit was in 2014, so I don’t expect any devs to be actively involved with it, but if you share your error message (on a new post), or point me to where you already did this, I can peek at the code and advise on how to go forward.

1 Like