> -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
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 g
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 Ma
ailto:dtro...@gmail.com]
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
mailto:thie...@openstack.org>> wrote:
Tim B
> -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,
> -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
...
>
>
> 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 discusse
> -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
On 21 Aug 2014, at 12:38, Thierry Carrez 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 n
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
http://www.stillhq.
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
cl
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
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]
Sen
ld advise how tokens could be renewed in
such a scenario.
Tim
On 01/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 d
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 sce
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.
> -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 dev
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 deploymen
> -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 A
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 sca
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 accidentally
+2
I think that there is also a need to verify the user story aspect. One of the
great things with the ability to subscribe to nova-specs is that the community
can give input early, when we can check on the need and the approach. I know
from the CERN team how the requirements need to be review
4 at 10:56 -0700, Steven Dake 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
> >
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:
> -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,
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,
/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
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
**
I’ve added the depreciation process to the section on meet the PTLs/TC for the
Atlanta Ops unconference
(https://etherpad.openstack.org/p/ATL-ops-unconference-RFC). Currently, it is
difficult to tell how much a particular feature is being used and the impact of
depreciation.
Tim
Sessions are
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 inte
t;
> On Mar 24, 2014, at 12:31 PM, Tim Bell 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 t
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
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 wi
meter][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
mailto:tim.b...@cern.ch>> wrote
+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 t
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 [m
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 data.
At CERN, we've had similar issues when enabling telemetry. Our resource-list
times out after 10 minutes when the proxies for HA assume there is no answer
coming back. Keystone instances per cell have helped the situation a little so
we can collect the data but there was a significant increase i
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 Dopi
+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) Restora
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 ins
>
> 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
mes infallible human beings as a design
> criteria is making an invalid assumption.
> >
> > --
> > Paul Carver
> > VO: 732-545-7377
> > Cell: 908-803-1656
> > E: pcar...@att.com
> > Q Instant Message
> >
> >
> > -Original Message-
&
][db][performance] Proposal: Get rid of soft
deletion (step by step)
On Tue, Mar 11, 2014 at 12:43 PM, Tim Bell
mailto: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 images
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 to
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
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
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 qu
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 Message---
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 dow
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 whi
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] Power/temperatu
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] [
org
> Subject: Re: [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
files.
Yes, the data collection was designed to be configured and controlled by the
deployer, not the tenant. What benefits do we gain by giving that control to
the tenant?
ildikov: Sorry, my explanation was not clear. I meant there the configuration
of data collection for projects, what was ment
+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 b
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 the
Is there a mechanism to tag changes as being potentially more appropriate for
the more ops related profiles ? I'm thinking more when someone proposes a
change they suspect could have an operations impact, they could highlight this
as being one for particular focus.
How about an OpsImpact tag ?
> - 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 ma
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 mor
From: 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,
?
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
be
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 the
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 https://b
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: ope
+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-
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,
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
To:
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 [mail
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) bu
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
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 concep
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
misunderstandings
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 [mailto:kilohoku.
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 bu
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
>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
Would the effort to do the following be substantial ?
- Nova doing the intelligent thing (i.e. choosing the best one for the job) by
default
- An operator override (do what I tell you in the config file)
Examples where I would want to use the operator override are
- If I upgrade Glance to 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 Mira
>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 th
ad.net/ceilometer/+spec/monitoring-physical-devices
--
Best regards,
Oleg Gelbukh
Mirantis Labs
On Wed, Oct 9, 2013 at 9:26 AM, Tim Bell
mailto: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 these
ors.html#module-nova.api.openstack.compute.contrib.hypervisors
[3]
https://blueprints.launchpad.net/ceilometer/+spec/monitoring-physical-devices
--
Best regards,
Oleg Gelbukh
Mirantis Labs
On Wed, Oct 9, 2013 at 9:26 AM, Tim Bell wrote:
I have proposed the summit design session for Hong Kong
(http://summit.openstack.org/cfp/details/
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, pl
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 s
] Medium Availability VMs
> From: Tim Bell 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
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
201 - 286 of 286 matches
Mail list logo
