Re: [openstack-dev] [midonet] ping cannot work from VM to external gateway IP.

Are the gateway nodes virtualized? If so, are you allowing promiscuous mode / MAC spoofing? > On Dec 16, 2015, at 4:19 AM, Li Ma wrote: > > Updated: > > Lots of ARP requests from external physical router to VM are catched > on the physical NIC binded to provider

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

From this operator’s perspective this is exactly the element of community culture that, by encouraging the proliferation of projects and tools, is making the OpenStack landscape more complex and less {user,operator,architect,business decision maker} friendly. In my opinion, it is essentially a

Re: [openstack-dev] [puppet] Moving puppet-ceph to the Openstack big tent

On 09/28/2015 08:31 AM, David Moreau Simard wrote: > puppet-ceph currently lives in stackforge [1] which is being retired > [2]. puppet-ceph is also mirrored on the Ceph Github organization [3]. > This version of the puppet-ceph module was created from scratch and > not as a fork of the (then)

Re: [openstack-dev] [puppet][keystone] To always use or not use domain name?

On 08/07/2015 01:58 PM, Rich Megginson wrote: Would someone who actually has to deploy/maintain puppet manifests and supporting code chime in here? How do you feel about having to ensure that every domain scoped Keystone resource name must end in ::domain? At the very least, if not using

Re: [openstack-dev] [puppet][keystone] To always use or not use domain name?

On 08/10/2015 10:24 AM, Rich Megginson wrote: As an operator, I like the ::$domain notation. I think the benefits it brings in terms of clarity outweigh any downsides. If you have to add ::$domain to all of your manifests and supporting code, what impact does that have? Practically speaking,

Re: [openstack-dev] Should project name be uppercase or lowercase?

Yuiko Takada wrote: How do you think which should we use uppercase vs lowercase for representing project names? They are proper names. The clear grammatical standard is capitalization. With that in mind, and unless there is some compelling reason for them not to be capitalized (I can't

Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

Aleksandr Didenko wrote: just wanted to mention another tool to work with 'Puppetfile' - r10k: I am a big fan of r10k - it is what we use internally @ Puppet and we encourage our users to do the same. https://github.com/puppetlabs/r10k Regards, Richard SysOps Engineer @ Puppet Labs

Re: [openstack-dev] [puppet] Clarification of 'Puppet Modules' Project Scope

Emilien Macchi wrote: I have a preference for #1 since IMHO it makes more sense for Midokura to have their Puppet module close to their code but I would not be against having it on Stackforge. [...] If you look at contributors [1], the history shows that this module has been written by people

Re: [openstack-dev] [HA] RFC: moving Pacemaker openstack-resource-agents to stackforge

Adam Spiers wrote: Martin Loschwitz, who owns this repository, has since moved away from OpenStack, and no longer maintains it. I recently proposed moving the repository to StackForge, and he gave his consent and in fact said that he had the same intention but hadn't got round to it I think

[openstack-dev] [puppet] Clarification of 'Puppet Modules' Project Scope

I am currently hoping to build consensus (or seek clarity if I am the only one with this question) about the appropriate scope for our 'Puppet Modules' project. The question in my mind is if we: A) Only include those modules which represent a 1:1 mapping with other OpenStack projects. B)

Re: [openstack-dev] [puppet] (officially) deprecate stable/{grizzly, havana} branches

Matt Fischer wrote: +1 from me for deprecation. I'd also like to know or have an official policy for future deprecations, such as when will we deprecate Icehouse? On Tue, Jun 16, 2015 at 9:50 AM, Emilien Macchi emil...@redhat.com mailto:emil...@redhat.com wrote: Hi, Some of our

Re: [openstack-dev] [puppet] OpenStack Puppet configuration for HA deployment

Cristina Aiftimiei wrote: The puppetlabs-openstack clearly states: Limitations * High availability and SSL-enabled endpoints are not provided by this module. As Matt touched on, you really should be building your own 'composition layer' for deploying production services

[openstack-dev] [puppet] [zaqar] Adding puppet-zaqar Module to Puppet Modules Project

