Re: [openstack-dev] [Murano] Versioning of Murano packages and MuranoPL classes
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:
1. 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.
2. 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'
3. 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.
4. 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
Re: [openstack-dev] [Murano] Versioning of Murano packages and MuranoPL classes
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
Re: [openstack-dev] [Murano] Versioning of Murano packages and MuranoPL classes
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.
--
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:
1. 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.
2. 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'
3. 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.
4. 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.
5. 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
Re: [openstack-dev] [Murano] Versioning of Murano packages and MuranoPL classes
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:
1. 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.
2. 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'
3. 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.
4. 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.
5. There is no mandatory need to add the the dependency on the core
library to the Requires
Re: [openstack-dev] [Murano] Versioning of Murano packages and MuranoPL classes
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:
1. 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.
2. 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'
3. 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.
4. 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.
5. 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.
6. All classes defined in a package are assumed to have a version
identical to the version of the package.
7. 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
