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.
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
> -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
> 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: 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
...
>
>
> -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,
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
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
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
> -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
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
Mistral can schedule the executions and then a workflow to do the server image
create.
The CERN implementation of this is described at
http://openstack-in-production.blogspot.com/2017/08/scheduled-snapshots.html
with the implementation at
https://gitlab.cern.ch/cloud-infrastructure/mistral-wo
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
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) bu
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
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:
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,
+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: ope
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
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 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
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,
?
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
> - 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
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 ?
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
+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
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
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
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] [
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
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
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
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---
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
> -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 qem
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)
Subject:
AM, "Tim Bell"
mailto: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
I think this is a good candidate for an
>exception. We will announce the process for asking for a formal spec
>exception shortly after new years.
>
From: Tim Bell [mailto:tim.b...@cern.ch]
Sent: 23 December 2014 19:02
To: OpenStack Development Mailing List (not for usage questions)
S
There must be other OpenStack services which have also faced this ‘stop
scheduling but keep replying’ issues. Can we make the names for the various
states and transitions consistent ?
Tim
From: Kyle Mestery [mailto:mest...@mestery.com]
Sent: 08 January 2015 16:26
To: OpenStack Development Maili
Let's ask the operators opinions too on openstack-operators mailing list. There
was some duplication during the summit between the tracks but there is also a
significant operator need outside the pure code area which comes along with the
big tent tagging for projects. We need to make sure that
Let's not forget that more than a quarter of OpenStack production deployments
are using the EC2 interface from my memory of the user survey. Our experience
is that the basic functionality is OK but you need to keep into the appropriate
subset.
Any plans for depreciation of the EC2 inside Nova
> -Original Message-
> From: Victor Lowther [mailto:victor.lowt...@gmail.com]
> Sent: 21 January 2015 21:06
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Ironic] RAID interface - backing disk hints
>
> On Tue, Jan 20, 2015 at 8:36 AM, Ji
This is often mentioned as one of those items which catches every OpenStack
cloud operator at some time. It's not clear to me that there could not be a
scheduled job built into the system with a default frequency (configurable,
ideally).
If we are all configuring this as a cron job, is there a
> -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
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: 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
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.
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 to
][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
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-
&
>
> 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
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
+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
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
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
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.
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
+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
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
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
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
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
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
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
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,
> -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:
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
> >
+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
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
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
On 22 Sep 2014, at 20:53, Doug Hellmann wrote:
>
> On Sep 19, 2014, at 6:29 AM, Thierry Carrez 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 enough to help me edit.
>>>
>>> h
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
consist
Monty talking about this :) Comments
> 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 p
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
> -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
> -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
> -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)
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 questio
> -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 d
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 w
> -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 a
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
hival as a Service .
>
> 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 r
> -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 Arc
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
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
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
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
cl
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
1 - 100 of 286 matches
Mail list logo
