19 Sep
2014
19 Sep
'14
12:12 a.m.
--=-QrcPJdYQqLQ8AoeWLTrC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le jeudi 18 septembre 2014 =C3=A0 10:42 +0200, David Caro a =C3=A9crit : > On Thursday, September 18, 2014 01:10:15 AM Michael Scherer wrote: > > Le mercredi 17 septembre 2014 =C3=A0 15:37 -0400, R P Herrold a =C3=A9c= rit : > > > On Wed, 17 Sep 2014, Michael Scherer wrote: > > > > As I said in the past, the plan wouldn't work. To have 2 gears > > > > communicate, we need to have them setup in a specific way, not just= 2 > > > > gears in the same account. If one is moved to another node, we need= to > > > > have a specific triggers on the webserver gear to trigger a potenti= al > > > > configuration change. > > >=20 > > > Why not just point the two through a pair of keyed access > > > openvpn links, each to a fixed (and routing) central hub? > > >=20 > > > MySQL will communicate just fine across a network fabric > > >=20 > > > hub > > > =20 > > > 10.0.0.1 10.0.1.1 > > > =20 > > > / \ > > > =20 > > > / \ > > > =20 > > > 10.0.0.2 10.0.1.2 > > > gear A gear B > > > (the wiki) (the MySQL server) > > >=20 > > > The hub just routes 10.0.1 and 10.0.0 back and forth > > >=20 > > > Nothing changes, save re-establishment of an openvpn link when > > > a 'spoke' moves > >=20 > > I would slightly be against the idea because : > >=20 > > 1) we do not root access in the gears > >=20 > > 2) the firewall will likely not be open for that from the gear to > > external world > >=20 > > 3) one of the main selling point of using openshift online was that we > > do not have to manage the platform aspect. Adding openvpn to bypass the > > platform is kinda managing a different platform than what we have, and > > kinda negate the main advantage of using openshift. > >=20 > > 4) we would have to manage the hub ( so need to manage 1 more server ), > > so we could as well manage mysql and the wiki on the server and that's > > it ? > >=20 > > If we must stretch the platform to its limit to make it do what we want= , > > I think we should accept that what we want is not what we have. > >=20 > > Again, i think openshift is a fine product when you use it with softwar= e > > made for the platform ( ie, aware of the scaling requirement, aware of > > the variable for integration, stateless if possible ). > >=20 > > But currently, it is: > > - not integrated with puppet ( so we have 2 identity store ) > > - not integrated with icinga ( so it has its own monitoring ) > > - no backups made by ovirt infra ( but made by openshift ops ) > > - various space issue ( with a quite complex solution ) > >=20 > > We can surely solve each of this with enough hack. I can surely run > > puppet inside the gear if I want, running a nagios agent if we want, > > make a clever backup script and solve the space issue by reinstalling > > everything. > >=20 > > But if we go the pain of reinstallation and update, a more standard > > setup would be cleaner and easier in the future, by using straight > > tarball from upstream, by using standard system to cache the data, etc, > > etc. >=20 > I can get you a publicly accessible vm on phx lab for the migration. but = the=20 > DNS will take some time to change itself, that would suffice for you? I do not think we should migrate before testing a bit, so we can in the mean time reduce the DNS ttl, and it should be good once the migration is done. > If so, tell me the OS you need and how much space you tihnk we will need = for=20 > it.=20 Either we go on el6, or el7. I personally prefer el7 due to newer features, but the main concern i would have is with puppet on it, and if that's fully ok with the current setup.=20 And I think having 40G would be largely enough. We have 10G now, so with 40G, we have space for backup.=20 And we can increase the size of the disk at will, no ? --=20 Michael Scherer Open Source and Standards, Sysadmin --=-QrcPJdYQqLQ8AoeWLTrC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAABAgAGBQJUG1jXAAoJEE89Wa+PrSK9P94P/A7boYydszXtE2adm8O1/WHN Xih5S6YtdTCsCI1OWr0U+xGV+eP0AT4HMNnoBHE8VFjYvR8kO3tn04oc528kMrV7 kW1QWWu+CEAcP3SBfWdYaryPDUxG5LZMgi/RAkt3dZIfq7BZ+p1oPtTaAt/1r0Ek 5Gec31ZlZ9vN8D7iSsDbDbi6e/T/4ndr/DLwJcwOPjzbhojEWH96Zgx7rfVv99Az H6b1l2blv/bn/ELgsH/CZmOwar3nHrQedSPAmyEMwliuJc98SkEgU4QGCVDTKZQp ESSvTlPoWlzcId6V3x51EcRlrt/ruhhWwZx67ieCCGVu7us5NI7hhtpP5VbPOFHM Olo9GDqs5ETmcMFqpOcC2Alwzi+tEVoWLpbm0rczvTONKJnSwywSgv5zjh8866bO QTGrZXDgFD/cIFmqIvQbhhHnJUltTCDTO0+nytt47HaTnr6g7Z1SlRDv9Aoelggb lb6U1NNJtGLHt7jefQzCH50itAE8q+ogG/g+b3NHmr6uuFzQm8Co39nB1+RBG7v+ dYCb/MOvcKWtWdFodu8NlY9cGxgWYyq/djLA5UMXDtushQGx1hpM7PCYxaNDRtGD NKcxQHwLT+2SOF/6ukX0O8AS0d97AxReHtuRsgsijixZG8JkoLtt56NGVSo5BM6X y8sGM77xIC39fsHZULYs =FOTG -----END PGP SIGNATURE----- --=-QrcPJdYQqLQ8AoeWLTrC--