[Vote ended on 2024-08-21] Ansible 11 roadmap

Project Discussions
, ,
1

I think we don’t have a roadmap for Ansible 11, so I’ve created a PR to suggest one.

5 Likes
2

Since I didn’t see any objections to my PR , let’s vote on merging it and have a roadmap for Ansible 11. The vote will end 2024-08-21.

Steering Committee vote
  • Accept / merge
  • Don’t accept / don’t merge
0 voters
Community vote
  • Accept / merge
  • Don’t accept / don’t merge
0 voters
1 Like
3

The vote ended and the suggested roadmap has been accepted with 7:0 votes from the SC and 1:0 votes from the community.

Thanks all for voting!

2 Likes
4

I see where Ansible 11 will track Ansible-core 2.18 and its planned work. Can someone recommend where one can read up on some of that planned work? I’m particularly intrigued by “Data Tagging”; pointers toward any details would be welcome.

I understand that in lots of tech dev, if you haven’t been “in the room” it’s hard to pick up from scratch; it’s likewise hard to bring others up to speed. It’s not like there’s a fly on the wall with a penchant for journalism who’s been recording it all as a gripping narrative. More’s the pity. So it may be that such docs simply don’t exist.

And people are busy. Perhaps I should scale back my request to a suggestion: that maybe each planned work bullet could be expanded to a paragraph or two to very briefly outline its scope, expected benefit, etc. As it is, those who are deeply involved already know, so the extra detail is of no use to them. And for those who aren’t, the terse list as it exists is marginally informative at best. One is left to wonder who’s the target audience for the ROADMAP’s planned work list.

Well, that came out less positively than intended. I do appreciate everyone’s efforts.

5

The github board for the 2.18 roadmap is here:

You can see what else we have planned for the release, but for “data tagging” the idea comes from the implementation of ANSIBLE_UNSAFE which was introduced in 2.0 to try and keep track of (not surprisingly) unsafe data sources so they don’t cause mischief in the templating engine. That has turned out to be an imperfect solution, leading to many games of “whack-a-mole” with bugs and other security problems over the years. Data tagging is an implementation that does several things to improve upon the idea of ANSIBLE_UNSAFE, but is essentially a very deep dive into many parts of the templating engine to maintain the chain of trust throughout templating. Ideally, once this is implemented internally, we hope to enable no_log functionality by default, as we would be able to track data that came from secure sources such as a vault file, and ensure the contents of those variables are never printed to the screen.

So that’s the 10,000 foot view of it :slight_smile:

1 Like
6

From a module’s author point of view, what you can (eventually?) do with data tagging:

  1. You can deprecate return values, so that if someone registers the output of your module and uses it, they will get a deprecation message. This wasn’t possible so far.
  2. You can mark a return value as secret (no_log). This in particular applies to values that have been passed into the module and are returned back; instead of replacing them with VALUE_SPECIFIED_IN_NO_LOG_PARAMETER or some other placeholder, it’s possible to return the real value with a no_log tag.

I’m not sure whether this can already be done with the first implementation, but especially the first one was a thing that got me interested in this topic a looong time ago.

2 Likes