From 99c4459224ccc94d086b993695ceb401ab0fe9dc Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Thu, 11 Feb 2016 15:51:53 -0500 Subject: [PATCH 1/4] Initial checkin of new roadmap file. Currently encompasses 2.1 roadmap and some community objectives. --- ROADMAP.md | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 ROADMAP.md diff --git a/ROADMAP.md b/ROADMAP.md new file mode 100644 index 00000000000..51a16bd7b7d --- /dev/null +++ b/ROADMAP.md @@ -0,0 +1,98 @@ +Ansible Roadmap +============= +This document is now the location for published Ansible Core roadmaps. + +The roadmap will be updated by version. Based on team and community feedback an initial roadmap will be published for a major or minor version (2.0, 2.1) Subminor versions will generally not have roadmaps published. + +This is the first time we've published this and asked for feedback in exactly this manner. So feedback on the roadmap and the new process is quite welcome. We're aiming for further transparency and better inclusion of both community desires and submissions. + +These are our *best guess* roadmaps based on our own experience and based on requests and feedback from the community. There are things that may not make it on due to time constraints, lack of community maintainers, etc. And there may be things we missed, so each roadmap is both published as an idea of what's upcoming in Ansible, but also as a medium for seeking further feedback from the community. Here are the good places for you to submit feedback: + + * Our google-group ansible-devel + * Ansible Fest conferences. + * IRC: Our freenode channel #ansible (this one may have things lost in lots of conversation, so a caution). + +2.1 Roadmap +========== +## Windows, General +* Figuring out privilege escalation (runas w/ username/password) +* Implement kerberos encryption over http +* pywinrm conversion to requests (Some mess here on pywinrm/requests. will need docs etc.) +* NTLM support + +## Modules +* Windows + * Finish cleaning up tests and support for post-beta release. + * Strict mode cleanup (one module in core) + * Domain user/group management + * finish win\_host and win\_rm in the domain/workgroup modules. + * Close 2 existing PRs (These were deemed insufficient) + * Replicate python module API in PS/C# (deprecate hodgepodge of stuff from module_utils/powershell.ps1) +* Network + * Cisco modules (ios, iosxr, nxos, iosxe) + * Arista modules (eos) + * Juniper modules (junos) + * OpenSwitch + * Cumulus + * Dell (os10) - At risk + * Netconf shared module + * Hooks for supporting Tower credentials +* VMware (This one is a little at risk due to staffing. We're investigating some community maintainers and shifting some people at Ansible around, but it is a VERY high priority). + * vsphere\_guest brought to parity with other vmware modules (vs Viasat and 'whereismyjetpack' provided modules) + * VMware modules moved to official pyvmomi bindings + * VMware inventory script updates for pyvmomi, adding tagging support +* Azure (Notes: This is on hold until microsoft releases a working code generator. We have basic modules working against all of these resources. Could ship it against current SDK, but may break. Or should we pin the version?) + * Minimal Azure coverage using new ARM api + * Resource Group + * Virtual Network + * Subnet + * Public IP + * Network Interface + * Storage Account + * Security Group + * Virtual Machine + * Update of inventory script to use new API, adding tagging support +* Docker: + * Start Docker module refactor + * Update to match current docker CLI capabilities + * Docker exec support +* Upgrade other cloud modules or work with community maintainers to upgrade. (In order) + * AWS (Community maintainers) + * Openstack (Community maintainers) + * Google (Google/Community) + * Digital Ocean (Community) +* Ziploader: + * Write code to create the zipfile that gets passed across the wire to be run on the remote python. + * Port most of the functionality in module_utils to be usage in ziploader instead. + * Port a few essential modules to use ziploader instead of module-replacer as proof of concept. + * New modules will be able to use ziploader. Old modules will need to be ported in future releases (Some modules will not need porting but others will) + * Better testing of modules, caching of modules clientside(Have not yet arrived at an architecture for this that we like. Low priority), better code sharing between ansible/ansible and modules + * ziploader is a helpful building block for: python3 porting(high priority), better code sharing between modules(medium priority) + * ziploader is a good idea before: enabling users to have custom module_utils directories +* Expand module diff support (already in progress in devel) + * Framework done. Need to add to modules, test etc. + * Coordinate with community to update their modules. +* Things we are kicking down the road that we said we’d do + * NOT remerging core with ansible/ansible this release cycle. +* Community stuff + * Define the process/ETA for reviewing PR’s from community. + * Publish better docs and how-tos for submitting code/freatures/fixes. + + + + + + + + + + + + + + + + + + + From bab251233ab551f267f57245127c73322b0e47d7 Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Thu, 11 Feb 2016 15:57:05 -0500 Subject: [PATCH 2/4] add target date --- ROADMAP.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ROADMAP.md b/ROADMAP.md index 51a16bd7b7d..7efd97ce0be 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -12,7 +12,7 @@ These are our *best guess* roadmaps based on our own experience and based on req * Ansible Fest conferences. * IRC: Our freenode channel #ansible (this one may have things lost in lots of conversation, so a caution). -2.1 Roadmap +2.1 Roadmap, Targeted to End of April ========== ## Windows, General * Figuring out privilege escalation (runas w/ username/password) From 2d01d43e51b1cfb34883f8b302cd1e7048e062f4 Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Thu, 11 Feb 2016 18:42:12 -0500 Subject: [PATCH 3/4] just some more grammer, punctuation cleanup. --- ROADMAP.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index 7efd97ce0be..069fac207d6 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -2,17 +2,17 @@ Ansible Roadmap ============= This document is now the location for published Ansible Core roadmaps. -The roadmap will be updated by version. Based on team and community feedback an initial roadmap will be published for a major or minor version (2.0, 2.1) Subminor versions will generally not have roadmaps published. +The roadmap will be updated by version. Based on team and community feedback, an initial roadmap will be published for a major or minor version (2.0, 2.1). Subminor versions will generally not have roadmaps published. -This is the first time we've published this and asked for feedback in exactly this manner. So feedback on the roadmap and the new process is quite welcome. We're aiming for further transparency and better inclusion of both community desires and submissions. +This is the first time we've published this and asked for feedback in this manner. So feedback on the roadmap and the new process is quite welcome. We are aiming for further transparency and better inclusion of both community desires and submissions. -These are our *best guess* roadmaps based on our own experience and based on requests and feedback from the community. There are things that may not make it on due to time constraints, lack of community maintainers, etc. And there may be things we missed, so each roadmap is both published as an idea of what's upcoming in Ansible, but also as a medium for seeking further feedback from the community. Here are the good places for you to submit feedback: +These are our *best guess* roadmaps based on our own experience and based on requests and feedback from the community. There are things that may not make it on due to time constraints, lack of community maintainers, etc. And there may be things we missed, so each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community. Here are the good places for you to submit feedback: - * Our google-group ansible-devel + * Our google-group: ansible-devel * Ansible Fest conferences. * IRC: Our freenode channel #ansible (this one may have things lost in lots of conversation, so a caution). -2.1 Roadmap, Targeted to End of April +2.1 Roadmap, Targeted for the End of April ========== ## Windows, General * Figuring out privilege escalation (runas w/ username/password) @@ -22,11 +22,11 @@ These are our *best guess* roadmaps based on our own experience and based on req ## Modules * Windows - * Finish cleaning up tests and support for post-beta release. + * Finish cleaning up tests and support for post-beta release * Strict mode cleanup (one module in core) * Domain user/group management - * finish win\_host and win\_rm in the domain/workgroup modules. - * Close 2 existing PRs (These were deemed insufficient) + * Finish win\_host and win\_rm in the domain/workgroup modules. + * Close 2 existing PRs (These were deemed insufficient) * Replicate python module API in PS/C# (deprecate hodgepodge of stuff from module_utils/powershell.ps1) * Network * Cisco modules (ios, iosxr, nxos, iosxe) @@ -62,21 +62,21 @@ These are our *best guess* roadmaps based on our own experience and based on req * Google (Google/Community) * Digital Ocean (Community) * Ziploader: - * Write code to create the zipfile that gets passed across the wire to be run on the remote python. - * Port most of the functionality in module_utils to be usage in ziploader instead. - * Port a few essential modules to use ziploader instead of module-replacer as proof of concept. + * Write code to create the zipfile that gets passed across the wire to be run on the remote python + * Port most of the functionality in module\_utils to be usage in ziploader instead + * Port a few essential modules to use ziploader instead of module-replacer as proof of concept * New modules will be able to use ziploader. Old modules will need to be ported in future releases (Some modules will not need porting but others will) - * Better testing of modules, caching of modules clientside(Have not yet arrived at an architecture for this that we like. Low priority), better code sharing between ansible/ansible and modules + * Better testing of modules, caching of modules clientside(Have not yet arrived at an architecture for this that we like), better code sharing between ansible/ansible and modules * ziploader is a helpful building block for: python3 porting(high priority), better code sharing between modules(medium priority) * ziploader is a good idea before: enabling users to have custom module_utils directories * Expand module diff support (already in progress in devel) * Framework done. Need to add to modules, test etc. - * Coordinate with community to update their modules. + * Coordinate with community to update their modules * Things we are kicking down the road that we said we’d do - * NOT remerging core with ansible/ansible this release cycle. + * NOT remerging core with ansible/ansible this release cycle * Community stuff - * Define the process/ETA for reviewing PR’s from community. - * Publish better docs and how-tos for submitting code/freatures/fixes. + * Define the process/ETA for reviewing PR’s from community + * Publish better docs and how-tos for submitting code/freatures/fixes From 8e4ed34cbd72e78b67380b2f1e9d09610a73f9b9 Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Thu, 11 Feb 2016 20:56:33 -0500 Subject: [PATCH 4/4] series of changes based on PR comments --- ROADMAP.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index 069fac207d6..d4982369d45 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,16 +1,16 @@ -Ansible Roadmap +Roadmap For Ansible by RedHat ============= This document is now the location for published Ansible Core roadmaps. The roadmap will be updated by version. Based on team and community feedback, an initial roadmap will be published for a major or minor version (2.0, 2.1). Subminor versions will generally not have roadmaps published. -This is the first time we've published this and asked for feedback in this manner. So feedback on the roadmap and the new process is quite welcome. We are aiming for further transparency and better inclusion of both community desires and submissions. +This is the first time Ansible has published this and asked for feedback in this manner. So feedback on the roadmap and the new process is quite welcome. The team is aiming for further transparency and better inclusion of both community desires and submissions. -These are our *best guess* roadmaps based on our own experience and based on requests and feedback from the community. There are things that may not make it on due to time constraints, lack of community maintainers, etc. And there may be things we missed, so each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community. Here are the good places for you to submit feedback: +These roadmaps are the team's *best guess* roadmaps based on the Ansible team's experience and are also based on requests and feedback from the community. There are things that may not make it on due to time constraints, lack of community maintainers, etc. And there may be things that got missed, so each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community. Here are the good places for you to submit feedback: - * Our google-group: ansible-devel + * Ansible's google-group: ansible-devel * Ansible Fest conferences. - * IRC: Our freenode channel #ansible (this one may have things lost in lots of conversation, so a caution). + * IRC freenode channel: #ansible-devel (this one may have things lost in lots of conversation, so a caution). 2.1 Roadmap, Targeted for the End of April ========== @@ -41,7 +41,7 @@ These are our *best guess* roadmaps based on our own experience and based on req * vsphere\_guest brought to parity with other vmware modules (vs Viasat and 'whereismyjetpack' provided modules) * VMware modules moved to official pyvmomi bindings * VMware inventory script updates for pyvmomi, adding tagging support -* Azure (Notes: This is on hold until microsoft releases a working code generator. We have basic modules working against all of these resources. Could ship it against current SDK, but may break. Or should we pin the version?) +* Azure (Notes: This is on hold until Microsoft swaps out the code generator on the Azure Python SDK, which may introduce breaking changes. We have basic modules working against all of these resources at this time. Could ship it against current SDK, but may break. Or should the version be pinned?) * Minimal Azure coverage using new ARM api * Resource Group * Virtual Network @@ -72,11 +72,11 @@ These are our *best guess* roadmaps based on our own experience and based on req * Expand module diff support (already in progress in devel) * Framework done. Need to add to modules, test etc. * Coordinate with community to update their modules -* Things we are kicking down the road that we said we’d do +* Things being kicking down the road that we said we’d do * NOT remerging core with ansible/ansible this release cycle * Community stuff * Define the process/ETA for reviewing PR’s from community - * Publish better docs and how-tos for submitting code/freatures/fixes + * Publish better docs and how-tos for submitting code/features/fixes