Hey all,
While we're discussing meeting times, I'd also like to discuss rotating
chair duties so that 1) nobody is saddled with it all the time, and 2)
the Chair 'o the Week (TM) shows up prepared to run the meeting.
That means:
- Has the action items from the last meeting at hand to run through those
- Has the Trac report at hand to go through
- Has called for any new items that are urgent: So, for example if we
have something really pressing it can go before just churning through
tickets and #actions
- Will send the meeting minutes to the mailing list after the meeting
I added a section to the wiki:
https://fedoraproject.org/wiki/Cloud#Meetings
With the next seven meeting dates. Can we have folks step up and claim
chair? (Should be a member of the working group, ideally, or at least
regular participant.)
Thoughts, comments, flames? Any volunteers?
Best,
jzb
--
Joe Brockmeier | Community Team, OSAS
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
Hi, folks. Thought this might be of interest. I just hacked autocloud
support into my new nightly image finder thingy. So if you look at:
https://www.happyassassin.net/nightlies.html
now, you will see some cloud images colored red, indicating their tests
failed. You won't see any colored green because no cloud image for F24
or Rawhide has passed any tests in the last 28 days, but once one does,
you should =)
As there's still no API for the production autocloud instance, I seeded
with results pulled from the datagrepper logs. The fedmsg consumer
should update it with results as they come in, from now on.
I may add another table for the 'two week atomic' stable release
nightlies soon...
I think going forward we may want to make PDC the official store of
'did this image pass tests' data, though, so maybe we can look at
sending the info there instead and the nightly finder can just consume
it.
For the cloud images that don't show test results (blue links), I think
the tool is correct, it doesn't look like Autocloud actually tested
them...but let me know if any look wrong. It's kinda hard to tell
manually because the Autocloud summary view is fairly useless (it does
nothing to tell you what image each test is for, so you have to go
click on every single one separately and look at the file name).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
Minutes are here:
https://meetbot.fedoraproject.org/fedora-meeting-1/2016-04-13/fedora_cloud_…
And text below:
=============================================
#fedora-meeting-1: Fedora Cloud Working Group
=============================================
Meeting started by jzb at 17:03:44 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2016-04-13/fedora_cloud_…
.
Meeting summary
---------------
* Origin on Fedora (jzb, 17:08:31)
* LINK: https://fedoraproject.org/wiki/FAD_Cloud_WG_2016 (tflink,
17:09:23)
* ACTION: jzb create Wiki page for OpenShift work (jzb, 17:21:41)
* last week's actions (jzb, 17:28:58)
* ACTION: jberkus to update Fedora-Dockerfiles examples for Kubernetes
(ticket #125) (jzb, 17:30:04)
* ACTION: imcleod wrangle karma for Factory updates (Ticket 131)
(jzb, 17:30:38)
* ACTION: imcleod take ticket 136 on vagrant file fixups (jzb,
17:30:47)
* ACTION: kushal to drop a mail to the list after creating a ticket
for new base image release for f23 (jzb, 17:31:08)
* Fedora Activity Day (jzb, 17:40:50)
* ACTION: kushal add flight info to FAD page (jzb, 17:43:06)
* LINK: https://fedoraproject.org/wiki/How_to_organize_a_FAD (nb,
17:46:00)
* open floor (jzb, 17:46:41)
* LINK: https://rdoproject.org/ " (puiterwijk, 17:50:17)
Meeting ended at 17:54:38 UTC.
Action Items
------------
* jzb create Wiki page for OpenShift work
* jberkus to update Fedora-Dockerfiles examples for Kubernetes (ticket
#125)
* imcleod wrangle karma for Factory updates (Ticket 131)
* imcleod take ticket 136 on vagrant file fixups
* kushal to drop a mail to the list after creating a ticket for new base
image release for f23
* kushal add flight info to FAD page
Action Items, by person
-----------------------
* jberkus
* jberkus to update Fedora-Dockerfiles examples for Kubernetes (ticket
#125)
* jzb
* jzb create Wiki page for OpenShift work
* **UNASSIGNED**
* imcleod wrangle karma for Factory updates (Ticket 131)
* imcleod take ticket 136 on vagrant file fixups
* kushal to drop a mail to the list after creating a ticket for new
base image release for f23
* kushal add flight info to FAD page
People Present (lines said)
---------------------------
* jzb (114)
* scollier (59)
* jberkus (39)
* puiterwijk (37)
* dustymabe (25)
* zodbot (20)
* maxamillion (20)
* jbrooks (16)
* goern][ (10)
* nzwulfin (7)
* rtnpro (6)
* nirik (5)
* tflink (4)
* nb (4)
* bcl (2)
* pryanka (1)
* trishnag (1)
* roshi (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Joe Brockmeier | Community Team, OSAS
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
Hi,
I am still packing for super early morning trip. Will miss the meeting
tonight. See you all next week.
Kushal
--
Fedora Cloud Engineer
CPython Core Developer
https://kushaldas.inhttps://dgplug.org
So the 'canonical' list of release blocking images:
https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fe…
has a 'yes' for the Cloud x86_64 network install image.
This seems suspicious to me. Who does network installs of the Cloud
tree? Why would you want to do that? Why would it be a release-blocking
deliverable?
I can't find a paper trail that explicitly indicates that people
actually sat down and said "uh huh, yup, we're blocking on the
netinst". https://fedorahosted.org/cloud/ticket/118 is where the Cloud
WG "signed off" on the blocking list for F23, but there's no specific
discussion of the netinst there. Nor do I see any in
https://meetbot.fedoraproject.org/fedora-meeting-1/2015-09-09/cloud_wg.2015… .
I'm interested for the purpose of the daily check for missing images
(right now this is done in my 'check-compose' tool and uses a list I
made up myself called "expected images", which is not quite the same as
the list of "release blocking deliverables"; but I want to move it into
compose-utils and make it strictly a check for the canonical list of
release-blocking images.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
Dear all,
You are kindly invited to the meeting:
Fedora Cloud Workgroup on 2016-04-13 from 17:00:00 to 18:00:00 UTC
At fedora-meeting-1(a)irc.freenode.net
The meeting will be about:
Standing meeting for the Fedora Cloud Workgroup
Source: https://apps.fedoraproject.org/calendar/meeting/1999/
Hey all, I have put together a mattermost docker container image and send a
pull request to
[1] a short writeup is at [2]
//G
[1] - https://github.com/fedora-cloud/Fedora-Dockerfiles
[2] - http://b4mad.net/datenbrei/mattermost/in-a-container/
--
Principal Software Engineer - Systems Design & Engineering
Mobile: +49 171 2801345
Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
Handelsregister: Amtsgericht München, HRB 153243,
Geschäftsführer: Paul Argiry, Charles Cachera, Michael Cunningham, Michael
O'Neill
Hi, folks!
So I noticed today that F24 nightly composes are missing Cloud images.
This is, I think, because 32-bit Cloud image generation is still
enabled for F24, and it's failing due to the known kernel bug
preventing 32-bit boot working at all:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13434747http://koji.fedoraproject.org/koji/taskinfo?taskID=13434766https://kojipkgs.fedoraproject.org//work/tasks/4766/13434766/screenshot.ppm
I believe when the i386 image build fails the Koji task fails, and when
the Koji task fails Pungi just doesn't pull in any of the images - even
though the x86_64 subtask succeeded and built images.
Obviously we could consider solving that in Pungi somehow, but it led
me to wondering whether we actually want 32-bit image generation
enabled at all any more. It seems from this ticket:
https://fedorahosted.org/cloud/ticket/106
and this meeting discussion:
https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2015-09-09/cloud_wg.…
that the intent was to 'sunset' the i386 images in the F24 cycle. I'm
not sure whether that means you still want them built, or not. So can
the WG please clarify if they still want i386 Cloud images to be built
at all? If not, releng can disable them in the Pungi config.
Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
Dear all,
You are kindly invited to the meeting:
Fedora Cloud Workgroup on 2016-04-06 from 17:00:00 to 18:00:00 UTC
At fedora-meeting-1(a)irc.freenode.net
The meeting will be about:
Standing meeting for the Fedora Cloud Workgroup
Source: https://apps.fedoraproject.org/calendar/meeting/1999/