#10215 RFR: Demo Kiwi TCMS instance for QA
Closed: Fixed 2 years ago by jbley. Opened 2 years ago by tflink.

Describe what you would like us to do:


Some of us in QA have been discussing the idea of using something other than the wiki for storing test cases. Specifically, Kiwi TCMS. At this point, setting up a demo instance would really help with the discussion around whether this is worth putting any more energy into.

It doesn't need to be much - enough to run a django app w/ mariadb and an SSL cert (letsencrypt is fine). No backups, no monitoring, no SLA needed.

When do you need this to be done by? (YYYY/MM/DD)


It's not terribly urgent. Sometime before 2021/10/01 would be great.


Hi,

would an openshift project be sufficient for you to run the app?

Metadata Update from @humaton:
- Issue tagged with: low-gain, medium-trouble, ops

2 years ago

Hi,

would an openshift project be sufficient for you to run the app?

I believe so, yes.

A few more questions. :)

  • Can it use postgresql for db? (not a blocker, but we prefer postgres).
  • Does it need any persistent storage? Or is everything in db?
  • Can it use OIDC for auth?

Anyhow, if openshift will work, perhaps we could stand up a staging instance? It would be nicer still if we could just give you an account on our devel openshift cluster, but... we don't have one still. ;(

Metadata Update from @mohanboddu:
- Issue priority set to: Waiting on Assignee (was: Needs Review)

2 years ago

A few more questions. :)

  • Can it use postgresql for db? (not a blocker, but we prefer postgres).

I think there is some support for postgres but their default is mariadb.

  • Does it need any persistent storage? Or is everything in db?

I believe that everything is in the db.

  • Can it use OIDC for auth?

No, it can't. That's a known blocker that we will need to deal with if we end up going forward with using Kiwi

Anyhow, if openshift will work, perhaps we could stand up a staging instance? It would be nicer still if we could just give you an account on our devel openshift cluster, but... we don't have one still. ;(

Honestly, whatever is the easiest to create and destroy would be best. using a devel account/cluster would work best but seeing as that's not a thing, whatever's closest to it and involves the least amount of effort would be my first choice.

I do want to re-iterate that we're only looking at Kiwi right now as an option and we're a ways off from making any decisions on using it. My interest is in a public-facing demo instance so that more people can see how it works in a fedora-qa-like context and participate in the discussion around whether we want to use it or not.

Yeah, so I guess the two options are:
1) a staging instance (but this will need to be in ansible and setup with packages, etc
or
(and I think this might be better for you)
2) a aws instance where you can just install it however you like?

Yeah, I'd prefer 2) if openshift involves packaging work right now.

At the moment, I don't want to put any more work into this than I have to since it's only a demo instance. The easiest way to deploy Kiwi is to just use the published docker containers.

this is an interesting topic, we are trying to move away from nitrate (which kiwi forked before) in RHEL :)

What stats would you like for a aws instance then? mem/cpu/disk? and fedora or centos or rhel or ? for os?

Some of us in QA have been discussing the idea of using something other than the wiki for storing test cases.

What are the exact requirements for "storing test cases"? Is this meant for manual test cases only? Or for automated stuff as well? Is the core part of the use case tracking historical results of the test execution? I believe it makes sense to keep tools across fedora and rhel as consistent as possible to provide users with a comfortable experience when working with tests.

Some of us in QA have been discussing the idea of using something other than the wiki for storing test cases.

What are the exact requirements for "storing test cases"? Is this meant for manual test cases only? Or for automated stuff as well? Is the core part of the use case tracking historical results of the test execution? I believe it makes sense to keep tools across fedora and rhel as consistent as possible to provide users with a comfortable experience when working with tests.

Honestly, it's as much about storing results than it is about storing test cases but the emphasis is on the test cases/results we use for release decisions. There is an emphasis on manual tests but there are a bunch of the test cases which are also automated.

I also want to emphasize that no decisions have been made and I'm not trying to avoid any discussion. It just seems a bit silly to start a conversation around a TCMS without some concrete demo when there are 2 feasible options that I know of - Kiwi and "roll our own" so I want to have that demo in place before starting much of a conversation.

What stats would you like for a aws instance then? mem/cpu/disk? and fedora or centos or rhel or ? for os?

I'd prefer CentOS 7 for ease of deployment with docker-compose.

In terms of system resources, 4 GiB memory/ 2-ish cpu/ 15 GiB disk should work for a demo.

Upstream guidelines do mention that t2.medium and t3.medium have been good enough in their experience if those are reasonable options.

Sorry for the delay here. :(

A t3.medium should be up at 52.34.129.149 and have your ssh key in for root.
The security-zone isn't blocking anything, so you will want to firewall off everything except things you need. :)

Please let us know if you need anything else at all.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Issue status updated to: Open (was: Closed)

2 years ago

Issue status updated to: Closed (was: Open)
Issue close_status updated to: Fixed

2 years ago

Login to comment on this ticket.

Metadata
Boards 1
ops Status: Done