I took a few minutes to update the ipv6 draft spec.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+VPC+Router
On Fri, Jan 17, 2014 at 2:20 PM, Marcus Sorensen wrote:
> On Fri, Jan 17, 2014 at 11:59 AM, Chiradeep Vittal
> wrote:
>> Yes, let's not shut o
I think there's a hole in the volume lifecycle. I've been noticing
volumes lingering that should have been cleaned up, and it seems to be
a bug in the state machine for the volumes:
s_fsm.addTransition(Destroy, Event.ExpungingRequested, Expunging);
s_fsm.addTransition(Expu
trying to clean up. I think it's ultimately
good to surface those (better than potentially orphaning disks on
storage), but it may be something to watch for.
On Thu, Jan 30, 2014 at 2:56 PM, Mike Tutkowski
wrote:
> I agree, Marcus.
>
>
> On Thu, Jan 30, 2014 at 2:42 PM, Marc
yep
On Thu, Jan 30, 2014 at 4:01 PM, Mike Tutkowski
wrote:
> Hi,
>
> This is a minor issue.
>
> Has anyone else noticed when you return to the GUI from another window that
> sometimes the GUI's font has changed?
>
> To get the GUI to switch back to the expected font, I have to refresh it by
> cl
fact, the file is gone (regardless of whether
> or not your delete command actually deleted the file or it was gone for
> some other reason).
>
> I think, as you say, it's probably good to expose those other issues,
> though.
>
>
> On Thu, Jan 30, 2014 at 3:29 PM, Ma
I don't think preallocation=metadata is required for sparse qcow2.
Just if you want it to NOT be sparse for metadata.
I also remember hearing that either recent qemu-img has a decent
preallocation by default now, or that performance has improved such
that it doesn't matter. Will need to do some re
created will remain intact. However, it's
just a backing file so the new qcow2 that stores changes will need to
have settings as well.
On Fri, Jan 31, 2014 at 11:01 PM, Marcus wrote:
> I don't think preallocation=metadata is required for sparse qcow2.
> Just if you want it to NO
t
>>preallocation by default now, or that performance has improved such
>>that it doesn't matter. Will need to do some reading to remember, but
>>I think I remember hearing it's not a big deal nowadays.
>
> Ummm. I tested with "qemu-img version 0.12.1,"
data leaves disk as 1.7M, it's also sparse, but a bit bigger.
On Fri, Jan 31, 2014 at 11:41 PM, Marcus wrote:
> Yes, no_option.img is only 256k in size. it's sparse.
>
> On Fri, Jan 31, 2014 at 11:38 PM, Yoshikazu Nojima wrote:
>>>I don't think preallocation=met
2014 at 11:43 PM, Marcus wrote:
> Here are my tests, using stock centos 6.5 qemu-img:
>
> [root@server ~]# qemu-img create -f qcow2 image.qcow2 10G
> Formatting 'image.qcow2', fmt=qcow2 size=10737418240 encryption=off
> cluster_size=65536
> [root@server ~]# qemu-img info
eeds, just turning on preallocation=metadata by default
> or making it configurable from agent.properties is enough, but I'm
> still thinking about making it configurable from disk offerings.
>
> Thanks,
>
> 2014-01-31 Marcus :
>> Ok, so not technically sparse in the sense
Oh yes, and storage overprovisioning doesn't currently work for KVM
storage types, but it's a relatively simple fix:
https://issues.apache.org/jira/browse/CLOUDSTACK-5806
On Sat, Feb 1, 2014 at 12:12 AM, Marcus wrote:
> I don't think you'd have to change anything. C
This particular release passed my basic testing for KVM and storage
types local, clvm, and nfs. Both Ubuntu 12.04 and CentOS 6.5.
On Thu, Feb 6, 2014 at 8:55 AM, Animesh Chaturvedi
wrote:
> Yes I will look over all commits in 4.3-forward since RC3 and pull them into
> 4.3
>
> Thanks
> Animesh
>
I occasionally have some minor improvement that I need to make to
whatever version of cloudstack we're currently running. This is almost
always behind what is currently being developed, and I don't always
feel like I have time to rebase/refactor it for master. I'm wondering
if there are any individ
revisit it later...
On Fri, Feb 7, 2014 at 7:37 PM, David Nalley wrote:
> - Users:
>
> Regardless of whether someone takes you up on the offer or not, I'd
> still love to see these patches hit RB or the mailing list, or Jira
> perhaps.
>
> --David
>
> On Fri, F
+1 (binding)
Built RPMs on CentOS 6.5, deployed advanced zone, vpc, network,
installed template, launched VM on local storage, launched VM on NFS
storage, launched VM on CLVM storage.
Built DEBs on Ubuntu 12.04, deployed advanced zone, vpc, network,
installed template, launched VM on local storag
That IS the right thing. It would drive me crazy it if I manually told
cloudstack the VM was supposed to be off and it kept starting it. HA
makes sure a VM that is supposed to be running stays running.
On Sun, Feb 9, 2014 at 5:38 AM, Nux! wrote:
> Hi,
>
> I'm testing HA in 4.3 and for the most pa
Oh, sorry, I see you mean you turn it off outside of cloudstack. If CS
checks the server and notices that a vm is no longer running, and it
thought the vm was running, it should probably start it.
On Sun, Feb 9, 2014 at 10:02 AM, Marcus wrote:
> That IS the right thing. It would drive me cr
This doesn't seem to be an issue with 4.3, but I noticed that in
4.2 we have hard-coded the max custom disk offering size to 1024. I'm
going to fix this (assuming we ever release a 4.2.2), but the use of
'final', and the fact that the min size is already set up to be
configurable, made me thin
I dropped a patch into
https://issues.apache.org/jira/browse/CLOUDSTACK-6088, and if someone
can get to it, great, otherwise I'll try to circle back around to it.
On Fri, Feb 7, 2014 at 9:45 PM, Marcus wrote:
> Yeah, I just don't know where to capture them. If I have a patch for
If I'm not mistaken, I think the primary concern wasn't about breaking
compatibility, but simply this:
"The format seems very cumbersome compared to accesskey=
secretkey= - has this been a community decision to move in this
direction that I've missed?"
I'd say yes, it was a community decision, an
Does it need to go to review board though? I generally only post
patches that can actually be applied to reviewboard. This is more or
less just a blueprint for someone who is willing to make it work in
master.
On Wed, Feb 12, 2014 at 12:31 PM, Alex Hitchins
wrote:
> Thanks for the patch Mar
I can see how that is confusing, because 'guest' traffic type is where
isolated networks are created. They are largely synonymous in many
areas of cloudstack.
On Wed, Feb 12, 2014 at 8:08 PM, Yitao Jiang wrote:
> Guest network is same as public ip, which vm's traffic go through switch
> directly.
I think it's interesting, the PCI discovery that was mentioned, it
would alleviate the manual agent.properties config that the patch
requires. I imagine it will be available in the Ubuntu 14.04 release
as well, assuming they're targeting current versions.
On Thu, Feb 13, 2014 at 1:21 PM, Edison S
The most direct way is to register the windows DVD as an ISO, and then
use it to install your own windows VM. Then you can create a template
from that. You can also find some Windows 2012 eval templates floating
around the internet, and convert them to VHD if necessary using
qemu-img or some other
tration of every PCI ID for every VF in every
agent.properties, for example. One could simply turn on SR-IOV NIC or
GPU.
On Thu, Feb 13, 2014 at 6:00 PM, Edison Su wrote:
>
>
>> -Original Message-
>> From: Marcus [mailto:[email protected]]
>> Sent: Thursday, Fe
Too late! It's not super critical, I'm just putting things there for
whatever 4.3.x release can include them.
On Thu, Feb 13, 2014 at 3:20 PM, Animesh Chaturvedi
wrote:
> Marcus
>
>
>
> I see your commits in 4.3-forward for CLOUDSTACK-6089. Do you want it
Don't you already have dropbox support? Just go into your drop box and
fetch a public URL, add &qcow2 to fool the file type checker, and it
should pull the thing down.
On Thu, Feb 20, 2014 at 7:08 PM, Chiradeep Vittal
wrote:
> Heh, AWS seems to manage fine without it. But that is AWS.
> Service o
If someone gets around to it they can add in root resize support via
the patch I've posted to the list once or twice. I can maybe look at
updating it for master and testing if I can find some time. It's a
very short patch, but the testing is what I don't have time for at the
moment, more of a prior
Yeah, that's an option too. It's sometimes very inconvenient, but
that's what was intended. At any rate I don't think we want to
automatically create multiple templates of different sizes after
upload, I'd rather see the root resize.
On Thu, Feb 20, 2014 at 7:08 PM, Chiradeep Vittal
wrote:
> Heh,
Sometimes it's not easy to revert the commit, I suppose a bug should
be raised and assigned to the individual, in that case. For example,
someone branches and then merges without pulling in fixes that
occurred in between, this is fairly common and can be painful when
file locations are shifted arou
Also keep in mind that with an Object or custom objects that extend it, doing
if (obj.equals(thing))
is usually the same as:
if (obj == thing)
Since the Object.equals() method by default says something like:
public boolean equals(Object other)
{
return this == other;
code.
>> 2. If object1 and object2 have the same hash code, they do NOT have to
>> be equal too.
>>
> >From http://tutorials.jenkov.com/java-collections/hashcode-equals.html
>>
>>
>>On Tue, Feb 25, 2014 at 3:07 PM, Marcus wrote:
>>
>>> Also
Perhaps we just need to reduce overlap. Most people work on 4.3 until
it's out the door, I think. Personally, I have a hard time straddling
the two during this phase.
On Wed, Feb 26, 2014 at 9:08 PM, Ram Ganesh wrote:
> I agree on the RC process! Few thoughts from my end
>
> - I see a rus
I don't know. I do think we should stick to a schedule, but I also
think that the track record has shown that there are far too many
features stuffed into our releases to have such short release cycles.
Part of the point of short release cycles (assuming you consider 4
months to be short, with a ch
Change the agent to debug mode by changing all 'INFO' to 'DEBUG' in
/etc/cloudstack/agent/log4j.cloud, this will give you more info,
usually the agent can't find the required network config on the host
or something like that.
On Sat, Mar 1, 2014 at 1:21 PM, María Noelia Gil wrote:
> Hi, I'm thro
4.3-forward is where commits go that you want to eventually end up in
4.3.x, whether it be another RC build or a maintenance release
(4.3.1). Then the release manager approves and pulls into 4.3, or when
4.3 is released pulls all of 4.3-forward back into 4.3 for the next
release going forard.
On S
ndler-2:null)
> Proccess agent startup answer, agent id = 0
> 2014-03-03 00:32:45,733 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Set
> agent id 0
> 2014-03-03 00:32:45,737 INFO [cloud.agent.Agent] (AgentShutdownThread:null)
> Stopping the agent: Reason = sig.kill
> 2014-03-03
I'm not sure I understand. How do you expect to reboot your primary
storage while vms are running? It sounds like the host is being
fenced since it cannot contact the resources it depends on.
On Sun, Mar 2, 2014 at 3:24 PM, Nux! wrote:
> On 02.03.2014 21:17, Andrei Mikhailovsky wrote:
>>
>> Hell
Or do you mean you have multiple primary storages and this one was not
in use and put into maintenance?
On Sun, Mar 2, 2014 at 5:25 PM, Marcus wrote:
> I'm not sure I understand. How do you expect to reboot your primary
> storage while vms are running? It sounds like the host is bei
Also, please note that in the bug you referenced it doesn't have a
problem with the reboot being triggered, but with the fact that reboot
never completes due to hanging NFS mount (which is why the reboot
occurs, inaccessible primary storage).
On Sun, Mar 2, 2014 at 5:26 PM, Marcus wrote:
&g
I remember seeing this in the past. You can probably find some info on
the list. The KVM side is simply saying 'this storage is already
registered with libvirt', but the management server seems to think
this is a brand new host/agent and is failing to register the local
storage pool since there's a
On that note, we need to be careful *how* we merge features, otherwise
it can be painful to revert.
On Sun, Mar 2, 2014 at 11:12 AM, Sebastien Goasguen wrote:
>
> On Feb 28, 2014, at 9:09 AM, Hugo Trippaers wrote:
>
>> i'm all for being flexible, but i find a lot of the arguments used here
>> d
!!
>
> The primary storage needs to be put in maintenance before doing any
> upgrade/reboot as mentioned in the previous mails.
>
> -Koushik
>
> On 03-Mar-2014, at 6:07 AM, Marcus wrote:
>
>> Also, please note that in the bug you referenced it doesn't have a
>&
What is your overprovisioning set to? The dashboard might be correct,
for example if you have 3.17T and set overprovision to 3 you'll have
9.51T of allocatable space.
On Mon, Mar 3, 2014 at 9:50 AM, Nux! wrote:
> On 03.03.2014 08:39, Nux! wrote:
>>
>> Hi,
>>
>> I'm on 4.3 rev 4440 (latest RC). Af
I came across this code in 4.4 recently:
commit e5cfe948186b825d2b28c99ce2915a5ca8498aff
Author: Bharat Kumar
Date: Thu Nov 28 12:34:16 2013 +0530
CLOUDSTACK-5160 add a map to specify the custom compute parameters
in the deployvm api.
Signed-off-by: Jayapal
It looks like you can set
Along these lines, the details parameter in deployVirtualMachine seems
broken. If I call "details[0].key=foo,details[0].value=bar", it stores
entries in the database like this:
id | vmid | name | value | display
12 | 25 | value | bar | 1
13 | 25 | key | foo
at, why did you pick this format for storing the vm details? Were you
> following the rules from some other calls? If so, what those calls are?
>
> -Alena.
>
> On 3/3/14, 1:00 PM, "Marcus" wrote:
>
>>Along these lines, the details parameter in deployVirtualMachine
this format for storing the vm details? Were you
> following the rules from some other calls? If so, what those calls are?
>
> -Alena.
>
> On 3/3/14, 1:00 PM, "Marcus" wrote:
>
>>Along these lines, the details parameter in deployVirtualMachine seems
>>bro
On Tue, Mar 4, 2014 at 3:34 AM, France wrote:
> Hi Marcus and others.
>
> There is no need to kill of the entire hypervisor, if one of the primary
> storages fail.
> You just need to kill the VMs and probably disable SR on XenServer, because
> all other SRs and VMs have no probl
If you get a moment, please look at resize-root branch and see if it
works for Gluster. I didn't see any code specific to creating volumes
in your patch, mostly just pool stuff, so hopefully it's covered.
Also, Wido, as mentioned on the bug for resize-root I'd prefer it if
you could review the cha
ich also isn't great).
I just thought of one minor improvement to the situation that might
fix CLOUDSTACK-5429. They could potentially use the sysrq triggers to
force reboot.
On Tue, Mar 4, 2014 at 7:45 AM, Wido den Hollander wrote:
> On 03/04/2014 03:38 PM, Marcus wrote:
>>
>>
resizeVolume has been extended to work with root disks. If
resizeVolume works on XenServer (which I believe it does), then it
should just work.
Also, if someone looks at the CopyCommand for CitrixResourceBase (or
whatever handles the storage commands for Xen now) that is used to
create new disks f
It is, but not yet merged. We're investigating whether anyone who
codes on the other hypervisors are interested in supporting it for the
release. If not, it will be KVM-only for now.
On Tue, Mar 4, 2014 at 3:15 PM, Mike Tutkowski
wrote:
> Is this feature currently KVM only?
>
>
> On Tue, Mar 4, 2
uter&serviceProviderList[5].service=UserData&serviceProviderList[5].provider=VirtualRouter&serviceProviderList[6].service=SourceNat&serviceProviderList[6].provider=JuniperSRX&serviceProviderList[7].service=StaticNat&serviceProviderList[7].provider=JuniperSRX&ser
sure, I lose track of who is committer, as many times committers post
to reviewboard as well if the code is unfamiliar.
On Tue, Mar 4, 2014 at 9:46 PM, Saksham Srivastava
wrote:
> Marcus, as a committer can you kindly commit it too.
>
> -Original Message-
> From: Mar
Wouldn't this be implemented as just changing disk offerings? The
resizeVolume API call already allows you to switch disk offerings, we
just need to add a hook in there to optionally call the storage driver
(If volume is deployed to a primary storage) to make an update to the
iops properties on the
bindings to do so, per
previous discussion.
On Wed, Mar 5, 2014 at 11:12 AM, Marcus wrote:
> Wouldn't this be implemented as just changing disk offerings? The
> resizeVolume API call already allows you to switch disk offerings, we
> just need to add a hook in there to optionally ca
Yes, that's what I mean. When the offering is changed, we need to have
a hook in there that calls the applicable storage driver for the
volume. Then the drivers can be free to implement or not implement.
On Wed, Mar 5, 2014 at 11:36 AM, Mike Tutkowski
wrote:
> Hi Marcus,
>
> In
Hi guys,
Trying to get back into the Xen devcloud for a few things, and
following the instructions it seems that the existing devcloud2 is
missing java 7. Do our docs point to an old image, or are we just
installing that manually?
om.trilead.ssh2.SCPClient.readResponse(SCPClient.java:59)
at com.trilead.ssh2.SCPClient.sendFiles(SCPClient.java:166)
at com.trilead.ssh2.SCPClient.put(SCPClient.java:588)
... 20 more
On Fri, Mar 7, 2014 at 10:54 AM, Marcus wrote:
> Hi guys,
>Trying to get back into the Xen devcloud for a few th
Any suggestion? Do we go forward assuming that the correct parameter
for resize on deploy is:
deployVirtualMachine&details[0].rootdisksize=3
or do we change it to
deployVirtualMachine&rootdisksize=3
On Tue, Mar 4, 2014 at 4:14 PM, Marcus wrote:
> Ok, sounds like there needs to b
Link says this new file is missing license:
Unapproved licenses:
api/src/com/cloud/offering/DiskOfferingInfo.java
On Fri, Mar 7, 2014 at 4:14 PM, Nitin Mehta wrote:
> There is a RAT build failure. Check the link [1] for the file that misses
> license header. Checking whether RAT build works f
Wido,
I'm seeing this in Ubuntu 12.04 after commit
2014-02-10 01:19:16,793 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-2:null) Volume
/mnt/2fe9a944-505e-38cb-bf87-72623634be4a/e47e6501-c8ae-41a7-9abc-0f7fdad5fb30
can be resized by libvirt. Asking libvirt to resize the
Ubuntu 12.04 doesn't support
virStorageVolResize.
# strings /usr/lib/libvirt.so.0.9.8 | grep virStorageVolR
virStorageVolRef
virStorageVolRef
virStorageVolRef
On Fri, Mar 7, 2014 at 4:28 PM, Marcus wrote:
> Wido,
> I'm seeing this in Ubuntu 12.04 after commit
>
>
>
On Fri, Mar 7, 2014 at 4:30 PM, Marcus wrote:
> Hrm... sent instead of pasted. Commit
>
> commit 3989d6c48118f31464c87c71b6279a11eb13eb35
> Author: Wido den Hollander
> Date: Mon Feb 3 17:04:11 2014 +0100
>
> kvm: Resize volumes using libvirt
>
> virsh blockresi
I've been randomly hitting this with my master testing, and I'm unsure
if it's something strange in my test environment, or if somebody has
been working on the async job handler and there's some sort of race
condition. I saw it first when trying to destroy a vm, then during a
test run with volume d
Perhaps there's a new service. I know in the past we've seen issues with
this , specifically the conntrackd log. I think the cloud logs weren't
getting rolled either, but I thought it was all fixed.
There's also simply not a ton of space on /var, I wish we would go back to
just having one partitio
ich log files are taking up more space
> in /var
>
> Thanks
> Rajesh Battala
>
> -Original Message-
> From: Marcus [mailto:[email protected]]
> Sent: Saturday, March 8, 2014 8:19 PM
> To: [email protected]
> Subject: RE: system vm disk space issue in
I imagine the new LTS will have it, but I'm not sure what our OS support
policy is.
On Mar 8, 2014 11:59 AM, "Wido den Hollander" wrote:
>
>
> On 03/08/2014 12:32 AM, Marcus wrote:
>
>> On Fri, Mar 7, 2014 at 4:30 PM, Marcus wrote:
>>
>>> Hrm.
Mike has sent out several emails about the DB changes he made.
On Mon, Mar 10, 2014 at 5:28 AM, Koushik Das wrote:
> I am seeing the following exception
>
> ERROR [c.c.a.ApiServer] (38419149@qtp-1917357200-11:ctx-116b8207
> ctx-9a54f764) unhandled exception executing api command:
> [Ljava.lang.
Was actually bitten by another db change today that I hadn't pulled in yet:
commit 830328b63da3c720712263d792f0393ea547466d
Author: Nitin Mehta
Date: Wed Mar 5 16:40:44 2014 -0800
CLOUDSTACK-6199: Hide action events for Vm/Volume commands when
the resources have display flag=0.
Introd
lso not require any further
> changes in the API if we need to add some more custom values in future.
>
> On 08-Mar-2014, at 1:42 am, Marcus wrote:
>
>> Any suggestion? Do we go forward assuming that the correct parameter
>> for resize on deploy is:
&g
ameter, and our documentation is
currently very lacking in exposing exactly which details exist or the
info on parameters inside parameters.
>
> On 08-Mar-2014, at 1:42 am, Marcus wrote:
>
>> Any suggestion? Do we go forward assuming that the correct parameter
>> for resize on
o specify any
> custom parameters related to VM.
>
> Thanks
> Bharat.
>
> On 10-Mar-2014, at 10:57 pm, Marcus wrote:
>
>> It is valid, as I've implemented it. So we need to decide if we're
>> using 'details' or rootdisksize as an api param. T
urrently no
root size on service offering, but we could in the future add a 'min
root size' attribute into the service offering that would override the
template size if it were larger than the selected template.
On Mon, Mar 10, 2014 at 11:38 AM, Marcus wrote:
> Yes, we'd have to l
Mar 8, 2014 at 11:32 AM, Marcus wrote:
> Yeah, I've just seen on busy systems where even with log rotation working
> properly the little space left in var after OS files is barely enough, for
> example the conntrackd log on a busy VPC. We actually ended up rolling our
> own system
Please test that fix and close the case if it works.
On Mon, Mar 10, 2014 at 3:18 PM, Nux! wrote:
> Hello,
>
> While on 4.4 testing Marcus' root resize patches I got a hard time getting
> the cloudstack-agent to work, this is due to a broken init script.
> Opened https://is
Of course...
On Mon, Mar 10, 2014 at 3:45 PM, Nux! wrote:
> On 10.03.2014 21:37, Marcus wrote:
>>
>> Please test that fix and close the case if it works.
>
>
> It doesn't, it needs to be:
> `basename "$0"`
>
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
we can maybe switch to an agent properties for the system vms that use
a size-based roll for logging.
On Mon, Mar 10, 2014 at 5:30 PM, Anirban Chakraborty wrote:
> Thanks for all the responses. I do not see cloud.log and cloud.out logs are
> zipped in /var/log and /var/log/cloud respectively. On
I'm adding extra tests to the integration suite, and I'm testing for
unsupported hypervisor. I'm wondering if the automated integration
testing we use passes the '-a hypervisor=' filter that is appropriate
for the test environment, such that I can appropriately mark tests to
be run or not run as th
st wrap parts of the test in an 'if' statement. I'll see if I can
figure out why it's doing that.
On Tue, Mar 11, 2014 at 1:03 AM, Marcus wrote:
> I'm adding extra tests to the integration suite, and I'm testing for
> unsupported hypervisor. I'm wond
gt; The hypervisor type is picked up from config file you provided to nosetests,
> If not default to xen.
>
> Santhosh
> ________
> From: Marcus [[email protected]]
> Sent: Tuesday, March 11, 2014 3:10 AM
> To: [email protected]
>
;
> Santhosh
> ________
> From: Marcus [[email protected]]
> Sent: Tuesday, March 11, 2014 3:17 AM
> To: [email protected]
> Subject: Re: quick marvin/integration test question
>
> Yeah, that doesn't seem to be working for me. it's only define
ed in v.resize. See the last comments
on this issue https://issues.apache.org/jira/browse/CLOUDSTACK-6181
On Mon, Mar 10, 2014 at 5:10 AM, Wido den Hollander wrote:
>
>
> On 03/09/2014 01:19 AM, Marcus wrote:
>>
>> I imagine the new LTS will have it, but I'm not sure wh
ou're more often getting newer software, but it
will be the same issue soon when CentOS 7 comes out. CentOS 6 will
still get updates and software bumps, but it will likely get left
behind eventually.
On Tue, Mar 11, 2014 at 9:27 AM, Marcus wrote:
> The hard part is that there are so many li
Christopher, 4.1 was also delayed several months.
I'm also -1 on moving it, even though I'm not sure it will have much
impact. The key is in how we look at merge requests, and whether or
not things are even being done in branches or directly to master.
People are going to rush to stuff things in,
OpenStack. Are we ok with using that?
On Tue, Mar 11, 2014 at 9:47 AM, Marcus wrote:
> Now that I think about it a bit more, I'm not really interested in
> hobbling ourselves until 2017 to support libvirt 0.9.8 on ubuntu
> 12.04. It's a bit easier with the RHEL/CentOS model,
so it looks like preallocation only works 1) on raw volumes, and 2) on
certain libvirt versions. I'll see if I can add those checks in,
assuming we really want to keep that flag.
On Tue, Mar 11, 2014 at 10:36 AM, Marcus wrote:
> I see that the Ubuntu Cloud Archive revolves around p
Created CLOUDSTACK-6225 and pushed a patch to verify libvirt version
and format before adding the allocate flag.
The bug also mentions the outstanding Ubuntu 12.04 issue.
On Tue, Mar 11, 2014 at 10:50 AM, Nux! wrote:
> On 11.03.2014 16:46, Marcus wrote:
>>
>> so it looks like pre
uild-master-slowbuild/406/changes>
>
> Changes:
>
> [marcus] CLOUDSTACK-6225: Check libvirt version and volume format before
>
> [jessicawang] CLOUDSTACK-6226: UI > multi widget > dropdown field > translate
> option value.
>
> [kishan] CLOUDSTACK-6122: LXC sy
I'd like to merge the resize-root branch for the requested feature of
being able to resize root volumes. I have pulled from master and
tested.
I should note that this feature is affected by an existing bug in
master that was introduced recently, breaking the existing data disk
resize feature on Ub
The overlap is simply a byproduct of cutting the branch, I'm not sure
there's a way around it. It's a good point though, that essentially
the window is 1 month shorter than I think was intended. Better
testing will help that, however, with the point being that we
shouldn't be doing a ton of work to
branch is cut and you move on to the newer release. I'm
> not
> >> > sure that was the intent when such a schedule was created. It means
> we're
> >> > releasing every four months, but developing for only three.
> >> >
> >> >
> &g
Min, in looking at this branch merge, I need to be reminded whether we
are supposed to squash feature branches when they come in, or preserve
history. It's nice to preserve history, but it's a lot easier to undo
a squashed merge.
On Thu, Mar 13, 2014 at 5:56 PM, Min Chen wrote:
> IAM branch is no
I see this on KVM as well. I don't recall hearing about the GPU
feature, sounds interesting.
014-03-14 01:14:06,302 DEBUG [agent.manager.AgentManagerImpl]
(StatsCollector-1:ctx-b3b2e81f) Details from executing class
com.cloud.agent.api.GetGPUStatsCommand: Unsupported command
issued:com.cloud.agent
oh yes, I do remember this. We probably need to fix the null pointer,
but I think it's more or less just noise.
On Fri, Mar 14, 2014 at 1:15 AM, Marcus wrote:
> I see this on KVM as well. I don't recall hearing about the GPU
> feature, sounds interesting.
>
> 014-03
Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
On Thu, Mar 13, 2014 at 11:30 PM, Marcus wrote:
> Min, in looking at this branch merge, I need to be reminded whether we
> are supposed to squash feature branches when they come in, or preserve
> history. It's nice to pr
:03 AM, Marcus wrote:
> I have no idea if its related to this branch merge or not, but I'm
> unable to start the ssvm on master since I pulled about an hour ago. I
> can deploy a fresh zone, and the ssvm will actually start, but it
> can't transition state in the DB, so it kil
>
>> As we have a 72 hour window for MERGE requests, please make sure they
>> are in today (if the feature is ready).
>>
>>
>> Cheers,
>>
>> Hugo
>
>
> Can someone confirm if this has made it in?
> https://issues.apache.org/jira/browse/CLOUDSTA
1 - 100 of 1292 matches
Mail list logo
