atomic workstation status

[Matthias Clasen]

(For the innocent bystanders, we've decided to use fedora-desktop list
for development communication around https://fedoraproject.org/wiki/Cha
nges/WorkstationOstree , so you'll see some more or less mundane stuff
go by here - if you're not interested, just ignore it. Better than
chasing things via private mail or yet-another-list, I believe).

Here's a first status update of sorts for the atomic workstation effort
(I'm afraid this name will stick if we don't come up with something
else soon, I'm already used to it).

David got an initial repo set up at http://209.132.179.147/repo
After some fixups, we've gotten it to boot, show gdm and log in in
boxes.

Here is what I did to get to the login screen:

1) Install fedora-atomic in a vm (following the instructions on www.pro
jectatomic.io).

2) Add a remote with
  ostree remote add workstation http://209.132.179.147/repo 

3) Turn off selinux with
  setenforce 0

3) Switch out the atomic host image with the workstation image with
  rpm-ostree rebase workstation:fedora-atomic-
workstation/rawhide/x86_64/foo-host

4) Reboot, edit /etc/pam.d/gdm-lauch-environment to replace pam_unix.so
with pam_permit.so

5) Start gdm with
  systemctl isolate graphical.target

So thats a good first milestone to reach. Or almost reach - we still
need to put the gdm pam fixes into the repo (or rather, in upstream
gdm), and make the system boot to graphical.target by default.

The next steps I see are:

- Figure out how we can work on the repository together. David, can you
make your scripts and tooling for the repository building available
somewhere ? github or pagure would be the obvious candidates, I guess.

- Figure out how to work on other bits that we need in this scenario.

Mainly, this will be Richard making gnome-software talk to rpm-
ostreed. 
We should probably explore the option to locally compose a tree with
custom bits in it. Or just work inside a vm ? Owen is looking at using
vagrant for this, I think.

- Get a friendlier installation story than transmutating a fedora
atomic image. rpm-ostree has support for generating some form of
install image, we should look into that. I think this is on Davids todo
list.

- Talk to rel-eng about steps to move this from our prototyping into
their real. I have an initial meeting next week to start this.

[Ray Strode]

Hi,

>  2) Add a remote with
>    ostree remote add workstation http://209.132.179.147/repo  
So I had to put
--no-gpg-verify on this command

>  3) Turn off selinux with
>    setenforce 0
>  
>  3) Switch out the atomic host image with the workstation image with
>    rpm-ostree rebase workstation:fedora-atomic-
>  workstation/rawhide/x86_64/foo-host 
YOU HAVE TWO STEP 3s HERE !
>  
>  4) Reboot, edit /etc/pam.d/gdm-lauch-environment to replace pam_unix.so
>  with pam_permit.so 
To be clear, you're avoiding the pam_unix module by not
including the
system-auth service file for the account management and password stacks.

(system-auth should still get included for the session stack).

I've pushed that change upstream now:

https://git.gnome.org/browse/gdm/commit/?id=74f6145

>  5) Start gdm with
>    systemctl isolate graphical.target 
I guess

systemctl set-default graphical.target

before the reboot, would be better

--Ray

[Ray Strode]

Hi,
>  So thats a good first milestone to reach. Or almost reach - we still
>  need to put the gdm pam fixes into the repo (or rather, in upstream
>  gdm), and make the system boot to graphical.target by default. 
So the PAM fixes
make sense anyway (because the GDM account doesn't
have a password and won't get locked), but this turns out to just
be an selinux issue.  We should get the policy fixed and as a near
term workaround, put SELINUX=permissive in /etc/selinux/config

[Matthew Miller]

On Fri, Apr 01, 2016 at 01:07:22PM -0400, Matthias Clasen wrote:
>  - Get a friendlier installation story than transmutating a fedora
>  atomic image. rpm-ostree has support for generating some form of
>  install image, we should look into that. I think this is on Davids todo
>  list. 
Anaconda can install an ostree-based system from an ostree repository
directly. That's how the Atomic installer from the Cloud WG works (and
the cloud image is then generated from that).

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Adam Williamson]

On Fri, 2016-04-01 at 13:07 -0400, Matthias Clasen wrote:
>  (For the innocent bystanders, we've decided to use fedora-desktop
> list
>  for development communication around https://fedoraproject.org/wiki/Cha
>  nges/WorkstationOstree , so you'll see some more or less mundane stuff
>  go by here - if you're not interested, just ignore it. Better than
>  chasing things via private mail or yet-another-list, I believe).
>  
>  Here's a first status update of sorts for the atomic workstation effort
>  (I'm afraid this name will stick if we don't come up with something
>  else soon, I'm already used to it). 
Can you please call it something like "rpm-ostree workstation"? There's
quite a significant distinction between the rpm-ostree mechanism for
constructing an OS, and the "Atomic host" concept. AIUI, *one* of the
essential properties of an "Atomic host" is that it be built by rpm-
ostree, but *another* essential propert of an "Atomic host" is that it
consist of (or at least contain) a specific set of components, which a
Workstation-on-rpm-ostree most likely would not. Quote:

"The core of Project Atomic is the Project Atomic Host. This is a
lightweight operating system that has been assembled out of upstream
RPM content. It is designed to run applications in Docker containers."

http://www.projectatomic.io/docs/introduction/

basically it seems to me that the definition of an Atomic Host is at
least "an OS built with rpm-ostree that includes systemd, Docker and
Kubernetes", but 'lightweight' can be read as implying that it
shouldn't include very much at all *beyond* that (which would mean a
Workstation would not qualify).

Unless this new Workstation effort is specifically intended to always
meet the definition of an "Atomic Host", *as well as* being a Fedora
Workstation, I don't think it should be called Atomic Workstation.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Adam Williamson]

On Fri, 2016-04-01 at 17:12 -0700, Adam Williamson wrote:
>  On Fri, 2016-04-01 at 13:07 -0400, Matthias Clasen wrote:
>  > 
>  > (For the innocent bystanders, we've decided to use fedora-desktop list
>  > for development communication around https://fedoraproject.org/wiki/Cha
>  > nges/WorkstationOstree , so you'll see some more or less mundane stuff
>  > go by here - if you're not interested, just ignore it. Better than
>  > chasing things via private mail or yet-another-list, I believe).
>  > 
>  > Here's a first status update of sorts for the atomic workstation effort
>  > (I'm afraid this name will stick if we don't come up with something
>  > else soon, I'm already used to it). 
>  Can you please call it something like "rpm-ostree
> workstation"? There's
>  quite a significant distinction between the rpm-ostree mechanism for
>  constructing an OS, and the "Atomic host" concept. AIUI, *one* of the
>  essential properties of an "Atomic host" is that it be built by rpm-
>  ostree, but *another* essential propert of an "Atomic host" is that it
>  consist of (or at least contain) a specific set of components, which a
>  Workstation-on-rpm-ostree most likely would not. Quote:
>  
>  "The core of Project Atomic is the Project Atomic Host. This is a
>  lightweight operating system that has been assembled out of upstream
>  RPM content. It is designed to run applications in Docker containers."
>  
>  http://www.projectatomic.io/docs/introduction/
>  
>  basically it seems to me that the definition of an Atomic Host is at
>  least "an OS built with rpm-ostree that includes systemd, Docker and
>  Kubernetes", but 'lightweight' can be read as implying that it
>  shouldn't include very much at all *beyond* that (which would mean a
>  Workstation would not qualify).
>  
>  Unless this new Workstation effort is specifically intended to always
>  meet the definition of an "Atomic Host", *as well as* being a Fedora
>  Workstation, I don't think it should be called Atomic Workstation. 
To argue with myself a bit, I suppose you could make the argument that
an "Atomic Workstation" could be another type of "atomic thing" - so
we
would have "Atomic Hosts" and "Atomic Workstations". But man, that
sounds like it might get confusing...at least I think whoever gets to
decide what the hell "Atomic" means exactly (i.e. Project Atomic)
should probably weigh in on it, before anything else gets "Atomic" in
its name.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Daniel J Walsh]

On 04/01/2016 08:17 PM, Adam Williamson wrote:
>  On Fri, 2016-04-01 at 17:12 -0700, Adam Williamson wrote:
> > On Fri, 2016-04-01 at 13:07 -0400, Matthias Clasen wrote:
> >> (For the innocent bystanders, we've decided to use fedora-desktop list
> >> for development communication around https://fedoraproject.org/wiki/Cha
> >> nges/WorkstationOstree , so you'll see some more or less mundane stuff
> >> go by here - if you're not interested, just ignore it. Better than
> >> chasing things via private mail or yet-another-list, I believe).
> >>
> >> Here's a first status update of sorts for the atomic workstation effort
> >> (I'm afraid this name will stick if we don't come up with something
> >> else soon, I'm already used to it).
> > Can you please call it something like "rpm-ostree workstation"?
> There's
> > quite a significant distinction between the rpm-ostree mechanism for
> > constructing an OS, and the "Atomic host" concept. AIUI, *one* of the
> > essential properties of an "Atomic host" is that it be built by rpm-
> > ostree, but *another* essential propert of an "Atomic host" is that it
> > consist of (or at least contain) a specific set of components, which a
> > Workstation-on-rpm-ostree most likely would not. Quote:
> >
> > "The core of Project Atomic is the Project Atomic Host. This is a
> > lightweight operating system that has been assembled out of upstream
> > RPM content. It is designed to run applications in Docker containers."
> >
> > http://www.projectatomic.io/docs/introduction/
> >
> > basically it seems to me that the definition of an Atomic Host is at
> > least "an OS built with rpm-ostree that includes systemd, Docker and
> > Kubernetes", but 'lightweight' can be read as implying that it
> > shouldn't include very much at all *beyond* that (which would mean a
> > Workstation would not qualify).
> >
> > Unless this new Workstation effort is specifically intended to always
> > meet the definition of an "Atomic Host", *as well as* being a Fedora
> > Workstation, I don't think it should be called Atomic Workstation.
>  To argue with myself a bit, I suppose you could make the argument that
>  an "Atomic Workstation" could be another type of "atomic thing" - so
> we
>  would have "Atomic Hosts" and "Atomic Workstations". But man, that
>  sounds like it might get confusing...at least I think whoever gets to
>  decide what the hell "Atomic" means exactly (i.e. Project Atomic)
>  should probably weigh in on it, before anything else gets "Atomic" in
>  its name. 
First we should change the definition of atomic hosts, to specify
containers, not just docker containers.  In an upcoming release
we will be supporting runc containers, and I see no reason not
to support RKT containers.

In a grand view of the future, we have talked about "PET" containers
and a PET container could be a SPC container that you could dnf install 
into,
Should this be part of the Atomic Workstation, and could this be a 
Desktop Pet?

Potentially we could keep the concept of atomic host and then just add a
really big container that runs the desktop.  Does not even need to be a 
docker
container, or need to use a COW file system, but could use an OSTREE 
file system.

This Super Container, then could even run other containers for desktop apps.

Just throwing out crazy ideas...

[Matthias Clasen]

On Mon, 2016-04-04 at 10:45 -0400, Daniel J Walsh wrote:
>  
>  
>  In a grand view of the future, we have talked about "PET" containers
>  and a PET container could be a SPC container that you could dnf
>  install 
>  into,
>  Should this be part of the Atomic Workstation, and could this be a 
>  Desktop Pet? 
We want the desktop itself to be immutable, so it should not be a pet
container. Otherwise many advantages of going image-based are lost.

[Daniel J Walsh]

On 04/04/2016 11:12 AM, Matthias Clasen wrote:
>  On Mon, 2016-04-04 at 10:45 -0400, Daniel J Walsh wrote:
> >   
> >
> > In a grand view of the future, we have talked about "PET" containers
> > and a PET container could be a SPC container that you could dnf
> > install
> > into,
> > Should this be part of the Atomic Workstation, and could this be a
> > Desktop Pet?
>  We want the desktop itself to be immutable, so it should not be a pet
>  container. Otherwise many advantages of going image-based are lost.
>  --
>  desktop mailing list
>  desktop(a)lists.fedoraproject.org
>  http://lists.fedoraproject.org/admin/lists/[e-mail] 
Well it
could be an immutable container also.  Just using this as an 
example.

The question would be can the desktop environment add additional xdg-app
containers.

[Chris Murphy]

On Mon, Apr 4, 2016, 9:13 AM Matthias Clasen <mclasen(a)redhat.com&gt; wrote:

>  On Mon, 2016-04-04 at 10:45 -0400, Daniel J Walsh wrote:
>  >
>  >
>  > In a grand view of the future, we have talked about "PET" containers
>  > and a PET container could be a SPC container that you could dnf
>  > install
>  > into,
>  > Should this be part of the Atomic Workstation, and could this be a
>  > Desktop Pet?
>
>  We want the desktop itself to be immutable, so it should not be a pet
>  container. Otherwise many advantages of going image-based are lost.
>
>  
Are there users who use more than one DE and switch between them? Are they
a considerable minority?


Chris Murphy

[Daiki Ueno]

Matthias Clasen <mclasen(a)redhat.com&gt; writes:

>  The next steps I see are:
>
>  - Figure out how we can work on the repository together. David, can you
>  make your scripts and tooling for the repository building available
>  somewhere ? github or pagure would be the obvious candidates, I guess.
>
>  - Figure out how to work on other bits that we need in this scenario.
>
>  Mainly, this will be Richard making gnome-software talk to rpm-
>  ostreed. 
>  We should probably explore the option to locally compose a tree with
>  custom bits in it. Or just work inside a vm ? Owen is looking at using
>  vagrant for this, I think. 
I just have one question: how are translations/locales handled under
this setting?  /usr/share/locale is almost empty except for C and en_US
and it seems to be deliberate[1].  Will locale specific data for other
languages be provided as a layered package or something like that?

Footnotes: 
[1]  https://git.fedorahosted.org/cgit/fedora-atomic.git/tree/treecompose-post...

Regards,
-- 
Daiki Ueno

[Chris Murphy]

On Wed, Apr 6, 2016 at 8:32 PM, Daiki Ueno <ueno(a)fedoraproject.org&gt; wrote:
>  Matthias Clasen <mclasen(a)redhat.com&gt; writes:
>
> > The next steps I see are:
> >
> > - Figure out how we can work on the repository together. David, can you
> > make your scripts and tooling for the repository building available
> > somewhere ? github or pagure would be the obvious candidates, I guess.
> >
> > - Figure out how to work on other bits that we need in this scenario.
> >
> > Mainly, this will be Richard making gnome-software talk to rpm-
> > ostreed.
> > We should probably explore the option to locally compose a tree with
> > custom bits in it. Or just work inside a vm ? Owen is looking at using
> > vagrant for this, I think.
>
>  I just have one question: how are translations/locales handled under
>  this setting?  /usr/share/locale is almost empty except for C and en_US
>  and it seems to be deliberate[1].  Will locale specific data for other
>  languages be provided as a layered package or something like that?
>
>  Footnotes:
>  [1]  https://git.fedorahosted.org/cgit/fedora-atomic.git/tree/treecompose-post...
I'd expect the installed OS tree contains all languages. Otherwise
we'd need locale specific trees. Same for each xdg-app.

-- 
Chris Murphy

[Matthias Clasen]

On Thu, 2016-04-07 at 11:32 +0900, Daiki Ueno wrote:
>  Matthias Clasen <mclasen(a)redhat.com&gt; writes:
>  
>  > 
>  > The next steps I see are:
>  > 
>  > - Figure out how we can work on the repository together. David, can
>  > you
>  > make your scripts and tooling for the repository building available
>  > somewhere ? github or pagure would be the obvious candidates, I
>  > guess.
>  > 
>  > - Figure out how to work on other bits that we need in this
>  > scenario.
>  > 
>  > Mainly, this will be Richard making gnome-software talk to rpm-
>  > ostreed. 
>  > We should probably explore the option to locally compose a tree
>  > with
>  > custom bits in it. Or just work inside a vm ? Owen is looking at
>  > using
>  > vagrant for this, I think.
>  I just have one question: how are translations/locales handled under
>  this setting?  /usr/share/locale is almost empty except for C and
>  en_US
>  and it seems to be deliberate[1].  Will locale specific data for
>  other
>  languages be provided as a layered package or something like that?
>   
Hey Daiki, see my status update from earlier this week - we've taken
the use of inst_langs out of the config, so locales should be fully
populated now.