)]}'
{"specs/liberty/independent-role-repositories.rst":[{"author":{"_account_id":13997,"name":"SHIGEMATSU Mitsuhiro","email":"shigematsu.mitsuhiro@lab.ntt.co.jp","username":"pshige"},"change_message_id":"2ae6e96bfaa4cac55d576396e08d3c13896dab4f","unresolved":false,"context_lines":[{"line_number":7,"context_line":"produced by openstack-ansible in different reference use-case"},{"line_number":8,"context_line":"deployments and allow independent development of each role by"},{"line_number":9,"context_line":"different projects, this specification proposes that each role be"},{"line_number":10,"context_line":"broken out of the current monolithic repository into seperate"},{"line_number":11,"context_line":"repositories named ``openstack/openstack-ansible-\u003crole\u003e``."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"* https://blueprints.launchpad.net/openstack-ansible/+spec/independent-role-repositories"}],"source_content_type":"text/x-rst","patch_set":1,"id":"da20952f_2b05d60f","line":10,"updated":"2015-09-05 04:52:44.000000000","message":"s/seperate/separate/","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":12000,"name":"Ian Cordasco","email":"sigmavirus24@gmail.com","username":"sigmavirus24"},"change_message_id":"a2b49f42631ffe59db838241fb30eeaef3b793e0","unresolved":false,"context_lines":[{"line_number":21,"context_line":""},{"line_number":22,"context_line":"* The roles will be more easily consumed in different reference"},{"line_number":23,"context_line":"  architectures. Currently the playbooks and roles are specifically"},{"line_number":24,"context_line":"  geared for deployment in LXC containers. Making the roles"},{"line_number":25,"context_line":"  independant entities will allow them to be consumed for completely"},{"line_number":26,"context_line":"  different architectures. eg: a deployment without containers,"},{"line_number":27,"context_line":"  a deployment with VM\u0027s instead of containers, a deployment with"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_d12278b9","line":24,"updated":"2015-08-17 17:10:51.000000000","message":"So this is the default, but am I mistaken in thinking that anything can be toggled with the `is_metal` flag so that it\u0027s not in a container? If so, I don\u0027t see how making this a separate repository makes this any better.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"9a9fa0d92cd6e26f1da465c99d5bf9600b8522e5","unresolved":false,"context_lines":[{"line_number":21,"context_line":""},{"line_number":22,"context_line":"* The roles will be more easily consumed in different reference"},{"line_number":23,"context_line":"  architectures. Currently the playbooks and roles are specifically"},{"line_number":24,"context_line":"  geared for deployment in LXC containers. Making the roles"},{"line_number":25,"context_line":"  independant entities will allow them to be consumed for completely"},{"line_number":26,"context_line":"  different architectures. eg: a deployment without containers,"},{"line_number":27,"context_line":"  a deployment with VM\u0027s instead of containers, a deployment with"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_276ef9c9","line":24,"in_reply_to":"fa1b9901_d12278b9","updated":"2015-08-18 06:43:06.000000000","message":"Making the roles separate repositories loosens the tight coupling, makes it easier to enforce the role\u0027s independence from the architecture and makes it more obvious that the role can be consumed independently of the architecture. Please see the problem description.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":13997,"name":"SHIGEMATSU Mitsuhiro","email":"shigematsu.mitsuhiro@lab.ntt.co.jp","username":"pshige"},"change_message_id":"2ae6e96bfaa4cac55d576396e08d3c13896dab4f","unresolved":false,"context_lines":[{"line_number":22,"context_line":"* The roles will be more easily consumed in different reference"},{"line_number":23,"context_line":"  architectures. Currently the playbooks and roles are specifically"},{"line_number":24,"context_line":"  geared for deployment in LXC containers. Making the roles"},{"line_number":25,"context_line":"  independant entities will allow them to be consumed for completely"},{"line_number":26,"context_line":"  different architectures. eg: a deployment without containers,"},{"line_number":27,"context_line":"  a deployment with VM\u0027s instead of containers, a deployment with"},{"line_number":28,"context_line":"  a different container technology"}],"source_content_type":"text/x-rst","patch_set":1,"id":"da20952f_cb053a10","line":25,"updated":"2015-09-05 04:52:44.000000000","message":"s/independant/independent/","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":13997,"name":"SHIGEMATSU Mitsuhiro","email":"shigematsu.mitsuhiro@lab.ntt.co.jp","username":"pshige"},"change_message_id":"2ae6e96bfaa4cac55d576396e08d3c13896dab4f","unresolved":false,"context_lines":[{"line_number":27,"context_line":"  a deployment with VM\u0027s instead of containers, a deployment with"},{"line_number":28,"context_line":"  a different container technology"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"* Each role can have its own independant core teams, providing the"},{"line_number":31,"context_line":"  opportunity for subject matter experts (SME\u0027s) to safeguard the"},{"line_number":32,"context_line":"  core functionality provided by the role from an educated"},{"line_number":33,"context_line":"  standpoint."}],"source_content_type":"text/x-rst","patch_set":1,"id":"da20952f_eb0a7e1f","line":30,"updated":"2015-09-05 04:52:44.000000000","message":"s/independant/independent/","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":12000,"name":"Ian Cordasco","email":"sigmavirus24@gmail.com","username":"sigmavirus24"},"change_message_id":"a2b49f42631ffe59db838241fb30eeaef3b793e0","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  a different container technology"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"* Each role can have its own independant core teams, providing the"},{"line_number":31,"context_line":"  opportunity for subject matter experts (SME\u0027s) to safeguard the"},{"line_number":32,"context_line":"  core functionality provided by the role from an educated"},{"line_number":33,"context_line":"  standpoint."},{"line_number":34,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_7c48235c","line":31,"updated":"2015-08-17 17:10:51.000000000","message":"So how will common roles necessary for these \"independent\" core teams be managed? Also, how will these \"independent\" core teams be aware of each other\u0027s work/progress? Will we have \"independent\" meetings for each role? If we have \"independent\" core teams, it\u0027ll be harder to synchronize with each other in a single meeting. Having \"independent\" core teams also means that we\u0027ll lose our focus on using wheels and pip, correct? Will we have separate specs repos for each role? There\u0027s a lot here that you\u0027re ignoring","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"ab5d8a9d5c17bd1f4bd70b2aa40972989fe73d32","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  a different container technology"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"* Each role can have its own independant core teams, providing the"},{"line_number":31,"context_line":"  opportunity for subject matter experts (SME\u0027s) to safeguard the"},{"line_number":32,"context_line":"  core functionality provided by the role from an educated"},{"line_number":33,"context_line":"  standpoint."},{"line_number":34,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_9f1b74ca","line":31,"in_reply_to":"fa1b9901_095ad283","updated":"2015-08-24 15:11:17.000000000","message":"Initially the openstack-ansible core team would be core members of all roles and would need to maintain the consistency. We may have to set some standard styles for roles in order to reduce the dependency on that core team and allow the role core teams to self govern. The integrated tests for releases would then act as a catch-all for issues that arise due to changes in the roles.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"cdefba4713aad7b399ee9719034428071ed3d735","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  a different container technology"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"* Each role can have its own independant core teams, providing the"},{"line_number":31,"context_line":"  opportunity for subject matter experts (SME\u0027s) to safeguard the"},{"line_number":32,"context_line":"  core functionality provided by the role from an educated"},{"line_number":33,"context_line":"  standpoint."},{"line_number":34,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_095ad283","line":31,"in_reply_to":"fa1b9901_67d07154","updated":"2015-08-24 14:59:36.000000000","message":"I take it we will have some sort of \"osad liaison\" in order to maintain consistency between the projects?","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"9a9fa0d92cd6e26f1da465c99d5bf9600b8522e5","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  a different container technology"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"* Each role can have its own independant core teams, providing the"},{"line_number":31,"context_line":"  opportunity for subject matter experts (SME\u0027s) to safeguard the"},{"line_number":32,"context_line":"  core functionality provided by the role from an educated"},{"line_number":33,"context_line":"  standpoint."},{"line_number":34,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_67d07154","line":31,"in_reply_to":"fa1b9901_7c48235c","updated":"2015-08-18 06:43:06.000000000","message":"All roles will share a common PTL, a common community meeting, a common specs repository and will work together. Think of this like the keystone libraries versus keystone core - all this does is enables us to have independent core groups for the other repositories. It doesn\u0027t, however, mandate that there are different core groups. Also, openstack-ansible\u0027s mission is to deploy OpenStack from source - so the focus on wheels and pip does not get lost.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":12000,"name":"Ian Cordasco","email":"sigmavirus24@gmail.com","username":"sigmavirus24"},"change_message_id":"a2b49f42631ffe59db838241fb30eeaef3b793e0","unresolved":false,"context_lines":[{"line_number":40,"context_line":"  specific and relevant to the role. This will provide quicker"},{"line_number":41,"context_line":"  developer feedback and allow a quicker turnaround for development."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"* The roles can be registered in Ansible Galaxy. This will provide"},{"line_number":44,"context_line":"  greater awareness of the roles and may attract more contributors."},{"line_number":45,"context_line":"  This is especially useful for the infrastructure roles."},{"line_number":46,"context_line":"  (eg: haproxy, MariaDB, etc)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_bcac7bee","line":43,"updated":"2015-08-17 17:10:51.000000000","message":"Is there no flexibility such that they can be registered in the way they are now? That seems like a fundamental flaw in Ansible Galaxy rather than a reason to split the roles out","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"9a9fa0d92cd6e26f1da465c99d5bf9600b8522e5","unresolved":false,"context_lines":[{"line_number":40,"context_line":"  specific and relevant to the role. This will provide quicker"},{"line_number":41,"context_line":"  developer feedback and allow a quicker turnaround for development."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"* The roles can be registered in Ansible Galaxy. This will provide"},{"line_number":44,"context_line":"  greater awareness of the roles and may attract more contributors."},{"line_number":45,"context_line":"  This is especially useful for the infrastructure roles."},{"line_number":46,"context_line":"  (eg: haproxy, MariaDB, etc)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_c7005dad","line":43,"in_reply_to":"fa1b9901_bcac7bee","updated":"2015-08-18 06:43:06.000000000","message":"This is a benefit - one of many. Ansible Galaxy is a catalogue of roles. The ansible-galaxy tool grabs the latest tag for the role from the registered repository for the role, unless otherwise specified. It can also point directly at a git repository if the role is not registered in galaxy. Ansible\u0027s best practises implement the roles as a defined, generic unit which is consumed by playbooks. The playbooks define the architecture and the specifics of the environment - implementing independent repositories for roles and testing them independently helps to enforce that good practise.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":12000,"name":"Ian Cordasco","email":"sigmavirus24@gmail.com","username":"sigmavirus24"},"change_message_id":"a2b49f42631ffe59db838241fb30eeaef3b793e0","unresolved":false,"context_lines":[{"line_number":45,"context_line":"  This is especially useful for the infrastructure roles."},{"line_number":46,"context_line":"  (eg: haproxy, MariaDB, etc)"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"* Role seperation will improve code discipline. For the role to be"},{"line_number":49,"context_line":"  usable as an independent unit without knowledge of the playbooks"},{"line_number":50,"context_line":"  consuming it we will be forced to ensure that any variables we"},{"line_number":51,"context_line":"  consume in the role are defined and used properly."}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_bc931ba3","line":48,"updated":"2015-08-17 17:10:51.000000000","message":"It will also \"improve\" a variety of differing approaches to solving the same problem (e.g., distributing keys via memcached instead of a common role).","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":13997,"name":"SHIGEMATSU Mitsuhiro","email":"shigematsu.mitsuhiro@lab.ntt.co.jp","username":"pshige"},"change_message_id":"2ae6e96bfaa4cac55d576396e08d3c13896dab4f","unresolved":false,"context_lines":[{"line_number":45,"context_line":"  This is especially useful for the infrastructure roles."},{"line_number":46,"context_line":"  (eg: haproxy, MariaDB, etc)"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"* Role seperation will improve code discipline. For the role to be"},{"line_number":49,"context_line":"  usable as an independent unit without knowledge of the playbooks"},{"line_number":50,"context_line":"  consuming it we will be forced to ensure that any variables we"},{"line_number":51,"context_line":"  consume in the role are defined and used properly."}],"source_content_type":"text/x-rst","patch_set":1,"id":"da20952f_0b5fb2e5","line":48,"updated":"2015-09-05 04:52:44.000000000","message":"s/seperation/separation/","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"cdefba4713aad7b399ee9719034428071ed3d735","unresolved":false,"context_lines":[{"line_number":45,"context_line":"  This is especially useful for the infrastructure roles."},{"line_number":46,"context_line":"  (eg: haproxy, MariaDB, etc)"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"* Role seperation will improve code discipline. For the role to be"},{"line_number":49,"context_line":"  usable as an independent unit without knowledge of the playbooks"},{"line_number":50,"context_line":"  consuming it we will be forced to ensure that any variables we"},{"line_number":51,"context_line":"  consume in the role are defined and used properly."}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_293eb6da","line":48,"in_reply_to":"fa1b9901_071e550c","updated":"2015-08-24 14:59:36.000000000","message":"The current design of OSAD has some conventions to it (like breaking installation into pre, install, post, etc...). Will the independent roles have these same conventions?","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"ab5d8a9d5c17bd1f4bd70b2aa40972989fe73d32","unresolved":false,"context_lines":[{"line_number":45,"context_line":"  This is especially useful for the infrastructure roles."},{"line_number":46,"context_line":"  (eg: haproxy, MariaDB, etc)"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"* Role seperation will improve code discipline. For the role to be"},{"line_number":49,"context_line":"  usable as an independent unit without knowledge of the playbooks"},{"line_number":50,"context_line":"  consuming it we will be forced to ensure that any variables we"},{"line_number":51,"context_line":"  consume in the role are defined and used properly."}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_ffe710aa","line":48,"in_reply_to":"fa1b9901_293eb6da","updated":"2015-08-24 15:11:17.000000000","message":"At this stage the answer is \u0027not sure\u0027 - these conventions don\u0027t currently have any particular functional purpose, but that may change.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"9a9fa0d92cd6e26f1da465c99d5bf9600b8522e5","unresolved":false,"context_lines":[{"line_number":45,"context_line":"  This is especially useful for the infrastructure roles."},{"line_number":46,"context_line":"  (eg: haproxy, MariaDB, etc)"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"* Role seperation will improve code discipline. For the role to be"},{"line_number":49,"context_line":"  usable as an independent unit without knowledge of the playbooks"},{"line_number":50,"context_line":"  consuming it we will be forced to ensure that any variables we"},{"line_number":51,"context_line":"  consume in the role are defined and used properly."}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_071e550c","line":48,"in_reply_to":"fa1b9901_bc931ba3","updated":"2015-08-18 06:43:06.000000000","message":"I\u0027m not sure I understand what you\u0027re saying here?","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":13997,"name":"SHIGEMATSU Mitsuhiro","email":"shigematsu.mitsuhiro@lab.ntt.co.jp","username":"pshige"},"change_message_id":"2ae6e96bfaa4cac55d576396e08d3c13896dab4f","unresolved":false,"context_lines":[{"line_number":50,"context_line":"  consuming it we will be forced to ensure that any variables we"},{"line_number":51,"context_line":"  consume in the role are defined and used properly."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"* Role seperation will simplify the mission of openstack-ansible\u0027s"},{"line_number":54,"context_line":"  playbooks and scripts to be for the purpose of providing examples"},{"line_number":55,"context_line":"  of how to consume the roles and to implement gate testing for"},{"line_number":56,"context_line":"  integrated deployment verification of the use-cases that matter"}],"source_content_type":"text/x-rst","patch_set":1,"id":"da20952f_2b64f6b6","line":53,"updated":"2015-09-05 04:52:44.000000000","message":"s/seperation/separation/","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"cdefba4713aad7b399ee9719034428071ed3d735","unresolved":false,"context_lines":[{"line_number":73,"context_line":"  workarounds for the tight coupling that we have. Even when it is"},{"line_number":74,"context_line":"  possible to do, it is hard for a deployer to see how to do it due"},{"line_number":75,"context_line":"  to the deluge of variables that need to be set and code that needs"},{"line_number":76,"context_line":"  to be read."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"* There has been some interest in creating roles for other services"},{"line_number":79,"context_line":"  (eg: rally, congress, etc). Implementing the strategy of a repo"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_ac8bb467","line":76,"updated":"2015-08-24 14:59:36.000000000","message":"these variables need to be read, but they might not need to be used depending on the role being run.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":13997,"name":"SHIGEMATSU Mitsuhiro","email":"shigematsu.mitsuhiro@lab.ntt.co.jp","username":"pshige"},"change_message_id":"2ae6e96bfaa4cac55d576396e08d3c13896dab4f","unresolved":false,"context_lines":[{"line_number":87,"context_line":"* The infrastructure roles implemented as part of the project are not"},{"line_number":88,"context_line":"  getting much attention as they are more like a second-class citizen"},{"line_number":89,"context_line":"  within the role structure. This results in the configurations"},{"line_number":90,"context_line":"  deployed often not lining up to best-practises."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"* Any small changes to roles require the execution of a full"},{"line_number":93,"context_line":"  integration gate test which is slow and prone to error. It is"}],"source_content_type":"text/x-rst","patch_set":1,"id":"da20952f_ab700673","line":90,"updated":"2015-09-05 04:52:44.000000000","message":"s/practises/practices/","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":12892,"name":"Nolan Brubaker","email":"nolan.brubaker@rackspace.com","username":"nrb"},"change_message_id":"4f06ed63fed0d449ef8e2400416ee2d0088e1d64","unresolved":false,"context_lines":[{"line_number":97,"context_line":"Proposed change"},{"line_number":98,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"The following process should be followed:"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"#. For each role targeted for breaking out, a seperate blueprint must"},{"line_number":103,"context_line":"   be registered and a spec provided for the high level changes that"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_71adac87","line":100,"updated":"2015-08-17 16:55:44.000000000","message":"Each role\u0027s separation will also need to be evaluated for dependence on how openstack-ansible/OSAD does inventory right now, which is somewhat different from most other inventory libraries.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"9a9fa0d92cd6e26f1da465c99d5bf9600b8522e5","unresolved":false,"context_lines":[{"line_number":97,"context_line":"Proposed change"},{"line_number":98,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"The following process should be followed:"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"#. For each role targeted for breaking out, a seperate blueprint must"},{"line_number":103,"context_line":"   be registered and a spec provided for the high level changes that"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_27dd9942","line":100,"in_reply_to":"fa1b9901_71adac87","updated":"2015-08-18 06:43:06.000000000","message":"A role\u0027s dependence on the inventory is bad practice. The use of the inventory should be confined to the playbooks. But I agree - each role will need to be reviewed on a case-by-case basis and this can be done when preparing the spec for that role\u0027s transition.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":13997,"name":"SHIGEMATSU Mitsuhiro","email":"shigematsu.mitsuhiro@lab.ntt.co.jp","username":"pshige"},"change_message_id":"2ae6e96bfaa4cac55d576396e08d3c13896dab4f","unresolved":false,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"The following process should be followed:"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"#. For each role targeted for breaking out, a seperate blueprint must"},{"line_number":103,"context_line":"   be registered and a spec provided for the high level changes that"},{"line_number":104,"context_line":"   would be required in the current os-ansible-deployment playbooks"},{"line_number":105,"context_line":"   and roles to accommodate this change."}],"source_content_type":"text/x-rst","patch_set":1,"id":"da20952f_6b666ebc","line":102,"updated":"2015-09-05 04:52:44.000000000","message":"s/seperate/separate/","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":12000,"name":"Ian Cordasco","email":"sigmavirus24@gmail.com","username":"sigmavirus24"},"change_message_id":"a2b49f42631ffe59db838241fb30eeaef3b793e0","unresolved":false,"context_lines":[{"line_number":108,"context_line":"   repository should be registered upstream."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"#. Once the new repository has been created, extract the role from"},{"line_number":111,"context_line":"   the master branch with its history and push it into the new"},{"line_number":112,"context_line":"   repository."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"#. Implement a submodule in the os-ansible-deployment repository in"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_7ce4a33a","line":111,"updated":"2015-08-17 17:10:51.000000000","message":"\"with its history\" will be difficult. This isn\u0027t SVN. Is it worth preserving the history at this point?","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"9a9fa0d92cd6e26f1da465c99d5bf9600b8522e5","unresolved":false,"context_lines":[{"line_number":108,"context_line":"   repository should be registered upstream."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"#. Once the new repository has been created, extract the role from"},{"line_number":111,"context_line":"   the master branch with its history and push it into the new"},{"line_number":112,"context_line":"   repository."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"#. Implement a submodule in the os-ansible-deployment repository in"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_07e5f507","line":111,"in_reply_to":"fa1b9901_7ce4a33a","updated":"2015-08-18 06:43:06.000000000","message":"Perhaps, and perhaps not. This is up for debate. It seems possible: http://ariya.ofilabs.com/2014/07/extracting-parts-of-git-repository-and-keeping-the-history.html","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":12000,"name":"Ian Cordasco","email":"sigmavirus24@gmail.com","username":"sigmavirus24"},"change_message_id":"a2b49f42631ffe59db838241fb30eeaef3b793e0","unresolved":false,"context_lines":[{"line_number":123,"context_line":"   role for usage in the integrated use-cases, tag the initial"},{"line_number":124,"context_line":"   version of the role and implement the os-ansible-deployment"},{"line_number":125,"context_line":"   playbook, script and submodule SHA changes to consume the new"},{"line_number":126,"context_line":"   role."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"#. Finally, switch from using the submodule to using ansible-galaxy"},{"line_number":129,"context_line":"   to import the role. Once this is verified to be working"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_3c3ceb92","line":126,"updated":"2015-08-17 17:10:51.000000000","message":"Will each role be gated against os-ansible-deployment? It should be to ensure it plays well with others. Think of this as a devstack integration test in the big tent.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"9a9fa0d92cd6e26f1da465c99d5bf9600b8522e5","unresolved":false,"context_lines":[{"line_number":123,"context_line":"   role for usage in the integrated use-cases, tag the initial"},{"line_number":124,"context_line":"   version of the role and implement the os-ansible-deployment"},{"line_number":125,"context_line":"   playbook, script and submodule SHA changes to consume the new"},{"line_number":126,"context_line":"   role."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"#. Finally, switch from using the submodule to using ansible-galaxy"},{"line_number":129,"context_line":"   to import the role. Once this is verified to be working"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_27ab598b","line":126,"in_reply_to":"fa1b9901_3c3ceb92","updated":"2015-08-18 06:43:06.000000000","message":"We\u0027ll have to figure out the details when we try this with the first role, but my thinking is that the integration (ie full build and tempest) tests should be done using the use-cases/architectures defined in os-ansible-deployment whenever os-ansible-deployment wishes to do a revision. In other words, this won\u0027t be on every role\u0027s commit but instead be something like an on-demand check or an on-commit check in the os-ansible-deployment repo.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":12892,"name":"Nolan Brubaker","email":"nolan.brubaker@rackspace.com","username":"nrb"},"change_message_id":"4f06ed63fed0d449ef8e2400416ee2d0088e1d64","unresolved":false,"context_lines":[{"line_number":154,"context_line":"Upgrade impact"},{"line_number":155,"context_line":"--------------"},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"As this will be done in master, the upgrade impact will have to be"},{"line_number":158,"context_line":"determined and resolved in a specific spec which will probably have"},{"line_number":159,"context_line":"to be prepared later in the cycle."},{"line_number":160,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_f1b3fc08","line":157,"updated":"2015-08-17 16:55:44.000000000","message":"I disagree; upgrades should be addressed as part of moving a role. They aren\u0027t a completely separate concern.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"9a9fa0d92cd6e26f1da465c99d5bf9600b8522e5","unresolved":false,"context_lines":[{"line_number":154,"context_line":"Upgrade impact"},{"line_number":155,"context_line":"--------------"},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"As this will be done in master, the upgrade impact will have to be"},{"line_number":158,"context_line":"determined and resolved in a specific spec which will probably have"},{"line_number":159,"context_line":"to be prepared later in the cycle."},{"line_number":160,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_678f1124","line":157,"in_reply_to":"fa1b9901_3c638bb3","updated":"2015-08-18 06:43:06.000000000","message":"That is why this spec is targeted for during the (upstream) M cycle. Upgrades for Liberty need to be addressed in the specific blueprint for kilo to liberty upgrades. The upgrades for L to M need to be similarly worked on during the M cycle, but in its own blueprint. It can\u0027t be worked on exactly in parallel with the role conversion as there may be quite a bit of flux. My suggestion is that each role\u0027s upgrade path be determined once the changes have settled.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":12000,"name":"Ian Cordasco","email":"sigmavirus24@gmail.com","username":"sigmavirus24"},"change_message_id":"a2b49f42631ffe59db838241fb30eeaef3b793e0","unresolved":false,"context_lines":[{"line_number":154,"context_line":"Upgrade impact"},{"line_number":155,"context_line":"--------------"},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"As this will be done in master, the upgrade impact will have to be"},{"line_number":158,"context_line":"determined and resolved in a specific spec which will probably have"},{"line_number":159,"context_line":"to be prepared later in the cycle."},{"line_number":160,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_3c638bb3","line":157,"in_reply_to":"fa1b9901_f1b3fc08","updated":"2015-08-17 17:10:51.000000000","message":"I agree with Nolan. We have to figure upgrades out now. I doubt we\u0027ll get around to figuring them out later if we punt this close to the release of Liberty.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":12892,"name":"Nolan Brubaker","email":"nolan.brubaker@rackspace.com","username":"nrb"},"change_message_id":"4f06ed63fed0d449ef8e2400416ee2d0088e1d64","unresolved":false,"context_lines":[{"line_number":195,"context_line":""},{"line_number":196,"context_line":"The biggest negative developer impact will be the difficulty working"},{"line_number":197,"context_line":"between the two different structures - master being split, with"},{"line_number":198,"context_line":"liberty and kilo being consolidated. It may be worth considering"},{"line_number":199,"context_line":"ways to make them all work the same way once the conversions are"},{"line_number":200,"context_line":"done for master."},{"line_number":201,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_31a174aa","line":198,"updated":"2015-08-17 16:55:44.000000000","message":"According to this wording, master wouldn\u0027t change until a liberty branch is created in openstack-ansible. Is that intended? Is this work for M?","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"9a9fa0d92cd6e26f1da465c99d5bf9600b8522e5","unresolved":false,"context_lines":[{"line_number":195,"context_line":""},{"line_number":196,"context_line":"The biggest negative developer impact will be the difficulty working"},{"line_number":197,"context_line":"between the two different structures - master being split, with"},{"line_number":198,"context_line":"liberty and kilo being consolidated. It may be worth considering"},{"line_number":199,"context_line":"ways to make them all work the same way once the conversions are"},{"line_number":200,"context_line":"done for master."},{"line_number":201,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_8794a537","line":198,"in_reply_to":"fa1b9901_31a174aa","updated":"2015-08-18 06:43:06.000000000","message":"Yes. I don\u0027t see how we have time to do this in the (upstream) L cycle.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"cdefba4713aad7b399ee9719034428071ed3d735","unresolved":false,"context_lines":[{"line_number":249,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"While the placement of the role files on the deployment host will be"},{"line_number":252,"context_line":"different, the configuration and execution of the deployment should"},{"line_number":253,"context_line":"remain the same, resulting in minimal documentation impact."},{"line_number":254,"context_line":""},{"line_number":255,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_2c86c4db","line":252,"updated":"2015-08-24 14:59:36.000000000","message":"based on other comments, this will require more documentation around deploying a role with a static inventory, versus the current dynamic inventory.\n\nit might also be helpful to have documentation that strings together roles, which would be nice for the fledgling projects.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"ab5d8a9d5c17bd1f4bd70b2aa40972989fe73d32","unresolved":false,"context_lines":[{"line_number":249,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"While the placement of the role files on the deployment host will be"},{"line_number":252,"context_line":"different, the configuration and execution of the deployment should"},{"line_number":253,"context_line":"remain the same, resulting in minimal documentation impact."},{"line_number":254,"context_line":""},{"line_number":255,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa1b9901_9f7cd4b6","line":252,"in_reply_to":"fa1b9901_2c86c4db","updated":"2015-08-24 15:11:17.000000000","message":"Agreed - good input, thanks.","commit_id":"96be6a10dd414fb3bd122836807da2e84d83a431"}],"specs/mitaka/independent-role-repositories.rst":[{"author":{"_account_id":7353,"name":"Kevin Carter","email":"kevin@cloudnull.com","username":"cloudnull"},"change_message_id":"378f8d4d474eebfe7aabdeb22940dba5473c080f","unresolved":false,"context_lines":[{"line_number":27,"context_line":"  a deployment with VM\u0027s instead of containers, a deployment with"},{"line_number":28,"context_line":"  a different container technology"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"* Each role can have its own independent core teams, providing the"},{"line_number":31,"context_line":"  opportunity for subject matter experts (SME\u0027s) to safeguard the"},{"line_number":32,"context_line":"  core functionality provided by the role from an educated"},{"line_number":33,"context_line":"  standpoint."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_c38835c9","line":30,"updated":"2015-09-09 18:42:53.000000000","message":"I think this item may be speculating too far forward and should be cut from the spec. How teams will be formed, if ever, around the \"big tenting\" of the roles is something that we can work on in the future should it be necessary.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"3be6224780f6b52c8ec9ac70a1d47da4691e7f64","unresolved":false,"context_lines":[{"line_number":27,"context_line":"  a deployment with VM\u0027s instead of containers, a deployment with"},{"line_number":28,"context_line":"  a different container technology"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"* Each role can have its own independent core teams, providing the"},{"line_number":31,"context_line":"  opportunity for subject matter experts (SME\u0027s) to safeguard the"},{"line_number":32,"context_line":"  core functionality provided by the role from an educated"},{"line_number":33,"context_line":"  standpoint."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_c82ee08b","line":30,"in_reply_to":"da20952f_c38835c9","updated":"2015-09-10 19:56:51.000000000","message":"Done","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":7353,"name":"Kevin Carter","email":"kevin@cloudnull.com","username":"cloudnull"},"change_message_id":"378f8d4d474eebfe7aabdeb22940dba5473c080f","unresolved":false,"context_lines":[{"line_number":45,"context_line":"  This is especially useful for the infrastructure roles."},{"line_number":46,"context_line":"  (eg: haproxy, MariaDB, etc)"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"* Role separation will improve code discipline. For the role to be"},{"line_number":49,"context_line":"  usable as an independent unit without knowledge of the playbooks"},{"line_number":50,"context_line":"  consuming it we will be forced to ensure that any variables we"},{"line_number":51,"context_line":"  consume in the role are defined and used properly."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_1e08c427","line":48,"updated":"2015-09-09 18:42:53.000000000","message":"I\u0027m not sure that this is something that we need to spell out for this spec. I think we should define, within the main repo, what code standards we adhere to better enforce our code discipline however I think that needs to be done regardless of the move to independent roles. We have a bit of the style and code standards within our CONTRIBUTING.rst file [0] however as discussed today in IRC it may be wise to have a style guide that\u0027s independent of that one document.\n\n[0] - https://github.com/stackforge/os-ansible-deployment/blob/master/CONTRIBUTING.rst#style-guide\n\nI think this point could be refined or otherwise removed.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"3be6224780f6b52c8ec9ac70a1d47da4691e7f64","unresolved":false,"context_lines":[{"line_number":45,"context_line":"  This is especially useful for the infrastructure roles."},{"line_number":46,"context_line":"  (eg: haproxy, MariaDB, etc)"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"* Role separation will improve code discipline. For the role to be"},{"line_number":49,"context_line":"  usable as an independent unit without knowledge of the playbooks"},{"line_number":50,"context_line":"  consuming it we will be forced to ensure that any variables we"},{"line_number":51,"context_line":"  consume in the role are defined and used properly."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_c8b3404c","line":48,"in_reply_to":"da20952f_1e08c427","updated":"2015-09-10 19:56:51.000000000","message":"Done","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":7217,"name":"Hugh Saunders","email":"hugh@wherenow.org","username":"hughsaunders"},"change_message_id":"e2cc32aa2ae91a9d1106930e60fea4b7a3694097","unresolved":false,"context_lines":[{"line_number":66,"context_line":"* Currently the openstack-ansible roles are tightly coupled with the"},{"line_number":67,"context_line":"  playbooks that consume them. While the roles can technically be"},{"line_number":68,"context_line":"  consumed using different playbooks, this is not immediately"},{"line_number":69,"context_line":"  obvious to downstream consumers."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"* When consumers to try to consume the roles with different playbooks"},{"line_number":72,"context_line":"  for a different architecture, they are forced to implement many"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_6f3fde87","line":69,"updated":"2015-09-09 11:43:53.000000000","message":"The current roles are also tightly coupled with the inventory, having group names hard coded into them. Would that also be fixed in this work?","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"7695e139ccf35551a6bed9fb753c884c5a40d8f4","unresolved":false,"context_lines":[{"line_number":66,"context_line":"* Currently the openstack-ansible roles are tightly coupled with the"},{"line_number":67,"context_line":"  playbooks that consume them. While the roles can technically be"},{"line_number":68,"context_line":"  consumed using different playbooks, this is not immediately"},{"line_number":69,"context_line":"  obvious to downstream consumers."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"* When consumers to try to consume the roles with different playbooks"},{"line_number":72,"context_line":"  for a different architecture, they are forced to implement many"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_8f01126d","line":69,"in_reply_to":"da20952f_6f3fde87","updated":"2015-09-09 11:49:47.000000000","message":"The specifics would be handled on a per role basis - each role split out would be done with its own blueprint and spec. We would, however, need to decide whether the use of groups within roles for scoping is something that we\u0027re ok with or not. This is part of the documentation this specific blueprint\u0027s work must output.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":7353,"name":"Kevin Carter","email":"kevin@cloudnull.com","username":"cloudnull"},"change_message_id":"378f8d4d474eebfe7aabdeb22940dba5473c080f","unresolved":false,"context_lines":[{"line_number":66,"context_line":"* Currently the openstack-ansible roles are tightly coupled with the"},{"line_number":67,"context_line":"  playbooks that consume them. While the roles can technically be"},{"line_number":68,"context_line":"  consumed using different playbooks, this is not immediately"},{"line_number":69,"context_line":"  obvious to downstream consumers."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"* When consumers to try to consume the roles with different playbooks"},{"line_number":72,"context_line":"  for a different architecture, they are forced to implement many"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_dec32c89","line":69,"in_reply_to":"da20952f_8f01126d","updated":"2015-09-09 18:42:53.000000000","message":"Agreed. While I don\u0027t find group_names in roles to be offensive I think the initial move is to take the role \"as-is\" and migrate it to the defined role repository. In the migration we create an improved readme.rst file, \"improved\" most roles already contain a readme.rst file, which contains the names of the groups and variables, should there be any, that are required to make the role work along with a simple code example on base use.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"3be6224780f6b52c8ec9ac70a1d47da4691e7f64","unresolved":false,"context_lines":[{"line_number":66,"context_line":"* Currently the openstack-ansible roles are tightly coupled with the"},{"line_number":67,"context_line":"  playbooks that consume them. While the roles can technically be"},{"line_number":68,"context_line":"  consumed using different playbooks, this is not immediately"},{"line_number":69,"context_line":"  obvious to downstream consumers."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"* When consumers to try to consume the roles with different playbooks"},{"line_number":72,"context_line":"  for a different architecture, they are forced to implement many"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_287bdc7c","line":69,"in_reply_to":"da20952f_dec32c89","updated":"2015-09-10 19:56:51.000000000","message":"Agreed.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":7217,"name":"Hugh Saunders","email":"hugh@wherenow.org","username":"hughsaunders"},"change_message_id":"e2cc32aa2ae91a9d1106930e60fea4b7a3694097","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":"* Any small changes to roles require the execution of a full"},{"line_number":93,"context_line":"  integration gate test which is slow and prone to error. It is"},{"line_number":94,"context_line":"  difficult to isolate the error in the current monolithic stack."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_4fc0da7c","line":94,"updated":"2015-09-09 11:43:53.000000000","message":"I don\u0027t think running a full integration test is a bad thing. We could run specific tests as well to help isolate failures, but integration tests are very good at catching unforeseen side effects.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"7695e139ccf35551a6bed9fb753c884c5a40d8f4","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":"* Any small changes to roles require the execution of a full"},{"line_number":93,"context_line":"  integration gate test which is slow and prone to error. It is"},{"line_number":94,"context_line":"  difficult to isolate the error in the current monolithic stack."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_af1096ac","line":94,"in_reply_to":"da20952f_4fc0da7c","updated":"2015-09-09 11:49:47.000000000","message":"Agreed, but integration tests are only valid where integration is required - thus I propose that integration tests are run whenever a role is tagged for the purpose of deciding whether that tag is suitable for inclusion in a revised integrated deployment of openstack-ansible.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"3be6224780f6b52c8ec9ac70a1d47da4691e7f64","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":"* Any small changes to roles require the execution of a full"},{"line_number":93,"context_line":"  integration gate test which is slow and prone to error. It is"},{"line_number":94,"context_line":"  difficult to isolate the error in the current monolithic stack."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_28f2fc06","line":94,"in_reply_to":"da20952f_9e54d4ca","updated":"2015-09-10 19:56:51.000000000","message":"Agreed.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":7353,"name":"Kevin Carter","email":"kevin@cloudnull.com","username":"cloudnull"},"change_message_id":"378f8d4d474eebfe7aabdeb22940dba5473c080f","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":"* Any small changes to roles require the execution of a full"},{"line_number":93,"context_line":"  integration gate test which is slow and prone to error. It is"},{"line_number":94,"context_line":"  difficult to isolate the error in the current monolithic stack."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_9e54d4ca","line":94,"in_reply_to":"da20952f_af1096ac","updated":"2015-09-09 18:42:53.000000000","message":"+1 I think OSAD (main repo) keeps its integration tests while the independent roles do focused testing.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":7353,"name":"Kevin Carter","email":"kevin@cloudnull.com","username":"cloudnull"},"change_message_id":"378f8d4d474eebfe7aabdeb22940dba5473c080f","unresolved":false,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"The following documentation should be developed:"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"#. What the project considers to be Ansible Best Practises, and where"},{"line_number":103,"context_line":"   the project intentionally deviates from them (if any) and why."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"#. The primary use-cases/implementations tested by the project."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_befd18b3","line":102,"updated":"2015-09-09 18:42:53.000000000","message":"I don\u0027t think this should be covered by this spec or a dependent one however I do believe this is something that should be done as on its own.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"3be6224780f6b52c8ec9ac70a1d47da4691e7f64","unresolved":false,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"The following documentation should be developed:"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"#. What the project considers to be Ansible Best Practises, and where"},{"line_number":103,"context_line":"   the project intentionally deviates from them (if any) and why."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"#. The primary use-cases/implementations tested by the project."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_68a0f4a5","line":102,"in_reply_to":"da20952f_befd18b3","updated":"2015-09-10 19:56:51.000000000","message":"Agreed, I\u0027ve removed this line item.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":7353,"name":"Kevin Carter","email":"kevin@cloudnull.com","username":"cloudnull"},"change_message_id":"378f8d4d474eebfe7aabdeb22940dba5473c080f","unresolved":false,"context_lines":[{"line_number":110,"context_line":""},{"line_number":111,"context_line":"#. First steps for building a new role."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"#. How to work with the static inventory vs dynamic inventory."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"#. A base set of standards expected from a role in the project."},{"line_number":116,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_fe1ab017","line":113,"updated":"2015-09-09 18:42:53.000000000","message":"In the readme of the various roles I think we should provide an inventory example covering the required group_names and variables. Simply extending the role readme documentation should cover all available Ansible inventories.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"3be6224780f6b52c8ec9ac70a1d47da4691e7f64","unresolved":false,"context_lines":[{"line_number":110,"context_line":""},{"line_number":111,"context_line":"#. First steps for building a new role."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"#. How to work with the static inventory vs dynamic inventory."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"#. A base set of standards expected from a role in the project."},{"line_number":116,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_a8c7ec62","line":113,"in_reply_to":"da20952f_fe1ab017","updated":"2015-09-10 19:56:51.000000000","message":"I\u0027ve adjusted the sentence to describe this.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":7353,"name":"Kevin Carter","email":"kevin@cloudnull.com","username":"cloudnull"},"change_message_id":"378f8d4d474eebfe7aabdeb22940dba5473c080f","unresolved":false,"context_lines":[{"line_number":112,"context_line":""},{"line_number":113,"context_line":"#. How to work with the static inventory vs dynamic inventory."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"#. A base set of standards expected from a role in the project."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"#. Each role must have documentation developed for it that describes"},{"line_number":118,"context_line":"   how to consume it on its own, what options are available for its use,"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_be1438e9","line":115,"updated":"2015-09-09 18:42:53.000000000","message":"vague.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"3be6224780f6b52c8ec9ac70a1d47da4691e7f64","unresolved":false,"context_lines":[{"line_number":112,"context_line":""},{"line_number":113,"context_line":"#. How to work with the static inventory vs dynamic inventory."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"#. A base set of standards expected from a role in the project."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"#. Each role must have documentation developed for it that describes"},{"line_number":118,"context_line":"   how to consume it on its own, what options are available for its use,"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_e87ba427","line":115,"in_reply_to":"da20952f_be1438e9","updated":"2015-09-10 19:56:51.000000000","message":"I\u0027ve removed this as it is pretty much the same as the best practices line item.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":7353,"name":"Kevin Carter","email":"kevin@cloudnull.com","username":"cloudnull"},"change_message_id":"378f8d4d474eebfe7aabdeb22940dba5473c080f","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":"#. A base set of standards expected from a role in the project."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"#. Each role must have documentation developed for it that describes"},{"line_number":118,"context_line":"   how to consume it on its own, what options are available for its use,"},{"line_number":119,"context_line":"   whether it relies on any other roles, how upgrades are handled, any"},{"line_number":120,"context_line":"   known issues, etc."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_1eb3e40b","line":117,"updated":"2015-09-09 18:42:53.000000000","message":"Standard role documentation should be the readme.rst file which exists in most roles already. We\u0027ll simply need to update those files as the roles are migrated to the external repos.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"3be6224780f6b52c8ec9ac70a1d47da4691e7f64","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":"#. A base set of standards expected from a role in the project."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"#. Each role must have documentation developed for it that describes"},{"line_number":118,"context_line":"   how to consume it on its own, what options are available for its use,"},{"line_number":119,"context_line":"   whether it relies on any other roles, how upgrades are handled, any"},{"line_number":120,"context_line":"   known issues, etc."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_08ccd85f","line":117,"in_reply_to":"da20952f_1eb3e40b","updated":"2015-09-10 19:56:51.000000000","message":"Agreed - I\u0027ve consolidated that into the previous README line item.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":7353,"name":"Kevin Carter","email":"kevin@cloudnull.com","username":"cloudnull"},"change_message_id":"378f8d4d474eebfe7aabdeb22940dba5473c080f","unresolved":false,"context_lines":[{"line_number":142,"context_line":"   would be required in the current openstack-ansible playbooks and"},{"line_number":143,"context_line":"   roles to accommodate this change."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"#. Once the spec is approved, the review to register the new"},{"line_number":146,"context_line":"   repository should be registered upstream."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"#. Once the new repository has been created, extract the role from"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_3ead889b","line":145,"updated":"2015-09-09 18:42:53.000000000","message":"I think the process to get a new repo added into the project should be on the sitting PTL to do and not the reviewer.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"3be6224780f6b52c8ec9ac70a1d47da4691e7f64","unresolved":false,"context_lines":[{"line_number":142,"context_line":"   would be required in the current openstack-ansible playbooks and"},{"line_number":143,"context_line":"   roles to accommodate this change."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"#. Once the spec is approved, the review to register the new"},{"line_number":146,"context_line":"   repository should be registered upstream."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"#. Once the new repository has been created, extract the role from"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_e86c0438","line":145,"in_reply_to":"da20952f_3ead889b","updated":"2015-09-10 19:56:51.000000000","message":"Agreed - I\u0027ve adjusted the sentence to be more specific.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":7353,"name":"Kevin Carter","email":"kevin@cloudnull.com","username":"cloudnull"},"change_message_id":"378f8d4d474eebfe7aabdeb22940dba5473c080f","unresolved":false,"context_lines":[{"line_number":163,"context_line":"   changes to consume the new role. The changes in openstack-ansible will"},{"line_number":164,"context_line":"   need to pass the integrated gate checks before they can merge."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"#. Finally, switch from using the submodule to using ansible-galaxy"},{"line_number":167,"context_line":"   to import the role. Once this is verified to be working"},{"line_number":168,"context_line":"   successfully, remove the submodule."},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_5e8e3c28","line":166,"updated":"2015-09-09 18:42:53.000000000","message":"I don\u0027t think we need to or should do the submoduling for anything that is Ansible galaxy compatible. When the role is moved to the external repo we should update our role-requirements.yml file with the data required to make it go using our scripts.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"3be6224780f6b52c8ec9ac70a1d47da4691e7f64","unresolved":false,"context_lines":[{"line_number":163,"context_line":"   changes to consume the new role. The changes in openstack-ansible will"},{"line_number":164,"context_line":"   need to pass the integrated gate checks before they can merge."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"#. Finally, switch from using the submodule to using ansible-galaxy"},{"line_number":167,"context_line":"   to import the role. Once this is verified to be working"},{"line_number":168,"context_line":"   successfully, remove the submodule."},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_68ed548d","line":166,"in_reply_to":"da20952f_5e8e3c28","updated":"2015-09-10 19:56:51.000000000","message":"The use of a submodule is simply a protective measure to ensure that other development going on is not disrupted too badly. It also protects any downstream consumers who\u0027re already using role-requirements for other things and gives them time to adjust.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":7353,"name":"Kevin Carter","email":"kevin@cloudnull.com","username":"cloudnull"},"change_message_id":"378f8d4d474eebfe7aabdeb22940dba5473c080f","unresolved":false,"context_lines":[{"line_number":183,"context_line":""},{"line_number":184,"context_line":"Each role will have to:"},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"* carry any modules/filters that it consumes that are not available"},{"line_number":187,"context_line":"  in the upstream ansible repositories. This can be simplified by"},{"line_number":188,"context_line":"  putting the modules/filters into a common repository which can be"},{"line_number":189,"context_line":"  consumed by all roles."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_3ed348d7","line":186,"updated":"2015-09-09 18:42:53.000000000","message":"I think that our current libraries, filters, and plugins will need to be in it\u0027s own repo which can be pulled into OSAD using a submodule; submodule because libraries are not galaxy compatible to the best of my knowledge. If a role has a requirement for anyone of these items it should be noted within the readme.rst file that the role requires access to our shared library and provide a snippet on how to get the required bits. In this way we wont have to carry, update, or mess with actual code that\u0027s in multiple places and may adversely effect other roles or work in unexpected ways when being used by a deployer.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"3be6224780f6b52c8ec9ac70a1d47da4691e7f64","unresolved":false,"context_lines":[{"line_number":183,"context_line":""},{"line_number":184,"context_line":"Each role will have to:"},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"* carry any modules/filters that it consumes that are not available"},{"line_number":187,"context_line":"  in the upstream ansible repositories. This can be simplified by"},{"line_number":188,"context_line":"  putting the modules/filters into a common repository which can be"},{"line_number":189,"context_line":"  consumed by all roles."}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_68179454","line":186,"in_reply_to":"da20952f_3ed348d7","updated":"2015-09-10 19:56:51.000000000","message":"Agreed - I\u0027ve updated this bit.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":7353,"name":"Kevin Carter","email":"kevin@cloudnull.com","username":"cloudnull"},"change_message_id":"378f8d4d474eebfe7aabdeb22940dba5473c080f","unresolved":false,"context_lines":[{"line_number":286,"context_line":"* pep8 tests for all python files"},{"line_number":287,"context_line":"* ansible syntax checks for all ansible task files"},{"line_number":288,"context_line":"* ansible-lint tests for all ansible task files"},{"line_number":289,"context_line":"* functional tests for the service"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Integration tests are expected to be implemented in the openstack-ansible"},{"line_number":292,"context_line":"repository and executed whenever the role versions are incremented. This"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_5e94fce6","line":289,"updated":"2015-09-09 18:42:53.000000000","message":"Initial I think this is the integration tests that we do in OSAD presently. In the future I think we add most focused testing on a per-role basis.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"3be6224780f6b52c8ec9ac70a1d47da4691e7f64","unresolved":false,"context_lines":[{"line_number":286,"context_line":"* pep8 tests for all python files"},{"line_number":287,"context_line":"* ansible syntax checks for all ansible task files"},{"line_number":288,"context_line":"* ansible-lint tests for all ansible task files"},{"line_number":289,"context_line":"* functional tests for the service"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Integration tests are expected to be implemented in the openstack-ansible"},{"line_number":292,"context_line":"repository and executed whenever the role versions are incremented. This"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da20952f_632577ac","line":289,"in_reply_to":"da20952f_5e94fce6","updated":"2015-09-10 19:56:51.000000000","message":"Agreed.","commit_id":"c28a1a36bb570bd1e1d7dc6f65145b476ac28ae1"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"6e1077281ac56de4885ae8ddc45a3b40e0988e95","unresolved":false,"context_lines":[{"line_number":124,"context_line":"#. For each role targeted for breaking out, a separate blueprint must be"},{"line_number":125,"context_line":"   registered and a spec provided for the high level changes that would be"},{"line_number":126,"context_line":"   required in the current openstack-ansible playbooks and roles to"},{"line_number":127,"context_line":"   accommodate this change."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"#. Once the spec is approved, the review to register the new"},{"line_number":130,"context_line":"   repository should be registered upstream."}],"source_content_type":"text/x-rst","patch_set":4,"id":"da20952f_df098f2c","line":127,"updated":"2015-09-11 17:14:47.000000000","message":"I am tempted to leave the rest of this section out and simply state the if any role currently in the repository needs to be broken out, it needs to be planned in a spec on a per role basis. This can allow the planning for how this should happen to be done based on the experience at the time.","commit_id":"bd77c3b8083f89afcdb9d21b7d5faef6ba6c9807"},{"author":{"_account_id":7217,"name":"Hugh Saunders","email":"hugh@wherenow.org","username":"hughsaunders"},"change_message_id":"0780d98f23fb50ad639ae3418821cf9078d4d6a7","unresolved":false,"context_lines":[{"line_number":138,"context_line":"   the work is done to implement the changes in the new role and the"},{"line_number":139,"context_line":"   openstack-ansible playbooks/scripts. Fix the submodule to the starting"},{"line_number":140,"context_line":"   SHA so that other work can continue while changes are implemented in"},{"line_number":141,"context_line":"   the role repository."},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"#. Once independent gate checks on the role repository confirm that it is"},{"line_number":144,"context_line":"   in working order and the work is done to prepare the role for usage in"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da20952f_ae94af35","line":141,"updated":"2015-09-11 16:37:56.000000000","message":"What happens if a bug needs to be fixed in the transition period? Would we then have two branches in the role repo - legacy and dev for example, and use head of legacy for the OSAD submodule pointer. Fixes in legacy would then need to be forward ported to dev. \n\nIn that situation, you have two branches in the role repo. Why not  leave the role in OSAD while the new version is being developed externally. Then fixes can still go into OSAD (and be forward ported to the external role) and theres only one transition (osad role --\u003e galaxy external role) rather than two (osad role --\u003e submod external --\u003e galaxy external )\n\nThe obvious counter argument is divergence, but scenario 1 is just as susceptible to divergence as scenario 2.","commit_id":"bd77c3b8083f89afcdb9d21b7d5faef6ba6c9807"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"078a7d822acd0f198027b166845b538dbb0a2c6e","unresolved":false,"context_lines":[{"line_number":138,"context_line":"   the work is done to implement the changes in the new role and the"},{"line_number":139,"context_line":"   openstack-ansible playbooks/scripts. Fix the submodule to the starting"},{"line_number":140,"context_line":"   SHA so that other work can continue while changes are implemented in"},{"line_number":141,"context_line":"   the role repository."},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"#. Once independent gate checks on the role repository confirm that it is"},{"line_number":144,"context_line":"   in working order and the work is done to prepare the role for usage in"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da20952f_142b6e83","line":141,"in_reply_to":"da20952f_ae94af35","updated":"2015-09-11 16:44:38.000000000","message":"Well, an alternative is to not do a submodule at all - simply switch from being in-repo to using the galaxy inclusion. As this only affects master branch development this is less of an issue. We could just agree that any n-1 branch bugs need to be fixed in that branch and forward ported where necessary.","commit_id":"bd77c3b8083f89afcdb9d21b7d5faef6ba6c9807"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"6e1077281ac56de4885ae8ddc45a3b40e0988e95","unresolved":false,"context_lines":[{"line_number":155,"context_line":"Alternatives"},{"line_number":156,"context_line":"------------"},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"Leave everything as it is."},{"line_number":159,"context_line":""},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"Playbook/Role impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da20952f_ff2573ad","line":158,"updated":"2015-09-11 17:14:47.000000000","message":"and continue to merge any new roles into the same monolithic repository","commit_id":"bd77c3b8083f89afcdb9d21b7d5faef6ba6c9807"},{"author":{"_account_id":7217,"name":"Hugh Saunders","email":"hugh@wherenow.org","username":"hughsaunders"},"change_message_id":"0780d98f23fb50ad639ae3418821cf9078d4d6a7","unresolved":false,"context_lines":[{"line_number":168,"context_line":"It is clear that the libraries, filters and plugins will need to be broken out"},{"line_number":169,"context_line":"into its own repository and each role that consumes them will need to use a"},{"line_number":170,"context_line":"submodule reference in the role. This ensures that all the roles use a common"},{"line_number":171,"context_line":"set of libraries, filters and plugins."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"Upgrade impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da20952f_595b5f22","line":171,"updated":"2015-09-11 16:37:56.000000000","message":"If a downstream consumer was submoduling osad, then in the transition period there would be 4 levels: consumer--\u003eOSAD--\u003eRole--\u003eLibs\n\nYo dawg, I heard you like submodules etc.","commit_id":"bd77c3b8083f89afcdb9d21b7d5faef6ba6c9807"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"078a7d822acd0f198027b166845b538dbb0a2c6e","unresolved":false,"context_lines":[{"line_number":168,"context_line":"It is clear that the libraries, filters and plugins will need to be broken out"},{"line_number":169,"context_line":"into its own repository and each role that consumes them will need to use a"},{"line_number":170,"context_line":"submodule reference in the role. This ensures that all the roles use a common"},{"line_number":171,"context_line":"set of libraries, filters and plugins."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"Upgrade impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da20952f_943e9eb6","line":171,"in_reply_to":"da20952f_595b5f22","updated":"2015-09-11 16:44:38.000000000","message":"I would expect that this would become less and less of a problem way further down the line once all the roles are broken out as people would perhaps simply fork the base repo with the playbooks in it or do their own playbooks. Do you have an alternative suggestion for handling this?","commit_id":"bd77c3b8083f89afcdb9d21b7d5faef6ba6c9807"},{"author":{"_account_id":7307,"name":"Matt Thompson","email":"mattt@defunct.ca","username":"mattt416"},"change_message_id":"4ed3fb4a3e7fab63eafa1e109adb2aeb0c87519a","unresolved":false,"context_lines":[{"line_number":58,"context_line":"  consumed using different playbooks, this is not immediately"},{"line_number":59,"context_line":"  obvious to downstream consumers."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"* When consumers to try to consume the roles with different playbooks"},{"line_number":62,"context_line":"  for a different architecture, they are forced to implement many"},{"line_number":63,"context_line":"  workarounds for the tight coupling that we have. Even when it is"},{"line_number":64,"context_line":"  possible to do, it is hard for a deployer to see how to do it due"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba15a1d1_fd20789d","line":61,"updated":"2015-09-15 09:36:22.000000000","message":"Nit: s/to //","commit_id":"57c9e7999e5a2b3e1f0e9be0a46be408d2ddce56"},{"author":{"_account_id":7219,"name":"git-harry","email":"git-harry@live.co.uk","username":"git-harry"},"change_message_id":"4e220f6c6f6147ac3bcf7e188e51ca3602c067b4","unresolved":false,"context_lines":[{"line_number":155,"context_line":"determined on a role by role basis. This must be described in the spec on a"},{"line_number":156,"context_line":"per role basis."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"It is clear that the libraries, filters and plugins will need to be broken out"},{"line_number":159,"context_line":"into its own repository and each role that consumes them will need to use a"},{"line_number":160,"context_line":"submodule reference in the role. This ensures that all the roles use a common"},{"line_number":161,"context_line":"set of libraries, filters and plugins."}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba15a1d1_d113515b","line":158,"updated":"2015-09-14 10:28:39.000000000","message":"This item seems like it is a pre-requisite for separating roles from the project yet it is not listed as a work item.","commit_id":"57c9e7999e5a2b3e1f0e9be0a46be408d2ddce56"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"dc6bc92fe2cca8b528a628db2d414f7990ee215d","unresolved":false,"context_lines":[{"line_number":155,"context_line":"determined on a role by role basis. This must be described in the spec on a"},{"line_number":156,"context_line":"per role basis."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"It is clear that the libraries, filters and plugins will need to be broken out"},{"line_number":159,"context_line":"into its own repository and each role that consumes them will need to use a"},{"line_number":160,"context_line":"submodule reference in the role. This ensures that all the roles use a common"},{"line_number":161,"context_line":"set of libraries, filters and plugins."}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba15a1d1_47dd4313","line":158,"in_reply_to":"ba15a1d1_d113515b","updated":"2015-09-14 10:47:10.000000000","message":"This will only need to be done if the current roles are split out, or if a new role requires them. This work item would then be listed in the spec for that new requirement, rather than being done for the sake of it before it\u0027s needed.","commit_id":"57c9e7999e5a2b3e1f0e9be0a46be408d2ddce56"},{"author":{"_account_id":7353,"name":"Kevin Carter","email":"kevin@cloudnull.com","username":"cloudnull"},"change_message_id":"b6c116235ef603f76abf0ff29c85917fcf0db4a5","unresolved":false,"context_lines":[{"line_number":157,"context_line":""},{"line_number":158,"context_line":"It is clear that the libraries, filters and plugins will need to be broken out"},{"line_number":159,"context_line":"into its own repository and each role that consumes them will need to use a"},{"line_number":160,"context_line":"submodule reference in the role. This ensures that all the roles use a common"},{"line_number":161,"context_line":"set of libraries, filters and plugins."},{"line_number":162,"context_line":""},{"line_number":163,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba15a1d1_fbf400d0","line":160,"updated":"2015-09-22 03:02:32.000000000","message":"We will need a submodule in the main repo to pull in the shared libs when a deployer moves to use OSA however i don\u0027t know if we need or want to submodule every role that requires the shared libs. I\u0027d rather see a simple blub indicating that a role must have access to the shared lib and some information on how to get them. That data could be as simple as how to add the libs to an existing ansible installation or how to use the libs locally  through the use of an ansible.cfg file.","commit_id":"57c9e7999e5a2b3e1f0e9be0a46be408d2ddce56"},{"author":{"_account_id":7219,"name":"git-harry","email":"git-harry@live.co.uk","username":"git-harry"},"change_message_id":"4e220f6c6f6147ac3bcf7e188e51ca3602c067b4","unresolved":false,"context_lines":[{"line_number":244,"context_line":""},{"line_number":245,"context_line":"See proposed change section."},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"Testing"},{"line_number":248,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":249,"context_line":""},{"line_number":250,"context_line":"The testing impact will need to be described on a per-role basis."}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba15a1d1_b1b6dd3b","line":247,"updated":"2015-09-14 10:28:39.000000000","message":"Has any thought been given to breaking out the common testing elements into a  separate repo to prevent having to maintain the scripts separately?","commit_id":"57c9e7999e5a2b3e1f0e9be0a46be408d2ddce56"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"dc6bc92fe2cca8b528a628db2d414f7990ee215d","unresolved":false,"context_lines":[{"line_number":244,"context_line":""},{"line_number":245,"context_line":"See proposed change section."},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"Testing"},{"line_number":248,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":249,"context_line":""},{"line_number":250,"context_line":"The testing impact will need to be described on a per-role basis."}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba15a1d1_07350b45","line":247,"in_reply_to":"ba15a1d1_b1b6dd3b","updated":"2015-09-14 10:47:10.000000000","message":"The thinking at this stage is that each repo will have its own tests focused on its own needs - these scripts will be different for each repo as the preparation and execution of the tests in each repo will have different elements. I would suggest that if there is enough commonality at a later stage then this could be done - but for now there\u0027s not enough known about what would be common. I would rather that each role can independently evolve in a simple manner to suit its own needs instead of trying to put together complex common scripts that cover every need.","commit_id":"57c9e7999e5a2b3e1f0e9be0a46be408d2ddce56"}]}