Re: [DISCUSS] Making Atomic the cloud edition

[Joe Brockmeier]

On 08/24/2015 10:52 AM, Brian (bex) Exelbierd wrote:
> I'm well past the 72 hours, so this is probably able to be ignored, but ...
> 
> On 08/21/2015 06:15 PM, Joe Brockmeier wrote:
>> But I'd also disagree we need to spin up a new SIG around this when the
>> mapping of the Cloud SIG and Atomic interest is close to (if not
>> exactly) 1:1.
> 
> It sounds like we are talking about creating sub-working groups of
> fedora-cloud for base, atomic, and docker image.  That does start to
> smell a bit like SIGs to me ...

To me, this feels like spinning up unnecessary committees. Folks who are
interested in working on Atomic host specifically will work on that,
folks who want to work on docker images will work on that, etc. All of
that fits the same umbrella and eventual story (we don't have a complete
story without Atomic host, we don't have a complete story without a good
Fedora Docker image, and we don't have a complete story unless the host
works well in public/private cloud) so I don't know that spinning up
SIGs for each piece gets us anywhere.

Also - those are implementation details *if* the working group decides
it wants to pursue Atomic as the main "story" for Cloud.

Can we take a vote today during the Cloud meeting?

Best,

jzb
-- 
Joe Brockmeier | Community Team, OSAS
j...@redhat.com | http://community.redhat.com/
Twitter: @jzb  | http://dissociatedpress.net/



signature.asc
Description: OpenPGP digital signature
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [DISCUSS] Making Atomic the cloud edition

[Joe Brockmeier]

On 08/18/2015 08:34 PM, Josh Boyer wrote:
> 
> On Aug 18, 2015 5:54 PM, "Joe Brockmeier"  > wrote:
>> We also will continue to do the base cloud image - that won't go away -
>> but it won't be the focus of the working group or its marketing.
> 
> If it won't be the focus of the cloud work group, who do you expect to
> monitor its creation and correct operation?  I worry that it will fall
> by the wayside and bit rot into a state of disrepair.

Realized this morning that I responded face-to-face on this but not in
email. D'oh!

Most of the work that would go into making the base image is happening
already. We need to test it, but there doesn't seem to be a lot of churn
or major lifting required to keep creating the image. We don't seem to
have a lot of ideas for making the image more interesting - so there
won't be a lot of work from release to release there. (If we were
proposing a radical overhaul of some sort and saying "it's not the main
focus" then I would agree it's going to be problematic.)

Does anybody else feel we are unable to maintain the image as a sort of
basic offering for folks not ready to jump on Atomic?

Best,

jzb


-- 
Joe Brockmeier | Community Team, OSAS
j...@redhat.com | http://community.redhat.com/
Twitter: @jzb  | http://dissociatedpress.net/



signature.asc
Description: OpenPGP digital signature
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[cloud] #117: [VOTE] Make Atomic the primary focus of the Cloud Working Group

[Fedora Cloud Trac Tickets]

#117: [VOTE] Make Atomic the primary focus of the Cloud Working Group
-+---
 Reporter:  jzb  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  Future
Component:  Planning |   Keywords:  vote, meeting
-+---
 We've discussed on the mailing list:

 https://lists.fedoraproject.org/pipermail/cloud/2015-August/005660.html

 And in this week's cloud working group meeting in IRC:

 https://meetbot.fedoraproject.org/fedora-
 meeting-1/2015-08-26/cloud_wg.2015-08-26-17.00.html/

 I'm asking for a formal vote so we can move forward on some deliverables.

 Specifically:

 1. The new primary focus of the WG will be the atomic cloud image.
 2. The cloud base image will remain.
 3. The group will also be looking to improve and reduce the size of the
 Fedora Docker image.

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[VOTE] Make Atomic the primary focus of the Cloud Working Group

[Joe Brockmeier]

See ticket: https://fedorahosted.org/cloud/ticket/117

Thanks!

jzb
-- 
Joe Brockmeier | Community Team, OSAS
j...@redhat.com | http://community.redhat.com/
Twitter: @jzb  | http://dissociatedpress.net/



signature.asc
Description: OpenPGP digital signature
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #117: [VOTE] Make Atomic the primary focus of the Cloud Working Group

[Colin Walters]

On Wed, Aug 26, 2015, at 03:00 PM, Fedora Cloud Trac Tickets wrote:

>  1. The new primary focus of the WG will be the atomic cloud image.

Can we try to consistently say "Atomic Host" when we mean that?
There's a number of things under the projectatomic/ umbrella now,
and while I know it's convenient often to shorthand, at least in
semi-official text like this I think it's worth spelling out.

Also, "the image" is a bit misleading because in contrast to the
traditional cloud image, Atomic Host also supports bare metal and
soon PXE-to-Live which is a stateless approach to bare metal.

Something like s/atomic cloud image/Atomic Host model/ ?

>  2. The cloud base image will remain.

Random aside...I think it'd also be useful to improve ImageFactory
so it's more convenient to use, and have it be an official part of the
Cloud WG and promoted.  A lot of advanced consumers have been baking their
own images for quite a while for many reasons, and IMO we should
better support that.

I.e. make this better:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks#n12

>  3. The group will also be looking to improve and reduce the size of the
>  Fedora Docker image.

Also worth noting the Atomic Host model really wants the Docker image
to work, so having it be in a separate group is slightly strange.  Not
a big deal though.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Atomic Host and the kernel

