Maybe. I'm not up to speed on defcore/refstack requirements.. But, to put the question on the table, do folks want the OpenStack App-catalog to only have support for the "lowest-common-denominator" of artifacts and cloud capabilities, or instead allow for showcasing all that is possible when using cloud technology that major vendors have adopted but are not yet part of refstack/defcore?
-Keith On 5/27/15 6:58 PM, "Fox, Kevin M" <kevin....@pnnl.gov> wrote: >Should RefStack be involved here? To integrate tightly with the App >Catalog, the Cloud Provider would be required to run RefStack against >their cloud, the results getting registered to an App Catalog service in >that Cloud. The App Catalog UI in Horizon could then filter out from the >global App Catalog any apps that would be incompatible with their cloud. >I think the Android app store works kind of like that... > >Thanks, >Kevin >________________________________________ >From: Keith Bray [keith.b...@rackspace.com] >Sent: Wednesday, May 27, 2015 4:41 PM >To: OpenStack Development Mailing List (not for usage questions) >Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps > >In-line responses. Thanks for chipping in Monty. >-Keith > >On 5/27/15 6:03 PM, "Monty Taylor" <mord...@inaugust.com> wrote: > >>On 05/27/2015 06:35 PM, Keith Bray wrote: >>> Joe, regarding apps-catalog for any app deployable on OpenStack >>> (regardless of deployment technology), my two cents is that is a good >>> idea. I also believe, however, that the app-catalog needs to evolve >>> first with features that make it super simple to understand which >>> artifacts will work on which clouds (out-of-the-box) vs. needing >>> additional required dependencies or cloud operator software. My >>> guess is there will be a lot of discussions related to defcore, >>> and/or tagging artifacts with known public/private cloud >>> distributions the artifacts are known to work on. To the extent an >>> openstack operator or end user has to download/install 3rd party or >>> stack forge or non defcore openstack components in order to deploy an >>> artifact, the more sophisticated and complicated it becomes and we >>> need a way to depict that for items shown in the catalog. >>> >>> For example, I'd like to see a way to tag items in the catalog as >>> known-to-work on HP or Rackspace public cloud, or known to work on >>> RDO. Even a basic Heat template optimized for one cloud won't >>> necessarily work on another cloud without modification. >> >>That's an excellent point - I have two opposing thoughts to it. >> >>a) That we have to worry about the _vendor_ side of that is a bug and >>should be fixed. Since all clouds already have a service catalog, >>mapping out a "this app requires trove" should be easy enough. The other >>differences are ... let's just say as a user they do not provide me value > >I wouldn't call it a bug. By design, Heat is pluggable with different >resource implementations. And, different cloud run different plug-ins, >hence a template written for one cloud won't necessarily run on another >cloud unless that cloud also runs the same Heat plug-ins. > >> >>b) The state you describe is today's reality, and as much as wringing >>out hands and spitting may feel good, it doesn't get us anywhere. You >>do, in _fact_ need to know those things to use even basic openstack >>functions today- so we might as well deal with it. > >I don't buy the argument of you need to know those things to make >openstack function, because: The catalog _today_ is targeted more at the >end user, not the operator. The end user shouldn't need to know whether >trove is or is not set up, let alone how to do it. Maybe that isn't the >intention of the catalog, and probably worth sorting out. > >> >>I'll take this as an opportunity to point people towards work in this >>direction grew out of a collaboration between infra and ansible: >> >>http://git.openstack.org/cgit/openstack-infra/shade/ >>and >>http://git.openstack.org/cgit/openstack/os-client-config >> >>os-client-config knows about the differences between the clouds. It has, >>sadly, this file: >> >>http://git.openstack.org/cgit/openstack/os-client-config/tree/os_client_c >>o >>nfig/vendors.py >> >>Which lists as much knowledge as we've figured out so far about the >>differences between clouds. >> >>shade presents business logic to users so that they don't have to know. >>For instance: > >I'm all +1 on different artifact types with different deployment >mechanisms, including Ansible, in case that wasn't clear. As long as the >app-catalog supports letting the consumer know what they are in for and >expectations. I'm not clear on how the infra stuff works, but agree we >don't want cloud specific logic... I especially don't want the application >architect authors (e.g. The folks writing Heat templates and/or Murano >packages) to have to account for Cloud specific checks in their authoring >files. It'd be better to automate this on the catalog testing side at >best, or use author submission + voting as a low cost human method (but >not without problems in up-keep). > >> >>import shade >>cloud = shade.openstack_cloud() >>cloud.create_image( >> name='ubuntu-trusty', >> filename='ubuntu-trusty.qcow2', >> wait=True) >> >>Should upload an image to an openstack cloud no matter the deployer >>choices that are made. >> >>The new upstream ansible modules build on this - so if you say: >> >>os_server: name=ubuntu-test flavor_ram=1024 image='Ubuntu 14.04 LTS' >> config_drive=yes >> >>It _should_ just work. Of course, image names and image content across >>clouds vary - so you probably want: >> >>os_image: name=ubuntu-trusty file=ubuntu-trusty.qcow2 wait=yes >> register=image >>os_server: name=ubuntu-test flavor_ram=1024 image={{ image.id }} >> config_drive=yes >> >>And it should mostly just work everywhere. It's not strictly true - >>image uploading takes slightly more work (you need to know the needed >>format per-cloud) - but there is a role for that: >> >>https://github.com/emonty/ansible-build-image >> >>point being - this SHOULD be as easy as the above, but it's not. We're >>working on it out on the edges - but that work sadly has to be redone >>for each language and each framework. >> >>So - a) we should take note of the how hard this is and the fact that we >>need registries of capabilities - and b) we should fix it so that >>libraries like shade do not need to exist. I look forward to the day >>when I can retire it as a git repo. I fear that day will never come. > >+1 to registration of capabilities. That should be a core service me >thinks. Is there a project already for this? > >> >>I do strongly hope that things like the app catalog and Joe's suggest >>that it be able to host things like ansible playbooks bring in to stark >>relief how hard doing something so valuable really is these days. >> >>> Thanks, -Keith >>> >>> From: Joe Gordon >>> <joe.gord...@gmail.com<mailto:joe.gord...@gmail.com>> Reply-To: >>> "OpenStack Development Mailing List (not for usage questions)" >>> >>><openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack. >>>o >>>rg>> >>> >>> >>Date: Wednesday, May 27, 2015 5:20 PM >>> To: "OpenStack Development Mailing List (not for usage questions)" >>> >>><openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack. >>>o >>>rg>> >>> >>> >>Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps >>> >>> >>> >>> On Fri, May 22, 2015 at 9:06 PM, Christopher Aedo >>> <ca...@mirantis.com<mailto:ca...@mirantis.com>> wrote: I want to >>> start off by thanking everyone who joined us at the first working >>> session in Vancouver, and those folks who have already started adding >>> content to the app catalog. I was happy to see the enthusiasm and >>> excitement, and am looking forward to working with all of you to >>> build this into something that has a major impact on OpenStack >>> adoption by making it easier for our end users to find and share the >>> assets that run on our clouds. >>> >>> Great job. This is very exciting to see, I have been wanting >>> something like this for some time now. >>> >>> >>> The catalog: http://apps.openstack.org The repo: >>> https://github.com/stackforge/apps-catalog The wiki: >>> https://wiki.openstack.org/wiki/App-Catalog >>> >>> Please join us via IRC at #openstack-app-catalog on freenode. >>> >>> Our initial core team is Christopher Aedo, Tom Fifield, Kevin Fox, >>> Serg Melikyan. >>> >>> I¹ve started a doodle poll to vote on the initial IRC meeting >>> schedule, if you¹re interested in helping improve and build up this >>> catalog please vote for the day/time that works best and get >>> involved! http://doodle.com/vf3husyn4bdkui8w >>> >>> At the summit we managed to get one planning session together. We >>> captured that on etherpad[1], but I¹d like to highlight here a few >>> of the things we talked about working on together in the near term: >>> >>> -More information around asset dependencies (like clarifying >>> requirements for Heat templates or Glance images for instance), >>> potentially just by providing better guidance in what should be in >>> the description and attributes sections. -With respect to the assets >>> that are listed in the catalog, there¹s a need to account for >>> tagging, rating/scoring, and a way to have comments or a forum for >>> each asset so potential users can interact outside of the gerrit >>> review system. -Supporting more resource types (Sahara, Trove, Tosca, >>> others) >>> >>> What about expanding the scope of the application catalog to any >>> application that can run *on* OpenStack, versus the implied scope of >>> applications that can be deployed *by* (heat, murano, etc.) OpenStack >>> and *on* OpenStack services (nova, cinder etc.). This would mean >>> adding room for Ansible roles that provision openstack resources [0]. >>> And more generally it would reinforce the point that there is no >>> 'blessed' method of deploying applications on OpenStack, you can use >>> tools developed specifically for OpenStack or tools developed >>> elsewhere. >>> >>> >>> [0] >>> >>>https://github.com/ansible/ansible-modules-core/blob/1f99382dfb395c1b993 >>>b >>>2812122761371da1bad6/cloud/openstack/os_server.py >>> >>> -Discuss using glance artifact repository as the backend rather >>> than flat YAML files -REST API, enable searching/sorting, this would >>> ease native integration with other projects -Federated catalog >>> support (top level catalog including contents from sub-catalogs) - >>> I¹ll be working with the OpenStack infra team to get the server and >>> CI set up in their environment (though that work will not impact the >>> catalog as it stands today). >>> >>> I am pleased to see moving this to OpenStack Infra is a high >>> priority. >>> >>> A quick nslookup of http://apps.openstack.org shows it us currently >>> hosted on linode at >>> http://nb-23-239-6-45.fremont.nodebalancer.linode.com/. And last I >>> checked linode isn't OpenStack powered. >>> apps.openstack.org<http://apps.openstack.org> is a great example of >>> the type of application that should be easy to deploy with OpenStack, >>> since as far as I can tell it just needs a web server and that is it. >>> So wearing my OpenStack developer hat on, why did you go with linode >>> and not any one of the OpenStack based public clouds [1]? If >>> OpenStack is not a good solution for workloads like this, then it >>> would be great to know how what needs work. >>> >>> >>> [1] https://www.openstack.org/marketplace/public-clouds/ >>> >>> >>> There were a ton of great ideas that came up and it was clear there >>> was WAY more to discuss than we could accomplish in one short >>> session at the summit. I¹m looking forward to continuing the >>> conversation here on the mailing list, on IRC, and in Tokyo as well! >>> >>> [1] https://etherpad.openstack.org/p/YVR-app-catalog-plans >>> >>> -Christopher >>> >>> >>>________________________________________________________________________ >>>_ >>>_ >>> >>> >>OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> >>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://Ope >>>n >>>stack-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 >>> >> >> >>_________________________________________________________________________ >>_ >>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 > >__________________________________________________________________________ >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