[pve-devel] is the next pve version 8.0 with debian 12 ? (any planning on patches merge ?)

[pve-devel] is the next pve version 8.0 with debian 12 ? (any planning on patches merge ?)

[DERUMIER, Alexandre]

Hi,
I would like to known if the next pve version will be 8.0 on debian12 ?

and if they are any planning for patches merging ? (I would like to
schedule time on my agenda if my patches need to be rework).


We had discussed about it last year, but I would like to implement
permissions on vmbrX && sdn vnets, as it a breaking change.
https://git.proxmox.com/?p=pve-manager.git;a=commit;h=a37ff602ff742403f01d6682bf9948183f87eadb

  

Also, I have a bunch of patches waiting for review or merge. (sorry for
the flood ^_^)

Here the list to be sure that they will not be lost.


[pve-devel] [PATCH v4 qemu-server 00/16] rework memory hotplug +
virtiomem
https://lists.proxmox.com/pipermail/pve-devel/2023-February/055746.html
(waiting for HA to support the new memory format)

[pve-devel] [PATCH pve-manager 0/2] ui: add support for new memory
format
https://lists.proxmox.com/pipermail/pve-devel/2023-February/055834.html



[pve-devel] bump default kvm64 cpumodel to a new x86-64-v2 model ?
https://lists.proxmox.com/pipermail/pve-devel/2023-March/056014.html
(Not a patch yes, just a question, but maybe it could be great to bump
the default cpu model for proxmox 8 ?)



https://lists.proxmox.com/pipermail/pve-devel/2023-March/056107.html
[pve-devel] [PATCH qemu-server 0/6] improve virtio drive multiqueues
(I need to rework this, as it seem buggy when you have a lot of disk,
but add support for virtio disk, and expose the queues option in the
gui should be enough. This is mainly usefull to improve local nvme
speed)


https://lists.proxmox.com/pipermail/pve-devel/2023-March/056366.html
[pve-devel] [PATCH-SERIES qemu, qemu-server, manager 0/1] add tcmalloc
support
(could be really great for ceph users. I'm running it in production
since 2 months without problem)


https://lists.proxmox.com/pipermail/pve-devel/2023-March/056425.html
[pve-devel] [PATCH-SERIES pve-access-control/pve-manager] Add firewall
caps
(I really need this for a customer with audit access only)




some other network fixes:

https://lists.proxmox.com/pipermail/pve-devel/2023-April/056533.html
[pve-devel] [PATCH pve-container] fix #4457: use bridge mtu if no mtu
is defined

https://lists.proxmox.com/pipermail/pve-devel/2023-April/056557.html
[pve-devel] [PATCH frr] fix #4040 : patch : ospf6d: fix infinite loop
when adding ASBR route

https://lists.proxmox.com/pipermail/pve-devel/2023-April/056619.html
[pve-devel] [PATCH pve-network 0/6] sdn multiples fixes

Re: [pve-devel] is the next pve version 8.0 with debian 12 ? (any planning on patches merge ?)

[Thomas Lamprecht]

Am 28/04/2023 um 09:15 schrieb DERUMIER, Alexandre:
> I would like to known if the next pve version will be 8.0 on debian12 ?

yes.

> and if they are any planning for patches merging ? (I would like to
> schedule time on my agenda if my patches need to be rework).

Debian Bookworkm release is planned for June 10th, we have no hard
planned timeline to make public, but if I would need to guess from
top of my mind I'd say a beta a bit before that and a release a bit
after that, where "bit" here means roughly one to two weeks.

And we probably won't accept bigger breaking change after the beta
is made public. So, continuing the strong guess of mine, I'd say
if you get anything bigger submitted before ~ mid-may, we got still
some time for patches rework until ~ end of may.

> 
> 
> We had discussed about it last year, but I would like to implement
> permissions on vmbrX && sdn vnets, as it a breaking change.
> https://git.proxmox.com/?p=pve-manager.git;a=commit;h=a37ff602ff742403f01d6682bf9948183f87eadb
> 

yes, here the questions is more if we want to map in below some more
general resource-mapping ACL path as slightly/peripherally hinted in
a reply[0] to Dominik's HW mapping series. Or if we want to keep netdevs
in the /sdn path, which might be fine too as network devices is a big
and important enough class to be kept all in their own "access category"

[0]: https://lists.proxmox.com/pipermail/pve-devel/2022-November/054557.html

Fabian has some more spelled out questions/ideas IIRC.

>   
> 
> Also, I have a bunch of patches waiting for review or merge. (sorry for
> the flood ^_^)
> 

I'll probably jump start the final bootstrapping (we did some internal
ones already) soon, afterwards we can apply more stuff (would like to only
do bug fixes in 7.x from now on).

- Thomas

Re: [pve-devel] is the next pve version 8.0 with debian 12 ? (any planning on patches merge ?)

[Fabian Grünbichler]

On April 28, 2023 11:33 am, Thomas Lamprecht wrote:
> Am 28/04/2023 um 09:15 schrieb DERUMIER, Alexandre:
>> We had discussed about it last year, but I would like to implement
>> permissions on vmbrX && sdn vnets, as it a breaking change.
>> https://git.proxmox.com/?p=pve-manager.git;a=commit;h=a37ff602ff742403f01d6682bf9948183f87eadb
>> 
> 
> yes, here the questions is more if we want to map in below some more
> general resource-mapping ACL path as slightly/peripherally hinted in
> a reply[0] to Dominik's HW mapping series. Or if we want to keep netdevs
> in the /sdn path, which might be fine too as network devices is a big
> and important enough class to be kept all in their own "access category"
> 
> [0]: https://lists.proxmox.com/pipermail/pve-devel/2022-November/054557.html
> 
> Fabian has some more spelled out questions/ideas IIRC.

