Re: [openstack-dev] [nova] Can we deprecate the server backup API please?

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

Re: [openstack-dev] [ClusterLabs Developers] [HA] future of OpenStack OCF resource agents (was: resource-agents v4.2.0)

Adam, Personally, I would prefer the approach where the OpenStack resource agents are part of the repository in which they are used. This is also the approach taken in other open source projects such as Kubernetes and avoids the inconsistency where, for example, Azure resource agents are in

Re: [openstack-dev] Forum Schedule - Seeking Community Review

Jimmy, While it's not a clash within the forum, there are two sessions for Ironic scheduled at the same time on Tuesday at 14h20, each of which has Julia as a speaker. Tim -Original Message- From: Jimmy McArthur Reply-To: "OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series

c][ptl][uc] starting goal selection for T series On Wed, Sep 26, 2018 at 1:56 PM Tim Bell mailto:tim.b...@cern.ch>> wrote: Doug, Thanks for raising this. I'd like to highlight the goal "Finish moving legacy python-*client CLIs to python-openstackclient" from the etherpad and

Re: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series

Doug, Thanks for raising this. I'd like to highlight the goal "Finish moving legacy python-*client CLIs to python-openstackclient" from the etherpad and propose this for a T/U series goal. To give it some context and the motivation: At CERN, we have more than 3000 users of the OpenStack

Re: [openstack-dev] [nova][publiccloud-wg] Proposal to shelve on stop/suspend

Found the previous discussion at http://lists.openstack.org/pipermail/openstack-operators/2016-August/011321.html from 2016. Tim -Original Message- From: Tim Bell Date: Saturday, 15 September 2018 at 14:38 To: "OpenStack Development Mailing List (not for usage ques

Re: [openstack-dev] [nova][publiccloud-wg] Proposal to shelve on stop/suspend

One extra user motivation that came up during past forums was to have a different quota for shelved instances (or remove them from the project quota all together). Currently, I believe that a shelved instance still counts towards the instances/cores quota thus the reduction of usage by the user

Re: [openstack-dev] [all] Consistent policy names

So +1 Tim From: Lance Bragstad Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Wednesday, 12 September 2018 at 20:43 To: "OpenStack Development Mailing List (not for usage questions)" , OpenStack Operators Subject: [openstack-dev] [all] Consistent policy

Re: [openstack-dev] [tripleo][puppet] Hello all, puppet modules

CERN use these puppet modules too and contributes any missing functionality we need upstream. Tim From: Alex Schultz Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Thursday, 31 May 2018 at 16:24 To: "OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [StarlingX] StarlingX code followup discussions

I'd like to understand the phrase "StarlingX is an OpenStack Foundation Edge focus area project". My understanding of the current situation is that "StarlingX would like to be OpenStack Foundation Edge focus area project". I have not been able to keep up with all of the discussions so I'd be

Re: [openstack-dev] [tc] [all] TC Report 18-20

