Re: [Openstack-operators] [packaging][ubuntu] nova-api + nova-placement-api package conflict

2017-06-26 Thread Chris Apsey 

James,

Bug report submitted.

Thanks!

Chris

---
v/r

Chris Apsey
bitskr...@bitskrieg.net
https://www.bitskrieg.net

On 2017-06-26 09:28, James Page wrote:

Tweaking subject line a bit...

On Mon, 26 Jun 2017 at 02:27 Chris Apsey 
wrote:


All,

Doing some testing prior to moving to Ocata from Newton, and I ran
into
this issue when trying to get the nova placement api set up:

==
Package: nova-placement-api
Version: 2:14.0.5-0ubuntu1~cloud0
Priority: extra
Section: net
Source: nova
Maintainer: Ubuntu Developers

Original-Maintainer: Openstack Maintainers

Installed-Size: 56.3 kB
Depends: nova-common (= 2:14.0.5-0ubuntu1~cloud0),
init-system-helpers
(>= 1.18~), lsb-base (>= 4.1+Debian11ubuntu7), python:any (>= 2.7~)
Conflicts: nova-api
Download-Size: 6,062 B
APT-Sources: http://ubuntu-cloud.archive.canonical.com/ubuntu
xenial-updates/newton/main amd64 Packages
Description: OpenStack Compute - placement API frontend
=

Anyone encountered this before?  Not sure why nova-api is marked as
conflicts here.


Really good question - this Conflicts was dropped in
2:15.0.0~b2-0ubuntu1 and it looks like we need the same fix into the
Newton packages as well.

I can see why you want to get the placement api configured before
upgrading as I don't think Ocata will even function without the
placement api running - minimal downtime during release upgrades is
always a good idea!

If you could raise a bug using 'ubuntu-bug nova-placement-api' that
would be a great start to get things rolling.

Cheers

James
___
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-dev] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

2017-06-26 Thread Melvin Hillsman 
On Wed, Jun 21, 2017 at 11:55 AM, Matt Riedemann 
wrote:

> On 6/21/2017 11:17 AM, Shamail Tahir wrote:
>
>>
>>
>> On Wed, Jun 21, 2017 at 12:02 PM, Thierry Carrez > > wrote:
>>
>> Shamail Tahir wrote:
>> > In the past, governance has helped (on the UC WG side) to reduce
>> > overlaps/duplication in WGs chartered for similar objectives. I
>> would
>> > like to understand how we will handle this (if at all) with the new
>> SIG
>> > proposa?
>>
>> I tend to think that any overlap/duplication would get solved
>> naturally,
>> without having to force everyone through an application process that
>> may
>> discourage natural emergence of such groups. I feel like an
>> application
>> process would be premature optimization. We can always encourage
>> groups
>> to merge (or clean them up) after the fact. How much
>> overlaps/duplicative groups did you end up having ?
>>
>>
>> Fair point, it wasn't many. The reason I recalled this effort was because
>> we had to go through the exercise after the fact and that made the volume
>> of WGs to review much larger than had we asked the purpose whenever they
>> were created. As long as we check back periodically and not let the work
>> for validation/clean up pile up then this is probably a non-issue.
>>
>>
>> > Also, do we have to replace WGs as a concept or could SIG
>> > augment them? One suggestion I have would be to keep projects on
>> the TC
>> > side and WGs on the UC side and then allow for spin-up/spin-down of
>> SIGs
>> > as needed for accomplishing specific goals/tasks (picture of a
>> diagram
>> > I created at the Forum[1]).
>>
>> I feel like most groups should be inclusive of all community, so I'd
>> rather see the SIGs being the default, and ops-specific or
>> dev-specific
>> groups the exception. To come back to my Public Cloud WG example, you
>> need to have devs and ops in the same group in the first place before
>> you would spin-up a "address scalability" SIG. Why not just have a
>> Public Cloud SIG in the first place?
>>
>>
>> +1, I interpreted originally that each use-case would be a SIG versus the
>> SIG being able to be segment oriented (in which multiple use-cases could be
>> pursued)
>>
>>
>>  > [...]
>> > Finally, how will this change impact the ATC/AUC status of the SIG
>> > members for voting rights in the TC/UC elections?
>>
>> There are various options. Currently you give UC WG leads the AUC
>> status. We could give any SIG lead both statuses. Or only give the AUC
>> status to a subset of SIGs that the UC deems appropriate. It's really
>> an
>> implementation detail imho. (Also I would expect any SIG lead to
>> already
>> be both AUC and ATC somehow anyway, so that may be a non-issue).
>>
>>
>> We can discuss this later because it really is an implementation detail.
>> Thanks for the answers.
>>
>>
>> --
>> Thierry Carrez (ttx)
>>
>> 
>> __
>> 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,
>> Shamail Tahir
>> t: @ShamailXD
>> tz: Eastern Time
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> I think a key point you're going to want to convey and repeat ad nauseum
> with this SIG idea is that each SIG is focused on a specific use case and
> they can be spun up and spun down. Assuming that's what you want them to be.
>
> One problem I've seen with the various work groups is they overlap in a
> lot of ways but are probably driven as silos. For example, how many
> different work groups are there that care about scaling? So rather than
> have 5 work groups that all overlap on some level for a specific issue,
> create a SIG for that specific issue so the people involved can work on
> defining the specific problem and work to come up with a solution that can
> then be implemented by the upstream development teams, either within a
> single project or across projects depending on the issue. And once the
> specific issue is resolved, close down the SIG.


> Examples here would be things that fall under proposed community wide
> goals for a release, like running API services under wsgi, py3 support,
> moving policy rules into code, hierarchical quotas, RBAC "admin

Re: [Openstack-operators] Leveraging Gnocchi in Mitaka

2017-06-26 Thread Tracy Comstock Roesler 
Hi Gordon,

If I understand what you¹re saying, you think I can try
direct://?publisher=gnocchi in the pipeline.yaml on the controller nodes,
but not the compute nodes to bypass the collector?

When I attempted to do so I received an error (full stack trace ommitted):

2017-06-26 14:52:51.625 41444 ERROR ceilometer.pipeline
[req-e8ac0e01-32f1-4df0-979d-185cd445c7d
5 - - - - -] Pipeline cpu_sink: Continue after error from publisher



...

2017-06-26 14:52:51.625 41444 ERROR ceilometer.pipeline ProgrammingError:
(pymysql.err.Programmi
ngError) (1146, u"Table 'ceilometer.meter' doesn't exist") [SQL: u'SELECT
meter.id \nFROM meter
\nWHERE meter.name = %(name_1)s AND meter.type = %(type_1)s AND meter.unit
= %(unit_1)s'] [param
eters: {u'type_1': 'gauge', u'name_1': 'cpu_util', u'unit_1': '%'}]
2017-06-26 14:52:51.625 41444 ERROR ceilometer.pipeline



It looks like it¹s attempting to pull something from the mysql table for
ceilometer, which we don¹t have tables for.

On 6/26/17, 6:47 AM, "gordon chung"  wrote:

>
>
>On 24/06/17 10:49 PM, Mike Smith wrote:
>> We use ceilometer-compute and we would like to have it push metrics
>>directly to Gnocchi, bypassing the rabbit queues that ceilometer uses in
>>the default Mitaka configuration.  Currently our ceilometer-compute
>>pushes to the notification queue, which gets consumed by a ceilometer
>>process and put into the metrics queue, which in turn gets consumed and
>>pushed to gnocchi by the another ceilometer process.
>>
>> We have tried to set the Œpublisher¹ in the ceilometer pipeline.yaml
>>file to gnocchi:// instead of notifier://, but it doesn¹t seem to do
>>anything.  No errors or anything, it just doesn¹t seem to try and send
>>metrics to the configured gnocchi endpoint.
>>
>> We are running RDO and have openstack-ceilometer-compute-6.1.3-2.el7.
>>We¹re curious if a different version of openstack-ceilometer-compute is
>>required in order to send metrics directly to gnocchi
>
>changing publiser to gnocchi:// won't work in mitaka. this was only done
>in Ocata i believe. you'd have to backport[1] if you want to use
>gnocchi:// directly. alternatively, you can put direct:// and it should
>allow you to avoid collector service.
>
>that said, you cannot push directly from polling agents -- not without
>some hacking. all the pipeline work is handled by notification agent. if
>you don't need any transformations than it's possible to skip
>notification agent but this requires hacking your code as we do not
>support this. i imagine this would be a welcomed addition, we just don't
>have resources to implement it.
>
>[1] 
>https://github.com/openstack/ceilometer/commit/f843b7882fb806cf564c5b3106f
>601815a48c93b
>
>
>-- 
>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

[Openstack-operators] OpenStack User Survey Now Open

2017-06-26 Thread Allison Price 
Hi everyone, 

If you’re running OpenStack, please participate in the OpenStack User Survey 
. If you have already completed the 
survey before, you can simply login to update your deployment details. Please 
note that if your survey response has not been updated in 12 months, it will 
expire, so we encourage you to take this time to update your existing profile 
so your deployment can be included in the upcoming analysis.

As a member of our community, please help us spread the word. We're trying to 
gather as much real-world deployment data as possible to share back with you. 
We have made it easier to complete, and the survey is now available in 7 
languages—English, German, Indonesian, Japanese, Korean, traditional Chinese 
and simplified Chinese. 

The information provided is confidential and will only be presented in 
aggregate unless you consent to making it public.

The deadline to complete the survey and be part of the next report is Friday, 
August 11 at 23:59 UTC.

You can login and complete the OpenStack User Survey here: 
http://www.openstack.org/user-survey 
If you’re interested in joining the OpenStack User Survey Working Group to help 
with the survey analysis, please complete this form: 
https://openstackfoundation.formstack.com/forms/user_survey_working_group 
 
Help us promote the User Survey: 
https://twitter.com/OpenStack/status/879434563134652416 


Please let me know if you have any questions. 

Cheers,
Allison


Allison Price
OpenStack Foundation
alli...@openstack.org


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

Re: [Openstack-operators] [packaging][ubuntu] nova-api + nova-placement-api package conflict

2017-06-26 Thread James Page 
Tweaking subject line a bit...

On Mon, 26 Jun 2017 at 02:27 Chris Apsey  wrote:

> All,
>
> Doing some testing prior to moving to Ocata from Newton, and I ran into
> this issue when trying to get the nova placement api set up:
>
> ==
> Package: nova-placement-api
> Version: 2:14.0.5-0ubuntu1~cloud0
> Priority: extra
> Section: net
> Source: nova
> Maintainer: Ubuntu Developers 
> Original-Maintainer: Openstack Maintainers
> 
> Installed-Size: 56.3 kB
> Depends: nova-common (= 2:14.0.5-0ubuntu1~cloud0), init-system-helpers
> (>= 1.18~), lsb-base (>= 4.1+Debian11ubuntu7), python:any (>= 2.7~)
> Conflicts: nova-api
> Download-Size: 6,062 B
> APT-Sources: http://ubuntu-cloud.archive.canonical.com/ubuntu
> xenial-updates/newton/main amd64 Packages
> Description: OpenStack Compute - placement API frontend
> =
>
> Anyone encountered this before?  Not sure why nova-api is marked as
> conflicts here.
>

Really good question - this Conflicts was dropped in 2:15.0.0~b2-0ubuntu1
and it looks like we need the same fix into the Newton packages as well.

I can see why you want to get the placement api configured before upgrading
as I don't think Ocata will even function without the placement api running
- minimal downtime during release upgrades is always a good idea!

If you could raise a bug using 'ubuntu-bug nova-placement-api' that would
be a great start to get things rolling.

Cheers

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

Re: [Openstack-operators] Leveraging Gnocchi in Mitaka

2017-06-26 Thread gordon chung 


On 24/06/17 10:49 PM, Mike Smith wrote:
> We use ceilometer-compute and we would like to have it push metrics directly 
> to Gnocchi, bypassing the rabbit queues that ceilometer uses in the default 
> Mitaka configuration.  Currently our ceilometer-compute pushes to the 
> notification queue, which gets consumed by a ceilometer process and put into 
> the metrics queue, which in turn gets consumed and pushed to gnocchi by the 
> another ceilometer process.
>
> We have tried to set the ‘publisher’ in the ceilometer pipeline.yaml file to 
> gnocchi:// instead of notifier://, but it doesn’t seem to do anything.  No 
> errors or anything, it just doesn’t seem to try and send metrics to the 
> configured gnocchi endpoint.
>
> We are running RDO and have openstack-ceilometer-compute-6.1.3-2.el7.   We’re 
> curious if a different version of openstack-ceilometer-compute is required in 
> order to send metrics directly to gnocchi

changing publiser to gnocchi:// won't work in mitaka. this was only done 
in Ocata i believe. you'd have to backport[1] if you want to use 
gnocchi:// directly. alternatively, you can put direct:// and it should 
allow you to avoid collector service.

that said, you cannot push directly from polling agents -- not without 
some hacking. all the pipeline work is handled by notification agent. if 
you don't need any transformations than it's possible to skip 
notification agent but this requires hacking your code as we do not 
support this. i imagine this would be a welcomed addition, we just don't 
have resources to implement it.

[1] 
https://github.com/openstack/ceilometer/commit/f843b7882fb806cf564c5b3106f601815a48c93b


-- 
gord

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