[Starlingx-discuss] Is there any plan of containerize the flock services ?

[Victor Rodriguez]

On Fri, Mar 1, 2019 at 7:20 AM Rowsell, Brent <Brent.Rowsell at windriver.com>
wrote:

> Hi Victor,
>
> See inline
>
> Brent
>
> -----Original Message-----
> From: Victor Rodriguez [mailto:vm.rod25 at gmail.com]
> Sent: Wednesday, February 27, 2019 12:00 PM
> To: Rowsell, Brent <Brent.Rowsell at windriver.com>
> Cc: starlingx-discuss at lists.starlingx.io; Miller, Frank <
> Frank.Miller at windriver.com>
> Subject: Re: [Starlingx-discuss] Is there any plan of containerize the
> flock services ?
>
> On Tue, Feb 26, 2019 at 8:14 PM Rowsell, Brent <
> Brent.Rowsell at windriver.com> wrote:
> >
> > Hi Victor,
> >
> > For R2 only the openstack and some of it’s supporting services will be
> containerized.
> >
> > A longer term objective is to containerize as much of the flock services
> as possible. This is a candidate for the next release and will be
>  discussed as part of the R3 planning later this year.
> >
> > Brent
> >
>
> Thanks a lot for your repply Brent
>
> I definitely support the approach of containers, now, one question, if the
> goal is to containerize as much of the flock services as possible, can we
> have the list of what services are not going to be on containers? based on
> that we can minimize the efforts of packaging for Ubuntu and maybe help
> more on the containerization of the flock services. The more we have in
> containers the easier is for us to migrate to other OS ( the packages that
> might need be ported to other OS might be: kernel, horizon, and keystone
> right ? )
> [BR] Unfortunately I will not have that view  of what can/will be
> containerized until we start the R3 planning.
>
>
Thanks a lot for the reply Brent, as discussed on the multiOS meeting we
will focus for now on the build of one STX flock service in Ubuntu as
preparation for the build of maybe more. During today containers meeting I
heard that the only one that is a target for R2 is sxt fault , is that
correct ? that was the one we were taking as POC to build, but if it is
already targeted to be in a container we might choose a different one,
Brent, Frank, which one do you recommend we take one, that we all be aware
that we are working on?

Regards

 Victor Rodriguez

So far we have a POC of fm-manager and fm-common [1], what I don't want is
> to spend time building debs that will not be useful in the future.
>
> Regards
>
> Victor Rodriguez
>
> [1]
> https://github.com/marcelarosalesj/stx-packaging/commit/4bf237bf5f97e68b96a5be14a3e260467190e767
>
>
>
> > Sent from my iPhone
> >
> > > On Feb 26, 2019, at 11:59 AM, Victor Rodriguez <vm.rod25 at gmail.com>
> wrote:
> > >
> > > Hi Frank and STX community
> > >
> > > Based on the presentation discuss during phoenix meeting last
> > > January I had the impression that flock services were meant to be on
> > > the host OS where the containers are running, is this still valid
> > > for the long term?
> > >
> > > I am asking this because on today multi-OS meeting we present the
> > > following architecture/plan:
> > >
> > > https://docs.google.com/presentation/d/1ck7vGH50AIAjUx9GNrIGtowG5qg7
> > > OYUBNdJyY-5ZvDc/edit?usp=sharing
> > >
> > > Where we are considering the task of build all the flock services on
> > > Ubuntu, However, based on this task:
> > >
> > > https://storyboard.openstack.org/#!/story/2004008
> > >
> > > Gives me the impression that there is a plan for reducing the number
> > > of flock services running on the host OS, If that is the case, Could
> > > you please share the list of what flock services that you have in
> > > mind to put in a container?  this will help us to reduce the list of
> > > packages we need to build.
> > >
> > > On the same topic, for the none open stack packages like systemd,
> > > bash or python, do you have the list of packages that need to run
> > > outside the containers on the host OS? Having this exact list of
> > > packages will help us to focus on the exact packages to build on
> Ubuntu.
> > >
> > > Regards
> > >
> > > Victor Rodriguez
> > >
> > > _______________________________________________
> > > Starlingx-discuss mailing list
> > > Starlingx-discuss at lists.starlingx.io
> > > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20190304/e2a4b03e/attachment.html>