From my memory, the LCOO was started in 2015 or 2016. The UC was started at the end of 2012, start of 2013 (https://www.openstack.org/blog/?p=3777) with Ryan, JC and I. Tim -Original Message- From: Graham Hayes Reply-To: "OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

You may also need something like pre-emptible instances to arrange the clean up of opportunistic VMs when the owner needs his resources back. Some details on the early implementation at http://openstack-in-production.blogspot.fr/2018/02/maximizing-resource-utilization-with.html. If you're in

Re: [openstack-dev] [tripleo] ironic automated cleaning by default?

xpect that we want it to be a deliberate request from administrator to do. Maybe user when they "return" a node to free pool after baremetal usage. Thanks, Arkady -Original Message- From: Tim Bell [mailto:tim.b...@cern.ch] Sent: Thursday, April 26

Re: [openstack-dev] [tripleo] ironic automated cleaning by default?

How about asking the operators at the summit Forum or asking on openstack-operators to see what the users think? Tim -Original Message- From: Ben Nemec Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

One of the challenges in the academic sector is the time from lightbulb moment to code commit. Many of the academic resource opportunities are short term (e.g. PhDs, student projects, government funded projects) and there is a latency in current system to onboard, get the appropriate

Re: [openstack-dev] [nova] Default scheduler filters survey

I'd suggest asking on the openstack-operators list since there is only a subset of operators who follow openstack-dev. Tim -Original Message- From: Chris Friesen Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [tripleo] PTG session about All-In-One installer: recap & roadmap

How about * As an operator, I’d like to spin up the latest release to check if a problem is fixed before reporting a problem upstream We use this approach frequently with packstack. Ideally (as today with packstack), we’d do this inside a VM on a running OpenStack cloud… inception… ☺ Tim

Re: [openstack-dev] [ironic] baremetal firmware lifecycle management

We've experienced different firmware update approaches.. this is a wish list rather than a requirement since in the end, it can all be scripted if needed. Currently, these are manpower intensive and require a lot of co-ordination since the upgrade operation has to be performed by the hardware

Re: [openstack-dev] [nova] about rebuild instance booted from volume

Deleting all snapshots would seem dangerous though... 1. I want to reset my instance to how it was before 2. I'll just do a snapshot in case I need any data in the future 3. rebuild 4. oops Tim -Original Message- From: Ben Nemec Reply-To: "OpenStack Development

Re: [openstack-dev] [nova] about rebuild instance booted from volume

Matt, To add another scenario and make things even more difficult (sorry (), if the original volume has snapshots, I don't think you can delete it. Tim -Original Message- From: Matt Riedemann Reply-To: "OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [ironic] PTG Summary

ery but with a different name. I think we should try to make cleaning work for this case instead. Dmitry On 03/12/2018 12:33 PM, Tim Bell wrote: > Julia, > > A basic summary of CERN does burn-in is at http://openstack-in-production.blogspot.ch/2

Re: [openstack-dev] [ironic] PTG Summary

Julia, A basic summary of CERN does burn-in is at http://openstack-in-production.blogspot.ch/2018/03/hardware-burn-in-in-cern-datacenter.html Given that the burn in takes weeks to run, we'd see it as a different step to cleaning (with some parts in common such as firmware upgrades to latest

Re: [openstack-dev] Pros and Cons of face-to-face meetings

Fully agree with Doug. At CERN, we use video conferencing for 100s, sometimes >1000 participants for the LHC experiments, the trick we've found is to fully embrace the chat channels (so remote non-native English speakers can provide input) and chairs/vectors who can summarise the remote

Re: [openstack-dev] [Openstack-sigs] [keystone] [oslo] new unified limit library

bject: Re: [Openstack-sigs] [openstack-dev] [keystone] [oslo] new unified limit library This is certainly a feature will make Public Cloud providers very happy :) On Thu, Mar 8, 2018 at 12:33 AM, Tim Bell <tim.b...@cern.ch<mailto:tim.b...@cern.ch>> wrote: Sorry, I remember more detail

Re: [openstack-dev] [keystone] [oslo] new unified limit library

Sorry, I remember more detail now... it was using the 'owner' of the VM as part of the policy rather than quota. Is there a per-user/per-group quota in Nova? Tim -Original Message- From: Tim Bell <tim.b...@cern.ch> Reply-To: "OpenStack Development Mailing List (not for usag

Re: [openstack-dev] [keystone] [oslo] new unified limit library

There was discussion that Nova would deprecate the user quota feature since it really didn't fit well with the 'projects own resources' approach and was little used. At one point, some of the functionality stopped working and was repaired. The use case we had identified goes away if you have 2

Re: [openstack-dev] [all] [tc] Community Goals for Rocky

I was reading a tweet from Jean-Daniel and wondering if there would be an appropriate community goal regarding support of some of the later API versions or whether this would be more of a per-project goal. https://twitter.com/pilgrimstack/status/951860289141641217 Interesting numbers about

Re: [openstack-dev] [all] Switching to longer development cycles

The forums would seem to provide a good opportunity for get togethers during the release cycle. With these happening April/May and October/November, there could be a good chance for productive team discussions and the opportunities to interact with the user/operator community. There is a risk

Re: [openstack-dev] [heat] Removal of CloudWatch api

Rabi, I’d suggest to review the proposal with the openstack-operators list who would be able to advise on potential impact for their end users. Tim From: Rabi Mishra Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [tc][docs][release] Updating the PTI for docs and tarballs

Having a PDF (or similar offline copy) was also requested during OpenStack UK days event during the executive Q with jbryce. Tim -Original Message- From: Doug Hellmann Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [tc][masakari] new project teams application for Masakari

Great to see efforts for this use case. Is there community convergence that Masakari is the solution to address VMs high availability? Tim -Original Message- From: Sam P Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [trove][tc][all] Trove restart - next steps

o midcycle, 2014). It came up briefly in the Kilo midcycle as well but was quickly rejected again. I've added it to the list of topics for discussion at the PTG. If others want to add topics to that list, the etherpad is at https://etherpad.openstack.org/p/trove-queens-ptg​ Thanks! -amrith On T

