You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@marvin.apache.org by Lucas Cardoso Silva <ca...@gmail.com> on 2020/08/15 21:32:21 UTC
Presentation of the architectural proposal
Hi guys,
To continue our goal to evaluate the architecture, we have to present the
proposal for all involved. I will take the opportunity to discuss some
points about the implementation of the daemon and new CLI.
Each engine has a Dockerfile for development where all dependencies related
to the operating system will be declared. When the CLI is invoked for the
engine, the image is created and the container starts, with the daemon as
the main execution. All modifications to the engine are saved directly to
the files (via bind mount). All commands, except the creational and
versioning commands, run on the daemon (called by the CLI). Do you agree
with this approach? It’s a little different from that represented in the
image, which represents the use of a volume.
Architectural proposal image:
https://github.com/lucasbm88/incubator-apache-marvin/wiki/Development-Resources#v005---refactoring-architecture
Image of the current architecture:
https://docs.google.com/drawings/d/1UOR8Bk0fpLAOnotdeAn4Ww1GBbRxhdtM5mfoTJKQNVo/edit?usp=sharing
Thanks a lot,
Lucas
Re: Presentation of the architectural proposal
Posted by Lucas Cardoso Silva <ca...@gmail.com>.
A call would be great if we were able to organize. Some things can be
confusing by email, but I will try to clarify some points of what I meant.
The email was to carry out a control step within the architectural analysis
I am proposing, but as I believe that everyone is familiar with an
architectural proposal, even more than I am, I tried to generate discussion
suggesting a small change.
Answering the question from @lucas. I believe it would be easier to work
with bind mounts, as it would allow the toolbox to create an engine outside
the container, and it would be easily accessible inside the container. I
couldn't find any way to put files inside a docker volume without using a
container.
I just did a PR with a new CLI, if it is accepted, the architectural change
will be well advanced: https://github.com/apache/incubator-marvin/pull/52
Best regards,
Lucas Cardoso
Em qua., 26 de ago. de 2020 às 15:35, Wei Chen <we...@apache.org>
escreveu:
> That will be nice, I am in Taipei (GMT+8)
>
> Best Regards,
> Wei
>
> On Thu, Aug 27, 2020 at 12:20 AM Daniel Takabayashi <
> daniel.takabayashi@gmail.com> wrote:
>
> > Guys if you prefer we could organize a call to discuss these more complex
> > points. Maybe could be more productive.
> >
> > Em dom., 23 de ago. de 2020 às 22:39, Daniel Takabayashi <
> > daniel.takabayashi@gmail.com> escreveu:
> >
> > > Hi Lucas,
> > >
> > > I am a little confused about your e-mail, I couldn't get your point.
> > > Could you please be a little more specific?
> > >
> > > Thanks,
> > > Taka
> > >
> > > Em sáb., 15 de ago. de 2020 às 14:32, Lucas Cardoso Silva <
> > > cardosolucas61.lcs@gmail.com> escreveu:
> > >
> > >> Hi guys,
> > >>
> > >> To continue our goal to evaluate the architecture, we have to present
> > the
> > >> proposal for all involved. I will take the opportunity to discuss some
> > >> points about the implementation of the daemon and new CLI.
> > >>
> > >> Each engine has a Dockerfile for development where all dependencies
> > >> related
> > >> to the operating system will be declared. When the CLI is invoked for
> > the
> > >> engine, the image is created and the container starts, with the daemon
> > as
> > >> the main execution. All modifications to the engine are saved directly
> > to
> > >> the files (via bind mount). All commands, except the creational and
> > >> versioning commands, run on the daemon (called by the CLI). Do you
> agree
> > >> with this approach? It’s a little different from that represented in
> the
> > >> image, which represents the use of a volume.
> > >>
> > >> Architectural proposal image:
> > >>
> > >>
> >
> https://github.com/lucasbm88/incubator-apache-marvin/wiki/Development-Resources#v005---refactoring-architecture
> > >>
> > >> Image of the current architecture:
> > >>
> > >>
> >
> https://docs.google.com/drawings/d/1UOR8Bk0fpLAOnotdeAn4Ww1GBbRxhdtM5mfoTJKQNVo/edit?usp=sharing
> > >>
> > >> Thanks a lot,
> > >> Lucas
> > >>
> > >
> >
>
Re: Presentation of the architectural proposal
Posted by Wei Chen <we...@apache.org>.
That will be nice, I am in Taipei (GMT+8)
Best Regards,
Wei
On Thu, Aug 27, 2020 at 12:20 AM Daniel Takabayashi <
daniel.takabayashi@gmail.com> wrote:
> Guys if you prefer we could organize a call to discuss these more complex
> points. Maybe could be more productive.
>
> Em dom., 23 de ago. de 2020 às 22:39, Daniel Takabayashi <
> daniel.takabayashi@gmail.com> escreveu:
>
> > Hi Lucas,
> >
> > I am a little confused about your e-mail, I couldn't get your point.
> > Could you please be a little more specific?
> >
> > Thanks,
> > Taka
> >
> > Em sáb., 15 de ago. de 2020 às 14:32, Lucas Cardoso Silva <
> > cardosolucas61.lcs@gmail.com> escreveu:
> >
> >> Hi guys,
> >>
> >> To continue our goal to evaluate the architecture, we have to present
> the
> >> proposal for all involved. I will take the opportunity to discuss some
> >> points about the implementation of the daemon and new CLI.
> >>
> >> Each engine has a Dockerfile for development where all dependencies
> >> related
> >> to the operating system will be declared. When the CLI is invoked for
> the
> >> engine, the image is created and the container starts, with the daemon
> as
> >> the main execution. All modifications to the engine are saved directly
> to
> >> the files (via bind mount). All commands, except the creational and
> >> versioning commands, run on the daemon (called by the CLI). Do you agree
> >> with this approach? It’s a little different from that represented in the
> >> image, which represents the use of a volume.
> >>
> >> Architectural proposal image:
> >>
> >>
> https://github.com/lucasbm88/incubator-apache-marvin/wiki/Development-Resources#v005---refactoring-architecture
> >>
> >> Image of the current architecture:
> >>
> >>
> https://docs.google.com/drawings/d/1UOR8Bk0fpLAOnotdeAn4Ww1GBbRxhdtM5mfoTJKQNVo/edit?usp=sharing
> >>
> >> Thanks a lot,
> >> Lucas
> >>
> >
>
Re: Presentation of the architectural proposal
Posted by Lucas Bonatto Miguel <lu...@apache.org>.
The new image is looking good.
What would be the advantage of using bind instead of volumes here?
Best,
Lucas
On Wed, Aug 26, 2020 at 1:31 PM Luciano Resende <lu...@gmail.com>
wrote:
> On Wed, Aug 26, 2020 at 9:20 AM Daniel Takabayashi
> <da...@gmail.com> wrote:
> >
> > Guys if you prefer we could organize a call to discuss these more complex
> > points. Maybe could be more productive.
> >
>
> +1
>
>
>
>
> --
> Luciano Resende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: Presentation of the architectural proposal
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Aug 26, 2020 at 9:20 AM Daniel Takabayashi
<da...@gmail.com> wrote:
>
> Guys if you prefer we could organize a call to discuss these more complex
> points. Maybe could be more productive.
>
+1
--
Luciano Resende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Presentation of the architectural proposal
Posted by Daniel Takabayashi <da...@gmail.com>.
Guys if you prefer we could organize a call to discuss these more complex
points. Maybe could be more productive.
Em dom., 23 de ago. de 2020 às 22:39, Daniel Takabayashi <
daniel.takabayashi@gmail.com> escreveu:
> Hi Lucas,
>
> I am a little confused about your e-mail, I couldn't get your point.
> Could you please be a little more specific?
>
> Thanks,
> Taka
>
> Em sáb., 15 de ago. de 2020 às 14:32, Lucas Cardoso Silva <
> cardosolucas61.lcs@gmail.com> escreveu:
>
>> Hi guys,
>>
>> To continue our goal to evaluate the architecture, we have to present the
>> proposal for all involved. I will take the opportunity to discuss some
>> points about the implementation of the daemon and new CLI.
>>
>> Each engine has a Dockerfile for development where all dependencies
>> related
>> to the operating system will be declared. When the CLI is invoked for the
>> engine, the image is created and the container starts, with the daemon as
>> the main execution. All modifications to the engine are saved directly to
>> the files (via bind mount). All commands, except the creational and
>> versioning commands, run on the daemon (called by the CLI). Do you agree
>> with this approach? It’s a little different from that represented in the
>> image, which represents the use of a volume.
>>
>> Architectural proposal image:
>>
>> https://github.com/lucasbm88/incubator-apache-marvin/wiki/Development-Resources#v005---refactoring-architecture
>>
>> Image of the current architecture:
>>
>> https://docs.google.com/drawings/d/1UOR8Bk0fpLAOnotdeAn4Ww1GBbRxhdtM5mfoTJKQNVo/edit?usp=sharing
>>
>> Thanks a lot,
>> Lucas
>>
>
Re: Presentation of the architectural proposal
Posted by Daniel Takabayashi <da...@gmail.com>.
Hi Lucas,
I am a little confused about your e-mail, I couldn't get your point.
Could you please be a little more specific?
Thanks,
Taka
Em sáb., 15 de ago. de 2020 às 14:32, Lucas Cardoso Silva <
cardosolucas61.lcs@gmail.com> escreveu:
> Hi guys,
>
> To continue our goal to evaluate the architecture, we have to present the
> proposal for all involved. I will take the opportunity to discuss some
> points about the implementation of the daemon and new CLI.
>
> Each engine has a Dockerfile for development where all dependencies related
> to the operating system will be declared. When the CLI is invoked for the
> engine, the image is created and the container starts, with the daemon as
> the main execution. All modifications to the engine are saved directly to
> the files (via bind mount). All commands, except the creational and
> versioning commands, run on the daemon (called by the CLI). Do you agree
> with this approach? It’s a little different from that represented in the
> image, which represents the use of a volume.
>
> Architectural proposal image:
>
> https://github.com/lucasbm88/incubator-apache-marvin/wiki/Development-Resources#v005---refactoring-architecture
>
> Image of the current architecture:
>
> https://docs.google.com/drawings/d/1UOR8Bk0fpLAOnotdeAn4Ww1GBbRxhdtM5mfoTJKQNVo/edit?usp=sharing
>
> Thanks a lot,
> Lucas
>