Thank you Paul for reading through this, bellow are some comments on maintenance/operation topics...
> So I was looking at the retro and the following caught my eye: > >> Black Hat: Bad stuff >> No time to work on Software Factory. rpmfactoy every day. > > Personally, you should seriously consider having the Software Factory team > step > back from the day to day of RPMFactory. I'll probably sound like the bad guy, > but you don't want to get bogged down managing Software Factory deployments, > you > want to actively develop or maintain Software Factory. > First note that RPMFactory stories in Cobra sprint (so far) are about designing a workflow to produce packages using openstack-infra CI as well as supporting a smooth migration from the current RDO build architecture (which is spread accross gerrithub, centos build system and fedora for clients). While this is implemented out of tree (respectively in rpmfactory and python-sfrdo repositories), it will actually be contributed back to software-factory to provide a koji and distgit logic for rpm package production using Software Factory. > I understand why you are doing a lot of work with RPMFactory but I think your > first priority should be to transition RPMfactory off ASAP and bring new > maintainer into the fold to manage it. This new maintainer should be > responsible > for actively deploying SF. Obviously this will be a huge undertaking for the > new > maintainer to learn the ins and outs of openstack-infra CI. > About actual production and operation of the upcoming review.rdoproject.org deployment, this will be managed by the Cobra team until the community can takes over operations. In the last two years running and upgrading sf-project.io system, we actually didn't have much trouble with the openstack-infra CI components. Moreover, using and upgrading our own plateform really made SF more stable and I hope this will continue through this new deployment. For example if some logs needs rotation or nodepool database needs to be curated, then this need to be implemented in SF. So we did a "pre-mortem" discussion about what could go wrong, and the biggest risk we identified was the hosting cloud provider... Otherwise CI maintenance is a self service process (same as openstack-infra with the project-config repository). Thus it will be up to the community (as well as the Cobra team) to make sure jobs are running as expected. > I've seen this happen a few time with people running openstack-infra CI in > house, they become overwhelmed just trying to maintain the CI system and > slowly > drift farther and farther from upstream. I would hate to see the SF team > start > maintaining deployments of CI over training others to do the work. > Well that's why Software Factory comes as an image with an integrated deployment/configuration process. You can't really diverge from upstream since each reconfiguration/upgrade will put everything back to the reference deployment. Finally, note that daily backups are exported to an external swift container, which could be used to respawn the whole system very quickly. > As a data point, the HP Gozer team was about 10-12 people strong just > maintaining their shadow instance of upstream CI. Upstream openstack-infra > has > 9 infra-roots (and countless volunteers) keeping upstream CI working. > Oh well, sf-project.io root access are very occasional and plateform upgrades are usually performed by 1 or 2 team members... Though we surely don't have the same workload as HP or openstack-infra :-) Regards, -Tristan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