Re: [openstack-dev] [trove][tc][all] Trove restart - next steps

One idea I found interesting from the past discussion was the approach that the user need is a database with a connection string. How feasible is the approach where we are provisioning access to a multi-tenant database infrastructure rather than deploying a VM with storage and installing a

Re: [openstack-dev] [QA][LCOO] MEX-ops-meetup: OpenStack Extreme Testing

+1 for Boris’ suggestion. Many of us use Rally to probe our clouds and have significant tooling behind it to integrate with local availability reporting and trouble ticketing systems. It would be much easier to deploy new functionality such as you propose if it was integrated into an existing

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

> On 29 Jun 2017, at 17:35, Chris Friesen wrote: > > On 06/29/2017 09:23 AM, Monty Taylor wrote: > >> We are already WELL past where we can solve the problem you are describing. >> Pandora's box has been opened - we have defined ourselves as an Open >> community.

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

terminology On Thu, Jun 15, 2017 at 03:41:30PM +, Tim Bell wrote: > OpenStack Nucleus and OpenStack Electrons? > > Tim > Hah, love it! __ OpenStack Develo

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

OpenStack Nucleus and OpenStack Electrons? Tim -Original Message- From: Thierry Carrez Organization: OpenStack Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Thursday, 15 June 2017 at 14:57 To:

Re: [openstack-dev] [tc] revised Postgresql deprecation patch for governance

Thanks. It’s more of a question of not leaving people high and dry when they have made a reasonable choice in the past based on the choices supported at the time. Tim On 23.05.17, 21:14, "Sean Dague" <s...@dague.net> wrote: On 05/23/2017 02:35 PM, Tim Bell wrote: >

Re: [openstack-dev] [tc] revised Postgresql deprecation patch for governance

Is there a proposal where deployments who chose Postgres on good faith can find migration path to a MySQL based solution? Tim On 23.05.17, 18:35, "Octave J. Orgeron" wrote: As OpenStack has evolved and grown, we are ending up with more and more MySQL-isms

Re: [openstack-dev] [neutron] multi-site forum discussion

On 12 May 2017, at 23:38, joehuang > wrote: Hello, Neutron cells aware is not equal to multi-site. There are lots of multi-site deployment options, not limited to nova-cells, whether to use Neutron-cells/Nova-cells in multi-site deployments,

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

> On 14 May 2017, at 13:04, Sean Dague wrote: > > One of the things that came up in a logging Forum session is how much effort > operators are having to put into reconstructing flows for things like server > boot when they go wrong, as every time we jump a service barrier the

Re: [openstack-dev] [scientific][nova][cyborg] Special Hardware Forum session

I think there will be quite a few ops folk… I can promise at least one ☺ Blair and I can also do a little publicity in https://www.openstack.org/summit/boston-2017/summit-schedule/events/18751/future-of-hypervisor-performance-tuning-and-benchmarking which is on Tuesday. Tim From: Rochelle

Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

Are there any implications for the end user experience by going to different repos (such as requiring dedicated menu items)? Tim From: "Sridar Kandaswamy (skandasw)" Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] Project Navigator Updates - Feedback Request

Lauren, Can we also update the sample configurations? We should certainly have Neutron now in the HTC (since nova-network deprecation) Tim From: Lauren Sell Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)

> On 22 Mar 2017, at 00:53, Alex Schultz wrote: > > On Tue, Mar 21, 2017 at 5:35 PM, John Dickinson wrote: >> >> >> On 21 Mar 2017, at 15:34, Alex Schultz wrote: >> >>> On Tue, Mar 21, 2017 at 3:45 PM, John Dickinson wrote: I've been

