Re: [Openstack-operators] [gnocchi][ceilometer] Taking Scientific WG Ops Meetup Feedback back to Ceilometer

[Stig Telfer]

> On 4 Mar 2016, at 15:40, gordon chung  wrote:
> 
>> One part of the documentation set that we were missing was a guide to how to 
>> migrate from ceilometer to a ceilometer/gnocchi combination (which I 
>> understand is the ultimate architecture). We would like to migrate the 
>> historical data we have stored in ceilometer.
>> 
>> The main line documentation (such as 
>> http://docs.openstack.org/liberty/config-reference/content/) does not yet 
>> contain details on the Gnocchi configuration so some people may miss this 
>> option when following the docs. The gnocchi.xyz has good content but it is 
>> not the standard configuration guides. I guess once Gnocchi is into the Big 
>> Tent then this sort of integration can occur.
>> 
>> It’s early days yet so we don’t yet have the feeling for running Gnocchi at 
>> scale.
>> 
>> Tim
> 
> hi,
> 
> there isn't an active migration path between Ceilometer's legacy 
> database to Gnocchi. it was discussed but given the limited resources we 
> have (contributors are welcomed) we just do not have the bandwidth 
> currently to build a tool to help port data over.
> 
> Gnocchi is not a 1:1 replacement of Ceilometer's old API, it does not 
> capture full-fidelity of data and requires defined archive policy rules, 
> which makes a migration tool necessary. it is mainly intended to replace 
> the 'ceilometer statistics' use case of the old API.
> 
> we were hoping to get a reference architecture this cycle but were 
> delayed due to resources being pulled to other tasks. currently, the 
> best option is to take a look at the devstack plugins for Gnocchi[1] and 
> Ceilometer[2] (requires bash knowledge) to get an idea of how they're 
> set up to work together in the gate.
> 
> as with all new things, it's recommended you test this out first, to 
> learn new API[3] and find potential bugs. you can configure the 
> Ceilometer collector to write to both existing db and Gnocchi so your 
> current usage is not interrupted.
> 
> [1] https://github.com/openstack/gnocchi/blob/master/devstack/plugin.sh
> [2] https://github.com/openstack/ceilometer/blob/master/devstack/plugin.sh
> [3] http://gnocchi.xyz/rest.html
> 
> cheers,
> -- 
> gord

We evaluated Monasca as an alternative for monitoring.  One of its appeals is 
that through its use of Kafka we get logging, events and time-series telemetry 
data streams all in one place (we send syslog through the same Kafka instance). 
 The attraction of this was that it would then be feasible to create a system 
for multi-variate alert triggering and anomaly detection, using a single API to 
access near-real-time data from arbitrary and diverse sources from across the 
data centre.

Not that that system ever got created, ahem, but through bringing the data 
sources together I think it was brought a step closer…

Gord, if Gnocchi is functionality split off from Ceilometer, would using 
Gnocchi require API changes to any client subscribing to sources of both 
monitoring and event data?

Huge thanks to you Anita for starting this discussion.

Best wishes,
Stig


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [glance] Remove `run_tests.sh` and `tools/*`

[Nikhil Komawar]

I meant exactly that if you're not using venv for glance testing and
want to use testing tools shipped that have the wrappings of run_test or
even tox then asking packagers to write new scripts for doing the same
thing seems odd.

My question still stands: who is still using run_test towards this
purpose? I am aware that some ops do prefer it.

On 3/4/16 2:20 PM, Flavio Percoco wrote:
> On 04/03/16 14:12 -0500, Nikhil Komawar wrote:
>> Surely you can directly use the standard libraries to test systemwide
>> but I am more curious to know if there are some who are still using
>> run_tests wrappings that exist for to ease the pain a bit.
>
> Oh, sorry if I came off wrong. What I meant is that if you have glance
> installed
> systemwide, you'd be better off running the command found in tox.ini
> rather than
> running `run_tests.sh`. One reason is that one point in favor to `tox`
> and even
> `run_tests.sh` itself is isolating test environments. Other than that,
> I don't
> think they provide much other benefits over just running testr
> directly (which I
> sometimes do).
>
> Hope that's clearer,
> Flavio
>
>> On 3/4/16 12:41 PM, Flavio Percoco wrote:
>>> On 04/03/16 11:59 -0500, Nikhil Komawar wrote:
 I think the hard question to me here is:

 Do people care about testing code on system installs vs. virtual env?
 run_tests does that and for some cases when you want to be extra sure
 about your CICD nodes, packaging and upgrades, the problem is solved.

 Are packagers using tox to this purpose?
>>>
>>> TBH, if you're testing things without venvs and sytemwide, I think
>>> it'd be far
>>> easier to just call nosetests/testr directly in your system than
>>> calling the
>>> run_tests script.
>>>
>>> Some packages don't even ship tests.
>>>
>>> Cheers,
>>> Flavio
>>>
 On 3/4/16 11:16 AM, Steve Martinelli wrote:
>
> The keystone team did the same during Liberty while we were moving
> towards using oslo.* projects instead of oslo-incubator [0]. We also
> noticed that they were rarely used, and we did not go through a
> deprecation process since these are developer tools. We're still
> finding a few spots in our docs that need updating, but overall it
> was
> an easy transition.
>
> [0]
> https://github.com/openstack/keystone/commit/55e9514cbd4e712e2c317335294355cf1596d870
>
>
>
> stevemar
>
> Inactive hide details for Flavio Percoco ---2016/03/04 06:51:47
> AM---Hey Folks, I'm looking at doing some cleanups in our repo Flavio
> Percoco ---2016/03/04 06:51:47 AM---Hey Folks, I'm looking at doing
> some cleanups in our repo and I would like to start by
>
> From: Flavio Percoco 
> To: openstack-...@lists.openstack.org
> Cc: openstack-operators@lists.openstack.org
> Date: 2016/03/04 06:51 AM
> Subject: [Openstack-operators] [glance] Remove `run_tests.sh` and
> `tools/*`
>
> 
>
>
>
>
>
> Hey Folks,
>
> I'm looking at doing some cleanups in our repo and I would like to
> start by
> deprecating the `run_tests` script and the contents in the `tools/`
> dir.
>
> As far as I can tell, no one is using this code - we're not even
> using
> it in the
> gate - as it was broken until recently, I believe. The recommended
> way
> to run
> tests is using `tox` and I believe having this script in the code
> base
> misleads
> new contributors and other users.
>
> So, before we do this. I wanted to get feedback from a broader
> audience and give
> a heads up to folks that might be using this code.
>
> Any objections? Something I'm missing?
>
> Flavio
>
> -- 
> @flaper87
> Flavio Percoco
> [attachment "signature.asc" deleted by Steve Martinelli/Toronto/IBM]
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
>
>
> __
>
>
> 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

 -- 

 Thanks,
 Nikhil

>>>
>>
>> -- 
>>
>> Thanks,
>> Nikhil
>>
>

-- 

Thanks,
Nikhil


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [glance] Remove `run_tests.sh` and `tools/*`

[Flavio Percoco]

On 04/03/16 14:12 -0500, Nikhil Komawar wrote:

Surely you can directly use the standard libraries to test systemwide
but I am more curious to know if there are some who are still using
run_tests wrappings that exist for to ease the pain a bit.


Oh, sorry if I came off wrong. What I meant is that if you have glance installed
systemwide, you'd be better off running the command found in tox.ini rather than
running `run_tests.sh`. One reason is that one point in favor to `tox` and even
`run_tests.sh` itself is isolating test environments. Other than that, I don't
think they provide much other benefits over just running testr directly (which I
sometimes do).

Hope that's clearer,
Flavio


On 3/4/16 12:41 PM, Flavio Percoco wrote:

On 04/03/16 11:59 -0500, Nikhil Komawar wrote:

I think the hard question to me here is:

Do people care about testing code on system installs vs. virtual env?
run_tests does that and for some cases when you want to be extra sure
about your CICD nodes, packaging and upgrades, the problem is solved.

Are packagers using tox to this purpose?


TBH, if you're testing things without venvs and sytemwide, I think
it'd be far
easier to just call nosetests/testr directly in your system than
calling the
run_tests script.

Some packages don't even ship tests.

Cheers,
Flavio


On 3/4/16 11:16 AM, Steve Martinelli wrote:


The keystone team did the same during Liberty while we were moving
towards using oslo.* projects instead of oslo-incubator [0]. We also
noticed that they were rarely used, and we did not go through a
deprecation process since these are developer tools. We're still
finding a few spots in our docs that need updating, but overall it was
an easy transition.

[0]
https://github.com/openstack/keystone/commit/55e9514cbd4e712e2c317335294355cf1596d870


stevemar

Inactive hide details for Flavio Percoco ---2016/03/04 06:51:47
AM---Hey Folks, I'm looking at doing some cleanups in our repo Flavio
Percoco ---2016/03/04 06:51:47 AM---Hey Folks, I'm looking at doing
some cleanups in our repo and I would like to start by

From: Flavio Percoco 
To: openstack-...@lists.openstack.org
Cc: openstack-operators@lists.openstack.org
Date: 2016/03/04 06:51 AM
Subject: [Openstack-operators] [glance] Remove `run_tests.sh` and
`tools/*`






Hey Folks,

I'm looking at doing some cleanups in our repo and I would like to
start by
deprecating the `run_tests` script and the contents in the `tools/`
dir.

As far as I can tell, no one is using this code - we're not even using
it in the
gate - as it was broken until recently, I believe. The recommended way
to run
tests is using `tox` and I believe having this script in the code base
misleads
new contributors and other users.

So, before we do this. I wanted to get feedback from a broader
audience and give
a heads up to folks that might be using this code.

Any objections? Something I'm missing?

Flavio

--
@flaper87
Flavio Percoco
[attachment "signature.asc" deleted by Steve Martinelli/Toronto/IBM]
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





__

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


--

Thanks,
Nikhil





--

Thanks,
Nikhil



--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [vmware][nova] "could not find capabilities for domaintype=kvm"

[Adam Lawson]

Hey all,

We're testing OpenStack Liberty on an ESX host and it installs fine. When
attempting to create a VM, receiving an error:

*libvirtError: invalid argument : could not find capabilities for
domaintype=kvm*

VMware environment is ESX 5.5:
*Capabilities*

nestedHVSupported = true

Intel VT-X = Supported


Is there any obvious ways to solve this or clarify whether this is a
physical or ESX configuration issue?

//adam

*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [glance] Remove `run_tests.sh` and `tools/*`

[Nikhil Komawar]

Surely you can directly use the standard libraries to test systemwide
but I am more curious to know if there are some who are still using
run_tests wrappings that exist for to ease the pain a bit.

On 3/4/16 12:41 PM, Flavio Percoco wrote:
> On 04/03/16 11:59 -0500, Nikhil Komawar wrote:
>> I think the hard question to me here is:
>>
>> Do people care about testing code on system installs vs. virtual env?
>> run_tests does that and for some cases when you want to be extra sure
>> about your CICD nodes, packaging and upgrades, the problem is solved.
>>
>> Are packagers using tox to this purpose?
>
> TBH, if you're testing things without venvs and sytemwide, I think
> it'd be far
> easier to just call nosetests/testr directly in your system than
> calling the
> run_tests script.
>
> Some packages don't even ship tests.
>
> Cheers,
> Flavio
>
>> On 3/4/16 11:16 AM, Steve Martinelli wrote:
>>>
>>> The keystone team did the same during Liberty while we were moving
>>> towards using oslo.* projects instead of oslo-incubator [0]. We also
>>> noticed that they were rarely used, and we did not go through a
>>> deprecation process since these are developer tools. We're still
>>> finding a few spots in our docs that need updating, but overall it was
>>> an easy transition.
>>>
>>> [0]
>>> https://github.com/openstack/keystone/commit/55e9514cbd4e712e2c317335294355cf1596d870
>>>
>>>
>>> stevemar
>>>
>>> Inactive hide details for Flavio Percoco ---2016/03/04 06:51:47
>>> AM---Hey Folks, I'm looking at doing some cleanups in our repo Flavio
>>> Percoco ---2016/03/04 06:51:47 AM---Hey Folks, I'm looking at doing
>>> some cleanups in our repo and I would like to start by
>>>
>>> From: Flavio Percoco 
>>> To: openstack-...@lists.openstack.org
>>> Cc: openstack-operators@lists.openstack.org
>>> Date: 2016/03/04 06:51 AM
>>> Subject: [Openstack-operators] [glance] Remove `run_tests.sh` and
>>> `tools/*`
>>>
>>> 
>>>
>>>
>>>
>>>
>>> Hey Folks,
>>>
>>> I'm looking at doing some cleanups in our repo and I would like to
>>> start by
>>> deprecating the `run_tests` script and the contents in the `tools/`
>>> dir.
>>>
>>> As far as I can tell, no one is using this code - we're not even using
>>> it in the
>>> gate - as it was broken until recently, I believe. The recommended way
>>> to run
>>> tests is using `tox` and I believe having this script in the code base
>>> misleads
>>> new contributors and other users.
>>>
>>> So, before we do this. I wanted to get feedback from a broader
>>> audience and give
>>> a heads up to folks that might be using this code.
>>>
>>> Any objections? Something I'm missing?
>>>
>>> Flavio
>>>
>>> -- 
>>> @flaper87
>>> Flavio Percoco
>>> [attachment "signature.asc" deleted by Steve Martinelli/Toronto/IBM]
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>>
>>>
>>>
>>> __
>>>
>>> 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
>>
>> -- 
>>
>> Thanks,
>> Nikhil
>>
>

-- 

Thanks,
Nikhil


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [gnocchi][ceilometer] Taking Scientific WG Ops Meetup Feedback back to Ceilometer

[Tim Bell]

On 04/03/16 16:40, "gordon chung"  wrote:

>> One part of the documentation set that we were missing was a guide to how to 
>> migrate from ceilometer to a ceilometer/gnocchi combination (which I 
>> understand is the ultimate architecture). We would like to migrate the 
>> historical data we have stored in ceilometer.
>>
>> The main line documentation (such as 
>> http://docs.openstack.org/liberty/config-reference/content/) does not yet 
>> contain details on the Gnocchi configuration so some people may miss this 
>> option when following the docs. The gnocchi.xyz has good content but it is 
>> not the standard configuration guides. I guess once Gnocchi is into the Big 
>> Tent then this sort of integration can occur.
>>
>> It’s early days yet so we don’t yet have the feeling for running Gnocchi at 
>> scale.
>>
>> Tim
>
>hi,
>
>there isn't an active migration path between Ceilometer's legacy 
>database to Gnocchi. it was discussed but given the limited resources we 
>have (contributors are welcomed) we just do not have the bandwidth 
>currently to build a tool to help port data over.
>
>Gnocchi is not a 1:1 replacement of Ceilometer's old API, it does not 
>capture full-fidelity of data and requires defined archive policy rules, 
>which makes a migration tool necessary. it is mainly intended to replace 
>the 'ceilometer statistics' use case of the old API.

Some aggregation for us is fine (e.g. After a week to group the data hourly, 
after a month, to group the data daily)

>
>we were hoping to get a reference architecture this cycle but were 
>delayed due to resources being pulled to other tasks. currently, the 
>best option is to take a look at the devstack plugins for Gnocchi[1] and 
>Ceilometer[2] (requires bash knowledge) to get an idea of how they're 
>set up to work together in the gate.
>
>as with all new things, it's recommended you test this out first, to 
>learn new API[3] and find potential bugs. you can configure the 
>Ceilometer collector to write to both existing db and Gnocchi so your 
>current usage is not interrupted.

OK, we’ll do that. We’re also working around the RDO RPMs and Puppet 
configuration to get that robust.

Thanks
Tim

>
>[1] https://github.com/openstack/gnocchi/blob/master/devstack/plugin.sh
>[2] https://github.com/openstack/ceilometer/blob/master/devstack/plugin.sh
>[3] http://gnocchi.xyz/rest.html
>
>cheers,
>-- 
>gord
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-community] Recognising Ops contributions

[Silence Dogood]

+1

On Fri, Mar 4, 2016 at 12:30 PM, Matt Jarvis 
wrote:

> +1
>
> On 4 March 2016 at 17:21, Robert Starmer  wrote:
>
>> If fixing a typo in a document is considered a technical contribution,
>> then I think we've already cast the net far and wide. ATC as used has
>> become a name implying you're trying to make OpenStack better, more
>> useable, and more functional for those who would use/deploy (and fix,
>> update, enhance) it.  And somehow that's been connected to touching the
>> codebase directly.  This implies that an architectural discussion that
>> changes OpenStack, but doesn't initiate a code change is not an ATC worthy
>> event.
>>
>> So let's fix this, and if a proposal is needed how about:
>>
>> Active Technical Contributions are those that improve OpenStack either
>> directly by impacting the code base, or indirectly by making OpenStack
>> useable.
>>
>> Robert
>>
>> On Fri, Mar 4, 2016 at 10:07 AM, Jonathan Proulx 
>> wrote:
>>
>>> On Fri, Mar 04, 2016 at 12:20:44PM +, Jeremy Stanley wrote:
>>> :On 2016-03-04 10:02:36 +0100 (+0100), Thierry Carrez wrote:
>>> :[...]
>>> :> Upstream contributors are represented by the Technical Committee
>>> :> and vote for it. Downstream contributors are represented by the
>>> :> User Committee and (imho) should vote for it.
>>> :[...]
>>> :
>>> :Right, this brings up the other important point I meant to make. The
>>> :purpose of the "ATC" designation is to figure out who gets to vote
>>> :for the Technical Committee, as a form of self-governance. That's
>>> :all, but it's very important (in my opinion, far, far, far more
>>> :important than some look-at-me status on a conference badge or a
>>> :hand-out on free admission to an event). Granting votes for the
>>> :upstream technical governing body to people who aren't involved
>>> :directly in upstream technology decisions makes little sense, or at
>>> :least causes it to cease being self-governance (as much as letting
>>> :all of OpenStack's software developers decide who should run the
>>> :User Committee would make it no longer well represent downstream
>>> :users).
>>>
>>> At the risk of drifting off topic that concern "letting all of
>>> OpenStack's software developers decide who should run the User
>>> Committee (UC)" is largely why the UC hasn't expanded to include
>>> elected positions.
>>>
>>> As currently written bylaws define the UC as 3 appointed positions. !
>>> appointed by TC one by the board and the third by thte other two (FYI
>>> I'm currently sitting in the TC apointed seat).  The by laws further
>>> allow the UC to add seats elected by all foundation members.  In
>>> Tokyo summit sessions where expantion was discussed the consensus was
>>> to encourage more volunteer participation but not to add more formal
>>> seats because there was no way to properly define the voting
>>> constituency. Personally I can see both sides of that argument, but
>>> the sense of the room was not to add elected positions untill we can
>>> better deifne the constituency (that discussion could be reopened but
>>> if you'd like to do so please start a new thread)
>>>
>>> Perhaps nailing down this definition for recognition can actually have
>>> broader implications and help to define who elects the UC.  It would
>>> take a by-law change of course, but atleast we'd actually have a good
>>> proposal (which we currently don't).
>>>
>>> -Jon
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
> DataCentred Limited registered in England and Wales no. 05611763
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] libvirt cpu type per instance

[Tim Bell]

There is a better explanation in the OpenStack docs :-) with an example how to 
get 50% slower (not something my users ask for often)

cpu_quota & cpu_period seems to give it according to 
http://docs.openstack.org/admin-guide-cloud/compute-flavors.html

Tim




On 04/03/16 15:59, "Jonathan Proulx"  wrote:

>On Fri, Mar 04, 2016 at 11:52:33AM +0800, gustavo panizzo (gfa) wrote:
>:On Thu, Mar 03, 2016 at 03:52:49PM -0500, Jonathan Proulx wrote:
>:> 
>:> I have a user who wants to specify their libvirt CPU type to restrict
>:> performance because they're modeling embeded systems.
>:> 
>:> I seem to vaguely recall there is/was a way to specify this either in
>:> the instance type or maybe even in the image metadata, but I can't
>:> seem to find it.
>:> 
>:> Am I delusional or blind?
>
>
>As previous posters pointed out I was a bit delusional obviously cpu
>type only limits instruction set & is useful for bianry compatibility
>but mothing to do with speed limiting or equalization. 
>
>:you can use
>:https://wiki.openstack.org/wiki/InstanceResourceQuota
>
>Thanks I think that has the bits I'm looking for.  Had been reading on
>a different document about cpu_shares (which are relative and thus not
>what I want), but some how missed "cpu_quota" which may be the right
>thing for me
>
>so I was also a bit blind :)
>
>Thanks,
>-Jon
>
>
>:
>:to create "slow" flavors
>:
>:> 
>:> -Jon 
>:> 
>:> -- 
>:> 
>:> ___
>:> OpenStack-operators mailing list
>:> OpenStack-operators@lists.openstack.org
>:> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>:
>:-- 
>:1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333
>:
>:keybase: http://keybase.io/gfa
>
>-- 
>
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-community] Recognising Ops contributions

