)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"925d73f0958f465e19989b4954ea30276fb8b323","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"First (rough) draft for Dew project [RFC]"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Amend: fix wording \"OpenCloud\" to \"OpenStack\""},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Change-Id: I3292e9c04ffa2b162121d9fea8f36f6de8b97065"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"bf51134e_f93b4136","line":9,"updated":"2020-07-18 01:21:12.000000000","message":"There\u0027s no need to keep the history of the change in the commit message, we can see it in Gerrit: https://review.opendev.org/#/c/741008/1..2/doc/source/ideas/dew.rst","commit_id":"06f641037328c004ae8cd90bb7fd78aeb659f8c2"}],"doc/source/ideas/dew.rst":[{"author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"change_message_id":"a2a49e383eba2a9eee1a260ba737dd7446cbd2fb","unresolved":false,"context_lines":[{"line_number":39,"context_line":"the same experience with some hardware."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"The environment is thus: An old desktop with a quad-core 2.5Ghz x86 processor, with 4GB of RAM."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"The goal here is for Openstack services + OS services to not take up more than 1GB of memory, so that the Tinkerer can"},{"line_number":44,"context_line":"launch 3 * 1GB-RAM compute instances on this same machine, or launch 1 * 3GB-RAM instance managed by Zun."},{"line_number":45,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"bf51134e_df210cb8","line":42,"updated":"2020-07-17 11:58:41.000000000","message":"Is that really realistic?\nI am afraid to burn people in over-optimization.\n\nI like the noble goal of a \"Tinkerer\" having a single machine it can use openstack with, in an \"All in one\" manner.\n\nMany deployment projects already offer that \"All in one mode\". Sadly they need more than 4GB of RAM :)","commit_id":"06f641037328c004ae8cd90bb7fd78aeb659f8c2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"925d73f0958f465e19989b4954ea30276fb8b323","unresolved":false,"context_lines":[{"line_number":43,"context_line":"The goal here is for Openstack services + OS services to not take up more than 1GB of memory, so that the Tinkerer can"},{"line_number":44,"context_line":"launch 3 * 1GB-RAM compute instances on this same machine, or launch 1 * 3GB-RAM instance managed by Zun."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"This is instantly a relatively powerful resource pool for a beginner developer, with 3GB of RAM now instantly available."},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"On such a machine, the following (randomly picked) services could be ran: a Gitea host, a mysql Database, a Swift host,"},{"line_number":49,"context_line":"some Qinling functions, and a dozen containers."}],"source_content_type":"text/x-rst","patch_set":2,"id":"bf51134e_39c77967","line":46,"range":{"start_line":46,"start_character":18,"end_line":46,"end_character":78},"updated":"2020-07-18 01:21:12.000000000","message":"Relative to what? It\u0027s notably less powerful than a $55 Raspberry Pi, and the multitenancy features of OpenStack (which are the main thing it brings to the table) are not useful to a developer working on their own.","commit_id":"06f641037328c004ae8cd90bb7fd78aeb659f8c2"},{"author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"change_message_id":"a2a49e383eba2a9eee1a260ba737dd7446cbd2fb","unresolved":false,"context_lines":[{"line_number":67,"context_line":"preserving data loss at any risk by replicating the disk blocks across multiple physically-seperated storage nodes."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"The goal is to be tolerant of failures in such an environment, uptime is secondary."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The end result is a Cloud environment which can be tolerant of hardware failure, has a high hardware turnover, but is"},{"line_number":72,"context_line":"still able to survive on aging and refurbished hardware."},{"line_number":73,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"bf51134e_bf07f81d","line":70,"updated":"2020-07-17 11:58:41.000000000","message":"What are the level of the failures you want to target?\nAre you talking about a compute node that goes down? Yes, you can continue operation, and if necessary, you can reschedule your workloads to start on a new node. But if you are talking about memory corruption, I doubt OpenStack will help fix hardware solution. My point is that there is a level of fault tolerance that isn\u0027t really obvious in this sentence.","commit_id":"06f641037328c004ae8cd90bb7fd78aeb659f8c2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"925d73f0958f465e19989b4954ea30276fb8b323","unresolved":false,"context_lines":[{"line_number":89,"context_line":"The goal is two-fold:"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"#.  Distribute openstack components across all of these devices dynamically (powered by technologies"},{"line_number":92,"context_line":"    such as ``mDNS`` and ``ARP`` announcements (for floating IPs))"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"#.  Optimize Openstack components to be low-resources, possibly requiring offloading to"},{"line_number":95,"context_line":"    `Native Extensions \u003chttps://docs.python.org/3/extending/extending.html\u003e`_ for more controlled and optimized memory"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bf51134e_399c9969","line":92,"updated":"2020-07-18 01:21:12.000000000","message":"I think VRRP is a more likely candidate. This means that the Keystone catalog does not need to be modified when services move. Substantially all highly-available deployments are already using this.","commit_id":"06f641037328c004ae8cd90bb7fd78aeb659f8c2"},{"author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"change_message_id":"a2a49e383eba2a9eee1a260ba737dd7446cbd2fb","unresolved":false,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"#.  Distribute openstack components across all of these devices dynamically (powered by technologies"},{"line_number":92,"context_line":"    such as ``mDNS`` and ``ARP`` announcements (for floating IPs))"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"#.  Optimize Openstack components to be low-resources, possibly requiring offloading to"},{"line_number":95,"context_line":"    `Native Extensions \u003chttps://docs.python.org/3/extending/extending.html\u003e`_ for more controlled and optimized memory"},{"line_number":96,"context_line":"    usage."}],"source_content_type":"text/x-rst","patch_set":2,"id":"bf51134e_624ae75b","line":93,"updated":"2020-07-17 11:58:41.000000000","message":"We already have a service catalog through keystone. I guess the first step would be, for this case, to build mDNS software to broadcast the services.","commit_id":"06f641037328c004ae8cd90bb7fd78aeb659f8c2"},{"author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"change_message_id":"a2a49e383eba2a9eee1a260ba737dd7446cbd2fb","unresolved":false,"context_lines":[{"line_number":94,"context_line":"#.  Optimize Openstack components to be low-resources, possibly requiring offloading to"},{"line_number":95,"context_line":"    `Native Extensions \u003chttps://docs.python.org/3/extending/extending.html\u003e`_ for more controlled and optimized memory"},{"line_number":96,"context_line":"    usage."},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"End Product"},{"line_number":99,"context_line":"-----------"},{"line_number":100,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"bf51134e_627307b6","line":97,"updated":"2020-07-17 11:58:41.000000000","message":"I am afraid this idea will make the software more complex to review, not less complex. Can you elaborate on what project could deserve this treatment?","commit_id":"06f641037328c004ae8cd90bb7fd78aeb659f8c2"},{"author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"change_message_id":"a2a49e383eba2a9eee1a260ba737dd7446cbd2fb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"bf51134e_221aaf6e","line":103,"updated":"2020-07-17 11:58:41.000000000","message":"I think if we ensure that the usual openstack services are accomodated for this purpose, then there is nothing else to do.\nOpenStack already has packaging projects, and those can build the necessary artifacts for consumption.\n\nOpenStack is a community where we build software together. IMO, we don\u0027t really build _a product_. That\u0027s up to product companies.","commit_id":"06f641037328c004ae8cd90bb7fd78aeb659f8c2"}]}