Re: [openstack-dev] [keystone][all] Reseller - do we need it?

Lance, I had understood that the resellers was about having users/groups at the different points in the tree. I think the basic resource management is being looked at as part of the nested quotas functionality. For CERN, we’d look to delegate the quota and roles management but not support

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

> On 11 Mar 2017, at 08:19, Clint Byrum wrote: > > Excerpts from Christopher Aedo's message of 2017-03-10 19:30:18 -0800: >> On Fri, Mar 10, 2017 at 6:20 PM, Clint Byrum wrote: >>> Excerpts from Fox, Kevin M's message of 2017-03-10 23:45:06 +: So,

Re: [openstack-dev] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it

Is there cloud-init support for this mode or do we still need to mount as a config drive? Tim On 20.02.17, 17:50, "Jeremy Stanley" wrote: On 2017-02-20 15:46:43 + (+), Daniel P. Berrange wrote: > The data is exposed either as a block device or as a character

Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

On 16 Feb 2017, at 19:42, Fox, Kevin M > wrote: +1. The assumption was market forces will cause the best OpenStack deployment tools to win. But the sad reality is, market forces are causing people to look for non OpenStack solutions instead as the

Re: [openstack-dev] Hierarchical quotas at the PTG?

On 12 Feb 2017, at 12:13, Boris Bobrov > wrote: I would like to talk about it too. On 02/10/2017 11:56 PM, Matt Riedemann wrote: Operators want hierarchical quotas [1]. Nova doesn't have them yet and we've been hesitant to invest scarce

Re: [openstack-dev] [tc][glance][glare][all] glance/glare/artifacts/images at the PTG

Although there has not been much discussion on this point on the mailing list, I feel we do need to find the right level of granularity for ‘mainstream’ projects: For CERN, we look for the following before offering a project to our end users: - Distro packaging (in our case RPMs through RDO) -

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

On 17 Jan 2017, at 11:28, Maish Saidel-Keesing <mais...@maishsk.com<mailto:mais...@maishsk.com>> wrote: Please see inline. On 17/01/17 9:36, Tim Bell wrote: ... Are we really talking about Barbican or has the conversation drifted towards Big Tent concerns? Perhaps we can flip

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

On 17 Jan 2017, at 01:19, Brandon B. Jozsa > wrote: Inline On January 16, 2017 at 7:04:00 PM, Fox, Kevin M (kevin@pnnl.gov) wrote: I'm not stating that the big tent should be abolished and we go back to the way

Re: [openstack-dev] 答复: [heat] glance v2 support?

On 10 Jan 2017, at 17:41, Zane Bitter > wrote: On 10/01/17 05:25, Flavio Percoco wrote: I'd recommend Heat to not use locations as that will require deployers to either enable them for everyone or have a dedicate glance-api node for Heat. If

Re: [openstack-dev] [telemetry] [ceilometer] [panko] ceilometer API deprecation

On 10 Jan 2017, at 15:21, gordon chung > wrote: On 10/01/17 07:27 AM, Julien Danjou wrote: On Mon, Jan 09 2017, William M Edmonds wrote: I started the conversation on IRC [5], but wanted to send this to the mailing list and see if others have

Re: [openstack-dev] [heat] glance v2 support?

On 6 Jan 2017, at 05:04, Rabi Mishra > wrote: On Fri, Jan 6, 2017 at 4:38 AM, Emilien Macchi > wrote: Greetings Heat folks! My question is simple: When do you plan to support Glance v2?

Re: [openstack-dev] [all][ptls][tc][goals] community goals for Pike

> On 15 Dec 2016, at 16:19, Doug Hellmann wrote: > > Excerpts from Jean-Philippe Evrard's message of 2016-12-15 09:11:12 +: >> Hello, >> >> Maybe this will sound dumb … >> >> I received this email on openstack-dev mailing list. I don’t know if it was >> sent to any