[Robert Starmer]

If fixing a typo in a document is considered a technical contribution, then
I think we've already cast the net far and wide. ATC as used has become a
name implying you're trying to make OpenStack better, more useable, and
more functional for those who would use/deploy (and fix, update, enhance)
it.  And somehow that's been connected to touching the codebase directly.
This implies that an architectural discussion that changes OpenStack, but
doesn't initiate a code change is not an ATC worthy event.

So let's fix this, and if a proposal is needed how about:

Active Technical Contributions are those that improve OpenStack either
directly by impacting the code base, or indirectly by making OpenStack
useable.

Robert

On Fri, Mar 4, 2016 at 10:07 AM, Jonathan Proulx  wrote:

> On Fri, Mar 04, 2016 at 12:20:44PM +, Jeremy Stanley wrote:
> :On 2016-03-04 10:02:36 +0100 (+0100), Thierry Carrez wrote:
> :[...]
> :> Upstream contributors are represented by the Technical Committee
> :> and vote for it. Downstream contributors are represented by the
> :> User Committee and (imho) should vote for it.
> :[...]
> :
> :Right, this brings up the other important point I meant to make. The
> :purpose of the "ATC" designation is to figure out who gets to vote
> :for the Technical Committee, as a form of self-governance. That's
> :all, but it's very important (in my opinion, far, far, far more
> :important than some look-at-me status on a conference badge or a
> :hand-out on free admission to an event). Granting votes for the
> :upstream technical governing body to people who aren't involved
> :directly in upstream technology decisions makes little sense, or at
> :least causes it to cease being self-governance (as much as letting
> :all of OpenStack's software developers decide who should run the
> :User Committee would make it no longer well represent downstream
> :users).
>
> At the risk of drifting off topic that concern "letting all of
> OpenStack's software developers decide who should run the User
> Committee (UC)" is largely why the UC hasn't expanded to include
> elected positions.
>
> As currently written bylaws define the UC as 3 appointed positions. !
> appointed by TC one by the board and the third by thte other two (FYI
> I'm currently sitting in the TC apointed seat).  The by laws further
> allow the UC to add seats elected by all foundation members.  In
> Tokyo summit sessions where expantion was discussed the consensus was
> to encourage more volunteer participation but not to add more formal
> seats because there was no way to properly define the voting
> constituency. Personally I can see both sides of that argument, but
> the sense of the room was not to add elected positions untill we can
> better deifne the constituency (that discussion could be reopened but
> if you'd like to do so please start a new thread)
>
> Perhaps nailing down this definition for recognition can actually have
> broader implications and help to define who elects the UC.  It would
> take a by-law change of course, but atleast we'd actually have a good
> proposal (which we currently don't).
>
> -Jon
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-community] Recognising Ops contributions

[Robert Starmer]

So when a user manages a discussion across a group of operators, who's
input is then fed into the development teams who are developing the
software, and in such a way are supporting the development cycle, would
those downstream users (I'm not touching the code), not also be ATCs?  The
discussions are technical, they are active, and they are hopefully
contributing to the codebase.  But the venue, and resources involved are
clearly users.

How do you differentiate that.

But I'll also say, we are now _way_ off topic.  The point that drove a lot
of this discussion wasn't wether Ops should get ATC (perhaps needs a
separate thread, as I believe strongly that they should), but wether there
was a model by which the downstream users could be recognized for their
contributions to making OpenStack functional.  Hence the concept that
perhaps for now, it makes sense to have a different title, and still allow
folks to go to conferences where they can continue to engage with the
community, at a technical level, to further all of our goals at growing
OpenStack.

I still think we should go with TOC/IRO/ACC or whatever, and discuss what a
technical contribution might be separately.

Robert



On Fri, Mar 4, 2016 at 9:38 AM, Jeremy Stanley  wrote:

> On 2016-03-04 16:34:27 +0200 (+0200), Maish Saidel-Keesing wrote:
> [...]
> > By saying that someone who contributes to OpenStack - but doing so by
> > not writing code are not entitled to any technical say in what
> > directions OpenStack should pursue or how OpenStack should be governed,
> > is IMHO a weird (to put it nicely) perception of equality.
> [...]
>
> Conversely, you're arguing for an expansion of scope for the TC. Its
> charter right now gives it power to govern the activities of the
> groups which produce the software and documentation which make up
> OpenStack. We have a separate governing body, the UC, which is
> intended to represent the people who deploy, run and interact with
> OpenStack software. Are you saying the UC should be dissolved and
> everyone it formerly represented should come under the jurisdiction
> of the TC? Or that we should all be represented by both the TC and
> UC no matter what our involvement with the OpenStack
> community/ecosystem might be? Or something else entirely?
>
> Governance in OpenStack is a two-way street, and the people whose
> actions are governed choose who governs those actions. Any increase
> in scope of possible voters is an equal increase in scope for the
> body governing them, and I don't personally think we should hand the
> TC additional jurisdiction outside its present charter.
> --
> Jeremy Stanley
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-community] Recognising Ops contributions

[Jonathan Proulx]

On Fri, Mar 04, 2016 at 12:20:44PM +, Jeremy Stanley wrote:
:On 2016-03-04 10:02:36 +0100 (+0100), Thierry Carrez wrote:
:[...]
:> Upstream contributors are represented by the Technical Committee
:> and vote for it. Downstream contributors are represented by the
:> User Committee and (imho) should vote for it.
:[...]
:
:Right, this brings up the other important point I meant to make. The
:purpose of the "ATC" designation is to figure out who gets to vote
:for the Technical Committee, as a form of self-governance. That's
:all, but it's very important (in my opinion, far, far, far more
:important than some look-at-me status on a conference badge or a
:hand-out on free admission to an event). Granting votes for the
:upstream technical governing body to people who aren't involved
:directly in upstream technology decisions makes little sense, or at
:least causes it to cease being self-governance (as much as letting
:all of OpenStack's software developers decide who should run the
:User Committee would make it no longer well represent downstream
:users).

