)]}'
{"specs/auth-consolidation.rst":[{"author":{"_account_id":6525,"name":"Gilles Dubreuil","email":"gilles@redhat.com","username":"q-1illes-a"},"change_message_id":"30dba2e2c58626a465615215231c8b4409404ff0","unresolved":false,"context_lines":[{"line_number":19,"context_line":"* Flexibility - operators should be able to specify the authentication"},{"line_number":20,"context_line":"  credentials to use in several different ways: environment, config files,"},{"line_number":21,"context_line":"  etc."},{"line_number":22,"context_line":"* Security - some precautions should be taken to protect passwords, tokens, and"},{"line_number":23,"context_line":"  other secrets being passed to the shell command"},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9af37de9_0c656644","line":22,"updated":"2015-05-11 05:11:03.000000000","message":"How to hide from the approach taken by OSC?\n\nFor example, when OSC uses options to pass parameters, i.e --os-auth-password:\n# puppet resource keystone_user foo ensure\u003dpresent password\u003dblah\n\nBy allowing this we fall in the ps trap!","commit_id":"41e280eaeb4d0fa845269ac957ebc820f9908c34"},{"author":{"_account_id":6525,"name":"Gilles Dubreuil","email":"gilles@redhat.com","username":"q-1illes-a"},"change_message_id":"30dba2e2c58626a465615215231c8b4409404ff0","unresolved":false,"context_lines":[{"line_number":44,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"There should be several sources of authentication credentials, each with its"},{"line_number":47,"context_line":"own precedence:"},{"line_number":48,"context_line":"* lowest: A configuration file like `openrc` or the new openstack client"},{"line_number":49,"context_line":"  config file"},{"line_number":50,"context_line":"* next: The application configuration file, from the Keystone authentication"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9af37de9_2c9b8acb","line":47,"updated":"2015-05-11 05:11:03.000000000","message":"The ENV variables are at the lowest, because they\u0027re a de facto default if nothing else is provided.\n\nThe RC file to be second and then configuration file afterward, as fail safe.","commit_id":"41e280eaeb4d0fa845269ac957ebc820f9908c34"},{"author":{"_account_id":6525,"name":"Gilles Dubreuil","email":"gilles@redhat.com","username":"q-1illes-a"},"change_message_id":"30dba2e2c58626a465615215231c8b4409404ff0","unresolved":false,"context_lines":[{"line_number":57,"context_line":"  the form `OS_PARAMNAME` e.g. `OS_USERNAME`, `OS_PASSWORD`, etc.  The operator"},{"line_number":58,"context_line":"  should be able to set these environment variables in the puppet execution"},{"line_number":59,"context_line":"  environment to override any settings in the openstack or app config file."},{"line_number":60,"context_line":"* next: An override parameter.  For example, the keystone_user `password`"},{"line_number":61,"context_line":"  provider method needs to test if a users password is valid.  The code should"},{"line_number":62,"context_line":"  be able to say \"use these credentials and ignore anything else\"."},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9af37de9_2ce94a1b","line":60,"updated":"2015-05-11 05:11:03.000000000","message":"An openstack client parameter always override any ENV setup, there is no need for this to generalize it. Providers just make the call directly to Puppet::Provider::Openstack.authenticate_request.\n\nThis case can be removed","commit_id":"41e280eaeb4d0fa845269ac957ebc820f9908c34"},{"author":{"_account_id":6525,"name":"Gilles Dubreuil","email":"gilles@redhat.com","username":"q-1illes-a"},"change_message_id":"30dba2e2c58626a465615215231c8b4409404ff0","unresolved":false,"context_lines":[{"line_number":89,"context_line":"continue to work as before."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"Module API impact"},{"line_number":93,"context_line":"-----------------"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"The `openstacklib` `Puppet::Provider::Openstack` `self.request` method should"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9af37de9_c7a979e1","line":92,"updated":"2015-05-11 05:11:03.000000000","message":"What about a class managing the authentication instead ?","commit_id":"41e280eaeb4d0fa845269ac957ebc820f9908c34"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"bd237b19be9651d09877f9d6983f0fd46940b913","unresolved":false,"context_lines":[{"line_number":19,"context_line":"applications configuration\u0027s files."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Solution description"},{"line_number":23,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"The targeted solution is to allow to interface to openstack (OSC) using Keystone"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7ad8896b_e8d7af21","line":22,"updated":"2015-05-11 19:31:43.000000000","message":"This needs to follow the template and describe the problem first, not the solution first.","commit_id":"81721067b19a1e0ebf255b887e91a6361e2c5a46"},{"author":{"_account_id":6525,"name":"Gilles Dubreuil","email":"gilles@redhat.com","username":"q-1illes-a"},"change_message_id":"caf4f02ef1a3ee257f995244b5fef38020cc0f50","unresolved":false,"context_lines":[{"line_number":19,"context_line":"applications configuration\u0027s files."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Solution description"},{"line_number":23,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"The targeted solution is to allow to interface to openstack (OSC) using Keystone"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da1255d7_095fa90f","line":22,"in_reply_to":"7ad8896b_e8d7af21","updated":"2015-05-12 00:25:53.000000000","message":"I changed that, my bad! Thinking in terms of solutions :)","commit_id":"81721067b19a1e0ebf255b887e91a6361e2c5a46"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"bd237b19be9651d09877f9d6983f0fd46940b913","unresolved":false,"context_lines":[{"line_number":31,"context_line":"---------------"},{"line_number":32,"context_line":"As part of the initial implementation of openstacklib, there was the option for"},{"line_number":33,"context_line":"the authentication details, or credentials, to be provided as parameters to a"},{"line_number":34,"context_line":"resource. It turned out to be impracticable, because providers shouldn\u0027t have"},{"line_number":35,"context_line":"different credentials based on a resource\u0027s instance context."},{"line_number":36,"context_line":"This is not sustainable for OpenStack types/providers"},{"line_number":37,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7ad8896b_08bafbe1","line":34,"updated":"2015-05-11 19:31:43.000000000","message":"impractical, not impracticable","commit_id":"81721067b19a1e0ebf255b887e91a6361e2c5a46"},{"author":{"_account_id":6525,"name":"Gilles Dubreuil","email":"gilles@redhat.com","username":"q-1illes-a"},"change_message_id":"caf4f02ef1a3ee257f995244b5fef38020cc0f50","unresolved":false,"context_lines":[{"line_number":31,"context_line":"---------------"},{"line_number":32,"context_line":"As part of the initial implementation of openstacklib, there was the option for"},{"line_number":33,"context_line":"the authentication details, or credentials, to be provided as parameters to a"},{"line_number":34,"context_line":"resource. It turned out to be impracticable, because providers shouldn\u0027t have"},{"line_number":35,"context_line":"different credentials based on a resource\u0027s instance context."},{"line_number":36,"context_line":"This is not sustainable for OpenStack types/providers"},{"line_number":37,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da1255d7_09b6893d","line":34,"in_reply_to":"7ad8896b_08bafbe1","updated":"2015-05-12 00:25:53.000000000","message":"Thanks! Excuse my French!","commit_id":"81721067b19a1e0ebf255b887e91a6361e2c5a46"},{"author":{"_account_id":9983,"name":"Richard Megginson","email":"rmeggins@redhat.com","username":"rmeggins"},"change_message_id":"575ace1456c8106b2d9c359ef7890b978540d5c6","unresolved":false,"context_lines":[{"line_number":62,"context_line":"   an OpenStack application configuration file can be used by the provider."},{"line_number":63,"context_line":"   A Ruby module, will provide the framework that any provider can include if"},{"line_number":64,"context_line":"   needed, to interface with such configuration file and allow to use its"},{"line_number":65,"context_line":"   credentials details."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"The implementation must be flexible to accommodate the new Keystone"},{"line_number":68,"context_line":"authentication types now and in the future, without having to re-factor or alter"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5ad58531_70ce0e85","line":65,"updated":"2015-05-11 19:50:21.000000000","message":"I disagree.  I think the lowest precedence should be the RC file.   I think it will be more likely that operators will create a more or less generic RC file which will be applied to a wide variety of systems.  The first level to override these is the app config data, which will also be provided by the operator, and will be more specific than the RC file.  For even more specific settings, or to allow the operator to override both the RC file and the app config file, the operator should be able to set ENV.\n\nFinally, there should be a way for a puppet resource writer to override the above.  For example, `keystone_user.password` must be able to provide the correct parameters.  If `keystone_user.password` sets ENV, the parameters set may be overridden by the RC or app config file.  There must be a way for a resource provider to absolutely override any other config settings.","commit_id":"81721067b19a1e0ebf255b887e91a6361e2c5a46"},{"author":{"_account_id":9983,"name":"Richard Megginson","email":"rmeggins@redhat.com","username":"rmeggins"},"change_message_id":"ed537a182a435dd844f1d3207ded446b568d413f","unresolved":false,"context_lines":[{"line_number":62,"context_line":"   an OpenStack application configuration file can be used by the provider."},{"line_number":63,"context_line":"   A Ruby module, will provide the framework that any provider can include if"},{"line_number":64,"context_line":"   needed, to interface with such configuration file and allow to use its"},{"line_number":65,"context_line":"   credentials details."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"The implementation must be flexible to accommodate the new Keystone"},{"line_number":68,"context_line":"authentication types now and in the future, without having to re-factor or alter"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5ad58531_8726da14","line":65,"in_reply_to":"5ad58531_1ce241a0","updated":"2015-05-11 22:27:50.000000000","message":"So keystone_user.password would look something like this::\n\n    localenv[\u0027OS_USERNAME\u0027] \u003d \u0027username\u0027\n    localenv[\u0027OS_PASSWORD\u0027] \u003d \u0027password\u0027\n    localenv[\u0027OS_TENANT_NAME\u0027] \u003d \u0027tenant\u0027\n    localenv[\u0027OS_AUTH_URL\u0027] \u003d \u0027authurl\u0027\n    withenv(localenv) do\n       authenticate_request(\u0027token\u0027, \u0027issue\u0027, .....)\n    end\n\nAnd authenticate_request would ignore ENV, openrc, and the app config file.\n\nWhat precedence should the app config file have?","commit_id":"81721067b19a1e0ebf255b887e91a6361e2c5a46"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"7fa1fb847b6672397770288195abf8cc8599225a","unresolved":false,"context_lines":[{"line_number":62,"context_line":"   an OpenStack application configuration file can be used by the provider."},{"line_number":63,"context_line":"   A Ruby module, will provide the framework that any provider can include if"},{"line_number":64,"context_line":"   needed, to interface with such configuration file and allow to use its"},{"line_number":65,"context_line":"   credentials details."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"The implementation must be flexible to accommodate the new Keystone"},{"line_number":68,"context_line":"authentication types now and in the future, without having to re-factor or alter"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5ad58531_a171c6e2","line":65,"in_reply_to":"5ad58531_70ce0e85","updated":"2015-05-11 21:20:33.000000000","message":"I\u0027m not sure I agree with the disagreement. Environment variables and rc files should be essentially the same precedence.\n\nI don\u0027t understand why the resource needs to be able to override the other settings, that seems like it will cause a lot of unexpected behavior that will be hard to debug. The precedence laid out gives environment variables the highest precedence, so I think with the example of keystone_user\u0027s password methods it should be fine. Resources can also set --os-* flags if they need to, which would override anything else, but again I don\u0027t see why they would need to.","commit_id":"81721067b19a1e0ebf255b887e91a6361e2c5a46"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"ef644cb270025519104badf43fedff44970a2851","unresolved":false,"context_lines":[{"line_number":62,"context_line":"   an OpenStack application configuration file can be used by the provider."},{"line_number":63,"context_line":"   A Ruby module, will provide the framework that any provider can include if"},{"line_number":64,"context_line":"   needed, to interface with such configuration file and allow to use its"},{"line_number":65,"context_line":"   credentials details."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"The implementation must be flexible to accommodate the new Keystone"},{"line_number":68,"context_line":"authentication types now and in the future, without having to re-factor or alter"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5ad58531_1ce241a0","line":65,"in_reply_to":"5ad58531_7ce70513","updated":"2015-05-11 21:54:43.000000000","message":"\u003e But they can\u0027t actually be the same - which one should come first?\n\nEnvironment variables first and openrc second is fine. I just don\u0027t agree with the config file coming between them.\n\n\u003e So how would keystone_user.password be implemented? I just don\u0027t see it.\n\nI think I need a more concrete example of what you\u0027re concerned about.\n\nIf the password getter needs to set OS_PASSWORD in order to attempt to authenticate as the user, it can set that environment variable and restore the old environment afterword. Since environment variables have the highest precedence for openstacklib\u0027s authentication, this temporary OS_PASSWORD will be used for that request.","commit_id":"81721067b19a1e0ebf255b887e91a6361e2c5a46"},{"author":{"_account_id":6525,"name":"Gilles Dubreuil","email":"gilles@redhat.com","username":"q-1illes-a"},"change_message_id":"caf4f02ef1a3ee257f995244b5fef38020cc0f50","unresolved":false,"context_lines":[{"line_number":62,"context_line":"   an OpenStack application configuration file can be used by the provider."},{"line_number":63,"context_line":"   A Ruby module, will provide the framework that any provider can include if"},{"line_number":64,"context_line":"   needed, to interface with such configuration file and allow to use its"},{"line_number":65,"context_line":"   credentials details."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"The implementation must be flexible to accommodate the new Keystone"},{"line_number":68,"context_line":"authentication types now and in the future, without having to re-factor or alter"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da1255d7_a9e65de6","line":65,"in_reply_to":"5ad58531_8726da14","updated":"2015-05-12 00:25:53.000000000","message":"I agree per Colleen\u0027s latest comment.\n\nI think the configuration file should be used only as last resort of getting credentials details nothing else.\n\n| I think I need a more concrete example of what you\u0027re concerned about.\n\nI believe Richard is talking about the keystone_user case which needs to validate the password (openstack token issue ...).\n\nThe answer to such requests can call directly authenticate_request and provide auth details.\n\nIn the token issue example:\nPuppet::Provider::Openstack.authenticate_request(\u0027token\u0027, \u0027issue\u0027, [[\u0027--format\u0027, \u0027value\u0027, \u0027--os-username\u0027, resource[:name] , \u0027--os-project-name\u0027, resource[:tenant], \u0027--os-auth-url\u0027, endpoint, \u0027--os-password\u0027, resource[:password]]])\n\nAlthough this is a very particular case if not the only one. But that\u0027s okay since the provider can always issue an authenticate_request call instead of using the request method. The latter being the one fetching/validating credentials.\n\nNow again what are the uses cases besides this one? Maybe we don\u0027t know/see alll of them yet, but we don\u0027t have to worry too much about them since we know there will be able to pass their specific options/credentials needs to OSC directly through authenticate_request. I don\u0027t think there is any need for factoring anything here, so we can move on.","commit_id":"81721067b19a1e0ebf255b887e91a6361e2c5a46"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"d023be335e9235cc4d7b5ce17103e179f6ed99d7","unresolved":false,"context_lines":[{"line_number":62,"context_line":"   an OpenStack application configuration file can be used by the provider."},{"line_number":63,"context_line":"   A Ruby module, will provide the framework that any provider can include if"},{"line_number":64,"context_line":"   needed, to interface with such configuration file and allow to use its"},{"line_number":65,"context_line":"   credentials details."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"The implementation must be flexible to accommodate the new Keystone"},{"line_number":68,"context_line":"authentication types now and in the future, without having to re-factor or alter"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da1255d7_6920654a","line":65,"in_reply_to":"5ad58531_8726da14","updated":"2015-05-11 23:40:11.000000000","message":"That code looks fine to me.\n\nwithenv sets ENV, so authenticate_request isn\u0027t really ignoring it: https://github.com/puppetlabs/puppet/blob/master/lib/puppet/util.rb#L31\n\nEarlier I said \"Since environment variables have the highest precedence for openstacklib\u0027s authentication, this temporary OS_PASSWORD will be used for that request.\" But it looks like authenticate_request doesn\u0027t deal with any of that anyways, it just assumes the credentials are set somehow in the *args or ENV, so I really don\u0027t see how this matters to the password getter: https://review.openstack.org//#/c/180407/10/lib/puppet/provider/openstack.rb\n\nI think the config file should have the lowest precedence but I don\u0027t think that\u0027s actually relevant to how the password gets set.","commit_id":"81721067b19a1e0ebf255b887e91a6361e2c5a46"},{"author":{"_account_id":9983,"name":"Richard Megginson","email":"rmeggins@redhat.com","username":"rmeggins"},"change_message_id":"b6d251b21eae715695143f8dc07e112c084d8b55","unresolved":false,"context_lines":[{"line_number":62,"context_line":"   an OpenStack application configuration file can be used by the provider."},{"line_number":63,"context_line":"   A Ruby module, will provide the framework that any provider can include if"},{"line_number":64,"context_line":"   needed, to interface with such configuration file and allow to use its"},{"line_number":65,"context_line":"   credentials details."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"The implementation must be flexible to accommodate the new Keystone"},{"line_number":68,"context_line":"authentication types now and in the future, without having to re-factor or alter"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5ad58531_7ce70513","line":65,"in_reply_to":"5ad58531_a171c6e2","updated":"2015-05-11 21:38:34.000000000","message":"\u003e Environment variables and rc files should be essentially the same precedence.\n\nBut they can\u0027t actually be the same - which one should come first?\n\n\u003e The precedence laid out gives environment variables the highest precedence, so I think with the example of keystone_user\u0027s password methods it should be fine.\n\nSo how would keystone_user.password be implemented?  I just don\u0027t see it.\n\n\u003e Resources can also set --os-* flags if they need to, which would override anything else,\n\nExcept for passwords/tokens/other secrets which should be passed as environment variables.","commit_id":"81721067b19a1e0ebf255b887e91a6361e2c5a46"},{"author":{"_account_id":9983,"name":"Richard Megginson","email":"rmeggins@redhat.com","username":"rmeggins"},"change_message_id":"f3f4562deba61662136dfb7d110503ae235f9de8","unresolved":false,"context_lines":[{"line_number":62,"context_line":"   an OpenStack application configuration file can be used by the provider."},{"line_number":63,"context_line":"   A Ruby module, will provide the framework that any provider can include if"},{"line_number":64,"context_line":"   needed, to interface with such configuration file and allow to use its"},{"line_number":65,"context_line":"   credentials details."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"The implementation must be flexible to accommodate the new Keystone"},{"line_number":68,"context_line":"authentication types now and in the future, without having to re-factor or alter"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da1255d7_c993d14e","line":65,"in_reply_to":"da1255d7_6920654a","updated":"2015-05-11 23:46:19.000000000","message":"Hmm - I didn\u0027t see that withenv _adds_ the given hash to ENV, preserving the other values in ENV.  That\u0027s not good.  That means the caller has to ensure that there are no other authentication related environment variables in ENV.  For example, what if keystone_user.password wants to authenticate with OS_USERNAME, OS_PASSWORD, OS_TENANT_NAME, OS_AUTH_URL?  It has to first remove OS_USER_ID, OS_PROJECT_ID, OS_USER_DOMAIN_NAME, etc. etc. from ENV.  Either that, or we use a custom version of withenv that clears ENV first before setting whatever is in the given hash.  But that will wipe out things like PATH and LD_LIBRARY_PATH and RUBYLIB etc.  So we need a custom withenv that will only wipe out OS_* from ENV?","commit_id":"81721067b19a1e0ebf255b887e91a6361e2c5a46"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"73b8664881e17c95044e7d511d21c2acdedf02f5","unresolved":false,"context_lines":[{"line_number":13,"context_line":"https://blueprints.launchpad.net/puppet-openstacklib/+spec/auth-consolidation"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"OpenStack Puppet modules providers are managing their resources using"},{"line_number":16,"context_line":"openstackclient-python (OSC), the \u0027openstack\u0027 CLI, to interface to"},{"line_number":17,"context_line":"OpenStack."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Class inheritance between Puppet::Provider::Openstack and providers using the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a016987_bce6b541","line":16,"updated":"2015-05-22 22:42:47.000000000","message":"python-openstackclient not openstackclient-python","commit_id":"cf712f2b0029f4c6472b9008eb06c6b61dbfc42b"},{"author":{"_account_id":6525,"name":"Gilles Dubreuil","email":"gilles@redhat.com","username":"q-1illes-a"},"change_message_id":"a108dcf0429b5cdd04dbbff127d68ce04f39fb8b","unresolved":false,"context_lines":[{"line_number":13,"context_line":"https://blueprints.launchpad.net/puppet-openstacklib/+spec/auth-consolidation"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"OpenStack Puppet modules providers are managing their resources using"},{"line_number":16,"context_line":"openstackclient-python (OSC), the \u0027openstack\u0027 CLI, to interface to"},{"line_number":17,"context_line":"OpenStack."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Class inheritance between Puppet::Provider::Openstack and providers using the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a016987_a20999df","line":16,"in_reply_to":"7a016987_bce6b541","updated":"2015-05-27 06:35:30.000000000","message":"Thanks","commit_id":"cf712f2b0029f4c6472b9008eb06c6b61dbfc42b"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"73b8664881e17c95044e7d511d21c2acdedf02f5","unresolved":false,"context_lines":[{"line_number":23,"context_line":"There are security issues when using openstack client command passing"},{"line_number":24,"context_line":"arguments that are visible from PS."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"This Blue Print was initially called auth-consolidation, it\u0027s a misnomer!"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a016987_7cecbd29","line":26,"updated":"2015-05-22 22:42:47.000000000","message":"Then the file name and topic should be changed.\n\nThe scope of this blueprint has changed a lot between when richm proposed it and when gildub took it over, is there a different problem that richm was trying to address that should be captured here or in a different blueprint?","commit_id":"cf712f2b0029f4c6472b9008eb06c6b61dbfc42b"},{"author":{"_account_id":6525,"name":"Gilles Dubreuil","email":"gilles@redhat.com","username":"q-1illes-a"},"change_message_id":"a108dcf0429b5cdd04dbbff127d68ce04f39fb8b","unresolved":false,"context_lines":[{"line_number":23,"context_line":"There are security issues when using openstack client command passing"},{"line_number":24,"context_line":"arguments that are visible from PS."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"This Blue Print was initially called auth-consolidation, it\u0027s a misnomer!"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a016987_e29b1171","line":26,"in_reply_to":"7a016987_0f7d6db1","updated":"2015-05-27 06:35:30.000000000","message":"Ok, wasn\u0027t sure it was appropriate to change topic and file name.\nWill do that.","commit_id":"cf712f2b0029f4c6472b9008eb06c6b61dbfc42b"},{"author":{"_account_id":9983,"name":"Richard Megginson","email":"rmeggins@redhat.com","username":"rmeggins"},"change_message_id":"7cd930e1ce591dce386499eb11eb5dd174b2ca30","unresolved":false,"context_lines":[{"line_number":23,"context_line":"There are security issues when using openstack client command passing"},{"line_number":24,"context_line":"arguments that are visible from PS."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"This Blue Print was initially called auth-consolidation, it\u0027s a misnomer!"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a016987_0f7d6db1","line":26,"in_reply_to":"7a016987_7cecbd29","updated":"2015-05-25 17:10:55.000000000","message":"The inifile support has been dropped (not essential), and the order of precedence is somewhat less strict with the latest code.  I believe gildub is going to update the bp when the dust settles a bit.","commit_id":"cf712f2b0029f4c6472b9008eb06c6b61dbfc42b"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"73b8664881e17c95044e7d511d21c2acdedf02f5","unresolved":false,"context_lines":[{"line_number":24,"context_line":"arguments that are visible from PS."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"This Blue Print was initially called auth-consolidation, it\u0027s a misnomer!"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Problem description"},{"line_number":30,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a016987_fc4e6d39","line":27,"updated":"2015-05-22 22:42:47.000000000","message":"This section above that starts describing the problem should be under the problem description section.","commit_id":"cf712f2b0029f4c6472b9008eb06c6b61dbfc42b"},{"author":{"_account_id":6525,"name":"Gilles Dubreuil","email":"gilles@redhat.com","username":"q-1illes-a"},"change_message_id":"a108dcf0429b5cdd04dbbff127d68ce04f39fb8b","unresolved":false,"context_lines":[{"line_number":24,"context_line":"arguments that are visible from PS."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"This Blue Print was initially called auth-consolidation, it\u0027s a misnomer!"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Problem description"},{"line_number":30,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a016987_8298dd6b","line":27,"in_reply_to":"7a016987_fc4e6d39","updated":"2015-05-27 06:35:30.000000000","message":"Reading carefully the template file to respect the practice...","commit_id":"cf712f2b0029f4c6472b9008eb06c6b61dbfc42b"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"73b8664881e17c95044e7d511d21c2acdedf02f5","unresolved":false,"context_lines":[{"line_number":33,"context_line":"provider instance through the :auth parameter but is not available as a class"},{"line_number":34,"context_line":"method.  This has 2 implications:"},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"- Provider class methods such as self.instances and self.fetch cannot rely on"},{"line_number":37,"context_line":"the :auth information. This is breaking the rules of Puppet Types/Providers."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"- The current approach use class inheritance from Puppet::Provider::Openstack"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a016987_7c2f1d3f","line":36,"updated":"2015-05-22 22:42:47.000000000","message":"self.prefetch not self.fetch","commit_id":"cf712f2b0029f4c6472b9008eb06c6b61dbfc42b"},{"author":{"_account_id":6525,"name":"Gilles Dubreuil","email":"gilles@redhat.com","username":"q-1illes-a"},"change_message_id":"a108dcf0429b5cdd04dbbff127d68ce04f39fb8b","unresolved":false,"context_lines":[{"line_number":33,"context_line":"provider instance through the :auth parameter but is not available as a class"},{"line_number":34,"context_line":"method.  This has 2 implications:"},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"- Provider class methods such as self.instances and self.fetch cannot rely on"},{"line_number":37,"context_line":"the :auth information. This is breaking the rules of Puppet Types/Providers."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"- The current approach use class inheritance from Puppet::Provider::Openstack"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a016987_c2dc951a","line":36,"in_reply_to":"7a016987_7c2f1d3f","updated":"2015-05-27 06:35:30.000000000","message":"A yeah, thanks.","commit_id":"cf712f2b0029f4c6472b9008eb06c6b61dbfc42b"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"73b8664881e17c95044e7d511d21c2acdedf02f5","unresolved":false,"context_lines":[{"line_number":68,"context_line":"openstacklib/provider/openstack methods to be moved to an authentication module."},{"line_number":69,"context_line":"The module acts as an interface to provider classes that extend the module,"},{"line_number":70,"context_line":"which makes all the methods needed available by a provider class i.e"},{"line_number":71,"context_line":"Puppet::Provider::Keystone and not its super class Puppet::Provider::Openstack"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Also the use of credentials on a CLI (spawned command like"},{"line_number":74,"context_line":"openstack --os-password\u003dsecret) must be forbidden in order to not be visible via"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a016987_b7612ed5","line":71,"updated":"2015-05-22 22:42:47.000000000","message":"Can you explain more what the purpose of this is?","commit_id":"cf712f2b0029f4c6472b9008eb06c6b61dbfc42b"},{"author":{"_account_id":6525,"name":"Gilles Dubreuil","email":"gilles@redhat.com","username":"q-1illes-a"},"change_message_id":"a108dcf0429b5cdd04dbbff127d68ce04f39fb8b","unresolved":false,"context_lines":[{"line_number":68,"context_line":"openstacklib/provider/openstack methods to be moved to an authentication module."},{"line_number":69,"context_line":"The module acts as an interface to provider classes that extend the module,"},{"line_number":70,"context_line":"which makes all the methods needed available by a provider class i.e"},{"line_number":71,"context_line":"Puppet::Provider::Keystone and not its super class Puppet::Provider::Openstack"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Also the use of credentials on a CLI (spawned command like"},{"line_number":74,"context_line":"openstack --os-password\u003dsecret) must be forbidden in order to not be visible via"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a016987_82345d4a","line":71,"in_reply_to":"7a016987_b7612ed5","updated":"2015-05-27 06:35:30.000000000","message":"The methods of module Puppet::Provider::Openstack::Auth are available as class methods to the providers extending it.\n\nI\u0027ll update this section accordingly.","commit_id":"cf712f2b0029f4c6472b9008eb06c6b61dbfc42b"}]}