On 21/01/14 13:14 -0500, Joe Gordon wrote:
On Jan 17, 2014 12:24 AM, "Flavio Percoco" wrote:
On 16/01/14 17:32 -0500, Doug Hellmann wrote:
On Thu, Jan 16, 2014 at 3:19 PM, Ben Nemec wrote:
On 2014-01-16 13:48, John Griffith wrote:
Hey Everyone,
A review came up today th
Hi Dong,
Can you elaborate an example of what you get, and what you were expecting
exactly?.
I have a similar problem within one operator, where they assign you sparse
blocks
of IP addresses (floating IPs), directly routed to your machine, and they also
assign the virtual mac add
On 22 January 2014 00:00, Robert Collins wrote:
> I think dropping frames that can't be forwarded is entirely sane - at
>
a guess it's what a physical ethernet switch would do if you try to
> send a 1600 byte frame (on a non-jumbo-frame switched network) - but
> perhaps there is an actual standar
On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
Hiya - Resource is actually a Heat term that corresponds to what we're
deploying within
the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1
Controller
and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Com
Hi All,
I have two questions ...
1) Glance v1 APIs can take a --location argument when creating an image
but v2 APIs can't - bug or feature? (Details below)
2) How should glanceclient (v2 commands) handle reserved attributes?
a) status quo: (Apparently) let the user se
On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
Hiya - Resource is actually a Heat term that corresponds to what we're
deploying within
the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1
Controller
and 3 Compute, Heat will create a Stack that contains 1 Controller and 3 Com
On Tue, Jan 21 2014, ZhiQiang Fan wrote:
> six 1.5.2 has been released on 2014-01-06, it provides urllib/urlparse
> compatibility. Is there any plan to upgrade six to 1.5.2? (since it is
> fresh new, may need some time to test)
>
> six 1.4.1 is lack of urllib/urlparse support, so oslo-incubator/py
On Tue, Jan 21 2014, Joe Gordon wrote:
> I would like to propose having a integration test job in Oslo incubator
> that syncs in the code, similar to how we do global requirements.
I don't think that would be possible as a voting job, since the point of
oslo-incubator is to be able to break the A
Le 22/01/2014 02:50, Jay Pipes a écrit :
Yup, agreed. It's difficult to guess what the capacity implications
would be without having solid numbers on customer demands for this
functionality, including hard data on how long such instances would
typically live (see my previous point about re-using
Le 22/01/2014 01:37, Dugger, Donald D a écrit :
Sylvain-
Tnx, that worked great.
(Now if I can just find a way to get the affinity tests working, all
the other tests pass. I only have 17 tests failing out of 254.)
I'm pretty busy these days with Climate 0.1 to deliver, but if I find
so
On Wed, Jan 22, 2014 at 11:17 AM, Julien Danjou wrote:
> On Tue, Jan 21 2014, ZhiQiang Fan wrote:
>
> > six 1.5.2 has been released on 2014-01-06, it provides urllib/urlparse
> > compatibility. Is there any plan to upgrade six to 1.5.2? (since it is
> > fresh new, may need some time to test)
> >
On 22 January 2014 21:28, Ian Wells wrote:
> On 22 January 2014 00:00, Robert Collins wrote:
>>
>> I think dropping frames that can't be forwarded is entirely sane - at
>>
>> a guess it's what a physical ethernet switch would do if you try to
>> send a 1600 byte frame (on a non-jumbo-frame switch
Hello Team:
As some of you are aware, I've been working on a couple of reviews to add
Trove testing support to devstack-gate (viz.
https://review.openstack.org/#/c/65040/, and
https://review.openstack.org/#/c/65065/). Hopefully these will be merged
soon.
The next part of the integration plan is t
Hi all,
we have an approved blueprint that concerns reducing number of ignored PEP8
and openstack/hacking style checks for heat (
https://blueprints.launchpad.net/heat/+spec/reduce-flake8-ignored-rules).
I've been already warned that enabling some of these rules will be quite
controversial, and pe
Current EDP config-hints are not only plugin specific. Several types of jobs
must have certain key/values and without it job will fail. For instance,
MapReduce (former Jar) job type requires Mapper/Reducer classes parameters
to be set[1]. Moreover, for such kind of jobs we already have separated
On 22/01/14 11:40 +0100, Chmouel Boudjnah wrote:
On Wed, Jan 22, 2014 at 11:17 AM, Julien Danjou wrote:
On Tue, Jan 21 2014, ZhiQiang Fan wrote:
> six 1.5.2 has been released on 2014-01-06, it provides urllib/urlparse
> compatibility. Is there any plan to upgrade six to 1.5.2? (since
On 01/22/2014 03:27 AM, Robert Collins wrote:
> On 22 January 2014 10:50, Kashyap Chamarthy wrote:
>> [CC'ed libguestfs author, Rich Jones]
>>
>> Heya,
>>
>>
>> On 01/21/2014 07:59 AM, Robert Collins wrote:
>>> I was reminded of this while I cleaned up failed file injection nbd
>>> devices on ci-o
On 22 January 2014 12:01, Robert Collins wrote:
> > Getting the MTU *right* on all hosts seems to be key to keeping your hair
> > attached to your head for a little longer. Hence the DHCP suggestion to
> set
> > it to the right value.
>
> I certainly think having the MTU set to the right value i
On 21 January 2014 22:46, Veiga, Anthony wrote:
>
>Hi, Sean and Xuhan:
>
> I totally agree. This is not the ultimate solution with the assumption
> that we had to use “enable_dhcp”.
>
> We haven’t decided the name of another parameter, however, we are open
> to any suggestions. As we mention
On 2014/22/01 10:00, Jaromir Coufal wrote:
On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
Hiya - Resource is actually a Heat term that corresponds to what we're
deploying within
the Overcloud Stack - i.e., if we specify that we want an Overcloud
with 1 Controller
and 3 Compute, Heat will create
Hello, Jaromir
On Wed, Jan 22, 2014 at 4:09 PM, Jaromir Coufal wrote:
>
> I am leaning towards Role. We can be more specific with adding some extra
> word, e.g.:
> * Node Role
>
We use this term a lot internally for the very similar purpose, so it looks
reasonable to me.
Just my 2c.
--
Best re
On Wed, Jan 22, 2014 at 01:23:05PM +0200, Pavlo Shchelokovskyy wrote:
> Hi all,
>
> we have an approved blueprint that concerns reducing number of ignored PEP8
> and openstack/hacking style checks for heat (
> https://blueprints.launchpad.net/heat/+spec/reduce-flake8-ignored-rules).
> I've been al
On 01/22/2014 06:23 AM, Pavlo Shchelokovskyy wrote:
> Hi all,
>
> we have an approved blueprint that concerns reducing number of ignored
> PEP8 and openstack/hacking style checks for heat
> (https://blueprints.launchpad.net/heat/+spec/reduce-flake8-ignored-rules).
> I've been already warned that e
On 01/22/2014 05:19 AM, Julien Danjou wrote:
> On Tue, Jan 21 2014, Joe Gordon wrote:
>
>> I would like to propose having a integration test job in Oslo incubator
>> that syncs in the code, similar to how we do global requirements.
>
> I don't think that would be possible as a voting job, since t
Sounds great! Let's do it on Thursday.
--Robert
On 1/22/14 12:46 AM, "Irena Berezovsky"
mailto:ire...@mellanox.com>> wrote:
Hi Robert, all,
I would suggest not to delay the SR-IOV discussion to the next week.
Let’s try to cover the SRIOV side and especially the nova-neutron interaction
points
Thanks for your input, Carl. You're right, it seems the more appropriate
place for this is _validate_subnet(). It checks ip version, gateway,
etc... but not the size of the subnet.
Carl Baldwin wrote on 01/21/2014 09:22:55 PM:
> From: Carl Baldwin
> To: OpenStack Development Mailing List
,
That's a fair question; I'd argue that it *should* be resources. When we
update an overcloud deployment, it'll create additional resources.
Mainn
- Original Message -
>
>
> On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
> > Hiya - Resource is actually a Heat term that corresponds to what w
- Original Message -
>
>
> On 2014/22/01 10:00, Jaromir Coufal wrote:
> >
> >
> > On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
> >> Hiya - Resource is actually a Heat term that corresponds to what we're
> >> deploying within
> >> the Overcloud Stack - i.e., if we specify that we want an O
On 22/01/14 07:32 -0500, Sean Dague wrote:
On 01/22/2014 05:19 AM, Julien Danjou wrote:
On Tue, Jan 21 2014, Joe Gordon wrote:
I would like to propose having a integration test job in Oslo incubator
that syncs in the code, similar to how we do global requirements.
I don't think that would be
> > On 2014/22/01 10:00, Jaromir Coufal wrote:
> > >
> > >
> > > On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
> > >> Hiya - Resource is actually a Heat term that corresponds to what we're
> > >> deploying within
> > >> the Overcloud Stack - i.e., if we specify that we want an Overcloud
> > >> with 1
Things aren't great, but they are actually better than yesterday.
Vital Stats:
Gate queue length: 107
Check queue length: 107
Head of gate entered: 45hrs ago
Changes merged in last 24hrs: 58
The 58 changes merged is actually a good number, not a great number, but
best we've seen in a numb
On 22/01/14 14:31, Tzu-Mainn Chen wrote:
On 2014/22/01 10:00, Jaromir Coufal wrote:
On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
Hiya - Resource is actually a Heat term that corresponds to what we're
deploying within
the Overcloud Stack - i.e., if we specify that we want an Overcloud
with 1 Con
> From: Sylvain Bauza
>
> Le 22/01/2014 02:50, Jay Pipes a écrit :
> >
> > Yup, agreed. It's difficult to guess what the capacity implications
> > would be without having solid numbers on customer demands for this
> > functionality, including hard data on how long such instances would
> > typical
Jay Pipes wrote on 01/21/2014 08:50:36 PM:
...
> On Tue, 2014-01-21 at 14:28 +, Day, Phil wrote:
> > > >
> > > > I think there is clear water between this and the existing
> aggregate based
> > > isolation. I also think this is a different use case from
> reservations. It's
> > > *mostly*
On 01/22/2014 09:38 AM, Sean Dague wrote:
> Things aren't great, but they are actually better than yesterday.
>
> Vital Stats:
> Gate queue length: 107
> Check queue length: 107
> Head of gate entered: 45hrs ago
> Changes merged in last 24hrs: 58
>
> The 58 changes merged is actually a go
Le 22/01/2014 15:57, Mike Spreitzer a écrit :
Is that enough? Remember that some of us are concerned with business
workloads, rather than HPC jobs. While it might be acceptable in a
business workload to plan on regularly recycling every individual
instance, it is definitely not acceptable t
It's worth noticing that elastic recheck is signalling bug 1253896 and bug
1224001 but they have actually the same signature.
I found also interesting that neutron is triggering a lot bug 1254890,
which appears to be a hang on /dev/nbdX during key injection; so far I have
no explanation for that.
On Jan 22, 2014, at 4:02 AM, Jaromir Coufal wrote:
>
>
> On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
>> Hiya - Resource is actually a Heat term that corresponds to what we're
>> deploying within
>> the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1
>> Controller
>> and
On Jan 22, 2014, at 9:52 AM, Dougal Matthews wrote:
> On 22/01/14 14:31, Tzu-Mainn Chen wrote:
On 2014/22/01 10:00, Jaromir Coufal wrote:
>
>
> On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
>> Hiya - Resource is actually a Heat term that corresponds to what we're
>> deplo
On Jan 22, 2014, at 7:09 AM, Jaromir Coufal wrote:
>
>
> On 2014/22/01 10:00, Jaromir Coufal wrote:
>>
>>
>> On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
>>> Hiya - Resource is actually a Heat term that corresponds to what we're
>>> deploying within
>>> the Overcloud Stack - i.e., if we specif
> On Jan 22, 2014, at 7:09 AM, Jaromir Coufal wrote:
>
> >
> >
> > On 2014/22/01 10:00, Jaromir Coufal wrote:
> >>
> >>
> >> On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
> >>> Hiya - Resource is actually a Heat term that corresponds to what we're
> >>> deploying within
> >>> the Overcloud Stack
> On Jan 22, 2014, at 4:02 AM, Jaromir Coufal wrote:
>
> >
> >
> > On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
> >> Hiya - Resource is actually a Heat term that corresponds to what we're
> >> deploying within
> >> the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1
> >> Co
Oh dear user... :)
I'll step a little bit back. We need to agree if we want to name
concepts one way in the background and other way in the UI for user (did
we already agree on this point?). We all know pros and cons. And I will
still fight for users to get global infrastructure terminology (
Hey everybody,
I am sending updated wireframes.
http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-22_tripleo-ui-icehouse.pdf
Updates:
* p15-18 for down-scaling deployment
Any questions are welcome, I am happy to answer them.
-- Jarda
On 2014/16/01 01:50, Jaromir Coufal wrote:
Hi f
On Jan 22, 2014, at 10:53 AM, Jaromir Coufal wrote:
> Oh dear user... :)
>
> I'll step a little bit back. We need to agree if we want to name concepts one
> way in the background and other way in the UI for user (did we already agree
> on this point?). We all know pros and cons. And I will st
On Jan 20, 2014, at 3:02 AM, Jaromir Coufal wrote:
> Hello everybody,
>
> based on feedback which I received last week, I am sending updated
> wireframes. They are still not completely final, more use-cases and smaller
> updates will occur, but I believe that we are going forward pretty well.
Hey everyone I have run into an issue with the configuration parameter URI.
I'd like some input on what the URI might look like for getting the list
configuration parameters for a specific datastore.
Problem: Configuration parameters need to be selected per datastore.
Currently: Its setup to use
Ian,
I think the last "two attributes" PDF from Shixiong's last email is trying to
solve the problem you are saying, right?
—
Xu Han Peng (xuhanp)
On Wed, Jan 22, 2014 at 8:15 PM, Ian Wells wrote:
> On 21 January 2014 22:46, Veiga, Anthony
> wrote:
>>
>>Hi, Sean and Xuhan:
>>
>> I tota
I don't know if it's reasonable to expect a deployment of OpenStack that
has an *external* DHCP server. It's certainly hard to imagine how you'd
get the Neutron API and an external DHCP server to agree on an IP
assignment, since OpenStack expects to be the source of truth.
--
Sean M. Collins
Thanks for the update!
One question - is it possible to move the "Deploying Status" bar from page 12
to page 14?
The reason is that the former looks like a "Deployment Creation" page, while
the latter is
a "Deployment Detail" page. For me, the former is about sending parameters to
the API to
On Wed, Jan 22, 2014 at 1:05 AM, Public Mail wrote:
> Hi All,
>
> I have two questions ...
>
> 1) Glance v1 APIs can take a --location argument when creating an image
>but v2 APIs can't - bug or feature? (Details below)
>
I'd call that a missing feature. I think we probably need
On 01/22/2014 03:01 AM, Robert Collins wrote:
I certainly think having the MTU set to the right value is important.
I wonder if there's a standard way we can signal the MTU (e.g. in the
virtio interface) other than DHCP. Not because DHCP is bad, but
because that would work with statically injecte
Thanks for spotting that one Mark! Good catch!
I've put together a quick test case and patch for this.
https://review.openstack.org/#/c/68420
Thanks again.
Tom
On Tue, Jan 21, 2014 at 10:48:40PM -0800, Mark Washenberger wrote:
> I found the cause. When using role-based protections, instead of st
I like #4 over #5 because it seems weird to have to create a configuration
first to see what parameters are allowed. With #4 you could look up what is
allowed first then create your configuration.
Robert
On Jan 22, 2014 10:18 AM, "Craig Vyvial" wrote:
> Hey everyone I have run into an issue with
I've been thinking a bit more about how TripleO updates are developing
specifically with regards to compute nodes. What is commonly called the "update
story" I think.
As I understand it we expect people to actually have to reboot a compute node
in the cluster in order to deploy an update. This
On 2014-01-22 06:32, Sean Dague wrote:
I think we need to graduate things to stable interfaces a lot faster.
Realizing that stable just means "have to deprecate to change it". So
the interface is still changeable, just requires standard deprecation
techniques. Which we are trying to get more pyth
On 22/01/14 10:59 -0600, Ben Nemec wrote:
On 2014-01-22 06:32, Sean Dague wrote:
I think we need to graduate things to stable interfaces a lot faster.
Realizing that stable just means "have to deprecate to change it". So
the interface is still changeable, just requires standard deprecation
techn
Hi,
Though cpu/disk/ram stats are overcommitted in openstack, hypervisor summary
page in horizon UI displays the actual stats on compute node instead of
overcommitted values calculated in openstack. This gives incorrect data to the
user while provisioning instances as the used value of cpu/disk
Excerpts from Dan Prince's message of 2014-01-22 09:17:24 -0800:
> I've been thinking a bit more about how TripleO updates are developing
> specifically with regards to compute nodes. What is commonly called the
> "update story" I think.
>
> As I understand it we expect people to actually have to
- Original Message -
> From: "Clint Byrum"
> To: "openstack-dev"
> Sent: Wednesday, January 22, 2014 12:45:45 PM
> Subject: Re: [openstack-dev] [TripleO] our update story: can people live
> with it?
>
> Excerpts from Dan Prince's message of 2014-01-22 09:17:24 -0800:
> > I've bee
My thoughts so far:
/datastores//configuration/parameters (Option Three)
+ configuration set without an associated datastore is meaningless
+ a configuration set must be associated to exactly one datastore
+ each datastore must have 0-1 configuration set
+ All above relationships are immediately a
Hi everyone,
Milestone-proposed branches were created for Keystone, Glance, Nova,
Neutron, Cinder, Ceilometer, Heat and and Trove in preparation
for the icehouse-2 milestone publication tomorrow.
Horizon should be there in a few hours.
You can find candidate tarballs at:
http://tarballs.openstac
Hi everyone,
A milestone-proposed branch was created for Swift in preparation for the
1.12.0 release.
Please test the proposed delivery to ensure no critical regression found
its way in. Release-critical fixes might be backported to the
milestone-proposed branch until final release, and will be t
Another tricky bit left is how to handle service restarts as needed?
Thanks,
Kevin
From: Dan Prince [dpri...@redhat.com]
Sent: Wednesday, January 22, 2014 10:15 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev]
On 01/22/2014 12:17 PM, Dan Prince wrote:
> I've been thinking a bit more about how TripleO updates are developing
> specifically with regards to compute nodes. What is commonly called the
> "update story" I think.
>
> As I understand it we expect people to actually have to reboot a compute node
Clint wrote:
> I would call your e-mail a documentation/roadmap bug. This plan may
> have been recorded somewhere, but for me it has just always been in my
> head as the end goal (thanks to Robert Collins for drilling the hole
> and pouring it in there btw ;).
I found the following links helpful i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/22/2014 09:38 AM, Sean Dague wrote:
> Thanks to everyone that's been pitching in digging on reset bugs.
> More help is needed. Many core reviewers are at this point
> completely ignoring normal reviews until the gate is back, so if
> you are wait
Excerpts from Dan Prince's message of 2014-01-22 10:15:20 -0800:
>
> - Original Message -
> > From: "Clint Byrum"
> > To: "openstack-dev"
> > Sent: Wednesday, January 22, 2014 12:45:45 PM
> > Subject: Re: [openstack-dev] [TripleO] our update story: can people live
> > with it?
> >
>
- Original Message -
> Oh dear user... :)
>
> I'll step a little bit back. We need to agree if we want to name
> concepts one way in the background and other way in the UI for user (did
> we already agree on this point?). We all know pros and cons. And I will
> still fight for users to g
On Wed, 2014-01-22 at 13:15 -0500, Dan Prince wrote:
>
> - Original Message -
> > From: "Clint Byrum"
> > To: "openstack-dev"
> > Sent: Wednesday, January 22, 2014 12:45:45 PM
> > Subject: Re: [openstack-dev] [TripleO] our update story: can people live
> > with it?
> >
> > Excerpts
Agreed, it is tricky if we try to only restart what we've changed.
OR, just restart everything. We can make endpoints HA and use rolling
updates to avoid spurious faults.
There are complex ways to handle things even smoother.. but I go back to
"What does complexity cost?"
Excerpts from Fox, Kevi
Greetings,
I'd be interested in your opinions and feedback on the following blueprint:
https://blueprints.launchpad.net/swift/+spec/domain-level-quotas
The idea is to have a middleware checking a domain's current usage against a
limit set in the configuration before allowing an upload. The doma
Sean, I agree with you. I prefer OpenStack as the single source of truth. What
end user chooses may be different. But with this pair of keywords, at least we
provide comprehensive coverage on all scenarios.
For Icehouse, I suggest we only consider the supports for the scenarios that
OpenStack h
That is correct, Xu Han!
> On Jan 22, 2014, at 11:14 AM, "Xuhan Peng" wrote:
>
> Ian,
>
> I think the last "two attributes" PDF from Shixiong's last email is trying to
> solve the problem you are saying, right?
> —
> Xu Han Peng (xuhanp)
>
>
>> On Wed, Jan 22, 2014 at 8:15 PM, Ian Wells
Greetings,
I'd be interested in some opinions and feedback on the following blueprint:
https://blueprints.launchpad.net/ceilometer/+spec/quotas-on-alarms
I think it'd be interesting to allow admins to limit the number of running
alarms at any of the three levels defined by keystone. Thoughts ?
Agreed. That would be a good place for that check.
Carl
On Wed, Jan 22, 2014 at 6:40 AM, Paul Ward wrote:
> Thanks for your input, Carl. You're right, it seems the more appropriate
> place for this is _validate_subnet(). It checks ip version, gateway, etc...
> but not the size of the subnet.
Hi
Looks good approach. Lets start discussion.
I propose API spec for it
https://gist.github.com/andreyshestakov/8559309
Please look it and add your advices and comments.
Thanks
On Thu, Nov 21, 2013 at 2:44 AM, McReynolds, Auston
wrote:
> With "Multiple Datastore Types/Versions" merged to mas
Hello.
On Tue, Jan 21, 2014 at 12:52 PM, Dong Liu wrote:
> What's your opinion?
>
We've just discussed a use case for this today. I want to create a sandbox
for Fuel but I can't do it with OpenStack.
The reason is a bit different from telecom case: Fuel needs to manage nodes
directly via DHCP a
Yuriy Taraday wrote:
>Fuel needs to manage nodes directly via DHCP and PXE and you can't do that
>with Neutron since you can't make its >dnsmasq service quiet.
Can you elaborate on what you mean by this? You can turn of Neutron’s dnsmasq
on a per network basis, correct? Do you mean something el
On Jan 22, 2014, at 10:19 AM, Kaleb Pomeroy wrote:
> My thoughts so far:
>
> /datastores//configuration/parameters (Option Three)
> + configuration set without an associated datastore is meaningless
> + a configuration set must be associated to exactly one datastore
> + each datastore must have
Hi folks,
At this point we have a few major action items, mostly patches on review.
Please note that the gate is in pretty bad shape, so don't expect anything
to be approved/merged until this is sorted out.
1) SSL extension
https://review.openstack.org/#/c/63510/
The code here is in a good shape
On Thu, Jan 16, 2014 at 10:32 AM, Thierry Carrez wrote:
> James Slagle wrote:
>> [...]
>> And yes, I'm volunteering to do the work to support the above, and the
>> release work :).
>
> Let me know if you have any question or need help. The process and tools
> used for the integrated release are de
Hi All,
Are we using tools/install_venv_common.py in python-troveclient,
If so just let us know.
Otherwise, it may be cleaned up (removing it from openstack-common.conf)
Thanks.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http:
Excerpts from Jay Pipes's message of 2014-01-22 10:53:14 -0800:
> On Wed, 2014-01-22 at 13:15 -0500, Dan Prince wrote:
> >
> > - Original Message -
> > > From: "Clint Byrum"
> > > To: "openstack-dev"
> > > Sent: Wednesday, January 22, 2014 12:45:45 PM
> > > Subject: Re: [openstack-dev] [
I think most of the time taken to reboot is spent in bringing down/up the
services though, so I'm not sure what it really buys you if you do it all. It
may let you skip the crazy long bootup time on "enterprise" hardware, but that
could be worked around with kexec on the full reboot method too.
On Tue, 2014-01-21 at 01:15 -0500, Yair Fried wrote:
> I seem to be unable to convey my point using generalization, so I will give a
> specific example:
> I would like to have "update dns server" as an additional network scenario.
> Currently I could add it to the existing module:
>
> 1. tests c
Goodday to all.
#3 looks more than acceptable.
/datastores//configuration/parameters.
According to configuration parameters design, a configuration set must be
associated to exactly one datastore.
Best regards, Denis Makogon.
2014/1/22 Michael Basnight
> On Jan 22, 2014, at 10:19 AM, Kaleb Po
On Jan 22, 2014, at 1:53 PM, Jay Pipes wrote:
> On Wed, 2014-01-22 at 13:15 -0500, Dan Prince wrote:
>>
>> - Original Message -
>>> From: "Clint Byrum"
>>> To: "openstack-dev"
>>> Sent: Wednesday, January 22, 2014 12:45:45 PM
>>> Subject: Re: [openstack-dev] [TripleO] our update story:
Excerpts from Fox, Kevin M's message of 2014-01-22 12:19:56 -0800:
> I think most of the time taken to reboot is spent in bringing down/up the
> services though, so I'm not sure what it really buys you if you do it all. It
> may let you skip the crazy long bootup time on "enterprise" hardware, bu
On Thu, Jan 23, 2014 at 12:04 AM, CARVER, PAUL wrote:
>
> Can you elaborate on what you mean by this? You can turn of Neutron’s
> dnsmasq on a per network basis, correct? Do you mean something else by
> “make its dnsmasq service quiet”?
>
What I meant is for dnsmasq to not send offers to specifi
On 01/22/2014 03:19 PM, Jay Pipes wrote:
On Tue, 2014-01-21 at 01:15 -0500, Yair Fried wrote:
I seem to be unable to convey my point using generalization, so I will give a
specific example:
I would like to have "update dns server" as an additional network scenario.
Currently I could add it to
Changes coming in gate structure
Unless you've been living under a rock, on the moon, around Saturn,
you'll have noticed that the gate has been quite backed up the last 2
weeks. Every time we get towards a milestone this gets measur
On Wed, 2014-01-22 at 12:12 -0800, Clint Byrum wrote:
> Excerpts from Jay Pipes's message of 2014-01-22 10:53:14 -0800:
> > On Wed, 2014-01-22 at 13:15 -0500, Dan Prince wrote:
> > >
> > > - Original Message -
> > > > From: "Clint Byrum"
> > > > To: "openstack-dev"
> > > > Sent: Wednesda
On Wed, Jan 22, 2014 at 1:39 PM, Sean Dague wrote:
>
> Changes coming in gate structure
>
>
> Unless you've been living under a rock, on the moon, around Saturn,
> you'll have noticed that the gate has been quite backed up the last
Excerpts from Keith Basil's message of 2014-01-22 12:27:50 -0800:
> On Jan 22, 2014, at 1:53 PM, Jay Pipes wrote:
>
> > On Wed, 2014-01-22 at 13:15 -0500, Dan Prince wrote:
> >>
> >> - Original Message -
> >>> From: "Clint Byrum"
> >>> To: "openstack-dev"
> >>> Sent: Wednesday, January
Another +1 for option 3.
Greg
On Jan 22, 2014, at 2:27 PM, Denis Makogon
mailto:dmako...@mirantis.com>> wrote:
Goodday to all.
#3 looks more than acceptable.
/datastores//configuration/parameters.
According to configuration parameters design, a configuration set must be
associated to exactly
On Tue, Jan 21, 2014 at 7:35 PM, Dugger, Donald D wrote:
> Well, the first goal is to get the scheduler code into a separate tree,
> even though that code is still utilizing common code from nova. Right now
> just about every scheduler file includes some nova modules. Ultimately
> yes, we want
Maybe I misunderstand, but I thought:
kexec - lets you boot a new kernel/initrd starting at the point a boot loader
would skipping the bios init. All previous running processes are not running in
the new boot just like a normal reboot.
CRIU - Lets you snapshot/restart running processes.
While
On Wed, 2014-01-22 at 15:39 -0500, Sean Dague wrote:
>
> ==
> Executive Summary
> ==
> To summarize, the effects of these changes will be:
>
> - 1) Decrease the impact of failures resetting the entire gate queue
>by doing the heavy testing in t
On Wed, Jan 22, 2014 at 3:22 AM, Flavio Percoco wrote:
> On 21/01/14 13:14 -0500, Joe Gordon wrote:
>
>>
>> On Jan 17, 2014 12:24 AM, "Flavio Percoco" wrote:
>>
>>>
>>> On 16/01/14 17:32 -0500, Doug Hellmann wrote:
>>>
On Thu, Jan 16, 2014 at 3:19 PM, Ben Nemec
wrote:
1 - 100 of 141 matches
Mail list logo
