Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Emilien Macchi]

I suggest that we continue the discussion in this freshly created specs:
https://review.openstack.org/602480

http://logs.openstack.org/80/602480/2/check/openstack-tox-docs/9da610c/html/specs/stein/podman.html

Any feedback and inputs are welcome.
Thanks,

On Thu, Sep 13, 2018 at 3:36 AM Bogdan Dobrelya  wrote:

> On 8/27/18 6:38 PM, Fox, Kevin M wrote:
> > I think in this context, kubelet without all of kubernetes still has the
> value that it provides an abstraction layer that podmon/paunch is being
> suggested to handle.
> >
> > It does not need the things you mention, network, sidecar, scaleup/down,
> etc. You can use as little as you want.
> >
> > For example, make a pod yaml per container with hostNetwork: true. it
> will run just like it was on the host then. You can do just one container.
> no sidecars necessary. Without the apiserver, it can't do scaleup/down even
> if you wanted to.
> >
> > It provides declarative yaml based management of containers, similar to
> paunch. so you can skip needing that component.
>
> That would be a step into the right direction IMO.
>
> >
> > It also already provides crio and docker support via cri.
> >
> > It does provide a little bit of orchestration, in that you drive things
> with declarative yaml. You drop in a yaml file in
> /etc/kubernetes/manifests, and it will create the container. you delete it,
> it removes the container. If you change it, it will update the container.
> and if something goes wrong with the container, it will try and get it back
> to the requested state automatically. And, it will recover the containers
> on reboot without help.
> >
> > Thanks,
> > Kevin
> >
> > 
> > From: Sergii Golovatiuk [sgolo...@redhat.com]
> > Sent: Monday, August 27, 2018 3:46 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for
> nice   API calls
> >
> > Hi,
> >
> > On Mon, Aug 27, 2018 at 12:16 PM, Rabi Mishra 
> wrote:
> >> On Mon, Aug 27, 2018 at 3:25 PM, Sergii Golovatiuk  >
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Mon, Aug 27, 2018 at 5:32 AM, Rabi Mishra 
> wrote:
> >>>> On Mon, Aug 27, 2018 at 7:31 AM, Steve Baker 
> wrote:
> >>> Steve mentioned kubectl (kubernetes CLI which communicates with
> >>
> >>
> >> Not sure what he meant. May be I miss something, but not heard of
> 'kubectl
> >> standalone', though he might have meant standalone k8s cluster on every
> node
> >> as you think.
> >>
> >>>
> >>> kube-api) not kubelet which is only one component of kubernetes. All
> >>> kubernetes components may be compiled as one binary (hyperkube) which
> >>> can be used to minimize footprint. Generated ansible for kubelet is
> >>> not enough as kubelet doesn't have any orchestration logic.
> >>
> >>
> >> What orchestration logic do we've with TripleO atm? AFAIK we've provide
> >> roles data for service placement across nodes, right?
> >> I see standalone kubelet as a first step for scheduling openstack
> services
> >> with in k8s cluster in the future (may be).
> >
> > It's half measure. I don't see any advantages of that move. We should
> > either adopt whole kubernetes or doesn't use its components at all as
> > the maintenance cost will be expensive. Using kubelet requires to
> > resolve networking communication, scale-up/down, sidecar, or inter
> > services dependencies.
> >
> >>
> >>>>>
> >>>>> This was a while ago now so this could be worth revisiting in the
> >>>>> future.
> >>>>> We'll be making gradual changes, the first of which is using podman
> to
> >>>>> manage single containers. However podman has native support for the
> pod
> >>>>> format, so I'm hoping we can switch to that once this transition is
> >>>>> complete. Then evaluating kubectl becomes much easier.
> >>>>>
> >>>>>> Question. Rather then writing a middle layer to abstract both
> >>>>>> container
> >>>>>> engines, couldn't you just use CRI? CRI is CRI-O's native language,
> >>>>>> and
> >>>>>> there is support already for Docker as well.
> >>>>>
> >>>>>
> >>>>> We're not writing a middle layer, we're leveraging one whic

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Bogdan Dobrelya]

On 8/27/18 6:38 PM, Fox, Kevin M wrote:

I think in this context, kubelet without all of kubernetes still has the value 
that it provides an abstraction layer that podmon/paunch is being suggested to 
handle.

It does not need the things you mention, network, sidecar, scaleup/down, etc. 
You can use as little as you want.

For example, make a pod yaml per container with hostNetwork: true. it will run 
just like it was on the host then. You can do just one container. no sidecars 
necessary. Without the apiserver, it can't do scaleup/down even if you wanted 
to.

It provides declarative yaml based management of containers, similar to paunch. 
so you can skip needing that component.


That would be a step into the right direction IMO.



It also already provides crio and docker support via cri.

It does provide a little bit of orchestration, in that you drive things with 
declarative yaml. You drop in a yaml file in /etc/kubernetes/manifests, and it 
will create the container. you delete it, it removes the container. If you 
change it, it will update the container. and if something goes wrong with the 
container, it will try and get it back to the requested state automatically. 
And, it will recover the containers on reboot without help.

Thanks,
Kevin


From: Sergii Golovatiuk [sgolo...@redhat.com]
Sent: Monday, August 27, 2018 3:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice   
API calls

Hi,

On Mon, Aug 27, 2018 at 12:16 PM, Rabi Mishra  wrote:

On Mon, Aug 27, 2018 at 3:25 PM, Sergii Golovatiuk 
wrote:


Hi,

On Mon, Aug 27, 2018 at 5:32 AM, Rabi Mishra  wrote:

On Mon, Aug 27, 2018 at 7:31 AM, Steve Baker  wrote:

Steve mentioned kubectl (kubernetes CLI which communicates with



Not sure what he meant. May be I miss something, but not heard of 'kubectl
standalone', though he might have meant standalone k8s cluster on every node
as you think.



kube-api) not kubelet which is only one component of kubernetes. All
kubernetes components may be compiled as one binary (hyperkube) which
can be used to minimize footprint. Generated ansible for kubelet is
not enough as kubelet doesn't have any orchestration logic.



What orchestration logic do we've with TripleO atm? AFAIK we've provide
roles data for service placement across nodes, right?
I see standalone kubelet as a first step for scheduling openstack services
with in k8s cluster in the future (may be).


It's half measure. I don't see any advantages of that move. We should
either adopt whole kubernetes or doesn't use its components at all as
the maintenance cost will be expensive. Using kubelet requires to
resolve networking communication, scale-up/down, sidecar, or inter
services dependencies.





This was a while ago now so this could be worth revisiting in the
future.
We'll be making gradual changes, the first of which is using podman to
manage single containers. However podman has native support for the pod
format, so I'm hoping we can switch to that once this transition is
complete. Then evaluating kubectl becomes much easier.


Question. Rather then writing a middle layer to abstract both
container
engines, couldn't you just use CRI? CRI is CRI-O's native language,
and
there is support already for Docker as well.



We're not writing a middle layer, we're leveraging one which is already
there.

CRI-O is a socket interface and podman is a CLI interface that both sit
on
top of the exact same Go libraries. At this point, switching to podman
needs
a much lower development effort because we're replacing docker CLI
calls.


I see good value in evaluating kubelet standalone and leveraging it's
inbuilt grpc interfaces with cri-o (rather than using podman) as a long
term
strategy, unless we just want to provide an alternative to docker
container
runtime with cri-o.


I see no value using kubelet without kubernetes IMHO.







Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Thursday, August 23, 2018 8:36 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for
nice
API calls

Dan, thanks for the details and answers. Appreciated.

Best,
-jay

On 08/23/2018 10:50 AM, Dan Prince wrote:


On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes  wrote:


On 08/15/2018 04:01 PM, Emilien Macchi wrote:


On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi mailto:emil...@redhat.com>> wrote:

   More seriously here: there is an ongoing effort to converge
the
   tools around containerization within Red Hat, and we, TripleO
are
   interested to continue the containerization of our services
(which
   was initially done with Docker & Docker-Distribution).
   We're looking at how these containers could be managed by k8s
one
   day but way before that we plan to swap out Docker and join
CRI-O
   efforts, 

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Fox, Kevin M]

I think in this context, kubelet without all of kubernetes still has the value 
that it provides an abstraction layer that podmon/paunch is being suggested to 
handle.

It does not need the things you mention, network, sidecar, scaleup/down, etc. 
You can use as little as you want.

For example, make a pod yaml per container with hostNetwork: true. it will run 
just like it was on the host then. You can do just one container. no sidecars 
necessary. Without the apiserver, it can't do scaleup/down even if you wanted 
to.

It provides declarative yaml based management of containers, similar to paunch. 
so you can skip needing that component.

It also already provides crio and docker support via cri.

It does provide a little bit of orchestration, in that you drive things with 
declarative yaml. You drop in a yaml file in /etc/kubernetes/manifests, and it 
will create the container. you delete it, it removes the container. If you 
change it, it will update the container. and if something goes wrong with the 
container, it will try and get it back to the requested state automatically. 
And, it will recover the containers on reboot without help.

Thanks,
Kevin


From: Sergii Golovatiuk [sgolo...@redhat.com]
Sent: Monday, August 27, 2018 3:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice   
API calls

Hi,

On Mon, Aug 27, 2018 at 12:16 PM, Rabi Mishra  wrote:
> On Mon, Aug 27, 2018 at 3:25 PM, Sergii Golovatiuk 
> wrote:
>>
>> Hi,
>>
>> On Mon, Aug 27, 2018 at 5:32 AM, Rabi Mishra  wrote:
>> > On Mon, Aug 27, 2018 at 7:31 AM, Steve Baker  wrote:
>> Steve mentioned kubectl (kubernetes CLI which communicates with
>
>
> Not sure what he meant. May be I miss something, but not heard of 'kubectl
> standalone', though he might have meant standalone k8s cluster on every node
> as you think.
>
>>
>> kube-api) not kubelet which is only one component of kubernetes. All
>> kubernetes components may be compiled as one binary (hyperkube) which
>> can be used to minimize footprint. Generated ansible for kubelet is
>> not enough as kubelet doesn't have any orchestration logic.
>
>
> What orchestration logic do we've with TripleO atm? AFAIK we've provide
> roles data for service placement across nodes, right?
> I see standalone kubelet as a first step for scheduling openstack services
> with in k8s cluster in the future (may be).

