From dwalsh@redhat.com Wed Oct 5 08:39:36 2016 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u95Cda2V016828 for ; Wed, 5 Oct 2016 08:39:36 -0400 Received: from mx1.redhat.com (ext-mx02.extmail.prod.ext.phx2.redhat.com [10.5.110.26]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u95CdZJE027269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 5 Oct 2016 08:39:35 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DFE6C466FA for ; Wed, 5 Oct 2016 12:39:35 +0000 (UTC) Received: from dhcp-10-19-62-196.boston.devel.redhat.com (vpn-236-191.phx2.redhat.com [10.3.236.191]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u95CdZmi018619 for ; Wed, 5 Oct 2016 08:39:35 -0400 From: Daniel J Walsh To: "atomic-devel@projectatomic.io" Message-ID: Date: Wed, 5 Oct 2016 08:39:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------142FCBF4C683E5C0984CBDAB" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 05 Oct 2016 12:39:35 +0000 (UTC) X-loop: atomic-devel@redhat.com Subject: [atomic-devel] Overlay/SELinux patches merged - Linus 4.9 tree. X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 12:39:36 -0000 This is a multi-part message in MIME format. --------------142FCBF4C683E5C0984CBDAB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Great work by Vivek G*oyal* . Now need to RHEL7 backport. Available in Fedora 25 and Rawhide now. --------------142FCBF4C683E5C0984CBDAB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Great work by Vivek Goyal. Now need to RHEL7 backport. Available in Fedora 25 and Rawhide now.
--------------142FCBF4C683E5C0984CBDAB-- From dusty@dustymabe.com Mon Oct 10 16:36:48 2016 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9AKam57026220 for ; Mon, 10 Oct 2016 16:36:48 -0400 Received: from mx1.redhat.com (ext-mx04.extmail.prod.ext.phx2.redhat.com [10.5.110.28]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9AKalpW029138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 10 Oct 2016 16:36:47 -0400 Received: from p3plsmtpa06-08.prod.phx3.secureserver.net (p3plsmtpa06-08.prod.phx3.secureserver.net [173.201.192.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 689377EA82 for ; Mon, 10 Oct 2016 20:36:46 +0000 (UTC) Received: from [10.13.65.109] ([66.187.233.202]) by :SMTPAUTH: with SMTP id thJ1b9KbR9MdfthJ1b9gAS; Mon, 10 Oct 2016 13:36:15 -0700 To: "atomic-devel@projectatomic.io" From: Dusty Mabe Message-ID: <8116892e-f971-2fab-cd42-74d59e56f799@dustymabe.com> Date: Mon, 10 Oct 2016 16:36:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfEFCT8V4hXhk9QvtrNeG8o3dREugP7sKzR8ZYqNTTcxBZc1kD4zPQDIUcH1nHv3ilCGJ5m/cchxWW/4u+9gLXDvh2L8WJyWbg0hdE40UezM9USDh4cH1 SLrQLIjfRUU8oKZszE3kucIrwP/1RAyPdKCvuLurX58I3FvgEZYxZP9mi5WKpBmiILxkhGkkR3JziQ== X-Greylist: Sender IP whitelisted by DNSRBL, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 10 Oct 2016 20:36:46 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 10 Oct 2016 20:36:46 +0000 (UTC) for IP:'173.201.192.109' DOMAIN:'p3plsmtpa06-08.prod.phx3.secureserver.net' HELO:'p3plsmtpa06-08.prod.phx3.secureserver.net' FROM:'dusty@dustymabe.com' RCPT:'' X-RedHat-Spam-Score: 0.37 (BAYES_50, DCC_REPUT_00_12, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL) 173.201.192.109 p3plsmtpa06-08.prod.phx3.secureserver.net 173.201.192.109 p3plsmtpa06-08.prod.phx3.secureserver.net X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.28 X-loop: atomic-devel@redhat.com Subject: [atomic-devel] rpm-ostree error: Bus owner changed, aborting. X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 20:36:48 -0000 Latest F25 Vagrant box: https://kojipkgs.fedoraproject.org//work/tasks/7256/16027256/Fedora-Atomic-Vagrant-25-20161010.n.0.x86_64.vagrant-libvirt.box ``` -bash-4.3# rpm-ostree status State: idle Deployments: ● fedora-atomic:fedora-atomic/25/x86_64/docker-host Version: 25.22 (2016-10-10 10:12:50) Commit: 584b8d3e395fbad4ed14c7f69639b6bd33bb4b5641f13379e4ea6719e1d6c6fd OSName: fedora-atomic -bash-4.3# -bash-4.3# rpm -q rpm-ostree rpm-ostree-2016.7-4.fc25.x86_64 -bash-4.3# -bash-4.3# rpm-ostree upgrade Updating from: fedora-atomic:fedora-atomic/25/x86_64/docker-host error: Bus owner changed, aborting. -bash-4.3# -bash-4.3# journalctl | tail Oct 10 20:32:48 vanilla-f25atomic kernel: pool[2850]: segfault at 510 ip 00007f66b20bbae0 sp 00007f66b305b8e8 error 4 in libgnutls.so.30.10.0[7f66b207c000+151000] Oct 10 20:32:48 vanilla-f25atomic systemd[1]: Started Process Core Dump (PID 2852/UID 0). Oct 10 20:32:48 vanilla-f25atomic audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@3-2852-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Oct 10 20:32:48 vanilla-f25atomic systemd-coredump[2853]: Core Dumping has been disabled for process 2841 (rpm-ostreed). Oct 10 20:32:48 vanilla-f25atomic systemd-coredump[2853]: Process 2841 (rpm-ostreed) of user 0 dumped core. Oct 10 20:32:48 vanilla-f25atomic audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@3-2852-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Oct 10 20:32:48 vanilla-f25atomic audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=rpm-ostreed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Oct 10 20:32:48 vanilla-f25atomic systemd[1]: rpm-ostreed.service: Main process exited, code=killed, status=11/SEGV Oct 10 20:32:48 vanilla-f25atomic systemd[1]: rpm-ostreed.service: Unit entered failed state. Oct 10 20:32:48 vanilla-f25atomic systemd[1]: rpm-ostreed.service: Failed with result 'signal'. -bash-4.3# -bash-4.3# rpm -qf /usr/lib64/libgnutls.so.30.10.0 gnutls-3.5.4-1.fc25.x86_64 -bash-4.3# rpm -q selinux-policy-targeted selinux-policy-targeted-3.13.1-218.fc25.noarch ``` From jbrooks@redhat.com Mon Oct 10 17:06:04 2016 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9AL64KB028725 for ; Mon, 10 Oct 2016 17:06:04 -0400 Received: from mx1.redhat.com (ext-mx10.extmail.prod.ext.phx2.redhat.com [10.5.110.39]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9AL64mB017696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 10 Oct 2016 17:06:04 -0400 Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EA14F9D0EC for ; Mon, 10 Oct 2016 21:06:02 +0000 (UTC) Received: by mail-qk0-f176.google.com with SMTP id n189so3462128qke.0 for ; Mon, 10 Oct 2016 14:06:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=MAoCq25ZRAbMBzuP3+MuSbLoovImpBYHmSMrXET3z9E=; b=KOkMBd2ULZNDfbBt2LkjyrR4CQ/oI9evLbpJOhPa/yxHJHsGgj3AqshuPweMSbT5H5 xIIUDV4GpfdZ2dEEAY30/Zkn+SuvpWCK1O81Yj9n1ABHqUyjEALMuoNxkrl4DgNjZ/TZ 3yy1OshU9owvtgXHfSnwBAL8Z4BmCUxe6yJAzyPYN6nLAVLeTcS4KkwRWoarrODF0zJl MRE2xlrKrmnTUU9+1Gkk16SVS6VgudGRQil2QXpwB0AqZMk7o7Y5fhAjLdE/UzkzZoE6 iYIC6upB0t96VBoH3i1qI9MWX8BstjF3QMuVn6Y9xvzrKTZZeeUibue66e75vCar4MAk PVTw== X-Gm-Message-State: AA6/9RklZw3ocXr89UfF0WP/3kW3bPjIA5JBQ9I0l/2UwngZU5C9xDRY50kGj8rOvlJZdby23T81o3JjLZMMbrEB X-Received: by 10.55.160.17 with SMTP id j17mr188008qke.167.1476133562003; Mon, 10 Oct 2016 14:06:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.109.197 with HTTP; Mon, 10 Oct 2016 14:06:01 -0700 (PDT) In-Reply-To: <8116892e-f971-2fab-cd42-74d59e56f799@dustymabe.com> References: <8116892e-f971-2fab-cd42-74d59e56f799@dustymabe.com> From: Jason Brooks Date: Mon, 10 Oct 2016 14:06:01 -0700 Message-ID: To: atomic-devel Content-Type: text/plain; charset=UTF-8 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 10 Oct 2016 21:06:03 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 10 Oct 2016 21:06:03 +0000 (UTC) for IP:'209.85.220.176' DOMAIN:'mail-qk0-f176.google.com' HELO:'mail-qk0-f176.google.com' FROM:'jbrooks@redhat.com' RCPT:'' X-RedHat-Spam-Score: 0.888 (BAYES_50, DCC_REPUT_00_12, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, RCVD_IN_SORBS_SPAM, SPF_PASS) 209.85.220.176 mail-qk0-f176.google.com 209.85.220.176 mail-qk0-f176.google.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.39 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists04.pubmisc.prod.ext.phx2.redhat.com id u9AL64KB028725 X-loop: atomic-devel@redhat.com Subject: Re: [atomic-devel] rpm-ostree error: Bus owner changed, aborting. X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 21:06:04 -0000 On Mon, Oct 10, 2016 at 1:36 PM, Dusty Mabe wrote: > > Latest F25 Vagrant box: > https://kojipkgs.fedoraproject.org//work/tasks/7256/16027256/Fedora-Atomic-Vagrant-25-20161010.n.0.x86_64.vagrant-libvirt.box > also: [vagrant@localhost ~]$ systemctl status rpm-ostreed Warning: rpm-ostreed.service changed on disk. Run 'systemctl daemon-reload' to ● rpm-ostreed.service - RPM OSTree Manager Loaded: loaded (/usr/lib/systemd/system/rpm-ostreed.service; static; vendor Active: inactive (dead) [vagrant@localhost ~]$ sudo systemctl start rpm-ostreed Warning: rpm-ostreed.service changed on disk. Run 'systemctl daemon-reload' to reload units. [vagrant@localhost ~]$ sudo systemctl daemon-reload [vagrant@localhost ~]$ sudo systemctl start rpm-ostreed Warning: rpm-ostreed.service changed on disk. Run 'systemctl daemon-reload' to reload units. [vagrant@localhost ~]$ sudo systemctl restart rpm-ostreed Warning: rpm-ostreed.service changed on disk. Run 'systemctl daemon-reload' to reload units. [vagrant@localhost ~]$ sudo systemctl status rpm-ostreed ● rpm-ostreed.service - RPM OSTree Manager Loaded: loaded (/usr/lib/systemd/system/rpm-ostreed.service; static; vendor Active: active (running) since Mon 2016-10-10 20:55:42 UTC; 18s ago Main PID: 3121 (rpm-ostreed) Tasks: 3 (limit: 4915) CGroup: /system.slice/rpm-ostreed.service └─3121 /usr/libexec/rpm-ostreed Oct 10 20:55:42 localhost.localdomain systemd[1]: Starting RPM OSTree Manager. Oct 10 20:55:42 localhost.localdomain rpm-ostreed[3121]: rpm-ostreed starting Oct 10 20:55:42 localhost.localdomain systemd[1]: Started RPM OSTree Manager. Warning: rpm-ostreed.service changed on disk. Run 'systemctl daemon-reload' to [vagrant@localhost ~]$ sudo atomic host upgrade Updating from: fedora-atomic:fedora-atomic/25/x86_64/docker-host error: Bus owner changed, aborting. From walters@verbum.org Tue Oct 11 10:10:19 2016 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9BEAJhq032408 for ; Tue, 11 Oct 2016 10:10:19 -0400 Received: from mx1.redhat.com (ext-mx05.extmail.prod.ext.phx2.redhat.com [10.5.110.29]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9BEAJ7Y025721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 11 Oct 2016 10:10:19 -0400 Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5216031B333 for ; Tue, 11 Oct 2016 14:10:18 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9511320A53 for ; Tue, 11 Oct 2016 10:10:17 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute1.internal (MEProxy); Tue, 11 Oct 2016 10:10:17 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=E9uSC1uUuDbYDUo ubTw9C439nfU=; b=Vnhgu1pm7lI6qIrCACqJkvz3w9XE4Bxjah6FBt46Xbmeb2F 9xswDKhmzur28V6yriPVeJWBhJZaYIvEbUkq839tKrao85OiwaYOxs2rjHqpg1Q9 5HrKXb+lzbgZa/RBBjwbga4Gqh0hffOtdApMdSZ7gMUKpUaTPLoFf4tCZ7+Q= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 74FDCD01AF; Tue, 11 Oct 2016 10:10:17 -0400 (EDT) Message-Id: <1476195017.4041924.752432409.53088647@webmail.messagingengine.com> X-Sasl-Enc: K3vC3YcLwGx1vWUQx8tsRBX4RoiDA/okl64Sb27+XPsi 1476195017 From: Colin Walters To: atomic-devel@projectatomic.io MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Date: Tue, 11 Oct 2016 10:10:17 -0400 In-Reply-To: <8116892e-f971-2fab-cd42-74d59e56f799@dustymabe.com> References: <8116892e-f971-2fab-cd42-74d59e56f799@dustymabe.com> X-Greylist: Sender IP whitelisted by DNSRBL, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 11 Oct 2016 14:10:18 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 11 Oct 2016 14:10:18 +0000 (UTC) for IP:'66.111.4.29' DOMAIN:'out5-smtp.messagingengine.com' HELO:'out5-smtp.messagingengine.com' FROM:'walters@verbum.org' RCPT:'' X-RedHat-Spam-Score: -0.301 (BAYES_50, DCC_REPUT_00_12, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2) 66.111.4.29 out5-smtp.messagingengine.com 66.111.4.29 out5-smtp.messagingengine.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.29 X-loop: atomic-devel@redhat.com Subject: Re: [atomic-devel] rpm-ostree error: Bus owner changed, aborting. X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 14:10:20 -0000 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 From dwalsh@redhat.com Tue Oct 11 13:33:43 2016 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9BHXhiu020087 for ; Tue, 11 Oct 2016 13:33:43 -0400 Received: from mx1.redhat.com (ext-mx10.extmail.prod.ext.phx2.redhat.com [10.5.110.39]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9BHXhMJ003535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 11 Oct 2016 13:33:43 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B520DE0352 for ; Tue, 11 Oct 2016 17:33:43 +0000 (UTC) Received: from dhcp-10-19-62-196.boston.devel.redhat.com (vpn-236-188.phx2.redhat.com [10.3.236.188]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9BHXhCR031408 for ; Tue, 11 Oct 2016 13:33:43 -0400 To: "atomic-devel@projectatomic.io" From: Daniel J Walsh Message-ID: Date: Tue, 11 Oct 2016 13:33:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 11 Oct 2016 17:33:43 +0000 (UTC) X-loop: atomic-devel@redhat.com Subject: [atomic-devel] I have setup a IRC Channel on Freenode for OCID X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 17:33:44 -0000 Join #ocid if you are interested in the ongoing development. From jeder@redhat.com Tue Oct 11 13:36:16 2016 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9BHaG9G020476 for ; Tue, 11 Oct 2016 13:36:16 -0400 Received: from mx1.redhat.com (ext-mx07.extmail.prod.ext.phx2.redhat.com [10.5.110.31]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9BHaGCW030864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 11 Oct 2016 13:36:16 -0400 Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 655A8C001BFC for ; Tue, 11 Oct 2016 17:36:15 +0000 (UTC) Received: by mail-io0-f179.google.com with SMTP id i202so32449392ioi.2 for ; Tue, 11 Oct 2016 10:36:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XX1TtrKoKA/NtCfkRaNzFYcXLXiwYXlDXEIsRJLOGvk=; b=QdC/LwAhjPYjNT4YXWsHOtKFgo4kkZSERxcUNPBzEqZvr3QXr4NBBVAXEb9P0qs5tY jfAgIZt0urCzB/X0yaH9n2duPprdhtriO68h8DwgrZoi4qkTL8chYpfyUKtPb421wJOW +nEjw4uUwzMNwqSnAYfCLjknijMUE40YKfg0fl7nJzpORPv5lDKE7dbqZdGnsJvDU/It AtXP3dQBgAIHrde2E23H04syn27kQL0qSv/3LU8eUXItKgJn/YFV9/K4vUkoC8ta0pmF c7FXdm2bExJL0U7lLyXfALGh08LKVGQUtmXgwLBCrrdlFGsOXB/krY8biqEO1DPdpMz3 qDEQ== X-Gm-Message-State: AA6/9RmrcoRQh7jLp9dUaooaXsyJGz1n+fTHTI0QICgDrZuvudQn9kIZbwAeFADB69Zp9vMz6y4lf8+8+rjsn1Ku X-Received: by 10.107.28.136 with SMTP id c130mr7581559ioc.195.1476207374729; Tue, 11 Oct 2016 10:36:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.8.34 with HTTP; Tue, 11 Oct 2016 10:36:14 -0700 (PDT) From: Jeremy Eder Date: Tue, 11 Oct 2016 13:36:14 -0400 Message-ID: To: atomic-devel , "Dodson, Scott" Content-Type: multipart/alternative; boundary=001a113fdec62f9f3a053e9a50e7 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 11 Oct 2016 17:36:15 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 11 Oct 2016 17:36:15 +0000 (UTC) for IP:'209.85.223.179' DOMAIN:'mail-io0-f179.google.com' HELO:'mail-io0-f179.google.com' FROM:'jeder@redhat.com' RCPT:'' X-RedHat-Spam-Score: 0.389 (BAYES_50, DCC_REPUT_00_12, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_PASS) 209.85.223.179 mail-io0-f179.google.com 209.85.223.179 mail-io0-f179.google.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.31 X-loop: atomic-devel@redhat.com Subject: [atomic-devel] How to apply non-atomic tuned profiles to atomic host X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 17:36:16 -0000 --001a113fdec62f9f3a053e9a50e7 Content-Type: text/plain; charset=UTF-8 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? --001a113fdec62f9f3a053e9a50e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">Right now we've got the tuned package in the base ato= mic content.=C2=A0 There are atomic-host and atomic-guest tuned profiles wh= ich are currently identical to the atomic-openshift ones.=C2=A0 We'd li= ke 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 loc= ations (atomic-* and atomic-openshift-* tuned profiles with identical conte= nt.

So, trying to = reason a way to get those profiles onto an AH since we can't install th= e 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 fil= es" in /etc.=C2=A0 Thoughts?

--001a113fdec62f9f3a053e9a50e7-- From jdetiber@redhat.com Tue Oct 11 13:44:12 2016 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9BHiCZe020953 for ; Tue, 11 Oct 2016 13:44:12 -0400 Received: from mx1.redhat.com (ext-mx03.extmail.prod.ext.phx2.redhat.com [10.5.110.27]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9BHiBaE013754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 11 Oct 2016 13:44:11 -0400 Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CA33F83F3A for ; Tue, 11 Oct 2016 17:44:10 +0000 (UTC) Received: by mail-oi0-f48.google.com with SMTP id m72so32396208oik.3 for ; Tue, 11 Oct 2016 10:44:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XxdMjSOjbho7ylR2S3C5DHjQgjWrq1lBfdjE3ZyfGAQ=; b=VmqeQtm+6kBvDuLoiwqb4pWHWwLEcnctlvuQ1dUK6p+AHhohS1IMj8UZYAWyN2PcqS GQ0zA8EhW4yuuFPE3Oa+EAhBJNgwcYnNRWrsYEJig2Svpw6C2ZVhQZ707x4coobNER7t WajFNPR3btDJ3dKSVzqRx7Rale7cRa9uucAj/l3X+7kA6uK6dUDyDXJqaZx1TGe/X+Wj alGH0OV1tM8L59xBbgwzsBcg9rH6ddvEiXFQlu0YykESoPYIgkgWZ/H09QhJFGxGpO1k ywAecN0fet8B6PKuo3QO34vctgStKYbE3zeTaZ6cabCIhNSKT0yONylDPNGbMejPsLeR y1JQ== X-Gm-Message-State: AA6/9RkFsFOlqVYCtlRCTa7i5hXzk7CpIjImyN0tzUzLmUDWPiWWteTb6crPyZkFJ3Km57bY2sE3AWZ1L8/LBUmz X-Received: by 10.157.17.90 with SMTP id p26mr2825404otp.197.1476207850235; Tue, 11 Oct 2016 10:44:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.7.131 with HTTP; Tue, 11 Oct 2016 10:44:09 -0700 (PDT) In-Reply-To: References: From: Jason DeTiberus Date: Tue, 11 Oct 2016 13:44:09 -0400 Message-ID: To: Jeremy Eder Content-Type: multipart/alternative; boundary=001a1141c872874349053e9a6ce2 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 11 Oct 2016 17:44:10 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 11 Oct 2016 17:44:10 +0000 (UTC) for IP:'209.85.218.48' DOMAIN:'mail-oi0-f48.google.com' HELO:'mail-oi0-f48.google.com' FROM:'jdetiber@redhat.com' RCPT:'' X-RedHat-Spam-Score: 0.389 (BAYES_50, DCC_REPUT_00_12, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_PASS) 209.85.218.48 mail-oi0-f48.google.com 209.85.218.48 mail-oi0-f48.google.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.27 X-loop: atomic-devel@redhat.com Cc: "Dodson, Scott" , atomic-devel Subject: Re: [atomic-devel] How to apply non-atomic tuned profiles to atomic host X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 17:44:12 -0000 --001a1141c872874349053e9a6ce2 Content-Type: text/plain; charset=UTF-8 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 --001a1141c872874349053e9a6ce2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 11, 2016 at 1:36 PM, Jeremy Eder <jeder@redhat.com><= /span> wrote:

Hi,

Right now we've got the tuned package in the base atomic c= ontent.=C2=A0 There are atomic-host and atomic-guest tuned profiles which a= re currently identical to the atomic-openshift ones.=C2=A0 We'd like to= make a change to the atomic-openshift-node/master profiles (which are dist= ributed with the openshift product).

Going fwd, I think we would rathe= r not maintain two locations (atomic-* and atomic-openshift-* tuned profile= s 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 R= PM...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 ki= nd of hacky since there would be "orphan files" in /etc.=C2=A0 Th= oughts?

With a sufficiently rec= ent version of atomic host, you could use layered packages:=C2=A0http://www.projectatomic.io/blog/2016/08/new-centos-a= tomic-host-with-package-layering-support/

Jason= DeTiberus

--001a1141c872874349053e9a6ce2-- From jdetiber@redhat.com Tue Oct 11 14:05:12 2016 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9BI5Cca022649 for ; Tue, 11 Oct 2016 14:05:12 -0400 Received: from mx1.redhat.com (ext-mx06.extmail.prod.ext.phx2.redhat.com [10.5.110.30]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9BI5Cid032657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 11 Oct 2016 14:05:12 -0400 Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 72B533D948 for ; Tue, 11 Oct 2016 18:05:11 +0000 (UTC) Received: by mail-oi0-f48.google.com with SMTP id y2so33371266oie.0 for ; Tue, 11 Oct 2016 11:05:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pAn6gyR12vr3gjZqBY9pt4sVgDOoJhP1YwNPR6f8/JU=; b=dtE8KdNt86MkfSVXtDarnY7CeKV8zVI+Ptn/a6hspyME8zXx+NuRrLuTEWh6nUP4le 1WEl4JAOD6v7IYUoMGhbnbWEf1wX6E40pCXkkXeOHBSiEhKgQLQKD+iGrsAaI7rArsYH PsW64LmWKa9J7Qdvslf+1RsrpR42Jztt09w8hMWFlR2O6ugxnVmJc0jFksmELfwCL07J HM6iK4Lmm/vfzGkqMD2l3bcHnxe4Is+MKGg+qCtdOtEm2D6g62FUS+oICgGaYeUvgFFe LG/FINr2tgGLt4Bz64Vsf4qh2wuDg8d+akqkYAY7LDv5K8MvapJheo4own7Vh3/M91GU /97w== X-Gm-Message-State: AA6/9RkQO3c0L6JyL6I5h2Oxb3MWyDTgGHAekR+65r06dfmxEVifxxqwtddI/x6tvJafxURoMtBIi6N7LBExEeEC X-Received: by 10.202.196.69 with SMTP id u66mr3557336oif.101.1476209110868; Tue, 11 Oct 2016 11:05:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.7.131 with HTTP; Tue, 11 Oct 2016 11:05:10 -0700 (PDT) In-Reply-To: References:

From: Jason DeTiberus Date: Tue, 11 Oct 2016 14:05:10 -0400 Message-ID: To: Scott Dodson Content-Type: multipart/alternative; boundary=001a1134f5acab046c053e9ab740 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 11 Oct 2016 18:05:11 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 11 Oct 2016 18:05:11 +0000 (UTC) for IP:'209.85.218.48' DOMAIN:'mail-oi0-f48.google.com' HELO:'mail-oi0-f48.google.com' FROM:'jdetiber@redhat.com' RCPT:'' X-RedHat-Spam-Score: 0.389 (BAYES_50, DCC_REPUT_00_12, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_PASS) 209.85.218.48 mail-oi0-f48.google.com 209.85.218.48 mail-oi0-f48.google.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.30 X-loop: atomic-devel@redhat.com Cc: atomic-devel Subject: Re: [atomic-devel] How to apply non-atomic tuned profiles to atomic host X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 18:05:12 -0000 --001a1134f5acab046c053e9ab740 Content-Type: text/plain; charset=UTF-8 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 --001a1134f5acab046c053e9ab740 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 11, 2016 at 1:53 PM, Scott Dodson <sdodson@redhat.com= > wrote:

On Tu= e, Oct 11, 2016 at 1:44 PM, Jason DeTiberus <jdetiber@redhat.com> wrote:
>
>
> On Tue, Oct 11, 2016 at 1:36 PM, Jeremy Eder <jeder@redhat.com> wrote:
>>
>> Hi,
>>
>> Right now we've got the tuned package in the base atomic conte= nt.=C2=A0 There
>> are atomic-host and atomic-guest tuned profiles which are currentl= y
>> identical to the atomic-openshift ones.=C2=A0 We'd like to mak= e 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 (ato= mic-*
>> 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 /et= c/tuned
>> and enable them manually...but I'm not sure that jives with ho= w we're
>> supposed to use AH and it seems kind of hacky since there would be= "orphan
>> files" in /etc.=C2=A0 Thoughts?
>
>
> With a sufficiently recent version of atomic host, you could use layer= ed
> packages:
> h= ttp://www.projectatomic.io/blog/2016/08/new-centos-atomic-host-wi= th-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 th= at may not make sense to deploy containerized (storage dependencies for exa= mple), so package layering seems like the proper place to manage those depe= ndencies. I would view the tuned profiles in the same way.

--
Jason DeTiberus

--001a1134f5acab046c053e9ab740-- From walters@verbum.org Tue Oct 11 14:14:07 2016 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9BIE7mF024035 for ; Tue, 11 Oct 2016 14:14:07 -0400 Received: from mx1.redhat.com (ext-mx08.extmail.prod.ext.phx2.redhat.com [10.5.110.32]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9BIE7w8007687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 11 Oct 2016 14:14:07 -0400 Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AA8E7C05A287 for ; Tue, 11 Oct 2016 18:14:05 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E632C2085A for ; Tue, 11 Oct 2016 14:14:04 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute1.internal (MEProxy); Tue, 11 Oct 2016 14:14:04 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=m8G4P+iIFxccDlN YZfjMwij8EEc=; b=C++ZbQ4HWzTfImUzebbULX2hYPw83PtXyOgflOaI7BBwPpU 0uwjgH5Kd0tBhL+8qCorg8Dq1gs3zXWpQVFkf1DdaSWEVUs+axKJg6JvBmkdOets JRy37RxzQL9D2WgO55jGtv1n3scNRxdbwr0WQzvlEaGsqxbzfd3xhb0/LDGA= Received: by mailuser.nyi.internal (Postfix, from userid 99) id BB3D2D01AF; Tue, 11 Oct 2016 14:14:04 -0400 (EDT) Message-Id: <1476209644.4099876.752712481.746048C1@webmail.messagingengine.com> X-Sasl-Enc: GTrXcZxpPrxDTeL+zj9LXiKDD2++OPeCDkDHHo02vmyF 1476209644 From: Colin Walters To: atomic-devel@projectatomic.io MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_147620964440998761"; charset="utf-8" In-Reply-To: References: Date: Tue, 11 Oct 2016 14:14:04 -0400 X-Greylist: Sender IP whitelisted by DNSRBL, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 11 Oct 2016 18:14:05 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 11 Oct 2016 18:14:05 +0000 (UTC) for IP:'66.111.4.29' DOMAIN:'out5-smtp.messagingengine.com' HELO:'out5-smtp.messagingengine.com' FROM:'walters@verbum.org' RCPT:'' X-RedHat-Spam-Score: 0.4 (BAYES_60, DCC_REPUT_00_12, DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2) 66.111.4.29 out5-smtp.messagingengine.com 66.111.4.29 out5-smtp.messagingengine.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.32 X-loop: atomic-devel@redhat.com Subject: Re: [atomic-devel] How to apply non-atomic tuned profiles to atomic host X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 18:14:07 -0000 This is a multi-part message in MIME format. --_----------=_147620964440998761 Content-Transfer-Encoding: 7bit Content-Type: text/plain 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) --_----------=_147620964440998761 Content-Transfer-Encoding: 7bit Content-Type: text/html

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)

--_----------=_147620964440998761-- From walters@verbum.org Tue Oct 11 14:26:17 2016 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9BIQGDZ025568 for ; Tue, 11 Oct 2016 14:26:16 -0400 Received: from mx1.redhat.com (ext-mx03.extmail.prod.ext.phx2.redhat.com [10.5.110.27]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9BIQGNd017214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 11 Oct 2016 14:26:16 -0400 Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B82D18AE6C for ; Tue, 11 Oct 2016 18:26:14 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B553220ACA for ; Tue, 11 Oct 2016 14:26:13 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute1.internal (MEProxy); Tue, 11 Oct 2016 14:26:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=McfSVkUvqw/V7cb L1IuB22F4pkY=; b=UYfvAUR0COshx6nW5Jj91lmypPD9AhMZHikPS0FKZN5KlAP jOfpdoZ38r9Z8Uqhg6XsKO6glHhyL+jbxE4T12TtCfkZYlISVKlzNgxuXztHd82x w4kmM7Zm9dLY+v8u4AaUmgUjkvsro02WUxc8+XpIpvD4Lhc4ZGW6wkvqGjyg= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9347DD01AF; Tue, 11 Oct 2016 14:26:13 -0400 (EDT) Message-Id: <1476210373.4102589.752731753.24F486C7@webmail.messagingengine.com> X-Sasl-Enc: UEsz6V3mn23+wK3fc23cx5BS8nYdb+UTOMJP2HoQeEEY 1476210373 From: Colin Walters To: atomic-devel@projectatomic.io MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain In-Reply-To: <1476195017.4041924.752432409.53088647@webmail.messagingengine.com> References: <8116892e-f971-2fab-cd42-74d59e56f799@dustymabe.com> <1476195017.4041924.752432409.53088647@webmail.messagingengine.com> Date: Tue, 11 Oct 2016 14:26:13 -0400 X-Greylist: Sender IP whitelisted by DNSRBL, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 11 Oct 2016 18:26:14 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 11 Oct 2016 18:26:14 +0000 (UTC) for IP:'66.111.4.29' DOMAIN:'out5-smtp.messagingengine.com' HELO:'out5-smtp.messagingengine.com' FROM:'walters@verbum.org' RCPT:'' X-RedHat-Spam-Score: -0.301 (BAYES_50, DCC_REPUT_00_12, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2) 66.111.4.29 out5-smtp.messagingengine.com 66.111.4.29 out5-smtp.messagingengine.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.27 X-loop: atomic-devel@redhat.com Subject: Re: [atomic-devel] rpm-ostree error: Bus owner changed, aborting. X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 18:26:17 -0000 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 From jeder@redhat.com Tue Oct 11 14:45:16 2016 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9BIjGLi026884 for ; Tue, 11 Oct 2016 14:45:16 -0400 Received: from mx1.redhat.com (ext-mx10.extmail.prod.ext.phx2.redhat.com [10.5.110.39]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9BIjG10031001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 11 Oct 2016 14:45:16 -0400 Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C2AAF6267F for ; Tue, 11 Oct 2016 18:45:14 +0000 (UTC) Received: by mail-it0-f52.google.com with SMTP id o19so28031457ito.1 for ; Tue, 11 Oct 2016 11:45:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F++Q7nwwjhbfk1968XzAWZO9Y5+fEJwa8lpc2BDzFTA=; b=CjSgNmILs1DzFGkp9i3OIgQ1rrEJKpe4cVgXQ8OOFnD6aUKTcTPyhDrUr2OO6lW/kO Txl6KbrbhNciHtHAhgl36zIOoSifMxQNgY0ztbDGHts8dqv+qABUA+DNw8ucvmFamkEt 9jPCArwErfkP1eT6Ar9xDtcWdFSfu1B6UmrZYYH5Z6LH9CjAvU5jINW2j4oC6yH51iQH I9Tqbqi6YDg8q/NijEETkK2EyJCWCZaGTegjI8rv7CCA6VaGhy9QQ9xOj/1mNzM8gSU8 xUP8OmKkrG2vEFith6yEuwog4zuUdokRMqPx9md3WGp9Yc4cmdLhiL4DZCnFaFUuiWw1 zadQ== X-Gm-Message-State: AA6/9RkcEIuFLxwsaGP7CB6VBLfsEIPCqAECtLPm0xCLd4CPEyDvkvM+ParFzdIT+F5RI/7RQdpII++yWcX0LWgH X-Received: by 10.36.189.73 with SMTP id x70mr19302250ite.19.1476211513735; Tue, 11 Oct 2016 11:45:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.8.34 with HTTP; Tue, 11 Oct 2016 11:45:12 -0700 (PDT) In-Reply-To: <1476209644.4099876.752712481.746048C1@webmail.messagingengine.com> References: <1476209644.4099876.752712481.746048C1@webmail.messagingengine.com> From: Jeremy Eder Date: Tue, 11 Oct 2016 14:45:12 -0400 Message-ID: To: Colin Walters Content-Type: multipart/alternative; boundary=94eb2c19e34ce3e9c5053e9b46da X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 11 Oct 2016 18:45:14 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 11 Oct 2016 18:45:14 +0000 (UTC) for IP:'209.85.214.52' DOMAIN:'mail-it0-f52.google.com' HELO:'mail-it0-f52.google.com' FROM:'jeder@redhat.com' RCPT:'' X-RedHat-Spam-Score: 0.87 (BAYES_50, DCC_REPUT_00_12, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, RCVD_IN_SORBS_SPAM, SPF_PASS) 209.85.214.52 mail-it0-f52.google.com 209.85.214.52 mail-it0-f52.google.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.39 X-loop: atomic-devel@redhat.com Cc: atomic-devel Subject: Re: [atomic-devel] How to apply non-atomic tuned profiles to atomic host X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 18:45:16 -0000 --94eb2c19e34ce3e9c5053e9b46da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. > =E2=80=8BOK, I hadn't seen it.=E2=80=8B Just read the blog that Jason sent= . Looks good. > ...We could copy them to /etc/tuned and enable them manually...but I'm no= t > 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) > =E2=80=8BBecause layered products (not just OpenShift) do not want to be co= upled to the RHEL release schedule to update their profiles. They want to own their profiles and rely on the tuned daemon to be there. =E2=80=8B 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-packag= e-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=3D767977 =E2=80=8B ?=E2=80=8B --94eb2c19e34ce3e9c5053e9b46da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 11, 2016 at 2:14 PM, Colin Walters= <walters@verbum.org> wrote:

On Tue, Oct 11= , 2016, at 01:36 PM, Jeremy Eder wrote:

Going fwd, I think we would rather no= t maintain two locations (atomic-* and atomic-openshift-* tuned profiles wi= th identical content.

Yes, agreed.

So, t= rying to reason a way to get those profiles onto an AH since we can't i= nstall the tuned-atomic-openshift RPM

That's not true.=C2=A0 We'v= e been shipping package layering for quite a while.

=E2=80=8BOK, I hadn't seen = it.=E2=80=8B =C2=A0Just read the blog that Jason sent.=C2=A0 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 kin= d of hacky since there would be "orphan files" in /etc.=C2=A0 Tho= ughts?

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

Although a common trap with management sys= tems like Ansible and Puppet is (by default) they're subject

to https://en.wikipedia.org/wiki/Hysteres= is - if one version of the installer creates a tuned snippet, then
<= /div>
we later don't want it to apply, the A= nsible rules have to carry code to explicitly ensure it's deleted.=C2= =A0 Whereas

with RPM (and ostree) the system does sync= hronize 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
<= /div>
3) Installers like openshift-ansible ensur= e it's installed (noop on AH)

=E2=80=8BBecause layered products (not= just OpenShift) do not want to be coupled to the RHEL release schedule to = update their profiles.=C2=A0 They want to own their profiles and rely on th= e tuned daemon to be there.
=E2=80=8B

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.=C2=A0 Are= there any? If we're the first that's not an issue, just want to ma= ke sure we get it right.

Now, what would the implementation look like ... bas= ically 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 hav= e a reboot requirement.=C2=A0 Is that correct?=C2=A0 At least until we have=

https://bugzilla.gnome.org/s= how_bug.cgi?id=3D767977

=E2=80=8B ?=E2= =80=8B

--94eb2c19e34ce3e9c5053e9b46da-- From walters@verbum.org Wed Oct 12 10:29:05 2016 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9CET5na013936 for ; Wed, 12 Oct 2016 10:29:05 -0400 Received: from mx1.redhat.com (ext-mx08.extmail.prod.ext.phx2.redhat.com [10.5.110.32]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9CET5nX019502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 12 Oct 2016 10:29:05 -0400 Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2B802C054931 for ; Wed, 12 Oct 2016 14:29:04 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 83E7E2076A; Wed, 12 Oct 2016 10:29:03 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute1.internal (MEProxy); Wed, 12 Oct 2016 10:29:03 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=vkHVkO56lO3xQi6 UDcuFKep09mw=; b=uunxaL5iNe8HyBpLqhAgA+PSSxInoo6B7gyHtV/vvSc77Q9 15AJyePUrVCnxmUlsJz7p3fUszijyqkfI1b57R8TjUqWqcMNnwgBQMRglFBQNI9J iceZDkaSHiaYX8Svfk7r+TVOzJNf3974TDZZn7AsrUDFbVG+aei7iQjBMkv4= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 61148CC6EF; Wed, 12 Oct 2016 10:29:03 -0400 (EDT) Message-Id: <1476282543.2095480.753660465.09EA950E@webmail.messagingengine.com> X-Sasl-Enc: 9LkQvjFj15sxw5/wXtck/uRS9lkN7laKHemE52Vg6GbA 1476282543 From: Colin Walters To: Jeremy Eder MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_147628254320954800"; charset="utf-8" Date: Wed, 12 Oct 2016 10:29:03 -0400 In-Reply-To: References: <1476209644.4099876.752712481.746048C1@webmail.messagingengine.com> X-Greylist: Sender IP whitelisted by DNSRBL, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 12 Oct 2016 14:29:04 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 12 Oct 2016 14:29:04 +0000 (UTC) for IP:'66.111.4.29' DOMAIN:'out5-smtp.messagingengine.com' HELO:'out5-smtp.messagingengine.com' FROM:'walters@verbum.org' RCPT:'' X-RedHat-Spam-Score: -0.3 (BAYES_50, DCC_REPUT_00_12, DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2) 66.111.4.29 out5-smtp.messagingengine.com 66.111.4.29 out5-smtp.messagingengine.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.32 X-loop: atomic-devel@redhat.com Cc: atomic-devel Subject: Re: [atomic-devel] How to apply non-atomic tuned profiles to atomic host X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 14:29:05 -0000 This is a multi-part message in MIME format. --_----------=_147628254320954800 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Tue, Oct 11, 2016, at 02:45 PM, Jeremy Eder wrote: > 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. I see two aspects to this discussion: 1) Generic tradeoffs with host configuration 2) The specific discussion about tuned profiles Following 2) if I run: $ cd ~/src/github/openshift/origin $ git describe --tags --always v1.3.-rc1-14-ge9081ae $ git log --follow contrib/tuned/origin-node-host/tuned.conf There are a grand total of *two* commits that aren't mere code reorganization: commit d959d25a405bb28568a17f8bf1b79e7d427ae0dc Author: Jeremy Eder AuthorDate: Tue Mar 29 10:40:03 2016 -0400 Commit: Jeremy Eder CommitDate: Tue Mar 29 10:40:03 2016 -0400 bump inotify watches commit c11cb47c07e24bfeec22a7cf94b0d6d693a00883 Author: Scott Dodson AuthorDate: Thu Feb 12 13:06:57 2015 -0500 Commit: Scott Dodson CommitDate: Wed Mar 11 16:41:08 2015 -0400 Provide both a host and guest profile That level of change seems quite sufficient for the slower RHEL cadence, no? Particularly when one considers that something like the inotify watch bump could easily be part of a "tuned updates" in the installer that would live there until the base tuned profile updates. Right? > 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. In this particular case of tuned, I'd argue that Atomic Host should come out of the box with these profiles, and that any async updates could be done via the openshift-ansible installer. --_----------=_147628254320954800 Content-Transfer-Encoding: 7bit Content-Type: text/html

On Tue, Oct 11, 2016, at 02:45 PM, Jeremy Eder wrote:

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.

I see two aspects to this discussion:

1) Generic tradeoffs with host configuration

2) The specific discussion about tuned profiles

Following 2) if I run:

$ cd ~/src/github/openshift/origin

$ git describe --tags --always

v1.3.0-rc1-14-ge9081ae

$ git log --follow contrib/tuned/origin-node-host/tuned.conf

There are a grand total of *two* commits that aren't mere

code reorganization:

commit d959d25a405bb28568a17f8bf1b79e7d427ae0dc

Author: Jeremy Eder <jeder@redhat.com>

AuthorDate: Tue Mar 29 10:40:03 2016 -0400

Commit: Jeremy Eder <jeder@redhat.com>

CommitDate: Tue Mar 29 10:40:03 2016 -0400

bump inotify watches

commit c11cb47c07e24bfeec22a7cf94b0d6d693a00883

Author: Scott Dodson <sdodson@redhat.com>

AuthorDate: Thu Feb 12 13:06:57 2015 -0500

Commit: Scott Dodson <sdodson@redhat.com>

CommitDate: Wed Mar 11 16:41:08 2015 -0400

Provide both a host and guest profile

That level of change seems quite sufficient for the slower

RHEL cadence, no?

Particularly when one considers that something like the

inotify watch bump could easily be part of a "tuned updates"

in the installer that would live there until the base tuned

profile updates.

Right?

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.

In this particular case of tuned, I'd argue that Atomic Host should come out of the box with these profiles,

and that any async updates could be done via the openshift-ansible installer.

--_----------=_147628254320954800-- From atomic@ibotty.net Wed Oct 12 15:17:11 2016 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9CJHBWS009793 for ; Wed, 12 Oct 2016 15:17:11 -0400 Received: from mx1.redhat.com (ext-mx02.extmail.prod.ext.phx2.redhat.com [10.5.110.26]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9CJHAfe002486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Oct 2016 15:17:10 -0400 Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CA8FD5455F; Wed, 12 Oct 2016 19:17:08 +0000 (UTC) X-Envelope-From: atomic@ibotty.net Received: from [192.168.0.97] (ip5b41db4d.dynamic.kabel-deutschland.de [91.65.219.77]) (authenticated bits=0) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id u9CJH42e019215 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Oct 2016 21:17:05 +0200 To: Daniel J Walsh , =?UTF-8?B?THVrw6HFoSBOeWtyw71u?= , atomic-devel@projectatomic.io, Lennart Poettering , Giuseppe Scrivano References: <3a03c725-2f5b-7b13-94d5-24bcd8fd1621@redhat.com> <147393614236.12736.16980196453002524458@piano> <1474023891.1847.5.camel@redhat.com> <2bababf7-7d50-7e6a-9bee-6bb782da56b6@redhat.com> From: Tobias Florek Message-ID: Date: Wed, 12 Oct 2016 21:17:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <2bababf7-7d50-7e6a-9bee-6bb782da56b6@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted by DNSRBL, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 12 Oct 2016 19:17:09 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 12 Oct 2016 19:17:09 +0000 (UTC) for IP:'192.109.42.8' DOMAIN:'einhorn.in-berlin.de' HELO:'einhorn.in-berlin.de' FROM:'atomic@ibotty.net' RCPT:'' X-RedHat-Spam-Score: 0.08 (BAYES_50, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL) 192.109.42.8 einhorn.in-berlin.de 192.109.42.8 einhorn.in-berlin.de X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.26 X-loop: atomic-devel@redhat.com Subject: Re: [atomic-devel] systemd as pid 1 in an unprivileged container. X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 19:17:11 -0000 Hi, >>> I think we need to discuss this with the systemd team. We are currently >>> looking into running non privileged containers as a user launched >>> at boot time using systemd. >>> >>> Lukas what is the chances of getting a systemd that would run as a non >>> root user as pid 1 inside of a container? Could we execute systemd-user >>> to do something like that? >> Currently this is not possible, but I think to making that work it >> would require just minor changes. Anyway I don't want to promise >> anything, so can we postpone this discussion to systemd conference? >> >> Lukas now that systemd conference has been a success, I wanted to ask whether you had a chance to look into it? Cheers, Tobias Florek From gscrivan@redhat.com Thu Oct 13 09:27:01 2016 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9DDR10R019828 for ; Thu, 13 Oct 2016 09:27:01 -0400 Received: from mx1.redhat.com (ext-mx01.extmail.prod.ext.phx2.redhat.com [10.5.110.25]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9DDR1AA021937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Oct 2016 09:27:01 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E5E258E3FB; Thu, 13 Oct 2016 13:27:00 +0000 (UTC) Received: from helium (vpn1-7-152.ams2.redhat.com [10.36.7.152]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9DDQujE002187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Oct 2016 09:26:58 -0400 From: Giuseppe Scrivano To: Tobias Florek References: <3a03c725-2f5b-7b13-94d5-24bcd8fd1621@redhat.com> <147393614236.12736.16980196453002524458@piano> <1474023891.1847.5.camel@redhat.com> <2bababf7-7d50-7e6a-9bee-6bb782da56b6@redhat.com> Date: Thu, 13 Oct 2016 15:26:55 +0200 In-Reply-To: (Tobias Florek's message of "Wed, 12 Oct 2016 21:17:04 +0200") Message-ID: <8760owxtuo.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 13 Oct 2016 13:27:01 +0000 (UTC) X-loop: atomic-devel@redhat.com Cc: =?utf-8?B?THVrw6HFoSBOeWtyw71u?= , atomic-devel@projectatomic.io, Lennart Poettering , Alexander Larsson Subject: Re: [atomic-devel] systemd as pid 1 in an unprivileged container. X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 13:27:02 -0000 Hi, Tobias Florek writes: > now that systemd conference has been a success, I wanted to ask whether > you had a chance to look into it? I was playing around with bubblewrap and systemd. I've submitted some patches for systemd that got merged: https://github.com/systemd/systemd/pull/4280 they enable systemd to work without CAP_AUDIT[READ|WRITE] and not fail when setgroups is disabled (can be done through /proc/PID/setgroups). I have more patches to bubblewrap: https://github.com/projectatomic/bubblewrap/pull/101 that are needed to run systemd in it. I think the overall design, and that some caps are left only when in a new user namespace is safe. Anyway, they require a very accurate review, as a bug there can open the door to really bad things. Regards, Giuseppe From gscrivan@redhat.com Thu Oct 13 11:35:29 2016 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9DFZTqN032025 for ; Thu, 13 Oct 2016 11:35:29 -0400 Received: from mx1.redhat.com (ext-mx07.extmail.prod.ext.phx2.redhat.com [10.5.110.31]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9DFZTxV022056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Oct 2016 11:35:29 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DA2F4C04B921; Thu, 13 Oct 2016 15:35:28 +0000 (UTC) Received: from helium (vpn1-7-152.ams2.redhat.com [10.36.7.152]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9DFZN6v025435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Oct 2016 11:35:25 -0400 From: Giuseppe Scrivano To: Tob References: <3a03c725-2f5b-7b13-94d5-24bcd8fd1621@redhat.com> <147393614236.12736.16980196453002524458@piano> <1474023891.1847.5.camel@redhat.com> <2bababf7-7d50-7e6a-9bee-6bb782da56b6@redhat.com> <8760owxtuo.fsf@redhat.com> <147637151968.8471.12582792558786287471@piano> Date: Thu, 13 Oct 2016 17:35:23 +0200 In-Reply-To: <147637151968.8471.12582792558786287471@piano> (Tob's message of "Thu, 13 Oct 2016 17:11:59 +0200") Message-ID: <87vawww9c4.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 13 Oct 2016 15:35:29 +0000 (UTC) X-loop: atomic-devel@redhat.com Cc: Alexander Larsson , Lennart Poettering , =?utf-8?B?THVrw6HFoSBOeWtyw71u?= , atomic-devel@projectatomic.io Subject: Re: [atomic-devel] systemd as pid 1 in an unprivileged container. X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 15:35:29 -0000 Hi Tob, Tob writes: > thank you for working on it. So the plan to run systemd with a positive > uid is to wrap it in bubblewrap? Will that work with docker (or OCI)? it works with Docker and runc as well, they leave more capabilities in the container than what bubblewrap does (with my WIP patches). Regards, Giuseppe From walters@verbum.org Thu Oct 13 14:45:50 2016 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9DIjoK8018532 for ; Thu, 13 Oct 2016 14:45:50 -0400 Received: from mx1.redhat.com (ext-mx05.extmail.prod.ext.phx2.redhat.com [10.5.110.29]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9DIjoAP027706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Oct 2016 14:45:50 -0400 Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D4F7C20278 for ; Thu, 13 Oct 2016 18:45:48 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2940A206C1 for ; Thu, 13 Oct 2016 14:45:48 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute1.internal (MEProxy); Thu, 13 Oct 2016 14:45:48 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=HypxuRE3z/vV+zjXslSpIn19Jlk=; b=T9x04 KJAxr7GjehQQ38q40SWRSlkNcMKy36ypz3zD/EqfWsPArkPvWgkSy5PPUpEQ0mRU d9orFTiDqDe1CI+bckV991nfa/UoHSckCcD+INjwkH+pZe79EbdTlRzzjy0jePKm RRzEQhbt13fkAHOJYaRSZzfPmnItDxfoMH8apw= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 062C7CC7C8; Thu, 13 Oct 2016 14:45:47 -0400 (EDT) Message-Id: <1476384347.4113751.755151761.41AE3F53@webmail.messagingengine.com> X-Sasl-Enc: qoL6/hJcaHN6jkHCdxTiGq86YZfTsg63IieZMaOCnmRZ 1476384347 From: Colin Walters To: atomic-devel@projectatomic.io MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Date: Thu, 13 Oct 2016 14:45:47 -0400 X-Greylist: Sender IP whitelisted by DNSRBL, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 13 Oct 2016 18:45:48 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 13 Oct 2016 18:45:48 +0000 (UTC) for IP:'66.111.4.29' DOMAIN:'out5-smtp.messagingengine.com' HELO:'out5-smtp.messagingengine.com' FROM:'walters@verbum.org' RCPT:'' X-RedHat-Spam-Score: -0.301 (BAYES_50, DCC_REPUT_00_12, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2) 66.111.4.29 out5-smtp.messagingengine.com 66.111.4.29 out5-smtp.messagingengine.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.29 X-loop: atomic-devel@redhat.com Subject: [atomic-devel] CentOS Atomic Host Alpha 7.2016.402 X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 18:45:50 -0000 Hi, I've tagged a new CentOS Atomic Host Alpha, see: https://wiki.centos.org/SpecialInterestGroup/Atomic/Devel There's a lot happening in the atomic/skopeo components, and this continues to track the latest there, as well as newer ostree/rpm-ostree, which have a few fixes for package layering. This also rolls in security updates from CentOS base, such as the kernel and openssl. This is the second release of the "new" promotion model from the "continuous" -> "alpha", and things seemed to work fine, but let us know (as an issue on https://github.com/CentOS/sig-atomic-buildscripts/ ) if you see any problems. Thanks! Upgraded: NetworkManager-1:1.0.6-31.el7_2.x86_64 NetworkManager-libnm-1:1.0.6-31.el7_2.x86_64 atomic-1.13.0.4-adc8956f50a38d15b65ebf34dacee6a418524e20.c6c664b91e099b3f2078e562af19220c2ff7562d.el7.centos.x86_64 bind-libs-32:9.9.4-29.el7_2.4.x86_64 bind-libs-lite-32:9.9.4-29.el7_2.4.x86_64 bind-license-32:9.9.4-29.el7_2.4.noarch bind-utils-32:9.9.4-29.el7_2.4.x86_64 bubblewrap-0.1.2.1-169db041313862c3ef03235dde30e6d3c96e2a6a.el7.centos.x86_64 device-mapper-multipath-0.4.9-85.el7_2.6.x86_64 device-mapper-multipath-libs-0.4.9-85.el7_2.6.x86_64 device-mapper-persistent-data-0.6.3-1.el7.centos.x86_64 dnsmasq-2.66-14.el7_2.1.x86_64 docker-1.10.3-46.el7.14.x86_64 docker-common-1.10.3-46.el7.14.x86_64 docker-latest-1.12.1-2.el7.centos.x86_64 docker-lvm-plugin-1.10.3-46.el7.14.x86_64 docker-novolume-plugin-1.10.3-46.el7.14.x86_64 docker-rhel-push-plugin-1.10.3-46.el7.14.x86_64 docker-selinux-1.10.3-46.el7.14.x86_64 kernel-3.10.0-327.36.1.el7.x86_64 kmod-20-8.el7_2.x86_64 kmod-libs-20-8.el7_2.x86_64 kpartx-0.4.9-85.el7_2.6.x86_64 libarchive-3.1.2-10.el7_2.x86_64 libgudev1-219-19.el7_2.13.x86_64 libsolv-0.6.23-5.el7.centos.x86_64 libtasn1-4.9-1.el7.centos.x86_64 oci-register-machine-1:0-1.8.gitaf6c129.el7.x86_64 openssl-1:1.0.1e-51.el7_2.7.x86_64 openssl-libs-1:1.0.1e-51.el7_2.7.x86_64 ostree-2016.11.1-0446cdb0d38e1e05fc51202b580e28c44993b76c.ee3685405394f0193b77e9a9db9256cd1750e69d.el7.centos.x86_64 ostree-grub2-2016.11.1-0446cdb0d38e1e05fc51202b580e28c44993b76c.ee3685405394f0193b77e9a9db9256cd1750e69d.el7.centos.x86_64 python-2.7.5-39.el7_2.x86_64 python-libs-2.7.5-39.el7_2.x86_64 python-perf-3.10.0-327.36.1.el7.x86_64 rpm-ostree-2016.10.0-af23b948f12b01db99143bfab82ff60a3e4a4aee.7081d79d1a21dc196c1286ea012b740d47d68e1e.el7.centos.x86_64 selinux-policy-3.13.1-63.atomic.el7.7.noarch selinux-policy-targeted-3.13.1-63.atomic.el7.7.noarch systemd-219-19.el7_2.13.x86_64 systemd-libs-219-19.el7_2.13.x86_64 systemd-sysv-219-19.el7_2.13.x86_64 tuned-2.5.1-4.el7_2.6.noarch tuned-profiles-atomic-2.5.1-4.el7_2.6.noarch tzdata-2016g-2.el7.noarch xfsprogs-4.5.0-2.el7.centos.x86_64 Downgraded: skopeo-1.14-7d786d11d668f2932e524da53afb658438c8ebfc.0aa48eb05ef9b646ac444ddc878eb93dbd3d6d98.el7.centos.x86_64 Added: attr-2.4.46-12.el7.x86_64 From walters@verbum.org Thu Oct 13 17:49:43 2016 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9DLnhFm003807 for ; Thu, 13 Oct 2016 17:49:43 -0400 Received: from mx1.redhat.com (ext-mx09.extmail.prod.ext.phx2.redhat.com [10.5.110.38]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9DLnhrW022149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Oct 2016 17:49:43 -0400 Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D6C794E4C5 for ; Thu, 13 Oct 2016 21:49:41 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F1E242088E; Thu, 13 Oct 2016 17:49:40 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute1.internal (MEProxy); Thu, 13 Oct 2016 17:49:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=MCdwOFeL8LGzmJn6SR203eojXUg=; b=MGIuu M+CzLIakL+/KJBhOSdx/LhQ/ExS6QgnCmzX4hJHKV/ILQ8xlSTWUHjYyU4ER8CQZ EJzpSqZlJ5/ZK+0UTGvuH0gZsQK5wLwaU2ulwqGVXUa6A+2MO34qoAUBu/12hrlU 4kNXxIs/h4tpuOYhbAGUoDUZnn6/n9gYDDxbGs= Received: by mailuser.nyi.internal (Postfix, from userid 99) id C433DD02D5; Thu, 13 Oct 2016 17:49:40 -0400 (EDT) Message-Id: <1476395380.450221.755283481.69103E40@webmail.messagingengine.com> X-Sasl-Enc: falj6yaoQGC1vC3DfzMni61Vdf1+cDUFJC+jHJUETQaq 1476395380 From: Colin Walters To: desktop@lists.fedoraproject.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Date: Thu, 13 Oct 2016 17:49:40 -0400 X-Greylist: Sender IP whitelisted by DNSRBL, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 13 Oct 2016 21:49:41 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 13 Oct 2016 21:49:41 +0000 (UTC) for IP:'66.111.4.29' DOMAIN:'out5-smtp.messagingengine.com' HELO:'out5-smtp.messagingengine.com' FROM:'walters@verbum.org' RCPT:'' X-RedHat-Spam-Score: 0.399 (BAYES_60, DCC_REPUT_00_12, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2) 66.111.4.29 out5-smtp.messagingengine.com 66.111.4.29 out5-smtp.messagingengine.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.38 X-loop: atomic-devel@redhat.com Cc: atomic-devel@projectatomic.io Subject: [atomic-devel] Atomic Workstation development work X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 21:49:43 -0000 Hey, so we've talked about this a lot, and there are now two change pages: https://fedoraproject.org/wiki/Changes/WorkstationOstree This is in Fedora release engineering, and the scope is basically rpm-ostree + flatpak https://fedoraproject.org/wiki/Workstation/AtomicWorkstation But I'd like to revisit this, since I want to argue strongly for adding Docker to the mix. I now use "pet" Docker containers for most of my random software building/hacking, and I think this use case is not really covered by flatpak, and installing build tools on the host system I believe should be an explicit anti-pattern. I've set up https://pagure.io/atomic-ws which is running in CentOS CI. This specifically configures Docker in a useful way (overlayfs), and starts by default. Basically, by adding Docker, I think this feels closer to Project Atomic, hence the rebranding. Besides the link on the pagure page, I copied a snapshot of the ISO here: https://fedorapeople.org/~walters/atomicws-installer-25.2016.61.iso There are hence a few things to do to merge this into Fedora: - Decide on tooling emphasis (and management; does PackageKit need to learn anything about docker?) - Decide on the branding - Merge in the partitioning changes I made in https://pagure.io/atomic-ws/blob/master/f/overlay.yml#_46 (switch to something similar to Server - xfs by default, no split /home, but overlayfs for docker) - Fix the ostree management in Fedora (right now at-most-once-a-day is far too slow for development and far too fast for most users, I think it could make sense to do a two-week cadence (+async security) as we're planning for Atomic Host). This will also enable static deltas and make the experience more pleasant; see https://fedorahosted.org/rel-eng/ticket/6313 In CentOS for Atomic Host we use a "promotion" model. From mattdm@fedoraproject.org Thu Oct 13 19:48:16 2016 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9DNmGjh015551 for ; Thu, 13 Oct 2016 19:48:16 -0400 Received: from mx1.redhat.com (ext-mx10.extmail.prod.ext.phx2.redhat.com [10.5.110.39]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9DNmF17009743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Oct 2016 19:48:15 -0400 Received: from disco.bu.edu (disco.bu.edu [128.197.11.69]) by mx1.redhat.com (Postfix) with ESMTP id 7C585624A2 for ; Thu, 13 Oct 2016 23:48:14 +0000 (UTC) Received: by disco.bu.edu (Postfix, from userid 18281) id 0875E816114A; Thu, 13 Oct 2016 19:40:36 -0400 (EDT) Date: Thu, 13 Oct 2016 19:40:36 -0400 From: Matthew Miller To: Discussions about development for the Fedora desktop Message-ID: <20161013234036.GA28817@mattdm.org> References: <1476395380.450221.755283481.69103E40@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1476395380.450221.755283481.69103E40@webmail.messagingengine.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Delayed for 00:07:38 by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 13 Oct 2016 23:48:14 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 13 Oct 2016 23:48:14 +0000 (UTC) for IP:'128.197.11.69' DOMAIN:'disco.bu.edu' HELO:'disco.bu.edu' FROM:'mattdm@fedoraproject.org' RCPT:'' X-RedHat-Spam-Score: 3.7 *** (BAYES_99, BAYES_999) 128.197.11.69 disco.bu.edu 128.197.11.69 disco.bu.edu X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.39 X-loop: atomic-devel@redhat.com Cc: atomic-devel@projectatomic.io Subject: Re: [atomic-devel] Atomic Workstation development work X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 23:48:16 -0000 On Thu, Oct 13, 2016 at 05:49:40PM -0400, Colin Walters wrote: > https://fedoraproject.org/wiki/Workstation/AtomicWorkstation > But I'd like to revisit this, since I want to argue strongly for adding > Docker to the mix. I now use "pet" Docker containers for most of my > random software building/hacking, and I think this use case is > not really covered by flatpak, and installing build tools on the host > system I believe should be an explicit anti-pattern. Did you see my post to the desktop list earlier today about Owen's "Purple Egg" project? There must be something in the air right now. :) > - Fix the ostree management in Fedora (right now at-most-once-a-day > is far too slow for development and far too fast for most users, I > think it could make sense to do a two-week cadence (+async This'd be like the "alpha" and "continuous" streams in CentOS? Would it be possible to have the continuous stream in CentOS CI (or the Fedora Jenkins instance, or triggered by taskotron, or whatever) and the alpha-equivalent (the user facing view, basically) promotion cause builds to fire off in Fedora releng infrastructure? (Just kind of thinking out loud about the easiest way to get this done.) > we're planning for Atomic Host). This will also enable static > deltas and make the experience more pleasant; see > https://fedorahosted.org/rel-eng/ticket/6313 In CentOS for Atomic > Host we use a "promotion" model. I know Adam was working on that, but I'm not sure where it landed. I know the layered image build stuff has continued to be 1000% more work than initially expected. I think it might be the "Atomic ostree repo management" item under Other in the status report here https://fedoraproject.org/wiki/ReleaseEngineering/StatusReport -- Matthew Miller Fedora Project Leader From jeder@redhat.com Fri Oct 14 07:40:10 2016 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9EBeAAW020721 for ; Fri, 14 Oct 2016 07:40:10 -0400 Received: from mx1.redhat.com (ext-mx05.extmail.prod.ext.phx2.redhat.com [10.5.110.29]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9EBeAnR023308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 14 Oct 2016 07:40:10 -0400 Received: from mail-it0-f53.google.com (mail-it0-f53.google.com [209.85.214.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C6FA91C13C0 for ; Fri, 14 Oct 2016 11:40:07 +0000 (UTC) Received: by mail-it0-f53.google.com with SMTP id e187so276945itc.1 for ; Fri, 14 Oct 2016 04:40:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l9LF8SbmggVHD9dTiZ4h0k9DnjvqleJmjqJhdnI//3A=; b=TPj6zC7g7xpb/PJxatEin2r0+tq8Exk4XfZpnMF9tvUrwAodqYu0kWxHsZOYuWUv1S GqUuhZcOadx5FUOxQSnXi815OqIZ/zxkSgYxfa+Aq01piSCt3zjCfuXlYR/5f2LGtZSc oKeFM7Lidq744WVPaGx06LvpTdhnD0Uj3bJX8Eohi7sRJ0Cch+lgWKeGZ1zbLW+V7Vl1 XXJV7nTWavBXgtrOjpBRdAQ2d/Qa84SyPlxflU3wPGqY6LSUw60SK/l3ap50FVIz+jU9 cdSMzGD2tO3a853o5hNjwx/nBuQ5ctQVq3YimZvN08xSg2vDiLFwCqxQLQMTntJPz1bn Ht1w== X-Gm-Message-State: AA6/9RmhmTbJH3+gLuNvDRlZEg961HKg5nnoRf7LZt3Ayz7nmeaW0W4iCWZhE8nlH0us09R7BHRFD0OlmNd8QwN6 X-Received: by 10.36.189.73 with SMTP id x70mr11795443ite.19.1476445206927; Fri, 14 Oct 2016 04:40:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.8.34 with HTTP; Fri, 14 Oct 2016 04:40:06 -0700 (PDT) In-Reply-To: <1476282543.2095480.753660465.09EA950E@webmail.messagingengine.com> References: <1476209644.4099876.752712481.746048C1@webmail.messagingengine.com> <1476282543.2095480.753660465.09EA950E@webmail.messagingengine.com> From: Jeremy Eder Date: Fri, 14 Oct 2016 07:40:06 -0400 Message-ID: To: Colin Walters Content-Type: multipart/alternative; boundary=94eb2c19e34c16eecb053ed1b0cb X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 14 Oct 2016 11:40:08 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 14 Oct 2016 11:40:08 +0000 (UTC) for IP:'209.85.214.53' DOMAIN:'mail-it0-f53.google.com' HELO:'mail-it0-f53.google.com' FROM:'jeder@redhat.com' RCPT:'' X-RedHat-Spam-Score: 0.18 (BAYES_50, DCC_REPUT_00_12, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, RCVD_IN_SORBS_SPAM, SPF_PASS) 209.85.214.53 mail-it0-f53.google.com 209.85.214.53 mail-it0-f53.google.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.29 X-loop: atomic-devel@redhat.com Cc: atomic-devel Subject: Re: [atomic-devel] How to apply non-atomic tuned profiles to atomic host X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 11:40:10 -0000 --94eb2c19e34c16eecb053ed1b0cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2016 at 10:29 AM, Colin Walters wrote: > > On Tue, Oct 11, 2016, at 02:45 PM, Jeremy Eder wrote: > > Because layered products (not just OpenShift) do not want to be coupled t= o > the RHEL release schedule to update their profiles. They want to own the= ir > profiles and rely on the tuned daemon to be there. > > > I see two aspects to this discussion: > > 1) Generic tradeoffs with host configuration > 2) The specific discussion about tuned profiles > > Following 2) if I run: > > $ cd ~/src/github/openshift/origin > $ git describe --tags --always > v1.3.0-rc1-14-ge9081ae > $ git log --follow contrib/tuned/origin-node-host/tuned.conf > > There are a grand total of *two* commits that aren't mere > code reorganization: > > commit d959d25a405bb28568a17f8bf1b79e7d427ae0dc > Author: Jeremy Eder > AuthorDate: Tue Mar 29 10:40:03 2016 -0400 > Commit: Jeremy Eder > CommitDate: Tue Mar 29 10:40:03 2016 -0400 > > bump inotify watches > > commit c11cb47c07e24bfeec22a7cf94b0d6d693a00883 > Author: Scott Dodson > AuthorDate: Thu Feb 12 13:06:57 2015 -0500 > Commit: Scott Dodson > CommitDate: Wed Mar 11 16:41:08 2015 -0400 > > Provide both a host and guest profile > > That level of change seems quite sufficient for the slower > RHEL cadence, no? > Decoupling profiles from RHEL has already been negotiated with many different engineering teams. As you can imagine, it has ties into our channels and distribution mechanics. Making an exception here doesn't make sense to me when it's working fine everywhere else. Particularly when one considers that something like the > inotify watch bump could easily be part of a "tuned updates" > in the installer that would live there until the base tuned > profile updates. > > Right? > =E2=80=8BPersonally I would prefer to keep tuning centralized into tuned an= d not have 5 difference places where it's being done...but to your point around having two commits ... I'm losing that consolidation battle because Kubernetes has hardcoded certain sysctl adjustments that ideally we really should have carried in tuned :-/ But if we can at least avoid doing things in openshift-ansible at least that's one less place to track.=E2=80=8B > Before we go the layered RPM route I just want to make sure you're onboar= d > 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 wan= t > to make sure we get it right. > > > In this particular case of tuned, I'd argue that Atomic Host should come > out of the box with these profiles, > and that any async updates could be done via the openshift-ansible > installer. > Realistically speaking -- we may want to use AH with another product...we've developed =E2=80=8Brealtime and =E2=80=8B NFV profiles which again exist in another =E2=80=8B channel and there is no such thing as openshift-ansible there. =E2=80=8B What would be your approach if the openshift-ansible option did not exist? (back to scattered tuning)=E2=80=8B =E2=80=8B=E2=80=8B --94eb2c19e34c16eecb053ed1b0cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 12, 2016 at 10:29 AM, Colin Walters <walters@verbum.org> wrote:

On Tue, Oct 11, 2016, at 02:45 PM, Jeremy Eder wrote:

Because= layered products (not just OpenShift) do not want to be coupled to the RHE= L release schedule to update their profiles.=C2=A0 They want to own their p= rofiles and rely on the tuned daemon to be there.

I see two aspects to this discussio= n:

1) Generic tradeoffs with host configurati= on

2) The specific discussion about tuned pro= files

Following 2) if I run:

$ cd ~/src/github/openshift/origin

$ git describe --tags --always

v1.3.0-rc1-14-ge9081ae

$ git log --follow contrib/tuned/origin-no= de-host/tuned.conf

There are a grand total of *two* commits t= hat aren't mere

code reorganization:

commit d959d25a405bb28568a17f8bf1b79e= 7d427ae0dc

Author:=C2=A0=C2=A0=C2=A0=C2=A0 Jeremy Ede= r <jeder@redhat.co= m>

AuthorDate: Tue Mar 29 10:40:03 2016 -0400=

Commit:=C2=A0=C2=A0=C2=A0=C2=A0 Jeremy Ede= r <jeder@redhat.co= m>

CommitDate: Tue Mar 29 10:40:03 2016 -0400=

=C2=A0=C2=A0=C2=A0 bump inotify watches

commit c11cb47c07e24bfeec22a7cf94b0d6= d693a00883

Author:=C2=A0=C2=A0=C2=A0=C2=A0 Scott Dods= on <sdodson@redh= at.com>

AuthorDate: Thu Feb 12 13:06:57 2015 -0500=

Commit:=C2=A0=C2=A0=C2=A0=C2=A0 Scott Dods= on <sdodson@redh= at.com>

CommitDate: Wed Mar 11 16:41:08 2015 -0400=

=C2=A0=C2=A0=C2=A0 Provide both a host and= guest profile

That level of change seems quite sufficien= t for the slower

RHEL cadence, no?

Decoupling profiles from RHEL has already been negotiated with many dif= ferent engineering teams.=C2=A0 As you can imagine, it has ties into our ch= annels and distribution mechanics.=C2=A0 Making an exception here doesn'= ;t make sense to me when it's working fine everywhere else.
<= /div>

=

Particularly when one considers that somet= hing like the

inotify watch bump could easily be part of= a "tuned updates"

in the installer that would live there unt= il the base tuned

profile updates.

Right?
=E2=80=8BPersonally I would prefer to keep = tuning centralized into tuned and not have 5 difference places where it'= ;s being done...but to your point around having two commits ... I'm los= ing that consolidation battle because Kubernetes has hardcoded certain sysc= tl adjustments that ideally we really should have carried in tuned :-/ =C2= =A0But if we can at least avoid doing things in openshift-ansible at least = that's one less place to track.=E2=80=8B

=C2=A0
=

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

In this particular case of tuned, I= 'd argue that Atomic Host should come out of the box with these profile= s,

and that any async updates could be done v= ia the openshift-ansible installer.

=
Realistically s= peaking -- we may want to use AH with another product...we've developed=
=E2=80=8Brealtime and =E2=80=8B
NFV= profiles which again exist in another
= =E2=80=8B
channel and there is no such thing as openshift-ansible ther= e.
=E2=80=8B =C2=A0
What would be your approach if= the openshift-ansible option did not exist? (back to scattered tuning)=E2=80=8B
=E2=80=8B=E2=80=8B

--94eb2c19e34c16eecb053ed1b0cb-- From jdetiber@redhat.com Fri Oct 14 10:22:48 2016 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9EEMmQl004708 for ; Fri, 14 Oct 2016 10:22:48 -0400 Received: from mx1.redhat.com (ext-mx02.extmail.prod.ext.phx2.redhat.com [10.5.110.26]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9EEMlD6029534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 14 Oct 2016 10:22:47 -0400 Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 51F2C335F96 for ; Fri, 14 Oct 2016 14:22:40 +0000 (UTC) Received: by mail-oi0-f54.google.com with SMTP id y2so138696370oie.0 for ; Fri, 14 Oct 2016 07:22:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EhgWXEEKeJ7a1jWisbhmSBAn/Q0h25ZVs6WLNLSuWLs=; b=jg8ubRLaUTwVRWuDIomsEZWjutQMkI30tm9WNvQUdh8YRYumV1Gs0EC9FZ/vndLKAZ tXLgDBYgvVHNOyLXnyfOqnEPsShPOPXC8MDM2dLKlVCkTuuc8wTPHYL5bm515bdxIXZE fcetSrrvck/aETtm24nyMo8CfxvH8FbIDnkofwFIQv4KKMNAO/Wxa0s0Idtey6S1lVt7 YkluiL5DmdB3em4MaL78hJ945NMnBdlF05IZ72ZiJrkfLjUhwLEWRRaEvazqjn06MRAb DGyR2hV4qZX3k0D0h4C/Os0jcxVaxQZEz6qdtiTmQ3XSKd6Ds75bGY13HLiJqP3RaAvJ mz3Q== X-Gm-Message-State: AA6/9RnPq2WP80wDEJocRHYjZ2o+y8OKZz23OsI8iD6H0LiMtHSqHf5AcgA0nS4GsS787XvUtuD9Hpl+EC1ohH+D X-Received: by 10.157.50.198 with SMTP id u64mr5768234otb.157.1476454959498; Fri, 14 Oct 2016 07:22:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.7.233 with HTTP; Fri, 14 Oct 2016 07:22:38 -0700 (PDT) In-Reply-To: References: <1476209644.4099876.752712481.746048C1@webmail.messagingengine.com> <1476282543.2095480.753660465.09EA950E@webmail.messagingengine.com> From: Jason DeTiberus Date: Fri, 14 Oct 2016 10:22:38 -0400 Message-ID: To: Jeremy Eder Content-Type: multipart/alternative; boundary=001a1149363263656d053ed3f534 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 14 Oct 2016 14:22:40 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 14 Oct 2016 14:22:40 +0000 (UTC) for IP:'209.85.218.54' DOMAIN:'mail-oi0-f54.google.com' HELO:'mail-oi0-f54.google.com' FROM:'jdetiber@redhat.com' RCPT:'' X-RedHat-Spam-Score: 0.87 (BAYES_50, DCC_REPUT_00_12, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, RCVD_IN_SORBS_SPAM, SPF_PASS) 209.85.218.54 mail-oi0-f54.google.com 209.85.218.54 mail-oi0-f54.google.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.26 X-loop: atomic-devel@redhat.com Cc: atomic-devel Subject: Re: [atomic-devel] How to apply non-atomic tuned profiles to atomic host X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 14:22:48 -0000 --001a1149363263656d053ed3f534 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 14, 2016 at 7:40 AM, Jeremy Eder wrote: > On Wed, Oct 12, 2016 at 10:29 AM, Colin Walters > wrote: > >> >> On Tue, Oct 11, 2016, at 02:45 PM, Jeremy Eder wrote: >> >> 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. >> >> >> I see two aspects to this discussion: >> >> 1) Generic tradeoffs with host configuration >> 2) The specific discussion about tuned profiles >> >> Following 2) if I run: >> >> $ cd ~/src/github/openshift/origin >> $ git describe --tags --always >> v1.3.0-rc1-14-ge9081ae >> $ git log --follow contrib/tuned/origin-node-host/tuned.conf >> >> There are a grand total of *two* commits that aren't mere >> code reorganization: >> >> commit d959d25a405bb28568a17f8bf1b79e7d427ae0dc >> Author: Jeremy Eder >> AuthorDate: Tue Mar 29 10:40:03 2016 -0400 >> Commit: Jeremy Eder >> CommitDate: Tue Mar 29 10:40:03 2016 -0400 >> >> bump inotify watches >> >> commit c11cb47c07e24bfeec22a7cf94b0d6d693a00883 >> Author: Scott Dodson >> AuthorDate: Thu Feb 12 13:06:57 2015 -0500 >> Commit: Scott Dodson >> CommitDate: Wed Mar 11 16:41:08 2015 -0400 >> >> Provide both a host and guest profile >> >> That level of change seems quite sufficient for the slower >> RHEL cadence, no? >> > > Decoupling profiles from RHEL has already been negotiated with many > different engineering teams. As you can imagine, it has ties into our > channels and distribution mechanics. Making an exception here doesn't ma= ke > sense to me when it's working fine everywhere else. > Given the reboot issue gets addressed, I think I would prefer this approach as well. We are working as best as we can to decouple the underlying host management from the cluster management especially around upgrades. Being able to update and ship the tuned profiles as needed would allow us to manage it as part of the cluster management without having to query underlying host state to determine if we need to do temporary modifications. The other issue is that we don't require users to manage their environments with Ansible, so our temporary modifications would also need to be documented and implemented separately for non-Ansible users. Particularly when one considers that something like the >> inotify watch bump could easily be part of a "tuned updates" >> in the installer that would live there until the base tuned >> profile updates. >> >> Right? >> > > =E2=80=8BPersonally I would prefer to keep tuning centralized into tuned = and not > have 5 difference places where it's being done...but to your point around > having two commits ... I'm losing that consolidation battle because > Kubernetes has hardcoded certain sysctl adjustments that ideally we reall= y > should have carried in tuned :-/ But if we can at least avoid doing thin= gs > in openshift-ansible at least that's one less place to track.=E2=80=8B > I can understand why Kubernetes wouldn't want to require tuned, but maybe we can drive changes upstream to make sysctl management optional. Then we would be able to add the tuned requirement in our packaging and handle it there without forcing tuned upstream. > > > >> 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, ju= st >> want to make sure we get it right. >> >> >> In this particular case of tuned, I'd argue that Atomic Host should come >> out of the box with these profiles, >> and that any async updates could be done via the openshift-ansible >> installer. >> > > Realistically speaking -- we may want to use AH with another > product...we've developed > =E2=80=8Brealtime and =E2=80=8B > NFV profiles which again exist in another > =E2=80=8B > channel and there is no such thing as openshift-ansible there. > =E2=80=8B > What would be your approach if the openshift-ansible option did not exist= ? > (back to scattered tuning)=E2=80=8B > =E2=80=8B=E2=80=8B > > --=20 Jason DeTiberus --001a1149363263656d053ed3f534 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 14, 2016 at 7:40 AM, Jeremy Eder <jeder@redhat.com><= /span> wrote:

On Wed, Oct 12, 2016 a= t 10:29 AM, Colin Walters <= walters@verbum.org> wrote:

On Tue, Oct 11, 2016, at 02:45 PM, Jeremy Eder wrote:

Because= layered products (not just OpenShift) do not want to be coupled to the RHE= L release schedule to update their profiles.=C2=A0 They want to own their p= rofiles and rely on the tuned daemon to be there.

I see two aspects to this discussio= n:

1) Generic tradeoffs with host configurati= on

2) The specific discussion about tuned pro= files

Following 2) if I run:

$ cd ~/src/github/openshift/origin

$ git describe --tags --always

v1.3.0-rc1-14-ge9081ae

$ git log --follow contrib/tuned/origin-no= de-host/tuned.conf

There are a grand total of *two* commits t= hat aren't mere

code reorganization:

commit d959d25a405bb28568a17f8bf1b79e= 7d427ae0dc

Author:=C2=A0=C2=A0=C2=A0=C2=A0 Jeremy Ede= r <jeder@redhat.co= m>

AuthorDate: Tue Mar 29 10:40:03 2016 -0400=

Commit:=C2=A0=C2=A0=C2=A0=C2=A0 Jeremy Ede= r <jeder@redhat.co= m>

CommitDate: Tue Mar 29 10:40:03 2016 -0400=

=C2=A0=C2=A0=C2=A0 bump inotify watches

commit c11cb47c07e24bfeec22a7cf94b0d6= d693a00883

Author:=C2=A0=C2=A0=C2=A0=C2=A0 Scott Dods= on <sdodson@redh= at.com>

AuthorDate: Thu Feb 12 13:06:57 2015 -0500=

Commit:=C2=A0=C2=A0=C2=A0=C2=A0 Scott Dods= on <sdodson@redh= at.com>

CommitDate: Wed Mar 11 16:41:08 2015 -0400=

=C2=A0=C2=A0=C2=A0 Provide both a host and= guest profile

That level of change seems quite sufficien= t for the slower

RHEL cadence, no?

Decoupling profiles from RHEL has already been negotiated w= ith many different engineering teams.=C2=A0 As you can imagine, it has ties= into our channels and distribution mechanics.=C2=A0 Making an exception he= re doesn't make sense to me when it's working fine everywhere else.=

Given the r= eboot issue gets addressed, I think I would prefer this approach as well. W= e are working as best as we can to decouple the underlying host management = from the cluster management especially around upgrades. Being able to updat= e and ship the tuned profiles as needed would allow us to manage it as part= of the cluster management without having to query underlying host state to= determine if we need to do temporary modifications. The other issue is tha= t we don't require users to manage their environments with Ansible, so = our temporary modifications would also need to be documented and implemente= d separately for non-Ansible users.

=C2=A0

Particularly when one considers that somet= hing like the

inotify watch bump could easily be part of= a "tuned updates"

in the installer that would live there unt= il the base tuned

profile updates.

Right?

=E2=80=8BPersonally I would prefer to keep tuning centralize= d into tuned and not have 5 difference places where it's being done...b= ut to your point around having two commits ... I'm losing that consolid= ation battle because Kubernetes has hardcoded certain sysctl adjustments th= at ideally we really should have carried in tuned :-/ =C2=A0But if we can a= t least avoid doing things in openshift-ansible at least that's one les= s place to track.=E2=80=8B

<= br>

I can understand why Kubernetes wouldn't want to require = tuned, but maybe we can drive changes upstream to make sysctl management op= tional. Then we would be able to add the tuned requirement in our packaging= and handle it there without forcing tuned upstream.

=C2=A0

=C2=A0

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

In this particular case of tuned, I= 'd argue that Atomic Host should come out of the box with these profile= s,

and that any async updates could be done v= ia the openshift-ansible installer.

=
Realisti= cally speaking -- we may want to use AH with another product...we've de= veloped
=E2=80=8Brealtime and =E2=80=8B
NFV profiles which a= gain exist in another
=E2=80=8B
channel and there is no such= thing as openshift-ansible there.
=E2=80=8B =C2=A0
What would be your app= roach if the openshift-ansible option did not exist? (back to scattered tun= ing)=E2=80=8B=
=E2=80=8B=E2=80=8B

Ja= son DeTiberus

--001a1149363263656d053ed3f534-- From walters@verbum.org Fri Oct 14 12:53:43 2016 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9EGrg8b018949 for ; Fri, 14 Oct 2016 12:53:42 -0400 Received: from mx1.redhat.com (ext-mx01.extmail.prod.ext.phx2.redhat.com [10.5.110.25]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9EGrgwv008267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 14 Oct 2016 12:53:42 -0400 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 390E185365 for ; Fri, 14 Oct 2016 16:53:41 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8661B2060B for ; Fri, 14 Oct 2016 12:53:40 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute1.internal (MEProxy); Fri, 14 Oct 2016 12:53:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=TjTa4IBrocE1ok/0pZ+Y56oruhc=; b=VfSk4 oE0qzReeY97VyFjZQb7lblAEsP7rgxM8mVE4NeEYRjZi7Yra2vAESz39QY+ueBP9 BhW/nc1m8XSE3F8MkUsH0JsAj4MlU/3lPVhq6H9aSOExnSH8Z8ErR6JskeBJSJPl QOq6RKmjWC0t7rMI/sg5Ve1EAEA2g3CotszKGc= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 63905D0527; Fri, 14 Oct 2016 12:53:40 -0400 (EDT) Message-Id: <1476464020.3438944.756211537.6E02381F@webmail.messagingengine.com> X-Sasl-Enc: 97PdFoWKurhAeb4FJCEn1LAFcHqhfZFDd2JbKjMAYGgL 1476464020 From: Colin Walters To: atomic-devel@projectatomic.io MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Date: Fri, 14 Oct 2016 12:53:40 -0400 X-Greylist: Sender IP whitelisted by DNSRBL, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 14 Oct 2016 16:53:41 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 14 Oct 2016 16:53:41 +0000 (UTC) for IP:'66.111.4.25' DOMAIN:'out1-smtp.messagingengine.com' HELO:'out1-smtp.messagingengine.com' FROM:'walters@verbum.org' RCPT:'' X-RedHat-Spam-Score: -0.32 (BAYES_50, DCC_REPUT_00_12, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL) 66.111.4.25 out1-smtp.messagingengine.com 66.111.4.25 out1-smtp.messagingengine.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.25 X-loop: atomic-devel@redhat.com Subject: [atomic-devel] bubblewrap 0.1.3 (fixes CVE-2016-8659) X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 16:53:43 -0000 A new release of bubblewrap is available: https://github.com/projectatomic/bubblewrap/releases/tag/v0.1.3 Which fixes a local privilege escalation. Specifically relevant to Project Atomic, this applies only to CentOS7/RHEL7 systems which have bubblewrap installed as privileged code. Notably, we *do* install it by default as /usr/bin/bwrap in CentOS Atomic Host Alpha, but not in the primary CentOS Atomic Host release, where it exists solely as /usr/libexec/rpm-ostree/bwrap for use by rpm-ostree's package layering, but is not installed as privileged and hence is not a vulnerability vector. Fedora, because it unconditionally enables `CLONE_NEWUSER` access, is not vulnerable to this. So, expect updates to land in: - EPEL7 - CentOS AH Alpha soon. From dwalsh@redhat.com Fri Oct 14 14:37:09 2016 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9EIb9LJ029407 for ; Fri, 14 Oct 2016 14:37:09 -0400 Received: from mx1.redhat.com (ext-mx06.extmail.prod.ext.phx2.redhat.com [10.5.110.30]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9EIb9Qt004038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 14 Oct 2016 14:37:09 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5C03C3D94C; Fri, 14 Oct 2016 18:37:09 +0000 (UTC) Received: from dhcp-10-19-62-196.boston.devel.redhat.com (vpn-236-209.phx2.redhat.com [10.3.236.209]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9EIb7M1015906; Fri, 14 Oct 2016 14:37:08 -0400 To: Colin Walters , Vivek Goyal , Vincent Batts From: Daniel J Walsh Message-ID: <1f3c6f53-c371-4cd4-ea18-b18e7831c9b3@redhat.com> Date: Fri, 14 Oct 2016 14:37:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 14 Oct 2016 18:37:09 +0000 (UTC) X-loop: atomic-devel@redhat.com Cc: "Temple, William M" , "atomic-devel@projectatomic.io" Subject: [atomic-devel] We are looking at using OSTree as a backend for sharing file systems into an OCID Container runtime X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 18:37:09 -0000 We are seeing the same problem that William Temple had this summer, where OSTree refuses to store an image with devices on it. We understand that devices should not be in image, but sadly Ubuntu image has them and therefore thousands of other images do as well. If we block the creation of the devices when exploding a OCI Image Bundle, we end up with something that is different then what is downloaded and this could potentially cause problems with mtree checking of the image on disk versus the image as shipped. Is there a reason OSTree does not work with Device Inodes? From walters@verbum.org Fri Oct 14 15:36:25 2016 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9EJaPaX002890 for ; Fri, 14 Oct 2016 15:36:25 -0400 Received: from mx1.redhat.com (ext-mx04.extmail.prod.ext.phx2.redhat.com [10.5.110.28]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9EJaPFL027753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 14 Oct 2016 15:36:25 -0400 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 20A4080082 for ; Fri, 14 Oct 2016 19:36:24 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 20E7920603 for ; Fri, 14 Oct 2016 15:36:23 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute1.internal (MEProxy); Fri, 14 Oct 2016 15:36:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=EXmwzzXVhTo8gMn McR0PMyhNVao=; b=TubaAdwZPdKyUJRy74RtQi2UxgbDI7FiW/fnTmtjyqFomW7 Av3MDaXbYwDppDuEdx/EQFX8SHE0mFKOcGeIjRpQzUBLaFNETiqMKclvGgJFTtBz ySs9aM0z9Kz6uDrcVelVhygg1qpkljgBuKcVm0VV7MVSIRS+oLXAuvDboIKA= Received: by mailuser.nyi.internal (Postfix, from userid 99) id ED9D6D0527; Fri, 14 Oct 2016 15:36:22 -0400 (EDT) Message-Id: <1476473782.3474199.756367753.61488D04@webmail.messagingengine.com> X-Sasl-Enc: 8Un+74Rx7mZoHHJj2km9kg/OF5haNbKeE5gyO2Mea0Ib 1476473782 From: Colin Walters To: atomic-devel@projectatomic.io MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Date: Fri, 14 Oct 2016 15:36:22 -0400 In-Reply-To: <1476464020.3438944.756211537.6E02381F@webmail.messagingengine.com> References: <1476464020.3438944.756211537.6E02381F@webmail.messagingengine.com> X-Greylist: Sender IP whitelisted by DNSRBL, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 14 Oct 2016 19:36:24 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 14 Oct 2016 19:36:24 +0000 (UTC) for IP:'66.111.4.25' DOMAIN:'out1-smtp.messagingengine.com' HELO:'out1-smtp.messagingengine.com' FROM:'walters@verbum.org' RCPT:'' X-RedHat-Spam-Score: -0.32 (BAYES_50, DCC_REPUT_00_12, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL) 66.111.4.25 out1-smtp.messagingengine.com 66.111.4.25 out1-smtp.messagingengine.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.28 X-loop: atomic-devel@redhat.com Subject: Re: [atomic-devel] bubblewrap 0.1.3 (fixes CVE-2016-8659) X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 19:36:25 -0000 On Fri, Oct 14, 2016, at 12:53 PM, Colin Walters wrote: > A new release of bubblewrap is available: > > https://github.com/projectatomic/bubblewrap/releases/tag/v0.1.3 ... > So, expect updates to land in: > > - EPEL7 https://bodhi.fedoraproject.org/updates/bubblewrap-0.1.3-2.el7 > - CentOS AH Alpha Done, see: https://wiki.centos.org/SpecialInterestGroup/Atomic/Devel Note this pulled in a number of other updates as we do binary promotion of continuous -> alpha. The atomic/skopeo train continues to rev, and there are some smaller fixes to the ostree stack. Changed: atomic 1.13.0.4-adc8956f50a38d15b65ebf34dacee6a418524e20.c6c664b91e099b3f2078e562af19220c2ff7562d.el7.centos -> 1.13.1.21-aed68da24c0db3ea7e2e3bd4de0904c6b67115e4.dd4522961a9990fd47096ad652d3b6d9059051d7.el7.centos bubblewrap 0.1.2.1-169db041313862c3ef03235dde30e6d3c96e2a6a.el7.centos -> 0.1.2.5-7d035f1bbcce30a80a40fc564427ddbf7589e5f1.el7.centos ostree 2016.11.1-0446cdb0d38e1e05fc51202b580e28c44993b76c.ee3685405394f0193b77e9a9db9256cd1750e69d.el7.centos -> 2016.11.5-a660e5650d0f460810ea75c44d044b6924659f59.ee3685405394f0193b77e9a9db9256cd1750e69d.el7.centos ostree-grub2 2016.11.1-0446cdb0d38e1e05fc51202b580e28c44993b76c.ee3685405394f0193b77e9a9db9256cd1750e69d.el7.centos -> 2016.11.5-a660e5650d0f460810ea75c44d044b6924659f59.ee3685405394f0193b77e9a9db9256cd1750e69d.el7.centos rpm-ostree 2016.10.0-af23b948f12b01db99143bfab82ff60a3e4a4aee.7081d79d1a21dc196c1286ea012b740d47d68e1e.el7.centos -> 2016.10.3-a15364c185df0a72d99440b2dcd210432b9da1d0.7081d79d1a21dc196c1286ea012b740d47d68e1e.el7.centos skopeo 1.14-7d786d11d668f2932e524da53afb658438c8ebfc.0aa48eb05ef9b646ac444ddc878eb93dbd3d6d98.el7.centos -> 1.14-66160a083bed5ec3b551eab62729c6ad5b0889aa.ec8b80abfd4d904e882bcdf340ee21a852e2f979.el7.centos Added: skopeo-containers-1.14-66160a083bed5ec3b551eab62729c6ad5b0889aa.ec8b80abfd4d904e882bcdf340ee21a852e2f979.el7.centos.x86_64 From walters@verbum.org Fri Oct 14 16:08:30 2016 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9EK8UZC005479 for ; Fri, 14 Oct 2016 16:08:30 -0400 Received: from mx1.redhat.com (ext-mx09.extmail.prod.ext.phx2.redhat.com [10.5.110.38]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9EK8URc026911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 14 Oct 2016 16:08:30 -0400 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A36BE4E4DE for ; Fri, 14 Oct 2016 20:08:29 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0192D20875 for ; Fri, 14 Oct 2016 16:08:29 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute1.internal (MEProxy); Fri, 14 Oct 2016 16:08:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=R+pGfcHumFTFDA0 +janjd0MkqS4=; b=oGKWYRka81hYnX0Sqhm0G0QwmaUv9TGs7S4xj2XkFgalh4X MKBMRxJGqTFgD9WzZdcMUpgXryMKlBWh4l8cJ+mq2G1BcROkH8wFsjPU0ZXfPWaO +s9sSGXcOsvz/CkpDIjgVsH318jzU5yfdxceVlp9WoTTvbG602JNAF//1Beo= Received: by mailuser.nyi.internal (Postfix, from userid 99) id D255ED0527; Fri, 14 Oct 2016 16:08:28 -0400 (EDT) Message-Id: <1476475708.3481679.756392945.34497A5C@webmail.messagingengine.com> X-Sasl-Enc: scM6pFsLPyEGe110Q9kiVnLGhLgbjXXD5qgcHl5vxN8k 1476475708 From: Colin Walters To: atomic-devel@projectatomic.io MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Date: Fri, 14 Oct 2016 16:08:28 -0400 In-Reply-To: <1f3c6f53-c371-4cd4-ea18-b18e7831c9b3@redhat.com> References: <1f3c6f53-c371-4cd4-ea18-b18e7831c9b3@redhat.com> X-Greylist: Sender IP whitelisted by DNSRBL, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 14 Oct 2016 20:08:29 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 14 Oct 2016 20:08:29 +0000 (UTC) for IP:'66.111.4.25' DOMAIN:'out1-smtp.messagingengine.com' HELO:'out1-smtp.messagingengine.com' FROM:'walters@verbum.org' RCPT:'' X-RedHat-Spam-Score: -0.32 (BAYES_50, DCC_REPUT_00_12, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL) 66.111.4.25 out1-smtp.messagingengine.com 66.111.4.25 out1-smtp.messagingengine.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.38 X-loop: atomic-devel@redhat.com Subject: Re: [atomic-devel] We are looking at using OSTree as a backend for sharing file systems into an OCID Container runtime X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 20:08:30 -0000 On Fri, Oct 14, 2016, at 02:37 PM, Daniel J Walsh wrote: > If we block the creation of the devices when exploding a OCI Image > Bundle, we end up with something that is different then what is > downloaded and this could potentially cause problems with mtree checking > of the image on disk versus the image as shipped. https://github.com/ostreedev/ostree/pull/443 would be a good place to discuss this. > Is there a reason OSTree does not work with Device Inodes? Yes, I think there's no good reason to include devices in OS or container images. For OS images (i.e. ostree-as-base), all modern systems use devtmpfs. (Also for that matter, a bit more strictly, FIFOs either. OSTree very intentionally only supports regular files and symlinks) For the Ubuntu Docker image, the user can't even see them because Docker (correctly) mounts over /dev/ with the "API devices" as systemd calls them. So basically...my proposal would be that we ignore them, and that's indeed what the proposed OSTree API above does. If we implement any other verification layer like mtree, it should then just skip devices and FIFOs (or more generally anything except regular files and symlinks). From podvody@redhat.com Mon Oct 17 09:18:32 2016 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9HDIW3E002482 for ; Mon, 17 Oct 2016 09:18:32 -0400 Received: from mx1.redhat.com (ext-mx01.extmail.prod.ext.phx2.redhat.com [10.5.110.25]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9HDIVNE027313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 17 Oct 2016 09:18:31 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DAA3F81F07 for ; Mon, 17 Oct 2016 13:18:31 +0000 (UTC) Received: from ovpn-204-79.brq.redhat.com (ovpn-204-79.brq.redhat.com [10.40.204.79]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9HDIURj027299 for ; Mon, 17 Oct 2016 09:18:31 -0400 Message-ID: <1476710302.7704.33.camel@redhat.com> From: Pavel Odvody To: "atomic-devel@projectatomic.io" Date: Mon, 17 Oct 2016 15:18:22 +0200 Organization: Red Hat Inc. Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-jgwdDbIqeCTPARXz3LD6" Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 17 Oct 2016 13:18:31 +0000 (UTC) X-loop: atomic-devel@redhat.com Subject: [atomic-devel] dnc: tool to capture traffic of docker containers X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 13:18:32 -0000 --=-jgwdDbIqeCTPARXz3LD6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, the other day I needed to tap into the network of a running container to see where it's trying to connect so I wrote this tool which uses tcpdump to capture all packets sent by the container (both loopback and bridge). Direct output to stdout is supported as well as JSON output format. https://github.com/shaded-enmity/docker-network-capture Cheers, Pavel --=20 Pavel Odvody Sr. Software Engineer - EMEA ENG Developer Experience 5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno --=-jgwdDbIqeCTPARXz3LD6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYBM+eAAoJEDr6OmYCT/aNVhgP+gM/VmrRK86eflFN0pl6LnI1 ipA1Q9UNA0SOS3RR6jd33fkbJKWNpj9O+cptHxNxl6iMusR5xWpPFQwxq9/QSffE z3SO8GW3WtqsR0lPNfBEJIBEwHsINwME1LT5gBRZQhFE/Ol52l3Oq+sp9bbJ2I0Z 8Fs+MSvqSiJHZUdtJ8axK7e3EIJyaym5zKIbeY4olbOP52Kp6WzCCPlRr0Q1Zc/l UOz7HMtX31Yl5SQ+ur/XU9W3kYj8A/1SQnes9XoVbvu53k6NX8OGsS6SugVmuEKw oZDYMZporc0hjaZi8VddRrGpmcgzDSEmYSNf0jcN6zZcF14ihloqrthg7HnJ64vM QDPQNUoiUfyFqzcJZ11SdxaHMGxBt5Wk6Ims+pDrmLvxJ/UkBpHz4dwOe7DPm7i4 S8ZXfH0gvpGR9YT08iNqPWJHsynFT7Vx1/nue97yAxp5M3d4x3sES0kdSuPZr3UF X6tuPGJ/zDQayeZ4BnrZ2TN4Noh+nlJbSBAkkn4ReaUmOKtx4snFMV1XNE23vI3T YPix7zXV9gCpEn0zDREPty3c6559FUg4LGOZr/anOWyRBxfoE3IozOIAKm3N5zGK 3jMuDwCHpoLd6vre0P3/a3ZyiqDG/ei//HmsrmSR6FJiMDRh0iQU7XdX75Cqs5C8 PlfGgAFba9fzcANj1iRP =AlAX -----END PGP SIGNATURE----- --=-jgwdDbIqeCTPARXz3LD6-- From jfilak@redhat.com Mon Oct 17 10:35:34 2016 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9HEZYtC009667 for ; Mon, 17 Oct 2016 10:35:34 -0400 Received: from mx1.redhat.com (ext-mx07.extmail.prod.ext.phx2.redhat.com [10.5.110.31]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9HEZY2Z020370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 17 Oct 2016 10:35:34 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B7C83C04B30E for ; Mon, 17 Oct 2016 14:35:34 +0000 (UTC) Received: from [10.34.24.187] (dhcp-24-187.brq.redhat.com [10.34.24.187]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9HEZWZZ020332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Oct 2016 10:35:34 -0400 To: Jeremy Eder , Derek Carr References: <18254173.h4fB0zpU25@astar> <3482719.FFtL0I6ara@astar>

From: Jakub Filak Organization: Red Hat Message-ID: Date: Mon, 17 Oct 2016 16:35:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 17 Oct 2016 14:35:34 +0000 (UTC) X-loop: atomic-devel@redhat.com Cc: atomic-devel Subject: Re: [atomic-devel] How to handle crashes X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 14:35:35 -0000 Creating ABRT image is definitely possible. ABRT provides an D-Bus API for accessing detected problems and it's possible to set up ABRT on nodes to report detected problems to a central ABRT daemon. The main difference between ABRT and node-problem-detector is that node-problem-detector is tuned for running on a node, so it is aware of stuff that ABRT does not know about. ABRT is tuned for detecting problems like core dumps, python exceptions, ruby exceptions, kernel oopses, MCEs etc. and bringing them to user's attention. ABRT cannot detect unresponsive programs yet. But if someone tell us how to do it or if we get a request to develop such a feature, we will do it. ABRT is easily extensible, so adding new types of detect problems is just a matter of finding a way how to detect them. Do you have any idea how to start? I played with docker and ABRT last year: https://github.com/abrt/docker-abrt And I've recently proved that we can use *nsenter* to run abrt's core_pattern helper from a docker image: https://github.com/abrt/abrt/wiki/ABRT-docker-image-experiments And we can report Python exceptions from containers to ABRT container: https://github.com/abrt/abrt/pull/1182 Regards, Jakub On 09/15/2016 02:28 AM, Jeremy Eder wrote: > Anyone know? There's a node-problem-detector proposed in Kubernetes but ... > abrt is far more comprehensive. > https://github.com/kubernetes/node-problem-detector > > The difference is that node-problem-detector has hooks to call back to the > kubernetes control plane to inform it that a node has problems. > We could create an abrt container that does the same for RH-based ecosystem. > > On Fri, Sep 9, 2016 at 11:21 AM, Jeremy Eder > wrote: > > Hmm, appears this was not integrated into Fedora Atomic? Is there a > plan to do so? > > On Fri, Mar 20, 2015 at 5:50 AM, Jakub Filak > wrote: > > __ > > Hello, > > > > I've been working on integration of ABRT with Project Atomic and, > today, my work landed in Fedora 22 [1]. > > > > To enable abrt core_dump helper on Atomic hosts, it is necessary to > install abrt-atomic package and enable abrt-coredump-helper service. > After doing so core dump files will be stored in sub-directories of > /var/tmp/abrt/. > > > > You can find more technical details here: > > https://github.com/abrt/abrt/wiki/Containers-and-chroots#abrt---project-atomic > > > > > > > Should I write a new proposal for the oversight repository or should > I just open a new pull request for fedora-atomic repository? > > > > > > > > Regards, > > Jakub > > > > > > 1: > https://admin.fedoraproject.org/updates/gnome-abrt-1.1.0-1.fc22,abrt-2.5.0-2.fc22,libreport-2.5.0-1.fc22 > > > > > > -- > > -- Jeremy Eder > > > > > -- > > -- Jeremy Eder From dwalsh@redhat.com Mon Oct 17 11:18:17 2016 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9HFIGvu014272 for ; Mon, 17 Oct 2016 11:18:17 -0400 Received: from mx1.redhat.com (ext-mx01.extmail.prod.ext.phx2.redhat.com [10.5.110.25]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9HFIGgm031594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 17 Oct 2016 11:18:16 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DA97F81255 for ; Mon, 17 Oct 2016 15:18:16 +0000 (UTC) Received: from dhcp-10-19-62-196.boston.devel.redhat.com (dhcp-25-17.bos.redhat.com [10.18.25.17]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9HFIGLc004053 for ; Mon, 17 Oct 2016 11:18:16 -0400 To: "atomic-devel@projectatomic.io" From: Daniel J Walsh Message-ID: <8390e05d-ce82-5e9c-7d74-12f2de2657bd@redhat.com> Date: Mon, 17 Oct 2016 11:18:16 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 17 Oct 2016 15:18:16 +0000 (UTC) X-loop: atomic-devel@redhat.com Subject: [atomic-devel] New blog on running containers with tightened capabilities X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 15:18:17 -0000 http://rhelblog.redhat.com/2016/10/17/secure-your-containers-with-this-one-weird-trick/ From dharmit@redhat.com Tue Oct 18 09:28:57 2016 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by lists04.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u9IDSvCd015161 for ; Tue, 18 Oct 2016 09:28:57 -0400 Received: from mx1.redhat.com (ext-mx04.extmail.prod.ext.phx2.redhat.com [10.5.110.28]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9IDSvKY013395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 18 Oct 2016 09:28:57 -0400 Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com [209.85.192.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F320285546 for ; Tue, 18 Oct 2016 13:28:56 +0000 (UTC) Received: by mail-pf0-f178.google.com with SMTP id 128so95315691pfz.0 for ; Tue, 18 Oct 2016 06:28:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=9FXBvtY9GalgN2wXl0qq2Wpy3DdY+3gfxVm9WasBR7I=; b=Aegqpn1800hW7MMcXxrsHdQY1hKKXWdOe+H9xQTUxuDCUqra/rC7oI+9ofDvPvJXvu 7VtQTBiUsa223o+LDlka76oa7vKcEq7NaeASiFoNL4de1OhLuBlJEdd59j0nvWaNMhJl cKxy/8avZATs6W9Ccsq1XjkuPfSg8JGI43BIBl70yVltdYOMT+xTD5sgxdROQDkPLYl8 AwXJFeeJiCgVu1dy/F2ME2KO2Bw2YUWw+zQeGsNKZvfcHxMuJO5Qa6228B0q+2bEQbux HBjGnfhuBjigxFCNZLkQWim9QbTSw23oOHyv6cJ86eHNexS9/OowfpKWBYBUIFiOuTPi MAVQ== X-Gm-Message-State: AA6/9Rl0nxDf8TLCVi3X2LjSgSTMX6HPGGJX0zc9z46A+6kK9wO/ZSQ39cymkZBcv1uS6e+W X-Received: by 10.98.147.78 with SMTP id b75mr675409pfe.167.1476797335927; Tue, 18 Oct 2016 06:28:55 -0700 (PDT) Received: from gmail.com ([103.21.161.96]) by smtp.gmail.com with ESMTPSA id ad15sm56370589pac.33.2016.10.18.06.28.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Oct 2016 06:28:54 -0700 (PDT) Date: Tue, 18 Oct 2016 18:58:43 +0530 From: Dharmit Shah To: atomic-devel@projectatomic.io Message-ID: <20161018132843.r24rzpxigm5oxwwv@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: NeoMutt/20161014 (1.7.1) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 18 Oct 2016 13:28:57 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 18 Oct 2016 13:28:57 +0000 (UTC) for IP:'209.85.192.178' DOMAIN:'mail-pf0-f178.google.com' HELO:'mail-pf0-f178.google.com' FROM:'dharmit@redhat.com' RCPT:'' X-RedHat-Spam-Score: 0.888 (BAYES_50, DCC_REPUT_00_12, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, RCVD_IN_SORBS_SPAM, SPF_PASS) 209.85.192.178 mail-pf0-f178.google.com 209.85.192.178 mail-pf0-f178.google.com X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Scanned-By: MIMEDefang 2.78 on 10.5.110.28 X-loop: atomic-devel@redhat.com Subject: [atomic-devel] Python interface for atomic scan X-BeenThere: atomic-devel@projectatomic.io X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development list for Project Atomic