At the risk of drifting off topic that concern "letting all of
OpenStack's software developers decide who should run the User
Committee (UC)" is largely why the UC hasn't expanded to include
elected positions.

As currently written bylaws define the UC as 3 appointed positions. !
appointed by TC one by the board and the third by thte other two (FYI
I'm currently sitting in the TC apointed seat).  The by laws further
allow the UC to add seats elected by all foundation members.  In
Tokyo summit sessions where expantion was discussed the consensus was
to encourage more volunteer participation but not to add more formal
seats because there was no way to properly define the voting
constituency. Personally I can see both sides of that argument, but
the sense of the room was not to add elected positions untill we can
better deifne the constituency (that discussion could be reopened but
if you'd like to do so please start a new thread)

Perhaps nailing down this definition for recognition can actually have
broader implications and help to define who elects the UC.  It would
take a by-law change of course, but atleast we'd actually have a good
proposal (which we currently don't).

-Jon

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [glance] Remove `run_tests.sh` and `tools/*`

[Nikhil Komawar]

I think the hard question to me here is:

Do people care about testing code on system installs vs. virtual env?
run_tests does that and for some cases when you want to be extra sure
about your CICD nodes, packaging and upgrades, the problem is solved.

Are packagers using tox to this purpose?

On 3/4/16 11:16 AM, Steve Martinelli wrote:
>
> The keystone team did the same during Liberty while we were moving
> towards using oslo.* projects instead of oslo-incubator [0]. We also
> noticed that they were rarely used, and we did not go through a
> deprecation process since these are developer tools. We're still
> finding a few spots in our docs that need updating, but overall it was
> an easy transition.
>
> [0]
> https://github.com/openstack/keystone/commit/55e9514cbd4e712e2c317335294355cf1596d870
>
> stevemar
>
> Inactive hide details for Flavio Percoco ---2016/03/04 06:51:47
> AM---Hey Folks, I'm looking at doing some cleanups in our repo Flavio
> Percoco ---2016/03/04 06:51:47 AM---Hey Folks, I'm looking at doing
> some cleanups in our repo and I would like to start by
>
> From: Flavio Percoco 
> To: openstack-...@lists.openstack.org
> Cc: openstack-operators@lists.openstack.org
> Date: 2016/03/04 06:51 AM
> Subject: [Openstack-operators] [glance] Remove `run_tests.sh` and
> `tools/*`
>
> 
>
>
>
> Hey Folks,
>
> I'm looking at doing some cleanups in our repo and I would like to
> start by
> deprecating the `run_tests` script and the contents in the `tools/` dir.
>
> As far as I can tell, no one is using this code - we're not even using
> it in the
> gate - as it was broken until recently, I believe. The recommended way
> to run
> tests is using `tox` and I believe having this script in the code base
> misleads
> new contributors and other users.
>
> So, before we do this. I wanted to get feedback from a broader
> audience and give
> a heads up to folks that might be using this code.
>
> Any objections? Something I'm missing?
>
> Flavio
>
> -- 
> @flaper87
> Flavio Percoco
> [attachment "signature.asc" deleted by Steve Martinelli/Toronto/IBM]
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
>
> __
> 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

-- 

Thanks,
Nikhil

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [glance] Remove `run_tests.sh` and `tools/*`

[Steve Martinelli]

The keystone team did the same during Liberty while we were moving towards
using oslo.* projects instead of oslo-incubator [0]. We also noticed that
they were rarely used, and we did not go through a deprecation process
since these are developer tools. We're still finding a few spots in our
docs that need updating, but overall it was an easy transition.

[0]
https://github.com/openstack/keystone/commit/55e9514cbd4e712e2c317335294355cf1596d870

stevemar



From:   Flavio Percoco 
To: openstack-...@lists.openstack.org
Cc: openstack-operators@lists.openstack.org
Date:   2016/03/04 06:51 AM
Subject:[Openstack-operators] [glance] Remove `run_tests.sh` and
`tools/*`



Hey Folks,

I'm looking at doing some cleanups in our repo and I would like to start by
deprecating the `run_tests` script and the contents in the `tools/` dir.

As far as I can tell, no one is using this code - we're not even using it
in the
gate - as it was broken until recently, I believe. The recommended way to
run
tests is using `tox` and I believe having this script in the code base
misleads
new contributors and other users.

So, before we do this. I wanted to get feedback from a broader audience and
give
a heads up to folks that might be using this code.

Any objections? Something I'm missing?

Flavio

--
@flaper87
Flavio Percoco
[attachment "signature.asc" deleted by Steve Martinelli/Toronto/IBM]
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [gnocchi][ceilometer] Taking Scientific WG Ops Meetup Feedback back to Ceilometer

[gordon chung]

> One part of the documentation set that we were missing was a guide to how to 
> migrate from ceilometer to a ceilometer/gnocchi combination (which I 
> understand is the ultimate architecture). We would like to migrate the 
> historical data we have stored in ceilometer.
>
> The main line documentation (such as 
> http://docs.openstack.org/liberty/config-reference/content/) does not yet 
> contain details on the Gnocchi configuration so some people may miss this 
> option when following the docs. The gnocchi.xyz has good content but it is 
> not the standard configuration guides. I guess once Gnocchi is into the Big 
> Tent then this sort of integration can occur.
>
> It’s early days yet so we don’t yet have the feeling for running Gnocchi at 
> scale.
>
> Tim

hi,

there isn't an active migration path between Ceilometer's legacy 
database to Gnocchi. it was discussed but given the limited resources we 
have (contributors are welcomed) we just do not have the bandwidth 
currently to build a tool to help port data over.

Gnocchi is not a 1:1 replacement of Ceilometer's old API, it does not 
capture full-fidelity of data and requires defined archive policy rules, 
which makes a migration tool necessary. it is mainly intended to replace 
the 'ceilometer statistics' use case of the old API.

we were hoping to get a reference architecture this cycle but were 
delayed due to resources being pulled to other tasks. currently, the 
best option is to take a look at the devstack plugins for Gnocchi[1] and 
Ceilometer[2] (requires bash knowledge) to get an idea of how they're 
set up to work together in the gate.

as with all new things, it's recommended you test this out first, to 
learn new API[3] and find potential bugs. you can configure the 
Ceilometer collector to write to both existing db and Gnocchi so your 
current usage is not interrupted.

[1] https://github.com/openstack/gnocchi/blob/master/devstack/plugin.sh
[2] https://github.com/openstack/ceilometer/blob/master/devstack/plugin.sh
[3] http://gnocchi.xyz/rest.html

cheers,
-- 
gord
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-community] Recognising Ops contributions

[Matt Jarvis]

Isn't this more nuanced than simply 'upstream' and 'downstream' ?
Characterising downstream as "people who help others using OpenStack, by
moderating Ops meetups, by filing bugs, by answering questions on Ask, by
contributing a blogpost, etc...". is an extremely broad church.

My assumption about this whole thread was that the point of it was to try
and recognise the operators in the middle of these two groups - who are
contributing to technical direction through active participation in ops
events, providing feedback and testing for features, contributing to the
ops codebase through osops etc. etc. etc.



On 4 March 2016 at 14:34, Maish Saidel-Keesing  wrote:

>
>
> On 03/04/16 14:20, Jeremy Stanley wrote:
> > On 2016-03-04 10:02:36 +0100 (+0100), Thierry Carrez wrote:
> > [...]
> >> Upstream contributors are represented by the Technical Committee
> >> and vote for it. Downstream contributors are represented by the
> >> User Committee and (imho) should vote for it.
> > [...]
> >
> > Right, this brings up the other important point I meant to make. The
> > purpose of the "ATC" designation is to figure out who gets to vote
> > for the Technical Committee, as a form of self-governance. That's
> > all, but it's very important (in my opinion, far, far, far more
> > important than some look-at-me status on a conference badge or a
> > hand-out on free admission to an event). Granting votes for the
> > upstream technical governing body to people who aren't involved
> > directly in upstream technology decisions makes little sense, or at
> > least causes it to cease being self-governance (as much as letting
> > all of OpenStack's software developers decide who should run the
> > User Committee would make it no longer well represent downstream
> > users).
> I have been following this as a silent bystander for a while - and we
> have come full circle. And again here we bring up an old issue.
>
> (And forgive me Jeremy that you were the one whose mail triggered my
> response - this is not directed at you personally, or any specific
> person - but the OpenStack Community as a whole)
>
> Should ops contributors be accepted as ATC's?
>
> I have been saying this for a while - and I will continue singing this
> song for as long as I can - hopefully until someone listens.
>
> Operator contributions to OpenStack are no less important or no less
> equal than that of anyone writing code or translating UI's or writing
> documentation.
>
> By saying that someone who contributes to OpenStack - but doing so by
> not writing code are not entitled to any technical say in what
> directions OpenStack should pursue or how OpenStack should be governed,
> is IMHO a weird (to put it nicely) perception of equality.
>
> > I worry that "ATC means I get into events for free" is conflating
> > two completely incidental factors and causes focus on the wrong
> > issues. Let's figure out how to get the community better involved in
> > these events, but making everyone an "ATC" isn't really the solution
> > to that problem.
> So I see two options.
>
> 1. Ops Contributors are considered Active Technical Contributors - just
> the same as anyone writing code - or fixing a spelling mistake in
> documentation (and yes submitting a patch to correct a typo in a
> document - does give you ATC status). Their contributions are just as
> important to the success of the community as anyone else.
>
> or
>
> 2. Give Ops contributors a different status (whatever the name may be) -
> and change the governance laws to allow these people with this status a
> voting right in the Technical committee. They have as much right as any
> other contributor to cast their opinion on how the TC should govern and
> what direction it should choose.
>
> By alienating Operators (and yes it is harsh word - but that is the
> feeling that many Operators - me included - have at the moment) from
> having a say in - how OpenStack should run, what release cycles should
> be - what the other side of the fence is experiencing each and every day
> due to problems in OpenStack's past and possible potential trouble with
> the future - reminds me of a time in the not so far back history where
> not all men/women were equal.
>
> Where some were allowed to vote, and others not - they were told that
> others could decide for them - because those others knew what was best.
>
> *Forgive the rant.*
>
> --
> Best Regards,
> Maish Saidel-Keesing
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

-- 
DataCentred Limited registered in England and Wales no. 05611763
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [ceilometer] Is it possible to set how often a ceilometer alarm fires when continuous alarm is true?

[gordon chung]

hi Mike,

the actual frequency of alerts corresponds to the frequency of alarm 
evaluations[1]. the evaluation frequency defaults to 60s but can be 
changed by setting 'evaluation_interval' option in your conf file.


On 03/03/2016 5:20 PM, Mike Smith wrote:
> We are using Ceilometer to tell us when it’s time to expand a server
> cluster based on cpu utilization.  When I turn on repeat-actions
> (continuous alarming), it alerts about every 20 seconds.  Is there any
> way to specify how often the continuous alarm fires?   I like the idea
> of continuous alarm for our use-case, but doing it multiple times per
> minute is excessive.
>
> I haven’t seen anything about this in the docs or in my search.  Help
> appreciated!
>
> Mike Smith
> Lead Cloud Systems Architect
> Overstock.com 
>
>
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

cheers,
-- 
gord

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] libvirt cpu type per instance

[Jonathan Proulx]

On Fri, Mar 04, 2016 at 11:52:33AM +0800, gustavo panizzo (gfa) wrote:
:On Thu, Mar 03, 2016 at 03:52:49PM -0500, Jonathan Proulx wrote:
:> 
:> I have a user who wants to specify their libvirt CPU type to restrict
:> performance because they're modeling embeded systems.
:> 
:> I seem to vaguely recall there is/was a way to specify this either in
:> the instance type or maybe even in the image metadata, but I can't
:> seem to find it.
:> 
:> Am I delusional or blind?


As previous posters pointed out I was a bit delusional obviously cpu
type only limits instruction set & is useful for bianry compatibility
but mothing to do with speed limiting or equalization. 

:you can use
:https://wiki.openstack.org/wiki/InstanceResourceQuota

Thanks I think that has the bits I'm looking for.  Had been reading on
a different document about cpu_shares (which are relative and thus not
what I want), but some how missed "cpu_quota" which may be the right
thing for me

so I was also a bit blind :)

