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

[Richard Raseley]

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 router port.
> 
> It seems that external physical router doesn't get answers to these
> ARP requests.
> 
> On Wed, Dec 16, 2015 at 8:08 PM, Li Ma  wrote:
>> Hi Midoers,
>> 
>> I have a platform running Midonet 2015 (I think it is the last release
>> when you switch to 5.0).
>> I cannot ping from VM to external gateway IP (which is set up at the
>> physical router side).
>> 
>> VM inter-connectivity is OK.
>> 
>> When I tcpdump packets on the physical interface located in the gateway node,
>> I just grabbed lots of ARP requests to external gateway IP.
>> 
>> I'm not sure how midonet gateway manages ARP?
>> Will the ARP be cached on the gateway host?
>> 
>> Can I specify a static ARP record by 'ip command' on gateway node to
>> solve it quickly (not gracefully)?
>> 
>> (Currently I'm in the business trip that cannot touch the environment.
>> So, I'd like to get some ideas first and then I can tell my partners
>> to work on it.)
>> 
>> Thanks a lot,
>> 
>> --
>> 
>> Li Ma (Nick)
>> Email: skywalker.n...@gmail.com
> 
> 
> 
> --
> 
> Li Ma (Nick)
> Email: skywalker.n...@gmail.com
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 manufactured and completely unnecessary 
distinction. I look forward to the day when, through some yet to be known 
mechanism, we have have a more focused product perspective within the community.

> On Nov 9, 2015, at 10:11 AM, Tim Hinrichs  wrote:
> 
> They shouldn't be combined because they can each be used without the other.  
> That is, they each stand on their own.
> 
> Congress can be used for monitoring or delegating policy without attempting 
> to correct violations (i.e. without needing workflows).
> 
> Mistral can be used to make complex changes without writing a policy.
> 
> Tim
> 
> 
> 
> 
> 
> On Mon, Nov 9, 2015 at 8:57 AM Adam Young  wrote:
> On 11/09/2015 10:57 AM, Tim Hinrichs wrote:
>> Congress happens to have the capability to run a script/API call under 
>> arbitrary conditions on the state of other OpenStack projects, which sounded 
>> like what you wanted.  Or did I misread your original question?
>> 
>> Congress and Mistral are definitely not competing.Congress lets people 
>> declare which states of the other OpenStack projects are permitted using a 
>> general purpose policy language, but it does not try to make complex changes 
>> (often requiring a workflow) to eliminate prohibited states.  Mistral lets 
>> people create a workflow that makes complex changes to other OpenStack 
>> projects, but it doesn't have a general purpose policy language that 
>> describes which states are permitted.  Congress and Mistral are 
>> complementary, and each can stand on its own.
> 
> And why should not these two things be in a single project?
> 
> 
> 
>> 
>> Tim
>> 
>> 
>> On Mon, Nov 9, 2015 at 6:46 AM Adam Young  wrote:
>> On 11/06/2015 06:28 PM, Tim Hinrichs wrote:
>>> Congress allows users to write a policy that executes an action under 
>>> certain conditions.
>>> 
>>> The conditions can be based on any data Congress has access to, which 
>>> includes nova servers, neutron networks, cinder storage, keystone users, 
>>> etc.  We also have some Ceilometer statistics; I'm not sure about whether 
>>> it's easy to get the Keystone notifications that you're talking about 
>>> today, but notifications are on our roadmap.  If the user's login is 
>>> reflected in the Keystone API, we may already be getting that event.
>>> 
>>> The action could in theory be a mistral/heat API or an arbitrary script.  
>>> Right now we're set up to invoke any method on any of the python-clients 
>>> we've integrated with.  We've got an integration with heat but not mistral. 
>>>  New integrations are typically easy.
>> 
>> Sounds like Mistral and Congress are competing here, then.  Maybe we should 
>> merge those efforts.
>> 
>> 
>>> 
>>> Happy to talk more.
>>> 
>>> Tim
>>> 
>>> 
>>> 
>>> On Fri, Nov 6, 2015 at 9:17 AM Doug Hellmann  wrote:
>>> Excerpts from Dolph Mathews's message of 2015-11-05 16:31:28 -0600:
>>> > On Thu, Nov 5, 2015 at 3:43 PM, Doug Hellmann  
>>> > wrote:
>>> >
>>> > > Excerpts from Clint Byrum's message of 2015-11-05 10:09:49 -0800:
>>> > > > Excerpts from Doug Hellmann's message of 2015-11-05 09:51:41 -0800:
>>> > > > > Excerpts from Adam Young's message of 2015-11-05 12:34:12 -0500:
>>> > > > > > Can people help me work through the right set of tools for this 
>>> > > > > > use
>>> > > case
>>> > > > > > (has come up from several Operators) and map out a plan to 
>>> > > > > > implement
>>> > > it:
>>> > > > > >
>>> > > > > > Large cloud with many users coming from multiple Federation 
>>> > > > > > sources
>>> > > has
>>> > > > > > a policy of providing a minimal setup for each user upon first 
>>> > > > > > visit
>>> > > to
>>> > > > > > the cloud:  Create a project for the user with a minimal quota, 
>>> > > > > > and
>>> > > > > > provide them a role assignment.
>>> > > > > >
>>> > > > > > Here are the gaps, as I see it:
>>> > > > > >
>>> > > > > > 1.  Keystone provides a notification that a user has logged in, 
>>> > > > > > but
>>> > > > > > there is nothing capable of executing on this notification at the
>>> > > > > > moment.  Only Ceilometer listens to Keystone notifications.
>>> > > > > >
>>> > > > > > 2.  Keystone does not have a workflow engine, and should not be
>>> > > > > > auto-creating projects.  This is something that should be 
>>> > > > > > performed
>>> > > via
>>> > > > > > a Heat template, and Keystone does not know about Heat, nor should
>>> > > it.
>>> > > > > >
>>> > > > > > 3.  The Mapping code is pretty static; it assumes a user entry or 
>>> > > > > > a
>>> > > > > > group entry in identity when creating a role assignment, and 
>>> > > > > > neither
>>> > > > > > 

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

