breaking up tripleo components

# breaking up tripleo components ###### tags: `Design` # prototype information: - URL: https://trunk-staging.rdoproject.org/centos7-master - API: https://trunk-staging.rdoproject.org/api-centos-master-uc/api/report.html - https://review.rdoproject.org/r/23277 - TripleO CI EPIC: https://tree.taiga.io/project/tripleo-ci-board/epic/1363 # meeting 1/09/2020 Attendees: jpena, weshay, chandan, rfolco, arx ## had two issues to discuss. ### naming collision w/ https://trunk-staging.rdoproject.org/centos7-master/current-tripleo/ 1. # 1 is missing 2. this is 100% in our control based on the arguments passed in the component promotion. The same promotion name should be passed to all components. Use the name "promoted-components" for now. 3. E.G. Currently we send: ``` dlrnapi --url https://trunk-staging.rdoproject.org/api-centos-master-uc \ --username review_rdoproject_org \ repo-promote \ --commit-hash 406a7fb2221379d890f49f3b67daab271f5a8e3b \ --distro-hash b6c485f3eb7fafb1582c5578f73c3dabc2c5a370 \ --promote-name current-tripleo-keystone ``` This should be changed to: ``` dlrnapi --url https://trunk-staging.rdoproject.org/api-centos-master-uc \ --username review_rdoproject_org \ repo-promote \ --commit-hash 406a7fb2221379d890f49f3b67daab271f5a8e3b \ --distro-hash b6c485f3eb7fafb1582c5578f73c3dabc2c5a370 \ --promote-name promoted-components ``` ### We need a unique identifier for each build 1. Now that each build is made up of a number of promoted dlrn hashes, we require a unique identifier for our build and promotion process. ``` https://trunk-staging.rdoproject.org/centos7-master/promoted-components/ file structure.. like (md5sum of delorean.repo file) 3343rjlkjrlk/delorean.repo r333fsfsfsfs/delorean.repo tripleo-ci-testing ---> 3343rjlkjrlk/delorean.repo ^- NOTE(jpena): this would better be delorean.repo --> 3343rjlkjrlk/delorean.repo, to reflect that the current promoted-components/delorean.repo points to the hashed repo file. back out one directory to --> centos7-master current-tripleo ---> promoted-components/r333fsfsfsfs/delorean.repo ^- NOTE(jpena): current-tripleo, if promoted via the DLRN API, will have its own structure of hashed dirs We may in fact want or need the md5sum directory to look like 33/43/3343rjlkjrlk ( not sure ) ^- NOTE (jpena): that's ok, and consistent with the repo structure ``` # meeting notes 11/15/2019 Attendees: pweeks, mburns, jpena, wes, marios, rfolco ## michal presenting https://www.google.com/url?q=https://docs.google.com/drawings/d/1KcKh-WzRNrLAVF70w1aXtBDlaVp_TyVdJbxxd4sMSi4/edit&sa=D&ust=1574251212912000&usg=AOvVaw3X9T7E-3XP-K-5Dni3RDI- ## status of upstream POC ## design questions * component job: * current-tripleo + untested component * note: component-common is NOT tested here * build/update containers w/ latest component + known good build ( current-tripleo) * run standalone + tempest + send results to dlrn_api * A seperate periodic job reads dlrn_api results and promotes component * (rfolco) if we make this job dependent of component jobs, we don't need to check dlrn api results to promote * Integration: We need codify the repo definition for promoted components + component-common. # meeting notes 11/18/2019 Attendees: pweeks, jpena, jjoyce Notes: * split the component pipeline design into two parts * Using an upstream model build out the pipeline for today * Begin a design of what could be done to integrate CPAS into the pipelines in the future * discussed dependency updates, CI testing. * discussed using a single deps config file for both upstream and downstream openstack deps * discussed pinning the dlrn-deps repo for jobs * discussed how cpas could work w/ deps testing for internal work * It's a problem, planting seeds of change Context of meeting: 1. how to split up openstack by components using rpms / yum repos 2. perhaps promote containers, not rpms https://review.opendev.org/#/q/project:openstack/nova | V TripleO >>>>>>>>>>>>>> Subset of https://review.opendev.org/#/q/project:openstack/nova ++++++++++++++++ >>>>>>>>>>>>>> TripleO jobs | V https://code.engineering.redhat.com/gerrit/#/q/project:nova OSP trunk delorean ! >>>>>>>>>>>>>> Subset of https://review.opendev.org/#/q/project:openstack/nova >>>>>>>>>>>>>> Subset of TripleO jobs # tripleo os-net-config paunch puppet-tripleo python-tripleoclient tripleo-common tripleo-heat-templates tripleo-image-elements tripleo-puppet-elements tripleo-ansible os-apply-config tripleo-validations # breaking down by components * assume we know which repos go w/ which component * single dlrn * (migi) For me definition of component is one where jobs are defined, example: https://github.com/openstack/neutron/blob/master/.zuul.yaml CORRECT definition of COMPONENT COMPONENT is set of many REPOS REPOS have per repo check (known as .zuul.yaml) inside that repos REPOS are verified per rebase and per gerrit change in similar way COMPONENT is verified by subset of upstream/TripleO jobs Note: OSP Trunk is currently rebasing on every commit. This may change based on the previous paragraph (or is it just after-GA?) upstream component promotion * non-tripleo components, will have 1 tripleo job for component promotion * blocks internal rebase when component fails * problematic when rebases pile up, it's hard to rebase/cherrypick the code into code.eng downstream * internal patch -jobs defined if owner exists * rebase - jobs defined if owner exists * component promotion - all components have 1 triple/director job defined. monitored and owned by greater ci team. SO for internal rebase testing.. * we need gerrit * rebase and package builds need to be uncoupled * jobs defined on the repo appropriately. Notes 9/20 https://docs.google.com/drawings/d/1KcKh-WzRNrLAVF70w1aXtBDlaVp_TyVdJbxxd4sMSi4/edit?usp=sharing https://docs.google.com/drawings/d/1Qvp5kEI8C1XaBK19-7OQfpD5M7hAM2AlBunkYt4zkDs/edit?usp=sharing (to be discussed later) # FIRST PASS ONLY DLRN REPOS * tags * component-test * component-current Components (first pass): * Compute * nova * python-novaclient * Network * octavia * neutron * not a component, but openvswtich * Storage * ceph * glance * manila * swift * cinder * TripleO * mistral / heat included in TripleO * Keystone / TLS * Oslo / client libraries * Ironic * CloudOps * UI * Tempest * ~~Leftovers~~ Common * DEPENDENCIES - NOT A COMPONENT (migi) Currently running some downstream CI: https://github.com/redhat-openstack/octario/tree/master/components_config/13 * Next Steps * https://review.rdoproject.org/r/22394 * rdoinfo tags a repo w/ component * ( inherited )ospinfo tags a repo w/ components * this can be defined per release * dlrn component repos

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.