From cboylan at sapwetik.org Mon Jan 4 21:08:18 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Mon, 04 Jan 2021 13:08:18 -0800 Subject: Meeting Agenda for January 5, 2021 Message-ID: <0a2e1e42-9e1c-465a-9015-2c5320ee8b08@www.fastmail.com> Happy New Year and welcome back. We will have a meeting tomorrow, though depending on attendance it may be on the less formal side of things. I figure we'll try to have an agenda though. Here is our agenda for the meeting on January 5, 2021 at 19:00UTC in #opendev: == 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/update-config-management.html Update Config Management] *** topic:update-cfg-mgmt *** Zuul as CD engine ** OpenDev *** Post Gerrit Upgrade Updates **** Configuration tuning ***** Using strong refs for jgit caches ***** Batch user groups and threads **** Zuul results table rendering (ianw 20210105) **** WIP changes (ianw 20210105) ***** This needs work in Zuul to not treat these changes as mergeable. *** Gerrit 3.3.1 includes the fix for Zuul *** Gitea 1.13.1 now available * General topics ** OpenDev Project Update for the Foundation Annual Report (clarkb 20210105) ** Bup and Borg Backups (clarkb 20210105) ** Splitting puppet else into specific infra-prod jobs (clarkb 20201208) *** Should be mostly mechanical *** Does it make sense to try and sprint this? Have several people work on getting it done in a short period of time? ** Trusty Upgrade Progress (clarkb 20200929) *** Wiki updates * Open discussion From cboylan at sapwetik.org Thu Jan 7 23:59:47 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Thu, 07 Jan 2021 15:59:47 -0800 Subject: Service Coordinator Nominations Message-ID: <578fc941-73e2-4aad-86f3-2a543316e0b0@www.fastmail.com> Hello everyone, It has been pointed out that in our governance document we stated we would elect a service coordinator every 6 months. I filled this role at the beginning of May 2020 which means we are overdue for a new election. The beginning of the year is always a bit slow so I figure we can give folks until January 31st at 23:59UTC to nominate themselves. Then if we need an election we can do that during the week from February 1st to February 8 at 23:59UTC. I've now been in this role (either as Service Coordinator or Infra PTL) a while. I think it would excellent to rotate in some new eyeballs and perspectives if possible. If you have interest but also have questions feel free to reach out. In order to avoid this slipping by in the future I'm going to go ahead and write down the dates for the next nomination period and election now: * Nominations July 12, 20201 - August 1, 2021 at 23:59 UTC * Election if necessary August 2 - August 9, 2021 at 23:59 UTC I think I got the math right. If I've got it wrong or you have other concerns feel free to bring them up on this thread and we can sort things out. I'm trying to balance giving people enough time to show interest at the beginning of the year while also not letting this languish for longer than it needs to. Then doing math for what 6 months from now will look like. Clark From iwienand at redhat.com Fri Jan 15 05:56:39 2021 From: iwienand at redhat.com (Ian Wienand) Date: Fri, 15 Jan 2021 16:56:39 +1100 Subject: OpenAFS timestamp rollover issues, discussion and plan Message-ID: <20210115055639.GA2973029@fedora19.localdomain> Hello, We were made aware of an issue relating to handling of a timestamp rollover affecting OpenAFS deployments [1] that in the worst case results in inability of the client and server to communicate. From the OpenAFS 1.8.7 release: It fixes a critical issue in the generation of Rx connection IDs that prevent Rx clients started after 14 Jan 2021 08:25:36 AM UTC from being able to successfully make connections. In addition to cache managers and client utilities, fileservers and database servers are also affected, since they initiate connections to (other) database servers during their normal operation. The issue occurs only at startup, while generating the initial connection ID, so cache managers or servers that were already running at the time in question will not be affected until they restart. The full extent of the issues for our particular circumstances is still somewhat unclear. We run a heterogeneous deployment with all clients under our control using 1.8.6 release, but all servers running 1.6 era packages from Ubuntu Xenial. My current understanding is that since we started our servers and clients before the problem time, we are currently unaffected. When we restart our servers, due to differences in the code with our 1.6 versions, the bug will manifest more as periodic/random-ish I/O failures rather than a complete inability to communicate. We have rebuilt our openafs packages with the required fixes and deployed these to all clients under our control. Thus if any client restarts for whatever reason, they will at least be using fixed code. Some clients we have restarted just to ensure sanity of the new version against the existing severs (so far seems good). All clients have been checked for deployment of these new packages. We do not expect issues, but will monitor this situation. This leaves us with the server side. We have been told there are no fixes for the 1.6 servers planned. We do not have a wonderful answer here, unfortunately. We have planned to move our AFS infrastructure off the Xenial hosts it runs on for some time. These servers are all deployed with legacy puppet, something none of us want to spend significant time hacking on. There is also the small matter that 1.6 to 1.8 upgrades are not terribly well documented, to say the least. While we don't intend on restarting the servers, from time to time the cloud provider needs to migrate things or has other issues that affect uptime; we can't predict this other than it will happen, eventually. It seems our best option here is to take some down-time of the AFS services and perform a manual, in-place upgrade of the existing servers to 1.8 code. We will freeze these from ongoing automated config managment (puppet). This will allow us to deploy and evaluate 1.8 servers and keep with the principle of "change one thing at a time". Once we are in a steady state, we should have enough redundancy that we can replace the servers one-at-a-time with no, or very little, downtime. This gives us time to write, test and review Ansible based deployment as usual. When we do switch in new Focal based servers, we have the advantage we are not also trying to change the AFS version too. In some ways, it works out well (something about lemons and lemonade). We usually try to have a rollback plan with any upgrades. Since 1.6 is not getting updates, and as far as I know we still do not have the technology to move reality backwards in the time continum before the problem rollover time (if I do figure out time travel, I will be sure to pre-respond to this message that it can be ignored) our revert plans seem limited. However, we will be no worse off than if the servers decided to reboot themselves now. In it's defence, this is not new code; 1.8.0 came out early 2018 and we have been using 1.8 clients since we started integrating arm64. The queues are very deep at the moment, so we'd obviously like to minimise downtime. I'd suggest that I could start looking at this around 2021-01-17 21:00UTC, following the plan layed out in [2], which interested parties should definitely review. This should hopefully be a quiet time, and give us a decent runway if we do hit issues. -i [1] https://lists.openafs.org/pipermail/openafs-info/2021-January/043013.html [2] https://etherpad.opendev.org/p/infra-openafs-1.8 From fungi at yuggoth.org Fri Jan 15 19:24:22 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 15 Jan 2021 19:24:22 +0000 Subject: OpenAFS timestamp rollover issues, discussion and plan In-Reply-To: <20210115055639.GA2973029@fedora19.localdomain> References: <20210115055639.GA2973029@fedora19.localdomain> Message-ID: <20210115192422.42run7xfyzwh3vbm@yuggoth.org> On 2021-01-15 16:56:39 +1100 (+1100), Ian Wienand wrote: [...] > We have been told there are no fixes for the 1.6 servers planned. > We do not have a wonderful answer here, unfortunately. [...] Per subsequent discussion in IRC today, the problem (at least for 1.6) stems from the number of zero bits in the timestamp leading to weak/repeating ID generation, and will cease to present a problem around the end of the month. > It seems our best option here is to take some down-time of the AFS > services and perform a manual, in-place upgrade of the existing > servers to 1.8 code. We will freeze these from ongoing automated > config managment (puppet). This will allow us to deploy and evaluate > 1.8 servers and keep with the principle of "change one thing at a > time". Once we are in a steady state, we should have enough > redundancy that we can replace the servers one-at-a-time with no, or > very little, downtime. This gives us time to write, test and review > Ansible based deployment as usual. When we do switch in new Focal > based servers, we have the advantage we are not also trying to change > the AFS version too. In some ways, it works out well (something about > lemons and lemonade). It turns out 1.6 and 1.8 share the same protocols and on-disk volume format, and the old and new keystores for them can coexist side-by-side as well, so we very well may be able to just do this in-place or with a rolling/piecemeal upgrade if we want. > We usually try to have a rollback plan with any upgrades. Since 1.6 > is not getting updates, and as far as I know we still do not have the > technology to move reality backwards in the time continum before the > problem rollover time (if I do figure out time travel, I will be sure > to pre-respond to this message that it can be ignored) our revert > plans seem limited. [...] Given the new information we have about the bug ceasing to be a problem in a couple of weeks, and also the ability to switch freely between and mix 1.6 and 1.8 servers, it sounds like a rollback won't necessarily be intractable if we decide it's warranted. > I'd suggest that I could start looking at this around 2021-01-17 > 21:00UTC, following the plan layed out in [2], which interested > parties should definitely review. This should hopefully be a quiet > time, and give us a decent runway if we do hit issues. [...] This sounds reasonable time-wise, but also it seems like we might be able to reduce the impact/outage and can take it slower if we need. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From cboylan at sapwetik.org Fri Jan 15 20:42:05 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Fri, 15 Jan 2021 12:42:05 -0800 Subject: OpenAFS timestamp rollover issues, discussion and plan In-Reply-To: <20210115192422.42run7xfyzwh3vbm@yuggoth.org> References: <20210115055639.GA2973029@fedora19.localdomain> <20210115192422.42run7xfyzwh3vbm@yuggoth.org> Message-ID: <928a2be0-d4d4-4bd2-964a-44c4cf6e7aff@www.fastmail.com> On Fri, Jan 15, 2021, at 11:24 AM, Jeremy Stanley wrote: > On 2021-01-15 16:56:39 +1100 (+1100), Ian Wienand wrote: > [...] > > We have been told there are no fixes for the 1.6 servers planned. > > We do not have a wonderful answer here, unfortunately. > [...] > > Per subsequent discussion in IRC today, the problem (at least for > 1.6) stems from the number of zero bits in the timestamp leading to > weak/repeating ID generation, and will cease to present a problem > around the end of the month. > > > It seems our best option here is to take some down-time of the AFS > > services and perform a manual, in-place upgrade of the existing > > servers to 1.8 code. We will freeze these from ongoing automated > > config managment (puppet). This will allow us to deploy and evaluate > > 1.8 servers and keep with the principle of "change one thing at a > > time". Once we are in a steady state, we should have enough > > redundancy that we can replace the servers one-at-a-time with no, or > > very little, downtime. This gives us time to write, test and review > > Ansible based deployment as usual. When we do switch in new Focal > > based servers, we have the advantage we are not also trying to change > > the AFS version too. In some ways, it works out well (something about > > lemons and lemonade). > > It turns out 1.6 and 1.8 share the same protocols and on-disk volume > format, and the old and new keystores for them can coexist > side-by-side as well, so we very well may be able to just do this > in-place or with a rolling/piecemeal upgrade if we want. > > > We usually try to have a rollback plan with any upgrades. Since 1.6 > > is not getting updates, and as far as I know we still do not have the > > technology to move reality backwards in the time continum before the > > problem rollover time (if I do figure out time travel, I will be sure > > to pre-respond to this message that it can be ignored) our revert > > plans seem limited. > [...] > > Given the new information we have about the bug ceasing to be a > problem in a couple of weeks, and also the ability to switch freely > between and mix 1.6 and 1.8 servers, it sounds like a rollback won't > necessarily be intractable if we decide it's warranted. > > > I'd suggest that I could start looking at this around 2021-01-17 > > 21:00UTC, following the plan layed out in [2], which interested > > parties should definitely review. This should hopefully be a quiet > > time, and give us a decent runway if we do hit issues. > [...] > > This sounds reasonable time-wise, but also it seems like we might be > able to reduce the impact/outage and can take it slower if we need. Yes, rather than doing it all in one go with a downtime maybe we should instead start with afs01.ord or afs02.dfw (the more secondary servers), ensure that server is happy then roll through things in a rolling fashion? We have documented that general process here: https://docs.opendev.org/opendev/system-config/latest/afs.html#no-outage-server-maintenance. It does appear that the existing releases may complicate this process though as we typically want to have the RW volume on active servers? > -- > Jeremy Stanley > > Attachments: > * signature.asc From iwienand at redhat.com Fri Jan 15 22:28:33 2021 From: iwienand at redhat.com (Ian Wienand) Date: Sat, 16 Jan 2021 09:28:33 +1100 Subject: OpenAFS timestamp rollover issues, discussion and plan In-Reply-To: <928a2be0-d4d4-4bd2-964a-44c4cf6e7aff@www.fastmail.com> References: <20210115055639.GA2973029@fedora19.localdomain> <20210115192422.42run7xfyzwh3vbm@yuggoth.org> <928a2be0-d4d4-4bd2-964a-44c4cf6e7aff@www.fastmail.com> Message-ID: <20210115222833.GA3057057@fedora19.localdomain> On Fri, Jan 15, 2021 at 12:42:05PM -0800, Clark Boylan wrote: > > Given the new information we have about the bug ceasing to be a > > problem in a couple of weeks, and also the ability to switch freely > > between and mix 1.6 and 1.8 servers, it sounds like a rollback won't > > necessarily be intractable if we decide it's warranted. > Yes, rather than doing it all in one go with a downtime maybe we > should instead start with afs01.ord or afs02.dfw (the more secondary > servers), ensure that server is happy then roll through things in a > rolling fashion? We have documented that general process here: > https://docs.opendev.org/opendev/system-config/latest/afs.html#no-outage-server-maintenance. It > does appear that the existing releases may complicate this process > though as we typically want to have the RW volume on active servers? I agree with this; we can start with one server manually to validate that 1.6 and 1.8 do actually co-exist as happily as advertised. As mentioned in the etherpad I can work on things like new key distribution first as well, which is a good first thing to start running ansible with. I think we need to keep the manual upgrade plan in our pocket in case of a unexpected restart before the end of January. -i From cboylan at sapwetik.org Mon Jan 18 20:44:43 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Mon, 18 Jan 2021 12:44:43 -0800 Subject: Team Meeting Agenda for January 19, 2021 Message-ID: <7e366044-6bf5-4694-b911-840f347d5821@www.fastmail.com> We will meet January 19, 2021 at 19:00UTC in #opendev-meeting with this agenda: == 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/update-config-management.html Update Config Management] *** topic:update-cfg-mgmt *** Zuul as CD engine ** OpenDev *** Service Coordinator position nominations **** http://lists.opendev.org/pipermail/service-discuss/2021-January/000161.html *** Zuul results table rendering (ianw 20210105) **** https://review.opendev.org/q/topic:%22gerrit-admin-user%22+status:open *** WIP changes (ianw 20210105) **** Zuul should now support these properly. We need to retest. *** Gerrit 3.3.1 includes the fix for Zuul *** Configuration tuning **** Using strong refs for jgit caches **** Batch user groups and threads *** Gitea 1.13.1 now available **** https://review.opendev.org/c/opendev/system-config/+/769226 * General topics ** OpenAFS cluster status (clarkb 20210119) *** New packages built for CentOS *** Need to sort out openafs-client installation on Debian Buster *** Are we properly installing openafs-client on Xenial? *** https://review.opendev.org/c/opendev/system-config/+/771268 ** Picking up steam on Puppet -> Ansible rewrites (clarkb 20210119) *** Enable Xenial -> Bionic/Focal system upgrades ** Discuss infra-core (on behalf of OpenStack) (mnaser) ** two-review rule impact on low-activity projects (zbr 20210115) *** projects like git-review rely on infra team and delay changes *** risks for enabling exceptions? how could we expose these in gerrit? *** apparently that issue is affecting multiple projects, maybe we can think about a generic solution? ** Bup and Borg Backups (clarkb 20210105) * Open discussion From narjes.bessghaier.1 at ens.etsmtl.ca Tue Jan 19 18:08:10 2021 From: narjes.bessghaier.1 at ens.etsmtl.ca (Bessghaier, Narjes) Date: Tue, 19 Jan 2021 18:08:10 +0000 Subject: Requesting help with OpenStack configuration files Message-ID: Dear OpenStack team, I’m a Ph.D. student in software engineering at the ETS Montreal, University of Quebec working on the quality and configuration of web-based software systems. I’m particularly interested in analyzing configuration files from different OpenStack files. One of the main challenges I am currently facing is the proper identification of configuration files. I’m mostly confused between the python files used for production and the python files used for configuration. I am kindly requesting your precious help with the following questions: 1- How to distinguish between python files used for configuration and python files used for production? It will be very helpful if there are some configuration-based patterns (eg, textual patterns or expressions) that we can find in python files to help us distinguish between source code and configuration files? 2- Certain python files use the oslo_config to access and define configuration options. Could "all" these python files be considered as configuration files? For example, the following python file of the keystone project: keystone/keystone/conf/auth.py, is it considered a source code or a configuration file? 3- Why are there different source code and configuration repositories for OpenStack projects (eg, nova and puppet-nova)? For instance, does the OpenStack-nova service have some configuration files in its repository and have the puppet-nova as a separate configuration repository as well? Thank you very much in advance for your time and your help! Kind regards, Narjes Bessghaier Narjes Bessghaier Ph.D student in Software Engineering École de Technologie Supérieure (ETS)| University of Quebec Montreal, Canada narjes.bessghaier.1 at ens.etsmtl.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Tue Jan 19 20:29:34 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 19 Jan 2021 20:29:34 +0000 Subject: Requesting help with OpenStack configuration files In-Reply-To: References: Message-ID: <20210119202934.lpjixgwjddtqstsp@yuggoth.org> On 2021-01-19 18:08:10 +0000 (+0000), Bessghaier, Narjes wrote: > I’m a Ph.D. student in software engineering at the ETS Montreal, > University of Quebec working on the quality and configuration of > web-based software systems. I’m particularly interested in > analyzing configuration files from different OpenStack files. [...] This mailing list describes itself as "Use, maintenance and development of OpenDev services." That is, the services which make up the OpenDev Collaboratory at https://opendev.org/ (code review, continuous integration, collaborative editing, and so on). You should probably as your question on an OpenStack mailing list instead, like: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss Hope that helps. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From kennelson11 at gmail.com Thu Jan 21 22:05:33 2021 From: kennelson11 at gmail.com (Kendall Nelson) Date: Thu, 21 Jan 2021 14:05:33 -0800 Subject: Fwd: [All][StoryBoard] Angular.js Alternatives In-Reply-To: References: Message-ID: Hello Everyone! The StoryBoard team is looking at alternatives to Angular.js since its going end of life. After some research, we've boiled all the options down to two possibilities: Vue.js or React.js I am diving more deeply into researching those two options this week, but any opinions or feedback on your experiences with either of them would be helpful! Here is the etherpad with our research so far[3]. Feel free to add opinions there or in response to this thread! -Kendall Nelson (diablo_rojo) & The StoryBoard Team [1] https://vuejs.org/ [2] https://reactjs.org/ [3] https://etherpad.opendev.org/p/replace-angularjs-storyboard-research -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Thu Jan 21 22:17:04 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 21 Jan 2021 22:17:04 +0000 Subject: Fwd: [All][StoryBoard] Angular.js Alternatives In-Reply-To: References: Message-ID: <20210121221704.dgt3n4r2ib5qkjxa@yuggoth.org> On 2021-01-21 14:05:33 -0800 (-0800), Kendall Nelson wrote: > The StoryBoard team is looking at alternatives to Angular.js since its > going end of life. [...] See also the minutes and log from the weekly meeting where initial discussion of these points took place: http://eavesdrop.openstack.org/meetings/storyboard/2021/storyboard.2021-01-21-18.02.html -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jim at acmegating.com Thu Jan 21 22:29:05 2021 From: jim at acmegating.com (James E. Blair) Date: Thu, 21 Jan 2021 14:29:05 -0800 Subject: Fwd: [All][StoryBoard] Angular.js Alternatives In-Reply-To: (Kendall Nelson's message of "Thu, 21 Jan 2021 14:05:33 -0800") References: Message-ID: <87ft2t53gu.fsf@meyer.lemoncheese.net> Kendall Nelson writes: > Hello Everyone! > > The StoryBoard team is looking at alternatives to Angular.js since its > going end of life. After some research, we've boiled all the options down > to two possibilities: > > Vue.js > > or > > React.js > > I am diving more deeply into researching those two options this week, but > any opinions or feedback on your experiences with either of them would be > helpful! > > Here is the etherpad with our research so far[3]. > > Feel free to add opinions there or in response to this thread! > > -Kendall Nelson (diablo_rojo) & The StoryBoard Team > > [1] https://vuejs.org/ > [2] https://reactjs.org/ > [3] https://etherpad.opendev.org/p/replace-angularjs-storyboard-research React +1 I've heard good things about Vue and I think it's very comparable to React, and probably a little easier to learn and work with, but even so, React has a huge amount of support and has made significant strides in becoming easier to use, to the point that it may be a tossup. Given that, the large React ecosystem and support base tips the scale for me. Overlap with Zuul means there's a bunch of code you can copy (and eventually vice versa, so don't consider this an impartial recommendation!). Also test jobs, framework, docs etc. See https://zuul-ci.org/docs/zuul/reference/developer/javascript.html and https://www.softwarefactory-project.io/react-for-python-developers.html for uniquely local perspectives on getting started with react. Finally, a relatively new development in the react space is the "redux toolkit". Redux is the standard-ish way of dealing with client-side state and transitions in react (and we use it in Zuul), but it's easily the least straightforward part of the whole system. Redux toolkit handles a whole bunch of the boilerplate there and makes it almost easy to follow. At some point I'd like to rework Zuul's use of redux to use the toolkit, but haven't gotten around to it yet. If storyboard uses react and redux, give that a good look; it's much easier to start with that. -Jim From hashar at free.fr Thu Jan 21 23:08:16 2021 From: hashar at free.fr (Antoine Musso) Date: Fri, 22 Jan 2021 00:08:16 +0100 Subject: Fwd: [All][StoryBoard] Angular.js Alternatives In-Reply-To: References: Message-ID: Le 21/01/2021 à 23:05, Kendall Nelson a écrit : > Hello Everyone! > > The StoryBoard team is looking at alternatives to Angular.js since its > going end of life. After some research, we've boiled all the options > down to two possibilities: > > Vue.js > > or > > React.js > > I am diving more deeply into researching those two options this week, > but any opinions or feedback on your experiences with either of them > would be helpful! ... Hello, Wikimedia has picked up Vue.js.  It has been evaluated based on a fairly large of requirements and challenged against over frameworks with react.js being the main if not the sole challenger. Lot of the work happened in 2019 eventually leading to an introduction presentation by the working group late 2019: https://upload.wikimedia.org/wikipedia/commons/f/fd/FAWG_Demo.pdf Formally agreeing on Vue.js went through a RFC which is https://phabricator.wikimedia.org/T241180   . The description at the top is the proposal to adopt Vue.js. The comments have all the discussions with arguments for both sides. The project lead of Vue.js (Evan You) came and clarified a few key points, which is always much appreciated. There some interesting exchanges regarding React. That should be a good read (grab several coffees). There are some more discussions on Hacker News which involved Wikimedia employees and it gives some more context: https://news.ycombinator.com/item?id=22625556 I can ask internally whether anyone at Wikimedia would be open for a round of discussion with your group.  Or feel free to reach out to them directly on my behalf. A few other random thoughts: - Gerrit UI is based on Polymer, Zuul has a dashboard using React. - If I got it right: Storyboard was written to replace Launchpad Blueprint in the context of OpenStack development.  OpenStack Horizon uses Angular and I am assuming a lot of other OS projects do as well.  Maybe there the framework selection for Storyboard should be made in coordination with the rest of the ecosystem using it? - if a rewrite is a lot of work, there is an opportunity to pick an entirely different system. But I guess Storyboard is adhoc for the unique workflows you have to support. Antoine "hashar" Musso Wikimedia Release Engineering -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Fri Jan 22 09:28:29 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Fri, 22 Jan 2021 10:28:29 +0100 Subject: [All][StoryBoard] Angular.js Alternatives In-Reply-To: References: Message-ID: On Thu, Jan 21, 2021 at 10:24 PM Kendall Nelson wrote: > > Hello Everyone! > > The StoryBoard team is looking at alternatives to Angular.js since its going end of life. After some research, we've boiled all the options down to two possibilities: > > Vue.js > > or > > React.js Hello, Kendall! This is likely the toughest question in the frontend universe at the moment. Both solutions are very well thought out and have solid ecosystems. Based on observed productivity both are good choices. Personally, I have done more Vue than React. I have added a few points in the etherpad. Angular is not a bad choice either but it involves much stronger bonding with the final product. The others leave more freedom of choice. As for the verdict, I am afraid the best solution would be to run voting for parties interested in Storyboard development and just stick to the poll winner. -yoctozepto > I am diving more deeply into researching those two options this week, but any opinions or feedback on your experiences with either of them would be helpful! > > Here is the etherpad with our research so far[3]. > > Feel free to add opinions there or in response to this thread! > > -Kendall Nelson (diablo_rojo) & The StoryBoard Team > > [1] https://vuejs.org/ > [2] https://reactjs.org/ > [3] https://etherpad.opendev.org/p/replace-angularjs-storyboard-research From cboylan at sapwetik.org Mon Jan 25 23:38:45 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Mon, 25 Jan 2021 15:38:45 -0800 Subject: Meeting agenda for January 26, 2021 Message-ID: We will meet on January 26, 2021 at 19:00 UTC in #opendev-meeting with this agenda: == 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/update-config-management.html Update Config Management] *** topic:update-cfg-mgmt *** Zuul as CD engine ** OpenDev *** Service Coordinator position nominations **** http://lists.opendev.org/pipermail/service-discuss/2021-January/000161.html less than a week remaining. *** Gerrit account and group inconsistencies **** ~1 group has a subgroup membership loop. **** We have ~109 accounts with preferred email addresses that don't have a matching external id ***** Some of these are inactive accounts that we can more properly retire, others are accounts that can be set to inactive due to lack of external ids, some have email addresses we might convert to preferred email address, and others will need proper digging. **** We have ~642 accounts with conflicting emails in their external ids. This needs more investigating to better understand the fix for. **** Need to correct the ~642 external id issues before we can push updates to refs/meta/external-ids with Gerrit online. **** Workaround is we can stop gerrit, push to external ids directly, reindex accounts (and groups?), start gerrit, then clear accounts caches (and groups caches?) *** WIP changes (ianw 20210105) **** Zuul should now support these properly. We need to retest. *** Gerrit 3.3.1 includes the fix for Zuul and Zuul has the fixes too. *** Configuration tuning **** Using strong refs for jgit caches **** Batch user groups and threads * General topics ** OpenAFS cluster status (clarkb 20210126) *** https://review.opendev.org/c/opendev/system-config/+/771521 properly install new openafs on xenial openafs clients. *** What is server cluster status? Have they all been upgraded to 1.8.6? **** Upgrading servers to bionic then focal in place is next? ** Bup and Borg Backups (clarkb 20210126) *** wiki backup status *** borg disk consumption workarounds ** Picking up steam on Puppet -> Ansible rewrites (clarkb 20210126) *** Enable Xenial -> Bionic/Focal system upgrades *** Clarkb to write up an etherpad that captures the rough TODO list. ** two-review rule impact on low-activity projects (zbr 20210126) *** projects like git-review rely on infra team and delay changes *** Properly setting expectations for what our small team is able to pay attention to *** Communicating the topics that are consuming our time day to day **** We update the priority efforts documentation and possibly link to a storyboard dashboard there that is populated with the current fires. * Open discussion From kennelson11 at gmail.com Tue Jan 26 20:49:47 2021 From: kennelson11 at gmail.com (Kendall Nelson) Date: Tue, 26 Jan 2021 12:49:47 -0800 Subject: Fwd: [All][StoryBoard] Angular.js Alternatives In-Reply-To: References: Message-ID: Thank you for the perspective! I am only just getting started reading the discussion on the wikimedia RFC now, but if I have questions, I will be sure to let you know! -Kendall (diablo_rojo) On Thu, Jan 21, 2021 at 3:08 PM Antoine Musso wrote: > Le 21/01/2021 à 23:05, Kendall Nelson a écrit : > > Hello Everyone! > > The StoryBoard team is looking at alternatives to Angular.js since its > going end of life. After some research, we've boiled all the options down > to two possibilities: > > Vue.js > > or > > React.js > > I am diving more deeply into researching those two options this week, but > any opinions or feedback on your experiences with either of them would be > helpful! > > ... > > Hello, > > Wikimedia has picked up Vue.js. It has been evaluated based on a fairly > large of requirements and challenged against over frameworks with react.js > being the main if not the sole challenger. > > Lot of the work happened in 2019 eventually leading to an introduction > presentation by the working group late 2019: > https://upload.wikimedia.org/wikipedia/commons/f/fd/FAWG_Demo.pdf > > Formally agreeing on Vue.js went through a RFC which is > https://phabricator.wikimedia.org/T241180 . The description at the top > is the proposal to adopt Vue.js. > > The comments have all the discussions with arguments for both sides. The > project lead of Vue.js (Evan You) came and clarified a few key points, > which is always much appreciated. There some interesting exchanges > regarding React. That should be a good read (grab several coffees). > > There are some more discussions on Hacker News which involved Wikimedia > employees and it gives some more context: > https://news.ycombinator.com/item?id=22625556 > > I can ask internally whether anyone at Wikimedia would be open for a round > of discussion with your group. Or feel free to reach out to them directly > on my behalf. > > > A few other random thoughts: > > - Gerrit UI is based on Polymer, Zuul has a dashboard using React. > > - If I got it right: Storyboard was written to replace Launchpad Blueprint > in the context of OpenStack development. OpenStack Horizon uses Angular > and I am assuming a lot of other OS projects do as well. Maybe there the > framework selection for Storyboard should be made in coordination with the > rest of the ecosystem using it? > > - if a rewrite is a lot of work, there is an opportunity to pick an > entirely different system. But I guess Storyboard is adhoc for the unique > workflows you have to support. > > > Antoine "hashar" Musso > > Wikimedia Release Engineering > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkopec at redhat.com Thu Jan 28 20:19:26 2021 From: mkopec at redhat.com (Martin Kopec) Date: Thu, 28 Jan 2021 21:19:26 +0100 Subject: Deploy a new refstack.openstack.org instance Message-ID: Hi, I'd like to ask for help with deploying a new refstack.openstack.org instance [1]. I also added this topic to the weekly meeting agenda [2]. I'll help with testing the new instance before we put it to the production. [1] https://review.opendev.org/c/opendev/system-config/+/705258 [2] https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Weekly_Project_Infrastructure_team_meeting Thank you for your help. Regards, -- Martin Kopec Software Quality Engineer Red Hat EMEA -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Thu Jan 28 20:23:41 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Thu, 28 Jan 2021 12:23:41 -0800 Subject: Deploy a new refstack.openstack.org instance In-Reply-To: References: Message-ID: On Thu, Jan 28, 2021, at 12:19 PM, Martin Kopec wrote: > Hi, > > I'd like to ask for help with deploying a new refstack.openstack.org > instance [1]. > I also added this topic to the weekly meeting agenda [2]. I'll help > with testing the new instance before we put it to the production. Thank you for updating this change and getting it into a working state. I think the next steps for this are to have an infra-root work with you to deploy a new instance with the ansible+docker config management. We can double check that new instance is happy, then schedule a downtime for the service and migrate the data and dns to the new instance. Thank you for volunteering to help with the testing of the new instance before we put it into production. If any infra-root are interested please volunteer here or in our next meeting. > > [1] https://review.opendev.org/c/opendev/system-config/+/705258 > [2] > https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Weekly_Project_Infrastructure_team_meeting > > Thank you for your help. > Regards, > -- > Martin Kopec > > Software Quality Engineer > > Red Hat EMEA > > From cboylan at sapwetik.org Sat Jan 30 23:36:12 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Sat, 30 Jan 2021 15:36:12 -0800 Subject: Service Coordinator Nominations In-Reply-To: <578fc941-73e2-4aad-86f3-2a543316e0b0@www.fastmail.com> References: <578fc941-73e2-4aad-86f3-2a543316e0b0@www.fastmail.com> Message-ID: <38d97d55-f3ab-483a-9087-3b9984cf158b@www.fastmail.com> On Thu, Jan 7, 2021, at 3:59 PM, Clark Boylan wrote: > Hello everyone, > > It has been pointed out that in our governance document we stated we > would elect a service coordinator every 6 months. I filled this role at > the beginning of May 2020 which means we are overdue for a new election. > > The beginning of the year is always a bit slow so I figure we can give > folks until January 31st at 23:59UTC to nominate themselves. Then if we > need an election we can do that during the week from February 1st to > February 8 at 23:59UTC. > > I've now been in this role (either as Service Coordinator or Infra PTL) > a while. I think it would excellent to rotate in some new eyeballs and > perspectives if possible. If you have interest but also have questions > feel free to reach out. > I haven't seen anyone else volunteer yet and time is running out. I still think having some fresh perspectives would be great, but to avoid having no nominations in ~24 hours when the nomination period ends I'll go ahead and nominate myself. As mentioned before, I've been at it a while now, and I don't expect my approach to change much. I'll continue to try and keep a focus on sustainability of our services and work upstream and downstream to ensure we're doing what we can to keep things running. If you'd like to see a different approach you have about a day to volunteer :) I'll keep it short since I feel that my approach is a known quantity. Happy to answer any questions if you've got them though. Clark