[cloud] #171: [VOTE] To mark recent failure on Atomic images as non blocking

2016-09-15 Thread Fedora Cloud Trac Tickets 
#171: [VOTE] To mark recent failure on Atomic images as non blocking
+
 Reporter:  kushal  |  Owner:
 Type:  task| Status:  new
 Priority:  normal  |  Milestone:  Future
Component:  --- |   Keywords:
+
 You can view the error at
 https://apps.fedoraproject.org/autocloud/jobs/606/output#227

 Related bugzilla bus

 * https://bugzilla.redhat.com/show_bug.cgi?id=1265295
 * https://bugzilla.redhat.com/show_bug.cgi?id=1353688

 We want to mark these issues as non-blocking.

 Can the WG members please vote in? (Aye, Nay, Abstain).

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #171: [VOTE] To mark recent failure on Atomic images as non blocking

2016-09-15 Thread Fedora Cloud Trac Tickets 
#171: [VOTE] To mark recent failure on Atomic images as non blocking
+-
 Reporter:  kushal  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by kushal):

 First I should vote:  Aye (to make them non-blocking).

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: overlayfs for AFTER Fedora 25

2016-09-15 Thread Kushal Das 
On 14/09/16, Adam Miller wrote:
> On Wed, Sep 14, 2016 at 2:14 PM, Dusty Mabe  wrote:
> >
> > In the cloud meeting today I brought up overlayfs and F25. After
> > discussing with the engineers closer to the technology they recommend
> > waiting to move to overlayfs as the default in F26.
> >
> > I think this will work well because it will give us some time to allow
> > people to "try" overlayfs in F25 (we should provide good docs on this)
> > and then give us feedback before we go with it as default in F26. If
> > the feedback is bad then maybe we wouldn't even go with it in F26, but
> > hopefully that won't be the case.
> >
> > Thoughts?
> 
> Seems a little conservative, but I'm not opposed.
> 
> I've been under the impression that part of the point of the Two Week
> Release cycle was to be able to deliver new stuff faster and fix
> issues faster but playing it safe isn't inherently a bad approach
> either.
For two week atomic we are not tied with the Fedora 25 release cycle. We
can enable it in our release when we think it is ready for the
consumers. It does not have to wait F26 release. For example we see it
is in good condition after one week of F25 release, we can then enable
it default in the next 2WA release.

Kushal
-- 
Fedora Cloud Engineer
CPython Core Developer
https://kushaldas.in
https://dgplug.org
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #171: [VOTE] To mark recent failure on Atomic images as non blocking

2016-09-15 Thread Fedora Cloud Trac Tickets 
#171: [VOTE] To mark recent failure on Atomic images as non blocking
+-
 Reporter:  kushal  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by trishnag):

 What is the point of having the testcase if we want to release images even
 though they bugs?

 This testcase is also **not a non-gating test** AFAIK.
 https://github.com/kushaldas/tunirtests/blob/master/cloudtests.py#L61-L98

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #171: [VOTE] To mark recent failure on Atomic images as non blocking

2016-09-15 Thread Fedora Cloud Trac Tickets 
#171: [VOTE] To mark recent failure on Atomic images as non blocking
+-
 Reporter:  kushal  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by dustymabe):

 Replying to [comment:2 trishnag]:
 > What is the point of having the testcase if we want to release images
 even though they have bugs?
 >

 So that we can find and fix bugs faster when they do happen. If we choose
 to release with the bug anyway then we know it exists and can guide users
 accordingly until it is fixed.

 > This testcase is also **not a non-gating test** AFAIK.
 https://github.com/kushaldas/tunirtests/blob/master/cloudtests.py#L61-L98

 Does that link prove it is a non-gating test? Where is the list of gating
 vs non-gating?

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #171: [VOTE] To mark recent failure on Atomic images as non blocking

2016-09-15 Thread Fedora Cloud Trac Tickets 
#171: [VOTE] To mark recent failure on Atomic images as non blocking
+-
 Reporter:  kushal  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by dustymabe):

 I vote aye (+1) to release with this known bug.

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #171: [VOTE] To mark recent failure on Atomic images as non blocking

2016-09-15 Thread Fedora Cloud Trac Tickets 
#171: [VOTE] To mark recent failure on Atomic images as non blocking
+-
 Reporter:  kushal  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by trishnag):

 Replying to [comment:3 dustymabe]:
 > Replying to [comment:2 trishnag]:
 > > What is the point of having the testcase if we want to release images
 even though they have bugs?
 > >
 >
 > So that we can find and fix bugs faster when they do happen. If we
 choose to release with the bug anyway then we know it exists and can guide
 users accordingly until it is fixed.
 >
 Okay, if we choose to release with the bug anyway does that mean that the
 bug is not going to affect users much?
 > > This testcase is also **not a non-gating test** AFAIK.
 https://github.com/kushaldas/tunirtests/blob/master/cloudtests.py#L61-L98
 >
 > Does that link prove it is a non-gating test? Where is the list of
 gating vs non-gating?
 We put non-gating tests here
 https://github.com/kushaldas/tunirtests/blob/master/nongatingtests.py
 Rest of the files have gating tests. Journal logging test is a gating
 test. So we have it in a separate file.

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #171: [VOTE] To mark recent failure on Atomic images as non blocking

