[OpenStack-Infra] Infra Meeting Agenda for May 14, 2019
== Agenda for next meeting == * Announcements * Actions from last meeting * Specs approval * Priority Efforts (Standing meeting agenda items. Please expand if you have subtopics.) ** [http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html A Task Tracker for OpenStack] ** [http://specs.openstack.org/openstack-infra/infra-specs/specs/update-config-management.html Update Config Management] *** topic:puppet-4 and topic:update-cfg-mgmt *** Zuul as CD engine ** OpenDev *** Next steps * General topics ** Trusty Upgrade Progress (clarkb 20190507) ** https mirror update (ianw 20190514) * Open discussion ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Question: How to attach large files to LP bugs?
On 2019-05-13 12:48:53 -0400 (-0400), Clark Boylan wrote: [...] > compress multiple chunks and upload them separately? [...] I would go the other direction: compress as thoroughly as possible and then use the `split` utility specifying whatever the upload limit for LP is (I too have no idea what they limit attachment sizes to). Reassembly can be done with `cat` to stuff the chunks back together and then decompress the resulting file as usual. This is starting to remind me of splitting uuencoded data to overcome posting length limits on Usenet. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] 2019 Denver Summit/Forum/PTG Recap
Apologies for not getting this out earlier, but last week was a very odd week for. Slowly returning to normal now though. The long week started with a board meeting. In that board meeting Zuul was confirmed as a top level OpenStack Foundation Project. An exciting start to the week for our friends in Zuul land (which happens to be many of us too)! The first day of the summit we had Keynotes where corvus talked about the way we speculatively test changes with containers. ttx had a talk after keynotes on "Open Source is not enough" [0] which helps to point out why the infrastructure that we run is valuable. Later that day we had a Forum session on Storyboard painpoints. There was good feedback and we got a couple volunteers to help fix existing issues [1]. Tuesday started with a back to back Zuul BoF then Working Group session (in the same room) that ended up being a good discussion among current and potential Zuul users. We discussed how people were using Zuul and hangups upgrading from v2 to v3. There was a forum discussion on PTL tips and tricks [2] which I found interesting (as current PTL). In particular is seems that a number of projects use regular update emails (like Zuul) to keep people up to date on goings on rather than the weekly meeting. We recently discussed this as a team so I don't think we need to rehash it but was good to see other approaches. This day ended with a session on improving the Help Most Wanted list [3] which we are still on. General consensus seemed to be that the first pass at writing business cases addressed the wrong audience so a second pass would be made. In addition to that Allison Randall would reach out to institutions like OSUOSL to see if there is possibility to collaboration there. The last day of the summit included a forum session on OpenLab [4]. This was useful to help communicate where OpenDev can serve its users and where OpenLab is able to help too. At this point I think I was a zombie and we finished up the Summit with back to back Infra and Zuul project updates. But wait there is more! We had an Infra PTG room the next two days. Notes were taken at this etherpad [5] under the bolded headings. We kicked things off with a rundown of recent tech changes so that everyone had a rough idea of what those looked like. Jhesketh showed us that docker-compose can do things like get logs for your composed docker containers :) We discussed what the future of our deployment tooling looks like using Zuul as a CD engine and how we transition to that point. The current plan is that we'll split up the base.yaml playbook into other playbooks (but continue to have cron drive them). Then we can have Zuul take over the execution of each playbook over time (and possibly even use Zuul's periodic pipeline to do convergence if things are skipped for some reason). Initial work on that has started here [6]. We also talked about what new repo and namespace creation looks like in OpenDev. We ended up with a plan that roughly comes down to individual namespaces will be self managed as much as possible. This means that the Infra team won't be approving what goes into openstack/ or airship/ or zuul/ instead appropriate representatives from those groups will make those approvals. To make this happen we'll likely end up with a metadata repo per namespaces that tracks who can approve these things then rely on some combo of Gerrit config and Zuul jobs to make that happen. We also discussed how the namespaces might manage info needed to create valid zuul main.yaml then we can have tooling aggregate that together and deploy it. This way we don't have to manage each of those additions for zuul directly. Finally we discussed if OpenDev would be an appropriate location for throwaway repos and unfortunately we don't think we are there yet. Gerrit currently won't scale to that use case for us. Last major item we poked at was improving the reliability of our docker based jobs, particularly those that run on ipv6 clouds. The plan there is to use the in region mirror nodes for dockerhub proxying rather than local buildset registry proxies as the in region mirror has a floating IP to do 1:1 ipv4 NAT but the test nodes are many:1 ipv4 NAT. We expect this will improve reliability significantly. Before we can do that though we need to enable TLS on those mirror nodes as we'll be publishing the resulting artifacts. We can do this via letsencrypting new opendev.org mirror endpoints. The StarlingX folks came over to talk to us about their testing needs. They would like to do larger test scenarios on multiple nodes and ideally on baremetal. We suggested that they start by scaling up the testing on VMs (as many issues fall out when you go from one to two to three nodes) and getting that tested even on VMs would be valuable. For the baremetal problem we pointed out that we can support baremetal testing, we just need someone to give us access to
Re: [OpenStack-Infra] Question: How to attach large files to LP bugs?
On Fri, May 10, 2019, at 6:47 AM, Jones, Bruce E wrote: > > Greetings Infra team. The StarlingX project has a question – we have > had some bug reports where the log files needed to debug the bug turn > out to be quite large. Larger than can be attached to a LP entry. > > > Is there a recommended way to handle this case? I'm not even sure what the launchpad attachment size limit is, so I think this is the first time I have had to consider this problem. One option if possible would be to use an efficient compression algorithm like xz to compress the logs down to a size that LP will accept the upload. If that still doesn't get things small enough maybe compress multiple chunks and upload them separately? If we can't come up with a workaround like the above options, then the next best option is likely to host the content somewhere else and link LP to that location. Clark ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
