Re: Miami CCC '17 Roundtable/Hackathon Summary

[Daan Hoogland]

Nice write-up Matthew,

In short, I think everybody in the round table (it was actually a big whole 
between the chairs, but it was round indeed) agreed with
- the VR functionality should be packaged with cloudstack
- it must be easy to install
- the plugin system needs work
Thank you for your reminder, though. We cannot stress those ground principles 
enough. A movement away from our own implementation(s) and leveraging other 
products as much as we can is the only thing you could see as a change in 
philosophy, though that has been going on for quite a while as well. The idea 
is that we package those products (as jars) as much as possible, so the 
‘monolithic’ nature of the beast is not compromised more than absolutely 
possible.


daan.hoogl...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

On 24/05/2017, 21:48, "Matthew Smart"  wrote:

Hey guys,

I originally chose Cloudstack because I really liked the idea of a 
monolithic stack and always pick an Apache project over an industry 
controlled one. I moved on to OpenStack because I could not figure out 
how to implement some advanced networking capabilities using Cloudstack 
(and for some stupid reason I did not engage the community to figure it 
out). The networking architecture I was needing to implement was 
supposed to be supported by OpenStack so I started working with it. I 
spent months banging my head against that mess. I would get one module 
up and running just to find out that another one was failing. I never 
actually managed to get a stable OpenStack deployment running that I 
felt I could trust with my production systems.

So I came back to Cloudstack, talked to the mailing list, and found a 
workaround for my networking environment and got deployed. Even so, 
networking, and specifically the VR are the biggest liabilities in my 
opinion. There are several very important features I am living without 
right now because they either do not work or are not stable enough for 
production.

That being said, I am kind of in the middle on the NFV issue. The last 
thing we should be doing is taking away those elements of Cloudstack 
that differentiate us, both philosophically and structurally, from the 
other platforms out there. Cloudstack should always have, as a core 
feature, the fact that it is monolithic. One installer and a dead simple 
means of deploying a full stack is absolutely essential for adoption.

On the other hand, having just put together a networking plugin, I can 
say that the plugin system needs to be MUCH less ambiguous. I would have 
had my PR issued months ago (and would not have pestered Will and Syed 
from Cloudops so relentlessly... poor bastards!) if I had advance 
information about what data the system was going to send to my plugin 
for the different networking functions. I kept running into situations 
where my plugin was receiving the same data structure but with some 
subset of the data elements coming through as NULL depending on the 
situation. So I would be relying on having some data that I would 
receive in some cases but not in others. I essentially had to get ACS to 
send me commands for each permutation of operation and manually inspect 
the command's data structures to see what I was being given and then 
workaround the missing information. Of course, I would get most of the 
way done and find a corner case that I missed where I did not have the 
information I needed and that would require that I go back and refactor 
things to workaround the limitation.

If the plugin system was better documented though, then integrating with 
it would be pretty simple. I really think we need to be careful here 
about throwing out the baby with the bathwater. If we are looking to 
replace the current plugin system entirely and make it more modular we 
should first come up with a list of functionalities that are not 
supported by the current system. If that list is sufficiently large then 
it makes sense to start over. If not, then I think the entire issue can 
be addressed by refactoring and documenting the existing plugin system. 
At the end of the day, we would be doing ourselves, and our entire 
community, a disservice if we start moving away from ease of 
implementation. Openstack in my opinion is too modular. Thereby making 
its architecture and implementation so complex that only a company who 
specializes in it can efficiently deploy it. It is no surprise that its 
sponsoring companies sell prepackaged Openstack distros and/or 
deployment and maintenance services. Obfuscate and profit.

Having something/s analogous to the current VR in terms of features is a 
must have for Cloudstack no matter what decision is made.

some issues after upgrade cloudstack to 4.9.2

[Marc Poll Garcia]

Hi all,

we have just upgraded our cloud environment based on Cloudstack 4.5.2 to
4.9.2 and we're expriencing some issues after this.

