infrastructure January 2019

infrastructure@lists.fedoraproject.org

37 participants
41 discussions

About JS framework
by Pierre-Yves Chibon 14 Sep '22

14 Sep '22

Good Morning Everyone, Our infrastructure is mostly a python store, meaning almost all our apps are written in python and most using wsgi. However in python we are using a number of framework: * flask for most * pyramid for some of the biggest (bodhi, FAS3) * Django (askbot, Hyperkitty) * TurboGears2 (fedora-packages) * aiohttp (python3, async app: mdapi) While this makes sometime things difficult, these are fairly standard framework and most of our developers are able to help on all. However, as I see us starting to look at JS for some of our apps (fedora-hubs, wartaa...), I wonder if we could start the discussion early about the different framework and eventually see if we can unify around one. This would also allow those of us not familiar with any JS framework to look at the recommended one instead of picking one up semi-randomly. So has anyone experience with one or more JS framework? Do you have one that would you recommend? Why? Thanks for your inputs, Pierre

15 19

What are we going to do about sigul?
by Neal Gompa 25 Mar '19

25 Mar '19

Hey all, So, we've got a bit of a problem. The sigul package is not installable in Fedora 29, and pygpgme is half-broken in Fedora 28 and was retired during Fedora 29 development due to constant breakage. This means that sigul is in danger of being retired in Fedora. Unfortunately, sigul is the only supported signer system for Koji at the moment. What do we want to do here? It's well-known that sigul does not work with GnuPG 2, though I vaguely recall that some work was done to try to fix this. Do we want to port sigul to python3-gpg, switching Sigul to Python 3 and the official gpgme bindings so that it works with GnuPG 2? Or do we want to adapt the bridge to work with obs-signd (which is already used by Copr)? -- 真実はいつも一つ！/ Always, there's only one truth!

4 6

cloud retirement
by Kevin Fenzi 02 Mar '19

02 Mar '19

Hey everyone. As you know, we currently have a RHOSP5 ancient cloud. After a bunch of work last year, we got a RHOSP13 cloud up and mostly working, but it was a ton of work. After hearing from the Fedora Council and our various management chains we determined that it wouldn't really be a good use of our time moving forward to keep maintaining a OpenStack cloud. We have not yet determined what we want to do with the hardware that we had allocated to this, but are weighing our options. We may want to setup OpenShift bare nodes so we can do kubevirt, we may want to just setup a normal virthost setup managed by ansible. For the items currently in our cloud, we will be looking at options for them, we are definitely not shutting things off until we have plans in place. Happy to answer any questions and will make sure everything is properly migrated. kevin

6 7

[PATCH] Configure a separate namespace for Flatpaks
by Owen Taylor 01 Feb '19

01 Feb '19

From: "Owen W. Taylor" <otaylor(a)fishsoup.net> Configure pagure to allow a flatpaks/ namespace, and koji and MBS to allow building from it. When we sync package ownership to Koji, the f29-flatpaks tag (which has the Flatpak containers) tag gets everything in the flatpaks/ namespace, while the f29-modular tag gets everything in modules/ *and* flatpaks/, since modules can be built from either. Signed-off-by: Owen W. Taylor <otaylor(a)fishsoup.net> --- .../backend/files/koji-sync-listener.py | 2 +- roles/bodhi2/backend/tasks/main.yml | 2 +- .../backend/templates/owner-sync-pagure.j2 | 55 +++++++++++-------- roles/distgit/pagure/templates/pagure.cfg | 3 +- roles/koji_builder/templates/kojid.conf | 2 + roles/mbs/common/templates/config.py | 10 +++- 6 files changed, 45 insertions(+), 29 deletions(-) diff --git a/roles/bodhi2/backend/files/koji-sync-listener.py b/roles/bodhi2/backend/files/koji-sync-listener.py index 02b0e3f18..cbcbd280f 100644 --- a/roles/bodhi2/backend/files/koji-sync-listener.py +++ b/roles/bodhi2/backend/files/koji-sync-listener.py @@ -23,7 +23,7 @@ def handle(content): sys.stdout.flush() # XXX If you modify this taglist. Please also modify the other copy in # bodhi2/backend/tasks/main.yml - taglist = 'f30 f30-container f30-modular f29 f28 f29-container f28-container f28-docker f29-modular f28-modular epel7 dist-6E-epel module-package-list modular' + taglist = 'f30 f30-container f30-modular f29 f28 f29-container f29-flatpak f28-container f28-docker f29-modular f28-modular epel7 dist-6E-epel module-package-list modular' cmd = [ '/usr/local/bin/owner-sync-pagure', '--package', package, diff --git a/roles/bodhi2/backend/tasks/main.yml b/roles/bodhi2/backend/tasks/main.yml index 114c113d5..e65feb417 100644 --- a/roles/bodhi2/backend/tasks/main.yml +++ b/roles/bodhi2/backend/tasks/main.yml @@ -166,7 +166,7 @@ # bodhi2/backend/files/koji-sync-listener.py # This cronjob runs only once a day. The listener script runs reactively. cron: name="owner-sync" minute="15" hour="4" user="root" - job="/usr/local/bin/lock-wrapper owner-sync '/usr/local/bin/owner-sync-pagure f30 f30-container f30-modular f29 f28 f29-container f28-container f28-docker f29-modular f28-modular epel7 dist-6E-epel module-package-list modular'" + job="/usr/local/bin/lock-wrapper owner-sync '/usr/local/bin/owner-sync-pagure f30 f30-container f30-modular f29 f28 f29-container f29-flatpak f28-container f28-docker f29-modular f28-modular epel7 dist-6E-epel module-package-list modular'" cron_file=update-koji-owner when: inventory_hostname.startswith('bodhi-backend01') and env == "production" tags: diff --git a/roles/bodhi2/backend/templates/owner-sync-pagure.j2 b/roles/bodhi2/backend/templates/owner-sync-pagure.j2 index 89d7a371c..e558a26b9 100755 --- a/roles/bodhi2/backend/templates/owner-sync-pagure.j2 +++ b/roles/bodhi2/backend/templates/owner-sync-pagure.j2 @@ -65,6 +65,7 @@ if not PDC_URL.endswith('/'): PDC_TYPES = { 'rpms': 'rpm', 'modules': 'module', + 'flatpaks': 'flatpak', 'container': 'container', } @@ -118,26 +119,29 @@ def get_options(): return opts -def get_namespace_and_version_from_tag(tag): +def get_namespaces_and_version_from_tag(tag): if 'container' in tag: - namespace = 'container' + namespaces = ['container'] version = tag.split('-')[0].split('f')[1] elif 'docker' in tag: - namespace = 'container' + namespaces = ['container'] version = tag.split('-')[0].split('f')[1] elif 'modular' in tag: - namespace = 'modules' + namespaces = ['flatpaks', 'modules'] try: version = tag.split('-')[0].split('f')[1] except IndexError: version = RAWHIDE + elif 'flatpak' in tag: + namespaces = ['flatpaks'] + version = tag.split('-')[0].split('f')[1] elif tag == 'module-package-list': # See https://pagure.io/releng/issue/6663 # and https://pagure.io/fm-orchestrator/issue/333 - namespace = 'rpms' + namespaces = ['rpms'] version = RAWHIDE else: - namespace = 'rpms' + namespaces = ['rpms'] if tag.startswith('epel'): version = tag.split('epel')[1] elif tag.startswith('f'): @@ -378,15 +382,15 @@ if __name__ == '__main__': unique_namespaces = set() tag_info = {} for tag in tags: - namespace, version = get_namespace_and_version_from_tag(tag) + namespaces, version = get_namespaces_and_version_from_tag(tag) branch, arches = get_branch_and_arches(tag, version) tag_info[tag] = { - 'namespace': namespace, + 'namespaces': namespaces, 'version': version, 'branch': branch, 'arches': arches } - unique_namespaces.add(namespace) + unique_namespaces.update(namespaces) # Get all the project to branch mappings for every namespace namespace_to_projects = {} @@ -401,24 +405,27 @@ if __name__ == '__main__': if verbose: print('Determining which projects have the namespace "{0}" and ' 'branch "{1}"'.format(namespace, tag)) - namespace = info['namespace'] + namespaces = info['namespace'] pkgs = [] - for pkg, branches in namespace_to_projects[namespace].items(): - if info['branch'] in branches or tag == ('f' + RAWHIDE): - # The tag and branch names are the same for "old-style" branches - pkgs.append(pkg) - elif namespace == 'modules': - # Add modules to f27-modular-updates even if their only branch is '2.4' - pkgs.append(pkg) - - # This is a special project, not in dist-git, but which needs to be in - # the package list. - if namespace == 'rpms': - pkgs.append('module-build-macros') + for namespace in namespaces: + for pkg, branches in namespace_to_projects[namespace].items(): + if info['branch'] in branches or tag == ('f' + RAWHIDE): + # The tag and branch names are the same for "old-style" branches + pkgs.append(pkg) + elif namespace in ('modules', 'flatpaks'): + # Add modules to f27-modular-updates even if their only branch is '2.4' + # Similarly, flatpaks will be built into f29-flatpak-updates-candidate + # if they use the f29 runtime, even from master or stream branches. + pkgs.append(pkg) + + # This is a special project, not in dist-git, but which needs to be in + # the package list. + if namespace == 'rpms': + pkgs.append('module-build-macros') if verbose: print('Setting the Koji ownership and package list on packages in ' - 'the tag "{0}" and namespace "{1}" and for arches "{2}"' - .format(tag, namespace, ', '.join(info['arches']))) + 'the tag "{0}" and namespaces "{1}" and for arches "{2}"' + .format(tag, namespaces, ', '.join(info['arches']))) set_koji_ownership(tag, pkgs, info['arches'], verbose=verbose) diff --git a/roles/distgit/pagure/templates/pagure.cfg b/roles/distgit/pagure/templates/pagure.cfg index 4b8e00b1b..46173b9b6 100644 --- a/roles/distgit/pagure/templates/pagure.cfg +++ b/roles/distgit/pagure/templates/pagure.cfg @@ -211,7 +211,7 @@ LOGGING = { # Configuration item that are specific for this odd pagure instance ENABLE_UI_NEW_PROJECTS = False -ALLOWED_PREFIX = ['rpms', 'modules', 'container', 'tests'] +ALLOWED_PREFIX = ['rpms', 'modules', 'flatpaks', 'container', 'tests'] EXCLUDE_GROUP_INDEX = ['packager'] PRIVATE_PROJECTS = False FEDMSG_NOTIFICATIONS = True @@ -235,6 +235,7 @@ ACLS = { REQUIRED_GROUPS = { 'container/*': ['packager'], + 'flatpaks/*': ['packager'], 'modules/*': ['packager'], 'rpms/*': ['packager'], } diff --git a/roles/koji_builder/templates/kojid.conf b/roles/koji_builder/templates/kojid.conf index 9fbb8216a..a1eb32338 100644 --- a/roles/koji_builder/templates/kojid.conf +++ b/roles/koji_builder/templates/kojid.conf @@ -81,6 +81,7 @@ allowed_scms= !src.stg.fedoraproject.org:/forks/* !src.stg.fedoraproject.org:/cgit/* src.stg.fedoraproject.org:/container/*:false + src.stg.fedoraproject.org:/flatpaks/*:false src.stg.fedoraproject.org:/git/rpms/*:false:fedpkg,sources !src.stg.fedoraproject.org:/git/* !pkgs.stg.fedoraproject.org:/fork/* @@ -88,6 +89,7 @@ allowed_scms= !pkgs.stg.fedoraproject.org:/cgit/* !pkgs.stg.fedoraproject.org:/git/* pkgs.stg.fedoraproject.org:/container/*:false + pkgs.stg.fedoraproject.org:/flatpaks/*:false pkgs.stg.fedoraproject.org:/rpms/*:false:fedpkg,sources pkgs.stg.fedoraproject.org:/*:false:fedpkg,sources src.stg.fedoraproject.org:/*:false:fedpkg,sources diff --git a/roles/mbs/common/templates/config.py b/roles/mbs/common/templates/config.py index 47f3ad790..4ed7a9ef2 100644 --- a/roles/mbs/common/templates/config.py +++ b/roles/mbs/common/templates/config.py @@ -140,7 +140,10 @@ class ProdConfiguration(BaseConfiguration): PDC_URL = 'https://pdc.stg.fedoraproject.org/rest_api/v1' SCMURLS = ['git+https://src.stg.fedoraproject.org/modules/', 'https://src.stg.fedoraproject.org/modules/', - 'https://src.stg.fedoraproject.org/git/modules/'] + 'https://src.stg.fedoraproject.org/git/modules/', + 'git+https://src.stg.fedoraproject.org/flatpaks/', + 'https://src.stg.fedoraproject.org/flatpaks/', + 'https://src.stg.fedoraproject.org/git/flatpaks/'] {% else %} KOJI_PROFILE = 'production' @@ -155,7 +158,10 @@ class ProdConfiguration(BaseConfiguration): PDC_URL = 'https://pdc.fedoraproject.org/rest_api/v1' SCMURLS = ['git+https://src.fedoraproject.org/modules/', 'https://src.fedoraproject.org/modules/', - 'https://src.fedoraproject.org/git/modules/'] + 'https://src.fedoraproject.org/git/modules/', + 'git+https://src.fedoraproject.org/flatpaks/', + 'https://src.fedoraproject.org/flatpaks/', + 'https://src.fedoraproject.org/git/flatpaks/'] {% endif %} RESOLVER = "db" -- 2.20.1

2 2

Project Details
by Leigh Griffin 31 Jan '19

31 Jan '19

Hey everyone, I am trying to get a handle on the number of projects that we are actively working on for any given day of the week. Could I ask everybody to reply here with some information. At a minimum if you could share with me: - Project you are actively working regularly on - Link to the Landing Page / Tracker / Source / Docs / anything relevant really that might help me get a handle on the project - Got a roadmap link? Or backlog link? - Any upcoming release plans that you are aware of / have committed to? - Anything else you think is worth sharing by all means include it I want to try and get a picture of the landscape and to take all of that into account when we start looking at the upcoming priorities for the Red Hat team. I want to try paint a bigger picture of our current responsibilities and commitments to help us inform what our future commitments look like. I intend to transpose this *somewhere* in due course, the Wiki might be a good starting point but for now I'm happy to take the details within this thread and I can follow up with another conversation as the information flows in. Thanks, Leigh -- LEIGH GRIFFIN ENGINEERING MANAGER, Community Platform Engineering Red Hat Ireland <https://www.redhat.com/> Communications House, Cork Road Waterford City, Ireland X91NY33 lgriffin(a)redhat.com M: +353877545162 IM: lgriffin <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> @redhatway <https://twitter.com/redhatway> @redhatinc <https://instagram.com/redhatinc> @redhatsnaps <https://snapchat.com/add/redhatsnaps>

10 11

Infra team schedule tasks
by Ben Cotton 31 Jan '19

31 Jan '19

I am beginning to prepare the schedule for Fedora 31. One thing I want to do is to make sure it still accurately reflects the work of different teams within Fedora. Please look at the tasks on your team's schedule [1] and discuss them in your team. Let me know if there are tasks that should be added, removed, or modified. You can email me directly or file an issue in Pagure[2]. I ask that you please provide feedback by Friday, 18 January, although I will be able to incorporate changes after that. [1] https://fedorapeople.org/groups/schedule/f-30/f-30-infrastructure.html [2] https://pagure.io/fedora-project-schedule/issues -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

2 1

MBI (Playground 2.0)
by Igor Gnatenko 31 Jan '19

31 Jan '19

MayBe I …(can do something useful)? Hello, We've been discussing some (hopefully) nice idea with Mikolaj, Neal and Jakub how we could improve packager (and user) experience and we have some proposal which will be described below. We would like to ask you to read it, understand it and ask us any questions you have. From the Fedora Infrastructure we would like to ask for some machines to implement this idea (you can find some more information in "Implementation details" part). I would like to apologize for HTML email, but it is much easier to have it that way to have better visibility and reading easiness. Feel free to reply to this email or comment in google doc (there is a link on the bottom). Proposal Owners - Mikolaj Izdebski (mizdebsk) <mizdebsk(a)redhat.com> - Java SIG, Fedora infrastructure - Igor Gnatenko (ignatenkobrain) <ignatenkobrain(a)fedoraproject.org> - Rust SIG, Golang SIG, Neuro SIG, RPM and libsolv contributor - Neal Gompa (ngompa) <ngompa13(a)gmail.com> - Rust SIG, Golang SIG, RPM contributor - Jakub Čajka (jcajka) <jcajka(a)fedoraproject.org> - Golang SIG, Container SIG This proposal aligns with the objective of improving the packager experience <https://fedoraproject.org/wiki/Objectives/Packager_Experience> by developing a platform whereby the proposal owners and others can experiment with improvements that can be funneled back into the official production infrastructure. ProblemsProblem №1: Build-only packages Some ecosystems have many build-only packages (packages which are used to build other packages, without having them installed on end-user systems). Those ecosystems include Java, Rust and Go. It is extremely hard to keep up maintaining them due to lack of time/people. Upstreams are usually changing quickly (sometimes when you update just one such package, you’d need to update tens of the dependencies). Few facts about such packages: - They are almost always outdated in released versions of distribution; - They are often FTBFS (e.g. because there was compiler update but not package update, broken deps, broken APIs due to deps rebases, …). In Rust ecosystem, we abuse Rawhide to build and store such packages there and then generate end-user application (e.g. ripgrep) which uses some of those packages and produces binary for all supported releases. Those applications have high quality and are supported. Rawhide gating makes this much more complicated because builds appear in buildroot slower, updating group of packages would need side tags and it’s just painful to work with. https://pagure.io/fesco/issue/2068 And, after all, those packages shouldn’t be shipped to users. Problem №2: Testing of new rpm/koji/mock features/configuration When developing new features in RPM (e.g. rich dependencies) or testing different Koji configuration (e.g. removing gcc/gcc-c++ from the buildroot), it is required to make custom configuration and try building things. Problem №3: Developing modules Modules are built in MBS as a single unit. It is hard to develop big modules by progressively improving individual packages or small package groups. Scratch builds for modules are not implemented. Local builds work differently from official module builds, they don’t scale and don’t allow groups of people to work collaboratively. All these problems can be solved by first developing a flat repository of packages in a shared environment and then generating modulemd from such package set. Problem №4: Testing things before push Primary Fedora Koji and dist-git are not suited for packaging experimentation. Packagers are expected to experiment on their own systems and push changes of successful experiments only. But this approach doesn’t scale with number of maintained packages. Often you can find commits like “d’oh, forgot to upload sources” or “let’s try with this settings”. People need to build things somewhere quickly, do development and testing. And only after that, they should push commit(s) to Fedora. Solution - Separate Koji + Koschei deployed in Fedora infrastructure cloud; - Builders are optimized for the best performance (see below <https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwGGg…> ); - People can have their own targets where they can break things as they wish without affecting others; - Package changes are eventually contributed to Fedora proper by merging changes to Fedora dist-git and rebuilding packages in official Fedora Koji; - All improvements can eventually be contributed back to official Fedora infra. Ideas All ideas which you’ll find below are just an ideas and do not have to be implemented. Idea №1: Automated legal review openSUSE released their review app called Cavil <https://github.com/openSUSE/cavil> which we could try running in automated way. Idea №2: Automated package review Currently review process is burden and we could run automated legal review, create a repo, run set of checks and notify person. Somewhat similar to fresque <https://github.com/fedora-infra/fresque>. In future might be integrated with approval process and auto-imported into Fedora. Idea №3: Building packages for multiple distributions In Rust ecosystem, we managed to get have same packaging guidelines in openSUSE, Mageia and Fedora. We could automatically build some packages on multiple distributions and be kinda upstream. Idea №4: Building custom images with user content Deploy (or build) a tool(s) to enable user-built install, appliance and container images with their content (modulo restrictions similar to COPR) on top of Fedora. Implementation details - Koji and Koschei deployed in fedorainfracloud.org - A few builders constantly running, with a possibility to add more builders as needed and as available cloud resources allow - Deployed and maintained by proposal owners - not supported by Fedora infrastructure - Other contributors can have access granted by proposal owners (for the time being only users in “packagers” group will be eligible to get access) - Possibility to have some builders running outsides of Fedora infrastructure - contributed by proposal owners - Koji builds can be done from SCM (src.fp.o, pagure.io, github, …) or from SRPM upload FAQWhy not COPR? - COPR has been starved of resources for years, which has impaired its ability to provide reliable service at scale. Fedora Infrastructure refuses to consider supporting it officially and Fedora Release Engineering seems to have some undefined issues with COPR. - It is not official build system of Fedora which is not helping with Problem №2: Testing of new rpm/koji/mock features/configuration <https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwGGg…> . - COPR is not extensible enough, more specifically: - No query API (e.g. it is not possible to find out from which SCM commit the package has been built) - Builds always have access to all previous builds in a repository (i.e. not possible to control when/how repo is created) - GC doesn’t exist - No scratch builds Why not staging Koji? - Staging Koji is meant for testing Koji itself and not for package development. - Staging Koji is often in broken state where it is not possible to build anything. - No one can touch staging Koji, so it’s pointless for offering a useful service. How can you make Koji builds faster? - By tuning Koji for performance, not correctness and reliability. - By building only on a single, fast architecture. - By extensive caching. Files like RPM packages, repodata and files in lookaside cache don’t change after they are initially stored, so builders can cache them aggressively. - By keeping build repositories small. Some package sets don’t need to be built against full Fedora, but can use a minimal subset of Fedora. Such repositories can be generated by Koji in seconds, not minutes. Why not the Open Build Service (OBS)? - OBS is not yet packaged for Fedora officially. The upstream code lacks adaptations necessary to deploy and run on Fedora and in Fedora Infrastructure. - OBS is not official build system of Fedora, which does not help with Problem №2: Testing of new rpm/koji/mock features/configuration <https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwGGg…> . What does MBI stand for? - M for middlestream, module, mizdebsk, … - B for build, bootstrap, … - I for infrastructure, initiative, ignatenkobrain, … - MBI might be pronounced as “maybe I …(can make something cool)?” - MBI is also initials of mizdebsk (Mikolaj Bozydar Izdebski) - MBI is also IBM spelled backwards :) Is it somehow related to Fedora Playground <https://fedoraproject.org/wiki/Playground>? Yes, it is. Although it is more developer-focused. Users could enrol for some specific things like experimental Java/Rust packages. MBI (Playground 2.0) <https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwGGg…>

4 3

Release Engineering Automation effort
by Clement Verna 31 Jan '19

31 Jan '19

Hi all, I have started a document [0] to gather the releng tasks that would benefit automation. At this point I am not looking for the HOW, but more for the WHAT. So if you have any ideas please add an entry to this bullet list [1], Once we have a few items there we can start looking at HOW, this is something I started for automating the unorphan requests.[2] As always feedbacks are more than welcome. Thanks Clément [0] - https://fedoraproject.org/wiki/Infrastructure_2020/RelengAutomation [1] - https://fedoraproject.org/wiki/Infrastructure_2020/RelengAutomation#Release… [2] - https://fedoraproject.org/wiki/Infrastructure_2020/RelengAutomation#Adoptin…

2 2

Lost access to my Fedora Account (FAS)
by Guillaume Bernard 30 Jan '19

30 Jan '19

Hi there, I think that there’s a problem with my FAS account because I cannot acess it anymore, the password associated with it does not longer works and even when using my login and email address it does not send me anything to regain access to it. I posted something on Ask Fedora few months ago and I just wanted to add information, which I cannot do anymore. You’ll see on my Ask profile [1] that I registered my own website, which can prove, in a way, my identity (who will give a website which is not its own?). And as well, i use this username (guilieb) on GNOME Damned Lies app [2]. My GPG key should also be registered on my account, number 0x31E06F062CA02892. FAS login: guilieb [1]: https://ask.fedoraproject.org/en/users/19096/guilieb/ [2]: https://l10n.gnome.org/users/guilieb/ Thanks a lot for your precious help, Best regards, -- Guillaume Bernard

2 1

Reminder: Infrastructure meeting 2019-01-31 15:00 UTC
by Stephen John Smoogen 30 Jan '19

30 Jan '19

This shared document is for the next fedora infrastructure meeting. = Preamble = The infrastructure team will be having its weekly meeting tomorrow, 2019-01-31 at 15:00 UTC in #fedora-meeting-1 on the freenode network. We have a gobby document (see: https://fedoraproject.org/wiki/Gobby ) fedora-infrastructure-meeting-next is the document. Please try and review and edit that document before the meeting and we will use it to have our agenda of things to discuss. A copy as of today is included in this email. If you have something to discuss, add the topic to the discussion area with your name. If you would like to teach other folks about some application or setup in our infrastructure, please add that topic and your name to the learn about section. = Introduction = We will use it over the week before the meeting to gather status and info and discussion items and so forth, then use it in the irc meeting to transfer information to the meetbot logs. = Meeting start stuff = #startmeeting Infrastructure (2019-01-31) #meetingname infrastructure #topic aloha #chair nirik pingou puiterwijk relrod smooge tflink threebean cverna mkonecny = Let new people say hello = #topic New folks introductions #info This is a place where people who are interested in Fedora Infrastructure can introduce themselves #info Getting Started Guide: https://fedoraproject.org/wiki/Infrastructure/GettingStarted = Status / Information / Trivia / Announcements = (We put things here we want others on the team to know, but don't need to discuss) (Please use #info <the thing> - your name) #topic announcements and information #info nirik will have sparse hours due to house move #info devconf happened and many meetings occurred. Feedback will occur. #info outage at PHX2 colocation around 2019-02-02 #info cleanup of sysadmin groups = Things we should discuss = We use this section to bring up discussion topics. Things we want to talk about as a group and come up with some consensus /suor decision or just brainstorm a problem or issue. If there are none of these we skip this section. (Use #topic your discussion topic - your username) #topic Discuss: Is the Fedora pastebin still useful? - relrod #topic Oncall #info smooge is on call from 2019-01-31 -> 2019-02-07 #info ?????? is on call from 2019-02-07 -> 2019-02-14 #info ?????? is on call from 2019-02-14 -> 2019-02-21 #info ?????? is on call from 2019-02-21 -> 2019-02-28 #info Summary of last week: (from relrod ) #topic Monitoring discussion #info https://nagios.fedoraproject.org/nagios #info Go over existing out items and fix #topic Tickets discussion #info https://pagure.io/fedora-infrastructure/report/Meetings%20ticket Go thru each ticket one by one = Apprentice office hours = #topic Apprentice Open office minutes #info A time where apprentices may ask for help or look at problems. Here we will discuss any apprentice questions, try and match up people looking for things to do with things to do, progress, testing anything like that. = Learn about some application or setup in infrastructure = (This section, each week we get 1 person to talk about an application or setup that we have. Just going over what it is, how to contribute, ideas for improvement, etc. Whoever would like to do this, just add the i/nfo in this section. In the event we don't find someone to teach about something, we skip this section and just move on to open floor.) #info = Meeting end stuff = #topic Open Floor #endmeeting -- Stephen J Smoogen.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure January 2019