Re: [pve-devel] [RFC manager 5/5] add certificates API endpoints

comments inline On 04/11/2018 10:08 AM, Fabian Grünbichler wrote: to allow retrieval of certificate information, and uploading or removing of custom certificate files. Signed-off-by: Fabian Grünbichler --- PVE/API2/Makefile| 1 +

Re: [pve-devel] [RFC manager 1/5] add CertHelpers utility

comment inline On 04/11/2018 10:08 AM, Fabian Grünbichler wrote: PVE-specific certificate helper functions Signed-off-by: Fabian Grünbichler --- PVE/Makefile | 1 + PVE/CertHelpers.pm | 104 + 2 files

Re: [pve-devel] fix #1961

Hi Wolfgang, I think we could do it to delete an HD too. (ceph can take time for big volumes for example) - Mail original - De: "Wolfgang Link" À: "pve-devel" Envoyé: Mardi 17 Avril 2018 14:39:04 Objet: [pve-devel] fix #1961 Use the

Re: [pve-devel] API - GET /nodes/{node}/storage

On Tue, Apr 17, 2018 at 02:47:01PM +0200, Andreas Steinel wrote: > On Tue, Apr 17, 2018 at 2:09 PM, Fabian Grünbichler > wrote: > > there are some places where we really don't know much more than "some > > object" (because the API call does a bit too much, and can

Re: [pve-devel] [Patch storage 2/2] fix #1691: increase timeout

On Tue, Apr 17, 2018 at 02:39:06PM +0200, Wolfgang Link wrote: > A ZFS storage under heavy load can take more time. > --- > PVE/Storage/ZFSPoolPlugin.pm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/PVE/Storage/ZFSPoolPlugin.pm b/PVE/Storage/ZFSPoolPlugin.pm > index

Re: [pve-devel] API - GET /nodes/{node}/storage

On Tue, Apr 17, 2018 at 2:09 PM, Fabian Grünbichler wrote: > there are some places where we really don't know much more than "some > object" (because the API call does a bit too much, and can return one > thing or another depending on the code path taken), but in many

[pve-devel] [Patch manager] fix #1691: use asynchronous API call for HD create

It should use an asynchronous API call to create an image, because some storages may need longer to alloc an image. If a storage needs more than 30 sec the proxy will timeout and we have an orphan image. Also, it is possible to increase the timeout for some storages if an asynchronous call is

[pve-devel] fix #1961

Use the async API call 'update_vm' to create a HD. This will encourage a worker and we can increase the time-out for ZFS at high load. ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] [Patch storage 2/2] fix #1691: increase timeout

A ZFS storage under heavy load can take more time. --- PVE/Storage/ZFSPoolPlugin.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/PVE/Storage/ZFSPoolPlugin.pm b/PVE/Storage/ZFSPoolPlugin.pm index 9680a94..b63fc27 100644 --- a/PVE/Storage/ZFSPoolPlugin.pm +++

[pve-devel] [Patch storage 1/2] fix #1691: replace udev check

`zfs create` add the creation job in a worker queue, which should normally execute instantly. But there are circumstances where the job will take a while to get processed. If this is the case udev settle will see no dev in the queue and the program will continue without an allocated dev. The busy

Re: [pve-devel] Sending patches

> yes, but please send each patch as separate mail (in reply to the cover > letter). 'git send-email' does the right thing, so I'd recommend just > collecting all the patches ('git format-patch' with subjectprefix set > correctly in each repository) into one directory, and then running > > $ git

Re: [pve-devel] API - GET /nodes/{node}/storage

On Tue, Apr 17, 2018 at 02:02:23PM +0200, Andreas Steinel wrote: > Thank you Fabian for the in depth analysis. > > I tried to use the json representation of the API in order to > automatically extract the schema definitions for a consuming API that > generates the code based on the found

Re: [pve-devel] Sending patches

On Tue, Apr 17, 2018 at 01:16:11PM +0200, Rene Jochum wrote: > Hi, > > I've read https://pve.proxmox.com/wiki/Developer_Documentation. > > I would like to send ONE patch series for lots of packages where > i add/extend the .gitignore. > > Is that possible? > > Thanks, > René yes, but please

Re: [pve-devel] API - GET /nodes/{node}/storage

Thank you Fabian for the in depth analysis. I tried to use the json representation of the API in order to automatically extract the schema definitions for a consuming API that generates the code based on the found definitions of all elements. This works fine most of the time but failed in this

[pve-devel] Sending patches

Hi, I've read https://pve.proxmox.com/wiki/Developer_Documentation. I would like to send ONE patch series for lots of packages where i add/extend the .gitignore. Is that possible? Thanks, René ___ pve-devel mailing list pve-devel@pve.proxmox.com

Re: [pve-devel] pve-edk2-firmware and mirror_edk2

fixed - please test again. > On April 17, 2018 at 11:04 AM Rene Jochum wrote: > > > Hi, > > while building my packages for Buster i found that both repos in the > Subject aren't exported. > > I see those are pretty new, do they miss a "git-daemon-export-ok" or is > that

[pve-devel] pve-edk2-firmware and mirror_edk2

Hi, while building my packages for Buster i found that both repos in the Subject aren't exported. I see those are pretty new, do they miss a "git-daemon-export-ok" or is that indented? Thanks, René ___ pve-devel mailing list pve-devel@pve.proxmox.com

Re: [pve-devel] Gitlab-ci

On 2018-04-17 10:27, Dietmar Maurer wrote: > I personally think this adds much overhead and does not really help > developing software. > Ok. ___ pve-devel mailing list pve-devel@pve.proxmox.com

Re: [pve-devel] Gitlab-ci

> I've made some Dockerfiles for PVE (easy to add more for PMG). These > don't require the Docker HUB - so it will be able to build them > even when the hub goes down. > > https://git.lxch.eu/git/pve-dockerfiles > > Is that something Proxmox is interested in? If yes, I'll continue my >

Re: [pve-devel] API - GET /nodes/{node}/storage

On Mon, Apr 16, 2018 at 06:03:58PM +0200, Andreas Steinel wrote: > Hi all, > > I tried to access the storage API and looked through [1] to find, that the > > GET /nodes/{node}/storage > > returns an array of string according to [2] the excerpt is: > > "GET" : { >"description" : "Get status