Re: [openstack-dev] [Ansible][Infra] Moving ansible roles into big tent?

Hi I will be interested as well. Having these playbooks in ansible can also be useful in order to integrate with infra-ansible project. I really see that collection as a valid alternative for puppet modules, with the advantages that ansible can provide, but of course that moving from puppet to

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

The reason people want offline deployment feature is not because of poor connection, but rather the enterprise intranets where getting subnet with external access sometimes is a real pain in various body parts. -- Best regards, Oleg Gelbukh On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

I've heard very strong requirements on having all-in-one ISO, with no Internet access installation. Why can't we make this optional in the build system? It should be easy to implement, is not it? We can then consider to have this as a default option. Igor, unfortunately > In 2015 I believe we

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

+1 to Alex & Andrey. Let's just be very careful, and consider all the use cases before making a change. If we can have answers to all the use cases, then we are good to go. Important thing which we need to fix now - is to enable easy UX for making changes to environments after deployments. Like

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Agree, we should understand taht this is not engineering decision but rather political/business related and fully functional ISO or ISO+some QCOW2/whatever is a strong requirement. regards, A. On Thu, Sep 10, 2015 at 8:53 AM, Yaguang Tang wrote: > > > On Thu, Sep 10, 2015

Re: [openstack-dev] [TripleO] Releasing tripleo-common on PyPI

On 09/09/2015 12:15 PM, Dougal Matthews wrote: Hi, The tripleo-common library appears to be registered or PyPI but hasn't yet had a release[1]. I am not familiar with the release process - what do we need to do to make sure it is regularly released with other TripleO packages? We will also

[openstack-dev] questions about nova compute monitors extensions

