Re: [Container-tools] CRI-O vs. ContainerD

2017-03-20 Thread Daniel J Walsh 


On 03/20/2017 12:33 PM, Josh Berkus wrote:
> ... can someone give me a practical rundown?
>
> Speaking as a Kubernetes user, how are these different?
>
CRI-O is a CRI Daemon that is being developed to support Kubernetes
workloads using three sub packages

github.com://containers/storage
github.comf://containers/image
github.com://opencontainers/runtime-spec and
github.com://opencontainers/runc

Red Hat is taking the lead on this effort, but we have major
contributors from Suse, Intel, IBM.  It is part of an k8s incubator
project.  Available now in Rawhide as the ocid package.  We are
currently passing about 1/3 of the k8s CRI test suite.  Hope to pass all
within 6 months.

ContainerD is an new monolithic daemon from Docker Inc. It includes what
is containerd from the docker project which was a daemon built mainly to
support the Swarm workloads as well as sucked parts of the docker daemon
out to handle container storage and pulling/pushing images. As of now it
does not support k8s CRI, although that is clearly Docker Inc's aim.  It
also only supports storage on Overlay2 and Aufs.  They did some redesign
of the Storage layer to make it different then Docker mechanism.  (We
based containers/storage off of the Docker storage).  Containerd still
has Solomon Sykes as the BDL of containerd.  We submitted pull requests
to use containers/storage and containers/image to containerd but was
rejected by the containerd team.  Docker would like to see containerd be
the one Daemon to handle all container workloads.  We think at some
point in the future the upstream docker project will move to containerd.

___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

Re: [Container-tools] new minishift CDK

2017-03-20 Thread Lalatendu Mohanty 
On Fri, Mar 17, 2017 at 8:44 PM, Burr Sutter  wrote:

> We had a situation where a route was misbehaving. My investigation
> strategy is to get inside the VM, oc get services and curl the IP address.
>
> I actually do this as a live demo on the current CDK.
>
> And I transfer in files that I need via
> vagrant rsync
>
> Do we have an Asher for that?
>
>
With Minishift we have not taken that route as we want to keep the ISO as
much as light weighted. But I think we need to provide some sort of way for
advance users who want to play with the VM more.

At this point we are focusing on making Minishift useful for developers and
it is a lot of work. If you think we should take use case like this with
high priority then we should talk and discuss.


> Also, another inside VM trick, I like checking free memory and disk.
> Running out of disk is common with heavy Docker usage.
>

Right. We also want to add an feature where user can specify a higher size
disk. Currently the default is 20GB and there is no way to change it.

>
> And this reminds me, what is the directory to rm -fr to clean out of stuff
> under the Docker daemon?
>
>
I would suggest "docker rmi" command for that. The OpenShift stuff lives in
/var/lib/minishift.

Thanks,
Lala

>
>
> On Fri, Mar 17, 2017 at 2:39 AM Praveen Kumar <
> kumarpraveen.nit...@gmail.com> wrote:
>
>> On Thu, Mar 16, 2017 at 10:42 PM, Burr Sutter  wrote:
>>
>> if I  "minishift ssh", I would like "oc" and "kubectl" to be available to
>> me in the PATH.  Only "docker" seems to be available right now.
>>
>>
>> we don't have "oc" or "kubectl" binary inside the image because VM
>> something is blackbox for users and they should interact it from host
>> itself. Any specific requirement for which we need it for the iso/vm?
>>
>>
>>
>>
>> ___
>> Container-tools mailing list
>> Container-tools@redhat.com
>> https://www.redhat.com/mailman/listinfo/container-tools
>>
>>
>>
>>
>> --
>> Praveen Kumar
>> http://fedoraproject.org/wiki/User:Kumarpraveen
>> http://fedoraproject.org/
>> http://kumar-pravin.blogspot.com
>>
>>
>
> ___
> Container-tools mailing list
> Container-tools@redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
>
>
___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

Re: [Container-tools] [node-devel] Community Node.js Builder Images

2017-03-20 Thread Stephanos Bacon 
On Fri, Mar 17, 2017 at 1:57 PM, Lance Ball  wrote:

>
>
> On Fri, Mar 17, 2017 at 12:43 PM Ben Parees  wrote:
>
>> On Fri, Mar 17, 2017 at 12:18 PM, Lance Ball  wrote:
>>
>>
>>- Allowing for composability so that the developer can add what they
>>need at image build time. I think that .s2i/assemble and friends make
>>this possible, but maybe I am missing something larger. Am I?
>>
>> ​I think you're missing two things:
>>
>> 1) assemble can't install packages, it doesn't have root permissions
>> 2) doing things at assemble time means doing them every time you build
>> the application image, instead of just one time when you create the builder
>> image, so it dramatically increases build times.
>>
>
> Ahh, good points. Thanks.
>
>
>>
>>- Providing two different s2i base images for each runtime
>>environment: s2i-core and s2i-base, for example. I think the core
>>image should be similar to rhel7-atomic. Just a bare bones,
>>optimized-for-the-container image. Developers concerned about image size
>>can use this image and .s2i/assemble to have a fully customizable
>>build/runtime environment. Developers less concerned about minimal size
>>could depend on s2i-base which has all of the tools and development
>>libraries that are generally required for the vast majority of
>>OS/platform/language environments.
>>
>>
>> ​s2i-base really started out as an internal thing for us to use as a
>> common base for the s2i images we were providing.  We actually fought, for
>> a long time, making it "public" and having other people start creating
>> their own images on top of it because we didn't want to treat it as an api.
>>
>> If we were going to create a "slimmed down" version of s2i-base, i'd be
>> curious what would actually be in it, as opposed to just telling people who
>> want to build smaller s2i images, to use some other generic base image.
>> The things s2i-base provides are:
>> 1) common set of packages that are useful for things built on top (the
>> stuff you are suggesting getting rid of)
>> 2) a few helper scripts and env variables that provide useful context for
>> an s2i image.
>>
>
>> I don't know that there's enough value in (2) to justify created a second
>> "s2i-base-lite" image once you get rid of (1).
>>
>
> I think that means that for users who want to build smaller images,
> they'll need to use the base image of their choice, and then be aware
> of/provide the bits described here: https://docs.openshift.org/
> latest/creating_images/guidelines.html#openshift-
> origin-specific-guidelines and here: https://docs.openshift.org/
> latest/creating_images/s2i.html#creating-images-s2i, if I understand
> correctly. In my opinion, a slim image that provides these things would be
> useful. There is a lot of content in those docs to sift through and
> implement for a potentially common case. But I'm a sample size of 1, so...
> :)
>
>
>>
>>- Allow users to specify the runtime image and runtime artifact(s) on
>>the command line, as described in the document linked below. In a
>>contrived/simple case, this would mean that a developer could use
>>s2i-base for building the application image and s2i-core for the
>>runtime. No customization required, just a simple command line option that
>>builds in a full featured environment and deploys to a slimmed down
>>runtime.
>>
>>
>> ​fyi we are really encouraging people not to use extended builds(the
>> build/runtime image mechanism) and instead accomplish that goal via
>> chained-builds:
>>
>> https://docs.openshift.org/latest/dev_guide/builds/
>> advanced_build_operations.html#dev-guide-chaining-builds
>>
>
> Interesting. If I want to use chained builds, how do I accomplish that? Do
> I need to create a build in the UI, then manually edit the BuildConfig? Or
> somehow POST a BuildConfig to OpenShift? Is there any easier and more
> intuitive way?
>
> I'm curious why this is the suggested approach. From my perspective,
> extended builds seem much more intuitive, and certainly easier for the end
> user.
>
> Lance
>

Also, will chained builds work on OpenShift Online and OpenShift Dedicated?
 (I thought that docker builds didn't work on OCO and OCD).  Also, also -
if docker builds work anyway, could one dispense with the s2i build and do
both the compilation and the docker build in a jenkins build pod?

-steph
___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

[Container-tools] oc cluster up metrics=true

2017-03-20 Thread Burr Sutter 
what is the "metrics=true" equivalent in minishift?
___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

Re: [Container-tools] Community Node.js Builder Images

2017-03-20 Thread Brian Gollaher 

On 03/17/2017 04:29 PM, Lance Ball wrote:
This has been a great conversation. Thanks everyone for your input. 
One thing that kind of got lost in the shuffle, though is this.


On Thu, Mar 16, 2017 at 12:37 PM Lance Ball > wrote:


I also think that, in addition to the current OpenShift offerings
for Node.js on RHEL and CentOS, we should be providing a larger
matrix of options. Is there any reason not to pursue community
versions of Node.js builder images for the following combination
of OS/Node?

RHEL -> Node 4, 5, 6, 7
rhel7-atomic -> Node 4, 5, 6, 7
Fedora -> Node 4, 5, 6, 7
CentOS -> Node 4, 5, 6, 7

Who will do the packaging and support for these versions?  Is Middleware 
engineering signing up or are you asking for the RHEL team to do these?



I understand that SCL-provided, supported images for RHEL already
exist for Node.js v4.x and soon to be Node.js v6.x. As you
probably know, some of us are actively working towards a solution
that would allow these supported images to achieve greater
turnaround time, and maintain version parity with all current
Node.js releases.

Would the addition of community provided rhel7-atomic, fedora and
perhaps even rhel images be welcomed?


Anyone have feedback or concerns about this idea?

Thanks
Lance


___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools


--
Brian Gollaher
Red Hat Platform Product Management
Phone: 978 392-3173
Cell: 508 740-6549
bri...@redhat.com

___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

Re: [Container-tools] new minishift CDK

2017-03-20 Thread Hardy Ferentschik 
Hi,

> > We had a situation where a route was misbehaving. My investigation
> > strategy is to get inside the VM, oc get services and curl the IP address.

We are providing oc on the host, so you can skip the step of logging into
the VM. You can execute 'oc get service' on the host. Even better,
we have a Minishift specific command (there is a bug we are fixing atm),
so that you can do 'minishift openshift service list -n myproject' and you
get a list of all routes. 

> > And I transfer in files that I need via
> > vagrant rsync

The aim is to do as much as possible on the host. Also, as we are getting closer
to a consistent solution for host folders, there should be no need for rsyncing 
anything.

> > Do we have an Asher for that?

What's that?

> With Minishift we have not taken that route as we want to keep the ISO as
> much as light weighted. But I think we need to provide some sort of way for
> advance users who want to play with the VM more.

And what would you have in mind there?

--Hardy



signature.asc
Description: PGP signature
___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

Re: [Container-tools] new minishift CDK

2017-03-20 Thread Praveen Kumar 
On Mon, Mar 20, 2017 at 11:43 AM, Lalatendu Mohanty  wrote:
>
>
>
> On Fri, Mar 17, 2017 at 8:44 PM, Burr Sutter  wrote:
>>
>> We had a situation where a route was misbehaving. My investigation strategy 
>> is to get inside the VM, oc get services and curl the IP address.
>>
>> I actually do this as a live demo on the current CDK.
>>
>> And I transfer in files that I need via
>> vagrant rsync
>>
>> Do we have an Asher for that?
>>
>
> With Minishift we have not taken that route as we want to keep the ISO as 
> much as light weighted. But I think we need to provide some sort of way for 
> advance users who want to play with the VM more.
>
> At this point we are focusing on making Minishift useful for developers and 
> it is a lot of work. If you think we should take use case like this with high 
> priority then we should talk and discuss.
>
>>
>> Also, another inside VM trick, I like checking free memory and disk.  
>> Running out of disk is common with heavy Docker usage.
>
>
> Right. We also want to add an feature where user can specify a higher size 
> disk. Currently the default is 20GB and there is no way to change it.

We do have option in minishift start where you can specify a higher
disk space like 40GB when start. `minishift start --disk-size 40g`
which create 40GB persistent storage in the VM.


-- 
Praveen Kumar
http://fedoraproject.org/wiki/User:Kumarpraveen
http://fedoraproject.org/
http://kumar-pravin.blogspot.com

___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

Re: [Container-tools] new minishift CDK

2017-03-20 Thread Burr Sutter 
Will this work with the "config view" command?


On Mon, Mar 20, 2017 at 12:07 PM Praveen Kumar <
kumarpraveen.nit...@gmail.com> wrote:

> On Mon, Mar 20, 2017 at 11:43 AM, Lalatendu Mohanty 
> wrote:
> >
> >
> >
> > On Fri, Mar 17, 2017 at 8:44 PM, Burr Sutter  wrote:
> >>
> >> We had a situation where a route was misbehaving. My investigation
> strategy is to get inside the VM, oc get services and curl the IP address.
> >>
> >> I actually do this as a live demo on the current CDK.
> >>
> >> And I transfer in files that I need via
> >> vagrant rsync
> >>
> >> Do we have an Asher for that?
> >>
> >
> > With Minishift we have not taken that route as we want to keep the ISO
> as much as light weighted. But I think we need to provide some sort of way
> for advance users who want to play with the VM more.
> >
> > At this point we are focusing on making Minishift useful for developers
> and it is a lot of work. If you think we should take use case like this
> with high priority then we should talk and discuss.
> >
> >>
> >> Also, another inside VM trick, I like checking free memory and disk.
> Running out of disk is common with heavy Docker usage.
> >
> >
> > Right. We also want to add an feature where user can specify a higher
> size disk. Currently the default is 20GB and there is no way to change it.
>
> We do have option in minishift start where you can specify a higher
> disk space like 40GB when start. `minishift start --disk-size 40g`
> which create 40GB persistent storage in the VM.
>
>
> --
> Praveen Kumar
> http://fedoraproject.org/wiki/User:Kumarpraveen
> http://fedoraproject.org/
> http://kumar-pravin.blogspot.com
>
___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

[Container-tools] CRI-O vs. ContainerD

2017-03-20 Thread Josh Berkus 
... can someone give me a practical rundown?

Speaking as a Kubernetes user, how are these different?

-- 
--
Josh Berkus
Project Atomic
Red Hat OSAS

___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools

Re: [Container-tools] [node-devel] Community Node.js Builder Images

2017-03-20 Thread Jay Balunas 
On Mon, Mar 20, 2017 at 8:39 AM, Brian Gollaher  wrote:

> On 03/17/2017 04:29 PM, Lance Ball wrote:
>
> This has been a great conversation. Thanks everyone for your input. One
> thing that kind of got lost in the shuffle, though is this.
>
> On Thu, Mar 16, 2017 at 12:37 PM Lance Ball  wrote:
>
>> I also think that, in addition to the current OpenShift offerings for
>> Node.js on RHEL and CentOS, we should be providing a larger matrix of
>> options. Is there any reason not to pursue community versions of Node.js
>> builder images for the following combination of OS/Node?
>>
>> RHEL -> Node 4, 5, 6, 7
>> rhel7-atomic -> Node 4, 5, 6, 7
>> Fedora -> Node 4, 5, 6, 7
>> CentOS -> Node 4, 5, 6, 7
>>
> Who will do the packaging and support for these versions?  Is Middleware
> engineering signing up or are you asking for the RHEL team to do these?
>

This is part of the we'd like to nail down across the teams, and you'll
likely hear from us for another joint discussion soon.  This has been
mostly R, investigations/discussions, etc... but with some encouraging
results.

However, the MW node team has the expertise in the node functionality[1],
and we think that we could be the maintainers of these artifacts if the
base images are there.  The devil is in the details, but again, lets think
about a follow up discussion on this shortly.

[1] Enough that we've already fixed a few things upstream that previous
builds needed to work around, which is awesome value add!


>
>> I understand that SCL-provided, supported images for RHEL already exist
>> for Node.js v4.x and soon to be Node.js v6.x. As you probably know, some of
>> us are actively working towards a solution that would allow these supported
>> images to achieve greater turnaround time, and maintain version parity with
>> all current Node.js releases.
>>
>> Would the addition of community provided rhel7-atomic, fedora and perhaps
>> even rhel images be welcomed?
>>
>
> Anyone have feedback or concerns about this idea?
>
> Thanks
> Lance
>
>
> ___
> Container-tools mailing 
> listContainer-tools@redhat.comhttps://www.redhat.com/mailman/listinfo/container-tools
>
>
> --
> Brian Gollaher
> Red Hat Platform Product Management
> Phone: 978 392-3173 <(978)%20392-3173>
> Cell: 508 740-6549 <(508)%20740-6549>bri...@redhat.com
>
>
___
Container-tools mailing list
Container-tools@redhat.com
https://www.redhat.com/mailman/listinfo/container-tools