Alexander, do you plan to update the https://review.openstack.org/#/c/140402/
versioning spec? We can possibly try to make it a joint effort, if you like.
--
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc
On 14 Jul 2015 at 11:34:56, Alexander Tivelkov (ativel...@mirantis.com) wrote:
Gosha,
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.
--
Regards,
Alexander Tivelkov
On Mon, Jul 13, 2015 at 5:54 PM, Georgy Okrokvertskhov
<gokrokvertsk...@mirantis.com> wrote:
On Mon, Jul 13, 2015 at 2:19 AM, Alexander Tivelkov <ativel...@mirantis.com>
wrote:
Hi Gosha,
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.
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.
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.
--
Regards,
Alexander Tivelkov
On Fri, Jul 10, 2015 at 5:56 PM, Georgy Okrokvertskhov
<gokrokvertsk...@mirantis.com> wrote:
Hi Alex,
Thank you for the great summary.
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.
Thanks
Gosha
On Fri, Jul 10, 2015 at 4:53 AM, Alexander Tivelkov <ativel...@mirantis.com>
wrote:
Hi folks,
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.
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.
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.
Here is the detailed outcome of the session:
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.
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'
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 apps.openstack.org. It is suggested to use this
block in the deployment process as well, and extend its semantics.
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.
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.
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.
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.
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.
All classes defined in a package are assumed to have a version identical to the
version of the package.
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.
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.
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.
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.
The generation of the object model by dynamic UI also remains intact.
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.
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.
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.
(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.
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.
So, all the above cover most of our present needs for MuranoPL package and
class versioning.
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.
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.
[1]
https://github.com/openstack/murano-apps/blob/master/MySQL/package/manifest.yaml#L26
--
Regards,
Alexander Tivelkov
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
