hi,
what was the final decision around how best to export artifacts so they are visible on the same url as internally inside of ci ?
regards,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 24/11/15 13:02, Karanbir Singh wrote:
hi,
what was the final decision around how best to export artifacts so they are visible on the same url as internally inside of ci ?
regards,
Let me recap what we discussed the other day : Actually artifacts are available from outside through the following URL : https://ci.centos.org/artifacts/ Someone tried to (for a job) also not store but first retrieve previously saved artifacts pushed to the artifact node (see https://wiki.centos.org/QaWiki/CI/GettingStarted#head-a46ee49e8818ef9b50225c...)
Problem is that from an inside PoV, ci.centos.org is a A record pointing directly to the jenkins node, while from an external PoV, it's pointing to an nginx reverse proxy ( / being redirected to jenkins, while /artifacts is itself a proxy_pass to the internal artifacts node)
We can't just simply redirect now the internal A record to the nginx reverse proxy , as Jenkins slave java processes are accessing ci.centos.org internally through jnlp too , on some specific/fixed ports, so internal ci.centos.org A record needs to still be pointing to jenkins node.
The proposed solution is then to setup nginx on the jenkins node itself, redirecting / to itself (on the jenkins port, and not through iptables redirect rules), while /artifacts would then be redirected to the internal artifacts node, so that would mean that all URLs would be accessible internally and externally.
If that sounds good for everybody, we can create a "card" on the CI board and implement that during next maintenance window.
- -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
On 11/24/2015 02:28 PM, Fabian Arrotin wrote:
On 24/11/15 13:02, Karanbir Singh wrote:
hi,
what was the final decision around how best to export artifacts so they are visible on the same url as internally inside of ci ?
regards,
Let me recap what we discussed the other day : Actually artifacts are available from outside through the following URL : https://ci.centos.org/artifacts/ Someone tried to (for a job) also not store but first retrieve previously saved artifacts pushed to the artifact node (see https://wiki.centos.org/QaWiki/CI/GettingStarted#head-a46ee49e8818ef9b50225c...)
Problem is that from an inside PoV, ci.centos.org is a A record pointing directly to the jenkins node, while from an external PoV, it's pointing to an nginx reverse proxy ( / being redirected to jenkins, while /artifacts is itself a proxy_pass to the internal artifacts node)
We can't just simply redirect now the internal A record to the nginx reverse proxy , as Jenkins slave java processes are accessing ci.centos.org internally through jnlp too , on some specific/fixed ports, so internal ci.centos.org A record needs to still be pointing to jenkins node.
The proposed solution is then to setup nginx on the jenkins node itself, redirecting / to itself (on the jenkins port, and not through iptables redirect rules), while /artifacts would then be redirected to the internal artifacts node, so that would mean that all URLs would be accessible internally and externally.
If that sounds good for everybody, we can create a "card" on the CI board and implement that during next maintenance window.
Is there any update on this?
I still get 404 on http://ci.centos.org/artifacts/rdo/images/liberty/delorean/stable/undercloud... vs. http://artifacts.ci.centos.org/artifacts/rdo/images/liberty/delorean/stable/... from the our rdo-ci slave.
We would need to have the same URLs in our jobs, otherwise people will have no success trying to reproduce them outside of the CentOS CI environment.
Attila
On 01/05/2016 10:50 AM, Attila Darazs wrote:
On 11/24/2015 02:28 PM, Fabian Arrotin wrote:
On 24/11/15 13:02, Karanbir Singh wrote:
hi,
what was the final decision around how best to export artifacts so they are visible on the same url as internally inside of ci ?
regards,
Let me recap what we discussed the other day : Actually artifacts are available from outside through the following URL : https://ci.centos.org/artifacts/ Someone tried to (for a job) also not store but first retrieve previously saved artifacts pushed to the artifact node (see https://wiki.centos.org/QaWiki/CI/GettingStarted#head-a46ee49e8818ef9b50225c...)
Problem is that from an inside PoV, ci.centos.org is a A record pointing directly to the jenkins node, while from an external PoV, it's pointing to an nginx reverse proxy ( / being redirected to jenkins, while /artifacts is itself a proxy_pass to the internal artifacts node)
We can't just simply redirect now the internal A record to the nginx reverse proxy , as Jenkins slave java processes are accessing ci.centos.org internally through jnlp too , on some specific/fixed ports, so internal ci.centos.org A record needs to still be pointing to jenkins node.
The proposed solution is then to setup nginx on the jenkins node itself, redirecting / to itself (on the jenkins port, and not through iptables redirect rules), while /artifacts would then be redirected to the internal artifacts node, so that would mean that all URLs would be accessible internally and externally.
If that sounds good for everybody, we can create a "card" on the CI board and implement that during next maintenance window.
Is there any update on this?
I still get 404 on http://ci.centos.org/artifacts/rdo/images/liberty/delorean/stable/undercloud... vs. http://artifacts.ci.centos.org/artifacts/rdo/images/liberty/delorean/stable/... from the our rdo-ci slave.
We would need to have the same URLs in our jobs, otherwise people will have no success trying to reproduce them outside of the CentOS CI environment.
I do not think it is such a big deal to have the default url be the one that works outside of CI, and just have CI override the default. This is what I have been doing for tripleo-quickstart.
Attila _______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/01/16 16:50, Attila Darazs wrote:
On 11/24/2015 02:28 PM, Fabian Arrotin wrote:
On 24/11/15 13:02, Karanbir Singh wrote:
hi,
what was the final decision around how best to export artifacts so they are visible on the same url as internally inside of ci ?
regards,
Let me recap what we discussed the other day : Actually artifacts are available from outside through the following URL : https://ci.centos.org/artifacts/ Someone tried to (for a job) also not store but first retrieve previously saved artifacts pushed to the artifact node (see https://wiki.centos.org/QaWiki/CI/GettingStarted#head-a46ee49e8818ef9b50225c...)
Problem is that from an inside PoV, ci.centos.org is a A record
pointing directly to the jenkins node, while from an external PoV, it's pointing to an nginx reverse proxy ( / being redirected to jenkins, while /artifacts is itself a proxy_pass to the internal artifacts node)
We can't just simply redirect now the internal A record to the nginx reverse proxy , as Jenkins slave java processes are accessing ci.centos.org internally through jnlp too , on some specific/fixed ports, so internal ci.centos.org A record needs to still be pointing to jenkins node.
The proposed solution is then to setup nginx on the jenkins node itself, redirecting / to itself (on the jenkins port, and not through iptables redirect rules), while /artifacts would then be redirected to the internal artifacts node, so that would mean that all URLs would be accessible internally and externally.
If that sounds good for everybody, we can create a "card" on the CI board and implement that during next maintenance window.
Is there any update on this?
I still get 404 on http://ci.centos.org/artifacts/rdo/images/liberty/delorean/stable/undercloud...
vs.
http://artifacts.ci.centos.org/artifacts/rdo/images/liberty/delorean/stable/...
from the our rdo-ci slave.
We would need to have the same URLs in our jobs, otherwise people will have no success trying to reproduce them outside of the CentOS CI environment.
Attila
Hi Attila,
Yes, it was on the TODO list, but lot of us are/were still recovering from the "break" :-) We discussed that and I implemented today the following workaround : instead of having to setup a proxy_pass (and so the need for a maintenance window on the jenkins host), we've decided to in fact implement the artifacts.ci.centos.org node at the external level. In short, that means that for example in your case, the url http://artifacts.ci.centos.org/artifacts/rdo/images/liberty/delorean/stable/... now works both internally and externally.
Can you change/adapt your job and confirm that everything works fine for you now ?
Kind Regards,
- -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
-
Attila Darazs -
Fabian Arrotin -
John Trowbridge -
Karanbir Singh