Michael has been posting very informative blogs on the summary of the mid-cycle
meetups for Nova. The one on the Nova Network to Neutron migration was of
particular interest to me as it raises a number of potential impacts for the
CERN production cloud. The blog itself is at
On 21 Aug 2014, at 12:38, Thierry Carrez thie...@openstack.org wrote:
Tim Bell wrote:
Michael has been posting very informative blogs on the summary of the
mid-cycle meetups for Nova. The one on the Nova Network to Neutron
migration was of particular interest to me as it raises a number
-Original Message-
From: John Dickinson [mailto:m...@not.mn]
Sent: 23 August 2014 03:20
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale
PTLs
I think Anne makes some excellent points about
From: Michael Still [mailto:mi...@stillhq.com]
Sent: 25 August 2014 23:38
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] Migration from nova-network to
Neutron for large production clouds
...
Mark McClain and I discussed a
-Original Message-
From: Michael Still [mailto:mi...@stillhq.com]
Sent: 26 August 2014 22:20
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] Migration from nova-network to
Neutron for large production clouds
...
Mark
-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org]
Sent: 04 September 2014 16:59
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Zaqar] Comments on the concerns arose during
the TC meeting
Sean Dague wrote:
[...]
So, honestly, I'll
]
Sent: 05 September 2014 19:11
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Zaqar] Comments on the concerns arose during the
TC meeting
On Fri, Sep 5, 2014 at 4:27 AM, Thierry Carrez
thie...@openstack.orgmailto:thie...@openstack.org wrote:
Tim
The End User working group is being described at
https://wiki.openstack.org/wiki/End_User_Working_Group. Chris Kemp is
establishing the structure.
This page covers how to get involved...
Tim
From: Brad Topol [mailto:bto...@us.ibm.com]
Sent: 08 September 2014 19:50
To: OpenStack Development
It would be great if each OpenStack component could provide a maintenance mode
like this… there was some work being considered on Cells
https://blueprints.launchpad.net/nova/+spec/disable-child-cell-support which
would have allowed parts of Nova to indicate they were in maintenance.
Something
-Original Message-
From: Stefano Maffulli [mailto:stef...@openstack.org]
Sent: 10 September 2014 19:29
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Zaqar] Comments on the concerns arose during
the TC meeting
On 09/05/2014 12:36 PM, Tim Bell wrote:
How
Has Kristy's patch made it into Juno ?
Tim
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: 17 September 2014 15:37
To: openstack-dev@lists.openstack.org; Kristy Siu
Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
Hi Adam
On 22 Sep 2014, at 20:53, Doug Hellmann d...@doughellmann.com wrote:
On Sep 19, 2014, at 6:29 AM, Thierry Carrez thie...@openstack.org wrote:
Monty Taylor wrote:
I've recently been thinking a lot about Sean's Layers stuff. So I wrote
a blog post which Jim Blair and Devananda were kind
Seems like there is some overlap with the end user (i.e. consumer) working
group at https://wiki.openstack.org/wiki/End_User_Working_Group
Sounds like it would be worth discussing with them on how to focus on these
needs. The scope of the end user is much larger than just the API but a
+1
There is also the use case where a new service is being introduced for everyone
eventually but you wish to start with a few friends. In the event of problems,
the effort to tidy up is much less. Documentation can be updated with the
production environment.
Tim
-Original Message-
There appears to be some overlap of this proposal with 'climate' which provides
a resource reservation system.
They meet regularly ... see https://wiki.openstack.org/wiki/Meetings/Climate
for contacts.
Tim
From: Alan Tan [mailto:y...@students.waikato.ac.nz]
Sent: 16 December 2013 23:42
To:
I'm not sure how Climate would map to the non-predictable nature of the
workload. I had understood Climate as providing a booking system to reserve
resources in the future (which is a valuable use case but not quite the problem
Ulrich is describing of delegation of quota).
Looking at
I think there is a need for an incompatible change review process which
includes more of the community than just those performing the code reviews.
This kind of change can cause a lot of disruption for those of us running
clouds so it is great to see that you are looking for more input.
In
I think there also needs to be a scalability best practise and reference
architecture.
Benchmarking allows us to identify problems with the code but we also need some
community wisdom on how to deploy at scale.
Does this fit within Rally or can you advise where this community wisdom should
: bo...@pavlovic.ru [mailto:bo...@pavlovic.ru] On Behalf Of Boris Pavlovic
Sent: 28 December 2013 21:02
To: OpenStack Development Mailing List (not for usage questions)
Cc: Ali Beddah; Tim Bell
Subject: Re: [openstack-dev] Announce of Rally - benchmarking system for
OpenStack
Ali Gamal,
?
Tim
There is a big difference between DocImpact (i.e. needing some improvements to
the doc) and putting the migration effort onto the users without automation to
help... as I have said previously, while this (and others like it) may be a
worthwhile change in isolation, making the upgrade process
- Changes in default behaviour: Always likely to affect existing systems in
some way. Maybe we should have an additional type of review vote that comes
from people who are recognised as reperensting large production deployments ?
This is my biggest worry... there are changes which may
Thinking using inotify/configuration file changes to implement dynamic meters,
this would be limited to administrators of ceilometer itself (i.e. with write
access to the file) rather than the project administrators (as defined by
keystone roles). Thus, as a project administrator who is not
+1 from me too UpgradeImpact is a much better term.
Tim
-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: 07 January 2014 17:53
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] minimum review period for functional
changes that break
for projects, what was mentioned by Tim Bell in a previous
email. This would mean that the project administrator is able to create a data
collection configuration for his/her own project, which will not affect the
other project's configuration. The tenant would be able to specify meters
(enabled
: [openstack-dev] [nova] minimum review period for functional
changes that break backwards compatibility
Jay Pipes wrote:
On Wed, 2014-01-08 at 14:26 +0100, Thierry Carrez wrote:
Tim Bell wrote:
+1 from me too UpgradeImpact is a much better term.
So this one is already documented[1], but I
Is the impact of dropping XML understood for the users of the OpenStack APIs ?
Tim
-Original Message-
From: Alex Xu [mailto:x...@linux.vnet.ibm.com]
Sent: 15 January 2014 14:33
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [rfc]
Is there overlap with https://launchpad.net/kwapi and
https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer ?
Tim
From: Gao, Fengqian [mailto:fengqian@intel.com]
Sent: 23 January 2014 06:25
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Nova]
This is exactly my worry... at what point can I consider moving to MariaDB with
the expectation that the testing confidence is equivalent to that which is
currently available from MySQL ?
The on-disk format is not so much a concern but there are many potential subtle
differences in the API
I'm not seeing a path to migrate 1,000s of production VMs from nova network to
Neutron.
Can someone describe how this can be done without downtime for the VMs ?
Can we build an approach for the cases below in a single OpenStack production
cloud:
1. Existing VMs to carry on running without
Jay,
We've got a similar requirement at CERN where we would like to have pools of
ip/mac combinations for each subnet and have it so that the user is just
allocated one (and for the same subnet that the hypervisor is on).
We've not found a good solution so far.
Tim
-Original
Are these hooks generic enough to be included upstream ? This may solve a
problem we've been struggling with.
Tim
-Original Message-
From: Collins, Sean [mailto:sean_colli...@cable.comcast.com]
Sent: 20 February 2014 22:59
To: OpenStack Development Mailing List (not for usage
The recent operator gathering
(https://etherpad.openstack.org/p/operators-feedback-mar14) concluded a similar
proposal, based on Blueprint-on-Blueprints (BoB for short).
The aim was that operators of production OpenStack clouds should engage to give
input at an early stage
- Raising concerns
If the deleted column is removed, how would the 'undelete' functionality be
provided ? This saves operators when user accidents occur since restoring the
whole database to a point in time affects the other tenants also.
Tim
Hi all,
I've never understood why we treat the DB as a LOG
Typical cases are user error where someone accidentally deletes an item from a
tenant. The image guys have a good structure where images become unavailable
and are recoverable for a certain period of time. A regular periodic task
cleans up deleted items after a configurable number of seconds
][db][performance] Proposal: Get rid of soft
deletion (step by step)
On Tue, Mar 11, 2014 at 12:43 PM, Tim Bell
tim.b...@cern.chmailto:tim.b...@cern.ch wrote:
Typical cases are user error where someone accidentally deletes an item from a
tenant. The image guys have a good structure where
-
From: Tim Bell [mailto:tim.b...@cern.ch]
Sent: Tuesday, March 11, 2014 15:43
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][db][performance] Proposal: Get rid
of soft deletion (step by step)
Typical cases are user error where someone
If you want to archive images per-say, on deletion just export it to a
'backup tape' (for example) and store enough of the metadata
on that 'tape' to re-insert it if this is really desired and then delete it
from the database (or do the export... asynchronously). The
same could be said
I think we need to split the scenarios and focus on the end user experience
with the cloud
a few come to my mind from the CERN experience (but this may not be all):
1. Accidental deletion of an object (including meta data)
2. Multi-level consistency (such as between Cell API and child
+1 .. looks like it would cover the accidental use case. Something could then
be included into oslo for standardisation.
Tim
From: Boris Pavlovic [mailto:bpavlo...@mirantis.com]
Sent: 13 March 2014 20:42
To: OpenStack Development Mailing List
Subject: [openstack-dev] [db][all] (Proposal)
Glance provides a very nice set up for this
- Default is no delayed deletion
- Length of time before scrubbing is configurable
- The clean up process is automated using the glance scrubber which can be run
as a standalone job or as a daemon
Tim
-Original Message-
From: Radomir
Interesting proposal... there would also be a benefit of different tables per
program from an operational perspective. If I need to recover a database for
any reason, having different tables would ensure that I could restore glance to
a point in time without having to lose the nova delete
If UCA is required, what would be the upgrade path for a currently running
OpenStack Havana site to Icehouse with this requirement ?
Would it be an online upgrade (i.e. what order to upgrade the different
components in order to keep things running at all times) ?
Tim
From: Chmouel Boudjnah
+1 for performance analysis to understand what needs to be optimised. Metering
should be light-weight.
For those of us running in production, we don't have an option to turn
ceilometer off some of the time. That we are not able to run through the gate
tests hints that there are optimisations
][QA][Tempest][Infra] Ceilometer
tempest testing in gate
Tim, yep. If you use one db for Ceilometer and Nova then nova's performance may
be affected. I've seen this issue.
Will start profiling ASAP.
On Thu, Mar 20, 2014 at 3:59 PM, Tim Bell
tim.b...@cern.chmailto:tim.b...@cern.ch wrote:
+1
I am a strong advocate of the Blueprint-on-Blueprints process we discussed in
the operator mini-summit so that experienced cloud administrators can give
input before lots of code is written
(https://etherpad.openstack.org/p/operators-feedback-mar14) but we need to be
aware that these people
How does this interact with cells ? Can the cell API instances be upgraded
independently of the cells themselves ?
My ideal use case would be
- It would be possible to upgrade one of the cells (such as a QA environment)
before the cell API nodes
- Cells can be upgraded one-by-one as needed by
:31 PM, Tim Bell tim.b...@cern.ch wrote:
How does this interact with cells ? Can the cell API instances be upgraded
independently of the cells themselves ?
My ideal use case would be
- It would be possible to upgrade one of the cells (such as a QA
environment) before the cell API
My assumption on the depreciation messages is that this is targeted at non-core
OpenStack applications.
OpenStack developer pressure should be established within the projects, not by
overwhelming production clouds with logs that something is depreciated.
Equally, asking locally developed
Anne,
From my understanding, Trove is due to graduate in the Juno release.
Is documentation for developers, operators and users not one of the criteria
(http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements)
?
* Documentation / User support
**
/install/yum/content/ ?
Tim
From: Anne Gentle [mailto:a...@openstack.org]
Sent: 06 April 2014 20:33
To: OpenStack Development Mailing List (not for usage questions)
Cc: Glen Campbell; openstack-d...@lists.openstack.org
Subject: Re: [openstack-dev] Doc for Trove ?
On Sun, Apr 6, 2014 at 12:44 PM, Tim
My worry is that many deployers are waiting for programs to reach integrated
before looking at them in detail. When something is announced as integrated,
there is an expectation that the TC criteria are met.
When there is no installation documentation or end user CLI or dashboard
information,
I have proposed the summit design session for Hong Kong
(http://summit.openstack.org/cfp/details/103) to discuss exactly these sort of
points. We have the low level Nova commands but need a service to automate the
process.
I see two scenarios
- A hardware intervention needs to be scheduled,
/ceilometer/+spec/monitoring-physical-devices
--
Best regards,
Oleg Gelbukh
Mirantis Labs
On Wed, Oct 9, 2013 at 9:26 AM, Tim Bell
tim.b...@cern.chmailto:tim.b...@cern.ch wrote:
I have proposed the summit design session for Hong Kong
(http://summit.openstack.org/cfp/details/103) to discuss exactly
From the user perspective, splitting off the projects seems to be focussing on
the ease of commit compared to the final user experience. An 'extras' project
without *strong* testing co-ordination with packagers such as SUSE and RedHat
would end up with the consumers of the product facing the
A partial slot to discuss how to achieve the vision in
https://wiki.openstack.org/wiki/DomainQuotaManagementAndEnforcement would be
useful.
The goal is to avoid duplicate effort which could be focused on a single theme.
With the various collaborations between HP, CERN and BARC along with
From a user perspective, I want that a gate on changes which significantly
degrade performance to be rejected.
Tempest (and its associated CI) provide a current check on functionality. It is
inline and understood.
Let's just add a set of benchmarks to Tempest which can validate that improved
Is it easy ? No... it is hard, whether in an integrated test suite or on its own
Can it be solved ? Yes, we have done incredible things with the current QA
infrastructure
Should it be split off from other testing ? No, I want EVERY commit to have
this check. Performance through benchmarking at
It is not just the development effort but also those users who rely on tempest
to probe their production environments. If there is a second project, they'd
have to configure the endpoints, user accounts etc. in both systems.
In my view, this cannot be done at the gate, it would take too long
We also need some standardisation on the command line options for the client
portion (such as --os-auth-method, --os-x509-cert etc.) . Unfortunately, this
is not yet in Oslo so there would be multiple packages to be enhanced.
Tim
-Original Message-
From: Alan Sill
As a speaker of the Queen's English, I find flavor to be incorrect. Does that
mean I can -1 any patch that does not use flavour ?
At CERN, we are working with 130 countries in a single community. The value of
the contribution of non-english speakers far exceeds the occasional
Can we make sure that the costs for the end users are also considered as part
of this ?
- Configuration management will need further modules
- Dashboard confusion as we get multiple tabs
- Accounting, Block Storage, Networking, Orchestration confusion as
the
Starting from the existing code also makes migration for production
environments currently using the code much easier.
Support those of us running production OpenStack clouds needs to be one of the
major development concerns as people reflect on refactoring along with making
sure we don't make
Horizon uses Project in the user interface, yet the openstack.rc file contains
tenant_id and tenant_name. It makes it very difficult to write user guides
given that such a fundamental concept has two names.
No problem to maintain compatibility (i.e. try OS_TENANT_NAME after
OS_PROJECT_NAME)
To be clear, I don't care Tenant vs Project. However, I do care that we should
not continue this confusion.
One or the other... but not both and a plan to depreciate the other. Naturally,
at least 1 release backwards compatibility for environment variables or APIs.
Tim
From: Dean Troyer
Can we get a TC policy that 'project' is the standard and that all projects
using tenant should plan a smooth migration path to project along with the
timescales for implementation and retirement of tenant ?
Tim
From: Christopher Yeoh [mailto:cbky...@gmail.com]
Sent: 26 November 2013 12:48
Completely agree with Brad... a new project for this is not what is needed.
From an operator's point of view, it is a REAL, REAL, REAL pain to be
configuring yet another project, yet another set of Puppet/Chef recipes,
additional monitoring, service nodes, new databases, more documentation,
-Original Message-
From: Sean Dague [mailto:s...@dague.net]
Sent: 12 June 2014 17:37
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Gate proposal - drop Postgresql configurations in
the gate
...
But if we're talking about a devstack /
We have some projects which are dynamically creating VMs up to their quota.
Under some circumstances, as cloud administrators, we would like these projects
to shrink and make room for other higher priority work.
We had investigated setting the project quota below the current utilisation
(i.e.
Eric,
Thanks for sharing your work, it looks like an interesting development.
I was wondering how the Keystone token expiry is handled since the tokens
generally have a 1 day validity. If the request is scheduling for more than one
day, it would no longer have a valid token. We have similar
/07/2014 08:46, Tim Bell wrote:
Eric,
Thanks for sharing your work, it looks like an interesting development.
I was wondering how the Keystone token expiry is handled since the tokens
generally have a 1 day validity. If the request is scheduling for more than
one day, it would no longer have
Will this work will be built to exploit the existing federated authentication
and role mapping code in Icehouse ?
Resource discover/access/provisioning is a natural next step but I hope it is
built on the existing identity frameworks.
Tim
From: Tiwari, Arvind [mailto:arvind.tiw...@hp.com]
As we approach Juno-3, a number of specs have been correctly marked as
abandoned since they are not expected to be ready in time for the release.
Is there a mechanism to keep these specs open for discussion even though there
is no expectation that they will be ready for Juno and 'defer' them to
As I mentioned on the review, the title could cause confusion.
Rally tests performance and scalability but the title could lead people to
think that if you install Rally, you will get Performance and Scale from your
OpenStack instance. Adding Benchmark or Testing in to the description would
-Original Message-
From: Andrew Laski [mailto:andrew.la...@rackspace.com]
Sent: 11 April 2014 16:38
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Dynamic scheduling
On 04/10/14 at 11:33pm, Oleg Gelbukh wrote:
Andrew,
...
Can Heat control/monitor a VM which it has not created and restart it
(potentially on a different hypervisor with live migration) ?
Tim
-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: 14 April 2014 19:21
To: openstack-dev@lists.openstack.org
Subject: Re:
wrote:
On 04/14/2014 10:46 AM, Tim Bell wrote:
Can Heat control/monitor a VM which it has not created and restart it
(potentially on a different hypervisor with live migration) ?
Tim
Tim,
No it sure can't.
But a 10-20 line shell script could, calling nova CLI commands.
I
As a native English speaker who works in two Francophone countries for an
international organisation, I would suggest tolerance in this area.
Where there are sufficient language difficulties that the blueprint is
difficult to read and understand, this should be a -1.
Where someone
Joe,
There are a number of problem reports on ceilometer performance and some
promising blueprints to address them. I'd suggest we re-run the performance
test when those are in place. Having reference performance tests such as this
are helpful to pick up cases where there are regression or
-Original Message-
From: Adam Young [mailto:ayo...@redhat.com]
Sent: 28 May 2014 18:23
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone] Redesign of Keystone Federation
On 05/28/2014 11:59 AM, David Chadwick wrote:
Hi Everyone
at the Atlanta
A further vote to maintain compatibility . One of the key parts to a good
federation design is to be using it in the field and encountering real life
problems.
Production sites expect stability of interfaces and functions. If this cannot
be reasonably ensured, the federation function
inline...
On 09/22/2014 03:11 PM, Tim Bell wrote:
The quality designation is really important for the operator community
who are trying to work out what we can give to our end users.
So, I think it's important to point out here that there are three different
kinds of
operators
Alison,
Can you give some more details on the survey with respect to OpenStack ? I have
both a developer contribution policy survey and a project contribution policy
survey.
It would also be good to have more background as to the interest in obtaining
the survey results and what you intend to
-Original Message-
From: John Garbutt [mailto:j...@johngarbutt.com]
Sent: 30 September 2014 15:35
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack
cascading
On 30 September 2014 14:04,
-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: 14 October 2014 19:01
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Automatic evacuate
On 10/13/2014 05:59 PM, Russell Bryant wrote:
Nice timing. I was working on a blog post on this
-Original Message-
From: Christopher Aedo [mailto:d...@aedo.net]
Sent: 21 October 2014 04:45
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [All] Maintenance mode in OpenStack during
patching/upgrades
...
Also, I would like to see
-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com]
Sent: 21 October 2014 13:08
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Summit] Coordination between OpenStack
lower layer virt stack (libvirt, QEMU/KVM)
On
Chris,
Thanks for your work on cells in OpenStack nova... we're heavily exploiting it
to scale out the CERN cloud.
Tim
-Original Message-
From: Chris Behrens [mailto:cbehr...@codestud.com]
Sent: 22 October 2014 19:37
To: OpenStack Development Mailing List (not for usage questions)
-Original Message-
From: Andrew Laski [mailto:andrew.la...@rackspace.com]
Sent: 22 October 2014 21:12
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] Cells conversation starter
On 10/22/2014 12:52 AM, Michael Still wrote:
Angus,
There are two groups which may be relevant regarding ‘consumers’ of Heat
-Application eco system working group at
https://wiki.openstack.org/wiki/Application_Ecosystem_Working_Group
-API working group at https://wiki.openstack.org/wiki/API_Working_Group
There are some
There is a formal structure via the OpenStack user committee and the associated
working groups
(https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee). We have
Monday afternoon and all of Thursday in the summit time dedicated to
discussions. The specs review process was prepared
-Original Message-
From: Carl Baldwin [mailto:c...@ecbaldwin.net]
Sent: 24 October 2014 19:05
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Travels tips for the Paris summit
+1
It would be great to know where to go in the airport
There were some discussions over the past years.
I raised the question of Swift tape support in my keynote in Boston in 2011
(http://www.slideshare.net/noggin143/cern-user-story) but there was limited
interest. LTFS makes it more likely but we should not underestimate the
challenges. Ensuring
.
On 14.11.14 20:43, Tim Bell wrote:
It would need to be tiered (i.e. migrate whole collections rather than
files) and a local catalog would be needed to map containers to tapes.
Timeouts would be an issue since we are often waiting hours for recall
(to ensure that multiple recalls for the same tape
-Original Message-
From: Tim Bell [mailto:tim.b...@cern.ch]
Sent: 17 November 2014 19:44
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [swift] LTFS integration with OpenStack Swift for
scenario like - Data Archival as a Service
Discussing with various people in the community, there seems to be interest in
a way to
- Identify when a hypervisor is being drained or is down and inventory
its VMs
- Find the best practise way of restarting that VM for hypervisors
still available
o Live migration
] Medium Availability VMs
From: Tim Bell tim.b...@cern.ch mailto:tim.b...@cern.ch
...
Discussing with various people in the community, there seems to be
interest in a way to
- Identify when a hypervisor is being drained or is down
and inventory its VMs
- Find
It would be interesting to compare candidates with who stood previously. I also
welcome elections but if the previous PTL is
standing down and there is only one new candidate, that is more healthy than a
single person consistently in the same position
(although maybe not ideal).
Are there any
-Original Message-
From: Tony Breeds [mailto:t...@bakeyournoodle.com]
Sent: 06 December 2014 06:39
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova] Fixing the console.log grows forever bug.
...
However I was encouraged to investigate fixing this in qemu, such
It would be great if we can get approval for the Hierachical Quota handling in
Nova too (https://review.openstack.org/#/c/129420/).
Tim
From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
Sent: 23 December 2014 01:22
To: OpenStack Development Mailing List (not for usage questions)
AM, Tim Bell
tim.b...@cern.chmailto:tim.b...@cern.ch wrote:
It would be great if we can get approval for the Hierachical Quota handling
in Nova too (https://review.openstack.org/#/c/129420/).
Nova's spec deadline has passed, but I think this is a good candidate for an
exception. We
1 - 100 of 276 matches
Mail list logo
