Re: [atomic-devel] CentOS Atomic Host 7.1910 Available for Download

2019-11-25 Thread Scott McCarty 
All,
 Sorry about the crossed wires. I SWEAR I responded to the right thread
and GMail sent this on the next thread up (off by one errors?) :-)

On Fri, Nov 22, 2019 at 11:15 AM Scott McCarty  wrote:

> Katie,
> No worries. I am just nursing this along because it's on my list. I'm
> on PTO the week after Thanksgiving, so things will hopefully be slowing
> down.
>
> Best Regards
> Scott M
>
> On Thu, Nov 21, 2019 at 5:34 PM Jason Brooks  wrote:
>
>> The CentOS Atomic SIG has released an [updated
>> version](https://wiki.centos.org/SpecialInterestGroup/Atomic/Download)
>> of CentOS Atomic Host (7.1910), an operating system designed to run
>> Linux containers, built from standard CentOS 7 RPMs, and tracking the
>> component versions included in Red Hat Enterprise Linux Atomic Host.
>>
>> CentOS Atomic Host includes these core component versions:
>>
>> * atomic-1.22.1-29.gitb507039.el7.x86_64
>> * rpm-ostree-client-2018.5-2.atomic.el7.x86_64
>> * ostree-2019.1-2.el7.x86_64
>> * cloud-init-18.5-3.el7.centos.x86_64
>> * docker-1.13.1-103.git7f2769b.el7.centos.x86_64
>> * kernel-3.10.0-1062.4.3.el7.x86_64
>> * podman-1.4.4-4.el7.centos.x86_64
>> * flannel-0.7.1-4.el7.x86_64
>> * etcd-3.3.11-2.el7.centos.x86_64
>>
>> ## Download CentOS Atomic Host
>>
>> CentOS Atomic Host is available as a VirtualBox or libvirt-formatted
>> Vagrant box, or as an installable ISO, or qcow2 image. For links to
>> media, see the [CentOS
>> wiki](https://wiki.centos.org/SpecialInterestGroup/Atomic/Download).
>>
>> ## Upgrading
>>
>> If you're running a previous version of CentOS Atomic Host, you can
>> upgrade to the current image by running the following command:
>>
>> ```bash
>> # atomic host upgrade
>> ```
>>
>> ## Release Cycle
>>
>> The CentOS Atomic Host image follows the upstream Red Hat Enterprise
>> Linux Atomic Host cadence. After sources are released, they're rebuilt
>> and included in new images. After the images are tested by the SIG and
>> deemed ready, we announce them.
>>
>> ## Getting Involved
>>
>> CentOS Atomic Host is produced by the [CentOS Atomic
>> SIG](http://wiki.centos.org/SpecialInterestGroup/Atomic), based on
>> upstream work from  [Project Atomic](http://www.projectatomic.io/). If
>> you'd like to work on testing images, help with packaging,
>> documentation -- join us!
>>
>> You'll often find us in #atomic and/or #centos-devel if you have
>> questions. You can also join the
>> [atomic-devel](
>> https://lists.projectatomic.io/mailman/listinfo/atomic-devel)
>> mailing list if you'd like to discuss the direction of Project Atomic,
>> its components, or have other questions.
>>
>> ## Getting Help
>>
>> If you run into any problems with the images or components, feel free
>> to ask on the [centos-devel](
>> http://lists.centos.org/mailman/listinfo/centos-devel)
>> mailing list.
>>
>> Have questions about using Atomic? See the
>> [atomic](https://lists.projectatomic.io/mailman/listinfo/atomic)
>> mailing list or find us in the #atomic channel on Freenode.
>>
>>
>> --
>> Jason Brooks
>> Community Architects & Infrastructure
>> Red Hat Open Source Program Office (OSPO)
>> https://community.redhat.com | https://osci.io
>>
>>
>>
>
> --
>
> --
>
> Scott McCarty, RHCA
> Product Management - Containers, Red Hat Enterprise Linux & OpenShift
> Email: smcca...@redhat.com
> Phone: 312-660-3535
> Cell: 330-807-1043
> Web: http://crunchtools.com
>
> Deeply understand the different between Portability, Compatibility, and 
> Supportability with containers: http://bit.ly/2Qw3dJI
>
>

-- 

-- 

Scott McCarty, RHCA
Product Management - Containers, Red Hat Enterprise Linux & OpenShift
Email: smcca...@redhat.com
Phone: 312-660-3535
Cell: 330-807-1043
Web: http://crunchtools.com

Deeply understand the different between Portability, Compatibility,
and Supportability with containers: http://bit.ly/2Qw3dJI

Re: [atomic-devel] CentOS Atomic Host 7.1910 Available for Download

2019-11-22 Thread Scott McCarty 
Katie,
No worries. I am just nursing this along because it's on my list. I'm
on PTO the week after Thanksgiving, so things will hopefully be slowing
down.

Best Regards
Scott M

On Thu, Nov 21, 2019 at 5:34 PM Jason Brooks  wrote:

> The CentOS Atomic SIG has released an [updated
> version](https://wiki.centos.org/SpecialInterestGroup/Atomic/Download)
> of CentOS Atomic Host (7.1910), an operating system designed to run
> Linux containers, built from standard CentOS 7 RPMs, and tracking the
> component versions included in Red Hat Enterprise Linux Atomic Host.
>
> CentOS Atomic Host includes these core component versions:
>
> * atomic-1.22.1-29.gitb507039.el7.x86_64
> * rpm-ostree-client-2018.5-2.atomic.el7.x86_64
> * ostree-2019.1-2.el7.x86_64
> * cloud-init-18.5-3.el7.centos.x86_64
> * docker-1.13.1-103.git7f2769b.el7.centos.x86_64
> * kernel-3.10.0-1062.4.3.el7.x86_64
> * podman-1.4.4-4.el7.centos.x86_64
> * flannel-0.7.1-4.el7.x86_64
> * etcd-3.3.11-2.el7.centos.x86_64
>
> ## Download CentOS Atomic Host
>
> CentOS Atomic Host is available as a VirtualBox or libvirt-formatted
> Vagrant box, or as an installable ISO, or qcow2 image. For links to
> media, see the [CentOS
> wiki](https://wiki.centos.org/SpecialInterestGroup/Atomic/Download).
>
> ## Upgrading
>
> If you're running a previous version of CentOS Atomic Host, you can
> upgrade to the current image by running the following command:
>
> ```bash
> # atomic host upgrade
> ```
>
> ## Release Cycle
>
> The CentOS Atomic Host image follows the upstream Red Hat Enterprise
> Linux Atomic Host cadence. After sources are released, they're rebuilt
> and included in new images. After the images are tested by the SIG and
> deemed ready, we announce them.
>
> ## Getting Involved
>
> CentOS Atomic Host is produced by the [CentOS Atomic
> SIG](http://wiki.centos.org/SpecialInterestGroup/Atomic), based on
> upstream work from  [Project Atomic](http://www.projectatomic.io/). If
> you'd like to work on testing images, help with packaging,
> documentation -- join us!
>
> You'll often find us in #atomic and/or #centos-devel if you have
> questions. You can also join the
> [atomic-devel](
> https://lists.projectatomic.io/mailman/listinfo/atomic-devel)
> mailing list if you'd like to discuss the direction of Project Atomic,
> its components, or have other questions.
>
> ## Getting Help
>
> If you run into any problems with the images or components, feel free
> to ask on the [centos-devel](
> http://lists.centos.org/mailman/listinfo/centos-devel)
> mailing list.
>
> Have questions about using Atomic? See the
> [atomic](https://lists.projectatomic.io/mailman/listinfo/atomic)
> mailing list or find us in the #atomic channel on Freenode.
>
>
> --
> Jason Brooks
> Community Architects & Infrastructure
> Red Hat Open Source Program Office (OSPO)
> https://community.redhat.com | https://osci.io
>
>
>

-- 

-- 

Scott McCarty, RHCA
Product Management - Containers, Red Hat Enterprise Linux & OpenShift
Email: smcca...@redhat.com
Phone: 312-660-3535
Cell: 330-807-1043
Web: http://crunchtools.com

Deeply understand the different between Portability, Compatibility,
and Supportability with containers: http://bit.ly/2Qw3dJI

Re: [atomic-devel] Getting to full deprecation of the projectatomic/ Github organization

2019-10-01 Thread Scott McCarty 
>
> > so my question is short:
> >
> > - is there any high level overview of a private containerized system
> > using rh's tool in the next few year?
> > - is there any plan about it?
> > - is it public? can someone share it with us?
> > - is there any roadmap, priorities?
> > - can someone tell me or much better to everybody a plan/roadmap about
> > coreos?
> > - about okd?
> > - about podman, buildah etc
> >
> > and not to mention which is the right forum to discuss such thing???
> >
> > thanks in advance.
> >
> > On 9/27/19 7:20 PM, Colin Walters wrote:
> >> bubblewrap moved: https://github.com/containers/bubblewrap
> >> rpm-ostree moved: https://github.com/coreos/rpm-ostree
> >>
> >> Of the things remaining...probably the biggest is our docker branch:
> >> https://github.com/projectatomic/docker
> >> I feel like it'd be cleanest if we created a new org for this
> >> stuff...queue naming bikeshed, I know.
> >>
> >> There's also:
> >> https://github.com/projectatomic/ContainerApplicationGenericLabels -
> >> did we ever standardize that stuff elsewhere?
> >>
> >> I think if we got those bits done we could probably mass-archive the
> >> remaining repos.
> >>
> >
> >
>
>
>

-- 

-- 

Scott McCarty, RHCA
Product Management - Containers, Red Hat Enterprise Linux & OpenShift
Email: smcca...@redhat.com
Phone: 312-660-3535
Cell: 330-807-1043
Web: http://crunchtools.com

Have questions on Red Hat UBI? Check out the official FAQ:
https://red.ht/2yaUcez

Re: [atomic-devel] moby-engine for centos/epel

2019-05-06 Thread Scott McCarty 
Neal,
Yeah, we will not port to RHEL (no ans at all), but to get moby-engine
working on CentOS should be just stealing the Fedora spec file and doing a
little work...

On Mon, May 6, 2019, 10:57 AM Neal Gompa  wrote:

> On Mon, May 6, 2019 at 4:52 AM Scott McCarty  wrote:
> >
> > Muayyad & Neal,
> > That makes perfect sense. Thank you for the feedback. It might sound
> crazy but I am keeping a list of every use case I can find and tracking our
> progress with podman.
> >
> > All of these use cases make sense (and I plan on tracking them in my
> list when I get back to a computer). If I were to surmise, it sounds like
> many people need some time to migrate certain use cases which have Docker
> specific requirements. Hence, having the option of moby-engine around would
> make that more convenient.
> >
> > Sounds like there are two short term goals:
> >
> > 1. Update podman in CentOS. I have to dig into this to see if it is
> tracking g the version in RHEL properly.
> > 2. Add moby-engine to CentOS. This one might be interesting for for the
> same reason, but admittedly it would be hard for me to push to dedicate Red
> Hat people's time to package it. We would love a volunteer ;-)
> >
> > So much work and so little time. I wish I could just knock out all of
> these use cases out on a weekend, but a 19 month old has put a dent in my
> free time :-)
> >
>
> The old patches for making docker work with RHEL entitlements would
> need to be ported, though.
>
> SUSE has a variation of these patches for their docker package[1],
> maybe these could help with moby-engine?
>
> [1]:
> https://build.opensuse.org/package/show/Virtualization:containers/docker
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>

Re: [atomic-devel] moby-engine for centos/epel

2019-05-06 Thread Scott McCarty 
Muayyad & Neal,
That makes perfect sense. Thank you for the feedback. It might sound
crazy but I am keeping a list of every use case I can find and tracking our
progress with podman.

All of these use cases make sense (and I plan on tracking them in my list
when I get back to a computer). If I were to surmise, it sounds like many
people need some time to migrate certain use cases which have Docker
specific requirements. Hence, having the option of moby-engine around would
make that more convenient.

Sounds like there are two short term goals:

1. Update podman in CentOS. I have to dig into this to see if it is
tracking g the version in RHEL properly.
2. Add moby-engine to CentOS. This one might be interesting for for the
same reason, but admittedly it would be hard for me to push to dedicate Red
Hat people's time to package it. We would love a volunteer ;-)

So much work and so little time. I wish I could just knock out all of these
use cases out on a weekend, but a 19 month old has put a dent in my free
time :-)

Best Regards
Scott M

On Mon, May 6, 2019, 2:17 AM Neal Gompa  wrote:

> On Sun, May 5, 2019 at 6:39 PM Muayyad AlSadi  wrote:
> >
> > > Is there some particular reason why you still want/need the Moby
> Engine package?
> >
> > no, I just want to have that option (even if in a non default repo) for
> convenient and easy migration and switch between old scripts/ansible
> playbooks, new fedora ...etc..
> >
> >
>
> At least for me, the main reason for moby-engine is that the GitLab CI
> Runner requires it. No one has contributed a port of the container
> runner executor to use Podman, so it requires Docker. It uses the
> Docker Engine API, so it can't be trivially replaced by the
> "podman-docker" package either.
>
> Without the enhancements to the Docker package though (that is,
> vanilla moby-engine), GitLab CI can't use RHEL environments without
> some manual work in the middle. :(
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>

Re: [atomic-devel] moby-engine for centos/epel

2019-05-05 Thread Scott McCarty 
Muayyad,
Was there a specific use case that Podman was not meeting? Is there
some particular reason why you still want/need the Moby Engine package?

Best Regards
Scott M

On Sun, May 5, 2019 at 8:30 AM Muayyad AlSadi  wrote:

> > BTW Have you tried out Podman
>
> of course, Podman is an awesome peice of software
> BTW: I'm the author of podman-compose and I'm writing an article about
> buildah for fedora magazine
>
> > I think this is up to a volunteer to take it on.
>
> centos ships too old docker I'm not sure about compatibility
> maybe we should ship moby-engine in a different repo just like we used to
> do with docker and docker-latest
>
> https://access.redhat.com/articles/2317361
>
>
>
> On Sun, May 5, 2019 at 2:34 PM Daniel Walsh  wrote:
>
>> On 5/5/19 4:33 AM, Muayyad AlSadi wrote:
>> > Hi,
>> >
>> > it seems that fedora had shipped moby-engine,
>> > when can we ship it for centos/epel?
>> >
>> > if not in epel,link for that repo?
>>
>> I think this is up to a volunteer to take it on.
>>
>>
>> BTW Have you tried out Podman
>>
>>

-- 

-- 
Scott McCarty, RHCA
Product Management - Containers, Red Hat Enterprise Linux & OpenShift
Email: smcca...@redhat.com
Phone: 312-660-3535
Cell: 330-807-1043
Web: http://crunchtools.com

Do Linux Distributions Still Matter with Containers? https://red.ht/2FgQTqq

Re: [atomic-devel] recommended way of running a container

2019-05-03 Thread Scott McCarty 
I assume by "atomic host" you mean a standalone, non-clustered, aka
non-Kubernetes environment?

On Thu, May 2, 2019, 4:12 PM Farkas Levente  wrote:

> Hi,
> I'm just read the blog about healthchecks:
>
>
> https://developers.redhat.com/blog/2019/04/18/monitoring-container-vitality-and-availability-with-podman/
>
> What is the current recommended way of running a container on an atomic
> host using podman? Assume I'd not like to use docker.
> As I understand it now:
> - Create a systemd service file on the host for the container,
> - Create a systemd service file on the host for the healthcheck,
> - Create a systemd timer  file on the host for the healthcheck.
>
> Who should have to restart the container? ie. on the container's service
> file what is the Restart line and the Type?
>
> Is there any recommended template for this?
>
> Yes I know there are several ways to do it in container systemd, on host
> systemd manual healthcheck etc. But IMHO it'd be useful for everybody do
> give a recommended way or template which is in your planed future way of
> doing so. AFAIS (after read it) RHEL official container docs is a bit
> outdated.
>
> Thanks in advance.
>
> --
>   Levente   "Si vis pacem para bellum!"
>
>

Re: [atomic-devel] Install CRI-O on Atomic Host

2019-01-29 Thread Scott McCarty 
Chris/Derrick,
Have either of you ran into this?

Best Regards
Scott M

On Fri, Jan 25, 2019 at 12:56 PM mabi  wrote:

> Hello,
>
> I would like to use CRI-O (https://cri-o.io/) on CentOS Atomic Host along
> with or instead of Docker but it looks like there are no cri-o packages for
> Atomic Host:
>
> # rpm-ostree install cri-o
> Checking out tree 4b20905... done
> Enabled rpm-md repositories: base updates extras
> rpm-md repo 'base' (cached); generated: 2018-11-25 16:00:34
> rpm-md repo 'updates' (cached); generated: 2019-01-24 13:56:44
> rpm-md repo 'extras' (cached); generated: 2018-12-10 16:00:03
> Importing metadata [=] 100%
> error: No package matches 'cri-o'
>
> Is there any other ways I can get CRI-O running on Atomic Host? and/or is
> it planned to be also available on Atomic Hosting in the near future?
>
> Regards,
> Mabi
>
>
>
>
>
>
>

-- 

-- 
Scott McCarty, RHCA
Product Management - Containers, Red Hat Enterprise Linux & OpenShift
Email: smcca...@redhat.com
Phone: 312-660-3535
Cell: 330-807-1043
Web: http://crunchtools.com

Learning Container Engines by Demo: https://goo.gl/zMrLqR

Re: [atomic-devel] Atomic as Base OS for Standalone Appliance

2018-05-30 Thread Scott McCarty 




On 05/26/2018 06:50 PM, Dusty Mabe wrote:


On 05/25/2018 04:34 PM, Scott McCarty wrote:

Shane,

      I see nobody has responded. To be honest, I read your email three
times, and I can't quite figure out your use case. I am guessing others
may be heads down working on the new Red Hat CoreOS and hence haven't
had time to dig into this.

*cough*
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2018-May/msg00038.html
*cough*
My apologies, I just had this sitting in my inbox forever and didn't see 
a response. I get that subconscious stressful feeling when I know there 
are unanswered questions on a mailing anywhere the Internet ;-)


:)


I will be down in Raleigh on the afternoon/evening of June 5th and would
love to meet up and chat. Happy to meet up late afternoon, or early
evening. If you are around feel free to respond to me off list.

Let me know if you guys schedule something.


--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? 
http://red.ht/22xKw9i

Re: [atomic-devel] Additional Discussion about the Future of Atomic Host + Container Linux

2018-05-16 Thread Scott McCarty 
Really interesting thread. Thanks for sharing. I was SO overwhelmed last 
week that I didn't even have a chance to respond, and I never would have 
caught this thread. I just chimed in on a few points, and I am 
definitely capturing feedback from this thread as potential 
features/roadmap items, etc.



Best Regards
Scott M


On 05/10/2018 03:32 PM, Sanja Bonic wrote:
Thanks, Micah. This HN thread has been circulating today and I was 
wondering whether we should retweet and encourage it - so yeah, let's 
do it. Since the legally approved press release didn't give us much of 
a way to talk shop, the HN thread is out and helpful for once.


We'll have to see what's next and hope we have a solution or way 
forward for upstream soon.


Have a good weekend everyone!

On Thu, May 10, 2018 at 4:20 PM, Micah Abbott <miabb...@redhat.com 
<mailto:miabb...@redhat.com>> wrote:


Many of you probably saw the recent press release or related news
about the future of Atomic Host + Container Linux.


https://www.redhat.com/en/about/press-releases/red-hat-unveils-roadmap-coreos-integration-red-hat-openshift

<https://www.redhat.com/en/about/press-releases/red-hat-unveils-roadmap-coreos-integration-red-hat-openshift>

As press releases go, it had plenty of buzzwords but was also
partly ambiguous. So it is not a surprise that you might have
additional questions.

While I don't have all (or any?) of the answers, the press release
was picked up by Hacker News and there has been good discussion
going on in the thread with members of CoreOS, Fedora, and Red Hat.

https://news.ycombinator.com/item?id=17027097
<https://news.ycombinator.com/item?id=17027097>

I'd encourage you to read through the thread and see if some (or
all) of your questions are addressed there.

    Thanks!




--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? 
http://red.ht/22xKw9i

Re: [atomic-devel] Kubernetes manual setup (need reviewers)

2018-03-15 Thread Scott McCarty 
Yup, the plan is to publish next week, just waiting for final comments 
(I gave a two week period). Basically, it's a one way process moving 
from Google docs to Wordpress, so I like to get comments before I move, 
tweak assets/images/links, and publish.



Best Regards

Scott M


On 03/15/2018 10:58 AM, Chris Negus wrote:

Hey Scott,

Are there plans to make that public? I don't want to just repeat the work you 
are doing there, but I would be happy to refer to it.

Also, you make a good point about showcasing other tools like skopeo, buildah, 
and podman. Since we have packages for them in Fedora, I'll suggest trying them 
out as well.

-- Chris


- Original Message -

Chris,

      Just a heads up, there is also an RPM for Origin on Fedora. In
fact, IMHO, it is the easiest way to get a long term "test environment"
up and running per this [1]. That article even explains how to get DNS
working similar to an OCP install which makes it really convenient for
somebody that doesn't have time to hassle around.

The problem with oc cluster up and all of the others is no working DNS,
and no start on boot...


[1]:
https://docs.google.com/document/d/1VgWYq4RGeWU9eOpiOv9fbTdWB6pFpFlycKJJKTLoo2Y/edit#heading=h.d359y1uuq93r


On 03/14/2018 03:17 PM, Chris Negus wrote:

- Original Message -

Make it public?

Here is a public link:

 
https://docs.google.com/a/redhat.com/document/d/e/2PACX-1vRJaraa244HAGZIn5xCPSYU85hzFVWRO0II4qAAT1YwBl3vCRA707vfxu5wMJBqVgBVxC2svwX2Xndv/pub

-- Chris Negus
   

On Wed, Mar 14, 2018, 8:29 PM Chris Negus <cne...@redhat.com> wrote:


I have a draft of a write-up for running Kubernetes on Fedora or Fedora
Atomic, using kubeadm, that I'd like to submit to upstream Kubernetes. I
would appreciate people reviewing the document and trying the procedure.

Before publishing, I have a few issues that I need to get through (listed
at the top of the document). Any feedback (especially help with those
issues) would be appreciated:


https://docs.google.com/document/d/1s9yUkC4nj3V0CCWV18PYimIIwBBB1OGxpuMmyinA62Y/edit#

-- Chris Negus


- Original Message -

On 02/23/2018 10:43 AM, Matthew Miller wrote:

On Fri, Feb 23, 2018 at 10:16:46AM -0800, Jason Brooks wrote:

If we have a preferred non-manual way, we should encourage people to
use that, but I don't see what we lose from having good documentation
at a lower level too.

That's totally awesome. Now someone needs to do that work. In the
absence of that person, it's not dismissive to link them to a popular
resource for manual installation.

Of course -- but what I mean is saying "You wanted to know how to do
Kubernetes on Fedora Atomic Host? Go do Kubernetes the hard way!"
doesn't come off as very friendly to someone who doesn't know that
"Learn  the hard way!" is a somewhat tongue-in-cheek meme. If
that's the best resource and we recommend it, let's recommend it with a
preface.

Oh, I was planning to recommend Kubeadm.  Kubeadm is good enough for
most users, these days, and it's actually a good way to test new
Kubernetes releases.  And the Kubeadm team is enthusiastic enough to
maybe offer us some help.

My primary concern with making sure that Kube is available on FAH/CAH is
that I want Kubernetes developers regarding AH as a reasonable target
platform for development.  We also want to make sure not to abandon our
existing AH+Kube users, but presumably installation docs are not the
primary thing those users need.

I wouldn't *mind* having a "the hard way" doc for FAH/CAH, but I can't
commit to putting in the time it would require to write it, since I'm
not sure who the target user for it is.  Someone who wants something
"production" is going to install Origin, no?

--
--
Josh Berkus
Kubernetes Community
Red Hat OSAS



--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers?
http://red.ht/22xKw9i




--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? 
http://red.ht/22xKw9i

Re: [atomic-devel] Kubernetes manual setup (need reviewers)

2018-03-15 Thread Scott McCarty 

Chris,

    Just a heads up, there is also an RPM for Origin on Fedora. In 
fact, IMHO, it is the easiest way to get a long term "test environment" 
up and running per this [1]. That article even explains how to get DNS 
working similar to an OCP install which makes it really convenient for 
somebody that doesn't have time to hassle around.


The problem with oc cluster up and all of the others is no working DNS, 
and no start on boot...



[1]: 
https://docs.google.com/document/d/1VgWYq4RGeWU9eOpiOv9fbTdWB6pFpFlycKJJKTLoo2Y/edit#heading=h.d359y1uuq93r



On 03/14/2018 03:17 PM, Chris Negus wrote:

- Original Message -

Make it public?

Here is a public link:


https://docs.google.com/a/redhat.com/document/d/e/2PACX-1vRJaraa244HAGZIn5xCPSYU85hzFVWRO0II4qAAT1YwBl3vCRA707vfxu5wMJBqVgBVxC2svwX2Xndv/pub

-- Chris Negus
  

On Wed, Mar 14, 2018, 8:29 PM Chris Negus <cne...@redhat.com> wrote:


I have a draft of a write-up for running Kubernetes on Fedora or Fedora
Atomic, using kubeadm, that I'd like to submit to upstream Kubernetes. I
would appreciate people reviewing the document and trying the procedure.

Before publishing, I have a few issues that I need to get through (listed
at the top of the document). Any feedback (especially help with those
issues) would be appreciated:


https://docs.google.com/document/d/1s9yUkC4nj3V0CCWV18PYimIIwBBB1OGxpuMmyinA62Y/edit#

-- Chris Negus


- Original Message -

On 02/23/2018 10:43 AM, Matthew Miller wrote:

On Fri, Feb 23, 2018 at 10:16:46AM -0800, Jason Brooks wrote:

If we have a preferred non-manual way, we should encourage people to
use that, but I don't see what we lose from having good documentation
at a lower level too.

That's totally awesome. Now someone needs to do that work. In the
absence of that person, it's not dismissive to link them to a popular
resource for manual installation.

Of course -- but what I mean is saying "You wanted to know how to do
Kubernetes on Fedora Atomic Host? Go do Kubernetes the hard way!"
doesn't come off as very friendly to someone who doesn't know that
"Learn  the hard way!" is a somewhat tongue-in-cheek meme. If
that's the best resource and we recommend it, let's recommend it with a
preface.

Oh, I was planning to recommend Kubeadm.  Kubeadm is good enough for
most users, these days, and it's actually a good way to test new
Kubernetes releases.  And the Kubeadm team is enthusiastic enough to
maybe offer us some help.

My primary concern with making sure that Kube is available on FAH/CAH is
that I want Kubernetes developers regarding AH as a reasonable target
platform for development.  We also want to make sure not to abandon our
existing AH+Kube users, but presumably installation docs are not the
primary thing those users need.

I wouldn't *mind* having a "the hard way" doc for FAH/CAH, but I can't
commit to putting in the time it would require to write it, since I'm
not sure who the target user for it is.  Someone who wants something
"production" is going to install Origin, no?

--
--
Josh Berkus
Kubernetes Community
Red Hat OSAS






--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? 
http://red.ht/22xKw9i

Re: [atomic-devel] DevConf Project Atomic BOF - giving a 2 minutes presentation?

2017-12-21 Thread Scott McCarty 

I want to go to ALL OF THESE :-)


On 12/21/2017 02:44 PM, Sanja Bonic wrote:

Hi everyone,

As some of you already know, I'm the new community manager for Project 
Atomic and we're going to have a BOF and Retrospective session at 
DevConf that Josh took care of so far. As he is now the Kubernetes 
Community Manager, we did a handover for everything Project Atomic.


For those of you going to DevConf, we would like a 2 minute briefing 
on the status and plans of each of the following projects:


* Fedora Atomic Host
* CentOS Atomic Host
* Fedora Atomic Workstation
* FLIBS
* CentOS Container Pipeline
* Buildah
* Skopeo
* Documentation
* Cockpit
* other Atomic-related projects

If you're interested in presenting any of these, please let me know by 
January 12. Also, please forward this email to other contributors who 
you think might be interested.


Thank you and happy holidays,
Sanja


--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? 
http://red.ht/22xKw9i

Re: [atomic-devel] Who got accepted to Kubecon?

2017-09-29 Thread Scott McCarty 
My talks got rejected, but I believe my team has a ticket for me from 
Jen



Best Regards

Scott M


On 09/28/2017 10:29 AM, Josh Berkus wrote:

Folks:

- who got a talk accepted to KubeCon US?
- who didn't get a talk accepted but wants to go anyway?

Let me know, I need to figure out passes for the conference.



--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? 
http://red.ht/22xKw9i

Re: [atomic-devel] Need Advice: Container Internals Lab

2017-05-15 Thread Scott McCarty 



On 05/15/2017 09:06 AM, Dusty Mabe wrote:


On 05/15/2017 08:59 AM, Scott McCarty wrote:


On 05/15/2017 08:28 AM, Dusty Mabe wrote:

I would encourage you to make this image "timeless". For the lab we did at
summit someone could theoretically download the qcow2 years from now and still
run through the entire lab. We baked all of the container images we needed as
well as all rpms we needed for 'builds' into the image and also tested it
completely offline.

Yeah, I really, really like this idea. I need to figure out how to get
the RPMs baked in. I am quickly realizing that I need to have a Red Hat
downstream version of this lab and an upstream version because the RPMs
for the rhel-tools image aren't redistribute-able :-( without breaking
the RHEL legal rules.

What did you use to cache the RPMs? Some kind of proxy?

I initially set up a squid proxy and ran through the entire lab with the
container builds pointing to the squid proxy. Then I just used the logs
from the squid proxy to grab the NVRA of the rpms we needed and then used
yumdownloader (or dnf download in your case) to get them.

I wouldn't bother trying to pull the actual rpms out of the squid proxy
cache. It's in some format that is optimized for fast access and not trivial
to get the actual files back out of it.


Intteresting. I I am thinking maybe, I would just leave squid running on 
Atomic Host :-) I have automated builds in OpenShift happening, so there 
is no easy way to bind mount the RPMs in to the containers at build 
(that I know of).


How did you configure the proxy in the containers? Just drop in a 
yum.repos file?



Also 'virt-sparsify --compress' is your friend.




[1]: https://github.com/fatherlinux/container-internals-lab


Best Regards
Scott M




--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? 
http://red.ht/22xKw9i

Re: [atomic-devel] Need Advice: Container Internals Lab

2017-05-15 Thread Scott McCarty 



On 05/15/2017 08:28 AM, Dusty Mabe wrote:


On 05/15/2017 07:55 AM, Scott McCarty wrote:

All,

  So, I need some advice. I know that everybody has an opinion on
this kind of thing, but I really do need some ideas. I am working on
building some kind of environment that people can download to run the
Linux Container Internals lab [1] which I built for Red Hat Summit.
There was tremendous demand to get in and I believe it would make sense
to create a Fedora/OpenShift Origin all in one to download and run
through the lab.


My assumptions are:

1. The CDK 3 Beta doesn't have enough disk space and also requires
vagrant or some other madness which many may not be comfortable with

CDK 3 (based on minishift) does not need vagrant, but i'm not sure it fits
your needs either.
This did cross my mind, but I played with it before Summit, and it's 
just not ready yet. It's too small by default which means chaos having 
users resize it (if that is even possible). I instantly rejected it as 
hacky to have the user work on the environment. Also, baking in RPMs, 
etc as per below, will be tougher...



2. I need about 12 GB of data for the JBoss images and rhel-tools container
3. I am apprehensive to pull down official RHEL images and run them on
Fedora, but not sure what to do for an upstream version. I feel like it
needs to be low barrier to get started

No upstream versions exist?
I am going to research the java images and see if they can meet my 
needs. I can definitely use the Fedora Tools container image...



4. The lab material really requires the use of Atomic Host (i.e. all
containers), Docker and OpenShift.


My question is:

1. Should I build an all-in-one Fedora/Origin VM in Qcow2 format that
users can download?

Probably the best approach.


2. Can I redistribute a Fedora/Origin image

I don't know if there are any legal implications here. Might be better able to
do it if you don't give it a name with "Fedora" in it, but rather a name like
'container_internals_lab.qcow2' and then describe it as based on Fedora.


3. Where would be a good place to distribute this? Dropbox?

I would put it in s3 and share the URL. Pretty much the same as Dropbox I guess.

I would encourage you to make this image "timeless". For the lab we did at
summit someone could theoretically download the qcow2 years from now and still
run through the entire lab. We baked all of the container images we needed as
well as all rpms we needed for 'builds' into the image and also tested it
completely offline.
Yeah, I really, really like this idea. I need to figure out how to get 
the RPMs baked in. I am quickly realizing that I need to have a Red Hat 
downstream version of this lab and an upstream version because the RPMs 
for the rhel-tools image aren't redistribute-able :-( without breaking 
the RHEL legal rules.


What did you use to cache the RPMs? Some kind of proxy?


Also 'virt-sparsify --compress' is your friend.




[1]: https://github.com/fatherlinux/container-internals-lab


Best Regards
Scott M




--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? 
http://red.ht/22xKw9i

[atomic-devel] Fwd: Devops Weekly #324

2017-04-03 Thread Scott McCarty 

Interesting. Targeting this use case without the docker daemon could be tricky 
right?

Tools
=

Ctop is a top-like interface for container metrics, connecting to a Docker 
socket and presenting information about container memory, CPU and network usage.

https://bcicen.github.io/ctop/
https://github.com/bcicen/ctop



 Forwarded Message 
Subject:Devops Weekly #324
Date:   Sun, 12 Mar 2017 10:17:59 +
From:   Devops Weekly 
Reply-To:   us2-33741cb112-ca6abee...@conversation01.mailchimpapp.com
To: scott.mcca...@gmail.com



DEVOPS WEEKLY
ISSUE #324 - 12th March 2017

A bit of a theme around the use of cloud infrastructure this week, with several 
opinions on design considerations in light of outages, the use of serverless 
for common cron-based tasks and other pitfalls and practicalities, from 
monitoring to secrets.


Sponsor
==

Free Incident Management Maturity Assessment. Learn how your team ranks against 
leading DevOps practices and get helpful tips on how to improve.

http://try.victorops.com/ima/devopsweekly


Sponsored


Practical Tips for Ops: End User Monitoring [Part 3: DevOps Journey Series]

When measuring DevOps success, it’s not just about feature delivery speed, but 
how end users respond to your innovation. Join us March 23rd for part 3 of our 
DevOps Journey Series where you’ll get practical tips for end user monitoring 
that you can implement quickly.

http://ow.ly/Ug4A309wkmC


News


A useful set of posts on cloud security best practices, including how to keep 
secrets out of your code repositories using tools like truffleHog, git-secrets 
and git-crypt.

https://blog.threatstack.com/cloud-security-best-practicesfinding-securing-managing-secrets-part-1
https://blog.threatstack.com/cloud-security-best-practices-finding-securing-managing-secrets-part-2


Understanding how technical decisions are made is interesting, especially when 
those decisions are on lots of people's minds. This post covers in detail the 
rationale for staying in a cloud environment rather than switching to physical 
infrastructure.

https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-the-cloud/


Interesting research into why two common syscalls on EC2 are 77% slower.

https://blog.packagecloud.io/eng/2017/03/08/system-calls-are-much-slower-on-ec2/


A nice counter to some of the talk of cloud strategy after the S3 outage, and 
some good points on SLAs.

https://medium.com/@ben11kehoe/yes-s3-was-down-for-hours-dont-make-expensive-decisions-because-of-it-27d45d0a8eb1#.m7nntl1lk


Google Cloud is definitely picking up new features and increased interest. 
These posts cover how best to monitor the various series and moving parts in 
GCE.

https://www.datadoghq.com/blog/monitoring-google-compute-engine-performance/
https://www.datadoghq.com/blog/how-to-collect-gce-metrics/


A good post on a trend towards using serverless environments like AWS Lambda 
for recurring operations scripts which might previously have used arbitrary 
server instances, cron and the like.

https://redmonk.com/fryan/2017/03/02/serverless-redefining-devops/


A good post on creating a complete WIndows environment in AWS with Terraform.

http://eng
ineering.rallyhealth.com//jekyll/update/2017/02/15/immutable-infrastructure-w-terraform-and-windows.html


CNCF


KubeCon / CloudNativeCon 17 - Join leading Kubernetes and Cloud Native 
technologists in Berlin for a full range of technology sessions on the cloud 
native ecosystem. Almost sold out, register below.

https://goo.gl/hjfE4g


An introduction to Linkerd with William Morgan of buoyant.io

Linkerd is the latest hosted project to join the CNCF alongside Kubernetes, 
Prometheus, OpenTracing and Fluentd. Linkerd is an open source, resilient 
service mesh for cloud-native applications. Used by companies like Twitter, 
Soundcloud, Pinterest and ING. Linkerd brings scalable, production-tested 
reliability to cloud-native applications in the form of a service mesh, a 
dedicated infrastructure layer for service communication that adds resilience, 
visibility and control to applications without requiring complex application 
integration.

https://goo.gl/z7GM0n


Jobs


The Best DevOps Jobs in the World, (all in one place)

http://hrd.cm/2jHrf1B


Tools
=

Ctop is a top-like interface for container metrics, connecting to a Docker 
socket and presenting information about container memory, CPU and network usage.

https://bcicen.github.io/ctop/
https://github.com/bcicen/ctop


Kubecfg is a tool for managing complex Kubernetes configurations, by providing 
a nice wrapper around jsonnet templates.

https://github.com/anguslees/kubecfg



Free Incident Management Maturity Assessment. Learn how your team ranks against 
leading DevOps practices and get helpful tips on how to improve.

http://try.victorops.com/ima/devopsweekly


If you received this email directly then you're already signed up, thanks! If 
however

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

2017-03-06 Thread Scott McCarty 



On 03/06/2017 10:02 PM, Clayton Coleman wrote:
Dumb-init is more like nohup, or tee, or strace. It's for processes 
(most of them) that don't deal with being PID 1.  So jumping through 
hoops to write a unit file feels like you're saying "do it the hard 
way" when I know perfectly well that I don't need to do it the hard way.

I get it.


On Mon, Mar 6, 2017 at 10:00 PM, Clayton Coleman <ccole...@redhat.com 
<mailto:ccole...@redhat.com>> wrote:


Please do not tell me that I want to write a unit file when the
*entire* ecosystem takes command lines just fine.  I have hundreds
of dockerfiles that have entry points - why do I need to write
unit files for them?  I have command line tools that generate
docker images... with command lines - why would I want to write
unit files for them?

Also, dumb-init is not an init system.  It's a signal proxy.


On Mon, Mar 6, 2017 at 9:55 PM, Scott McCarty <smcca...@redhat.com
<mailto:smcca...@redhat.com>> wrote:

I am skeptical of any "resource" argument against systemd. Are
you seeing some actually impact to performance that is causing
problems? As for unit files, they are rediculously easy. Much
easier than figuring out how to start a daemon properly by
reading documentation.

I don't have a strong opinion for CentOS/Fedora. But for RHEL,
I think multiple init systems will just generate more
technical questions from customers and eat up more sales
resources explaining when people should use what. Options are
great, but confusing, that's why Apple got rid of a lot of them...


On 03/06/2017 09:48 PM, Clayton Coleman wrote:

Zero overhead, defunct process management, proper logging,
simplicity, no moving parts, no additional unit file (I
don't have unit files).

Turn it around - if I have the command line
"ansible-playbook ...", what does systemd get me?

On Mon, Mar 6, 2017 at 9:35 PM, Eric Paris
<epa...@redhat.com <mailto:epa...@redhat.com>
<mailto:epa...@redhat.com <mailto:epa...@redhat.com>>> wrote:

On Mon, 2017-03-06 at 21:22 -0500, Clayton Coleman wrote:
> They'd be really helpful for cases where you don't
want full blown
> systemd, but want a long running container that
needs to reap
> processes.  I don't know that one or the other
matters, I have a
> slight bias for dumb-init in terms of signal
rewriting (a few cases
> might need that).
>
> Anyone using these today?

    What does dumb-init or tini get me that systemd doesn't?



-- 


Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com <mailto:smcca...@redhat.com>

Phone: 312-660-3535 

Cell: 330-807-1043 

Web: http://crunchtools.com

    When should you split your application into multiple
containers? http://red.ht/22xKw9i





--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? 
http://red.ht/22xKw9i

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

2017-03-06 Thread Scott McCarty 



On 03/06/2017 10:00 PM, Clayton Coleman wrote:
Please do not tell me that I want to write a unit file when the 
*entire* ecosystem takes command lines just fine. I have hundreds of 
dockerfiles that have entry points - why do I need to write unit files 
for them?  I have command line tools that generate docker images... 
with command lines - why would I want to write unit files for them?
Interesting use case. Nothing I have ever heard form a developer. I 
think we are "in" the bubble. You are one of the smartest programmers, 
and one of the largest contributors to Kubernetes. There is zero chance 
that our customers will want to rewrite all of their services from 
scratch. I mean, maybe 15 years from now.


I am not arguing against you using it, I am arguing against us packing 
more stuff in RHEL and confusing the not as smart people...


Also, dumb-init is not an init system.  It's a signal proxy.

On Mon, Mar 6, 2017 at 9:55 PM, Scott McCarty <smcca...@redhat.com 
<mailto:smcca...@redhat.com>> wrote:


I am skeptical of any "resource" argument against systemd. Are you
seeing some actually impact to performance that is causing
problems? As for unit files, they are rediculously easy. Much
easier than figuring out how to start a daemon properly by reading
documentation.

I don't have a strong opinion for CentOS/Fedora. But for RHEL, I
think multiple init systems will just generate more technical
questions from customers and eat up more sales resources
explaining when people should use what. Options are great, but
confusing, that's why Apple got rid of a lot of them...


On 03/06/2017 09:48 PM, Clayton Coleman wrote:

Zero overhead, defunct process management, proper logging,
simplicity, no moving parts, no additional unit file (I don't
have unit files).

Turn it around - if I have the command line "ansible-playbook
...", what does systemd get me?

On Mon, Mar 6, 2017 at 9:35 PM, Eric Paris <epa...@redhat.com
<mailto:epa...@redhat.com> <mailto:epa...@redhat.com
<mailto:epa...@redhat.com>>> wrote:

On Mon, 2017-03-06 at 21:22 -0500, Clayton Coleman wrote:
> They'd be really helpful for cases where you don't want
full blown
> systemd, but want a long running container that needs to
reap
> processes.  I don't know that one or the other matters,
I have a
> slight bias for dumb-init in terms of signal rewriting
(a few cases
> might need that).
>
> Anyone using these today?

    What does dumb-init or tini get me that systemd doesn't?



-- 


Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com <mailto:smcca...@redhat.com>

Phone: 312-660-3535 

Cell: 330-807-1043 

Web: http://crunchtools.com

When should you split your application into multiple containers?
http://red.ht/22xKw9i




--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? 
http://red.ht/22xKw9i

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

2017-03-06 Thread Scott McCarty 
I am skeptical of any "resource" argument against systemd. Are you 
seeing some actually impact to performance that is causing problems? As 
for unit files, they are rediculously easy. Much easier than figuring 
out how to start a daemon properly by reading documentation.


I don't have a strong opinion for CentOS/Fedora. But for RHEL, I think 
multiple init systems will just generate more technical questions from 
customers and eat up more sales resources explaining when people should 
use what. Options are great, but confusing, that's why Apple got rid of 
a lot of them...



On 03/06/2017 09:48 PM, Clayton Coleman wrote:
Zero overhead, defunct process management, proper logging, simplicity, 
no moving parts, no additional unit file (I don't have unit files).


Turn it around - if I have the command line "ansible-playbook ...", 
what does systemd get me?


On Mon, Mar 6, 2017 at 9:35 PM, Eric Paris <epa...@redhat.com 
<mailto:epa...@redhat.com>> wrote:


On Mon, 2017-03-06 at 21:22 -0500, Clayton Coleman wrote:
> They'd be really helpful for cases where you don't want full blown
> systemd, but want a long running container that needs to reap
> processes.  I don't know that one or the other matters, I have a
> slight bias for dumb-init in terms of signal rewriting (a few cases
> might need that).
>
> Anyone using these today?

What does dumb-init or tini get me that systemd doesn't?




--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? 
http://red.ht/22xKw9i

Re: [atomic-devel] System container images in projectatomic docker hub

2017-01-12 Thread Scott McCarty 

Dumb question. Are these CentOS/Fedora images? Not RHEL right?


On 01/12/2017 08:44 AM, Matthew Miller wrote:

On Wed, Jan 11, 2017 at 08:32:41PM -0800, Jason Brooks wrote:

I think it would be worth getting these  into fedora's layered build
system, too.

+1000!

Then, they'll end up at the registry Randy Barlow is working on, and
also pushed to Docker Hub as part of that process.



--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smcca...@redhat.com

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? 
http://red.ht/22xKw9i