It's half measure. I don't see any advantages of that move. We should
either adopt whole kubernetes or doesn't use its components at all as
the maintenance cost will be expensive. Using kubelet requires to
resolve networking communication, scale-up/down, sidecar, or inter
services dependencies.

>
>> >>
>> >> This was a while ago now so this could be worth revisiting in the
>> >> future.
>> >> We'll be making gradual changes, the first of which is using podman to
>> >> manage single containers. However podman has native support for the pod
>> >> format, so I'm hoping we can switch to that once this transition is
>> >> complete. Then evaluating kubectl becomes much easier.
>> >>
>> >>> Question. Rather then writing a middle layer to abstract both
>> >>> container
>> >>> engines, couldn't you just use CRI? CRI is CRI-O's native language,
>> >>> and
>> >>> there is support already for Docker as well.
>> >>
>> >>
>> >> We're not writing a middle layer, we're leveraging one which is already
>> >> there.
>> >>
>> >> CRI-O is a socket interface and podman is a CLI interface that both sit
>> >> on
>> >> top of the exact same Go libraries. At this point, switching to podman
>> >> needs
>> >> a much lower development effort because we're replacing docker CLI
>> >> calls.
>> >>
>> > I see good value in evaluating kubelet standalone and leveraging it's
>> > inbuilt grpc interfaces with cri-o (rather than using podman) as a long
>> > term
>> > strategy, unless we just want to provide an alternative to docker
>> > container
>> > runtime with cri-o.
>>
>> I see no value using kubelet without kubernetes IMHO.
>>
>>
>> >
>> >>>
>> >>>
>> >>> Thanks,
>> >>> Kevin
>> >>> 
>> >>> From: Jay Pipes [jaypi...@gmail.com]
>> >>> Sent: Thursday, August 23, 2018 8:36 AM
>> >>> To: openstack-dev@lists.openstack.org
>> >

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Sergii Golovatiuk]

Hi,

On Mon, Aug 27, 2018 at 12:16 PM, Rabi Mishra  wrote:
> On Mon, Aug 27, 2018 at 3:25 PM, Sergii Golovatiuk 
> wrote:
>>
>> Hi,
>>
>> On Mon, Aug 27, 2018 at 5:32 AM, Rabi Mishra  wrote:
>> > On Mon, Aug 27, 2018 at 7:31 AM, Steve Baker  wrote:
>> Steve mentioned kubectl (kubernetes CLI which communicates with
>
>
> Not sure what he meant. May be I miss something, but not heard of 'kubectl
> standalone', though he might have meant standalone k8s cluster on every node
> as you think.
>
>>
>> kube-api) not kubelet which is only one component of kubernetes. All
>> kubernetes components may be compiled as one binary (hyperkube) which
>> can be used to minimize footprint. Generated ansible for kubelet is
>> not enough as kubelet doesn't have any orchestration logic.
>
>
> What orchestration logic do we've with TripleO atm? AFAIK we've provide
> roles data for service placement across nodes, right?
> I see standalone kubelet as a first step for scheduling openstack services
> with in k8s cluster in the future (may be).

It's half measure. I don't see any advantages of that move. We should
either adopt whole kubernetes or doesn't use its components at all as
the maintenance cost will be expensive. Using kubelet requires to
resolve networking communication, scale-up/down, sidecar, or inter
services dependencies.

>
>> >>
>> >> This was a while ago now so this could be worth revisiting in the
>> >> future.
>> >> We'll be making gradual changes, the first of which is using podman to
>> >> manage single containers. However podman has native support for the pod
>> >> format, so I'm hoping we can switch to that once this transition is
>> >> complete. Then evaluating kubectl becomes much easier.
>> >>
>> >>> Question. Rather then writing a middle layer to abstract both
>> >>> container
>> >>> engines, couldn't you just use CRI? CRI is CRI-O's native language,
>> >>> and
>> >>> there is support already for Docker as well.
>> >>
>> >>
>> >> We're not writing a middle layer, we're leveraging one which is already
>> >> there.
>> >>
>> >> CRI-O is a socket interface and podman is a CLI interface that both sit
>> >> on
>> >> top of the exact same Go libraries. At this point, switching to podman
>> >> needs
>> >> a much lower development effort because we're replacing docker CLI
>> >> calls.
>> >>
>> > I see good value in evaluating kubelet standalone and leveraging it's
>> > inbuilt grpc interfaces with cri-o (rather than using podman) as a long
>> > term
>> > strategy, unless we just want to provide an alternative to docker
>> > container
>> > runtime with cri-o.
>>
>> I see no value using kubelet without kubernetes IMHO.
>>
>>
>> >
>> >>>
>> >>>
>> >>> Thanks,
>> >>> Kevin
>> >>> 
>> >>> From: Jay Pipes [jaypi...@gmail.com]
>> >>> Sent: Thursday, August 23, 2018 8:36 AM
>> >>> To: openstack-dev@lists.openstack.org
>> >>> Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for
>> >>> nice
>> >>> API calls
>> >>>
>> >>> Dan, thanks for the details and answers. Appreciated.
>> >>>
>> >>> Best,
>> >>> -jay
>> >>>
>> >>> On 08/23/2018 10:50 AM, Dan Prince wrote:
>> >>>>
>> >>>> On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes  wrote:
>> >>>>>
>> >>>>> On 08/15/2018 04:01 PM, Emilien Macchi wrote:
>> >>>>>>
>> >>>>>> On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi > >>>>>> <mailto:emil...@redhat.com>> wrote:
>> >>>>>>
>> >>>>>>   More seriously here: there is an ongoing effort to converge
>> >>>>>> the
>> >>>>>>   tools around containerization within Red Hat, and we, TripleO
>> >>>>>> are
>> >>>>>>   interested to continue the containerization of our services
>> >>>>>> (which
>> >>>>>>   was initially done with Docker & Docker-Distribution).
>> >>>>>>   We're looking at how these containers could be managed by k8s
&

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Rabi Mishra]

On Mon, Aug 27, 2018 at 3:25 PM, Sergii Golovatiuk 
wrote:

> Hi,
>
> On Mon, Aug 27, 2018 at 5:32 AM, Rabi Mishra  wrote:
> > On Mon, Aug 27, 2018 at 7:31 AM, Steve Baker  wrote:
> Steve mentioned kubectl (kubernetes CLI which communicates with
>

Not sure what he meant. May be I miss something, but not heard of 'kubectl
standalone', though he might have meant standalone k8s cluster on every
node as you think.


> kube-api) not kubelet which is only one component of kubernetes. All
> kubernetes components may be compiled as one binary (hyperkube) which
> can be used to minimize footprint. Generated ansible for kubelet is
> not enough as kubelet doesn't have any orchestration logic.
>

What orchestration logic do we've with TripleO atm? AFAIK we've provide
roles data for service placement across nodes, right?
I see standalone kubelet as a first step for scheduling openstack services
with in k8s cluster in the future (may be).

>>
> >> This was a while ago now so this could be worth revisiting in the
> future.
> >> We'll be making gradual changes, the first of which is using podman to
> >> manage single containers. However podman has native support for the pod
> >> format, so I'm hoping we can switch to that once this transition is
> >> complete. Then evaluating kubectl becomes much easier.
> >>
> >>> Question. Rather then writing a middle layer to abstract both container
> >>> engines, couldn't you just use CRI? CRI is CRI-O's native language, and
> >>> there is support already for Docker as well.
> >>
> >>
> >> We're not writing a middle layer, we're leveraging one which is already
> >> there.
> >>
> >> CRI-O is a socket interface and podman is a CLI interface that both sit
> on
> >> top of the exact same Go libraries. At this point, switching to podman
> needs
> >> a much lower development effort because we're replacing docker CLI
> calls.
> >>
> > I see good value in evaluating kubelet standalone and leveraging it's
> > inbuilt grpc interfaces with cri-o (rather than using podman) as a long
> term
> > strategy, unless we just want to provide an alternative to docker
> container
> > runtime with cri-o.
>
> I see no value using kubelet without kubernetes IMHO.
>
>
>
> >>>
> >>>
> >>> Thanks,
> >>> Kevin
> >>> 
> >>> From: Jay Pipes [jaypi...@gmail.com]
> >>> Sent: Thursday, August 23, 2018 8:36 AM
> >>> To: openstack-dev@lists.openstack.org
> >>> Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for
> nice
> >>> API calls
> >>>
> >>> Dan, thanks for the details and answers. Appreciated.
> >>>
> >>> Best,
> >>> -jay
> >>>
> >>> On 08/23/2018 10:50 AM, Dan Prince wrote:
> >>>>
> >>>> On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes  wrote:
> >>>>>
> >>>>> On 08/15/2018 04:01 PM, Emilien Macchi wrote:
> >>>>>>
> >>>>>> On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi  >>>>>> <mailto:emil...@redhat.com>> wrote:
> >>>>>>
> >>>>>>   More seriously here: there is an ongoing effort to converge
> the
> >>>>>>   tools around containerization within Red Hat, and we, TripleO
> >>>>>> are
> >>>>>>   interested to continue the containerization of our services
> >>>>>> (which
> >>>>>>   was initially done with Docker & Docker-Distribution).
> >>>>>>   We're looking at how these containers could be managed by k8s
> >>>>>> one
> >>>>>>   day but way before that we plan to swap out Docker and join
> >>>>>> CRI-O
> >>>>>>   efforts, which seem to be using Podman + Buildah (among other
> >>>>>> things).
> >>>>>>
> >>>>>> I guess my wording wasn't the best but Alex explained way better
> here:
> >>>>>>
> >>>>>> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%
> 23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52
> >>>>>>
> >>>>>> If I may have a chance to rephrase, I guess our current intention is
> >>>>>> to
> >>>>>> continue our containerization and investigate how we can improve

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Sergii Golovatiuk]

Hi,