Thanks,
-Jon


:
:to create "slow" flavors
:
:> 
:> -Jon 
:> 
:> -- 
:> 
:> ___
:> OpenStack-operators mailing list
:> OpenStack-operators@lists.openstack.org
:> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
:
:-- 
:1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333
:
:keybase: http://keybase.io/gfa

-- 

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-community] Recognising Ops contributions

[Jeremy Stanley]

On 2016-03-04 10:02:36 +0100 (+0100), Thierry Carrez wrote:
[...]
> Upstream contributors are represented by the Technical Committee
> and vote for it. Downstream contributors are represented by the
> User Committee and (imho) should vote for it.
[...]

Right, this brings up the other important point I meant to make. The
purpose of the "ATC" designation is to figure out who gets to vote
for the Technical Committee, as a form of self-governance. That's
all, but it's very important (in my opinion, far, far, far more
important than some look-at-me status on a conference badge or a
hand-out on free admission to an event). Granting votes for the
upstream technical governing body to people who aren't involved
directly in upstream technology decisions makes little sense, or at
least causes it to cease being self-governance (as much as letting
all of OpenStack's software developers decide who should run the
User Committee would make it no longer well represent downstream
users).

I worry that "ATC means I get into events for free" is conflating
two completely incidental factors and causes focus on the wrong
issues. Let's figure out how to get the community better involved in
these events, but making everyone an "ATC" isn't really the solution
to that problem.
-- 
Jeremy Stanley

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [glance] Remove `run_tests.sh` and `tools/*`