2016-09-15 Thread Fedora Cloud Trac Tickets 
#171: [VOTE] To mark recent failure on Atomic images as non blocking
+-
 Reporter:  kushal  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by dustymabe):

 Replying to [comment:5 trishnag]:
 > Replying to [comment:3 dustymabe]:
 > > Replying to [comment:2 trishnag]:
 > > > What is the point of having the testcase if we want to release
 images even though they have bugs?
 > > >
 > >
 > > So that we can find and fix bugs faster when they do happen. If we
 choose to release with the bug anyway then we know it exists and can guide
 users accordingly until it is fixed.
 > >
 > Okay, if we choose to release with the bug anyway does it mean that the
 bug is not going to affect users much?

 Yeah. The idea is that we put items to a vote and determine the severity.
 This bug is not that severe as it is just a logging issue. While
 important, it shouldn't block release in this case IMHO. My opinion could
 change in the future, but since this has been going out in our images for
 some time now we aren't making the currently released image any worse by
 releasing the next image.


 > > > This testcase is also **not a non-gating test** AFAIK.
 https://github.com/kushaldas/tunirtests/blob/master/cloudtests.py#L61-L98
 > >
 > > Does that link prove it is a non-gating test? Where is the list of
 gating vs non-gating?
 > We put non-gating tests here
 https://github.com/kushaldas/tunirtests/blob/master/nongatingtests.py
 > Rest of the files have gating tests. Journal logging test is a gating
 test. So we have it in a separate file.


 Thanks

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: overlayfs for AFTER Fedora 25

2016-09-15 Thread Matthew Miller 
On Thu, Sep 15, 2016 at 01:55:16PM +0530, Kushal Das wrote:
> For two week atomic we are not tied with the Fedora 25 release cycle. We
> can enable it in our release when we think it is ready for the
> consumers. It does not have to wait F26 release. For example we see it
> is in good condition after one week of F25 release, we can then enable
> it default in the next 2WA release.

+1

-- 
Matthew Miller

Fedora Project Leader
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: overlayfs for AFTER Fedora 25

2016-09-15 Thread Matthew Miller 
On Wed, Sep 14, 2016 at 02:47:09PM -0700, Josh Berkus wrote:
> > Seems a little conservative, but I'm not opposed.
> > I've been under the impression that part of the point of the Two Week
> > Release cycle was to be able to deliver new stuff faster and fix
> > issues faster but playing it safe isn't inherently a bad approach
> > either.
> When is F26 out?

Next June.

-- 
Matthew Miller

Fedora Project Leader
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: overlayfs for AFTER Fedora 25

2016-09-15 Thread Dusty Mabe 


On 09/15/2016 04:25 AM, Kushal Das wrote:
> On 14/09/16, Adam Miller wrote:
>> On Wed, Sep 14, 2016 at 2:14 PM, Dusty Mabe  wrote:
>>>
>>> In the cloud meeting today I brought up overlayfs and F25. After
>>> discussing with the engineers closer to the technology they recommend
>>> waiting to move to overlayfs as the default in F26.
>>>
>>> I think this will work well because it will give us some time to allow
>>> people to "try" overlayfs in F25 (we should provide good docs on this)
>>> and then give us feedback before we go with it as default in F26. If
>>> the feedback is bad then maybe we wouldn't even go with it in F26, but
>>> hopefully that won't be the case.
>>>
>>> Thoughts?
>>
>> Seems a little conservative, but I'm not opposed.
>>
>> I've been under the impression that part of the point of the Two Week
>> Release cycle was to be able to deliver new stuff faster and fix
>> issues faster but playing it safe isn't inherently a bad approach
>> either.
> For two week atomic we are not tied with the Fedora 25 release cycle. We
> can enable it in our release when we think it is ready for the
> consumers. It does not have to wait F26 release. For example we see it
> is in good condition after one week of F25 release, we can then enable
> it default in the next 2WA release.
> 

That is correct, but changing a default like that might be a bad idea.
My opinion is that it should happen on a major release boundary.

The user still has the option to choose to user overlayfs if they
want.

Dusty
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #171: [VOTE] To mark recent failure on Atomic images as non blocking

2016-09-15 Thread Fedora Cloud Trac Tickets 
#171: [VOTE] To mark recent failure on Atomic images as non blocking
+-
 Reporter:  kushal  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by jberkus):

 So:

 My reason for unblocking these tests is simple:

 The version we are *currently distributing* also fails these tests.

 If we had a version on getfedora which passed the tests, and it was only
 the pending version which was failing, I'd keep them blocking.  But I see
 no point in continuing to block on tests which the "stable" version also
 doesn't pass.  Clearly we've decided it's acceptable to ship a version of
 Fedora Atomic which fails the log tests.

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #171: [VOTE] To mark recent failure on Atomic images as non blocking