not so much spelled out, but yeah, this came up recently again because
of a forum question :)

I would really like to have the ability to restrict access to bridges
and bridge-like entities from SDN in 8.0. right now it's only possible
to limit the configuration itself, but not the "usage". for SDN there is
a cosmetic filter in place, but that is only cosmetic, as long as a
user/token has VM.Config.Network they can use *any* bridge or *any*
vnet via the API.

these are the basic parts I've thought of:

1.) decide on the ACLs/privs for regular bridges

- ACL path and privileges shared with SDN
- OR: ACL path and privileges shared with other per-node hardware
  entities, like those used for pass-through

the former is probably more easy, since it means we don't need special
helpers or complicated code when checking access in places where either
a regular bridge or SDN is used.. the advantage of the map would be that
we'd have a single mechanism for defining and giving access to per-node
resources. so not really clear cut (yet)

- which privilege levels do we need?
- See (Audit), Use, Configure (Admin)?

2.) implement access control checks in all the places

- mostly guest-related: create/restore/update/remote-migrate/clone
- firewall (rules referencing bridges/vnets? maybe it doesn't matter,
  since if I can change the host firewall I can already mess stuff up,
  and for the guest firewall I can probably use whatever I want?)
- SDN (e.g., to configure a zone to use a certain bridge?)
- node network config (switch from Sys.Modify to SDN.Admin?)

once the decision on the privileges has been made, we need to backport
any new privileges to the last 7.x version, so that admins can setup the
new ACLs before (partially!) upgrading their clusters, and also to avoid
breaking not-yet-updated nodes when ACLs are modified on already
upgraded ones.

Re: [pve-devel] is the next pve version 8.0 with debian 12 ? (any planning on patches merge ?)

[DERUMIER, Alexandre]

> 
> not so much spelled out, but yeah, this came up recently again
> because
> of a forum question :)
> 
> I would really like to have the ability to restrict access to bridges
> and bridge-like entities from SDN in 8.0. right now it's only
> possible
> to limit the configuration itself, but not the "usage". for SDN there
> is
> a cosmetic filter in place, but that is only cosmetic, as long as a
> user/token has VM.Config.Network they can use *any* bridge or *any*
> vnet via the API.
Oh yes, you are right, I totally miss that.


> 
> these are the basic parts I've thought of:
> 
> 1.) decide on the ACLs/privs for regular bridges
> 
> - ACL path and privileges shared with SDN
> - OR: ACL path and privileges shared with other per-node hardware
>   entities, like those used for pass-through
> 
> the former is probably more easy, since it means we don't need
> special
> helpers or complicated code when checking access in places where
> either
> a regular bridge or SDN is used.. the advantage of the map would be
> that
> we'd have a single mechanism for defining and giving access to per-
> node
> resources. so not really clear cut (yet)
> 

Personnaly, I think this should be strange to give access to a bridge
on a specific node only.
(Same vmbr name should be same physical network..so if user have access
on the vmbr on a node, you can flood traffic to all nodes where the
vmbr is present).
Also if HA migrate the vm, and user don't have access the vmbr on other
node, that's really stange.


> - which privilege levels do we need?
> - See (Audit), Use, Configure (Admin)?
> 
I think:

- "Use" permission  on vmbr, on vnet, or a whole zone (all vnets)
- "Admin" on a specific zone. (Be able to create/modify vnets  +
(reload sdn????)
- "Admin" on a node to configure local vmbr
- "Audit" for read config on a specific zone


Another thing is vlan tag on vm nic. I really don't known how to handle
permissions. (with sdn, it's 1vnet=1tag).
But it could great to be able to restrict vlans list too.


> 2.) implement access control checks in all the places
> 
> - mostly guest-related: create/restore/update/remote-migrate/clone
> - firewall (rules referencing bridges/vnets? maybe it doesn't matter,
>   since if I can change the host firewall I can already mess stuff
> up,
>   and for the guest firewall I can probably use whatever I want?)
> - SDN (e.g., to configure a zone to use a certain bridge?)
> - node network config (switch from Sys.Modify to SDN.Admin?)
> 
> once the decision on the privileges has been made, we need to
> backport
> any new privileges to the last 7.x version, so that admins can setup
> the
> new ACLs before (partially!) upgrading their clusters, and also to
> avoid
> breaking not-yet-updated nodes when ACLs are modified on already
> upgraded ones.
> 

Re: [pve-devel] is the next pve version 8.0 with debian 12 ? (any planning on patches merge ?)

[DERUMIER, Alexandre]

Le vendredi 28 avril 2023 à 11:33 +0200, Thomas Lamprecht a écrit :
> And we probably won't accept bigger breaking change after the beta
> is made public. So, continuing the strong guess of mine, I'd say
> if you get anything bigger submitted before ~ mid-may, we got still
> some time for patches rework until ~ end of may.

Ok thanks! 

I don't have nothing big in my pipe. 

(I only have a patch series for ifupdown2 for ipv6 slaac support, I'm
waiting for ifupdown2 dev review before submiting it to pve-devel)
https://github.com/CumulusNetworks/ifupdown2/pull/259

I'm going on holiday tomorrow for 2 weeks, so Mid-may --> end may,
no problem, I should have time to rebase/rework my previous patches if
needed. (or help to implement network permissions)


for proxmox8, I'll also look to bump frr && ifupdown2 to last versions.


Alexandre