Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

easier > > and straightforward. I'm fine with that plan, speaking as the original developer; as I say, I don't think Rackspace ever utilized the functionality anyway, and if no one else pipes up saying that they're using it, I'd be all over deprecating the quota class

[openstack-dev] [barbican][cinder][glance][nova] Goodbye from JHUAPL

All, After over five years of contributing security features to OpenStack, the JHUAPL team is wrapping up our involvement with OpenStack. To all who have reviewed/improved/accepted our contributions, thank you. It has been a pleasure to be a part of the community. Regards, The JHUAPL

Re: [openstack-dev] [nova] Confusion over how enable_certificate_validation is meant to be used

Matt, The end goal is that certificate validation will always occur alongside signature validation, but we wanted there to be an upgrade path that would allow signature validation to continue to work until certificate validation was set up. See the first paragraph of the proposed change in

Re: [openstack-dev] [nova] pep8 failures on master

can imagine stopping these errors in the future would be to double-up on the pep8 check: have the gate run pep8 under both Python 2 and Python 3. -- Kevin L. Mitchell <klmi...@mit.edu> signature.asc Description: This is a digitally signed message part _

Re: [openstack-dev] Gerrit custom menu entries - help needed

Hello, I have found the Gerrit Dashboard Creator (see https://github.com/openstack/gerrit-dash-creator ) to be very helpful when putting together queries. Thanks, ~Brianna On 12/8/17, 16:25, "Sławek Kapłoński" wrote: Hello, I’m trying to personalize my

Re: [openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

Thanks for sending this out. I would vote for Option 1. Thanks, John From: Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com] Sent: Tuesday, November 14, 2017 8:16 AM To: OpenStack Development Mailing List (not for usage questions) Subject:

Re: [openstack-dev] [nova] Proposing Balazs Gibizer for nova-core

contributors to Nova get involved which helps grow our  > contributor base. +1 from me -- Kevin L. Mitchell <klmi...@mit.edu> signature.asc Description: This is a digitally signed message part __ OpenStack Dev

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

ouldn't require a version bump in this case: it _is_ a breakage that's being fixed. -- Kevin L. Mitchell <klmi...@mit.edu> signature.asc Description: This is a digitally signed message part __ OpenStack Development Maili

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

ve a deployer would view as a bug, if they encountered it, and because it was introduced prior to a named final release. -- Kevin L. Mitchell <klmi...@mit.edu> signature.asc Description: This is a digitally signed message part _

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

On Fri, 2017-08-04 at 12:26 -0700, Boris Pavlovic wrote: > By the way stevedore is really providing very bad plugin experience > and should not be used definitely.  Perhaps entrypointer[1]? ;) [1] https://pypi.python.org/pypi/entrypointer -- Kevin L. Mitchell <klmi...@mit.edu> s

[openstack-dev] [Swift] 404 on geo-replicated clusters with write affinity

Hi everyone, It was great to meet you at the Boston summit and agree on the best way to fix the 404 error code bug on geo-replicated clusters with write affinity. As you know, this is a topic that is dear to us at Catalyst, and we would like to provide a patch to it. Since we are relatively new

Re: [openstack-dev] [ironic] Translations removal

If that's the case, that may help provide a solution to translate user-visible messages while leaving logs untranslated. -- Kevin L. Mitchell <klmi...@mit.edu> signature.asc Description: This is a digitally signed message part __

Re: [openstack-dev] [ironic] Translations removal

hat are your thoughts? When the translators go to translate, they generally only get to see what's inside _(), so #2 is a no-go for translations, and #3 also is a no-go. -- Kevin L. Mitchell <klmi...@mit.edu> signature.asc Description: This is a digitally signed message part __

[openstack-dev] [Ironic] FYI: Making changes required for Ironic multi-node grenade to work

In order for Ironic multi-node grenade testing work we have to correct a mistake we (well really I) made. We need to remove the enabling of the ironic plugin in our devstack/upgrade/settings file and move it to openstack-infra/project-config. As enabling the plugin in that file works for

Re: [openstack-dev] [All] IRC Mishaps

ppened to be the #3 largest IRC network at the time. Fixing *that* was fun :) -- Kevin L. Mitchell <klmi...@mit.edu> signature.asc Description: This is a digitally signed message part __ OpenStack Development Mailing List (n

Re: [openstack-dev] [QA] Gate Jobs failing after patch for bug/1628016

Jobs failing after patch for bug/1628016 On Mon, Jan 30, 2017 at 3:25 PM White, Joshua L <joshua.l.wh...@intel.com<mailto:joshua.l.wh...@intel.com>> wrote: Hi Team, I would like to get your feedback on the gate jobs failing and how to alleviate the issue. The gate jobs are

[openstack-dev] [QA] Gate Jobs failing after patch for bug/1628016

Hi Team, I would like to get your feedback on the gate jobs failing and how to alleviate the issue. The gate jobs are failing once the prefix is actually added for these tests jobs below: 1. test_list_container_contents_with_path Issue: For some reason whoever coded this test hardcoded

[openstack-dev] [OpenStack][Dev] Changes coming to Product WG & Enterprise WG

After 35+ yrs in the Technology Industry, I have decided it's time for a change. I will be retiring from Intel on February 2nd. OpenStack has been a highlight of my career and I owe much of that to you all. It's been a pleasure knowing and working with you. Yih Leong Sun (aka Leong) will be

[openstack-dev] (dis)Continuation of Neutron VPNaaS

Hi, November last year the Neutron team has announced that VPN as a Service will be no longer part of Neutron[1]. We run a public cloud based in New Zealand called Catalyst Cloud[2]. Our customers find the VPN service extremely useful to integrate their cloud tenant's with on-premise

Re: [openstack-dev] [nova] Nominating Stephen Finucane for nova-core

On Fri, 2016-12-02 at 09:22 -0600, Matt Riedemann wrote: > I'm proposing that we add Stephen Finucane to the nova-core team. +1 from me. -- Kevin L. Mitchell <klmi...@mit.edu> signature.asc Description: This is a digitally signed mes

Re: [openstack-dev] [docs][upgrades] time to add official docs for upgrading services?

Yes, I think it’s time to create a specific guide for this. It’s a topic of high interest for Operators (current and future) and helping them to understand how to plan their deployment for upgradability (ideally non-disruptive upgrades) would be very valuable. Carol From: Steve Martinelli

Re: [openstack-dev] [kolla][git]How to backport commit after repo split

At some point, it would be good if the kolla-ansible repo is added as a submodule of the kolla one to simplify things. Thanks, Juan > On Nov 17, 2016, at 22:19, Jeffrey Zhang wrote: > > Yes. it works. Maybe we should add this into develop doc. > > thanks Paul. > >

Re: [openstack-dev] [ironic] Core team updates

I just want to give a big thank you to Haomeng Wang and Chris Krelle for all their contributions to Ironic! And especially thanks to Chris (NobodyCam) for all of his help while I was learning about Ironic. It helps we were in the same timezone, so we overlapped in IRC often :) John >

Re: [openstack-dev] [all][API WG] How does one best express a time interval as an API filtering query?

ee that that is non-ideal. How about a syntax something like: ?finished_at=between:ISO_DATE_A@ISO_DATE_B_at=between:ISO_DATE_C@ISO_DATE_D -- Kevin L. Mitchell <klmi...@mit.edu> signature.asc Description: This is a digitally signed message part

Re: [openstack-dev] [all][oslo] Parse ISO8601 (open) time intervals

eutil than to > put the function in a library not meant for anyone else outside of > OpenStack to use. You might also want to look at the timestring library… -- Kevin L. Mitchell <klmi...@mit.edu> signature

[openstack-dev] [Ironic] The Ironic Grenade gate job is currently broken. Please don't do recheck on patches

Currently the Ironic Grenade gate job is broken. Until the issue is resolved please don't do recheck on openstack/ironic patch. Work is ongoing to figure out why it stopped working. __ OpenStack Development Mailing List

Re: [openstack-dev] [UX] Results Presentation: Managing OpenStack Quotas within Production Environments

Danielle – I think this is good, but if you are not getting the level of participation you want…or commitment to follow-on actions, I would suggest you adopt a “go to them” strategy. Thanks Carol From: Danielle Mundle [mailto:danielle.m.mun...@gmail.com] Sent: Wednesday, September 21, 2016

Re: [openstack-dev] [kolla][ptl] Self non-nomination for Kolla PTL for Ocata cycle

Steve - You did a great job leading the effort & appreciate your work on building a leadership pipeline for the project. Best wishes Carol Sent from my iPhone On Sep 12, 2016, at 12:09 PM, Steven Dake (stdake) > wrote: To the OpenStack Community,

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

ined in the charter (rather > than having to change it). The PTLs we will elect in the coming weeks > won't be renewed before April, 2017 -- while Pike development will > start in February. > > I know this can all be a bit confusing, so feel free to reach out to > me with

[openstack-dev] [Ironic] QA Meeting cancelled today

To focus on the Newton work. The Ironic QA meeting is cancelled for today. Thanks, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [Fuel] Common fuel-core group for all Fuel projects

+1 to Lukasz. -1 to the proposal, we had it this way for a quite some time, and it was not good for the project (as Lukasz pointed out), why should a person who merges the code to the library have an access to merge the code to Nailgun/Astute without proper expertise. Those are different areas

Re: [openstack-dev] [ironic] Driver removal policies - should we make it softer?

> -Original Message- > From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com] > Sent: Friday, August 19, 2016 7:15 AM > To: OpenStack Development Mailing List (not for usage questions) > > Subject: [openstack-dev] [ironic] Driver removal policies -

Re: [openstack-dev] [nova] Let's kill quota classes (again)

I'm going to start a pet project of rooting this stuff out > again, starting with nova.context.RequestContext.quota_class, unless > anyone has a good reason we should keep this in tree. > > I think we should also add a microversion to the API in Ocata to disable > the abi

[openstack-dev] [Charm][Congress] Upstreaming JuJu Charm for Openstack Congress

Hi, I've been working in the OPNFV (https://wiki.opnfv.org/) on a JuJu Charm to install the OpenStack Congress service on the OPNFV reference platform. This charm should be useful for anyone that wants to install Congress for use with an OpenStack deployment, using the JuJu tool. I want to get

Re: [openstack-dev] [ironic] UFCG OneView CI comments missing recheck command

> -Original Message- > From: Thiago Paiva [mailto:thia...@lsd.ufcg.edu.br] > Sent: Tuesday, June 28, 2016 17:00 > To: OpenStack Development Mailing List (not for usage questions) > Cc: ufcg-oneview...@lsd.ufcg.edu.br > Subject: Re: [openstack-dev] [ironic] UFCG OneView CI comments

Re: [openstack-dev] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

On 06/23/2016 Daniel Berrange wrote (lost attribution in thread): > Our long term goal is that 100% of all network storage will be connected > to directly by QEMU. We already have the ability to partially do this with > iSCSI, but it is lacking support for multipath. As & when that gap is >

Re: [openstack-dev] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

Daniel, Thanks. Looking for a sense of direction. Clearly there is some range of opinion, as Walter indicates. :) Not sure you are get to 100% direct connection to QEMU. When there is dedicated hardware to do off-board processing of the connection to storage, you might(?) be stuck routing

Re: [openstack-dev] [all] Proposal: Architecture Working Group

> On Jun 21, 2016, at 2:56 AM, Thierry Carrez wrote: > > Chris Dent wrote: >> On Mon, 20 Jun 2016, Doug Wiegley wrote: >>> On Jun 21, 2016, at 2:19 PM, Carol Barrett >>> wrote: >>> So, it sounds like you've just described the job of the TC. And

[openstack-dev] [Ironic] Grenade non-voting test results

TL;DR: In my opinion Grenade job is performing reliably. Using the table at: http://ci-watch.tintri.com/project?project=ironic=7+days Note: Unable to extract the data out of the web page to do more thorough data evaluation. The Grenade job appears to be performing successfully. On Thursday

Re: [openstack-dev] [nova] consistency and exposing quiesce in the Nova API

Comments inline. On Thu, Jun 16, 2016 at 10:13 AM, Matt Riedemann <mrie...@linux.vnet.ibm.com > wrote: > On 6/16/2016 6:12 AM, Preston L. Bannister wrote: > >> I am hoping support for instance quiesce in the Nova API makes it into >> OpenStack. To my understanding, t

Re: [openstack-dev] [ironic] Proposing two new cores

> -Original Message- > From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com] > Sent: Thursday, June 16, 2016 08:13 > To: openstack-dev@lists.openstack.org > Subject: [openstack-dev] [ironic] Proposing two new cores > > Hi all, > > I'd like to propose Jay Faulkner (JayF) and Sam Betts

Re: [openstack-dev] [nova] consistency and exposing quiesce in the Nova API

I am hoping support for instance quiesce in the Nova API makes it into OpenStack. To my understanding, this is existing function in Nova, just not-yet exposed in the public API. (I believe Cinder uses this via a private Nova API.) Much of the discussion is around disaster recovery (DR) and NFV -

Re: [openstack-dev] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

QEMU has the ability to directly connect to iSCSI volumes. Running the iSCSI connections through the nova-compute host *seems* somewhat inefficient. There is a spec/blueprint and implementation that landed in Kilo:

[openstack-dev] [Congress] Progress on Congress support in OPNFV Colorado

Hi Congress team, A quick update on progress at OPNFV on integrating Congress into the OPNFV Colorado release (Mitaka-based). With the help of RedHat (Dan Radez) and Canonical (Narinder Gupta, Liam Young) we are getting very close to upstreaming two key things to OpenStack: -

Re: [openstack-dev] [Fuel] Nominate Artur Svechnikov to the fuel-web-core team

Hi Dmitry, It depends, but usually it takes half of working time to do reviews, I'm not sure if we can assume 25-30%, also finding a good reviewer usually is much harder than a person who can write the code, so it would be much more productive to encourage people to spend as much time as they can

[openstack-dev] [congress] Spec for congress.conf

Hi Congress team, Quick question for anyone. Is there a spec for fields in congress.conf file? As of Liberty this has to be tox-generated but I need to know which conf values are required vs optional. The generated sample output doesn't clarify that. This is for the Puppet Module and JuJu

Re: [openstack-dev] disabling deprecated APIs by config?

ny sense at all to add additional keys? We could add a 'warnings' key in that top-level dictionary that could document deprecations, among other things. (That said, /capabilities or equivalent would probably be superior for this particular case…) -- Kevin L. Mitchell <klmi...@mit.edu> sign

Re: [openstack-dev] [ironic] usage of ironic-lib

> -Original Message- > From: Lucas Alvares Gomes [mailto:lucasago...@gmail.com] > What I don't think we should do is say that the library's _right now_ > ready for it, the interfaces we have at the moment should not be > considered stable, Ironic is very opinionated in many aspects >

Re: [openstack-dev] [ironic][nova][neutron][qa] Injecting code into grenade resource create phase

> From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com] > On Thu, May 12, 2016 at 06:48:02AM -0400, Sean Dague wrote: > > Let me make sure I understand the crux of the issue: services may need > > to create additional custom networking in order for the rest of the > > resource flow to work

Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

Hello all, I’m an Operator that has worked with DIB here for the last few months to get some working images for our Private Cloud. The only major issue I could come up with at the summit was the way grub 0.97 is treated in the bootloader element. For Centos 6, I had to find an element that

[openstack-dev] [Ironic] Grenade testing work

During the OpenStack Summit it was decided that getting Grenade to work for Ironic would be the highest priority for the Ironic project. Because without Grenade, we won't have upgrade testing and we need upgrade testing for features we want to land to ensure we don't break anything. We will be

Re: [openstack-dev] [Fuel][Plugins] One plugin - one Launchpad project

Hi Irina, I fully support the idea of creating separate launchpad project for each plugin, because plugins have different release cycles and different teams who support them. Fuel Plugin documentation [2] has to be updated with information for plugin developers (how to setup new project) and for

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

several backoff strategies. Of course, it's a decorator-based backoff implementation, whereas I tend to implement iterator-based solutions, but there may already be a solution in that space as well… -- Kevin L. Mitchell <klmi...@mit.edu> signature.asc Description: This is a digital

Re: [openstack-dev] [Fuel] [ironic] [inspector] Rewriting nailgun agent on Python proposal

> necessary to merge such custom things into Ironic tree. Happily, Ironic > is > > smart enough to consume drivers using stevedore. About ironic-inspector > > the case is the same. Whether we are going to run it inside 'user > instance' > > or inside ramdisk it does not affect

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

ecause Shotgun is a generic > tool. Please review these [1], [2]. > > [1] https://review.openstack.org/#/c/298603 > [2] https://review.openstack.org/#/c/298615 > > > Btw, one of the ideas was to use Fuel task capabilities > to gather diagnostic snapshot. > > Vladimir Koz

Re: [openstack-dev] [ceilometer][horizon] metric-list not complete and show metrics in horizon dashboard

> From: gordon chung [mailto:g...@live.ca] > Sent: Tuesday, April 12, 2016 8:00 AM > > On 12/04/2016 7:47 AM, Safka, JaroslavX wrote: > > > * > > And my question is: How is connected the database table meter and the > command metric-list? > > i assume you mean meter-list. it uses a

Re: [openstack-dev] [Fuel] Newton Design Summit sessions planning

Hi, no problem from my side. On Thu, Apr 14, 2016 at 10:53 AM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Dear colleagues, > > I'd like to request workrooms sessions swap. > > We have a session about Fuel/Ironic integration and I'd like > this session not to overlap with Ironic

Re: [openstack-dev] [nova] Newton midcycle planning

Hi Folks - I'm looking into the options for Intel to host in Hillsboro Oregon. Stay tuned for more details. Thanks Carol -Original Message- From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] Sent: Tuesday, April 12, 2016 9:05 AM To: openstack-dev@lists.openstack.org Subject: Re:

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

Hi, Problems which I see with current Shotgun are: 1. Luck of parallelism, so it's not going to fetch data fast enough from medium/big clouds. 2. There should be an easy way to run it manually (it's possible, but there is no ready-to-use config), it would be really helpful in case if

Re: [openstack-dev] [fuel] Component Leads Elections

Hi, I'm not sure if it's a right place to continue this discussion, but if there are doubts that such role is needed, we should not wait for another half a year to drop it. Also I'm not sure if a single engineer (or two engineers) can handle majority of upcoming patches + specs + meetings around

[openstack-dev] [election][tc] TC Candidacy for Carol Barrett

Hi - I am announcing my candidacy for the OpenStack Technical Committee for the upcoming term. Currently, I am a Data Center Software Planner at Intel. I have been an active member in the community since 2013, working with Community teams to understand market needs and bring that information

Re: [openstack-dev] [ironic] Nominating Julia Kreger for core reviewer

+1 for me. Julia has been an awesome resource and person in the Ironic community :) John -Original Message- From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com] Sent: Thursday, March 24, 2016 12:09 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [ironic] Nominating

Re: [openstack-dev] [Fuel][Infra] Nailgun extensions testing

Hi Roman, >> reasonable to just install it from PyPi (first we need to release Nailgun to PyPi) Yes there will be dependencies, but there should be a way to test core extensions (those which go to standard Fuel build) from master (or any other branch), so installing from pypi is not always an

[openstack-dev] [Fuel][Bareon][Ironic] The future of integration module

Hi, I would like to bring up discussion on Bareon [0] and Ironic integration and plans for the future. But first let me provide background information on the topic. Bareon is partitioning/provisioning system [1] which is based on Fuel-agent [2], currently it's in active development and will be

[openstack-dev] [Bareon] Weekly update

Hi, here is a weekly update from Bareon team. 1. Extensions testing procedure in Fuel (required for Bareon integration). 1.1. Spec is still in progress [0]. 1.2. Email was sent [1] to figure out the best way to do it in OpenStack Infra, we would appreciate for any help on that. 2. Bareon dynamic

[openstack-dev] [OpenStack-Dev][sahara] Community roadmap update

All - Thanks for reviewing the 100' view Sahara slide in yesterday's team meeting. I made the updates we discussed and have posted the updated (and hopefully final) slide for you to check here: https://docs.google.com/presentation/d/1-iGE2LJRs7X5KXABuWOzbekQbQI0JT27QTK7A_RGZkw/edit?usp=sharing

Re: [openstack-dev] [Fuel] [ironic] [inspector] Rewriting nailgun agent on Python proposal

On Thu, Mar 17, 2016 at 3:16 PM, Dmitry Tantsur <dtant...@redhat.com> wrote: > On 03/16/2016 01:39 PM, Evgeniy L wrote: > >> Hi Dmitry, >> >> I can try to provide you description on what current Nailgun agent is, >> and what are potential requirements

Re: [openstack-dev] [Fuel] [ironic] [inspector] Rewriting nailgun agent on Python proposal

Hi Dmitry, I can try to provide you description on what current Nailgun agent is, and what are potential requirements we may need from HW discovery system. Nailgun agent is a one-file Ruby script [0] which is periodically run under cron. It collects information about HW using ohai [1], plus it

Re: [openstack-dev] [all][infra] revert new gerrit

nfortunately, we weren't able to get priority for the project, and I'm afraid it's probably not going to go anywhere now :/ -- Kevin L. Mitchell <kevin.mitch...@rackspace.com> Rackspace __ OpenStack Development Mailing L

[openstack-dev] [Fuel] Plans on networking modularisation

Hi, We've been working on networking modularisation, during this activity Nailgun is being fixed [0] in order to provide better layer boundary between network related code and the rest of the system. The purpose of this email is: 1. To make sure that this activity is known in Fuel team. 2. To

Re: [openstack-dev] [Fuel] Rewriting nailgun agent on Python proposal

Hi Alexander, thanks for bringing this up. >From your list of problems the only problem which I see is 1st, 2nd and 3rd are solvable even with current implementation. Also I don't think that we should continue developing our own HW discovery mechanism, we should consider switching to

Re: [openstack-dev] [Bareon] Weekly update

On Mon, Mar 14, 2016 at 6:53 PM, Evgeniy L <e...@mirantis.com> wrote: > Hi, here is update from Bareon team. > 1. The team was actively helping with reviews/debugging/triage/designs for > Fuel 9.0 release [0-6].2. Changing deployment data with extensions, the > code is merged [7],

[openstack-dev] [Bareon] Weekly update

Hi, here is update from Bareon team. 1. The team was actively helping with reviews/debugging/triage/designs for Fuel 9.0 release [0-6].2. Changing deployment data with extensions, the code is merged [7], also bug is fixed [8].3. Extensions testing procedure spec is still in progress [9].4. Dynamic

Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

Hi Mike, thanks for clarification. On Fri, Mar 11, 2016 at 9:42 AM, Mike Scherbakov wrote: > Thank you for comments folks. > Clarifications, with the feedback incorporated: > 1) We can install plugin developed against 8 to Fuel Mitaka (9). But it > won't appear in the

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

