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