<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Alexander, do you plan to update the <a href="https://review.openstack.org/#/c/140402/">https://review.openstack.org/#/c/140402/</a> versioning spec? We can possibly try to make it a joint effort, if you like.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1436882960349798912" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Kirill Zaitsev<br>Murano team</div><div style="font-family:helvetica,arial;font-size:13px">Software Engineer</div><div style="font-family:helvetica,arial;font-size:13px">Mirantis, Inc</div></div> <br><p class="airmail_on" style="color:#000;">On 14 Jul 2015 at 11:34:56, Alexander Tivelkov (<a href="mailto:ativelkov@mirantis.com">ativelkov@mirantis.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<div dir="ltr">
<div class="gmail_default" style="font-size:small">Gosha,</div>
<div class="gmail_default" style="font-size:small"><br></div>
<div class="gmail_default" style="font-size:small">Could you please
elaborate what do you mean by extra blocks? Glance V3 comes with
Glance out-of-the box, no extra deployment is needed. The only
thing one will have to install is Murano Package Type plugin - but
it will be installed at the same time with Murano.</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature">
<div dir="ltr"><font size="2">--<br></font>
<div dir="ltr"><font size="2">Regards,<br>
Alexander Tivelkov</font></div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Mon, Jul 13, 2015 at 5:54 PM, Georgy
Okrokvertskhov <span dir="ltr"><<a href="mailto:gokrokvertskhov@mirantis.com" target="_blank">gokrokvertskhov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span class="">On Mon, Jul 13, 2015 at
2:19 AM, Alexander Tivelkov <span dir="ltr"><<a href="mailto:ativelkov@mirantis.com" target="_blank">ativelkov@mirantis.com</a>></span> wrote:<br></span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div style="font-size:small">Hi Gosha,</div>
<div style="font-size:small"><br></div>
<div style="font-size:small">Supporting versioning in existing
backend will require us to re-implement the significant part of
Artifact Repository in Murano API: we'll need to add versions and
dependencies concepts into our model (which is already complicated
and dirty enough), extend appropriate API calls etc. And all the
efforts will be a waste of time once we finally migrate to
Artifacts.</div>
<div style="font-size:small"><br></div>
<div style="font-size:small">Also, what do you mean by "set by
default"? V3 API is experimental, but it is already merged into
upstream Glance, so there is no problem with using it in Murano
right away.</div>
</div>
<div class="gmail_extra"><br clear="all"></div>
</blockquote>
<div>This is exactly why I have these concerns. I wonder how much
customers will use experimental API in production. I just don't
want to add extra block on Murano adoption way.</div>
<div>
<div class="h5">
<div><br></div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_extra">
<div>
<div>
<div dir="ltr"><font size="2">--<br></font>
<div dir="ltr"><font size="2">Regards,<br>
Alexander Tivelkov</font></div>
</div>
</div>
</div>
<div>
<div><br>
<div class="gmail_quote">On Fri, Jul 10, 2015 at 5:56 PM, Georgy
Okrokvertskhov <span dir="ltr"><<a href="mailto:gokrokvertskhov@mirantis.com" target="_blank">gokrokvertskhov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>Hi Alex,<br>
<br></div>
Thank you for the great summary.<br>
<br></div>
I have a concern about item #8. Can we add an option to Murano to
use previous storage engine rather then Glance v3? We need to make
sure that v3 API in Glance is set by default before we do a hard
dependency on it in Murano.<br>
<br></div>
Thanks<br></div>
Gosha<br></div>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div>On Fri, Jul 10, 2015 at 4:53 AM, Alexander Tivelkov <span dir="ltr"><<a href="mailto:ativelkov@mirantis.com" target="_blank">ativelkov@mirantis.com</a>></span> wrote:<br></div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
<div dir="ltr">
<div style="font-size:small">
<div>Hi folks,</div>
<div><br></div>
<div>Ability to manage multiple versions of application packages
and their dependencies was always an important item in Murano
roadmap, however we still don't have a clear spec for this
feature. </div>
<div>Yesterday we hosted a small design session to come up with a
plan on what can be done in Liberty timeframe to have proper
versioning for MuranoPL classes and packages. Stan Lagun, Kirill
Zaitsev and myself participated offline, some other muranoers
joined remotely. Thanks to everybody who joined us.</div>
<div><br></div>
<div>TL;DR: it turns out that now we have a clear plan which will
allow us to achieve proper versioning of the packages and classes,
and we'll try to implement the most important parts of it in
Liberty.</div>
<div><br></div>
<div>Here is the detailed outcome of the session:</div>
<div><br></div>
<div>
<ol>
<li>We'll use the standard Semantic Versioning format
('Major.Minor.Patch[-dev-build.label[+metadata.label]]') to version
our packages: changes which break backwards-compatibility should
increment the major segment, non-breaking new features increment
the minor segment and all non-breaking bugfixes increment the patch
segment. The developers should be carefull with the "new features"
part: if you add a new method to a class, it may be considered a
breaking change if the existing subclasses of this class have the
same method already declared. We still assume that such changes
should lead to increment of 'minor' segment, however it is up to
best judgement of developers in particular case: if the risk of
such method override is really high it may worth to increment the
'major' segment. Proper guideline on the versioning rules will be
published closer to L release.<br>
<br></li>
<li>A new field 'Version' is introduced into package manifest file
which should define package version in complete semver format. The
field itself is optional (so existing apps are not broken), if it
is not specified the package is assumed to have version
'0.0.0'<br>
<br></li>
<li>The existing 'Require' block of Application manifest will be
used to specify the package dependencies. Currently it is a
yaml-based dictionary, with the keys set to fully-qualified names
of the dependency packages and the values set to the version of
those dependencies. Currently this block is used only for
integration with apps stored at <a href="http://apps.openstack.org" target="_blank">apps.openstack.org</a>. It is suggested to use this
block in the deployment process as well, and extend its
semantics.<br>
The version of the dependency specified there should also follow
the semver notation, however it may be specified in the shortened
format, i.e. without specifying the 'patch' or 'patch' and 'minior'
components. In this case the dependency will be specified as a
range of allowed versions. For example, a dependency version 1.2
will mean a (1.2.0 >= version < 1.3) range.<br>
If the version of a dependency is not specified (like in this
existing app - [1]) then we assume the version "0" - i.e. the last
available pre-release version of a package.<br>
<br></li>
<li>Murano core library is also a package which has its own
version. The current one is assumed to have a version 0.1.0, the
one which is going to be released in L will be probably called
0.2.0. The lib is still quickly evolving, so we are not releasing a
1.0.0 until we are sure that we are not going to have any breaking
changes anytime soon.<br>
As with any other package it will be possible to have several
versions of the Core Library installed in Murano at the same moment
of time.<br>
<br></li>
<li>There is no mandatory need to add the the dependency on the
core library to the "Requires" block of each application, as it is
added there implicitly. However, this implicit dependency will have
a version "0" - i.e. will reference the latest pre-release version
of the Core Library available. So it is still better to pin the
core library requirement to a particular version to make sure that
your app does not break if we introduce any breaking change into
the core lib.<br>
<br></li>
<li>All classes defined in a package are assumed to have a version
identical to the version of the package.<br>
<br></li>
<li>Murano Extension Plugins (i.e python packages which declare
setuptools-entrypoints in 'io.murano.extensions' namespace) also
will have similar versioning semantics: they will have a fully
qualified name (defined by the setuptools' package name) and a
version (also defined by setuptools), an will get an ability to
specify their own dependencies if needed. From the class-loader
perspective the MuranoPL classes defined in the plugins are no
difference from the classes defined in a regular package.<br>
<br></li>
<li>We are going to store murano packages as Glance V3 Artifacts
Repository, naturally mapping package's FQN and version to
artifact's name and version.<br>
The package dependencies will be stored in Glance as cross-artifact
dynamic dependencies (i.e. dependencies not on a particular
artifact but on the last artifact matching the given name and the
version range query) as soon as that feature is implemented in
Glance (currently only static dependencies are implemented there).
Until that, the dependencies will be stored as a regular list of
strings, and the Murano engine will process it and query Glance to
fetch the packages.<br>
<br></li>
<li>In L cycle we are not going to show multiple versions of the
same app in Murano dashboard: only the last one will be shown if
the multiple versions are present. This is to minimize the changes
at Dashboard side: in future releases we'll add the ability to
select the proper version.<br>
The generation of the object model by dynamic UI also remains
intact.<br>
<br></li>
<li>However, the structure of the object model isself gets changed:
in the "?" block of each object two new fields appear: "package"
and "version", which correspond to the FQN and the version of the
package which contain the class of the given object. UI leaves
these fields as Nones when it generates the OM, and the engine
computes them in a regular way: queries the package repository for
the most recent version of a package which contains the class with
a given name, and saves information about its name and version.
This values get persisted in an Object Model when it gets
serialized after the deployment. As a result, the versions of the
components are fixed once the environment is deployed, so if some
packages get updated afterwards, the existing components remain
pinned to their initial version. As a result, the environment may
get several components of the same type but different
versions.<br>
<br></li>
<li>When the Object Model is validated after the deserialization,
the behavior of "$.class()" contract is changed. During its
validation the value passed to the appropriate property or argument
should be of a type which is declared either in a current package
(or in the another version of the current package, given that the
major component of the versions is the same) or in one of the
packages satisfying the requirements of the current one. I.e. it
becomes impossible to reference any class from the unreferenced
package.<br>
<br></li>
<li>When inheriting some other class using the 'Extends' attribute,
the ancestor class should be defined either in the current package
or in one of the packages satisfying the requirements of the
current one.<br>
<br></li>
<li>(creepy advanced stuff) It may turn out that in case of the
multiple inheritance a single class will attempt to inherit from
two different versions of a same class. An exception should be
thrown in this case, unless there is a possibility to find a
version of this class which satisfies all parties.</li>
</ol>
</div>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div style="font-size:small">
<div><i>For example: classA inherits classB from packageX and
classC from packageY. Both classB and classC inherit from classD
from packageZ, however packageX depends on the version 1.2.0 of
packageZ, while packageY depends on the version 1.3.0. This leads
to a situation when classA transitively inherits classD of both
versions 1.2 and 1.3. So, an exception will be thrown. However, if
packageY's dependency would be just "1" (which means any of the
1.x.x family) the conflict would be resolved and a 1.2 would be
used as it satisfies both inheritance chains.</i></div>
</div>
</blockquote>
</blockquote>
<div style="font-size:small">
<div><br></div>
<div><br></div>
<div>So, all the above cover most of our present needs for MuranoPL
package and class versioning. </div>
<div>Also, we already have a way which allows us to properly
version the format of MuranoPL language (a "Format" key in
application manifests) and UI-definition files ("Version" key in
that files). This basically allows us to target the packages for a
minimum version of Murano / Murano Dashboard.</div>
<div><br></div>
<div><br></div>
<div>I hope this rather lengthly email is useful. Stan Lagun has
taken an action item to frame all the above into a more formal
spec.</div>
<div><br></div>
<div><br></div>
<div>
<div><br></div>
<div>[1] <a href="https://github.com/openstack/murano-apps/blob/master/MySQL/package/manifest.yaml#L26" target="_blank">https://github.com/openstack/murano-apps/blob/master/MySQL/package/manifest.yaml#L26</a></div>
</div>
<div><br></div>
<div><br></div>
</div>
<div>
<div>
<div dir="ltr"><font size="2">--<br></font>
<div dir="ltr"><font size="2">Regards,<br>
Alexander Tivelkov</font></div>
</div>
</div>
</div>
</div>
<br></div>
</div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote>
</div>
<span><font color="#888888"><br>
<br clear="all">
<br>
--<br></font></span>
<div>
<div dir="ltr"><span><font color="#888888"><font color="#999999"><span style="background-color:rgb(255,255,255)">Georgy
Okrokvertskhov<br>
Architect,<br>
<span style="font-family:arial;font-size:small">OpenStack Platform
Products,</span><br>
Mirantis</span><br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. <a href="tel:%2B1%20650%20963%209828" value="+16509639828" target="_blank">+1 650 963 9828</a><br>
Mob. <a href="tel:%2B1%20650%20996%203284" value="+16509963284" target="_blank">+1 650 996
3284</a></font><br></font></span></div>
</div>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote>
</div>
<br></div>
</div>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote>
</div>
</div>
</div>
<div>
<div class="h5"><br>
<br clear="all">
<div><br></div>
--<br>
<div>
<div dir="ltr"><font color="#999999"><span style="background-color:rgb(255,255,255)">Georgy Okrokvertskhov<br>
Architect,<br>
<span style="font-family:arial;font-size:small">OpenStack Platform
Products,</span><br>
Mirantis</span><br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. <a href="tel:%2B1%20650%20963%209828" value="+16509639828" target="_blank">+1 650 963 9828</a><br>
Mob. <a href="tel:%2B1%20650%20996%203284" value="+16509963284" target="_blank">+1 650 996 3284</a></font><br></div>
</div>
</div>
</div>
</div>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote>
</div>
<br></div>
__________________________________________________________________________
<br>OpenStack Development Mailing List (not for usage questions)
<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<br></div></div></span></blockquote></body></html>