Re: Cloud and Server Q

2016-10-04 Thread Matthew Miller 
On Tue, Oct 04, 2016 at 12:58:05PM -0700, Josh Berkus wrote:
> What this is sounding like is a huge discrepancy between what the
> Council, PRD group, etc. think we should be doing and what we can
> actually do.
> 
> Given that, I think I should tell the designer to push the design
> changes back.

I don't see how that follows. In the ideal — and I think most likely,
since the bugs making F25 not work are being knocked off — case, we'll
have Atomic built on F25 at F25 GA date. In the less ideal case, we'll
keep shipping the F24-based one, but there's no reason that can't work
with the new Atomic-focused design. For that matter, we could launch
that _before_ the GA.

-- 
Matthew Miller

Fedora Project Leader
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Cloud and Server Q

2016-10-04 Thread Matthew Miller 
On Tue, Oct 04, 2016 at 11:13:02AM -0400, Colin Walters wrote:
> It's not that simple - this is a messy topic.  What I think this
> is about isn't delaying or blocking - it's *prioritization*.  If
> an issue comes up in Anaconda or systemd or whatever
> that affects the "next AH", we need those teams to priortize
> those fixes the same as they do for Workstation or Server.
> 
> As far as I know the "blocker flag" is the main means
> of cutting through all of the red tape.

Yeah, I've been talking about this problem for a while — basically,
since Release Blocker is the only big attention-forcing hammer we have,
we tend to hit too many things with it. We need a different way.

> Now, we could discuss alternatives, such as having
> Atomic Host being able to carry its own overrides
> temporarily.

As you know, I'm in favor of this possibility should it come to that.

-- 
Matthew Miller

Fedora Project Leader
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Cloud and Server Q

2016-10-04 Thread Matthew Miller 
On Tue, Oct 04, 2016 at 09:46:44AM -0400, Paul W. Frields wrote:
> We need to be clear on the difference between considering it important
> for Atomic images to be ready on release day, and being "release
> blockers."  The latter has a very specific meaning as Adam W can
> attest.  Being a deliverable is not the same as being release
> blocking.  This seems like a problem of vocabulary.

Agreed that it's a terminology problem. Things like "catastrophic
infrastructure failure and the getfedora.org website totally doesn't
work" would block the release, but not, as far as I know, be a "release
blocker". (Or some similar example.) This is in some ways similar to
that. 


> I think mattdm would agree we don't want to potentially,
> *indefinitely* block a six-month release with a deliverable that can
> be fixed and re-released in two weeks.  That's what "release blocking"
> means.  If it's not ready, the release doesn't go out.  This was an
> overwhelming point in having that two week cycle -- to give more
> flexiblity vs. the standard Fedora release.
> 
> Does this mean we shouldn't strive to have Atomic images ready
> day-and-date on GA?  No.  We missed this narrowly in F24, as I recall,
> and we should avoid repeating that, if at all possible.  But let's not
> undermine a major dimension of the two-week release by confusing the
> release-blocker definition.

As we get into the Grand World of Modularity, there's going to be more
and more stuff like this. If the base runtime is updating on a one
month cycle, and GNOME updating whenever the upstream x.y.1 is ready,
and server roles all coming out as each is updated... a "release" is
more a line in the sand than anything else.

-- 
Matthew Miller

Fedora Project Leader
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Fedora 25 atomic images?

2016-10-04 Thread Matthew Miller 
On Mon, Oct 03, 2016 at 04:05:24PM -0700, Adam Williamson wrote:
> As Dennis said, there are Atomic images produced nightly as part of the
> *regular* Branched composes. So you don't see any Fedora-Atomic-25-
> (foo) fedmsgs because there are no Fedora-Atomic-25 composes. There are
> just Fedora-25 composes that include Atomic images.
> 
> There won't be any need for Fedora-Atomic-25 composes until Fedora 25
> goes stable.
> 
> 'Fedora-Atomic' composes are basically post-release stable nightly
> composes, only at present we only do them in order to get the Atomic
> images, so we call them 'Fedora-Atomic' composes.

A! Got it through my head now. Thanks. :)

One can see this unified compose at, for example,
https://apps.fedoraproject.org/autocloud/jobs/302 (and see that the
Atomic parts are failing).

What causes the transition from this to Fedora-Atomic-25? Manual
changes? Is there a documented SOP for this?

-- 
Matthew Miller

Fedora Project Leader
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Cloud and Server Q