Hi all, I notice nova compute monitor now only tries to load monitors with namespace "nova.compute.monitors.cpu", and only one monitor in one namespace can be enabled( https://review.openstack.org/#/c/209499/6/nova/compute/monitors/__init__.py ). Is there a plan to make

Re: [openstack-dev] [TripleO] trello

On 09/09/15 18:03, Jason Rist wrote: On 09/09/2015 07:09 AM, Derek Higgins wrote: On 08/09/15 16:36, Derek Higgins wrote: Hi All, Some of ye may remember some time ago we used to organize TripleO based jobs/tasks on a trello board[1], at some stage this board fell out of use (the

Re: [openstack-dev] Question about generating an oslo.utils release

Paul, Usually there are releases every week from the oslo team. At the moment, oslo.* releases are frozen until stable/liberty branches are cut. Usually you can also request a new oslo library release by logging a review against openstack/releases repository as well. Depends-On tag works for

[openstack-dev] [CI] [zuul] Can not vote +/-1 verified into gerrit server

Hi, all, In my CI environment, after submitting a patch into openstack-dev/sandbox, the Jenkins Job can be launched automatically, and the result message of the job also can be posted into the gerrit server successfully. Everything seems fine. But in the “Verified” column, there is no

[openstack-dev] Fwd: Re: [neutron][L3][dvr][fwaas] FWaaS

Hi , Instance creation is failing with below error from last 4 days. *2015-09-10 02:14:00.583 WARNING neutron.plugins.ml2.drivers.mech_agent [req-44530c97-56fa-4d5d-ad35-c5e988ab4644 neutron 24109c82ae76465c8fb20562cce67a4f] Attempting to bind with dead agent: {'binary':

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

On Thu, Sep 10, 2015 at 1:52 PM, Igor Kalnitsky wrote: > Hello, > > I agree with Vladimir - the idea of online repos is a right way to > move. In 2015 I believe we can ignore this "poor Internet connection" > reason, and simplify both Fuel and UX. Moreover, take a look

Re: [openstack-dev] [Heat] Multi Node Stack - keystone federation

>>On 09/09/15 04:10, SHTILMAN, Tomer (Tomer) wrote: >> We are currently building in our lab multi cloud setup with keystone >> federation and I will check if my understating is correct, I am >> planning for propose a BP for this once will be clear > On 09/09/15 Zane wrote: >There was further

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

Alex, I absolutely understand the point you are making about need for deployment engineers to modify things 'on the fly' in customer environment. It's makes things really flexible and lowers the entry barrier for sure. However, I would like to note that in my opinion this kind on 'monkey

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

Oleg, Alex gave a perfect example regarding support folks when they need to fix something really quick. It's client's choice what to patch or not. You may like it or not, but it's client's choice. On 10 Sep 2015, at 09:33, Oleg Gelbukh wrote: Alex, I absolutely

Re: [openstack-dev] [glance] [nova] Verification of glance images before boot

Brianna, I can imagine a denial of service attack by uploading images whose signature is invalid if we allow them to reside in Glance In a "killed" state. This would be less of an issue "killed" images still consume storage quota until actually deleted. Also given MD-5 less secure, why not have

[openstack-dev] [Fuel] IRC meeting today

Hi folks, please add topics to the agenda before the meeting: https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda It would be great to discuss: - Critical bugs, and the pipeline of bugs which may become Criticals with larger audience. - Current status of builds from master -

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Folks, what I can see is that most of you represent 'engineering' point of view. Way of installing OpenStack by Fuel is not 'engineering' decision - it is political and business related decision. I believe that possibility to get fully working / not internet dependent ISO or ISO + some additional

Re: [openstack-dev] [glance] differences between def detail() and def index() in glance/registry/api/v1/images.py

This was the case until about two weeks ago. Since 1.0.0 release we have been defaulting to Images API v2 instead of v1 [0]. If you want to exercise the v1 functionality from the CLI client you would need to specify the either environmental variable OS_IMAGE_API_VERSION=1 or use the command

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Mike, > still not exactly true for some large enterprises. Due to all the security, > etc., > there are sometimes VPNs / proxies / firewalls with very low throughput. It's their problem, and their policies. We can't and shouldn't handle all possible cases. If some enterprise has "no Internet"

Re: [openstack-dev] [neutron] RFE process question

Hi James, I think that https://review.openstack.org/#/c/216021/ might be what you are looking for. Please review and see that it fits your requierment. Hopefully this gets approved for next release and i can start working on it, if you would like to join and contribute (or anyone in your team) i

[openstack-dev] Question about generating an oslo.utils release

Hi I have an olso.utils change merged (220620 ). A nova change (220622 ) depends on this. What is the process for creating a new version of olso.utils? Is this performed periodically by a release manager

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Folks I think, Mike is completely right here - we need an option to build all-in-one ISO which can be tried-out/deployed unattendedly without internet access. Let's let a user make a choice what he wants, not push him into embarassing situation. We still have many parts of Fuel which make choices

[openstack-dev] Instance STOPS/STARTS while taking snapshot

Openstack Kilo release Ceph storage backend I have run into an issue lately where I create a snapshot of a running instance, while the snapshot state is "image pending upload" And "Queued" state in the image service, I cant access my Instance I cant access it via the console, ssh and I ran a

Re: [openstack-dev] [Glance] Feature Freeze Exception proposal

Thank you! -- Malini -Original Message- From: Nikhil Komawar [mailto:nik.koma...@gmail.com] Sent: Wednesday, September 09, 2015 8:06 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Glance] Feature Freeze Exception proposal FYI, this was granted FFE. On 9/8/15

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

Folks I have a strong +1 for the proposal to decouple master node and slave nodes. Here are the stregnths of this approach 1) We can always decide which particular node runs which particular set of manifests. This will allow us to do be able to apply/roll back changes node-by-node. This is very

Re: [openstack-dev] [Ironic] Command structure for OSC plugin

On 09/09/2015 06:48 PM, Jim Rollenhagen wrote: On Tue, Sep 01, 2015 at 03:47:03PM -0500, Dean Troyer wrote: [late catch-up] On Mon, Aug 24, 2015 at 2:56 PM, Doug Hellmann wrote: Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400: On 24/08/15 18:19

Re: [openstack-dev] [Ironic] Command structure for OSC plugin

Hi, > Disclaimer: I don't know much about OSC or its syntax, command > structure, etc. These may not be well-formed thoughts. :) > Same here, I don't know much about OSC in general. > So, many of the nova commands (openstack server foo) don't make sense in > an Ironic context, and vice versa.

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Igor Having poor access to the internet is a regular use case which we must support. This is not a crazy requirement. Not having full ISO makes cloud setup harder to complete. Even more, not having hard requirement to create a mirror will detract newcomers. I can say that if I were a user and saw

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

I went forward and filed a bug for this issue (since we agreed that it should be fixed): https://bugs.launchpad.net/horizon/+bug/1494251 The code is already in gerrit (see links in bug), feel free to review. On Fri, Jul 10, 2015 at 1:51 AM Douglas Fish wrote: > I think

Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC

Sean Dague wrote: > Right now, they are all a bunch of files, they can be anywhere. And then > you have other files that have to reference these files by path, which > can be anywhere. We could just punt in that part and say "punt! every > installer and configuration management install needs to

Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC

On 09/10/2015 08:23 AM, Thierry Carrez wrote: > Sean Dague wrote: >> Right now, they are all a bunch of files, they can be anywhere. And then >> you have other files that have to reference these files by path, which >> can be anywhere. We could just punt in that part and say "punt! every >>

Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified into gerrit server

I added Fnst OpenStackTest CI to the third-party ci group. Ramy From: Evgeny Antyshev [mailto:eantys...@virtuozzo.com] Sent: Thursday, September 10, 2015 3:51 AM To: OpenStack Development Mailing List (not for

[openstack-dev] Fwd: Re: [neutron][L3][dvr][fwaas] FWaaS

Hi , neutron-openvswitch-agent is crashing with below error 2015-09-10 04:39:36.675 DEBUG neutron.agent.linux.utils [req-a6c70c4e-aa40-44e4-bd09-493e82bfe43c None None] Command: ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', '--columns=name,other_config,tag', 'list',

Re: [openstack-dev] [Fuel] Let's change the way we distribute Fuel (was: [Fuel] Remove MOS DEB repo from master node)

> Vladimir's proposal was to use smth similar to MiniCD Just to clarify. My proposal is to remove DEB MOS repo from the master node by default and thus from the ISO. That is it. My proposal does not assume having internet connection during installing the master node. Fuel RPM packages together

Re: [openstack-dev] [kilo-devstack] [disk-usage]

disk = 0 does not mean there is no disk. It means the disk image won't be expanded to a larger size. The disk used will be whatever your image size is. -Sean On 09/10/2015 06:54 AM, Abhishek Talwar wrote: > Hi Folks, > > > I have installed devstack kilo version of OpenStack and created

Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC

On 09/09/2015 07:16 PM, Doug Hellmann wrote: > Excerpts from Matt Riedemann's message of 2015-09-09 13:45:29 -0500: >> >> On 9/9/2015 1:04 PM, Doug Hellmann wrote: >>> Excerpts from Sean Dague's message of 2015-09-09 13:36:37 -0400: >> The problem with the static file paths in rootwrap.conf is

Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified into gerrit server

Hi Ramy & Evgeny, Yes, it does work. Thanks a lot. Once I thought there is no need to add the CI group for the sandbox project. Xiexs From: Asselin, Ramy [mailto:ramy.asse...@hp.com] Sent: Thursday, September 10, 2015 7:00 PM To: OpenStack Development Mailing List (not for usage questions)

[openstack-dev] [tempest] Is there a sandbox project how to use tempest test plugin interface?

Hi, I just noticed that from tag 6, the test plugin interface considered ready, and I am eager to start to use it. I have some questions: If I understand well in the future the plugin interface will be moved to tempest-lib, but now I have to import module(s) from tempest to start to use the

[openstack-dev] [kilo-devstack] [disk-usage]

Hi Folks,I have installed devstack kilo version of OpenStack and created an instance on it with flavor “m1.nano” that gives a disk of 0 to your instance. But while checking disk usage of the instance using “disk.usage” meter it gives the output to be greater than 0 so how is it possible

[openstack-dev] [Fuel] Let's change the way we distribute Fuel (was: [Fuel] Remove MOS DEB repo from master node)

Hello, thread! First let me address some of the very good points Alex raised in his email. On Wed, Sep 9, 2015 at 10:33 PM Alex Schultz wrote: > Fair enough, I just wanted to raise the UX issues around these types of > things as they should go into the decision making

[openstack-dev] [Fuel][Plugins] SDK is updated with the latest information

Hi to all, Please be informed that the Fuel Plugin SDK now has a set of useful instructions that cover the following issues: - how to create a new project for Fuel Plugins in /openstack namespace [1]. - how to add your plugin to DriverLog [2] - how to form documentation for your plugin [3]. If

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Igor This is not the case to tell users if they are stupid are not. We are working for our users, not vice versa. On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky wrote: > Mike, > > > still not exactly true for some large enterprises. Due to all the > security, etc., >

Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified into gerrit server

On 10.09.2015 11:30, Xie, Xianshan wrote: Hi, all, In my CI environment, after submitting a patch into openstack-dev/sandbox, the Jenkins Job can be launched automatically, and the result message of the job also can be posted into the gerrit server successfully. Everything seems

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Guys, I really appreciate your opinions on whether Fuel should be all inclusive or not. But the original topic of this thread is different. I personally think that in 2015 it is not a big deal to make the master node able to access any online host (even taking into account paranoid security

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

On 09/10/2015 10:06 AM, James Slagle wrote: TripleO has added a few new repositories, one of which is python-tripleoclient[1], the former python-rdomanager-oscplugin. With the additional repositories, there is an additional review burden on our core reviewers. There is also the fact that folks

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

On 09/10/2015 09:06 AM, James Slagle wrote: > TripleO has added a few new repositories, one of which is > python-tripleoclient[1], the former python-rdomanager-oscplugin. > > With the additional repositories, there is an additional review burden > on our core reviewers. There is also the fact

Re: [openstack-dev] [Fuel] Let's change the way we distribute Fuel (was: [Fuel] Remove MOS DEB repo from master node)

On Thu, Sep 10, 2015 at 4:43 PM Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > > Vladimir's proposal was to use smth similar to MiniCD > > Just to clarify. My proposal is to remove DEB MOS repo from the master > node by default and thus from the ISO. That is it. > My proposal does not

Re: [openstack-dev] [gate] broken by pyeclib 1.0.9 release

On 9/10/2015 9:44 AM, Sean Dague wrote: The pyeclib 1.0.9 release has broken the gate because Swift is in the default grenade upgrade jobs, and Swift stable/kilo allows 1.0.9 (which doesn't compile correctly with a pip install). We're working to pin requirements in kilo/juno right now, but

[openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

TripleO has added a few new repositories, one of which is python-tripleoclient[1], the former python-rdomanager-oscplugin. With the additional repositories, there is an additional review burden on our core reviewers. There is also the fact that folks who have been working on the client code for a

Re: [openstack-dev] [tempest] Is there a sandbox project how to use tempest test plugin interface?

On Thu, Sep 10, 2015 at 02:56:31PM +0200, Lajos Katona wrote: > Hi, > > I just noticed that from tag 6, the test plugin interface considered ready, > and I am eager to start to use it. > I have some questions: > > If I understand well in the future the plugin interface will be moved to >

[openstack-dev] [openstack-ansible] Security hardening

Hey there, I've been looking for some ways to harden the systems that are deployed by os-ansible-deployment (soon to be openstack-ansible?) and I've been using the Center for Internet Security (CIS)[1] benchmarks as a potential pathway for that. There are benchmarks available for various

Re: [openstack-dev] [Ansible][Infra] Moving ansible roles into big tent?

On Thu, Sep 10, 2015 at 09:31:47AM +0200, Yolanda Robla Mota wrote: > Hi > I will be interested as well. Having these playbooks in ansible can also be > useful > in order to integrate with infra-ansible project. > I really see that collection as a valid alternative for puppet modules, with > the

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Vladimir, I give my +1. We must have different repos for MOS and master node. As a sample I am giving a case when we need to implement CentOS 7 support but master node may remain on Centos 6. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Thu, Sep 10, 2015 at 3:06 PM,

[openstack-dev] [gate] broken by pyeclib 1.0.9 release

The pyeclib 1.0.9 release has broken the gate because Swift is in the default grenade upgrade jobs, and Swift stable/kilo allows 1.0.9 (which doesn't compile correctly with a pip install). We're working to pin requirements in kilo/juno right now, but anything that has a grenade job is going to

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Vladimir, * We don't have full ISO anyway * We don't require to create mirror. When you launch your browser, do you mean to have mirror of the Internet locally? Probably, no. The same is here. Internet connection is the common requirement nowadays, but if you don't have one, you definitely need

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Folks I guess I need to get you on-site to deploy something at our user's datacenter. I do want to be able to download an ISO which contains all packages. This may not be the primary artifact of our software suite, but we need to have this opportunity to build full ISO with ALL components.

[openstack-dev] [Congress] Ending feature freeze

Hi all, We're now finished with feature freeze. We have our first release candidate and the stable/liberty branch. So master is once again open for new features. Couple of things to note: 1. Documentation. We should also look through the docs and update them. Documentation is really

Re: [openstack-dev] SOS

Shameless plug: http://apps.openstack.org :) Thanks, Kevin From: Gongys [gong_ys2...@aliyun.com] Sent: Wednesday, September 09, 2015 8:51 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] SOS It should be easy, you

Re: [openstack-dev] [openstack-ansible] Security hardening

On 09/10/2015 09:54 AM, Major Hayden wrote: > Hey there, > > I've been looking for some ways to harden the systems that are deployed by > os-ansible-deployment (soon to be openstack-ansible?) and I've been using the > Center for Internet Security (CIS)[1] benchmarks as a potential pathway for

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Vladimir, * We can not put upstream Ubuntu on ISO by default and publish it. We just can not and thus won't do that. * If a user wants to have all inclusive ISO, he/she will do it on his/her own, on his/her own machine, probably using publicly available Fuel tools, but not using Fuel CI/CD. I am

[openstack-dev] [ALL] Instance Users

Many OpenStack projects have a failry common problem. The lack of well defined way for OpenStack Instances to talk to the OpenStack its running under. Each OpenStack project has been working around it themselves in one form or another, including Heat, Sahara, Trove, Magnum, and others. Zaqar

Re: [openstack-dev] [ironic] [tripleo] [kolla] Possible to support multiple compute drivers?

On Wed, Sep 9, 2015 at 10:25 PM, Steve Gordon wrote: > - Original Message - > > From: "Jeff Peeler" > > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > > > > I'd greatly prefer using

[openstack-dev] [Glance] FFE request for parallel scrubbing

Hi, We had a request for this small spec [1] to be in Liberty. It addresses the concerns around parallel scrubbing performance improvements. The reason for asking for creating a spec was that it can rather affect performance negatively in some cases and a config is to help fine tune that. This

[openstack-dev] [heat] Backup resources and properties in the delete-path

Hi all, So, I've been battling with $subject for the last few days ref [1][2]. The problem I have is that out TestResource references several properties in the delete (check_delete_complete) path[4], which it turns out doesn't work very well if those properties refer to parameters via get_param,

Re: [openstack-dev] [openstack-ansible] Security hardening

On 09/10/2015 11:33 AM, Major Hayden wrote: > On 09/10/2015 11:22 AM, Matthew Thode wrote: >> Sane defaults can't be used? The two bugs you listed look fine to me as >> default things to do. > > Thanks, Matthew. I tend to agree. > > I'm wondering if it would be best to make a "punch list" of

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Dmitry, Thanks a lot. That is exactly what I mean. fuel-createmirror can be used by a user during building ISO, after deployment, never and whenever he/she wants. Standard approach for all repos. That is it. We just don't need to put DEB MOS repo on ISO by default, because it makes little sense

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

On 10/09/15 15:06, James Slagle wrote: TripleO has added a few new repositories, one of which is python-tripleoclient[1], the former python-rdomanager-oscplugin. With the additional repositories, there is an additional review burden on our core reviewers. There is also the fact that folks who

Re: [openstack-dev] [heat] Backup resources and properties in the delete-path

On 10/09/15 12:53, Steven Hardy wrote: Hi all, So, I've been battling with $subject for the last few days ref [1][2]. The problem I have is that out TestResource references several properties in the delete (check_delete_complete) path[4], which it turns out doesn't work very well if those

Re: [openstack-dev] [Neutron][ML2] ML2 late/early-cycle sprint announcement

Hi Gal, I was hoping you will join us in yesterday's ML2 meeting to discuss further. Anyhow, we would love your participation in this activity. Please check the ether pad and see if you could join us in this sprint? If yes, please sign up so that host can make appropriate arrangements.

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Guys, looks like you’ve started to talk about different things. As I see, original proposal was: stop treat MOS DEB repo as a special case and use the same flow for all repos. Your use case does not contradict it. Moreover, it requires standard flow for all repos. ‘Put everything on the ISO’

Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC

Excerpts from Thierry Carrez's message of 2015-09-10 14:23:34 +0200: > Sean Dague wrote: > > Right now, they are all a bunch of files, they can be anywhere. And then > > you have other files that have to reference these files by path, which > > can be anywhere. We could just punt in that part and

Re: [openstack-dev] [openstack-ansible] Security hardening

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/10/2015 11:22 AM, Matthew Thode wrote: > Sane defaults can't be used? The two bugs you listed look fine to me as > default things to do. Thanks, Matthew. I tend to agree. I'm wondering if it would be best to make a "punch list" of CIS

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

On Thu, Sep 10, 2015 at 10:06:31AM -0400, James Slagle wrote: > TripleO has added a few new repositories, one of which is > python-tripleoclient[1], the former python-rdomanager-oscplugin. > > With the additional repositories, there is an additional review burden > on our core reviewers. There is

[openstack-dev] [puppet] [ceilometer] Puppetize OpenStack Aodh

Hi, I'm working [1] on a new Puppet modules for AODH [2]. The good news is that we don't need AODH to have alarming working in Liberty, so people using puppet to deploy Ceilometer will be able to use Alarming with future stable/liberty. I'll of course use puppet-openstack-cookiecutter to create

Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC

Sean Dague wrote: > On 09/10/2015 08:23 AM, Thierry Carrez wrote: >> Now another problem you're describing is that there is no single place >> where those filters end up, depending on the way the projects (or libs) >> are packaged and installed. And it's up to the distros to "fix" the >>

Re: [openstack-dev] [gate] broken by pyeclib 1.0.9 release

Hi Sean, To start with, "pip install PyECLib==1.0.9" works fine on a clean trusty instance. Looking at the gate log - http://logs.openstack.org/92/115092/11/check/gate-grenade-dsvm/ecfb1f5/logs/grenade.sh.txt.gz#_2015-09-10_13_54_32_069: -[snip]- 2015-09-10 13:55:52.335 | Collecting

Re: [openstack-dev] [gate] broken by pyeclib 1.0.9 release

On 9/10/2015 1:31 PM, Gohad, Tushar wrote: Hi Sean, To start with, "pip install PyECLib==1.0.9" works fine on a clean trusty instance. Looking at the gate log - http://logs.openstack.org/92/115092/11/check/gate-grenade-dsvm/ecfb1f5/logs/grenade.sh.txt.gz#_2015-09-10_13_54_32_069:

[openstack-dev] [ceilometer][aodh][gnocchi] Tokyo design session planning

hi, as mentioned during today's meeting, since we have our slots for design summit, we'll start accepting proposals for the telemetry-related topics for the Tokyo summit. similar to previous design summits, anyone is welcome to propose topics related to ceilometer, aodh, gnocchi, or any

[openstack-dev] Fwd: [kolla] Planned maintenance for Delorean instance - September 14-15

FYI -- Forwarded message -- From: Javier Pena Date: Thu, Sep 10, 2015 at 11:50 AM Subject: [Rdo-list] [delorean] Planned maintenance for Delorean instance - September 14-15 To: rdo-list Dear all, Due to a planned maintenance of the

Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC

Just out of curiosity, not 100% related to this thread, but other applications also bundle configuration files (for example heat templates @ https://github.com/openstack/magnum/tree/master/magnum/templates) Should there be some guidelines on how these config files are packaged and distributed

[openstack-dev] [all][Elections] Nominations for OpenStack PTLs (Program Technical Leads) are now open

Nominations for OpenStack PTLs (Program Technical Leads) are now open and will remain open until September 17, 05:59 UTC. All candidacies must be submitted as a text file to the openstack/election repository as explained on the wiki[0]. In order to be an eligible candidate (and be allowed to

[openstack-dev] [infra] PTL candidacy

It's time to toss my hat into the ring for Infrastructure PTL, if you'll have me. I wasn't around at the beginning like my illustrious predecessors, but I've been a core reviewer and root sysadmin for OpenStack's community-maintained project infrastructure these past three years. In that time it's

[openstack-dev] [Horizon]Let's take care of our integration tests

It looks like we've reached the point where our Horizon integration tests are functional again. Thanks for your work on this Timur! (Offer for beer/hug at the next summit still stands) I'd like to have these tests voting again ASAP, but I understand that might be a bit risky at this point. We

Re: [openstack-dev] [keystone] PTL non-candidacy

Best of luck in your new adventures, and thanks for all your hard work! On Thu, Sep 10, 2015 at 5:28 PM, Dolph Mathews wrote: > Thank you for all your work, Morgan! Good luck with the opportunity to > write some code again :) > > On Thu, Sep 10, 2015 at 4:40 PM, Morgan

Re: [openstack-dev] [OpenStack-Infra] [infra] PTL non-candidacy

On Fri, Sep 11, 2015 at 6:56 AM, Jeremy Stanley wrote: > On 2015-09-10 13:27:53 -0700 (-0700), James E. Blair wrote: > [...] > > I do not plan to run for PTL in the next cycle. > [...] > > Thanks for the awesome job you did as PTL these last cycles. I hope > you enjoy a

Re: [openstack-dev] [heat] Backup resources and properties in the delete-path

On 11/09/15 05:02, Zane Bitter wrote: On 10/09/15 12:53, Steven Hardy wrote: Hi all, So, I've been battling with $subject for the last few days ref [1][2]. The problem I have is that out TestResource references several properties in the delete (check_delete_complete) path[4], which it turns

[openstack-dev] [ceilometerclient] Updating global-requirements caps.

Hi all, In trying to fix a few stable/juno issues we need to release a new version of ceilometerclient for stable/juno. This email is to try and raise awareness so that if the proposal is bonkers [1] we can come up with something better. This isn't currently possible due to the current caps

Re: [openstack-dev] custom lbaas driver

Srikumar-- I'm not aware of any particular write-up. The best advice I have is to start with the logging noop driver and refer to the reference haproxy namespace driver to see what these are doing to implement the functionality of LBaaS v2. Sorry! I wish I had better news for you. Stephen On

Re: [openstack-dev] [Horizon]Let's take care of our integration tests

I completely agree about monitoring for integration test failures and blocking until the failure is corrected. The hope is to make sure we've stabilized the integration testing framework a bit before reenabling to vote. Thanks Timur, I know this has been a considerable undertaking. David On

[openstack-dev] [oslo][release] stable/juno branch creation

On Wed, Aug 26, 2015 at 03:11:56PM -0400, Doug Hellmann wrote: > Tony, > > Thanks for digging into this! > > I should be able to help, but right now we're ramping up for the L3 > feature freeze and there are a lot of release-related activities going > on. Can this wait a few weeks for things to

Re: [openstack-dev] [all][Elections] Nominations for OpenStack PTLs (Program Technical Leads) are now open

On Fri, Sep 11, 2015 at 10:24:17AM +1000, Tony Breeds wrote: > Nominations for OpenStack PTLs (Program Technical Leads) are now open and will > remain open until September 17, 05:59 UTC. > > All candidacies must be submitted as a text file to the openstack/election > repository as explained on

[openstack-dev] [keystone] PTL non-candidacy

As I outlined (briefly) in my recent announcement of changes ( https://www.morganfainberg.com/blog/2015/09/09/openstack-career-act-3-scene-1/ ) I will not be running for PTL of Keystone this next cycle (Mitaka). The role of PTL is a difficult but extremely rewarding job. It has been amazing to see

Re: [openstack-dev] [keystone] PTL non-candidacy

Thank you for all your work, Morgan! Good luck with the opportunity to write some code again :) On Thu, Sep 10, 2015 at 4:40 PM, Morgan Fainberg wrote: > As I outlined (briefly) in my recent announcement of changes ( >

Re: [openstack-dev] [OpenStack-Infra] [infra] PTL non-candidacy

Thanks James for the great work done on the team! I am sure we are going to hear a lot more from you in the community ;-) Edgar On 9/10/15, 1:27 PM, "James E. Blair" wrote: >Hi, > >I've been the Infrastructure PTL for some time now and I've been >fortunate to serve

Re: [openstack-dev] [neutron] RFE process question

On 10/09/15 19:39, Gal Sagie wrote: > Hi James, > > I think that https://review.openstack.org/#/c/216021/ might be what you are > looking for. > Please review and see that it fits your requierment. > Hopefully this gets approved for next release and i can start working on > it, if you would like

[openstack-dev] [sahara] mitaka summit session ideas

hey all, i started an etherpad for us to collect ideas about our session for the mitaka summit. https://etherpad.openstack.org/p/mitaka-sahara-session-plans please drop any thoughts or suggestions about the summit there. thanks, mike

[openstack-dev] [magnum] Vote for our weekly meeting schedule

Hi team, Currently, magnum weekly team meeting is scheduled at Tuesday UTC1600 and UTC2200. As our team growing, contributors from different timezones joined and actively participated. I worried that our current meeting schedule (which was decided a long time ago) might not be update-to-date

[openstack-dev] [neutron][nova] - removing "INVALID drop" iptables rule

Hi, I have a patch out in which I want to make sure any allow rules are processed before the rule that drops packets conntrack deems as INVALID.[1] This rule interferes with setups where conntrack might not see the first part of a TCP handshake because of encapsulation in a load balancer

Re: [openstack-dev] [oslo][release] stable/juno branch creation

+1 from me! Thanks, Dims On Thu, Sep 10, 2015 at 7:50 PM, Tony Breeds wrote: > On Wed, Aug 26, 2015 at 03:11:56PM -0400, Doug Hellmann wrote: > > Tony, > > > > Thanks for digging into this! > > > > I should be able to help, but right now we're ramping up for the L3 > >

  1   2   >