On 03/29/2012 02:45 PM, Justin Santa Barbara wrote:
I think _we_ should stand behind OpenStack.
That said, I understand why it's a tough call. Hopefully most problems
can be fixed with a simple-ish SQL script post-release.
I've got a fix for the first index issue up in gerrit for master.
htt
I think _we_ should stand behind OpenStack.
That said, I understand why it's a tough call. Hopefully most problems can
be fixed with a simple-ish SQL script post-release.
On Thu, Mar 29, 2012 at 11:06 AM, David Kranz wrote:
> Well, there are diablo-stable packages. If Ubuntu, Debian, Red Hat,
Well, there are diablo-stable packages. If Ubuntu, Debian, Red Hat,
etc. keep hearing from customers that Essex in an LTS release is not
adequate, there will be essex-stable packages too. They are the ones who
have to stand behind the product. It is perfectly understandable that
there is resis
I'm not saying it can't be rationalized; I'm saying it is frustrating to me.
My understanding is that Essex is going to be baked into both Ubuntu &
Debian for the long term - 5 years plus. That's a long time to have to
keep explaining why X is broken; I'd rather just fix X.
On Thu, Mar 29, 20
On 3/29/2012 12:46 PM, Justin Santa Barbara wrote:
Is there a good way to map back where in the code these calls are
coming from?
There's not a great way currently. I'm trying to get a patch in for
Essex which will let deployments easily turn on SQL debugging (though
this is proving
>
> Is there a good way to map back where in the code these calls are coming
> from?
There's not a great way currently. I'm trying to get a patch in for Essex
which will let deployments easily turn on SQL debugging (though this is
proving contentious); it will have a configurable log level to al
On 03/25/2012 01:03 PM, Justin Santa Barbara wrote:
The performance of the metadata query with cloud-init has been causing
some people problems (it's so slow cloud-init times out!), and has led
to the suggestion that we need lots of caching. (My hypothesis is that
we don't...)
By turning on SQL
The performance of the metadata query with cloud-init has been causing some
people problems (it's so slow cloud-init times out!), and has led to the
suggestion that we need lots of caching. (My hypothesis is that we
don't...)
By turning on SQL debugging in SQL Alchemy (for which I've proposed a p
8 matches
Mail list logo
