Open Stack

I mentioned on IRC the other day that I find this problem fundamentally
un-interesting, and I'll explain why. I should note that this is strictly
my personal opinion, probably in no way resembles the views of anyone else
involved in Heat, and is unlikely to persuade anyone.

>
> This guy, your hypothetical typical Murano user. Two minutes ago he didn't
> know what OpenStack is, or that Drupal requires a database. But now it's
> suddenly *imperative* that he be able to swap out MySQL for Postgres in
> this pre-packaged application???
>
> This problem is not interesting to me because nobody has this problem.
>
> Except maybe bored micromanagers looking to mark their territory by
> putting their stamp on some part of a project. (See http://programmers.
> stackexchange.com/a/122148.) And I'm not interested in them either.
>
> (Looking up the appropriate Dilbert references to insert here is left as
> an exercise for the reader.)
>
> If the developer wants to support a MySQL version and a Postgres version,
> let them release two versions. They will know, of course, that the number
> of things they need to test increases combinatorially with the number of
> options they provide, and may well not be as keen as you think to make
> everything customisable. (Of course the right answer here, and the one that
> substantially all application authors will choose, is to use whatever
> built-in DBaaS the operator provides.)
>
>
Sorry for being unclear. I just merged several use cases into one to
demonstrate what should be IMO possible to do rather than why it is
important. There are guys that don't know or don't care what components
application is made of. There are those who do. We want Murano to be useful
for both of them (although it is no doubt that advanced guys may chose to
go with the Heat of puppet). I can easily imagine cases when I do care on
database like Marconi case where there is a trade of between high
performance with AGPL MongoDB and low-performance regular MySQL. Or maybe I
have set up expensive Oracle database cluster with HA, backups and
everything and I prefer applications to use it rather than install private
instance of MySQL (have you ever seen applications that uses Oracle by
default?). The bigger environment you have (in terms of how many
application it comprises of) the more chances you want to swap/merge some
components to make less moving part, to increase resource utilization or to
reduce TOC, Anyway this is not sole purpose of Murano but a nice bonus that
you have because of system flexibility.




>
>  In Heat HOT developer is the user. But in Murano those are completely
>> different roles. There are developers that write application definitions
>>
>
> I don't really see a difference. In both HOT and Murano the person
> launching the application may or may not be the same person who wrote the
> application definition. There's no reason e.g. that both should not be made
> available in a Glance-like application catalog.
>
> Both should be in Glance, no doubt. The difference is in who is
responsible for the template. In Heat you can take and use HOT template
written by someone else and if it doesn't completely fits your needs you
can always modify it. Anyway as soon as you submit it the system (Heat)
does not distinguish or care how that HOT was obtained. In Murano those
roles are separated by design. There are different interfaces for
publishing application to AppCatalog and building environment from
applications that are already in catalog. They controlled by different
ACLs. For example cloud provider (IT department in case of private cloud)
may choose not to allow users to publish applications and let them to
deploy just those apps that cloud provider has chosen.


>
>  And let users build environments of any
>> complexity from small components while providing reasonable default so
>> that one-click deployment would also be possible. And such system to be
>> useful the design process need to be guided and driven by UI. System
>> must know what combination of components are possible and what are not
>> and not let user create Microsoft IIS hosted on Fedora.
>>
>
> If I may go all editorial on you again, this sounds like the same thing
> we've been hearing since the 1970s: "When everything is object oriented,
> non-technical users will be able to program just by plugging together
> existing chunks of code." Except it hasn't ever worked. 35+ years. No
> results.


Agree. I know it sounds like marketing bullshit. I never believed myself
this would work for programming. It never worked because OOP approach
doesn't save you from writing code. But there domains when component
development did worked. Like CAD design. I don't see why this wouldn't work
for deployment/ALM. Anyway I believe we need to try because it is better to
fail than even not try. But if we succeed this ma be a breakthrough. You
know there are so many systems available that can bring you WordPress or
MySQL with several mouse clicks and most of them work fine with OpenStack.
So what is the point of building just another JuJu? My belief is that we
have to be innovative and try to do what other couldn't achieve or just
step out. This is just my personal opinion and motivation.


>
>
>  5. Mistral does not need all that OOP stuff, inheritance, constraints
>> etc. And in practice it is very hard to separate declarations from the
>> workflow code as they are very coupled in their nature
>>
>
> Why? Because of all the $this stuff? From the few I have looked at, all of
> the stuff that is being done imperatively in the workflows using the
> object's properties could have been done declaratively in Heat, just
> passing the properties as parameters to a template.
>
>
Because code and data are tightly connected. Since the classes can
reference each other you can have expressions like $this.ref1.ref2.property
e.g. navigate in object model. But how do you do that if you offload
execution to the system that is not aware of you object model and works
with flat data? (not saying it is completely undoable but this may be very
hard and not a good idea anyway). Properties have contracts. If you say
that your property is an array of integers then you should not let assign
strings or use it as it was scalar. Thus execution engine (Mistral in this
case) need to be aware of data typing and contracts. And then comes
inheritance - property may be introduced in derived class and is not
available via reference to his parent class. There is also method name
resolution, access control for properties and many more. Thats all because
declarations and imperative code are not separate things but one single
programming language. And while it may be reasonable to have imperative
workflow in Mistral I don't feel that Mistral also wants to have all that
OOP declarations. Initially we wanted to translate MuranoPL into Mistral
DSL that is much simpler and not object-oriented similar to how you compile
OOP C++ to non-OOP assembly. But it turns to be too difficult to implement
at current stage.


>
>  6. DSL is a hart and brain of Murano. It is the most vital part of it.
>> You cannot develop system of such level as Murano without having control
>> over it. Any decision taken by Mistral team can become fatal for Murano.
>>
>
> You depend on parts of HOT already, don't you have the same issue with
> Heat?
>
>
>  Anyway I hope that some day we will be able to somehow merge our
>> DSLs/codebase/whatever
>>
>
> This seems unlikely to happen by accident.
>
> I think the difference between the approach you've taken and what I'm
> advocating for is that it's very top-down. Start with a problem, design a
> DSL around it, stick it in OpenStack and "hope that some day we will be
> able to somehow merge". I would much prefer a more bottom-up approach. We
> have these tools already (or in the case of Mistral, we're in the process
> of developing them)... in what ways can we extend them incrementally to
> help them cover a wider range of use cases? (Folks who were around a year
> ago when talk of moving Heat closer to TOSCA first began will tell you that
> I have been pretty consistent in pushing this approach.)



You're absolutely right. The problem with bottom-up approach is that it pulls
you down. Once you start doing 'small thing' and get your first users there
are very few chances for you to make revolutionary changes and step
forward. You always need to maintain backward compatibility and make
everybody happy. If you started your project as a calculator it will
probably never become MATLAB even if you had it in mind. Just because most
of your contributors would be happy with calculator and it is calculator
that your customers have bought and not MATLAB. We can definitely start
doing something simpler than what we want. And if we lower the bar we would
not need MuranoPL and all that but I afraid we would never have a change to
bring it back. Consider what it would take now to replace HOT with
something completely different if you decide to. There is also a big
players on the market outside OpenStack community.  And while we are going
from the bottom and hoping to grow some day big companies release their
AppEngines, CloudFoundries and BlueMixes that catch up customers and have
WOW effect and nobody cares that they are so cool just on the surface. Even
if we grow our calculator to MATLAB level it just would be too late then.
Again this is just my opinion and this very depends on what are the
priorities and goals and my bosses may not agree with me here. Anyway
top-bottom approach doesn't mean we cannot merge our efforts other than
accidentally. If we start collaborate on early stages and coordinate our
efforts I don't see why it shouldn't happen.


I also agree with Thomas on that TOSCA is a perfect place for collaboration
and Murano should become involved as soon as it is possible



>
>
> cheers,
> Zane.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Sincerely yours
Stanislav (Stan) Lagun
Senior Developer
Mirantis
35b/3, Vorontsovskaya St.
Moscow, Russia
Skype: stanlagun
www.mirantis.com
slagun at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140326/460fa670/attachment.html>