On Thu, 30 Jul 2015 19:39:12 +0200
Mikolaj Izdebski <mizdebsk(a)redhat.com> wrote:
Overall status: most of things are configured and working. New
Jenkins should be ready for data migration from old instance. I've
migrated two projects for now and they seem to be working.
Great news. Thanks so much for working on this. ;)
Deployment details: There are: 1 master and 3 slaves (workers)
in the new cloud. All instances are of type "m1.small" (1 CPU, 2 GB
RAM, 20 GB disk).
In the old cloud some of the builders were bigger, should we bump
these up some when we move to production?
Some notes or questions, in random order:
Slaves have public IP assigned. It's not needed by Jenkins itself,
but I think it is required to be able to manage them through ansible.
Yeah, easiest to just leave this as is. We could proxy to them via the
master, but it would be a hassle to get all working right.
Master is running official jenkins package from Fedora 22, with
several core plugins also from Fedora. Plugins which were not
available in Fedora are packaged in Copr repo and installed as RPMs
too. Packages in Copr are just wrappers around upstream binaries -
they are not built from source in Copr.
Jenknis runs as unprivileged user, so it can't listen on port 80 - it
listens on port 8080. Old Jenkins was running httpd proxy, which
forwarded incoming requests from port 80 to 8080. New Jenkins
forwards ports using netfilter (aka iptables). Was there any other
reason for running httpd proxy?
Only members of sysadmin-jenkins group have admin access through web
interface. Should sysadmin-main be added there too?
We could, but I think all the sysadmin-main folks that are interested
are already in sysadmin-jenkins and/or we could add them easily.
Subversion plugin is currently disabled due to unresolved problem.
Projects using subversion SCM (if any) won't work until this is fixed.
Do we have any SVN projects in the old cloud?
Slaves have the same set of extra packages installed as in the old
cloud. Like in the old Jenkins instance, jenkins user is member of
mock group, which opens possibility for arbitrary code execution on
any of Jenkins hosts (on slaves as root, on master as jenkins user)
for anyone with write access to any project. I'm not saying it's
necessairly a problem, but I wanted to point it out clearly.
Current Jenkins master doesn't have persistent storage, but I
like to add it when moving to production.
Easy to do anytime.
Thanks again for working on it.