Re: Squeeze another PR (#2398) in 4.11 milestone

Rafael, It got changed on this PR: https://github.com/apache/cloudstack/pull/1749/files#diff-6eeb1a2fb818cccb14785ee80c93a561R560 On Tue, Jan 9, 2018 at 4:44 PM, Khosrow Moossavi wrote: > That is correct Mike. The quoted part above was misleading, it should have >

Re: Squeeze another PR (#2398) in 4.11 milestone

That is correct Mike. The quoted part above was misleading, it should have been "at any given point in time *when transaction finished*" Removal of "other" or "current failed" snapshot happens at the very end of the method. The state of SR throughout time would be something like: 1) snapshot-01

Re: Squeeze another PR (#2398) in 4.11 milestone

Yes. That is actually what we do. Looking at the code of "Xenserver625StorageProcessor.java ", it feels that we were already doing this even before this PR #2398. However, I might not be understanding the

Re: Squeeze another PR (#2398) in 4.11 milestone

“technically we should only have "one" on primary storage at any given point in time” I just wanted to follow up on this one. When we are copying a delta from the previous snapshot, we should actually have two snapshots on primary storage for a time. If the delta copy is successful, then we

Re: Squeeze another PR (#2398) in 4.11 milestone

"We are already deleting snapshots in the primary storage, but we always leave behind the last one" This issue doesn't happen only when something fails. We are not deleting the snapshots from primary storage (not on XenServer 6.25+ and not since Feb 2017) The fix of this PR is: 1) when

Re: Squeeze another PR (#2398) in 4.11 milestone

Khosrow, I have seen this issue as well. It happens when there are problems to transfer the snapshot from the primary to the secondary storage. However, we need to clarify one thing. We are already deleting snapshots in the primary storage, but we always leave behind the last one. The problem is

Squeeze another PR (#2398) in 4.11 milestone

Hi community We've found [1] and fixed [2] an issue in 4.10 regarding snapshots remaining on primary storage (XenServer + Swift) which causes VDI chain gets full after some time and user cannot take another snapshot. Please include this in 4.11 milestone if you see fit. [1]:

Re: Support MHz resource limit and accounting for VM instances for accounts and domains

Rafael is right. I'm talking about the excplicit limit which with (cpu cores limit, ram limit) allows limiting account. E.g. We have - low cpu VM offering: 4 cores / 1000 MHz / 4 GB RAM - high cpu offering: 1 core / 3400 MHz / 2 GB RAM Without MHz parameter it's impossible enforce an user can

Re: Support MHz resource limit and accounting for VM instances for accounts and domains

I believe he is talking about something different. The Quota plugin is used to manage users' resources indirectly. Meaning, instead of assigning the limit of resource a user can allocate/use, the administrator/operator assigns a monetary value to users. Then, the user has the freedom to use as

Re: Support MHz resource limit and accounting for VM instances for accounts and domains

Ivan, Is the feature you are suggesting not just a slightly different version of the quota service – which afaik is already in place? https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quota+Service+-+FS Regards, Dag Sonstebo Cloud Architect ShapeBlue On 09/01/2018, 12:58, "Rafael

Re: Support MHz resource limit and accounting for VM instances for accounts and domains

Very interesting proposal. I even thought it already existed, but it is not there yet. +1 On Mon, Jan 8, 2018 at 6:32 AM, Ivan Kudryavtsev wrote: > Hello, community. > > We are going to implement the feature which enables limiting accounts and > domains for cumulative

Re: Master Blockers and Criticals

Ivan, I did not quite understand what you said. Could you create other thread for these issues, so we can discuss them without polluting this one. On Tue, Jan 9, 2018 at 8:16 AM, Ivan Kudryavtsev wrote: > Rafael, > > I don't have log entries because there are no

Re: cloudstack Wikipedia page

just anonymously removed it, Giles On Tue, Jan 9, 2018 at 11:21 AM, Giles Sirett wrote: > Somebody has made an edit to the cloudstack wikipedia entry > > https://en.wikipedia.org/w/index.php?diff=819108440=815849996 > > In essence, they have changed the start of the

cloudstack Wikipedia page

Somebody has made an edit to the cloudstack wikipedia entry https://en.wikipedia.org/w/index.php?diff=819108440=815849996 In essence, they have changed the start of the history section to give a history of the cloud.com domain name. I do not think that is either relevant or appropriate to the

Re: Master Blockers and Criticals

Rafael, I don't have log entries because there are no specific info, except the but I have very live stand which I can provide an access and demonstrate the problems (for 4.10 with some PRs from master). Also, I open two these bugs, but I would like to check them against the live master first to

Re: Master Blockers and Criticals

Do you have log entries for problem (1)? On Tue, Jan 9, 2018 at 7:55 AM, Ivan Kudryavtsev wrote: > During last days I found 2 bugs which I believe is critical for 4.11 > release. I would like to share them here and get help if possible: > > 1. CPVM bug. I use wildcard

Re: Master Blockers and Criticals

During last days I found 2 bugs which I believe is critical for 4.11 release. I would like to share them here and get help if possible: 1. CPVM bug. I use wildcard certificate issued by Comodo CA. I uploaded it to CS via UI and destroyed CPVM to force use it. It uses it like a charm, but after

Re: Master Blockers and Criticals

All, Using Paul's list and tracking JIRA for issues, I see no tickets marked as a BLOCKER. If you do believe we've missed any blocker issue please share. We'll continue with the PRs tagged with the 4.11 milestone (list is frozen now) and afterward, do a final round of smoketest/component