Open Stack

Hi Chris,

concern regarding assets versioning in Community App Catalog indeed
affects Murano because we are constantly improving our language and
adding new features, e.g. we added ability to select existing Neutron
network for particular application in Liberty and if user wants to use
this feature - his application will be incompatible with Kilo. I think
this also valid for Heat because they HOT language is also improving
with each release.

Thank you for proposing workaround, I think this is a good way to
solve immediate blocker while Community App Catalog team is working on
resolving handling versions elegantly from they side. Kirill proposed
two changes in Murano to follow this approach that I've already +2 ed:

* https://review.openstack.org/225251 - openstack/murano-dashboard
* https://review.openstack.org/225249 - openstack/python-muranoclient

Looks like corresponding commit to Community App Catalog is already
merged [0] and our next step is to prepare new version of applications
from openstack/murano-apps and then figure out how to publish them
properly.

P.S. I've also talked with Alexander and Kirill regarding better ways
to handle versioning for assets in Community App Catalog and they
shared that they are starting working on PoC using Glance Artifact
Repository, probably they can share more details regarding this work
here. We would be happy to work on this together given that in Liberty
we implemented experimental support for package versioning inside the
Murano (e.g. having two version of the same app working side-by-side)
[1]

References:
[0] https://review.openstack.org/224869
[1] http://murano-specs.readthedocs.org/en/latest/specs/liberty/murano-versioning.html

On Thu, Sep 17, 2015 at 11:00 PM, Christopher Aedo <doc at aedo.net> wrote:
> One big thing missing from the App Catalog right now is the ability to
> version assets.  This is especially obvious with the Murano assets
> which have some version/release dependencies.  Ideally an app-catalog
> user would be able to pick an older version (ie "works with kilo
> rather than liberty"), but we don't have that functionality yet.
>
> We are working on resolving handling versions elegantly from the App
> Catalog side but in the short term we believe Murano is going to need
> a workaround.  In order to support multiple entries with the same name
> (i.e. Apache Tomcat package for both Kilo and Liberty) we are
> proposing the Liberty release of Murano have a new default URL, like:
>
> MURANO_REPO_URL="http://apps.openstack.org/api/v1/murano_repo/liberty/"
>
> We have a patch ready [1] which would redirect traffic hitting that
> URL to http://storage.apps.openstack.org.  If we take this approach,
> we will then retain the ability to manage where Murano fetches things
> from without requiring clients of the Liberty-Murano release to do
> anything.  For instance, if there is a need for Liberty versions of
> Murano packages to be different from Kilo, we could set up a
> Liberty-specific directory and put those versions there, and then
> adjust the redirect appropriately.
>
> What do you think?  We definitely need feedback here, otherwise we are
> likely to break things Murano relies on.  kzaitsev is active on IRC
> and was the one who highlighted this issue, but if there are other
> compatibility or version concerns as Murano continues to grow and
> improve, we could use one or two more people from Murano to stay in
> touch with us wherever you intersect with the App Catalog so we don't
> break something for you :)
>
> [1] https://review.openstack.org/#/c/224869/
>
> -Christopher
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelikyan at mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836