- Zuul-discuss - lists.opendev.org

nodepoolcmd + secure.conf
by Paul Belanger 25 Mar '19

25 Mar '19

Greetings, I wanted to discuss maybe reverting the following change[1]. On friday I updated our local nodepool.yaml configuration to move zookeeper-servers section into secure.conf. This was mostly to prepare for the upcoming patch adding SSL support for zookeeper. However, because 480310 removed the default value of the -s flag, I now find myself having to type the following everytime I want to interact with nodepool: $ nodepool -s /etc/nodepool/secure.conf list $ nodepool -s /etc/nodepool/secure.conf dib-image-list ... I actually don't think a full revert is the best case here, as that would mean ever nodepool install would need to add /etc/nodepool/secure.conf, even if empty to have the CLI command not raise an exception for missing file. I also don't think silently failing, if /etc/nodepool/secure.conf is missing is the best way forward either as this could mask deployment issues. Does anybody have an idea how we could fix this to be a little more user friendly? Thanks! - Paul [1] https://review.openstack.org/480310/

2 2

Speculative docker images
by corvus＠inaugust.com 22 Mar '19

22 Mar '19

Hi, As you know, with respect to git repositories, Zuul frequently operates well into the future, allowing jobs to build software with changes that haven't landed yet under the assurance that they will. As more of us have incorporated container image building into our processes, we find that we want the same thing there -- that not only would our git repositories represent the future that Zuul sees, but also our container image registries. As a concrete and simple example, we have an integration job called 'zuul-quick-start' which uses both Nodepool and Zuul container images. Those images themselves depend on build images created from the openstack-infra/system-config repository, which they use via a "FROM" line in Dockerfiles, and extending the zuul-quick-start job to be able to rebuild and use those builder images in the case of a Depends-On change is too complex to consider. In particular, the "FROM" line is problematic, as the only way to realistically use a speculative image as a base image is to alter the Dockerfile or make the image available in a registry. Therefore, this is a proposal for a system for building speculative images which can then be used by further speculative images. Every item in a Zuul pipeline has its own future state which is related to, but separate from all the other items. It needs to be able to build an image for a project and store it in a registry under the final published name and tag, without affecting any of the changes ahead of it. Therefore, each item needs its own image registry. In the case of a single, simple job such as zuul-quick-start, we can just run a docker registry on the node on which the job is running. In the case of a more complicated system where we want to build an image once and use it in multiple dependent jobs in a job graph, we will start an image registry at the root of the job graph, pause the job, and the dependent jobs will use it. Now that we have the registry for the change, we need to have that registry reflect the state of any changes ahead. We need to know when the change ahead has finished building its images so that we can then add those images into our change's registry. To accomplish this, we can extend Zuul so that jobs have a provides/requires interface. If our job requires docker images produced by a job in a dependent change, we can say: - job: name: zuul-quick-start requires: docker-images - job: name: system-config-build-image-python-builder provides: docker-images Zuul will see that zuul-quick-start should not start until all of the jobs for all of the changes ahead which provide "docker-images" have completed. Then zuul-quick-start will be able to retrieve images from the preceding changes' jobs and add them to its own registry. In the gate, the behavior of this is obvious: if a change has a job with a requirement, iterate over all changes ahead of it in the shared queue and search for jobs on those changes which provide that requirement. If there are none, or all of them have completed or paused, then that job is ready to start. Otherwise, wait. In an independent pipeline, we do include dependent changes ahead in the shared queue, but they are not live -- they don't run any actual jobs. So in that case, we're going to have to peek outside our shared queue and see if our dependent changes show up anywhere else in the same pipeline, and if they do, wait for their jobs. If they don't show up, then we know they completed earlier, and it's safe to start. There's one more thing about this change that will help us later: a job that "provides" something should be able to pass data to a job which "requires" it. So our image build jobs can use zuul_return to provide information about which images they built so that it's easier for later jobs to import those images into their registries. Once again, the independent pipelines make this tricky, as since those jobs may have run some time in the past, the scheduler may have forgotten the data they returned. However, once the SQL database is required, we can rely on that to fill in any missing data. That's the only change we need to Zuul itself to support this system. The rest is all playbooks and roles. That brings us to the challenge of how to actually transfer these artifacts between items. I can think of two approaches. They are not mutually exclusive -- we can implement both if we want. They both have pros and cons. But I would like input from Zuul operators (including openstack-infra/opendev) as to which they would prefer, and I'll implement that approach in OpenDev for Zuul's own upstream use. If we have a split decision, someone else can implement the second approach. I think we can support both in zuul-jobs, but I'd like us to run the most widely applicable approach upstream. Alternative 1: Use the Logserver ================================ In the case of a simple job, at the end of the job, or in the case of a complex job graph, a child job dependent on the completion of the image build process (so we don't have to wait for all the jobs to complete), we will export the images to the filesystem and upload their layers (minus any layers which are already on Docker Hub, in order to save space) to the logserver. This next bit is a little complicated, but remember that this will all be encapsulated in roles so we only have to implement it once; the user interface will resemble "roles: [fetch-dependent-images]". At the end of the image build job, for every image that we built: Export it to a directory on the filesystem. For each layer in the image: Perform a HEAD request against the Docker Hub registry to see if the layer exists in the target repository. If that exists, layer exists in docker, remove from filesystem. rsync image directories to logserver. zuul_return image location on logserver. At the start of a job which requires images: For each previous image (as provided by zuul_return): Rsync image directory from logserver to filesystem. For each layer in image manifest: If layer is missing from filesystem: Get the layer from Docker Hub. Import image into local registry. The advantages of this approach: * No external operational dependencies (i.e., you don't have to run a docker registry). The disadvantages of this approach: * Images can't easily be fetched and used for debugging. * Implementation is slightly more complex. Alternative 2: Use a Central Registry ===================================== In this approach, we would run a central registry to store speculative images. It would not store final images at all, and every image uploaded to it would be tagged only with a tag like "pipeline_check_change_1234_original_tag" to uniquely identify its build context. At the end of the image build job, for every image that we built: Copy it from the per-change registry to the central registry, and tag it with pipeline and change id. zuul_return image location and tag. At the start of a job which requires images: For each previous image (as provided by zuul_return): Copy it from the central registry to the local registry, and tag it with the original tag. The advantages of this approach: * Developers can fetch images from the central registry by pulling them with the crazy tag. * Implementation is a little easier, and uses more standardized tools. The disadvantages of this approach: * An external service is required. * We will need to prune old images from the registry. Conclusion ========== I don't think this system will take long to implement with either of the alternatives. Please let me know what you think of the system, and of the storage/transfer alternatives. -Jim

4 4

Parameterized Build
by Tristan Cacqueray 20 Mar '19

20 Mar '19

Hello, It seems like it would help the migration of Jenkins users if they could have a similar feature[0] in Zuul to manually trigger a job with custom parameters. One solution is to create a fake change or branch to trigger a job, but perhaps Zuul can offer a better user experience. In particular, the Jenkins implementation offers a nice form to set the parameters. I started to implement this feature with a jobtrigger driver[1] along with a web page[2] to expose the job's variables but James asked to describe the use case first. Our current use case is for QA/QE engineers who would like to run a single (usualy long running) job with custom parameters such as the product version, the system version, ... With Jenkins, we can have lots of jobs grouped as multijob running in different phases, and the parameterized build is a very convenient way to run a single job, sometime using a parameter to add a breakpoint and get access to the environment. Another solution would be to build on top of the zuul-runner to provide a similar workflow, but it seems like more efficient if we could re-use the zuul-scheduler and let it request/cleanup the nodes. In summary, could we adjust the architecture to support executing an individual job instead of an entire job graph and could we support a zuul-web trigger? Regards, -Tristan [0]: https://wiki.jenkins.io/display/JENKINS/Parameterized+Build [1]: https://review.openstack.org/555153 [2]: https://review.openstack.org/554839

3 9

Re: Zuul 3.7.0 released
by Jimmy McArthur 20 Mar '19

20 Mar '19

Congrats to the whole Zuul community :) > James E. Blair <mailto:corvus@inaugust.com> > March 20, 2019 at 3:33 PM > The Zuul team is pleased to announce the release of Zuul 3.7.0. > > Download it from PyPI: https://pypi.org/project/zuul > > The release notes, included below, are also available in the > documentation with hyperlink references: > > https://zuul-ci.org/docs/zuul/releasenotes.html#relnotes-3-7-0 > > Upgrade Notes > ============= > > * The default ansible version is now 2.7. In case this breaks any jobs > this can be overridden in job.ansible-version, > tenant.default-ansible-version or scheduler.default_ansible_version > > * In order to support several ansible versions installed simultaneously > Zuul now handles them itself in virtual environments. By default Zuul > installs the needed ansible versions on startup so there is no further > user action required. However it is recommended to pre-install the > ansible environments during installation by invoking > zuul-manage-ansible. > > * The user value in the [fingergw] configuration section previously > defaulted to zuul, but now is unset by default, which will cause > fingergw not to drop privileges. It is recommended that this value be > explicitly set to an unprivileged user. > > * The hosts value in the [zookeeper] configuration section previously > defaulted to localhost:2181, but now is unset by default. This value > is required and must be explicitly set (and the documentation has > always indicated this). > > New Features > ============ > > * Jobs may now specify which ansible version is used to run them. The > ansible version to use can now be specified by job.ansible-version. > > * Zuul now supports ansible 2.6 for running jobs. > > * Zuul now supports ansible 2.7 for running jobs. > > * The ansible_python_interpreter variable is now whitelisted for the > add_host task. > > _______________________________________________ > Zuul-announce mailing list > Zuul-announce(a)lists.zuul-ci.org > http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-announce

