Re: [openstack-dev] [nova][cinder][glance] What should be the response for invalid 'Accpet' header?

[Singh, Niraj]

Hi Sean,

As per your suggestion, I have reported a bug in Launchpad.
Please refer, https://bugs.launchpad.net/masakari/+bug/1714416

Thank you,

Niraj

From: Sean McGinnis [mailto:sean.mcgin...@gmx.com]
Sent: 31 August 2017 20:47
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][cinder][glance] What should be the response 
for invalid 'Accpet' header?


Hey Niraj,

That does seem to be incorrect behavior on the services side. It would be good 
to have a bug
filed to track it. For now you could open one and flag each project as being 
affected. We may
find that it requires a change in each project, or it may end up being a common 
oslo change.
Either way, a bug will allow us to capture findings and make sure it gets 
resolved.

https://bugs.launchpad.net/cinder/+filebug

Thanks,

Sean

On 08/31/2017 05:10 AM, Singh, Niraj wrote:
Hi Devs,

As of now, when user passes 'Accept' header in request other than JSON and XML 
using curl command then it returns 200 OK response with json format data.
In api-ref guide [1] also it's not clearly mentioned about what response it 
should return if invalid value for 'Accept' header is specified. IMO instead of 
'HTTP 200 OK' it should return 'HTTP 406 Not Acceptable' response.

I have checked this behavior for nova, cinder and glance and for all of these 
it is returning HTTP 200 OK which is invalid.
Please let me know your opinion for the same.

Steps to reproduce:

Request:
curl -g -i -X GET 
http://controller/volume/v2/c72e66cc4f1341f381e0c2eb7b28b443/volumes/detail -H 
"User-Agent: python-cinderclient" -H "Accept: application/abc" -H 
"X-Auth-Token: cd85aff745ce4dc0a04f686b52cf7e4f"


Response:
HTTP/1.1 200 OK
Date: Thu, 31 Aug 2017 07:12:18 GMT
Server: Apache/2.4.18 (Ubuntu)
x-compute-request-id: req-ab48db9d-f869-4eb4-95f9-ef8e90a918df
Content-Type: application/json
Content-Length: 2681
x-openstack-request-id: req-ab48db9d-f869-4eb4-95f9-ef8e90a918df
Connection: close

[1] 
https://developer.openstack.org/api-ref/block-storage/v2/#list-volumes-with-details


Thank you,
Niraj Singh


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.




__

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


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] [QA] [Cinder] [Aodh] [Zaqar] [neutron-lbaas] [neutron-fwaas] [networking-bgpvpn] [ceilometer] [monasca-api] Removal of Old Deprecated data_utils from Temepst

[Ghanshyam Mann]

Updates:

Only nova-lxd is left to merge fix on their stable branches if needed.
nova-lxd  -
Patch Up- 
https://review.openstack.org/#/q/I0a08bdfd304d988ca48fb07d901d3ecfd5968599,n,z

As Pike is released and almost all plugins merged their fix. I have
pushed the old data-utils removal from Tempest. It is WIP and will try
to merge in PTG.   If any plugin still using it, switch to new
location.

https://review.openstack.org/#/c/499869/1


-gmann


On Tue, Jul 25, 2017 at 4:07 PM, Ghanshyam Mann  wrote:
> Hi All,
>
> Tempest migrated data_utils to stale interface long back but kept the
> same in old location also not to break the tempest plugins.
>
> Kenichi has done very nice job to fixing all the tempest plugin to
> switch to stable interface:
> https://review.openstack.org/#/q/branch:master+topic:tempest-data_utils
> and mentioned in ML to backport the same fix on project's stable
> branch if tempest plugin are still in project repo [1].
>
> After around 5 months of time, we merged the patch to remove the old
> deprecated data_utils [2] and many project gate broke due to grenade
> jobs are using stable branch where tempest plugin fix is not
> backported by projects.
> As of now to unblock the gate we approved the revert of tempest patch
> [3] but that is temporary fix to give projects more time to fix their
> tempest plugin on stable branch.
>
> We will extend another month time to remove the deprecated data_utils
> from Tempest. These issue would not occur if all plugins can be
> separated as independent branchless repo as queens TC goal.
>
> Below projects need attentions. I have proposed cherry pick for many
> of the branches listed below, please merge those or fix if patch is
> not up (as it need manual backport).
> 
> neutron-lbaas -
> Patch Up - 
> https://review.openstack.org/#/q/Ie4fd8a4f142430a1bd57c6dc29e143485f449eb9,n,z
> neutron-fwaas
> Patch Up- 
> https://review.openstack.org/#/q/I1a39fc0636a3d1b45aed7a283587460afc076110,n,z
> nova-lxd  -
> Patch Up- 
> https://review.openstack.org/#/q/I0a08bdfd304d988ca48fb07d901d3ecfd5968599,n,z
> cinder -
> Patch Up- 
> https://review.openstack.org/#/q/I9ec9282268adc80c947e18c34f34dc0fdd82b187,n,z
> Aodh
>   ocata- https://review.openstack.org/#/c/486875/
>   newton - TODO
> zaqar
>   ocata- https://review.openstack.org/#/c/486876/
>   newton - TODO
> networking-bgpvpn
>   ocata- https://review.openstack.org/#/c/486877/
>   newton - TODO
> ceilometer
>   ocata- https://review.openstack.org/#/c/486881/
>   newton - TODO
> monasca-api
>   ocata- https://review.openstack.org/#/c/486884/
>   newton - TODO
>
> ..1 http://lists.openstack.org/pipermail/openstack-dev/2017-March/114099.html
> ..2 https://review.openstack.org/#/c/72
> ..3 https://review.openstack.org/#/c/486856/
>
> -gmann

__
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] [openstack] [charms] Openstack with OVN

[Russell Bryant]

Just to make sure you saw it - here is the manual installation doc to help
guide you through what needs to be implemented in a project like this.

https://docs.openstack.org/networking-ovn/latest/install/index.html

On Thu, Aug 31, 2017 at 3:39 PM, Aakash Kt  wrote:

> Hi James,
> Thanks for the reply. This definitely cleared some thing up for me.
> I would love to get started on this charm soon, and will be sure to drop
> in weekly meeting or ask questions on IRC.
>
> Cheers,
> Aakash
>
>
> On Tue, Aug 29, 2017 at 1:56 PM, James Page  wrote:
>
>> Hi Aakash
>>
>> On Tue, 29 Aug 2017 at 05:09 Aakash Kt  wrote:
>>
>>> Hello all,
>>> Resending this mail since I think there might have been some error
>>> sending it the last time.
>>>
>>>I am looking to develop an openstack bundle which uses OVN as the
>>> SDN. I have been reading : https://docs.openstack.org/c
>>> harm-guide/latest/
>>> I have also read : https://docs.openstack.org/n
>>> etworking-ovn/latest/install/index.html
>>>
>>
>> Awesome; we chatted about this on IRC a few times but put off any
>> concrete work until OVN 2.8.0 is released (soon).
>>
>> As far as I understand, this will require me to replace the
>>> "neutron-openvswitch" charm in the openstack base bundle. However, I am not
>>> able to exactly understand what all I will have to rewrite / replace to
>>> make this work.
>>>
>>
>> I think the new charm work is actually three charms (or maybe two) -
>> neutron-ovn (replacing neutron-openvswitch alongside nova-compute
>> deployments), neutron-api-ovn (providing the API only integration of the
>> Neutron API to OVN), and probably an ovn charm for deployment of OVN
>> itself, with relations  <->  <->  for
>> propagation of configuration in deployments.  The ODL charm set is similar
>> is high level design (neutron-api-odl, odl-controller, openvswitch-odl).
>>
>>
>>> Specifically, I need to make neutron work only as an API instead of the
>>> full blown SDN. Also, in the above doc, its mentioned that we have to run
>>> some setup on "controller nodes". How does the term "controller node" map
>>> to the charm?
>>>
>>
>> Controller nodes are one option for the charms, however components of the
>> controller nodes are deployed inside LXD containers to provide separation
>> between services.  For example, you can dedicated three physical servers
>> and then deploy the nova-cloud-controller, neutron-api, glance, keystone,
>> cinder, ceilometer, heat etc.. charms in LXD containers onto those physical
>> machines.  So in the case of OVN, we'd look to deploy the ovn charm on
>> these same physical servers.
>>
>> Hope that helps explain things a bit; if you want to drop into
>> #openstack-charms to ask more questions please do, or you can join one of
>> our weekly meetings and we can discuss further.  We'd normally start a
>> piece of work like this with a spec (http://specs.openstack.org/op
>> enstack/charm-specs/); this topic is something we could discuss in a bit
>> more detail at the PTG in Denver (I'll add an item to the agenda for the
>> charms room).
>>
>> Cheers
>>
>> James
>>
>>
>> 
>> __
>> 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
>>
>>
>
> __
> 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
>
>


-- 
Russell Bryant
__
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] [openstack] [charms] Openstack with OVN

[Aakash Kt]

Hi James,
Thanks for the reply. This definitely cleared some thing up for me.
I would love to get started on this charm soon, and will be sure to drop in
weekly meeting or ask questions on IRC.

Cheers,
Aakash


On Tue, Aug 29, 2017 at 1:56 PM, James Page  wrote:

> Hi Aakash
>
> On Tue, 29 Aug 2017 at 05:09 Aakash Kt  wrote:
>
>> Hello all,
>> Resending this mail since I think there might have been some error
>> sending it the last time.
>>
>>I am looking to develop an openstack bundle which uses OVN as the SDN.
>> I have been reading : https://docs.openstack.org/charm-guide/latest/
>> I have also read : https://docs.openstack.org/
>> networking-ovn/latest/install/index.html
>>
>
> Awesome; we chatted about this on IRC a few times but put off any concrete
> work until OVN 2.8.0 is released (soon).
>
> As far as I understand, this will require me to replace the
>> "neutron-openvswitch" charm in the openstack base bundle. However, I am not
>> able to exactly understand what all I will have to rewrite / replace to
>> make this work.
>>
>
> I think the new charm work is actually three charms (or maybe two) -
> neutron-ovn (replacing neutron-openvswitch alongside nova-compute
> deployments), neutron-api-ovn (providing the API only integration of the
> Neutron API to OVN), and probably an ovn charm for deployment of OVN
> itself, with relations  <->  <->  for
> propagation of configuration in deployments.  The ODL charm set is similar
> is high level design (neutron-api-odl, odl-controller, openvswitch-odl).
>
>
>> Specifically, I need to make neutron work only as an API instead of the
>> full blown SDN. Also, in the above doc, its mentioned that we have to run
>> some setup on "controller nodes". How does the term "controller node" map
>> to the charm?
>>
>
> Controller nodes are one option for the charms, however components of the
> controller nodes are deployed inside LXD containers to provide separation
> between services.  For example, you can dedicated three physical servers
> and then deploy the nova-cloud-controller, neutron-api, glance, keystone,
> cinder, ceilometer, heat etc.. charms in LXD containers onto those physical
> machines.  So in the case of OVN, we'd look to deploy the ovn charm on
> these same physical servers.
>
> Hope that helps explain things a bit; if you want to drop into
> #openstack-charms to ask more questions please do, or you can join one of
> our weekly meetings and we can discuss further.  We'd normally start a
> piece of work like this with a spec (http://specs.openstack.org/
> openstack/charm-specs/); this topic is something we could discuss in a
> bit more detail at the PTG in Denver (I'll add an item to the agenda for
> the charms room).
>
> Cheers
>
> James
>
>
> __
> 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

Re: [openstack-dev] [nova] Can we remove the monkey_patch_modules config option?

[Matt Riedemann]

On 8/30/2017 1:16 PM, Lokesh Jain wrote:

Hi Matt,

Thank you for pointing this out and bringing this to my attention.

We are using the monkey_patch options to add more nova capabilities.
Specifically we are using it to replace Nova’s

nova/network/neutronv2/api.get_port_vnic_info

function for extending the vnic type + phys network lookup for given
neutron port id logic in case of multi-segments + multi phys network
SRIOV deployments.

We are using this functionality since Mitaka. I am assuming that the
removal of nova parameters is proposed for Pike and onwards. Or is the
plan to backport it to previous releases as well? In that case will
need to figure out the plan for it.

Please let me know if further information or clarification is required.

Thanks and Regards,
Lokesh Jain



__
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



The change to deprecate the monkey_patch and monkey_patch_modules option 
was deprecated in Queens, so they wouldn't be removed until the Rocky 
release at the earliest. We don't backport changes which deprecate things.


My recommendation to you is upstream your changes. If it's a new 
feature, propose a blueprint [1].


Chances are someone else needs or wants the same thing, or is already 
doing something similar but without the monkey patch config options.


[1] https://docs.openstack.org/nova/latest/contributor/blueprints.html

--

Thanks,

Matt

__
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] PTG Agenda draft - action required

[Emilien Macchi]

On Thu, Aug 31, 2017 at 10:27 AM, Emilien Macchi  wrote:
[...]
> I'm preparing a Google Calendar today, so everyone can easily
> understand the schedule.

I prepared this public agenda:
https://calendar.google.com/calendar/ical/c1g5npdrsd3p37ods24s19gg0g%40group.calendar.google.com/public/basic.ics
That anyone can subscribe.

Hope it helps,
-- 
Emilien Macchi

__
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] [cinder] [ironic] PTG cross-platform meetup possibility

[Jay S Bryant]

Rich,

I can make Monday at 4 pm work.  Conflicts with some Docs discussions 
but I can step out for a bit.


Thanks!

Jay



On 8/31/2017 8:25 AM, Richard Wellum wrote:

Hi,

How does Monday at 4pm sound? Kolla already has a cross-platform 
discussion with Triple-O at 2pm, so this would dovetail nicely.


Thanks,

||Rich

On Wed, Aug 30, 2017 at 2:48 PM Ivan Kolodyazhny > wrote:


Hi team,

I'm interested in cinder containerization too. It would be great
if we can schedule our meetup after 3pm or even 4pm, It will
increase my chances to attend it.

Thanks in advance.

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Wed, Aug 30, 2017 at 4:23 PM, Dmitry Tantsur
> wrote:

Hi!

I'm all for it. Monday sounds okay to me, though I'll have to
manage some conflicts, of course.


On 08/29/2017 05:56 PM, Richard Wellum wrote:

Hi Folks,

Would there be some interest from Cinder and Ironic (and
others of course) team members to have a quick session at
the PTG with the Kolla team on the latest developments in
Kolla (like the new kolla-ansible devmode for example)?

Also it would give the Kolla team an opportunity to hear
about your teams interest and experiences in
containerization and what you need from Kolla going forward.

I'm thinking an hour or two on Monday afternoon, the first
day of the PTG?

Thanks,

||Rich



__
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 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 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] PTG Agenda draft - action required

[Emilien Macchi]

I brought some changes in the schedule:

- On Wednesday morning, we'll start at 9am and do a one hour
retrospective to discuss what went wrong and good in Pike, and see how
we can do better in Queens. Alex an I will animate this retro.
- Which means, CI topics will be split in 2 times: from 10am to 11am
(don't forget to stay in the room after 11am to collaborate with
Kolla) and also on the afternoon from 1.45pm to 3pm. I think it's
enough time.
- Heat / Mistral sessions from 3pm to 5.30pm.

I don't count the breaks but we'll figure.
I'm preparing a Google Calendar today, so everyone can easily
understand the schedule.
Any feedback / comment is welcome, thanks.

On Tue, Aug 29, 2017 at 8:36 AM, Emilien Macchi  wrote:
> On Mon, Aug 28, 2017 at 3:17 PM, Emilien Macchi  wrote:
> [...]
>> Also, it's still time to propose topics, please go ahead and
>> contribute to the etherpad. We'll review the schedule before the PTG
>> (probably during our weekly meetings tomorrow and next week).
> [...]
>
> I forgot to remind folks that PTG is a very good time to discuss about
> blueprints, as we want to schedule together what we do in the next
> cycle.
> Which means, please be prepared and create blueprints / specs (even
> drafts) prior to the PTG, so we have some support that we can use for
> scheduling and discussions.
>
> Thanks a lot,
> --
> Emilien Macchi
-- 
Emilien Macchi

__
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] [vitrage] Collectd - to - Vitrage setup issues

[Waines, Greg]

Hi Ifat,
I actually have ‘debug = true’ in /etc/vitrage/vitrage.conf .
However I don’t see vitrage-graph.log anywhere ?
Where is it suppose to be ?   in /var/log/ ?
Greg.


root@devstack-vitrage:/# more /etc/vitrage/vitrage.conf



[DEFAULT]

debug = True

transport_url = rabbit://stackrabbit:admin@10.10.10.13:5672/



[oslo_policy]

policy_file = /etc/vitrage/policy.json



[service_credentials]

auth_url = http://10.10.10.13/identity

region_name = RegionOne

project_name = admin

password = admin

project_domain_id = default

user_domain_id = default

username = vitrage

auth_type = password



[datasources]

types = 
nova.host,nova.instance,nova.zone,static,static_physical,aodh,cinder.volume,neutron.network,neutron.port,doctor,collectd



[keystone_authtoken]

memcached_servers = 10.10.10.13:11211

signing_dir = /var/cache/vitrage

cafile = /opt/stack/data/ca-bundle.pem

project_domain_name = Default

project_name = admin

user_domain_name = Default

password = admin

username = vitrage

auth_url = http://10.10.10.13/identity

auth_type = password



[api]

pecan_debug = False



[collectd]

config_file = /etc/vitrage/collectd_conf.yaml



root@devstack-vitrage:/#


From: "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Date: Thursday, August 31, 2017 at 3:52 AM
To: Greg Waines , 
"openstack-dev@lists.openstack.org" 
Cc: "TAHHAN, MARYAM" 
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Greg,

Vitrage listens to Collectd notifications, not statistics.
Can you please turn on the debug option in /etc/vitrage/vitrage.conf (set 
“debug = true”), and send me the vitrage-graph.log?

Thanks,
Ifat.

From: "Waines, Greg" 
Date: Wednesday, 30 August 2017 at 22:17
To: "OpenStack Development Mailing List (not for usage questions)" 

Cc: "Afek, Ifat (Nokia - IL/Kfar Sava)" , "TAHHAN, MARYAM" 

Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Ifat,
thanks for the reply ... just got around to trying your suggestions.

This definitely helps ... I no longer get any errors on re-starting collectd or 
vitrage-graph.
i.e. it appears to load the collectd and updated vitrage conf files correctly 
now.

Now still don’t get any alarms in vitrage.
HOWEVER I suspect it may be my collectd setup now.
( WARNING I am NOT a collectd expert. ;) )

I suspect that the vitrage-collectd plugin only sends collectd NOTIFICATIONS or 
THRESHOLD Events to vitrage.
i.e. it likely does NOT send just statistic/status samples to vitrage.

I can see that collectd sampling is happening ... I have logfile and csv and 
rrd plugins running and samples are being captured in the specified directories 
/ files.

I tried to set threshold for CPU based on an example I had found on web.
See attached collectd.conf file .

BUT really not sure if the threshold configuration in my collectd.conf is 
correct or working ... is there a way to confirm this ?   ( any collectd 
experts out there ? )
OR
Is there an example collectd.conf that has notifications or thresholds 
(whatever vitrage needs) setup for something basic like CPU ?

Greg.




From: "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Monday, August 28, 2017 at 9:42 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Greg,

I’m less familiar with the collectd configuration and the events that it sends.

Regarding the collectd_conf.yaml, it is definitely missing. You should add a 
/etc/vitrage/collectd_conf.yaml file that looks like that:

collectd:
- collectd_host: 
   type: 
   name: 
- collectd_host: …


This file maps a Collectd resource to the corresponding resource in OpenStack. 
Only resources that are listed in this file will have their alarms imported to 
Vitrage.

Next, you should add a reference to this file in /etc/vitrage/vitrage.conf:

[collectd]
config_file = /etc/vitrage/collectd_conf.yaml

Then you should restart vitrage-graph.

Let me know if it helped,
Ifat.


From: "Waines, Greg" 
Date: Wednesday, 23 August 2017 at 21:19

I am trying to get collectd to report some alarms to vitrage in a devstack 
setup,

I am using a devstack created on a late version of ocata.
And my devstack with vitrage appears to be working ok otherwise;
e.g.  I can create VMs, and raise fake alarms using “vitrage event post 
-type=compute.host.down ...” or with “aodh alarm create ... 
resource_id=instance-uuid” ... and they get reported fine in vitrage.

UNFORTUNATELY not seeing anything in vitrage from collectd, and
  don’t believe I’m seeing anything even from collectd, 
for example from the syslog 

Re: [openstack-dev] Future Trove development

[Luke Browning]

Amrith, 

See answers to your questions below.

Cheers,
Luke 

>>
>> I understand that the Trove project will be going into maintenance mode
>> soon. I have a number of Trove related enhancements and bug fixes that 
I
>> would like to submit to the community, but I don't know if they would 
be
>> considered given that the project is going into maintenance mode. 
Please
>> elaborate on what you mean by maintenance mode.
>>
>
> ​See: https://review.openstack.org/#/c/488947/
>
> It is not a foregone conclusion that the project will go into 
maintenance
> mode. Thierry and I (for example) are not convinced that this is the 
right
> course of action, but if there are no offers to contribute to the 
project,
> it may be a decision by default.
>
> Do you subscribe to the OpenStack-dev mailing list​. Please also see
> http://openstack.markmail.org/thread/4p6gp263fei4mbru
>
> Finally, for a description of what maintenance mode means, please refer:
> https://governance.openstack.org/tc/reference/tags/status_ma
> intenance-mode.html
>
>>
>>
>> Would Trove be updated to support new OpenStack versions?
>>
> Would support be provided for Trove gate testing?
>>
> Would elements be enhanced to support Xenial and newer versions of
>> databases?
>>
> Is there a time limit associated with maintenance mode? For example, 
would
>> it remain in effect for a year or two after the new stuff is released?
>>
>> ​For the four questions above, I direct your attention to the 
definition
> of the maintenance-mode tag (https://governance.openstack.
> org/tc/reference/tags/status_maintenance-mode.html) and remind you that
> support for different versions from the community, for gate testing and 
for
> elements is dependent on people participating (and their employers 
allowing
> them to do this). At this point, I have no one who has stepped up to do
> this in any significant way. There are a couple of people from China 
Mobile
> who want to help but who are largely in the weeds, trying to fix this 
and
> that bug but have no idea what Trove is all about. IBM has a core 
reviewer
> on the project ​(Mariam is copied on this email). I am happy that she's
> able to devote what time she can to the project but absent competent
> reviewers, whether your changes ever get merged or not remains an
> interesting question. Since you will be contributing elements and 
propose
> to contribute a tool, will you be (or will IBM be) offering to support 
it?
>
>  Let me provide some back ground on my code changes, so you will have a
> better idea of what might be submitted in a patch.
>
>>
>> I have written a fully automated command that creates a virtual guest
>> image based on Ubuntu 16.04 containing a user specified version of a
>> database. The user's selection is validated against an internal list of
>> databases built into the tool. Once validated, the tool creates the 
image,
>> registers it with Glance, and then creates a Trove Datastore definition 
for
>> it. This is done in a single command invocation that typically takes 
about
>> 25 minutes to complete. For some of the databases, it takes 
considerably
>> longer (2 hours for mongodb) as I have to compile source code. The 
guest
>> image that is produced is complete from a Trove perspective. It 
includes
>> the Cloud specific trove-guestagent.conf file and SSH public keys for 
the
>> DBA and OpenStack controller nodes.
>>
>> ​What mechanism does it use to develop the image? is it 
diskimage-builder
> or some other?

Yes, diskimage-builder and Trove elements

>
>
> Is there something the matter with the existing tool that exists, it
> already works, it does more than just build an image, and it is already
> integrated in the gate. Why not use that?​

Is your question why don't we use trovestack?If so, we were looking 
for
something that was more streamlined with fewer dependencies.   The tool
would need to interface with the client's cloud.   Our tool is directed at
customers and IBM lab based services, neither of whom is expected to be
an OpenStack or Trove expert.

Beyond that, there is a difference in how are images our built.   First, 
we need
to control which versions of databases are built as opposed to letting the 
stack
determine that.ppc64le support in the database communities is at 
varying
stages.   In some cases, there are packages and in others there are not. 
In
addition, there are specific versions that we have tested and enhanced 
from
a performance perspective that we would like to include in our offering. 
 
The second part of this is related to the Trove Guest Agent.   We needed 
to
make a few code changes to support different versions and to fix bugs that
we have found.   Anyway, this led to us carrying patches in the tool, 
which is
part of a broader strategy to stage our database deliverables.   We would
like to add support for new databases over time.   To deliver these to our
clients without them having to re-install Trove on the controller side.
Fundamentally, 

Re: [openstack-dev] [TripleO][CI] FreeIPA Deployment

[Juan Antonio Osorio]

Something that just came to my mind: Another option would be to allocate an
extra IP Address for the undercloud, that would be dedicated to FreeIPA,
and that way we MAY be able to deploy the FreeIPA server in the undercloud.
If folks are OK with this I could experiment on this front. Maybe I could
try to run FreeIPA on a container [1] (which wasn't available when I
started working on this).

[1] https://hub.docker.com/r/freeipa/freeipa-server/

On Sat, Aug 26, 2017 at 2:52 AM, Emilien Macchi  wrote:

> On Sun, Aug 20, 2017 at 11:45 PM, Juan Antonio Osorio
>  wrote:
> > The second option seems like the most viable. Not sure how the TripleO
> > integration would go though. Care to elaborate on what you had in mind?
>
> Trying to reproduce what we did with ceph-ansible and use Mistral to
> deploy FreeIPA with an external deployment tool.
> Though I find the solution quite complex, maybe we can come-up with an
> easier approach this time?
> --
> Emilien Macchi
>
> __
> 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
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@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

Re: [openstack-dev] [nova][cinder][glance] What should be the response for invalid 'Accpet' header?

[Sean McGinnis]

Hey Niraj,

That does seem to be incorrect behavior on the services side. It would 
be good to have a bug
filed to track it. For now you could open one and flag each project as 
being affected. We may
find that it requires a change in each project, or it may end up being a 
common oslo change.
Either way, a bug will allow us to capture findings and make sure it 
gets resolved.


https://bugs.launchpad.net/cinder/+filebug

Thanks,

Sean


On 08/31/2017 05:10 AM, Singh, Niraj wrote:


Hi Devs,

As of now, when user passes 'Accept' header in request other than JSON 
and XML using curl command then it returns 200 OK response with json 
format data.


In api-ref guide [1] also it's not clearly mentioned about what 
response it should return if invalid value for 'Accept' header is 
specified. IMO instead of 'HTTP 200 OK' it should return 'HTTP 406 Not 
Acceptable' response.


I have checked this behavior for nova, cinder and glance and for all 
of these it is returning HTTP 200 OK which is invalid.


Please let me know your opinion for the same.

Steps to reproduce:

Request:

curl -g -i -X GET 
http://controller/volume/v2/c72e66cc4f1341f381e0c2eb7b28b443/volumes/detail 
-H "User-Agent: python-cinderclient" -H "Accept: application/abc" -H 
"X-Auth-Token: cd85aff745ce4dc0a04f686b52cf7e4f"


Response:

HTTP/1.1 200 OK

Date: Thu, 31 Aug 2017 07:12:18 GMT

Server: Apache/2.4.18 (Ubuntu)

x-compute-request-id: req-ab48db9d-f869-4eb4-95f9-ef8e90a918df

Content-Type: application/json

Content-Length: 2681

x-openstack-request-id: req-ab48db9d-f869-4eb4-95f9-ef8e90a918df

Connection: close

[1] 
https://developer.openstack.org/api-ref/block-storage/v2/#list-volumes-with-details 



Thank you,

Niraj Singh


__
Disclaimer: This email and any attachments are sent in strictest 
confidence

for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then 
delete
and destroy this email and any attachments without any further use, 
copying

or forwarding.


__
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

Re: [openstack-dev] [nova] Should we add the 'force' option to the cold migrate API too?

[Sylvain Bauza]

On Wed, Aug 30, 2017 at 5:09 PM, Matt Riedemann  wrote:

> Given the recent bugs [1][2] due to the force flag in the live migrate and
> evacuate APIs related to Placement, and some other long standing bugs about
> bypassing the scheduler [3], I don't think we should add the force option
> to the cold migrate API, as (re-)proposed in Takashi's cold migrate spec
> here [4].
>
> I'm fine with being able to specify a host during cold migrate/resize, but
> I think the specified host should be validated by the scheduler (and
> placement) so that the instance can actually move to that specified
> destination host.
>
> Since we've built more logic into the scheduler in Pike for integration
> with Placement, bypassing that gets us into maintenance issues with having
> to duplicate code throughout conductor and just in general, seems like a
> bad idea to force a host and bypass the scheduler and potentially break the
> instance. Not to mention the complicated logic of passing the host through
> from the API to conductor to the scheduler is it's own maintenance problem
> [5].
>
> Looking back at when the force flag was added to the APIs, it was from
> this spec [6]. Reading that, before that microversion if a host was
> specified we'd bypass the scheduler, so the force flag was really just
> there for backward compatibility


Indeed. That said, I've heard some ops wanting to migrate instances to
computes where resources were not possibly enough to accept the instance
but where it's preferred to have performance problems than just stopped
instances.
If you think about the move operations using the force flag (evacuate and
live-migrate), those were used by operators when they had a problem with a
compute node and they wanted to *evacuate* very quickly instances.




> I guess in case you wanted the option to break the instance or your
> deployment. :) Otherwise after that microversion if you specify a host but
> not the force flag, then we validate the specified host via the scheduler
> first. Given this, and the fact we don't have any backward compatibility to
> maintain with specifying a host for cold migrate, I don't think we need to
> add a force flag for it, unless people really love that option on the live
> migrate and evacuate APIs, but it just seems overly dangerous to me.
>

While I understand operators wanting to *evacuate* instances (or rebuilding
them by using the evacuation API) in case they see problems with hosts, I
don't see why we should need to have a "force" flag for a cold migration if
you're passing a target.
Say :
 - either your compute node is down and then you need to recreate your
customers' instances very quickly : then you call "nova evacuate".
 - or your compute node is still alive but you want to migrate quickly
without telling your customers : then you use "nova live-migrate".

I don't see cases where operators (because passing a target requires you to
be an admin)  would like to cold migrate instances for their customers
without communicating them a specific timeline for the move operation and
so quickly that it would require to use a force flag to bypass the
scheduler.
Maybe I'm wrong but I'm fine with asking Takashi to not add the force flag
in his implementation for the cold migration API and wait for people
wanting to have that flag to propose a specific specification that would
describe the use-case.



>
> Finally, if one is going to make the argument, "but this would be
> consistent with the live migrate and evacuate APIs", I can also point out
> that we don't allow you to specify a host (forced or not) during unshelve
> of a shelved offloaded instance - which is basically a move (new build on a
> new host chosen by the scheduler). I'm not advocating that we make unshelve
> more complicated though, because that's already broken in several known
> ways [7][8][9].
>

Well, we don't have consistent APIs anyway. If you think about all the move
operations plus the boot request itself, each of them is *already* very
different from the other from an API perspective. Yay.



>
> [1] https://bugs.launchpad.net/nova/+bug/1712008
> [2] https://bugs.launchpad.net/nova/+bug/1713786
> [3] https://bugs.launchpad.net/nova/+bug/1427772
> [4] https://review.openstack.org/#/c/489031/
> [5] http://lists.openstack.org/pipermail/openstack-dev/2017-Augu
> st/121342.html
> [6] https://specs.openstack.org/openstack/nova-specs/specs/mitak
> a/implemented/check-destination-on-migrations.html
> [7] https://bugs.launchpad.net/nova/+bug/1675791
> [8] https://bugs.launchpad.net/nova/+bug/1627694
> [9] https://bugs.launchpad.net/nova/+bug/1547142
>
> --
>
> Thanks,
>
> Matt
>
> __
> 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] [cinder] [ironic] PTG cross-platform meetup possibility

[Ivan Kolodyazhny]

Hi team,

Monday at 4pm sounds great for me. I hope, it will work well both for
Cinder and Kolla teams.

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Thu, Aug 31, 2017 at 4:25 PM, Richard Wellum 
wrote:

> Hi,
>
> How does Monday at 4pm sound? Kolla already has a cross-platform
> discussion with Triple-O at 2pm, so this would dovetail nicely.
>
> Thanks,
>
> ||Rich
>
> On Wed, Aug 30, 2017 at 2:48 PM Ivan Kolodyazhny  wrote:
>
>> Hi team,
>>
>> I'm interested in cinder containerization too. It would be great if we
>> can schedule our meetup after 3pm or even 4pm, It will increase my chances
>> to attend it.
>>
>> Thanks in advance.
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>> On Wed, Aug 30, 2017 at 4:23 PM, Dmitry Tantsur 
>> wrote:
>>
>>> Hi!
>>>
>>> I'm all for it. Monday sounds okay to me, though I'll have to manage
>>> some conflicts, of course.
>>>
>>>
>>> On 08/29/2017 05:56 PM, Richard Wellum wrote:
>>>
 Hi Folks,

 Would there be some interest from Cinder and Ironic (and others of
 course) team members to have a quick session at the PTG with the Kolla team
 on the latest developments in Kolla (like the new kolla-ansible devmode for
 example)?

 Also it would give the Kolla team an opportunity to hear about your
 teams interest and experiences in containerization and what you need from
 Kolla going forward.

 I'm thinking an hour or two on Monday afternoon, the first day of the
 PTG?

 Thanks,

 ||Rich


 
 __
 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 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 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] Gate is broken - Do not approve any patch until further notice

[Jiří Stránský]

On 30.8.2017 06:54, Emilien Macchi wrote:

On Tue, Aug 29, 2017 at 4:17 PM, Emilien Macchi  wrote:

We are currently dealing with 4 issues and until they are fix, please
do not approve any patch. We want to keep the gate clear to merge the
fixes for the 4 problems first.

1) devstack-gate broke us because we use it as a library (bad)
https://bugs.launchpad.net/tripleo/+bug/1713868

2) https://review.openstack.org/#/c/474578/ broke us and we're
reverting it https://bugs.launchpad.net/tripleo/+bug/1713832

3) We shouldn't build images on multinode jobs
https://bugs.launchpad.net/tripleo/+bug/1713167

4) We should use pip instead of git for delorean
https://bugs.launchpad.net/tripleo/+bug/1708832


Until further notice from Alex or myself, please do not approve any patch.


The 4 problems have been mitigated.
You can now proceed to normal review.

Please do not recheck a patch without an elastic-recheck comment, we
need to track all issues related to CI from now.
Paul Belanger has been doing extremely useful work to help us, now
let's use elastic-recheck more and stop blind rechecks.
All known issues are in http://status.openstack.org/elastic-recheck/
If one is missing, you're welcome to contribute by sending a patch to
elastic-recheck. Example with https://review.openstack.org/#/c/498954/


Posted DLRN build failure query [1]. I used the Kibana interface [2] to 
test-drive the query.


I wanted to tackle other bugs but it seems we don't have enough info in 
console.html. I wonder if it's realistic to start pulling some logs 
maybe from undercloud/home/jenkins dir into logstash? That's where OOOQ 
puts the most of its more detailed output, so having that might allow us 
to produce more specific queries.


Thanks,

Jirka

[1] https://review.openstack.org/499532
[2] http://logstash.openstack.org



I've restored all patches that were killed from the gate and did
recheck already, hopefully we can get some merges and finish this
release.

Thanks Paul and all Infra for their consistent help!




__
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] [cinder] [ironic] PTG cross-platform meetup possibility

[Richard Wellum]

Hi,

How does Monday at 4pm sound? Kolla already has a cross-platform discussion
with Triple-O at 2pm, so this would dovetail nicely.

Thanks,

||Rich

On Wed, Aug 30, 2017 at 2:48 PM Ivan Kolodyazhny  wrote:

> Hi team,
>
> I'm interested in cinder containerization too. It would be great if we can
> schedule our meetup after 3pm or even 4pm, It will increase my chances to
> attend it.
>
> Thanks in advance.
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Wed, Aug 30, 2017 at 4:23 PM, Dmitry Tantsur 
> wrote:
>
>> Hi!
>>
>> I'm all for it. Monday sounds okay to me, though I'll have to manage some
>> conflicts, of course.
>>
>>
>> On 08/29/2017 05:56 PM, Richard Wellum wrote:
>>
>>> Hi Folks,
>>>
>>> Would there be some interest from Cinder and Ironic (and others of
>>> course) team members to have a quick session at the PTG with the Kolla team
>>> on the latest developments in Kolla (like the new kolla-ansible devmode for
>>> example)?
>>>
>>> Also it would give the Kolla team an opportunity to hear about your
>>> teams interest and experiences in containerization and what you need from
>>> Kolla going forward.
>>>
>>> I'm thinking an hour or two on Monday afternoon, the first day of the
>>> PTG?
>>>
>>> Thanks,
>>>
>>> ||Rich
>>>
>>>
>>>
>>> __
>>> 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 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-dev] [docs] adopting whereto as official tool maintained by docs team

[Doug Hellmann]

As part of the work for the doc-migration project this cycle, we have
expanded the way we use redirects to allow project teams to have
htaccess files in tree. Since redirects can be tricky to test without a
live server, I put together a tool that we can use in CI to do some
minimal validation. It takes as input an htaccess file and another file
of test values, and reports if any test path does not redirect in the
expected way or if any redirect rule is untested. I'm sure we can
improve on it from there.

The tool is already being used to test the htaccess file in
openstack-manuals. We need to add it to the requirements list before
we can use it in other builds that follow the requirements management
processes[1].

I would also like the docs team to take up maintenance of the tool so
I'm not doing it on my own [2]. If anyone has any concerns about doing
that, please let me know.

Doug

[1] https://review.openstack.org/499584
[2] https://review.openstack.org/499581

__
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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Jeremy Stanley]

On 2017-08-31 15:21:19 +1000 (+1000), Tony Breeds wrote:
[...]
> I assume it's infra that needs to do the actual unpublish?

We're the ones with the most consistent access to all of them,
though in a majority of cases there's at least one other account
with sufficient access to do the same (it just tends to vary by team
and origination timeframe). So, yes, probably easiest to give the
Infra team a list once it's been confirmed.
-- 
Jeremy Stanley


signature.asc
Description: 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] [docs] Updating the docs team mission statement

[Alexandra Settle]

I have updated the mission statement as per Thierry’s suggestion (thank you, I 
liked that a lot!)

See the review here: https://review.openstack.org/#/c/499556/ 

It is currently in WIP. Petr and I agree that the best place to discuss this 
will be at the PTG.

On 8/22/17, 5:34 PM, "Doug Hellmann"  wrote:

Excerpts from Jay S Bryant's message of 2017-08-22 11:06:37 -0500:
> 
> On 8/22/2017 7:30 AM, Doug Hellmann wrote:
> > Excerpts from Doug Hellmann's message of 2017-08-08 08:11:25 -0400:
> >> Excerpts from Thierry Carrez's message of 2017-08-08 12:28:58 +0200:
> >>> Petr Kovar wrote:
>  Hi all,
> 
>  With the core docs suite moving from openstack-manuals to individual
>  project repos as per
>  
http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html,
>  it's also time to update the docs team mission statement from
>  
https://governance.openstack.org/tc/reference/projects/documentation.html.
> 
>  What are everybody's thoughts on what should the new mission 
statement
>  say now that most OpenStack docs maintenance is in the hands of 
project
>  teams?
> 
>  One idea is for the docs team to act as a focused group of editors 
and
>  maintain a common set of guidelines, recommended practices (style
>  guidelines come to mind, for instance), and requirements (such as a 
common
>  docs and publishing structure shared across projects).
> >>> I would say something like:
> >>>
> >>> The docs team provides guidance, assistance, tooling, and style guides
> >>> enabling OpenStack project teams to produce consistent, accurate, and
> >>> high-quality documentation.
> >>>
> >> Thanks for starting this thread, Petr.
> >>
> >> To make it easier to compare, here's the current mission statement:
> >>
> >>Provide documentation for core OpenStack projects to promote
> >>OpenStack.  Develop and maintain tools and processes to ensure
> >>quality, accurate documentation. Treat documentation like OpenStack
> >>code.
> >>
> >> Thierry's suggestion highlights some of the changes I see coming
> >> for the docs team. I would like to hear from some of the other team
> >> members about what they think about that.
> >>
> >> Doug
> > This thread died out, but I think it's important that we make some
> > progress on the discussion before the PTG because the outcome is
> > going to influence the work we do there.
> >
> > One way we could approach it is to make a list of all of the things
> > that the team is currently doing (or has been doing, up to Pike)
> > and then review that list to consider which of those things, if the
> > team was not already doing them, you would be willing to start doing
> > today.  That should establish a pattern for the types of tasks and
> > initiatives the team thinks it can manage, and help us focus the
> > mission statement.
> >
> > So, what does the docs team "do" or "make" today?
> >
> > Doug
> >
> > 
__
> > 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
> Doug,
> 
> I think this is a good idea.  Rather than writing a mission statement 
> and try to get what we do to fit it, we should look at what everyone is 
> doing and can do and then work to craft the statement from that.
> 
> One important part in the process, however, would be to look at how that 
> compares to what was previously being done and make sure that there 
> aren't gaps.  It is an opportunity to make sure we don't let anything 
> slip through the cracks.
> 
> Jay
> 

It's also an opportunity to identify things that should be dropped, or
moved to another team. But yes, let's start by understanding what's
actually happening today.

Doug

__
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-dev] removing screen from devstack - RSN

[Sean Dague]

The work that started last cycle to make devstack only have a single
execution mode, that was the same between automated QA and local, is
nearing it's completion.

https://review.openstack.org/#/c/499186/ is the patch that will remove
screen from devstack (which was only left as a fall back for things like
grenade during Pike). Tests are currently passing on all the gating jobs
for it. And experimental looks mostly useful.

The intent is to merge this in about a week (right before PTG). So, if
you have a complicated devstack plugin you think might be affected by
this (and were previously making jobs pretend to be grenade to keep
screen running), now is the time to run tests against this patch and see
where things stand.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [openstack][ANNOUNCE][Stackube] v1.0 beta released

[Harry Zhang]

Hi all,

We are excited to announce Stackube project is v1.0 beta released!

Stackube blends Kubernetes and OpenStack to build Container-native IaaS
[1]. Stackube uses Kubernetes, instead of Nova, as the compute fabric
controller, to provision containers as the compute instance, along with
other OpenStack services (e.g. Cinder, Neutron).  It naturally supports
multiple container runtime technologies, e.g. Docker, Hyper, and offers
built-in soft / hard multi-tenancy (depending on the container runtime
used).

Stackube = Kubernetes + Keystone + Neutron + Cinder + Baremetal

To learn more:
- Project Scope: http://stackube.readthedocs.io/en/latest/stackube_scope_
clarification.html
- Blueprint: https://launchpad.net/stackube
- Wiki: https://wiki.openstack.org/wiki/Stackube
- Code: https://github.com/openstack/stackube
- Docs: http://stackube.readthedocs.io/en/latest/index.html


Happy hacking,
The Stackube Team

[1] For example: Azure ACI https://azure.microsoft.com/
en-us/services/container-instances/ , and Hyper https://hyper.sh
__
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] [nova][cinder][glance] What should be the response for invalid 'Accpet' header?

[Singh, Niraj]

Hi Devs,

As of now, when user passes 'Accept' header in request other than JSON and XML 
using curl command then it returns 200 OK response with json format data.
In api-ref guide [1] also it's not clearly mentioned about what response it 
should return if invalid value for 'Accept' header is specified. IMO instead of 
'HTTP 200 OK' it should return 'HTTP 406 Not Acceptable' response.

I have checked this behavior for nova, cinder and glance and for all of these 
it is returning HTTP 200 OK which is invalid.
Please let me know your opinion for the same.

Steps to reproduce:

Request:
curl -g -i -X GET 
http://controller/volume/v2/c72e66cc4f1341f381e0c2eb7b28b443/volumes/detail -H 
"User-Agent: python-cinderclient" -H "Accept: application/abc" -H 
"X-Auth-Token: cd85aff745ce4dc0a04f686b52cf7e4f"


Response:
HTTP/1.1 200 OK
Date: Thu, 31 Aug 2017 07:12:18 GMT
Server: Apache/2.4.18 (Ubuntu)
x-compute-request-id: req-ab48db9d-f869-4eb4-95f9-ef8e90a918df
Content-Type: application/json
Content-Length: 2681
x-openstack-request-id: req-ab48db9d-f869-4eb4-95f9-ef8e90a918df
Connection: close

[1] 
https://developer.openstack.org/api-ref/block-storage/v2/#list-volumes-with-details


Thank you,
Niraj Singh


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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] Gate is broken - Do not approve any patch until further notice

[Michele Baldessari]

On Thu, Aug 31, 2017 at 10:55:34AM +0200, Bogdan Dobrelya wrote:
> On 31.08.2017 10:33, Michele Baldessari wrote:
> > On Wed, Aug 30, 2017 at 11:31:14AM +0200, Bogdan Dobrelya wrote:
> >> On 30.08.2017 6:54, Emilien Macchi wrote:
> >>> On Tue, Aug 29, 2017 at 4:17 PM, Emilien Macchi  
> >>> wrote:
>  We are currently dealing with 4 issues and until they are fix, please
>  do not approve any patch. We want to keep the gate clear to merge the
>  fixes for the 4 problems first.
> 
>  1) devstack-gate broke us because we use it as a library (bad)
>  https://bugs.launchpad.net/tripleo/+bug/1713868
> 
>  2) https://review.openstack.org/#/c/474578/ broke us and we're
>  reverting it https://bugs.launchpad.net/tripleo/+bug/1713832
> 
>  3) We shouldn't build images on multinode jobs
>  https://bugs.launchpad.net/tripleo/+bug/1713167
> 
>  4) We should use pip instead of git for delorean
>  https://bugs.launchpad.net/tripleo/+bug/1708832
> 
> 
>  Until further notice from Alex or myself, please do not approve any 
>  patch.
> >>>
> >>> The 4 problems have been mitigated.
> >>> You can now proceed to normal review.
> >>>
> >>> Please do not recheck a patch without an elastic-recheck comment, we
> >>> need to track all issues related to CI from now.
> >>> Paul Belanger has been doing extremely useful work to help us, now
> >>> let's use elastic-recheck more and stop blind rechecks.
> >>> All known issues are in http://status.openstack.org/elastic-recheck/
> >>> If one is missing, you're welcome to contribute by sending a patch to
> >>> elastic-recheck. Example with https://review.openstack.org/#/c/498954/
> >>
> >> That's a great example! Let me follow up on that and share my beginner's
> >> experience as well.
> >>
> >> Let's help with improving elastic-recheck queries to identify those
> >> unknown or new failures, this is really important. This also trains
> >> domain knowledge for particular areas, either openstack or *-infra, or
> >> tripleo specific.
> >>
> >> As beginners, we could start with watching for failing tripleo-ci
> >> periodic [0],[1] (available as RSS feeds) and gate jobs without e-r
> >> comments, also from that page [2].
> >>
> >> Then fetching the logs locally with tools like getthelogs [3], or
> >> looking into the logs.openstack.org directly, if advanced beginners wish 
> >> so.
> >>
> >> Finally, identifying discovered (just do some grep, like I do with my
> >> tool [4]) errorish patterns and helping with root cause analysis. And,
> >> ideally, submitting new e-r queries (see also [5]) and corresponding lp
> >> bugs. And absolutely ideally, help with addressing those as well. This
> >> might be hard though as we may be not experts in some of the areas. Some
> >> of the error messages would literally mean nothing to us. For me, the
> >> most  But as the best effort, we could invite the right persons to
> >> look into that, or at least ask folks on #tripleo or #openstack-infra.
> >>
> >> [0]
> >> http://status.openstack.org/openstack-health/#/g/project/openstack-infra~2Ftripleo-ci
> >> [1]
> >> http://status.openstack.org/openstack-health/#/g/project/openstack~2Ftripleo-quickstart
> >> [2] http://status.openstack.org/elastic-recheck/data/others.html
> >> [3] https://review.openstack.org/#/c/492178/
> >> [4] 
> >> https://github.com/bogdando/fuel-log-parse/blob/master/fuel-log-parse.sh
> >> [5]
> >> https://docs.openstack.org/infra/elastic-recheck/readme.html#running-queries-locally
> > 
> > Thanks Bogdan, this is very helpful. Do we have some docs/readme on [5].
> > It is failing here with a bunch of 404, so I presume I am missing a
> > proper elasticRecheck.conf file or some other settings?
> > 
> > I was basically trying to validate https://review.openstack.org/#/c/499516/ 
> > before
> > submitting it.
> 
> There is install docs [0] :)
> Although for my case, the following worked as well (given
> VENV=${HOME}/.virtualenvs):
> 
> $ mkvirtualenv erqtest
> $ pip install -r requirements.txt
> $ python setup.py develop
> $ ${VENV}/erqtest/bin/elastic-recheck-query queries/foo.yaml
> 
> [0] https://docs.openstack.org/infra/elastic-recheck/installation.html

:) I had gotten that far.

the usual python setup.py build + install in a new venv leaves me still with 
404s all
over:
$ elastic-recheck-query queries/1713832.yaml 
2017-08-31 11:33:04  DEBUG[urllib3.util.retry] Converted retries value: 
False -> Retry(total=False, connect=None, read=None, redirect=0)
2017-08-31 11:33:04  WARNING  [elasticsearch  ] GET 
/logstash-2017.08.31/_status [status:404 request:0.567s]
2017-08-31 11:33:04  DEBUG[elasticsearch  ] > 
2017-08-31 11:33:04  DEBUG[elasticsearch  ] <   404 Not Found 

Not Found The requested URL /logstash-2017.08.31/_status was not 
found on this server. 
Apache/2.4.7 (Ubuntu) Server at logstash.openstack.org Port 
80 

Whereas the develop command fails me on:
Processing dependencies 

Re: [openstack-dev] [tripleo] Gate is broken - Do not approve any patch until further notice

[Bogdan Dobrelya]

On 31.08.2017 10:33, Michele Baldessari wrote:
> On Wed, Aug 30, 2017 at 11:31:14AM +0200, Bogdan Dobrelya wrote:
>> On 30.08.2017 6:54, Emilien Macchi wrote:
>>> On Tue, Aug 29, 2017 at 4:17 PM, Emilien Macchi  wrote:
 We are currently dealing with 4 issues and until they are fix, please
 do not approve any patch. We want to keep the gate clear to merge the
 fixes for the 4 problems first.

 1) devstack-gate broke us because we use it as a library (bad)
 https://bugs.launchpad.net/tripleo/+bug/1713868

 2) https://review.openstack.org/#/c/474578/ broke us and we're
 reverting it https://bugs.launchpad.net/tripleo/+bug/1713832

 3) We shouldn't build images on multinode jobs
 https://bugs.launchpad.net/tripleo/+bug/1713167

 4) We should use pip instead of git for delorean
 https://bugs.launchpad.net/tripleo/+bug/1708832


 Until further notice from Alex or myself, please do not approve any patch.
>>>
>>> The 4 problems have been mitigated.
>>> You can now proceed to normal review.
>>>
>>> Please do not recheck a patch without an elastic-recheck comment, we
>>> need to track all issues related to CI from now.
>>> Paul Belanger has been doing extremely useful work to help us, now
>>> let's use elastic-recheck more and stop blind rechecks.
>>> All known issues are in http://status.openstack.org/elastic-recheck/
>>> If one is missing, you're welcome to contribute by sending a patch to
>>> elastic-recheck. Example with https://review.openstack.org/#/c/498954/
>>
>> That's a great example! Let me follow up on that and share my beginner's
>> experience as well.
>>
>> Let's help with improving elastic-recheck queries to identify those
>> unknown or new failures, this is really important. This also trains
>> domain knowledge for particular areas, either openstack or *-infra, or
>> tripleo specific.
>>
>> As beginners, we could start with watching for failing tripleo-ci
>> periodic [0],[1] (available as RSS feeds) and gate jobs without e-r
>> comments, also from that page [2].
>>
>> Then fetching the logs locally with tools like getthelogs [3], or
>> looking into the logs.openstack.org directly, if advanced beginners wish so.
>>
>> Finally, identifying discovered (just do some grep, like I do with my
>> tool [4]) errorish patterns and helping with root cause analysis. And,
>> ideally, submitting new e-r queries (see also [5]) and corresponding lp
>> bugs. And absolutely ideally, help with addressing those as well. This
>> might be hard though as we may be not experts in some of the areas. Some
>> of the error messages would literally mean nothing to us. For me, the
>> most  But as the best effort, we could invite the right persons to
>> look into that, or at least ask folks on #tripleo or #openstack-infra.
>>
>> [0]
>> http://status.openstack.org/openstack-health/#/g/project/openstack-infra~2Ftripleo-ci
>> [1]
>> http://status.openstack.org/openstack-health/#/g/project/openstack~2Ftripleo-quickstart
>> [2] http://status.openstack.org/elastic-recheck/data/others.html
>> [3] https://review.openstack.org/#/c/492178/
>> [4] https://github.com/bogdando/fuel-log-parse/blob/master/fuel-log-parse.sh
>> [5]
>> https://docs.openstack.org/infra/elastic-recheck/readme.html#running-queries-locally
> 
> Thanks Bogdan, this is very helpful. Do we have some docs/readme on [5].
> It is failing here with a bunch of 404, so I presume I am missing a
> proper elasticRecheck.conf file or some other settings?
> 
> I was basically trying to validate https://review.openstack.org/#/c/499516/ 
> before
> submitting it.

There is install docs [0] :)
Although for my case, the following worked as well (given
VENV=${HOME}/.virtualenvs):

$ mkvirtualenv erqtest
$ pip install -r requirements.txt
$ python setup.py develop
$ ${VENV}/erqtest/bin/elastic-recheck-query queries/foo.yaml

[0] https://docs.openstack.org/infra/elastic-recheck/installation.html

> 
> Thanks,
> Michele
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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] Gate is broken - Do not approve any patch until further notice

[Michele Baldessari]

On Wed, Aug 30, 2017 at 11:31:14AM +0200, Bogdan Dobrelya wrote:
> On 30.08.2017 6:54, Emilien Macchi wrote:
> > On Tue, Aug 29, 2017 at 4:17 PM, Emilien Macchi  wrote:
> >> We are currently dealing with 4 issues and until they are fix, please
> >> do not approve any patch. We want to keep the gate clear to merge the
> >> fixes for the 4 problems first.
> >>
> >> 1) devstack-gate broke us because we use it as a library (bad)
> >> https://bugs.launchpad.net/tripleo/+bug/1713868
> >>
> >> 2) https://review.openstack.org/#/c/474578/ broke us and we're
> >> reverting it https://bugs.launchpad.net/tripleo/+bug/1713832
> >>
> >> 3) We shouldn't build images on multinode jobs
> >> https://bugs.launchpad.net/tripleo/+bug/1713167
> >>
> >> 4) We should use pip instead of git for delorean
> >> https://bugs.launchpad.net/tripleo/+bug/1708832
> >>
> >>
> >> Until further notice from Alex or myself, please do not approve any patch.
> > 
> > The 4 problems have been mitigated.
> > You can now proceed to normal review.
> > 
> > Please do not recheck a patch without an elastic-recheck comment, we
> > need to track all issues related to CI from now.
> > Paul Belanger has been doing extremely useful work to help us, now
> > let's use elastic-recheck more and stop blind rechecks.
> > All known issues are in http://status.openstack.org/elastic-recheck/
> > If one is missing, you're welcome to contribute by sending a patch to
> > elastic-recheck. Example with https://review.openstack.org/#/c/498954/
> 
> That's a great example! Let me follow up on that and share my beginner's
> experience as well.
> 
> Let's help with improving elastic-recheck queries to identify those
> unknown or new failures, this is really important. This also trains
> domain knowledge for particular areas, either openstack or *-infra, or
> tripleo specific.
> 
> As beginners, we could start with watching for failing tripleo-ci
> periodic [0],[1] (available as RSS feeds) and gate jobs without e-r
> comments, also from that page [2].
> 
> Then fetching the logs locally with tools like getthelogs [3], or
> looking into the logs.openstack.org directly, if advanced beginners wish so.
> 
> Finally, identifying discovered (just do some grep, like I do with my
> tool [4]) errorish patterns and helping with root cause analysis. And,
> ideally, submitting new e-r queries (see also [5]) and corresponding lp
> bugs. And absolutely ideally, help with addressing those as well. This
> might be hard though as we may be not experts in some of the areas. Some
> of the error messages would literally mean nothing to us. For me, the
> most  But as the best effort, we could invite the right persons to
> look into that, or at least ask folks on #tripleo or #openstack-infra.
> 
> [0]
> http://status.openstack.org/openstack-health/#/g/project/openstack-infra~2Ftripleo-ci
> [1]
> http://status.openstack.org/openstack-health/#/g/project/openstack~2Ftripleo-quickstart
> [2] http://status.openstack.org/elastic-recheck/data/others.html
> [3] https://review.openstack.org/#/c/492178/
> [4] https://github.com/bogdando/fuel-log-parse/blob/master/fuel-log-parse.sh
> [5]
> https://docs.openstack.org/infra/elastic-recheck/readme.html#running-queries-locally

Thanks Bogdan, this is very helpful. Do we have some docs/readme on [5].
It is failing here with a bunch of 404, so I presume I am missing a
proper elasticRecheck.conf file or some other settings?

I was basically trying to validate https://review.openstack.org/#/c/499516/ 
before
submitting it.

Thanks,
Michele
-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D

__
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] [vitrage] Collectd - to - Vitrage setup issues

[Mytnyk, VolodymyrX]

Hi Greg,

First of all, let’s make sure that the notification is 
generated by collectd. To do so, create a simple collectd python plugin to dump 
notifications into /tmp/python-notifications.dump' file:

cat > /etc/collectd_notification_dump.py <
  ModulePath "/etc"
  LogTraces true
  Interactive false
  Import "collectd_notification_dump"


Restart collectd. All collectd notifications will be dump in 
/tmp/python-notifications.dump' file. E.g. if the collectd `threshold` plugin 
generate the notification, it will appear in the dump file. If not, there may 
be a problem with configuring the threshold plugin.

Thanks and Regards,
Volodymyr

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Wednesday, August 30, 2017 10:18 PM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: Tahhan, Maryam 
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Ifat,
thanks for the reply ... just got around to trying your suggestions.

This definitely helps ... I no longer get any errors on re-starting collectd or 
vitrage-graph.
i.e. it appears to load the collectd and updated vitrage conf files correctly 
now.

Now still don’t get any alarms in vitrage.
HOWEVER I suspect it may be my collectd setup now.
( WARNING I am NOT a collectd expert. ;) )

I suspect that the vitrage-collectd plugin only sends collectd NOTIFICATIONS or 
THRESHOLD Events to vitrage.
i.e. it likely does NOT send just statistic/status samples to vitrage.

I can see that collectd sampling is happening ... I have logfile and csv and 
rrd plugins running and samples are being captured in the specified directories 
/ files.

I tried to set threshold for CPU based on an example I had found on web.
See attached collectd.conf file .

BUT really not sure if the threshold configuration in my collectd.conf is 
correct or working ... is there a way to confirm this ?   ( any collectd 
experts out there ? )
OR
Is there an example collectd.conf that has notifications or thresholds 
(whatever vitrage needs) setup for something basic like CPU ?

Greg.




From: "Afek, Ifat (Nokia - IL/Kfar Sava)" 
>
Reply-To: 
"openstack-dev@lists.openstack.org" 
>
Date: Monday, August 28, 2017 at 9:42 AM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Greg,

I’m less familiar with the collectd configuration and the events that it sends.

Regarding the collectd_conf.yaml, it is definitely missing. You should add a 
/etc/vitrage/collectd_conf.yaml file that looks like that:

collectd:
- collectd_host: 
   type: 
   name: 
- collectd_host: …


This file maps a Collectd resource to the corresponding resource in OpenStack. 
Only resources that are listed in this file will have their alarms imported to 
Vitrage.

Next, you should add a reference to this file in /etc/vitrage/vitrage.conf:

[collectd]
config_file = /etc/vitrage/collectd_conf.yaml

Then you should restart vitrage-graph.

Let me know if it helped,
Ifat.


From: "Waines, Greg" 
>
Date: Wednesday, 23 August 2017 at 21:19

I am trying to get collectd to report some alarms to vitrage in a devstack 
setup,

I am using a devstack created on a late version of ocata.
And my devstack with vitrage appears to be working ok otherwise;
e.g.  I can create VMs, and raise fake alarms using “vitrage event post 
-type=compute.host.down ...” or with “aodh alarm create ... 
resource_id=instance-uuid” ... and they get reported fine in vitrage.

UNFORTUNATELY not seeing anything in vitrage from collectd, and
  don’t believe I’m seeing anything even from collectd, 
for example from the syslog output plugin.

I’ve attached the following files:   ( not sure if these get distributed on 
mailing list )
· /etc/collectd/collectd.conf   <-- do these look ok ?
· /etc/vitrage/vitrage.conf  <-- do these look ok ?
· /var/log/syslog ... around the time when I updated 
collectd.conf and vitrage.conf and restarted collectd and vitrage-graph
oQUESTIONS
•  NOTE THE FOLLOWING ERRORS IN THE SYSLOG FILE ... where do I get the 
collectd_conf.yaml file from ?  Can’t see it in the devstack files for vitrage.
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.039 25962 ERROR vitrage.utils.file [-] File doesn't exist: 
/etc/vitrage/collectd_conf.yaml.
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.040 25962 ERROR vitrage.datasources.collectd.driver [-] failed in init 
'NoneType' object has no 

Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Greg,

Vitrage listens to Collectd notifications, not statistics.
Can you please turn on the debug option in /etc/vitrage/vitrage.conf (set 
“debug = true”), and send me the vitrage-graph.log?

Thanks,
Ifat.

From: "Waines, Greg" 
Date: Wednesday, 30 August 2017 at 22:17
To: "OpenStack Development Mailing List (not for usage questions)" 

Cc: "Afek, Ifat (Nokia - IL/Kfar Sava)" , "TAHHAN, MARYAM" 

Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Ifat,
thanks for the reply ... just got around to trying your suggestions.

This definitely helps ... I no longer get any errors on re-starting collectd or 
vitrage-graph.
i.e. it appears to load the collectd and updated vitrage conf files correctly 
now.

Now still don’t get any alarms in vitrage.
HOWEVER I suspect it may be my collectd setup now.
( WARNING I am NOT a collectd expert. ;) )

I suspect that the vitrage-collectd plugin only sends collectd NOTIFICATIONS or 
THRESHOLD Events to vitrage.
i.e. it likely does NOT send just statistic/status samples to vitrage.

I can see that collectd sampling is happening ... I have logfile and csv and 
rrd plugins running and samples are being captured in the specified directories 
/ files.

I tried to set threshold for CPU based on an example I had found on web.
See attached collectd.conf file .

BUT really not sure if the threshold configuration in my collectd.conf is 
correct or working ... is there a way to confirm this ?   ( any collectd 
experts out there ? )
OR
Is there an example collectd.conf that has notifications or thresholds 
(whatever vitrage needs) setup for something basic like CPU ?

Greg.




From: "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Monday, August 28, 2017 at 9:42 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [vitrage] Collectd - to - Vitrage setup issues

Hi Greg,

I’m less familiar with the collectd configuration and the events that it sends.

Regarding the collectd_conf.yaml, it is definitely missing. You should add a 
/etc/vitrage/collectd_conf.yaml file that looks like that:

collectd:
- collectd_host: 
   type: 
   name: 
- collectd_host: …


This file maps a Collectd resource to the corresponding resource in OpenStack. 
Only resources that are listed in this file will have their alarms imported to 
Vitrage.

Next, you should add a reference to this file in /etc/vitrage/vitrage.conf:

[collectd]
config_file = /etc/vitrage/collectd_conf.yaml

Then you should restart vitrage-graph.

Let me know if it helped,
Ifat.


From: "Waines, Greg" 
Date: Wednesday, 23 August 2017 at 21:19

I am trying to get collectd to report some alarms to vitrage in a devstack 
setup,

I am using a devstack created on a late version of ocata.
And my devstack with vitrage appears to be working ok otherwise;
e.g.  I can create VMs, and raise fake alarms using “vitrage event post 
-type=compute.host.down ...” or with “aodh alarm create ... 
resource_id=instance-uuid” ... and they get reported fine in vitrage.

UNFORTUNATELY not seeing anything in vitrage from collectd, and
  don’t believe I’m seeing anything even from collectd, 
for example from the syslog output plugin.

I’ve attached the following files:   ( not sure if these get distributed on 
mailing list )
· /etc/collectd/collectd.conf   <-- do these look ok ?
· /etc/vitrage/vitrage.conf  <-- do these look ok ?
· /var/log/syslog ... around the time when I updated 
collectd.conf and vitrage.conf and restarted collectd and vitrage-graph
oQUESTIONS
•  NOTE THE FOLLOWING ERRORS IN THE SYSLOG FILE ... where do I get the 
collectd_conf.yaml file from ?  Can’t see it in the devstack files for vitrage.
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.039 25962 ERROR vitrage.utils.file [-] File doesn't exist: 
/etc/vitrage/collectd_conf.yaml.
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.040 25962 ERROR vitrage.datasources.collectd.driver [-] failed in init 
'NoneType' object has no attribute '__getitem__' : TypeError: 'NoneType' object 
has no attribute '__getitem__'
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.040 25962 ERROR vitrage.datasources.collectd.driver Traceback (most 
recent call last):
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.040 25962 ERROR vitrage.datasources.collectd.driver   File 
"/opt/stack/vitrage/vitrage/datasources/collectd/driver.py", line 65, in 
_configuration_mapping
· Aug 23 14:09:31 localhost vitrage-graph[25962]: 2017-08-23 
14:09:31.040 25962 ERROR vitrage.datasources.collectd.driver