[releng] Issue #7153: Review time-1.28 F28 Change
by Petr Pisar
ppisar reported a new issue against the project: `releng` that you are following:
``
I will submit a system-wide Fedora change for Fedora 28 about "time" tool upgraded to 1.8 version.
The most important change is that the tool will print an additional line if the command measured by the time tool fails. This is not the case if the tool is executed in the POSIX mode ("-p" option).
Please review your scripts. They could be affected.
See https://fedoraproject.org/wiki/Changes/time-1.8 for more details.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7153
6 years, 3 months
[releng] Issue #7100: new koji tags for atomic host
by Dusty Mabe
dustymabe reported a new issue against the project: `releng` that you are following:
``
With the new [Fedora CI objective](https://fedoraproject.org/wiki/Objectives/Continuous_Integrati...
we will have better testing of the packages that comprise Fedora Atomic Host
and eventually extend that out to packages that aren't included in Atomic Host
(i.e. the broader Fedora).
It is almost guaranteed that we won't catch everything before some packages make
it into stable (some long running tests or even possibly some failures that we
don't yet have tests for). For that reason we have established that we will need
the ability to revert packages in Atomic Host that fail tests (or are otherwise bad).
This is mostly so that the testing of future packages doesn't get blocked by a host
that is now in a bad state.
We had previously considered using modularity for this purpose, but we aren't quite
ready to use modularity yet. In the interim we'd like to use a few koji tags and a rigorous
definition of Atomic Host to achieve this goal.
Today:
- we have the `f27-atomic` tag. This is used to primarily "freeze" our install
media for Atomic Host at the f27 "release day" package set. Occasionally we will need
a new version of anaconda or ostree/rpm-ostree for the installer and we'll ask to
have things tagged into this tag.
- we build our ostree for Atomic Host from the release day repo (f27) as well as the
updates repo that was created by Bodhi (f27-updates).
Proposed Future:
- we have an `f27-atomic-installer` tag that is used for the same purpose as the
`f27-atomic` tag is today. Mainly to freeze the installer package set at f27
release day packages. This tag inherites from f27 (release day) tag.
- we have an `f27-atomic-overrides` tag. This tag does not inherit from any other
tag and only contains rpms that we have tagged in there for reverting to previous
versions of rpms.
- we have a dist-repo for `f27-atomic-overrides` so that whenever we tag something
into that tag we can request a repo get created for it.
- we update the ostree compose definition (in our pungi configs) to pull from this new
dist-repo, as well as f27 and f27-updates. In our fedora-atomic tree manifest we will
specify NVR for rpms (possibly even for all packages that make up atomic host).
- we request a new "atomic" koji permission. This permission will have the appropriate
policy to allow people with this permission to add/remove packages from these tags.
Thanks to @mikeb who helped me come up with this solution by providing technical guidance.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7100
6 years, 4 months
Re: Adding Dusty Access/Membership to Releng/Infra
by Dusty Mabe
On 11/29/2017 02:04 PM, Stephen John Smoogen wrote:
> On 29 November 2017 at 12:29, Dusty Mabe <dusty(a)dustymabe.com> wrote:
>>
>>
>> So let's develop a set of sudo rules so I can only run certain commands?
>>
>
> That sounds good but isn't what you asked for. This may sound like a
> "but it should be clear that isn't what I wanted" but it isn't.
My initial email in this thread listed out specific things and did not
ask for root access. Patrick explained to me that "you're asking for root
access", so yes then I said: "sure I guess i'm asking for root access".
You voiced concern. To curb that I suggested sudo rules for those things
I asked for in the original email.
> Most
> requests for root from various projects has been for complete root and
> any amount of sudo rules gets them cranky. Which makes us reflex to
> assuming that a person is asking for what they know they require.
>
> Writing limited sudo commands is also hard because it is very easy to
> leave something open which goes BOOM.. we have done it to ourselves a
> lot and found that there is no shortcut to writing a command. It
> usually means making it very very limited and then opening it up
> slower and slower until it does what the person wants while we have a
> limited amount of risk. We can do this but expect that there will be a
> long period of "it doesn't do X", "ok try now" "I have lost Y" "ok why
> do you need Y?" "well it needs to get W working". And then a bunch "oh
> huh, I never knew it used Z"
I really only need a few things. sudo rule to allow me to kick off composes
and/or resubmit koji tasks and a few sudo rules to give me "read-only" access
to the filesystems/logs/rpm db of the builders. read/write access to /mnt/koji
(for admining the ostree repos) might be a difficult sudo rule to write, but
should be able to do it.
>
> That requires a lot of documentation on processes all around.
>
>>> And when things fail, those of us in root are the ones who
>>> collectively get blamed for it.
>>
>> Possible blame is definitely something I worry about when requesting
>> access like this. I do propose that I work with some bumpers (i.e.
>> only doing things after I get someone to review it, announcing things
>> i'm going to do). Basically I would be in FBR mode all the time, except
>> after I get reviewed I can actually do the work myself.
>>
>
> I am not clear on FBR means in this context. I am used to the context
> Full Blown Root which is not what you are meaning.
Freeze Break Request. When we are in freeze we have to ask for an FBR for
everything and we typically get things reviewed more often. I think it should
be like this more of the time, or at least have some system in place where
actions get reviewed more often.
>
>> Why did you let smooge have rights to
>>> the system? Why did you not check his actions before he did them. How
>>> did you not catch a ... in that line of code? It may all sound like
>>> reasonable questions but to the people who are dealing with the
>>> problem it gets picked up as "How did you let this moron ever do
>>> this?" And because things fail so much.. it eventually comes across as
>>> "You people are completely inept".
>>>
>>> All of this:
>>> * High chance that someone as root is going to make a mistake and the
>>> more people who have it more likely.
>>> * High chance that some systems will catch fire through all the rest
>>> of infrastructure
>>> * Perceived blame
>>>
>>> makes that adding anyone else a very difficult process. We can be
>>> prickly because of 3 and should mitigate it, but the real problem are
>>> the first two in the list.
>>>
>>
>> yes, hopefully the infra becomes less kerosene over time, but I'd like to
>> be part of the solution there rather than just someone waiting on it to
>
> I think infrastructure will always be keroseney by the nature of
> trying to make radical changes every 6 months. The best we can hope
> for at times is that a contained fire will take out enough old stuff
> we can build the new refinery on top of it.>
<jokes>
Then we should give everyone root access :). One controlled burn coming right up!
/me runs out and buys a mac because they'll just give anyone root!
</jokes>
>> happen. I'm mostly here to offer help and also deliver/release atomic host
>> every two weeks. Often times this means I find issues before anyone else
>> does (because I'm releasing tomorrow and not 6 months from now). This translates
>> mostly into: I help fix problems before other people even notice they are
>> problems. This translates into: I think I do more good than harm. The
>> jury is out on that, though.
>
> I am not sure I want the jury's opinion on myself.
>
>
>> Dusty
>
>
>
6 years, 4 months