Big Data Image: call for heroes
by Haïkel
Hey,
Since our last discussion about what we should include in the Big data
image, not much happened.
I suggest that we work on:
1. listing key packages for the big data images (ie: ambari ?)
2. which services should be start at runtime
3. test cases (I think we agreed about reusing blog posts from the Big
Data SIG folks)
4. Anything else ?
We need to get something working soon.
We'll probably organize a cloud BoF at Flock, I would love to hear
from you if you're coming there.
Best regards,
H.
9 years, 9 months
Re: 2014-07-09 @ **17:00 UTC** - F21 Blocker Review #1
by Bruno Wolff III
On Wed, Jul 09, 2014 at 23:07:12 +0400,
Igor Gnatenko <ignatenkobrain(a)fedoraproject.org> wrote:
>Hi,
>On Wed, Jul 9, 2014 at 4:20 AM, Mike Ruckman <roshi(a)fedoraproject.org> wrote:
>> # F21 Blocker Review meeting #1
>> # Date: 2014-07-09
>> # Time: 17:00 UTC (13:00 EST, 10:00 PST)
>> # Location: #fedora-blocker-review on irc.freenode.neteria
>> ...
>> ==
>> // Mike
>> Fedora QA
>> irc: roshi | twitter: roshi_fedora
>> blog: roshi.fedorapeople.org
>Why this msg not going to the test-announce@? :P
I don't think the meeting log needs to go to test-announce. If the complaint
is really about the meeting notice, then that is arguably a reasonable
suggestion.
9 years, 9 months
First cut of comps and spin changes for cloud
by Ian McLeod
Attached are two very simple patches, one to f21 comps and one to the
cloud install spin kickstart. (I do not have commit rights on the repos
containing these files.)
I offered to have a go at this yesterday on #fedora-cloud. I gather
today may be too late for the upcoming compose, but I see no reason not
to at least start a discussion on the mailing list. Hopefully I haven't
misunderstood the goal here.
Per the chat yesterday, I've added two groups and included both of them
in the spin.
1) cloud-server - This is meant to be packages which need to end up
inside of servers/images running in a cloud environment. For the
moment, the only thing in here is cloud-init. Another potential
candidate is the Nova agent for Rackspace, but I've yet to work that
through the package approval process. I'm sure there are others.
Discuss.
2) cloud-management - This is meant to be packages that allow management
of instances and images on cloud environments. I've included the EC2
and Rackspace python and ruby bindings as well as libcloud and,
selfishly, the cloud-relevant portions of Image Factory. Again, I'm
sure I'm missing something. Discuss.
-Ian
9 years, 9 months
Fedora 21 Alpha validation test work
by Adam Williamson
Hi, folks.
So, we're scheduled for Alpha TC1 tomorrow. We had a nice happy
co-operative plan where QA and the WGs would collaborate on revising the
release validation test process for Fedora.next...
...which, well, didn't really happen. As of this morning we were nowhere
near having a viable validation process. So I went for plan B: I spent
today more or less pulling the entire thing out of my ass.
It's a bit rough around the edges, but I think we more or less have
something workable now. I have skipped the draft stage for a lot of
documents just in the interest of having something vaguely workable in
time for TC1; of course, the pages can be revised as much as necessary
as we work with them.
It's a bit hard to remember everything I've done, but we now have a
draft Alpha Release Criteria page which should cover all
release-blocking media, which for now I'm assuming includes the
Workstation live media, Server minimal and offline install media, Cloud
and ARM disk images, and possibly some kind of generic network install
image. That draft is at
https://fedoraproject.org/wiki/User:Adamwill/Draft_F21_Alpha_criteria
and is based on the stuff from
https://fedoraproject.org/wiki/User:Adamwill/Draft_server_release_criteria , https://fedoraproject.org/wiki/User:Adamwill/Draft_workstation_release_cr... and https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Alpha_Relea... , plus some adjustments to the templates that handle the preamble.
We have a new validation matrix, for Server product-specific tests:
https://fedoraproject.org/wiki/QA:Server_validation_results_template
The Desktop matrix has been adjusted to cover - not quite elegantly, but
at least cover - both the Workstation product and the KDE spin:
https://fedoraproject.org/wiki/QA:Desktop_validation_results_template
The Base matrix has been extended to add a couple of new test cases that
came out of the Product criteria drafting process, but actually aren't
really product specific, and has had its columns adjusted to be
product-y:
https://fedoraproject.org/wiki/QA:Base_validation_results_template
The installation matrix has similarly had a couple of new criteria
wedged in, but much more importantly, I ripped the netinst, DVD and live
image 'sanity test' sections and replaced them with an ARM-style table
where a single 'generic' test case is run against several images on
several platforms - that's the "Default boot and install" section, so
please cast an eye over it:
https://fedoraproject.org/wiki/QA:Fedora_21_Install_Results_Template
and I made a small change to the release validation test event SOP to
list the server matrix as one to create:
https://fedoraproject.org/wiki/QA/SOP_Release_Validation_Test_Event
Here are links to all (I think) of the new test cases I had to write as
I went along:
https://fedoraproject.org/wiki/QA:Testcase_Boot_default_install
https://fedoraproject.org/wiki/QA:Testcase_kickstart_user_creation
https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation
https://fedoraproject.org/wiki/QA:Testcase_base_selinux
https://fedoraproject.org/wiki/QA:Testcase_Server_firewall_default
https://fedoraproject.org/wiki/QA:Testcase_kickstart_firewall
https://fedoraproject.org/wiki/QA:Testcase_Server_cockpit_default
The following test cases already existed, but are newly included in the
release validation process (they were written for test days):
https://fedoraproject.org/wiki/QA:Testcase_FreeIPA_realmd_join
https://fedoraproject.org/wiki/QA:Testcase_realmd_join_kickstart
https://fedoraproject.org/wiki/QA:Testcase_realmd_join_server
There are still quite a few i's to dot and t's to cross. There are some
release criteria and test cases that explicitly reference 'the DVD'
image that will need to be adjusted. We need to apply the 'associated
release criterion' template to all the new test cases, and probably
clean up some categorizations. Various other process documentation pages
may need to be updated, we'll have to check through all of them. But I
think now we at least have the broad strokes of what's needed for .next
validation testing.
All feedback on the above changes is of course welcome! Please do cast
your eye over and point out anything I missed, anything that looks
silly, any possible improvements and so on. Remember, though, this is
really *test process* design: we're not actually doing product design
here, if you think there are issues with the Fedora.next changes
themselves, that goes to the WGs or FESCo. As far as this work is
concerned, we're just trying to test the new Products as they're
designed (all of the above is based off of the Product PRDs and tech
specs).
I'll take time tomorrow to do some polishing, and of course look at any
and all feedback on the stuff I did today.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 9 months
Draft combined Alpha release criteria for F21
by Adam Williamson
Hi, folks. So I've just slapped together the existing release criteria
drafts into a draft combined Fedora 21 Alpha release criteria page:
https://fedoraproject.org/wiki/User:Adamwill/Draft_F21_Alpha_criteria
product-specific notes:
Cloud - AFAICS the Cloud-specific draft Roshi did only took things away,
it didn't add any, so there is basically no change as far as Cloud is
concerned. The wirding should exempt Cloud from all inappropriate
criteria - please point out anywhere this is not the case.
Workstation - none of the proposed new criteria are Alpha criteria. The
Alpha proposals for a separate Workstation criteria page were
simplifications of the more 'generic' criteria that apply to multiple
desktops.
There appears to be considerable confusion over an important desktop-ish
question for F21, namely:
"Are network installs of GNOME/Workstation and/or KDE considered to be
release-blocking?"
That is, do we only block on the Workstation (product) and KDE (spin)
live images, or are we also going to block on network installation of
either or both?
As this has not been established, I have mostly left the desktop-y
criteria and preamble wording as-is, with the intent that we can fudge
it in the interpretation. If we decide that we do not block on desktop
network installs, we can refine and focus the wording somewhat; if we
decide to block on them, I'll have to insert something into the preamble
and possibly fiddling with the 'release-blocking desktop' wording a bit
to clarify precisely what we're talking about. This particularly affects
the desktop criteria (obviously) and the "Package sets" criterion, which
looks distinctly wobbly and would be a complete dead letter if we only
care about the live images.
I also just remembered that Workstation apparently wants to make it
possible to install KDE as an alternative desktop post-install, which
is...another fun thing to think about? Goddamnit, this is becoming a
real PITA.
Server - I plucked out the criteria that seemed most Alpha-y and
inserted them into this draft in appropriate places, basically. You'll
note that Server alone has a Product-specific section, down the bottom.
A couple of the criteria proposed for Server and/or Workstation actually
work okay as 'generic' criteria, so I added those into the generic
section: those would be "SELinux configuration" (SELinux must be
enforcing after installation - all Products want this, I believe) and
"Scripted user creation" (which is primarily for Server, but since
there's only one installer, it's probably fine for it to go in the
generic installer criteria).
I tweaked the "DVD package source" criterion to not refer to a
now-obsolete deliverable - it talks more generically about a "dedicated
installer image that contains packages". As things stand, I believe the
only such release-blocking medium will be the Server image that contains
server role packages (once we actually, you know, make that, but it's
listed in the Server tech spec).
I included the latest draft of my proposed "system service manipulation"
criterion, since this is still a draft and it seemed best to get all the
proposals in one place together.
I updated the definition of 'release-blocking images' in the preamble to
be appropriate for Fedora.next:
"The current set of release-blocking images includes the images defined
by the three primary Products - Server, Workstation and Cloud - in their
product requirement documents and/or technical specifications, and the
KDE live image."
(I could make that a lot damn cleaner if all the Products defined their
deliverables in the same document, btw :> some do it in PRD, some in
tech spec. Actually, we *still* ought to have a deliverables policy.
That's been on my todo list for, er, three years? Patches welcome. It's
not actually a QA job.)
There are probably still some corners of this that don't entirely make
sense any more, please point out any logic fails etc. But I think it's
probably at least better than the current page -
https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria , which
is completely un-Next-ified - as a basis for Alpha testing, which I once
again remind folks, is supposed to start tomorrow :) So I'd like to get
this into 'production' before Alpha TC1 drops.
Next steps are going to be to write a couple more missing test cases,
and come up with a vaguely plausible set of test matrices. I'll try and
get that done this afternoon.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 9 months
Re: Proposed generic release criterion: service manipulation
by Adam Williamson
On Mon, 2014-07-07 at 11:50 -0400, Richard Ryniker wrote:
> > It must be possible to start, stop, enable and disable system
> > services using the initialization framework's standard commands.
>
> This sounds like any service that fails (will not start, will not
> stop...) will block a release.
You're the second person to read it that way, so clearly I wrote it
wrong, but no, that is not the intention at all.
> Should there be a distinction between "critical" services that must work
> or block release, and lesser services that may fail and not block
> release? For example, journald might be deemed critical, while sheepdog
> is not.
The intention is that the *mechanism* for manipulating services - that
is, at present, systemd - works to the extent specified. The criterion
assumes the notional service being manipulated is functional. In my
head, if I'd actually been writing the criterion you thought I was, I'd
have written something like "all system services in Fedora packages" or
"all system services on the release-blocking media" or something like
that - tied it to a *concrete* set of service scripts, not the entirely
abstract notion of "system services" that's in the current language.
Anyway, as I said, when two people read something wrong, I generally
figure I wrote it wrong, so - can anyone suggest wording that would make
this clearer?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 9 months
Re: Proposed generic release criterion: service manipulation
by Adam Williamson
On Mon, 2014-07-07 at 10:45 -0400, Miloslav Trmač wrote:
> ----- Original Message -----
> > On 07/04/2014 03:22 PM, Adam Williamson wrote:
> > > System service manipulation
> > >
> > > It must be possible to start, stop, enable and disable system
> > > services using the initialization framework's standard commands.
> > >
> > > I don't think it needs any footnotes beyond standard 'References'.
> > >
> > > Does this seem reasonable to everyone? Thanks!
> >
> > Is this another way of saying "All services must provide a systemd
> > unit file"?
No.
> Same question here. I’ve never heard of an “initialization framework”
> before, I'd guess that’s the piece of code and conventions to
> run .ctors. Just saying systemd would simplify things (though,
> perhaps s/must provide/must be controlled by/ ?)
As mitr (I think) understands, the criterion is intended to test
systemd. I said "initialization framework" because I have a pathological
attachment to generics, I guess. :P I meant it to be read as a generic
term for 'sysvinit, or systemd, or whatever we invent in five years to
replace systemd', so I don't have to rewrite the release criterion then.
If someone can think of a more commonly understood generic term, I'm
happy to substitute that. We *could* just say systemd, if everyone
promises to let me say "I told you so!" when someone notices in five
years it still says 'systemd' even though we all switched to openrc or
something. (har, har.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 9 months
Cloud SIG Meeting Minutes for 2014-07-03
by Haïkel
Hello,
The Cloud WG was able to held its weekly meeting despite summer :)
You'll find below the minutes and the logs of the meeting
=========================
#fedora-meeting: Cloud WG
=========================
Meeting started by number80 at 14:10:58 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2014-07-03/fedora-meeting...
.
Meeting summary
---------------
* Hello everyone (number80, 14:11:34)
* Working Group (number80, 14:14:29)
* Automatic Smoketests on Image Build (number80, 14:16:17)
* taskotron moving toward production and replacing AutoQA soon
(number80, 14:17:34)
* roshi working on fabric-based test suite for cloud images
(number80, 14:19:34)
* Deliverables and release engineering changes for Fedora.Next
(number80, 14:22:31)
* LINK: https://fedorahosted.org/cloud/ticket/50 (number80,
14:22:37)
* changes freeze is scheduled on 2014/07/08 (number80, 14:23:59)
* ACTION: jzb ticket 50: https://fedorahosted.org/cloud/ticket/50
(jzb, 14:24:23)
* start communication/collaboration on cloud image updates (number80,
14:25:45)
* ACTION: mattdm to keep moving this forward; agrimm to help (mattdm,
14:38:01)
* Docker image (number80, 14:41:14)
* dgilmore and jgreguske are working on updating koji to support
docker images creation (number80, 14:42:28)
* ACTION: mattdm to ping lsm5 about that too (as he is the feature
owner) (mattdm, 14:43:57)
* LINK: https://fedorahosted.org/cloud/ticket/65 (number80,
14:44:12)
* Project Atomic (number80, 14:46:58)
* LINK: https://fedorahosted.org/cloud/ticket/64 (number80,
14:47:03)
* ACTION: agrimm is helping on ticket 64:
https://fedorahosted.org/cloud/ticket/64 (number80, 14:50:04)
* looking for integrating of ostree trees into fedora infrastructure
(number80, 14:52:45)
* ACTION: jzb trying to setup a cantas instance for the cloud SIG
(number80, 14:58:47)
* next steps on test plan (number80, 15:00:22)
* LINK: https://fedorahosted.org/cloud/ticket/61 (number80,
15:00:24)
* adamw is syncing all tests docs from all WGs (number80, 15:01:32)
* open floor (number80, 15:04:14)
* ACTION: number80 organize the vote to welcome agrimm in the WG
(number80, 15:07:47)
Meeting ended at 15:12:17 UTC.
Action Items
------------
* jzb ticket 50: https://fedorahosted.org/cloud/ticket/50
* mattdm to keep moving this forward; agrimm to help
* mattdm to ping lsm5 about that too (as he is the feature owner)
* agrimm is helping on ticket 64:
https://fedorahosted.org/cloud/ticket/64
* jzb trying to setup a cantas instance for the cloud SIG
* number80 organize the vote to welcome agrimm in the WG
Action Items, by person
-----------------------
* agrimm
* mattdm to keep moving this forward; agrimm to help
* agrimm is helping on ticket 64:
https://fedorahosted.org/cloud/ticket/64
* number80 organize the vote to welcome agrimm in the WG
* jzb
* jzb ticket 50: https://fedorahosted.org/cloud/ticket/50
* jzb trying to setup a cantas instance for the cloud SIG
* mattdm
* mattdm to keep moving this forward; agrimm to help
* mattdm to ping lsm5 about that too (as he is the feature owner)
* number80
* number80 organize the vote to welcome agrimm in the WG
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* number80 (87)
* jzb (37)
* mattdm (35)
* roshi (22)
* agrimm (21)
* zodbot (12)
* dgilmore (7)
* frankieonuonga (6)
* jsmith (2)
* geppeto (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting/2014-07-03/fedora-meeting...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting/2014-07-03/fedora-meeting...
Log:
http://meetbot.fedoraproject.org/fedora-meeting/2014-07-03/fedora-meeting...
9 years, 9 months