Re: [atomic-devel] How to apply non-atomic tuned profiles to atomic host

2016-10-11 Thread Jeremy Eder 
On Tue, Oct 11, 2016 at 2:14 PM, Colin Walters  wrote:

> On Tue, Oct 11, 2016, at 01:36 PM, Jeremy Eder wrote:
>
> Going fwd, I think we would rather not maintain two locations (atomic-*
> and atomic-openshift-* tuned profiles with identical content.
>
>
> Yes, agreed.
>
>
> So, trying to reason a way to get those profiles onto an AH since we can't
> install the tuned-atomic-openshift RPM
>
>
> That's not true.  We've been shipping package layering for quite a while.
>

​OK, I hadn't seen it.​  Just read the blog that Jason sent.  Looks good.

> ...We could copy them to /etc/tuned and enable them manually...but I'm not
> sure that jives with how we're supposed to use AH and it seems kind of
> hacky since there would be "orphan files" in /etc.  Thoughts?
>
>
> I wouldn't say they're orphaned if something "owns" it.  Ownership doesn't
> have to just be RPM, it can also be Ansible.
>
> Although a common trap with management systems like Ansible and Puppet is
> (by default) they're subject
> to https://en.wikipedia.org/wiki/Hysteresis - if one version of the
> installer creates a tuned snippet, then
> we later don't want it to apply, the Ansible rules have to carry code to
> explicitly ensure it's deleted.  Whereas
> with RPM (and ostree) the system does synchronize to the new state,
> automatically deleting files
> no longer shipped.
>
> Anyways, I'm a bit confused here - why isn't the fix to:
>
> 1) Put the profile in the tuned RPM
> 2) Atomic Host installs it by default
> 3) Installers like openshift-ansible ensure it's installed (noop on AH)
>

​Because layered products (not just OpenShift) do not want to be coupled to
the RHEL release schedule to update their profiles.  They want to own their
profiles and rely on the tuned daemon to be there.
​

Before we go the layered RPM route I just want to make sure you're onboard
with it, as I was not aware of any existing in-product users of that
feature.  Are there any? If we're the first that's not an issue, just want
to make sure we get it right.

Now, what would the implementation look like ... basically
openshift-ansible would do what the blog does?
http://www.projectatomic.io/blog/2016/08/new-centos-atomic-host-with-package-layering-support/

Also using the layered RPMs seems to currently have a reboot requirement.
Is that correct?  At least until we have
https://bugzilla.gnome.org/show_bug.cgi?id=767977
​ ?​

Re: [atomic-devel] rpm-ostree error: Bus owner changed, aborting.

2016-10-11 Thread Colin Walters 


On Tue, Oct 11, 2016, at 10:10 AM, Colin Walters wrote:

> https://bugzilla.redhat.com/show_bug.cgi?id=1383708

https://bodhi.fedoraproject.org/updates/gnutls-3.5.5-2.fc25

Re: [atomic-devel] How to apply non-atomic tuned profiles to atomic host

2016-10-11 Thread Colin Walters 
On Tue, Oct 11, 2016, at 01:36 PM, Jeremy Eder wrote:

> Going fwd, I think we would rather not maintain two locations (atomic-
> * and atomic-openshift-* tuned profiles with identical content.

Yes, agreed.

>
> So, trying to reason a way to get those profiles onto an AH since we
> can't install the tuned-atomic-openshift RPM

That's not true.  We've been shipping package layering for quite a
while.

> ...We could copy them to /etc/tuned and enable them manually...but I'm
> not sure that jives with how we're supposed to use AH and it seems
> kind of hacky since there would be "orphan files" in /etc.  Thoughts?

I wouldn't say they're orphaned if something "owns" it.  Ownership
doesn't have to just be RPM, it can also be Ansible.

Although a common trap with management systems like Ansible and Puppet
is (by default) they're subject
to https://en.wikipedia.org/wiki/Hysteresis - if one version of the
installer creates a tuned snippet, then
we later don't want it to apply, the Ansible rules have to carry code to
explicitly ensure it's deleted.  Whereas
with RPM (and ostree) the system does synchronize to the new state,
automatically deleting files
no longer shipped.

Anyways, I'm a bit confused here - why isn't the fix to:

1) Put the profile in the tuned RPM
2) Atomic Host installs it by default
3) Installers like openshift-ansible ensure it's installed (noop on AH)

Re: [atomic-devel] How to apply non-atomic tuned profiles to atomic host

