or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Do you want to remove this version name and description?
Syncing
xxxxxxxxxx
Scenario 1 (Green - Merged):-
Patch - code.engineering.redhat.com/gerrit/#/c/200373
Testproject Patch with run - https://code.engineering.redhat.com/gerrit/#/c/199982/
Scenario 4 (Green - Merged):-
Patch - code.engineering.redhat.com/gerrit/#/c/200505
Testproject with job run - code.engineering.redhat.com/gerrit/#/c/200636
Scenario 2 (Green - Merged)
Patch - https://code.engineering.redhat.com/gerrit/#/c/200511/
Testproject with job run - https://code.engineering.redhat.com/gerrit/#/c/200637/
Scenario10 (Green - Merged)
Patch - code.engineering.redhat.com/gerrit/#/c/200673
Testproject with job run - code.engineering.redhat.com/gerrit/#/c/200674
Fixed after moving from validate-tempest to os_tempest
Move fs062 to os_tempest)
Port sc10 job to os_tempest)
Scenario7 (Green - Merged)
Patch - https://code.engineering.redhat.com/gerrit/#/c/201430/
Testproject with job run - https://code.engineering.redhat.com/gerrit/#/c/200637/
Track of issue faced earlier - rabbitmq can't start properly in some sceanrios when ipv6 is entirely disabled on the system. ipv6 was getting disabled due to downstream nodepool specific customization.
After fix - https://code.engineering.redhat.com/gerrit/#/c/201431/1 and the new image builds - https://sf.hosted.upshift.rdu2.redhat.com/nodepool-log/cloud-rhel-8-1-0000013385.log - we are good
Multinode featureset010 (Red)
Patch - https://code.engineering.redhat.com/gerrit/#/c/201376/
testproject - https://code.engineering.redhat.com/gerrit/#/c/201382/
Failing with emit_releases_file.py: error: argument –stable-release: invalid choice: 'rhos-17
https://sf.hosted.upshift.rdu2.redhat.com/logs/82/201382/1/check/periodic-tripleo-ci-rhel-8-multinode-1ctlr-featureset010-rhos-17/eff9e9e/job-output.txt
Extra Discussion
Ceph container parameters
It looks like the internal jobs were not looking for the internal ceph containers in the correct locations.
The review above try to address that.
NOTE: tripleo-ci-internal tenant went down on Monady 05/18.
This was CIX'ed. If you catch infra, you can rerun and check.
Note also the reparenting from the job that would be in the integration line (to match the upstream RDO pattern).
Rework parenting??
@rlandy @marios fyi.. Gathered some thoughts here on possible parenting design.. Will need your suggestions to help in opting the best possible solution here. (We are still currently focusing on sceanrio001 as rest other sceanrios will follow the pattern - scenario001 currently is running good but failing due to prometheues containers)
Context:-
In rdo/upstream whenever we create a new scenario job - we create it for master and whenever there is branching(new release) - we inherit from master for the new branched job(for ex: ussuri).
example:-
But in downstream there is no Master to follow , Right now in downstream(In our initial work[1]) we are treating rhos-17 as master. If we follow same pattern when RHOSP18 will come - in order to not repeat ourselves we can possibily use rhos-17 as parent and override release specific vars(This can just work fine) - but this can create a challenge if in future we decided to drop rhos17 jobs.
[1] https://code.engineering.redhat.com/gerrit/#/c/200373/14/zuul.d/standalone-jobs.yaml
What can be done -
First possible solution:-
I am wondering if in downstream we should first just create generic jobs(without any release specific vars) instead of treating 17 as master, This way we can just reuse the generic jobs to create rhos17/18/19.. jobs(as they come). We will diverge from RDO/Upstream pattern but it seems needed as we don't have a master to follow.
I brainstormed to rework https://code.engineering.redhat.com/gerrit/#/c/200373/14/zuul.d/standalone-jobs.yaml to something like below:-
standalone-jobs.yaml
Create a generic new scenario001 job without any rhosp-17 vars.
Changes in component-jobs.yaml
Alternative Possible Solution
https://code.engineering.redhat.com/gerrit/#/c/200373/14/zuul.d/standalone-jobs.yaml
This can create a challenge if in future we decided to drop rhos17 jobs.
What can be done if above situation comes in future?