On Mon, Aug 27, 2018 at 5:32 AM, Rabi Mishra  wrote:
> On Mon, Aug 27, 2018 at 7:31 AM, Steve Baker  wrote:
>>
>>
>>
>> On 24/08/18 04:36, Fox, Kevin M wrote:
>>>
>>> Or use kubelet in standalone mode. It can be configured for either Cri-o
>>> or Docker. You can drive the static manifests from heat/ansible per host as
>>> normal and it would be a step in the greater direction of getting to
>>> Kubernetes without needing the whole thing at once, if that is the goal.
>>
>>
>> I was an advocate for using kubectl standalone for our container
>> orchestration needs well before we started containerizing TripleO. After
>> talking to a few kubernetes folk I cooled on the idea, because they had one
>> of two responses:
>> - cautious encouragement, but uncertainty about kubectl standalone
>> interface support and consideration for those use cases
>> - googly eyed incomprehension followed by "why would you do that??"
>>
>
> AFAIK, kubelet does not have a good set of REST API yet[1], but things like
> heapster do directly interface with kubelet. Last I've seen there was no
> general consensus for kubelet to provide a subset of api-server APIs.
> However, from TripleO standpoint providing a set of pod specs to kubelet
> generated by ansible may be sufficient?
>
> [1] https://github.com/kubernetes/kubernetes/issues/28138

Steve mentioned kubectl (kubernetes CLI which communicates with
kube-api) not kubelet which is only one component of kubernetes. All
kubernetes components may be compiled as one binary (hyperkube) which
can be used to minimize footprint. Generated ansible for kubelet is
not enough as kubelet doesn't have any orchestration logic.

>>
>> This was a while ago now so this could be worth revisiting in the future.
>> We'll be making gradual changes, the first of which is using podman to
>> manage single containers. However podman has native support for the pod
>> format, so I'm hoping we can switch to that once this transition is
>> complete. Then evaluating kubectl becomes much easier.
>>
>>> Question. Rather then writing a middle layer to abstract both container
>>> engines, couldn't you just use CRI? CRI is CRI-O's native language, and
>>> there is support already for Docker as well.
>>
>>
>> We're not writing a middle layer, we're leveraging one which is already
>> there.
>>
>> CRI-O is a socket interface and podman is a CLI interface that both sit on
>> top of the exact same Go libraries. At this point, switching to podman needs
>> a much lower development effort because we're replacing docker CLI calls.
>>
> I see good value in evaluating kubelet standalone and leveraging it's
> inbuilt grpc interfaces with cri-o (rather than using podman) as a long term
> strategy, unless we just want to provide an alternative to docker container
> runtime with cri-o.

I see no value using kubelet without kubernetes IMHO.

>
>>>
>>>
>>> Thanks,
>>> Kevin
>>> 
>>> From: Jay Pipes [jaypi...@gmail.com]
>>> Sent: Thursday, August 23, 2018 8:36 AM
>>> To: openstack-dev@lists.openstack.org
>>> Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice
>>> API calls
>>>
>>> Dan, thanks for the details and answers. Appreciated.
>>>
>>> Best,
>>> -jay
>>>
>>> On 08/23/2018 10:50 AM, Dan Prince wrote:
>>>>
>>>> On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes  wrote:
>>>>>
>>>>> On 08/15/2018 04:01 PM, Emilien Macchi wrote:
>>>>>>
>>>>>> On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi >>>>> <mailto:emil...@redhat.com>> wrote:
>>>>>>
>>>>>>   More seriously here: there is an ongoing effort to converge the
>>>>>>   tools around containerization within Red Hat, and we, TripleO
>>>>>> are
>>>>>>   interested to continue the containerization of our services
>>>>>> (which
>>>>>>   was initially done with Docker & Docker-Distribution).
>>>>>>   We're looking at how these containers could be managed by k8s
>>>>>> one
>>>>>>   day but way before that we plan to swap out Docker and join
>>>>>> CRI-O
>>>>>>   efforts, which seem to be using Podman + Buildah (among other
>>>>>> things).
>>>>>>
>>>>>> I guess my wording wasn't the b

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Rabi Mishra]

On Mon, Aug 27, 2018 at 7:31 AM, Steve Baker  wrote:

>
>
> On 24/08/18 04:36, Fox, Kevin M wrote:
>
>> Or use kubelet in standalone mode. It can be configured for either Cri-o
>> or Docker. You can drive the static manifests from heat/ansible per host as
>> normal and it would be a step in the greater direction of getting to
>> Kubernetes without needing the whole thing at once, if that is the goal.
>>
>
> I was an advocate for using kubectl standalone for our container
> orchestration needs well before we started containerizing TripleO. After
> talking to a few kubernetes folk I cooled on the idea, because they had one
> of two responses:
> - cautious encouragement, but uncertainty about kubectl standalone
> interface support and consideration for those use cases
> - googly eyed incomprehension followed by "why would you do that??"
>
>
AFAIK, kubelet does not have a good set of REST API yet[1], but things like
heapster do directly interface with kubelet. Last I've seen there was no
general consensus for kubelet to provide a subset of api-server APIs.
However, from TripleO standpoint providing a set of pod specs to kubelet
generated by ansible may be sufficient?

[1] https://github.com/kubernetes/kubernetes/issues/28138


>
> This was a while ago now so this could be worth revisiting in the future.
> We'll be making gradual changes, the first of which is using podman to
> manage single containers. However podman has native support for the pod
> format, so I'm hoping we can switch to that once this transition is
> complete. Then evaluating kubectl becomes much easier.
>
> Question. Rather then writing a middle layer to abstract both container
>> engines, couldn't you just use CRI? CRI is CRI-O's native language, and
>> there is support already for Docker as well.
>>
>
> We're not writing a middle layer, we're leveraging one which is already
> there.
>
> CRI-O is a socket interface and podman is a CLI interface that both sit on
> top of the exact same Go libraries. At this point, switching to podman
> needs a much lower development effort because we're replacing docker CLI
> calls.
>
> I see good value in evaluating kubelet standalone and leveraging it's
inbuilt grpc interfaces with cri-o (rather than using podman) as a long
term strategy, unless we just want to provide an alternative to docker
container runtime with cri-o.


>
>> Thanks,
>> Kevin
>> ____________________
>> From: Jay Pipes [jaypi...@gmail.com]
>> Sent: Thursday, August 23, 2018 8:36 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice
>> API calls
>>
>> Dan, thanks for the details and answers. Appreciated.
>>
>> Best,
>> -jay
>>
>> On 08/23/2018 10:50 AM, Dan Prince wrote:
>>
>>> On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes  wrote:
>>>
>>>> On 08/15/2018 04:01 PM, Emilien Macchi wrote:
>>>>
>>>>> On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi >>>> <mailto:emil...@redhat.com>> wrote:
>>>>>
>>>>>   More seriously here: there is an ongoing effort to converge the
>>>>>   tools around containerization within Red Hat, and we, TripleO are
>>>>>   interested to continue the containerization of our services
>>>>> (which
>>>>>   was initially done with Docker & Docker-Distribution).
>>>>>   We're looking at how these containers could be managed by k8s one
>>>>>   day but way before that we plan to swap out Docker and join CRI-O
>>>>>   efforts, which seem to be using Podman + Buildah (among other
>>>>> things).
>>>>>
>>>>> I guess my wording wasn't the best but Alex explained way better here:
>>>>> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23op
>>>>> enstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52
>>>>>
>>>>> If I may have a chance to rephrase, I guess our current intention is to
>>>>> continue our containerization and investigate how we can improve our
>>>>> tooling to better orchestrate the containers.
>>>>> We have a nice interface (openstack/paunch) that allows us to run
>>>>> multiple container backends, and we're currently looking outside of
>>>>> Docker to see how we could solve our current challenges with the new
>>>>> tools.
>>>>> We're looking at CRI-O because it happens to be a project with a great
>>>>> community, focusing 

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Steve Baker]

On 24/08/18 04:36, Fox, Kevin M wrote:

Or use kubelet in standalone mode. It can be configured for either Cri-o or 
Docker. You can drive the static manifests from heat/ansible per host as normal 
and it would be a step in the greater direction of getting to Kubernetes 
without needing the whole thing at once, if that is the goal.


I was an advocate for using kubectl standalone for our container 
orchestration needs well before we started containerizing TripleO. After 
talking to a few kubernetes folk I cooled on the idea, because they had 
one of two responses:
- cautious encouragement, but uncertainty about kubectl standalone 
interface support and consideration for those use cases

- googly eyed incomprehension followed by "why would you do that??"

This was a while ago now so this could be worth revisiting in the 
future. We'll be making gradual changes, the first of which is using 
podman to manage single containers. However podman has native support 
for the pod format, so I'm hoping we can switch to that once this 
transition is complete. Then evaluating kubectl becomes much easier.




Question. Rather then writing a middle layer to abstract both container 
engines, couldn't you just use CRI? CRI is CRI-O's native language, and there 
is support already for Docker as well.


We're not writing a middle layer, we're leveraging one which is already 
there.


CRI-O is a socket interface and podman is a CLI interface that both sit 
on top of the exact same Go libraries. At this point, switching to 
podman needs a much lower development effort because we're replacing 
docker CLI calls.

Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Thursday, August 23, 2018 8:36 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice API 
calls

Dan, thanks for the details and answers. Appreciated.

Best,
-jay

On 08/23/2018 10:50 AM, Dan Prince wrote:

On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes  wrote:

On 08/15/2018 04:01 PM, Emilien Macchi wrote:

On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi mailto:emil...@redhat.com>> wrote:

  More seriously here: there is an ongoing effort to converge the
  tools around containerization within Red Hat, and we, TripleO are
  interested to continue the containerization of our services (which
  was initially done with Docker & Docker-Distribution).
  We're looking at how these containers could be managed by k8s one
  day but way before that we plan to swap out Docker and join CRI-O
  efforts, which seem to be using Podman + Buildah (among other things).

I guess my wording wasn't the best but Alex explained way better here:
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52

If I may have a chance to rephrase, I guess our current intention is to
continue our containerization and investigate how we can improve our
tooling to better orchestrate the containers.
We have a nice interface (openstack/paunch) that allows us to run
multiple container backends, and we're currently looking outside of
Docker to see how we could solve our current challenges with the new tools.
We're looking at CRI-O because it happens to be a project with a great
community, focusing on some problems that we, TripleO have been facing
since we containerized our services.

We're doing all of this in the open, so feel free to ask any question.

I appreciate your response, Emilien, thank you. Alex' responses to
Jeremy on the #openstack-tc channel were informative, thank you Alex.

For now, it *seems* to me that all of the chosen tooling is very Red Hat
centric. Which makes sense to me, considering Triple-O is a Red Hat product.

Perhaps a slight clarification here is needed. "Director" is a Red Hat
product. TripleO is an upstream project that is now largely driven by
Red Hat and is today marked as single vendor. We welcome others to
contribute to the project upstream just like anybody else.

And for those who don't know the history the TripleO project was once
multi-vendor as well. So a lot of the abstractions we have in place
could easily be extended to support distro specific implementation
details. (Kind of what I view podman as in the scope of this thread).


I don't know how much of the current reinvention of container runtimes
and various tooling around containers is the result of politics. I don't
know how much is the result of certain companies wanting to "own" the
container stack from top to bottom. Or how much is a result of technical
disagreements that simply cannot (or will not) be resolved among
contributors in the container development ecosystem.

Or is it some combination of the above? I don't know.

What I *do* know is that the current "NIH du jour" mentality currently
playing itself out in the container ecosystem -- reminding me very much
of the 

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Dmitry Tantsur]

On 08/17/2018 07:45 AM, Cédric Jeanneret wrote:



On 08/17/2018 12:25 AM, Steve Baker wrote:



On 15/08/18 21:32, Cédric Jeanneret wrote:

Dear Community,

As you may know, a move toward Podman as replacement of Docker is starting.

One of the issues with podman is the lack of daemon, precisely the lack
of a socket allowing to send commands and get a "computer formatted
output" (like JSON or YAML or...).

In order to work that out, Podman has added support for varlink¹, using
the "socket activation" feature in Systemd.

On my side, I would like to push forward the integration of varlink in
TripleO deployed containers, especially since it will allow the following:
# proper interface with Paunch (via python link)

I'm not sure this would be desirable. If we're going to all container
management via a socket I think we'd be better supported by using CRI-O.
One of the advantages I see of podman is being able to manage services
with systemd again.


Using the socket wouldn't prevent a "per service" systemd unit. Varlink
would just provide another way to manage the containers.
It's NOT like the docker daemon - it will not manage the containers on
startup for example. It's just an API endpoint, without any "automated
powers".

See it as an interesting complement to the CLI, allowing to access
containers data easily with a computer-oriented language like python3.


# a way to manage containers from within specific containers (think
"healthcheck", "monitoring") by mounting the socket as a shared volume

# a way to get container statistics (think "metrics")

# a way, if needed, to get an ansible module being able to talk to
podman (JSON is always better than plain text)

# a way to secure the accesses to Podman management (we have to define
how varlink talks to Podman, maybe providing dedicated socket with
dedicated rights so that we can have dedicated users for specific tasks)

Some of these cases might prove to be useful, but I do wonder if just
making podman calls would be just as simple without the complexity of
having another host-level service to manage. We can still do podman
operations inside containers by bind-mounting in the container state.


I wouldn't mount the container state as-is for mainly security reasons.
I'd rather get the varlink abstraction rather than the plain `podman'
CLI - in addition, it is far, far easier for applications to get a
proper JSON instead of some random plain text - even if `podman' seems
to get a "--format" option. I really dislike calling "subprocess" things
when there is a nice API interface - maybe that's just me ;).

In addition, apparently the state is managed by some sqlite DB -
concurrent accesses to that DB isn't really a good idea, we really don't
want a corruption, do we?


IIRC sqlite handles concurrent accesses, it just does them slowly.






That said, I have some questions:
° Does any of you have some experience with varlink and podman interface?
° What do you think about that integration wish?
° Does any of you have concern with this possible addition?

I do worry a bit that it is advocating for a solution before we really
understand the problems. The biggest unknown for me is what we do about
healthchecks. Maybe varlink is part of the solution here, or maybe its a
systemd timer which executes the healthcheck and restarts the service
when required.


Maybe. My main concern is: would it be interesting to compare both
solutions?
The Healthchecks are clearly docker-specific, no interface exists atm in
the libpod for that. So we have to mimic it in the best way.
Maybe the healthchecks place is in systemd, and varlink would be used
only for external monitoring and metrics. That would also be a nice way
to explore.

I would not focus on only one of the possibilities I've listed. There
are probably even more possibilities I didn't see - once we get a proper
socket, anything is possible, the good and the bad ;).


Thank you for your feedback and ideas.

Have a great day (or evening, or whatever suits the time you're reading
this ;))!

C.


¹ https://www.projectatomic.io/blog/2018/05/podman-varlink/




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Bogdan Dobrelya]

On 8/23/18 6:36 PM, Fox, Kevin M wrote:

Or use kubelet in standalone mode. It can be configured for either Cri-o or 
Docker. You can drive the static manifests from heat/ansible per host as normal 
and it would be a step in the greater direction of getting to Kubernetes 
without needing the whole thing at once, if that is the goal.


I like the idea to adopt k8s components early and deprecate paunch!
Just not that time had shown the plans for k8s integration in tripleo 
look too distant now and we need the solution today...




Thanks,
Kevin

From: Fox, Kevin M [kevin@pnnl.gov]
Sent: Thursday, August 23, 2018 9:22 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice API 
calls

Question. Rather then writing a middle layer to abstract both container 
engines, couldn't you just use CRI? CRI is CRI-O's native language, and there 
is support already for Docker as well.

Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Thursday, August 23, 2018 8:36 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice API 
calls

Dan, thanks for the details and answers. Appreciated.

Best,
-jay

On 08/23/2018 10:50 AM, Dan Prince wrote:

On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes  wrote:


On 08/15/2018 04:01 PM, Emilien Macchi wrote:

On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi mailto:emil...@redhat.com>> wrote:

  More seriously here: there is an ongoing effort to converge the
  tools around containerization within Red Hat, and we, TripleO are
  interested to continue the containerization of our services (which
  was initially done with Docker & Docker-Distribution).
  We're looking at how these containers could be managed by k8s one
  day but way before that we plan to swap out Docker and join CRI-O
  efforts, which seem to be using Podman + Buildah (among other things).

I guess my wording wasn't the best but Alex explained way better here:
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52

If I may have a chance to rephrase, I guess our current intention is to
continue our containerization and investigate how we can improve our
tooling to better orchestrate the containers.
We have a nice interface (openstack/paunch) that allows us to run
multiple container backends, and we're currently looking outside of
Docker to see how we could solve our current challenges with the new tools.
We're looking at CRI-O because it happens to be a project with a great
community, focusing on some problems that we, TripleO have been facing
since we containerized our services.

We're doing all of this in the open, so feel free to ask any question.


I appreciate your response, Emilien, thank you. Alex' responses to
Jeremy on the #openstack-tc channel were informative, thank you Alex.

For now, it *seems* to me that all of the chosen tooling is very Red Hat
centric. Which makes sense to me, considering Triple-O is a Red Hat product.


Perhaps a slight clarification here is needed. "Director" is a Red Hat
product. TripleO is an upstream project that is now largely driven by
Red Hat and is today marked as single vendor. We welcome others to
contribute to the project upstream just like anybody else.

And for those who don't know the history the TripleO project was once
multi-vendor as well. So a lot of the abstractions we have in place
could easily be extended to support distro specific implementation
details. (Kind of what I view podman as in the scope of this thread).



I don't know how much of the current reinvention of container runtimes
and various tooling around containers is the result of politics. I don't
know how much is the result of certain companies wanting to "own" the
container stack from top to bottom. Or how much is a result of technical
disagreements that simply cannot (or will not) be resolved among
contributors in the container development ecosystem.

Or is it some combination of the above? I don't know.

What I *do* know is that the current "NIH du jour" mentality currently
playing itself out in the container ecosystem -- reminding me very much
of the Javascript ecosystem -- makes it difficult for any potential
*consumers* of container libraries, runtimes or applications to be
confident that any choice they make towards one of the other will be the
*right* choice or even a *possible* choice next year -- or next week.
Perhaps this is why things like openstack/paunch exist -- to give you
options if something doesn't pan out.


This is exactly why paunch exists.

Re, the podman thing I look at it as an implementation detail. The
good news is that given it is almost a parity replacement for what we
already use we'll still contribute to the OpenStack community

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Fox, Kevin M]

Or use kubelet in standalone mode. It can be configured for either Cri-o or 
Docker. You can drive the static manifests from heat/ansible per host as normal 
and it would be a step in the greater direction of getting to Kubernetes 
without needing the whole thing at once, if that is the goal.

Thanks,
Kevin

From: Fox, Kevin M [kevin@pnnl.gov]
Sent: Thursday, August 23, 2018 9:22 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice API 
calls

Question. Rather then writing a middle layer to abstract both container 
engines, couldn't you just use CRI? CRI is CRI-O's native language, and there 
is support already for Docker as well.

Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Thursday, August 23, 2018 8:36 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice API 
calls

Dan, thanks for the details and answers. Appreciated.

Best,
-jay

On 08/23/2018 10:50 AM, Dan Prince wrote:
> On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes  wrote:
>>
>> On 08/15/2018 04:01 PM, Emilien Macchi wrote:
>>> On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi >> <mailto:emil...@redhat.com>> wrote:
>>>
>>>  More seriously here: there is an ongoing effort to converge the
>>>  tools around containerization within Red Hat, and we, TripleO are
>>>  interested to continue the containerization of our services (which
>>>  was initially done with Docker & Docker-Distribution).
>>>  We're looking at how these containers could be managed by k8s one
>>>  day but way before that we plan to swap out Docker and join CRI-O
>>>  efforts, which seem to be using Podman + Buildah (among other things).
>>>
>>> I guess my wording wasn't the best but Alex explained way better here:
>>> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52
>>>
>>> If I may have a chance to rephrase, I guess our current intention is to
>>> continue our containerization and investigate how we can improve our
>>> tooling to better orchestrate the containers.
>>> We have a nice interface (openstack/paunch) that allows us to run
>>> multiple container backends, and we're currently looking outside of
>>> Docker to see how we could solve our current challenges with the new tools.
>>> We're looking at CRI-O because it happens to be a project with a great
>>> community, focusing on some problems that we, TripleO have been facing
>>> since we containerized our services.
>>>
>>> We're doing all of this in the open, so feel free to ask any question.
>>
>> I appreciate your response, Emilien, thank you. Alex' responses to
>> Jeremy on the #openstack-tc channel were informative, thank you Alex.
>>
>> For now, it *seems* to me that all of the chosen tooling is very Red Hat
>> centric. Which makes sense to me, considering Triple-O is a Red Hat product.
>
> Perhaps a slight clarification here is needed. "Director" is a Red Hat
> product. TripleO is an upstream project that is now largely driven by
> Red Hat and is today marked as single vendor. We welcome others to
> contribute to the project upstream just like anybody else.
>
> And for those who don't know the history the TripleO project was once
> multi-vendor as well. So a lot of the abstractions we have in place
> could easily be extended to support distro specific implementation
> details. (Kind of what I view podman as in the scope of this thread).
>
>>
>> I don't know how much of the current reinvention of container runtimes
>> and various tooling around containers is the result of politics. I don't
>> know how much is the result of certain companies wanting to "own" the
>> container stack from top to bottom. Or how much is a result of technical
>> disagreements that simply cannot (or will not) be resolved among
>> contributors in the container development ecosystem.
>>
>> Or is it some combination of the above? I don't know.
>>
>> What I *do* know is that the current "NIH du jour" mentality currently
>> playing itself out in the container ecosystem -- reminding me very much
>> of the Javascript ecosystem -- makes it difficult for any potential
>> *consumers* of container libraries, runtimes or applications to be
>> confident that any choice they make towards one of the other will be the
>> *right* choice or even a *possible* choice next year -- or next week.
&g

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Bogdan Dobrelya]

On 8/23/18 6:22 PM, Fox, Kevin M wrote:

Question. Rather then writing a middle layer to abstract both container 
engines, couldn't you just use CRI? CRI is CRI-O's native language, and there 
is support already for Docker as well.


I may be messing up abstraction levels, but IMO when it's time to 
support CRI-O as well, paunch should handle that just like docker or 
podman. So nothing changes in the moving layers of tripleo components.
It's nice that CRI-O also supports docker and other runtimes, but not 
sure we want something in tripleo moving parts to become neither docker 
not podman nor CRI-O bound.




Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Thursday, August 23, 2018 8:36 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice API 
calls

Dan, thanks for the details and answers. Appreciated.

Best,
-jay

On 08/23/2018 10:50 AM, Dan Prince wrote:

On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes  wrote:


On 08/15/2018 04:01 PM, Emilien Macchi wrote:

On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi mailto:emil...@redhat.com>> wrote:

  More seriously here: there is an ongoing effort to converge the
  tools around containerization within Red Hat, and we, TripleO are
  interested to continue the containerization of our services (which
  was initially done with Docker & Docker-Distribution).
  We're looking at how these containers could be managed by k8s one
  day but way before that we plan to swap out Docker and join CRI-O
  efforts, which seem to be using Podman + Buildah (among other things).

I guess my wording wasn't the best but Alex explained way better here:
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52

If I may have a chance to rephrase, I guess our current intention is to
continue our containerization and investigate how we can improve our
tooling to better orchestrate the containers.
We have a nice interface (openstack/paunch) that allows us to run
multiple container backends, and we're currently looking outside of
Docker to see how we could solve our current challenges with the new tools.
We're looking at CRI-O because it happens to be a project with a great
community, focusing on some problems that we, TripleO have been facing
since we containerized our services.

We're doing all of this in the open, so feel free to ask any question.


I appreciate your response, Emilien, thank you. Alex' responses to
Jeremy on the #openstack-tc channel were informative, thank you Alex.

For now, it *seems* to me that all of the chosen tooling is very Red Hat
centric. Which makes sense to me, considering Triple-O is a Red Hat product.


Perhaps a slight clarification here is needed. "Director" is a Red Hat
product. TripleO is an upstream project that is now largely driven by
Red Hat and is today marked as single vendor. We welcome others to
contribute to the project upstream just like anybody else.

And for those who don't know the history the TripleO project was once
multi-vendor as well. So a lot of the abstractions we have in place
could easily be extended to support distro specific implementation
details. (Kind of what I view podman as in the scope of this thread).



I don't know how much of the current reinvention of container runtimes
and various tooling around containers is the result of politics. I don't
know how much is the result of certain companies wanting to "own" the
container stack from top to bottom. Or how much is a result of technical
disagreements that simply cannot (or will not) be resolved among
contributors in the container development ecosystem.

Or is it some combination of the above? I don't know.

What I *do* know is that the current "NIH du jour" mentality currently
playing itself out in the container ecosystem -- reminding me very much
of the Javascript ecosystem -- makes it difficult for any potential
*consumers* of container libraries, runtimes or applications to be
confident that any choice they make towards one of the other will be the
*right* choice or even a *possible* choice next year -- or next week.
Perhaps this is why things like openstack/paunch exist -- to give you
options if something doesn't pan out.


This is exactly why paunch exists.

Re, the podman thing I look at it as an implementation detail. The
good news is that given it is almost a parity replacement for what we
already use we'll still contribute to the OpenStack community in
similar ways. Ultimately whether you run 'docker run' or 'podman run'
you end up with the same thing as far as the existing TripleO
architecture goes.

Dan



You have a tough job. I wish you all the luck in the world in making
these decisions and hope politics and internal corporate management
decisions play as little

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Fox, Kevin M]

Question. Rather then writing a middle layer to abstract both container 
engines, couldn't you just use CRI? CRI is CRI-O's native language, and there 
is support already for Docker as well.

Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Thursday, August 23, 2018 8:36 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice API 
calls

Dan, thanks for the details and answers. Appreciated.

Best,
-jay

On 08/23/2018 10:50 AM, Dan Prince wrote:
> On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes  wrote:
>>
>> On 08/15/2018 04:01 PM, Emilien Macchi wrote:
>>> On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi >> <mailto:emil...@redhat.com>> wrote:
>>>
>>>  More seriously here: there is an ongoing effort to converge the
>>>  tools around containerization within Red Hat, and we, TripleO are
>>>  interested to continue the containerization of our services (which
>>>  was initially done with Docker & Docker-Distribution).
>>>  We're looking at how these containers could be managed by k8s one
>>>  day but way before that we plan to swap out Docker and join CRI-O
>>>  efforts, which seem to be using Podman + Buildah (among other things).
>>>
>>> I guess my wording wasn't the best but Alex explained way better here:
>>> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52
>>>
>>> If I may have a chance to rephrase, I guess our current intention is to
>>> continue our containerization and investigate how we can improve our
>>> tooling to better orchestrate the containers.
>>> We have a nice interface (openstack/paunch) that allows us to run
>>> multiple container backends, and we're currently looking outside of
>>> Docker to see how we could solve our current challenges with the new tools.
>>> We're looking at CRI-O because it happens to be a project with a great
>>> community, focusing on some problems that we, TripleO have been facing
>>> since we containerized our services.
>>>
>>> We're doing all of this in the open, so feel free to ask any question.
>>
>> I appreciate your response, Emilien, thank you. Alex' responses to
>> Jeremy on the #openstack-tc channel were informative, thank you Alex.
>>
>> For now, it *seems* to me that all of the chosen tooling is very Red Hat
>> centric. Which makes sense to me, considering Triple-O is a Red Hat product.
>
> Perhaps a slight clarification here is needed. "Director" is a Red Hat
> product. TripleO is an upstream project that is now largely driven by
> Red Hat and is today marked as single vendor. We welcome others to
> contribute to the project upstream just like anybody else.
>
> And for those who don't know the history the TripleO project was once
> multi-vendor as well. So a lot of the abstractions we have in place
> could easily be extended to support distro specific implementation
> details. (Kind of what I view podman as in the scope of this thread).
>
>>
>> I don't know how much of the current reinvention of container runtimes
>> and various tooling around containers is the result of politics. I don't
>> know how much is the result of certain companies wanting to "own" the
>> container stack from top to bottom. Or how much is a result of technical
>> disagreements that simply cannot (or will not) be resolved among
>> contributors in the container development ecosystem.
>>
>> Or is it some combination of the above? I don't know.
>>
>> What I *do* know is that the current "NIH du jour" mentality currently
>> playing itself out in the container ecosystem -- reminding me very much
>> of the Javascript ecosystem -- makes it difficult for any potential
>> *consumers* of container libraries, runtimes or applications to be
>> confident that any choice they make towards one of the other will be the
>> *right* choice or even a *possible* choice next year -- or next week.
>> Perhaps this is why things like openstack/paunch exist -- to give you
>> options if something doesn't pan out.
>
> This is exactly why paunch exists.
>
> Re, the podman thing I look at it as an implementation detail. The
> good news is that given it is almost a parity replacement for what we
> already use we'll still contribute to the OpenStack community in
> similar ways. Ultimately whether you run 'docker run' or 'podman run'
> you end up with the same thing as far as the existing TripleO
> architecture goes.
>
> Dan
>
>&g

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Jay Pipes]

Dan, thanks for the details and answers. Appreciated.

Best,
-jay

On 08/23/2018 10:50 AM, Dan Prince wrote:

On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes  wrote:


On 08/15/2018 04:01 PM, Emilien Macchi wrote:

On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi mailto:emil...@redhat.com>> wrote:

 More seriously here: there is an ongoing effort to converge the
 tools around containerization within Red Hat, and we, TripleO are
 interested to continue the containerization of our services (which
 was initially done with Docker & Docker-Distribution).
 We're looking at how these containers could be managed by k8s one
 day but way before that we plan to swap out Docker and join CRI-O
 efforts, which seem to be using Podman + Buildah (among other things).

I guess my wording wasn't the best but Alex explained way better here:
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52

If I may have a chance to rephrase, I guess our current intention is to
continue our containerization and investigate how we can improve our
tooling to better orchestrate the containers.
We have a nice interface (openstack/paunch) that allows us to run
multiple container backends, and we're currently looking outside of
Docker to see how we could solve our current challenges with the new tools.
We're looking at CRI-O because it happens to be a project with a great
community, focusing on some problems that we, TripleO have been facing
since we containerized our services.

We're doing all of this in the open, so feel free to ask any question.


I appreciate your response, Emilien, thank you. Alex' responses to
Jeremy on the #openstack-tc channel were informative, thank you Alex.

For now, it *seems* to me that all of the chosen tooling is very Red Hat
centric. Which makes sense to me, considering Triple-O is a Red Hat product.


Perhaps a slight clarification here is needed. "Director" is a Red Hat
product. TripleO is an upstream project that is now largely driven by
Red Hat and is today marked as single vendor. We welcome others to
contribute to the project upstream just like anybody else.

And for those who don't know the history the TripleO project was once
multi-vendor as well. So a lot of the abstractions we have in place
could easily be extended to support distro specific implementation
details. (Kind of what I view podman as in the scope of this thread).



I don't know how much of the current reinvention of container runtimes
and various tooling around containers is the result of politics. I don't
know how much is the result of certain companies wanting to "own" the
container stack from top to bottom. Or how much is a result of technical
disagreements that simply cannot (or will not) be resolved among
contributors in the container development ecosystem.

Or is it some combination of the above? I don't know.

What I *do* know is that the current "NIH du jour" mentality currently
playing itself out in the container ecosystem -- reminding me very much
of the Javascript ecosystem -- makes it difficult for any potential
*consumers* of container libraries, runtimes or applications to be
confident that any choice they make towards one of the other will be the
*right* choice or even a *possible* choice next year -- or next week.
Perhaps this is why things like openstack/paunch exist -- to give you
options if something doesn't pan out.


This is exactly why paunch exists.

Re, the podman thing I look at it as an implementation detail. The
good news is that given it is almost a parity replacement for what we
already use we'll still contribute to the OpenStack community in
similar ways. Ultimately whether you run 'docker run' or 'podman run'
you end up with the same thing as far as the existing TripleO
architecture goes.

Dan



You have a tough job. I wish you all the luck in the world in making
these decisions and hope politics and internal corporate management
decisions play as little a role in them as possible.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Dan Prince]

On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes  wrote:
>
> On 08/15/2018 04:01 PM, Emilien Macchi wrote:
> > On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi  > > wrote:
> >
> > More seriously here: there is an ongoing effort to converge the
> > tools around containerization within Red Hat, and we, TripleO are
> > interested to continue the containerization of our services (which
> > was initially done with Docker & Docker-Distribution).
> > We're looking at how these containers could be managed by k8s one
> > day but way before that we plan to swap out Docker and join CRI-O
> > efforts, which seem to be using Podman + Buildah (among other things).
> >
> > I guess my wording wasn't the best but Alex explained way better here:
> > http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52
> >
> > If I may have a chance to rephrase, I guess our current intention is to
> > continue our containerization and investigate how we can improve our
> > tooling to better orchestrate the containers.
> > We have a nice interface (openstack/paunch) that allows us to run
> > multiple container backends, and we're currently looking outside of
> > Docker to see how we could solve our current challenges with the new tools.
> > We're looking at CRI-O because it happens to be a project with a great
> > community, focusing on some problems that we, TripleO have been facing
> > since we containerized our services.
> >
> > We're doing all of this in the open, so feel free to ask any question.
>
> I appreciate your response, Emilien, thank you. Alex' responses to
> Jeremy on the #openstack-tc channel were informative, thank you Alex.
>
> For now, it *seems* to me that all of the chosen tooling is very Red Hat
> centric. Which makes sense to me, considering Triple-O is a Red Hat product.

Perhaps a slight clarification here is needed. "Director" is a Red Hat
product. TripleO is an upstream project that is now largely driven by
Red Hat and is today marked as single vendor. We welcome others to
contribute to the project upstream just like anybody else.

And for those who don't know the history the TripleO project was once
multi-vendor as well. So a lot of the abstractions we have in place
could easily be extended to support distro specific implementation
details. (Kind of what I view podman as in the scope of this thread).

>
> I don't know how much of the current reinvention of container runtimes
> and various tooling around containers is the result of politics. I don't
> know how much is the result of certain companies wanting to "own" the
> container stack from top to bottom. Or how much is a result of technical
> disagreements that simply cannot (or will not) be resolved among
> contributors in the container development ecosystem.
>
> Or is it some combination of the above? I don't know.
>
> What I *do* know is that the current "NIH du jour" mentality currently
> playing itself out in the container ecosystem -- reminding me very much
> of the Javascript ecosystem -- makes it difficult for any potential
> *consumers* of container libraries, runtimes or applications to be
> confident that any choice they make towards one of the other will be the
> *right* choice or even a *possible* choice next year -- or next week.
> Perhaps this is why things like openstack/paunch exist -- to give you
> options if something doesn't pan out.

This is exactly why paunch exists.

Re, the podman thing I look at it as an implementation detail. The
good news is that given it is almost a parity replacement for what we
already use we'll still contribute to the OpenStack community in
similar ways. Ultimately whether you run 'docker run' or 'podman run'
you end up with the same thing as far as the existing TripleO
architecture goes.

Dan

>
> You have a tough job. I wish you all the luck in the world in making
> these decisions and hope politics and internal corporate management
> decisions play as little a role in them as possible.
>
> Best,
> -jay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Cédric Jeanneret]

On 08/17/2018 12:25 AM, Steve Baker wrote:
> 
> 
> On 15/08/18 21:32, Cédric Jeanneret wrote:
>> Dear Community,
>>
>> As you may know, a move toward Podman as replacement of Docker is starting.
>>
>> One of the issues with podman is the lack of daemon, precisely the lack
>> of a socket allowing to send commands and get a "computer formatted
>> output" (like JSON or YAML or...).
>>
>> In order to work that out, Podman has added support for varlink¹, using
>> the "socket activation" feature in Systemd.
>>
>> On my side, I would like to push forward the integration of varlink in
>> TripleO deployed containers, especially since it will allow the following:
>> # proper interface with Paunch (via python link)
> I'm not sure this would be desirable. If we're going to all container
> management via a socket I think we'd be better supported by using CRI-O.
> One of the advantages I see of podman is being able to manage services
> with systemd again.

Using the socket wouldn't prevent a "per service" systemd unit. Varlink
would just provide another way to manage the containers.
It's NOT like the docker daemon - it will not manage the containers on
startup for example. It's just an API endpoint, without any "automated
powers".

See it as an interesting complement to the CLI, allowing to access
containers data easily with a computer-oriented language like python3.

>> # a way to manage containers from within specific containers (think
>> "healthcheck", "monitoring") by mounting the socket as a shared volume
>>
>> # a way to get container statistics (think "metrics")
>>
>> # a way, if needed, to get an ansible module being able to talk to
>> podman (JSON is always better than plain text)
>>
>> # a way to secure the accesses to Podman management (we have to define
>> how varlink talks to Podman, maybe providing dedicated socket with
>> dedicated rights so that we can have dedicated users for specific tasks)
> Some of these cases might prove to be useful, but I do wonder if just
> making podman calls would be just as simple without the complexity of
> having another host-level service to manage. We can still do podman
> operations inside containers by bind-mounting in the container state.

I wouldn't mount the container state as-is for mainly security reasons.
I'd rather get the varlink abstraction rather than the plain `podman'
CLI - in addition, it is far, far easier for applications to get a
proper JSON instead of some random plain text - even if `podman' seems
to get a "--format" option. I really dislike calling "subprocess" things
when there is a nice API interface - maybe that's just me ;).

In addition, apparently the state is managed by some sqlite DB -
concurrent accesses to that DB isn't really a good idea, we really don't
want a corruption, do we?

> 
>> That said, I have some questions:
>> ° Does any of you have some experience with varlink and podman interface?
>> ° What do you think about that integration wish?
>> ° Does any of you have concern with this possible addition?
> I do worry a bit that it is advocating for a solution before we really
> understand the problems. The biggest unknown for me is what we do about
> healthchecks. Maybe varlink is part of the solution here, or maybe its a
> systemd timer which executes the healthcheck and restarts the service
> when required.

Maybe. My main concern is: would it be interesting to compare both
solutions?
The Healthchecks are clearly docker-specific, no interface exists atm in
the libpod for that. So we have to mimic it in the best way.
Maybe the healthchecks place is in systemd, and varlink would be used
only for external monitoring and metrics. That would also be a nice way
to explore.

I would not focus on only one of the possibilities I've listed. There
are probably even more possibilities I didn't see - once we get a proper
socket, anything is possible, the good and the bad ;).

>> Thank you for your feedback and ideas.
>>
>> Have a great day (or evening, or whatever suits the time you're reading
>> this ;))!
>>
>> C.
>>
>>
>> ¹ https://www.projectatomic.io/blog/2018/05/podman-varlink/
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Cédric Jeanneret
Software Engineer
DFG:DF



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Cédric Jeanneret]

>> On my side, I would like to push forward the integration of varlink in
>> TripleO deployed containers, especially since it will allow the
>> following:
>> # proper interface with Paunch (via python link)
> 
> "integration of varlink in TripleO deployed containers" sounds like we'd
> need to make some changes to the containers themselves, but is that the
> case? As i read the docs, it seems like a management API wrapper for
> Podman, so just an alternative interface to Podman CLI. I'd expect we'd
> use varlink from Paunch, but probably not from the containers
> themselves? (Perhaps that's what you meant, just making sure we're on
> the same page.)

In fact, the "podman varlink thing" is already distributed with the
podman package. In order to activate that socket, we just need to
activate a systemd unit that will create the socket - the "service"
itself is activated only when the socket is accessed.
The only thing we might need to add as a package is the libvarlink-util
(provides the "varlink" command) and the python3 binding
(python3-libvarlink iirc).

Varlink "activation" itself doesn't affect the containers.

And yep, it's just an alternative to `podman' CLI, providing a nicer
computer interface with python3 bindings in order to avoid
"subprocess.Popen" and the like, providing a nice JSON output (well.
mostly - I detected at least one output not properly formatted).

> 
>>
>> # a way to manage containers from within specific containers (think
>> "healthcheck", "monitoring") by mounting the socket as a shared volume
> 
> I think healthchecks are currently quite Docker-specific, so we could
> have a Podman-specific alternative here. We should be careful about how
> much container runtime specificity we introduce and keep though, and
> we'll probably have to amend our tools (e.g. pre-upgrade validations
> [2]) to work with both, at least until we decide whether to really make
> a full transition to Podman or not.

Of course - I just listed the possibilities activating varlink would
provide - proper PoCs and tests are to be done ;).

> 
>>
>> # a way to get container statistics (think "metrics")
>>
>> # a way, if needed, to get an ansible module being able to talk to
>> podman (JSON is always better than plain text)
>>
>> # a way to secure the accesses to Podman management (we have to define
>> how varlink talks to Podman, maybe providing dedicated socket with
>> dedicated rights so that we can have dedicated users for specific tasks)
>>
>> That said, I have some questions:
>> ° Does any of you have some experience with varlink and podman interface?
>> ° What do you think about that integration wish?
>> ° Does any of you have concern with this possible addition?
> 
> I like it, but we should probably sync up with Podman community if they
> consider varlink a "supported" interface for controlling Podman, and
> it's not just an experiment which will vanish. To me it certainly looks
> like a much better programmable interface than composing CLI calls and
> parsing their output, but we should make sure Podman folks think so too :)