[Flavio Percoco]

Hey Folks,

I'm looking at doing some cleanups in our repo and I would like to start by
deprecating the `run_tests` script and the contents in the `tools/` dir.

As far as I can tell, no one is using this code - we're not even using it in the
gate - as it was broken until recently, I believe. The recommended way to run
tests is using `tox` and I believe having this script in the code base misleads
new contributors and other users.

So, before we do this. I wanted to get feedback from a broader audience and give
a heads up to folks that might be using this code.

Any objections? Something I'm missing?

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Horizon bug fixed in Liberty, how should we ask a backport to Kilo ?

[Matthias Runge]

On 04/03/16 10:47, James Page wrote:
> Added a bug task for the Kilo UCA - this should be picked up in the next
> round of kilo updates for the UCA.
> 

I cherry-picked the fix into Red Hat OpenStack version 7, tracking bug is
https://bugzilla.redhat.com/show_bug.cgi?id=1314698

Matthias


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Horizon bug fixed in Liberty, how should we ask a backport to Kilo ?

[James Page]

Added a bug task for the Kilo UCA - this should be picked up in the next
round of kilo updates for the UCA.

On Fri, 4 Mar 2016 at 08:35 Matt Jarvis 
wrote:

> This thread is a great example of the value of the midcycle meetups :)
>
> On 4 March 2016 at 08:09, Saverio Proto  wrote:
>
>> Thanks for merging the patch so quickly ! I will try today to build
>> new ubuntu packages and and for feedback at UCA.
>>
>> > But yes, thank you for pointing this out. Bug fixes are mostly
>> > backported to Liberty release, in some rare cases Kilo might get a fix
>> > as well.
>>
>> This is an endless discussion :)
>> But please look here at page 20:
>> https://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf
>>
>> Most production systems are on old releases.
>> Kilo is not that old ! And I am really curious to see the results of
>> the next Survey.
>> We would like to avoid to have each installation with custom packages.
>>
>> I think this email thread was a good example on how we can improve
>> operators to developers feedback to have better stable branches.
>> Operators should not be afraid of proposing a cherry-pick to  stable
>> branch, especially if it fixes a non-corner case problem, and if it
>> easy to review.
>>
>> my 2 cents :)
>>
>> Cheers,
>>
>> Saverio
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> DataCentred Limited registered in England and Wales no. 05611763
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-community] Recognising Ops contributions

