Re: [openstack-dev] [murano] [app-catalog] versions for murano assets in the catalog

[Fox, Kevin M]

To clarify a bit, We're unsure that running glance without keystone as a 
distribution mechanism for apps.openstack.org assets is a good idea/fit.

Having assets stored in the local cloud all in one place (In glance) seems like 
a very good idea to me.

We need closer communications between Murano, Glance, and App-Catalog going 
forward since each project has valuable things to contribute to the over all 
big picture.

Thanks,
Kevin

From: Christopher Aedo [d...@aedo.net]
Sent: Thursday, September 24, 2015 2:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [murano] [app-catalog] versions for murano assets 
in the catalog

On Tue, Sep 22, 2015 at 12:06 PM, Serg Melikyan <smelik...@mirantis.com> wrote:
> 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.

Yep, thanks, this looks like a step in the right direction to give us
some wiggle room to handle different versions of assets in the App
Catalog for the next few months.

Down the road we want to make sure that the App Catalog is not closely
tied to any other projects, or how those projects handle versions.  We
will clearly communicate our intentions around versions of assets (and
how to specify which version is desired when retrieving an asset) here
on the mailing list, during the weekly meetings, and during the weekly
cross-project meeting as well.

> 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

Thanks, looking forward to the PoC.  We have discussed whether or not
using Glance Artifact Repository makes sense for the App Catalog and
so far the consensus has been that it is not a great fit for what we
need.  Though it brings a lot of great stuff to the table, all we
really need is a place to drop large (and small) binaries.  Swift as a
storage component is the obvious choice for that - the metadata around
the asset itself (when it was added, by whom, rating, version, etc.)
will have to live in a DB anyway.  Given that, seems like Glance is
not an obvious great fit, but like I said I'm looking forward to
hearing/seeing more on this front :)

-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

__
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

Re: [openstack-dev] [murano] [app-catalog] versions for murano assets in the catalog

[Christopher Aedo]

On Tue, Sep 22, 2015 at 12:06 PM, Serg Melikyan  wrote:
> 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.

Yep, thanks, this looks like a step in the right direction to give us
some wiggle room to handle different versions of assets in the App
Catalog for the next few months.

Down the road we want to make sure that the App Catalog is not closely
tied to any other projects, or how those projects handle versions.  We
will clearly communicate our intentions around versions of assets (and
how to specify which version is desired when retrieving an asset) here
on the mailing list, during the weekly meetings, and during the weekly
cross-project meeting as well.

> 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

Thanks, looking forward to the PoC.  We have discussed whether or not
using Glance Artifact Repository makes sense for the App Catalog and
so far the consensus has been that it is not a great fit for what we
need.  Though it brings a lot of great stuff to the table, all we
really need is a place to drop large (and small) binaries.  Swift as a
storage component is the obvious choice for that - the metadata around
the asset itself (when it was added, by whom, rating, version, etc.)
will have to live in a DB anyway.  Given that, seems like Glance is
not an obvious great fit, but like I said I'm looking forward to
hearing/seeing more on this front :)

-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

Re: [openstack-dev] [murano] [app-catalog] versions for murano assets in the catalog

[Serg Melikyan]

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  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

[openstack-dev] [murano] [app-catalog] versions for murano assets in the catalog

[Christopher Aedo]

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