I think we can say "supported", since they provide the varlink socket
and service directly in podman package. In addition, it was a request:
https://trello.com/c/8RQ6ZF4A/565-8-add-podman-varlink-subcommand
https://github.com/containers/libpod/pull/627

and it's pretty well followed regarding both issues and libpod API updates.

I'll ping them in order to validate that feeling.

> 
> Thanks for looking into this
> 
> Jirka
> 
> [2] https://review.openstack.org/#/c/582502/
> 
>>
>> Thank you for your feedback and ideas.
>>
>> Have a great day (or evening, or whatever suits the time you're reading
>> this ;))!
>>
>> C.
>>
>>
>> ¹ https://www.projectatomic.io/blog/2018/05/podman-varlink/
>>
>>
>>
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Cédric Jeanneret
Software Engineer
DFG:DF



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Steve Baker]

On 15/08/18 21:32, Cédric Jeanneret wrote:

Dear Community,

As you may know, a move toward Podman as replacement of Docker is starting.

One of the issues with podman is the lack of daemon, precisely the lack
of a socket allowing to send commands and get a "computer formatted
output" (like JSON or YAML or...).

In order to work that out, Podman has added support for varlink¹, using
the "socket activation" feature in Systemd.

On my side, I would like to push forward the integration of varlink in
TripleO deployed containers, especially since it will allow the following:
# proper interface with Paunch (via python link)
I'm not sure this would be desirable. If we're going to all container 
management via a socket I think we'd be better supported by using CRI-O. 
One of the advantages I see of podman is being able to manage services 
with systemd again.

# a way to manage containers from within specific containers (think
"healthcheck", "monitoring") by mounting the socket as a shared volume

# a way to get container statistics (think "metrics")

# a way, if needed, to get an ansible module being able to talk to
podman (JSON is always better than plain text)

# a way to secure the accesses to Podman management (we have to define
how varlink talks to Podman, maybe providing dedicated socket with
dedicated rights so that we can have dedicated users for specific tasks)
Some of these cases might prove to be useful, but I do wonder if just 
making podman calls would be just as simple without the complexity of 
having another host-level service to manage. We can still do podman 
operations inside containers by bind-mounting in the container state.



That said, I have some questions:
° Does any of you have some experience with varlink and podman interface?
° What do you think about that integration wish?
° Does any of you have concern with this possible addition?
I do worry a bit that it is advocating for a solution before we really 
understand the problems. The biggest unknown for me is what we do about 
healthchecks. Maybe varlink is part of the solution here, or maybe its a 
systemd timer which executes the healthcheck and restarts the service 
when required.

Thank you for your feedback and ideas.

Have a great day (or evening, or whatever suits the time you're reading
this ;))!

C.


¹ https://www.projectatomic.io/blog/2018/05/podman-varlink/




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Jiří Stránský]

On 16.8.2018 07:39, Cédric Jeanneret wrote:



On 08/16/2018 12:10 AM, Jason E. Rist wrote:

On 08/15/2018 03:32 AM, Cédric Jeanneret wrote:

Dear Community,

As you may know, a move toward Podman as replacement of Docker is starting.

One of the issues with podman is the lack of daemon, precisely the lack
of a socket allowing to send commands and get a "computer formatted
output" (like JSON or YAML or...).

In order to work that out, Podman has added support for varlink¹, using
the "socket activation" feature in Systemd.

On my side, I would like to push forward the integration of varlink in
TripleO deployed containers, especially since it will allow the following:
# proper interface with Paunch (via python link)

# a way to manage containers from within specific containers (think
"healthcheck", "monitoring") by mounting the socket as a shared volume

# a way to get container statistics (think "metrics")

# a way, if needed, to get an ansible module being able to talk to
podman (JSON is always better than plain text)

# a way to secure the accesses to Podman management (we have to define
how varlink talks to Podman, maybe providing dedicated socket with
dedicated rights so that we can have dedicated users for specific tasks)

That said, I have some questions:
° Does any of you have some experience with varlink and podman interface?
° What do you think about that integration wish?
° Does any of you have concern with this possible addition?

Thank you for your feedback and ideas.

Have a great day (or evening, or whatever suits the time you're reading
this ;))!

C.


¹ https://www.projectatomic.io/blog/2018/05/podman-varlink/




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



How might this effect upgrades?


What exactly? addition of varlink, or the whole podman thingy? The
question was more about "varlink" than "podman" in fact - I should maybe
have worded things otherwise... ?


Varlink shouldn't be a problem as it's just an additive interface. 
Switching container runtime might be a bit difficult though :)


When running any upgrade, we stop any containers that need updating, and 
replace them with new ones. In theory we could just as well start the 
new ones using a different runtime, all we need is to keep the same bind 
mounts etc. What would need to be investigated is whether support for 
this (stopping on one runtime, starting on another) needs to be 
implemented directly into tools like Paunch and Pacemaker, or if we can 
handle this one-time scenario just with additional code in 
upgrade_tasks. It might be a combination of both.


Problem might come with sidecar containers for Neutron, which generally 
don't like being restarted (it can induce data plane downtime). Advanced 
hackery might be needed on this front... :)


Either way i think we'd have to do some PoC of such migration before 
fully committing to it.


Jirka





-J





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Jiří Stránský]

On 15.8.2018 11:32, Cédric Jeanneret wrote:

Dear Community,

As you may know, a move toward Podman as replacement of Docker is starting.

One of the issues with podman is the lack of daemon, precisely the lack
of a socket allowing to send commands and get a "computer formatted
output" (like JSON or YAML or...).

In order to work that out, Podman has added support for varlink¹, using
the "socket activation" feature in Systemd.

On my side, I would like to push forward the integration of varlink in
TripleO deployed containers, especially since it will allow the following:
# proper interface with Paunch (via python link)


"integration of varlink in TripleO deployed containers" sounds like we'd 
need to make some changes to the containers themselves, but is that the 
case? As i read the docs, it seems like a management API wrapper for 
Podman, so just an alternative interface to Podman CLI. I'd expect we'd 
use varlink from Paunch, but probably not from the containers 
themselves? (Perhaps that's what you meant, just making sure we're on 
the same page.)




# a way to manage containers from within specific containers (think
"healthcheck", "monitoring") by mounting the socket as a shared volume


I think healthchecks are currently quite Docker-specific, so we could 
have a Podman-specific alternative here. We should be careful about how 
much container runtime specificity we introduce and keep though, and 
we'll probably have to amend our tools (e.g. pre-upgrade validations 
[2]) to work with both, at least until we decide whether to really make 
a full transition to Podman or not.




# a way to get container statistics (think "metrics")

# a way, if needed, to get an ansible module being able to talk to
podman (JSON is always better than plain text)

# a way to secure the accesses to Podman management (we have to define
how varlink talks to Podman, maybe providing dedicated socket with
dedicated rights so that we can have dedicated users for specific tasks)

That said, I have some questions:
° Does any of you have some experience with varlink and podman interface?
° What do you think about that integration wish?
° Does any of you have concern with this possible addition?


I like it, but we should probably sync up with Podman community if they 
consider varlink a "supported" interface for controlling Podman, and 
it's not just an experiment which will vanish. To me it certainly looks 
like a much better programmable interface than composing CLI calls and 
parsing their output, but we should make sure Podman folks think so too :)


Thanks for looking into this

Jirka

[2] https://review.openstack.org/#/c/582502/



Thank you for your feedback and ideas.

Have a great day (or evening, or whatever suits the time you're reading
this ;))!

C.


¹ https://www.projectatomic.io/blog/2018/05/podman-varlink/




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Jiří Stránský]

On 16.8.2018 10:38, Steven Hardy wrote:

On Wed, Aug 15, 2018 at 10:48 PM, Jay Pipes  wrote:

On 08/15/2018 04:01 PM, Emilien Macchi wrote:


On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi mailto:emil...@redhat.com>> wrote:

 More seriously here: there is an ongoing effort to converge the
 tools around containerization within Red Hat, and we, TripleO are
 interested to continue the containerization of our services (which
 was initially done with Docker & Docker-Distribution).
 We're looking at how these containers could be managed by k8s one
 day but way before that we plan to swap out Docker and join CRI-O
 efforts, which seem to be using Podman + Buildah (among other things).

I guess my wording wasn't the best but Alex explained way better here:

http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52

If I may have a chance to rephrase, I guess our current intention is to
continue our containerization and investigate how we can improve our tooling
to better orchestrate the containers.
We have a nice interface (openstack/paunch) that allows us to run multiple
container backends, and we're currently looking outside of Docker to see how
we could solve our current challenges with the new tools.
We're looking at CRI-O because it happens to be a project with a great
community, focusing on some problems that we, TripleO have been facing since
we containerized our services.

We're doing all of this in the open, so feel free to ask any question.



I appreciate your response, Emilien, thank you. Alex' responses to Jeremy on
the #openstack-tc channel were informative, thank you Alex.

For now, it *seems* to me that all of the chosen tooling is very Red Hat
centric. Which makes sense to me, considering Triple-O is a Red Hat product.


Just as a point of clarification - TripleO is an OpenStack project,
and yes there is a downstream product derived from it, but we could
e.g support multiple container backends in TripleO if there was
community interest in supporting that.

Also I think Alex already explained that fairly clearly in the IRC
link that this is initially about proving our existing abstractions
work to enable alternate container backends.


+1, and with my upgrade-centric hat on, we've had a fair share of 
trouble with Docker -- update of the daemon causing otherwise needless 
downtime of services and sometimes data plane too. Most recent example i 
can think of is here [1][2] -- satisfactory solution still doesn't 
exist. So my 2 cents: i am very interested in exploring alternative 
container runtimes, and daemon-less sounds to me like a promising direction.


Jirka

[1] https://bugs.launchpad.net/tripleo/+bug/1777146
[2] https://review.openstack.org/#/c/575758/1/puppet/services/docker.yaml



Thanks,

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Steven Hardy]

On Wed, Aug 15, 2018 at 10:48 PM, Jay Pipes  wrote:
> On 08/15/2018 04:01 PM, Emilien Macchi wrote:
>>
>> On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi > > wrote:
>>
>> More seriously here: there is an ongoing effort to converge the
>> tools around containerization within Red Hat, and we, TripleO are
>> interested to continue the containerization of our services (which
>> was initially done with Docker & Docker-Distribution).
>> We're looking at how these containers could be managed by k8s one
>> day but way before that we plan to swap out Docker and join CRI-O
>> efforts, which seem to be using Podman + Buildah (among other things).
>>
>> I guess my wording wasn't the best but Alex explained way better here:
>>
>> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52
>>
>> If I may have a chance to rephrase, I guess our current intention is to
>> continue our containerization and investigate how we can improve our tooling
>> to better orchestrate the containers.
>> We have a nice interface (openstack/paunch) that allows us to run multiple
>> container backends, and we're currently looking outside of Docker to see how
>> we could solve our current challenges with the new tools.
>> We're looking at CRI-O because it happens to be a project with a great
>> community, focusing on some problems that we, TripleO have been facing since
>> we containerized our services.
>>
>> We're doing all of this in the open, so feel free to ask any question.
>
>
> I appreciate your response, Emilien, thank you. Alex' responses to Jeremy on
> the #openstack-tc channel were informative, thank you Alex.
>
> For now, it *seems* to me that all of the chosen tooling is very Red Hat
> centric. Which makes sense to me, considering Triple-O is a Red Hat product.

Just as a point of clarification - TripleO is an OpenStack project,
and yes there is a downstream product derived from it, but we could
e.g support multiple container backends in TripleO if there was
community interest in supporting that.

Also I think Alex already explained that fairly clearly in the IRC
link that this is initially about proving our existing abstractions
work to enable alternate container backends.

Thanks,

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Cédric Jeanneret]

On 08/16/2018 12:10 AM, Jason E. Rist wrote:
> On 08/15/2018 03:32 AM, Cédric Jeanneret wrote:
>> Dear Community,
>>
>> As you may know, a move toward Podman as replacement of Docker is starting.
>>
>> One of the issues with podman is the lack of daemon, precisely the lack
>> of a socket allowing to send commands and get a "computer formatted
>> output" (like JSON or YAML or...).
>>
>> In order to work that out, Podman has added support for varlink¹, using
>> the "socket activation" feature in Systemd.
>>
>> On my side, I would like to push forward the integration of varlink in
>> TripleO deployed containers, especially since it will allow the following:
>> # proper interface with Paunch (via python link)
>>
>> # a way to manage containers from within specific containers (think
>> "healthcheck", "monitoring") by mounting the socket as a shared volume
>>
>> # a way to get container statistics (think "metrics")
>>
>> # a way, if needed, to get an ansible module being able to talk to
>> podman (JSON is always better than plain text)
>>
>> # a way to secure the accesses to Podman management (we have to define
>> how varlink talks to Podman, maybe providing dedicated socket with
>> dedicated rights so that we can have dedicated users for specific tasks)
>>
>> That said, I have some questions:
>> ° Does any of you have some experience with varlink and podman interface?
>> ° What do you think about that integration wish?
>> ° Does any of you have concern with this possible addition?
>>
>> Thank you for your feedback and ideas.
>>
>> Have a great day (or evening, or whatever suits the time you're reading
>> this ;))!
>>
>> C.
>>
>>
>> ¹ https://www.projectatomic.io/blog/2018/05/podman-varlink/
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> How might this effect upgrades?

What exactly? addition of varlink, or the whole podman thingy? The
question was more about "varlink" than "podman" in fact - I should maybe
have worded things otherwise... ?

> 
> -J
> 

-- 
Cédric Jeanneret
Software Engineer
DFG:DF



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Jason E. Rist]

On 08/15/2018 03:32 AM, Cédric Jeanneret wrote:
> Dear Community,
> 
> As you may know, a move toward Podman as replacement of Docker is starting.
> 
> One of the issues with podman is the lack of daemon, precisely the lack
> of a socket allowing to send commands and get a "computer formatted
> output" (like JSON or YAML or...).
> 
> In order to work that out, Podman has added support for varlink¹, using
> the "socket activation" feature in Systemd.
> 
> On my side, I would like to push forward the integration of varlink in
> TripleO deployed containers, especially since it will allow the following:
> # proper interface with Paunch (via python link)
> 
> # a way to manage containers from within specific containers (think
> "healthcheck", "monitoring") by mounting the socket as a shared volume
> 
> # a way to get container statistics (think "metrics")
> 
> # a way, if needed, to get an ansible module being able to talk to
> podman (JSON is always better than plain text)
> 
> # a way to secure the accesses to Podman management (we have to define
> how varlink talks to Podman, maybe providing dedicated socket with
> dedicated rights so that we can have dedicated users for specific tasks)
> 
> That said, I have some questions:
> ° Does any of you have some experience with varlink and podman interface?
> ° What do you think about that integration wish?
> ° Does any of you have concern with this possible addition?
> 
> Thank you for your feedback and ideas.
> 
> Have a great day (or evening, or whatever suits the time you're reading
> this ;))!
> 
> C.
> 
> 
> ¹ https://www.projectatomic.io/blog/2018/05/podman-varlink/
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

How might this effect upgrades?

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Jay Pipes]

On 08/15/2018 04:01 PM, Emilien Macchi wrote:
On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi > wrote:


More seriously here: there is an ongoing effort to converge the
tools around containerization within Red Hat, and we, TripleO are
interested to continue the containerization of our services (which
was initially done with Docker & Docker-Distribution).
We're looking at how these containers could be managed by k8s one
day but way before that we plan to swap out Docker and join CRI-O
efforts, which seem to be using Podman + Buildah (among other things).

I guess my wording wasn't the best but Alex explained way better here:
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52

If I may have a chance to rephrase, I guess our current intention is to 
continue our containerization and investigate how we can improve our 
tooling to better orchestrate the containers.
We have a nice interface (openstack/paunch) that allows us to run 
multiple container backends, and we're currently looking outside of 
Docker to see how we could solve our current challenges with the new tools.
We're looking at CRI-O because it happens to be a project with a great 
community, focusing on some problems that we, TripleO have been facing 
since we containerized our services.


We're doing all of this in the open, so feel free to ask any question.


I appreciate your response, Emilien, thank you. Alex' responses to 
Jeremy on the #openstack-tc channel were informative, thank you Alex.


For now, it *seems* to me that all of the chosen tooling is very Red Hat 
centric. Which makes sense to me, considering Triple-O is a Red Hat product.


I don't know how much of the current reinvention of container runtimes 
and various tooling around containers is the result of politics. I don't 
know how much is the result of certain companies wanting to "own" the 
container stack from top to bottom. Or how much is a result of technical 
disagreements that simply cannot (or will not) be resolved among 
contributors in the container development ecosystem.


Or is it some combination of the above? I don't know.

What I *do* know is that the current "NIH du jour" mentality currently 
playing itself out in the container ecosystem -- reminding me very much 
of the Javascript ecosystem -- makes it difficult for any potential 
*consumers* of container libraries, runtimes or applications to be 
confident that any choice they make towards one of the other will be the 
*right* choice or even a *possible* choice next year -- or next week. 
Perhaps this is why things like openstack/paunch exist -- to give you 
options if something doesn't pan out.


You have a tough job. I wish you all the luck in the world in making 
these decisions and hope politics and internal corporate management 
decisions play as little a role in them as possible.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Emilien Macchi]

On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi  wrote:

> More seriously here: there is an ongoing effort to converge the tools
> around containerization within Red Hat, and we, TripleO are interested to
> continue the containerization of our services (which was initially done
> with Docker & Docker-Distribution).
> We're looking at how these containers could be managed by k8s one day but
> way before that we plan to swap out Docker and join CRI-O efforts, which
> seem to be using Podman + Buildah (among other things).
>

I guess my wording wasn't the best but Alex explained way better here:
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52

If I may have a chance to rephrase, I guess our current intention is to
continue our containerization and investigate how we can improve our
tooling to better orchestrate the containers.
We have a nice interface (openstack/paunch) that allows us to run multiple
container backends, and we're currently looking outside of Docker to see
how we could solve our current challenges with the new tools.
We're looking at CRI-O because it happens to be a project with a great
community, focusing on some problems that we, TripleO have been facing
since we containerized our services.

We're doing all of this in the open, so feel free to ask any question.

Thanks,
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Emilien Macchi]

Hi Jay,

On Wed, Aug 15, 2018 at 3:59 PM Jay Pipes  wrote:

> This was news to me. Is this just a triple-o thing?
>

It's in the newspapers!
https://www.serverwatch.com/server-news/red-hat-looks-beyond-docker-for-container-technology.html

More seriously here: there is an ongoing effort to converge the tools
around containerization within Red Hat, and we, TripleO are interested to
continue the containerization of our services (which was initially done
with Docker & Docker-Distribution).
We're looking at how these containers could be managed by k8s one day but
way before that we plan to swap out Docker and join CRI-O efforts, which
seem to be using Podman + Buildah (among other things).

The work done at this time (so far) is pure investigation, but feedback is
always welcome.
We're tracking our efforts here:
https://etherpad.openstack.org/p/tripleo-podman

Thanks,
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Jay Pipes]

On 08/15/2018 05:32 AM, Cédric Jeanneret wrote:

Dear Community,

As you may know, a move toward Podman as replacement of Docker is starting.


This was news to me. Is this just a triple-o thing?

-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Cédric Jeanneret]

Dear Community,

As you may know, a move toward Podman as replacement of Docker is starting.

One of the issues with podman is the lack of daemon, precisely the lack
of a socket allowing to send commands and get a "computer formatted
output" (like JSON or YAML or...).

In order to work that out, Podman has added support for varlink¹, using
the "socket activation" feature in Systemd.

On my side, I would like to push forward the integration of varlink in
TripleO deployed containers, especially since it will allow the following:
# proper interface with Paunch (via python link)

# a way to manage containers from within specific containers (think
"healthcheck", "monitoring") by mounting the socket as a shared volume

# a way to get container statistics (think "metrics")

# a way, if needed, to get an ansible module being able to talk to
podman (JSON is always better than plain text)

# a way to secure the accesses to Podman management (we have to define
how varlink talks to Podman, maybe providing dedicated socket with
dedicated rights so that we can have dedicated users for specific tasks)

That said, I have some questions:
° Does any of you have some experience with varlink and podman interface?
° What do you think about that integration wish?
° Does any of you have concern with this possible addition?

Thank you for your feedback and ideas.

Have a great day (or evening, or whatever suits the time you're reading
this ;))!

C.


¹ https://www.projectatomic.io/blog/2018/05/podman-varlink/


-- 
Cédric Jeanneret
Software Engineer
DFG:DF



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev