> Not everyone will have access to such resources, if all you have is 1 such
> pod you'll be waiting a long time (in theory one month, and you actually need
> a few bigger pods for some of the more extensive tests, e.g. large upgrade
> tests)….
One thing worth calling out: I believe we have *
>
> - There are hw constraints, is there any approximation on how long it will
> take to run all tests? Or is there a stated goal that we will strive to
> reach as a project?
>
> Have to defer to Mick on this; I don't think the changes outlined here
> will materially change the runtime on our curre
I don’t think users necessarily need to be able to update their own
identities. I just don’t want to have to use the super user role. The
super user role has all power over all things in the data base. I don’t
want to have to give that much power to the person who manages identities,
I just wan
All great questions I don't have answers to Ekaterina. :) Thoughts though:
> - Currently we run at most two parallel CI runs in Jenkins-dev, I guess you
> will try to improve that limitation?
If we get to using cloud-based resources for CI instead of our donated hardware
w/a budget, we could the
Thank you, Josh and Mick
Immediate questions on my mind:
- Currently we run at most two parallel CI runs in Jenkins-dev, I guess you
will try to improve that limitation?
- There are hw constraints, is there any approximation on how long it will
take to run all tests? Or is there a stated goal that
Yuki, Jeremiah both are fair points. The mental model we're using for
mTLS authentication is slightly different.
In your model you're treating the TLS identity itself to be similar to
the password. The password is the 'shared secret' that currently needs
to be rotated by the user that owns the acc
Thanks Josh, this looks great! I think the constraints you've outlined are
reasonable for an initial attempt. We can always evolve if we run into
issues.
Cheers,
Derek
On Fri, Jun 30, 2023 at 11:19 AM Josh McKenzie wrote:
> Context: we're looking to get away from having split CircleCI and ASF
Context: we're looking to get away from having split CircleCI and ASF CI as well
as getting ASF CI to a stable state. There's a variety of reasons why it's flaky
(orchestration, heterogenous hardware, hardware failures, flaky tests,
non-deterministic runs, noisy neighbors, etc), many of which Mick
