This is a security failsafe, so even if destination does not exist we mkdir the path
with 0700 permission. If path exists mkdir -m 700 -p won't do anything.
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
- Assumption is that mkdir is available on xen host
- We don't know what kind of file we're copying, dirs would have 0777 permission
by default
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
- Mgmt server impl is a pluggable service, fix it's method
- Fix getCommands() to return all cmd api classes supported by this mgmt server
- For api-discovery, get commands from pluggable services only, don't use reflections
- Don't use reflections in ApiServer, iterate pluggableservices
- Fix api discovery unit test
- The fix was done automatically using following python program along with
following step:
1. Get all apis provided by default mgmt server, all of them are in cloud-api now
cd api/src/org/apache/cloudstack/api/command
find . >> apis
2. For all apis, generate java code that adds the class to the cmdList arraylist:
f = open('apis', 'r')
data = f.read()
f.close()
output = ""
for a in data.split('\n'):
output += "cmdList.add(%s);" % a.split('/')[-1].replace('.java', '.class')
# wrote output to a file, copied content to mgmt server impl's getCommands()
# similarly, fixed import statements using same code, splitting on /
Testing:
Ran apiserver, put breakpoints in ApiServer's init() where classes are processed
Total cmd classes found by reflections (ReflectUtil) = 354
Total cmd classes found by getCommands for all pluggable services = 354
Next, copied the comma separated values for each set to a string in ipython, a & b
set(a).difference(set(b)) returned null.
The above test implies both set of cmd classes found by both methods, i.e. using
reflections and using getCommands() had same set of apis and all were unique.
Conclusion:
The changes are idempotent and don't break api server's cmd class api discovery
processing.
BUG-ID: CLOUDSTACK-1210
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
We used to define domains persistent in libvirt, which caused XML definitions
to stay there after a reboot of the hypervisor.
We however don't do anything with those already defined domains, actually, we wipe
all defined domains when starting the agent.
Some users however reported that libvirt started these domains after a reboot
before the CloudStack agent was started.
By starting domains from the XML description and not defining them we prevent
them from ever being stored in libvirt.
Due to incorrect logic the private network traffic label specified was not getting used, instead some default was getting used (vSwitch0 or privateEthernetPortProfile). The fix passes the correct label in the format vSwitchX or vSwitchX,<vlan_id> and based on that the correct switch is used.
following changes
- introduced notion of event bus with publish, subscribe, unsubscribe
semantics
- a plug-in can implement the EventBus abstraction to provide event
bug to CloudStack
- A rabbitMQ based plug-in that can interact with AMQP servers to
provide message broker based event-bug
- stream lines, action events, usage events, alerts publishing in to
convineance classed which are also used to publish corresponding
event on to event bus
- introduced notion of state change event. On a state change, in the
state machine corrsponding to the resource, a state change event is
published on the event bug
- associated a state machined with Snapshot and Network objects
- Virtual Machine, Volume, Snaphost, Network object state changes wil
result in a state change event
