[PVE-User] Simultaneous API call

[Mohamed Sadok Ben Jazia]

Hello,
to describe my purpose, i'm supposed to create a commercial plateform for
providing IAAS and PAAS using proxmox.
For this step, i'm planning to develop a full API for third pary users, the
development will be done in PHP as start.
The API will contain 3 main parts (clustering and managing hosts and nodes,
Actions on CT's and VM's, Authorisations handling)
The issue i'm facing here happens when i run simultaneous API call to
create CT's on the same host because i'm using call-to-nextid() that
returns the same id.
I think semaphores or mutex are not a good options because once not well
implemented, i will have deadlocks which is worst than simple error.
I simply think to implement call-to-nextid() myself and get a list of used
id's and add a random number for security but it's not a perfect choice.

Thanks
Sadok

On 13 February 2016 at 10:07, Thomas Lamprecht <t.lamprecht at proxmox.com>
wrote:

> Hi,
>
> can you show a (simple) example how you do it? Are you making next id
> calls from all over the cluster (in parallel)?
>
> If you're doing it in serial like:
>
> new_vmid = call-to-nextid();
> create-ct(new_vmid)
>
> you're fine, doing parallel calls you get race conditions and atomicity
> violations.
>
> Solving that could be done in several ways:
>
> * Locking from your side (with semaphore, mutex, ...)
>
>
> LOCK(CREATE)
>
> new_vmid = call-to-nextid();
> create-ct(new_vmid)
>
> UNLOCK(CREATE)
>
>
> this is a pit of an overkill though, as you only need to lock until the
> container config is created in:
>
> /etc/pve/nodes/<yournode>/lxc/<neew_vmid>.conf
>
> Ther should be also the possibility to force create a CT, AFAIK, then
> you could do the following:
>
> LOCK(CREATE)
>
> new_vmid = call-to-nextid();
>
> // create the cfg file before calling pct create
> touch /etc/pve/nodes/<yournode>/lxc/<new_vmid>.conf
>
> UNLOCK(CREATE)
>
> create-ct(new_vmid, force=true)
>
>
> The locked context here would be magnitudes shorter and thus everything
> more responsive, BUT I didn't tested that sod it could be that I'm miss
> a check we do, will quickly test it on Monday.
>
> Third way would be to hold a possible free list "bitmap" of VMIDs in
> your program which you use to determine the next free. This would be
> synced with the real one from time to time, not that nice but a
> possibility.
>
> Out of interest, in what language do you make this? And what's the goal,
> if I may ask?
>
> cheers,
> Thomas
>
>
> On 10.02.2016 10:08, Mohamed Sadok Ben Jazia wrote:
> > Hello list,
> > I'm creating LXC container using the API on proxmox 4.1
> > I use get("/cluster/nextid") to get the next free id to use.
> > The issue i encountered is when i do simultaneous number of API calls
> > I get proxmox trying to create containers with the same ID which gave me
> > this error
> >
> > trying to aquire lock...TASK ERROR: can't lock file
> > '/run/lock/lxc/pve-config-147.lock' - got timeout
> >
> > are there a standard way to deal with this?
> >
> >
> > _______________________________________________
> > pve-user mailing list
> > pve-user at pve.proxmox.com
> > http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user
> >
>
> _______________________________________________
> pve-user mailing list
> pve-user at pve.proxmox.com
> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.proxmox.com/pipermail/pve-user/attachments/20160213/81d5b33e/attachment.htm>