)]}'
{"doc/source/admin/emulator.conf":[{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"2ea5b12f153696c5e2d4d059ce6a1cc4775bd74f","unresolved":false,"context_lines":[{"line_number":37,"context_line":"#"},{"line_number":38,"context_line":"# If this map is not present in the configuration, a single default"},{"line_number":39,"context_line":"# Manager is configured automatically to manage all available Systems."},{"line_number":40,"context_line":"SUSHY_EMULATOR_MANAGERS \u003d ["},{"line_number":41,"context_line":"    {"},{"line_number":42,"context_line":"        \"Id\": \"BMC\","},{"line_number":43,"context_line":"        \"Name\": \"Manager\","}],"source_content_type":"text/plain","patch_set":13,"id":"3fce034c_0c914c53","line":40,"updated":"2019-04-11 09:45:28.000000000","message":"Just to illustrate my point on the previous patches: this bit kind of proves that System/Manager split does not make sense for us. You have to make operators \"invent\" managers for you rather than managers coming naturally from your backend.\n\nAnd then, if I read your following patches right, you still rely on the System backend for actual virtual media actions. Which proves again that a manager is a system for sushy-tools..","commit_id":"432d641659e1b8f98e0d0a55c5729411da112f49"},{"author":{"_account_id":26340,"name":"Ilya Etingof","email":"etingof@gmail.com","username":"etingof"},"change_message_id":"0a02c250991e9ea5fc0a17c91fe2561919c91878","unresolved":false,"context_lines":[{"line_number":37,"context_line":"#"},{"line_number":38,"context_line":"# If this map is not present in the configuration, a single default"},{"line_number":39,"context_line":"# Manager is configured automatically to manage all available Systems."},{"line_number":40,"context_line":"SUSHY_EMULATOR_MANAGERS \u003d ["},{"line_number":41,"context_line":"    {"},{"line_number":42,"context_line":"        \"Id\": \"BMC\","},{"line_number":43,"context_line":"        \"Name\": \"Manager\","}],"source_content_type":"text/plain","patch_set":13,"id":"3fce034c_a7885171","line":40,"in_reply_to":"3fce034c_0c914c53","updated":"2019-04-11 10:34:20.000000000","message":"\u003e  You have to make operators \"invent\" managers for you rather than managers coming naturally from your backend.\n\nWell, the alternative view on this can be that the managers are implemented by (potentially many different) drivers. In this case, the driver is very primitive, it consumes bits of static configuration.\n\nOne can see this as a clear logical separation of the distinct physical entities - managers and systems (then chassis). While I understand that this may not look immediately useful, I feel like having proper model right from the start will save us time and effort going forward, once we come to emulating system-independent aspects of managers and chassis..\n\n\u003e And then, if I read your following patches right, you still rely on the System backend for actual virtual media actions. Which proves again that a manager is a system for sushy-tools..\n\nI try to model it precisely how Redfish prescribes it - the manager handles the action of \"attaching\" virtual media device it owns to (surprisingly) all systems it manages.","commit_id":"432d641659e1b8f98e0d0a55c5729411da112f49"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"10b045138b4c0de9495ce62bcde309e96a997c7b","unresolved":false,"context_lines":[{"line_number":37,"context_line":"#"},{"line_number":38,"context_line":"# If this map is not present in the configuration, a single default"},{"line_number":39,"context_line":"# Manager is configured automatically to manage all available Systems."},{"line_number":40,"context_line":"SUSHY_EMULATOR_MANAGERS \u003d ["},{"line_number":41,"context_line":"    {"},{"line_number":42,"context_line":"        \"Id\": \"BMC\","},{"line_number":43,"context_line":"        \"Name\": \"Manager\","}],"source_content_type":"text/plain","patch_set":13,"id":"3fce034c_076cc534","line":40,"in_reply_to":"3fce034c_a7885171","updated":"2019-04-11 11:13:00.000000000","message":"\u003e Well, the alternative view on this can be that the managers are implemented by (potentially many different) drivers.\n\nDo you have a practical example applicable to sushy-tools?\n\n\u003e I feel like having proper model right from the start will save us time and effort going forward\n\nSounds like premature optimization :)\n\nI\u0027d be fine with this patch series if you\n\n1. Delete this from configuration (if managers are real, let us not invent them).\n\n2. Move virtual media methods to Manager from System.\n\nI just doubt it\u0027s practically possible, given that we\u0027re unlikely to ever have any managers and chassis in our two existing backends..","commit_id":"432d641659e1b8f98e0d0a55c5729411da112f49"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"526f892f16d41e64157478437ee534fd916423d6","unresolved":false,"context_lines":[{"line_number":47,"context_line":"        \"ServiceEntryPointUUID\": \"92384634-2938-2342-8820-489239905423\","},{"line_number":48,"context_line":"        \"UUID\": \"58893887-8974-2487-2389-841168418919\""},{"line_number":49,"context_line":"    }"},{"line_number":50,"context_line":"]"}],"source_content_type":"text/plain","patch_set":24,"id":"dfbec78f_f8f981c7","line":50,"updated":"2019-05-13 15:34:00.000000000","message":"This is a static, not a dynamic emulator. We should avoid hardcoding objects in code or configuration.","commit_id":"12a41fc010711e26dbfef11a5d2c7948c50029c1"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"0e3470b1685576a62c38a05806b9c37c2374ca6b","unresolved":false,"context_lines":[{"line_number":47,"context_line":"        \"ServiceEntryPointUUID\": \"92384634-2938-2342-8820-489239905423\","},{"line_number":48,"context_line":"        \"UUID\": \"58893887-8974-2487-2389-841168418919\""},{"line_number":49,"context_line":"    }"},{"line_number":50,"context_line":"]"}],"source_content_type":"text/plain","patch_set":24,"id":"dfbec78f_6d0b68d5","line":50,"in_reply_to":"dfbec78f_0da42c07","updated":"2019-05-15 14:35:00.000000000","message":"\u003e VM is good for emulating Redfish System. But VM is not as convenient for emulating other Redfish resources.\n\nWe\u0027re literally talking about a project emulating Redfish resources on top of VMs :) Emulating them on top of something else can be an interesting project, but is out of scope as far as Ironic is concerned.\n\n\u003e Imagine a blade system where we might get one Manager, one Chassis and N Systems.\n\nCan we please get back to talking about sushy-tools and only it? We\u0027re not going to have a bladed system here. Not until we get bladed VMs.\n\nEspecially since we\u0027re talking about virtual media support here, which seems impossible for N+M systems because of Redfish desigh..","commit_id":"12a41fc010711e26dbfef11a5d2c7948c50029c1"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"4f4c6ff96e67173d931ee56174e19842faa7f8ca","unresolved":false,"context_lines":[{"line_number":47,"context_line":"        \"ServiceEntryPointUUID\": \"92384634-2938-2342-8820-489239905423\","},{"line_number":48,"context_line":"        \"UUID\": \"58893887-8974-2487-2389-841168418919\""},{"line_number":49,"context_line":"    }"},{"line_number":50,"context_line":"]"}],"source_content_type":"text/plain","patch_set":24,"id":"dfbec78f_c7483a2e","line":50,"in_reply_to":"dfbec78f_3eaf017e","updated":"2019-05-15 08:00:04.000000000","message":"Well, this bit is the key point of contention. Independent of the outcome of that discussion, we should not make users invent resources for us. This is the opposite of what the emulator does.","commit_id":"12a41fc010711e26dbfef11a5d2c7948c50029c1"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"09013db2ae58998a2ed901a88ce51f32cbb296f2","unresolved":false,"context_lines":[{"line_number":47,"context_line":"        \"ServiceEntryPointUUID\": \"92384634-2938-2342-8820-489239905423\","},{"line_number":48,"context_line":"        \"UUID\": \"58893887-8974-2487-2389-841168418919\""},{"line_number":49,"context_line":"    }"},{"line_number":50,"context_line":"]"}],"source_content_type":"text/plain","patch_set":24,"id":"dfbec78f_c02a5bd9","line":50,"in_reply_to":"dfbec78f_40098b93","updated":"2019-05-15 15:51:48.000000000","message":"In the unlikely event of this happening, we can switch to N+M design :) After all, adding more configuration is easier than removing (and complicating is usually easier than simplifying).","commit_id":"12a41fc010711e26dbfef11a5d2c7948c50029c1"},{"author":{"_account_id":26340,"name":"Ilya Etingof","email":"etingof@gmail.com","username":"etingof"},"change_message_id":"a09a74d7eabd2d75d3736fad398c72e11640e20e","unresolved":false,"context_lines":[{"line_number":47,"context_line":"        \"ServiceEntryPointUUID\": \"92384634-2938-2342-8820-489239905423\","},{"line_number":48,"context_line":"        \"UUID\": \"58893887-8974-2487-2389-841168418919\""},{"line_number":49,"context_line":"    }"},{"line_number":50,"context_line":"]"}],"source_content_type":"text/plain","patch_set":24,"id":"dfbec78f_e0675fe8","line":50,"in_reply_to":"dfbec78f_6d0b68d5","updated":"2019-05-15 15:29:10.000000000","message":"\u003e Emulating them on top of something else can be an interesting project, but is out of scope as far as Ironic is concerned.\n\nIt seems pretty much in scope to me. I am arguing that VM is an inconvenient basis for emulating resources that have nothing to do with VM per se.\n\n\u003e We\u0027re not going to have a bladed system here. Not until we get bladed VMs.\n\nTo emulate a bladed system we just need to have X Managers and Y Systems where X !\u003d Y. Most obvious setting is one Manager + one Chassis + many Systems (VMs).\n\nMore generally, if we go the 1+1 design you are advocating, how will we emulate  any other hardware configuration once the need comes up?\n\n\u003e Especially since we\u0027re talking about virtual media support here, which seems impossible for N+M systems because of Redfish desigh..\n\nWhy do you think N+M is impossible in hardware? At least 1+M (blade) seems quite feasible.\n\nThis reminds me that having ability to emulate N+M setup may be valuable for debugging/CI if we want ironic to support such configurations. Because I am thinking that may be ironic needs to synchronize its access to virtual media devices - otherwise ironic may try to eject a CD (while node is booting from it) to boot the other node sharing the same Manager and therefore CD. Blade system again.","commit_id":"12a41fc010711e26dbfef11a5d2c7948c50029c1"},{"author":{"_account_id":26340,"name":"Ilya Etingof","email":"etingof@gmail.com","username":"etingof"},"change_message_id":"3629d2064d8b004728754653004d5996e1edf196","unresolved":false,"context_lines":[{"line_number":47,"context_line":"        \"ServiceEntryPointUUID\": \"92384634-2938-2342-8820-489239905423\","},{"line_number":48,"context_line":"        \"UUID\": \"58893887-8974-2487-2389-841168418919\""},{"line_number":49,"context_line":"    }"},{"line_number":50,"context_line":"]"}],"source_content_type":"text/plain","patch_set":24,"id":"dfbec78f_0da42c07","line":50,"in_reply_to":"dfbec78f_76757ef9","updated":"2019-05-15 14:28:40.000000000","message":"\u003e Sorry, I don\u0027t quite get it, but just in case: we only deal with VMs here.\n\nVM is good for emulating Redfish System. But VM is not as convenient for emulating other Redfish resources. If we emulate everything (Chassis, Managers, Virtual Media, LEDs, PSU etc.) on top of a VM, we will suffer and breed a spaghetti monster.\n\nI am arguing that basing resource emulation on a variety of underlying entities (e.g. VM, DB, templates, configs, whatever fits best) would be more straightforward and extensible going forward.\n\n\u003e If you replace a Dell server with an identical model, will Manager UUID be the same?\n\nThat\u0027s one simple case of Manager+System. For pretty much any other arrangement your design won\u0027t be a good fit. Imagine a blade system where we might get one Manager, one Chassis and N Systems. When we replace one System in a blade machine, I expect no side-effects.","commit_id":"12a41fc010711e26dbfef11a5d2c7948c50029c1"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"faaae39db1408c0e29688f338119969f49f5a62f","unresolved":false,"context_lines":[{"line_number":47,"context_line":"        \"ServiceEntryPointUUID\": \"92384634-2938-2342-8820-489239905423\","},{"line_number":48,"context_line":"        \"UUID\": \"58893887-8974-2487-2389-841168418919\""},{"line_number":49,"context_line":"    }"},{"line_number":50,"context_line":"]"}],"source_content_type":"text/plain","patch_set":24,"id":"dfbec78f_a46baeee","line":50,"in_reply_to":"dfbec78f_84e46a0e","updated":"2019-05-16 08:50:06.000000000","message":"I\u0027m not sure what you\u0027re trying to say. But the OpenStack bare metal project does not have a goal of building a high quality Redfish emulator for all cases. We could in theory, but not with current staffing and downstream situation.\n\nThe current goal of sushy-tools is to provide CI for Ironic, that\u0027s why it was created and that\u0027s why it is under Ironic governance. I agree it could be fun to build a proper emulator.. but not here, not now :(","commit_id":"12a41fc010711e26dbfef11a5d2c7948c50029c1"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"9485805d4a9cb8efb9c70c774dd9967a255e393d","unresolved":false,"context_lines":[{"line_number":47,"context_line":"        \"ServiceEntryPointUUID\": \"92384634-2938-2342-8820-489239905423\","},{"line_number":48,"context_line":"        \"UUID\": \"58893887-8974-2487-2389-841168418919\""},{"line_number":49,"context_line":"    }"},{"line_number":50,"context_line":"]"}],"source_content_type":"text/plain","patch_set":24,"id":"dfbec78f_76757ef9","line":50,"in_reply_to":"dfbec78f_9b493bb8","updated":"2019-05-15 13:23:50.000000000","message":"\u003e If we prohibit ourselves mimicking resources based on something other than a VM, then we will struggle trying to find a glimpse of a non-existing resource in libvirt.\n\nSorry, I don\u0027t quite get it, but just in case: we only deal with VMs here.\n\n\u003e If we recreate libvirt domain that changes Manager UUID as a side effect. Weird!\n\nIf you replace a Dell server with an identical model, will Manager UUID be the same?\n\n\u003e That\u0027s because we are bending the model - Chassis are not Systems, they have different roles and life cycles.\n\nWe are inevitably bending the model, since we have neither Chassis nor Managers on the backend. The question is only how we bend, and I\u0027m on the user experience side here.","commit_id":"12a41fc010711e26dbfef11a5d2c7948c50029c1"},{"author":{"_account_id":26340,"name":"Ilya Etingof","email":"etingof@gmail.com","username":"etingof"},"change_message_id":"5d6bd4178e859df02ed38ddc4957592ca44b5019","unresolved":false,"context_lines":[{"line_number":47,"context_line":"        \"ServiceEntryPointUUID\": \"92384634-2938-2342-8820-489239905423\","},{"line_number":48,"context_line":"        \"UUID\": \"58893887-8974-2487-2389-841168418919\""},{"line_number":49,"context_line":"    }"},{"line_number":50,"context_line":"]"}],"source_content_type":"text/plain","patch_set":24,"id":"dfbec78f_e33e89b6","line":50,"in_reply_to":"dfbec78f_c02a5bd9","updated":"2019-05-15 16:16:56.000000000","message":"\u003e In the unlikely event of this happening, we can switch to N+M design\n\nIt seems that to accommodate the design you are advocating we\u0027d need to:\n\n1. undo the independent resources approach\n2. merge everything taken from (1)  into one swiss-army-knife class under libvirt/openstack driver\n3. adjust the rest of the code to driver API changes\n4. introduce/migrate configuration settings\n\nQuite a bit of work + some user-visible behavior changes.\n\nAnyway, I think it makes sense to fork sushy-tools at its current point of development to save my efforts and to use it, should we ever need to emulate non-trivial configurations. If some of my experiments prove to be useful, we could back port those to the upstream version.\n\nThat will be the Wild West of sushy-tools! ;-)","commit_id":"12a41fc010711e26dbfef11a5d2c7948c50029c1"},{"author":{"_account_id":26340,"name":"Ilya Etingof","email":"etingof@gmail.com","username":"etingof"},"change_message_id":"9164178688204d611ab039fc4802f705360190ae","unresolved":false,"context_lines":[{"line_number":47,"context_line":"        \"ServiceEntryPointUUID\": \"92384634-2938-2342-8820-489239905423\","},{"line_number":48,"context_line":"        \"UUID\": \"58893887-8974-2487-2389-841168418919\""},{"line_number":49,"context_line":"    }"},{"line_number":50,"context_line":"]"}],"source_content_type":"text/plain","patch_set":24,"id":"dfbec78f_9b493bb8","line":50,"in_reply_to":"dfbec78f_c7483a2e","updated":"2019-05-15 12:36:15.000000000","message":"If we prohibit ourselves mimicking resources based on something other than a VM, then we will struggle trying to find a glimpse of a non-existing resource in libvirt.\n\nThe need to devise UUIDs for other resources based on libvirt UUID is an  illustration of that struggle. If we recreate libvirt domain that changes Manager UUID as a side effect. Weird!\n\nThat\u0027s because we are bending the model - Chassis are not Systems, they have different roles and life cycles.\n\nI can see significant inconveniences in deriving all resources from libvirt domains. But what is the ultimate gain?\n\nTheoretically, emulation is all about mimicking [1], not modeling. The purpose of emulator (as opposed to simulator) is to *look* reasonably convincing for the purpose, no matter how it is achieved.\n\n1. https://stackoverflow.com/questions/1584617/simulator-or-emulator-what-is-the-difference","commit_id":"12a41fc010711e26dbfef11a5d2c7948c50029c1"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"e2ef68c32b9c5dcaf2729ebb964b86f57ddeac68","unresolved":false,"context_lines":[{"line_number":47,"context_line":"        \"ServiceEntryPointUUID\": \"92384634-2938-2342-8820-489239905423\","},{"line_number":48,"context_line":"        \"UUID\": \"58893887-8974-2487-2389-841168418919\""},{"line_number":49,"context_line":"    }"},{"line_number":50,"context_line":"]"}],"source_content_type":"text/plain","patch_set":24,"id":"dfbec78f_e0f67fd7","line":50,"in_reply_to":"dfbec78f_e0675fe8","updated":"2019-05-15 15:34:05.000000000","message":"\u003e It seems pretty much in scope to me.\n\nThe scope of this project is to facilitate ironic testing on devstack (i.e. VMs). We extended it to cover openstack backend for the sake of testing tripleo. That\u0027s it.\n\n\u003e how will we emulate any other hardware configuration once the need comes up?\n\nWe won\u0027t, unless/until 1. a need appears in ironic (doubtfully), 2. we find a suitable backend (even more doubtfully), 3. that works with devstack (well..).\n\n\u003e Why do you think N+M is impossible in hardware?\n\nI\u0027m not saying that, I\u0027m saying that the current virtual media design make it really weird when used when such configuration. To an extent that ironic probably won\u0027t support it.\n\n\u003e we want ironic to support such configurations\n\nWe want it, we wanted it for quite some time, but we\u0027re still years away from it :( I don\u0027t think it\u0027s worth making any provisions for that, given that the primary drivers behind it (Intel with their RackScale) went down a path of creating a new Nova virt driver (as I learned on the Summit).","commit_id":"12a41fc010711e26dbfef11a5d2c7948c50029c1"},{"author":{"_account_id":26340,"name":"Ilya Etingof","email":"etingof@gmail.com","username":"etingof"},"change_message_id":"fffad7f950db0b8890f459b6edd9036c148c7c5c","unresolved":false,"context_lines":[{"line_number":47,"context_line":"        \"ServiceEntryPointUUID\": \"92384634-2938-2342-8820-489239905423\","},{"line_number":48,"context_line":"        \"UUID\": \"58893887-8974-2487-2389-841168418919\""},{"line_number":49,"context_line":"    }"},{"line_number":50,"context_line":"]"}],"source_content_type":"text/plain","patch_set":24,"id":"dfbec78f_40098b93","line":50,"in_reply_to":"dfbec78f_e0f67fd7","updated":"2019-05-15 15:48:30.000000000","message":"\u003e We won\u0027t, unless/until 1. a need appears in ironic (doubtfully), 2. we find a suitable backend (even more doubtfully), 3. that works with devstack (well..).\n\nTo clarify: if deploying a blade system with ironic is something we want to test (1), that should readily work with libvirt (2) and devstack (3) *if* we won\u0027t go the 1+1 design of the emulator you are proposing.","commit_id":"12a41fc010711e26dbfef11a5d2c7948c50029c1"},{"author":{"_account_id":26340,"name":"Ilya Etingof","email":"etingof@gmail.com","username":"etingof"},"change_message_id":"a967c44425dfb9ba1721213137b74f2f1a477be8","unresolved":false,"context_lines":[{"line_number":47,"context_line":"        \"ServiceEntryPointUUID\": \"92384634-2938-2342-8820-489239905423\","},{"line_number":48,"context_line":"        \"UUID\": \"58893887-8974-2487-2389-841168418919\""},{"line_number":49,"context_line":"    }"},{"line_number":50,"context_line":"]"}],"source_content_type":"text/plain","patch_set":24,"id":"dfbec78f_84e46a0e","line":50,"in_reply_to":"dfbec78f_e33e89b6","updated":"2019-05-16 08:25:59.000000000","message":"I\u0027ve looked around for emulators landscape. Here\u0027s what I found interesting about them to share with you.\n\nOfficial DTMF implementation [1]. Combines static and dynamic emulation in one process. Dynamic emulation is implemented in form of Python files autogenerated from Redfish schemas. Once you have these prototype files in place, you can add some code to tie it up with something external. Supports representing non-trivial  hardware and has fancy features like eventing. Support IndicatorLEDs everywhere.\n\nReddrum simulator. Emulation seems to be done based on mutable and persistent JSON files initially generated from Redfish schema.\n\nRedfish Profile Simulator from DTMF - minimalistic implementation supporting just one monolithic server [3]. Dynamic emulation is done based on JSON files stored on the file system. The JSON files (called mocks) are generated ahead of time via a special tool.\n\nI have not come across anything like we have in sushy-tools i.e. backend drivers.\n\nNone of these projects require manual resource implementation like we do in sushy-tools. Therefore they can readily emulate everything and switch between schema versions.\n\nCode quality is not exactly high with all these projects.\n\n1. https://github.com/DMTF/Redfish-Interface-Emulator\n2. https://github.com/RedDrum-Redfish-Project/RedDrum-Simulator\n3. https://github.com/DMTF/Redfish-Profile-Simulator","commit_id":"12a41fc010711e26dbfef11a5d2c7948c50029c1"},{"author":{"_account_id":26340,"name":"Ilya Etingof","email":"etingof@gmail.com","username":"etingof"},"change_message_id":"27e82db27a8fa65651c61bd1e2ff1db5660df842","unresolved":false,"context_lines":[{"line_number":47,"context_line":"        \"ServiceEntryPointUUID\": \"92384634-2938-2342-8820-489239905423\","},{"line_number":48,"context_line":"        \"UUID\": \"58893887-8974-2487-2389-841168418919\""},{"line_number":49,"context_line":"    }"},{"line_number":50,"context_line":"]"}],"source_content_type":"text/plain","patch_set":24,"id":"dfbec78f_3eaf017e","line":50,"in_reply_to":"dfbec78f_f8f981c7","updated":"2019-05-13 17:19:58.000000000","message":"I\u0027ve posted my thoughts in the other patch [1].\n\n1. https://review.opendev.org/656792","commit_id":"12a41fc010711e26dbfef11a5d2c7948c50029c1"}],"releasenotes/notes/add-managers-resource-ffa58e329eccc058.yaml":[{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"6f4e088c8dc525cb2d5e5888f43bcc9e0f13ff6f","unresolved":false,"context_lines":[{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    Adds Managers resource emulation to dynamic Redfish emulator. Emulated"},{"line_number":5,"context_line":"    Computer Systems link up automatically to the first of the configured"},{"line_number":6,"context_line":"    Managers (just one by default)."}],"source_content_type":"text/x-yaml","patch_set":25,"id":"9fb8cfa7_a477b63a","line":6,"updated":"2019-06-05 22:37:43.000000000","message":"Redfish makes my head hurt, FWIW.","commit_id":"49fd3e65110fb1137974a6b283442b0a67f825b0"},{"author":{"_account_id":26340,"name":"Ilya Etingof","email":"etingof@gmail.com","username":"etingof"},"change_message_id":"6b14324da0a38696b549481c90fbf45e4d3de9f2","unresolved":false,"context_lines":[{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    Adds Managers resource emulation to dynamic Redfish emulator. Emulated"},{"line_number":5,"context_line":"    Computer Systems link up automatically to the first of the configured"},{"line_number":6,"context_line":"    Managers (just one by default)."}],"source_content_type":"text/x-yaml","patch_set":25,"id":"9fb8cfa7_118dd57a","line":6,"in_reply_to":"9fb8cfa7_a477b63a","updated":"2019-06-18 10:06:07.000000000","message":"+1 hurting head","commit_id":"49fd3e65110fb1137974a6b283442b0a67f825b0"}]}