Hi Adrian, The cpu number in the host details view, is the actual host cpu number * cpu overprovisioning factor On the overall dashboard, it does not take the cpu overprovisioning factor into consideration. The value is the sum of host cpu numbers.
-Wei On Fri, 30 Jul 2021 at 08:47, Michael Kesper <mkes...@schokokeks.org> wrote: > Hi Eric, > > Am 29.07.21 um 19:55 schrieb Eric Green: > > On 7/29/2021 3:48 AM, Andrija Panic wrote: > >> AND, the "insufficient capacity" has, wait one.... 99% of the case > NOTHING > >> to do with not having enough capacity here or there, it's the stupid, > >> generic message on failure. > > > > Talking about which, a bit off-topic here I know, I dug through the > source code a bit trying to figure out if there's a way we can get better > error messages because 95% of the time, what finally makes it out to the > GUI after going through all the various layers from agent to task runner to > api to GUI just isn't very informative. I shouldn't have to be digging > through logs to know why my new instance didn't run, that error message > should be turned into a standard English (or other language) error message > that gives me actual information and propagate up through the layers until > it reaches me. I came to the conclusion that it wasn't going to be an easy > task because whoever architected this thing just didn't make provisions for > propagating errors in a consistent way, and it was going to require a bit > of re-factoring here and there to make it happen. Has there been any talk > of doing that work, or has it been lost behind the constant struggle to > keep Cloudstack up to date and > > compatible with recent hypervisor and OS changes? > > > > BTW, I am already a maintainer of another massive pile of Java code with > a similar architecture and similar issues (we *mostly* do a good job of > telling you why a task failed, but not 100% of the time, the agent is > supposed to give us an event giving us a reason why it failed for us to put > in the task state but sometimes it just splats flat on its face and all we > can tell you is that a task failed, though at least we don't give a > misleading excuse for why it failed) so alas lack the cycles to contribute > to Cloudstack. > > I'm unable to find a bug already explicitly covering the "too broad error > message" yet. Maybe I overlooked it, else it really should be created. > > Maybe you could give some directions how the code could be structured to > better support this? > > Best > Michael > > >