Here are the two changes I submitted for review to get puppet-zaqar added to the project: https://review.openstack.org/#/c/191942/ https://review.openstack.org/#/c/191946/ I am not sure these are 100% correct, but I followed the guide[0] as well as I could. Any feedback would be

Re: [openstack-dev] [puppet] OpenStack Puppet configuration for HA deployment

Cristina Aiftimiei wrote: thank you very much for the suggestion. We are trying to achieve something like you describe - just that I didn't know how to ... describe what we want :). Your sugestion is very, very interesting. So from where do you advice that we start from? I'm looking at

Re: [openstack-dev] [puppet][zaqar] Help needed creating Zaqar manifests for puppet.

Flavio Percoco wrote: Greetings, I'm reaching out to our puppet community looking for help on creating Zaqar's puppet manifests. We've started doing lots of work to help the community adopt Zaqar and it'd be a shame to get at the end of the road without having OPs friendly deployment tools. I

Re: [openstack-dev] [puppet][zaqar] Help needed creating Zaqar manifests for puppet.

James E. Blair wrote: If the PuppetOpenStack project will be adopting this, then we can just go ahead and start it in openstack/. You can create the project-config change that way, and then adjust the list of repos in the governance repository later (prior TC approval is not needed for trivial

Re: [openstack-dev] [nova] Should we add instance action event to live migration?

Andrew Laski wrote: There are many reasons a deployer may want to live-migrate instances around: capacity planning, security patching, noisy neighbors, host maintenance, etc... and I just don't think the user needs to know or care that it has taken place. They might care, insofar as live

Re: [openstack-dev] [ops][tags][packaging] ops:packaging tag - a little common sense, please

. I don't believe the Ops Tags team should be curating the packaging tags -- the packaging community should do that, and do that under the main openstack/governance repository. Again, agreed. The area of concern needs to map to the area of responsibility. Regards, Richard Raseley SysOps

Re: [openstack-dev] [puppet] Change abandonment policy

Colleen Murphy wrote: 3) Manually abandon after N months/weeks changes that have a -1 that was never responded to ``` If a change is submitted and given a -1, and subsequently the author becomes unresponsive for a few weeks, reviewers should leave reminder comments on the review or attempt to

[openstack-dev] [Puppet] Keystone Module Now 'Puppet Approved'

and the community for building such a quality module. I look forward to helping obtain this designation for as many of our other modules as possible. Regards, Richard Raseley Systems Operations Engineer @ Puppet Labs [0] - https://forge.puppetlabs.com/stackforge/keystone [1] - https

Re: [openstack-dev] [Puppet] Proposed Change in Nova Service Defaults

Matt Fischer wrote: Was the intent here to allow bringing up new compute hosts without them being enabled? If so there's another flag that could be set to manage that state. Mathieu posited the following intent in the review: It was used in some active/passive setup (as stated in the bug

[openstack-dev] [Puppet] Proposed Change in Nova Service Defaults

review[0]. Regards, Richard Raseley System Operations Engineer @ Puppet Labs [0] - https://review.openstack.org/#/c/184656/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ

Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy

Zane Bitter wrote: Steve is working on a patch to allow package-based updates of overcloud nodes[1] using the distro's package manager (yum in the case of RDO, but conceivable apt in others). Note we're talking exclusively about minor updates, not version-to-version upgrades here. Dan mentioned

Re: [openstack-dev] [glance] [kolla] [magnum] [nova] [neutron] Vancouver Summit Operations Containers Session

Flavio Percoco wrote: There's work going on on something called Artifacts[0], which - in a poorly worded definition - is an enhancement of the current image model in Glance. It'll take some time for the full migration to happen but that should solve your requirement. [0]

Re: [openstack-dev] [Puppet] puppet-keystone federation module

On May 25, 2015, at 11:35 AM, Iury Ferreira iurygreg...@gmail.com wrote: Hello everyone, I'm new in the community and i'm starting to work with K2K Federation. I have created scripts in python to easily configure SP (Service Provider) and IdP (Identity Provider) in a K2K environment. I

Re: [openstack-dev] [Puppet] puppet-keystone federation module

different, I need to create two blueprints or just one? 2015-05-25 16:30 GMT-03:00 Richard Raseley rich...@raseley.com: On May 25, 2015, at 11:35 AM, Iury Ferreira iurygreg...@gmail.com wrote: Hello everyone, I'm new in the community and i'm starting to work with K2K Federation. I have

Re: [openstack-dev] [glance] [kolla] [magnum] [nova] [neutron] Vancouver Summit Operations Containers Session

Daniel Comnea wrote: Since i couldn't attend the summit, are there any AIs which needs to happen/ take place and which i can keep an eye on? There weren't any action items, which aren't already (in whole or in part) in flight as part of their respective product discussions. From my

[openstack-dev] [glance] [kolla] [magnum] [nova] [neutron] Vancouver Summit Operations Containers Session

. Most of the conversation was captured pretty well on the etherpad, which can be found here: https://etherpad.openstack.org/p/YVR-ops-containers A big thank you to everyone who participated - it was really informative. Regards, Richard Raseley SysOps Engineer @ Puppet Labs [0] - http

[openstack-dev] [Puppet] puppet-openstack_zeromq module

Harish Kumar wrote: Hello All, I have written a puppet-openstack_zeromq module using which one can install/configure openstack zeromq reciever. I would like to know if it make sense to host that code with other openstack related puppet module. Please see the code -

Re: [openstack-dev] [new][cloudpulse] Announcing a project to HealthCheck OpenStack deployments

On 05/12/2015 01:20 PM, Vinod Pandarinathan (vpandari) wrote: Hello, I'm pleased to announce the development of a new project called CloudPulse. CloudPulse provides Openstack health-checking services to both operators, tenants, and applications. This project will begin as a StackForge project

Re: [openstack-dev] [neutron][Nagios] Configure Nagios to monitor neutron agents

Leo Y wrote: Can anyone direct me to instructions or example of how to configure Nagios to monitor neutron L2 and L3 agents? Leo, Though I don't think the content directly addresses the agents you called out, please take a look at the following links: *

Re: [openstack-dev] [all] Question for the TC candidates

Doug Hellmann wrote: I think we chose blog posts for their relative permanence, and retweetability. Maybe we should post to the mailing list instead, if the contributor community follows the list more regularly than blogs? I like blog posts for the reasons you mentioned. Perhaps sending a

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

there. Regards, Richard Raseley SysOps Engineer Puppet Labs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org

Re: [openstack-dev] [puppet] CI status proposal for puppet-syntax-future jobs

Emilien Macchi wrote: I dressed a spreadsheet with the current status of our CI [1]. You can see that we need to work on Puppet4.0 [2] and beaker [3]. Otherwise, gate-puppet-*-puppet-syntax-future is green everywhere and I don't see any reason why they should not vote in our CI process. Also,

Re: [openstack-dev] [puppet] rabbit/kombu settings deprecations

as it is identified as a transitional step; I do pretty strongly believe that the right long-term model is to treat master as the 'bleeding edge' and to only pin yourself to stable releases. Regards, Richard Raseley SysOps Engineer Puppet Labs

Re: [openstack-dev] [puppet] naming of the project

), but rather is a purely defensive decision. We are in the process of reevaluating our usage guidelines, but there is no firm timetable as of this moment. Regards, Richard Raseley SysOps Engineer Puppet Labs __ OpenStack

Re: [openstack-dev] [puppet] naming of the project

this on to people internally to find out if there are any issues with using the Puppet name. Regards, Richard Raseley SysOps Engineer Puppet Labs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe

Re: [openstack-dev] [puppet] PTL Candidacy

Emilien Macchi wrote: As we want to move under the big tent, we decided in the last Puppet OpenStack meeting that we need a PTL for the next Cycle. I would like to announce my candidacy. Emilien, Though I've only been involved with the project for a short time, it is clear that you are an