Re: [OpenStack-Infra] [openstack-dev] There is no Jenkins, only Zuul
Are 3d party CIs affected by this change and if yes how? What's the recommendation for newly created 3rd party CIs - should they use new zuul only or it's fine to use existing (and tested) jenkins+zuul configuration? Second question - if jobs are to be launched by zuul+ansible, how will the worker host be chosen, by ansible-launcher? (normally as I understand Jenkins master takes care of deciding which hosts are free to run jobs) Are there any specs about way of managing workers (adding/removing, setting # of executors)? Thank you. -marek -- Marek Zawadzki Mirantis Containerized Control Plane Team ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [openstack-dev] There is no Jenkins, only Zuul
On Mon, Jun 20, 2016 at 01:47:24PM +0200, Marek Zawadzki wrote: > Are 3d party CIs affected by this change and if yes how? > What's the recommendation for newly created 3rd party CIs - should they use > new zuul only or it's fine to use existing (and tested) jenkins+zuul > configuration? > 3rd party CI should not be affected by recent changes. As there interface to our CI system is gerrit (review.openstack.org). Zuulv25 is really only meant to be consumed by openstack-infra as a stepping stone to zuulv3. At this time I would not recommend people update their CI systems to consume it. > Second question - if jobs are to be launched by zuul+ansible, how will the > worker host be chosen, by ansible-launcher? (normally as I understand > Jenkins master takes care of deciding which hosts are free to run jobs) > Are there any specs about way of managing workers (adding/removing, setting > # of executors)? > This was and still is controlled by nodepool[1]. Even when we used jenkins, nodepool was responsible for creating our jenkins slaves. Under zuulv25, this is still the case except they are called zuul workers now. [1] http://docs.openstack.org/infra/nodepool/ > Thank you. > > -marek > > -- > Marek Zawadzki > Mirantis Containerized Control Plane Team > > > ___ > 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
[OpenStack-Infra] [StoryBoard] StoryBoard Bug Squash 22nd-23rd June
Hi everyone! For one week only*, the StoryBoard bug squash is coming to an OpenStack community near you! That's right; from 11:00 UTC 22nd June, to 11:00 UTC 23rd June THIS week, the StoryBoard team will be making a critically-acclaimed appearance in #openstack-sprint. We'll be setting time aside to help new contributors and to smoosh as many pesky little bugs as possible. So come one, come all, and let's squash some bugs! As always, you can also catch us in #storyboard. You can also help with the effort by tagging smaller tasks as low-hanging-fruit in storyboard.openstack.org. We have a worklist-in-progress listing all such StoryBoard stories here: https://storyboard.openstack.org/#!/worklist/76 Feel free to ask any questions in #storyboard, and we hope to see you there! Best Wishes, Zara *every week, really, we just don't use #openstack-sprint most weeks. ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] [gear] Making Gear easier to consume ( less .encode() and .decode() )
As I have been converting Zuul and NodePool to python3, I have had to do a bunch of changes around encode() and decode() of strings since gear is (properly) an implementation of a protocol that requires binary data (rather than text_strings). What this has highlighted is that gear should be made a bit more friendly to use in the python world. We already explicitly assume a utf-8 encoding for when things are turned into "binary" when crafting the job object in certain cases [1]. I have discussed this with Jim Blair, and we both agree that the ability to still reference attributes such as "job.name" (in a simple manner that is straight forward), is important. Here is the outline of the change I'm proposing: * The main consumable part of gear (public classes) will convert the "string" data we assign ( name[2], unique[3]) into utf-8-encoded bytes via @property, @property.setter, and @property.getter for public consumption. * Arguments are explicitly supposed to be a binary_blob [4]. I am unsure if this should also be automatically converted *or* if it should be the inverse, .arguments and .arguments_string ? * Internally gear will reference the encoded bits via the underlying _binary form, which will allow direct access to a non-"string" form of the data itself in the case that there is interesting things that need to be handled via binary packing (for example) instead of "stringified" versions. * For compatibility the main @property.setter will handle either binary_type or string_type (so we don't break everyone). * The "_binary" will enforce that the data with be a binary_type only. I think this can be done in a single release of gear with minimal impact to those using it. For what it is worth, it is unlikely that anyone has used gear extensively in python3 as of yet because of recent bug fixes that addressed py2->py3 compat issues around dict.values() and similar list() -> iter() changes. See the one question in the above proposal for "arguments". [1] https://github.com/openstack-infra/gear/blob/59d29104cb9c370e49b44f313e568bd43b172e1b/gear/__init__.py#L86 [2] https://github.com/openstack-infra/gear/blob/59d29104cb9c370e49b44f313e568bd43b172e1b/gear/__init__.py#L2054 [3] https://github.com/openstack-infra/gear/blob/59d29104cb9c370e49b44f313e568bd43b172e1b/gear/__init__.py#L2058 [4] https://github.com/openstack-infra/gear/blob/59d29104cb9c370e49b44f313e568bd43b172e1b/gear/__init__.py#L2056 Thanks, --Morgan ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] [Infra] Meeting Tuesday June 21st at 19:00 UTC
Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday June 21st, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting Anyone is welcome to to add agenda items and everyone interested in the project infrastructure and process surrounding automated testing and deployment is encouraged to attend. In case you missed it or would like a refresher, the meeting minutes and full logs from our last meeting are available: Minutes: http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-06-14-19.02.html Minutes (text): http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-06-14-19.02.txt Log: http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-06-14-19.02.log.html -- Elizabeth Krumbach Joseph || Lyz || pleia2 ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Infra priorities and spec cleanup
On 2016-06-08 23:08:16 +1000 (+1000), Joshua Hesketh wrote: > On Mon, Jun 6, 2016 at 9:21 AM, Jeremy Stanley wrote: > [...] > > Store Build Logs in Swift > [...] > > 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. [...] > Additionally the urgency of this spec seems to have been reduced (due to > limiting the retention on logs). We should perhaps reconsider if it's a > priority spec or not after we've decided on a path forward. That makes sense, though I think we can agree the original spec (and accompanying implementation) has ceased to be treated as a priority so it's a bit disingenuous to leave it on our priority list. Anyway, I've pushed a cleanup/update change at https://review.openstack.org/331903 which: * removes logs-in-swift * replaces maniphest with task-tracker * adds nodepool-zookeeper-workers due to its coupling with zuulv3 * updates the Gerrit query string/URL accordingly I'll put it on the meeting agenda now for formal council vote this week. If approved, this leaves us at 6 priority specs, so if we consider that we were pretty well saturated at 8 last cycle, we can also discuss adding a couple more we expect to be spending significant time on over the remainder of this cycle or whether sticking with those 6 is perhaps better for focusing our efforts? -- Jeremy Stanley signature.asc Description: Digital signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
