[Fedora QA] #436: SSH access to systems in Beaker lab
by fedora-badges
#436: SSH access to systems in Beaker lab
--------------------------------------+---------------------
Reporter: atodorov | Owner: tflink
Type: defect | Status: new
Priority: major | Milestone:
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+---------------------
= bug description =
Currently systems in Beaker lab can be accessed only through bastion.fp.o
which is not as convenient as direct SSH into the system.
There's also the question whether or not to open the systems directly to
the Internet.
This needs to be discussed with infra. Filing here so it doesn't get lost.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/436>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
7 years, 5 months
[Fedora QA] #443: Better format for test compose (TC) and release candidate (RC) requests
by fedora-badges
#443: Better format for test compose (TC) and release candidate (RC) requests
----------------------------------------+------------------------
Reporter: jreznik | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 21
Component: Blocker/NTH review process | Version:
Keywords: | Blocked By:
Blocking: |
----------------------------------------+------------------------
= problem =
With Dennis (in CC), we discussed how to make release process, with
Fedora.next in mind, more transparent and bullet proof. One issue is that
releng request can become pretty messy, with full text included and
sometimes it leads to errors (omission of packages in compose etc).
= enhancement recommendation =
One possibility is to visibly separate full text description (with bug
numbers, reasons - it's good to have history) and the list of exact nvrs
(maybe in code block?), try to avoid "qt bundle" etc. so it's easier to
pick up the right list (for blockers, FEs + exceptional tools requests).
Another thing is better coordination between requester/releng - to mark
when/which list was picked up etc, in similar way how Go/No-Go decision is
stated in the ticket.
Now I'll let more space to Dennis, maybe example of how the request should
look like to make it easy to parse would help.
Long term (and preferred) solution would be to have automation in place,
Blocker app talking to releng interface, compose database, web dashboard
etc...
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/443>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
8 years, 8 months
[Fedora QA] #437: Need to import daily Fedora snapshots into Beaker
by fedora-badges
#437: Need to import daily Fedora snapshots into Beaker
--------------------------------------+---------------------
Reporter: atodorov | Owner: tflink
Type: task | Status: new
Priority: major | Milestone:
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+---------------------
= bug description =
In order to perform any meaningfull testing Beaker needs to import more
recent Fedora trees. It could be daily(nightly) snapshots or less often
depending on available resources.
The tree directory structure needs to be a copy/snapshot of the current
state at the time of import. The reason is b/c devel trees utilize one URL
but the contents under this URL are updated in a rolling fashion. We need
tree URLs where content is not changing in order to produce consistent
test results.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/437>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
8 years, 8 months
[Fedora QA] #433: blocker proposal form forgets everything after login timeout
by fedora-badges
#433: blocker proposal form forgets everything after login timeout
--------------------------------------+---------------------
Reporter: kvolny | Owner: tflink
Type: defect | Status: new
Priority: major | Milestone:
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+---------------------
= bug description =
I was trying to propose a F20 blocker. I needed to gather information from
multiple bugs, so it took me longer to write the justification. After
finishing and submitting that, I was presented with a login screen. After
logging in again, I was redirected to the proposal form again, but it was
completely empty, all the text that took me so long to write was gone.
(Okay, I'm a smart guy and I had it in clipboard for such case, but if I
had forgotten ... booh.)
= bug analysis =
Seems the login code doesn't care about other variables in the http
request ...
= fix recommendation =
1) If there is such a short login timeout, the user should be warned about
it (e.g. countdown timer on the page) and the page should allow refresh
without submitting the data.
2) Once the login expires, the submitted data should be caried over all
the redirects back to the submission form.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/433>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
8 years, 8 months
Next Steps for Taskotron
by Tim Flink
Now that we're pretty much feature-complete for replacing AutoQA with
Taskotron, it's time to start talking about what to work on next.
The next big feature that I want to work on is support for disposable
clients in Taskotron. We've been talking about doing this for years in
AutoQA but for various reasons, it never happened. Disposable clients
will pave the way for things like:
- user submitted tasks
- destructive tasks (things which could leave the client in a broken
state)
- tasks that require extra packages to be installed
While disposable clients may sound simple, there are many parts to this.
- deciding whether to use something like openstack vs. libvirt
* The limiting issue here is likely to be that clients need to be
isolated on the network which may preclude use of the existing
Fedora infra cloud. I'm not sure that setting up our own openstack
instance is wise or efficient.
- Figuring out how to store logs in a persistent way since clients
will be destroyed on a regular basis
- If we have different client retention policies for various tasks
(eg keep generic clients for rpmlint, depcheck etc. around for a
while and destroy all other clients after a single use), enhance
trigger to support those policies.
- Support systems for image maintenance/distribution
* base images should be reasonably up to date
* make sure that images are distributed to all required places
- Explore whether buildbot's ephemeral slave support will be enough
for our uses or if that will need enhancements.
- Test the snot out of the disposable clients feature
* This feature will add a decent amount of complexity and we need to
make sure most of the kinks are worked out
Outside of this "big feature", there are several smaller features and
support artifacts that I want to see done in the reasonably near future:
- CI for taskotron
* I also want to see continuous deployment on taskotron-dev but that
may need to wait for later
- (More) build automation
* The current process that I'm using for builds is tedious, painful
and convoluted
* We need to start supporting longer-lived repos than what we get
with copr
- Submit Taskotron packages for inclusion in the Fedora repos
* This will make it easier for folks to install libtaskotron and for
infra to update the Taskotron systems
If you have arguments for why something outside of what I've described
above should be a higher priority, feel free to make an argument for
that feature but please make it quick. I'm planning to start filing
tickets later today.
Also, this is for the more immediate future. As the F21 test cycle is
starting up, we have fewer human resources available to work on
Taskotron and the stuff I've listed above is likely to consume a decent
chunk of time.
Tim
9 years, 2 months
Taskotron Staging Has Been Deployed
by Tim Flink
This has been a long time coming but after running on smaller systems
for the last couple months to make sure that all the parts are running
smoothly, Taskotron is now running in staging:
https://taskotron.stg.fedoraproject.org/
What does this mean? It means that we are almost ready to turn on the
production Taskotron system and turn off AutoQA. The staging
environment will be used to test the code in a production-ish
environment so that we aren't testing new configuration or
features in production and is one of the last steps before we
can truly say that Taskotron is running in Fedora.
We're planning to deploy the production systems sometime next week
so if you are responsible for a package and follow the results from
AutoQA, please take a look at the Taskotron output for your packages
and let us know if there are any discrepancies that we may have missed
in our testing. If you're a tester (or anyone else), feel free to look
through the results and let us know if you see anything that doesn't
seem right.
Task results can be found at:
https://taskotron.stg.fedoraproject.org/resultsdb/jobs
Simulated bodhi comments from the running tasks can be found at:
https://taskotron.stg.fedoraproject.org/fakefedorainfra/boji/comments/0
Please report any issues found to:
https://phab.qadevel.cloud.fedoraproject.org/
While replacing AutoQA is a significant milestone, Taskotron is far
from complete. Keep an eye out for blog posts and mailing list threads
about the next steps for Taskotron once the production system is up and
running. If you have any questions, come find one of us in #fedora-qa,
qa-devel@ or continue a thread here.
Tim
9 years, 2 months
Phabricator Updated on qadevel-stg
by Tim Flink
I just did new phabricator builds and updated qadevel-stg. It seems
to be working but please take a look at it to see if I've missed
something.
There have been some UI changes but most things seem to be working as
they have been.
Tim
9 years, 2 months
2014-06-30 Canceled: Fedora QA Devel Meeting
by Tim Flink
Since the Brno RH QE folks are not going to be around Monday and
Tuesday, I don't see much of a point in having a QA devel meeting
tomorrow.
If you have questions, feel free to ask on IRC or on the list.
Tim
9 years, 2 months