Re: [openstack-dev] [kolla] Monitoring tooling

[Stephen Hindle]

My understanding was Sensu could produce metrics ?
And Kapacitor can do alerting for the TICK stack stuff mewald is doing...
I really don't see them as that different ?


On Fri, Jul 22, 2016 at 5:19 PM, Dave Walker  wrote:
> Yes, this is my thought.
>
> The scope of the Sensu work is: "Is this thing working?" (with the reference
> being up/down)
> But the scope of the Grafana and friends is, "How hard is this working?"
> (but no alerting)
>
> They are certainly complementary However, Sensu can throw data at a
> Grafana stack (aiui).. but I fear that is too much to achieve this cycle.
>
> --
> Kind Regards,
> Dave Walker
>
> On 23 July 2016 at 00:11, Fox, Kevin M  wrote:
>>
>> I think those are two different, complementary things.
>>
>> One's metrics and the other is monitoring. You probably want both at the
>> same time.
>>
>> Thanks,
>> Kevin
>> 
>> From: Steven Dake (stdake) [std...@cisco.com]
>> Sent: Friday, July 22, 2016 3:52 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [kolla] Monitoring tooling
>>
>> Thanks for pointing that out.  Brain out to lunch today it appears :(
>>
>> I think choices are a good thing even though they increase our
>> implementation footprint.  Anyone opposed to implementing both with
>> something in globals.yml like
>> monitoring: grafana or
>> monitoring: sensu
>>
>> Comments questions or concerns welcome.
>>
>> Regards
>> -steve
>>
>> On 7/22/16, 3:42 PM, "Stephen Hindle"  wrote:
>>
>> >Don't forget mewalds implementation as well - we now have 2 monitoring
>> >options for kolla :-)
>> >
>> >On Fri, Jul 22, 2016 at 3:15 PM, Steven Dake (stdake) 
>> >wrote:
>> >> Hi folks,
>> >>
>> >> At the midcycle we decided to push off implementing Monitoring until
>> >>post
>> >> Newton.  The rationale for this decision was that the core review team
>> >>has
>> >> enough on their plates and nobody was super keen to implement any
>> >>monitoring
>> >> solution given our other priorities.
>> >>
>> >> Like all good things, communities produce new folks that want to do new
>> >> things, and Sensu was proposed as Kolla's monitoring solution (atleast
>> >>the
>> >> first one).  A developer that has done some good work has shown up to
>> >>do the
>> >> job as well :)  I have heard good things about Sensu, minus the fact
>> >>that it
>> >> is implemented in Ruby and I fear it may end up causing our gate a lot
>> >>of
>> >> hassle.
>> >>
>> >> https://review.openstack.org/#/c/341861/
>> >>
>> >>
>> >> Anyway I think we can work through the gate problem.
>> >>
>> >> Does anyone have any better suggestion?  I'd like to unblock Dave's
>> >> work
>> >> which is blocked on a ­2 pending a complete discussion of our
>> >> monitoring
>> >> solution.  Note we may end up implementing more than one down the road
>> >> ­
>> >> Sensu is just where the original interest was.
>> >>
>> >> Please provide feedback, even if you don't have a preference, whether
>> >>your a
>> >> core reviewer or not.
>> >>
>> >> My take is we can merge this work in non-prioirty order, and if it
>> >>makes the
>> >> end of the cycle fantastic ­ if not, we can release it in Ocatta.
>> >>
>> >> Regards
>> >> -steve
>> >>
>> >>
>> >>
>>
>> >> >>_
>> >>_
>> >> 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
>> >>
>> >
>> >
>> >
>> >--
>> >Stephen Hindle - Senior Systems Engineer
>> >480.807.8189 480.807.8189
>> >www.limelight.com Delivering Faster Better
>> >
>> >Join the conversation
>> >
>> >at Limelight Connect
>> >
>> >--
>> >The information in this message may be confidential.  It is intended
>> >solely
>> >for
>> >the addressee(s).  If you are not the intended recipient, any disclosure,
>> >copying or distribution of the message, or any action or omission taken
>> >by
>> >you
>> >in reliance on it, is prohibited and may be unlawful.  Please immediately
>> >contact the sender if you have received this message in error.
>> >
>> >
>>
>> > >__
>> >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 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 Development 

Re: [openstack-dev] [OpenStack-docs] [glance] [docs] WADL migration achieved

[Anne Gentle]

Excellent! Thanks for sharing.

Well done, Brian, your efforts are much appreciated. Thanks Nikhil for
letting us celebrate with your team!

:) Happy to waddle-no-more.
Anne

On Sat, Jul 23, 2016 at 2:05 PM, Nikhil Komawar  wrote:
> Hi all,
>
>
> I wanted to share my rejoice with you all that after persistent effort
> from Brian Rosmaita, we've (Glance) managed to accomplish another
> priority for this cycle the WADL migration, along with a good number of
> updates to the api-ref docs. For those unaware, this was the request
> from the docs team at the beginning of newton release [1].
>
>
> Kudos Brian and everyone else who have pitched into this effort
> including reviews. Please consider my congratulations to all involved
> for this nice change.
>
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-May/thread.html#93765
>
> --
>
> Thanks,
> Nikhil
>
>
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs



-- 
Anne Gentle
www.justwriteclick.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

[openstack-dev] [kolla][stable] Please consider our application for stable:follows-policy for Kolla

[Steven Dake (stdake)]

[Forgot kolla tag]

From: Steven Dake >
Date: Saturday, July 23, 2016 at 12:30 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [stable] Please consider our application for stable:follows-policy for 
Kolla

Hey folks,

The review is here:
https://review.openstack.org/346455
__
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] [stable] Please consider our application for stable:follows-policy for Kolla

[Steven Dake (stdake)]

Hey folks,

The review is here:
https://review.openstack.org/346455
__
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] [requirements] cross project testing

[Matthew Thode]

On 07/22/2016 10:54 PM, Matthew Thode wrote:
> One of the things that seems to happen now and then is that an update to
> requirements breaks gate for other projects in some way.  One thing that
> helps is cross project testing, though we do that on a one off basis I'd
> like to see this testing become more codified.  I have a review out that
> does a (very) hackish proof of concept, I've tested both functional and
> unit testing, both pass.
> 
> https://review.openstack.org/#/c/345011/
> 
> (saved the functional testing, don't have the unit test link...)
> http://logs.openstack.org/11/345011/5/check/gate-requirements-pep8/5afcdf9/console.html
> 
> So, my question to put to other projects is, which tests of yours do we
> hit when requirements break things for you.  This list will hopefully be
> used to figure out what we can test our changes against to not cause the
> badness.
> 
> Any notes on this would be appreciated :D
> 
> 
> 
> __
> 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
> 

I forgot to mention, but thanks to Ian (sigmavirus) for pointing me to
the script I modified for this (came from bandit).

-- 
-- Matthew Thode (prometheanfire)

__
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] [docs] WADL migration achieved

[Nikhil Komawar]

Hi all,


I wanted to share my rejoice with you all that after persistent effort
from Brian Rosmaita, we've (Glance) managed to accomplish another
priority for this cycle the WADL migration, along with a good number of
updates to the api-ref docs. For those unaware, this was the request
from the docs team at the beginning of newton release [1].


Kudos Brian and everyone else who have pitched into this effort
including reviews. Please consider my congratulations to all involved
for this nice change.


[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-May/thread.html#93765

-- 

Thanks,
Nikhil


__
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] [kolla][vote] Applying for stable-follows tag

[Steven Dake (stdake)]

This vote passed unanimously prior to the July 25th deadline.

Lets apply :)

Regards
-steve

From: Steven Dake >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, July 18, 2016 at 5:07 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [kolla][vote] Applying for stable-follows tag

Hey Koalians,

I'd like us to consider applying  for the stable follows policy tag.  Full 
details are here:

http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst

Because of the magic work we did to make liberty functional, it is possible 
that we may not be able to apply for this tag until Liberty falls into EOL.  
Still I personally believe intent matters most, and our intent has always been 
for these to be stable low-rate-of-change no-feature-backport branches.  There 
are some exceptions I think we would fit under for the Liberty case, so I think 
it is worth a shot.

I'd need 2-4 people to commit to joining the stable backport team for Kolla 
reviews specifically.  These folks would be the only folks that could ACK 
patches in the stable branch maintenance queue.  Anyone could continue to 
submit backport patches as they desire.

I'll leave voting open for 1 week or until there I a majority (6 core 
reviewers) or until there is a unanimous vote.  If there is not, then we won't 
apply.  The deadline for this vote is July 25th.

Thanks!
-steve


__
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] [release][kolla] Error in tagging process by release liason

[Steven Dake (stdake)]

Doug and friends,

I made a pretty serious error when tagging kolla-kubernetes originally.  
Kolla-kubernetes is in development and not in a production ready state.  We 
also don't intend to apply for many if any tags for this repository until it 
becomes more mature.  We do not intend to do backports to this repository once 
Newton is released.

The original tag should have been 0.1.0.0b1.  The second milestone tag was 
0.1.1 (which should have been 0.1.0.0b2).  I caught this during Doug's review 
but it was merged before I had a chance to talk to the release team about 
solutions to this problem.

I don't expect to rewrite the tags or any of that.  I'd like guidance on what 
to do for milestone 3 and Ocatta as well (where I guess we can just reset on 
0.2.0.0b1).

Regards
-steve
__
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] Floating IP pool public not found

[Telles Nobrega]

Hi again, I just ran into this same problem, in my case I solved by setting
in /etc/sahara/sahara.conf the config use_neutron = False

On Thu, Jul 21, 2016 at 10:58 PM, Telles Nobrega 
wrote:

> Hi,
>
> in your /etc/sahara/sahara.conf is use_floating_ips set to true?
>
> On Thu, Jul 21, 2016 at 10:46 PM, 云淡风轻 <821696...@qq.com> wrote:
>
>> hi everyone,
>>
>> when create node group template with sahara 4.0.0 in M version,an error
>> occur:
>>
>> $  openstack dataprocessing node group template create --json
>> my_master_template_create_default.json
>> *Floating IP pool public not found*
>> Error ID: 62672c58-8fdd-40d9-8e6b-8aef0f6ab554
>>
>> less my_master_template_create_default.json
>> {
>> "plugin_name": "vanilla",
>> "hadoop_version": "2.7.1",
>> "node_processes": [
>> "namenode",
>> "resourcemanager"
>> ],
>> "name": "vanilla-default-master",
>> "floating_ip_pool": "*public*",
>> "flavor_id": "6",
>> "auto_security_group": false
>> }
>>
>> in sahara.log:
>> 2016-07-21 21:40:05.216 1521 DEBUG keystoneclient.session
>> [req-ee9a5b0d-b19a-418f-bdd3-018fc4634eb0 7fff70fbbf83441a9b3c4d91a5613825
>> 6cb156a82d0f486a9f50132be9438eb6 - - -] REQ: curl -g -i --insecure -X GET
>> http://10.0.0.132:8774/v2/6cb156a82d0f486a9f50132be9438eb6/os-networks
>> -H "User-Agent: python-novaclient" -H "Accept: application/json" -H
>> "X-Auth-Token: {SHA1}5971da83434fe662c7726b695a4007128c1dc383"
>> _http_log_request
>> /usr/lib/python2.7/site-packages/keystoneclient/session.py:206
>> 2016-07-21 21:40:05.552 1521 DEBUG keystoneclient.session
>> [req-ee9a5b0d-b19a-418f-bdd3-018fc4634eb0 7fff70fbbf83441a9b3c4d91a5613825
>> 6cb156a82d0f486a9f50132be9438eb6 - - -] RESP: [200] Date: Fri, 22 Jul 2016
>> 01:40:05 GMT Connection: keep-alive Content-Type: application/json
>> Content-Length: 1297 X-Compute-Request-Id:
>> req-3279a048-145e-4f8e-bb7b-f77d22037f2a
>> RESP BODY: {"networks": [{"bridge": null, "vpn_public_port": null,
>> "dhcp_start": null, "bridge_interface": null, "share_address": null,
>> "updated_at": null, "id": "9c597886-d439-4fe2-b76b-5338d85aaf37",
>> "cidr_v6": null, "deleted_at": null, "gateway": null, "rxtx_base": null,
>> "label": "public", "priority": null, "project_id": null,
>> "vpn_private_address": null, "deleted": null, "vlan": null, "broadcast":
>> null, "netmask": null, "injected": null, "cidr": null,
>> "vpn_public_address": null, "multi_host": null, "enable_dhcp": null,
>> "dns2": null, "created_at": null, "host": null, "mtu": null, "gateway_v6":
>> null, "netmask_v6": null, "dhcp_server": null, "dns1": null}, {"bridge":
>> null, "vpn_public_port": null, "dhcp_start": null, "bridge_interface":
>> null, "share_address": null, "updated_at": null, "id":
>> "3aaa392b-af4d-4f70-9e2e-1b71a965ff7d", "cidr_v6": null, "deleted_at":
>> null, "gateway": null, "rxtx_base": null, "label": "private", "priority":
>> null, "project_id": null, "vpn_private_address": null, "deleted": null,
>> "vlan": null, "broadcast": null, "netmask": null, "injected": null, "cidr":
>> null, "vpn_public_address": null, "multi_host": null, "enable_dhcp": null,
>> "dns2": null, "created_at": null, "host": null, "mtu": null, "gateway_v6":
>> null, "netmask_v6": null, "dhcp_server": null, "dns1": null}]}
>>  _http_log_response
>> /usr/lib/python2.7/site-packages/keystoneclient/session.py:231
>> 2016-07-21 21:40:05.617 1521 DEBUG sahara.utils.openstack.base
>> [req-ee9a5b0d-b19a-418f-bdd3-018fc4634eb0 7fff70fbbf83441a9b3c4d91a5613825
>> 6cb156a82d0f486a9f50132be9438eb6 - - -] Permanent error occurred during
>> "find" execution: *No Network matching {'id': u'public'}*. (HTTP 404).
>> execute_with_retries
>> /usr/lib/python2.7/site-packages/sahara/utils/openstack/base.py:99
>> 2016-07-21 21:40:05.670 1521 ERROR sahara.utils.api
>> [req-ee9a5b0d-b19a-418f-bdd3-018fc4634eb0 7fff70fbbf83441a9b3c4d91a5613825
>> 6cb156a82d0f486a9f50132be9438eb6 - - -] Validation Error occurred:
>> error_code=400, error_message=*Floating IP pool public not found*
>> Error ID: e369a75d-bf03-4de6-8192-23959967f45a, error_name=NOT_FOUND
>>
>>
>> with:
>> $  neutron net-list
>>
>> +--+-+--+
>> | id   | name| subnets
>>|
>>
>> +--+-+--+
>> | 3aaa392b-af4d-4f70-9e2e-1b71a965ff7d | private |
>> 7cd8341e-9994-4a1d-a46f-22aedfde7bd8 10.0.0.0/24 |
>> | 9c597886-d439-4fe2-b76b-5338d85aaf37 | public  |
>> 0d7a6c95-3f6a-42ad-9cf8-c96e1d9c3c82 172.24.4.224/28 |
>>
>> +--+-+--+
>>
>> $  neutron subnet-list
>>
>> +--++-+--+
>> | id   | name