2016-10-11 Thread Jason DeTiberus 
On Tue, Oct 11, 2016 at 1:53 PM, Scott Dodson  wrote:

> On Tue, Oct 11, 2016 at 1:44 PM, Jason DeTiberus 
> wrote:
> >
> >
> > On Tue, Oct 11, 2016 at 1:36 PM, Jeremy Eder  wrote:
> >>
> >> Hi,
> >>
> >> Right now we've got the tuned package in the base atomic content.  There
> >> are atomic-host and atomic-guest tuned profiles which are currently
> >> identical to the atomic-openshift ones.  We'd like to make a change to
> the
> >> atomic-openshift-node/master profiles (which are distributed with the
> >> openshift product).
> >>
> >> Going fwd, I think we would rather not maintain two locations (atomic-*
> >> and atomic-openshift-* tuned profiles with identical content.
> >>
> >> So, trying to reason a way to get those profiles onto an AH since we
> can't
> >> install the tuned-atomic-openshift RPM...We could copy them to
> /etc/tuned
> >> and enable them manually...but I'm not sure that jives with how we're
> >> supposed to use AH and it seems kind of hacky since there would be
> "orphan
> >> files" in /etc.  Thoughts?
> >
> >
> > With a sufficiently recent version of atomic host, you could use layered
> > packages:
> > http://www.projectatomic.io/blog/2016/08/new-centos-
> atomic-host-with-package-layering-support/
>
> Is that a solution we want to support OCP customers on?
>

I don't see why not. As we go down the path of reducing the size of atomic
host, we'll need to install dependencies that may not make sense to deploy
containerized (storage dependencies for example), so package layering seems
like the proper place to manage those dependencies. I would view the tuned
profiles in the same way.


-- 
Jason DeTiberus

Re: [atomic-devel] How to apply non-atomic tuned profiles to atomic host

2016-10-11 Thread Jason DeTiberus 
On Tue, Oct 11, 2016 at 1:36 PM, Jeremy Eder  wrote:

> Hi,
>
> Right now we've got the tuned package in the base atomic content.  There
> are atomic-host and atomic-guest tuned profiles which are currently
> identical to the atomic-openshift ones.  We'd like to make a change to the
> atomic-openshift-node/master profiles (which are distributed with the
> openshift product).
>
> Going fwd, I think we would rather not maintain two locations (atomic-*
> and atomic-openshift-* tuned profiles with identical content.
>
> So, trying to reason a way to get those profiles onto an AH since we can't
> install the tuned-atomic-openshift RPM...We could copy them to /etc/tuned
> and enable them manually...but I'm not sure that jives with how we're
> supposed to use AH and it seems kind of hacky since there would be "orphan
> files" in /etc.  Thoughts?
>

With a sufficiently recent version of atomic host, you could use layered
packages:
http://www.projectatomic.io/blog/2016/08/new-centos-atomic-host-with-package-layering-support/


-- 
Jason DeTiberus

[atomic-devel] How to apply non-atomic tuned profiles to atomic host

2016-10-11 Thread Jeremy Eder 
Hi,

Right now we've got the tuned package in the base atomic content.  There
are atomic-host and atomic-guest tuned profiles which are currently
identical to the atomic-openshift ones.  We'd like to make a change to the
atomic-openshift-node/master profiles (which are distributed with the
openshift product).

Going fwd, I think we would rather not maintain two locations (atomic-* and
atomic-openshift-* tuned profiles with identical content.

So, trying to reason a way to get those profiles onto an AH since we can't
install the tuned-atomic-openshift RPM...We could copy them to /etc/tuned
and enable them manually...but I'm not sure that jives with how we're
supposed to use AH and it seems kind of hacky since there would be "orphan
files" in /etc.  Thoughts?

[atomic-devel] I have setup a IRC Channel on Freenode for OCID

2016-10-11 Thread Daniel J Walsh 
Join #ocid if you are interested in the ongoing development.

Re: [atomic-devel] rpm-ostree error: Bus owner changed, aborting.

2016-10-11 Thread Colin Walters 


On Mon, Oct 10, 2016, at 04:36 PM, Dusty Mabe wrote:

> -bash-4.3# rpm-ostree upgrade
> Updating from: fedora-atomic:fedora-atomic/25/x86_64/docker-host
> error: Bus owner changed, aborting.

https://bugzilla.redhat.com/show_bug.cgi?id=1383708