)]}'
{"manifests/keystone/auth.pp":[{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"c3935c6af3905670827a9b13da09f75cada86a5e","unresolved":false,"context_lines":[{"line_number":224,"context_line":"  $admin_url              \u003d \u0027http://127.0.0.1:8776/v1/%(tenant_id)s\u0027,"},{"line_number":225,"context_line":"  $service_name           \u003d \u0027cinder\u0027,"},{"line_number":226,"context_line":"  $service_type           \u003d \u0027volume\u0027,"},{"line_number":227,"context_line":"  $service_description    \u003d \u0027Cinder Service\u0027,"},{"line_number":228,"context_line":") {"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"  include ::cinder::deps"}],"source_content_type":"text/x-puppet","patch_set":2,"id":"9fdfeff1_703cc02e","line":227,"updated":"2019-02-13 19:04:14.000000000","message":"We usually undef out any params that are deprecated. Should we just rely on the user clearing out the endpoint rather than keeping these here so we do it? It seems a bit opinionated on the functionality.","commit_id":"2a7b5af0dccb13a28dec1c68eb7f4bc6e9ee9bea"},{"author":{"_account_id":21129,"name":"Alan Bishop","email":"abishopsweng@gmail.com","username":"ASBishop","status":"ex Red Hat"},"change_message_id":"51967367895f8b422f9343f997ff9771cd797046","unresolved":false,"context_lines":[{"line_number":224,"context_line":"  $admin_url              \u003d \u0027http://127.0.0.1:8776/v1/%(tenant_id)s\u0027,"},{"line_number":225,"context_line":"  $service_name           \u003d \u0027cinder\u0027,"},{"line_number":226,"context_line":"  $service_type           \u003d \u0027volume\u0027,"},{"line_number":227,"context_line":"  $service_description    \u003d \u0027Cinder Service\u0027,"},{"line_number":228,"context_line":") {"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"  include ::cinder::deps"}],"source_content_type":"text/x-puppet","patch_set":2,"id":"9fdfeff1_b358f230","line":227,"in_reply_to":"9fdfeff1_703cc02e","updated":"2019-02-13 19:21:20.000000000","message":"Yes, I retained the default values solely to facilitate removing the v1 service and endpoint. But you raise a good point about whether that chore should be left in the hands of the user.\n\nI will happily update this patch if that\u0027s a better way to go.","commit_id":"2a7b5af0dccb13a28dec1c68eb7f4bc6e9ee9bea"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"594f10e7b111efd715d530ffae201f0ba16469c6","unresolved":false,"context_lines":[{"line_number":224,"context_line":"  $admin_url              \u003d \u0027http://127.0.0.1:8776/v1/%(tenant_id)s\u0027,"},{"line_number":225,"context_line":"  $service_name           \u003d \u0027cinder\u0027,"},{"line_number":226,"context_line":"  $service_type           \u003d \u0027volume\u0027,"},{"line_number":227,"context_line":"  $service_description    \u003d \u0027Cinder Service\u0027,"},{"line_number":228,"context_line":") {"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"  include ::cinder::deps"}],"source_content_type":"text/x-puppet","patch_set":2,"id":"9fdfeff1_7367eaea","line":227,"in_reply_to":"9fdfeff1_b358f230","updated":"2019-02-13 19:24:40.000000000","message":"I think it\u0027s best to leave the removal up to the end user. I\u0027m not sure we can make assumptions about it not still being used for some reason","commit_id":"2a7b5af0dccb13a28dec1c68eb7f4bc6e9ee9bea"},{"author":{"_account_id":16137,"name":"Tobias Urdin","email":"tobias.urdin@binero.com","username":"tobasco"},"change_message_id":"4a2e8939ead6942cbe94d7431a825d930621ddc7","unresolved":false,"context_lines":[{"line_number":239,"context_line":"  # Always configure the original (non-v2|v3) user and user roles, as these"},{"line_number":240,"context_line":"  # can be used by the v2 and v3 services."},{"line_number":241,"context_line":"  keystone::resource::service_identity { \u0027cinder\u0027:"},{"line_number":242,"context_line":"    configure_user      \u003d\u003e $configure_user,"},{"line_number":243,"context_line":"    configure_user_role \u003d\u003e $configure_user_role,"},{"line_number":244,"context_line":"    configure_endpoint  \u003d\u003e false,"},{"line_number":245,"context_line":"    configure_service   \u003d\u003e false,"},{"line_number":246,"context_line":"    region              \u003d\u003e $region,"}],"source_content_type":"text/x-puppet","patch_set":2,"id":"9fdfeff1_b5a0e4f5","line":243,"range":{"start_line":242,"start_character":0,"end_line":243,"end_character":48},"updated":"2019-02-13 11:50:03.000000000","message":"Shouldn\u0027t we try to get rid of these? So instead of having 6 options where you can only set 2 without causing conflict atleast could be 4 and then in the future narrowed down even more?","commit_id":"2a7b5af0dccb13a28dec1c68eb7f4bc6e9ee9bea"},{"author":{"_account_id":21129,"name":"Alan Bishop","email":"abishopsweng@gmail.com","username":"ASBishop","status":"ex Red Hat"},"change_message_id":"5dab150952df6d456d38f201123ef93fd9d82127","unresolved":false,"context_lines":[{"line_number":239,"context_line":"  # Always configure the original (non-v2|v3) user and user roles, as these"},{"line_number":240,"context_line":"  # can be used by the v2 and v3 services."},{"line_number":241,"context_line":"  keystone::resource::service_identity { \u0027cinder\u0027:"},{"line_number":242,"context_line":"    configure_user      \u003d\u003e $configure_user,"},{"line_number":243,"context_line":"    configure_user_role \u003d\u003e $configure_user_role,"},{"line_number":244,"context_line":"    configure_endpoint  \u003d\u003e false,"},{"line_number":245,"context_line":"    configure_service   \u003d\u003e false,"},{"line_number":246,"context_line":"    region              \u003d\u003e $region,"}],"source_content_type":"text/x-puppet","patch_set":2,"id":"9fdfeff1_50e666b2","line":243,"range":{"start_line":242,"start_character":0,"end_line":243,"end_character":48},"in_reply_to":"9fdfeff1_b5a0e4f5","updated":"2019-02-13 13:16:02.000000000","message":"I wouldn\u0027t object, but don\u0027t know how to without creating a regression. \n\nThis module (auth.pp) was designed with the notion that there would be a\ncomplete set of parameters per API version, which I feel is somewhat\nmisguided. The user and user roles for v2 and v3 are optional (their\n$config_XXX parameters default to false). So, by default, the v2 and v3\nservices will use the user and role associated with $auth_name, and hence my\ncomment at L239.\n\nIf we deprecate $config_user and $config_user_role, then would we replace\ntheir use on L242 and L243 with a hard-coded true? I don\u0027t think that\u0027s\nappropriate because it would create a regression in the (rare) situation where\na someone does NOT want to use $auth_name because they\u0027re using $auth_name_v2|3.","commit_id":"2a7b5af0dccb13a28dec1c68eb7f4bc6e9ee9bea"}]}
