11:30:33 <nardasev> #startmeeting <The so-called "Factory 2.0">
11:30:33 <zodbot> Meeting started Wed Aug  3 11:30:33 2016 UTC.  The chair is nardasev. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:30:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
11:30:33 <zodbot> The meeting name has been set to '<the_so-called_"factory_2.0">'
11:30:47 <nardasev> #meetingname flock 2016
11:30:47 <zodbot> The meeting name has been set to 'flock_2016'
11:31:30 <nardasev> bunch of the presentation is about figuring about what Factory 2.0 even means
11:32:12 <nardasev> let's start with a question: have you heard of the Eternal September?
11:32:27 <nardasev> also called the September that never ended
11:32:50 <nardasev> the second Eternal September is the rise of GitHub
11:32:59 <jflory7> nardasev: Ah, did you want to get this one?
11:33:00 <jflory7> #meetingname flock2016
11:33:00 <zodbot> The meeting name has been set to 'flock2016'
11:33:02 <jflory7> nardasev: Seems like I'm having problems with my connection - not sure when this will send, but I'll leave transcribing to you :)
11:33:29 <nardasev> consequent changes to app development and deployment:
11:33:45 <nardasev> pip freeze > requirements.txt # ship it!
11:34:06 <nardasev> to the traditional distribution: nixOS, coreOS, docker and friends
11:35:02 <nardasev> the Fedora rings conversation started a few years ago
11:35:23 <nardasev> Envs and Stacks and Alephs were also initial ideas
11:35:37 <nardasev> Red Hat is now funding a team to see what we can do
11:35:46 <nardasev> Throwing things over the wall:
11:36:08 <nardasev> in the past, we talked about how to articulate Red Hat things in the Fedora space
11:36:19 <nardasev> I work a group in Red Hat called PnT DevOps
11:36:36 <nardasev> Fedora packagers -> RH platform engineering
11:36:46 <nardasev> Fedora infra -> RH PnT DevOps
11:37:08 <nardasev> let's worry less about "If Fedora is interested" and just share.
11:37:17 <nardasev> What Factory 2.0 is NOT:
11:37:38 <nardasev> single web application
11:37:47 <nardasev> a rewrite of our entire pipeline
11:37:48 <nardasev> silver bullet
11:37:52 <nardasev> silver platter
11:37:58 <nardasev> just Modularity
11:38:03 <nardasev> going to be easy
11:38:51 <jflory7> #topic What Factory 2.0 is not
11:39:08 <jflory7> nardasev: Ah, try typing: #chair jflory7
11:39:12 <nardasev> if you have a particular problem, we don't guarantee that Factory 2.0 is going to solve it
11:39:21 <nardasev> #chair jflory7
11:39:21 <zodbot> Current chairs: jflory7 nardasev
11:39:23 <jflory7> #topic What Factory 2.0 is not
11:39:26 <nardasev> cool :)
11:39:27 <jflory7> nardasev++
11:39:32 <nardasev> thanks ;)
11:39:47 <jflory7> #topic the same "thing" under different interpretation
11:40:03 <nardasev> why it took us so long to get there
11:40:24 <nardasev> how long ago was it that we started talking about the Rings proposal?
11:40:46 <nardasev> Does Modularity mean anything with Factory 2.0?
11:41:00 <nardasev> Does Factory 2.0 mean anything without Modularity?
11:41:08 <nardasev> We put together 6 problems to be solved
11:41:21 <nardasev> 1) repetitive human intervention makes the pipeline slow
11:41:36 <nardasev> (to be analyzed later in the presentation)
11:42:15 <nardasev> Some of them need to be solved first, because they don't depend on solutions to others
11:42:38 <nardasev> Modularity is the most dependent and can only be solved last
11:43:04 <nardasev> Modularity is also the most complicated one
11:43:23 <nardasev> if we had problems before, they are about to get worse.
11:43:39 <nardasev> Remember the lego blocks analogy?
11:43:47 <nardasev> Imagine Modularity without Factory 2.0
11:44:39 <nardasev> it is like running barefoot on pieces of lego
11:44:42 <jflory7> #topic Dependency Chain
11:44:55 <nardasev> (problem #6)
11:45:17 <nardasev> the purpose of it is just to expand the pdc-updater
11:46:12 <nardasev> you can release component types and have release component relationship types
11:46:38 <nardasev> pdc updater responds to message bus and others
11:46:56 <nardasev> we would use that information for great justice
11:47:16 <nardasev> such as future tooling, Pungi/distil, Bodhi/ET
11:47:39 <nardasev> update notes (errate) we want them to be automated
11:48:29 <jflory7> #topic Pipeline Serialization
11:48:41 <nardasev> (problem #2)
11:48:57 <nardasev> unnecessary serialization makes the pipeline slow.
11:49:37 <nardasev> it's less a problem for Fedora's infrastructure than it is for the internal DevOps environment: things happen, unnecessarily, in serial.
11:50:10 <nardasev> One proposed solution is to introduce a new build key treated semantically different from the gold key.
11:50:17 <nardasev> Let's consider it also in Fedora.
11:50:34 <nardasev> #topic Automating Throughput
11:50:41 <nardasev> (problem #1)
11:50:51 <nardasev> rebuilds and composes
11:51:15 <nardasev> we'd like to build a workflow layer on top of Koji called "the orchestrator"
11:51:40 <nardasev> the concept was originally confused with modularity-specific considerations, but we'd like it to be more general
11:52:06 <nardasev> composes: take pungi and break it out into an ad hoc process alongside the buildsystem
11:52:24 <nardasev> we can do two-week Fedora Atomic releases now. Yay!
11:52:46 <nardasev> can we reconcile that with the mainline compose/QA/release process?
11:53:01 <nardasev> the problem is much more intense for Red Hat just due to volume.
11:53:14 <nardasev> we have uncovered ground in Bodhi for automation.
11:53:31 <nardasev> the karma system is a predecessor, but it relies on humans.
11:53:49 <nardasev> can we fast-track some components based on taskotron results?
11:54:19 <nardasev> how can we specify an (automated) for setting difference between release cadences?
11:54:29 <nardasev> #topic Flexible Cadence
11:54:36 <nardasev> (problem #3)
11:54:50 <nardasev> the pipeline imposes a rigid and inflexible cadence on products.
11:55:26 <nardasev> releases are related to the previous point about automating releases. in the first analysis, "the pipeline is as fast as the pipeline is."
11:55:48 <nardasev> EOL: think about the different EOL discussions for the different Editions.
11:56:19 <nardasev> Beyond that - a major goal of modularity is "independent lifecycles." what does that mean in practice?
11:56:37 <nardasev> let's talk about pkgdb2 and its collections model.
11:57:41 <nardasev> if you think about disconnecting the lifecycle of packages from the lifecycles of releases
11:57:57 <nardasev> Modularity: all roads lead to Rome
11:58:09 <nardasev> the distro is defined by packages, not "features"
11:58:27 <nardasev> #topic Modularity
11:58:37 <nardasev> building modules (showing a graph)
11:58:53 <nardasev> visiting the Modularity infrastructure page
11:59:36 <nardasev> it's about 2 months old, after Flock we should update it
11:59:47 <nardasev> things in white don't need to change at all for Modularity
11:59:53 <nardasev> yellow things need to be adjusted
12:00:07 <nardasev> green things are entirely new concepts needed for modularity
12:00:28 <nardasev> we update dependencies in pdc-updater
12:01:17 <nardasev> we hope to have a circular flow between orchestrator, koji and taskotron
12:01:35 <nardasev> Comps as a Servics (CaaS)
12:01:55 <nardasev> composes are defined by their variants
12:02:16 <nardasev> which are based on Comps
12:03:13 <nardasev> we have a huge variety of yum repos and searching for particular repos is difficult
12:03:29 <nardasev> we have requests to have some additional metadata on the side
12:03:47 <nardasev> build pipeline overview: we have crazy automation going on
12:04:02 <nardasev> today you know what you are doing and manually do bodhi updates
12:04:37 <nardasev> pipeline overviews watches the message but so we have an idea of what is going in the automation
12:05:38 <nardasev> #topic Artifact Assumptions
12:05:45 <nardasev> (problem #4)
12:06:01 <nardasev> I want to be able to build any content in any format without changing anything.
12:06:11 <nardasev> it's an odd duck from the other ones
12:06:21 <nardasev> qualitative, not quantitative.
12:06:45 <nardasev> can we make creating new types of content easier over time?
12:06:57 <nardasev> Autocloud and two week Atomic
12:07:02 <nardasev> OSBS
12:07:16 <nardasev> Flatpak, snaps, rocket containers, etc...
12:07:28 <nardasev> we can do anything, but how easily can we do it?
12:07:41 <nardasev> The pernicious hobgoblin of technical debt
12:07:54 <nardasev> Microservices (consolidate around responsbility)
12:08:00 <nardasev> Reactive services
12:08:05 <nardasev> idempotent services
12:08:12 <nardasev> infrastructure automation
12:08:50 <nardasev> we do relatively well at idempotent services
12:10:25 <nardasev> we have an opportunity to do something really cool with how we make the distro
12:10:33 <nardasev> please tell me where I'm wrong
12:10:43 <jflory7> #topic Conclusion / Q&A
12:10:58 <nardasev> hop in #fedora-modularity and #fedora-admin to join the party
12:13:33 <nardasev> there is a workflow for translators
12:13:51 <nardasev> but it's inefficient
12:14:04 <nardasev> we'd like our packages to be more tied to release cycles
12:14:39 <nardasev> we should take what we do with dist-git currently
12:16:46 <nardasev> slides available at http://threebean.org/presentations/factory2-flock16/
12:18:52 <jflory7> #link http://threebean.org/presentations/factory2-flock16/
12:19:29 <nardasev> #endmeeting