Open Stack

Yeah. Sounds reasonable. I just wanted to raise the discussion since one might affect the implementation of the other. 

In fact, thinking through it more, having the validate template api be restricted to just what the specific instance of heat can do actually might help play a part in the solution to the other issue.

If you go look at the template in the app catalog ui in horizon, it could call out to heat template validate at that point and let you know if its supported or not by your specific cloud. If it validated for all clouds, that wouldn't be an option.

Though there is another issue the catalog will eventually hit where we would like to have a repo of contributed templates that we can do some automated tests to ensure they either work or at least validate. The --all flag would probably help with that case. In the test environment, we might not be able to test against some advanced services but could at least tell if it was a valid template.

Thanks,
Kevin
________________________________________
From: Randall Burt [randall.burt at RACKSPACE.COM]
Sent: Tuesday, July 14, 2015 3:58 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure - second        thoughts

A feedback mechanism for users is obviously a "good thing", but IMO, not germane to the threads original purpose of how and when to expose supported resources in Heat. I cannot imagine us implementing such a feature directly.

This may be a good discussion to have in the context of app catalog exclusively and not in the context of Heat since we seem to be discussing a generally available catalog vs Heat running in a specific environment. These two issues are quite different in terms of "what's supported".

In the Heat case, the documentation in OpenStack is "good enough" IMO for "what are all the things Heat can possibly let me do" while the chosen endpoint is the place to answer "what are the things *this* installation of Heat will let me do". If the answer to the latter is unsatisfactory, then the user should already have mechanisms to encourage the operator to provide what's missing.

On Jul 14, 2015, at 5:31 PM, "Fox, Kevin M" <Kevin.Fox at pnnl.gov>
 wrote:

> Without a feedback loop of some kind, how does one solve issues like the following:
>
> * Operator decides users don't need neutron NaaS because its "too complicated and users don't need it" (Seen on the mailing list multiple times)
> * Software developer writes cloud templates that deploys software that needs private networks to work (For example, ElasticSearch)
> * User wants to deploy said software but can't discover a working version.
>
> User is sad because they can't find a working template to do what they want. They either reinvent the wheel, or give up and don't use the cloud for that task.
>
> Being able to close the loop and let the operator easily know the users actually need something they aren't providing gives them the opportunity to fix the issue, benefiting all 3 parties.
>
> Thanks,
> Kevin
>
> ________________________________________
> From: Randall Burt [randall.burt at RACKSPACE.COM]
> Sent: Tuesday, July 14, 2015 2:40 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure - second        thoughts
>
> Making users complain to admins that may have little to no control over what is and isn't available isn't a healthy strategy for user experience. Purposefully engineering hardship to try and influence operators to "do the right thing" in someone else's opinion sounds pretty counter productive to adoption as well.
>
> FWIW, as a user, I don't want to see things I can't use because it just wastes my time. I agree that the docs are a good place to see "all the things" while querying the service should tell me what's available to me at the time.
>
> On Jul 14, 2015, at 4:20 PM, "Fox, Kevin M" <Kevin.Fox at pnnl.gov>
> wrote:
>
>> We're kind of debating the same thing for the app catalog. Do we show templates that don't work on a given cloud since they wont work, potentially making useful tools hard to discover, or do we view it as an opportunity for users to complain to their admins that they need X feature in order to do what they need to do. Last time we talked about it, we were leaning towards the latter.
>>
>> Maybe a happy middle ground is to have enough smarts in the system to show the templates, identify what parts won't work, gray out the template but provide a ui to "notifify the admin" of desire for X to work. That way users can easily feed back their desires.
>>
>> Thanks,
>> Kevin
>> From: Pavlo Shchelokovskyy [pshchelokovskyy at mirantis.com]
>> Sent: Tuesday, July 14, 2015 11:34 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Heat] conditional resource exposure - second thoughts
>>
>> Hi Heaters,
>> currently we already expose to the user only resources for services deployed in the cloud [1], and soon we will do the same based on whether actual user roles allow creating specific resources [2]. Here I would like to get your opinion on some of my thoughts regarding behavior of resource-type-list, resource-type-show and template-validate with this new features.
>> resource-type-list
>> We already (or soon will) hide unavailable in the cloud / for the user resources from the listing. But what if we add an API flag e.g. --all to show all registered in the engine resources? That would give any user a glimpse of what their Orchestration service can manage in principle, so they can nag the cloud operator to install additional OpenStack components or give them required roles :)
>> resource-type-show
>> Right now the plan is to disable "showing" unavailable to the user resources. But may be we should leave this as it is, for the same purpose as above (or again add a --all flag or such)?
>> template-validate
>> Right now Heat is failing validation for templates containing resource types not registered in the engine (e.g. typo). Should we also make this call available services- and roles-sensitive? Or should we leave a way for a user to check validity of any template with any in principle supported resources?
>> The bottom line is we are good in making Heat service to be as much self-documented via its own API as possible - let's keep doing that and make any Heat deployment to be the Heat primer :)
>> Eager to hear your opinions.
>> [1] http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-services.html
>> [2] http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-roles.html
>> Best regards,
>> --
>> Dr. Pavlo Shchelokovskyy
>> Senior Software Engineer
>> Mirantis Inc
>> www.mirantis.com
>> __________________________________________________________________________
>> 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