)]}'
{"resolutions/20170317-cloud-applications-mission.rst":[{"author":{"_account_id":19181,"name":"David F Flanders","email":"dff.openstack@gmail.com","username":"DFFlanders"},"change_message_id":"d7ac42a07d51e7f1f37b6dae3f2bf4f1c7777fc2","unresolved":false,"context_lines":[{"line_number":7,"context_line":""},{"line_number":8,"context_line":"OpenStack\u0027s mission is:"},{"line_number":9,"context_line":""},{"line_number":10,"context_line":"  To produce a ubiquitous Open Source Cloud Computing platform that is"},{"line_number":11,"context_line":"  easy to use, simple to implement, interoperable between deployments,"},{"line_number":12,"context_line":"  works well at all scales, and meets the needs of users and operators of"},{"line_number":13,"context_line":"  both public and private clouds."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Implications for Cloud Applications"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_7e02ba70","line":13,"range":{"start_line":10,"start_character":2,"end_line":13,"end_character":33},"updated":"2017-03-21 04:12:23.000000000","message":"Assumption: Based on the OpenStack mission, we believe the community should actively strive to: enable a ubiquitous and open cloud which is easy for application developer to use, interoperable so multiple app stacks can run, simple to build apps atop and aims to meet the needs of apps which want to work across both public and private clouds.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":9664,"name":"amrith","email":"amrith.kumar@gmail.com","username":"amrith"},"change_message_id":"8eb4eddbe1cfb6adf94cc4cb360b6c0814818ab5","unresolved":false,"context_lines":[{"line_number":16,"context_line":"Implications for Cloud Applications"},{"line_number":17,"context_line":"-----------------------------------"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we do not believe this should be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable Open Source"},{"line_number":22,"context_line":"alternative so that users can select, and switch, vendors (including moving"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_34ffb968","line":19,"updated":"2017-03-19 18:50:13.000000000","message":"vendors,","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":19181,"name":"David F Flanders","email":"dff.openstack@gmail.com","username":"DFFlanders"},"change_message_id":"5448e3131c866e0069c277e6dabf65242bde066c","unresolved":false,"context_lines":[{"line_number":17,"context_line":"-----------------------------------"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we do not believe this should be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable Open Source"},{"line_number":22,"context_line":"alternative so that users can select, and switch, vendors (including moving"},{"line_number":23,"context_line":"between public and private clouds) based on the value they provide instead of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_e8a9c27c","line":20,"updated":"2017-03-21 03:38:32.000000000","message":"How does this tie to the OpenStack mission statement?","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"294b430f8873316f7acff79854c760ec3eab8a18","unresolved":false,"context_lines":[{"line_number":17,"context_line":"-----------------------------------"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we do not believe this should be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable Open Source"},{"line_number":22,"context_line":"alternative so that users can select, and switch, vendors (including moving"},{"line_number":23,"context_line":"between public and private clouds) based on the value they provide instead of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_3a02f30b","line":20,"in_reply_to":"1a1ced50_e8a9c27c","updated":"2017-03-21 16:35:28.000000000","message":"It\u0027s the reason there _is_ a mission statement.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":9664,"name":"amrith","email":"amrith.kumar@gmail.com","username":"amrith"},"change_message_id":"8eb4eddbe1cfb6adf94cc4cb360b6c0814818ab5","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we do not believe this should be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable Open Source"},{"line_number":22,"context_line":"alternative so that users can select, and switch, vendors (including moving"},{"line_number":23,"context_line":"between public and private clouds) based on the value they provide instead of"},{"line_number":24,"context_line":"being hostage to a proprietary API."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_54027570","line":21,"updated":"2017-03-19 18:50:13.000000000","message":"why is Open Source capitalized? shouldn\u0027t it just be open source or open-source?","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"b5df50831afbe512f44686014fc59ab8687e44f3","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we do not believe this should be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable Open Source"},{"line_number":22,"context_line":"alternative so that users can select, and switch, vendors (including moving"},{"line_number":23,"context_line":"between public and private clouds) based on the value they provide instead of"},{"line_number":24,"context_line":"being hostage to a proprietary API."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_fb07a119","line":21,"in_reply_to":"1a1ced50_54027570","updated":"2017-03-21 00:40:40.000000000","message":"Missed replying to this earlier. I want to say it\u0027s because I\u0027m referring to the term of art, Open Source in the OSI-approved sense, rather than the plain meaning of the words.\n\nThe truth, though, is that I lived in Germany for two and a half years and during that time the part of my brain that used to know which words to capitalise in English was rendered inoperative. (All nouns are capitalised in German.) I am not making this up.\n\nBasically we\u0027d need to take a poll because I am incapable of deciding what to believe.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":10112,"name":"Jason E. Rist","email":"jrist@redhat.com","username":"jrist"},"change_message_id":"7ef3c5a50f33d31d57071af3696e5c8252539df1","unresolved":false,"context_lines":[{"line_number":24,"context_line":"being hostage to a proprietary API."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Even Open Source APIs create lock-in, of course, but not *vendor* lock-in."},{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"},{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_2665ef44","line":27,"range":{"start_line":27,"start_character":25,"end_line":27,"end_character":30},"updated":"2017-03-17 16:02:37.000000000","message":"are you trying to emphasize \"locked in\" here or should the \"in to\"s in this paragraph be \"into\"?","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"e99b64bf49b7b06b52b79c116be26c01f8228534","unresolved":false,"context_lines":[{"line_number":24,"context_line":"being hostage to a proprietary API."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Even Open Source APIs create lock-in, of course, but not *vendor* lock-in."},{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"},{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_3f632eb3","line":27,"range":{"start_line":27,"start_character":25,"end_line":27,"end_character":30},"in_reply_to":"1a1ced50_2665ef44","updated":"2017-03-17 17:18:40.000000000","message":"the former","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":9664,"name":"amrith","email":"amrith.kumar@gmail.com","username":"amrith"},"change_message_id":"8eb4eddbe1cfb6adf94cc4cb360b6c0814818ab5","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"},{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_94f4ed87","line":30,"updated":"2017-03-19 18:50:13.000000000","message":"so, I\u0027ve read two paragraphs and I have no idea where this story is going.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"4aa36da68d6ce99114b6bbaf6c1fde194c27f447","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"},{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_ab95f2e4","line":30,"in_reply_to":"1a1ced50_94f4ed87","updated":"2017-03-20 15:46:51.000000000","message":"It\u0027s an elucidation of OpenStack\u0027s Mission Statement, and right here at the beginning of the second paragraph we have a declaration of OpenStack\u0027s \"highest purpose\". If that\u0027s not direct enough for you then perhaps this isn\u0027t the resolution you\u0027re looking for.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":668,"name":"Adrian Otto","email":"aotto@aotto.com","username":"aotto"},"change_message_id":"5f07a336db0852c42f6a9d49ea92ef0dd94f00c2","unresolved":false,"context_lines":[{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"},{"line_number":34,"context_line":"OpenStack is to fulfill its mission. While there are many existing applications"},{"line_number":35,"context_line":"that are self-contained (that is, they could run on any server or VPS) and it"},{"line_number":36,"context_line":"is important that they run well in OpenStack clouds, this should be largely a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_2756b729","line":33,"range":{"start_line":33,"start_character":42,"end_line":33,"end_character":50},"updated":"2017-03-18 17:40:23.000000000","message":"directly and securely","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":9664,"name":"amrith","email":"amrith.kumar@gmail.com","username":"amrith"},"change_message_id":"8eb4eddbe1cfb6adf94cc4cb360b6c0814818ab5","unresolved":false,"context_lines":[{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"},{"line_number":34,"context_line":"OpenStack is to fulfill its mission. While there are many existing applications"},{"line_number":35,"context_line":"that are self-contained (that is, they could run on any server or VPS) and it"},{"line_number":36,"context_line":"is important that they run well in OpenStack clouds, this should be largely a"},{"line_number":37,"context_line":"side-effect of, and certainly not a substitute for, OpenStack\u0027s support of"},{"line_number":38,"context_line":"cloud-aware applications. Only if developers of cloud-aware applications see"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_142f1df7","line":35,"range":{"start_line":35,"start_character":24,"end_line":35,"end_character":70},"updated":"2017-03-19 18:50:13.000000000","message":"that\u0027s not what I would normally consider to be a definition of self-contained","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":9664,"name":"amrith","email":"amrith.kumar@gmail.com","username":"amrith"},"change_message_id":"8eb4eddbe1cfb6adf94cc4cb360b6c0814818ab5","unresolved":false,"context_lines":[{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"},{"line_number":34,"context_line":"OpenStack is to fulfill its mission. While there are many existing applications"},{"line_number":35,"context_line":"that are self-contained (that is, they could run on any server or VPS) and it"},{"line_number":36,"context_line":"is important that they run well in OpenStack clouds, this should be largely a"},{"line_number":37,"context_line":"side-effect of, and certainly not a substitute for, OpenStack\u0027s support of"},{"line_number":38,"context_line":"cloud-aware applications. Only if developers of cloud-aware applications see"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_b4f3a99d","line":35,"updated":"2017-03-19 18:50:13.000000000","message":"what is a VPS?","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"4aa36da68d6ce99114b6bbaf6c1fde194c27f447","unresolved":false,"context_lines":[{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"},{"line_number":34,"context_line":"OpenStack is to fulfill its mission. While there are many existing applications"},{"line_number":35,"context_line":"that are self-contained (that is, they could run on any server or VPS) and it"},{"line_number":36,"context_line":"is important that they run well in OpenStack clouds, this should be largely a"},{"line_number":37,"context_line":"side-effect of, and certainly not a substitute for, OpenStack\u0027s support of"},{"line_number":38,"context_line":"cloud-aware applications. Only if developers of cloud-aware applications see"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_cb2f8e3c","line":35,"in_reply_to":"1a1ced50_b4f3a99d","updated":"2017-03-20 15:46:51.000000000","message":"https://en.wikipedia.org/wiki/Virtual_private_server\n\nI\u0027m totally making up the whole self-contained/cloud-aware terminology here, and I\u0027m totally open to better suggestions.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":9664,"name":"amrith","email":"amrith.kumar@gmail.com","username":"amrith"},"change_message_id":"8eb4eddbe1cfb6adf94cc4cb360b6c0814818ab5","unresolved":false,"context_lines":[{"line_number":34,"context_line":"OpenStack is to fulfill its mission. While there are many existing applications"},{"line_number":35,"context_line":"that are self-contained (that is, they could run on any server or VPS) and it"},{"line_number":36,"context_line":"is important that they run well in OpenStack clouds, this should be largely a"},{"line_number":37,"context_line":"side-effect of, and certainly not a substitute for, OpenStack\u0027s support of"},{"line_number":38,"context_line":"cloud-aware applications. Only if developers of cloud-aware applications see"},{"line_number":39,"context_line":"OpenStack as a competitive platform on which to build new cloud-aware"},{"line_number":40,"context_line":"applications can we help them to avoid proprietary lock-in."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_5410b5a8","line":37,"range":{"start_line":37,"start_character":50,"end_line":37,"end_character":51},"updated":"2017-03-19 18:50:13.000000000","message":"this comma is, I believe, incorrect.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"4aa36da68d6ce99114b6bbaf6c1fde194c27f447","unresolved":false,"context_lines":[{"line_number":34,"context_line":"OpenStack is to fulfill its mission. While there are many existing applications"},{"line_number":35,"context_line":"that are self-contained (that is, they could run on any server or VPS) and it"},{"line_number":36,"context_line":"is important that they run well in OpenStack clouds, this should be largely a"},{"line_number":37,"context_line":"side-effect of, and certainly not a substitute for, OpenStack\u0027s support of"},{"line_number":38,"context_line":"cloud-aware applications. Only if developers of cloud-aware applications see"},{"line_number":39,"context_line":"OpenStack as a competitive platform on which to build new cloud-aware"},{"line_number":40,"context_line":"applications can we help them to avoid proprietary lock-in."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_cb8b0e1d","line":37,"range":{"start_line":37,"start_character":50,"end_line":37,"end_character":51},"in_reply_to":"1a1ced50_5410b5a8","updated":"2017-03-20 15:46:51.000000000","message":"I don\u0027t believe it is.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":9664,"name":"amrith","email":"amrith.kumar@gmail.com","username":"amrith"},"change_message_id":"8eb4eddbe1cfb6adf94cc4cb360b6c0814818ab5","unresolved":false,"context_lines":[{"line_number":37,"context_line":"side-effect of, and certainly not a substitute for, OpenStack\u0027s support of"},{"line_number":38,"context_line":"cloud-aware applications. Only if developers of cloud-aware applications see"},{"line_number":39,"context_line":"OpenStack as a competitive platform on which to build new cloud-aware"},{"line_number":40,"context_line":"applications can we help them to avoid proprietary lock-in."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"We recognise that some cloud-aware application developers may work at one or"},{"line_number":43,"context_line":"more levels of abstraction removed from OpenStack itself, such as that provided"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_74277112","line":40,"updated":"2017-03-19 18:50:13.000000000","message":"OK, make that three paragraphs.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"294b430f8873316f7acff79854c760ec3eab8a18","unresolved":false,"context_lines":[{"line_number":37,"context_line":"side-effect of, and certainly not a substitute for, OpenStack\u0027s support of"},{"line_number":38,"context_line":"cloud-aware applications. Only if developers of cloud-aware applications see"},{"line_number":39,"context_line":"OpenStack as a competitive platform on which to build new cloud-aware"},{"line_number":40,"context_line":"applications can we help them to avoid proprietary lock-in."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"We recognise that some cloud-aware application developers may work at one or"},{"line_number":43,"context_line":"more levels of abstraction removed from OpenStack itself, such as that provided"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_ee5a6029","line":40,"in_reply_to":"1a1ced50_08b7fed8","updated":"2017-03-21 16:35:28.000000000","message":"The whole point of this resolution is to put emphasis on cloud-aware (I\u0027m not going to say \"cloud native\") applications.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":19181,"name":"David F Flanders","email":"dff.openstack@gmail.com","username":"DFFlanders"},"change_message_id":"5448e3131c866e0069c277e6dabf65242bde066c","unresolved":false,"context_lines":[{"line_number":37,"context_line":"side-effect of, and certainly not a substitute for, OpenStack\u0027s support of"},{"line_number":38,"context_line":"cloud-aware applications. Only if developers of cloud-aware applications see"},{"line_number":39,"context_line":"OpenStack as a competitive platform on which to build new cloud-aware"},{"line_number":40,"context_line":"applications can we help them to avoid proprietary lock-in."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"We recognise that some cloud-aware application developers may work at one or"},{"line_number":43,"context_line":"more levels of abstraction removed from OpenStack itself, such as that provided"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_08b7fed8","line":40,"in_reply_to":"1a1ced50_74277112","updated":"2017-03-21 03:38:32.000000000","message":"Too much emphasis on cloud native applications?","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":10112,"name":"Jason E. Rist","email":"jrist@redhat.com","username":"jrist"},"change_message_id":"7ef3c5a50f33d31d57071af3696e5c8252539df1","unresolved":false,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"We recognise that some cloud-aware application developers may work at one or"},{"line_number":43,"context_line":"more levels of abstraction removed from OpenStack itself, such as that provided"},{"line_number":44,"context_line":"by a Container Orchestration Engine or Platform as a Service. In such cases we"},{"line_number":45,"context_line":"regard the COE or PaaS as part of the application layer from OpenStack\u0027s"},{"line_number":46,"context_line":"perspective.  OpenStack can add considerable value to these layers by allowing"},{"line_number":47,"context_line":"them to become cloud-aware themselves or to be supplemented by cloud-aware"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_0612b3b4","line":44,"range":{"start_line":44,"start_character":70,"end_line":44,"end_character":75},"updated":"2017-03-17 16:02:37.000000000","message":"cases,","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":19181,"name":"David F Flanders","email":"dff.openstack@gmail.com","username":"DFFlanders"},"change_message_id":"5448e3131c866e0069c277e6dabf65242bde066c","unresolved":false,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"We recognise that some cloud-aware application developers may work at one or"},{"line_number":43,"context_line":"more levels of abstraction removed from OpenStack itself, such as that provided"},{"line_number":44,"context_line":"by a Container Orchestration Engine or Platform as a Service. In such cases we"},{"line_number":45,"context_line":"regard the COE or PaaS as part of the application layer from OpenStack\u0027s"},{"line_number":46,"context_line":"perspective.  OpenStack can add considerable value to these layers by allowing"},{"line_number":47,"context_line":"them to become cloud-aware themselves or to be supplemented by cloud-aware"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_88cbee52","line":44,"range":{"start_line":44,"start_character":76,"end_line":44,"end_character":78},"updated":"2017-03-21 03:38:32.000000000","message":"perhaps too bold of a statement, do the C/PaaS see it valuable to become cloud aware?","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":9664,"name":"amrith","email":"amrith.kumar@gmail.com","username":"amrith"},"change_message_id":"8eb4eddbe1cfb6adf94cc4cb360b6c0814818ab5","unresolved":false,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"We recognise that some cloud-aware application developers may work at one or"},{"line_number":43,"context_line":"more levels of abstraction removed from OpenStack itself, such as that provided"},{"line_number":44,"context_line":"by a Container Orchestration Engine or Platform as a Service. In such cases we"},{"line_number":45,"context_line":"regard the COE or PaaS as part of the application layer from OpenStack\u0027s"},{"line_number":46,"context_line":"perspective.  OpenStack can add considerable value to these layers by allowing"},{"line_number":47,"context_line":"them to become cloud-aware themselves or to be supplemented by cloud-aware"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_b421e9fd","line":44,"range":{"start_line":44,"start_character":70,"end_line":44,"end_character":75},"in_reply_to":"1a1ced50_0612b3b4","updated":"2017-03-19 18:50:13.000000000","message":"Yes!","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"294b430f8873316f7acff79854c760ec3eab8a18","unresolved":false,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"We recognise that some cloud-aware application developers may work at one or"},{"line_number":43,"context_line":"more levels of abstraction removed from OpenStack itself, such as that provided"},{"line_number":44,"context_line":"by a Container Orchestration Engine or Platform as a Service. In such cases we"},{"line_number":45,"context_line":"regard the COE or PaaS as part of the application layer from OpenStack\u0027s"},{"line_number":46,"context_line":"perspective.  OpenStack can add considerable value to these layers by allowing"},{"line_number":47,"context_line":"them to become cloud-aware themselves or to be supplemented by cloud-aware"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_9458208c","line":44,"range":{"start_line":44,"start_character":76,"end_line":44,"end_character":78},"in_reply_to":"1a1ced50_88cbee52","updated":"2017-03-21 16:35:28.000000000","message":"I and many of my colleagues have worked with OpenShift on this, so I\u0027d say yes?\n\nWhat PaaS operator _wouldn\u0027t_ want their PaaS to autoscale, for example?","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":9664,"name":"amrith","email":"amrith.kumar@gmail.com","username":"amrith"},"change_message_id":"8eb4eddbe1cfb6adf94cc4cb360b6c0814818ab5","unresolved":false,"context_lines":[{"line_number":42,"context_line":"We recognise that some cloud-aware application developers may work at one or"},{"line_number":43,"context_line":"more levels of abstraction removed from OpenStack itself, such as that provided"},{"line_number":44,"context_line":"by a Container Orchestration Engine or Platform as a Service. In such cases we"},{"line_number":45,"context_line":"regard the COE or PaaS as part of the application layer from OpenStack\u0027s"},{"line_number":46,"context_line":"perspective.  OpenStack can add considerable value to these layers by allowing"},{"line_number":47,"context_line":"them to become cloud-aware themselves or to be supplemented by cloud-aware"},{"line_number":48,"context_line":"management services."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_147d5de7","line":45,"updated":"2017-03-19 18:50:13.000000000","message":"on the first (and hopefully preceding) occurrence of the expression \"Container Orchestration Engine\", please add \"(COE)\". Same thing for PaaS though it is reasonable to assume that people reading that know what a PaaS is.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"4aa36da68d6ce99114b6bbaf6c1fde194c27f447","unresolved":false,"context_lines":[{"line_number":42,"context_line":"We recognise that some cloud-aware application developers may work at one or"},{"line_number":43,"context_line":"more levels of abstraction removed from OpenStack itself, such as that provided"},{"line_number":44,"context_line":"by a Container Orchestration Engine or Platform as a Service. In such cases we"},{"line_number":45,"context_line":"regard the COE or PaaS as part of the application layer from OpenStack\u0027s"},{"line_number":46,"context_line":"perspective.  OpenStack can add considerable value to these layers by allowing"},{"line_number":47,"context_line":"them to become cloud-aware themselves or to be supplemented by cloud-aware"},{"line_number":48,"context_line":"management services."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_8b72f647","line":45,"in_reply_to":"1a1ced50_147d5de7","updated":"2017-03-20 15:46:51.000000000","message":"good idea","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":9664,"name":"amrith","email":"amrith.kumar@gmail.com","username":"amrith"},"change_message_id":"8eb4eddbe1cfb6adf94cc4cb360b6c0814818ab5","unresolved":false,"context_lines":[{"line_number":45,"context_line":"regard the COE or PaaS as part of the application layer from OpenStack\u0027s"},{"line_number":46,"context_line":"perspective.  OpenStack can add considerable value to these layers by allowing"},{"line_number":47,"context_line":"them to become cloud-aware themselves or to be supplemented by cloud-aware"},{"line_number":48,"context_line":"management services."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"Further, we anticipate that many applications of the future will be"},{"line_number":51,"context_line":"heterogeneous in their infrastructure needs: parts of an application may be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_5487d5d6","line":48,"updated":"2017-03-19 18:50:13.000000000","message":"Four paragraphs.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":19181,"name":"David F Flanders","email":"dff.openstack@gmail.com","username":"DFFlanders"},"change_message_id":"5448e3131c866e0069c277e6dabf65242bde066c","unresolved":false,"context_lines":[{"line_number":47,"context_line":"them to become cloud-aware themselves or to be supplemented by cloud-aware"},{"line_number":48,"context_line":"management services."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"Further, we anticipate that many applications of the future will be"},{"line_number":51,"context_line":"heterogeneous in their infrastructure needs: parts of an application may be"},{"line_number":52,"context_line":"implemented running directly on the virtual infrastructure, other parts in"},{"line_number":53,"context_line":"shared multi-tenant cloud services, and still other parts on top of a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_a8c6ea46","line":50,"updated":"2017-03-21 03:38:32.000000000","message":"Based on what evidence?","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"294b430f8873316f7acff79854c760ec3eab8a18","unresolved":false,"context_lines":[{"line_number":47,"context_line":"them to become cloud-aware themselves or to be supplemented by cloud-aware"},{"line_number":48,"context_line":"management services."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"Further, we anticipate that many applications of the future will be"},{"line_number":51,"context_line":"heterogeneous in their infrastructure needs: parts of an application may be"},{"line_number":52,"context_line":"implemented running directly on the virtual infrastructure, other parts in"},{"line_number":53,"context_line":"shared multi-tenant cloud services, and still other parts on top of a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_c758278d","line":50,"in_reply_to":"1a1ced50_a8c6ea46","updated":"2017-03-21 16:35:28.000000000","message":"I think the burden of proof here is on anybody who thinks that as single platform can accommodate every part of every application.\n\nApplications in the real world have very diverse requirements (e.g. imagine all of the things that need to work together in for a network service provider), and often accrete in very messy ways - through acquisitions, incremental rewrites... \u0026c.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":9664,"name":"amrith","email":"amrith.kumar@gmail.com","username":"amrith"},"change_message_id":"8eb4eddbe1cfb6adf94cc4cb360b6c0814818ab5","unresolved":false,"context_lines":[{"line_number":50,"context_line":"Further, we anticipate that many applications of the future will be"},{"line_number":51,"context_line":"heterogeneous in their infrastructure needs: parts of an application may be"},{"line_number":52,"context_line":"implemented running directly on the virtual infrastructure, other parts in"},{"line_number":53,"context_line":"shared multi-tenant cloud services, and still other parts on top of a"},{"line_number":54,"context_line":"third-party COE or PaaS layer. For this reason we will seek to partner with"},{"line_number":55,"context_line":"Open Source COE and PaaS projects to provide them with integration points in"},{"line_number":56,"context_line":"OpenStack that will allow end-user applications running on them to access the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_94694d28","line":53,"range":{"start_line":53,"start_character":0,"end_line":53,"end_character":34},"updated":"2017-03-19 18:50:13.000000000","message":"is \"shared multi-tenant cloud services\" mutually exclusive from virtual infrastructure?","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"4aa36da68d6ce99114b6bbaf6c1fde194c27f447","unresolved":false,"context_lines":[{"line_number":50,"context_line":"Further, we anticipate that many applications of the future will be"},{"line_number":51,"context_line":"heterogeneous in their infrastructure needs: parts of an application may be"},{"line_number":52,"context_line":"implemented running directly on the virtual infrastructure, other parts in"},{"line_number":53,"context_line":"shared multi-tenant cloud services, and still other parts on top of a"},{"line_number":54,"context_line":"third-party COE or PaaS layer. For this reason we will seek to partner with"},{"line_number":55,"context_line":"Open Source COE and PaaS projects to provide them with integration points in"},{"line_number":56,"context_line":"OpenStack that will allow end-user applications running on them to access the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_8feda127","line":53,"range":{"start_line":53,"start_character":0,"end_line":53,"end_character":34},"in_reply_to":"1a1ced50_94694d28","updated":"2017-03-20 15:46:51.000000000","message":"It depends who you ask :/\n\nI do think this needs to be more clear about the fact that the cloud services (like Swift, Zaqar, Trove, \u0026c.) are as much a part of OpenStack as e.g. Nova. I\u0027ll try to clarify that in the next revision.\n\nAt the very least I\u0027ll change \"virtual infrastructure\" to \"virtual compute infrastructure\", but again I\u0027d really welcome suggestions of better terminology here.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":10112,"name":"Jason E. Rist","email":"jrist@redhat.com","username":"jrist"},"change_message_id":"7ef3c5a50f33d31d57071af3696e5c8252539df1","unresolved":false,"context_lines":[{"line_number":51,"context_line":"heterogeneous in their infrastructure needs: parts of an application may be"},{"line_number":52,"context_line":"implemented running directly on the virtual infrastructure, other parts in"},{"line_number":53,"context_line":"shared multi-tenant cloud services, and still other parts on top of a"},{"line_number":54,"context_line":"third-party COE or PaaS layer. For this reason we will seek to partner with"},{"line_number":55,"context_line":"Open Source COE and PaaS projects to provide them with integration points in"},{"line_number":56,"context_line":"OpenStack that will allow end-user applications running on them to access the"},{"line_number":57,"context_line":"full benefits of the OpenStack ecosystem when those layers are deployed on"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_8626a314","line":54,"range":{"start_line":54,"start_character":40,"end_line":54,"end_character":46},"updated":"2017-03-17 16:02:37.000000000","message":"reason,","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":9664,"name":"amrith","email":"amrith.kumar@gmail.com","username":"amrith"},"change_message_id":"8eb4eddbe1cfb6adf94cc4cb360b6c0814818ab5","unresolved":false,"context_lines":[{"line_number":50,"context_line":"Further, we anticipate that many applications of the future will be"},{"line_number":51,"context_line":"heterogeneous in their infrastructure needs: parts of an application may be"},{"line_number":52,"context_line":"implemented running directly on the virtual infrastructure, other parts in"},{"line_number":53,"context_line":"shared multi-tenant cloud services, and still other parts on top of a"},{"line_number":54,"context_line":"third-party COE or PaaS layer. For this reason we will seek to partner with"},{"line_number":55,"context_line":"Open Source COE and PaaS projects to provide them with integration points in"},{"line_number":56,"context_line":"OpenStack that will allow end-user applications running on them to access the"},{"line_number":57,"context_line":"full benefits of the OpenStack ecosystem when those layers are deployed on"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_d473c513","line":54,"range":{"start_line":53,"start_character":36,"end_line":54,"end_character":29},"updated":"2017-03-19 18:50:13.000000000","message":"same as previous comment","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":9664,"name":"amrith","email":"amrith.kumar@gmail.com","username":"amrith"},"change_message_id":"8eb4eddbe1cfb6adf94cc4cb360b6c0814818ab5","unresolved":false,"context_lines":[{"line_number":55,"context_line":"Open Source COE and PaaS projects to provide them with integration points in"},{"line_number":56,"context_line":"OpenStack that will allow end-user applications running on them to access the"},{"line_number":57,"context_line":"full benefits of the OpenStack ecosystem when those layers are deployed on"},{"line_number":58,"context_line":"OpenStack."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We invite all OpenStack projects to review their development priorities for"},{"line_number":61,"context_line":"alignment with the most critical aspects of our mission: to provide a secure,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_545ef576","line":58,"updated":"2017-03-19 18:50:13.000000000","message":"Whoa, this is a long sentence and we seem to be finally getting somewhere closer to what this whole resolution is about.\n\nBut, honestly, I don\u0027t see how I can relate the preceding 4.5 paragraphs to this sentence.\n\nAnd yes, I read the mailing list thread heavily referencing trove before I got to this review.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"4aa36da68d6ce99114b6bbaf6c1fde194c27f447","unresolved":false,"context_lines":[{"line_number":55,"context_line":"Open Source COE and PaaS projects to provide them with integration points in"},{"line_number":56,"context_line":"OpenStack that will allow end-user applications running on them to access the"},{"line_number":57,"context_line":"full benefits of the OpenStack ecosystem when those layers are deployed on"},{"line_number":58,"context_line":"OpenStack."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We invite all OpenStack projects to review their development priorities for"},{"line_number":61,"context_line":"alignment with the most critical aspects of our mission: to provide a secure,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_4bc63e4a","line":58,"in_reply_to":"1a1ced50_545ef576","updated":"2017-03-20 15:46:51.000000000","message":"Actually this paragraph is mostly making clear what this resolution is *not* about. (Specifically, it\u0027s *not* about reinventing OpenStack as a competitor to Kubernetes.)","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":19181,"name":"David F Flanders","email":"dff.openstack@gmail.com","username":"DFFlanders"},"change_message_id":"5448e3131c866e0069c277e6dabf65242bde066c","unresolved":false,"context_lines":[{"line_number":55,"context_line":"Open Source COE and PaaS projects to provide them with integration points in"},{"line_number":56,"context_line":"OpenStack that will allow end-user applications running on them to access the"},{"line_number":57,"context_line":"full benefits of the OpenStack ecosystem when those layers are deployed on"},{"line_number":58,"context_line":"OpenStack."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We invite all OpenStack projects to review their development priorities for"},{"line_number":61,"context_line":"alignment with the most critical aspects of our mission: to provide a secure,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_68eb12b1","line":58,"in_reply_to":"1a1ced50_545ef576","updated":"2017-03-21 03:38:32.000000000","message":"I feel this should be the lead paragraph of this mission statement as it ties most directly to what the OpenStack mission statement is.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"294b430f8873316f7acff79854c760ec3eab8a18","unresolved":false,"context_lines":[{"line_number":55,"context_line":"Open Source COE and PaaS projects to provide them with integration points in"},{"line_number":56,"context_line":"OpenStack that will allow end-user applications running on them to access the"},{"line_number":57,"context_line":"full benefits of the OpenStack ecosystem when those layers are deployed on"},{"line_number":58,"context_line":"OpenStack."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We invite all OpenStack projects to review their development priorities for"},{"line_number":61,"context_line":"alignment with the most critical aspects of our mission: to provide a secure,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_c43f4585","line":58,"in_reply_to":"1a1ced50_68eb12b1","updated":"2017-03-21 16:35:28.000000000","message":"Really? I can\u0027t find any reference to this in the Mission at all, one way or the other.\n\nI don\u0027t think this makes sense without the preceding context. As I said before, the intent here is to circumscribe the scope of the resolution.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":9664,"name":"amrith","email":"amrith.kumar@gmail.com","username":"amrith"},"change_message_id":"8eb4eddbe1cfb6adf94cc4cb360b6c0814818ab5","unresolved":false,"context_lines":[{"line_number":57,"context_line":"full benefits of the OpenStack ecosystem when those layers are deployed on"},{"line_number":58,"context_line":"OpenStack."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We invite all OpenStack projects to review their development priorities for"},{"line_number":61,"context_line":"alignment with the most critical aspects of our mission: to provide a secure,"},{"line_number":62,"context_line":"simple, scalable, interoperable set of services to the applications that depend"},{"line_number":63,"context_line":"on OpenStack APIs."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_94506d60","line":63,"range":{"start_line":60,"start_character":0,"end_line":63,"end_character":18},"updated":"2017-03-19 18:50:13.000000000","message":"wait. After five paragraphs, you don\u0027t have a clear \"call to action\"?\n\nWhat are \"all OpenStack projects\" supposed to be doing?\n\nWhat constitutes an alignment with a mission of providing a secure , simple, scalable, ...that depend on OpenStack API\u0027s?","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"b616bd1eb8173c3e20be1591a6403c61a533c6b2","unresolved":false,"context_lines":[{"line_number":57,"context_line":"full benefits of the OpenStack ecosystem when those layers are deployed on"},{"line_number":58,"context_line":"OpenStack."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We invite all OpenStack projects to review their development priorities for"},{"line_number":61,"context_line":"alignment with the most critical aspects of our mission: to provide a secure,"},{"line_number":62,"context_line":"simple, scalable, interoperable set of services to the applications that depend"},{"line_number":63,"context_line":"on OpenStack APIs."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_32df890e","line":63,"range":{"start_line":60,"start_character":0,"end_line":63,"end_character":18},"in_reply_to":"1a1ced50_7224a15f","updated":"2017-03-21 10:58:25.000000000","message":"hmm, I didn\u0027t really finish there.\n\nI am putting together this working group to help get agreement on more priorities for a sub set of the projects.\n\nIts likely supporting some of these concepts become release goals. See how the TC is now helping drive some project direction.\n\nThe work we need to do here is build consensus on what that list of needs looks like, and the work that needs doing. Once thats done, we could turn making progress on that into a release goal.","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"4aa36da68d6ce99114b6bbaf6c1fde194c27f447","unresolved":false,"context_lines":[{"line_number":57,"context_line":"full benefits of the OpenStack ecosystem when those layers are deployed on"},{"line_number":58,"context_line":"OpenStack."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We invite all OpenStack projects to review their development priorities for"},{"line_number":61,"context_line":"alignment with the most critical aspects of our mission: to provide a secure,"},{"line_number":62,"context_line":"simple, scalable, interoperable set of services to the applications that depend"},{"line_number":63,"context_line":"on OpenStack APIs."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_95d4d047","line":63,"range":{"start_line":60,"start_character":0,"end_line":63,"end_character":18},"in_reply_to":"1a1ced50_94506d60","updated":"2017-03-20 15:46:51.000000000","message":"I\u0027ve spent a lot of time working with the TC and I know that the TC will never ever approve anything that could be construed as dictating a technical direction to the community. (If you want to know why, look at the backlash to the relatively innocuous \u0027release goals\u0027, which are merely about co-ordinating the adoption of technical changes already accepted by the community.)\n\nThe TC are happy to let\u0027s the community\u0027s open development processes decide what technical features to implement, and so am I *provided* that we all agree on what we\u0027re trying to build and for whom. The motivation behind this proposed resolution is simply that we don\u0027t have that shared understanding, and that the disconnect is approaching crisis levels.\n\nThe language in this paragraph is quite deliberately as uncontroversial as I can make it, to avoid sparking a pointless fight that would distract from the real issue we need to debate as a community in paragraph 2. If TC members want to strengthen the language then they\u0027re welcome to, but that initiative should come from them, not me. It ultimately doesn\u0027t matter though, because the important thing here is that next time some project turns down a feature you need by saying something to the effect of \"that doesn\u0027t sound important to our users\", you can point them back here and say \"hey, remember who we\u0027re building for?\".","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"9e911370264db2521245009e44b8efad398282b2","unresolved":false,"context_lines":[{"line_number":57,"context_line":"full benefits of the OpenStack ecosystem when those layers are deployed on"},{"line_number":58,"context_line":"OpenStack."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We invite all OpenStack projects to review their development priorities for"},{"line_number":61,"context_line":"alignment with the most critical aspects of our mission: to provide a secure,"},{"line_number":62,"context_line":"simple, scalable, interoperable set of services to the applications that depend"},{"line_number":63,"context_line":"on OpenStack APIs."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_7224a15f","line":63,"range":{"start_line":60,"start_character":0,"end_line":63,"end_character":18},"in_reply_to":"1a1ced50_95d4d047","updated":"2017-03-21 10:55:30.000000000","message":"I am currently trhyin","commit_id":"79da51bddec531ef525a6737ba5a1799be4541f2"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"c45f80be3a22a0fef2b78a8e6fec9f9cf8f57207","unresolved":false,"context_lines":[{"line_number":10,"context_line":"  To produce a ubiquitous Open Source Cloud Computing platform that is"},{"line_number":11,"context_line":"  easy to use, simple to implement, interoperable between deployments,"},{"line_number":12,"context_line":"  works well at all scales, and meets the needs of users and operators of"},{"line_number":13,"context_line":"  both public and private clouds."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Implications for Cloud Applications"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_4f8ee5d0","line":13,"updated":"2017-03-22 13:48:39.000000000","message":"DRY: I would avoid quoting as the mission wording may change in the future. Point to https://governance.openstack.org/tc/reference/charter.html instead ?","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"e68c44509bd134cae3484df438501e3db089cb27","unresolved":false,"context_lines":[{"line_number":10,"context_line":"  To produce a ubiquitous Open Source Cloud Computing platform that is"},{"line_number":11,"context_line":"  easy to use, simple to implement, interoperable between deployments,"},{"line_number":12,"context_line":"  works well at all scales, and meets the needs of users and operators of"},{"line_number":13,"context_line":"  both public and private clouds."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Implications for Cloud Applications"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_a4c05b51","line":13,"in_reply_to":"1a1ced50_4f8ee5d0","updated":"2017-03-22 15:14:02.000000000","message":"I see this as a feature, not a bug :)\n\nThe resolution is effectively an interpretation of the mission statement; I think it should be read in conjunction with the mission statement as the interpreters knew it at the time they interpreted it. I\u0027d be unhappy about burying it behind a link.\n\nAlso, that isn\u0027t a link to the OpenStack mission statement (it\u0027s the TC\u0027s mission).","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"7fb20827cc3fc49679a01b68ee9905c01085eb31","unresolved":false,"context_lines":[{"line_number":10,"context_line":"  To produce a ubiquitous Open Source Cloud Computing platform that is"},{"line_number":11,"context_line":"  easy to use, simple to implement, interoperable between deployments,"},{"line_number":12,"context_line":"  works well at all scales, and meets the needs of users and operators of"},{"line_number":13,"context_line":"  both public and private clouds."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Implications for Cloud Applications"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_b1b3124c","line":13,"in_reply_to":"1a1ced50_a4c05b51","updated":"2017-03-23 09:39:47.000000000","message":"Actually, it quotes the OpenStack mission in the \"OpenStack Project Teams\" paragraph. But I see your point on interpreting /this/ version of the mission statement.","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":2,"name":"Monty Taylor","email":"mordred@inaugust.com","username":"mordred"},"change_message_id":"b2ac4d3c01f1866b7990e3ef7ea7a36184102ef7","unresolved":false,"context_lines":[{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"},{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Even Open Source APIs create lock-in, of course, but not *vendor* lock-in."},{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_778e3c7a","line":24,"updated":"2017-03-21 18:08:46.000000000","message":"YES","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":2,"name":"Monty Taylor","email":"mordred@inaugust.com","username":"mordred"},"change_message_id":"b2ac4d3c01f1866b7990e3ef7ea7a36184102ef7","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"},{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_978bb867","line":30,"updated":"2017-03-21 18:08:46.000000000","message":"DEAR GOD YES","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":2,"name":"Monty Taylor","email":"mordred@inaugust.com","username":"mordred"},"change_message_id":"b2ac4d3c01f1866b7990e3ef7ea7a36184102ef7","unresolved":false,"context_lines":[{"line_number":34,"context_line":"OpenStack is to fulfill its mission. While there are many existing applications"},{"line_number":35,"context_line":"that are self-contained (that is, they could run on any server or VPS_) and it"},{"line_number":36,"context_line":"is important that they run well in OpenStack clouds, this should be largely a"},{"line_number":37,"context_line":"side-effect of, and certainly not a substitute for, OpenStack\u0027s support of"},{"line_number":38,"context_line":"cloud-aware applications. Only if developers of cloud-aware applications see"},{"line_number":39,"context_line":"OpenStack as a competitive platform on which to build new cloud-aware"},{"line_number":40,"context_line":"applications can we help them to avoid proprietary lock-in."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_97b9f817","line":37,"updated":"2017-03-21 18:08:46.000000000","message":"Quibble - I would like us to ALSO consider those applications as first-class citizens, not just accidental extras. I know you already responded in patch 1 about this - but the reason I mention it is that earlier chasing of so-called \"cloud native\" applications led us to the mess we\u0027re in with floating ips / NAT being the default mechanism of getting network - even though OpenStack actually supports _BOTH_ NAT and non-NAT. If we\u0027d focused on empowering the end-user even if their use case didn\u0027t match our pre-conceived notion of what they _should_ want to do, we might actually have a great interface to empower developers to decide at runtime what sort of network access they want on _all_ of our clouds, not just the few that decide to enable both models.\n\nSo while yes, the intent of being amazing for cloud-aware applications is spot-on, I\u0027d prefer not to create a false dichotomy when we don\u0027t need to.","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"891d93adbd1e8df1099b7acce5273fa74552a34d","unresolved":false,"context_lines":[{"line_number":34,"context_line":"OpenStack is to fulfill its mission. While there are many existing applications"},{"line_number":35,"context_line":"that are self-contained (that is, they could run on any server or VPS_) and it"},{"line_number":36,"context_line":"is important that they run well in OpenStack clouds, this should be largely a"},{"line_number":37,"context_line":"side-effect of, and certainly not a substitute for, OpenStack\u0027s support of"},{"line_number":38,"context_line":"cloud-aware applications. Only if developers of cloud-aware applications see"},{"line_number":39,"context_line":"OpenStack as a competitive platform on which to build new cloud-aware"},{"line_number":40,"context_line":"applications can we help them to avoid proprietary lock-in."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_bac89923","line":37,"in_reply_to":"1a1ced50_97b9f817","updated":"2017-03-21 18:43:44.000000000","message":"That\u0027s a fair critique.\n\nTBH I think those edge cases are probably rare enough to slip through the catch-all loophole \u0027largely\u0027 here. In the vast majority of cases, designing for cloud-aware applications first (e.g. app-centric auth) will cater just fine to legacy applications, but the reverse is absolutely not true as we\u0027ve discovered. (Arguably even your example could be as much due to naivete about IPv6 as to preconceived notions about how users use clouds.)\n\nBut if you think it\u0027s important I could reword it to something like:\n\n\"There are many existing applications that are self-contained (that is, they could run on any server or VPS_) and it is important that they run well in OpenStack clouds. However, this cannot be a substitute for OpenStack\u0027s support of\ncloud-aware applications.\"","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"c45f80be3a22a0fef2b78a8e6fec9f9cf8f57207","unresolved":false,"context_lines":[{"line_number":34,"context_line":"OpenStack is to fulfill its mission. While there are many existing applications"},{"line_number":35,"context_line":"that are self-contained (that is, they could run on any server or VPS_) and it"},{"line_number":36,"context_line":"is important that they run well in OpenStack clouds, this should be largely a"},{"line_number":37,"context_line":"side-effect of, and certainly not a substitute for, OpenStack\u0027s support of"},{"line_number":38,"context_line":"cloud-aware applications. Only if developers of cloud-aware applications see"},{"line_number":39,"context_line":"OpenStack as a competitive platform on which to build new cloud-aware"},{"line_number":40,"context_line":"applications can we help them to avoid proprietary lock-in."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_ef7a31bc","line":37,"in_reply_to":"1a1ced50_bac89923","updated":"2017-03-22 13:48:39.000000000","message":"+1 on rewording","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":170,"name":"Mike Perez","email":"thingee@gmail.com","username":"thingee"},"change_message_id":"0f69f41515940ff2c22a876aded9cb630915df55","unresolved":false,"context_lines":[{"line_number":34,"context_line":"OpenStack is to fulfill its mission. While there are many existing applications"},{"line_number":35,"context_line":"that are self-contained (that is, they could run on any server or VPS_) and it"},{"line_number":36,"context_line":"is important that they run well in OpenStack clouds, this should be largely a"},{"line_number":37,"context_line":"side-effect of, and certainly not a substitute for, OpenStack\u0027s support of"},{"line_number":38,"context_line":"cloud-aware applications. Only if developers of cloud-aware applications see"},{"line_number":39,"context_line":"OpenStack as a competitive platform on which to build new cloud-aware"},{"line_number":40,"context_line":"applications can we help them to avoid proprietary lock-in."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_e2f15696","line":37,"in_reply_to":"1a1ced50_ef7a31bc","updated":"2017-03-22 19:58:01.000000000","message":"+1","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":2,"name":"Monty Taylor","email":"mordred@inaugust.com","username":"mordred"},"change_message_id":"b2ac4d3c01f1866b7990e3ef7ea7a36184102ef7","unresolved":false,"context_lines":[{"line_number":37,"context_line":"side-effect of, and certainly not a substitute for, OpenStack\u0027s support of"},{"line_number":38,"context_line":"cloud-aware applications. Only if developers of cloud-aware applications see"},{"line_number":39,"context_line":"OpenStack as a competitive platform on which to build new cloud-aware"},{"line_number":40,"context_line":"applications can we help them to avoid proprietary lock-in."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Many factors contribute to making a platform attractive to developers, but"},{"line_number":43,"context_line":"robust security is the *sine qua non* for that large proportion of applications"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_17442819","line":40,"updated":"2017-03-21 18:08:46.000000000","message":"I agree with 95% of the intent of this paragraph, quibble in the middle notwithstanding.","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":2,"name":"Monty Taylor","email":"mordred@inaugust.com","username":"mordred"},"change_message_id":"b2ac4d3c01f1866b7990e3ef7ea7a36184102ef7","unresolved":false,"context_lines":[{"line_number":45,"context_line":"(not just user-centric) authentication and authorization model. It must give"},{"line_number":46,"context_line":"fine-grained control to the application developer (not administrator) to"},{"line_number":47,"context_line":"delegate, in perpetuity until revoked, *minimal* privileges to access OpenStack"},{"line_number":48,"context_line":"APIs to the *parts* of the application that need them. Application developers"},{"line_number":49,"context_line":"can also benefit from the broad range of cloud services that are already, or in"},{"line_number":50,"context_line":"the future will become, part of the OpenStack project. These services can help"},{"line_number":51,"context_line":"them to, for example, reduce development effort, centralize scarce skills in"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_975018d6","line":48,"updated":"2017-03-21 18:08:46.000000000","message":"YES","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"c45f80be3a22a0fef2b78a8e6fec9f9cf8f57207","unresolved":false,"context_lines":[{"line_number":50,"context_line":"the future will become, part of the OpenStack project. These services can help"},{"line_number":51,"context_line":"them to, for example, reduce development effort, centralize scarce skills in"},{"line_number":52,"context_line":"their organization, scale at finer levels of granularity, share expensive"},{"line_number":53,"context_line":"resources efficiently, provide relability guarantees cheaply by amortizing the"},{"line_number":54,"context_line":"cost over multiple applications, help the application to manage its own"},{"line_number":55,"context_line":"infrastructure, or obtain from the cloud information that it needs to do so."},{"line_number":56,"context_line":"Many OpenStack services offer more than one of those benefits. Some of those"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_6fcac11c","line":53,"range":{"start_line":53,"start_character":31,"end_line":53,"end_character":41},"updated":"2017-03-22 13:48:39.000000000","message":"reliability","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":2,"name":"Monty Taylor","email":"mordred@inaugust.com","username":"mordred"},"change_message_id":"b2ac4d3c01f1866b7990e3ef7ea7a36184102ef7","unresolved":false,"context_lines":[{"line_number":52,"context_line":"their organization, scale at finer levels of granularity, share expensive"},{"line_number":53,"context_line":"resources efficiently, provide relability guarantees cheaply by amortizing the"},{"line_number":54,"context_line":"cost over multiple applications, help the application to manage its own"},{"line_number":55,"context_line":"infrastructure, or obtain from the cloud information that it needs to do so."},{"line_number":56,"context_line":"Many OpenStack services offer more than one of those benefits. Some of those"},{"line_number":57,"context_line":"services themselves comprise cloud-aware applications running on the virtual"},{"line_number":58,"context_line":"compute infrastructure."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_175b48f7","line":55,"updated":"2017-03-21 18:08:46.000000000","message":"Applications managing their own infrastructure are great. It would be great if we could provide them with a minimal access, as you say, so that they can\u0027t just accidentally delete themselves.","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":2,"name":"Monty Taylor","email":"mordred@inaugust.com","username":"mordred"},"change_message_id":"b2ac4d3c01f1866b7990e3ef7ea7a36184102ef7","unresolved":false,"context_lines":[{"line_number":55,"context_line":"infrastructure, or obtain from the cloud information that it needs to do so."},{"line_number":56,"context_line":"Many OpenStack services offer more than one of those benefits. Some of those"},{"line_number":57,"context_line":"services themselves comprise cloud-aware applications running on the virtual"},{"line_number":58,"context_line":"compute infrastructure."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We recognise that some cloud-aware application developers may work at one or"},{"line_number":61,"context_line":"more levels of abstraction removed from OpenStack itself, such as that provided"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_17e0a8f9","line":58,"updated":"2017-03-21 18:08:46.000000000","message":"Yes. Incidentally, \"application developer not administrator\" is key here. I\u0027ve been whinging for a while that keystone v3 allows administrators to set up users each with their own domain and as a domain admin, allowing their users to then create their own projects and users. This exists now - and almost nobody actually exposes it in any meaningful manner. (of course, roles being random opaque strings encoded in policy.json does nobody any favors, but if we could just get \"customer-account \u003d\u003d domain-admin with user creation\" as the _norm_ - we\u0027d be so much futher.","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"891d93adbd1e8df1099b7acce5273fa74552a34d","unresolved":false,"context_lines":[{"line_number":55,"context_line":"infrastructure, or obtain from the cloud information that it needs to do so."},{"line_number":56,"context_line":"Many OpenStack services offer more than one of those benefits. Some of those"},{"line_number":57,"context_line":"services themselves comprise cloud-aware applications running on the virtual"},{"line_number":58,"context_line":"compute infrastructure."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We recognise that some cloud-aware application developers may work at one or"},{"line_number":61,"context_line":"more levels of abstraction removed from OpenStack itself, such as that provided"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_d737f0fc","line":58,"in_reply_to":"1a1ced50_17e0a8f9","updated":"2017-03-21 18:43:44.000000000","message":"genau.","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":2,"name":"Monty Taylor","email":"mordred@inaugust.com","username":"mordred"},"change_message_id":"b2ac4d3c01f1866b7990e3ef7ea7a36184102ef7","unresolved":false,"context_lines":[{"line_number":63,"context_line":"such cases, we regard the COE or PaaS as part of the application layer from"},{"line_number":64,"context_line":"OpenStack\u0027s perspective. OpenStack can add considerable value to these layers"},{"line_number":65,"context_line":"by allowing them to become cloud-aware themselves or to be supplemented by"},{"line_number":66,"context_line":"cloud-aware management services."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Further, we anticipate that many applications of the future will be"},{"line_number":69,"context_line":"heterogeneous in their infrastructure needs: parts of an application may be"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_d70b70d4","line":66,"updated":"2017-03-21 18:08:46.000000000","message":"YES","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":2,"name":"Monty Taylor","email":"mordred@inaugust.com","username":"mordred"},"change_message_id":"b2ac4d3c01f1866b7990e3ef7ea7a36184102ef7","unresolved":false,"context_lines":[{"line_number":72,"context_line":"third-party COE or PaaS layer. For this reason, we will seek to partner with"},{"line_number":73,"context_line":"Open Source COE and PaaS projects to ensure that OpenStack integrates well with"},{"line_number":74,"context_line":"them. That will allow those projects\u0027 workloads access to the full benefits of"},{"line_number":75,"context_line":"the OpenStack ecosystem when they are deployed on an OpenStack cloud."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"We invite all OpenStack projects to review their development priorities for"},{"line_number":78,"context_line":"alignment with the most critical aspects of our mission: to provide a secure,"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_b7bb54e4","line":75,"updated":"2017-03-21 18:08:46.000000000","message":"Yup.","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"e68c44509bd134cae3484df438501e3db089cb27","unresolved":false,"context_lines":[{"line_number":72,"context_line":"third-party COE or PaaS layer. For this reason, we will seek to partner with"},{"line_number":73,"context_line":"Open Source COE and PaaS projects to ensure that OpenStack integrates well with"},{"line_number":74,"context_line":"them. That will allow those projects\u0027 workloads access to the full benefits of"},{"line_number":75,"context_line":"the OpenStack ecosystem when they are deployed on an OpenStack cloud."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"We invite all OpenStack projects to review their development priorities for"},{"line_number":78,"context_line":"alignment with the most critical aspects of our mission: to provide a secure,"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_64710344","line":75,"in_reply_to":"1a1ced50_8a0b6bd5","updated":"2017-03-22 15:14:02.000000000","message":"The intent of these two paragraphs is an abstract version of \"A cloud app that deploys to Kubernetes is still an OpenStack app since it may talk to MariaDB running in a Nova VM, and/or Swift, \u0026c. and we will definitely make sure that Kuryr works so this can happen but we will not write our own competitor to Kubernetes because Kubernetes is perfectly fine and we don\u0027t have a compulsive need to NIH everything\". Which I think is the same thing you want to say.\n\nI\u0027m open to alternative wording that makes that more clear without getting too concrete (i.e. I don\u0027t think we should mention K8s, Kuryr \u0026c. by name).","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"c45f80be3a22a0fef2b78a8e6fec9f9cf8f57207","unresolved":false,"context_lines":[{"line_number":72,"context_line":"third-party COE or PaaS layer. For this reason, we will seek to partner with"},{"line_number":73,"context_line":"Open Source COE and PaaS projects to ensure that OpenStack integrates well with"},{"line_number":74,"context_line":"them. That will allow those projects\u0027 workloads access to the full benefits of"},{"line_number":75,"context_line":"the OpenStack ecosystem when they are deployed on an OpenStack cloud."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"We invite all OpenStack projects to review their development priorities for"},{"line_number":78,"context_line":"alignment with the most critical aspects of our mission: to provide a secure,"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_8a0b6bd5","line":75,"in_reply_to":"1a1ced50_b7bb54e4","updated":"2017-03-22 13:48:39.000000000","message":"I think I agree with the intent of those last two paragraphs, but I think the wording should be tweaked a bit to be a bit less exclusionary.\n\nPersonally I\u0027d like to consider a set up that has Keystone, Cinder, Neutron+Kuryr, Nova and Kubernetes as \"OpenStack\". A cloud app that happens to deploy to Kubernetes most of its components but still use a Nova VM for deploying MariaDB (and using Neutron/Kuryr to plug those into shared networks) is an OpenStack cloud app. So I\u0027m worried wording like \"removed from OpenStack itself\" or \"ensure that OpenStack integrates well with them\" is creating a us vs. them view. I\u0027d rather push the idea than an OpenStack deployment can include pieces that are not developed by OpenStack.","commit_id":"788fffbba9f50f98d727359f5b564e9d2036b623"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"dea9b03a848be7c540d0b4cf4a6c453cf97a789c","unresolved":false,"context_lines":[{"line_number":16,"context_line":"Implications for Cloud Applications"},{"line_number":17,"context_line":"-----------------------------------"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_a5751dfc","line":19,"updated":"2017-03-29 09:08:30.000000000","message":"As a vendor, I\u0027m just about fed up with \u0027vendor\u0027 being used as the go-to dirty word in OpenStack.  Please try to avoid that in this resolution.\n\nHere, specifically, just delete \"to vendors\".","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"2d5d4175e402e220e01c723a122552578540502d","unresolved":false,"context_lines":[{"line_number":16,"context_line":"Implications for Cloud Applications"},{"line_number":17,"context_line":"-----------------------------------"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_e90066ae","line":19,"in_reply_to":"ffe62b97_1a2763cc","updated":"2017-03-30 11:54:39.000000000","message":"Is Red Hat a \u0027vendor\u0027, as you understand that term?\n\nFair enough, if so.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":595,"name":"Nick Barcet","email":"nicolas@barcet.com","username":"nijaba"},"change_message_id":"e600572297c959c9485f157f6b4dd44e4c856103","unresolved":false,"context_lines":[{"line_number":16,"context_line":"Implications for Cloud Applications"},{"line_number":17,"context_line":"-----------------------------------"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_cd970e45","line":19,"in_reply_to":"ffe62b97_2209f594","updated":"2017-03-29 18:09:22.000000000","message":"maybe change this to \"...users to a specific vendor...\"","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"5a370d99a806f3ff8a59ca455d71add3d2eebc95","unresolved":false,"context_lines":[{"line_number":16,"context_line":"Implications for Cloud Applications"},{"line_number":17,"context_line":"-----------------------------------"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_2209f594","line":19,"in_reply_to":"ffe62b97_a5751dfc","updated":"2017-03-29 13:33:33.000000000","message":"I won\u0027t do that because it would render the next paragraph nonsensical.\n\nUnless you work for AWS then you really don\u0027t have any legitimate concern about being the bad guy in this paragraph.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"0561d87a11fd0ce77fcb460ad4fe2fd894666e01","unresolved":false,"context_lines":[{"line_number":16,"context_line":"Implications for Cloud Applications"},{"line_number":17,"context_line":"-----------------------------------"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_1a2763cc","line":19,"in_reply_to":"ffe62b97_cd970e45","updated":"2017-03-30 00:03:37.000000000","message":"Ah! That will work, thanks Nick.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"16cc9a79f43ce6fec0f6304e6e13d52587e1a77e","unresolved":false,"context_lines":[{"line_number":16,"context_line":"Implications for Cloud Applications"},{"line_number":17,"context_line":"-----------------------------------"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_9398e31b","line":19,"in_reply_to":"ffe62b97_e90066ae","updated":"2017-03-30 15:40:22.000000000","message":"Yes, of course we are.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"dea9b03a848be7c540d0b4cf4a6c453cf97a789c","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"},{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_65e035ce","line":21,"updated":"2017-03-29 09:08:30.000000000","message":"So your primary belief is in zero cost, rather than in the moral and technical benefits of sharing free/open source software?\n\nThat is surprising, if so.  In my understanding, free/open source software has never been primarily about zero cost.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"2d5d4175e402e220e01c723a122552578540502d","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"},{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_57cfee28","line":21,"in_reply_to":"ffe62b97_450dfce6","updated":"2017-03-30 11:54:39.000000000","message":"Here\u0027s how I get that meaning - if I\u0027ve got one of these steps wrong, please explain.\n\n\"We develop OpenStack because we believe this should not be the\nprice of entry to cloud computing.\"\n\nFirstly, note it doesn\u0027t say \"among other considerations\" here, such as the moral, social or technical benefits that I mentioned.  So this sentence appears to be saying that this is the main or even only reason why we develop OpenStack.\n\nNow, expand \"this\":\n\n\"We develop OpenStack because we believe that exposure to rent-seeking should not be the price of entry to cloud computing.\"\n\nI think \"rent-seeking\" means \"being asked for or required to pay money for continued service\"; right?  So:\n\n\"We develop OpenStack because we believe that risking being asked or required to pay money should not be the price of entry to cloud computing.\"\n\nWhere have I gone wrong, if I have?\n\nIf I haven\u0027t gone wrong, how can that _not_ be read as a statement about cost?","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"16cc9a79f43ce6fec0f6304e6e13d52587e1a77e","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"},{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_b361a714","line":21,"in_reply_to":"ffe62b97_57cfee28","updated":"2017-03-30 15:40:22.000000000","message":"\u003e I think \"rent-seeking\" means \"being asked for or required to pay money for continued service\"; right?\n\nNope: https://en.wikipedia.org/wiki/Rent-seeking","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":595,"name":"Nick Barcet","email":"nicolas@barcet.com","username":"nijaba"},"change_message_id":"e600572297c959c9485f157f6b4dd44e4c856103","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"},{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_6de5a2db","line":21,"in_reply_to":"ffe62b97_6275bdf9","updated":"2017-03-29 18:09:22.000000000","message":"s/price of entry/necessary right of passage/ would clarify","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"5a370d99a806f3ff8a59ca455d71add3d2eebc95","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"},{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_6275bdf9","line":21,"in_reply_to":"ffe62b97_65e035ce","updated":"2017-03-29 13:33:33.000000000","message":"I don\u0027t understand how anybody could get that message from this paragraph, which never mentions zero-cost as even one, let alone the primary, benefit of FLOSS.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":6908,"name":"Simon Leinen","email":"simon.leinen@gmail.com","username":"simon-leinen"},"change_message_id":"2ea5a64047bb442fdf431dcc3fdc87d94323b1c3","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"},{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_450dfce6","line":21,"in_reply_to":"ffe62b97_65e035ce","updated":"2017-03-30 08:49:00.000000000","message":"Like Zane, I cannot understand how anyone could read that from the text. What I read is that _(specific) vendor lock-in and exposure to possible rent-seeking_ shouldn\u0027t be the price of entry to cloud computing. Interpreting this as a call for zero cost is quite far-fetched.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":12807,"name":"Steve Lewis (stevelle)","email":"stevelle@gmail.com","username":"stevelle"},"change_message_id":"26d435f9530e186cc060a9e73a6e8ecf859575ba","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"},{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_b069a68c","line":21,"in_reply_to":"ffe62b97_b361a714","updated":"2017-03-31 20:55:49.000000000","message":"maybe \"the price of entry to\" can become \"an inherent risk in\" in order to not use price in a way that could be misconstrued.\n\nrent-seeking will likely be a less familiar concept even if correctly used here, so an alternative phrasing may be valuable.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":6772,"name":"Stephen Gordon","email":"sgordon@redhat.com","username":"sgordon"},"change_message_id":"f072596235029032188926a249820e0619658b14","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"},{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."},{"line_number":25,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_1fbf6ed1","line":22,"range":{"start_line":22,"start_character":12,"end_line":22,"end_character":17},"updated":"2017-03-29 13:13:15.000000000","message":"cloud or cloud infrastructure API?","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"13a2ae2eecc012af425cbbba86ea04d16ce5b5ce","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"},{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."},{"line_number":25,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_33702908","line":22,"range":{"start_line":22,"start_character":12,"end_line":22,"end_character":17},"in_reply_to":"ffe62b97_1fbf6ed1","updated":"2017-03-29 14:55:59.000000000","message":"The mission statement says \"Cloud Computing platform\"; nothing about infrastructure only :)\n\nIME it\u0027s unhelpful to use the word \u0027infrastructure\u0027 because everyone has a different idea about what it means.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":9237,"name":"Kevin Fox","email":"kevin@efox.cc","username":"kfox1111"},"change_message_id":"d71fd6992617a568611ae0542f459c27d2fb71f5","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Proprietary APIs lock users in to vendors and expose them to possible"},{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"},{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."},{"line_number":25,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_26453bb4","line":22,"range":{"start_line":22,"start_character":12,"end_line":22,"end_character":17},"in_reply_to":"ffe62b97_33702908","updated":"2017-03-31 16:16:33.000000000","message":"This is very important. A lot of the cloud api\u0027s that are locking folks into single vendor clouds today are non infrastructure api\u0027s depending on your definition. Such as, message queue as a service.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":6772,"name":"Stephen Gordon","email":"sgordon@redhat.com","username":"sgordon"},"change_message_id":"f072596235029032188926a249820e0619658b14","unresolved":false,"context_lines":[{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"},{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Even Open Source APIs create lock-in, of course, but not *vendor* lock-in."},{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_5ff2969b","line":24,"range":{"start_line":23,"start_character":0,"end_line":24,"end_character":69},"updated":"2017-03-29 13:13:15.000000000","message":"I\u0027m not sure this wholly encompasses the reality of what OpenStack does and doesn\u0027t facilitate today but rather seems like a re-iteration of our predefined view of the world that we should instead be re-evaluating.\n\nOpenStack provides a cloud platform but increasingly users are using higher level APIs/platforms (Kubernetes, Cloud Foundry, OpenShift, etc.) as the way they abstract their applications away from the infrastructure platform so that they can switch vendors, clouds, etc. including to/from those that are proprietary in nature.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"13a2ae2eecc012af425cbbba86ea04d16ce5b5ce","unresolved":false,"context_lines":[{"line_number":20,"context_line":"rent-seeking. We develop OpenStack because we believe this should not be the"},{"line_number":21,"context_line":"price of entry to cloud computing. Our goal is to provide a viable alternative"},{"line_number":22,"context_line":"Open Source cloud API `and implementation`_ so that users can select, and"},{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Even Open Source APIs create lock-in, of course, but not *vendor* lock-in."},{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_8edd8ae1","line":24,"range":{"start_line":23,"start_character":0,"end_line":24,"end_character":69},"in_reply_to":"ffe62b97_5ff2969b","updated":"2017-03-29 14:55:59.000000000","message":"That\u0027s certainly one thing that\u0027s happening. I don\u0027t think we believe that\u0027s the whole story though. (Why would we still be working on OpenStack if we did?) The hype cycle is winner-take-all and turns on a dime. But we all know the real world doesn\u0027t work like that.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"dea9b03a848be7c540d0b4cf4a6c453cf97a789c","unresolved":false,"context_lines":[{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Even Open Source APIs create lock-in, of course, but not *vendor* lock-in."},{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_c0ac8fee","line":26,"updated":"2017-03-29 09:08:30.000000000","message":"Huh?  Open source APIs do not create lock-in - or at least, not as I understand \u0027lock-in\u0027 - what is your meaning?\n\nIt seems you\u0027re just talking about habit, right?  Whereas the traditional and much more precise definition of lock-in is to do with users of proprietary software being _unable_ to look at or modify the code of the software that they are using.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"16cc9a79f43ce6fec0f6304e6e13d52587e1a77e","unresolved":false,"context_lines":[{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Even Open Source APIs create lock-in, of course, but not *vendor* lock-in."},{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_596839b9","line":26,"in_reply_to":"ffe62b97_293f6eb6","updated":"2017-03-30 15:40:22.000000000","message":"\u003e I\u0027m afraid what I\u0027m seeing here is that the meaning of \u0027lock-in\u0027 is being diluted so far that it actually has no useful meaning left.\n\nIt means exactly what it sounds like in plain English: if you are locked in you cannot leave and go somewhere else.\n\nhttps://en.wikipedia.org/wiki/Lock-in_(decision-making)\n\nYou\u0027re literally the only person I\u0027ve ever heard of who thinks it means anything else in this context.\n\n\u003e In FLOSS tradition, \u0027lock-in\u0027 has a real, hard and useful definition, which is that you cannot see and modify the code that you are using yourself...\n\nNo it isn\u0027t! \u0027Proprietary\u0027 is the word that means what you said.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"2d5d4175e402e220e01c723a122552578540502d","unresolved":false,"context_lines":[{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Even Open Source APIs create lock-in, of course, but not *vendor* lock-in."},{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_293f6eb6","line":26,"in_reply_to":"ffe62b97_55903595","updated":"2017-03-30 11:54:39.000000000","message":"I\u0027m afraid what I\u0027m seeing here is that the meaning of \u0027lock-in\u0027 is being diluted so far that it actually has no useful meaning left.  All you are saying is that people get used to things, and there is cost in changing to different things.\n\nIf that is the only argument, it follows that everyone who is already using AWS or GCE or VMware should just carry on doing that and not consider OpenStack.\n\nIn FLOSS tradition, \u0027lock-in\u0027 has a real, hard and useful definition, which is that you cannot see and modify the code that you are using yourself, or pay someone else to do that for you; plus the consequences that stem from that, e.g. if the company that sold you the software changes focus or goes bust, or just doesn\u0027t want to prioritize your requests.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"f4b9fdc839278cf3328355e4e823fd148b6abb1b","unresolved":false,"context_lines":[{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Even Open Source APIs create lock-in, of course, but not *vendor* lock-in."},{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_04949843","line":26,"in_reply_to":"ffe62b97_596839b9","updated":"2017-03-30 17:36:47.000000000","message":"Actually, here is an even better Wikipedia link: https://en.wikipedia.org/wiki/Vendor_lock-in","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":15123,"name":"Drago","email":"drago.rosson@rackspace.com","username":"Drago"},"change_message_id":"5de9bc1a5f8690081f61046d54ad8cc6ee646a08","unresolved":false,"context_lines":[{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Even Open Source APIs create lock-in, of course, but not *vendor* lock-in."},{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_8a12dd61","line":26,"in_reply_to":"ffe62b97_596839b9","updated":"2017-03-30 16:30:51.000000000","message":"Agree with Zane. I\u0027ve never heard lock-in used to imply \"inability to view/modify the source code\", but always as an inability to switch because of large difficulty/barriers/investment that would need to be overcome.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":6772,"name":"Stephen Gordon","email":"sgordon@redhat.com","username":"sgordon"},"change_message_id":"f072596235029032188926a249820e0619658b14","unresolved":false,"context_lines":[{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Even Open Source APIs create lock-in, of course, but not *vendor* lock-in."},{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_02a151f8","line":26,"in_reply_to":"ffe62b97_c0ac8fee","updated":"2017-03-29 13:13:15.000000000","message":"Lock-in is not a binary, although that is how it is often used in marketing - ensuring that everyone treats it as a dirty word and wants to be \"not that\". Reality is that there are many degrees of lock-in in any given situation, is there a cost to switch? If yes then I am to at least some degree locked in, what changes obviously is with an open API implemented by multiple vendors I have more opportunities to reduce that switching cost.\n\nThis blog provides some thinking along these lines for consideration:\n\nhttp://cloudscaling.com/blog/openstack/you-are-locked-in-deal-with-it/\n\nI actually think it\u0027s a good thing that we\u0027re being honest here in stating that all solutions, even open ones, have some degree of lock-in rather than putting our heads in the sand.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"5a370d99a806f3ff8a59ca455d71add3d2eebc95","unresolved":false,"context_lines":[{"line_number":23,"context_line":"switch, vendors (including moving between public and private clouds) based on"},{"line_number":24,"context_line":"the value they provide instead of being hostage to a proprietary API."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Even Open Source APIs create lock-in, of course, but not *vendor* lock-in."},{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_55903595","line":26,"in_reply_to":"ffe62b97_c0ac8fee","updated":"2017-03-29 13:33:33.000000000","message":"Of course they do.\n\nThe traditional definition of lock-in is not and has never been \u0027inability to view/modify the source code\u0027. It\u0027s inability to change horses.\n\nIf you write an application for Linux then you are locked in to Linux. You can\u0027t just up and move to Windows without a huge investment. (Actually, apparently now you might be able to, only because Microsoft put Linux into Windows, but I digress.)\n\nBut if you write an application for Windows you are not only locked in to Windows, you are locked in to Microsoft as the single vendor of Windows. That isn\u0027t the case if you wrote for Linux, where you have plenty of options.\n\nOptions are good.\n\nNow substitute OpenStack for Linux and AWS for Windows. Same deal.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"dea9b03a848be7c540d0b4cf4a6c453cf97a789c","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"},{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_8071e746","line":30,"updated":"2017-03-29 09:08:30.000000000","message":"You seem to have arrived at an empty or circular statement here.  You\u0027re saying that OpenStack has no moral, social or technical purpose (e.g. because \"software should be libre\", or \"through allowing global engineers to collaborate more than they could on a closed system\", or \"we end up doing things _better_ than everyone else\"), and that it \"locks people in\" just as much as anything else - but yet it is still OpenStack\u0027s highest purpose to win for its own sake.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":12398,"name":"Dan Sneddon","email":"dsneddon@redhat.com","username":"dsneddon"},"change_message_id":"80b86d5f16e943e4fb0acc06420e4f7e95238128","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"},{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_f43856d3","line":30,"in_reply_to":"ffe62b97_0e661a2b","updated":"2017-03-29 21:11:44.000000000","message":"It seems to me that an example might be in order, and the best example I can think of is the Linux server revolution that changed the way online applications were hosted (away from single-vendor or hosted solutions, and onto Open Source on commodity hardware). We already know that the benefits of Open Source in that example are well-established, and it seems apropos to make a comparison between Linux and OpenStack. Linux is an industry standard because it is cross-vendor, accepts community updates, provides the ability to audit source and respond quickly to security issues, and because Linux has the broadest support for a wide variety of commodity hardware. These are all advantages that are shared by OpenStack. You might even go so far as to say that Linux prevented the takeover of the space by a single vendor, and that OpenStack may do the same.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"16cc9a79f43ce6fec0f6304e6e13d52587e1a77e","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"},{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_d9c5690c","line":30,"in_reply_to":"ffe62b97_695a1684","updated":"2017-03-30 15:40:22.000000000","message":"\u003e So do you have any interest in how I got that meaning from the text that you have proposed?\n\nIt\u0027s fairly obvious to me that it\u0027s because we\u0027re speaking entirely different languages.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":6772,"name":"Stephen Gordon","email":"sgordon@redhat.com","username":"sgordon"},"change_message_id":"f072596235029032188926a249820e0619658b14","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"},{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_a262a508","line":30,"in_reply_to":"ffe62b97_8071e746","updated":"2017-03-29 13:13:15.000000000","message":"I agree here, we\u0027ve acknowledged that lock-in exists regardless of open versus closed (which I agree with), then implied that vendor lock-in is still bad (not explaining why) before finally stating that being locked into OpenStack APIs is OK (equating it to being saved) but skipped explaining why. To me the missing part is the ecosystem effect of having multiple ways to consume OpenStack, and multiple vendors to choose from within those consumption models. Treating OpenStack as a monolith in this context is downplaying its value.\n\nEither via this angle or another this (backing up the statements in this paragraph) is a point I think we need to expand on because as I mentioned before current trends seem to be towards companies using higher level platforms on top of the infrastructure as the way to minimize lock-in, but this can be done when switching between the reigning proprietary public clouds as well. So effectively here we need to answer why OpenStack is a desirable/necessary approach in minimizing lock-in versus abstracting away other infrastructure providers via e.g. Kubernetes particularly in the context of a trend towards cloud native applications.\n\nPart of the answer surely is that not everything will transition to cloud native overnight so many \"real\" applications will need to interact with a mix of resources (e.g. VMs, bare-metal, containers) but this brings us back to the why OpenStack API versus proprietary public cloud API to get e.g. a VM.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"5a370d99a806f3ff8a59ca455d71add3d2eebc95","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"},{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_95d23d27","line":30,"in_reply_to":"ffe62b97_8071e746","updated":"2017-03-29 13:33:33.000000000","message":"I never said anything of the sort.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"13a2ae2eecc012af425cbbba86ea04d16ce5b5ce","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"},{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_0e661a2b","line":30,"in_reply_to":"ffe62b97_a262a508","updated":"2017-03-29 14:55:59.000000000","message":"\u003e then implied that vendor lock-in is still bad (not explaining why) before finally stating that being locked into OpenStack APIs is OK (equating it to being saved) but skipped explaining why.\n\nIt\u0027s explained why in the previous paragraph (exposure \"to possible rent-seeking\").\n\nI guess we could include more information about the benefits of Open Source, but this is really not intended to be a generic dissertation on why Open Source is good. It\u0027s a resolution of the OpenStack TC aimed at the technical community, who all know why Open Source is good - they wouldn\u0027t be here otherwise.\n\nThe point of this resolution is to make it clear *whom* we expect to get the benefit. There are a million places you can get a VM to run your IRC bouncer or whatever. But if you want to write an application against cloud APIs, OpenStack is pretty much the only Open Source option left in town. We have to serve those people.\n\n\u003e So effectively here we need to answer why OpenStack is a desirable/necessary approach in minimizing lock-in versus abstracting away other infrastructure providers via e.g. Kubernetes particularly in the context of a trend towards cloud native applications.\n\u003e\n\u003e Part of the answer surely is that not everything will transition to cloud native overnight so many \"real\" applications will need to interact with a mix of resources (e.g. VMs, bare-metal, containers) but this brings us back to the why OpenStack API versus proprietary public cloud API to get e.g. a VM.\n\nYep, and this is covered in the penultimate paragraph. (Personally, I think it\u0027s not just a question of everybody not switching to PaaS \"overnight\", and that apps spanning multiple compute platforms will be with us indefinitely. We\u0027ll see I guess.)\n\nAlso it makes me sad that we can\u0027t say \u0027cloud native\u0027 any more without it meaning \u0027runs on Kubernetes\u0027. Cloud is so much more than that.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"2d5d4175e402e220e01c723a122552578540502d","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Every user who is locked in to an OpenStack API is a user we have saved from"},{"line_number":28,"context_line":"being locked in to a single proprietary vendor. This is OpenStack\u0027s highest"},{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"},{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_695a1684","line":30,"in_reply_to":"ffe62b97_f43856d3","updated":"2017-03-30 11:54:39.000000000","message":"\u003e I never said anything of the sort.\n\nOK.  So do you have any interest in how I got that meaning from the text that you have proposed?","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"c146fb264256dd233e045ea11946ed7e9942c362","unresolved":false,"context_lines":[{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"},{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"},{"line_number":34,"context_line":"OpenStack is to fulfill its mission. There are many existing applications that"},{"line_number":35,"context_line":"are self-contained (that is, they could run on any server or VPS_) and it is"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_3e092995","line":32,"updated":"2017-03-29 03:39:03.000000000","message":"Perhaps some example applications? (and I\u0027d rather we exclude the ones inside of OpenStack community itself, ie, heat or mistral due to obvious bias)","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":6772,"name":"Stephen Gordon","email":"sgordon@redhat.com","username":"sgordon"},"change_message_id":"f072596235029032188926a249820e0619658b14","unresolved":false,"context_lines":[{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"},{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"},{"line_number":34,"context_line":"OpenStack is to fulfill its mission. There are many existing applications that"},{"line_number":35,"context_line":"are self-contained (that is, they could run on any server or VPS_) and it is"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_ff9a8a11","line":32,"in_reply_to":"ffe62b97_3e092995","updated":"2017-03-29 13:13:15.000000000","message":"+1, I generally agree with the sentiment of this paragraph at a high level but think some examples both of applications and what it would mean to have excellent support for them are needed to ensure we\u0027re all talking about the same thing.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"13a2ae2eecc012af425cbbba86ea04d16ce5b5ce","unresolved":false,"context_lines":[{"line_number":29,"context_line":"purpose. (Conversely, every user who is locked in to a single OpenStack vendor"},{"line_number":30,"context_line":"due to non-interoperability of solutions represents a failure of our mission.)"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Therefore, excellent support for cloud-aware applications -- that is,"},{"line_number":33,"context_line":"applications that access the cloud\u0027s APIs directly -- is imperative if"},{"line_number":34,"context_line":"OpenStack is to fulfill its mission. There are many existing applications that"},{"line_number":35,"context_line":"are self-contained (that is, they could run on any server or VPS_) and it is"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_98a5d4a4","line":32,"in_reply_to":"ffe62b97_3e092995","updated":"2017-03-29 14:55:59.000000000","message":"Heat and Mistral are services, not applications. Of the things inside OpenStack, things like Sahara and Magnum would be better examples since they are in a sense both.\n\nAn example of a cloud-aware application would be anything that needs to autoscale itself. Or reconfigure itself in response to a failure. Or use the cloud\u0027s APIs to back itself up. Or uses a cloud service for any of the reasons listed in the next paragraph. Or all of the above.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"c146fb264256dd233e045ea11946ed7e9942c362","unresolved":false,"context_lines":[{"line_number":35,"context_line":"are self-contained (that is, they could run on any server or VPS_) and it is"},{"line_number":36,"context_line":"important that they run well in OpenStack clouds. However, this cannot be a"},{"line_number":37,"context_line":"substitute for OpenStack\u0027s support of cloud-aware applications. Only if"},{"line_number":38,"context_line":"developers of cloud-aware applications see OpenStack as a competitive platform"},{"line_number":39,"context_line":"on which to build new cloud-aware applications can we help them to avoid"},{"line_number":40,"context_line":"proprietary lock-in."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_dedebd3c","line":38,"updated":"2017-03-29 03:39:03.000000000","message":"How are we measuring this \u0027competitiveness\u0027? \n\nI agree that we have to be this, but how are we validating that we are a competitive platform for developers (what I\u0027ve seen is that we try to be a a competitive platform for cloud operators or a competitive platform for people trying to make a new cloud service, and developers may or may not come as a result of that).\n\nI\u0027d be great if we could actually go direct to the source and get this information, instead of having to try to correlate how competitive we are to cloud operators/others trying to sell/distribute/offer cloud services and only then then trying to derive how competitive we are to the developers that use those cloud(s) services.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":12398,"name":"Dan Sneddon","email":"dsneddon@redhat.com","username":"dsneddon"},"change_message_id":"80b86d5f16e943e4fb0acc06420e4f7e95238128","unresolved":false,"context_lines":[{"line_number":35,"context_line":"are self-contained (that is, they could run on any server or VPS_) and it is"},{"line_number":36,"context_line":"important that they run well in OpenStack clouds. However, this cannot be a"},{"line_number":37,"context_line":"substitute for OpenStack\u0027s support of cloud-aware applications. Only if"},{"line_number":38,"context_line":"developers of cloud-aware applications see OpenStack as a competitive platform"},{"line_number":39,"context_line":"on which to build new cloud-aware applications can we help them to avoid"},{"line_number":40,"context_line":"proprietary lock-in."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_d4b6723e","line":38,"in_reply_to":"ffe62b97_58586c54","updated":"2017-03-29 21:11:44.000000000","message":"Perhaps modify this sentence to say something like \"Only if developers of cloud-aware applications see OpenStack as a viable platform on which to build new cloud-aware applicatios can we help them to avoid proprietary lock-in.\"","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"13a2ae2eecc012af425cbbba86ea04d16ce5b5ce","unresolved":false,"context_lines":[{"line_number":35,"context_line":"are self-contained (that is, they could run on any server or VPS_) and it is"},{"line_number":36,"context_line":"important that they run well in OpenStack clouds. However, this cannot be a"},{"line_number":37,"context_line":"substitute for OpenStack\u0027s support of cloud-aware applications. Only if"},{"line_number":38,"context_line":"developers of cloud-aware applications see OpenStack as a competitive platform"},{"line_number":39,"context_line":"on which to build new cloud-aware applications can we help them to avoid"},{"line_number":40,"context_line":"proprietary lock-in."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_58586c54","line":38,"in_reply_to":"ffe62b97_dedebd3c","updated":"2017-03-29 14:55:59.000000000","message":"Good question.\n\nWe\u0027re competitive if a developer starting a new project thinks to themselves \"should I develop for AWS, Azure, GCE, or OpenStack?\" and sometimes chooses OpenStack. If we don\u0027t make that list then we\u0027re not competitive.\n\nI agree that it would be great to track this directly somehow, as a primary goal rather than a flow-on effect. Maybe the Foundation has a role there.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"6993d8c3d51a86b808ac432099f9141aca8cb095","unresolved":false,"context_lines":[{"line_number":42,"context_line":"Many factors contribute to making a platform attractive to developers, but"},{"line_number":43,"context_line":"robust security is the *sine qua non* for that large proportion of applications"},{"line_number":44,"context_line":"that are network-facing. OpenStack therefore requires an application-centric"},{"line_number":45,"context_line":"(not just user-centric) authentication and authorization model. It must give"},{"line_number":46,"context_line":"fine-grained control to the application developer (not administrator) to"},{"line_number":47,"context_line":"delegate, in perpetuity until revoked, *minimal* privileges to access OpenStack"},{"line_number":48,"context_line":"APIs to the *parts* of the application that need them. Application developers"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_e6a58148","line":45,"updated":"2017-03-28 21:06:29.000000000","message":"++","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":2750,"name":"Sean Dague","email":"sean@dague.net","username":"sdague"},"change_message_id":"80115a18ed95000a0f04ace9f87db6626d66c185","unresolved":false,"context_lines":[{"line_number":55,"context_line":"infrastructure, or obtain from the cloud information that it needs to do so."},{"line_number":56,"context_line":"Many OpenStack services offer more than one of those benefits. Some of those"},{"line_number":57,"context_line":"services themselves comprise cloud-aware applications running on the virtual"},{"line_number":58,"context_line":"compute infrastructure."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We recognise that some cloud-aware application developers may work with"},{"line_number":61,"context_line":"additional layers of abstraction on top of OpenStack\u0027s virtual compute"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_c68b9d1c","line":58,"updated":"2017-03-28 20:52:54.000000000","message":"I think this is a good goal, I guess I want to know the plausible promise on this one. How do we get there? Because I\u0027m not sure I see it, and without that the whole thing feels a bit empty.\n\nI\u0027m +0 (I\u0027m good on the concept), but I\u0027d really love to see keystone team engaged before we declare this is what keystone is/needs.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":2750,"name":"Sean Dague","email":"sean@dague.net","username":"sdague"},"change_message_id":"fd161873628c7a852080846c70f8c4d7e100b8e2","unresolved":false,"context_lines":[{"line_number":55,"context_line":"infrastructure, or obtain from the cloud information that it needs to do so."},{"line_number":56,"context_line":"Many OpenStack services offer more than one of those benefits. Some of those"},{"line_number":57,"context_line":"services themselves comprise cloud-aware applications running on the virtual"},{"line_number":58,"context_line":"compute infrastructure."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We recognise that some cloud-aware application developers may work with"},{"line_number":61,"context_line":"additional layers of abstraction on top of OpenStack\u0027s virtual compute"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_a9b728f5","line":58,"in_reply_to":"ffe62b97_7ce464e0","updated":"2017-03-29 14:36:16.000000000","message":"Zane, cool! Perhaps we could footnote those steps forward so that it doesn\u0027t change the flow of this from a mission statement, but that we\u0027ve got that meat somewhere in the document.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"0561d87a11fd0ce77fcb460ad4fe2fd894666e01","unresolved":false,"context_lines":[{"line_number":55,"context_line":"infrastructure, or obtain from the cloud information that it needs to do so."},{"line_number":56,"context_line":"Many OpenStack services offer more than one of those benefits. Some of those"},{"line_number":57,"context_line":"services themselves comprise cloud-aware applications running on the virtual"},{"line_number":58,"context_line":"compute infrastructure."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We recognise that some cloud-aware application developers may work with"},{"line_number":61,"context_line":"additional layers of abstraction on top of OpenStack\u0027s virtual compute"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_c8eed1eb","line":58,"in_reply_to":"ffe62b97_a9b728f5","updated":"2017-03-30 00:03:37.000000000","message":"Sure, I\u0027m happy to do that if you think this is an appropriate forum.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"3db64e69d3db2ed2c9d42181d7b8be1173e11219","unresolved":false,"context_lines":[{"line_number":55,"context_line":"infrastructure, or obtain from the cloud information that it needs to do so."},{"line_number":56,"context_line":"Many OpenStack services offer more than one of those benefits. Some of those"},{"line_number":57,"context_line":"services themselves comprise cloud-aware applications running on the virtual"},{"line_number":58,"context_line":"compute infrastructure."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We recognise that some cloud-aware application developers may work with"},{"line_number":61,"context_line":"additional layers of abstraction on top of OpenStack\u0027s virtual compute"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_f956462a","line":58,"in_reply_to":"ffe62b97_c68b9d1c","updated":"2017-03-28 21:30:23.000000000","message":"I too like the idea and the sounds of this from a security perspective. As a mission statement I assume this is OK today because its something we can work *towards*, even though we might not meet that statement? Keystone, along with policy across OpenStack, struggles to fulfill some of these specific statements so I\u0027m wondering how that gets factored into realizing the mission.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"f788a60d29015ec5643bf4b5872761cf9d8c9d3d","unresolved":false,"context_lines":[{"line_number":55,"context_line":"infrastructure, or obtain from the cloud information that it needs to do so."},{"line_number":56,"context_line":"Many OpenStack services offer more than one of those benefits. Some of those"},{"line_number":57,"context_line":"services themselves comprise cloud-aware applications running on the virtual"},{"line_number":58,"context_line":"compute infrastructure."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We recognise that some cloud-aware application developers may work with"},{"line_number":61,"context_line":"additional layers of abstraction on top of OpenStack\u0027s virtual compute"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_7ca224fe","line":58,"in_reply_to":"ffe62b97_c68b9d1c","updated":"2017-03-28 21:38:17.000000000","message":"There\u0027s actually a fairly modest set of changes that would go a long way:\n\n* Not giving write access to all users in the default policy. John has a proposal for this already, Ib4cc7141d900881a7dc20842eb5d68eb90521fdd.\n* Some way of creating application \u0027users\u0027 that is guaranteed to exist in every cloud. Keystone already supports this with domains, so the main thing here is to pick a way and ensure that every cloud uses it. (e.g. this could be a single separate domain, or something more sophisticated like a domain per user as Monty mentioned in a previous comment.)\n* Some way to get the credentials to the application (and rotate them) securely, e.g. I86a994ca94e2d6a2a4e3753ffab107afc38d3dec (which would also solve the problem of getting every OpenStack cloud to support it in the same way).\n\nWith all of that in place then individual services can start implementing their own ways of giving control to the user over what a given application has access to. Hopefully we can get some consistency between services for how that\u0027s done by creating an Oslo library or something.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"dbaf8f50830c297e9d932181b7b8c94b839c2005","unresolved":false,"context_lines":[{"line_number":55,"context_line":"infrastructure, or obtain from the cloud information that it needs to do so."},{"line_number":56,"context_line":"Many OpenStack services offer more than one of those benefits. Some of those"},{"line_number":57,"context_line":"services themselves comprise cloud-aware applications running on the virtual"},{"line_number":58,"context_line":"compute infrastructure."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We recognise that some cloud-aware application developers may work with"},{"line_number":61,"context_line":"additional layers of abstraction on top of OpenStack\u0027s virtual compute"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_7ce464e0","line":58,"in_reply_to":"ffe62b97_f956462a","updated":"2017-03-28 21:42:54.000000000","message":"Lance: Yes, the point is to make sure that everybody has the same understanding of what direction we\u0027re going in and why. It\u0027s absolutely not to tell people off because we haven\u0027t arrived yet :)","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"c146fb264256dd233e045ea11946ed7e9942c362","unresolved":false,"context_lines":[{"line_number":61,"context_line":"additional layers of abstraction on top of OpenStack\u0027s virtual compute"},{"line_number":62,"context_line":"infrastructure, such as that provided by a Container Orchestration Engine (COE)"},{"line_number":63,"context_line":"or Platform as a Service (PaaS). In such cases, we regard the COE or PaaS as"},{"line_number":64,"context_line":"part of the application layer from OpenStack\u0027s perspective. OpenStack can add"},{"line_number":65,"context_line":"considerable value to these layers by allowing them to become cloud-aware"},{"line_number":66,"context_line":"themselves or to be supplemented by cloud-aware management services."},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_3ea489b9","line":64,"updated":"2017-03-29 03:39:03.000000000","message":"Do developers also agree with what is stated here?\n\nI don\u0027t think personally they would, they see the cloud as one thing, not two; and if we want to reach the first goal of \u0027competitiveness\u0027 we may have to change how we think to match our target \u0027person\u0027 better.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":5707,"name":"Henry Nash","email":"henryn@linux.vnet.ibm.com","username":"henry-nash"},"change_message_id":"2f87618566b199fc9a81e32f0ec57ea4920ec419","unresolved":false,"context_lines":[{"line_number":61,"context_line":"additional layers of abstraction on top of OpenStack\u0027s virtual compute"},{"line_number":62,"context_line":"infrastructure, such as that provided by a Container Orchestration Engine (COE)"},{"line_number":63,"context_line":"or Platform as a Service (PaaS). In such cases, we regard the COE or PaaS as"},{"line_number":64,"context_line":"part of the application layer from OpenStack\u0027s perspective. OpenStack can add"},{"line_number":65,"context_line":"considerable value to these layers by allowing them to become cloud-aware"},{"line_number":66,"context_line":"themselves or to be supplemented by cloud-aware management services."},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_0524c9ad","line":64,"in_reply_to":"ffe62b97_3ea489b9","updated":"2017-03-29 08:33:56.000000000","message":"++ I concur. The \"application\" developer may indeed want to pull together components from the cloud layers (e.g. I\u0027ll have a PaaS database, a couple of VMs and some containers please), and they see all of those as \"the cloud bits\". There are real challenges here, e.g. \"What do you mean I can\u0027t have one token that can speak to them all?\", \"What do you mean they all have different security models and I can\u0027t have one Identity \u0026 Access Management system that allows me to set access control across my cloud bits?\". Now I don\u0027t think it is the OpenStack mission to provide such centralised ability, but I would argue that it is our mission to provide the flexibility so that 3rd parties CAN build such control points without having to undertake significant surgery to OpenStack. In fact, we are probably not far off from this (i.e. pluggable token models, pluggable external Permission Access Point within keystone), but we haven\u0027t spent much time thinking about how others would use such abilities, whether the use of such things would lead to an efficient system etc.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"13a2ae2eecc012af425cbbba86ea04d16ce5b5ce","unresolved":false,"context_lines":[{"line_number":61,"context_line":"additional layers of abstraction on top of OpenStack\u0027s virtual compute"},{"line_number":62,"context_line":"infrastructure, such as that provided by a Container Orchestration Engine (COE)"},{"line_number":63,"context_line":"or Platform as a Service (PaaS). In such cases, we regard the COE or PaaS as"},{"line_number":64,"context_line":"part of the application layer from OpenStack\u0027s perspective. OpenStack can add"},{"line_number":65,"context_line":"considerable value to these layers by allowing them to become cloud-aware"},{"line_number":66,"context_line":"themselves or to be supplemented by cloud-aware management services."},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_f3e2c1d4","line":64,"in_reply_to":"ffe62b97_3ea489b9","updated":"2017-03-29 14:55:59.000000000","message":"It\u0027s both right? :)\n\nFrom the infrastructure level looking up, the PaaS layer looks like an application. From the application level looking down, it looks like part of the cloud.\n\nSo on one hand, the things we do to make OpenStack better for applications will also make OpenStack better for COEs/PaaS, since they are in a sense applications of OpenStack. That\u0027s what this paragraph is saying.\n\nAnd on the other hand, we need to integrate with those layers to make sure that from the actual application\u0027s perspective, everything looks seamless. That\u0027s what the next paragraph is saying.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"c146fb264256dd233e045ea11946ed7e9942c362","unresolved":false,"context_lines":[{"line_number":70,"context_line":"implemented running directly on the virtual compute infrastructure, other parts"},{"line_number":71,"context_line":"in shared multi-tenant cloud services, and still others on top of a third-party"},{"line_number":72,"context_line":"COE or PaaS layer. For this reason, we will seek to partner and integrate with"},{"line_number":73,"context_line":"Open Source COE and PaaS projects to ensure that their workloads also have full"},{"line_number":74,"context_line":"access to OpenStack\u0027s cloud services and to other application components"},{"line_number":75,"context_line":"deployed directly on the virtual compute infrastructure."},{"line_number":76,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_fe974139","line":73,"updated":"2017-03-29 03:39:03.000000000","message":"That\u0027s good.\n\nI\u0027d go farther and say heavily integrate, if that say means developers don\u0027t care about IAAS or they just want to run containers for there apps (or a COE just wants to use baremetal and not VMs) then once again, we need to be very flexible in what we call OpenStack (because honestly it\u0027s just a name).\n\nBut that goes into these mysterious app developers that I\u0027ve never heard much about what they want (and correlating the success of those developers by looking at the success of OpenStack projects is IMHO a hard problem).\n\nFor example, a thing to think about/ponder about.\n\nWhy was the CNCF created vs joining OpenStack Foundation (or vice-versa)?  Are we setting up walls for the sole purpose of setting up walls (or politics, or indecisiveness...); if so I\u0027d rather we break down those walls.","commit_id":"b4c78aee5dc7427e6b828dc2317028fe280f27b5"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"83bf0b6bdd6ed7c04410a259ff68ac269c51a849","unresolved":false,"context_lines":[{"line_number":46,"context_line":"(not just user-centric) authentication and authorization model. It must give"},{"line_number":47,"context_line":"fine-grained control to the application developer (not administrator) to"},{"line_number":48,"context_line":"delegate, in perpetuity until revoked, **minimal** privileges to access"},{"line_number":49,"context_line":"OpenStack APIs to the **parts** of the application that need them.\\ [#]_"},{"line_number":50,"context_line":"Application developers can also benefit from the broad range of cloud services"},{"line_number":51,"context_line":"that are already, or in the future will become, part of OpenStack. These"},{"line_number":52,"context_line":"services can help them to, for example, reduce development effort, centralize"}],"source_content_type":"text/x-rst","patch_set":4,"id":"dfeb2761_23675750","line":49,"range":{"start_line":49,"start_character":66,"end_line":49,"end_character":67},"updated":"2017-04-01 17:02:43.000000000","message":"stray \"\\\" in there?","commit_id":"92cb9d02722ab28d1452a4b1d7b2a9c4e3b63001"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"781825eab339cfcfc920e4d8ffc497821412d18c","unresolved":false,"context_lines":[{"line_number":46,"context_line":"(not just user-centric) authentication and authorization model. It must give"},{"line_number":47,"context_line":"fine-grained control to the application developer (not administrator) to"},{"line_number":48,"context_line":"delegate, in perpetuity until revoked, **minimal** privileges to access"},{"line_number":49,"context_line":"OpenStack APIs to the **parts** of the application that need them.\\ [#]_"},{"line_number":50,"context_line":"Application developers can also benefit from the broad range of cloud services"},{"line_number":51,"context_line":"that are already, or in the future will become, part of OpenStack. These"},{"line_number":52,"context_line":"services can help them to, for example, reduce development effort, centralize"}],"source_content_type":"text/x-rst","patch_set":4,"id":"dfeb2761_86bbb5c2","line":49,"range":{"start_line":49,"start_character":66,"end_line":49,"end_character":67},"in_reply_to":"dfeb2761_23675750","updated":"2017-04-03 14:06:28.000000000","message":"Nope, it\u0027s necessary to get the right formatting.","commit_id":"92cb9d02722ab28d1452a4b1d7b2a9c4e3b63001"},{"author":{"_account_id":2,"name":"Monty Taylor","email":"mordred@inaugust.com","username":"mordred"},"change_message_id":"9091816ff40966652a86b9b89f8d44ac336a51d9","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":".. [#] The first steps toward this would likely be to `eliminate write access`_"},{"line_number":91,"context_line":"   to the whole project for every user in the default policy; establish a"},{"line_number":92,"context_line":"   consistent Keystone domain or domains in which to create application user"},{"line_number":93,"context_line":"   accounts; and provide a secure method to `provision, rotate, and deliver"},{"line_number":94,"context_line":"   credentials`_ to the application."},{"line_number":95,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bff0334d_bd235f05","line":92,"updated":"2017-04-07 12:31:14.000000000","message":"I agree with everything in this document except for the idea of creating a consistent Keystone domain in which to create application user accounts, which I _strongly_ disagree with. Rather, the default behavior of all clouds should be that a human \"customer account\" should be granted a unique domain and domain admin in that domain. That human customer account (and not the cloud admin) should then be empowered to create application api users and projects as much as they want. (this is all stuff that exists in OpenStack today, but the default deployment that is being put out there does not take advantage of it) When we combine that with the things you\u0027re talking about in terms of having sane permissions structures, I think we\u0027re in a great place.\n\nBUT - that\u0027s a different discussion about the technical solution to a specific problem -so I actually suggest it just be removed from this document, as we need to be able to have that discussion differently, I think.","commit_id":"92cb9d02722ab28d1452a4b1d7b2a9c4e3b63001"},{"author":{"_account_id":2,"name":"Monty Taylor","email":"mordred@inaugust.com","username":"mordred"},"change_message_id":"c6cca7aff6bc0d61b4bd976a8e53af45f4e804f1","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":".. [#] The first steps toward this would likely be to `eliminate write access`_"},{"line_number":91,"context_line":"   to the whole project for every user in the default policy; establish a"},{"line_number":92,"context_line":"   consistent Keystone domain or domains in which to create application user"},{"line_number":93,"context_line":"   accounts; and provide a secure method to `provision, rotate, and deliver"},{"line_number":94,"context_line":"   credentials`_ to the application."},{"line_number":95,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bff0334d_e9224952","line":92,"in_reply_to":"bff0334d_4eedbb23","updated":"2017-04-07 14:08:14.000000000","message":"Honestly, maybe if we just added a \"for instance\" at the beginning or near the beginning of this footnote, and express a caveat at the end of the footnote that we\u0027re not defining the solution in this resolution, but merely providing an example possibility in case that makes the concept easier to grasp.","commit_id":"92cb9d02722ab28d1452a4b1d7b2a9c4e3b63001"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"aeeb49f96feb70eaa7dbcab6fd265b1b83316fdb","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":".. [#] The first steps toward this would likely be to `eliminate write access`_"},{"line_number":91,"context_line":"   to the whole project for every user in the default policy; establish a"},{"line_number":92,"context_line":"   consistent Keystone domain or domains in which to create application user"},{"line_number":93,"context_line":"   accounts; and provide a secure method to `provision, rotate, and deliver"},{"line_number":94,"context_line":"   credentials`_ to the application."},{"line_number":95,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bff0334d_4eedbb23","line":92,"in_reply_to":"bff0334d_bd235f05","updated":"2017-04-07 13:37:50.000000000","message":"Yeah, so this is a compression problem :)\n\nWhen I replied to Sean in the the last patchset, I said we needed, amongst other things:\n\n\"Some way of creating application \u0027users\u0027 that is guaranteed to exist in every cloud. Keystone already supports this with domains, so the main thing here is to pick a way and ensure that every cloud uses it. (e.g. this could be a single separate domain, or something more sophisticated like a domain per user as Monty mentioned in a previous comment.)\"\n\nSo the \"or domains\" part was meant to cover your suggestion. \"Consistent\" in that context would mean that you consistently get a domain for every human user for example, not necessarily that it\u0027s consistently the same domain for every cloud. I don\u0027t want to pre-judge what the technical solution looks like at all (FWIW I like your idea, but I\u0027m not a Keystone expert), I just want it to work the same on every cloud. Which I know we agree on :)\n\nSo we can either:\n\n* Accept that this footnote is not trying to define a solution at the technical level.\n* Reword the footnote to make that abundantly clear.\n* Remove the footnote.\n\nI genuinely have no preference. Since Sean suggested adding it and you suggested removing it, I\u0027m going to wait for y\u0027all to agree ;)","commit_id":"92cb9d02722ab28d1452a4b1d7b2a9c4e3b63001"}]}