[Tendrl-devel] Frontend tool stack: choices made

[Alfredo Deza]

On Fri, Sep 23, 2016 at 7:49 AM, Soumya Deb <deb at redhat.com> wrote:
>
>
> On 22 September 2016 at 22:28, John Spray <jspray at redhat.com> wrote:
>>
>> On Thu, Sep 22, 2016 at 4:06 PM, Soumya Deb <deb at redhat.com> wrote:
>> > On 22 September 2016 at 14:31, John Spray <jspray at redhat.com> wrote:
>> >>
>> >> The key point here is the added *runtime*.  For frontend javascript
>> >> you already have a runtime built into the browser.  On the backend,
>> >> you're going to be imposing a requirement for node and all its
>> >> dependencies.  Frontend/backend also involves different tools etc (I
>> >> know how to do right click->inspect, I do not know all the command
>> >> line equivalents).
>> >
>> > [SNIPPED]
>> >
>> > To address what are we about to do with it; yes you've made some correct
>> > guesses there. Our frontend implemented on REST for the browser/client
>> > to
>> > communicate with the server, we will have sophisticated routes handling
>> > in
>> > the server side as well, many of the non-generic error/failure handling
>> > can
>> > be implemented more easily (in cases where tendrl's backend provides
>> > machine
>> > readable errors, but we can process that into multilanguage supported
>> > humanly understood error-msg/warnings etc), abstracting out sensitive
>> > backend endpoints, implementing more login strategies more efficiently,
>> > mock
>> > APIs for building UI while the backend API isn't ready or to test
>> > features
>> > and many more reasons that come into play why having a server side
>> > scripting
>> > environment will come in handy.
>>
>> So to put this into context with [1], it seems like the stack looks like:
>>
>> UI code (Javascript, running in browser)
>>   ||
>>   v
>> Server-side UI support code (Javascript, running in node.js on a
>> Tendrl server node)
>>   ||
>>   v
>> Server-side Tendrl Application Instance (Unknown language)
>>   ||
>>   v
>> Tendrl Central Store (Unknown service, probably etcd?)
>>   ||
>>   v
>> Tendrl Node Agent (Python, running on Ceph storage node)
>>   ||
>>   v
>> Tendrl SDS Bridge (Python, running on Ceph storage node)
>>   ||
>>   v
>> Ceph (Python/C++)
>>
>> Can you see why I'm concerned about the number of moving parts here?
>> It's not so much a question of the merits of any one of them, as it is
>> the resulting total complexity.  It's not always easy to identify
>> pieces to cut out, but the server side UI support code certainly looks
>> like a tempting candidate, given that it could presumably be folded
>> into whatever language/framework is in use in the Tendrl Application
>> Instance.
>
>
> Your text-chart of the stack looks pretty correct for a linear and simple
> for the representation. Thanks for taking your time with it.
>
> Now, to address the points you brought (about varying tech-stack in each
> layer vs having consistency), brings some solid argument. Especially,
> when we see it under the perspective of one SDS. And in this case
> Python does look dominant.
>
> However, there will be other SDSs to support, and some might be
> developed in Go, Java, C++ or Rust (or whatever might be fitting for
> that particular product's team). Do you consider that should dictate
> the choice of language on the upper layers, or should they choose the
> ones that works best for them (as in, Tendrl bridge and Agent is on
> Python, but most SDS aren't written in Python - should they consider
> writting it in C++?). In that case, when all the other parts are pretty
> homogeneous and based on C++, should we consider the frontend
> to also base on C++ platform? This gets pretty far-fetched there on.
>
> In my understanding, as long as each modular part/layer uses best
> technology available for them, and interoperates with other parts in
> the stack this shouldn't cause any headache for the other layers.
>
>
>> I wonder if you've thought about how to package server-side javascript
>> for linux distributions, and how you will cope with the varying
>> availability of different versions of packages across different
>> distros.  If you go forward with using node.js on the server, I advise
>> you to do full packaging from day 1, so that you have early visibility
>> of any issues.
>
>
> About packaging - packaging, deploying and maintaining Node.js
> app is among the most hassle free option there is. It has its own
> package manager for the dependencies it uses, is smarter than pip
> in almost all the ways, doesn't require a venv to contain itself and
> not mess with the base system, node dependencies can have their
> own dependencies of same product's different versions and neither
> the system or the developer has to utter a word/write a line of extra
> code to avoid mess.

I don't think John meant packaging using the community/language
support, but rather using system packages.

The Ceph project builds binaries for a few distributions, and packages
some Python tools that come included.

This has nothing to do with pip, virtualenv, or how (easy?) it may be
with Node.js, the point here is that it might be
very tricky to do this with JS dependencies compared to say Python,
because Python packages are more readily available.

>
> Suggestion taken for doing full packaging from day 1. We already
> have the intention to automate the entire process anyway. So, from
> building, testing, packaging, deploying should ideally be taken care
> of after each successful merge/push into the upstream/master.

I would love to see what the plan for that is here. For Ceph we build
for several different distros and distro versions, and sometimes
for different architectures. The current system produces RPMs, DEBs
and their corresponding repositories.

This is a very non-trivial system that does build from upstream
changes in most branches too

"packaging from day 1" means here that, there should be a plan for the
community to be able to consume these binaries and repositories
for various different distros (is there a list of supported distros
somewhere? or what the plan is for those?)


>
> _______________________________________________
> Tendrl-devel mailing list
> Tendrl-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/tendrl-devel
>