[Richard Raseley]

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) upstream puppet-ceph by Enovance [4].
> Today, the version by Enovance is no longer officially maintained
> since Red Hat has adopted the new release.
>
> Being an Openstack project under Stackforge or Openstack brings a lot
> of benefits but it's not black and white, there are cons too.
>
> It provides us with the tools, the processes and the frameworks to
> review and test each contribution to ensure we ship a module that is
> stable and is held to the highest standards.
> But it also means that:
> - We forego some level of ownership back to the Openstack foundation,
> it's technical committee and the Puppet Openstack PTL.
> - puppet-ceph contributors will also be required to sign the
> Contributors License Agreement and jump through the Gerrit hoops [5]
> which can make contributing to the project harder.
>
> We have put tremendous efforts into creating a quality module and as
> such it was the first puppet module in the stackforge organization to
> implement not only unit tests but also integration tests with third
> party CI.
> Integration testing for other puppet modules are just now starting to
> take shape by using the Openstack CI inrastructure.
>
> In the context of Openstack, RDO already ships with a mean to install
> Ceph with this very module and Fuel will be adopting it soon as well.
> This means the module will benefit from real world experience and
> improvements by the Openstack community and packagers.
> This will help further reinforce that not only Ceph is the best
> unified storage solution for Openstack but that we have means to
> deploy it in the real world easily.
>
> We all know that Ceph is also deployed outside of this context and
> this is why the core reviewers make sure that contributions remain
> generic and usable outside of this use case.
>
> Today, the core members of the project discussed whether or not we
> should move puppet-ceph to the Openstack big tent and we had a
> consensus approving the move.
> We would also like to hear the thoughts of the community on this topic.
>
> Please let us know what you think.
There was some discussion a while back around whether or not to bring
those modules into the project which provide support for
OpenStack-related tools which were not part of OpenStack themselves. The
specific example at that time was the puppet-midonet module.

Unfortunately the consensus was to not allow these modules in. I think
now, as I did then, that there is a lot of value in bringing some of
these things into the project, as so many of our implementations depend
on them. I also understand the other perspective, but think any concerns
could be addressed by building some formal criteria about what third
party tools are 'blessed'.

I look forward to seeing feedback from the rest of the community on this.

Regards,

Richard



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 domains, and not changing
 the default domain, you would have to ensure something::Default
 _everywhere_ - and I do mean everywhere - every user and tenant name
 use, including in keystone_user_role, and in other, higher level
 classes/defines that refer to keystone users and tenants.

 Anyone?

 I also wonder how the Ansible folks are handling this, as they move to
 support domains and other Keystone v3 features in openstack-ansible code? 
