)]}'
{"specs/liberty/cloud-namespaces.rst":[{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"a89babc51f20486808da70025e2c1d969655abe9","unresolved":false,"context_lines":[{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"`bp cloud-or-region-namespaces \u003chttps://blueprints.launchpad.net/keystone/+spec/cloud-or-region-namespaces\u003e`_"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"OpenStack is getting extended to Intercloud deployment model, where"},{"line_number":14,"context_line":"multiple providers setup their clouds and collaborate to support"},{"line_number":15,"context_line":"notion of Intercloud. In this model each cloud entity will be operated"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_9b42680f","line":12,"updated":"2015-05-04 08:28:27.000000000","message":"cloud-or-region-namespaces vs filename cloud-namespaces.rst.\nThis should be unified.","commit_id":"100eac3f851e14fa36bcd507dd78fc91240b5ffb"},{"author":{"_account_id":994,"name":"Arvind Tiwari","email":"arvindt7@gmail.com","username":"arvind-tiwari"},"change_message_id":"050d754a9643e4eb19e110eb67a898d7f3ce41d8","unresolved":false,"context_lines":[{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"`bp cloud-or-region-namespaces \u003chttps://blueprints.launchpad.net/keystone/+spec/cloud-or-region-namespaces\u003e`_"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"OpenStack is getting extended to Intercloud deployment model, where"},{"line_number":14,"context_line":"multiple providers setup their clouds and collaborate to support"},{"line_number":15,"context_line":"notion of Intercloud. In this model each cloud entity will be operated"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_0485c605","line":12,"in_reply_to":"3acd31a7_9b42680f","updated":"2015-05-04 20:25:39.000000000","message":"Sure","commit_id":"100eac3f851e14fa36bcd507dd78fc91240b5ffb"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"feb6ecce606c6fca61e83dc296ff7b13b764f3d9","unresolved":false,"context_lines":[{"line_number":14,"context_line":"multiple providers setup their clouds and collaborate to support"},{"line_number":15,"context_line":"notion of Intercloud. In this model each cloud entity will be operated"},{"line_number":16,"context_line":"and managed by different and trusted business partners. The major intent"},{"line_number":17,"context_line":"of provider in such collaboration is to reach to to the bigger customer"},{"line_number":18,"context_line":"base without having physical presence in other geo-regions. This setup"},{"line_number":19,"context_line":"is also beneficial for consumers or users associated with one cloud"},{"line_number":20,"context_line":"provider (a.k.a. primary provider) as they seamlessly own computing"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a016987_ba95d232","line":17,"updated":"2015-05-29 15:32:26.000000000","message":"s/to to/out to/","commit_id":"100eac3f851e14fa36bcd507dd78fc91240b5ffb"},{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"a89babc51f20486808da70025e2c1d969655abe9","unresolved":false,"context_lines":[{"line_number":49,"context_line":"In Intercloud/distributed MR OpenStack cloud deployment, users may want to own"},{"line_number":50,"context_line":"resources (vms, images, volumes) across multiple cloud providers. Keystone"},{"line_number":51,"context_line":"entities (domains, projects, users and groups) provide integration with"},{"line_number":52,"context_line":"users to their resources and these entities it must have a unique name"},{"line_number":53,"context_line":"within their context. Following are the problems user and provider face"},{"line_number":54,"context_line":"in such setup:"},{"line_number":55,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_9b7dc870","line":52,"updated":"2015-05-04 08:28:27.000000000","message":"remove \u0027it\u0027","commit_id":"100eac3f851e14fa36bcd507dd78fc91240b5ffb"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"feb6ecce606c6fca61e83dc296ff7b13b764f3d9","unresolved":false,"context_lines":[{"line_number":53,"context_line":"within their context. Following are the problems user and provider face"},{"line_number":54,"context_line":"in such setup:"},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Use Case 1:"},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"In most of the deployments providers do not use domain concept as it is not"},{"line_number":59,"context_line":"yet transparent to services and they use only the default domain to model"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a016987_1ad506e4","line":56,"updated":"2015-05-29 15:32:26.000000000","message":"These are not really use cases. They are lists of problems you have with the current approach.","commit_id":"100eac3f851e14fa36bcd507dd78fc91240b5ffb"},{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"a89babc51f20486808da70025e2c1d969655abe9","unresolved":false,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"In most of the deployments providers do not use domain concept as it is not"},{"line_number":59,"context_line":"yet transparent to services and they use only the default domain to model"},{"line_number":60,"context_line":"the cloud. Cloud provider uses projects to map users and impose users to"},{"line_number":61,"context_line":"choose unique names for their projects. This causes problems for the user"},{"line_number":62,"context_line":"as they have to deal with multiple project names to model their workload"},{"line_number":63,"context_line":"across Interclouds. It would be helpful if they can use the same project"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_fbeddcef","line":60,"updated":"2015-05-04 08:28:27.000000000","message":"If the domains (being long enough in Keystone) are not yet fully adopted, do you think new parameter/concept like namespace will find its home across OpenStack ecosystem faster? \nI also think, there is no point in making intercloud without concept of domains, as we indeed need some granularity","commit_id":"100eac3f851e14fa36bcd507dd78fc91240b5ffb"},{"author":{"_account_id":994,"name":"Arvind Tiwari","email":"arvindt7@gmail.com","username":"arvind-tiwari"},"change_message_id":"050d754a9643e4eb19e110eb67a898d7f3ce41d8","unresolved":false,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"In most of the deployments providers do not use domain concept as it is not"},{"line_number":59,"context_line":"yet transparent to services and they use only the default domain to model"},{"line_number":60,"context_line":"the cloud. Cloud provider uses projects to map users and impose users to"},{"line_number":61,"context_line":"choose unique names for their projects. This causes problems for the user"},{"line_number":62,"context_line":"as they have to deal with multiple project names to model their workload"},{"line_number":63,"context_line":"across Interclouds. It would be helpful if they can use the same project"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_84bf96a9","line":60,"in_reply_to":"3acd31a7_fbeddcef","updated":"2015-05-04 20:25:39.000000000","message":"Namespace should not be transparent to services and there is no need for it. Namespaces will be know to Keystone only and services are associated with Namespace indirectly through keystone projects.","commit_id":"100eac3f851e14fa36bcd507dd78fc91240b5ffb"},{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"a89babc51f20486808da70025e2c1d969655abe9","unresolved":false,"context_lines":[{"line_number":61,"context_line":"choose unique names for their projects. This causes problems for the user"},{"line_number":62,"context_line":"as they have to deal with multiple project names to model their workload"},{"line_number":63,"context_line":"across Interclouds. It would be helpful if they can use the same project"},{"line_number":64,"context_line":"name across Intercloud."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"Use Case 2:"},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_1ba1b8a3","line":64,"updated":"2015-05-04 08:28:27.000000000","message":"What\u0027s your rationale here. You are worrying that popular public cloud provider may be asked to setup interclud with two private cloud providers with exactly same set of project/domain pair? (Pepsi and Cola will ask PublicCloudProvide to setup {domain: drinks, project: soda} setup because this is what they have in their local openstack setup? \nI am not sure if adding 3rd parameter will solve the case.....","commit_id":"100eac3f851e14fa36bcd507dd78fc91240b5ffb"},{"author":{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},"change_message_id":"72e44796ef4e479384f98c0ecb1bbea638afea3a","unresolved":false,"context_lines":[{"line_number":71,"context_line":"/group all the resources which they are managing for other regions in"},{"line_number":72,"context_line":"Intercloud/distributed OpenStack cloud deployment."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Use case 3:"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Keystone enforces uniqueness on domain names withing one OpenStack, due to this"},{"line_number":77,"context_line":"consumers may not get same domain name across Intercloud."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_8e6925c1","line":74,"updated":"2015-05-01 16:03:17.000000000","message":"This use case is not 100% accurate as you start looking into the HMT reseller model. Since we have namespaces via HMT, this use-case should be minimized as domains are unique within their tree not globally","commit_id":"100eac3f851e14fa36bcd507dd78fc91240b5ffb"},{"author":{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},"change_message_id":"e5b723740cf4d073b171779093d924df8cd3ced0","unresolved":false,"context_lines":[{"line_number":71,"context_line":"/group all the resources which they are managing for other regions in"},{"line_number":72,"context_line":"Intercloud/distributed OpenStack cloud deployment."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Use case 3:"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Keystone enforces uniqueness on domain names withing one OpenStack, due to this"},{"line_number":77,"context_line":"consumers may not get same domain name across Intercloud."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3afb71cf_b62369bc","line":74,"in_reply_to":"3acd31a7_273fa488","updated":"2015-06-11 04:46:43.000000000","message":"Please do not design anything with V2 specifically in mind.\n\nThere is a better way to achieve what you are looking for that will be more generic. Let me post up a spec to cover how it works.","commit_id":"100eac3f851e14fa36bcd507dd78fc91240b5ffb"},{"author":{"_account_id":994,"name":"Arvind Tiwari","email":"arvindt7@gmail.com","username":"arvind-tiwari"},"change_message_id":"050d754a9643e4eb19e110eb67a898d7f3ce41d8","unresolved":false,"context_lines":[{"line_number":71,"context_line":"/group all the resources which they are managing for other regions in"},{"line_number":72,"context_line":"Intercloud/distributed OpenStack cloud deployment."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Use case 3:"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Keystone enforces uniqueness on domain names withing one OpenStack, due to this"},{"line_number":77,"context_line":"consumers may not get same domain name across Intercloud."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_273fa488","line":74,"in_reply_to":"3acd31a7_8e6925c1","updated":"2015-05-04 20:25:39.000000000","message":"Problem is when default domain is used in Intercloud so this point is not very strong. can be removed.","commit_id":"100eac3f851e14fa36bcd507dd78fc91240b5ffb"},{"author":{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},"change_message_id":"72e44796ef4e479384f98c0ecb1bbea638afea3a","unresolved":false,"context_lines":[{"line_number":115,"context_line":"------------"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Providers have to maintain mapping of resources vs owner provider which is an"},{"line_number":118,"context_line":"overhead for provider."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Security Impact"},{"line_number":121,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_aea861dc","line":118,"updated":"2015-05-01 16:03:17.000000000","message":"Since the concept is an external broker, and all ids are unique within a deployment. It should be minimal overhead (and the job of the external system consuming these resources) to manage knowing what deployment a resource is part of. \n\nThis seems like the right solution in general","commit_id":"100eac3f851e14fa36bcd507dd78fc91240b5ffb"},{"author":{"_account_id":994,"name":"Arvind Tiwari","email":"arvindt7@gmail.com","username":"arvind-tiwari"},"change_message_id":"050d754a9643e4eb19e110eb67a898d7f3ce41d8","unresolved":false,"context_lines":[{"line_number":115,"context_line":"------------"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Providers have to maintain mapping of resources vs owner provider which is an"},{"line_number":118,"context_line":"overhead for provider."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Security Impact"},{"line_number":121,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_077148a8","line":118,"in_reply_to":"3acd31a7_aea861dc","updated":"2015-05-04 20:25:39.000000000","message":"This is not external broker concept which is address by HTM.","commit_id":"100eac3f851e14fa36bcd507dd78fc91240b5ffb"},{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"a89babc51f20486808da70025e2c1d969655abe9","unresolved":false,"context_lines":[{"line_number":165,"context_line":"1. Add \"namespace\" to models (Domain, User, Group and Project)."},{"line_number":166,"context_line":"2. Add \"namespace\" to REST (Domain, User, Group and Project)."},{"line_number":167,"context_line":"3. Update list API to support \"namespace\"."},{"line_number":168,"context_line":""},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"Dependencies"},{"line_number":171,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_1bc0987a","line":168,"updated":"2015-05-04 08:28:27.000000000","message":"Entities  (like project, user or group) would be now identified with (name, domain, namespace) tuple?","commit_id":"100eac3f851e14fa36bcd507dd78fc91240b5ffb"},{"author":{"_account_id":994,"name":"Arvind Tiwari","email":"arvindt7@gmail.com","username":"arvind-tiwari"},"change_message_id":"050d754a9643e4eb19e110eb67a898d7f3ce41d8","unresolved":false,"context_lines":[{"line_number":165,"context_line":"1. Add \"namespace\" to models (Domain, User, Group and Project)."},{"line_number":166,"context_line":"2. Add \"namespace\" to REST (Domain, User, Group and Project)."},{"line_number":167,"context_line":"3. Update list API to support \"namespace\"."},{"line_number":168,"context_line":""},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"Dependencies"},{"line_number":171,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3acd31a7_c71fd006","line":168,"in_reply_to":"3acd31a7_1bc0987a","updated":"2015-05-04 20:25:39.000000000","message":"As mentioned above most of the deployment do not consider domains and only default domain is used, in that just name for  (project, user or group) will not provide enough uniqueness but (name, \"default\", namespace) will help.","commit_id":"100eac3f851e14fa36bcd507dd78fc91240b5ffb"}]}