Re: [openstack-dev] [Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

On 4 Nov 2016, at 06:31, Sam Morrison > wrote: On 4 Nov. 2016, at 1:33 pm, Emilien Macchi > wrote: On Thu, Nov 3, 2016 at 9:10 PM, Sam Morrison > wrote:

Re: [openstack-dev] [telemetry] Deprecating the Ceilometer API

> On 4 Oct 2016, at 17:36, Chris Dent wrote: > > On Tue, 4 Oct 2016, Julien Danjou wrote: > >> Considering the split of Ceilometer in subprojects (Aodh and Panko) >> during those last cycles, and the increasing usage of Gnocchi, I am >> starting to wonder if it makes

Re: [openstack-dev] [nova] ops meetup feedback

On 20 Sep 2016, at 16:38, Sean Dague > wrote: ... There were also general questions about what scale cells should be considered at. ACTION: we should make sure workarounds are advertised better ACTION: we should have some document about "when cells"? This

Re: [openstack-dev] [puppet] Puppet OpenStack PTL non-candidacy

Emilien, Thanks for all your hard work in this area. You may not know how many happy consumers of the OpenStack Puppet project there are because we’re quiet until you decide to step down. Tim On 09/09/16 18:05, "Emilien Macchi" wrote: Hi, I wrote a little

Re: [openstack-dev] [OSC] Tenant Resource Cleanup

On 07 Sep 2016, at 15:05, John Davidge > wrote: Hello, During the Mitaka cycle we merged a new feature into the python-neutronclient called ’neutron purge’. This enables a simple CLI command that deletes all of the neutron

Re: [openstack-dev] [OSC] Tenant Resource Cleanup

On 07 Sep 2016, at 15:05, John Davidge > wrote: Hello, During the Mitaka cycle we merged a new feature into the python-neutronclient called ’neutron purge’. This enables a simple CLI command that deletes all of the neutron

Re: [openstack-dev] [ironic][OpenStackClient] two openstack commands for the same operation?

> On 29 Aug 2016, at 16:41, Loo, Ruby wrote: > > Hi, > > In ironic, we have these ironic CLI commands: > - ironic node-vendor-passthru (calls the specified passthru method) > - ironic node-get-vendor-passthru-methods (lists the available passthru > methods) > > For their

Re: [openstack-dev] [Openstack-operators] [Nova] Reconciling flavors and block device mappings

On 26 Aug 2016, at 17:44, Andrew Laski > wrote: On Fri, Aug 26, 2016, at 11:01 AM, John Griffith wrote: On Fri, Aug 26, 2016 at 7:37 AM, Andrew Laski > wrote: On Fri, Aug 26, 2016, at 03:44

Re: [openstack-dev] [Magnum] Next auto-scaling feature design?

> On 18 Aug 2016, at 09:56, hie...@vn.fujitsu.com wrote: > > Hi Magnum folks, > > I have some interests in our auto scaling features and currently testing with > some container monitoring solutions such as heapster, telegraf and > prometheus. I have seen the PoC session corporate with Senlin

Re: [openstack-dev] [magnum][heat] 2 million requests / sec, 100s of nodes

On 08 Aug 2016, at 11:51, Ricardo Rocha > wrote: Hi. On Mon, Aug 8, 2016 at 1:52 AM, Clint Byrum > wrote: Excerpts from Steve Baker's message of 2016-08-08 10:11:29 +1200: On 05/08/16 21:48, Ricardo

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

> On 05 Aug 2016, at 01:02, Jay Pipes wrote: > > On 08/04/2016 06:40 PM, Clint Byrum wrote: >> Excerpts from Jay Pipes's message of 2016-08-04 18:14:46 -0400: >>> On 08/04/2016 05:30 PM, Clint Byrum wrote: Excerpts from Fox, Kevin M's message of 2016-08-04 19:20:43

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

> On 04 Aug 2016, at 19:34, Erno Kuvaja wrote: > > On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum wrote: >> Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +: >>> >>> On 04 Aug 2016, at 17:27, Mikhail Fedosin >>>

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

On 04 Aug 2016, at 17:27, Mikhail Fedosin > wrote: Hi all, after 6 months of Glare v1 API development we have decided to continue our work in a separate project in the "openstack" namespace with its own core team (me, Kairat Kushaev, Darja

Re: [openstack-dev] [tc] persistently single-vendor projects

> On 02 Aug 2016, at 17:13, Hayes, Graham wrote: > > On 02/08/2016 15:42, Flavio Percoco wrote: >> On 01/08/16 10:19 -0400, Sean Dague wrote: >>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote: Thierry, Ben, Doug, How can we distinguish between. "Project is

Re: [openstack-dev] [glance][nova] Globally disabling hw_qemu_guest_agent support

Looking at the number of options for image properties, it would seem that a blacklist would be in order. I would be in favour for ‘standard’ images which support fsfreeze to support guest agent and that some of the NUMA properties not be available for end user images, but still for system ones.

Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker project

Given the inconsistency between the user survey and the apparent utilization/maintenance, I’d recommend checking on the openstack-operators list to see if this would be a major issue. Tim On 08/07/16 13:54, "Amrith Kumar" wrote: Did not realize that; I withdraw my request.

Re: [openstack-dev] [Magnum] The Magnum Midcycle

If we can confirm the dates and location, there is a reasonable chance we could also offer remote conferencing using Vidyo at CERN. While it is not the same as an F2F experience, it would provide the possibility for remote participation for those who could not make it to Geneva. We may also be

[openstack-dev] [nova] Replacing user based policies in Nova

With https://review.openstack.org/324068 (thanks ☺), the key parts of user based policies as currently deployed would be covered in the short term. However, my understanding is that this functionality needs to be replaced with something sustainable in the long term and consistent with the

Re: [openstack-dev] [nova] NUMA, huge pages, and scheduling

The documentation at http://docs.openstack.org/admin-guide/compute-flavors.html is gradually improving. Are there areas which were not covered in your clarifications ? If so, we should fix the documentation too since this is a complex area to configure and good documentation is a great help.

Re: [openstack-dev] [craton] meeting notes

Thanks for the notes. Is the agreement to work using Craton as a base for the fleet management ? Tim From: sean roberts Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Monday 16 May 2016 at 17:51 To:

Re: [openstack-dev] [magnum] How to document 'labels'

I’d be in favor of 1. At the end of the man page or full help text, a URL could be useful for more information but since most people using the CLI will have to do a context change to access the docs, it is not a simple click but a copy/paste/find the browser window which is not so friendly.

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

On 12/05/16 02:59, "Nikhil Komawar" wrote: >Thanks Josh about your reply. It's helpful. > >The attempt of this cross project work is to come up with a standard way >of implementing quota logic that can be used by different services. >Currently, different projects have

Re: [openstack-dev] [tc] supporting Go

From: Rayson Ho > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Tuesday 10 May 2016 at 01:43 To: "OpenStack Development Mailing List

Re: [openstack-dev] [nova][osc] Use of openstack client for admin commands

On 04/05/16 20:54, "Sean Dague" wrote: >On 05/04/2016 02:16 PM, Dean Troyer wrote: >> On Wed, May 4, 2016 at 12:08 PM, Chris Dent > > wrote: >> >> Since then the spec has been updated to reflect using OSC but the

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

On 04/05/16 20:35, "Nikhil Komawar" <nik.koma...@gmail.com> wrote: > > >On 5/4/16 2:09 PM, Tim Bell wrote: >> >> On 04/05/16 19:41, "Nikhil Komawar" <nik.koma...@gmail.com> wrote: >> >>> Thanks for the summary and taking ca

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

On 04/05/16 19:41, "Nikhil Komawar" wrote: >Thanks for the summary and taking care of the setup, Vilobh! > >Pretty meticulously written on what was agreed at the session. Kudos! > >I wanted to add some points that were asked during the Glance >contributors' meetup: > >*

Re: [openstack-dev] [nova] Distributed Database

On 04/05/16 19:00, "Edward Leafe" wrote: >On May 3, 2016, at 7:05 PM, Mark Doffman wrote: > >> This thread has been a depressing read. >> >> I understand that the content is supposed to be distributed databases but >> for me it has become an

Re: [openstack-dev] [tc] supporting Go

John, How would Oslo like functionality be included ? Would the aim be to produce equivalent libraries ? Tim On 03/05/16 17:58, "John Dickinson" wrote: >TC, > >In reference to >http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html and >Thierry's reply, I'm

Re: [openstack-dev] Summit Core Party after Austin

On 21/04/16 19:40, "Doug Hellmann" wrote: >Excerpts from Thierry Carrez's message of 2016-04-21 18:22:53 +0200: >> Michael Krotscheck wrote: >> >> >> So.. while I understand the need for calmer parties during the week, I >> think the general trends is to have less

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

On 21/04/16 17:38, "Hongbin Lu" wrote: > > >> -Original Message- >> From: Adrian Otto [mailto:adrian.o...@rackspace.com] >> Sent: April-21-16 10:32 AM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev]

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

As we’ve deployed more OpenStack components in production, one of the points we have really appreciated is the common areas - Single pane of glass for Horizon - Single accounting infrastructure - Single resource management, quota and admin roles - Single storage pools with Cinder - (not quite

Re: [openstack-dev] [all][elections] Results of the TC Election

On 08/04/16 20:08, "gordon chung" wrote: > > >On 08/04/2016 9:14 AM, Thierry Carrez wrote: >> Eoghan Glynn wrote: However, the turnout continues to slide, dipping below 20% for the first time: >>> >>>Election | Electorate (delta %) | Votes | Turnout (delta %) >>>

Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from nova

On 06/04/16 19:28, "Fox, Kevin M" wrote: >+1 > >From: Neil Jerram [neil.jer...@metaswitch.com] >Sent: Wednesday, April 06, 2016 10:15 AM >To: OpenStack Development Mailing List (not for usage questions) >Subject: Re: [openstack-dev]

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

On 06/04/16 18:36, "Daniel P. Berrange" wrote: >On Wed, Apr 06, 2016 at 04:29:00PM +, Fox, Kevin M wrote: >> It feels kind of like a defcore issue though. Its harder for app >> developers to create stuff like heat templates intended for cross >> cloud that recommend a

Re: [openstack-dev] [tc][ec2-api] EC2 API Future

On 21/03/16 17:23, "Doug Hellmann" <d...@doughellmann.com> wrote: > > >> On Mar 20, 2016, at 3:26 PM, Tim Bell <tim.b...@cern.ch> wrote: >> >> >> Doug, >> >> Given that the EC2 functionality is currently in use by at least 1/6t

Re: [openstack-dev] [tc][ec2-api] EC2 API Future

Doug, Given that the EC2 functionality is currently in use by at least 1/6th of production clouds (https://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf page 34), this is a worrying situation. The EC2 functionality was recently deprecated from Nova on the grounds that the

Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?

On 17/03/16 18:29, "Sean Dague" wrote: >On 03/17/2016 11:57 AM, Markus Zoeller wrote: > >> Suggested action items: >> >> 1. I close the open wish list items older than 6 months (=138 reports) >>and explain in the closing comment that they are outdated and the >>ML

Re: [openstack-dev] [magnum] High Availability

From: Hongbin Lu > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Saturday 19 March 2016 at 04:52 To: "OpenStack Development Mailing

Re: [openstack-dev] [cross-project] [all] Quotas -- service vs. library

On 16/03/16 07:25, "Nikhil Komawar" wrote: >Hello everyone, > >tl;dr; >I'm writing to request some feedback on whether the cross project Quotas >work should move ahead as a service or a library or going to a far >extent I'd ask should this even be in a common repository,

Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?

On 15/03/16 16:21, "Markus Zoeller" wrote: >Sean Dague wrote on 03/15/2016 02:52:47 PM: > >> From: Sean Dague >> To: openstack-dev@lists.openstack.org >> Date: 03/15/2016 02:53 PM >> Subject: Re: [openstack-dev] [nova] Wishlist bugs ==

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

From: Sylvain Bauza > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Thursday 10 March 2016 at 10:04 To: "OpenStack Development Mailing List

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

From: Matt Fischer > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Tuesday 8 March 2016 at 20:35 To: "OpenStack Development Mailing

Re: [openstack-dev] [nova] config options help text improvement: current status

Great. Does this additional improved text also get into the configuration guide documentation somehow ? Tim On 02/03/16 18:45, "Markus Zoeller" wrote: >TL;DR: From ~600 nova specific config options are: >~140 at a central location with an improved help

  1   2   3   >