[Thierry Carrez]

Jeremy Stanley wrote:

On 2016-03-03 10:41:45 -0800 (-0800), Stefano Maffulli wrote:
[...]

I suggest not to create a separate category, and reuse ATC. Active
Technical Contributor always meant to include any contribution of
technical nature, including legal, operations, documentation, user
stories, etc. Creating a new name risks TLA proliferation (it's a
thing) and exacerbate the "us vs them" that already exists. ATCs
would already know that they are operators, doc writers, UX
experts, marketers, translators, developers, laywers etc and all
have their own venues to meet and discuss among their peers.


I agree that we should use a common contributor term for all of
them (inclusivity is important and we're all one community), but I
actually disagree with our current use of "ATC" for this at all
because it's a term defined in the foundation bylaws and, while the
people who have "ATC" on their badges and get free conference
admission are a _subset_ of the ATC definition in the bylaws, who
gets free admission is decided by the conference coordinators on an
event-by-event basis and often does not extend to _all_ official
ATCs (for example, people with contributions in the prior cycle but
not the current cycle are officially ATC but don't get free
admission for that).


Yeah, we can't really overload ATC because this is defined and used in 
governance. I'd rather call all of us "contributors".


There are "upstream" contributors (people who author changes to the 
various git repositories that make up OpenStack), and "downstream" 
contributors (people who help others using OpenStack, by moderating Ops 
meetups, by filing bugs, by answering questions on Ask, by contributing 
a blogpost, etc...). Some people contribute both upstream and 
downstream. Upstream contributors are represented by the Technical 
Committee and vote for it. Downstream contributors are represented by 
the User Committee and (imho) should vote for it.


If any perks are associated to contribution, they should apply equally 
to upstream and downstream contributors, because both aspects are 
equally important.


--
Thierry Carrez (ttx)

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Horizon bug fixed in Liberty, how should we ask a backport to Kilo ?

[Matt Jarvis]

This thread is a great example of the value of the midcycle meetups :)

