Currently Murano supports part of it. It provides a per cloud region app store like functionality. But I think each deployer needs to load in the apps they want in the catalog. I'm thinking that ui should somehow plug into an openstack.org provided catalog of apps that OpenStack app developers can submit to via the openstack.org website. This would make it very simple to grow a large catalog of OpenStack hostable apps.
But also, Murano mostly just wraps heat templates. Having written quite a few heat templates, and trying to make them generic enough to work in this appstore like model, I can tell you its very very hard currently for things that aren't just a simple single server, and sometimes even that's hard. :/ The three major current stumbling blocks are: * Key management. (This helps https://blueprints.launchpad.net/barbican/+spec/vm-integration) * Lack of some basic conditional support in heat. (can be hacked around very nastily like https://github.com/EMSL-MSC/heat-templates/blob/master/cfn/lib/FloatingIp.yaml. Don't tell me that's not painful...) * NaaS being optional. (Requires implementing your own vpn's if the provider doens'nt give you NaaS... way to costly to do) Thanks, Kevin ________________________________________ From: Ihar Hrachyshka [ihrac...@redhat.com] Sent: Friday, April 17, 2015 9:34 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/17/2015 06:23 PM, Fox, Kevin M wrote: > Really, what I expect to see long term in a healthy OpenStack > ecosystem is some global AppStore like functionality baked in to > horizon. A user goes to it, selects "my awesome scalable web > hosting system", hits launch, and is given a link to login via > webbrowser to edit their site. Under the hood, the system just > stood up a trove database, an elasticsearch cluster in its own > network, a web tier, a load balancer etc. The user didnt have to > care how hard that use to be, and just gets charged for the > resources consumed. Benifiting the cloud deployer and the end user. > The easier it is to use/create/consume cloud resources the better > it is for the deployer. If a bit steaper learning curve up front is > nessisary, that sucks, but will be worth it. > > This sort of thing is what we need to get to, and is extremely > difficult if OpenStack clouds differ wildly in functionality. > Isn't it what Murano project is intended to do? /Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVMTYEAAoJEC5aWaUY1u57K2IH/A7hyLVMBmtnybih6TomSuyE MK1ZQIzSp2TmoUX8umwAi5d6OFvXxSZR2dm94TFXNedDsZUT2+PN/bOqJg0cXOdn URis7fWC1nU2scLB3SfW5jKgawCoM3R6rBiHHzKu2UrctujRz/obZpqrI5lUf4F6 +ONUYGkdL6eDe/g2tCQB6gfwNSFA44F+q193AdEh9IV/3725OJAvWKcD+iRpdEJq vVxLAh8KI6yokf2R9g+Vck3BLsltxQbjUuQjkyxYsRwq7L1vMcRqr4oTmQ2vRP+6 9dEQNlwEJpmDDqIRlL6vYIFH7NKM639EBtCoijdx6tM1oZ9bGoSwXhVtADBWw5U= =AD+V -----END PGP SIGNATURE----- __________________________________________________________________________ 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
