Open Stack

I'm thinking that refstack would have tests for things that aren't always required, but if they were there, it would ensure they were up to spec? If so, then we could use it to detect which standard but optional features where there and filter appropriately?

Ideally every cloud would provide everything every app would need, but I realize that's totally unrealistic. So is catering to the lowest common denominator. That would be no NaaS, and a lot of my templates need it. :/ I fear lowest common denominator at this point is strictly glance only. :/

Thanks,
Kevin
________________________________________
From: Keith Bray [keith.bray at RACKSPACE.COM]
Sent: Wednesday, May 27, 2015 5:20 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