Our setup is the following one:

- 1 x cloudstack managment server
- 1 x bbdd server cloudstack database on it
- 2 x Vmware Hipervisors (hosts)

I'm performing a list of tests:

*- Sometimes, and randomly console from instances does not load.*
*- Not possible to upload template from local.*

We see the following on log:

2017-05-25 09:00:31,665 ERROR [c.c.s.ImageStoreUploadMonitorImpl]
(Upload-Monitor-1:ctx-0b3bf6e9) (logid:e9c82a0f) *Template
b87459ac-8fbe-4b34-ae25-21235c3fcd1d failed to upload due to operation
timed out*
2017-05-25 09:02:18,265 ERROR [c.c.c.ClusterServiceServletContainer]
(Thread-11:null) (logid:) *Unexpected exception *
2017-05-25 09:03:35,940 ERROR [c.c.c.ClusterManagerImpl] (main:null)
(logid:) *Unable to ping management server at 192.168.100.2:9090
 due to ConnectException*


Why is it happening?
It does not happen on our old 4.5.2 version.

Is there any way to fix it? changing any global parameter or permissions
issue?

We need a clue with that because if affecting to our production environment.

Thanks in advance.

Kind regards.

Re: some issues after upgrade cloudstack to 4.9.2

[Marc Poll Garcia]

Hello again,

About the Cloudstack version upgrade, we've build it from sources, to
create new self-compiled package 4.9.2 version with "noredit", in order to
achieve VMware hypervisor compatibility.

During that process, we changed some files, trying to get Vmxnet3 as
virtual NIC by default instead of E1000 when new instances are created.

Unfortunatly it does not work either.

That's what we did:
/tmp/apache-cloudstack-4.9.2.0-src

*Change:*
*// Fallback to E1000 if no specific nicAdapter is passed*
*VirtualEthernetCardType nicDeviceType =
VirtualEthernetCardType.E1000;*

*Apache-cloudstack-4.9.2.0-src] # cat
./plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
| grep VirtualEthernetCardType*
*Import com.cloud.hypervisor.vmware.mo.VirtualEthernetCardType;*
*VirtualEthernetCardType nicDeviceType =
VirtualEthernetCardType.Vmxnet3;*



Any help on it?

More info:
http://users.cloudstack.apache.narkive.com/LTPpdCh3/vmxnet3-by-default

Many thanks!

Kind regards.

2017-05-25 11:14 GMT+02:00 Marc Poll Garcia :

> Hi all,
>
> we have just upgraded our cloud environment based on Cloudstack 4.5.2 to
> 4.9.2 and we're expriencing some issues after this.
>
> Our setup is the following one:
>
> - 1 x cloudstack managment server
> - 1 x bbdd server cloudstack database on it
> - 2 x Vmware Hipervisors (hosts)
>
> I'm performing a list of tests:
>
> *- Sometimes, and randomly console from instances does not load.*
> *- Not possible to upload template from local.*
>
> We see the following on log:
>
> 2017-05-25 09:00:31,665 ERROR [c.c.s.ImageStoreUploadMonitorImpl]
> (Upload-Monitor-1:ctx-0b3bf6e9) (logid:e9c82a0f) *Template
> b87459ac-8fbe-4b34-ae25-21235c3fcd1d failed to upload due to operation
> timed out*
> 2017-05-25 09:02:18,265 ERROR [c.c.c.ClusterServiceServletContainer]
> (Thread-11:null) (logid:) *Unexpected exception *
> 2017-05-25 09:03:35,940 ERROR [c.c.c.ClusterManagerImpl] (main:null)
> (logid:) *Unable to ping management server at 192.168.100.2:9090
>  due to ConnectException*
>
>
> Why is it happening?
> It does not happen on our old 4.5.2 version.
>
> Is there any way to fix it? changing any global parameter or permissions
> issue?
>
> We need a clue with that because if affecting to our production
> environment.
>
> Thanks in advance.
>
> Kind regards.
>