Open Stack

Oh and one more thing... I think one of the first cloud apps we may want to consider is refstack. :)

That way users can easily deploy and test.

Thanks,
Kevin

________________________________
From: Keith Bray
Sent: Wednesday, May 27, 2015 5:20:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps

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.Fox at 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.bray at 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" <mordred at 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.gordon0 at gmail.com<mailto:joe.gordon0 at gmail.com>> Reply-To:
>>> "OpenStack Development Mailing List (not for usage questions)"
>>>
>>><openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.
>>>o
>>>rg>>
>>>
>>>
>>Date: Wednesday, May 27, 2015 5:20 PM
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>
>>><openstack-dev at lists.openstack.org<mailto:openstack-dev at 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
>>> <caedo at mirantis.com<mailto:caedo at 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-request at lists.openstack.org?subject:unsubscribe<http://Ope
>>>n
>>>Stack-dev-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150528/20fb6b6f/attachment.html>