Re: Cloud and Server Q

2016-10-05 Thread Adam Miller
On Tue, Oct 4, 2016 at 6:21 AM, Kushal Das  wrote:
> 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.
>

This is correct, Fedora Atomic Two-Week Release was meant to allow
Fedora Atomic more flexibility in it's release cycle. Part of the
initial proposal was to remove it from being directly bound to the
standard six month release cycle. If this is something we want to
change, that's fine. However, if we do that we need to get buy in from
all groups involved in that process instead of just change things out
from everyone. Also, people will need to show up to do the work in
Fedora QA because there's a lot of it and we can't realistically ask
them to take on what is effectively 5 new deliverable artifacts
without assistance (ISO, qcow2, raw, vagrant-vbox, vagrant-libvirt).

-AdamM

> Kushal
> --
> Fedora Cloud Engineer
> CPython Core Developer
> https://kushaldas.in
> https://dgplug.org
> ___
> cloud mailing list -- cl...@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Cloud and Server Q

2016-10-03 Thread Kevin Fenzi
On Thu, 29 Sep 2016 11:17:51 -0400
Stephen Gallagher  wrote:

> On 09/27/2016 07:11 PM, Chris Murphy wrote:
> > Hi,
...snip...
> > I see 8 base images for Cloud that aren't rpm-ostree based. Are they
> > in need of a new home?  
> 
> As best I can tell, "yes".
> 
>  Who's using them?
> 
> No idea

Fedora Infrastructure is definitely using the cloud base image in our
openstack cloud. I would be willing to devote cycles to keeping this
image available and working. 

> So, my thoughts here is that we essentially retire *all* of them and
> then let the Server WG decide to resurrect one or more of them that
> fits with their mission. I think it's better to start from zero and
> add back in the ones that we want rather than to analyze what we have
> and try to decide which ones to abandon.

I'll answer over on the server list too. 

I am not sure how we want all the orginzational stuff to shake out. 
Perhaps if we decided the big high level things we want to
feature/push, there would be some common lines we can divide the work
up into. I guess in the mean time we keep the server group and the
cloud group can become atomic-online or whatever. 

kevin



pgpMd2UbYCUMn.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Cloud and Server Q

2016-09-30 Thread Chris Murphy
On Fri, Sep 30, 2016 at 3:31 PM, 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.
>
> Kushal?
>
> Based on my attendence at the Cloud WG meetings, I had the understanding
> that Atomic was becoming our main deliverable.  If that's not true, then
> I need to pull a whole bunch of changes and put them on ice until Fedora 26.

What also matters is the understanding of others who needed to
understand this. To me it sounds like a baton was dropped. But moving
forward...

What does release blocking mean? There are a bunch of QA criteria and
test cases that help make sure those criteria are met. There are no
atomic host specific criteria or test cases that I'm aware of. I
expect QA probably can't provide significant assistance in QAing the
atomic qcow2 image for this release. How big of a problem is that? Is
there a Fedora policy that requires a default download product to be
QA'd somehow, or to be release blocking? Can Cloud WG take the lead
QA'ing the atomic qcow2 image? What are the releng implications of it
not being release blocking?

For example, during the Fedora 24 cycle there was a neat bug in the
compose process that caused some images to fail. It wasn't possible to
just do another compose and cherry pick the working ISOs from two
different composes (I forget why). Is there anything like that here,
or is there sufficiently good isolation between ostree images and
other images? What happens if release is a go for everything else, but
atomic qcow2 is not working? What I've heard is "fix the problem and
remake the image" similar to the current two week cycle. Does releng
agree, and will there be time between a Thursday "go" and Tuesday
(whatever day it is) "release" to get an atomic qcow2 built and on
getfedora? What if there isn't? What if it's a week after release
before there's a working one?

If the liabilities there can be sorted out satisfactorily I'd say
proceed with Atomic on getfedora.

Next issue is Cloud Base images. Cloud WG needs to decide if these are
going to be created and if so how they're going to get linked to and
from where. Is there a designed landing page for these already? If
not, my thought is have a side bar link to a basic directory listing
for them, rather than the fancy landing page that currently exists for
Fedora 24 Cloud Base images. And demote the Cloud Base images to
non-release blocking. And then whatever contingency for that side bar
link if the Cloud Base images aren't available for release day.



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


Re: Cloud and Server Q

2016-09-30 Thread Josh Boyer
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.

josh

[1] https://fedorahosted.org/fesco/ticket/1626
[2] 
https://meetbot.fedoraproject.org/fedora-meeting/2016-09-30/fesco.2016-09-30-16.01.log.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Cloud and Server Q

2016-09-30 Thread Adam Miller
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.
>

Note that the cycle that Matt is mentioning here is Two-Week
iterations for Atomic Host so the window to release is relatively
rapid compared to the standard ~6 months.

-AdamM


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


Re: Cloud and Server Q

2016-09-30 Thread Adam Miller
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.
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> cloud mailing list -- cl...@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Cloud and Server Q

2016-09-30 Thread Matthew Miller
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.


-- 
Matthew Miller

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


Re: Cloud and Server Q

2016-09-29 Thread Adam Williamson
On Thu, 2016-09-29 at 16:51 -0600, Chris Murphy wrote:
> But I don't
> think QA clearly understands what cloud image(s) are release blocking,
> as previously they were just the non-atomic images.

I don't know what's going on with all this crap, but so far as I'm
concerned I understand perfectly well what the release blocking images
are. It's the ones listed on the release blocking images page which
specifically exists for this purpose:

https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fedora25

(we still need to make the canonical version of this a JSON file
somewhere and generate the human-readable version from the JSON, but
meh, I haven't got around to it yet).

if it doesn't say 'yes' there, it ain't release blocking. Maintaining
that thing is the program manager's problem (i.e. jkurik's), not mine,
but it does somewhat concern me the number of 'TBD's on there. I don't
think the question of what images are 'release blocking' for F25 should
be *remotely* live at this point: it should have been decided weeks
ago, at least by Alpha release. And so far as I remember it, that's
what the protocol was supposed to be, we weren't still supposed to be
kicking around 'is it blocking?' discussions at Beta freeze. I'd
personally be very unhappy with any attempt to significantly change
what that page says right now.

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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Cloud and Server Q

2016-09-29 Thread Chris Murphy
On Thu, Sep 29, 2016 at 4:32 PM, Chris Murphy  wrote:

> Also I read in the Fedora magazine meeting that just wrapped up 30
> minutes ago, that Atomic is the default for F25 (among Cloud
> deliverables). To my ears, "default" and "primary" download sound like
> they'd be release blocking. And the point of that is what bugs would
> block release, what criteria apply or not, to that deliverable.

Maybe default download is orthogonal to release blocking status - even
though off hand to me that seems like an odd duck.

