infra/tickets

Fork 1

Hosting space for nitrate project #2673

New issue

Closed

opened 2011-03-16 02:41:55 +00:00 by jlaska · 6 comments

jlaska commented

2011-03-16 02:41:55 +00:00

= Project Sponsor =

BR '''Project Team (FAS Names):''' rhe, vchen, jlaska
BR '''Infrastructure Sponsor:''' ???

= Project Info =

BR '''Project Name:''' nitrate server
BR '''Target Audience:''' Fedora QA
BR '''Expiration/Delivery Date (required):''' After Fedora 15 is released (eta 2011-05-17)
BR '''Description/Summary:'''

The Fedora QA team is interested in exploring nitrate to replace our use of wiki for managing test results from community test events (e.g. test days, release validation etc...)

A virtual guest where we can create+manage a mysql database, and host a Django-based application should be sufficient.

BR '''Project plan (Detailed):'''

The nitrate project (see https://fedorahosted.org/nitrate) is a test case management system created by Red Hat associates. The nitrate project uses the testopia database schema, but relies on a Django-based front-end to work around several issues with upstream testopia. The most notable issue being incompatible licensing of the Testopia front-end.

The Fedora QA team is interested in exploring nitrate to replace our use of wiki for managing test results from community test events (e.g. test days, release validation etc...). Hurry (Fedora QA) has been developing a list of requirements. However, in order to complete requirements, it will be helpful to have a proof-of-concept server available to use for several upcoming test runs.

BR '''Goals:'''

experiment with managing several community test events using nitrate
identify additional missing features or workflows

= Project Sponsor = [[BR]] '''Project Team (FAS Names):''' rhe, vchen, jlaska [[BR]] '''Infrastructure Sponsor:''' ??? = Project Info = [[BR]] '''Project Name:''' nitrate server [[BR]] '''Target Audience:''' Fedora QA [[BR]] '''Expiration/Delivery Date (required):''' After Fedora 15 is released (eta 2011-05-17) [[BR]] '''Description/Summary:''' The Fedora QA team is interested in exploring nitrate to replace our use of wiki for managing test results from community test events (e.g. test days, release validation etc...) A virtual guest where we can create+manage a mysql database, and host a Django-based application should be sufficient. [[BR]] '''Project plan (Detailed):''' The nitrate project (see https://fedorahosted.org/nitrate) is a test case management system created by Red Hat associates. The nitrate project uses the testopia database schema, but relies on a Django-based front-end to work around several issues with upstream testopia. The most notable issue being incompatible licensing of the Testopia front-end. The Fedora QA team is interested in exploring nitrate to replace our use of wiki for managing test results from community test events (e.g. test days, release validation etc...). Hurry (Fedora QA) has been developing a list of requirements. However, in order to complete requirements, it will be helpful to have a proof-of-concept server available to use for several upcoming test runs. [[BR]] '''Goals:''' * experiment with managing several community test events using nitrate * identify additional missing features or workflows

kevin commented

2011-04-08 23:52:42 +00:00

Owner

I'll help you guys out with this one.

Next steps:

Get nitrate packaged
Test on a publictest instance.
Decide some things:
a) does it need it's own local db, or can it use one of our existing db servers?
b) does it need to be load balanced or just a direct instance.

Likely there are many other decisions to make along the way, but we can do so as we come to them. ;)

I'll help you guys out with this one. Next steps: 1. Get nitrate packaged 2. Test on a publictest instance. 3. Decide some things: a) does it need it's own local db, or can it use one of our existing db servers? b) does it need to be load balanced or just a direct instance. Likely there are many other decisions to make along the way, but we can do so as we come to them. ;)

jlaska commented

2011-04-13 01:34:04 +00:00

Author

Replying to [comment:1 kevin]:

Get nitrate packaged

Can the packaging work proceed in parallel, or does it need to be completed before moving to the next step?

Test on a publictest instance.

Looking forward to this step! :)

Decide some things:
a) does it need it's own local db, or can it use one of our existing db servers?
b) does it need to be load balanced or just a direct instance.

I'll ask for guidance from rhe (or nitrate-devel) for this.

Replying to [comment:1 kevin]: > 1. Get nitrate packaged Can the packaging work proceed in parallel, or does it need to be completed before moving to the next step? > 2. Test on a publictest instance. Looking forward to this step! :) > 3. Decide some things: > a) does it need it's own local db, or can it use one of our existing db servers? > b) does it need to be load balanced or just a direct instance. I'll ask for guidance from rhe (or nitrate-devel) for this.

jlaska commented

2011-04-13 21:48:18 +00:00

Author

Replying to [comment:2 jlaska]:

a) does it need it's own local db, or can it use one of our existing db servers? b) does it need to be load balanced or just a direct instance.
I'll ask for guidance from rhe (or nitrate-devel) for this.

A MySQL database on a separate host is preferred.

Replying to [comment:2 jlaska]: > > a) does it need it's own local db, or can it use one of our existing db servers? b) does it need to be load balanced or just a direct instance. > I'll ask for guidance from rhe (or nitrate-devel) for this. A MySQL database on a separate host is preferred.

kevin commented

2011-04-13 22:30:24 +00:00

Owner

Can the packaging work proceed in parallel, or does it need to be completed before moving to the next step?

I'd really prefer the packaging is all worked out first. That way we can install and test that package and know what we are getting, can upgrade easily, etc.

A MySQL database on a separate host is preferred.

ok. We could do a local db on the same publictest for that stage of things, then when we move to staging we can move the db to a db host from there.

> Can the packaging work proceed in parallel, or does it need to be completed before moving to the next step? I'd really prefer the packaging is all worked out first. That way we can install and test that package and know what we are getting, can upgrade easily, etc. >A MySQL database on a separate host is preferred. ok. We could do a local db on the same publictest for that stage of things, then when we move to staging we can move the db to a db host from there.

jlaska commented

2011-04-13 22:54:29 +00:00

Author

Replying to [comment:4 kevin]:

Can the packaging work proceed in parallel, or does it need to be completed before moving to the next step?

I'd really prefer the packaging is all worked out first. That way we can install and test that package and know what we are getting, can upgrade easily, etc.

Certainly understood! Will stay tuned to [https://bugzilla.redhat.com/show_bug.cgi?id=690728 bug#690728] for updates.

Replying to [comment:4 kevin]: > > > Can the packaging work proceed in parallel, or does it need to be completed before moving to the next step? > > I'd really prefer the packaging is all worked out first. That way we can install and test that package and know what we are getting, can upgrade easily, etc. Certainly understood! Will stay tuned to [https://bugzilla.redhat.com/show_bug.cgi?id=690728 bug#690728] for updates.

kevin commented

2013-02-02 00:24:44 +00:00

Owner

I'm going to close this for now.

We can reopen it when/if we get closer to implementing anything.

I'm going to close this for now. We can reopen it when/if we get closer to implementing anything.