Re: [openstack-dev] [Vitrage] Installation

[Weyl, Alexey (Nokia - IL)]

Yes, this is how zabbix notifies on each new trigger or changes on existing 
triggers to Vitrage.

From: lương hữu tuấn [mailto:tuantulu...@gmail.com]
Sent: Wednesday, October 05, 2016 7:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Alexey,

Yeap, it is what i mean. It seems that the connection channel between Zabbix 
and Vitrage just only through this script.

Btw, thanks a lot

Br,

Tuan

On Wed, Oct 5, 2016 at 3:37 PM, Weyl, Alexey (Nokia - IL) 
> wrote:
Hi,

When you say notification in Zabbix, do you mean a new trigger in Zabbix?

If yes, then if you have configured the auxiliary Zabbix script successfully 
then the script should recognize any trigger raised in zabbix and send the 
trigger notification on the oslo bus.

Best Regards,
Alexey

From: lương hữu tuấn 
[mailto:tuantulu...@gmail.com]
Sent: Wednesday, October 05, 2016 4:13 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] Installation

Hi,

I have another question based on the getting information of vitrage from 
monitoring solution. As i see that we have the default one now is nagios and 
with the zabbix, we just have only the script that gets information from zabbix 
as below:
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/zabbix/auxiliary/zabbix_vitrage.py

If yes as above, so all the things like structure of zabbix notification, what 
if i create a new notification in zabbix, can vitrage understand it?

Br,

Tutj

On Wed, Oct 5, 2016 at 12:15 PM, Afek, Ifat (Nokia - IL) 
> wrote:
Hi Paul,

Please find the installation and configuration instructions here: 
https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst
Let us know if you have any other questions, we’ll be happy to help.

Best regards,
Ifat.


From: Paul Vaduva
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, 4 October 2016 at 16:03
To: 
"openstack-dev@lists.openstack.org"
Subject: [openstack-dev] [Vitrage] Installation

Hi everybody,

I am writing you to ask for guidance with the installation of Vitrage.
I have a deployed opnfv environment based on openstack mitaka release and I 
want to ask you how I would go about installing vitrage (with horizon) on this 
existing environment


Paul Ionut Vaduva
Software Engineer
Linux Team

Email  paul.vad...@enea.com

Enea R
319 Splaiul Independentei, OB403A
Bucharest, 060044
Phone  +4021311 43 00
Fax +402131143 01


www.enea.com

[cid:image002.png@01D00576.7D651240]
This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.


__
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] Neutron: Internet not available in VM instances

[kamalakannan sanjeevan]

Hello,

I am not able to connect to internet in teh spawned VM's.


Ethernet card details:

*Eth1 bridged through OVS(mybridge)  - 172.27.10.76*
*Eth3-
192.168.182.251*

after executing the command

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

iptables -t nat -A POSTROUTING -o mybridge -j MASQUERADE

- I see teh connectivity to VM's from my host name  ie 172.27.10.76 also
affected.

root@VFSR1:~# ovs-vsctl show
37f38767-0a2b-45fd-9507-abef7fd2d5c9
Bridge br-int
fail_mode: secure
Port "qr-2ff64ff8-b8"
tag: 6
Interface "qr-2ff64ff8-b8"
type: internal
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port "qvo310233a4-9f"
tag: 6
Interface "qvo310233a4-9f"
Port br-int
Interface br-int
type: internal
Port "tap6bc359b6-f0"
tag: 6
Interface "tap6bc359b6-f0"
type: internal
Port "qvo703c764e-23"
tag: 5
Interface "qvo703c764e-23"
Port int-mybridge
Interface int-mybridge
type: patch
options: {peer=phy-mybridge}
Port "qg-333a2d2b-ca"
tag: 5
Interface "qg-333a2d2b-ca"
type: internal









* Bridge mybridgePort mybridgeInterface
mybridgetype: internalPort "eth1"
Interface "eth1"Port phy-mybridgeInterface
phy-mybridgetype: patchoptions:
{peer=int-mybridge}*
Bridge br-tun
fail_mode: secure
Port br-tun
Interface br-tun
type: internal
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
ovs_version: "2.5.0"


Below is my network and router details

root@VFSR1:~# neutron net-list
+--+-+-+
| id   | name|
subnets |
+--+-+-+
| 51739543-b7d1-414b-bec1-9b38c3e5d5d7 | public  |
0db9fa02-27eb-4f38-8693-200719fc1fbf 172.27.10.0/24 |
| bf919707-b1eb-4d8f-90fe-5bcf0e07dce3 | private |
7fddc311-7938-44c4-abd4-e5095adba422 192.168.0.0/24 |
+--+-+-+
root@VFSR1:~# neutron router-list
+--++---+-+---+
| id   | name   |
external_gateway_info
| distributed | ha|
+--++---+-+---+
| 323a6782-46aa-458e-ad76-f9462d8ad955 | router | {"network_id":
"51739543-b7d1-414b-bec1-9b38c3e5d5d7", "enable_snat": true,
"external_fixed_ips": [{"subnet_id":
"0db9fa02-27eb-4f38-8693-200719fc1fbf", "ip_address": "172.27.10.101"}]} |
False   | False |
+--++---+-+---+

Below are my instances created

root@VFSR1:~# nova list
+--++++-++
| ID   | Name   | Status | Task State |
Power State | Networks   |
+--++++-++
| b737645b-317e-46be-b06a-f1b94f378d95 | test   | ACTIVE | -  |
Running | public=172.27.10.100   |
| 378b3776-dddb-4007-823a-8c4e2781dbdd | ubuntu | ACTIVE | -  |
Running | private=192.168.0.3, 172.27.10.102 |
+--++++-+-

I have internet connectivity using the machine IP 172.27.10.76, but the
internet is not working in teh VM range 172.27.10.100,172,27.10.250.


I have attached the firewall log as well.

Please advise.

Regards
kamal


firewal
Description: Binary data
__
OpenStack 

[openstack-dev] [QA] Meeting Thursday Oct 6th at 9:00 UTC

[Masayuki Igawa]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Oct 6th at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_October_6th_2016_.280900_UTC.29
Anyone is welcome to add an item to the agenda.

To help people figure out what time 9:00 UTC is in other timezones the
next meeting will be at:

04:00 EST
18:00 JST
18:30 ACST
11:00 CEST
04:00 CDT
02:00 PDT

Best Regards,
-- Masayuki Igawa

__
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] Future of turbo-hipster CI

[Joshua Hesketh]

On Wed, Oct 5, 2016 at 12:39 AM, Dan Smith  wrote:

> > Having said that, I think Dan Smith came across a fairly large
> > production DB dataset recently which he was using for testing some
> > archive changes, maybe Dan will become our new Johannes, but grumpier of
> > course. :)
>
> That's quite an insult to Johannes :)
>
> While working on the db archiving thing recently I was thinking about
> how it would be great to get t-h to run this process on one of its
> large/real datasets. Then I started to wonder when was the last time I
> actually saw it comment.
>
>
So if it's missed something important please let me know and we can look
into it. On the other hand with specific cases like this (as mentioned
earlier) we can test it individually as a special case.


> I feel like these days Nova, by policy, isn't doing any database
> migrations that can really take a long time for a variety of reasons
> (i.e. expand-only schema migrations, no data migrations). That means the
> original thing t-h set out to prevent is not really much of a risk anymore.
>
> I surely think it's valuable, but I understand if the benefit does not
> outweigh the cost at this point.
>


With nova being more careful of big migrations it does seem the effort is
beginning to outweigh the benefit.


>
> --Dan
>
> __
> 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] Future of turbo-hipster CI

[Joshua Hesketh]

On Wed, Oct 5, 2016 at 12:02 AM, Dean Troyer  wrote:

> On Mon, Oct 3, 2016 at 11:29 PM, Joshua Hesketh 
> wrote:
>
>> The question now is whether or not to continue running. Is there still
>> value in running turbo-hipster? It uses significant resources and it feels
>> that developers have learned the lessons it was designed to teach.
>>
>
> Is there any value in running turbo-hipster as a periodic job across
> multiple releases?  One common request from operators is to be able to
> upgrade directly from, say, kilo to mitaka or newton.  I know there are
> other factors involved in that (APIs, objects, etc), the question is if
> this is a necessary/useful component of testing that upgrade path?
>

No I don't think there is value. Once a migration is in the code base it's
very difficult to change it in any non-idempotent way. Some deployments run
very close to master and fixing a past migration would mean maintaining
users with diverged databases.



>
> dt
>
> --
>
> Dean Troyer
> dtro...@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
>
>
__
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] Future of turbo-hipster CI

[Joshua Hesketh]

On Tue, Oct 4, 2016 at 11:49 PM, Matt Riedemann 
wrote:

> On 10/3/2016 11:29 PM, Joshua Hesketh wrote:
>
>> Howdy,
>>
>> Quick bit of background. Turbo-hipster is a 3rd party CI system that
>> runs nova's database migrations against real datasets to try and catch
>> real-world problems.
>>
>> When it was initially written the state of migrations in nova would
>> cause a lot of pain for deployers (such as very long downtimes while
>> upgrades were performed or just not working at all). Since then nova has
>> made conscious efforts to minimise this time and are generally aware
>> when implementing a necessary migration may cause large downtimes and
>> attempt to work around it where possible.
>>
>> turbo-hipster used to run against every change in nova. This was to
>> catch changes that may have affected migration performance as a side
>> effect. However for the last few months turbo-hipster has only been
>> running against changes modifying files in nova/db/*. Any changes
>> outside of there that causes pain can likely be reverted.
>>
>> As a note, turbo-hipster is currently not running due
>> to https://review.openstack.org/#/c/374307/ until I have time to update
>> the datasets used.
>>
>> The question now is whether or not to continue running. Is there still
>> value in running turbo-hipster? It uses significant resources and it
>> feels that developers have learned the lessons it was designed to teach.
>>
>> Not running it increases the risk a migration will fail or take a very
>> long time for a real user, but turbo-hipster is far from perfect anyway
>> and only tests a couple of datasets so that risk is still there.
>>
>> Are nova developers still getting value out of turbo-hipster or has it
>> achieved its goal and is it time for it to retire?
>>
>> Thanks,
>> Josh
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> I honestly forgot it existed. We have had some proposed database
> migrations come up which were a bit controversial, e.g.:
>
> https://review.openstack.org/#/c/248780/
>
>

So we if know or expect something to be problematic/controversial it's
something that can be tested manually (as it sounds you have been doing).
It could be possible to find other operators willing to assist too.



> So it would be nice to have something big to test these out while
> considering them. We used to have Johannes for manual test runs on
> migration changes but he's no longer around.
>
> So I guess I'm fine with not having t-h anymore since I didn't even notice
> the absence for the last couple of releases, but I worry a bit about not
> having a large test dataset for manual runs.
>
>
It hasn't been absent for that long. It has only been running on migrations
(ie not every change) for the last few months.



> Having said that, I think Dan Smith came across a fairly large production
> DB dataset recently which he was using for testing some archive changes,
> maybe Dan will become our new Johannes, but grumpier of course. :)
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> 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] [murano] IRC Meeting time suggestion

[Tony Breeds]

On Thu, Oct 06, 2016 at 03:35:14AM +0300, Victor Ryzhenkin wrote:
> Hey!
> 
> Omar, time is good! Just please, don’t forget to update our meeting page [1] 
> with this information :)

Also update http://eavesdrop.openstack.org/#Murano_Meeting with a change in the 
openstack-infra/irc-meetings repo

Yours Tony.


signature.asc
Description: PGP 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] [murano] IRC Meeting time suggestion

[Victor Ryzhenkin]

Hey!

Omar, time is good! Just please, don’t forget to update our meeting page [1] 
with this information :)

Thanks!

[1] - https://wiki.openstack.org/wiki/Meetings/MuranoAgenda
-- 
Victor Ryzhenkin
Infra & QA Murano CPL
Quality Assurance Engineer
freerunner on #freenode

От 4 октября 2016 г. в 20:33:15, Serg Melikyan (smelik...@mirantis.com) написал:

Omar, 

time works for me!

On Thu, Sep 29, 2016 at 7:39 AM, aaronzhu1121  wrote:
Good news for contributor from China, will attend the meeting.

Thanks,
Zhu Rong

__
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




--
Serg Melikyan, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com | +1 (650) 440-8979
__  
OpenStack Development Mailing List (not for usage questions)  
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe  
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev  


signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [Congress] PTG planning

[Eric K]

Here are some of our choices as a team, as well as some first thoughts on
pros and cons:

1. Do work sessions at PTGs; no organized work sessions at summits.
Pro: schedule lines up wit beginning of dev cycle
Pro: work room available
Pro: easy to collaborate with other teams
Con: extra travel for those who will continue to attend summit.

2. Unofficial work session at summits; no work sessions at PTGs.
Pro: For people who would be going to the summits anyway, this option
reduces travel.
Con: probably no official work room available.
Con: happens at the middle of a dev cycle

3. Separately organize work sessions in the style of past mid-cycle
sprints; no work sessions at any of the official openstack events.
Pro: we can choose schedule and location
Con: harder to collaborate with other teams

4. No work sessions at all.

On 10/5/16, 4:18 PM, "Eric K"  wrote:

>Hi all,
>
>As you know, the traditional design summit will be split into the work
>sessions at PTGs and the community forums at the summits. The release
>schedules will be re-aligned so that the PTGs coincide with the beginning
>of the dev cycle for each release.
>http://www.openstack.org/ptg
>
>As a team, we are asked to decide whether we want to have work sessions at
>the upcoming PTG in in Atlanta (Feb 20-24) to kick-off the P-cycle. We¹re
>asked to have a decision no later than Oct 16, so hopefully we can discuss
>it over ML and the next couple meetings and come up with a decision.
>
>Some more details on the schedule at the first PTG:
>> The first Project Teams Gathering will happen in Atlanta, Feb 20-24,
>> 2017. We'll provide a separate room for every (non-single-vendor)
>> project team that asks for one, and each team will be able to organize
>> its own agenda (similar to what happens at mid-cycle sprints).
>
>> Horizontal teams (Infrastructure, Documentation, QA...) and
>> cross-project workgroups will meet on Monday-Tuesday (Monday optional).
>> Vertical teams (Nova, Cinder, Swift...) will meet on Wednesday-Friday
>> (Friday optional). Teams that fall in between (Packaging, Kolla,
>> Horizon...) might be placed with horizontal or vertical teams, depending
>> on room availability. Attendees will be encouraged to pick one
>> horizontal effort and one vertical team and attend the whole week,
>> although they can of course opt to only attend a single team meeting.
>
>



__
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] [libvirt] Debugging blockRebase() - "active block copy not ready for pivot"

[Kashyap Chamarthy]

TL;DR
-

>From the debug analysis of the log below, and discussion with Eric Blake
of upstream QEMU / libvirt resulted in the below bug report:

  https://bugzilla.redhat.com/show_bug.cgi?id=1382165 --
  virDomainGetBlockJobInfo: Adjust job reporting based on QEMU stats & the
  "ready" field of `query-block-jobs`

Until the above is fixed, I think _swap_volume() method in Nova could
either:

  (a) just try to either wait until it sees the BLOCK_JOB_READY event,
  which is emitted when a 'drive-mirror' job.  

  (b) Or keep polling, until we see "ready": true field (in the response
  of `query-block-jobs` inviked via libvirt blockJobInfo() 


Details
---

The code in Nova that's being executed is this part in _swap_volume()
from libvirt/driver.py.

[...]
# Start copy with VIR_DOMAIN_REBASE_REUSE_EXT flag to
# allow writing to existing external volume file
dev.rebase(new_path, copy=True, reuse_ext=True)

while not dev.is_job_complete():
time.sleep(0.5)

dev.abort_job(pivot=True)
[...]


(Optional Reading) libvirt / QEMU traffic log analysis 
--

Libvirt debug log (NB: 61MB)
http://logs.openstack.org/73/374373/2/check/gate-tempest-dsvm-full-ubuntu-xenial/149fe3e/logs/libvirt/libvirtd.txt.gz
Failed test: 
tempest.api.compute.admin.test_volume_swap.TestVolumeSwap.test_volume_swap

(I line-wrapped the logs manually.)

(1) We see _swap_volume() invokes the Libvirt blockRebase(), which calls
'drive-mirror' (ID: libvirt-25)

-
2016-10-04 15:54:45.308+: 30554: debug : qemuMonitorJSONCommandWithFd:291 :
Send command
'{"execute":"drive-mirror","arguments":{"device":"drive-virtio-disk1","target":"/dev/disk/by-path
/ip-10.205.221.168:3260-iscsi-iqn.2010-10.org.openstack:volume-7b86913d-78e4-4b68-8df2-63f1a4c6656a-lun-1","sync":"full","mode":"existing","format":"raw"},"id":"libvirt-25"}'
for write with FD -1
-


(2.a) Then, libvirt queries QEMU for job status (ID: 'libvirt-26') via
`query-block-jobs` command:

-
2016-10-04 15:54:45.332+: 30550: info : qemuMonitorIOWrite:528 :
QEMU_MONITOR_IO_WRITE: mon=0x7fa43000ee60
buf={"execute":"query-block-jobs","id":"libvirt-26"}
-

(2.b) Response for libvirt-26.  (Here we see: "len" == 1073741824,
"offset" == 0.  The copy job has just begun).

-
2016-10-04 15:54:45.332+: 30550: info :
qemuMonitorJSONIOProcessLine:206 : QEMU_MONITOR_RECV_REPLY:
mon=0x7fa43000ee60 reply={"return": [{"io-status": "ok", "device":
"drive-virtio-disk1", "busy": true, "len": 1073741824, "offset": 0,
"paused": false, "speed": 0, "ready": false, "type": "mirror"}], "id":
"libvirt-26"}
-

[Libvirt keeps on querying for job status, via `query-block-jobs`]
[Snip three polling requests 27, 28, 29]


(3.a) Next query (ID: libvirt-30):

-
2016-10-04 15:54:50.060+: 30550: info : qemuMonitorIOWrite:528 :
QEMU_MONITOR_IO_WRITE: mon=0x7fa43000ee60
buf={"execute":"query-block-jobs","id":"libvirt-30"}
-

(3.b) Response for libvirt-30.  (Here we see: "len" == 1073741824,
"offset" == 734003200 in bytes.  Copy operation is still in progress.)

-
2016-10-04 15:54:50.061+: 30550: info :
qemuMonitorJSONIOProcessLine:206 : QEMU_MONITOR_RECV_REPLY:
mon=0x7fa43000ee60 reply={"return": [{"io-status": "ok", "device":
"drive-virtio-disk1", "busy": true, "len": 1073741824, "offset":
734003200, "paused": false, "speed": 0, "ready": false, "type":
"mirror"}], "id": "libvirt-30"}
-

[Snip four (IDs, 31, 32, 33, 34) more job status request / response
round-trips.]


(4.a) Query for job status again (ID: libvirt-35):

-
2016-10-04 15:54:50.060+: 30550: info : qemuMonitorIOWrite:528 :
QEMU_MONITOR_IO_WRITE: mon=0x7fa43000ee60
buf={"execute":"query-block-jobs","id":"libvirt-30"}
-

(4.b) In response, finally, we see len (1073741824) == offset (1073741824):

-
2016-10-04 15:54:52.076+: 30550: info :
qemuMonitorJSONIOProcessLine:206 : QEMU_MONITOR_RECV_REPLY:
mon=0x7fa43000ee60 reply={"return": [{"io-status": "ok", "device":
"drive-virtio-disk1", "busy": true, "len": 1073741824, "offset":
1073741824, "paused": false, "speed": 0, "ready": false, "type":
"mirror"}], "id": "libvirt-35"}
-

Above, the "ready" flag does not yet indicate 'true', which signals the
job has _really_ ended.


Drilling down further


(5) The abort + pivot failed (as Nova calls
"dev.abort_job(pivot=True)"):

---
2016-10-04 15:54:52.076+: 30555: debug :
qemuDomainObjExitMonitorInternal:1923 : Exited monitor (mon=0x7fa43000ee60
vm=0x7fa414002a70 name=instance-0008)

2016-10-04 15:54:52.076+: 30555: error : qemuDomainBlockPivot:16137 : block
copy still active: disk 'vdb' not ready for pivot yet

2016-10-04 15:54:52.076+: 30555: debug : qemuBlockJobSyncEnd:242 : disk=vdb

2016-10-04 15:54:52.076+: 30555: debug : qemuDomainObjEndJob:1831 :
Stopping job: modify (async=none vm=0x7fa414002a70 name=instance-0008)
---

(6) HOWEVER, *here* we see 

[openstack-dev] [Congress] PTG planning

[Eric K]

Hi all,

As you know, the traditional design summit will be split into the work
sessions at PTGs and the community forums at the summits. The release
schedules will be re-aligned so that the PTGs coincide with the beginning
of the dev cycle for each release.
http://www.openstack.org/ptg

As a team, we are asked to decide whether we want to have work sessions at
the upcoming PTG in in Atlanta (Feb 20-24) to kick-off the P-cycle. We¹re
asked to have a decision no later than Oct 16, so hopefully we can discuss
it over ML and the next couple meetings and come up with a decision.

Some more details on the schedule at the first PTG:
> The first Project Teams Gathering will happen in Atlanta, Feb 20-24,
> 2017. We'll provide a separate room for every (non-single-vendor)
> project team that asks for one, and each team will be able to organize
> its own agenda (similar to what happens at mid-cycle sprints).

> Horizontal teams (Infrastructure, Documentation, QA...) and
> cross-project workgroups will meet on Monday-Tuesday (Monday optional).
> Vertical teams (Nova, Cinder, Swift...) will meet on Wednesday-Friday
> (Friday optional). Teams that fall in between (Packaging, Kolla,
> Horizon...) might be placed with horizontal or vertical teams, depending
> on room availability. Attendees will be encouraged to pick one
> horizontal effort and one vertical team and attend the whole week,
> although they can of course opt to only attend a single team meeting.



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

Re: [openstack-dev] [Fuel][Glance][Vsphere][Datastore]

[Sabari Murugesan]

This means that the glance store driver failed to lookup the datacenter
configured in the vmware_datastores option of glance-api.conf .

>From the official documentation for that option :-

*vmware_datastores allows administrators to*
*configure multiple datastores to save glance image in the VMware store
backend.*
*The required format for the option is:*
*::.*

*where datacenter_path*
*is the inventory path to the datacenter where the datastore is located.*

One of the common reason for your error is the following misconfiguration:-

If you are familiar with vCenter, check if the specified datacenter is under
inventory folders and if so, check whether the vmware_datastores option in
glance-api.conf references that folder in the inventory path.

e.g if your datacenter 'dc1' is under 'folder1' in vCenter, the
vmware_datastores option must be something like
'folder1/dc1::100'


Thanks
Sabari

On Wed, Oct 5, 2016 at 9:20 AM, lương hữu tuấn 
wrote:

> Hi,
>
> I have a problem related to glance when i try to install Openstack Liberty
> using Fuel MOS8.0 on top of Vsphere:
>
> - It had problem of uploading cirros image and i found out that at that
> time, glance-api was not working. The error is "Datacenter reference can
> not be None"
>
> - Then i checked the source code of "glance_store/_drivers/vmware_
> datastore.py" and realized that the "api.VMwareAPISession" has problem.
> It returned the value of datacenter_reference is None.
>
> Does anyone encounter this problem with Vsphere?
>
> Br,
>
> Tutj
>
> __
> 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] [neutron][networking-vpp]Introducing networking-vpp

[Kevin Benton]

Cool. Always like to see more drivers.

I'm curious about the choice of etcd instead of rabbitmq as the
communication mechanism between the mech driver and the agents since it
introduces a new dependency into the deployment. Is this because the agent
is written to work with other things like Kubernetes, Docker, etc as well?

On Wed, Oct 5, 2016 at 12:01 PM, Ian Wells  wrote:

> We'd like to introduce the VPP mechanism driver, networking-vpp[1], to the
> developer community.
>
> networking-vpp is an ML2 mechanism driver to control DPDK-based VPP
> user-space forwarders on OpenStack compute nodes.  The code does what
> mechanism drivers do - it connects VMs to each other and to other
> Neutron-provided network services like routers.  It also does it with care
> - we aim to make sure this is a robust design that can withstand common
> cloud problems and failures - and with clarity - so that it's
> straightforward to see what it's chosen to do and what it's thinking.
>
> To give some background:
>
> VPP is an open source network forwarder originally developed by Cisco and
> now part of the Linux Foundation FD.io project for fast dataplanes.  It's
> very very good at moving packets around, and has demonstrated performance
> up to and well beyond 10Gbps - of tiny packets: ten times the number of
> packets iperf uses to fill a 10Gbps link.  This makes it especially useful
> for NFV use cases.  It's a user space forwarder, which has other benefits
> versus kernel packet forwarding: it can be stopped and upgraded without
> rebooting the host, and (in the worst case) it can crash without bringing
> down the whole system.
>
> networking-vpp is its driver for OpenStack.  We've written about 3,000
> lines of code, consisting of a mechanism driver and an agent to program VPP
> through its Python API, and we use etcd to be a robust datastore and
> communication channel living between the two.
>
>
> The code, at the moment, is in a fairly early stage, so please play with
> it and fix or report any problems you find.  It will move packets between
> VLANs and flat networks and VMs, and will connect to DHCP servers, routers
> and the metadata server in your cloud, so for basic uses it will work just
> the way you expect.  However, we certainly don't support every feature of
> Neutron just yet.  In particular, we haven't tested some things like LBaaS
> and VPNaaS with it - they should work, we just haven't tried - and, most
> obviously, security groups are not yet implemented - that's on the way.
> However, we'd like to get it into your hands so that you can have a go with
> it, see what you like and don't like about it, and help us file down the
> rough edges if you feel like joining us.  Enjoy!
>
> [1]
> https://github.com/openstack/networking-vpp for all your code needs
> https://review.openstack.org/#/q/status:open+project:opensta
> ck/networking-vpp to help
> https://launchpad.net/networking-vpp for bugs
>
>
> __
> 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] [mistral] Don't use Scheduler to run actions

[Lingxian Kong]

Hi, Renat,

Thanks for raising it up!

Does that mean mistral-engine will do the RPC call directly to
mistral-executor after storing the calling information somewhere? I think a
flow chart would be better to explain current problem and your proposal,
and what's more, I personally think it deserves a spec since I see it as a
feature instead of a simple bug.


Cheers,
Lingxian Kong (Larry)

On Wed, Oct 5, 2016 at 11:14 PM, Renat Akhmerov 
wrote:

> Hi Team,
>
> I posted a bug [1] at Launchpad that is pretty important for many reasons.
> I tried to put all needed information into
> the bug description providing pros and cons of using Scheduler for running
> actions. I short, I’d like to remove
> Scheduler from the chain that leads to running an action on executor for
> performance reason (~30% difference
> on large workflows, from my experience). I decided to bring it up to a
> discussion here because I may be
> missing something and am very interested in your opinions. Please let me
> know if you have any additional
> arguments to those I provided in the bug.
>
> [1] https://bugs.launchpad.net/mistral/+bug/1630508
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
>
> __
> 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] [tc] open question to the candidates

[gordon chung]

hi,

just so it doesn't seem like you're replying to nobody. i want to thank 
all of you for opening up on this topic which hopefully isn't only 
important to me alone. it really helped me with my voting beyond the 
people i know.

i apologise if this was a polarising topic but it was great to see 
everyone's opinion on what the role of the TC is. there was a diverse 
set of answers so it should be fun trying to come to a consensus on 
everything when all is said and done. that said, it seems like the main 
commonality was y'all have optimism/passion in what you're targeting.

all the best in the election. everyone else, go vote!

for those who didn't reply but want to, i'm still interested. i feel 
like this could be asked to non-candidates too as what they expect but i 
don't know if ML is best medium for that.

cheers,
-- 
gord

__
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] Removing required port-id from classifier

[Sridhar Ramaswamy]

Hi Cathy,

See inline...

On Tue, Oct 4, 2016 at 2:36 PM, Cathy Zhang 
wrote:

> Hi Tim,
>
> Please see inline.
>
> Cathy
>
> -Original Message-
> From: Tim Rozet [mailto:tro...@redhat.com]
> Sent: Tuesday, October 04, 2016 1:29 PM
> To: Cathy Zhang
> Cc: OpenStack Development Mailing List (not for usage questions); Sridhar
> Ramaswamy; Sripriya Seetharam; Anil Vishnoi
> Subject: Re: Removing required port-id from classifier
>
> Responses inline.
>
> Thanks,
>
>
> Hi Cathy,
> I recall a while back discussing removing the required neutron port-id
> from the classifier.
>
> Cathy> Do you mean logical source port here?
> trozet> yeah the neutron_source_port seems required.
>
> Cathy> This is only required if the backend is OVS SFC driver (not
> required if it is ODL SFC driver or other drivers). There are several
> reasons for this. For example, without neutron source port being specified,
> we have to install flow classification rules on every compute node to catch
> the traffic flow from the source and scalability will be a big issue if
> there are thousands of compute nodes. Another example is that if two
> tenants use a shared network and each has its flow originating from
> different source VMs and going through its own SFC in the shared network,
> OVS needs different logical source ports to distinguish different tenants'
> traffic flow. Is there any reason why you can not specify a neutron source
> port?
>

The reason is - this restriction makes orchestrating service-chains very,
very difficult :(

With Tacker VNFFG feature you can neatly describe your waypoints and
classifier in a TOSCA yaml descriptor. Now, this restriction forces the
"operator" to select a specific neutron-port uuid among the possibly 100s
of ports as a "source". This negatively impacts usability and dilutes the
benefit the orchestration solution brings.

If scalability is an issue, instead forcing the higher layers to pick a
specific source-port, I'd suggest n-sfc team to look into coarse-grain
"source identifier" - like CIDR, neutron-network, etc. You should be able
to figure out specific compute-hosts where such VM's vif getting plugged
into neutron and apply the classification rules only on those compute nodes?

- Sridhar


>
>
> We just finished up implementing VNFFG in Tacker and are hitting this
> while testing.  What is the plan to remove this requirement?  Also, how are
> IETF SFC/NSH related API/plugin changes going?  Can we expect to have
> attributes like path-id, encap type soon?
>
> Cathy> The API already provides a way for specifying "path-id" and encap
> type (currently only MPLS encap type is supported since OVS does not
> support NSH yet). As to NSH support, the code patch is being worked on, not
> completed yet. We are also tracking the NSH work in OVS and hope OVS will
> support NSH soon so that when networking-sfc integrates with that new
> version of OVS, NSH can be supported properly.
> trozet> OK good. Anil is close (demoed at ODL summit) a networking-odl
> driver for networking-sfc that supports NSH.
> Can you link the patches or point me to who is working on the NSH support
> for the API/plugin DB layer?
>
> Cathy> Here is the patch link https://review.openstack.org/#/c/373465/
>
>
>
>
> Thanks,
>
> Tim Rozet
> Red Hat SDN Team
>
__
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] [ironic][docs] What is the policy for backporting docs changes to stable branches?

[Tony Breeds]

On Wed, Oct 05, 2016 at 09:37:07AM -0400, Jim Rollenhagen wrote:
> On Wed, Oct 5, 2016 at 9:00 AM, Luigi Toscano  wrote:
> > On Wednesday, 5 October 2016 15:31:50 CEST Pavlo Shchelokovskyy wrote:
> >> Hi all,
> >>
> >> lately I realized that docs for two of the features I was working on during
> >> Newton cycle are absent from Ironic's new install guide [0]. This is my
> >> fault, and I am sorry for missing that out. Currently I am working on
> >> adding those pieces.
> >>
> >> [...]
> >>
> >> Given the above, should those doc amendments be proposed as backports to
> >> stable/newton once they are merged in master? What is the general policy
> >> for backporting documentation amendments/fixes?
> >
> > The general rules are:
> > http://docs.openstack.org/project-team-guide/stable-branches.html
> >
> > "Note - It’s nevertheless allowed to backport fixes for other bugs if their
> > safety can be easily proved. For example, documentation fixes, debug log
> > message typo corrections, test only changes, patches that enhance test
> > coverage, configuration file content fixes can apply to all supported
> > branches. For those types of backports, stable maintainers will decide on 
> > case
> > by case basis. "
> >
> > I would consider "missing documentation for a(n important) feature" as a 
> > bug,
> > and I would try to backport it - at least for the project I'm involved in
> > (Sahara).
> 
> +1, ironic has been okay with backporting docs changes for a while
> now. Do it! :)

Yup.  The policy is about minimising the rick of regressions in running clouds.
I'm fine with backporting docs changes.  Feel free to add me as a reviewer
(from a policy POV)

Yours Tony.


signature.asc
Description: PGP 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

[openstack-dev] [nova] Draft Ocata design summit schedule is up

[Matt Riedemann]

The draft design summit schedule for nova is here:

https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Nova%3A

Depending on Matthew Booth's availability on Friday we might have to 
move the 11am session on the libvirt imagebackend refactor work to an 
earlier slot.


We'll also have a cross-project session with Neutron in their room on 
Wednesday afternoon:


https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16908/

The schedule is laid out keeping in mind we want to avoid conflicts with 
other projects that will have input in Nova sessions 
(neutron/keystone/cinder) and that people will be leaving early on 
Friday so may not be around for the meetup style on Friday afternoon.


If there are any questions or issues with this please speak up because 
this will more or less be official next week.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

[Ihar Hrachyshka]

Jeremy Stanley  wrote:


On 2016-10-04 18:22:10 +0200 (+0200), Ihar Hrachyshka wrote:
[...]
When I execute 'bindep test’ locally, I get the following error on  
centos7.2

which is expected:

Bad versions of installed packages:
sqlite version 3.7.17-8.el7 does not match >=3.8

I would think that this output is passed to apt-get in the gate. But  
then I

see the following failure in gate:

http://logs.openstack.org/06/381906/3/check/gate-neutron-pep8-ubuntu-xenial/148dcd8/console.html#_2016-10-04_15_57_36_846699

[...]

We hashed this out just now in #openstack-infra, but the quick
summary is that version specifiers with bindep are sort of
experimental. They were added as part of its initial design but the
first implementation was dpkg-only and made some assumptions about
how distros track available vs installed package versions that
couldn't easily be extended to other platforms. As a result, when we
started adding rpm (and then later emerge) support, we pretty much
just punted on version handling until someone actually turned up who
needed it and was willing to do the work to add it in a useful
cross-platform manner. For now at least, version specifiers have
poor coverage in bindep's unit tests and no coverage in its
functional tests and have probably bit-rotted on us.

It's on me that I forgot we actually mention version constraints in
the bindep documentation, with no indication that they aren't a
first-class feature at the moment. Anyway, it sounds like you may
have time and interest to help us get this supported properly (at
least for rpm-based platforms), so I'm thrilled and looking forward
to working with you toward that goal. Thanks again!
--
Jeremy Stanley

__
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


For reader’s sake, the patch to support versions for brief mode of the tool  
is: https://review.openstack.org/#/c/381979/


Cheers,
Ihar

__
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] [neutron][networking-vpp]Introducing networking-vpp

[Ian Wells]

We'd like to introduce the VPP mechanism driver, networking-vpp[1], to the
developer community.

networking-vpp is an ML2 mechanism driver to control DPDK-based VPP
user-space forwarders on OpenStack compute nodes.  The code does what
mechanism drivers do - it connects VMs to each other and to other
Neutron-provided network services like routers.  It also does it with care
- we aim to make sure this is a robust design that can withstand common
cloud problems and failures - and with clarity - so that it's
straightforward to see what it's chosen to do and what it's thinking.

To give some background:

VPP is an open source network forwarder originally developed by Cisco and
now part of the Linux Foundation FD.io project for fast dataplanes.  It's
very very good at moving packets around, and has demonstrated performance
up to and well beyond 10Gbps - of tiny packets: ten times the number of
packets iperf uses to fill a 10Gbps link.  This makes it especially useful
for NFV use cases.  It's a user space forwarder, which has other benefits
versus kernel packet forwarding: it can be stopped and upgraded without
rebooting the host, and (in the worst case) it can crash without bringing
down the whole system.

networking-vpp is its driver for OpenStack.  We've written about 3,000
lines of code, consisting of a mechanism driver and an agent to program VPP
through its Python API, and we use etcd to be a robust datastore and
communication channel living between the two.


The code, at the moment, is in a fairly early stage, so please play with it
and fix or report any problems you find.  It will move packets between
VLANs and flat networks and VMs, and will connect to DHCP servers, routers
and the metadata server in your cloud, so for basic uses it will work just
the way you expect.  However, we certainly don't support every feature of
Neutron just yet.  In particular, we haven't tested some things like LBaaS
and VPNaaS with it - they should work, we just haven't tried - and, most
obviously, security groups are not yet implemented - that's on the way.
However, we'd like to get it into your hands so that you can have a go with
it, see what you like and don't like about it, and help us file down the
rough edges if you feel like joining us.  Enjoy!

[1]
https://github.com/openstack/networking-vpp for all your code needs
https://review.openstack.org/#/q/status:open+project:
openstack/networking-vpp to help
https://launchpad.net/networking-vpp for bugs
__
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] Removing required port-id from classifier

[Cathy Zhang]

Hi Anil,

Could you check the /etc/neutron/neutron.conf to make sure you are not using 
flow classifiers drivers=ovs? You can also check your DB schema to make sure it 
is not old and does not have the check for source port. 
Another alternative is to use the latest code and also make sure your DB is 
migrated to the latest DB. If you still see the problem, could you send out the 
log?  

Thanks,
Cathy

-Original Message-
From: Anil Vishnoi [mailto:avish...@brocade.com] 
Sent: Tuesday, October 04, 2016 3:08 PM
To: Cathy Zhang; Tim Rozet
Cc: OpenStack Development Mailing List (not for usage questions); Sridhar 
Ramaswamy; Sripriya Seetharam
Subject: Re: Removing required port-id from classifier

Hi Cathy,

I am using the networking-odl sfc driver in my setup and that does require the 
logical_port for the classifier, although i am using around one month old 
networking-sfc master branch code. Is this something recently changed ?

Thanks
Anil 

From: Cathy Zhang 
Sent: Tuesday, October 4, 2016 2:36 PM
To: Tim Rozet; Cathy Zhang
Cc: OpenStack Development Mailing List (not for usage questions); Sridhar 
Ramaswamy; Sripriya Seetharam; Anil Vishnoi
Subject: RE: Removing required port-id from classifier

Hi Tim,



Please see inline.



Cathy



-Original Message-

From: Tim Rozet [mailto:tro...@redhat.com]

Sent: Tuesday, October 04, 2016 1:29 PM

To: Cathy Zhang

Cc: OpenStack Development Mailing List (not for usage questions); Sridhar 
Ramaswamy; Sripriya Seetharam; Anil Vishnoi

Subject: Re: Removing required port-id from classifier



Responses inline.



Thanks,



Tim Rozet

Red Hat SDN Team



- Original Message -

From: "Cathy Zhang" 

To: "Tim Rozet" , "OpenStack Development Mailing List (not 
for usage questions)" 

Cc: "Sridhar Ramaswamy" , "Sripriya Seetharam" 


Sent: Tuesday, October 4, 2016 1:54:04 PM

Subject: RE: Removing required port-id from classifier



Hi Tim,



Please see inline.



Thanks,

Cathy



-Original Message-

From: Tim Rozet [mailto:tro...@redhat.com]

Sent: Tuesday, October 04, 2016 10:07 AM

To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang

Cc: Sridhar Ramaswamy; Sripriya Seetharam

Subject: [tacker] [networking-sfc] Removing required port-id from classifier



Hi Cathy,

I recall a while back discussing removing the required neutron port-id from the 
classifier.



Cathy> Do you mean logical source port here?

trozet> yeah the neutron_source_port seems required.



Cathy> This is only required if the backend is OVS SFC driver (not required if 
it is ODL SFC driver or other drivers). There are several reasons for this. For 
example, without neutron source port being specified, we have to install flow 
classification rules on every compute node to catch the traffic flow from the 
source and scalability will be a big issue if there are thousands of compute 
nodes. Another example is that if two tenants use a shared network and each has 
its flow originating from different source VMs and going through its own SFC in 
the shared network, OVS needs different logical source ports to distinguish 
different tenants' traffic flow. Is there any reason why you can not specify a 
neutron source port?





We just finished up implementing VNFFG in Tacker and are hitting this while 
testing.  What is the plan to remove this requirement?  Also, how are IETF 
SFC/NSH related API/plugin changes going?  Can we expect to have attributes 
like path-id, encap type soon?



Cathy> The API already provides a way for specifying "path-id" and encap type 
(currently only MPLS encap type is supported since OVS does not support NSH 
yet). As to NSH support, the code patch is being worked on, not completed yet. 
We are also tracking the NSH work in OVS and hope OVS will support NSH soon so 
that when networking-sfc integrates with that new version of OVS, NSH can be 
supported properly.

trozet> OK good. Anil is close (demoed at ODL summit) a networking-odl driver 
for networking-sfc that supports NSH.

Can you link the patches or point me to who is working on the NSH support for 
the API/plugin DB layer?



Cathy> Here is the patch link 
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_373465_=DQIGaQ=IL_XqQWOjubgfqINi2jTzg=nNx-ccom3k8BhfkcqdGNBnq-5rteGW1CENWnxJvQP1M=UQNNvtujvkLCQr8XWkfqD3vDLIHnXj6PNYlMzCPvL2o=hm29JgqSH_6ZsobVL9vy5m5jEt7Q8laFNP2FmtCdo6c=









Thanks,



Tim Rozet

Red Hat SDN Team


__
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] [Magnum] What is Magnum's behaviour wrt Images in Glance and which ones are downloaded to COE ?

[Waines, Greg]

A few months ago, I asked a question wrt whether
MAGNUM pushed container images (from Glance) to the COE Master 
(e.g. SWARM Master) of the Magnum Bays ?

The answer was NO … other than the initial swarm container image, all other 
container images were downloaded by the docker daemon (either Swarm Master or 
Swarm Minion/Worker … I guess) from the OFFICIAL image hub from 
https://hub.docker.com/ … when a container was launched referencing a 
particular container image.


FOLLOW UP QUESTIONS:

· I would like to use a LOCAL Container Image Repository (Docker 
Registry?) with the MAGNUM deployment on OpenStack

· I would like to:

odeploy a LOCAL Container Image Repository (Docker Registry?) in a VM of 
OpenStack, and

othen deploy a MAGNUM BAY (e.g. Docker SWARM Master & Nodes) which ONLY use 
this LOCAL Container Image Repository

§  i.e. there is no requirement for external access to https://hub.docker.com/

§  and

§  I can push private container images into this LOCAL Container Image 
Repository … and they will be available to my MAGNUM Bay


· Assuming the answer is YES

owrt Deploying a LOCAL Container Image Repository (Docker Registry?) in a 
VM of OpenStack

§  is this https://docs.docker.com/registry/deploying/
a good example of what I would do (inside the VM) to setup this Docker Registry 
?


oHow do I launch the MAGNUM BAY such that it uses my LOCAL Container Image 
Repository (Docker Registry?) by default … and NOT https://hub.docker.com/   ???


Greg.


From: taget 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Tuesday, July 19, 2016 at 9:57 PM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [Magnum] What is Magnum's behaviour wrt Images in 
Glance and which ones are downloaded to COE ?


On 2016年07月20日 00:35, Waines, Greg wrote:

I created a Docker-Swarm bay and successfully launched a simple container.

What is the behavior of MAGNUM wrt downloading of Container-formatted Images in 
Glance to the COE ?

e.g. in the setup from the above link
gwaines@wildcat-76:~$ glance -v image-list
+--+-+-+--+---++--+
| ID   | Name| 
Disk_format | Container_format | Size  | Status | Owner 
   |
+--+-+-+--+---++--+
| 96a63dda-e9e8-45ac-843c-1635909aa79e | cirros-0.3.4-x86_64-uec | ami  
   | ami  | 25165824  | active | 
a7e010ece2bf4bbfa84551a03c0770ae |
| 9ff4c5a2-30d8-4c46-ac3e-fde566654fec | cirros-0.3.4-x86_64-uec-kernel  | aki  
   | aki  | 4979632   | active | 
a7e010ece2bf4bbfa84551a03c0770ae |
| df11374e-ef88-47eb-8603-5e646fa7c76c | cirros-0.3.4-x86_64-uec-ramdisk | ari  
   | ari  | 3740163   | active | 
a7e010ece2bf4bbfa84551a03c0770ae |
| 296d607a-6d7a-472b-987d-8bcde63ff124 | fedora-atomic-latest| 
qcow2   | bare | 507928064 | active | 
a7e010ece2bf4bbfa84551a03c0770ae |
+--+-+-+--+---++--+
gwaines@wildcat-76:~$
gwaines@wildcat-76:~$ docker images
REPOSITORY  TAG IMAGE IDCREATED 
SIZE
swarm   1.0.0   4a0d7b83266a5 months ago
0 B
cirros  latest  807dd1cf91c76 months ago
0 B
gwaines@wildcat-76:~$

Does MAGNUM automatically download all Glance Images of a particular Container 
Format to the COE ?

No, Magnum will not do this.
Only  the swarm docker image is download by Magnum.

In the above setup, which Glance Image does the ‘docker image’ “cirros” 
correspond to ?
None of from glance image.

You launched the swarm docker container with image 'cirros', the image of 
'cirros' was downloaded by docker daemon which is from OFFICIAL image hub from 
https://hub.docker.com/


--

Best Regards,

Eli Qiao (乔立勇), Intel OTC.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Ocata Design Summit: Couple of empty slots up for grabs

[eran]

Hi everyone,

The UX team PTL just released his two allocated design summit slots:

- One fishbowl session in a 73-seat room on Wednesday at 3:05pm
If possible - the storlets team would love to have this slot,  
particularly, as it does not conflict with a Swift  design session.


Thanks very much,
Eran


__
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] [neutron][l2gw] stable/newton

[Gary Kotton]

Hi,
Are there any plans to cut a stable/newton branch here?
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] weekly meeting #92

[Iury Gregory]

We did the meeting, you can read the notes in

http://eavesdrop.openstack.org/meetings/puppet_openstack/2016/puppet_openstack.2016-10-04-15.00.log.html

Thanks!

2016-10-03 11:58 GMT-03:00 Iury Gregory :

> Hi Puppeteers!
>
> We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting-4
>
> Here's a first agenda:
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20161004
>
> Feel free to add topics, and any outstanding bug and patch.
>
> See you tomorrow!
> Thanks,
>
> --
> ~
>
>
> *Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science
> at UFCG*
> *E-mail:  iurygreg...@gmail.com *
> ~
>



-- 

~


*Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science at
UFCG*
*E-mail:  iurygreg...@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

[openstack-dev] [charms] old LP repos

[Ryan Beisner]

Hi OpenStack Charmers,

After moving the dev focus of the OpenStack Charms from their original home
in Launchpad to Gerrit/Git, we kept repo syncs in place to allow a grace
period for tooling changes.  As far as I know, that is all complete.

There have been a number of people confused by the LP branch presence.  How
shall we proceed with the old repos?

Cheers,

Ryan
__
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][vsphere][datastore]

[lương hữu tuấn]

Hi,

I have a problem related to glance when i try to install Openstack Liberty
using Fuel MOS8.0 on top of Vsphere:

- It had problem of uploading cirros image and i found out that at that
time, glance-api was not working. The error is"Datacenter reference can not
be None"

- Then i checked the source code of "glance_store/_drivers/vmware_
datastore.py" and realized that the"api.VMwareAPISession" has problem. It
returned the value of datacenter_reference is None.

Does anyone encounter this problem with Vsphere?

Br,

Tutj
__
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] [Fuel][Glance][Vsphere][Datastore]

[lương hữu tuấn]

Hi,

I have a problem related to glance when i try to install Openstack Liberty
using Fuel MOS8.0 on top of Vsphere:

- It had problem of uploading cirros image and i found out that at that
time, glance-api was not working. The error is"Datacenter reference can not
be None"

- Then i checked the source code of "glance_store/_drivers/vmware_
datastore.py" and realized that the"api.VMwareAPISession" has problem. It
returned the value of datacenter_reference is None.

Does anyone encounter this problem with Vsphere?

Br,

Tutj
__
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] Installation

[Eyal B]

Hi Paul,

Did you install the Vitrage project and the Vitrage client project Does the
CLI work?

BR
Eyal

On Oct 5, 2016 19:05, "Paul Vaduva"  wrote:

> Hi Eyal
>
>
>
> Thanks for the reply.
>
>
>
> I installed vitrage-dasboard from the instructions here
>
> https://github.com/openstack/vitrage-dashboard
>
> Except that they are for a virtual environment I wanted to install on my
> allready deployed horizon so I did not use the „with_venv.sh” script for
> the pip commands and I copied the api and enable directories to the
> installation dir of openstack-dashbard which for me is
> „node-7:/usr/share/openstack-dashboard/openstack_dashboard” and I get the
> dashboard but I get the first email mentioned errors.
>
>
>
> BR
>
> Paul
>
>
>
> *From:* Eyal B [mailto:eya...@gmail.com]
> *Sent:* Wednesday, October 05, 2016 6:47 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Vitrage] Installation
>
>
>
> Hi Paul,
>
>
>
> How did you install vitrage ?
>
> if you install it using devstack then it installs the api service as part
> of httpd
>
> if you did it manually then vitrage api runs as a standalone service in
> that case all api logs will be in /var/log/vitrage
>
>
>
> Can you check the CLI just run the command "vitrage topology show" see if
> you get anything
>
>
>
>
>
> BR
>
>   Eyal
>
>
>
> On Wed, Oct 5, 2016 at 5:29 PM, Paul Vaduva  wrote:
>
> Hi Eyal
>
>
>
> It seems like I do not have this vitrage_wsgi_error.log in the same place
> or other place for that matter. Could be that I didn’t install everithing
> need ?
>
>
>
> BR
>
> Paul
>
>
>
> *From:* Eyal B [mailto:eya...@gmail.com]
> *Sent:* Wednesday, October 05, 2016 5:21 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Vitrage] Installation
>
>
>
> Hi Paul,
>
>
>
> check the log  (should be in the same place of horizon_error.log)
>
> check the logs of vitrage should be in /var/log/vitrage directory
>
>
>
> BR
>
>   Eyal
>
>
>
> On Wed, Oct 5, 2016 at 5:05 PM, Paul Vaduva  wrote:
>
> Hi Eyal
>
>
>
> I only get this warnings in horizon_error.log
>
> http://hastebin.com/anewoyifey.sql
>
>
>
> BR
>
>
>
> *From:* Eyal B [mailto:eya...@gmail.com]
> *Sent:* Wednesday, October 05, 2016 4:41 PM
>
>
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Vitrage] Installation
>
>
>
> Hi Paul,
>
>
>
> Could you please check the horizon_error.log
>
>
>
> It should be under /var/log/apache2 or /var/log/httpd
>
>
>
> BR
>
>   Eyal
>
>
>
> On Wed, Oct 5, 2016 at 4:24 PM, Paul Vaduva  wrote:
>
> Hi Ifat,
>
>
>
> Thanks you for the reply. I saw that this is for build on a virtual
> environment. I was courios if there is a way to install it on a deployed
> horizon. I tried to adapt the instructions to install it on my existing
> horizon installation (maily not use
>
> ./horizon/tools/with_venv.sh and copy cp -a vitragedashboard/enabled/* and
> the vitrageclient/api/* to my existing  horizon installation and the
> dashboard apeared on my web browser but
>
> · For Topology tab I get this error *Error:* Unable to fetch the
> Vitrage Topology service.
>
> · For Alarms tab I get *Error:* Unable to fetch the Vitrage
> Alarms service.
>
> · For Entity Graph I get *Error:* Unable to fetch the Vitrage
> Topology service.
>
>
>
> Best Regards,
>
> Paul
>
>
>
>
>
> *From:* Afek, Ifat (Nokia - IL) [mailto:ifat.a...@nokia.com]
> *Sent:* Wednesday, October 05, 2016 1:15 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Vitrage] Installation
>
>
>
> Hi Paul,
>
>
>
> Please find the installation and configuration instructions here:
> https://github.com/openstack/vitrage/blob/master/
> doc/source/installation-and-configuration.rst
>
> Let us know if you have any other questions, we’ll be happy to help.
>
>
>
> Best regards,
>
> Ifat.
>
>
>
>
>
> *From: *Paul Vaduva
> *Reply-To: *"OpenStack Development Mailing List (not for usage questions)"
> *Date: *Tuesday, 4 October 2016 at 16:03
> *To: *"openstack-dev@lists.openstack.org"
> *Subject: *[openstack-dev] [Vitrage] Installation
>
>
>
> Hi everybody,
>
>
>
> I am writing you to ask for guidance with the installation of Vitrage.
>
> I have a deployed opnfv environment based on openstack mitaka release and
> I want to ask you how I would go about installing vitrage (with horizon) on
> this existing environment
>
>
>
>
>
> *Paul Ionut Vaduva*
>
> Software Engineer
>
> Linux Team
>
>
>
> *Email*  *paul.vad...@enea.com *
>
>
>
> *Enea R*
>
> 319 Splaiul Independentei, OB403A
>
> Bucharest, 060044
>
> *Phone*  +4021311 43 00
>
> *Fax *+402131143 01

[openstack-dev] [Fuel][Glance][Vsphere][Datastore]

[lương hữu tuấn]

Hi,

I have a problem related to glance when i try to install Openstack Liberty
using Fuel MOS8.0 on top of Vsphere:

- It had problem of uploading cirros image and i found out that at that
time, glance-api was not working. The error is "Datacenter reference can
not be None"

- Then i checked the source code of
"glance_store/_drivers/vmware_datastore.py" and realized that the
"api.VMwareAPISession" has problem. It returned the value of
datacenter_reference is None.

Does anyone encounter this problem with Vsphere?

Br,

Tutj
__
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] TC candidacy

[Ihar Hrachyshka]

Joshua Harlow  wrote:


Flavio Percoco wrote:

On 03/10/16 23:25 +0100, Chris Dent wrote:

On Mon, 3 Oct 2016, Clay Gerrard wrote:


I just re-read your announcement - and I couldn't be happier you're
running
:D


a) Glad to hear it.

b) It's a shame these email threads didn't start last week. I
suspect many of the people reading have already voted. I think the
conversations are still valuable, both for the people who haven't
voted and to shape future discussions. It's making more things more
visible, and that's good.


FWIW, I think it's better to start these discussions when the candidacy
period
is over. As a voter, I always ask questions (or read other voter's
questions
before casting my vote). This might not be true for everyone, though.

Asking questions during the candidacy period might affect other
candidates too
(in a good or bad way), I believe.

That said, I'd like to also thank Clay for asking all the questions this
time
around. :D

Flavio


I for one think we should do 'live' televised debates, perhaps on CNN??

Maybe then not televised but in a IRC channel? Or on google hangouts or  
zoom (or other similar technology).


The idea seems to work for US presidential candidates so seems like it  
could work for the community here to (only sort of kidding).


Right. I think it’s obvious to everyone that the system narrows the list to  
the best candidates ever. /s


Ihar

__
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] Installation

[lương hữu tuấn]

Hi Alexey,

Yeap, it is what i mean. It seems that the connection channel between
Zabbix and Vitrage just only through this script.

Btw, thanks a lot

Br,

Tuan

On Wed, Oct 5, 2016 at 3:37 PM, Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

> Hi,
>
>
>
> When you say notification in Zabbix, do you mean a new trigger in Zabbix?
>
>
>
> If yes, then if you have configured the auxiliary Zabbix script
> successfully then the script should recognize any trigger raised in zabbix
> and send the trigger notification on the oslo bus.
>
>
>
> Best Regards,
>
> Alexey
>
>
>
> *From:* lương hữu tuấn [mailto:tuantulu...@gmail.com]
> *Sent:* Wednesday, October 05, 2016 4:13 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Vitrage] Installation
>
>
>
> Hi,
>
>
>
> I have another question based on the getting information of vitrage from
> monitoring solution. As i see that we have the default one now is nagios
> and with the zabbix, we just have only the script that gets information
> from zabbix as below:
>
> https://github.com/openstack/vitrage/blob/master/vitrage/
> datasources/zabbix/auxiliary/zabbix_vitrage.py
>
> If yes as above, so all the things like structure of zabbix notification,
> what if i create a new notification in zabbix, can vitrage understand it?
>
>
>
> Br,
>
>
>
> Tutj
>
>
>
> On Wed, Oct 5, 2016 at 12:15 PM, Afek, Ifat (Nokia - IL) <
> ifat.a...@nokia.com> wrote:
>
> Hi Paul,
>
>
>
> Please find the installation and configuration instructions here:
> https://github.com/openstack/vitrage/blob/master/
> doc/source/installation-and-configuration.rst
>
> Let us know if you have any other questions, we’ll be happy to help.
>
>
>
> Best regards,
>
> Ifat.
>
>
>
>
>
> *From: *Paul Vaduva
> *Reply-To: *"OpenStack Development Mailing List (not for usage questions)"
> *Date: *Tuesday, 4 October 2016 at 16:03
> *To: *"openstack-dev@lists.openstack.org"
> *Subject: *[openstack-dev] [Vitrage] Installation
>
>
>
> Hi everybody,
>
>
>
> I am writing you to ask for guidance with the installation of Vitrage.
>
> I have a deployed opnfv environment based on openstack mitaka release and
> I want to ask you how I would go about installing vitrage (with horizon) on
> this existing environment
>
>
>
>
>
> *Paul Ionut Vaduva*
>
> Software Engineer
>
> Linux Team
>
>
>
> *Email*  *paul.vad...@enea.com *
>
>
>
> *Enea R*
>
> 319 Splaiul Independentei, OB403A
>
> Bucharest, 060044
>
> *Phone*  +4021311 43 00
>
> *Fax *+402131143 01
>
>
>
>
>
> www.enea.com
>
>
>
> [image: cid:image002.png@01D00576.7D651240]
>
> This message, including attachments, is CONFIDENTIAL. It may also be
> privileged or otherwise protected by law. If you received this email by
> mistake please let us know by reply and then delete it from your system;
> you should not copy it or disclose its contents to anyone. All messages
> sent to and from Enea may be monitored to ensure compliance with internal
> policies and to protect our business. Emails are not secure and cannot be
> guaranteed to be error free as they can be intercepted, a mended, lost or
> destroyed, or contain viruses. The sender therefore does not accept
> liability for any errors or omissions in the contents of this message,
> which arise as a result of email transmission. Anyone who communicates with
> us by email accepts these risks.
>
>
>
>
> __
> 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] [Vitrage] Installation

[Paul Vaduva]

Hi Again

I forgot vtrage topology show  I get this
public endpoint for rca service in RegionOne region not found

BR
Paul

From: Eyal B [mailto:eya...@gmail.com]
Sent: Wednesday, October 05, 2016 6:47 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Paul,

How did you install vitrage ?
if you install it using devstack then it installs the api service as part of 
httpd
if you did it manually then vitrage api runs as a standalone service in that 
case all api logs will be in /var/log/vitrage

Can you check the CLI just run the command "vitrage topology show" see if you 
get anything


BR
  Eyal

On Wed, Oct 5, 2016 at 5:29 PM, Paul Vaduva 
> wrote:
Hi Eyal

It seems like I do not have this vitrage_wsgi_error.log in the same place or 
other place for that matter. Could be that I didn’t install everithing need ?

BR
Paul

From: Eyal B [mailto:eya...@gmail.com]
Sent: Wednesday, October 05, 2016 5:21 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Paul,

check the log  (should be in the same place of horizon_error.log)
check the logs of vitrage should be in /var/log/vitrage directory

BR
  Eyal

On Wed, Oct 5, 2016 at 5:05 PM, Paul Vaduva 
> wrote:
Hi Eyal

I only get this warnings in horizon_error.log
http://hastebin.com/anewoyifey.sql

BR

From: Eyal B [mailto:eya...@gmail.com]
Sent: Wednesday, October 05, 2016 4:41 PM

To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Paul,

Could you please check the horizon_error.log

It should be under /var/log/apache2 or /var/log/httpd

BR
  Eyal

On Wed, Oct 5, 2016 at 4:24 PM, Paul Vaduva 
> wrote:
Hi Ifat,

Thanks you for the reply. I saw that this is for build on a virtual 
environment. I was courios if there is a way to install it on a deployed 
horizon. I tried to adapt the instructions to install it on my existing horizon 
installation (maily not use
./horizon/tools/with_venv.sh and copy cp -a vitragedashboard/enabled/* and the 
vitrageclient/api/* to my existing  horizon installation and the dashboard 
apeared on my web browser but

• For Topology tab I get this error Error: Unable to fetch the Vitrage 
Topology service.

• For Alarms tab I get Error: Unable to fetch the Vitrage Alarms 
service.

• For Entity Graph I get Error: Unable to fetch the Vitrage Topology 
service.

Best Regards,
Paul


From: Afek, Ifat (Nokia - IL) 
[mailto:ifat.a...@nokia.com]
Sent: Wednesday, October 05, 2016 1:15 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Paul,

Please find the installation and configuration instructions here: 
https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst
Let us know if you have any other questions, we’ll be happy to help.

Best regards,
Ifat.


From: Paul Vaduva
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, 4 October 2016 at 16:03
To: 
"openstack-dev@lists.openstack.org"
Subject: [openstack-dev] [Vitrage] Installation

Hi everybody,

I am writing you to ask for guidance with the installation of Vitrage.
I have a deployed opnfv environment based on openstack mitaka release and I 
want to ask you how I would go about installing vitrage (with horizon) on this 
existing environment


Paul Ionut Vaduva
Software Engineer
Linux Team

Email  paul.vad...@enea.com

Enea R
319 Splaiul Independentei, OB403A
Bucharest, 060044
Phone  +4021311 43 00
Fax +402131143 01


www.enea.com

[cid:image002.png@01D00576.7D651240]
This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result 

Re: [openstack-dev] [Vitrage] Installation

[Paul Vaduva]

Hi Eyal

Thanks for the reply.

I installed vitrage-dasboard from the instructions here
https://github.com/openstack/vitrage-dashboard
Except that they are for a virtual environment I wanted to install on my 
allready deployed horizon so I did not use the „with_venv.sh” script for the 
pip commands and I copied the api and enable directories to the installation 
dir of openstack-dashbard which for me is 
„node-7:/usr/share/openstack-dashboard/openstack_dashboard” and I get the 
dashboard but I get the first email mentioned errors.

BR
Paul

From: Eyal B [mailto:eya...@gmail.com]
Sent: Wednesday, October 05, 2016 6:47 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Paul,

How did you install vitrage ?
if you install it using devstack then it installs the api service as part of 
httpd
if you did it manually then vitrage api runs as a standalone service in that 
case all api logs will be in /var/log/vitrage

Can you check the CLI just run the command "vitrage topology show" see if you 
get anything


BR
  Eyal

On Wed, Oct 5, 2016 at 5:29 PM, Paul Vaduva 
> wrote:
Hi Eyal

It seems like I do not have this vitrage_wsgi_error.log in the same place or 
other place for that matter. Could be that I didn’t install everithing need ?

BR
Paul

From: Eyal B [mailto:eya...@gmail.com]
Sent: Wednesday, October 05, 2016 5:21 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Paul,

check the log  (should be in the same place of horizon_error.log)
check the logs of vitrage should be in /var/log/vitrage directory

BR
  Eyal

On Wed, Oct 5, 2016 at 5:05 PM, Paul Vaduva 
> wrote:
Hi Eyal

I only get this warnings in horizon_error.log
http://hastebin.com/anewoyifey.sql

BR

From: Eyal B [mailto:eya...@gmail.com]
Sent: Wednesday, October 05, 2016 4:41 PM

To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Paul,

Could you please check the horizon_error.log

It should be under /var/log/apache2 or /var/log/httpd

BR
  Eyal

On Wed, Oct 5, 2016 at 4:24 PM, Paul Vaduva 
> wrote:
Hi Ifat,

Thanks you for the reply. I saw that this is for build on a virtual 
environment. I was courios if there is a way to install it on a deployed 
horizon. I tried to adapt the instructions to install it on my existing horizon 
installation (maily not use
./horizon/tools/with_venv.sh and copy cp -a vitragedashboard/enabled/* and the 
vitrageclient/api/* to my existing  horizon installation and the dashboard 
apeared on my web browser but

• For Topology tab I get this error Error: Unable to fetch the Vitrage 
Topology service.

• For Alarms tab I get Error: Unable to fetch the Vitrage Alarms 
service.

• For Entity Graph I get Error: Unable to fetch the Vitrage Topology 
service.

Best Regards,
Paul


From: Afek, Ifat (Nokia - IL) 
[mailto:ifat.a...@nokia.com]
Sent: Wednesday, October 05, 2016 1:15 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Paul,

Please find the installation and configuration instructions here: 
https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst
Let us know if you have any other questions, we’ll be happy to help.

Best regards,
Ifat.


From: Paul Vaduva
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, 4 October 2016 at 16:03
To: 
"openstack-dev@lists.openstack.org"
Subject: [openstack-dev] [Vitrage] Installation

Hi everybody,

I am writing you to ask for guidance with the installation of Vitrage.
I have a deployed opnfv environment based on openstack mitaka release and I 
want to ask you how I would go about installing vitrage (with horizon) on this 
existing environment


Paul Ionut Vaduva
Software Engineer
Linux Team

Email  paul.vad...@enea.com

Enea R
319 Splaiul Independentei, OB403A
Bucharest, 060044
Phone  +4021311 43 00
Fax +402131143 01


www.enea.com

[cid:image002.png@01D00576.7D651240]
This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its 

Re: [openstack-dev] TC candidacy

[Joshua Harlow]

Flavio Percoco wrote:

On 03/10/16 23:25 +0100, Chris Dent wrote:

On Mon, 3 Oct 2016, Clay Gerrard wrote:


I just re-read your announcement - and I couldn't be happier you're
running
:D


a) Glad to hear it.

b) It's a shame these email threads didn't start last week. I
suspect many of the people reading have already voted. I think the
conversations are still valuable, both for the people who haven't
voted and to shape future discussions. It's making more things more
visible, and that's good.


FWIW, I think it's better to start these discussions when the candidacy
period
is over. As a voter, I always ask questions (or read other voter's
questions
before casting my vote). This might not be true for everyone, though.

Asking questions during the candidacy period might affect other
candidates too
(in a good or bad way), I believe.

That said, I'd like to also thank Clay for asking all the questions this
time
around. :D

Flavio



I for one think we should do 'live' televised debates, perhaps on CNN??

Maybe then not televised but in a IRC channel? Or on google hangouts or 
zoom (or other similar technology).


The idea seems to work for US presidential candidates so seems like it 
could work for the community here to (only sort of kidding).


-Josh

__
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] Installation

[Eyal B]

Hi Paul,

How did you install vitrage ?
if you install it using devstack then it installs the api service as part
of httpd
if you did it manually then vitrage api runs as a standalone service in
that case all api logs will be in /var/log/vitrage

Can you check the CLI just run the command "vitrage topology show" see if
you get anything


BR
  Eyal

On Wed, Oct 5, 2016 at 5:29 PM, Paul Vaduva  wrote:

> Hi Eyal
>
>
>
> It seems like I do not have this vitrage_wsgi_error.log in the same place
> or other place for that matter. Could be that I didn’t install everithing
> need ?
>
>
>
> BR
>
> Paul
>
>
>
> *From:* Eyal B [mailto:eya...@gmail.com]
> *Sent:* Wednesday, October 05, 2016 5:21 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Vitrage] Installation
>
>
>
> Hi Paul,
>
>
>
> check the log  (should be in the same place of horizon_error.log)
>
> check the logs of vitrage should be in /var/log/vitrage directory
>
>
>
> BR
>
>   Eyal
>
>
>
> On Wed, Oct 5, 2016 at 5:05 PM, Paul Vaduva  wrote:
>
> Hi Eyal
>
>
>
> I only get this warnings in horizon_error.log
>
> http://hastebin.com/anewoyifey.sql
>
>
>
> BR
>
>
>
> *From:* Eyal B [mailto:eya...@gmail.com]
> *Sent:* Wednesday, October 05, 2016 4:41 PM
>
>
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Vitrage] Installation
>
>
>
> Hi Paul,
>
>
>
> Could you please check the horizon_error.log
>
>
>
> It should be under /var/log/apache2 or /var/log/httpd
>
>
>
> BR
>
>   Eyal
>
>
>
> On Wed, Oct 5, 2016 at 4:24 PM, Paul Vaduva  wrote:
>
> Hi Ifat,
>
>
>
> Thanks you for the reply. I saw that this is for build on a virtual
> environment. I was courios if there is a way to install it on a deployed
> horizon. I tried to adapt the instructions to install it on my existing
> horizon installation (maily not use
>
> ./horizon/tools/with_venv.sh and copy cp -a vitragedashboard/enabled/* and
> the vitrageclient/api/* to my existing  horizon installation and the
> dashboard apeared on my web browser but
>
> · For Topology tab I get this error *Error:* Unable to fetch the
> Vitrage Topology service.
>
> · For Alarms tab I get *Error:* Unable to fetch the Vitrage
> Alarms service.
>
> · For Entity Graph I get *Error:* Unable to fetch the Vitrage
> Topology service.
>
>
>
> Best Regards,
>
> Paul
>
>
>
>
>
> *From:* Afek, Ifat (Nokia - IL) [mailto:ifat.a...@nokia.com]
> *Sent:* Wednesday, October 05, 2016 1:15 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Vitrage] Installation
>
>
>
> Hi Paul,
>
>
>
> Please find the installation and configuration instructions here:
> https://github.com/openstack/vitrage/blob/master/
> doc/source/installation-and-configuration.rst
>
> Let us know if you have any other questions, we’ll be happy to help.
>
>
>
> Best regards,
>
> Ifat.
>
>
>
>
>
> *From: *Paul Vaduva
> *Reply-To: *"OpenStack Development Mailing List (not for usage questions)"
> *Date: *Tuesday, 4 October 2016 at 16:03
> *To: *"openstack-dev@lists.openstack.org"
> *Subject: *[openstack-dev] [Vitrage] Installation
>
>
>
> Hi everybody,
>
>
>
> I am writing you to ask for guidance with the installation of Vitrage.
>
> I have a deployed opnfv environment based on openstack mitaka release and
> I want to ask you how I would go about installing vitrage (with horizon) on
> this existing environment
>
>
>
>
>
> *Paul Ionut Vaduva*
>
> Software Engineer
>
> Linux Team
>
>
>
> *Email*  *paul.vad...@enea.com *
>
>
>
> *Enea R*
>
> 319 Splaiul Independentei, OB403A
>
> Bucharest, 060044
>
> *Phone*  +4021311 43 00
>
> *Fax *+402131143 01
>
>
>
>
>
> www.enea.com
>
>
>
> [image: cid:image002.png@01D00576.7D651240]
>
> This message, including attachments, is CONFIDENTIAL. It may also be
> privileged or otherwise protected by law. If you received this email by
> mistake please let us know by reply and then delete it from your system;
> you should not copy it or disclose its contents to anyone. All messages
> sent to and from Enea may be monitored to ensure compliance with internal
> policies and to protect our business. Emails are not secure and cannot be
> guaranteed to be error free as they can be intercepted, a mended, lost or
> destroyed, or contain viruses. The sender therefore does not accept
> liability for any errors or omissions in the contents of this message,
> which arise as a result of email transmission. Anyone who communicates with
> us by email accepts these risks.
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

[openstack-dev] [all] Ocata Design Summit: Couple of empty slots up for grabs

[Thierry Carrez]

Hi everyone,

The UX team PTL just released his two allocated design summit slots:

- One fishbowl session in a 73-seat room on Wednesday at 3:05pm
- One workroom session in a 20-seat room on Wednesday at 3:55pm

You can see those as empty slots on:

https://docs.google.com/spreadsheets/d/1TQ-RSlbiBBEclkonIbfUP7R1ExZSJylF1uiEKV2G_Cw/pubhtml?gid=1107826458=true

If your team is interested in grabbing those, let me know ! Please check
for conflicts before you do, though :)

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all] Why do we have project specific hacking rules?

[Ian Cordasco]

 

-Original Message-
From: Ihar Hrachyshka 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: October 5, 2016 at 10:30:32
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [all] Why do we have project specific hacking 
rules?

> Ian Cordasco wrote:
>  
> > -Original Message-
> > From: Tony Breeds  
> > Reply: OpenStack Development Mailing List (not for usage questions)
> > , OpenStack Development Mailing List
> > (not for usage questions)  
> > Date: October 5, 2016 at 08:14:40
> > To: OpenStack Development Mailing List (not for usage questions)
> >  
> > Subject: Re: [openstack-dev] [all] Why do we have project specific
> > hacking rules?
> >
> >> On Wed, Oct 05, 2016 at 07:56:15AM -0500, Ian Cordasco wrote:
> >>
> >>> So hacking doesn't push out to anyone. It's one of the projects that
> >>> doesn't
> >>> get updated by global-requirements updates, if I remember correctly.
> >>
> >> Just clarifying/confirming what Ian says.
> >>
> >> The proposal-bot does not generate updates to projects
> >> *requirements.txt. It's
> >> up to the projects to do that themselves.
> >>
> >> Having said that it *could* all the code is there but it was disabled
> >> for a reason.
> >
> > Right. Thank you for clarifying, Tony.
> >
> > I believe several projects didn't want Hacking to auto-update and break
> > things. With off-by-default rules (and the proliferation of them in
> > Hacking) I don't think this is the most valid of concerns anymore. The
> > only problem would be that pycodestyle and pyflakes frequently add new
> > checks in releases means that the way Hacking pins Flake8 and
> > itsdependencies is still necessary. We need to figure out how to keep
> > up-to-date with our upstream dependencies without causing problems for
> > projects. Until we do that, we should probably just keep our current
> > methodology of letting projects update when they want to and can afford
> > developer time to update.
>  
> I believe those transitive dependencies could be effectively pinned thru
> upper-constraints.txt mechanism.

They're already pinned (not using upper-constraints). I'm sorry I wasn't clear 
about that.

--  
Ian Cordasco


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

Re: [openstack-dev] [all] Why do we have project specific hacking rules?

[Ihar Hrachyshka]

Ian Cordasco  wrote:


-Original Message-
From: Tony Breeds 
Reply: OpenStack Development Mailing List (not for usage questions)  
, OpenStack Development Mailing List  
(not for usage questions) 

Date: October 5, 2016 at 08:14:40
To: OpenStack Development Mailing List (not for usage questions)  

Subject:  Re: [openstack-dev] [all] Why do we have project specific  
hacking rules?



On Wed, Oct 05, 2016 at 07:56:15AM -0500, Ian Cordasco wrote:

So hacking doesn't push out to anyone. It's one of the projects that  
doesn't

get updated by global-requirements updates, if I remember correctly.


Just clarifying/confirming what Ian says.

The proposal-bot does not generate updates to projects  
*requirements.txt. It's

up to the projects to do that themselves.

Having said that it *could* all the code is there but it was disabled  
for a reason.


Right. Thank you for clarifying, Tony.

I believe several projects didn't want Hacking to auto-update and break  
things. With off-by-default rules (and the proliferation of them in  
Hacking) I don't think this is the most valid of concerns anymore. The  
only problem would be that pycodestyle and pyflakes frequently add new  
checks in releases means that the way Hacking pins Flake8 and  
itsdependencies is still necessary. We need to figure out how to keep  
up-to-date with our upstream dependencies without causing problems for  
projects. Until we do that, we should probably just keep our current  
methodology of letting projects update when they want to and can afford  
developer time to update.


I believe those transitive dependencies could be effectively pinned thru  
upper-constraints.txt mechanism.


Ihar

__
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] [elections][tc]Thoughts on the TC election process

[John Griffith]

On Wed, Oct 5, 2016 at 9:08 AM, Sean Dague  wrote:

> On 10/03/2016 12:46 PM, Edward Leafe wrote:
> 
> > We are fortunate in that all of the candidates are exceptionally
> well-qualified, and those elected have put in excellent service while on
> the TC. But one thing I'm afraid of is that we tend to get into a situation
> where groupthink [0] is very likely. There are many excellent candidates
> running in every election, but it is rare for someone who hasn't been a PTL
> of a large project, and thus very visible, has been selected. Is this
> really the best approach?
> >
> > I wrote a blog post about implicit bias [1], and in that post used the
> example of blind auditions for musical orchestras radically changing the
> selection results. Before the introduction of blind auditions, men
> overwhelmingly comprised orchestras, but once the people judging the
> auditions had no clue as to whether the musician was male or female, women
> began to be selected much more in proportion to their numbers in the
> audition pools. So I'd like to propose something for the next election:
> have candidates self-nominate as in the past, but instead of writing a big
> candidacy letter, just state their interest in serving. After the
> nominations close, the election officials will assign each candidate a
> non-identifying label, such as a random number, and those officials will be
> the only ones who know which candidate is associated with which number. The
> nomination period can be much, much shorter, and then followed by a week of
> campaigning (the part that's really missing in the current process).
> Candidates will post their thoughts and positions, and respond to questions
> from people, and this is how the voters will know who best represents what
> they want to see in their TC.
>
> The comparison to orchestra auditions was brought up a couple of cycles
> ago as well. But I think it's a bad comparison.
>
> In the listed example the job being asked of people was performing their
> instrument, and it turns out that lots of things not having to do with
> performing their instrument were biasing the results. It was possible to
> remove the irrelevant parts.
>
> What is the job being asked of a TC member? To put the best interests of
> OpenStack at heart. To be effective in working with a diverse set of
> folks in our community to get things done. To find areas of friction and
> remove them. To help set an overall direction for the project that the
> community accepts and moves forward with.
>
> Writing a good candidacy email isn't really a good representation of
> those abilities. It's the measure of writing a good candidacy email, in
> english.
>
> I hope that when voters vote in the election they are taking the
> reputations of the individuals into account. That they look at the work
> they did across all of OpenStack, the hundreds / thousands of individual
> actions in the community that the person made. How they got to consensus
> on items. What efforts they were able to get folks to rally around and
> move forward. Where they get stuck, and how they dig out of being stuck.
> When they ask for help. When they admit they are out of their element.
> How they help new folks in our community. How they work with long timers.
>
> That aggregate reputation is much more indicative of their
> successfulness as a member of the TC to help OpenStack than the
> candidate email. It's easy to dismiss it as a popularity contest, but I
> don't think it is. This is about evaluating the plausible promise that
> individuals put forward. Not just the ideas they have, but how likely
> they are to be able to bring them to fruition.
>
> -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
>
​Well said Sean!​
__
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] [elections][tc]Thoughts on the TC election process

[Sean Dague]

On 10/03/2016 12:46 PM, Edward Leafe wrote:

> We are fortunate in that all of the candidates are exceptionally 
> well-qualified, and those elected have put in excellent service while on the 
> TC. But one thing I'm afraid of is that we tend to get into a situation where 
> groupthink [0] is very likely. There are many excellent candidates running in 
> every election, but it is rare for someone who hasn't been a PTL of a large 
> project, and thus very visible, has been selected. Is this really the best 
> approach?
> 
> I wrote a blog post about implicit bias [1], and in that post used the 
> example of blind auditions for musical orchestras radically changing the 
> selection results. Before the introduction of blind auditions, men 
> overwhelmingly comprised orchestras, but once the people judging the 
> auditions had no clue as to whether the musician was male or female, women 
> began to be selected much more in proportion to their numbers in the audition 
> pools. So I'd like to propose something for the next election: have 
> candidates self-nominate as in the past, but instead of writing a big 
> candidacy letter, just state their interest in serving. After the nominations 
> close, the election officials will assign each candidate a non-identifying 
> label, such as a random number, and those officials will be the only ones who 
> know which candidate is associated with which number. The nomination period 
> can be much, much shorter, and then followed by a week of campaigning (the 
> part that's really missing in the current p
 rocess). Candidates will post their thoughts and positions, and respond to 
questions from people, and this is how the voters will know who best represents 
what they want to see in their TC.

The comparison to orchestra auditions was brought up a couple of cycles
ago as well. But I think it's a bad comparison.

In the listed example the job being asked of people was performing their
instrument, and it turns out that lots of things not having to do with
performing their instrument were biasing the results. It was possible to
remove the irrelevant parts.

What is the job being asked of a TC member? To put the best interests of
OpenStack at heart. To be effective in working with a diverse set of
folks in our community to get things done. To find areas of friction and
remove them. To help set an overall direction for the project that the
community accepts and moves forward with.

Writing a good candidacy email isn't really a good representation of
those abilities. It's the measure of writing a good candidacy email, in
english.

I hope that when voters vote in the election they are taking the
reputations of the individuals into account. That they look at the work
they did across all of OpenStack, the hundreds / thousands of individual
actions in the community that the person made. How they got to consensus
on items. What efforts they were able to get folks to rally around and
move forward. Where they get stuck, and how they dig out of being stuck.
When they ask for help. When they admit they are out of their element.
How they help new folks in our community. How they work with long timers.

That aggregate reputation is much more indicative of their
successfulness as a member of the TC to help OpenStack than the
candidate email. It's easy to dismiss it as a popularity contest, but I
don't think it is. This is about evaluating the plausible promise that
individuals put forward. Not just the ideas they have, but how likely
they are to be able to bring them to fruition.

-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

Re: [openstack-dev] [release][keystone] keystone Newton RC3 available

[Thierry Carrez]

A RC3 was just produced for keystone to catch a critical upgrade issue.

Please test:
https://tarballs.openstack.org/keystone/keystone-10.0.0.0rc3.tar.gz
http://git.openstack.org/cgit/openstack/keystone/log/?h=stable/newton

Doug Hellmann wrote:
> Hello everyone,
> 
> A new release candidate for keystone for the end of the Newton cycle
> is available!  You can find the source code tarball at:
> 
> https://tarballs.openstack.org/keystone/keystone-10.0.0.0rc2.tar.gz
> 
> Unless release-critical issues are found that warrant a release
> candidate respin, this candidate will be formally released as the final
> Newton release on 6 October. You are therefore strongly
> encouraged to test and validate this tarball!
> 
> Alternatively, you can directly test the stable/newton release
> branch at:
> 
> http://git.openstack.org/cgit/openstack/keystone/log/?h=stable/newton
> 
> If you find an issue that could be considered release-critical,
> please file it at:
> 
> https://bugs.launchpad.net/keystone/+filebug
> 
> and tag it *newton-rc-potential* to bring it to the keystone release
> crew's attention.
> 
> Thanks,
> Doug

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all] Why do we have project specific hacking rules?

[Ian Cordasco]

-Original Message-
From: Tony Breeds 
Reply: OpenStack Development Mailing List (not for usage questions) 
, OpenStack Development Mailing List (not 
for usage questions) 
Date: October 5, 2016 at 08:14:40
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [all] Why do we have project specific hacking 
rules?

> On Wed, Oct 05, 2016 at 07:56:15AM -0500, Ian Cordasco wrote:
>  
> > So hacking doesn't push out to anyone. It's one of the projects that doesn't
> > get updated by global-requirements updates, if I remember correctly.
>  
> Just clarifying/confirming what Ian says.
>  
> The proposal-bot does not generate updates to projects *requirements.txt. It's
> up to the projects to do that themselves.
>  
> Having said that it *could* all the code is there but it was disabled for a 
> reason.

Right. Thank you for clarifying, Tony.

I believe several projects didn't want Hacking to auto-update and break things. 
With off-by-default rules (and the proliferation of them in Hacking) I don't 
think this is the most valid of concerns anymore. The only problem would be 
that pycodestyle and pyflakes frequently add new checks in releases means that 
the way Hacking pins Flake8 and itsdependencies is still necessary. We need to 
figure out how to keep up-to-date with our upstream dependencies without 
causing problems for projects. Until we do that, we should probably just keep 
our current methodology of letting projects update when they want to and can 
afford developer time to update.

--  
Ian Cordasco


__
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] Installation

[Paul Vaduva]

Hi Eyal

It seems like I do not have this vitrage_wsgi_error.log in the same place or 
other place for that matter. Could be that I didn’t install everithing need ?

BR
Paul

From: Eyal B [mailto:eya...@gmail.com]
Sent: Wednesday, October 05, 2016 5:21 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Paul,

check the log  (should be in the same place of horizon_error.log)
check the logs of vitrage should be in /var/log/vitrage directory

BR
  Eyal

On Wed, Oct 5, 2016 at 5:05 PM, Paul Vaduva 
> wrote:
Hi Eyal

I only get this warnings in horizon_error.log
http://hastebin.com/anewoyifey.sql

BR

From: Eyal B [mailto:eya...@gmail.com]
Sent: Wednesday, October 05, 2016 4:41 PM

To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Paul,

Could you please check the horizon_error.log

It should be under /var/log/apache2 or /var/log/httpd

BR
  Eyal

On Wed, Oct 5, 2016 at 4:24 PM, Paul Vaduva 
> wrote:
Hi Ifat,

Thanks you for the reply. I saw that this is for build on a virtual 
environment. I was courios if there is a way to install it on a deployed 
horizon. I tried to adapt the instructions to install it on my existing horizon 
installation (maily not use
./horizon/tools/with_venv.sh and copy cp -a vitragedashboard/enabled/* and the 
vitrageclient/api/* to my existing  horizon installation and the dashboard 
apeared on my web browser but

• For Topology tab I get this error Error: Unable to fetch the Vitrage 
Topology service.

• For Alarms tab I get Error: Unable to fetch the Vitrage Alarms 
service.

• For Entity Graph I get Error: Unable to fetch the Vitrage Topology 
service.

Best Regards,
Paul


From: Afek, Ifat (Nokia - IL) 
[mailto:ifat.a...@nokia.com]
Sent: Wednesday, October 05, 2016 1:15 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Paul,

Please find the installation and configuration instructions here: 
https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst
Let us know if you have any other questions, we’ll be happy to help.

Best regards,
Ifat.


From: Paul Vaduva
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, 4 October 2016 at 16:03
To: 
"openstack-dev@lists.openstack.org"
Subject: [openstack-dev] [Vitrage] Installation

Hi everybody,

I am writing you to ask for guidance with the installation of Vitrage.
I have a deployed opnfv environment based on openstack mitaka release and I 
want to ask you how I would go about installing vitrage (with horizon) on this 
existing environment


Paul Ionut Vaduva
Software Engineer
Linux Team

Email  paul.vad...@enea.com

Enea R
319 Splaiul Independentei, OB403A
Bucharest, 060044
Phone  +4021311 43 00
Fax +402131143 01


www.enea.com

[cid:image002.png@01D00576.7D651240]
This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.


__
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 

[openstack-dev] [nova] Notification tranformation burndown chart

[Balázs Gibizer]

Hi, 

Notification transformation work continues in nova for Ocata [1]. I've created 
a burndown chart that is automatically updated from gerrit based on  sdague's  
api-ref burndown code. Please use that page [2] to follow the work; to see what 
to do and what to review.

[1] 
https://blueprints.launchpad.net/nova/+spec/versioned-notification-transformation-ocata
 
[2] https://vntburndown-gibi.rhcloud.com/index.html 

Cheers,
gibi

__
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] Installation

[Eyal B]

Hi Paul,

check the log vitrage_wsgi_error.log (should be in the same place of
horizon_error.log)
check the logs of vitrage should be in /var/log/vitrage directory

BR
  Eyal

On Wed, Oct 5, 2016 at 5:05 PM, Paul Vaduva  wrote:

> Hi Eyal
>
>
>
> I only get this warnings in horizon_error.log
>
> http://hastebin.com/anewoyifey.sql
>
>
>
> BR
>
>
>
> *From:* Eyal B [mailto:eya...@gmail.com]
> *Sent:* Wednesday, October 05, 2016 4:41 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Vitrage] Installation
>
>
>
> Hi Paul,
>
>
>
> Could you please check the horizon_error.log
>
>
>
> It should be under /var/log/apache2 or /var/log/httpd
>
>
>
> BR
>
>   Eyal
>
>
>
> On Wed, Oct 5, 2016 at 4:24 PM, Paul Vaduva  wrote:
>
> Hi Ifat,
>
>
>
> Thanks you for the reply. I saw that this is for build on a virtual
> environment. I was courios if there is a way to install it on a deployed
> horizon. I tried to adapt the instructions to install it on my existing
> horizon installation (maily not use
>
> ./horizon/tools/with_venv.sh and copy cp -a vitragedashboard/enabled/* and
> the vitrageclient/api/* to my existing  horizon installation and the
> dashboard apeared on my web browser but
>
> · For Topology tab I get this error *Error:* Unable to fetch the
> Vitrage Topology service.
>
> · For Alarms tab I get *Error:* Unable to fetch the Vitrage
> Alarms service.
>
> · For Entity Graph I get *Error:* Unable to fetch the Vitrage
> Topology service.
>
>
>
> Best Regards,
>
> Paul
>
>
>
>
>
> *From:* Afek, Ifat (Nokia - IL) [mailto:ifat.a...@nokia.com]
> *Sent:* Wednesday, October 05, 2016 1:15 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Vitrage] Installation
>
>
>
> Hi Paul,
>
>
>
> Please find the installation and configuration instructions here:
> https://github.com/openstack/vitrage/blob/master/
> doc/source/installation-and-configuration.rst
>
> Let us know if you have any other questions, we’ll be happy to help.
>
>
>
> Best regards,
>
> Ifat.
>
>
>
>
>
> *From: *Paul Vaduva
> *Reply-To: *"OpenStack Development Mailing List (not for usage questions)"
> *Date: *Tuesday, 4 October 2016 at 16:03
> *To: *"openstack-dev@lists.openstack.org"
> *Subject: *[openstack-dev] [Vitrage] Installation
>
>
>
> Hi everybody,
>
>
>
> I am writing you to ask for guidance with the installation of Vitrage.
>
> I have a deployed opnfv environment based on openstack mitaka release and
> I want to ask you how I would go about installing vitrage (with horizon) on
> this existing environment
>
>
>
>
>
> *Paul Ionut Vaduva*
>
> Software Engineer
>
> Linux Team
>
>
>
> *Email*  *paul.vad...@enea.com *
>
>
>
> *Enea R*
>
> 319 Splaiul Independentei, OB403A
>
> Bucharest, 060044
>
> *Phone*  +4021311 43 00
>
> *Fax *+402131143 01
>
>
>
>
>
> www.enea.com
>
>
>
> [image: cid:image002.png@01D00576.7D651240]
>
> This message, including attachments, is CONFIDENTIAL. It may also be
> privileged or otherwise protected by law. If you received this email by
> mistake please let us know by reply and then delete it from your system;
> you should not copy it or disclose its contents to anyone. All messages
> sent to and from Enea may be monitored to ensure compliance with internal
> policies and to protect our business. Emails are not secure and cannot be
> guaranteed to be error free as they can be intercepted, a mended, lost or
> destroyed, or contain viruses. The sender therefore does not accept
> liability for any errors or omissions in the contents of this message,
> which arise as a result of email transmission. Anyone who communicates with
> us by email accepts these risks.
>
>
>
>
> __
> 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] [glance][cinder][nova] zip for raw Disk Format

[Eric Harney]

On 10/05/2016 05:46 AM, Chen CH Ji wrote:
> 
> From [1] we support a few common and vendor specific disk format, as use
> raw image sometimes will be very big and do we have existing any method to
> consider zip the raw disk so the disk space might be saved as an option to
> offer to end user and admin  ? so something like [2] could be enhanced to
> support zipped format?
> Thanks
> 

The qcow2 format supports compression and is one of the most widely
supported image formats that can be used with OpenStack.

You can convert a raw image to qcow2 with:
 $ qemu-img convert -f raw -O qcow2 -c image.raw image.qcow2

And then upload image.qcow2 to Glance.

> [1] http://docs.openstack.org/developer/glance/formats.html
> [2]
> https://github.com/openstack/cinder/blob/master/cinder/image/image_utils.py#L182
> 
> Best Regards!
> 
> Kevin (Chen) Ji 纪 晨
> 
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
> Phone: +86-10-82454158
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
> Beijing 100193, PRC
> 


__
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] Installation

[Paul Vaduva]

Hi Eyal

I only get this warnings in horizon_error.log
http://hastebin.com/anewoyifey.sql

BR

From: Eyal B [mailto:eya...@gmail.com]
Sent: Wednesday, October 05, 2016 4:41 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Paul,

Could you please check the horizon_error.log

It should be under /var/log/apache2 or /var/log/httpd

BR
  Eyal

On Wed, Oct 5, 2016 at 4:24 PM, Paul Vaduva 
> wrote:
Hi Ifat,

Thanks you for the reply. I saw that this is for build on a virtual 
environment. I was courios if there is a way to install it on a deployed 
horizon. I tried to adapt the instructions to install it on my existing horizon 
installation (maily not use
./horizon/tools/with_venv.sh and copy cp -a vitragedashboard/enabled/* and the 
vitrageclient/api/* to my existing  horizon installation and the dashboard 
apeared on my web browser but

• For Topology tab I get this error Error: Unable to fetch the Vitrage 
Topology service.

• For Alarms tab I get Error: Unable to fetch the Vitrage Alarms 
service.

• For Entity Graph I get Error: Unable to fetch the Vitrage Topology 
service.

Best Regards,
Paul


From: Afek, Ifat (Nokia - IL) 
[mailto:ifat.a...@nokia.com]
Sent: Wednesday, October 05, 2016 1:15 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Paul,

Please find the installation and configuration instructions here: 
https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst
Let us know if you have any other questions, we’ll be happy to help.

Best regards,
Ifat.


From: Paul Vaduva
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, 4 October 2016 at 16:03
To: 
"openstack-dev@lists.openstack.org"
Subject: [openstack-dev] [Vitrage] Installation

Hi everybody,

I am writing you to ask for guidance with the installation of Vitrage.
I have a deployed opnfv environment based on openstack mitaka release and I 
want to ask you how I would go about installing vitrage (with horizon) on this 
existing environment


Paul Ionut Vaduva
Software Engineer
Linux Team

Email  paul.vad...@enea.com

Enea R
319 Splaiul Independentei, OB403A
Bucharest, 060044
Phone  +4021311 43 00
Fax +402131143 01


www.enea.com

[cid:image002.png@01D00576.7D651240]
This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.


__
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] [tacker] [networking-sfc] Removing required port-id from classifier

[Tim Rozet]

Thanks Igor! Anil and I can help test out real NSH support when we have the 
networking-odl driver finished.  That would be a good way to exercise that side 
of networking-sfc code.  Will look at these patches.

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "Duarte Cardoso, Igor" 
To: "OpenStack Development Mailing List (not for usage questions)" 
, "Cathy Zhang" 
Sent: Wednesday, October 5, 2016 6:06:02 AM
Subject: Re: [openstack-dev] [tacker] [networking-sfc] Removing required 
port-idfrom classifier

Hi Tim,

Just about the second part of your email:

> how are IETF SFC/NSH related API/plugin changes going?  
I'm essentially finished with NSH encap support [1], just have to fix a few 
bugs and write the tests. Then I will work on connecting port-chains together 
so we can have SFC graphs, kind of like IETF's branching/reclassification "SFC 
Encapsulation" chains (described with higher detail in the NSH draft).

> Can we expect to have attributes like path-id, encap type soon?  
The NSH patch I mentioned above will allow NSH encap to be specified for both 
port-chains and port-pairs and, if port-pairs do not support the port-chain's 
encapsulation, it's up to the driver to SFC-Proxy the traffic accordingly (OVS 
will install SFC-proxy flows, just like it does today by default, for MPLS). 
Regarding the path-id, I was working on a patch to facilitate that [2], but we 
ended up merging one focused only on enabling the path-id ("chain_id") [3]. So 
we have both attributes now.

[1] https://review.openstack.org/#/c/373465
[2] https://review.openstack.org/#/c/346175
[3] https://review.openstack.org/#/c/355336

Best regards,
Igor.

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Tuesday, October 4, 2016 6:07 PM
To: OpenStack Development Mailing List (not for usage questions) 
; Cathy Zhang 
Subject: [openstack-dev] [tacker] [networking-sfc] Removing required port-id 
from classifier

Hi Cathy,
I recall a while back discussing removing the required neutron port-id from the 
classifier.  We just finished up implementing VNFFG in Tacker and are hitting 
this while testing.  What is the plan to remove this requirement?  Also, how 
are IETF SFC/NSH related API/plugin changes going?  Can we expect to have 
attributes like path-id, encap type soon?  

Thanks,

Tim Rozet
Red Hat SDN Team

__
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] [Vitrage] Installation

[Eyal B]

Hi Paul,

Could you please check the horizon_error.log

It should be under /var/log/apache2 or /var/log/httpd

BR
  Eyal

On Wed, Oct 5, 2016 at 4:24 PM, Paul Vaduva  wrote:

> Hi Ifat,
>
>
>
> Thanks you for the reply. I saw that this is for build on a virtual
> environment. I was courios if there is a way to install it on a deployed
> horizon. I tried to adapt the instructions to install it on my existing
> horizon installation (maily not use
>
> ./horizon/tools/with_venv.sh and copy cp -a vitragedashboard/enabled/* and
> the vitrageclient/api/* to my existing  horizon installation and the
> dashboard apeared on my web browser but
>
> · For Topology tab I get this error *Error:* Unable to fetch the
> Vitrage Topology service.
>
> · For Alarms tab I get *Error:* Unable to fetch the Vitrage
> Alarms service.
>
> · For Entity Graph I get *Error:* Unable to fetch the Vitrage
> Topology service.
>
>
>
> Best Regards,
>
> Paul
>
>
>
>
>
> *From:* Afek, Ifat (Nokia - IL) [mailto:ifat.a...@nokia.com]
> *Sent:* Wednesday, October 05, 2016 1:15 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Vitrage] Installation
>
>
>
> Hi Paul,
>
>
>
> Please find the installation and configuration instructions here:
> https://github.com/openstack/vitrage/blob/master/
> doc/source/installation-and-configuration.rst
>
> Let us know if you have any other questions, we’ll be happy to help.
>
>
>
> Best regards,
>
> Ifat.
>
>
>
>
>
> *From: *Paul Vaduva
> *Reply-To: *"OpenStack Development Mailing List (not for usage questions)"
> *Date: *Tuesday, 4 October 2016 at 16:03
> *To: *"openstack-dev@lists.openstack.org"
> *Subject: *[openstack-dev] [Vitrage] Installation
>
>
>
> Hi everybody,
>
>
>
> I am writing you to ask for guidance with the installation of Vitrage.
>
> I have a deployed opnfv environment based on openstack mitaka release and
> I want to ask you how I would go about installing vitrage (with horizon) on
> this existing environment
>
>
>
>
>
> *Paul Ionut Vaduva*
>
> Software Engineer
>
> Linux Team
>
>
>
> *Email*  *paul.vad...@enea.com *
>
>
>
> *Enea R*
>
> 319 Splaiul Independentei, OB403A
>
> Bucharest, 060044
>
> *Phone*  +4021311 43 00
>
> *Fax *+402131143 01
>
>
>
>
>
> www.enea.com
>
>
>
> [image: cid:image002.png@01D00576.7D651240]
>
> This message, including attachments, is CONFIDENTIAL. It may also be
> privileged or otherwise protected by law. If you received this email by
> mistake please let us know by reply and then delete it from your system;
> you should not copy it or disclose its contents to anyone. All messages
> sent to and from Enea may be monitored to ensure compliance with internal
> policies and to protect our business. Emails are not secure and cannot be
> guaranteed to be error free as they can be intercepted, a mended, lost or
> destroyed, or contain viruses. The sender therefore does not accept
> liability for any errors or omissions in the contents of this message,
> which arise as a result of email transmission. Anyone who communicates with
> us by email accepts these risks.
>
>
>
>
> __
> 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] [Vitrage] Installation

[Yujun Zhang]

Hi, Paul,

You may check whether all required services have been started normally.
Below is the example output from an instance created by
https://github.com/openzero-zte/vitrage-demo

The topology service is on `vitrage-graph` while the alarm service is on
`vitrage-notifier` if I understand it correctly.

ubuntu@vitrage-demo:~$ ps aux|grep vitrage
stack 5737  0.0  0.0 250496  5704 ?Sl   Oct02   0:08
(wsgi:vitrage-api -k start
stack 5738  0.0  0.0 250488  5704 ?Sl   Oct02   0:08
(wsgi:vitrage-api -k start
stack 7634  2.3  0.9 398724 74364 pts/25   S+   Aug30 1209:08
/usr/bin/python /usr/local/bin/vitrage-graph --config-file
/etc/vitrage/vitrage.conf
stack 8000  0.0  0.8 397696 70196 pts/25   S+   Aug30   3:16
/usr/bin/python /usr/local/bin/vitrage-graph --config-file
/etc/vitrage/vitrage.conf
stack 8001  0.0  0.8 399256 72144 pts/25   S+   Aug30  20:25
/usr/bin/python /usr/local/bin/vitrage-graph --config-file
/etc/vitrage/vitrage.conf
stack 8002  0.0  0.9 403712 76720 pts/25   S+   Aug30   3:55
/usr/bin/python /usr/local/bin/vitrage-graph --config-file
/etc/vitrage/vitrage.conf
stack 8003  0.0  0.8 397952 70676 pts/25   S+   Aug30   2:27
/usr/bin/python /usr/local/bin/vitrage-graph --config-file
/etc/vitrage/vitrage.conf
stack 8116  0.0  0.5 190668 43208 pts/26   Sl+  Aug30   1:17
/usr/bin/python /usr/local/bin/vitrage-notifier --config-file
/etc/vitrage/vitrage.conf
rabbitmq 25657  1.0  1.6 2344552 133980 ?  Sl   Aug30 559:24
/usr/lib/erlang/erts-5.10.4/bin/beam.smp -W w -K true -A30 -P 1048576 --
-root /usr/lib/erlang -progname erl -- -home /var/lib/rabbitmq -- -pa
/usr/lib/rabbitmq/lib/rabbitmq_server-3.2.4/sbin/../ebin -noshell -noinput
-s rabbit boot -sname rabbit@vitrage-demo -boot start_sasl -kernel
inet_default_connect_options [{nodelay,true}] -sasl errlog_type error -sasl
sasl_error_logger false -rabbit error_logger
{file,"/var/log/rabbitmq/rab...@vitrage-demo.log"} -rabbit
sasl_error_logger {file,"/var/log/rabbitmq/rab...@vitrage-demo-sasl.log"}
-rabbit enabled_plugins_file "/etc/rabbitmq/enabled_plugins" -rabbit
plugins_dir "/usr/lib/rabbitmq/lib/rabbitmq_server-3.2.4/sbin/../plugins"
-rabbit plugins_expand_dir
"/var/lib/rabbitmq/mnesia/rabbit@vitrage-demo-plugins-expand" -os_mon
start_cpu_sup false -os_mon start_disksup false -os_mon start_memsup false
-mnesia dir "/var/lib/rabbitmq/mnesia/rabbit@vitrage-demo"


On Wed, Oct 5, 2016 at 9:32 PM Paul Vaduva  wrote:

> Hi Ifat,
>
>
>
> Thanks you for the reply. I saw that this is for build on a virtual
> environment. I was courios if there is a way to install it on a deployed
> horizon. I tried to adapt the instructions to install it on my existing
> horizon installation (maily not use
>
> ./horizon/tools/with_venv.sh and copy cp -a vitragedashboard/enabled/* and
> the vitrageclient/api/* to my existing  horizon installation and the
> dashboard apeared on my web browser but
>
> · For Topology tab I get this error *Error:* Unable to fetch the
> Vitrage Topology service.
>
> · For Alarms tab I get *Error:* Unable to fetch the Vitrage
> Alarms service.
>
> · For Entity Graph I get *Error:* Unable to fetch the Vitrage
> Topology service.
>
>
>
> Best Regards,
>
> Paul
>
>
>
>
>
> *From:* Afek, Ifat (Nokia - IL) [mailto:ifat.a...@nokia.com]
> *Sent:* Wednesday, October 05, 2016 1:15 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Vitrage] Installation
>
>
>
> Hi Paul,
>
>
>
> Please find the installation and configuration instructions here:
> https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst
>
> Let us know if you have any other questions, we’ll be happy to help.
>
>
>
> Best regards,
>
> Ifat.
>
>
>
>
>
> *From: *Paul Vaduva
> *Reply-To: *"OpenStack Development Mailing List (not for usage questions)"
> *Date: *Tuesday, 4 October 2016 at 16:03
> *To: *"openstack-dev@lists.openstack.org"
> *Subject: *[openstack-dev] [Vitrage] Installation
>
>
>
> Hi everybody,
>
>
>
> I am writing you to ask for guidance with the installation of Vitrage.
>
> I have a deployed opnfv environment based on openstack mitaka release and
> I want to ask you how I would go about installing vitrage (with horizon) on
> this existing environment
>
>
>
>
>
> *Paul Ionut Vaduva*
>
> Software Engineer
>
> Linux Team
>
>
>
> *Email*  *paul.vad...@enea.com *
>
>
>
> *Enea R*
>
> 319 Splaiul Independentei, OB403A
>
> Bucharest, 060044
>
> *Phone*  +4021311 43 00
>
> *Fax *+402131143 01
>
>
>
>
>
> www.enea.com
>
>
>
> [image: cid:image002.png@01D00576.7D651240]
>
> This message, including attachments, is CONFIDENTIAL. It may also be
> privileged or otherwise protected by law. If you received this email by
> mistake please let us know by reply and then delete it from your system;
> you should not copy it or disclose its contents 

Re: [openstack-dev] [Vitrage] Installation

[Weyl, Alexey (Nokia - IL)]

Hi,

When you say notification in Zabbix, do you mean a new trigger in Zabbix?

If yes, then if you have configured the auxiliary Zabbix script successfully 
then the script should recognize any trigger raised in zabbix and send the 
trigger notification on the oslo bus.

Best Regards,
Alexey

From: lương hữu tuấn [mailto:tuantulu...@gmail.com]
Sent: Wednesday, October 05, 2016 4:13 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] Installation

Hi,

I have another question based on the getting information of vitrage from 
monitoring solution. As i see that we have the default one now is nagios and 
with the zabbix, we just have only the script that gets information from zabbix 
as below:
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/zabbix/auxiliary/zabbix_vitrage.py

If yes as above, so all the things like structure of zabbix notification, what 
if i create a new notification in zabbix, can vitrage understand it?

Br,

Tutj

On Wed, Oct 5, 2016 at 12:15 PM, Afek, Ifat (Nokia - IL) 
> wrote:
Hi Paul,

Please find the installation and configuration instructions here: 
https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst
Let us know if you have any other questions, we’ll be happy to help.

Best regards,
Ifat.


From: Paul Vaduva
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, 4 October 2016 at 16:03
To: 
"openstack-dev@lists.openstack.org"
Subject: [openstack-dev] [Vitrage] Installation

Hi everybody,

I am writing you to ask for guidance with the installation of Vitrage.
I have a deployed opnfv environment based on openstack mitaka release and I 
want to ask you how I would go about installing vitrage (with horizon) on this 
existing environment


Paul Ionut Vaduva
Software Engineer
Linux Team

Email  paul.vad...@enea.com

Enea R
319 Splaiul Independentei, OB403A
Bucharest, 060044
Phone  +4021311 43 00
Fax +402131143 01


www.enea.com

[cid:image002.png@01D00576.7D651240]
This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.


__
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] [ironic][docs] What is the policy for backporting docs changes to stable branches?

[Jim Rollenhagen]

On Wed, Oct 5, 2016 at 9:00 AM, Luigi Toscano  wrote:
> On Wednesday, 5 October 2016 15:31:50 CEST Pavlo Shchelokovskyy wrote:
>> Hi all,
>>
>> lately I realized that docs for two of the features I was working on during
>> Newton cycle are absent from Ironic's new install guide [0]. This is my
>> fault, and I am sorry for missing that out. Currently I am working on
>> adding those pieces.
>>
>> [...]
>>
>> Given the above, should those doc amendments be proposed as backports to
>> stable/newton once they are merged in master? What is the general policy
>> for backporting documentation amendments/fixes?
>
> The general rules are:
> http://docs.openstack.org/project-team-guide/stable-branches.html
>
> "Note - It’s nevertheless allowed to backport fixes for other bugs if their
> safety can be easily proved. For example, documentation fixes, debug log
> message typo corrections, test only changes, patches that enhance test
> coverage, configuration file content fixes can apply to all supported
> branches. For those types of backports, stable maintainers will decide on case
> by case basis. "
>
> I would consider "missing documentation for a(n important) feature" as a bug,
> and I would try to backport it - at least for the project I'm involved in
> (Sahara).

+1, ironic has been okay with backporting docs changes for a while
now. Do it! :)

// jim

__
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] Installation

[Paul Vaduva]

Hi Ifat,

Thanks you for the reply. I saw that this is for build on a virtual 
environment. I was courios if there is a way to install it on a deployed 
horizon. I tried to adapt the instructions to install it on my existing horizon 
installation (maily not use
./horizon/tools/with_venv.sh and copy cp -a vitragedashboard/enabled/* and the 
vitrageclient/api/* to my existing  horizon installation and the dashboard 
apeared on my web browser but

· For Topology tab I get this error Error: Unable to fetch the Vitrage 
Topology service.

· For Alarms tab I get Error: Unable to fetch the Vitrage Alarms 
service.

· For Entity Graph I get Error: Unable to fetch the Vitrage Topology 
service.

Best Regards,
Paul


From: Afek, Ifat (Nokia - IL) [mailto:ifat.a...@nokia.com]
Sent: Wednesday, October 05, 2016 1:15 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Vitrage] Installation

Hi Paul,

Please find the installation and configuration instructions here: 
https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst
Let us know if you have any other questions, we’ll be happy to help.

Best regards,
Ifat.


From: Paul Vaduva
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, 4 October 2016 at 16:03
To: 
"openstack-dev@lists.openstack.org"
Subject: [openstack-dev] [Vitrage] Installation

Hi everybody,

I am writing you to ask for guidance with the installation of Vitrage.
I have a deployed opnfv environment based on openstack mitaka release and I 
want to ask you how I would go about installing vitrage (with horizon) on this 
existing environment


Paul Ionut Vaduva
Software Engineer
Linux Team

Email  paul.vad...@enea.com

Enea R
319 Splaiul Independentei, OB403A
Bucharest, 060044
Phone  +4021311 43 00
Fax +402131143 01


www.enea.com

[cid:image002.png@01D00576.7D651240]
This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.

__
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] Installation

[lương hữu tuấn]

Hi,

I have another question based on the getting information of vitrage from
monitoring solution. As i see that we have the default one now is nagios
and with the zabbix, we just have only the script that gets information
from zabbix as below:
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/zabbix/auxiliary/zabbix_vitrage.py

If yes as above, so all the things like structure of zabbix notification,
what if i create a new notification in zabbix, can vitrage understand it?

Br,

Tutj

On Wed, Oct 5, 2016 at 12:15 PM, Afek, Ifat (Nokia - IL) <
ifat.a...@nokia.com> wrote:

> Hi Paul,
>
> Please find the installation and configuration instructions here:
> https://github.com/openstack/vitrage/blob/master/
> doc/source/installation-and-configuration.rst
> Let us know if you have any other questions, we’ll be happy to help.
>
> Best regards,
> Ifat.
>
>
> From: Paul Vaduva
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> Date: Tuesday, 4 October 2016 at 16:03
> To: "openstack-dev@lists.openstack.org"
> Subject: [openstack-dev] [Vitrage] Installation
>
> Hi everybody,
>
>
>
> I am writing you to ask for guidance with the installation of Vitrage.
>
> I have a deployed opnfv environment based on openstack mitaka release and
> I want to ask you how I would go about installing vitrage (with horizon) on
> this existing environment
>
>
>
>
>
> *Paul Ionut Vaduva*
>
> Software Engineer
>
> Linux Team
>
>
>
> *Email*  *paul.vad...@enea.com *
>
>
>
> *Enea R*
>
> 319 Splaiul Independentei, OB403A
>
> Bucharest, 060044
>
> *Phone*  +4021311 43 00
>
> *Fax *+402131143 01
>
>
>
>
>
> www.enea.com
>
>
>
> [image: cid:image002.png@01D00576.7D651240]
>
> This message, including attachments, is CONFIDENTIAL. It may also be
> privileged or otherwise protected by law. If you received this email by
> mistake please let us know by reply and then delete it from your system;
> you should not copy it or disclose its contents to anyone. All messages
> sent to and from Enea may be monitored to ensure compliance with internal
> policies and to protect our business. Emails are not secure and cannot be
> guaranteed to be error free as they can be intercepted, a mended, lost or
> destroyed, or contain viruses. The sender therefore does not accept
> liability for any errors or omissions in the contents of this message,
> which arise as a result of email transmission. Anyone who communicates with
> us by email accepts these risks.
>
>
>
>
> __
> 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] [all] Why do we have project specific hacking rules?

[Tony Breeds]

On Wed, Oct 05, 2016 at 07:56:15AM -0500, Ian Cordasco wrote:

> So hacking doesn't push out to anyone. It's one of the projects that doesn't
> get updated by global-requirements updates, if I remember correctly.

Just clarifying/confirming what Ian says.

The proposal-bot does not generate updates to projects *requirements.txt.  It's
up to the projects to do that themselves.

Having said that it *could* all the code is there but it was disabled for a 
reason.

Yours Tony.


signature.asc
Description: PGP 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] [ironic][docs] What is the policy for backporting docs changes to stable branches?

[Luigi Toscano]

On Wednesday, 5 October 2016 15:31:50 CEST Pavlo Shchelokovskyy wrote:
> Hi all,
> 
> lately I realized that docs for two of the features I was working on during
> Newton cycle are absent from Ironic's new install guide [0]. This is my
> fault, and I am sorry for missing that out. Currently I am working on
> adding those pieces.
> 
> [...]
> 
> Given the above, should those doc amendments be proposed as backports to
> stable/newton once they are merged in master? What is the general policy
> for backporting documentation amendments/fixes?

The general rules are: 
http://docs.openstack.org/project-team-guide/stable-branches.html

"Note - It’s nevertheless allowed to backport fixes for other bugs if their 
safety can be easily proved. For example, documentation fixes, debug log 
message typo corrections, test only changes, patches that enhance test 
coverage, configuration file content fixes can apply to all supported 
branches. For those types of backports, stable maintainers will decide on case 
by case basis. "

I would consider "missing documentation for a(n important) feature" as a bug, 
and I would try to backport it - at least for the project I'm involved in 
(Sahara).

-- 
Luigi

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

Re: [openstack-dev] [all] Why do we have project specific hacking rules?

[Ian Cordasco]

 

-Original Message-
From: Sean Dague 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: October 5, 2016 at 07:04:17
To: openstack-dev@lists.openstack.org 
Subject:  Re: [openstack-dev] [all] Why do we have project specific hacking 
rules?

> On 10/03/2016 03:01 AM, Ihar Hrachyshka wrote:
> > Andrew Laski wrote:
> >>
> >> A further hindrance to moving these checks to be OpenStack wide is that
> >> each check violation is a failure. So in order to roll a new check out
> >> across projects it requires a lot of churn in each project which
> >> violates the checks. I would prefer to leave it up to each project to
> >> make the decision to incorporate a new check and take the review load.
> >> Ultimately what I think sounds good would be a central listing of checks
> >> that are in use across projects and then leave it up to each project to
> >> replicate those that they like.
> >
> > Late flake8 releases support off_by_default decorator that allows to add
> > checks that are not triggered unless explicitly enabled in tox.ini with
> > select= directive. That should allow to maintain code in single place
> > while still having projects to opt-in new checks.
>  
> There could definitely be an effort to move more content up into hacking
> proper. It would require some genericizing and need folks focused on it.
>  
> One of the challenges is realizing that hacking updates push out to 50+
> projects. The project specific checks are often things where people have
> gotten the point of getting bored -1ing people for the same issues over
> and over again. Or using hacking a bit as a light weight unit test to
> make sure certain code doesn't exist (all those "don't use this code"
> checks).

So hacking doesn't push out to anyone. It's one of the projects that doesn't 
get updated by global-requirements updates, if I remember correctly.

> Joe Gordon used to be pretty aggressive in moving these checks up into
> hacking when they seemed to get enough concensus. But since he left the
> community, there has been less push on this.

The other problem with this is two-fold:

1. As one of the few people reviewing Hacking with more than a "The code looks 
good" point of view, it would be nice to have people from different projects 
affirming that more than one project would like the check in Hacking.

2. I'm not actually paid to work on Hacking or much upstream. What time I use 
to work on Hacking is my free time and that's already over-utilized.

If people think that absorbing all project-specific rules into Hacking is 
really that beneficial, I'd expect them to start participating a lot more 
actively in reviews of those changes. I won't have the time to pull down each 
one and verify it works as expected and won't break projects if it is enabled.

--  
Ian Cordasco


__
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] Newton packages for openSUSE and SLES available

[Thomas Bechtold]

Hi,

Newton packages for openSUSE and SLES are now available at:

http://download.opensuse.org/repositories/Cloud:/OpenStack:/Newton/

We currently maintain + test the packages for SLE 12SP2 and openSUSE
Leap 42.2.

If you find issues, please do not hesitate to report them to
opensuse-cloud at opensuse.org or to https://bugzilla.opensuse.org/

Thanks!

Have a lot of fun,

Tom

__
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] [ironic][docs] What is the policy for backporting docs changes to stable branches?

[Pavlo Shchelokovskyy]

Hi all,

lately I realized that docs for two of the features I was working on during
Newton cycle are absent from Ironic's new install guide [0]. This is my
fault, and I am sorry for missing that out. Currently I am working on
adding those pieces.

The two omissions I am worried about are:

- booting iPXE nodes directly from object storage [1] (already merged to
master)
- proper way of configuring auth info for service clients [2] (on review)

AFAIU the install guide is release-specific and the /newton/ version is
built and published from stable/newton branch. While not having the former
of two patches above in stable release docs is probably no big deal (new
feature), configuring service user auth as currently advised by Ironic's
Newton install guide will work but result in a deprecation warning log
message, which I would find strange having just set Ironic up the
recommended way.

Given the above, should those doc amendments be proposed as backports to
stable/newton once they are merged in master? What is the general policy
for backporting documentation amendments/fixes?

[0] http://docs.openstack.org/project-install-guide/baremetal/newton/
[1] https://review.openstack.org/#/c/379358/
[2] https://review.openstack.org/#/c/382358/

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.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] [tc] open question to the candidates

[Amrith Kumar]

Gordon,

You also asked for specific examples of things that candidates would like the 
TC to address in the coming year and I missed that.

Over the past several months there have been several independent threads that 
have called into question the 'leadership' that the TC has brought. There have 
been voices on both sides of this; the voices that say the TC doesn't do 
enough, and (when the TC does) voices that say the TC does too much. This is 
clearly a contentious area, but one that needs some attention.

I am therefore heartened that the TC did take the positive step of trying to 
gets its membership to attend a training session (and I was lucky to be able to 
attend that as well) and try and understand how the TC should lead. The model 
of leadership (Stewardship/Servant Leadership) is one that is well suited to 
the particular situation that the TC finds itself in. So item #1 on the list of 
things that I'd like the TC to take up as a priority in the next year is to 
further understand this model of leadership and make specific changes to the 
way(s) in which it does things to better serve the community; that is the very 
essence of Stewardship.

I'll also put in a shameless plug for a session[1] at Barcelona that I'll be 
moderating; Monty, Thierry, Colette Alexander and Doug Hellmann will be the 
panelists and we will be talking about this. 

The second thing that I would like the TC to actively advance is something that 
Doug Hellmann proposed recently, the notion of project wide series goals. I 
believe that it is one aspect of making OpenStack more cohesive, and better and 
easier for deployers and end users. Usability by deployers and end users has 
been a frequent complaint about OpenStack and I think this initiative will go a 
long way to improving that. The discussions around the idea (that I expected 
would be relatively non-controversial) regarding python is a microcosm of the 
kind(s) of challenges that come with leading a diverse community and I think 
improvements on the leadership model (above) will help drive these common and 
broad based improvements across OpenStack, things that are sorely needed if we 
don't want OpenStack to fragment into a number of disjointed projects.

As I was reading news on my RSS Feed yesterday, I happened upon a question "Do 
I need to install a installation of a sump pump?" I kid you not. When I clicked 
on the link, the question appeared to have been deleted. But there was a 
fleeting moment when I felt that I had missed the announcement of a new 
OpenStack project "sump pump". The big tent is a great thing, it did much of 
what it was intended to do but I'm not sure that the end result was completely 
predicted. I have some reservations about the end result of the Big Tent from 
the perspective of end-users and deployers.

Which brings me to the third thing, I believe that the TC must lead the 
discussion of "What is OpenStack" and I realize that there are those who 
believe that it is a single 'product' and those that feel that it is a loose 
federation of projects. In the conversation I have heard much of what OpenStack 
"never was" from people who have been associated with OpenStack from the time 
when it was 3 lines of code or during the first meetings that discussed it. 
Well, this is now six or more years later, and it is possible that the time has 
come for OpenStack to change.

In the department of things that I'd like the TC to do proactively, I see "big 
things", things which set vision, things that set the course, things that set 
the overall direction of OpenStack.

Sorry for missing this part of the question the first time around, and thanks 
for asking this question. I hope that in future election cycles we can have 
this conversation in a more robust way, and potentially not in a format that is 
squeezed for time.

Thanks,

-amrith

[1] 
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/15243/stewardship-bringing-more-leadership-and-vision-to-openstack


> -Original Message-
> From: Amrith Kumar [mailto:amr...@tesora.com]
> Sent: Monday, October 03, 2016 12:33 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [tc] open question to the candidates
> 
> 
> 
> > -Original Message-
> > From: gordon chung [mailto:g...@live.ca]
> > Sent: Monday, October 03, 2016 11:31 AM
> > To: openstack-dev@lists.openstack.org
> > Subject: [openstack-dev] [tc] open question to the candidates
> >
> > hi,
> >
> > as there are many candidates this TC election, i figured i'd ask a
> > question to better understand the candidates from the usual sales pitch
> > in self-nominations. hopefully, this will give some insights into the
> > candidates for those who haven't voted yet. obviously, the following is
> > completely optional. :)
> >
> > i initially asked this to John Dickinson[1] in his self-nomination. i'd
> > like to open this up to 

Re: [openstack-dev] [all] Why do we have project specific hacking rules?

[Sean Dague]

On 10/03/2016 03:01 AM, Ihar Hrachyshka wrote:
> Andrew Laski  wrote:
>>
>> A further hindrance to moving these checks to be OpenStack wide is that
>> each check violation is a failure. So in order to roll a new check out
>> across projects it requires a lot of churn in each project which
>> violates the checks. I would prefer to leave it up to each project to
>> make the decision to incorporate a new check and take the review load.
>> Ultimately what I think sounds good would be a central listing of checks
>> that are in use across projects and then leave it up to each project to
>> replicate those that they like.
> 
> Late flake8 releases support off_by_default decorator that allows to add
> checks that are not triggered unless explicitly enabled in tox.ini with
> select= directive. That should allow to maintain code in single place
> while still having projects to opt-in new checks.

There could definitely be an effort to move more content up into hacking
proper. It would require some genericizing and need folks focused on it.

One of the challenges is realizing that hacking updates push out to 50+
projects. The project specific checks are often things where people have
gotten the point of getting bored -1ing people for the same issues over
and over again. Or using hacking a bit as a light weight unit test to
make sure certain code doesn't exist (all those "don't use this code"
checks).

Joe Gordon used to be pretty aggressive in moving these checks up into
hacking when they seemed to get enough concensus. But since he left the
community, there has been less push on this.

-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

Re: [openstack-dev] [Keystone] Project name DB length

[Sean Dague]

On 10/03/2016 10:52 AM, gordon chung wrote:
> 
> 
> On 28/09/2016 11:52 PM, Adrian Turjak wrote:
>>
>> Plus although there is no true official standard, most projects in
>> OpenStack seem to use 255 as the default for a lot of string fields.
>> Weirdly enough, a lot of projects seem to use 255 even for project.id,
>> which seeing as it's 64 in keystone, and a uuid4 anyway, seems like a
>> bit of a waste.
> 
> this was brought up a year ago[1] as a broader issue in OpenStack. 255 
> bytes for id is weird especially as you mentioned if it's only a uuid. 
> but yeah, Morgan's reply might reflect why you it is a length of 255.
> 
> the original thread died pretty quickly; it didn't seem like an issue to 
> anyone or needed fixing... if only there was a global council that 
> worked on such technical things :P
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/068104.html
> 
> cheers,

Except... the 64 char field in keystone isn't required to be a uuid4.
Which we ran into when attempting to remove it from the URLs in Nova.
There is no validation anywhere that requires that of keystone values.

For instance, Rackspace uses ints.

Yes this is debt. And yes, a few things would be nicer if this was more
constrained, but as was recently stated on twitter, we've been calling
the 9th month the seventh month for 2000 years -
https://twitter.com/GonzoHacker/status/781890649444519937. Some times
the cost of fixing the thing really just isn't worth the potential
breaks to operators that were operating within the old constraints fine.

-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

Re: [openstack-dev] [tc] open question to the candidates

[Sean Dague]

On 10/03/2016 11:30 AM, gordon chung wrote:
> hi,
> 
> as there are many candidates this TC election, i figured i'd ask a 
> question to better understand the candidates from the usual sales pitch 
> in self-nominations. hopefully, this will give some insights into the 
> candidates for those who haven't voted yet. obviously, the following is 
> completely optional. :)
> 
> i initially asked this to John Dickinson[1] in his self-nomination. i'd 
> like to open this up to everyone. the (re-worded) question is:
> 
> the TC has historically been a reactive council that lets others ask for 
> change and acts as the final approver. do you believe the TC should be a 
> proactive committee that initiates change and if yes, to what scope? 
> more generally, what are some specific issues you'd like the TC address 
> in the coming year?
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2016-September/104821.html
> 
> thanks,
> 

Does a committee initiate change? or do dedicated individuals? I feel
like there are a ton of dedicated individuals within our community (many
on the TC, but 13 slots is not enough to cover how many dedicated folks
there are). They are constantly doing hard and good work to make our
community move forward.

I feel like the role of the TC, as a group that votes and controls the
governance, is mostly about making sure that all these really great
efforts aren't negatively impacting the long term viability of the
OpenStack community. The TC really is stewards of that community. The
community is what produces the software we have, supports our users, and
helps mentor folks into the environment.

There is tons of work to be done in Open Stack. Probably 80% of it is
non controversial. I often feel like the implicit part of the ask is
that the energy of the folks on the TC is spent on the most
controversial 5%, where our plurality shows, and we as a community are
not of one mind. It assumes that where we disagree is the most important
parts of how the community moves forward. But that's often not true.
Often the thing holding us back isn't that, it's other things where we
see folks struggling.

A couple of good instances that I've been involved in are things like
the devstack plugin interface, where lots of projects needed to build
their own custom full stack environments, way more than devstack code
support in tree. A few of us identified the friction, came up with a
solution, brought it to the community. The same with the recent API ref
effort. There was huge friction around API documentation, that meant our
users basically had to read our source code to write an application. At
which point the API is nearly pointless. A couple of us (2 from the TC)
identified the issue, spitballed options, figured out a path forward.
And it's been a huge success.

Now, people may say, those don't sound like giant strategic sweeping
direction changes. And they aren't. We we have to be careful not to
assume that flashy controversial work is the most important work to be
done. We're trying to building an ecosystem here. And an ecosystem isn't
just pretty flowers, and juicy tomatoes. It's grubs, and dirt, and
compost, and weeds, and worms, and bees, and lots of hard work creating
fertile soil to get the best results.

Ok, so there are still controversial issues, which we do need to have a
way through. Handling those kind of issues requires trust and the
benefit of the doubt. At times, recently, it doesn't feel like we have
enough of it. One thought I have had about moving us forward is to take
some time this next cycle on visions of OpenStack. Not a top down
version of this, but a TC led exercise where we get lots of people in
our community to write down their visions, and feel safe doing it. This
was really how we got to the Big Tent. At the time there was a bit of
deriding about "all the blogs" where people were expressing themselves.
But it was a really useful exercise, because you got lots of
perspectives out there. And, it turns out, they agreed on about 80% of
the changes we needed, and where we didn't agree we were able to move
forward knowing we were looking at shades of the same thing.

Maybe I'm overly optimistic there, but we as a community also need to
realize the amazing thing that we've built so far. And the fact that
we've build a community that is going strong, despite many of the
founding members having moved on.

-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

Re: [openstack-dev] [Vitrage] Installation

[Afek, Ifat (Nokia - IL)]

Hi Paul,

Please find the installation and configuration instructions here: 
https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst
Let us know if you have any other questions, we’ll be happy to help.

Best regards,
Ifat.


From: Paul Vaduva
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, 4 October 2016 at 16:03
To: 
"openstack-dev@lists.openstack.org"
Subject: [openstack-dev] [Vitrage] Installation

Hi everybody,

I am writing you to ask for guidance with the installation of Vitrage.
I have a deployed opnfv environment based on openstack mitaka release and I 
want to ask you how I would go about installing vitrage (with horizon) on this 
existing environment


Paul Ionut Vaduva
Software Engineer
Linux Team

Email  paul.vad...@enea.com

Enea R
319 Splaiul Independentei, OB403A
Bucharest, 060044
Phone  +4021311 43 00
Fax +402131143 01


www.enea.com

[cid:image002.png@01D00576.7D651240]
This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.

__
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] [mistral] Don't use Scheduler to run actions

[Renat Akhmerov]

Hi Team,

I posted a bug [1] at Launchpad that is pretty important for many reasons. I 
tried to put all needed information into
the bug description providing pros and cons of using Scheduler for running 
actions. I short, I’d like to remove
Scheduler from the chain that leads to running an action on executor for 
performance reason (~30% difference
on large workflows, from my experience). I decided to bring it up to a 
discussion here because I may be
missing something and am very interested in your opinions. Please let me know 
if you have any additional
arguments to those I provided in the bug.

[1] https://bugs.launchpad.net/mistral/+bug/1630508 


Thanks

Renat Akhmerov
@Nokia

__
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] [tacker] [networking-sfc] Removing required port-id from classifier

[Duarte Cardoso, Igor]

Hi Tim,

Just about the second part of your email:

> how are IETF SFC/NSH related API/plugin changes going?  
I'm essentially finished with NSH encap support [1], just have to fix a few 
bugs and write the tests. Then I will work on connecting port-chains together 
so we can have SFC graphs, kind of like IETF's branching/reclassification "SFC 
Encapsulation" chains (described with higher detail in the NSH draft).

> Can we expect to have attributes like path-id, encap type soon?  
The NSH patch I mentioned above will allow NSH encap to be specified for both 
port-chains and port-pairs and, if port-pairs do not support the port-chain's 
encapsulation, it's up to the driver to SFC-Proxy the traffic accordingly (OVS 
will install SFC-proxy flows, just like it does today by default, for MPLS). 
Regarding the path-id, I was working on a patch to facilitate that [2], but we 
ended up merging one focused only on enabling the path-id ("chain_id") [3]. So 
we have both attributes now.

[1] https://review.openstack.org/#/c/373465
[2] https://review.openstack.org/#/c/346175
[3] https://review.openstack.org/#/c/355336

Best regards,
Igor.

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Tuesday, October 4, 2016 6:07 PM
To: OpenStack Development Mailing List (not for usage questions) 
; Cathy Zhang 
Subject: [openstack-dev] [tacker] [networking-sfc] Removing required port-id 
from classifier

Hi Cathy,
I recall a while back discussing removing the required neutron port-id from the 
classifier.  We just finished up implementing VNFFG in Tacker and are hitting 
this while testing.  What is the plan to remove this requirement?  Also, how 
are IETF SFC/NSH related API/plugin changes going?  Can we expect to have 
attributes like path-id, encap type soon?  

Thanks,

Tim Rozet
Red Hat SDN Team

__
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] [ceilometer] ceilometer liberty detect instance creation

[Raghunath D]

Hi,

Please launch an instance using openstack dashboard or nova boot command and 
check once again "ceilometer meter-list".

With Best Regards
 Raghunath Dudyala
 Tata Consultancy Services Limited
 Mailto: raghunat...@tcs.com
 Website: http://www.tcs.com
 
 Experience certainty.  IT Services
Business Solutions
Consulting
 
 

-Yue Xin  wrote: -
To: "OpenStack Development Mailing List (not for usage questions)" 

From: Yue Xin 
Date: 10/04/2016 07:53PM
Subject: [openstack-dev] [ceilometer] ceilometer liberty detect instance
creation

Hi all,

I have installed the ceilometer liberty version. but when i use the command 
"ceilometer meter-list" there is no "instance.creation" "network.creation" 
appears(which can be detected on mitaka version), may i ask is this because of 
the version limit? Or there is some configuration file should be modified in 
order to be able to detect?

Thanks a lot.

Regards,
Yue  
__
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
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


__
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][cinder][nova] zip for raw Disk Format

[Chen CH Ji]

From [1] we support a few common and vendor specific disk format, as use
raw image sometimes will be very big and do we have existing any method to
consider zip the raw disk so the disk space might be saved as an option to
offer to end user and admin  ? so something like [2] could be enhanced to
support zipped format?
Thanks

[1] http://docs.openstack.org/developer/glance/formats.html
[2]
https://github.com/openstack/cinder/blob/master/cinder/image/image_utils.py#L182

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Ocata Design Summit ideas kick-off

[Carlos Gonçalves]

Hi Armando,

I'm not sure whether the team has already scheduled sessions for the design
summit.

I've added a topic to the list -- the usual suspect: discussion on status
and admin_state_up resource states...
I hope we can make to discuss their current behavior and expectations as
well as next steps being documentation the least we have to do.

Thanks,
Carlos



On Wed, Sep 28, 2016 at 2:41 AM, Armando M.  wrote:

> Hi folks,
>
> The summit is less than a month away and it's the time of the year where
> we need to plan for design summit sessions.
>
> This time we are going for 10 fishbowl sessions, plus Friday [0].
>
> We will break down sessions in three separate tracks as we did the last
> two summits. Each track will have its own theme and more details will be
> provided in due course.
>
> I started etherpad [1] to collect inputs and ideas. Please start
> brainstorming! I'll reach out to the driver team members individually to
> work out a more formal agenda once we get some ideas off the ground.
>
> Cheers,
> Armando
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-
> September/103851.html
> [1] https://etherpad.openstack.org/p/ocata-neutron-summit-ideas
>
> __
> 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] postgresql fails mitaka -> newton migrations on nova

[Sylvain Bauza]

Le 05/10/2016 08:18, Matthew Thode a écrit :

I've found two possible bugs, one with the online_data_migrations and
one after services are started again (ignoring the online_data_migration
failures).

The online_data_migration bug is located at:
   https://bugs.launchpad.net/nova/+bug/1630446

The post non-migration bug is located at:
   https://bugs.launchpad.net/nova/+bug/1630448

At the moment I think the first bug is likely the cause of the second
bug, but don't have enough info to verify or fix it.




Are you sure you also ran the nova-manage api_db sync before doing the 
db migrations ?


Most of the errors you got are because all those tables were migrated 
from the 'legacy' DB (now called cell DB) to the API DB, and you need to 
wrap it up.


Eg. for instance groups :
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api_migrations/migrate_repo/versions/018_instance_groups.py


Replying to bugs anyway.

-Sylvain


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

Re: [openstack-dev] [glance] iscsi backend for glance and cinder.

[Andrey Pavlov]

Try to use cinder as backend for glance.
It works from Mitaka.

Regards,
Andrey.

On Wed, Oct 5, 2016 at 6:03 AM, 박준하  wrote:

> Hello,
>
> I’m now planning to use Netapp storage with iscsi mode as volume
> storage(Cinder) and image storage(Glance)
>
>
>
> There is a problem that I want to use Netapp storage for Glance Backeds
> with iscsi, I mean, I don’t want to use Netapp as NFS, but I could not find
> any guides about setting glance’s backends on iscsi. Could you guys have
> any idea about it?
>
>
>
> Regards,
>
> Jun-ha Park
>
>
>
> __
> 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
>
>


-- 
Kind regards,
Andrey Pavlov.
__
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] [chef] Adding calbers to openstack-chef-core

[j.kl...@cloudbau.de]

Hi,

sounds good, +1 from me.

Cheers,
Jan

> On 05 Oct 2016, at 05:44, Samuel Cassiba  wrote:
> 
> Ohai Chefs!
> 
> I would like to nominate Christoph Albers (irc: calbers) for
> openstack-chef-core.
> 
> Christoph has consistently provided great quality reviews over the
> Newton cycle. He has been instrumental in getting the cookbooks up to
> speed with Identity v3 and openstackclient. During Mitaka, his reviews
> were crucial to the refactor work that took place during that cycle.
> From the quality of his reviews, he has a solid understanding of the
> codebase and I think he is qualified to be a core reviewer.
> 
> This will bring us back up to three dedicated core reviewers, and I
> would like to reimplement a 2x +2 policy for changes.
> 
> If there are no objections, I will put in a change at the end of the
> week. Consider this a +1 vote from me.
> 
> Thanks,
> 
> -sc
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] TC candidacy

[Flavio Percoco]

On 03/10/16 23:25 +0100, Chris Dent wrote:

On Mon, 3 Oct 2016, Clay Gerrard wrote:


I just re-read your announcement - and I couldn't be happier you're running
:D


a) Glad to hear it.

b) It's a shame these email threads didn't start last week. I
suspect many of the people reading have already voted. I think the
conversations are still valuable, both for the people who haven't
voted and to shape future discussions. It's making more things more
visible, and that's good.


FWIW, I think it's better to start these discussions when the candidacy period
is over. As a voter, I always ask questions (or read other voter's questions
before casting my vote). This might not be true for everyone, though.

Asking questions during the candidacy period might affect other candidates too
(in a good or bad way), I believe.

That said, I'd like to also thank Clay for asking all the questions this time
around. :D

Flavio


I was so surprised at the fallout from your suggestion that the TC should
actively engage in more broadcasting of important topics [1] to bring in
more voices from the community early!?  Links to IRC logs and Gerrit commit
history seemed to totally miss the point?


Yes, I found that surprising too. To be fair I think it probably has
a lot to do with different people's different communication styles.
For some people IRC logs and gerrit are great. For others, not so
much. This is one of the reasons for insisting that the TC have a
mixture of voices and opinions. It can be very easy to become
habituated to believing that the norm works for everyone, when it
could just be you for whom it is working.


I'm curious if any other discussions or questions on the mailing list have
excited or frustrated you in the past week?  Is there any specific goals
you have for a one year term on the TC - or do you think more clarity on
past "perceived agreements" and a better focus on visibility and
communication is the more important thing to fix first?


All that is important, and (transferring gordc's question over here)
better communication will certainly enhance the TC's capability as a
responsive (seems a better term than reactive) representative body.
Good communication is effectively a requirement for doing existing
and future work correctly.

Where I want to see the TC be proactive is a long list. A sample is
below. The reason I think the TC should take a lead on these is because
the issues need attention from a group that prioritizes the entire
community, not just one project, and the members of that group must have
the time to give real attention to the issues. Very few people in
the community are licensed to legitimately use time in that fashion.

Some ideas other candidates have already stated:

* Driving community-wide goals (for example Python 3 support sooner than
 later).

* Building bridges with other communities in similar spaces (for
 example our pals in k8s).

I hope that neither of these are controversial. They are fundamental for
the long term health of the community and the project.

Some notions that might be subject to some disagreement:

* Putting some strength in working groups like arch-wg and api-wg so
 we can start modernizing in general and in some cases correcting
 past mistakes.

* Concentrating more on contributor experience. Not at the expense
 of user experience, but in addition to. I think part of the role
 of the TC should be something akin to a union rep. Corporate driven
 open source is weird. We need to acknowledge that it presents some
 challenges. We've seen some discussion dancing around the edges of
 this topic in the review of the principles document linked from [1].

* Balance the needs of existing users against the needs of the users
 we haven't yet acquired somewhat in favor of the many more users yet
 to come. Too often we use existing users as an excuse to not make an
 improvement. This is not to say we should actively punish existing
 users but rather that there a multiple avenues to smooth transitions
 beyond simply avoiding them.

* Put some subjectivity back into the project evaluation process.
 The big tent was designed to make acceptance into the OpenStack
 community more objective. That's admirable in some ways, but has led
 to confusion about the identity of OpenStack. The thing is that
 taste matters. OpenStack needs to have opinions about what
 OpenStack is and does. We need humans to articulate those opinions
 and then act on them by sometimes saying yes and sometimes saying
 no. That's hard work but it pays dividends not just in community
 cohesion but also in product cohesion. This will require (as
 others have stated) making a real effort to set some goals on a 1, 2
 and 5 year timetable. Where do we want to be? How do we get there?
 What are our subjective assertions about how things should be at each
 of those stages.

* And because it needs to be said somewhere: I'm pretty okay with this
 whole golang thing. Requiring homogeneity is a sure fire way to
 

[openstack-dev] postgresql fails mitaka -> newton migrations on nova

[Matthew Thode]

I've found two possible bugs, one with the online_data_migrations and
one after services are started again (ignoring the online_data_migration
failures).

The online_data_migration bug is located at:
  https://bugs.launchpad.net/nova/+bug/1630446

The post non-migration bug is located at:
  https://bugs.launchpad.net/nova/+bug/1630448

At the moment I think the first bug is likely the cause of the second
bug, but don't have enough info to verify or fix it.

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