2016-10-04 Thread Josh Berkus 
On 10/04/2016 11:21 AM, Stephen John Smoogen wrote:

> The corollary is that if the people who are supposed to be working and
> caring for an edition are not doing the work already, making it
> release blocking doesn't magically fix it. What happens instead is
> that people who are doing that work on other editions have to add this
> to their last dash get it across the line.

What this is sounding like is a huge discrepancy between what the
Council, PRD group, etc. think we should be doing and what we can
actually do.

Given that, I think I should tell the designer to push the design
changes back.

-- 
--
Josh Berkus
Project Atomic
Red Hat OSAS
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Current Fedora 25 Atomic images are failing to boot

2016-10-04 Thread Jonathan Lebon 
Just an update on this. We're passed the kernel panic issue
now that dracut-fips was backed out, but we're now getting
a reboot loop due to:

https://bugzilla.redhat.com/show_bug.cgi?id=1290659

- Original Message -
> 
> 
> On 10/03/2016 02:47 AM, Trishna Guha wrote:
> > On Wed, Sep 28, 2016 at 9:26 PM, Kushal Das  wrote:
> >> Hi all,
> >>
> >> The current F25 Atomic images are failing to boot[1], I never managed to
> >> reach
> >> dracut emergency shell in my local box.
> >>
> >> Can anyone else also please have a look?
> >>
> >> [1] https://apps.fedoraproject.org/autocloud/jobs/704/output
> > 
> > All the Fedora 25 Atomic images: qcow2, vagrant-libvirt,
> > vagrant-virtualbox are failing to boot.
> 
> 
> There is a kernel panic happening early in boot. Here is the serial
> console log from one of those boots:
> 
> https://paste.fedoraproject.org/442720/14755209/
> 
> Dusty
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
> 
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Cloud and Server Q

2016-10-04 Thread Chris Murphy 
On Tue, Oct 4, 2016 at 11:59 AM, Josh Berkus  wrote:
> On 10/04/2016 08:13 AM, Colin Walters wrote:
>>
>> On Tue, Oct 4, 2016, at 09:46 AM, Paul W. Frields wrote:
>>> >
>>> > I think mattdm would agree we don't want to potentially,
>>> > *indefinitely* block a six-month release with a deliverable that can
>>> > be fixed and re-released in two weeks.
>> It's not that simple - this is a messy topic.  What I think this
>> is about isn't delaying or blocking - it's *prioritization*.  If
>> an issue comes up in Anaconda or systemd or whatever
>> that affects the "next AH", we need those teams to priortize
>> those fixes the same as they do for Workstation or Server.
>
> Yes, this is exactly the problem I'm raising.  We've had an issue with
> F25-base Atomic not booting for a couple weeks now, and until the last
> couple of days, nobody has been working on it.  It seems to be a simple
> fact of the Fedora release cycle that if something isn't
> release-blocking, it doesn't get done. This isn't new, it's an issue
> which has plagued Fedora Atomic for, as far as I can tell, its entire
> existence.

Perhaps in some cases, but it's not always true. Spins get done even
though they're not release blocking. The issue with release blocking
status is it compels the expert in the particular area of failure to
become involved. And that is a limited resource. Possibly a big part
of the reason for Atomic failures is there's a lack of documentation
across the board, both ostree stuff as well as releng's processes, and
then when ostree failures happen the logs are often lacking in such
detail that a Tarot card reader might have a better chance of guessing
what's going on than the logs indicate. This makes it difficult to get
contributors involved. And makes it damn near impossible any of them
would want to become even intermediately competent - it's a heavy
investment.



-- 
Chris Murphy
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Cloud and Server Q

2016-10-04 Thread Stephen John Smoogen 
On 4 October 2016 at 13:59, Josh Berkus  wrote:
> On 10/04/2016 08:13 AM, Colin Walters wrote:
>>
>> On Tue, Oct 4, 2016, at 09:46 AM, Paul W. Frields wrote:
>>> >
>>> > I think mattdm would agree we don't want to potentially,
>>> > *indefinitely* block a six-month release with a deliverable that can
>>> > be fixed and re-released in two weeks.
>> It's not that simple - this is a messy topic.  What I think this
>> is about isn't delaying or blocking - it's *prioritization*.  If
>> an issue comes up in Anaconda or systemd or whatever
>> that affects the "next AH", we need those teams to priortize
>> those fixes the same as they do for Workstation or Server.
>
> Yes, this is exactly the problem I'm raising.  We've had an issue with
> F25-base Atomic not booting for a couple weeks now, and until the last
> couple of days, nobody has been working on it.  It seems to be a simple
> fact of the Fedora release cycle that if something isn't
> release-blocking, it doesn't get done. This isn't new, it's an issue
> which has plagued Fedora Atomic for, as far as I can tell, its entire
> existence.
>

