Linch-pin feedback #147
Comments
|
Documentation is a constant work-in-progress. We know we are woefully behind on that. Until about 2 weeks ago we had no docs, so we're trying to make steady progress on that! Inconsistent field naming: Can you open a new issue to address this, specifically? This really is a bug and should be captured by some concerted work after a standard is decided upon. As for the other items you bring up: The lack of a top level namespace for the Python package components is captured in issue #133 The credentials problem has been raised before. We are working on a solution to credentials across the board, captured in #76 Debugging to a log file is already captured by #146 |
Sounds good. This is by far the biggest issue I encountered.
OK, I created #149. I'll close this now, since all the other ones are captured in issues. Thanks! |
|
@jlebon : Thank you for the feedback . We will working on the fixes. All the issues pointed out will be fixed in no time. |
To resolve the inconsistencies in topology field names schema_v4.json has been introduced. In schema_v4.json the major changes are as follows: <old field name> --> <new field name> res_group_type --> resource_group_type res_defs --> resource_definitions res_name --> name res_type --> type assoc_creds --> credentials new fields in topology: - schema_version Resolves: CentOS-PaaS-SIG#149 See also: CentOS-PaaS-SIG#147 Note: Though the schema_v4.json is introduced . linchpin will try to address backward compatibilty towards old schema through logic implemented in playbooks.
To resolve the inconsistencies in topology field names schema_v4.json has been introduced. In schema_v4.json the major changes are as follows: <old field name> --> <new field name> res_group_type --> resource_group_type res_defs --> resource_definitions res_name --> name res_type --> type assoc_creds --> credentials new fields in topology: - schema_version Resolves: CentOS-PaaS-SIG#149 See also: CentOS-PaaS-SIG#147 Note: Though the schema_v4.json is introduced . linchpin will try to address backward compatibilty towards old schema through logic implemented in playbooks.
To resolve the inconsistencies in topology field names schema_v4.json has been introduced. In schema_v4.json the major changes are as follows: <old field name> --> <new field name> res_group_type --> resource_group_type res_defs --> resource_definitions res_name --> name res_type --> type assoc_creds --> credentials new fields in topology: - schema_version Resolves: CentOS-PaaS-SIG#149 See also: CentOS-PaaS-SIG#147 Note: Though the schema_v4.json is introduced . linchpin will try to address backward compatibilty towards old schema through logic implemented in playbooks.
To resolve the inconsistencies in topology field names schema_v4.json has been introduced. In schema_v4.json the major changes are as follows: <old field name> --> <new field name> res_group_type --> resource_group_type res_defs --> resource_definitions res_name --> name res_type --> type assoc_creds --> credentials new fields in topology: - schema_version Resolves: CentOS-PaaS-SIG#149 See also: CentOS-PaaS-SIG#147 Note: Though the schema_v4.json is introduced . linchpin will try to address backward compatibilty towards old schema through logic implemented in playbooks.
To resolve the inconsistencies in topology field names schema_v4.json has been introduced. In schema_v4.json the major changes are as follows: <old field name> --> <new field name> res_group_type --> resource_group_type res_defs --> resource_definitions res_name --> name res_type --> type assoc_creds --> credentials new fields in topology: - schema_version Resolves: CentOS-PaaS-SIG#149 See also: CentOS-PaaS-SIG#147 Note: Though the schema_v4.json is introduced . linchpin will try to address backward compatibilty towards old schema through logic implemented in playbooks.
Hi all,
Thought I'd give some feedback from an exercise in trying out linch-pin for the first time. I understand a lot of the below is simply due to the project still being in its infancy, though I hope you still appreciate the feedback. :) Sorry in advance for the massive dump of issues in one shot. Some of those may already exist as independent issues.
Major issues:
Documentation is incomplete. There are no mentions of essential things like basic CLI usage (e.g.
init/rise/drop), the configuration file, credentials, etc... This makes it very hard for beginners to get started.Python packages are not namespaced, so e.g.
library/provision/outputsetc... are all dumped directly insite-packagesrather than e.g. alinchpin/dir. Esp. important since most of those are not even actual python modules.Credentials files have to be stored in the vars dir, which is in the bowels of the python site-packages dir.
Minor issues:
Inconsistent field naming. E.g. using
res_in some places andresource_in others. (I'd prefer the latter everywhere). Also, it's generally nicer in YAML to use-instead of_, but that's subjective of course :).Unconditional debug print statements used rather than e.g. a logging module. It makes the output a bit harder to understand.
The text was updated successfully, but these errors were encountered: