Hi All
I just wanted to clarify something in my comment the other day about DSLs
since I see that the acronym was also used in Alex's original document.
Unless I misunderstood, Alex was proposing to create a DSL for Brooklyn
using yaml as syntax and writing a code layer to translate between that
syntax and underlying APIs which are presumably all in Java.
What I was suggesting was a DSL written directly in Java (I guess) whose
syntax would be that language, but whose grammar would be keywords that
were also Java functions. Some of these functions would be pre-defined in
the DSL, while others could be defined by the user and could use other
functions of the DSL. The result would be turned into a JAR file (or
equivalent in another platform) But during the compile phase, it would be
checked for errors, and it could be debugged line by line either invoking
live functionality or using a library of mock versions of the Brooklyn API.
In this 'native' DSL one could provide different types of workflow
constructs as functions (In the BaseClass), taking function names as method
pointers, or using Lambdas. It would be a lot easier in Ruby or Python
// linear
brooklynRun(NamedTaskMethod, NamedTaskMethod)
// chained
TaskMethodA()TaskMethodB().
// asynchronous
brooklynJoin(NamedTaskMethod, NamedTaskMethod,...)
// conditional
brooklynRunIf(NamedTaskMethod, NamedConditionMethod,...)
// iterative
brooklynRunWhile(NamedTaskMethod, NamedConditionMethod,...)
brooklynRunUntil(NamedTaskMethod, NamedConditionMethod,...)
// there could even be a utility to implement legacy syntax (this of course
would require the extra code layer I was trying to avoid)
runYaml(Path)
A basic class structure might be
// where BrooklynRecipeBase implements the utility functions including,
among others Join, Run, If, While, Until mentioned above
// and the BrooklynWorkflowInterface would dictate the functional
requirements for the mandatory aspects of the Recipe.
class MyRecipe extends BrooklynRecipeBase implements,
BrooklynWorkflowInterface
{
Initialize()
createContext() - spin up resources
workflow() - the main launch sequence using aspects of the DSL
monitoring() - an asynchronous workflow used to manage sensor output or for
whatever needs to be done while the "orchestra" is plating
shutdownHook() - called whenever shutdown is happening
}
For those who don't like the smell of Java, the source file could just be
the contents, which would then be injected into the class framing code
before compilation.
These are just ideas. I'm not familiar enough with Brooklyn in its current
implementation to be able to create realistic pseudocode.
Peter
On Thu, Sep 1, 2022 at 9:24 AM Geoff Macartney <geoff.macart...@gmail.com>
wrote:
> Hi Alex,
>
> That's great, I'll be excited to hear all about it. 7th September
> suits me fine; I would probably prefer 4.00 p.m. over 11.00.
>
> Cheers
> Geoff
>
> On Thu, 1 Sept 2022 at 12:41, Alex Heneveld <a...@cloudsoft.io> wrote:
> >
> > Thanks for the excellent feedback Geoff and yes there are some very cool
> and exciting things added recently -- containers, conditions, and terraform
> and kubernetes support, all of which make writing complex blueprints much
> easier.
> >
> > I'd love to host a session to showcase these.
> >
> > How does Wed 7 Sept sound? I could do 11am UK or 4pm UK -- depending
> what time suits for people who are interested. Please RSVP and indicate
> your time preference!
> >
> > Best
> > Alex
> >
> >
> > On Wed, 31 Aug 2022 at 22:17, Geoff Macartney <geoff.macart...@gmail.com>
> wrote:
> >>
> >> Hi Alex,
> >>
> >> Another thought occurred to me when reading that workflow proposal. You
> wrote
> >>
> >> "and with the recent support for container-based tasks and declarative
> >> conditions, we have taken big steps towards enabling YAML authorship"
> >>
> >> Unfortunately over the past while I haven't been able to keep up as
> >> closely as I would like with developments in Brooklyn. I'm just
> >> wondering if it might be possible to get together some time, on Google
> >> Meet or Zoom or whatnot, if you or a colleague could spare half an
> >> hour to demo some of these recent developments? But don't worry about
> >> it if you're too busy at present.
> >>
> >> Adding dev@ to this in CC for the sake of Openness. Others might also
> >> be interested!
> >>
> >> Cheers
> >> Geoff
>
