Update notes for 3.14.0 GA #3728
Conversation
github-actions
bot
added
Needs tech review
|
The PR preview for 4bc4d3a is available at theforeman-foreman-documentation-preview-pr-3728.surge.sh The following output files are affected by this PR: |
|
@ekohl can you review/tag anyone else you think might be useful to get feedback from :) |
There was a problem hiding this comment.
I started to review theforeman/theforeman.org#2221, but the same notes apply. I should have started the review here.
@Lennonka I'd appreciate if you take a look as well
pr-processor
bot
added
Waiting on contributor
Lenna is on PTO. From my side, the SecureBoot note looks good. |
pr-processor
bot
added
Needs re-review
and removed
Waiting on contributor
| Deployment and operation in IPv6-only networks is now fully supported. | ||
|
|
||
| Provisioning over IPv6 is supported on bare metal hosts. | ||
| For compute resources, you can define the machine outside Satellite on the compute resource and then you can provision the machine as bare metal in Satellite. |
There was a problem hiding this comment.
| For compute resources, you can define the machine outside Satellite on the compute resource and then you can provision the machine as bare metal in Satellite. | |
| For compute resources, you can define the machine outside Foreman on the compute resource and then you can provision the machine as bare metal in Foreman. |
|
|
||
| === Secure Boot provisioning | ||
|
|
||
| Support for Secure Boot provisioning on bare-metal, VMware vSphere and Libvirt across multiple operating systems. |
There was a problem hiding this comment.
@nofaralfasi is this a good addition? I want to also imply that VMs will be created with Secure Boot enabled.
| Support for Secure Boot provisioning on bare-metal, VMware vSphere and Libvirt across multiple operating systems. | |
| Provisioning with Secure Boot is now supported on bare-metal, VMware vSphere and Libvirt across multiple operating systems. | |
| New virtual machines will be created with the default keys enrolled. |
There was a problem hiding this comment.
I don't quite follow. Are you referring to all new VMs being created with the default keys enrolled (which isn't the case)? Or are you talking specifically about new VMs with Secure Boot enabled? If it's the latter, why is it important to mention that here? Isn't that implicit?
There was a problem hiding this comment.
I think it's important to mention that you can also create new VMs with Secure Boot enabled. To me provisioning doesn't always imply creation of VMs. Perhaps then
| Support for Secure Boot provisioning on bare-metal, VMware vSphere and Libvirt across multiple operating systems. | |
| Provisioning with Secure Boot is now supported on bare-metal, VMware vSphere and Libvirt across multiple operating systems. | |
| New virtual machines with Secure Boot enabled will be created with the default keys enrolled. |
|
|
||
| === Invalidate JWT for global registration | ||
|
|
||
| This will give users the ability to edit user permissions and invalidate JWT tokens for other users, invalidate self's token, and admins can invalidate selfs and other user tokens |
There was a problem hiding this comment.
In release notes you are talking to the user, not about the user. When you write "This will give users" you're talking in the future tense, but the change has already landed so it should be written in the present tense.
The exact phrasing can probably be best reviewed by a writer, but how about:
| This will give users the ability to edit user permissions and invalidate JWT tokens for other users, invalidate self's token, and admins can invalidate selfs and other user tokens | |
| Users can now invalidate their own tokens for global registration. | |
| Users with the `edit_users` permission can also invalidate all tokens for all users in a single action. |
| This will give users the ability to edit user permissions and invalidate JWT tokens for otherers can now invalidate their own tokens for global registration. | ||
| Users with the `edit_users` permission can also invalidate all tokens for all users in a single action.users, invalidate self's token, and admins can invalidate selfs and other user tokens |
There was a problem hiding this comment.
I'm not sure what happened to this sentence my suggestion, but this doesn't read well to me.
The first sentence is also just wrong in saying that it gives users the ability to edit user permissions. It doesn't. Users that have the edit_users permission can now invalidate tokens for other users. In my suggestion I tried to split it up into 2 clear cases: something that's true for all users and something that's true for users with a specific permission.
Also, I've never seen self's before and it really confuses me. I'm not a native speaker, but if I look at https://www.merriam-webster.com/dictionary/self I see no definition that fits. Shouldn't there be a possessive pronoun in this context?
|
@ekohl I might have missed your original suggestion. please check again |
There was a problem hiding this comment.
I went over all the issues and moved them to the correct categories, please update this again.
ColeHiggins2
force-pushed
the
3.14-ga-notes
branch
from
41ebbb9 to
4bc4d3a
Compare
Adding Headline Features for 3.14.0 Release notes