[almighty] Names and Definitions

Max Rydahl Andersen manderse at redhat.com
Mon Sep 26 19:43:51 UTC 2016


On 26 Sep 2016, at 21:36, Leonard Dimaggio wrote:

> Hey Andrew,
>
> Great idea! One question on the hierarchy - we have to make it very 
> clear
> when a parent element is limited to one child or may have many 
> children.
> For example, a build or deployment may have to be run in many 
> environments.
>
> Actually - in re-thinking this - are ANY of these elements limited to 
> only
> one child?

Parent and child relationships inherently means one parent, multiple 
children so
not sure what you are concerned about here ?

> P.S.  I noticed your reference to bug tracking - will this be an 
> external
> system (bugzilla, JIRA, git, etc.) or something that we will build in?

he wrote issue tracking and yes almighty can be used for that - but we 
will focus
on making sure if you are using existing issue trackers you do not have 
to move to 100% almighty to use it.

/max

> On Mon, Sep 26, 2016 at 3:07 PM, Andrew Lee Rubinger <alr at redhat.com> 
> wrote:
>
>> Something I'd like to iron out sooner than later are common terms and
>> definitions, because getting to a mutual understanding about what 
>> we're
>> referring to starting to be pretty relevant. :)
>>
>> Alongside the discussions we had on this list last week, could I ask 
>> the
>> UXD team to take the lead on moderating the definitions and 
>> relationships
>> among the following constructs?  A graphical representation of
>> relationships where appropriate would be wonderful.
>>
>> * "Almighty System" - An instance of Almighty.  Contains all 
>> "Almighty
>> User" accounts and "Almighty Projects".
>> * "Almighty Project" - A top-level container for an application 
>> shared
>> among users/teams.  May hold N "Codebases", has issue tracking, build 
>> and
>> deployment environments.  Eventually will have realtime 
>> communications.
>> * "Codebase" - Basically a repository.  Can be N in a "Project"
>> * "Environment" - Target for running builds or deployments
>> * "Almighty User" - My account
>> * "Workspace" - The WebIDE view of an "Almighty Project".  Contains 
>> the
>> "Codebases", each of which may require its own Stack to be 
>> built/tested.
>> * "Stack" - Runtime to build a codebase or deploy its resultant
>> artifacts.  In practice, equates to an image which may be run as a
>> container.  NOTE: currently Che, as I understand it, has one Stack 
>> per
>> Workspace.  We'll need to address that in order to support opening, 
>> for
>> instance, a Java codebase and a Node codebase in the same workspace.
>> * Other important concepts I've missed here
>>
>> The terms definitions I'm using here are placeholders and could 
>> likely do
>> with something else that's descriptive and not so overloaded.  The
>> definitions are also up for debate -- everything is open to review 
>> now, but
>> let's try to get things at this level to gel quickly.
>>
>> S,
>> ALR
>>
>> --
>> Red Hat Developer Programs Architecture
>> @ALRubinger
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>>
>>
>
> -- 
> Len DiMaggio (ldimaggi at redhat.com)
> JBoss by Red Hat
> 314 Littleton Road
> Westford, MA 01886  USA
> tel:  978.392.3179
> cell: 781.472.9912
> http://www.redhat.com
> http://community.jboss.org/people/ldimaggio


> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public


/max
http://about.me/maxandersen




More information about the almighty-public mailing list