And it looks like it'd be the QCOW2 image that's the propose default,
not the ISO (which uses anaconda, and there are still bugs that would
be blocker worthy if it's the release blocking image). But I don't
think QA clearly understands what cloud image(s) are release blocking,
as previously they were just the non-atomic images.

Other than that I think I'm fairly well sorted out for now.


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


Re: Cloud and Server Q

2016-09-29 Thread Chris Murphy
OK my confusion definitely reduced but still some remains and they may
only be trivial details:



Cloud WG has explicitly mentioned an Atomic WG more than once, most
recently yesterday

17:40:46  #topic Open Floor
17:41:07  what about making the Atomic WG?
[...snip...]
17:42:45  sayan: I assumed that was a given
https://meetbot.fedoraproject.org/teams/fedora_cloud_wg/fedora_cloud_wg.2016-09-28-17.00.log.html

Also I read in the Fedora magazine meeting that just wrapped up 30
minutes ago, that Atomic is the default for F25 (among Cloud
deliverables). To my ears, "default" and "primary" download sound like
they'd be release blocking. And the point of that is what bugs would
block release, what criteria apply or not, to that deliverable.

And in the previous meeting a week ago:

17:14:15  here's  a draft from the designer:
https://raw.githubusercontent.com/fedoradesign/nextweb-assets/master/Mockups/Brochure%20Site/brochure-mock-atomic_WIP.png
17:14:23  sayan: I can't answer that.  someone else has to
17:15:37  the mockup looks good to me
17:16:06  jberkus, looks nice
17:16:12  just so everyone's up to date, the problem is that
this redesign orphans the AWS picker for Cloud base images (as opposed
to Atomic)
17:16:21  I like it
17:16:22  +1
17:16:29  presumably that now needs to live somewhere on Server
17:16:42  but someone more central to Fedora than me needs to
take it to them
17:16:48  So, is cloud base going to server for 25? Or is that 26?
17:17:03  25

https://meetbot.fedoraproject.org/fedora-meeting-1/2016-09-21/fedora_cloud_wg.2016-09-21-17.00.log.html

But then in the Server meeting this week, taking on cloud images was
discussed in the context of Fedora 26, not Fedora 25.

So... if I'm spreading confusion or focusing on details that don't
matter that much, most definitely throw tomatoes (preferably heirloom
or a nice red field).


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


Re: Cloud and Server Q

2016-09-29 Thread Matthew Miller
On Thu, Sep 29, 2016 at 11:17:51AM -0400, Stephen Gallagher wrote:
> Also membership on a WG isn't required for taking action; anyone who has

+1 to this point.


> they see fit. The WG exists mainly as an advisory body like FESCo:
> it's really there mostly to set general direction and resolve
> disputes.

And to make it obvious who to come to if there is a problem.

> Frankly, if someone comes and does a whole bunch of work for the
> Server SIG, there's a high probability that they will eventually be
> offered a seat on the WG as well. It's *intended* that the chairs be
> held by people doing active work, so people semi-regularly decide to
> give up their seat to others.

More +1.

> That being said, I'd kind of like to get to a point where Project FAO is
> basically just a tool container running atop a Fedora Server os-tree image.

That *definitely* argues for the merge — at least eventually.


-- 
Matthew Miller

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


Re: Cloud and Server Q

2016-09-29 Thread Stephen Gallagher
On 09/27/2016 07:11 PM, Chris Murphy wrote:
> Hi,
> 
> I was asked to start this in today's Server meeting. The genesis for
> me was, I have more questions than answers and I'm fairly convinced
> I'm not the only person who's kinda shrugging not knowing what all the
> questions even are. Answers are important too, but good questions to
> properly explore scope and liabilities have to come first.
> 

Agreed, thanks.

> Cloud WG folks had decided a while ago to focus on Atomic Host, and
> sounds like now they only want to do that, and form a new Atomic WG.
> [1][2]
> 
> I see 8 base images for Cloud that aren't rpm-ostree based. Are they
> in need of a new home?

As best I can tell, "yes".

 Who's using them?

No idea

 Are they all needed? Does it
> make sense for Server WG to produce the non-Atomic Cloud deliverable
> images?
> 

So, my thoughts here is that we essentially retire *all* of them and then let
the Server WG decide to resurrect one or more of them that fits with their
mission. I think it's better to start from zero and add back in the ones that we
want rather than to analyze what we have and try to decide which ones to 
abandon.


> At the last Cloud meeting, it was floated whether some Cloud people
> should move over to Server, or vice versa. Should there be an
> Atomic/Container WG? i.e. a fourth product deliverable?
> 

I don't think we need another WG for this. The space is already a bit crowded.
Also membership on a WG isn't required for taking action; anyone who has
experience generating these images that wants to keep doing so is highly
encouraged to join the ser...@lists.fedoraproject.org mailing list, come to the
Server SIG meetings and participate in whatever way they see fit. The WG exists
mainly as an advisory body like FESCo: it's really there mostly to set general
direction and resolve disputes.

Frankly, if someone comes and does a whole bunch of work for the Server SIG,
there's a high probability that they will eventually be offered a seat on the WG
as well. It's *intended* that the chairs be held by people doing active work, so
people semi-regularly decide to give up their seat to others.


> Being contrary, I wondered about consolidation as a solution rather
> than adding another WG and product. [3] Does anyone see Cloud WG, or
> Server WG as spread too thinly? What estimate do you have for overlap
> in work between Cloud and Server? Is there an economy of scale by
> combining them? And is it both useful and practical to have subgroups
> within a WG, to split out the sub variants of Server: hardware, cloud,
> atomic host?
> 

I don't know that we need the overhead of additional official *groups*. I think
we can probably keep it all to just the Server SIG for now and work as a team.


> Server and Workstation WGs have expressed interest in moving to
> rpm-ostree based deployments also. So I'm confused by what an Atomic
> WG would produce that's unique.

Last I heard, they weren't trying to be an "Atomic WG", but rather build a
complete container management solution atop OpenShift:
https://fedoraproject.org/wiki/Objectives/ProjectFAO

That being said, I'd kind of like to get to a point where Project FAO is
basically just a tool container running atop a Fedora Server os-tree image.


There are huge differences between
> conventional and rpm-ostree deployments. Does it make sense for an
> Atomic WG to have no outputs? And instead is liason with Server and
> Workstation WGs, QA, Docs, releng, and others, to help in the
> transition to this new way of delivering and maintaining Fedora?
> 

See above, but I think that's where I'd like us to be in a couple years, but I
think convergence will take some time.


> It might be that the Cloud and Server PRD refreshes help sort some of
> this stuff out too.
> 

Yes, I was hoping that some of this would fall out from the Server PRD process
as a natural by-product.


> OK I have more questions but this is long enough. I'm certain others
> can ask better questions, or versions of these ones, and in particular
> the questions I haven't asked.
> 

Thank you very much for getting this conversation started, Chris. I think it's
very important to try to get everyone talking and eventually on the same page.


> 
> [1]
> https://meetbot.fedoraproject.org/fedora-meeting-1/2016-09-21/fedora_cloud_wg.2016-09-21-17.00.log.html
> 
> 
> [2]
> https://fedorahosted.org/cloud/ticket/170
> 
> [3]
> (Combining) Cloud Atomic Server WGs
> https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/Z2P2ARN6AMMAW52F6KSOFGELQFKXHCFY/
> 




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Cloud and Server Q

2016-09-28 Thread Matthew Miller
On Tue, Sep 27, 2016 at 05:11:52PM -0600, Chris Murphy wrote:
> I was asked to start this in today's Server meeting. The genesis for
> me was, I have more questions than answers and I'm fairly convinced
> I'm not the only person who's kinda shrugging not knowing what all the
> questions even are. Answers are important too, but good questions to
> properly explore scope and liabilities have to come first.

Cool -- thanks for doing this.

> Cloud WG folks had decided a while ago to focus on Atomic Host, and
> sounds like now they only want to do that, and form a new Atomic WG.
> [1][2]

*nod* -- that's the plan, at least for the WG and Edition. There's
still interest in working on cloud technologies in general in the SIG,
though.

> I see 8 base images for Cloud that aren't rpm-ostree based. Are they
> in need of a new home? Who's using them? Are they all needed? Does it
> make sense for Server WG to produce the non-Atomic Cloud deliverable
> images?

Yes, at least some of them are in need of a new home. I don't know if
they are all needed. I know a non-zero but small number of people are
using them for their basic intended purpose (for building scale-out
infrastructure in EC2 or OpenStack) but I know a lot of other people
are using them as a convenient way to get a small-ish Fedora VM image
to run locally.


> Being contrary, I wondered about consolidation as a solution rather
> than adding another WG and product. [3] Does anyone see Cloud WG, or
> Server WG as spread too thinly? What estimate do you have for overlap
> in work between Cloud and Server? Is there an economy of scale by
> combining them? And is it both useful and practical to have subgroups
> within a WG, to split out the sub variants of Server: hardware, cloud,
> atomic host?

The more I think about this, the more I like your merger suggestion.

> Server and Workstation WGs have expressed interest in moving to
> rpm-ostree based deployments also. So I'm confused by what an Atomic
> WG would produce that's unique. There are huge differences between

See this in-progress document:
https://fedoraproject.org/wiki/Objectives/ProjectFAO
The goal of the Fedora Atomic/Openshift edition would be a multi-node
cluster based arond Atomic and OpenShift Origin. 


> It might be that the Cloud and Server PRD refreshes help sort some of
> this stuff out too.

Yes. :)

-- 
Matthew Miller

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


Cloud and Server Q

2016-09-27 Thread Chris Murphy
Hi,

I was asked to start this in today's Server meeting. The genesis for
me was, I have more questions than answers and I'm fairly convinced
I'm not the only person who's kinda shrugging not knowing what all the
questions even are. Answers are important too, but good questions to
properly explore scope and liabilities have to come first.

Cloud WG folks had decided a while ago to focus on Atomic Host, and
sounds like now they only want to do that, and form a new Atomic WG.
[1][2]

I see 8 base images for Cloud that aren't rpm-ostree based. Are they
in need of a new home? Who's using them? Are they all needed? Does it
make sense for Server WG to produce the non-Atomic Cloud deliverable
images?

At the last Cloud meeting, it was floated whether some Cloud people
should move over to Server, or vice versa. Should there be an
Atomic/Container WG? i.e. a fourth product deliverable?

Being contrary, I wondered about consolidation as a solution rather
than adding another WG and product. [3] Does anyone see Cloud WG, or
Server WG as spread too thinly? What estimate do you have for overlap
in work between Cloud and Server? Is there an economy of scale by
combining them? And is it both useful and practical to have subgroups
within a WG, to split out the sub variants of Server: hardware, cloud,
atomic host?

Server and Workstation WGs have expressed interest in moving to
rpm-ostree based deployments also. So I'm confused by what an Atomic
WG would produce that's unique. There are huge differences between
conventional and rpm-ostree deployments. Does it make sense for an
Atomic WG to have no outputs? And instead is liason with Server and
Workstation WGs, QA, Docs, releng, and others, to help in the
transition to this new way of delivering and maintaining Fedora?

It might be that the Cloud and Server PRD refreshes help sort some of
this stuff out too.

OK I have more questions but this is long enough. I'm certain others
can ask better questions, or versions of these ones, and in particular
the questions I haven't asked.


[1]
https://meetbot.fedoraproject.org/fedora-meeting-1/2016-09-21/fedora_cloud_wg.2016-09-21-17.00.log.html


[2]
https://fedorahosted.org/cloud/ticket/170

[3]
(Combining) Cloud Atomic Server WGs
https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/Z2P2ARN6AMMAW52F6KSOFGELQFKXHCFY/

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