On Tue, Apr 09, 2013 at 01:24:20PM -0600, Mike Tutkowski wrote:
> Well, one reason is it seems to confuse Eclipse when you do a checkout from
> one branch to another. If you have a workspace for master and one for 4.1,
> that seems to work more smoothly.
>
> Maybe I'm doing something wrong there?
Well, one reason is it seems to confuse Eclipse when you do a checkout from
one branch to another. If you have a workspace for master and one for 4.1,
that seems to work more smoothly.
Maybe I'm doing something wrong there?
On Tue, Apr 9, 2013 at 1:21 PM, Chip Childers wrote:
> On Tue, Apr 09,
On Tue, Apr 09, 2013 at 01:18:11PM -0600, Mike Tutkowski wrote:
> Updating my remote repos now (I have a repo I use specifically for 4.1 and
> one for master).
>
> Over the past couple weeks, I was working on stuff related to 4.1 and was
> happy where it was at, so wasn't updating.
>
> When I "up
Updating my remote repos now (I have a repo I use specifically for 4.1 and
one for master).
Over the past couple weeks, I was working on stuff related to 4.1 and was
happy where it was at, so wasn't updating.
When I "updated" today, I noticed nothing new...which seemed odd. :)
On Tue, Apr 9, 20
On Tue, Apr 09, 2013 at 12:26:35PM -0600, Mike Tutkowski wrote:
> Just added this to the Bug report:
>
> Hi Prachi,
>
> I am new to Git, so it is entirely possible I'm doing something wrong there.
>
> I ran a "git fetch upstream" where "upstream" is defined as the following:
>
> upstream https:
Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
Sent: Monday, April 08, 2013 10:08 PM
To: dev@cloudstack.apache.org
Subject: Re: VM deployed to wrong storage repository
Finally got it to happen again.
This time two VMs were placed on the same PS instead of each on their own PS.
All appears
Finally got it to happen again.
This time two VMs were placed on the same PS instead of each on their own
PS.
All appears to be configured properly.
This is just a log shot, but could this possibly be happening because the
iSCSI targets that are being used for storage repositories are not
format
It could be by chance. I've run a bunch of tests, however, and can no
longer get it to choose incorrectly. Before, though, it was placing both
VMs on the same PS and each should have been on a different one. I can't
see anything different in my config then versus now.
I'm still trying to repro
Could it just be that it occasionally chooses the right storage by chance?
On Apr 8, 2013 8:36 PM, "Prachi Damle" wrote:
> If you are seeing the tags honored sometimes then I guess this might be
> related to ordering of allocators.
>
> Kelven, is your fix to maintain the order in which allocators
If you are seeing the tags honored sometimes then I guess this might be related
to ordering of allocators.
Kelven, is your fix to maintain the order in which allocators are loaded, in
4.1 as well?
Prachi
On Apr 8, 2013, at 6:45 PM, "Mike Tutkowski"
wrote:
> Yeah, that dawned on me later,
Yeah, that dawned on me later, Marcus. :) I updated the Bug a couple hours
ago to note that it might have been due to lack of memory (I had mentioned
this issue in the Bug). That certainly is likely, in fact, since I'm
running two XenServers in VMs on my laptop. :) It just didn't click right
away t
By the way, the insufficient capacity in itself may not indicate storage
space. It could be lack of memory or CPU as well.
On Apr 8, 2013 2:48 PM, "Mike Tutkowski"
wrote:
> I went ahead and logged Bug 1971 for this issue.
>
> Currently I cannot get the system to deploy to the correct primary stor
Sure, np.
I've done a lot of Java development over the past ten years or so, but
never used Spring before, so that's been a new experience for me. :)
On Mon, Apr 8, 2013 at 6:29 PM, Joe Brockmeier wrote:
> Hi Mike,
>
> Any chance you could create a new page on the wiki + document your
> exper
Hi Mike,
Any chance you could create a new page on the wiki + document your
experience here? I'm not sure that someone with a need to specify
storage placement would hit on "Using Spring..."
You're raising a good question here, would love to see it on the wiki.
Best,
jzb
--
Joe Brockmeier
I went ahead and logged Bug 1971 for this issue.
Currently I cannot get the system to deploy to the correct primary storage
and it claims to run out of space when deploying a third VM:
INFO [user.vm.DeployVMCmd] (Job-Executor-19:job-19)
com.cloud.exception.InsufficientServerCapacityException: Un
Hey guys,
In nonossComponentContext.xml.in, I see the following for storage
allocators:
On Mon, Apr 8, 2013 at 12:52 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> Actually, now that I know to look for "componentContext.xml" and not
> "components.xml
Actually, now that I know to look for "componentContext.xml" and not
"components.xml," I found this page:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Using+Spring+in+CloudStack
On Mon, Apr 8, 2013 at 12:39 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> I wrote that last
I wrote that last filename incorrect (I meant one
nonossComponentContext.xml.in).
On Mon, Apr 8, 2013 at 12:37 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> Thanks, guys!
>
> I do see componentContext.xml.
>
> Not to be too much of a pain here :) (I looked for this on the Wiki and
Thanks, guys!
I do see componentContext.xml.
Not to be too much of a pain here :) (I looked for this on the Wiki and
couldn't find relevant info), but I have three componentContext.xml files,
one componentContext.xml.in file, three nonossComponentContext.xml files,
and one nonComponentContext.xml
On Mon, Apr 08, 2013 at 12:19:48PM -0600, Mike Tutkowski wrote:
> FYI that the closest I find are both called migration-components.xml (2 of
> them).
>
>
> On Mon, Apr 8, 2013 at 12:09 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Hi,
> >
> > I've never modified this file bef
If you're running it the Dev way with jetty, look for vmops.log in your git
root. If you've installed via package look for
/var/log/cloudstack/management/management-server.log.
On Apr 7, 2013 12:45 AM, "Mike Tutkowski"
wrote:
> Hi Marcus,
>
> I was just looking at the output in the console.
>
> C
However, even if CS failed to deploy the VM to the required tier, deploying
it to another tier would be erroneous behavior.
For example, one tier might be higher performing than another. If the
customer paid for a high-performance tier and was placed on something
lower, that wouldn't be acceptabl
Hi Marcus,
I was just looking at the output in the console.
Can you remind me again where the related logs are stored?
Thanks!
On Sun, Apr 7, 2013 at 12:39 AM, Marcus Sorensen wrote:
> Have you by chance looked at the debug logs to see if it by chance tried
> the proper storage and failed? I'
Have you by chance looked at the debug logs to see if it by chance tried
the proper storage and failed? I'm not sure that's OK either, but it would
be interesting to know.
On Apr 7, 2013 12:25 AM, "Mike Tutkowski"
wrote:
> Hi,
>
> I'm currently using 4.1 (from like a week or so ago).
>
> I have t
If someone would like me to demo this problem, please let me know.
I noticed it while writing code that makes use of the 4.1 API.
I assumed at first I had done something wrong, so I tried it manually using
the wizard in the GUI and noticed the same behavior: CloudStack was not
always honoring my
25 matches
Mail list logo
