Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra