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 <d...@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-requ...@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 | smelik...@mirantis.com +7 (495) 640-4904, 0261 +7 (903) 156-0836 __________________________________________________________________________ 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