On Sun, Jun 05, 2016 at 11:21:47PM +0000, Jeremy Stanley wrote: > Running through the current priorities list (mostly unchanged so far > from our discussion in Tokyo); let me know if you disagree with > these observations and we can adjust... > > > Ansible Puppet Apply > -------------------- > > http://specs.openstack.org/openstack-infra/infra-specs/specs/ansible_puppet_apply.html > > This seems to be basically done and in production, modulo some bugs > identified in our session in Austin: > > https://etherpad.openstack.org/p/newton-infra-robustify-ansible-puppet > > I think it needs to stay on the priority list until these are fixed, > or we need to enumerate those still outstanding as bugs in search of > a fix (and consider the spec implemented just buggy) if they won't > be fixed in the very near future. > > > Use Diskimage Builder in Nodepool > --------------------------------- > > http://specs.openstack.org/openstack-infra/infra-specs/specs/dib-nodepool.html > > As I understand it, this is complete except for TripleO's images > (yes, irony since DIB is itself a TripleO team project). We'd like > to be able to deprecate and eventually remove snapshot support in > nodepool, so I think this stays on the priority list until TripleO > is no longer an issue (fixed or switched to being a third-party CI > system). > 99% of the work is done. TripleO jobs are running on centos-7 DIBs in the tripleo-experimental pipeline. In fact, I think we are ready to review 316856[1] which replaced tripleo-f22 with tripleo-centos-7 DIB.
[1] https://review.openstack.org/#/c/316856 > > Infra-cloud > ----------- > > http://specs.openstack.org/openstack-infra/infra-specs/specs/infra-cloud.html > > I've unfortunately lost touch with the progress on this since our > hardware was brought back online following the great flood. I assume > it's not done yet, or I would have heard about it. ;) > > Given we're still light on available nodes at peak, this ought to > stay on the priority list for now. > I'd like to get move involved with this. The last I had heard there was still an issue with IP allocation for out-of-band management cards. > > Store Build Logs in Swift > ------------------------- > > http://specs.openstack.org/openstack-infra/infra-specs/specs/logs-in-swift.html > > This seems to have taken a break, with our log volume diminishing > significantly in the past year or so and an alternative AFS-based > solution proposed: > > https://review.openstack.org/269928 > > We should remove the original spec from our priority list (since > that's basically already ceased to be an actual priority), and > probably supercede it with the AFS proposal. > AFS++ > > maniphest migration > ------------------- > > http://specs.openstack.org/openstack-infra/infra-specs/specs/maniphest.html > > This spec no longer has a volunteer, and the alternative storyboard > proposal has gained steam: > > http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html > > I think we should swap these in the priority list. However, the > deployment automation work done for maniphest may still be > repurposed for pholio (another component of the phabricator suite), > since the UX team has expressed an interest in having us maintain an > instance of that for them. > > > Common OpenStack CI Solution > ---------------------------- > > http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html > > This seems done, other than the logstash/kibana module migration > which is currently underway. It makes sense to leave this on the > priority list until it's done (which should be very, very soon from > the look of things). > > > Zuul v3 > ------- > > http://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html > > We knew this was likely to be a multi-cycle effort when we first > identified it as a priority, so obviously makes sense to remain on > the list for now. The other spec for zookeeper in nodepool should > likely be lumped in with it at a similar priority level since > they're interrelated: > > http://specs.openstack.org/openstack-infra/infra-specs/specs/nodepool-zookeeper-workers.html > I had some time this past week to stand up zookeeper[2] on my local nodepool.o.o server. I was able to find a decent community puppet module with works very well. Obviously there is some settings that will need to be updated for zookeeper, but I think we can roll it into production pretty easily. As for scaling, I can get started on the zk0(1-5).o.o servers this week. I don't think it will take much to bring them online too. [2] https://review.openstack.org/#/c/324037/ > > Anybody disagree with any of the above? Or have any details to add? > Or want to propose other additions to the priority list for the > current cycle? > -- > Jeremy Stanley > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
