cloud July 2014

cloud@lists.fedoraproject.org

19 participants
75 discussions

[Fedocal] Reminder meeting : Fedora Cloud Workgroup
by jzb＠fedoraproject.org 10 Jul '14

10 Jul '14

Dear all, You are kindly invited to the meeting: Fedora Cloud Workgroup on 2014-07-10 from 14:00:00 to 15:00:00 UTC At fedora-meeting(a)irc.freenode.net The meeting will be about: Standing meeting for the Fedora Cloud Workgroup. Source: https://apps.fedoraproject.org/calendar//meeting/309/

3 3

Big Data Image: call for heroes
by Haïkel 10 Jul '14

10 Jul '14

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.

1 0

Re: 2014-07-09 @ **17:00 UTC** - F21 Blocker Review #1
by Bruno Wolff III 09 Jul '14

09 Jul '14

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.

1 0

2014-07-09 @ **17:00 UTC** - F21 Blocker Review #1
by Mike Ruckman 08 Jul '14

08 Jul '14

# 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.net Well folks, it's that time again. Throughout the planning process for Fedora.next, we've been able to identify some potential blockers and we should review them. As of today there are 13 proposed blockers and one proposed FE for F21 Alpha. The full list can be found here: https://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist With the branch today we'll be getting back into the swing of regular blocker review meetings - so prepare to re-block off your Wednesday mornings :) This meeting will also be a good chance to figure out ways of handling the different products going forward. Information on the release criteria for F21 can be found on the wiki [0]. Product specific plans are still being solidified, but that should be sorted quickly. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting See you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria == // Mike Fedora QA irc: roshi | twitter: roshi_fedora blog: roshi.fedorapeople.org

1 0

First cut of comps and spin changes for cloud
by Ian McLeod 08 Jul '14

08 Jul '14

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

1 0

Fedora 21 Alpha validation test work
by Adam Williamson 07 Jul '14

07 Jul '14

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_crit… and https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Alpha_Release… , 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

1 0

Draft combined Alpha release criteria for F21
by Adam Williamson 07 Jul '14

07 Jul '14

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

1 0

Re: Proposed generic release criterion: service manipulation
by Adam Williamson 07 Jul '14

07 Jul '14

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

1 0

Re: Proposed generic release criterion: service manipulation
by Adam Williamson 07 Jul '14

07 Jul '14

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

1 0

Cloud SIG Meeting Minutes for 2014-07-03
by Haïkel 03 Jul '14

03 Jul '14

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.2… . 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.2… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2014-07-03/fedora-meeting.2… Log: http://meetbot.fedoraproject.org/fedora-meeting/2014-07-03/fedora-meeting.2…

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud July 2014