Re: [atomic-devel] Python 2 and Atomic Host

[Josh Berkus]

On 08/02/2017 10:40 AM, Micah Abbott wrote:
> On 08/02/2017 10:20 AM, Colin Walters wrote:
>> Hey, just a quick note here that I've been waging a fight to keep
>> /usr/bin/python as Python 2 for Fedora Atomic Host, and in
>> general to support Ansible.
>>
>> This was covered on LWN:
>> https://lwn.net/Articles/729366/
>>
>> For openshift-ansible I think we're generally OK with supporting
>> Python 3 and working through that.  But if you're a user of
>> Atomic Host + Ansible with Python 2, it'd be useful to respond
>> here to let me know this fight is worth continuing =)
> 
> Yup, that's me.  The tests we maintain in the 'atomic-host-tests'
> repo[0] are all Ansible.

Counter-argument: Ansible container and/or system container.  That's how
we're supposed to handle these library issues, no?


-- 
--
Josh Berkus
Project Atomic
Red Hat OSAS

[atomic-devel] Why Atomic Host should be built using Modularity

[Colin Walters]

There was a discussion today in the Atomic WG about using Modules.
Meeting log: 
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-August/msg4.html
Agenda discussion: 
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-August/msg2.html
(Side note; this doc was originally stored at 
)

This post is the "why" that I'd written earlier.  Some of the rationale
here crosscuts with other active discussions; for example, keeping
Python 2 in Atomic Host, as well as Bodhi and update cadences.

There’s an effort in Fedora called
[“Modularity”](https://docs.pagure.org/modularity/) that effectively gives
multiple lifecycles for different components.

Today (and since the start), Fedora Atomic Host *is* Fedora - we have just added
another build process at the end of the "Everything" build process (and the same
is true of the `registry.fedoraproject.org/fedora` container). There's a lot of
benefits to that; any security fixes to e.g. `glibc` or `openssl` automatically
propagate.

Content streams
---

But on the other hand, Fedora Atomic Host is locked into the current Fedora
cycles; the freezes, then the "open the floodgates" model of Bodhi.

The "at most once a day updates" that Bodhi implements is quite suboptimal
for the server case.  We go to quite a bit of effort to implement a "two
week" cadence for the ostree updates, distinct from whatever happens in Bodhi
day to day.

Further, we really have no idea what might land in Bodhi day to day.  There
are a lot of updates that are basically non-critical, and should ideally
be batched together.  Things like `rsync`.

Another issue is that we currently don't have any ability to do *overrides* 
when we need
to. If a package gets karma or the maintainer decides to ship it anyways, that's
basically it. Yes, ideally we don't have overrides, but the reality is we need
the ability, we just want to avoid using it in any long term capacity.


Moving towards a single stream
--

One of the major benefits of the rpm-ostree technology is that there's
no special distinction between minor and major upgrades, as we've ended
up with between `yum upgrade` and `dnf system-upgrade`.  The underlying
ostree side is "image like" - we could easily do changes on the scale of
[UsrMove](https://fedoraproject.org/wiki/Features/UsrMove) without requiring
any special work or downtime, in the same way we can do small incremental 
updates
atomically.  For example, imagine that we decided to switch to
the [Debian Multiarch](https://wiki.debian.org/Multiarch) layout.  That'd
just be another atomic upgrade (with rollback, etc.)

See [this issue](https://pagure.io/atomic-wg/issue/228) for more background
discussion on this topic.

We'd like "Fedora Atomic Host" to simply be a single stream for most users.
This implies more than just having a unified update mechanism; we also
need to ensure that any Changes that land in "Fedora" are minimally
disruptive for the server case.

Good examples here are:

 - 
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/ZNQW72UP36UAFMX53HPFFQTWTQDZVJ3M/
   We'd probably take this change, but delay it quite a while.  It makes
   sense for desktops, and as an opt-in for server admins who want it.
 - Dropping /usr/bin/python: 
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/JO4WGEQVGRJMLNDLMZURHIQEGPXUZCOH/
   This badly affects Ansible (which is quite important for Atomic Host)

Now, a lot of how this works comes down to how quickly Modularity
takes over Fedora and the changes in general.  We're not going to get
out of being able to make changes like the above; but I think
we want more control over when they land - for example, allow
Workstation to actually do something earlier.

Basically, we want to create a minimal server OS focused
on container hosting which you can install to e.g. a
bare metal machine, and upgrade seamlessly in place
without any special work for years.

How many years?  This proposal doesn't address that,
but it certainly seems to me like we could easily handle
2-3 years without major breaking changes.

Obviously again, a lot of this relies on containerization to be
truly successful.  (And containerization in turn really requires
Modularity too!)

One important aspect of this the "system containers" effort to
move even things like Kubernetes into containers that are decoupled from
the host lifecycle.  We'd likely have Kubernetes containers as modules,
with likely at least 2 major versions available.

Development benefits for AH
---

We want to minimize the number of versions of our critical path
components that we maintain; think `docker`, `ostree` etc.  Now,
perhaps in a Modularity world we would end up offering multiple
`docker` RPMs (and containers), but I don't see a reason to maintain
multiple 

[atomic-devel] Atomic WG Meeting Minutes 2017-08-02

[Sinny Kumari]

full log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2017-08-02/fedora_atomic_wg.2017-08-02-17.00.log.html

===
#fedora-meeting-1: fedora_atomic_wg
===


Meeting started by ksinny at 17:00:09 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2017-08-02/fedora_atomic_wg.2017-08-02-17.00.log.html
.



Meeting summary
---
* Roll Call  (ksinny, 17:00:26)
  * kube-sig ticket about versions discussion
https://pagure.io/atomic/kubernetes-sig/issue/6  (jbrooks, 17:05:22)
  * jberkus wrote a blog post on the irc/list changes for pa.io and is
working on getting a blog out on the fedora comm blog
http://www.projectatomic.io/blog/2017/07/changes-to-fah-mailing-lists/
(dustymabe, 17:06:07)
  * dusty wrote a comprehensive blog post on upgrading f25->f26 atomic
host - it got merged but has not yet posted to the pa.io/blog:
https://github.com/projectatomic/atomic-site/pull/458  (dustymabe,
17:07:00)
  * dusty communicated about the ref issue in atomic host

https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-July/msg00043.html
(dustymabe, 17:07:50)
  * ACTION: dustymabe to create ticket to track RFE for rawhide based
containers to be made available from registry.fedoraproject.org
(dustymabe, 17:08:22)
  * ACTION: jberkus strigazi to continue moving kube issues to new
kube-sig tracker  (ksinny, 17:09:51)
  * dustymabe jberkus came up with etherpad for us to use during the
VFAD http://etherpad.osuosl.org/fedora_atomic_docs_vfad  (dustymabe,
17:10:23)

* experiment with modularity  (dustymabe, 17:12:27)
  * LINK:

https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-August/msg2.html
(dustymabe, 17:12:47)
  * LINK:
https://gist.github.com/cgwalters/c69bf2091eab7c1af316d0d7dd41f530
(walters, 17:14:50)
  * ACTION: jbrooks dustymabe to come up with list of questions for
modularity folks and invite them to our atomic weekly meeting in 1
or 2 weeks  (dustymabe, 17:31:23)
  * ACTION: dustymabe to create a ticket for experimenting with
modularity - where we can track progress on an atomic host module
POC  (dustymabe, 17:34:09)
  * ACTION: dustymabe to create a ticket for questions for them for us
to curate with a meeting tag  (dustymabe, 17:34:21)

* Open Floor  (ksinny, 17:36:53)

* status of building Atomic cloudimages on multi-arches  (ksinny,
  17:38:08)
  * LINK: https://pagure.io/atomic-wg/issue/299   (ksinny, 17:38:13)
  * LINK:

https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-August/msg2.html
(dustymabe, 17:55:46)
  * LINK: https://pagure.io/atomic-wg/issue/306   (dustymabe, 17:55:52)
  * LINK: http://lkml.iu.edu/hypermail/linux/kernel/1608.0/04662.html
the pull request in question  (Drakonis_, 17:57:29)
  * btrfs discussions for atomic host in
https://pagure.io/atomic-wg/issue/306  (dustymabe, 17:59:02)

Meeting ended at 18:00:08 UTC.




Action Items

* dustymabe to create ticket to track RFE for rawhide based containers
  to be made available from registry.fedoraproject.org
* jberkus strigazi to continue moving kube issues to new kube-sig
  tracker
* jbrooks dustymabe to come up with list of questions for modularity
  folks and invite them to our atomic weekly meeting in 1 or 2 weeks
* dustymabe to create a ticket for experimenting with modularity - where
  we can track progress on an atomic host module POC
* dustymabe to create a ticket for questions for them for us to curate
  with a meeting tag




Action Items, by person
---
* dustymabe
  * dustymabe to create ticket to track RFE for rawhide based containers
to be made available from registry.fedoraproject.org
  * jbrooks dustymabe to come up with list of questions for modularity
folks and invite them to our atomic weekly meeting in 1 or 2 weeks
  * dustymabe to create a ticket for experimenting with modularity -
where we can track progress on an atomic host module POC
  * dustymabe to create a ticket for questions for them for us to curate
with a meeting tag
* jbrooks
  * jbrooks dustymabe to come up with list of questions for modularity
folks and invite them to our atomic weekly meeting in 1 or 2 weeks
* **UNASSIGNED**
  * jberkus strigazi to continue moving kube issues to new kube-sig
tracker




People Present (lines said)
---
* dustymabe (127)
* ksinny (47)
* jbrooks (46)
* zodbot (19)
* maxamillion (16)
* walters (15)
* roshi (14)
* Drakonis_ (10)
* _ari_ (2)
* scollier (2)
* sayan (2)
* miabbott (1)
* pbrobinson (1)

Re: [atomic-devel] Python 2 and Atomic Host

[Micah Abbott]

On 08/02/2017 10:20 AM, Colin Walters wrote:

Hey, just a quick note here that I've been waging a fight to keep
/usr/bin/python as Python 2 for Fedora Atomic Host, and in
general to support Ansible.

This was covered on LWN:
https://lwn.net/Articles/729366/

For openshift-ansible I think we're generally OK with supporting
Python 3 and working through that.  But if you're a user of
Atomic Host + Ansible with Python 2, it'd be useful to respond
here to let me know this fight is worth continuing =)


Yup, that's me.  The tests we maintain in the 'atomic-host-tests' 
repo[0] are all Ansible.


I'd like to experiment with the tests in their current state against an 
Atomic Host that has Python 3 available before raising any red flags. 
But this is definitely something we need to watch.


[0] https://github.com/projectatomic/atomic-host-tests


There's a bigger picture question around how long we keep
Python 2.  I'll post something related to that soon.

[atomic-devel] Python 2 and Atomic Host

[Colin Walters]

Hey, just a quick note here that I've been waging a fight to keep
/usr/bin/python as Python 2 for Fedora Atomic Host, and in
general to support Ansible.

This was covered on LWN:
https://lwn.net/Articles/729366/

For openshift-ansible I think we're generally OK with supporting
Python 3 and working through that.  But if you're a user of
Atomic Host + Ansible with Python 2, it'd be useful to respond
here to let me know this fight is worth continuing =)

There's a bigger picture question around how long we keep
Python 2.  I'll post something related to that soon.