[
https://issues.apache.org/jira/browse/SLIDER-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412292#comment-15412292
]
Billie Rinaldi commented on SLIDER-875:
---------------------------------------
Thanks for the review, [~gsaha]! Some comments about your comments are below. I
am testing out a patch addressing the issues you've raised.
bq. PROPERTY_COMPONENT_TYPE = "site.global.component_type"
It looks like SliderKeys starting with PROPERTY_ are for JVM properties. There
doesn't seem to be a consistent naming for appConfig properties in SliderKeys.
Some start or end with KEY, but some don't. Perhaps we should standardize that
at some point. COMPONENT_TYPE_KEY has a good ring to it, so maybe I'll go with
that.
bq. Only external is a little vague and might make new users wonder what it
means.
I don't know, I think "external component type" and "application component
type" would both require explanation. If anything "application component type"
seems more confusing since the term "application" is so overloaded.
bq. Did we plan to move away from dash?
No, dash is still the separator. The change I've made is that user-defined
components are also allowed to have a dash in them.
bq. Do you think we can create a Pattern of a regex ... which will be faster
and more efficient? The inner for loop will be gone too.
I ran a quick test and it was 5 to 7 times slower to use a Pattern. Regular
expressions are expensive. I tried moving the duplicate key check before the
prefix checks, but that was slightly slower so I've left it as is.
bq. Should we call it loadExternalComponents or initializeExternalComponents or
something better instead of get, since it does not return anything?
I'll make getExternalComponents return a Set. I think loading instead of
getting was a holdover from an earlier version of my patch, and we don't need
to do that anymore.
bq. Also, rename the variable to COMPONENT_PREFIXES_TO_SKIP.
How about COMPONENT_KEYS_TO_SKIP? Since we're moving it out of context to
SliderKeys, I want to make it clear that it's for skipping appConfig keys.
> Ability to create an Uber application package with capability to deploy and
> manage as a single business app
> -----------------------------------------------------------------------------------------------------------
>
> Key: SLIDER-875
> URL: https://issues.apache.org/jira/browse/SLIDER-875
> Project: Slider
> Issue Type: New Feature
> Components: agent, app-package, appmaster, client, core
> Affects Versions: Slider 0.70
> Reporter: Gour Saha
> Assignee: Billie Rinaldi
> Fix For: Slider 2.0.0
>
>
> A business application as we typically refer to, is one that provides value
> to an end user. Few examples will be, a CRM application, an online
> advertising application, and a trucking application (to monitor driving
> habits of truck drivers).
> An end user does not understand (or care about) the numerous application
> components like HBase, Storm, Spark, Kakfa, Tomcat, MySql, Memcached, or
> Nodejs that are required to build such a business application.
> Several such business applications are hosted by cloud vendors like AWS, GCE,
> Azure, and others. From a cluster management point of view, the IT
> administrator would benefit from an Uber control of the business application
> as a whole. The business application owner understands the different
> components (like Tomcat, Memcached, HBase, etc.) of her/his Uber application.
> As much as they need fine-grain control of each of these individual
> applications (which is supported today), they would also benefit from a
> management control for the Uber app. With Docker becoming popular every day,
> this will provide a platform to the application owners to define a business
> application as a conglomeration of Docker containers.
> Slider currently is viewed (and used) to package individual applications like
> HBase, Storm, Kafka, Memcached, and Tomcat. Slider should be able to expose
> the concept of an Uber application package definition. This Uber definition
> will be composed of config and resource specifications of the individual
> application components. Additionally, it will have definitions for Uber
> management and control, like -
> # Stop, start and flex of the Uber app
> # Dependency specification between the individual applications such that flex
> of certain components of an application can automatically trigger
> proportional flex of components in another application
> # Cruise control of the Uber app, on top of what SLIDER-868 will provide for
> an individual app. Ability to define a skyline for the Uber app, over time
> and other dimensions.
> # Resource requirements and planning for the Uber app as a whole. Most of the
> time, an Uber app is functional only when all (or minimum viable) application
> components are deployed and available. Tomcat running with MySql, Memcached
> and HBase still waiting for containers, is a useless business application.
> Slider should be able to do resource calculation and negotiation for the Uber
> app as a whole. It can work with YARN to get the minimal viable applications
> of the Uber app running or not bother to run anything (I smell SLAs for
> vendors and savings for application owners).
> # Ability to define and use multiple YARN labels for the Uber application (in
> addition to the fine grained label definitions for the individual
> sub-components of a single app)
> I am sure, there are several other benefits which are not identified yet, but
> this is a start.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