[Josh Boyer]

Hi All,

I'm emailing my questions on the topic here as it seems to be the best
Fedora focused place to discuss Atomic Host and kernel interaction.
If that isn't the case, please point me to where you believe that is.

I have two basic questions around the interaction of Atomic Host and
the kernel.  The first is fairly straightforward: is there anything
Atomic Host or the atomic toolset needs that the kernel does not
provide today?  Missing features, bugs that have been hit but not
fixed, etc.  I believe the answer is likely no, given that atomic is
off and running fine and leverages hardlinks but I thought I would
ask.

The second question is a bit more involved.  Atomic provides the nice
ability for rollback across the entire OS tree.  However, that
requires an atomic image to be spun for every instance of that tree.
That, naturally, means that whenever a new Atomic Host instance is
spun it will use whatever kernel happens to be the latest in the
Fedora release it is built from.  This means that one cannot leverage
the nice side effect of being able to update the kernel independently
of userspace.  (Which is also nice from a testing perspective when it
comes to kernels and regressions.)

To my understanding, the only way to provide such testing would be to
create Atomic Host images that only deviate from the official images
in that they provide a new kernel.  Then one could use the standard
atomic tools to do testing and rollback of _only_ the kernel if a
problem is detected.  While this is certainly possible, I'm not sure
it is something the Cloud sig (or whomever) is really interested in
doing.  On the kernel side, we could provide such images built on our
own but I'm not sure the effort or duplication of
tooling/infrastructure is worthwhile overall.  Particularly when
non-atomic Rawhide continues to be flexible enough for these purposes.

With a two week image release timeframe though, being able to use
different kernels might be a good idea.  Does anyone have any thoughts
around this topic and how to possibly accomplish such testing?  The
only other idea I had was to spin the Atomic Host images containing
the last 3 kernels in them, but I am not sure if choosing between them
at boot is currently possible with multiple kernels installed.

Thanks in advance.

josh
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Atomic Host and the kernel

[Jason Brooks]

- Original Message -
> From: "Josh Boyer" 
> To: "Fedora Cloud SIG" 
> Cc: "Colin Walters" 
> Sent: Wednesday, August 26, 2015 2:09:23 PM
> Subject: Atomic Host and the kernel
> 
> Hi All,
> 
> I'm emailing my questions on the topic here as it seems to be the best
> Fedora focused place to discuss Atomic Host and kernel interaction.
> If that isn't the case, please point me to where you believe that is.

atomic-de...@projectatomic.io is another good place

> 
> I have two basic questions around the interaction of Atomic Host and
> the kernel.  The first is fairly straightforward: is there anything
> Atomic Host or the atomic toolset needs that the kernel does not
> provide today?  Missing features, bugs that have been hit but not
> fixed, etc.  I believe the answer is likely no, given that atomic is
> off and running fine and leverages hardlinks but I thought I would
> ask.

I don't think so -- I haven't heard of any such needs...

> 
> The second question is a bit more involved.  Atomic provides the nice
> ability for rollback across the entire OS tree.  However, that
> requires an atomic image to be spun for every instance of that tree.
> That, naturally, means that whenever a new Atomic Host instance is
> spun it will use whatever kernel happens to be the latest in the
> Fedora release it is built from.  This means that one cannot leverage
> the nice side effect of being able to update the kernel independently
> of userspace.  (Which is also nice from a testing perspective when it
> comes to kernels and regressions.)
> 
> To my understanding, the only way to provide such testing would be to
> create Atomic Host images that only deviate from the official images
> in that they provide a new kernel.  Then one could use the standard
> atomic tools to do testing and rollback of _only_ the kernel if a
> problem is detected.  While this is certainly possible, I'm not sure
> it is something the Cloud sig (or whomever) is really interested in
> doing.  On the kernel side, we could provide such images built on our
> own but I'm not sure the effort or duplication of
> tooling/infrastructure is worthwhile overall.  Particularly when
> non-atomic Rawhide continues to be flexible enough for these purposes.

My first thought is that the kernel in an atomic host should just 
work, dammit! :)

There could be different trees reflecting different levels of
kernel maturity. If it's to be one tree, multiple kernels
shipping together, as you mention below, might be the best option --
there's still a grub menu, for choosing, but I'm not positive if
there'd be a conflict w/ any ostree rollback fu.

Jason

> 
> With a two week image release timeframe though, being able to use
> different kernels might be a good idea.  Does anyone have any thoughts
> around this topic and how to possibly accomplish such testing?  The
> only other idea I had was to spin the Atomic Host images containing
> the last 3 kernels in them, but I am not sure if choosing between them
> at boot is currently possible with multiple kernels installed.
> 
> Thanks in advance.
> 
> josh
> ___
> cloud mailing list
> cloud@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> 
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #105: Missing Cockpit RPMs in Fedora Atomic 22

[Fedora Cloud Trac Tickets]

#105: Missing Cockpit RPMs in Fedora Atomic 22
---+--
 Reporter:  jzb|   Owner:  jasonbrooks
 Type:  defect |  Status:  assigned
 Priority:  blocker|   Milestone:  Fedora 22
Component:  Docker Host Image  |  Resolution:
 Keywords:  meeting|
---+--

Comment (by jasonbrooks):

 Blogged here: http://www.projectatomic.io/blog/2015/08/running-a
 -containerized-cockpit-ui-from-cloud-init/

 will check out where to add on the cloud wiki

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct