Release criteria: kickstart

"Jóhann B. Guðmundsson" johannbg at
Thu Aug 25 23:54:27 UTC 2011

On 08/25/2011 10:49 PM, Stephen John Smoogen wrote:
> On Thu, Aug 25, 2011 at 16:20, Adam Williamson<awilliam at>  wrote:
>> On Thu, 2011-08-25 at 14:35 -0600, Stephen John Smoogen wrote:
>>> On Thu, Aug 25, 2011 at 14:25, Chris Lumens<clumens at>  wrote:
>>>>> kickstart is a very broad area; you can write extremely complex
>>>>> kickstart files that do a lot of stuff. So broadly what we'd need to do
>>>>> is define a subset of kickstart functionality that we expect to work,
>>>>> and then possibly divide that up by release phase (so some stuff must
>>>>> work by Beta, the rest by Final, for e.g.)
>>>>> anaconda devs following this list, do you have any existing expectations
>>>>> as to what level of kickstart functionality ought to be in place for
>>>>> releases, and when you think would be appropriate?
>>>>> So far it seems everyone more or less agrees that it should be possible
>>>>> to do at least a basic unattended kickstart install by Beta.
>>>> You're right, kickstart is incredibly broad.  I don't think we could
>>>> ever hope to come up with criteria to cover all of it.  I guess the best
>>>> we can do is define criteria in terms of something else we already have.
>>> I would go for the classical kickstart test for Alpha:
>>> Does it take a minimal kickstart and build a default system. The
>>> minimal being the exact stuff that would be created if a person just
>>> clicked through a release.
>> Oh, I like that. That's very good.
>>> For Beta
>>> Take these X broken kickstarts, does it bail at the appropriate places.
>>> Take these Y working kickstarts, does it work.
>>> Where Y is a set of items that can be tested on say a KVM or a
>>> "default" desktop defined somewhere.
>> I'm not so keen on that; it's a bit specific. One of my fetishes with
>> the criteria is to keep them generic so they don't have to keep being
>> changed all the time; I wouldn't want a criterion to rely on some
>> specific kickstart file we keep lying around somewhere.
> Well I was trying to suggest something that wasn't handy-wavy. At some
> point a set of criteria are going to be needed for what is expected
> out anaconda at the minimum. From that criteria a set of test
> kickstarts can be built. If they dont' work then you have a blocker.
> Is that better?

I'm still on the opinion that we should not be adding an ks testing to 
the alpha criteria.

Cant we just create a set of most commonly ks use cases in ks files for 
releng and they can use pungi to test it with and post the result 
somewhere online with pass/fail more of an autoqa task and say all those 
must pass before beta?

Where does the need for those ks testing suddenly come from and why do 
we need to have those ks test involved in alpha?


More information about the test mailing list