On 4 March 2016 at 08:09, Saverio Proto  wrote:

> Thanks for merging the patch so quickly ! I will try today to build
> new ubuntu packages and and for feedback at UCA.
>
> > But yes, thank you for pointing this out. Bug fixes are mostly
> > backported to Liberty release, in some rare cases Kilo might get a fix
> > as well.
>
> This is an endless discussion :)
> But please look here at page 20:
> https://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf
>
> Most production systems are on old releases.
> Kilo is not that old ! And I am really curious to see the results of
> the next Survey.
> We would like to avoid to have each installation with custom packages.
>
> I think this email thread was a good example on how we can improve
> operators to developers feedback to have better stable branches.
> Operators should not be afraid of proposing a cherry-pick to  stable
> branch, especially if it fixes a non-corner case problem, and if it
> easy to review.
>
> my 2 cents :)
>
> Cheers,
>
> Saverio
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

-- 
DataCentred Limited registered in England and Wales no. 05611763
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Horizon bug fixed in Liberty, how should we ask a backport to Kilo ?

[Saverio Proto]

Thanks for merging the patch so quickly ! I will try today to build
new ubuntu packages and and for feedback at UCA.

> But yes, thank you for pointing this out. Bug fixes are mostly
> backported to Liberty release, in some rare cases Kilo might get a fix
> as well.

This is an endless discussion :)
But please look here at page 20:
https://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf

Most production systems are on old releases.
Kilo is not that old ! And I am really curious to see the results of
the next Survey.
We would like to avoid to have each installation with custom packages.

I think this email thread was a good example on how we can improve
operators to developers feedback to have better stable branches.
Operators should not be afraid of proposing a cherry-pick to  stable
branch, especially if it fixes a non-corner case problem, and if it
easy to review.

my 2 cents :)

Cheers,

Saverio

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators