Re: [openstack-dev] [Openstack] [Ceilometer] Ceilometer Python API Documentation

hi Hassaan, there's a similar link here: http://docs.openstack.org/developer/python-ceilometerclient i don't know if we have official docs but you can see some usage examples here: https://www.rdoproject.org/CeilometerQuickStart#Exploring_with_the_CLI On 18/06/2015 1:24 AM, Hassaan Ali wro

[openstack-dev] [glance] V3 Authentication for swift store

Hey everyone, TL;DR: glance_store requires a way to do v3 authentication to the swift backend. The keystone team is making a push to properly deprecate the v2 authentication APIs this cycle. As part of that we have a series of devstack reviews that moves devstack over to only using v3 APIs[1]

[openstack-dev] [Openstack] [Ceilometer] Ceilometer Python API Documentation

Hi, I am looking for Openstack Ceilometer Python API Documentation that includes example codes and guidelines for using it. So far I have been able to find the following link but it is not that much helpful: http://docs.openstack.org/developer/python-heatclient/ Your help will be highly apprecia

[openstack-dev] [Manila] Midcycle meetup dates

The Manila midcycle meetup will be July 29-30 at NetApp's office in Durham North Carolina. For those who can't attend in person there will be video conference (subject to limited slots) and audio conference. We will work on the agenda for the meetup in coming weeks. -Ben Swartzlander ___

Re: [openstack-dev] [Manila] Network path between admin network and shares

On 06/11/2015 04:52 PM, Rodrigo Barbieri wrote: Hello all, There has been a lot of discussion around Share Migration lately. This feature has two main code paths: - Driver Migration: optimized migration of shares from backend A to backend B where both backends belong to the same driver vendo

Re: [openstack-dev] [Manila] Ask for help on supportting the 3-rd party CI for HDFS driver

On 06/11/2015 10:34 AM, Jeremy Stanley wrote: On 2015-06-11 07:51:55 +0200 (+0200), Philipp Marek wrote: [...] I still stand by my opinion (as voiced in Vancouver) that for such one-off things (that contributors are not likely to repeat over and over again) it might make sense to have -infra sim

Re: [openstack-dev] [Manila] Changing DB regarding IDs for future migration/replication/AZ support

On 06/03/2015 09:35 AM, Rodrigo Barbieri wrote: Hello guys, I would like to bring everyone up to speed on this topic, since we have a weekly meeting tomorrow and I would like to further discuss this, either here or tomorrow at the meeting, since this is something that is a pre-requisite for

Re: [openstack-dev] [Sahara] Difference between Sahara and CloudBrak

I tried (or tried to try) Cloudbreak recently, as I need to deploy a newer version of HDP than Sahara supports. The interface is slick, but lacks the ability to make some choices about your OpenStack installation. The heat template the software generated wouldn't work with my deployment, and there

Re: [openstack-dev] [Manila] Expected Manila behavior for creation of share from snapshot

On 06/03/2015 12:43 PM, Deepak Shetty wrote: On Tue, Jun 2, 2015 at 4:42 PM, Valeriy Ponomaryov mailto:vponomar...@mirantis.com>> wrote: Deepak, "transfer-*" is not suitable in this particular case. Usage of share networks causes creation of resources, when "transfer" does n

Re: [openstack-dev] Proposing Brian Haley to Neutron L3 Core Reviewer Team

Congratulations Brian! Welcome to the team! Edgar On 6/17/15, 3:59 PM, "Carl Baldwin" wrote: >It has been a week and feedback has been positive and supportive of >Brian's nomination. Welcome to the L3 core reviewer team, Brian. > >Carl > >On Wed, Jun 10, 2015 at 1:11 PM, Carl Baldwin wrot

Re: [openstack-dev] [Ceilometer][Gnocchi] question on integration with time-series databases

On 17/06/2015 12:57 PM, Chris Dent wrote: On Tue, 16 Jun 2015, Simon Pasquier wrote: I'm still struggling to see how these optimizations would be implemented since the current Gnocchi design has separate backends for indexing and storage which means that datapoints (id + timestamp + value) an

Re: [openstack-dev] [Congress] Mid-cycle sprint

How many people do you think you will have? We have a midcycle in Boston University, July 15-17 and you are welcome to join in. I am pretty sure we will have more than enough capacity, considering the size of the Congress team. Hotels might be a bit of an issue, as we are getting close, and

Re: [openstack-dev] [ceilometer] When do we import aodh?

i've no idea how to add comments to github so i'll ask here. On 16/06/2015 11:12 AM, Julien Danjou wrote: On Tue, Jun 16 2015, Chris Dent wrote: 5. anything in tempest to worry about? Yes, we need to adapt and reenable tempest after. 6. what's that stuff in the "ceilometer" dir? 6.1. L

Re: [openstack-dev] [nova][ceilometer] proposal to send bulk hypervisor stats data in periodic notifications

not familiar/smart enough to comment on design within Nova but i'm very much in favour if this is possible. the polling option in Ceilometer was always a means to get information not readily available via notifications. that said, i don't think we can completely do away with polling. i'm aware

Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks

Kevin, Yes, the solution to slow performance on public registry servers is to cache content locally. Arranging that is not difficult, but we are not to that point yet. Basically you set up the bay models to use heat templates that set Docker Distribution to use a cloud local upstream. That ups

Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a dashboard for Ironic‏

Hi Krotscheck, Sorry for not attending the last meeting due to TZ. Yes, Horizon is moving towards an Angular application, but for now there’s no any Angular Dashboard landed. I think it’s high time that we should make a standard for other projects which want to horizon compatible on whether th

Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks

That would work, but would be a per tenant thing? So if you had lots of tenants using the same image, it would redownloaded lots of times. Are there any plans for glance integration so the cloud deployer could cache it in the image catalog? I seem to remember a version of docker that could use g

Re: [openstack-dev] [opensatck-dev][trove]redis replication

Thanks a lot Mariam -- Original -- From: "Mariam John"; Date: Wed, Jun 17, 2015 08:41 PM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [opensatck-dev][trove]redis replication Have you checked the blue

[openstack-dev] [Neutron] service chaining feature development meeting at 10am pacific time June 18

Hello everyone, Our next weekly IRC meeting for the OpenStack service chain feature development is 10am pacific time June 18 (UTC 1700) Following is the meeting info: Weekly on Thursday at 1700 UTC in #openstack-meetin

Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks

Kevin, Magnum has a plan for dealing with that. Solum will likely have a Magnum integration that will leverage it: https://blueprints.launchpad.net/magnum/+spec/registryv2-in-master With that said, yes, you could also optimize the performance of the upstream by caching it locally in swift. You

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

On 6/17/15, 10:59 AM, "Neil Jerram" wrote: > > >On 17/06/15 16:17, Kris G. Lindgren wrote: >> See inline. >> >> >> Kris Lindgren >> Senior Linux Systems Engineer >> GoDaddy, LLC. >> >> >> >> On 6/17/15, 5:12 AM, "Neil Jerram" wrote: >> >>> Hi Kris, >

Re: [openstack-dev] [taskflow] Returning information from reverted flow

Ok, so https://review.openstack.org/#/c/192942/ is a WIP of this. Seems to mostly work, just need to tweak a few more engine unit tests... -Josh Dulko, Michal wrote: -Original Message- From: Joshua Harlow [mailto:harlo...@outlook.com] Sent: Tuesday, June 16, 2015 4:52 PM To: OpenStac

[openstack-dev] [neutron] [networking-sfc] Project repo setup and ready to roll

Hi, The infrastructure jobs are completed. The project repository [1] has been provisioned, and it is ready to go. Spec [2] is being moved to the new repo, with patch [3]. Any documentation/specification effort that pertains, and/or is solely focused on SFC, should target the new repo from now on.

Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks

so, to not beat up on the public facing server, the user would have to copy the container from the public server to the cloud's swift stoage, then the docker hosts could pull from there? Thanks, Kevin From: Adrian Otto [adrian.o...@rackspace.com] Sent: We

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

> On 18 Jun 2015, at 2:59 am, Neil Jerram wrote: > > > > On 17/06/15 16:17, Kris G. Lindgren wrote: >> See inline. >> >> >> Kris Lindgren >> Senior Linux Systems Engineer >> GoDaddy, LLC. >> >> >> >> On 6/17/15, 5:12 AM, "Neil Jerram" wrote: >>

Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks

Kevin, > On Jun 17, 2015, at 4:03 PM, Fox, Kevin M wrote: > > Would then each docker host try and redownload the the prebuilt container > externally? If you build from source, does it build it once and then all the > docker hosts use that one local copy? Maybe Solum needs a mechanism to pull

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

> On 17 Jun 2015, at 8:35 pm, Neil Jerram wrote: > > Hi Sam, > > On 17/06/15 01:31, Sam Morrison wrote: >> We at NeCTAR are starting the transition to neutron from nova-net and >> neutron almost does what we want. >> >> We have 10 “public" networks and 10 “service" networks and depending on

Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks

Would then each docker host try and redownload the the prebuilt container externally? If you build from source, does it build it once and then all the docker hosts use that one local copy? Maybe Solum needs a mechanism to pull in a prebuilt LP? Thanks, Kevin

Re: [openstack-dev] Proposing Brian Haley to Neutron L3 Core Reviewer Team

It has been a week and feedback has been positive and supportive of Brian's nomination. Welcome to the L3 core reviewer team, Brian. Carl On Wed, Jun 10, 2015 at 1:11 PM, Carl Baldwin wrote: > Folks, > > As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to > propose Brian Haley as

Re: [openstack-dev] [Nova]

Thanks for the pointer, Matt. On Wed, Jun 17, 2015 at 2:40 PM, Matt Riedemann wrote: > > > On 6/17/2015 3:53 PM, Sourabh Patwardhan wrote: > >> Hello, >> >> I'm working on a new vif driver [1]. >> As part of the review comments, it was mentioned that a generic VIF >> driver will be introduced in

Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack

Excerpts from Kyle Mestery's message of 2015-06-17 13:54:06 -0700: > On Wed, Jun 17, 2015 at 3:48 PM, Doug Hellmann > wrote: > > > Excerpts from Dan Smith's message of 2015-06-17 13:16:46 -0700: > > > > Every change like this makes it harder for newcomers to participate. > > > > Frankly, it makes

[openstack-dev] [puppet] preparing Kilo release (6.0.0)

As we decided at the Summit, we are in the process to prepare a Kilo release. All the work can be tracked here: https://docs.google.com/spreadsheets/d/1XVrmEiLrJSdxDo-S_vFB7ljxTdYg-pe8hiMUryRor5A/edit#gid=0 https://etherpad.openstack.org/p/puppet-kilo-release Please raise any outstanding patch in

[openstack-dev] [neutron][api] Neutron micro-versioning update

As you are probably aware an api-wg guideline for microversioning is under review [1] Needless to say, neutron developers interested in this work should have a look at [1] - if nothing else because we need to ensure we are aligned - and influence the guideline were appropriate. Experimental APIs a

Re: [openstack-dev] [Glance] [all] Proposal for Weekly Glance Drivers meeting.

Erno, thanks for raising the concerns. tl;dr; * The meeting allows people to focus on spec reviews. * It also encourages people to think about some of the blockers on a weekly basis and drive the project forward. * It does NOT intend to discourage open discussion on gerrit or ML. The specs can a

[openstack-dev] [puppet] Re: duplicate keystone endpoints

We’ve had this same problem, too, and I’d agree it should fail the Puppet run rather than just passing. Would you mind writing up a bug report for this at https://launchpad.net/puppet-openstacklib ? I have this on my list of stuff to fix when we go to Kilo (soon), so if somebody else doesn’t f

Re: [openstack-dev] [puppet] New Juno (5.1.0) release

On 06/17/2015 09:57 AM, Emilien Macchi wrote: (...) > > All modules having stable/juno will be released 5.1.0 both in OpenStack > and Puppet forge. This is done. Puppet modules have now 5.1.0 release in both OpenStack repositories and Puppetforge. Special kudos to our team for their help to m

Re: [openstack-dev] [Nova]

On 6/17/2015 3:53 PM, Sourabh Patwardhan wrote: Hello, I'm working on a new vif driver [1]. As part of the review comments, it was mentioned that a generic VIF driver will be introduced in Liberty, which may render custom VIF drivers obsolete. Can anyone point me to blueprints / specs for the

Re: [openstack-dev] [all] setup.py executable bit

+1 both to using -x and to removing the shebang. On Wed, Jun 17, 2015 at 2:47 PM, Doug Hellmann wrote: > Excerpts from Robert Collins's message of 2015-06-18 06:40:33 +1200: >> An unintended side effect of the requirements refactoring was that we >> changed from preserving the 'x' bit on setup.py

Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack

On Wed, Jun 17, 2015 at 3:48 PM, Doug Hellmann wrote: > Excerpts from Dan Smith's message of 2015-06-17 13:16:46 -0700: > > > Every change like this makes it harder for newcomers to participate. > > > Frankly, it makes it harder for everyone because it means there are > > > more moving parts, but

[openstack-dev] [Nova]

Hello, I'm working on a new vif driver [1]. As part of the review comments, it was mentioned that a generic VIF driver will be introduced in Liberty, which may render custom VIF drivers obsolete. Can anyone point me to blueprints / specs for the generic driver work? Alternatively, any guidance on

Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack

Excerpts from Dan Smith's message of 2015-06-17 13:16:46 -0700: > > Every change like this makes it harder for newcomers to participate. > > Frankly, it makes it harder for everyone because it means there are > > more moving parts, but in this specific case many of the people > > involved in these

Re: [openstack-dev] [Magnum] Docker Native Networking

Team, This blueprint needs an assignee: https://blueprints.launchpad.net/magnum/+spec/native-docker-network I have moved the whiteboard discussion to the etherpad: https://etherpad.openstack.org/p/magnum-native-docker-network Please take a moment to put your input on the ether pad so we can draf

Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks

Thanks Christopher. Will do for sure. -Murali From: Christopher Aedo Sent: Wednesday, June 17, 2015 3:24 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads f

Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks

On Wed, Jun 17, 2015 at 12:53 PM, Murali Allada wrote: > Kevin\Keith, > > Yes, we would like to use the catalog for globally available artifacts, such > as operator languagepacks. More specifically the catalog would be a great > place to store metadata about publicly available artifacts to make

Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack

> Every change like this makes it harder for newcomers to participate. > Frankly, it makes it harder for everyone because it means there are > more moving parts, but in this specific case many of the people > involved in these messaging drivers are relatively new, so I point > that out. I dunno ab

[openstack-dev] [Solum][Mistral] Help with a patch

Hi Mistral team, Solum's devstack gate is running into an issue probably due to the change in location of mistral's repositories. Here is the bug: https://bugs.launchpad.net/mistral/+bug/1466149 There is a patch which tries to fix the issue: https://review.openstack.org/#/c/192754/1 If w

Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks

Kevin\Keith, Yes, we would like to use the catalog for globally available artifacts, such as operator languagepacks. More specifically the catalog would be a great place to store metadata about publicly available artifacts to make them searchable and easy to discover. The catalog would point t

Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack

On Wed, Jun 17, 2015 at 2:44 PM, Sean Dague wrote: > On 06/17/2015 03:08 PM, Doug Hellmann wrote: > > Excerpts from Sean Dague's message of 2015-06-17 14:07:35 -0400: > >> On 06/17/2015 01:29 PM, Clint Byrum wrote: > >>> Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: > On 0

Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack

On 06/17/2015 03:08 PM, Doug Hellmann wrote: > Excerpts from Sean Dague's message of 2015-06-17 14:07:35 -0400: >> On 06/17/2015 01:29 PM, Clint Byrum wrote: >>> Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: On 06/16/2015 12:49 PM, Clint Byrum wrote: > Excerpts from Sean

Re: [openstack-dev] [all] setup.py executable bit

On 6/17/15, 13:53, "Jeremy Stanley" wrote: >On 2015-06-17 14:47:48 -0400 (-0400), Doug Hellmann wrote: >> +1 both to using -x and to removing the shebang. > >Agreed. We don't want anyone directly invoking this file as an >executable script in PBR-based packages, so I'm strongly in favor of >any

Re: [openstack-dev] [Solum] [ Supporting swift downloads for operator languagepacks

A bit of a tangent, but it seems like the url would be to a public Swift system. I am unclear if a "source git repo" would be relevant but, assuming Swift would be "optional", perhaps users could host catalog LP's in git or some other distribution mechanism and have a method by which solum could

Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks

Hi Kevin, We absolute envision languagepack artifacts being made available via apps.openstack.org (ignoring for a moment that the name may not be a perfect fit, particularly for things like vanilla glance images ... Is it an OS or an App? ... catalog.openstack.org might be more fitting). Anyway,

Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack

Excerpts from Sean Dague's message of 2015-06-17 14:07:35 -0400: > On 06/17/2015 01:29 PM, Clint Byrum wrote: > > Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: > >> On 06/16/2015 12:49 PM, Clint Byrum wrote: > >>> Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: >

Re: [openstack-dev] [Solum] [ Supporting swift downloads for operator languagepacks

This question may be off on a tangent, or may be related. As part of the application catalog project, (http://apps.openstack.org/) we're trying to provide globally accessible resources that can be easily consumed in OpenStack Clouds. How would these global Language Packs fit in? Would the url r

Re: [openstack-dev] [stable] Call for testing: 2014.1.5 (last Icehouse point release) candidate tarballs

> http://tarballs.openstack.org/glance/heat-stable-icehouse.tar.gz copy-paste fail, this should be: http://tarballs.openstack.org/glance/glance-stable-icehouse.tar.gz __ OpenStack Development Mailing List (not for usage qu

Re: [openstack-dev] [all] setup.py executable bit

On 2015-06-17 14:47:48 -0400 (-0400), Doug Hellmann wrote: > +1 both to using -x and to removing the shebang. Agreed. We don't want anyone directly invoking this file as an executable script in PBR-based packages, so I'm strongly in favor of anything we can do to actively discourage that. -- Jere

Re: [openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining

Hi Nicolas, Thanks for your suggestion. Yes, we can add Application ID to the parameter of the flow classifier/filter. The next updated version will reflect this. Actually in its existing design, the parameter field of the flow classifier can be extended in the future to include more flow descr

[openstack-dev] [stable] Call for testing: 2014.1.5 (last Icehouse point release) candidate tarballs

Hi all, We are scheduled to publish 2014.1.5, last Icehouse point release, on Thurs June 18th for Ceilometer, Cinder, Glance, Heat, Horizon, Keystone, Neutron, Nova and Trove. The list of issues fixed can be seen here: https://launchpad.net/ceilometer/+milestone/2014.1.5 https://launchpad.ne

Re: [openstack-dev] [all] setup.py executable bit

Excerpts from Robert Collins's message of 2015-06-18 06:40:33 +1200: > An unintended side effect of the requirements refactoring was that we > changed from preserving the 'x' bit on setup.py, to discarding it. > This happened when we started writing the file atomically rather than > in-place - a go

[openstack-dev] [Ironic] [Nova] How to pass additional information from Flavor to an Ironic driver

Hi everyone, we are developing an Ironic driver for OneView [1], an Infrastructure Management System (IMS) by HP and, in order to deploy the node correctly, the driver needs to know some specific information about the configuration of the physical hardware. In OneView, there is the concept o

[openstack-dev] [all] setup.py executable bit

An unintended side effect of the requirements refactoring was that we changed from preserving the 'x' bit on setup.py, to discarding it. This happened when we started writing the file atomically rather than in-place - a good robustness improvement. Previously the requirements sync, which enforces

Re: [openstack-dev] [Solum] Supporting swift downloads for operator languagepacks

Yes. If an operator wants to make their LP publicly available outside of Solum, I was thinking they could just make GET's on the container public. That being said, I'm unsure if this is realistically do-able if you still have to have an authenticated tenant to access the objects. Scratch that;

[openstack-dev] [Solum] Update on current status

Hi team, With the recent application from our team to be included in the big tent (https://review.openstack.org/190949), I wanted to give a quick update on the state of our project. Before I do that, here is a quick overview of the current capabilities of Solum and a very high-level view o

Re: [openstack-dev] [Solum] Supporting swift downloads for operator languagepacks

To be clear, Randall is referring to a swift container (directory). Murali has a good idea of attempting to use swift client first, as it has performance optimizations that can speed up the process more than naive file transfer tools. I did mention to him that wget does have a retiree feature, a

Re: [openstack-dev] [devstack] apache wsgi application support

On 06/16/2015 05:25 PM, Chris Dent wrote: > On Tue, 16 Jun 2015, Sean Dague wrote: > >> I was just looking at the patches that put Nova under apache wsgi for >> the API, and there are a few things that I think are going in the wrong >> direction. Largely I think because they were copied from the >

Re: [openstack-dev] [Solum] Supporting swift downloads for operator languagepacks

Can't an operator make the target container public therefore removing the need for multiple access strategies? Original message From: Murali Allada Date:06/17/2015 11:41 AM (GMT-06:00) To: "OpenStack Development Mailing List (not for usage questions)" Subject: [openstack-dev] [S

Re: [openstack-dev] [tc] adding magnum-ui to the openstack git namespace

TC, I authorized the addition of the new repo in the ML thread, and have recorded my approval on each of the reviews. Thanks, Adrian Otto — OpenStack Magnum PTL On Jun 17, 2015, at 10:57 AM, Steven Dake (stdake) mailto:std...@cisco.com>> wrote: Hey TCers, In this thread, the Magnum communit

Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack

On 06/17/2015 01:29 PM, Clint Byrum wrote: > Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: >> On 06/16/2015 12:49 PM, Clint Byrum wrote: >>> Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: FYI, One of the things that came out of the summit for Devs

[openstack-dev] [tc] adding magnum-ui to the openstack git namespace

Hey TCers, In this thread, the Magnum community made a commitment to tackle horizon support for our software: http://lists.openstack.org/pipermail/openstack-dev/2015-June/066701.html We would like to add magnum-ui to the list of repos in the openstack namespace. The governance review change: h

[openstack-dev] [QA] Meeting Thursday June 18th at 17:00 UTC

Hi everyone, Just a quick reminder that the weekly OpenStack QA team IRC meeting will be tomorrow Thursday, June 18th at 17:00 UTC in the #openstack-meeting channel. The agenda for tomorrow's meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Anyone is welcome to a

Re: [openstack-dev] [nova] Plan to consolidate FS-style libvirt volume drivers under a common base class

On Wed, Jun 17, 2015 at 11:37:04AM -0500, Matt Riedemann wrote: > > > On 6/17/2015 4:46 AM, Daniel P. Berrange wrote: > >On Tue, Jun 16, 2015 at 04:21:16PM -0500, Matt Riedemann wrote: > >>The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume drivers are all very > >>similar. > >> > >>I want to e

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

Awesome! Thanks. :) Kevin From: Ihar Hrachyshka [ihrac...@redhat.com] Sent: Wednesday, June 17, 2015 9:41 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack

Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: > On 06/16/2015 12:49 PM, Clint Byrum wrote: > > Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: > >> FYI, > >> > >> One of the things that came out of the summit for Devstack plans going > >> forward is to trim it ba

Re: [openstack-dev] [neutron][db] online schema upgrades

On 6/17/15 12:40 PM, Ihar Hrachyshka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/17/2015 11:27 AM, Anna Kamyshnikova wrote: Ihar, thanks for bringing this up! This is very interesting and I think it worth trying. I'm +1 on that and want to participate in this work. Awesome

Re: [openstack-dev] Developers in the Bay Area

Lisette, what is this about? http://it.linkedin.com/in/fsoppelsa On 06/17/2015 07:10 AM, Lisette Sheehan wrote: Hi! I work for an events market research company and am in need of recruiting young developers in the San Francisco Bay Area to answer a short survey to see if they qualify for an

Re: [openstack-dev] [puppet][murano] Developing puppet module for Murano

I am planning on looking into Murano later this year so I'd be interested in helping review this code. I'm puppet-core so feel free to add me to reviews and I can look as time permits. On Wed, Jun 17, 2015 at 9:49 AM, Serg Melikyan wrote: > Emilien, > > Thank you for your proposal, I completely

[openstack-dev] [Tacker][Telco][NFV]: Reminder - weekly IRC meeting tomorrow Jun 18th

Meeting on #openstack-meeting @ 1600UTC (9am PDT) Agenda can be found here: https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_June_18.2C_2015 Feel free to update the agenda if needed. thanks, Sridhar __ OpenStack Devel

Re: [openstack-dev] [puppet][murano] Developing puppet module for Murano

Hi guys! > * Do not merge a patch without at least one review from both groups > * Collaborate to make the module compliant I'm strongly agree with it, because it'll help to avoid some mistakes. Also, someone from puppet-manager-core may to prompt what are we doing wrong or better way for elaborat

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

On 17/06/15 16:17, Kris G. Lindgren wrote: See inline. Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 6/17/15, 5:12 AM, "Neil Jerram" wrote: Hi Kris, Apologies in advance for questions that are probably really dumb - but there a

[openstack-dev] [Solum] Roadmap additions

Hi Adrian, As an FYI, I took a shot at updating the OpenStack wiki view of the Roadmap for Solum per IRC and developer collaboration, where good progress has been made over the last cycle delivering on features that make Solum usable in a production OpenStack system environment. This is, of co

Re: [openstack-dev] [Ceilometer][Gnocchi] question on integration with time-series databases

On Tue, 16 Jun 2015, Simon Pasquier wrote: I'm still struggling to see how these optimizations would be implemented since the current Gnocchi design has separate backends for indexing and storage which means that datapoints (id + timestamp + value) and metric metadata (tenant_id, instance_id, se

[openstack-dev] [cross-project] RBAC Policy Basics

Policy is supposed to allow access control to work across multiple services and endpoints. However, each service has specified policy differently. Here are some of the basic working assumptions for policy enforcement we can use to work towards consistent enforcement. 1) A policy rule shoul

Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS capabilities

Hi John, We were trying to push a very similar spec to enhance the security group API, we covered both DDoS case and another use case for brute force prevention (We did a research to identify common protocols login behaviour in order to identify brute force attacks using iptables) and even some UI

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/17/2015 05:55 PM, Fox, Kevin M wrote: > The biggest issue we have run into with multiple public networks is > restricting which users can use which networks. We have the same > issue, where we may have an internal public network for the > datac

[openstack-dev] [Solum] Supporting swift downloads for operator languagepacks

Hello Solum Developers, When we were designing the operator languagepack feature for Solum, we wanted to make use of public urls to download operator LPs, such as those available for CDN backed swift containers we have at Rackspace, or any publicly accessible url. This would mean that when a us

Re: [openstack-dev] [neutron][db] online schema upgrades

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/16/2015 05:58 PM, Mike Bayer wrote: > > > On 6/16/15 11:41 AM, Ihar Hrachyshka wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> - - instead of migrating data with alembic rules, migrate it in >> runtime. There should be a abst

Re: [openstack-dev] [neutron][db] online schema upgrades

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/17/2015 11:27 AM, Anna Kamyshnikova wrote: > Ihar, thanks for bringing this up! > > This is very interesting and I think it worth trying. I'm +1 on > that and want to participate in this work. > Awesome. > In fact a lot *not strict* migrati

Re: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting

I agree with Rob in terms of tooling and with Travis on rules.Any linting tool is fine with me as long as it does not break the rules we currently have set in Horizon. I believe the rules right now are general enough, so switching to eslint might not be an issue, but its something to look into. And

Re: [openstack-dev] [nova] Plan to consolidate FS-style libvirt volume drivers under a common base class

On 6/17/2015 4:46 AM, Daniel P. Berrange wrote: On Tue, Jun 16, 2015 at 04:21:16PM -0500, Matt Riedemann wrote: The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume drivers are all very similar. I want to extract a common base class that abstracts some of the common code and then let the sub

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

On 17 June 2015 at 17:19, Thierry Carrez wrote: > Ihar Hrachyshka wrote: >> On 06/17/2015 05:40 PM, Douglas Mendizábal wrote: >>> I tend to agree with Thomas that plan D is not ideal. For one, it >>> prevents changes to the stable branch that span multiple CRs, since >>> a two patch change would

Re: [openstack-dev] [nova] Plan to consolidate FS-style libvirt volume drivers under a common base class

On 6/17/2015 7:36 AM, Dmitry Guryanov wrote: On 06/17/2015 12:21 AM, Matt Riedemann wrote: The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume drivers are all very similar. I want to extract a common base class that abstracts some of the common code and then let the sub-classes provide over

Re: [openstack-dev] [nova] Plan to consolidate FS-style libvirt volume drivers under a common base class

On 6/17/2015 8:14 AM, Duncan Thomas wrote: On 17 June 2015 at 15:36, Dmitry Guryanov mailto:dgurya...@parallels.com>> wrote: On 06/17/2015 02:14 PM, Duncan Thomas wrote: On 17 June 2015 at 00:21, Matt Riedemann mailto:mrie...@linux.vnet.ibm.com>

Re: [openstack-dev] [Ironic] ironic-lib library

On 2015-06-17 10:10:22 -0400 (-0400), Doug Hellmann wrote: > Excerpts from Ramakrishnan G's message of 2015-06-17 12:50:25 +0530: > > Seems to me like we can keep ironic-lib git repository as a git submodule > > of the ironic and ironic-python-agent repositories. Any commit in Ironic > > or Ironic

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

Ihar Hrachyshka wrote: > On 06/17/2015 05:40 PM, Douglas Mendizábal wrote: >> I tend to agree with Thomas that plan D is not ideal. For one, it >> prevents changes to the stable branch that span multiple CRs, since >> a two patch change would generate two tags and there would be no >> clear indic

Re: [openstack-dev] Developers in the Bay Area

Lisette Sheehan wrote: > I work for an events market research company and am in need of > recruiting young developers in the San Francisco Bay Area to answer a > short survey to see if they qualify for an in-depth interview regarding > an upcoming developer event in San Francisco. Is this something

Re: [openstack-dev] [nova][ceilometer] proposal to send bulk hypervisor stats data in periodic notifications

I was involved in the IRC discussion, but to reiterate here this would be a wonderful thing to get done. The current polling can be terribly inefficient, and the ceilo team is already looking into other ways to reduce the impact of it. I'm looking forward to helping with this. Cheers, Jason On W

[openstack-dev] [Neutron] [QOS] Request for Additional QoS capabilities

Hello everyone: I would like to test the waters on some new functionality we think is needed to protect OpenStack deployments from some overload situations due to an excessive user or DDOS scenario. We wrote this up in the style of an RFE. Please let us know your thoughts and we can pr

Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a dashboard for Ironic‏

Hey there! Yes, we are duplicating effort. I've spent quite a bit of effort over the past few months landing features inside openstack that will make it possible for a JavaScript client to be imported to horizon as a dependency. This includes CORS, configuration, caching, infra tooling, etc, with

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

The biggest issue we have run into with multiple public networks is restricting which users can use which networks. We have the same issue, where we may have an internal public network for the datacenter, but also, say, a DMZ network we want to put some vm's on, but can't currently extend that n

Re: [openstack-dev] [puppet][murano] Developing puppet module for Murano

Emilien, Thank you for your proposal, I completely agree with it: > * Move the module under the big tent Proposed change in infra [1] and corresponding change in governance [2] > * Adding Puppet OpenStack group part of core permissions I've added puppet-manager-core to puppet-murano-core > * Ke

  1   2   >