[one-users] econe server "connection reset by peer"

[Parag Mhashilkar]

Hi Daniel,

It doesn't seem to be DB limitation. 

The info gets stored in the field body of user_pool which is medium text. 
mysql> desc user_pool;
+---------+--------------+------+-----+---------+-------+
| Field   | Type         | Null | Key | Default | Extra |
+---------+--------------+------+-----+---------+-------+
| oid     | int(11)      | NO   | PRI | NULL    |       |
| name    | varchar(128) | YES  | UNI | NULL    |       |
| body    | mediumtext   | YES  |     | NULL    |       |
| uid     | int(11)      | YES  |     | NULL    |       |
| gid     | int(11)      | YES  |     | NULL    |       |
| owner_u | int(11)      | YES  |     | NULL    |       |
| group_u | int(11)      | YES  |     | NULL    |       |
| other_u | int(11)      | YES  |     | NULL    |       |
+---------+--------------+------+-----+---------+-------+
8 rows in set (0.00 sec)


The actual content of the body with ~300 keys is ~240K bytes which is much less then the documented (http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html) limit of L + 3 bytes, where L < 224
mysql> select body from user_pool where name = "nova" into outfile '/tmp/parag.db1';
Query OK, 1 row affected (0.00 sec)
[oneadmin at fermicloud198 ~]$ wc --bytes /tmp/parag.db1 
240136 /tmp/parag.db1

Also, the contents of the field in DB are valid base64 encoded. So there is no chance of DB truncating the info.

We suspect the limit is somehow artificially imposed in the server. However we were not able to figure out where and how it is configurable.

Thanks & Regards
+==========================================================
| Parag Mhashilkar
| Fermi National Accelerator Laboratory, MS 120
| Wilson & Kirk Road, Batavia, IL - 60510
|----------------------------------------------------------
| Phone: 1 (630) 840-6530 Fax: 1 (630) 840-3109
|----------------------------------------------------------
| Wilson Hall, 806E (Nov 8, 2012 - To date)
| Wilson Hall, 867E (Nov 17, 2010 - Nov 7, 2012)
| Wilson Hall, 863E (Apr 24, 2007 - Nov 16, 2010)
| Wilson Hall, 856E (Mar 21, 2005 - Apr 23, 2007)
+==========================================================

On Oct 15, 2014, at 10:56 AM, Daniel Molina wrote:

> Hi Steven,
> 
> It looks like a DB limitation, this information is stored in the user template. So it should depend on the BODY column type and the DB backend used
> 
> Cheers
> 
> On 11 October 2014 03:58, Steven C Timm <timm at fnal.gov> wrote:
> We have been doing bulk tests of the OpenNebula 4.8 econe-server.
> With just a straight econe-run-instances we can get up to 1000 VM's (the limit of our current subnet) 
> started fairly quickly (about 30 minutes)
> 
> But in practice we are using a more complicated sequence of EC2 calls via HTCondor.
> In particular it is doing a CreateKeyPair call before it launches each VM and then 
> calling the RunInstances method with the --keypair option, a unique keypair for each VM.
> After the VM exits, it called a DeleteKeyPair call.
> 
> IT appears there is a hard limit of the number of key pairs that can be stored in 
> any one user's template and that hard limit is 301.  Any further CreateKeyPair calls
> return with "connection reset by peer" causing HTCondor to mark the VM as held.
> Fortunately it is possible to override this and tell HTCondor to continue, but it's a pain.
> We do have ways to log into the vm's without the ssh key pair so we wouldn't even really need to register
> them at all.
> 
> Is my analysis correct?  Is there a hard limit of the number of keys that can be stored in the user template?
> If so, how best to get around this limit?
> 
> Steve Timm
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
> 
> 
> 
> 
> -- 
> --
> Daniel Molina
> Project Engineer
> OpenNebula - Flexible Enterprise Cloud Made Simple
> www.OpenNebula.org | dmolina at opennebula.org | @OpenNebula
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2204 bytes
Desc: not available
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20141015/a634f1c9/attachment.bin>