)]}'
{"specs/mitaka/composable-services-within-roles.rst":[{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":11,"context_line":"https://blueprints.launchpad.net/tripleo/+spec/composable-services-within-roles"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Create a mechanism that allows an operator to define which"},{"line_number":14,"context_line":"services compose a specific Overcloud role. (contoller, compute, etc.)"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Problem Description"},{"line_number":17,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_23136b0f","line":14,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"controller\"","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Today in TripleO we have 5 basic Overcloud roles for: controller, compute,"},{"line_number":20,"context_line":"ceph storage, swift storage, and cinder storage. These roles can be scaled"},{"line_number":21,"context_line":"independantly and there are some boolean parameters to control various"},{"line_number":22,"context_line":"services and drivers within these roles but in general the role framework"},{"line_number":23,"context_line":"is rigidly defined with regards to which services run on each role."},{"line_number":24,"context_line":"As we add more services and custom vendor drivers the existing framework"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_432b0f34","line":21,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"indepedently\"","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":29,"context_line":"a new service should be pluggable, and not require editing a controller"},{"line_number":30,"context_line":"manifest that is already 100\u0027s of lines and growing. The goal of this"},{"line_number":31,"context_line":"spec is to move towards a framework that allows services that run on"},{"line_number":32,"context_line":"each roles to be flexible (as much as they can be) and make the"},{"line_number":33,"context_line":"maintenance involved with adding new services and drivers less painful."},{"line_number":34,"context_line":"This means defining an \"interface\" that all services (core or not)"},{"line_number":35,"context_line":"must implement to work with our deployment framework."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_23b84be5","line":32,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"each role\" not \"each roles\"","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Taking it a step further we may eventually want to allow operators to"},{"line_number":38,"context_line":"create ad-hoc new roles as well. I think this is a great idea but is"},{"line_number":39,"context_line":"perhaps slighly beyond the initial scope of this spec which is focussed"},{"line_number":40,"context_line":"not on what roles we have... but rather what goes into them. Once"},{"line_number":41,"context_line":"we have the abilty to flexibally define the services for each role I think"},{"line_number":42,"context_line":"it could be a logical next step to tackle the \"flexible roles\" issue but"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_e3ca436e","line":39,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"focused\"","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":38,"context_line":"create ad-hoc new roles as well. I think this is a great idea but is"},{"line_number":39,"context_line":"perhaps slighly beyond the initial scope of this spec which is focussed"},{"line_number":40,"context_line":"not on what roles we have... but rather what goes into them. Once"},{"line_number":41,"context_line":"we have the abilty to flexibally define the services for each role I think"},{"line_number":42,"context_line":"it could be a logical next step to tackle the \"flexible roles\" issue but"},{"line_number":43,"context_line":"perhaps that rigidly defining a couple more (like a database or neutron role)"},{"line_number":44,"context_line":"in the meantime would be us a lot of runway."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_63a5f3b3","line":41,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"flexibly\"","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8449,"name":"Marios Andreou","email":"marios.andreou@gmail.com","username":"marios"},"change_message_id":"f3e23c57f287e2a1dd90e107dc46a2300d620624","unresolved":false,"context_lines":[{"line_number":38,"context_line":"create ad-hoc new roles as well. I think this is a great idea but is"},{"line_number":39,"context_line":"perhaps slighly beyond the initial scope of this spec which is focussed"},{"line_number":40,"context_line":"not on what roles we have... but rather what goes into them. Once"},{"line_number":41,"context_line":"we have the abilty to flexibally define the services for each role I think"},{"line_number":42,"context_line":"it could be a logical next step to tackle the \"flexible roles\" issue but"},{"line_number":43,"context_line":"perhaps that rigidly defining a couple more (like a database or neutron role)"},{"line_number":44,"context_line":"in the meantime would be us a lot of runway."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a7e1126_734884b3","line":41,"in_reply_to":"9a8ffd7b_63a5f3b3","updated":"2015-12-22 09:04:29.000000000","message":"ability","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":4328,"name":"Steven Hardy","email":"steven.hardy@suse.com","username":"shardy"},"change_message_id":"00a910e9875b7a2bb6b284e39654b32b5d18cb58","unresolved":false,"context_lines":[{"line_number":41,"context_line":"we have the abilty to flexibally define the services for each role I think"},{"line_number":42,"context_line":"it could be a logical next step to tackle the \"flexible roles\" issue but"},{"line_number":43,"context_line":"perhaps that rigidly defining a couple more (like a database or neutron role)"},{"line_number":44,"context_line":"in the meantime would be us a lot of runway."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"Proposed Change"},{"line_number":47,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_0ec5f13a","line":44,"updated":"2015-11-25 16:26:08.000000000","message":"s/be us/buy us/","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8449,"name":"Marios Andreou","email":"marios.andreou@gmail.com","username":"marios"},"change_message_id":"f3e23c57f287e2a1dd90e107dc46a2300d620624","unresolved":false,"context_lines":[{"line_number":41,"context_line":"we have the abilty to flexibally define the services for each role I think"},{"line_number":42,"context_line":"it could be a logical next step to tackle the \"flexible roles\" issue but"},{"line_number":43,"context_line":"perhaps that rigidly defining a couple more (like a database or neutron role)"},{"line_number":44,"context_line":"in the meantime would be us a lot of runway."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"Proposed Change"},{"line_number":47,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a7e1126_131b4082","line":44,"in_reply_to":"9a8ffd7b_0ec5f13a","updated":"2015-12-22 09:04:29.000000000","message":"can you please revisit that last line. Do you mean use this \u0027composable services\u0027 approach to \u0027rigidly\u0027 define the services that go into a database, or neutron role and that for the forseeable future doing that will satisfy operator requests/requirements?","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":4328,"name":"Steven Hardy","email":"steven.hardy@suse.com","username":"shardy"},"change_message_id":"00a910e9875b7a2bb6b284e39654b32b5d18cb58","unresolved":false,"context_lines":[{"line_number":50,"context_line":"--------"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"The idea is that we will split up our rigid roles into a set of much"},{"line_number":53,"context_line":"smaller roles (or perhaps traits) that outline how to configure"},{"line_number":54,"context_line":"and encapsulate an individual service (or small set of services)."},{"line_number":55,"context_line":"Each service role will be defined as a nested stack heat template"},{"line_number":56,"context_line":"which has its own parameters, and \"role_data\" outputs to drive the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_e5a8cbdd","line":53,"updated":"2015-11-25 16:26:08.000000000","message":"I personally don\u0027t like the \"traits\" term, I think a role should be composed of \"services\", or maybe \"components\" - traits just (to me at least) doesn\u0027t clearly communicate an encapsulated service deployment/configuration.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":10873,"name":"Juan Antonio Osorio Robles","email":"jaosorior@redhat.com","username":"ejuaoso"},"change_message_id":"4311bf5b613021dfa6e81fa7a35fa83f03b5dfff","unresolved":false,"context_lines":[{"line_number":50,"context_line":"--------"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"The idea is that we will split up our rigid roles into a set of much"},{"line_number":53,"context_line":"smaller roles (or perhaps traits) that outline how to configure"},{"line_number":54,"context_line":"and encapsulate an individual service (or small set of services)."},{"line_number":55,"context_line":"Each service role will be defined as a nested stack heat template"},{"line_number":56,"context_line":"which has its own parameters, and \"role_data\" outputs to drive the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_358f812b","line":53,"in_reply_to":"3a7e1126_1ed6e74e","updated":"2016-02-06 16:50:33.000000000","message":"Seems like the right way to go. Lets revisit the terminology so this becomes easier to talk about and document. composable services within roles seems to make sense as a concept.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":6994,"name":"Michael Chapman","email":"woppin@gmail.com","username":"michaeltchapman"},"change_message_id":"97281bed7880a86e8c77d86ebdb3e15f05ebc707","unresolved":false,"context_lines":[{"line_number":50,"context_line":"--------"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"The idea is that we will split up our rigid roles into a set of much"},{"line_number":53,"context_line":"smaller roles (or perhaps traits) that outline how to configure"},{"line_number":54,"context_line":"and encapsulate an individual service (or small set of services)."},{"line_number":55,"context_line":"Each service role will be defined as a nested stack heat template"},{"line_number":56,"context_line":"which has its own parameters, and \"role_data\" outputs to drive the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7af24918_90186f86","line":53,"in_reply_to":"5a5ae5dd_358f812b","updated":"2016-03-02 03:33:19.000000000","message":"In puppet these are called profiles. A role is nothing more than a list of profiles, since it should be, as this spec proposes, composable in an ad-hoc manner. I think profile is a suitable term to use here as well, particularly given the puppet implementation.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":20775,"name":"Carlos Camacho","email":"ccamacho@redhat.com","username":"ccamacho"},"change_message_id":"f8c632aac55b68a0875ed1a292e85061b50d7c82","unresolved":false,"context_lines":[{"line_number":50,"context_line":"--------"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"The idea is that we will split up our rigid roles into a set of much"},{"line_number":53,"context_line":"smaller roles (or perhaps traits) that outline how to configure"},{"line_number":54,"context_line":"and encapsulate an individual service (or small set of services)."},{"line_number":55,"context_line":"Each service role will be defined as a nested stack heat template"},{"line_number":56,"context_line":"which has its own parameters, and \"role_data\" outputs to drive the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba0121b8_d17e7fad","line":53,"in_reply_to":"7af24918_90186f86","updated":"2016-03-29 11:20:27.000000000","message":"There are several similarities with this approach to a Software Product Line, in SPL’s the goal is to model features based in the commonality and variability of the functional components (Hardware resources, services, ...). It\u0027s possible to difference these components by adding attributes to the model and it uses a hierarchic structure (Like a nested stack). There are some references in the literature, for example ( https://github.com/ccamacho/papers/blob/master/1-s2.0-S2352220815000917-main.pdf  page 239 ) There you can see how to model a product line to deploy a “stack” based in roles, attributes, ... I think something similar can apply easily to formally define the composable services spec in THT","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":50,"context_line":"--------"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"The idea is that we will split up our rigid roles into a set of much"},{"line_number":53,"context_line":"smaller roles (or perhaps traits) that outline how to configure"},{"line_number":54,"context_line":"and encapsulate an individual service (or small set of services)."},{"line_number":55,"context_line":"Each service role will be defined as a nested stack heat template"},{"line_number":56,"context_line":"which has its own parameters, and \"role_data\" outputs to drive the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_e33b2337","line":53,"in_reply_to":"9a8ffd7b_047a1188","updated":"2015-11-30 21:23:07.000000000","message":"This was a big pain starting out in Tuskar, trying to get everyone to agree on these terms.\n\nI agree with Jiri that \"smaller roles\" isn\u0027t going to work. It\u0027s going to be a nightmare to talk about.\n\nTraits, IMO, is more of a tagging mechanic sort of word. Something to describe these pieces to perhaps use them in some sort of discovery process. I see why you\u0027re suggesting it, but \"trait\" feels innate to something, whereas we\u0027re talking about making roles more dynamic.\n\nServices could work, but I wonder if that will somehow cause confusion with the services that make up a project (especially given the next line about talking in terms of a small set of services).\n\nI like components as it\u0027s pretty agnostic to any existing breakdown of applications.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8449,"name":"Marios Andreou","email":"marios.andreou@gmail.com","username":"marios"},"change_message_id":"f3e23c57f287e2a1dd90e107dc46a2300d620624","unresolved":false,"context_lines":[{"line_number":50,"context_line":"--------"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"The idea is that we will split up our rigid roles into a set of much"},{"line_number":53,"context_line":"smaller roles (or perhaps traits) that outline how to configure"},{"line_number":54,"context_line":"and encapsulate an individual service (or small set of services)."},{"line_number":55,"context_line":"Each service role will be defined as a nested stack heat template"},{"line_number":56,"context_line":"which has its own parameters, and \"role_data\" outputs to drive the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a7e1126_1ed6e74e","line":53,"in_reply_to":"9a8ffd7b_e33b2337","updated":"2015-12-22 09:04:29.000000000","message":"+1 jistr -  So we are talking about composable services, not roles at this point right (glance-api, neutron-openvswitch-agent, not compute, control). \n\nI\u0027d revisit the use of roles here altogether...Why not just something like \u0027service configs\u0027\n\nThe idea is that we will split up our rigid roles into a set of much smaller service configs that outline how to ...\n\n\nEach service config will be defined as a nested stack...","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"b256d84756f49212a437ae89adaa4ad94150d4fc","unresolved":false,"context_lines":[{"line_number":50,"context_line":"--------"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"The idea is that we will split up our rigid roles into a set of much"},{"line_number":53,"context_line":"smaller roles (or perhaps traits) that outline how to configure"},{"line_number":54,"context_line":"and encapsulate an individual service (or small set of services)."},{"line_number":55,"context_line":"Each service role will be defined as a nested stack heat template"},{"line_number":56,"context_line":"which has its own parameters, and \"role_data\" outputs to drive the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_047a1188","line":53,"in_reply_to":"9a8ffd7b_e5a8cbdd","updated":"2015-11-30 13:22:53.000000000","message":"Hehe :) I\u0027m having a bit of trouble reviewing this because i constantly tend to think of \"roles\" as controller, compute, block storage etc., rather than glance-api, glance-registry etc. So perhaps i\u0027d prefer if \"role\" was a \"node type\", and then for the includable parts i don\u0027t mind very much traits/services/components sounds fine to me.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":7144,"name":"James Slagle","email":"jslagle@redhat.com","username":"slagle"},"change_message_id":"4dd554f74290d02fddbea0ffe4a30d9adc0e9065","unresolved":false,"context_lines":[{"line_number":51,"context_line":""},{"line_number":52,"context_line":"The idea is that we will split up our rigid roles into a set of much"},{"line_number":53,"context_line":"smaller roles (or perhaps traits) that outline how to configure"},{"line_number":54,"context_line":"and encapsulate an individual service (or small set of services)."},{"line_number":55,"context_line":"Each service role will be defined as a nested stack heat template"},{"line_number":56,"context_line":"which has its own parameters, and \"role_data\" outputs to drive the"},{"line_number":57,"context_line":"configuration (an updates) of that service to completion. The parameters"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_533ac2ce","line":54,"updated":"2016-02-10 16:52:50.000000000","message":"The first sentence here reads like a contradiction to the last paragraph of the previous section where you said we\u0027re not tackling flexible roles.\n\nWe\u0027re only allowing you to select which services/components are going to be enabled on our rigid roles.\n\nWe\u0027re not allowing anyone to split roles afaict. E.g., this spec doesn\u0027t cover how you might split the controller role into an api-server role and a db-server role (although it indirectly lays a framework for doings so).\n\nSo, I think it would be beneficial to call this distinction out more clearly about what we\u0027re initially addressing and what we aren\u0027t.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":7144,"name":"James Slagle","email":"jslagle@redhat.com","username":"slagle"},"change_message_id":"4dd554f74290d02fddbea0ffe4a30d9adc0e9065","unresolved":false,"context_lines":[{"line_number":52,"context_line":"The idea is that we will split up our rigid roles into a set of much"},{"line_number":53,"context_line":"smaller roles (or perhaps traits) that outline how to configure"},{"line_number":54,"context_line":"and encapsulate an individual service (or small set of services)."},{"line_number":55,"context_line":"Each service role will be defined as a nested stack heat template"},{"line_number":56,"context_line":"which has its own parameters, and \"role_data\" outputs to drive the"},{"line_number":57,"context_line":"configuration (an updates) of that service to completion. The parameters"},{"line_number":58,"context_line":"for each services are free form (each services can choose its own parameters)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_33461e50","line":55,"updated":"2016-02-10 16:52:50.000000000","message":"Agree with the other comments that we need a consistent terminology for these things without overlapping names.\n\nTo me, the role is what is applied to a server. e.g., control or compute.\n\nI\u0027d prefer to just call what makes up a role as \"services\". components is a bit too generic for me. Aren\u0027t they always going to be a running process, which equates to service in my mind.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":54,"context_line":"and encapsulate an individual service (or small set of services)."},{"line_number":55,"context_line":"Each service role will be defined as a nested stack heat template"},{"line_number":56,"context_line":"which has its own parameters, and \"role_data\" outputs to drive the"},{"line_number":57,"context_line":"configuration (an updates) of that service to completion. The parameters"},{"line_number":58,"context_line":"for each services are free form (each services can choose its own parameters)"},{"line_number":59,"context_line":"however the role_data outputs from a specific service role nested stack heat"},{"line_number":60,"context_line":"template must be a JSON data scructure that may optionally define the following"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_e3d7a3bd","line":57,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"and updates\"","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":55,"context_line":"Each service role will be defined as a nested stack heat template"},{"line_number":56,"context_line":"which has its own parameters, and \"role_data\" outputs to drive the"},{"line_number":57,"context_line":"configuration (an updates) of that service to completion. The parameters"},{"line_number":58,"context_line":"for each services are free form (each services can choose its own parameters)"},{"line_number":59,"context_line":"however the role_data outputs from a specific service role nested stack heat"},{"line_number":60,"context_line":"template must be a JSON data scructure that may optionally define the following"},{"line_number":61,"context_line":"sections:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_03e747ad","line":58,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"service\" not \"services\" in both cases.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":57,"context_line":"configuration (an updates) of that service to completion. The parameters"},{"line_number":58,"context_line":"for each services are free form (each services can choose its own parameters)"},{"line_number":59,"context_line":"however the role_data outputs from a specific service role nested stack heat"},{"line_number":60,"context_line":"template must be a JSON data scructure that may optionally define the following"},{"line_number":61,"context_line":"sections:"},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  * config_settings: this section drives any custom hiera data that is required"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_a38f5bcb","line":60,"updated":"2015-11-30 21:23:07.000000000","message":"\"specific service role nested stack heat template\" - If there isn\u0027t a shorter way to write this, trying to document/talk about it is going to be a nightmare :)","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"b256d84756f49212a437ae89adaa4ad94150d4fc","unresolved":false,"context_lines":[{"line_number":87,"context_line":""},{"line_number":88,"context_line":"  * config_steps_6: Post install, Fencing (Pacemaker)"},{"line_number":89,"context_line":"    Any puppet includes or puppet manifest snippets that should run at"},{"line_number":90,"context_line":"    config step 6. Optional."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"  * container_urls:"},{"line_number":93,"context_line":"    Custom docker (or other) container URLs that may be used to configure"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_e04850ce","line":90,"updated":"2015-11-30 13:22:53.000000000","message":"We might need Step7 as we move overcloud initialization to Puppet, maybe just for the pacemaker scenario, which is generally more step-hungry. I guess it wouldn\u0027t be an issue to add that extra step later, as these sections in the output JSON are optional.\n\n(https://review.openstack.org/#/c/180566/30 was on my mind when writing the comment, though in this specific case we might be able to lift the Step7 requirement, after recent enhancements in puppet-heat)","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":6994,"name":"Michael Chapman","email":"woppin@gmail.com","username":"michaeltchapman"},"change_message_id":"97281bed7880a86e8c77d86ebdb3e15f05ebc707","unresolved":false,"context_lines":[{"line_number":87,"context_line":""},{"line_number":88,"context_line":"  * config_steps_6: Post install, Fencing (Pacemaker)"},{"line_number":89,"context_line":"    Any puppet includes or puppet manifest snippets that should run at"},{"line_number":90,"context_line":"    config step 6. Optional."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"  * container_urls:"},{"line_number":93,"context_line":"    Custom docker (or other) container URLs that may be used to configure"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7af24918_6bee9423","line":90,"in_reply_to":"9a8ffd7b_e04850ce","updated":"2016-03-02 03:33:19.000000000","message":"This isn\u0027t specifically related to this spec, but once services are composable the orchestration dependencies between them can be modelled explicitly and the entire \u0027steps\u0027 concept can be replaced with gated includes via a hiera backend to a service catalog. There\u0027s a description of how to do this here: https://gist.github.com/michaeltchapman/adf2eb593e619d1494f6\n\nThis system allowed the system to recover from temporary failures during deployment/upgrade, which was nice.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8648,"name":"Radomir Dopieralski","email":"openstack@dopieralski.pl","username":"thesheep"},"change_message_id":"73cd1a0727f393033509d8775598da03eee5dee5","unresolved":false,"context_lines":[{"line_number":112,"context_line":""},{"line_number":113,"context_line":"The reason we manage the per server host bind settings in the server templates"},{"line_number":114,"context_line":"is because that is the only place that currently has (clean) access to"},{"line_number":115,"context_line":"these port/IP addresses.  The existance of these settings"},{"line_number":116,"context_line":"in the server templates won\u0027t cause functional configuration unless the"},{"line_number":117,"context_line":"associated puppet manifest enables the service. In this regard the service"},{"line_number":118,"context_line":"role templates config section should be thought of as \"global\" containing"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_b31f92b6","line":115,"updated":"2016-05-12 12:50:47.000000000","message":"nit: existence","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"b256d84756f49212a437ae89adaa4ad94150d4fc","unresolved":false,"context_lines":[{"line_number":117,"context_line":"associated puppet manifest enables the service. In this regard the service"},{"line_number":118,"context_line":"role templates config section should be thought of as \"global\" containing"},{"line_number":119,"context_line":"configuration data and VIPs that apply to all instances of a service"},{"line_number":120,"context_line":"within a cluster."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"NOTE on config_steps"},{"line_number":123,"context_line":"~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_7f7fe914","line":120,"updated":"2015-11-30 13:22:53.000000000","message":"[Forward looking, not a request for change.] The way you described is fine for the first iteration i think, it\u0027s going to be a significant change anyway :) However i wonder if, over time, we\u0027ll find ourselves in need to expose the IP/port parameters to the particular service SoftwareConfigs/SoftwareDeployments anyway.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"b256d84756f49212a437ae89adaa4ad94150d4fc","unresolved":false,"context_lines":[{"line_number":125,"context_line":"In general we want the contents of each config_step section to be just an"},{"line_number":126,"context_line":"include(s) to puppet modules. Any inline manifests should be kept to"},{"line_number":127,"context_line":"a minimum so as to avoid potential \"namespacing\" issues when we"},{"line_number":128,"context_line":"reconstruct the template to run at deployment time on each node. This"},{"line_number":129,"context_line":"is a fairly major shift in tripleo-heat-templates and means that we will"},{"line_number":130,"context_line":"likely want to create individual role manifests (all very small and focussed)"},{"line_number":131,"context_line":"in puppet-tripleo to help model this data. The development workflow here"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_9f0acd24","line":128,"updated":"2015-11-30 13:22:53.000000000","message":"Sorry i\u0027m having trouble following what this sentence refers to. What is meant by \"reconstruct the template\"? Do you mean passing multiple mini-manifests to Puppet simultaneously?","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8449,"name":"Marios Andreou","email":"marios.andreou@gmail.com","username":"marios"},"change_message_id":"f3e23c57f287e2a1dd90e107dc46a2300d620624","unresolved":false,"context_lines":[{"line_number":125,"context_line":"In general we want the contents of each config_step section to be just an"},{"line_number":126,"context_line":"include(s) to puppet modules. Any inline manifests should be kept to"},{"line_number":127,"context_line":"a minimum so as to avoid potential \"namespacing\" issues when we"},{"line_number":128,"context_line":"reconstruct the template to run at deployment time on each node. This"},{"line_number":129,"context_line":"is a fairly major shift in tripleo-heat-templates and means that we will"},{"line_number":130,"context_line":"likely want to create individual role manifests (all very small and focussed)"},{"line_number":131,"context_line":"in puppet-tripleo to help model this data. The development workflow here"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a7e1126_fea3dbaf","line":128,"in_reply_to":"9a8ffd7b_9f0acd24","updated":"2015-12-22 09:04:29.000000000","message":"yeah at https://review.openstack.org/#/c/236243/","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":127,"context_line":"a minimum so as to avoid potential \"namespacing\" issues when we"},{"line_number":128,"context_line":"reconstruct the template to run at deployment time on each node. This"},{"line_number":129,"context_line":"is a fairly major shift in tripleo-heat-templates and means that we will"},{"line_number":130,"context_line":"likely want to create individual role manifests (all very small and focussed)"},{"line_number":131,"context_line":"in puppet-tripleo to help model this data. The development workflow here"},{"line_number":132,"context_line":"should be impacted minimally as we also have recent patches which allow"},{"line_number":133,"context_line":"developers (and operators) to consume changes to puppet-tripleo without"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_4330ef07","line":130,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"focused\"","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"b256d84756f49212a437ae89adaa4ad94150d4fc","unresolved":false,"context_lines":[{"line_number":131,"context_line":"in puppet-tripleo to help model this data. The development workflow here"},{"line_number":132,"context_line":"should be impacted minimally as we also have recent patches which allow"},{"line_number":133,"context_line":"developers (and operators) to consume changes to puppet-tripleo without"},{"line_number":134,"context_line":"building an RPM package (thus things are still hackable locally)."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Top level params"},{"line_number":137,"context_line":"~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_311c3569","line":134,"updated":"2015-11-30 13:22:53.000000000","message":"One question related to the steps. In Puppet run in step N, do we pass also all the manifests from step N-1, N-2 etc.? Currently we\u0027re effectively doing so, and the benefit is that Puppet can guard convergence (if step 3 would undo/conflict with something that step 2 did, Puppet will refuse to run).","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":4328,"name":"Steven Hardy","email":"steven.hardy@suse.com","username":"shardy"},"change_message_id":"00a910e9875b7a2bb6b284e39654b32b5d18cb58","unresolved":false,"context_lines":[{"line_number":136,"context_line":"Top level params"},{"line_number":137,"context_line":"~~~~~~~~~~~~~~~~"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"We will strive to expose all service role parameters via the top level \"overcloud\" heat stack."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Enabling service"},{"line_number":142,"context_line":"~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_0eabb11e","line":139,"updated":"2015-11-25 16:26:08.000000000","message":"This is actually the opposite of what the patches are doing - everything is moving out of overcloud_without_mergepy into the role template, then the role parameters are only accessible via parameter defaults.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"b256d84756f49212a437ae89adaa4ad94150d4fc","unresolved":false,"context_lines":[{"line_number":136,"context_line":"Top level params"},{"line_number":137,"context_line":"~~~~~~~~~~~~~~~~"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"We will strive to expose all service role parameters via the top level \"overcloud\" heat stack."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Enabling service"},{"line_number":142,"context_line":"~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_7a237756","line":139,"updated":"2015-11-30 13:22:53.000000000","message":"This is something i\u0027ve been thinking about a bit lately. Perhaps using parameter_defaults over top-level params is the way which would allow us to have a per-deployment customizable set of roles in the future (have custom \"node types\" without prior knowledge in the top-level template about what the \"node types\" are and what params they need).\n\nMore about that on the list:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2015-November/080604.html","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":7509,"name":"Jiri Tomasek","email":"jtomasek@redhat.com","username":"jtomasek"},"change_message_id":"d4f36104e0cf67b515b4cd4281571b9adba96c50","unresolved":false,"context_lines":[{"line_number":136,"context_line":"Top level params"},{"line_number":137,"context_line":"~~~~~~~~~~~~~~~~"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"We will strive to expose all service role parameters via the top level \"overcloud\" heat stack."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Enabling service"},{"line_number":142,"context_line":"~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a740942_6e5acf52","line":139,"in_reply_to":"9a8ffd7b_7a237756","updated":"2015-12-09 11:18:49.000000000","message":"As I noted on the list, I am inclining to using top-level parameters only to define parameters that are explicitly required for minimal deployment. This will reduce the number of non-required parameters which are listed for the user to set.\n\nSame concept as this spec brings could be applied to make roles optional - The root environment defines just a base roles explicitly required for deployment (controller, compute) and all other roles are defined in separate optional environments.\n\nUsing this approach, the deployment design process boils down to:\n1. select environments set that matches the desired result\n2. set parameters values defined by selected environments\n\nOnly thing we need to make sure is we properly identify/validate/map the mechanism of environments selection combinations.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":136,"context_line":"Top level params"},{"line_number":137,"context_line":"~~~~~~~~~~~~~~~~"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"We will strive to expose all service role parameters via the top level \"overcloud\" heat stack."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Enabling service"},{"line_number":142,"context_line":"~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_9e470a4b","line":139,"in_reply_to":"9a8ffd7b_7a237756","updated":"2015-11-30 21:23:07.000000000","message":"I\u0027ll echo comments I made in that thread here.\n\nTop-level parameters define an integration API. Changes to that parameter set will have to be done carefully in the future to avoid breaking integrations that aren\u0027t part of the tripleo codebase.\n\nMaybe the large changes that result from this spec are the time to say \"this is the v1 THT API\" and then start to be more careful about changing that. Alternatively, we use this opportunity to significantly reduce that API footprint and move more into parameter_defaults to make backward compatible changes easier in the future.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":10873,"name":"Juan Antonio Osorio Robles","email":"jaosorior@redhat.com","username":"ejuaoso"},"change_message_id":"4311bf5b613021dfa6e81fa7a35fa83f03b5dfff","unresolved":false,"context_lines":[{"line_number":139,"context_line":"We will strive to expose all service role parameters via the top level \"overcloud\" heat stack."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Enabling service"},{"line_number":142,"context_line":"~~~~~~~~~~~~~~~~"},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"The goal would be to enable roles by simply choosing modifying a heat"},{"line_number":145,"context_line":"parameter. For the controller role we could add a new top level Heat"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_95a515a3","line":142,"updated":"2016-02-06 16:50:33.000000000","message":"Should we also be looking into disabling a service? It will become more complicated. But if an operator decides that the computes should no longer have X service for some reason; It seems to me that the only way to disable that is to tear down the nodes that have that role. So having a service-disabling manifest per service might actually make sense.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":141,"context_line":"Enabling service"},{"line_number":142,"context_line":"~~~~~~~~~~~~~~~~"},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"The goal would be to enable roles by simply choosing modifying a heat"},{"line_number":145,"context_line":"parameter. For the controller role we could add a new top level Heat"},{"line_number":146,"context_line":"parameter called \u0027ControllerServices\u0027 that would allow an operator to"},{"line_number":147,"context_line":"control the configured roles. Example:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_5e78c28f","line":144,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"choosing modifying\" isn\u0027t grammatically correct","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8449,"name":"Marios Andreou","email":"marios.andreou@gmail.com","username":"marios"},"change_message_id":"f3e23c57f287e2a1dd90e107dc46a2300d620624","unresolved":false,"context_lines":[{"line_number":143,"context_line":""},{"line_number":144,"context_line":"The goal would be to enable roles by simply choosing modifying a heat"},{"line_number":145,"context_line":"parameter. For the controller role we could add a new top level Heat"},{"line_number":146,"context_line":"parameter called \u0027ControllerServices\u0027 that would allow an operator to"},{"line_number":147,"context_line":"control the configured roles. Example:"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":".. code-block:: yaml"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a7e1126_3ec3a339","line":146,"updated":"2015-12-22 09:04:29.000000000","message":"would be great to link to the reviews too, like here is https://review.openstack.org/#/c/259568/6/overcloud.yaml","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":4328,"name":"Steven Hardy","email":"steven.hardy@suse.com","username":"shardy"},"change_message_id":"00a910e9875b7a2bb6b284e39654b32b5d18cb58","unresolved":false,"context_lines":[{"line_number":157,"context_line":"----"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"Using a Heat parameter is probably the simplest mechanism to implement"},{"line_number":160,"context_line":"this setting. As we move to towards ad-hoc role definitions (not in"},{"line_number":161,"context_line":"this spec) it is worth thinging about allows the user to free form"},{"line_number":162,"context_line":"the roles (perhaps this is even a good mechanism to move docker containers"},{"line_number":163,"context_line":"around a cluster, etc.). Imagine a format like testenv.json (what we currently"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_c2357d46","line":160,"updated":"2015-11-25 16:26:08.000000000","message":"So, I like the parameter approach, but I wonder if we might be able to make this cleaner via the proposed ResourceChain interface:\n\nhttps://review.openstack.org/#/c/228615/\n\nThen the parameter definition would look like:\n\n  ControllerDeploymentSteps:\n    type: json\n    default:\n      step1: [controller/loadbalancer.yaml]\n      step2: [controller/db.yaml, controller/rabbit.yaml]\n      step3: [controller/keystone.yaml, controller/glance-api.yaml ...]\n\nAnd in the controller-post.yaml, we\u0027d chain the templates together, like this:\n\n  DeploymentStep1:\n    type: OS::Heat::ResourceChain\n      properties:\t\n        types: {get_param: [ControllerDeploymentSteps, step1]}\n        resource_properties:\n          servers: {get_param: servers}\n\n  DeploymentStep2:\n    type: OS::Heat::ResourceChain\n      properties:\t\n        types: {get_param: [ControllerDeploymentSteps, step2]}\n        resource_properties:\n          servers: {get_param: servers}\n\netc\n\nThe nice thing about this is it keeps the service deployment completely encapsulated in a separate heat template, without the merging of manifests etc.  This would also enable much easier testing, as each template could probably be applied in isolation, e.g for debugging.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"b256d84756f49212a437ae89adaa4ad94150d4fc","unresolved":false,"context_lines":[{"line_number":157,"context_line":"----"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"Using a Heat parameter is probably the simplest mechanism to implement"},{"line_number":160,"context_line":"this setting. As we move to towards ad-hoc role definitions (not in"},{"line_number":161,"context_line":"this spec) it is worth thinging about allows the user to free form"},{"line_number":162,"context_line":"the roles (perhaps this is even a good mechanism to move docker containers"},{"line_number":163,"context_line":"around a cluster, etc.). Imagine a format like testenv.json (what we currently"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_ee97ace9","line":160,"in_reply_to":"9a8ffd7b_c2357d46","updated":"2015-11-30 13:22:53.000000000","message":"I think we\u0027ll have to use the ResourceChains for this anyway, right? What the blueprint suggests is already a customizable list of nested stack YAMLs, in essence.\n\nThe blueprint as it is caputres what we need probably a bit closer, as the service configuration can span multiple steps. We cannot assume that e.g. keystone configuration happens only in step 3.\n\nHowever, the benefit of what you are suggesting is that the individual \"service stacks\" don\u0027t need to conform to a shared agreement over what is supposed to happen in what step (and the responsibility about this shifts to how the node role is composed). This seems a bit cleaner to me. Perhaps if we\u0027d be OK with splitting the service configuration further if needed, we could get the best of both worlds:\n\n      # write config files on all nodes first\n      step3: [controller/keystone-config.yaml, controller/glance-config.yaml ...]\n\n      # start services (e.g. create a pcmk resource via the bootstrap node)\n      step4: [controller/keystone-service.yaml, controller/glance-api-service.yaml, controller/glance-registry-service.yaml ...]\n\nThen we\u0027d have probably finer-grained parameters to control the service customization, like ControllerStep1, ControllerStep2 etc., which means enabling services is a bit more involved process.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":157,"context_line":"----"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"Using a Heat parameter is probably the simplest mechanism to implement"},{"line_number":160,"context_line":"this setting. As we move to towards ad-hoc role definitions (not in"},{"line_number":161,"context_line":"this spec) it is worth thinging about allows the user to free form"},{"line_number":162,"context_line":"the roles (perhaps this is even a good mechanism to move docker containers"},{"line_number":163,"context_line":"around a cluster, etc.). Imagine a format like testenv.json (what we currently"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_de64b2e6","line":160,"in_reply_to":"9a8ffd7b_c2357d46","updated":"2015-11-30 21:23:07.000000000","message":"I\u0027m with Steve here, ResourceChains will help provide a lot of this functionality innately in HOT.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":3153,"name":"Emilien Macchi","email":"emilien@redhat.com","username":"emilienm"},"change_message_id":"b00cd90e2db0fa0397d430e0363f0769253435c3","unresolved":false,"context_lines":[{"line_number":157,"context_line":"----"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"Using a Heat parameter is probably the simplest mechanism to implement"},{"line_number":160,"context_line":"this setting. As we move to towards ad-hoc role definitions (not in"},{"line_number":161,"context_line":"this spec) it is worth thinging about allows the user to free form"},{"line_number":162,"context_line":"the roles (perhaps this is even a good mechanism to move docker containers"},{"line_number":163,"context_line":"around a cluster, etc.). Imagine a format like testenv.json (what we currently"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dae33548_d22129a1","line":160,"in_reply_to":"9a8ffd7b_de64b2e6","updated":"2016-02-16 17:34:20.000000000","message":"I like this approach a lot.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":158,"context_line":""},{"line_number":159,"context_line":"Using a Heat parameter is probably the simplest mechanism to implement"},{"line_number":160,"context_line":"this setting. As we move to towards ad-hoc role definitions (not in"},{"line_number":161,"context_line":"this spec) it is worth thinging about allows the user to free form"},{"line_number":162,"context_line":"the roles (perhaps this is even a good mechanism to move docker containers"},{"line_number":163,"context_line":"around a cluster, etc.). Imagine a format like testenv.json (what we currently"},{"line_number":164,"context_line":"feed to Ironic for provisioning) also contained a simple service role list"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_1ea9dadf","line":161,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"thinking\", not \"thinging\"\n\nNit: \"thinking about allows\" doesn\u0027t make sense; did you mean \"thinking about allowing the user\" ?","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8648,"name":"Radomir Dopieralski","email":"openstack@dopieralski.pl","username":"thesheep"},"change_message_id":"73cd1a0727f393033509d8775598da03eee5dee5","unresolved":false,"context_lines":[{"line_number":160,"context_line":"this setting. As we move to towards ad-hoc role definitions (not in"},{"line_number":161,"context_line":"this spec) it is worth thinging about allows the user to free form"},{"line_number":162,"context_line":"the roles (perhaps this is even a good mechanism to move docker containers"},{"line_number":163,"context_line":"around a cluster, etc.). Imagine a format like testenv.json (what we currently"},{"line_number":164,"context_line":"feed to Ironic for provisioning) also contained a simple service role list"},{"line_number":165,"context_line":"that needed to be deployed on each node. Something like could be passed"},{"line_number":166,"context_line":"into our overcloud configuration stack and thus provide the outline for"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dab17558_7376cad9","line":163,"updated":"2016-05-12 12:50:47.000000000","message":"nit: imagine that","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":162,"context_line":"the roles (perhaps this is even a good mechanism to move docker containers"},{"line_number":163,"context_line":"around a cluster, etc.). Imagine a format like testenv.json (what we currently"},{"line_number":164,"context_line":"feed to Ironic for provisioning) also contained a simple service role list"},{"line_number":165,"context_line":"that needed to be deployed on each node. Something like could be passed"},{"line_number":166,"context_line":"into our overcloud configuration stack and thus provide the outline for"},{"line_number":167,"context_line":"what services run where within a cluster. (Imagine moving docker containers,"},{"line_number":168,"context_line":"around in a similar fashion... all driven by a simple JSON file provided"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_5e868266","line":165,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"Something like *this* could be...\"","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":171,"context_line":"Alternatives"},{"line_number":172,"context_line":"------------"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":" * Continue to grow our rigig role manifests by adding (complex) conditionals"},{"line_number":175,"context_line":"   and logic to accomidate all of the service combinations that users"},{"line_number":176,"context_line":"   would like to have. This will likely continue to be painful as we"},{"line_number":177,"context_line":"   add more vendor drivers to existing services and more core services"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_9e8cea80","line":174,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"rigid\", not \"rigig\"","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":172,"context_line":"------------"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":" * Continue to grow our rigig role manifests by adding (complex) conditionals"},{"line_number":175,"context_line":"   and logic to accomidate all of the service combinations that users"},{"line_number":176,"context_line":"   would like to have. This will likely continue to be painful as we"},{"line_number":177,"context_line":"   add more vendor drivers to existing services and more core services"},{"line_number":178,"context_line":"   alike."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_bedc4e75","line":175,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"accommodate\", not \"accomidate\"","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":10873,"name":"Juan Antonio Osorio Robles","email":"jaosorior@redhat.com","username":"ejuaoso"},"change_message_id":"4311bf5b613021dfa6e81fa7a35fa83f03b5dfff","unresolved":false,"context_lines":[{"line_number":182,"context_line":""},{"line_number":183,"context_line":"The changes here only deal with how we implement and configure specific"},{"line_number":184,"context_line":"OpenStack services. We need to be careful to preserve existing settings"},{"line_number":185,"context_line":"when moving to the new service role implementation formats."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Performance Impact"},{"line_number":188,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_15dfe50d","line":185,"updated":"2016-02-06 16:50:33.000000000","message":"On the other hand, if a service is to be removed from the list, with the current proposal it would be left running there unmanaged, which would be a security risk. I think there might be a need for service-disabling to be included here.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":4328,"name":"Steven Hardy","email":"steven.hardy@suse.com","username":"shardy"},"change_message_id":"00a910e9875b7a2bb6b284e39654b32b5d18cb58","unresolved":false,"context_lines":[{"line_number":188,"context_line":"------------------"},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"On the controller role we already have 6 deployment steps during each"},{"line_number":191,"context_line":"heat stack-create/update. The other 4 roles today (compute, ceph, swift, cinder)"},{"line_number":192,"context_line":"all use one or two steps for during deployment. We would likely want to"},{"line_number":193,"context_line":"modify all the roles to support a 6 step deployment process so that each"},{"line_number":194,"context_line":"of the config_steps is properly supported and thus portable across the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_c2d1fdce","line":191,"updated":"2015-11-25 16:26:08.000000000","message":"With the ResourceChain approach, there\u0027s no performance impact, because if there are zero templates defined in the chain, we do nothing (or maybe create an empty nested stack, which will have a negligible performance impact).","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":190,"context_line":"On the controller role we already have 6 deployment steps during each"},{"line_number":191,"context_line":"heat stack-create/update. The other 4 roles today (compute, ceph, swift, cinder)"},{"line_number":192,"context_line":"all use one or two steps for during deployment. We would likely want to"},{"line_number":193,"context_line":"modify all the roles to support a 6 step deployment process so that each"},{"line_number":194,"context_line":"of the config_steps is properly supported and thus portable across the"},{"line_number":195,"context_line":"roles. This may slighly increase the total deployment time for each"},{"line_number":196,"context_line":"compute node for example by a minute or two due to added heat callbacks"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_be71ae79","line":193,"updated":"2015-11-30 21:23:07.000000000","message":"This is similar to my comment above about an API. We need to make sure these steps are the ones we are comfortable with and won\u0027t be adding/removing them frequently. I\u0027d like to see this part be brought up into the Proposed Change section itself and flushed out rather than only brought up in the context of performance.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":192,"context_line":"all use one or two steps for during deployment. We would likely want to"},{"line_number":193,"context_line":"modify all the roles to support a 6 step deployment process so that each"},{"line_number":194,"context_line":"of the config_steps is properly supported and thus portable across the"},{"line_number":195,"context_line":"roles. This may slighly increase the total deployment time for each"},{"line_number":196,"context_line":"compute node for example by a minute or two due to added heat callbacks"},{"line_number":197,"context_line":"and polling intervals, etc."},{"line_number":198,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_7ebd8601","line":195,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"slightly\", not \"slighly\"","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":208,"context_line":"In some cases instead of using a boolean parameter to enable/disable"},{"line_number":209,"context_line":"a service we would now use the inclusion or exclusion of the role name"},{"line_number":210,"context_line":"in a Heat list parameter. It may be possible to work around some of these"},{"line_number":211,"context_line":"cases with tooling like tripleoclient to make the upgrades process"},{"line_number":212,"context_line":"more transparent."},{"line_number":213,"context_line":""},{"line_number":214,"context_line":"Developer Impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_5e09a2dc","line":211,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"upgrade\", not \"upgrades\"","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":3153,"name":"Emilien Macchi","email":"emilien@redhat.com","username":"emilienm"},"change_message_id":"b00cd90e2db0fa0397d430e0363f0769253435c3","unresolved":false,"context_lines":[{"line_number":223,"context_line":""},{"line_number":224,"context_line":" * modify puppet-tripleo role manifest (in a local directory)"},{"line_number":225,"context_line":""},{"line_number":226,"context_line":" * push updated puppet modules to Swift"},{"line_number":227,"context_line":""},{"line_number":228,"context_line":" * modify tripleo-heat-templates nested stack role template"},{"line_number":229,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"dae33548_729f7db4","line":226,"updated":"2016-02-16 17:34:20.000000000","message":"why? puppet modules are in a single package, installed on all nodes. We just need to distribute hieradata here, generated by tripleo + heat, right?\n\nif I\u0027m wrong, please explain here, it\u0027s not clear to me.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":4328,"name":"Steven Hardy","email":"steven.hardy@suse.com","username":"shardy"},"change_message_id":"00a910e9875b7a2bb6b284e39654b32b5d18cb58","unresolved":false,"context_lines":[{"line_number":227,"context_line":""},{"line_number":228,"context_line":" * modify tripleo-heat-templates nested stack role template"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":" * heat stack-update to test these changes"},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"The above would involve no RPM building but would still allow developers"},{"line_number":233,"context_line":"and operators to test slight tweaks and changes to the puppet modules and role"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_4282ed95","line":230,"updated":"2015-11-25 16:26:08.000000000","message":"This workflow impact seems somewhat tangential to the composable roles to me, I think it sounds good, but I\u0027m not sure if it really belongs in this spec?","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":243,"context_line":"Work Items"},{"line_number":244,"context_line":"----------"},{"line_number":245,"context_line":""},{"line_number":246,"context_line":" * Splits the overcloud_controller.pp and overcloud_controller_pacemaker.pp"},{"line_number":247,"context_line":"   manifests into 6 individual steps that we then re-construct during"},{"line_number":248,"context_line":"   deployment. This allows us to gradually implement and inject data"},{"line_number":249,"context_line":"   from individual service roles in a patch series."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_7e190622","line":246,"updated":"2015-11-30 21:23:07.000000000","message":"Nit: \"split\", not \"splits\"","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8449,"name":"Marios Andreou","email":"marios.andreou@gmail.com","username":"marios"},"change_message_id":"f3e23c57f287e2a1dd90e107dc46a2300d620624","unresolved":false,"context_lines":[{"line_number":243,"context_line":"Work Items"},{"line_number":244,"context_line":"----------"},{"line_number":245,"context_line":""},{"line_number":246,"context_line":" * Splits the overcloud_controller.pp and overcloud_controller_pacemaker.pp"},{"line_number":247,"context_line":"   manifests into 6 individual steps that we then re-construct during"},{"line_number":248,"context_line":"   deployment. This allows us to gradually implement and inject data"},{"line_number":249,"context_line":"   from individual service roles in a patch series."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a7e1126_7efb6b79","line":246,"updated":"2015-12-22 09:04:29.000000000","message":"https://review.openstack.org/#/c/236243/","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":4328,"name":"Steven Hardy","email":"steven.hardy@suse.com","username":"shardy"},"change_message_id":"00a910e9875b7a2bb6b284e39654b32b5d18cb58","unresolved":false,"context_lines":[{"line_number":244,"context_line":"----------"},{"line_number":245,"context_line":""},{"line_number":246,"context_line":" * Splits the overcloud_controller.pp and overcloud_controller_pacemaker.pp"},{"line_number":247,"context_line":"   manifests into 6 individual steps that we then re-construct during"},{"line_number":248,"context_line":"   deployment. This allows us to gradually implement and inject data"},{"line_number":249,"context_line":"   from individual service roles in a patch series."},{"line_number":250,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_a208792e","line":247,"updated":"2015-11-25 16:26:08.000000000","message":"So, it\u0027s more than that isn\u0027t it - we need to split them into per-service manifests, and then potentially further split those manifests where multi-step configuration of a service is required?","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":246,"context_line":" * Splits the overcloud_controller.pp and overcloud_controller_pacemaker.pp"},{"line_number":247,"context_line":"   manifests into 6 individual steps that we then re-construct during"},{"line_number":248,"context_line":"   deployment. This allows us to gradually implement and inject data"},{"line_number":249,"context_line":"   from individual service roles in a patch series."},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"For each role"},{"line_number":252,"context_line":"~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_9e162af0","line":249,"updated":"2015-11-30 21:23:07.000000000","message":"Do we need work items to split the other roles into multiple steps as well?","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":10873,"name":"Juan Antonio Osorio Robles","email":"jaosorior@redhat.com","username":"ejuaoso"},"change_message_id":"4311bf5b613021dfa6e81fa7a35fa83f03b5dfff","unresolved":false,"context_lines":[{"line_number":246,"context_line":" * Splits the overcloud_controller.pp and overcloud_controller_pacemaker.pp"},{"line_number":247,"context_line":"   manifests into 6 individual steps that we then re-construct during"},{"line_number":248,"context_line":"   deployment. This allows us to gradually implement and inject data"},{"line_number":249,"context_line":"   from individual service roles in a patch series."},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"For each role"},{"line_number":252,"context_line":"~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_b5d051f7","line":249,"in_reply_to":"9a8ffd7b_9e162af0","updated":"2016-02-06 16:50:33.000000000","message":"Will adding pluggable services and documenting a way to do so be done as part of this spec?","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8399,"name":"Jay Dobies","email":"jason.dobies@redhat.com","username":"jdob"},"change_message_id":"cc1edd7d79f8b2dd37ff3138bf0503ce1869710e","unresolved":false,"context_lines":[{"line_number":247,"context_line":"   manifests into 6 individual steps that we then re-construct during"},{"line_number":248,"context_line":"   deployment. This allows us to gradually implement and inject data"},{"line_number":249,"context_line":"   from individual service roles in a patch series."},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"For each role"},{"line_number":252,"context_line":"~~~~~~~~~~~~~"},{"line_number":253,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_1e2a3a2d","line":250,"updated":"2015-11-30 21:23:07.000000000","message":"We really should have a work item that covers adding docs on how to use the new format.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":3153,"name":"Emilien Macchi","email":"emilien@redhat.com","username":"emilienm"},"change_message_id":"b00cd90e2db0fa0397d430e0363f0769253435c3","unresolved":false,"context_lines":[{"line_number":251,"context_line":"For each role"},{"line_number":252,"context_line":"~~~~~~~~~~~~~"},{"line_number":253,"context_line":""},{"line_number":254,"context_line":" * Create puppet-tripleo role manifest(s)"},{"line_number":255,"context_line":""},{"line_number":256,"context_line":" * Create a heat nested stack template that uses the new puppet-tripleo"},{"line_number":257,"context_line":"   manifest to configure/enable the service."}],"source_content_type":"text/x-rst","patch_set":2,"id":"dae33548_328df57b","line":254,"updated":"2016-02-16 17:34:20.000000000","message":"it\u0027s optional, whether we need it or not. Some services might not need it (glance?)","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":6994,"name":"Michael Chapman","email":"woppin@gmail.com","username":"michaeltchapman"},"change_message_id":"97281bed7880a86e8c77d86ebdb3e15f05ebc707","unresolved":false,"context_lines":[{"line_number":251,"context_line":"For each role"},{"line_number":252,"context_line":"~~~~~~~~~~~~~"},{"line_number":253,"context_line":""},{"line_number":254,"context_line":" * Create puppet-tripleo role manifest(s)"},{"line_number":255,"context_line":""},{"line_number":256,"context_line":" * Create a heat nested stack template that uses the new puppet-tripleo"},{"line_number":257,"context_line":"   manifest to configure/enable the service."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7af24918_aba41c57","line":254,"in_reply_to":"dae33548_328df57b","updated":"2016-03-02 03:33:19.000000000","message":"For a well written example of this you might like to refer to these profiles: https://github.com/Mylezeem/puppeels/tree/master/manifests/openstack\n\nI also suggest you break the profiles up so that there is a base profile responsible for the service like this:\n\nclass profile::base::glance::api {\n  include glance::api\n  include glance\n}\n\n and another profile above that responsible for when to include that profile eg \n\nclass profile::pacemaker::glance::api { \n  if (step \u003e 3) {\n    include profile::glance::api\n  } \n}\n\nThis lets you use the base profiles without the orchestration system at all which can be useful for quick testing and non-ha single node deployments (like replacing packstack), and also lets you swap out the orchestration system.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":3153,"name":"Emilien Macchi","email":"emilien@redhat.com","username":"emilienm"},"change_message_id":"b00cd90e2db0fa0397d430e0363f0769253435c3","unresolved":false,"context_lines":[{"line_number":256,"context_line":" * Create a heat nested stack template that uses the new puppet-tripleo"},{"line_number":257,"context_line":"   manifest to configure/enable the service."},{"line_number":258,"context_line":""},{"line_number":259,"context_line":" * docker integration"},{"line_number":260,"context_line":""},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dae33548_12df116a","line":259,"updated":"2016-02-16 17:34:20.000000000","message":"we might want to explain a bit more this.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"b256d84756f49212a437ae89adaa4ad94150d4fc","unresolved":false,"context_lines":[{"line_number":263,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":264,"context_line":""},{"line_number":265,"context_line":" * We should have the upgrades job in place to ensure we don\u0027t break"},{"line_number":266,"context_line":"   the ability to heat stack-update from a previous stack."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Testing"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a8ffd7b_f8ee8a20","line":266,"updated":"2015-11-30 13:22:53.000000000","message":"+1 on this as a dependency. I guess this change mainly concerns SoftwareConfig/SoftwareDeployment resources, so hopefully the potential of updates breakage is somewhat lower than when touching e.g. networks, but it\u0027s a big restructuring nevertheless.","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"},{"author":{"_account_id":3153,"name":"Emilien Macchi","email":"emilien@redhat.com","username":"emilienm"},"change_message_id":"b00cd90e2db0fa0397d430e0363f0769253435c3","unresolved":false,"context_lines":[{"line_number":263,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":264,"context_line":""},{"line_number":265,"context_line":" * We should have the upgrades job in place to ensure we don\u0027t break"},{"line_number":266,"context_line":"   the ability to heat stack-update from a previous stack."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Testing"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dae33548_72d49d46","line":266,"in_reply_to":"9a8ffd7b_f8ee8a20","updated":"2016-02-16 17:34:20.000000000","message":"big +1 (really big big)","commit_id":"6ff658329fa0effd6610b09ec6c6c79532af2044"}]}