2016-09-15 Thread Fedora Cloud Trac Tickets 
#171: [VOTE] To mark recent failure on Atomic images as non blocking
+-
 Reporter:  kushal  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by trishnag):

 Replying to [comment:6 dustymabe]:
 > Replying to [comment:5 trishnag]:
 > > Replying to [comment:3 dustymabe]:
 > > > Replying to [comment:2 trishnag]:
 > > > > What is the point of having the testcase if we want to release
 images even though they have bugs?
 > > > >
 > > >
 > > > So that we can find and fix bugs faster when they do happen. If we
 choose to release with the bug anyway then we know it exists and can guide
 users accordingly until it is fixed.
 > > >
 > > Okay, if we choose to release with the bug anyway does it mean that
 the bug is not going to affect users much?
 >
 > Yeah. The idea is that we put items to a vote and determine the
 severity. This bug is not that severe as it is just a logging issue. While
 important, it shouldn't block release in this case IMHO. My opinion could
 change in the future, but since this has been going out in our images for
 some time now we aren't making the currently released image any worse by
 releasing the next image.
 Got you. Thanks dustymabe.
 >
 >
 > > > > This testcase is also **not a non-gating test** AFAIK.
 https://github.com/kushaldas/tunirtests/blob/master/cloudtests.py#L61-L98
 > > >
 > > > Does that link prove it is a non-gating test? Where is the list of
 gating vs non-gating?
 > > We put non-gating tests here
 https://github.com/kushaldas/tunirtests/blob/master/nongatingtests.py
 > > Rest of the files have gating tests. Journal logging test is a gating
 test. So we have it in a separate file.
 >
 >
 > Thanks

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #171: [VOTE] To mark recent failure on Atomic images as non blocking

2016-09-15 Thread Fedora Cloud Trac Tickets 
#171: [VOTE] To mark recent failure on Atomic images as non blocking
+-
 Reporter:  kushal  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by mattdm):

 Replying to [comment:7 jberkus]:
 > If we had a version on getfedora which passed the tests, and it was only
 the pending version which was failing, I'd keep them blocking.  But I see
 no point in continuing to block on tests which the "stable" version also
 doesn't pass.  Clearly we've decided it's acceptable to ship a version of
 Fedora Atomic which fails the log tests.

 This implies a second decision to be made: once there ''is'' a working
 version, should the non-blocking test become a blocking one?

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #171: [VOTE] To mark recent failure on Atomic images as non blocking

2016-09-15 Thread Fedora Cloud Trac Tickets 
#171: [VOTE] To mark recent failure on Atomic images as non blocking
+-
 Reporter:  kushal  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by jberkus):

 My inclination is to say "non-blocking" because I do a lot of testing on
 Atomic Host and never noticed the bug, personally.  I generally figure
 that gating bugs should be ones which either (a) carry significant
 security risk or (b) make the system unusable, or significantly less
 usable, than the prior release.

 However, surely the Fedora project has some standards around what's
 considered a gating bug?

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #171: [VOTE] To mark recent failure on Atomic images as non blocking

2016-09-15 Thread Fedora Cloud Trac Tickets 
#171: [VOTE] To mark recent failure on Atomic images as non blocking
+-
 Reporter:  kushal  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by mattdm):

 Replying to [comment:10 jberkus]:
 > However, surely the Fedora project has some standards around what's
 considered a gating bug?

 We do for the traditional 6-month releases:

 https://fedoraproject.org/wiki/Fedora_Release_Criteria

 For example, functional system logging is considered to block an alpha
 release:

 https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria#System_logging

 The Atomic release doesn't have to follow the exact same rules, of course,
 but I'd highly suggest keeping in the ballpark and coordinating with QA
 for expertise.

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #171: [VOTE] To mark recent failure on Atomic images as non blocking

2016-09-15 Thread Fedora Cloud Trac Tickets 
#171: [VOTE] To mark recent failure on Atomic images as non blocking
+-
 Reporter:  kushal  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by jberkus):

 Yeah, so then the recommendation would be to unblock until this bug is
 fixed, but then make it a gating issue thereafter.

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #171: [VOTE] To mark recent failure on Atomic images as non blocking

2016-09-15 Thread Fedora Cloud Trac Tickets 
#171: [VOTE] To mark recent failure on Atomic images as non blocking
+-
 Reporter:  kushal  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by sayanchowdhury):

 Replying to [comment:12 jberkus]:
 > Yeah, so then the recommendation would be to unblock until this bug is
 fixed, but then make it a gating issue thereafter.

 Agree. I wonder if we can have a concrete release criteria as emphasis on
 a issue can change quickly.

 I don't know if my vote counts but I am +1 (Aye) to mark these as non-
 blocking.

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #171: [VOTE] To mark recent failure on Atomic images as non blocking

2016-09-15 Thread Fedora Cloud Trac Tickets 
#171: [VOTE] To mark recent failure on Atomic images as non blocking
+-
 Reporter:  kushal  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by trishnag):

 Replying to [comment:12 jberkus]:
 > Yeah, so then the recommendation would be to unblock until this bug is
 fixed, but then make it a gating issue thereafter.
 +1 to this.

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org