Hi, +1, it's very hard to use current representation of logs for debugging, everybody goes to the node and tries to find required logs, instead of reimplementing debugging friendly tool it would be better to get something ready to use on the master. Thanks, On Fri, Mar 11, 2016 at 12:05 PM,

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

ramework for every change to the framework, so that we can > have > > -1 right away if something goes wrong. > > > > I've started separate thread on general thoughts about backward > > compatibility and multiple releases support, which actually affects > > examples: [1

Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

Hi Mike, comments are inline. On Thu, Mar 10, 2016 at 10:30 AM, Mike Scherbakov wrote: > Hi folks, > in order to make a decision whether we need to support example plugins, > and if actually need them [1], I'd suggest to discuss more common things > about plugins. > >

Re: [openstack-dev] [nova][cinder] Limits on volume read throughput?

tock 3.10 > kernel. It has had many things backported from later kernels, though they > may not have backported the specific improvements you're looking for. > > I think CentOS is using qemu 2.3, which is pretty new. Not sure how new > their libiscsi is though. > > Chris > &g

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

coverage? > > On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L <e...@mirantis.com> wrote: > >> Ilya, >> >> What do you mean by "templates" the plugin which is create by just "fpb >> --create plugin-name"? >> It doesn't cover enough, package inst

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

Ilya, What do you mean by "templates" the plugin which is create by just "fpb --create plugin-name"? It doesn't cover enough, package installation and all range of tasks executions. Thanks, On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov wrote: > Igor, i completely agree,

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

Hi, Plugin examples mustn't be removed, those plugins are part of integration tests for fuel plugin builder, which should be able to build any version of plugin. So there are two ways to solve the problem: 1. Before test run update compatibility matrix for plugins automatically. 2. Continue

Re: [openstack-dev] [Fuel] UI code freeze

Hi, Thank you for your work, really happy to see it done. So as far as I can see from now on in fuel-web repository we have only Nailgun project. Is it correct? On Fri, Feb 26, 2016 at 3:53 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Dear colleagues, > > We are ready for moving

Re: [openstack-dev] [nova][cinder] Limits on volume read throughput?

n <chris.frie...@windriver.com> wrote: > On 03/03/2016 01:13 PM, Preston L. Bannister wrote: > > > Scanning the same volume from within the instance still gets the same >> > ~450MB/s that I saw before. >> >> Hmmm, with iSCSI inbetween that could be

Re: [openstack-dev] [nova][cinder] Limits on volume read throughput?

Note that my end goal is to benchmark an application that runs in an instance that does primarily large sequential full-volume-reads. On this path I ran into unexpectedly poor performance within the instance. If this is a common characteristic of OpenStack, then this becomes a question of concern

Re: [openstack-dev] [nova][cinder] Limits on volume read throughput?

cy? The in-instance "dd" CPU use is ~12%. (Not very interesting.) Not sure from where the (apparent) latency comes. The host iSCSI target? The QEMU iSCSI initiator? Onwards... On Tue, Mar 1, 2016 at 5:13 PM, Rick Jones <rick.jon...@hpe.com> wrote: > On 03/01

Re: [openstack-dev] [Openstack-operators] OpenStack Contributor Awards

(maybe further off-topic) Re use of NUCs for OpenStack, I have been doing this as a cheap lab environment for a few months, using the OPNFV Brahmaputra release (OS Liberty and ODL Lithium/Beryllium). It works great, and has really helped me come on board with OpenStack (as compared to

[openstack-dev] [nova][cinder] Limits on volume read throughput?

I have need to benchmark volume-read performance of an application running in an instance, assuming extremely fast storage. To simulate fast storage, I have an AIO install of OpenStack, with local flash disks. Cinder LVM volumes are striped across three flash drives (what I have in the present

[openstack-dev] Limits on volume read throughput?

I have need to benchmark volume-read performance of an application running in an instance, assuming extremely fast storage. To simulate fast storage, I have an AIO install of OpenStack, with local flash disks. Cinder LVM volumes are striped across three flash drives (what I have in the present

Re: [openstack-dev] [Fuel][Solar] Integration in 9.0

Hi Jedrzej, >> Maybe instead blueprint in 1st step should we create full blown fuel-spec? If there is anything to be discussed in implementation, or there are different options to do it, it's better to have blueprint and spec, so everybody will be able to see what the integration looks like.

Re: [openstack-dev] [Fuel] Question about Feature Freeze Exceptions for non-invasive features

dae...@mirantis.com > wrote: > If the spec is not going to require code changes in 9.0/Mitaka, why not > simply target it for 10.0/Newton? > > On Thu, Feb 25, 2016 at 05:21:55PM +0300, Evgeniy L wrote: > > Hi, > > > > We have a spec where we are trying to do research and d

[openstack-dev] [Fuel] Question about Feature Freeze Exceptions for non-invasive features

Hi, We have a spec where we are trying to do research and describe how we are going to test extensions [0], we will not be able to land it before feature freeze, so should we get feature freeze exception for it? Or it will not be a problem to merge it even after FF? The spec itself is more about

[openstack-dev] [Bareon] Weekly update

Hi, Here is weekly update from Bareon team. 1. 3 specs from Cray team were merged [0], roadmap was properly adjusted [1] 2. Changing deployment data using extensions in Nailgun [2], spec is merged, code is on review [3] 3. Extensions testing procedure, spec is in progress [4] 4. Dynamic

Re: [openstack-dev] [Fuel] Wildcards instead of

Hi, +1 to Igor, plugin developer should be able to granularly define what she/he wants to be executed on the node, without assumptions from our side. `exclude` - field doesn't look like a good solution to me, it will be hard to support and migrate plugins to newer version OpenStack release. I

Re: [openstack-dev] [fuel][nailgun][volume-manager][fuel-agent] lvm metadata size value. why was it set to 64M?

Hi Alexander, I was trying to trace the change and found 3 year old commit, yes it's hard to recover the reason [0]. So what we should ask is what is a right way to calculate lvm metadata size and change this behaviour. I would suggest at least explicitly set metadata size on Nailgun side to the

Re: [openstack-dev] [fuel] Fuel plugins: lets have some rules

Hi, I have some comments on CI for plugins, currently there is a good instruction on how to install your own CI and using fuel-qa write your own tests [0], since just running BVT is not enough to make sure that plugin works, we should provide a way for a plugin developer to easily extend

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

That is awesome, happy to finally see it enabled! On Mon, Feb 15, 2016 at 9:32 PM, Anastasia Urlapova wrote: > Aleksey, great news! > > On Mon, Feb 15, 2016 at 7:36 PM, Alexey Shtokolov > wrote: > >> Fuelers, >> >> Task based deployment engine

[openstack-dev] [Bareon] Weekly update

Hi, After the discussion with some folks, we agreed that it might be useful for the community to start sending weekly updates on what Bareon team is working on and what is our progress. So here is a first weekly update from Bareon team. 1. Data pipelines for Nailgun integration (changing

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

ould you please clarify what multi-package is? Thanks, On Fri, Feb 12, 2016 at 2:57 PM, Ilya Kutukov <ikutu...@mirantis.com> wrote: > > > On Fri, Feb 12, 2016 at 2:03 PM, Evgeniy L <e...@mirantis.com> wrote: > >> Ilya, >> >> What do you mean by "d

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

ve some things which are related to the deployment specified in the root and some in specific release. There is consistent mechanism to specify such kind of things, lets just use it. Thanks, On Fri, Feb 12, 2016 at 1:24 PM, Ilya Kutukov <ikutu...@mirantis.com> wrote: > > > On Fri, Feb

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

Ilya, >> My opinion that i've seen no example of multiple software of plugins versions shipped in one package or other form of bundle. Its not a common practice. With plugins we extend Fuel capabilities, which supports multiple operating system releases, so it's absolutely natural to extend

  1   2   3   4   5   >