Bug #246
oned crashes on buggy OCCI network request
Status: | Closed | Start date: | 05/28/2010 | |
---|---|---|---|---|
Priority: | High | Due date: | ||
Assignee: | Daniel Molina | % Done: | 0% | |
Category: | Core & System | |||
Target version: | Release 1.4.2 | |||
Resolution: | fixed | Pull request: | ||
Affected Versions: |
Description
Hi there,
I experienced the following problem: oned crashes when erroneous network request is submitted
through the OCCI interface, namely when the network address value is not present in the request.
Since the same request works when address value added, I guess it might be a bug.
Problem detais¶
- Cause: I issued an occi-network create command with a buggy xml file, something like this:
$ sudo su -c "occi-network --url $OCCI_URL --username $USER --password $PASSWORD create $LAN_DEF_PATH" - oneadmin .Reason:end of file reached
(though the output seems to indicate an error message, it is not obvious for me what it means)
- Effect: oned is no longer running, meanwhile
scheduler and occi server is still running...
oned.pid is stuck
oned.log doesn't contain any error message, eg. last 5 lines from the log:Fri May 28 12:01:08 2010 [ReM][D]: UserAllocate method invoked Fri May 28 12:01:09 2010 [ReM][D]: UserPoolInfo method invoked Fri May 28 12:01:09 2010 [ReM][D]: UserPoolInfo method invoked Fri May 28 12:01:09 2010 [ReM][D]: UserPoolInfo method invoked Fri May 28 12:01:09 2010 [ReM][D]: VirtualNetworkAllocate method invoked
- Priority: Currently we are only at the development stage so it is not a urgent issue... but
I think it is a high priority one since it means that a client can simply crash the whole cloud.
- Reproduction: I attached a sample xml (buggy-network.xml) you may reproduce the problem with,
eg.:
$ sudo su -c "occi-network --url $OCCI_URL --username $USER --password $PASSWORD create buggy-network.xml" - oneadmin
I also attached the correct version (network.xml) which works and shows that the problem is caused
by the missing address value.
- Environment: ONE v.1.4, Debian GNU/Linux
Quick fix¶
Catching erroneous OCCI messages and refusing them to pass through could workaround the
problem. Something like this:
215: def post_network(request) 234: # begin: network address quickfix 235: if network_info['NETWORK']['ADDRESS'].nil? 236: error_msg = "Network address not present in the request" 237: error = OpenNebula::Error.new(error_msg) 238: return error, 400 239: end 240: # end: network address quickfix 241: vntemplate = network.to_one_template(
source:src/cloud/occi/lib/OCCIServer.rb
However it might happen that other invalid OCCI messsages will cause the same problem. Thus it
might be useful to examine whether others are effected or not..., and of course the root cause
itself should be found.
Kind regards,
Gyula
Associated revisions
bug #246: Fix the bug for ranged networks without address. Added new tests to reproduce this bug
bug #246: Fix the bug for ranged networks without address. Added new tests to reproduce this bug
Bug #246: Check OpenNebula error and if leases exists
32 characters max in switch name (#246)
History
#1 Updated by Ruben S. Montero about 11 years ago
- Assignee changed from Ruben S. Montero to Daniel Molina
#2 Updated by Ruben S. Montero about 11 years ago
- Status changed from New to Closed
- Target version set to Release 1.4.2
- Resolution set to fixed
Changes in master & one-1.4 branch