The corollary is that if the people who are supposed to be working and
caring for an edition are not doing the work already, making it
release blocking doesn't magically fix it. What happens instead is
that people who are doing that work on other editions have to add this
to their last dash get it across the line.

If people aren't all that interested in a Fedora Cloud or Fedora
Atomic it would be better that the resources were spent where they
could be concentrated. I say this with the same view towards Fedora
Server or Fedora . If all we are doing is
making it so people not really interested in it HAVE to carry it
onward then it is a worse failure than saying "we would have been
better off in Arch or Madreia or Ubuntu Atomic" because we will have
lost all four F's. People won't be having Fun, they won't have
Freedom, they won't be Friends because of bitterness, and it will all
build up to make sure nothing is 'First'.  If that means that all we
do is build a couple of desktop distros then so be it.. at least
people will be working on something that meets those 4 Fs.


> And, like I said, this also ties into the F25 cycle getfedora.org
> redesign.  We simply can't go ahead with a redesign which emphasizes
> Atomic over the cloud base image if F25-base Atomic isn't ready at
> release time.  We'll have to hold that back, and that's something the
> design team needs to know.
>
> --
> --
> Josh Berkus
> Project Atomic
> Red Hat OSAS
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Cloud and Server Q

2016-10-04 Thread Josh Berkus 
On 10/04/2016 08:13 AM, Colin Walters wrote:
> 
> On Tue, Oct 4, 2016, at 09:46 AM, Paul W. Frields wrote:
>> > 
>> > I think mattdm would agree we don't want to potentially,
>> > *indefinitely* block a six-month release with a deliverable that can
>> > be fixed and re-released in two weeks.
> It's not that simple - this is a messy topic.  What I think this
> is about isn't delaying or blocking - it's *prioritization*.  If
> an issue comes up in Anaconda or systemd or whatever
> that affects the "next AH", we need those teams to priortize
> those fixes the same as they do for Workstation or Server.

Yes, this is exactly the problem I'm raising.  We've had an issue with
F25-base Atomic not booting for a couple weeks now, and until the last
couple of days, nobody has been working on it.  It seems to be a simple
fact of the Fedora release cycle that if something isn't
release-blocking, it doesn't get done. This isn't new, it's an issue
which has plagued Fedora Atomic for, as far as I can tell, its entire
existence.

And, like I said, this also ties into the F25 cycle getfedora.org
redesign.  We simply can't go ahead with a redesign which emphasizes
Atomic over the cloud base image if F25-base Atomic isn't ready at
release time.  We'll have to hold that back, and that's something the
design team needs to know.

-- 
--
Josh Berkus
Project Atomic
Red Hat OSAS
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Cloud and Server Q

2016-10-04 Thread Colin Walters 


On Tue, Oct 4, 2016, at 09:46 AM, Paul W. Frields wrote:
> 
> I think mattdm would agree we don't want to potentially,
> *indefinitely* block a six-month release with a deliverable that can
> be fixed and re-released in two weeks.

It's not that simple - this is a messy topic.  What I think this
is about isn't delaying or blocking - it's *prioritization*.  If
an issue comes up in Anaconda or systemd or whatever
that affects the "next AH", we need those teams to priortize
those fixes the same as they do for Workstation or Server.

As far as I know the "blocker flag" is the main means
of cutting through all of the red tape.

Now, we could discuss alternatives, such as having
Atomic Host being able to carry its own overrides
temporarily.
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Cloud and Server Q

2016-10-04 Thread Paul W. Frields 
On Tue, Oct 04, 2016 at 08:14:43AM -0500, Dennis Gilmore wrote:
> On Friday, September 30, 2016 5:01:52 PM CDT Josh Boyer wrote:
> > On Fri, Sep 30, 2016 at 4:41 PM, Josh Berkus  wrote:
> > > On 09/30/2016 01:11 PM, Adam Miller wrote:
> > >> On Fri, Sep 30, 2016 at 8:35 AM, Matthew Miller
> > >> 
> > >>  wrote:
> > >>> On Thu, Sep 29, 2016 at 04:16:15PM -0700, Adam Williamson wrote:
> > > think QA clearly understands what cloud image(s) are release blocking,
> > > as previously they were just the non-atomic images.
> >  
> >  Which images are prominent on the download pages and how much of a
> >  relationship there is between that and 'release blocking' status is
> >  *also* not my problem, but I'd agree with you (Chris) that it'd be
> >  rather strange for the most prominently advertised deliverable for a
> >  given product not to be a release-blocking one.
> > >>> 
> > >>> I don't think that Atomic *needs* to be release blocking, because if it
> > >>> misses the grand unified release, we have the ability to update it at
> > >>> the next cycle, so it's less of a big deal. But if we collectively
> > >>> prefer to make sure everything is lined up on the release day... I can
> > >>> see arguments for that, too.
> > > 
> > > Well, currently I'm working with the designers on a new page for Atomic
> > > F25.  So if that's NOT going to be live the day of the F25 release, then
> > > it's something we need to know ahead of time.
> > > 
> > > I also really don't like the message Atomic not being ready sends.   We
> > > will have three branches for GetFedora: Workstation, Server, and Atomic.
> > > 
> > >  If Atomic isn't ready the day of the release, it looks pretty bad;
> > > 
> > > that's saying we're ok with only being 2/3 ready, or that despite
> > > promoting Atomic to 1st class status we don't really believe it's
> > > important.
> > So... there is a pretty big disparity between what you just said and
> > what FESCo has been told in the past two meetings.  Jan has been
> > trying to get release blocking deliverables for the Cloud WG (now
> > Atomic?) confirmed for a while [1].  Two weeks ago, Kushal confirmed
> > the existing base images are release blocking and Atomic is not.  That
> > was repeated in today's meeting[2] as well:
> > 
> > 16:44:56  Cloud base image is the only blocking deliverable.
> > 16:44:59  Atomic is not.
> > 
> > I realize this WG is in the middle of rebooting itself, but to have
> > clearly conflicting information from the WG members is a bit
> > concerning.
> > 
> I will note that Atomic is not delivered as part of the relase at all. it is 
> only delivered as a stable artifact via the two week atomic host release 
> process. So there is no possible way it can be release blocking, there seems 
> to be some major confusion and disconnect here.

We need to be clear on the difference between considering it important
for Atomic images to be ready on release day, and being "release
blockers."  The latter has a very specific meaning as Adam W can
attest.  Being a deliverable is not the same as being release
blocking.  This seems like a problem of vocabulary.

I think mattdm would agree we don't want to potentially,
*indefinitely* block a six-month release with a deliverable that can
be fixed and re-released in two weeks.  That's what "release blocking"
means.  If it's not ready, the release doesn't go out.  This was an
overwhelming point in having that two week cycle -- to give more
flexiblity vs. the standard Fedora release.

Does this mean we shouldn't strive to have Atomic images ready
day-and-date on GA?  No.  We missed this narrowly in F24, as I recall,
and we should avoid repeating that, if at all possible.  But let's not
undermine a major dimension of the two-week release by confusing the
release-blocker definition.



-- 
Paul W. Frieldshttp://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Fedora cloud status update

2016-10-04 Thread Benson Muite 

Hi,

Can you take a minute to give feed back on Fedora cloud talking points 
here - hope have picked most relevant points and no errors, but 
corrections welcome:

https://fedoraproject.org/wiki/Fedora_25_talking_points#Fedora_Cloud

Thanks,
Benson
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Cloud and Server Q

2016-10-04 Thread Dennis Gilmore 
On Friday, September 30, 2016 5:01:52 PM CDT Josh Boyer wrote:
> On Fri, Sep 30, 2016 at 4:41 PM, Josh Berkus  wrote:
> > On 09/30/2016 01:11 PM, Adam Miller wrote:
> >> On Fri, Sep 30, 2016 at 8:35 AM, Matthew Miller
> >> 
> >>  wrote:
> >>> On Thu, Sep 29, 2016 at 04:16:15PM -0700, Adam Williamson wrote:
> > think QA clearly understands what cloud image(s) are release blocking,
> > as previously they were just the non-atomic images.
>  
>  Which images are prominent on the download pages and how much of a
>  relationship there is between that and 'release blocking' status is
>  *also* not my problem, but I'd agree with you (Chris) that it'd be
>  rather strange for the most prominently advertised deliverable for a
>  given product not to be a release-blocking one.
> >>> 
> >>> I don't think that Atomic *needs* to be release blocking, because if it
> >>> misses the grand unified release, we have the ability to update it at
> >>> the next cycle, so it's less of a big deal. But if we collectively
> >>> prefer to make sure everything is lined up on the release day... I can
> >>> see arguments for that, too.
> > 
> > Well, currently I'm working with the designers on a new page for Atomic
> > F25.  So if that's NOT going to be live the day of the F25 release, then
> > it's something we need to know ahead of time.
> > 
> > I also really don't like the message Atomic not being ready sends.   We
> > will have three branches for GetFedora: Workstation, Server, and Atomic.
> > 
> >  If Atomic isn't ready the day of the release, it looks pretty bad;
> > 
> > that's saying we're ok with only being 2/3 ready, or that despite
> > promoting Atomic to 1st class status we don't really believe it's
> > important.
> So... there is a pretty big disparity between what you just said and
> what FESCo has been told in the past two meetings.  Jan has been
> trying to get release blocking deliverables for the Cloud WG (now
> Atomic?) confirmed for a while [1].  Two weeks ago, Kushal confirmed
> the existing base images are release blocking and Atomic is not.  That
> was repeated in today's meeting[2] as well:
> 
> 16:44:56  Cloud base image is the only blocking deliverable.
> 16:44:59  Atomic is not.
> 
> I realize this WG is in the middle of rebooting itself, but to have
> clearly conflicting information from the WG members is a bit
> concerning.
> 
I will note that Atomic is not delivered as part of the relase at all. it is 
only delivered as a stable artifact via the two week atomic host release 
process. So there is no possible way it can be release blocking, there seems 
to be some major confusion and disconnect here.

Dennis

signature.asc
Description: This is a digitally signed message part.
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Current Fedora 25 Atomic images are failing to boot

2016-10-04 Thread Dennis Gilmore 
On Monday, October 3, 2016 1:16:04 PM CDT Chris Murphy wrote:
> On Mon, Oct 3, 2016 at 1:06 PM, Colin Walters  wrote:
> > On Mon, Oct 3, 2016, at 02:57 PM, Dusty Mabe wrote:
> >> There is a kernel panic happening early in boot. Here is the serial
> > 
> >> console log from one of those boots:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1380866
> 
> Does this need to be marked as a freeze exception to back the change
> out for beta candidate images to work?

No it does not. Atomic is not a release deliverable anymore.

Dennis

signature.asc
Description: This is a digitally signed message part.
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Cloud and Server Q

2016-10-04 Thread Kushal Das 
On 30/09/16, Josh Berkus wrote:
> On 09/30/2016 02:01 PM, Josh Boyer wrote:
> 
> > 16:44:56  Cloud base image is the only blocking deliverable.
> > 16:44:59  Atomic is not.
> > 
> > I realize this WG is in the middle of rebooting itself, but to have
> > clearly conflicting information from the WG members is a bit
> > concerning.
> 
Atomic host image is the deliverable for the Atomic WG, which is under 2
week release cycle. We sync up with the official release version at the
time of GA, but we continue to be in our 2 week atomic release cycle
then on the 6month old GA. This is my understanding about all the work
done for 2 Week Atomic.

Now I may be completely wrong to understand our 2 week release cycle
process, but this is what I followed for the release-infra work till
now.

Kushal
-- 
Fedora Cloud Engineer
CPython Core Developer
https://kushaldas.in
https://dgplug.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Request for review of blocking deliverables for Fedora 25

2016-10-04 Thread Kushal Das 
On 16/09/16, Jan Kurik wrote:
> On Fri, Sep 16, 2016 at 2:27 PM, Colin Walters  wrote:
> >
> >
> > On Fri, Sep 16, 2016, at 04:14 AM, Jan Kurik wrote:
> >> Hi,
> >>
> >> may I request any feedback on this topic, and/or adding this topic to
> >> the next Cloud WG meeting agenda ?
> >
> > It'd be nice to make Atomic Host a blocking deliverable - I think
> > we have sufficient experience now and manpower to do that.
> 
> How this should work ? I am asking because Atomic is delivered
> bi-weekly and Fedora releases are delivered two times a year. Perhaps
> delivering the last released Atomic build before Fedora release GA
> date might work. Any other/better ideas how this should be
> synchronized ?
This is my understanding too. We sync up Atomic host with the latest
released Fedora GA, and then follow on our normal 2-week release cycle.
This does not make the 2 week atomic into the official 6month old
release cycle story.

Kushal
-- 
Fedora Cloud Engineer
CPython Core Developer
https://kushaldas.in
https://dgplug.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org