As an operator, I like the ::$domain notation. I think the benefits it
brings in terms of clarity outweigh any downsides.



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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, as I know ahead of time where all the relevant
bits live, it just means I have to find all the instances of resources
which require the new notation, parse them and make the changes, and
then do some manual review. Save for the review, it could be easily
scripted.



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 imagine there is one), we should follow 
that model and conform to the expected behavior.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 working on Puppet OpenStack modules and it made
sense to have this repository on Stackforge to benefit of OpenStack
integration.
Until recently, puppet-vswitch was a dependency to run puppet-neutron.
See [2].

[1]https://github.com/openstack/puppet-vswitch/graphs/contributors
[2]
https://github.com/openstack/puppet-neutron/tree/stable/juno/manifests/plugins/ovs


To be less specific, Puppet modules that reside in OpenStack namespace
aretoday:
* deploying an OpenStack project (neutron, horizon, etc)
* a dependency to deploy modules (openstacklib, vswitch)
* contain some code used by our community to help with CI,
documentation, consistency, etc (modulesync, cookiebutter, integration,
blueprints).


Emilien,

Thank you for the input on this. The criteria you listed above seem 
totally reasonable, and based upon them, I can understand the reason for 
not bringing this module into the OpenStack namespace. Just to re-state 
the criteria to ensure my own understanding:


---

OpenStack Puppet Modules:

For a module to become part of the OpenStack Puppet Modules project it 
should meet one of the following requirements:


1) Provides configuration management capability for an OpenStack project.
2) Satisfies a dependency for deploying module(s) which conform to #1 above.
3) Assists in the creation, documentation, lifecycle-management, and 
testing for modules which conform to #1 above.


StackForge Modules:

For a module to become part of the StackForge project it should meet one 
of the following requirements:


1) Provides configuration management capability for one or more 
OpenStack-related project.
2) Provides configuration management capability for a project which is 
intending to become part of OpenStack.


Proprietary Modules:

For modules not meeting any of the above-outlined requirements, we 
suggest that it live in its own vendor-provided project or repository, 
and not utilize the OpenStack-infra provided CI and tooling.


---

Does this seem to capture all the relevant pieces to you?

Regards,

Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 this is an excellent idea. +1

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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) Also include those modules which provide 'supporting' infrastructure 
to OpenStack components.


To be totally transparent, this came to mind for me because I am 
currently working with the folks at Midokura to publish a module which 
can be used to configure their open source Midonet SDN for Neutron and I 
was contemplating whether or not it would be reasonable to be part of 
the project.


FWIW, we have carried over the 'puppet-vswitch' repository over with us 
as part of the move (which would align with option B), but I didn't want 
to assume that was intended to be precedent setting.


Regards,

Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 modules have stable/grizzly and stable/havana branches. Some
of them have the CI broken due to rspec issues that would require some
investigation and time if we wanted to fix it.

We would like to know who plan to backport some patches in these
branches?

If nobody plans to do that, we will let the branches as they are now but
won't officially support them.

By support I mean maintaining the CI jobs green (rspec, syntax, etc),
fixing bugs and adding new features.

Any feedback is welcome!

Regards,
--
Emilien Macchi



I echo your +1.

Perhaps most current stable supported, -1 stable version?

In that example, once the Liberty release of modules (or a particular 
module) is cut we would support Liberty and Kilo. When the same happens 
for M, we would deprecate Kilo and support M and Liberty.


Stable -2 also seems sane - I don't have a good sense of how far people 
are generally behind.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 and their supporting 
components, not consuming a pre-canned composition layer like 
'puppetlabs-openstack', which has value - but primarily as a 
demonstration and testing tool.


In this model, each of the classes contained puppet-* module (e.g. 
puppet-nova, puppet-keystone, et. al.) will be wrapped with your own 
custom classes (likely in a role and profile pattern) in order to define 
those relationships.


Regards,

Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 appreciated.

Regards,

Richard

[0] - http://docs.openstack.org/infra/manual/creators.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 https://launchpad.net/puppet-openstack and
https://github.com/openstack?utf8=%E2%9C%93query=puppet
https://github.com/openstack?utf8=%E2%9C%93query=puppet - Are those
the right places?


Yes, those are the appropriate modules.

It can appear a bit daunting at first, but if you pick off small bites 
and work in an iterative fashion, I have no doubts you'll be well on 
your way in no time.