1 0

Re: Migrating git repos to OpenDev
by corvus＠inaugust.com 20 Mar '19

20 Mar '19

corvus(a)inaugust.com (James E. Blair) writes: > Hi, > > As discussed in November[1], the OpenStack project infrastructure is > being rebranded as "OpenDev" to better support a wider community of > projects. > > We are nearly ready to perform the part of this transition with the > largest impact: moving the authoritative git repositories for existing > projects. Working with the folks representing each of the affected OSF projects, we've scheduled the migration for Friday, April 19, 2019. This is shortly after the next OpenStack release. Please see [2] for further details about what this will involve. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.ht… -Jim

1 0

BoF/WG Space at Open Infrastructure Summit Denver
by Jimmy McArthur 19 Mar '19

19 Mar '19

Does the Zuul Community have any interest in BoF or Working Group space in Denver? For those unfamiliar, Working Groups are informal groups of people sharing a common interest for a task or code subsystem. Birds of a Feather is an effort to interest new community members to your project through a presentation and Q&A format. Each session type is 40 minutes. Cheers, Jimmy

4 11

Zuul Board Approval Presentation
by Jimmy McArthur 18 Mar '19

18 Mar '19

Hi All - I'm working with Zuul on their pending project confirmation on behalf of the OpenStack Foundation. As you may or may not know, Zuul will need to do a presentation in front of the OpenStack Foundation Board. I've started an etherpad [1] with a rough outline, but ultimately this should be a community driven effort. If you are able to fill in some blanks, we welcome your contribution! Cheers, Jimmy [1] https://etherpad.openstack.org/p/Zuul_2019_OSF_Project_Confirmation_Process

1 0

Zuul generic jobs
by Tomasz Szandała 13 Mar '19

13 Mar '19

Greetings, I have a project, that requires compilation for different targets. Same commands, but each one has to be done separately. I have seen how OpenStack does it: https://github.com/openstack-infra/openstack-zuul-jobs/blob/master/zuul.d/j… so we define dozens of jobs separately even if they differ only by single element. My idea was to define job compilation, in which it is Ansible playbook that determines which target it should choose, based on job name: (compilation.yaml - playbook) - name: Set hardware and technology set_fact: hardware: "{{ zuul.job.split('.')[1] }}" technology: "{{ zuul.job.split('.')[2] }}" Now in project definition I can have something like this: - project: verification: jobs: - compilation.x86_64.old: parent: compilation - compilation.i686.old: parent: compilation - compilation.i686.future: parent: compilation But Zuul says, that compiation.x86_64.old is not defined. In other words: I want to define job inside project definition. This will mean that adding new variant I can only modify only 2 lines. Is there any reason why it is impossible? Kind regards, Tomasz

7 9

Zuul project update 2019-03-11
by corvus＠inaugust.com 12 Mar '19

12 Mar '19

Hi, Since the last email update, we merged the Multi-Ansible spec: https://zuul-ci.org/docs/zuul/developer/specs/multiple-ansible-versions.html Tristan worked on adding a job filter to the trigger event, as discussed previously on this list. The webtrigger patch is now based on that. Tristan also continued working on zuul-runner and a set of patches to support nodes with python3 only. I finally finished the changes related to buildset docker registries (also mentioned previously on this list). In the end, the system looks to be easy to use, but there are a few moving parts. My next task is to document how to set such a system up. ****************************** There are a lot of outstanding changes, and I'd like to attempt to prioritize and sequence them to help us work through them together: 1) The multi-ansible series While this is newer than the others on the list, it does address significant technical debt. It would be really good to get this finished and released before Ansible 2.5 goes out of maintenance (it's the oldest supported Ansible and only receives security fixes). 2) The zuul-runner series This has been in development for a long time, and has a significant impact on the executor. It will almost certainly conflict with the multi-ansible series, so let's work on getting this merged after that. 3) The web authentication spec This has been in development for a while, and folks working on it recently signaled it's ready for review. This shouldn't conflict with anything ahead of it, so we can review it as time permits. 4) The web authentication series Once the spec lands, we can review the implementation which has been developing in parallel. Of course, there's lots of other stuff out there we can review as well, and anyone is free to review anything they want. :) However, I think if we agree to prioritize these major efforts as I suggest, we will be able to focus on them together and make the most efficient progress. Help write the next update email by updating https://etherpad.openstack.org/p/zuul-update-email Thanks, Jim

5 5

404 - Tenant does not exist
by Tomasz Szandała 10 Mar '19

10 Mar '19

Greetings, I have set up zuul v3 using docker-compose, so on my host I can see following containers running: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b47be7107613 zuul/zuul-web "/usr/bin/dumb-init …" 12 hours ago Up 18 minutes 0.0.0.0:9000->9000/tcp docker_web_1 5b4fcd2a2238 zuul/zuul-executor "/usr/bin/dumb-init …" 12 hours ago Up 18 minutes docker_executor_1 4fe739ae6ace zuul/zuul-scheduler "/usr/bin/dumb-init …" 12 hours ago Up 7 minutes docker_scheduler_1 1c88df15bd55 zuul/nodepool-launcher "/usr/bin/dumb-init …" 12 hours ago Up 18 minutes 0.0.0.0:8022->8022/tcp docker_launcher_1 682c8f4ece17 zookeeper "/docker-entrypoint.…" 12 hours ago Up 18 minutes 2181/tcp, 2888/tcp, 3888/tcp docker_zk_1 3bcfaf604728 docker_logs "httpd-foreground" 12 hours ago Up 18 minutes 0.0.0.0:8000->80/tcp docker_logs_1 151eee2a9f4a mariadb "docker-entrypoint.s…" 12 hours ago Up 12 hours 3306/tcp Everything in real time works perfectly, but the problem is that I cannot see the builds history. My web service cannot get http://zuul-master.internal.com:9000/api/tenant/igor/buildsets nor any other /api call. It receives 404, tenant not found. I doesn't look like firewall issue, nor I see any errors in docker-compose logs. Any idea what did I set wrongly here? Kind regards, Tomasz

1 1

Re: [all] [forum] Forum Submissions are open!
by Kendall Nelson 27 Feb '19

27 Feb '19

Hello :) On Wed, Feb 27, 2019 at 1:26 PM Chris Morgan <mihalis68(a)gmail.com> wrote: > I think the issue is that forum submissions building on what gets > discussed in Berlin can't be expected to be finalised whilst attendees to > the berlin meetup are still traveling. It's not that Erik can't pull these > things together, in fact he's an old hand at this, it's more that this > process isn't reasonable if there's so little time to collate what we learn > in Berlin and feed it forward to Denver. Frankly it sounds like because the > planning committee needs 5 weeks, Erik can have two days. Seem unfair. > Honestly, the decision process doesn't take much time, aside from organizing a time that all 10 people can meet across x timezones (a thing unto itself). Its the community feedback period, giving people enough time to secure travel approval from their management, loading the sessions into the actual schedule app, and other print deadlines that force us to have everything set this far out. I will definitely help the ops community in whatever way I can! Do you have remote attendance set up for the meetup? > Chris > > On Wed, Feb 27, 2019 at 2:29 PM Kendall Nelson <kennelson11(a)gmail.com> > wrote: > >> Another- nother thought: You could take a look at what is submitted by >> project teams closer to the deadline and see if your ideas might fit well >> with theirs since they are looking for feedback from operators anyway. In >> the past I have always hoped for more engagement in the forum sessions I've >> submitted but only ever had one or two operators able to join us. >> >> -Kendall (diablo_rojo) >> >> On Wed, Feb 27, 2019 at 11:14 AM Kendall Nelson <kennelson11(a)gmail.com> >> wrote: >> >>> Hello :) >>> >>> On Wed, Feb 27, 2019 at 11:08 AM Jimmy McArthur <jimmy(a)openstack.org> >>> wrote: >>> >>>> Erik, >>>> >>>> I definitely understand the timeline is tight. One of the reasons that >>>> we publish the schedule so early is to enable community members to plan >>>> their schedule early, especially as there is more overlap with the main >>>> Summit Schedule in Denver. Additionally, travel approval is often >>>> predicated upon someone showing they're leading/moderating a session. >>>> >>>> Before publishing the schedule, we print a draft Forum schedule for >>>> community feedback and start promotion of the schedule, which we have to >>>> put up on the OpenStack website and apps at 5 weeks out. Extending the date >>>> beyond the 10th won't give the Forum Selection Committee enough time to >>>> complete those tasks. >>>> >>>> I think if the Ops team can come up with some high level discussion >>>> topics, we'll be happy to put some holds in the Forum schedule for >>>> Ops-specific content. diablo_rojo has also offered to attend some of the >>>> Ops sessions remotely as well, if that would help you all shape some things >>>> into actual sessions. >>>> >>> >>> I'm definitely happy to help as much as I can. If you'll have something >>> set up that I can call into (zoom, webex, bluejeans, hangout, whatever), I >>> definitely will. I could also read through etherpads you take notes in and >>> help summarize things into forum proposals. >>> >>> Another thing to note is that whatever you/we submit, it doesn't have to >>> be award winning :) Its totally possible to change session descriptions and >>> edit who the speaker is later. >>> >>> Other random thought, I know Sean McGinnis has attended a lot of the >>> Operators stuff in the past so maybe he could help narrow things down too? >>> Not to sign him up for more work, but I know he's written a forum propsal >>> or two in the past ;) >>> >>> >>>> >>>> I wish I could offer a further extension, but extending it another week >>>> would push too far into the process. >>>> >>>> Cheers, >>>> Jimmy >>>> >>>> Erik McCormick <emccormick(a)cirrusseven.com> >>>> February 27, 2019 at 12:43 PM >>>> >>>> Jimmy, >>>> >>>> I won't even get home until the 10th much less have time to follow up >>>> with anyone. The formation of those sessions often come from >>>> discussions spawned at the meetup and expanded upon later with folks >>>> who could not attend. Could we at least get until 3/17? I understand >>>> your desire to finalize the schedule, but 6 weeks out should be more >>>> than enough time, no? >>>> >>>> Thanks, >>>> Erik >>>> >>>> Jimmy McArthur <jimmy(a)openstack.org> >>>> February 27, 2019 at 12:04 PM >>>> >>>> Hi Erik, >>>> >>>> We are able to extend the deadline to 11:59PM Pacific, March 10th. >>>> That should give the weekend to get any additional stragglers in and still >>>> allow the Forum Programming Committee enough time to manage the rest of the >>>> approval and publishing process in time for people's travel needs, etc... >>>> >>>> For the Ops Meetup specifically, I'd suggest going a bit broader with >>>> the proposals and offering to fill in the blanks later. For example, if >>>> something comes up and everyone agrees it should go to the Forum, just >>>> submit before the end of the Ops session. Kendall or myself would be happy >>>> to help you add details a bit later in the process, should clarification be >>>> necessary. We typically have enough spots for the majority of proposed >>>> Forum sessions. That's not a guarantee, but food for thought. >>>> >>>> Cheers, >>>> Jimmy >>>> >>>> >>>> _______________________________________________ >>>> Airship-discuss mailing list >>>> Airship-discuss(a)lists.airshipit.org >>>> http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss >>>> >>>> Erik McCormick <emccormick(a)cirrusseven.com> >>>> February 27, 2019 at 11:31 AM >>>> Would it be possible to push the deadline back a couple weeks? I expect >>>> there to be a few session proposals that will come out of the Ops Meetup >>>> which ends the day before the deadline. It would be helpful to have a >>>> little time to organize and submit things afterwards. >>>> >>>> Thanks, >>>> Erik >>>> >>>> Jimmy McArthur <jimmy(a)openstack.org> >>>> February 27, 2019 at 10:40 AM >>>> Hi Everyone - >>>> >>>> A quick reminder that we are accepting Forum [1] submissions for the >>>> 2019 Open Infrastructure Summit in Denver [2]. Please submit your ideas >>>> through the Summit CFP tool [3] through March 8th. Don't forget to put >>>> your brainstorming etherpad up on the Denver Forum page [4]. >>>> >>>> This is not a classic conference track with speakers and presentations. >>>> OSF community members (participants in development teams, operators, >>>> working groups, SIGs, and other interested individuals) discuss the topics >>>> they want to cover and get alignment on and we welcome your participation. >>>> The Forum is your opportunity to help shape the development of future >>>> project releases. More information about the Forum [1]. >>>> >>>> If you have questions or concerns, please reach out to >>>> speakersupport(a)openstack.org. >>>> >>>> Cheers, >>>> Jimmy >>>> >>>> [1] https://wiki.openstack.org/wiki/Forum >>>> [2] https://www.openstack.org/summit/denver-2019/ >>>> [3] https://www.openstack.org/summit/denver-2019/call-for-presentations >>>> [4] https://wiki.openstack.org/wiki/Forum/Denver2019 >>>> ___________________________________________ >>>> >>>> >>> Hopefully that helps! >>> >>> -Kendall (diablo_rojo) >>> >> > > -- > Chris Morgan <mihalis68(a)gmail.com> > - Kendall Nelson (diablo_rojo)

1 0

Re: [all] [forum] Forum Submissions are open!
by Jimmy McArthur 27 Feb '19

27 Feb '19

Erik, I definitely understand the timeline is tight. One of the reasons that we publish the schedule so early is to enable community members to plan their schedule early, especially as there is more overlap with the main Summit Schedule in Denver. Additionally, travel approval is often predicated upon someone showing they're leading/moderating a session. Before publishing the schedule, we print a draft Forum schedule for community feedback and start promotion of the schedule, which we have to put up on the OpenStack website and apps at 5 weeks out. Extending the date beyond the 10th won't give the Forum Selection Committee enough time to complete those tasks. I think if the Ops team can come up with some high level discussion topics, we'll be happy to put some holds in the Forum schedule for Ops-specific content. diablo_rojo has also offered to attend some of the Ops sessions remotely as well, if that would help you all shape some things into actual sessions. I wish I could offer a further extension, but extending it another week would push too far into the process. Cheers, Jimmy > Erik McCormick <mailto:emccormick@cirrusseven.com> > February 27, 2019 at 12:43 PM > Jimmy, > > I won't even get home until the 10th much less have time to follow up > with anyone. The formation of those sessions often come from > discussions spawned at the meetup and expanded upon later with folks > who could not attend. Could we at least get until 3/17? I understand > your desire to finalize the schedule, but 6 weeks out should be more > than enough time, no? > > Thanks, > Erik > Jimmy McArthur <mailto:jimmy@openstack.org> > February 27, 2019 at 12:04 PM > Hi Erik, > > We are able to extend the deadline to 11:59PM Pacific, March 10th. > That should give the weekend to get any additional stragglers in and > still allow the Forum Programming Committee enough time to manage the > rest of the approval and publishing process in time for people's > travel needs, etc... > > For the Ops Meetup specifically, I'd suggest going a bit broader with > the proposals and offering to fill in the blanks later. For example, > if something comes up and everyone agrees it should go to the Forum, > just submit before the end of the Ops session. Kendall or myself > would be happy to help you add details a bit later in the process, > should clarification be necessary. We typically have enough spots for > the majority of proposed Forum sessions. That's not a guarantee, but > food for thought. > > Cheers, > Jimmy > > > _______________________________________________ > Airship-discuss mailing list > Airship-discuss(a)lists.airshipit.org > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss > Erik McCormick <mailto:emccormick@cirrusseven.com> > February 27, 2019 at 11:31 AM > Would it be possible to push the deadline back a couple weeks? I > expect there to be a few session proposals that will come out of the > Ops Meetup which ends the day before the deadline. It would be helpful > to have a little time to organize and submit things afterwards. > > Thanks, > Erik > > Jimmy McArthur <mailto:jimmy@openstack.org> > February 27, 2019 at 10:40 AM > Hi Everyone - > > A quick reminder that we are accepting Forum [1] submissions for the > 2019 Open Infrastructure Summit in Denver [2]. Please submit your > ideas through the Summit CFP tool [3] through March 8th. Don't forget > to put your brainstorming etherpad up on the Denver Forum page [4]. > > This is not a classic conference track with speakers and > presentations. OSF community members (participants in development > teams, operators, working groups, SIGs, and other interested > individuals) discuss the topics they want to cover and get alignment > on and we welcome your participation. The Forum is your opportunity > to help shape the development of future project releases. More > information about the Forum [1]. > > If you have questions or concerns, please reach out to > speakersupport(a)openstack.org <mailto:speakersupport@openstack.org>. > > Cheers, > Jimmy > > [1] https://wiki.openstack.org/wiki/Forum > [2] https://www.openstack.org/summit/denver-2019/ > [3] https://www.openstack.org/summit/denver-2019/call-for-presentations > [4] https://wiki.openstack.org/wiki/Forum/Denver2019 > ___________________________________________ >

2 2

Re: [all] [forum] Forum Submissions are open!
by Jimmy McArthur 27 Feb '19

27 Feb '19

Hi Erik, We are able to extend the deadline to 11:59PM Pacific, March 10th. That should give the weekend to get any additional stragglers in and still allow the Forum Programming Committee enough time to manage the rest of the approval and publishing process in time for people's travel needs, etc... For the Ops Meetup specifically, I'd suggest going a bit broader with the proposals and offering to fill in the blanks later. For example, if something comes up and everyone agrees it should go to the Forum, just submit before the end of the Ops session. Kendall or myself would be happy to help you add details a bit later in the process, should clarification be necessary. We typically have enough spots for the majority of proposed Forum sessions. That's not a guarantee, but food for thought. Cheers, Jimmy > Erik McCormick <mailto:emccormick@cirrusseven.com> > February 27, 2019 at 11:31 AM > Would it be possible to push the deadline back a couple weeks? I > expect there to be a few session proposals that will come out of the > Ops Meetup which ends the day before the deadline. It would be helpful > to have a little time to organize and submit things afterwards. > > Thanks, > Erik > > Jimmy McArthur <mailto:jimmy@openstack.org> > February 27, 2019 at 10:40 AM > Hi Everyone - > > A quick reminder that we are accepting Forum [1] submissions for the > 2019 Open Infrastructure Summit in Denver [2]. Please submit your > ideas through the Summit CFP tool [3] through March 8th. Don't forget > to put your brainstorming etherpad up on the Denver Forum page [4]. > > This is not a classic conference track with speakers and > presentations. OSF community members (participants in development > teams, operators, working groups, SIGs, and other interested > individuals) discuss the topics they want to cover and get alignment > on and we welcome your participation. The Forum is your opportunity > to help shape the development of future project releases. More > information about the Forum [1]. > > If you have questions or concerns, please reach out to > speakersupport(a)openstack.org <mailto:speakersupport@openstack.org>. > > Cheers, > Jimmy > > [1] https://wiki.openstack.org/wiki/Forum > [2] https://www.openstack.org/summit/denver-2019/ > [3] https://www.openstack.org/summit/denver-2019/call-for-presentations > [4] https://wiki.openstack.org/wiki/Forum/Denver2019 > ___________________________________________ >

1 0

[all] [forum] Forum Submissions are open!
by Jimmy McArthur 27 Feb '19

27 Feb '19

Hi Everyone - A quick reminder that we are accepting Forum [1] submissions for the 2019 Open Infrastructure Summit in Denver [2]. Please submit your ideas through the Summit CFP tool [3] through March 8th. Don't forget to put your brainstorming etherpad up on the Denver Forum page [4]. This is not a classic conference track with speakers and presentations. OSF community members (participants in development teams, operators, working groups, SIGs, and other interested individuals) discuss the topics they want to cover and get alignment on and we welcome your participation. The Forum is your opportunity to help shape the development of future project releases. More information about the Forum [1]. If you have questions or concerns, please reach out to speakersupport(a)openstack.org <mailto:speakersupport@openstack.org>. Cheers, Jimmy [1] https://wiki.openstack.org/wiki/Forum [2] https://www.openstack.org/summit/denver-2019/ [3] https://www.openstack.org/summit/denver-2019/call-for-presentations [4] https://wiki.openstack.org/wiki/Forum/Denver2019 ___________________________________________

1 0

OpenInfra Day Vietnam 2019 - pre-CFP
by Trinh Nguyen 26 Feb '19

26 Feb '19

Hello, This is the pre-calling for presentations at the OpenInfra Day in Vietnam this year. If you love to visit Hanoi <https://en.wikipedia.org/wiki/Hanoi>, the capital of Vietnam, and share your passion for the Open Infrastructure of any topic (container, CI, deployment, edge computing, etc.), please let me know by replying to this email. Below is the tentative information of the event: - Date: 31 August 2019 - Location: Hanoi, Vietnam We are working with the OpenStack Foundation to organize the Upstream Institute at the day so this will be a great opportunity for potential contributors to come and learn. There is also a couple of PTLs and projects core members have shown their interest in visiting Hanoi for this event. We will send out the official call-for-presentations after we've done with the logistic vendors and It would be around the beginning of May or sooner. If you have any questions, please do not hesitate to contact me. See you in Hanoi :) Bests, On behalf of VietOpenInfra Group. P/S: Have a look at our last OpenInfra Day: https://2018.vietopenstack.org/ -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

Zuul project update 2019-02-25
by corvus＠inaugust.com 25 Feb '19

25 Feb '19

Matthieu is working on authenticated web API, and thus enabling tenant- or project-scoped privileged actions. The spec needs feedback, especially the authorization definition in Zuul: https://review.openstack.org/562321 There is also a review topic with WIP implementation of the current state of the spec: https://review.openstack.org/#/q/topic:zuul_admin_web Tristan worked on web and AMQP triggers: https://review.openstack.org/#/q/topic:webtrigger https://review.openstack.org/#/q/topic:amqp-trigger As well as adding python3 only node support: https://review.openstack.org/#/q/topic:python3-interpreter Fabien worked on an URLTrigger driver: https://review.openstack.org/635567/ I have gotten speculative docker images are working, but we need buildset node affinity between jobs and their paused parents to complete implementation, so I'll be working on that this week. -Jim

1 0

Escaping text in Zuul inventory file
by corvus＠inaugust.com 24 Feb '19

24 Feb '19

Hi, Recently Zuul was modified to include the change message (i.e., commit message in Gerrit, PR message in GitHub) as a Zuul variable: https://review.openstack.org/631207 Ansible applies jinja templating to the inventory file (which we rely on for variables in many jobs). If the change message incidentally included jinja escapes, then Ansible may fail to run due to syntax errors or undefined variables. To correct this, we agreed that allowing templating of the change message was not useful and should be disabled. An initial approach using "{% raw %}" / "{% endraw %}" was deemed too fragile (a change message with "{% endraw %}" in it would defeat the fix). So we have merged this change which uses an Ansible-specific YAML tag, "!unsafe", to mark the string as untrusted input which should not be templated: https://review.openstack.org/633930 This appears to be an elegant and complete solution. Yet before we release the next version of Zuul with this, I think we should consider possible ramifications a bit more. I can think of two things that including YAML tags in the inventory *might* cause problems with, and I'd like input on whether folks think these could be actual problems, or are, instead, easily overcome. And of course, if you think of other potential problems. First, the YAML tag may make it more difficult for users who perform automatic processing of inventory files collected after the job runs. I know of know examples of that myself, and it seems like it should be safe for us to say that if you're going to parse an Ansible YAML inventory file, you should be using a YAML parser that understands Ansible YAML tags. But perhaps someone knows of why this would be an undue hardship. The second is really a special case of the first. As our build page in the Zuul web UI continues to become more sophisticated, we might want to have it parse the inventory file much as it is now currently parsing the job-output.json file. I don't recall any discussions of this, but if we think it's likely, we should probably make sure that any Javascript YAML parser we might use could handle the tag. If we think that these issues, or any others that folks may think of, make it worth avoiding the !unsafe tag, we could solve the problem by base64 encoding the change message. Ansible has convenient jinja filters for base64 decoding, and in fact, Ansible modules such as slurp provide data in base64-encoded form. It would be easy for a job which needed to inspect the change message to do so by running it through the b64decode filter first. However, if we think these issues are not blockers, the !unsafe tag presents the simplest and most human-readable approach. -Jim

6 7

[all] Forum Submissions are Open!
by Kendall Nelson 22 Feb '19

22 Feb '19

Hello Everyone! We are now accepting Forum [1] submissions for the 2019 Open Infrastructure Summit in Denver [2]. Please submit your ideas through the Summit CFP tool [3] through March 8th. Don't forget to put your brainstorming etherpad up on the Denver Forum page [4]. This is not a classic conference track with speakers and presentations. OSF community members (participants in development teams, operators, working groups, SIGs, and other interested individuals) discuss the topics they want to cover and get alignment on and we welcome your participation. The Forum is your opportunity to help shape the development of future project releases. More information about the Forum [1]. The timeline for submissions is as follows: Feb 22nd | Formal topic submission tool opens: https://www.openstack.org/summit/denver-2019/call-for-presentations. March 8th | Deadline for proposing Forum topics. Scheduling committee meeting to make draft agenda. March 22nd | Draft Forum schedule published. Crowd sourced session conflict detection. Forum promotion begins. March 29th | Scheduling committee final meeting April 5th | Forum schedule final April 29th-May 1st | Forum Time! If you have questions or concerns, please reach out to speakersupport(a)openstack.org. Cheers, Kendall Nelson (diablo_rojo) [1] https://wiki.openstack.org/wiki/Forum [2] https://www.openstack.org/summit/denver-2019/ [3] https://www.openstack.org/summit/denver-2019/call-for-presentations [4] https://wiki.openstack.org/wiki/Forum/Denver2019

1 0

Using add-build-sshkey with static node
by Tristan Cacqueray 20 Feb '19

20 Feb '19

Hello, The add-build-sshkey isn't great with static node because the key added to the authorized_keys isn't removed if the remove-build-sshkey doesn't run. This results in key being leaked in authorized_keys without bound. Thus I proposed to add an option to cleanup keys before adding a new one: https://review.openstack.org/632620 . However this isn't great for static node that can be used by more than one job concurrently (multi-slot). Though, multi-slot already needs special trick to isolate workspaces and it seems like many other roles assume the node is dedicated to the job. Multi-slot node usage could be improved by using a dedicated user for each job, e.g. the operator would create zuul-%d user, and nodepool would set unique username for each zknode. In the meantime, can we please consider 632620 as this works well for single user static node. Regards, -Tristan

1 0

Zuul talks at Open Infrastructure Summit Denver in April
by Claire Massey 20 Feb '19

20 Feb '19

Hey Zuul community, The agenda is now live for the Open Infrastructure Summit and there are quite a few Zuul talks - congratulations to all of the speakers! View the agenda for the Open Infrastructure Summit Denver <https://www.openstack.org/summit/denver-2019/summit-schedule#day=2019-04-29>. Zuul sessions include: Moving your testing infrastructure from Jenkins to Zuul Unleashing the power of Fabric: Orchestrating new performance features for SR-IOV VNFs Getting a Neural Network Up and Running with OpenLab Best Practice to Run Zuul on Kubernetes Profiling and Optimizing Container Image Builds Digital Transformation in the Finance Industry If you haven’t already registered for the Summit, you’ll want to do so now before prices increase on February 27! Register here <https://openinfrasummitandptgdenver.eventbrite.com/>. I’ll continue to share more information about the Summit as the date approaches. Let me know if you have any questions. Thanks, Claire

1 0

Zuul/Nodepool tracing
by Simon.Westphahl＠bmw.de 20 Feb '19

20 Feb '19

Hi, recently I was getting sick of grepping through the logs of scheduler, executor and nodepool to debug an issue. My main problem was that there was no single identifier that I could use to find all logs that are related to a specific change. You have to look for the change/PR to find the matching 'Change' object. Then use the found object id to continue searching for the node request id, and so on. I decided to try to add tracing[0] to Zuul, as I was hoping that would simplify my use-case. For this I used the OpenTracing Python library[1] with Jaeger[2][3] as the trace backend (both hosted by the CNCF). Proof of concept patches for Zuul and Nodepool are available at [4] and [5]. You can also find some screenshots at [6]. Without initializing a concrete tracing backend (e.g. Jaeger) the tracing API will be a noop. So this should not impact the performance of Zuul/Nodepool in a significant way. The main downside of tracing is probably that you need to add instrumentation to the code. Tracing is of course not only useful for debugging issues but also e.g. for performance profiling. Curious to hear what you guys think! - Simon [0] https://opentracing.io/docs/overview/ [1] https://github.com/opentracing/opentracing-python [2] https://www.jaegertracing.io/ [3] https://github.com/jaegertracing/jaeger-client-python [4] https://review.openstack.org/#/c/637505/ [5] https://review.openstack.org/#/c/637506/ [6] https://imgur.com/gallery/00FTNej

4 4

[all] Denver Forum Brainstorming
by Kendall Nelson 19 Feb '19

19 Feb '19

Hello Everyone! Welcome to the topic selection process for our Forum in Denver! This is not a classic conference track with speakers and presentations. OSF community members (participants in development teams, operators, working groups, SIGs, and other interested individuals) discuss the topics they want to cover and get alignment on and we welcome your participation. The Forum is your opportunity to help shape the development of future project releases. For OpenStack Denver marks the beginning of Train’s release cycle, where ideas and requirements will be gathered. We should come armed with feedback from the upcoming Stein release if at all possible. We aim to ensure the broadest coverage of topics that will allow for multiple parts of the community getting together to discuss key areas within our community/projects. For OSF Projects (StarlingX, Zuul, Airship, Kata Containers) As a refresher, the idea is to gather ideas and requirements for your project’s upcoming release. Look to https://wiki.openstack.org/wiki/Forum for an idea of how to structure fishbowls and discussions for your project. The idea is to ensure the broadest coverage of topics, while allowing for the project community to discuss critical areas of concern. To make sure we are presenting the best topics for discussion, we have asked representatives of each of your projects to help us out in the Forum selection process. There are two stages to the brainstorming: 1.If you haven’t already, its encouraged that you set up an etherpad with your team and start discussing ideas you'd like to talk about at the Forum and work out which ones to submit. 2. On the 22nd of February, we will open up a more formal web-based tool for you to submit abstracts for the most popular sessions that came out of your brainstorming. Make an etherpad and add it to the list at: https://wiki.openstack.org/wiki/Forum/Denver2018 <https://wiki.openstack.org/wiki/Forum/Berlin2018> This is your opportunity to think outside the box and talk with other projects, groups, and individuals that you might not see during Summit sessions. Look for interested parties to collaborate with and share your ideas. Examples of typical sessions that make for a great Forum: - Strategic, whole-of-community discussions, to think about the big picture, including beyond just one release cycle and new technologies - eg Making OpenStack One Platform for containers/VMs/Bare Metal (Strategic session) the entire community congregates to share opinions on how to make OpenStack achieve its integration engine goal - Cross-project sessions, in a similar vein to what has happened at past forums, but with increased emphasis on issues that are of relevant to all areas of the community - eg Rolling Upgrades at Scale (Cross-Project session) – the Large Deployments Team collaborates with Nova, Cinder and Keystone to tackle issues that come up with rolling upgrades when there’s a large number of machines. - Project-specific sessions, where community members most interested in a specific project can discuss their experience with the project over the last release and provide feedback, collaborate on priorities, and present or generate 'blue sky' ideas for the next release - eg Neutron Pain Points (Project-Specific session) – Co-organized by neutron developers and users. Neutron developers bring some specific questions about implementation and usage. Neutron users bring feedback from the latest release. All community members interested in Neutron discuss ideas about the future. Think about what kind of session ideas might end up as: Project-specific, cross-project or strategic/whole-of-community discussions. There'll be more slots for the latter two, so do try and think outside the box! This part of the process is where we gather broad community consensus - in theory the second part is just about fitting in as many of the good ideas into the schedule as we can. Further details about the forum can be found at: https://wiki.openstack.org/wiki/Forum Thanks all! Kendall Nelson, on behalf of the OpenStack Foundation, User Committee & Technical Committee

1 0

Job at periodic pipeline with "files" section
by Felix Enrique Llorente Pastora 19 Feb '19

19 Feb '19

Hi All, Here at tripleo CI we have try to run a tripleo job with "files" section from parent and it does not run at periodic, after doing some testing with zuul quickstart looks like it does not work, kind of make sense. Have open a bug here https://storyboard.openstack.org/#!/story/2005040, but don't know if it make sense to fix this. BR -- Quique Llorente Openstack TripleO CI

2 4

zuul-preview - a helper service for JAMstack preview sites
by Monty Taylor 14 Feb '19

14 Feb '19

Heya, One of the cool things we do in Zuul jobs are our static html preview sites. We use this for zuul-dashboard preview, as well as storyboard, docs builds and others. Recently some of us in OpenDev land have been working with the OpenStack Foundation folks to support using netlify-cms with gerrit, which lets people who would prefer to edit web content via vim/emacs via git collaborate with those who would prefer to do such a thing in a visual CMS-like manner. It's really cool - except, one of the things that came out of it is the realization that a non-zero number of static-site-generators and/or JAMstack applications make some assumptions that they exist at the root of a URL. While we could argue that it would be better if they didn't make that assumption, supporting them would be potentially friendlier. To that end, over the weekend Jim and I hacked up a service using Apache's mod_rewrite and its ability to call out to a helper program to find the target URL. We wrote a program that takes the input from apache, hits zuul's REST API and returns the appropriate url. With that, given a url like: http://site.926bb0aaddad4bc3853269451e115dcb.openstack.preview.opendev.org/ It can serve the content published on the fileserver, or in swift - basically allowing us to serve preview content as-if it was at the root of a url without sacrifcing the zuul pattern of jobs being the ones to tell zuul where they published the content. It is a small program bundled with pre-configured Apache in a Docker container, so anyone who wants to run this at their site can simply run the published docker container as-is. We think it would be appropriate for this service to be part of Zuul in general so that it's easily available to sites which want to run it, and so we wanted to see what people thought about Zuul adopting it. https://github.com/emonty/upgraded-octo-giggle We wrote it in C++, for two reasons: 1) It's a performance sensitive service, so C++ is helpful. 2) We've talked about potentially writing some of zuul's components in not-python in the future. We're not broadly ready for that yet, but we thought having a simple program in C++ (that's not likely to get any more complex) but that goes things like REST and JSON interactions, would give us a basis for a more informed discussion later. So ... what do people think? Should the Zuul project adopt a small c++ service? Monty

8 13

Zuul-config reload
by Tomasz Szandała 13 Feb '19

13 Feb '19

Greetings, how can I reload main configuration repository? It seems like my commits to Gerrit's zuul-config still requires to restart zuul's docker (I am using docker-compose setup). Kind regards, Tomasz

2 3