The first steps are, as they are with OpenStack in general, in building 
out the supporting components (e.g. database and message broker), so I 
would start by taking a look at the (excellent) MySQL[0] and RabbitMQ[1] 
modules from the Puppet Forge. Take your time and build out the roles 
and profiles[2] that control these components, make sure you're happy 
with the results and then gradually expand.


[0] - https://forge.puppetlabs.com/puppetlabs/mysql

[1] - https://forge.puppetlabs.com/puppetlabs/rabbitmq

[2] - 
https://docs.puppetlabs.com/pe/latest/puppet_assign_configurations.html#assigning-configuration-data-with-role-and-profile-modules


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 tried to work on this myself and then Jay Clark helped out a bit.
Here's the code[0], which is unfortunately not complete.

This said, I realize packaging is important and I'm happy to say that
there's a package for fedora/centos and Zigo is working on debian's
(Zigo, I know you're blocked by something I need to do, it's coming
;).

So, can we get some help from the puppet team during Liberty to create
these manifests?

It goes without saying that we're more than happy to help if needed.

[0] https://github.com/jasontclark/puppet-zaqar

Cheers,
Flavio

P.S: Puppet is just a start, in the future it'd be awesome to have
support for other deployment tools.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Flavio,

Apologies for not yet replying to your email dated June 4th.

I have time set aside tomorrow (Friday from 1PM - 4PM) to begin review 
of the work that's already done and start enumerating what the next 
steps are. Look for some updated information from me either tomorrow 
afternoon or over the weekend (which I'll share here for visibility).


What TZ are you in (in case I need to poke you with some questions)?

Regards,

Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 repository
additions to existing projects).


Jim,

Thanks so much for this information. I spoke to Emilien and will be 
building out the 'cookie cutter' module tomorrow, and hope to push to 
the new repository.


If I have questions at that time, may I reach out to you on IRC?

Regards,

Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 migrations will often cause performance 
degradation from a users perspective.


Having this information easily available might reduce the mean time to 
diagnose a performance issue caused by such a migration.


Regards,

Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

Jay Pipes wrote:


In short, I would love it if the Ops Tags team would stick with binary
tag definitions -- a tag should mean one thing and one thing only.


I absolutely agree Jay. I think the path that is currently being pursued 
adds a lot of challenges without appropriate offsetting benefits.



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 Engineer @ Puppet Labs

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 contact the original author via IRC
or email. If the change is easy to fix, anyone should feel welcome to
check out the change and resubmit it using the same change ID to
preserve original authorship. If the author is unresponsive for at least
3 months and no one else takes over the patch, core reviewers can
abandon the patch, leaving a detailed note about how the change can be
restored.

If a change is submitted and given a -2, or it otherwise becomes clear
that the change can not make it in (for example, if an alternate change
was chosen to solve the problem), and the author has been unresponsive
for at least 3 months, a core reviewer should abandon the change.
```


+1 for #3

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

I am happy to share that the Keystone module[0] has now been designated 
as a 'Puppet Approved Module'[1]. At a high level, this designation 
means that the module meets Puppet Labs' expectations for quality and 
usability.


Thank you to Hunter (and modules team) for helping guide the process 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://forge.puppetlabs.com/approved

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 report) 
where service state was managed by an external cluster/resource manager.


I think it reasonable that people would manage the state of their nodes 
via the composition layer, but it is also reasonable that we might want 
to put an additional option in place.


I'd love to hear more input on that.


As for the patch itself, we need to change it for all the other services
in nova too, not just API.


Agreed. I will see if Matt wants to do that work and if not will be 
happy to do so over the weekend.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

We are currently reviewing a patch[0] which will result in a change to 
the way Nova services are managed by default. Previously services were 
set to 'Disabled' by default, and had to be manually enabled in the 
manifests, this change will make the default value 'Enabled'.


The consensus is that this will bring the Nova module more in-line with 
the other modules, but we understand this could result in some 
undesirable behavior for some implementations.


If you have a strong opinion on the matter, or want to make sure your 
use-case is considered, please comment on the aforementioned 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...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 at the summit that this approach fails to take into
account the complex ballet of service restarts required to update
OpenStack services. (/me shakes fist at OpenStack services.) And
furthermore, that the Puppet manifests already encode the necessary
relationships to do this properly. (Thanks Puppeteers!) Indeed we'd be
doing the Wrong Thing by Puppet if we changed this stuff from under it.

The problem of course is that neither Puppet nor yum/apt has a view of
the entire system. Yum doesn't know about the relationships between
services and Puppet doesn't know about all of the _other_ packages that
they depend on.

One solution proposed was to do a yum update first but specifically
exclude any packages that Puppet knows about (the --excludes flag
appears sufficient for this); then follow that up with another Puppet
run using ensure - latest.

A problem with that approach is that it still fails to restart services
which have had libraries updated but have not themselves been updated.
That's no worse than the pure yum approach though. We might need an
additional way to just manually trigger a restart of services.

What do folks think of this plan? Anybody got better ideas?

thanks,
Zane.

[1] https://review.openstack.org/#/c/179974

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Adding the [Puppet] tag to raise visibility.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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]
http://specs.openstack.org/openstack/glance-specs/specs/kilo/artifact-repository.html



Thank you for bringing that to my attention, this looks like it solves 
the issue we outlined - very exciting. =]


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

 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 am now working on making these scripts with puppet, it would make sense to 
 propose two federation modules (IdP and SP) or just one in puppet-keystone 
 repo?
 
 Thanks 
 
 -- 
 ~
 Att[]'s
 Iury Gregory Melo Ferreira 
 Master student in Computer Science at UFCG
 E-mail:  iurygreg...@gmail.com
 ~
 -- 
 
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to puppet-openstack+unsubscr...@puppetlabs.com.

The functionality should be integrated into the existing puppet-keystone 
module, if I am understanding your question.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

Ah, since they are closely related, it seems plausible that a single blueprint 
would be sufficient.

Regards,

Richard 

 On May 25, 2015, at 12:44 PM, Iury Gregory iurygreg...@gmail.com wrote:
 
 Yes Richard, sorry for the misunderstanding.
 Since the configurations for SP and IdP are a little 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 created scripts in python to easily configure SP (Service Provider) 
 and IdP (Identity Provider) in a K2K environment.
 I am now working on making these scripts with puppet, it would make sense 
 to propose two federation modules (IdP and SP) or just one in 
 puppet-keystone repo?
 
 Thanks 
 
 -- 
 ~
 Att[]'s
 Iury Gregory Melo Ferreira 
 Master student in Computer Science at UFCG
 E-mail:  iurygreg...@gmail.com
 ~
 -- 
 
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to puppet-openstack+unsubscr...@puppetlabs.com.
 
 The functionality should be integrated into the existing puppet-keystone 
 module, if I am understanding your question.
 -- 
 
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to puppet-openstack+unsubscr...@puppetlabs.com.
 
 
 
 -- 
 ~
 Att[]'s
 Iury Gregory Melo Ferreira 
 Mestrando em Ciência da Computação - UFCG
 E-mail:  iurygreg...@gmail.com
   iury.ferre...@ccc.ufcg.edu.br  
 ~
 -- 
 
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to puppet-openstack+unsubscr...@puppetlabs.com.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 perspective, a couple of the key bits which came out of the 
discussion were:


* There needs to be a lot of consideration given to the use-case of 
containers as pets, not just as cattle. This is especially important 
from a service provider point of view. People want things like 
live-migration, non-ephemeral storage, etc.


* There is some confusion around what networking models play in what 
ways (e.g. Neutron integration).


* Interest in how Glance is going to solve the issue of 'hierarchical 
images' (for lack of a better term), which is important to some 
container models. This was as coupled with interest in making Glance a 
more generic artifact storage service.


Again, as I understand it these are already known quantities. If anyone 
feels I've misrepresented parts of our discussion here, please let me know.


Regards,

Richard


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

I apologize if this message is inappropriately broad, but I wanted to 
share the results of the Vancouver Summit operations containers 
session[0] we held yesterday with all of the projects which were mentioned.


This was a great discussion with approximately two-dozen individuals in 
attendance. 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://sched.co/3B45

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 - https://github.com/jiocloud/puppet-openstack_zeromq

Thanks,
Harish

--

To unsubscribe from this group and stop receiving emails from it, send
an email to puppet-openstack+unsubscr...@puppetlabs.com
mailto:puppet-openstack+unsubscr...@puppetlabs.com.


Harish,

Quick note that we've moved Puppet-OpenStack related conversation to the 
OpenStack development mailing list


Thank you so much for this contribution - it is certainly much 
appreciated. At this time, as I understand it, we are only hosting the 
OpenStack-specific modules (e.g. Nova, Neutron, etc.).


While someone very well might want to use your module for deploying 
OpenStack, I think it would be treated in the same way as our other 
supporting modules (e.g. MySQL, RabbitMQ, etc.) - which is that they 
would live under your (or your company's namespace).


Do you feel comfortable publishing this module on the Puppet Forge? I 
would be more than happy to help with that process if necessary.


Regards,

Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 based upon an empty cookiecutter[1]
repo.  The repos to work in are: Server:
https://github.com/stackforge/cloudpulse Client:
https://github.com/stackforge/python-cloudpulseclient

Please join us via iRC on #openstack-cloudpulse on freenode.

I am holding a doodle poll to select times for our first meeting
the week after summit.  This doodle poll will close May 24th and
meeting times will be announced on the mailing list at that time.
At our first IRC meeting, we will draft additional core team
members, so if your interested in joining a fresh new development
effort, please attend our first meeting. Please take a moment if
your interested in CloudPulse to fill out the doodle poll here:

https://doodle.com/kcpvzy8kfrxe6rvb

The initial core team is composed of Ajay Kalambur, Behzad Dastur,
Ian Wells, Pradeep chandrasekhar, Steven DakeandVinod
Pandarinathan. I expect more members to join during our initial
meeting.

A little bit about CloudPulse: Cloud operators need notification of
OpenStack failures before a customer reports the failure. Cloud
operators can then take timely corrective actions with minimal
disruption to applications.  Many cloud applications, including
those I am interested in (NFV) have very stringent service level
agreements.  Loss of service can trigger contractual costs
associated with the service.  Application high availability
requires an operational OpenStack Cloud, and the reality is that
occascionally OpenStack clouds fail in some mysterious ways. This
project intends to identify when those failures occur so corrective
actions may be taken by operators, tenants, and the applications
themselves.

OpenStack is considered healthy when OpenStack API services
respond appropriately.  Further OpenStack is healthy when network
traffic can be sent between the tenant networks and can access the
Internet.  Finally OpenStack is healthy when all infrastructure
cluster elements are in an operational state.

For information about blueprints check out:
https://blueprints.launchpad.net/cloudpulse
https://blueprints.launchpad.net/python-cloudpulseclient

For more details, check out our Wiki:
https://wiki.openstack.org/wiki/Cloudpulse

Plase join the CloudPulse team in designing and implementing a
world-class Carrier Grade system for checking the health of
OpenStack clouds.  We look forward to seeing you on IRC on
#openstack-cloudpulse.

Regards, Vinod Pandarinathan [1]
https://github.com/openstack-dev/cookiecutter


As others have expressed - I am a little skeptical about the need to 
'reinvent the wheel' with regards to monitoring.


Are there a well-defined set of business or user requirements which 
would be enabled by CloudPulse which are not enabled by existing 
solutions? I am just trying to better wrap my need around the problem...


Regards,

Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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:


* https://wiki.openstack.org/wiki/Operations/Monitoring

* https://github.com/osops/tools-monitoring

Regards,

Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 message to the list with the link to the post (or some 
semi-regular digest) would bridge the gap?


Regards,

Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

Flavio Percoco wrote:

I think getting operators to adopt it is key to getting other openstack
projects to also adopt it. There is something of a chicken and the egg
problem
with the integration. Some of the projects you will want to integrate
the most
with are already considered pretty stable and may not want to rewrite
working
bits to target a service thats hard for ops to deploy. It makes their
service
hard to deploy too.

Getting into RDO and Ubuntu will go a long way there. Getting into
Packstack
and other deployment tools even further.


I don't fully agree with the above. The problem on waiting for
operators to adopt it is that they might actually not have a reason to
do it, which doesn't mean the project is useless. Each operator will
decide what services they want to provide.


The needs of operators are a reflection of the needs of their users.

I don't want to use the word 'useless', because it has a clear negative 
connotation - and I don't think Zaqar is 'useless'. Let's instead 
discuss 'utility'.


The utility of any solution or product is completely subjective, and 
solely based upon the underlying requirements. If real operators with 
real requirements do not view a particular solution as having utility 
for them - then it doesn't.


You are correct in that there is a bit of a bootstrapping problem, but I 
strongly feel like the answer to that is continuing to listen to, and 
test against, the market (the architects and operators).


Build a minimally viable product that (a) has clear messaging and use 
cases (b) is easy to deploy and configure and (c) doesn't demand deep 
integration into an existing cloud and operators will start deploying, 
testing, and providing feedback. This will create the right feedback 
cycle and help in validating (or completely demolishing) assumptions on 
what users actually need.


With regard to '(b)' above, it doesn't appear that there any any Puppet 
modules to assist with the installation and configuration of Zaqar. If 
you're interested, let's chat in Vancouver to see if I can help in get a 
basic set out 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/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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, once we have Puppet4.0  jobs green everywhere, it makes sense they
will also vote.

Please raise your hand if you're against this idea, otherwise I'll
submit the patch in project-config.


Emilien,

+1 on both points, thank you.

Regards,

Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

Matt Fischer wrote:

Recently a mass of changes was proposed and some merged to move the
rabbit/kombu settings to avoid a Kilo deprecation. As far as I can tell
this will break rabbit connectivity for all modules still using Juno. I
did an experiment with Heat and it certainly can't talk to rabbit
anymore. (Hopefully you guys can just tell me I'm wrong here and
everything will still work)

So why did we do this? We seem to have traded a slightly annoying
deprecation warning for breaking every single module. It does not seem
like a good trade-off to me. At a minimum, I would have liked to wait
until we had forked Kilo off and we're working towards Liberty. Why?
Because there was simply no pressing reason to do this right now when
most everyone is still using Juno.

Since we as a community are pretty terrible at backports, this means
that I now need to switch to stable and sit on old and non-updated code
until I can upgrade to Kilo, which is likely a minimum of 45 days away
for many components for us.

This has implications for my team beyond breaking everything:

* It means that we need to stop importing puppet code changes with our
git-upstream jobs. This makes the process of moving back to master when
we finally can quite painful. I had to do it for Icehouse and I don't
relish doing it again.

* It means that any fixes we want will require a two step process to get
into backports. This delays things obviously.

* It means that the number of contributions you will get from us will
probably fall, not being on master makes it way more likely for us just
to hold patches.

* It means that we will have to write a shim layer in our module to deal
with these settings and whatever else gets broken like this.

So I'd like to discuss the philosophy of why this was done. I'd also
again like to put in my vote for master supporting current-1 for at
least some period of time. There's a reason that the upstream code that
we configure just did this with a deprecation rather than a if you set
it like this you are broken. We should do the same.

For now I've -1'd all the outstanding reviews until we can have a
discussion about it. I know one was merged despite my -1, but I didn't
think a -2 was warranted.


Matt,

I am certainly sympathetic to your situation - having the world change 
beneath your feet is never a good place to be. =]


It does seem, however, that there is a disconnect between your 
expectations (as I understand them) of what the 'master' branch 
represents, and what it has traditionally represented - the 'bleeding edge'


Master is volatile - it is expected to be volatile. As the code 
progresses between releases it is expected that things can (and will) break.


The solution, in my mind, is not to redefine what it means to be master, 
but rather to be more aggressive about back-porting changes to stable 
branches.


I am very much in favor of discussions that include your proposed 
solution above (i.e. 'current-1' support), as long 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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

Emilien Macchi wrote:

Hi all,

I sent a patch to openstack/governance to move our project under the big
tent, and it came up [1] that we should decide of a project name and be
careful about trademarks issues with Puppet name.

I would like to hear from Puppetlabs if there is any issue to use Puppet
in the project title; also, I open a new etherpad so people can suggest
some names: https://etherpad.openstack.org/p/puppet-openstack-naming

Thanks,

[1] https://review.openstack.org/#/c/172112/1/reference/projects.yaml,cm


Emilien,

I went ahead and had a discussion with Puppet's legal team on this 
issue. Unfortunately at this time we are unable to sanction the use of 
Puppet's name or registered trademarks as part of the project's name.


To be clear, this decision is in no way indicative of Puppet not feeling 
the project is 'worthy' or 'high quality' (in fact the opposite is 
true), 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

Emilien Macchi wrote:

Hi all,

I sent a patch to openstack/governance to move our project under the big
tent, and it came up [1] that we should decide of a project name and be
careful about trademarks issues with Puppet name.

I would like to hear from Puppetlabs if there is any issue to use Puppet
in the project title; also, I open a new etherpad so people can suggest
some names: https://etherpad.openstack.org/p/puppet-openstack-naming

Thanks,

[1] https://review.openstack.org/#/c/172112/1/reference/projects.yaml,cm


Emilien,

Thank you for driving this conversation. I can forward 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Richard Raseley]

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 extremely qualified PTL candidate. FWIW, a +1 from me.

Regards,

Richard



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev