Re: [openstack-dev] [kolla] Kolla-ansible is available

[Jeffrey Zhang]

If we can implement loose coupling, there will be optimal. But
it is hard to do this.

On Tue, Nov 29, 2016 at 2:50 PM, Joshua Harlow 
wrote:

> Jeffrey Zhang wrote:
>
>> Because the role and dockerfile are tight couplings.
>>
>> For example, the container/Dockerfile may need an environment variable
>> passed by ansible role. without it, the service may not work.
>>
>>
> Why do they need to be tightly coupled?
>
>
>
> __
> 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
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [vitrage] datasources terminology

[Afek, Ifat (Nokia - IL)]

Hi,

I think we have a confusing terminology in Vitrage datasources.

The following parameters are used in the drivers and transformers:

  *   event_type: the type of event/notification that comes from the 
datasource. For example: ‘compute.instance.delete.end’,  ‘volume.detach.start’
  *   event_action: used to tell the evaluator what to do with the entity - 
create, update or delete it.
  *   action_type: the type of action that was performed by the driver: 
init_snapshot, snapshot or update.

Personally I find these names very confusing.
My suggestion is to rename action_type to datasource_mode, or something similar.

Your thoughts?

Thanks,
Ifat.

__
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] Stepping down as testing lieutenant and from the core & drivers teams

[Vikram Choudhary]

Hi Assaf,

Wish you all the best for your future endeavor!

Thanks
Vikram


-Original Message-
From: Vasudevan, Swaminathan (PNB Roseville) 
[mailto:swaminathan.vasude...@hpe.com] 
Sent: 29 November 2016 00:35
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Stepping down as testing lieutenant and 
from the core & drivers teams

Hi Assaf,
Sorry to hear that you are stepping down. Thanks for your contribution to 
neutron and making the test suite more stable.
Wish you all success in your current job.

Thanks
Swami

-Original Message-
From: Assaf Muller [mailto:as...@redhat.com] 
Sent: Monday, November 28, 2016 10:59 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [neutron] Stepping down as testing lieutenant and from 
the core & drivers teams

Hi all,

For the past few months I've been gaining more responsibilities within Red Hat. 
I have less time to dedicate to personal contribution and it's had a 
considerable tole on my ability to perform my duties upstream to the degree of 
effectiveness I am satisfied with. To that end, I've decided that the right 
thing to do is to hand over my testing lieutenant responsibilities to Jakub 
Libosvar, and to step down from the core and drivers team.

This is a bitter sweet moment. I'm enormously proud to see the progress Neutron 
as a platform, community and as a reference implementation have made over the 
last 3 years and I'm thrilled to have taken part in that. It's grown from an 
experiment to a ubiquitous OpenStack project with a proven, robust and scalable 
batteries-included implementation used at the largest retail, insurance, 
banking, web and telco (And more!) companies in the world.
My focus will remain on OpenStack networking but my contributions will be 
indirect through my amazing team members. The people leading Quantum when I 
joined are nearly all gone and luckily we've seen a continuous influx of fresh 
talent ready to take over leadership responsibilities. I'm confident the wheel 
will keep on spinning and the project will continue stepping down the right 
path.

I'll still be on IRC and I'll be working over the upcoming couple of weeks to 
hand off any specific tasks I had going on. Have fun folks.

__
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] [kolla] Kolla-ansible is available

[Joshua Harlow]

Jeffrey Zhang wrote:

Because the role and dockerfile are tight couplings.

For example, the container/Dockerfile may need an environment variable
passed by ansible role. without it, the service may not work.



Why do they need to be tightly coupled?


__
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] [aodh] about alarm update with --query

[dong . wenjuan]

Hi all,

I use aodh cli to create a event alarm with query condition, the cli runs 
successfully.
But when i want to update the query condition, the cli runs failed.
The help info about `--query` para with these two cli  have no difference. 

The information is as follows, Does anyone else know why? Thanks~

stack@cloud:~$ aodh alarm create --name test --type event --event-type 
compute.instance.update --query 
"traits.instance_id=string::3ed4fbc1-023e-4c4e-85d3-cf6d73c9ac49"
+---+---+
| Field | Value  |
+---+---+
| alarm_actions | []  |
| alarm_id  | 8d1018bd-8f14-4f34-b47c-54588488d658   |
| description   | Alarm when compute.instance.update event 
occurred.|
| enabled   | True  |
| event_type| compute.instance.update  |
| insufficient_data_actions | []  |
| name  | test  |
| ok_actions| []  |
| project_id| f0895991f44044ccba8e62b201b70360   |
| query | traits.instance_id = 
3ed4fbc1-023e-4c4e-85d3-cf6d73c9ac49 |
| repeat_actions| False  |
| severity  | low  |
| state | insufficient data  |
| state_timestamp   | 2016-11-29T06:31:50.094836  |
| time_constraints  | []  |
| timestamp | 2016-11-29T06:31:50.094836  |
| type  | event  |
| user_id   | 7d7531a2030d4537b60a5193bf6ab286   |
+---+---+
stack@cloud:~$ 
stack@cloud:~$ 
stack@cloud:~$ aodh alarm update 8d1018bd-8f14-4f34-b47c-54588488d658 
--event-type computer.instance.delete --query 
"traits.instance_id=string::3ed4fbc1-023e-4c4e-85d3-cf6d73c9ac88"
Invalid input for field/attribute data. Value: '{'alarm_actions': [], 
'event_rule': {'query': 
'traits.instance_id=string::3ed4fbc1-023e-4c4e-85d3-cf6d73c9ac88', 
'event_type': 'computer.instance.delete'}, 'ok_actions': [], 'name': 
'test', 'state': 'insufficient data', 'timestamp': 
'2016-11-29T06:31:50.094836', 'enabled': True, 'state_timestamp': 
'2016-11-29T06:31:50.094836', 'severity': 'low', 'alarm_id': 
'8d1018bd-8f14-4f34-b47c-54588488d658', 'time_constraints': [], 
'insufficient_data_actions': [], 'repeat_actions': False, 'user_id': 
'7d7531a2030d4537b60a5193bf6ab286', 'project_id': 
'f0895991f44044ccba8e62b201b70360', 'type': 'event', 'description': 'Alarm 
when compute.instance.update event occurred.'}'. Value not a valid list: 
traits.instance_id=string::3ed4fbc1-023e-4c4e-85d3-cf6d73c9ac88 (HTTP 400) 
(Request-ID: req-ad8bd440-2784-43b7-98d7-7e0ae27dcebc)
stack@cloud:~$ 


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

Re: [openstack-dev] [kolla] the alternative of log processing tool

[Jeffrey Zhang]

On Tue, Nov 29, 2016 at 12:47 PM, Joshua Harlow 
wrote:

> Why are people/things parsing tracebacks out of log files when the
> following exists:
>
> http://docs.openstack.org/developer/oslo.log/api/formatters.
> html#oslo_log.formatters.JSONFormatter
>
> Seems like oslo.log also has a fluent formatter @
> http://docs.openstack.org/developer/oslo.log/api/formatters.
> html#oslo_log.formatters.FluentFormatter.
>
> IMHO I hope that nobody is making regex or such for tracebacks any more in
> the 21st century; structured data ftw...
>

Nice information, harlowja. It will be helpful when moving to fluentd.



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

Re: [openstack-dev] [kolla] the alternative of log processing tool

[Jeffrey Zhang]

On Tue, Nov 29, 2016 at 11:28 AM, Michał Jastrzębski 
wrote:

> Having custom /dev/log was real pain in few occasions. Also syslog was
> particularly bad in working with multi-line logging (like python
> tracebacks).
> Heka reads local log files, makes things easier, and parses things
> like tracebacks in it. It's my understanding that fluentd can do the
> same.
>

In some time, the syslog is the only choice, for example, the swift and
keepalived case.

btw, kolla is using /dev/log created by heka now.



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

Re: [openstack-dev] [kolla] Kolla-ansible is available

[Jeffrey Zhang]

Because the role and dockerfile are tight couplings.

For example, the container/Dockerfile may need an environment variable
passed by ansible role. without it, the service may not work.



On Tue, Nov 29, 2016 at 1:48 PM, Joshua Harlow 
wrote:

> Jeffrey Zhang wrote:
>
>> ​​
>> ​​
>> does
>> ​
>> anyone
>> ​ ​
>> has
>> an idea to leverage zuul's cross project testing[0] for kolla and
>> kolla-ansibe
>> gate?
>> ​
>>
>>
>> Here is a use case:
>>
>> when implementing A service, we need
>>
>> * add dockerfile in kolla project
>> * add ansible role in kolla-ansible project
>>
>
> Just curious, but why is it required to have the above?
>
> If I want to use just the dockerfiles and docker image building and not
> the ansible roles why should it be required to have both at the same time
> for a new service A?
>
> Why not just allow both the ansible 'code' and the docker files + code to
> be created and maintained independently? Of course if people want to use
> ansible to manage the docker images, more power to them.
>
> -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
>



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

Re: [openstack-dev] [kolla] Kolla-ansible is available

[Joshua Harlow]

Jeffrey Zhang wrote:

​​
​​
does
​
anyone
​ ​
has
an idea to leverage zuul's cross project testing[0] for kolla and
kolla-ansibe
gate?
​


Here is a use case:

when implementing A service, we need

* add dockerfile in kolla project
* add ansible role in kolla-ansible project


Just curious, but why is it required to have the above?

If I want to use just the dockerfiles and docker image building and not 
the ansible roles why should it be required to have both at the same 
time for a new service A?


Why not just allow both the ansible 'code' and the docker files + code 
to be created and maintained independently? Of course if people want to 
use ansible to manage the docker images, more power to them.


-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

[openstack-dev] [Horizon] Meeting at 20:00 UTC this Wednesday, 30th November

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 30th November in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend.


Cheers,

Richard

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

Re: [openstack-dev] [kolla] the alternative of log processing tool

[Joshua Harlow]

Why are people/things parsing tracebacks out of log files when the 
following exists:


http://docs.openstack.org/developer/oslo.log/api/formatters.html#oslo_log.formatters.JSONFormatter

Seems like oslo.log also has a fluent formatter @ 
http://docs.openstack.org/developer/oslo.log/api/formatters.html#oslo_log.formatters.FluentFormatter.


IMHO I hope that nobody is making regex or such for tracebacks any more 
in the 21st century; structured data ftw...


Michał Jastrzębski wrote:

Having custom /dev/log was real pain in few occasions. Also syslog was
particularly bad in working with multi-line logging (like python
tracebacks).
Heka reads local log files, makes things easier, and parses things
like tracebacks in it. It's my understanding that fluentd can do the
same.

On 28 November 2016 at 19:07, Jeffrey Zhang  wrote:

On Tue, Nov 29, 2016 at 7:29 AM, Michał Jastrzębski
wrote:

I don't really like logstash as it's big memory eating beast. We had
good arch without it, and I'd like to keep it this way. Even with
logstash we still would need to use rsyslog to push logs around to
logstash, and that's a pita (trust me, I wrote it.).

About the rsyslog mock socket, i think we have fixed it.
heka is using rsyslog socket too. IIUC, i know the issue. could u explain
more?


Fluentd just became cncf-backed project so that's a plus for fluentd.
Out of fliebeat+logstash vs flutentd I'd go with fluentd.


So, I am OK to use fluentd.

;)




--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

__
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] [kolla] the alternative of log processing tool

[Michał Jastrzębski]

Having custom /dev/log was real pain in few occasions. Also syslog was
particularly bad in working with multi-line logging (like python
tracebacks).
Heka reads local log files, makes things easier, and parses things
like tracebacks in it. It's my understanding that fluentd can do the
same.

On 28 November 2016 at 19:07, Jeffrey Zhang  wrote:
>
> On Tue, Nov 29, 2016 at 7:29 AM, Michał Jastrzębski 
> wrote:
>>
>> I don't really like logstash as it's big memory eating beast. We had
>> good arch without it, and I'd like to keep it this way. Even with
>> logstash we still would need to use rsyslog to push logs around to
>> logstash, and that's a pita (trust me, I wrote it.).
>
> About the rsyslog mock socket, i think we have fixed it.
> heka is using rsyslog socket too. IIUC, i know the issue. could u explain
> more?
>>
>>
>> Fluentd just became cncf-backed project so that's a plus for fluentd.
>> Out of fliebeat+logstash vs flutentd I'd go with fluentd.
>
>
> So, I am OK to use fluentd.
>
> ;)
>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> 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] [release] Re: [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Takashi Yamamoto]

release team,

can we (networking-midonet) branch stable/newton from a past commit
with a RC tag, backport some changes [1], and then cut the first release
on the branch?

[1] some addititonal features without db migrations (qos, lbaasv2, ...) and
removal of some unsupported code (lbaasv1, ...)

On Fri, Nov 25, 2016 at 11:32 PM, Ihar Hrachyshka  wrote:
>
>> On 25 Nov 2016, at 15:23, Takashi Yamamoto  wrote:
>>
>> On Fri, Nov 25, 2016 at 8:02 PM, Ihar Hrachyshka  wrote:
>>>
 On 25 Nov 2016, at 11:02, Takashi Yamamoto  wrote:

 On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka  
 wrote:
>
>> On 25 Nov 2016, at 09:25, Takashi Yamamoto  wrote:
>>
>> On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka  
>> wrote:
>>>
 On 25 Nov 2016, at 05:26, Takashi Yamamoto  
 wrote:

 hi,

 networking-midonet doesn't have stable/newton branch yet.
 newton jobs failures are false alarms.

 branching has been delayed because development of some futures
 planned for newton has not been completed yet.

 the plan is to revert ocata-specific changes after branching newton.
>>>
>>> I don’t think it’s a good idea since you will need to tag a release on 
>>> branch creation, that is supposed to be compatible with next releases 
>>> in that same branch.
>>
>> can't we create the tag after the revert?
>>
>
> No, that’s release team requirement that they branch on a release tag.

 ok, i didn't know the requirement. thank you.

>
>> anyway no one think this is a good idea.
>> it's just an unfortunate compromise we ended up.
>> we are trying to make the schedule better for next release.
>
> It would make more sense to tag on a compatible commit from the past and 
> consider it a first stable release. (Of course it means that feature 
> development would need to be aligned appropriately.)

 in that case, can we backport the features?
 (namely qos and lbaas drivers are in my mind)
>>>
>>> No, I don’t think so. Though maybe we can release an RC as the first tag in 
>>> the branch and backport features before releasing a final version? I dunno, 
>>> I guess you will need to talk to OpenStack release folks on how to proceed.
>>
>> is it a release team matter?
>> i thought these were a policy inside neutron.
>> after all networking-midonet is release:independent.
>
> Neutron does not override global policies. I explicitly asked during the last 
> summit if we can branch before a tag; the answer was no, it’s not an option.
>
> Adding [release] tag since it becomes a matter beyond neutron.
>
> 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] [nova][bugs] Nova Bugs Team Meeting this Tuesday at 1800 UTC

[Augustina Ragwitz]

The next Nova Bugs Team meeting will be Tuesday, November 29 at 1800UTC
in #openstack-meeting-4

http://www.timeanddate.com/worldclock/fixedtime.html?iso=20161129T18

Feel free to add to the meeting agenda: 
https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam

-- 
Augustina Ragwitz
Señora Software Engineer
---
Ask me about contributing to OpenStack Nova!
https://wiki.openstack.org/wiki/Nova/Mentoring
---
email: aragwitz+n...@pobox.com
irc: auggy

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

Re: [openstack-dev] [kolla] the alternative of log processing tool

[Jeffrey Zhang]

On Tue, Nov 29, 2016 at 7:29 AM, Michał Jastrzębski 
wrote:

> I don't really like logstash as it's big memory eating beast. We had
> good arch without it, and I'd like to keep it this way. Even with
> logstash we still would need to use rsyslog to push logs around to
> logstash, and that's a pita (trust me, I wrote it.).
>
​About the rsyslog mock socket, i think we have fixed it.
heka is using rsyslog socket too. IIUC, i know the issue. could u explain
more?​

>
> Fluentd just became cncf-backed project so that's a plus for fluentd.
> Out of fliebeat+logstash vs flutentd I'd go with fluentd.
>

​So, I am OK to use fluentd.​

​;)​




-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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][neutron-lbaas][octavia] Not be able to ping loadbalancer ip

[Wanjing Xu (waxu)]

Thanks Michael

I still have the following questions:
1)  For active-standby, do the amphorae VM pair really communicate with each 
other using vrrp protocol, like using multicast vrrp IP?
2)   How do we install/configure the Octavia so that amphorae instances are 
spun as containers or on bare metal?

Thanks!

Wanjing

On 11/10/16, 5:12 PM, "Michael Johnson"  wrote:

Hi Wanjing,

Yes, active/standby is available in Mitaka.  You must enable it via
the octavia.conf file.

As for benchmarking, there has been some work done in this space (see
the octavia meeting logs last month), but it varies greatly depending
on how your cloud is configured and/or the hardware it is on.

Michael

On Thu, Nov 10, 2016 at 3:18 PM, Wanjing Xu (waxu)  wrote:
> Thanks, Michael.  Now I have brought up this octavia.  I have a question:
> Is HA supported on octavia, or is it yet to come?  I am using
> stable/mitaka and I only see one amphorae vm launched per loadbalancer.
> And did anybody benchmark this octtavia against vender box?
>
> Regards!
>
> Wanjing
>
> On 11/7/16, 10:02 AM, "Michael Johnson"  wrote:
>
>>Hi Wanjing,
>>
>>You are not seeing the network interfaces for the VIP and member
>>networks because they are inside a network namespace for security
>>reasons.  You can see these by issuing "sudo ip netns exec
>>amphora-haproxy ifconfig -a".
>>
>>I'm not sure what version of octavia and neutron you are using, but
>>the issue you noted about "dns_name" was fixed here:
>>https://review.openstack.org/#/c/337939/
>>
>>Michael
>>
>>
>>On Thu, Nov 3, 2016 at 11:29 AM, Wanjing Xu (waxu)  wrote:
>>> Going through the log , I saw the following error on o-hm
>>>
>>> 2016-11-03 03:31:06.441 19560 ERROR
>>> octavia.controller.worker.controller_worker request_ids=request_ids)
>>> 2016-11-03 03:31:06.441 19560 ERROR
>>> octavia.controller.worker.controller_worker BadRequest: Unrecognized
>>> attribute(s) 'dns_name'
>>> 2016-11-03 03:31:06.441 19560 ERROR
>>> octavia.controller.worker.controller_worker Neutron server returns
>>> request_ids: ['req-1daed46e-ce79-471c-a0af-6d86d191eeb2']
>>>
>>> And it seemed that I need to upgrade my neutron client.  While I am
>>>planning
>>> to do it, could somebody please send me the document on how this vip is
>>> supposed to plug into the lbaas vm and what the failover is about ?
>>>
>>> Thanks!
>>> Wanjing
>>>
>>>
>>> From: Cisco Employee 
>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Date: Wednesday, November 2, 2016 at 7:04 PM
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Subject: [openstack-dev] [Neutron][neutron-lbaas][octavia] Not be able
>>>to
>>> ping loadbalancer ip
>>>
>>> So I bring up octavia using devstack (stable/mitaka).   I created a
>>> loadbalander and a listener(not create member yet) and start to look at
>>>how
>>> things are connected to each other.  I can ssh to amphora vm and I do
>>>see a
>>> haproxy is up with front end point to my listener.  I tried to ping
>>>(from
>>> dhcp namespace) to the loadbalancer ip, and ping could not go through.
>>>I am
>>> wondering how packet is supposed to reach this amphora vm.  I can see
>>>that
>>> the vm is launched on both network(lb_mgmt network and my vipnet), but I
>>> don¹t see any nic associated with my vipnet:
>>>
>>> ubuntu@amphora-dad2f14e-76b4-4bd8-9051-b7a5627c6699:~$ ifconfig -a
>>> eth0  Link encap:Ethernet  HWaddr fa:16:3e:b4:b2:45
>>>   inet addr:192.168.0.4  Bcast:192.168.0.255  Mask:255.255.255.0
>>>   inet6 addr: fe80::f816:3eff:feb4:b245/64 Scope:Link
>>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>>   RX packets:2496 errors:0 dropped:0 overruns:0 frame:0
>>>   TX packets:2626 errors:0 dropped:0 overruns:0 carrier:0
>>>   collisions:0 txqueuelen:1000
>>>   RX bytes:307518 (307.5 KB)  TX bytes:304447 (304.4 KB)
>>>
>>> loLink encap:Local Loopback
>>>   inet addr:127.0.0.1  Mask:255.0.0.0
>>>   inet6 addr: ::1/128 Scope:Host
>>>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>>>   RX packets:212 errors:0 dropped:0 overruns:0 frame:0
>>>   TX packets:212 errors:0 dropped:0 overruns:0 carrier:0
>>>   collisions:0 txqueuelen:0
>>>   RX bytes:18248 (18.2 KB)  TX bytes:18248 (18.2 KB)
>>>
>>> localadmin@dmz-eth2-ucs1:~/devstack$ nova list
>>>

Re: [openstack-dev] [kolla] the alternative of log processing tool

[Michał Jastrzębski]

I don't really like logstash as it's big memory eating beast. We had
good arch without it, and I'd like to keep it this way. Even with
logstash we still would need to use rsyslog to push logs around to
logstash, and that's a pita (trust me, I wrote it.).

Fluentd just became cncf-backed project so that's a plus for fluentd.
Out of fliebeat+logstash vs flutentd I'd go with fluentd.

On 28 November 2016 at 03:15, Christian Berendt
 wrote:
>
>> On 27 Nov 2016, at 06:55, Jeffrey Zhang  wrote:
>>
>> * Fluentd
>> * Logstash
>
> I do not have a strong behaviour.
>
> At the moment we use the E and K of the ELK stack. Because of that I think it 
> makes sense to go with Logstash. In this way, we have a stack developed by 
> one community and which is tuned to each other.
>
> Christian.
>
> --
> Christian Berendt
> Chief Executive Officer (CEO)
>
> Mail: bere...@betacloud-solutions.de
> Web: https://www.betacloud-solutions.de
>
> Betacloud Solutions GmbH
> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>
> Geschäftsführer: Christian Berendt
> Unternehmenssitz: Stuttgart
> Amtsgericht: Stuttgart, HRB 756139
>
>
> __
> 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] [nova] Quick recap on where we sit with blueprints

[Matt Riedemann]

Now that we're past the spec freeze and have a more clear picture of 
what we're tracking blueprint-wise for Ocata I wanted to give a recap on 
where we're sitting and level set on expectations.


Based on [1] I'm currently tracking 69 blueprints. 3 of those are still 
pending spec reviews but I'm giving them exceptions based on their 
priority for the release.


We more or less have 8 blueprints implemented already (I'm watching one 
go through the gate before I mark it implemented).


So we have 61 blueprints that aren't implemented yet. 14 of those aren't 
even started yet (no code up for review).


Given the Ocata release schedule [2] and feature freeze being on January 
26th, we have 10 weeks of development time left. Keep in mind that's 
including the week of Christmas and New Year's holidays in which a lot 
of people are probably going to be taking time off.


Just looking at the numbers, that means to get all blueprints completed 
in Ocata we'd need to be completing them at a rate of more than one per 
(work) day until 1/26, which realistically isn't going to happen.


If you have an approved blueprint/spec but don't have code up for review 
yet, you'd better get started on that.


If you have blueprint code up for review and actually get review 
comments, be quick about addressing those comments. Follow up in IRC if 
it requires a higher frequency discussion than code review allows.


I know there were a few specs that didn't get merged by the 11/17 
deadline. I've told some people that they can make a case for exceptions 
in the mailing list but given the numbers above I really don't want to 
be adding much more to our list as it detracts from everything we've 
already agreed to do, and giving too many exceptions makes future 
deadlines hollow.


If there are questions please reach out to me either in a reply here or 
in IRC.


[1] https://blueprints.launchpad.net/nova/ocata
[2] https://wiki.openstack.org/wiki/Nova/Ocata_Release_Schedule

--

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] [nova] away from Nova development for forseeable future

[Matt Riedemann]

On 11/28/2016 10:27 AM, Daniel P. Berrange wrote:

Hi Folks,

I was recently tasked with spending some months working full time on
another project unrelated to OpenStack Nova. As such I am not likely
to be participating in any Nova related work for at least the Ocata
development cycle. At this time, I don't know whether I'll be returning
to Nova in the Pike cycle or not. I hope that other Red Hat folks will
be able to take over involvement in any work I was responsible for (eg in
particular os-vif related stuff or any libvirt driver work). Since I
won't be on IRC, if there's some show stopper that needs my help, I'd
encourage people to ping other Red Hat or Nova team members who should
have enough knowledge to help, or failing that, email me.

I've not resigned from Nova core, but realistically I'm not going to be
doing any reviews for 3-4 months at a minimum, so I'll leave it up to
PTL to decide what action to take, if any. Regardless I think that
Nova needs to look core membership more broadly given the recent loss of
Andrew from the team too.

Thus I'd encourage the project to either promote more community members
to the Nova core team to increase bandwidth, and/or consider alternative
strategies to reduce the core bottleneck, such as an intermediate layer
of people who have +2, but not +A.

Regards,
Daniel



Thanks for the heads up Daniel. sahid, lyarwood, mdbooth and sfinucan 
have done a nice job of picking up work on the libvirt driver code 
lately, so I think we're in good shape there.


Good luck with the new project and hopefully we haven't heard the last 
of you in Nova.


--

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] [glance][oslo] oslo.log 3.17.0 use_stderr default change

[Tony Breeds]

On Mon, Nov 28, 2016 at 10:55:56AM -0500, Ian Cordasco wrote:

> So, I'm not entirely certain we actually want use_stderr on for
> everything by default. If you look at that failing test, it's
> asserting there's stderr output from running one of Glance's
> administrative commands (in this case glance-replicator, but it could
> apply to any of the other ones). I think, what we *probably* want is
> just to have stderr default to True for commands in glance.cmd
> (probably excluding glance-api and glance-registry) so that operators
> running those commands continue to see output.
> 
> I've been looking at this a little, and I think what we want is to do
> 
>    CONF.set_override(name='use_stderr',  default=True, enforce_type=True)
> 
> Does this sound reasonable to everyone else? If so, I already made
> https://review.openstack.org/403775 which does this and adds an
> upgrade release note to document the change.

Thanks Ian.  Great suggestion and I appreciate you running with this.

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] [heat][zaqar][telemetry] Subscribing to events

[McLellan, Steven]

On 11/28/16, 9:57 AM, "Zane Bitter"  wrote:

>On 28/10/16 08:32, Julien Danjou wrote:
>>> > 2. Content Format
>>> > The info/data forwarded by Aodh is alarm, not the original event. At 
>>> > here,
>>> > I assume most of the users would like to see the original event, not the 
>>> > alarm.
>> That sounds easy. :)
>
>Not that easy: https://review.openstack.org/#/c/356404/
>
>oslo.messaging data is not supposed to be given out to users, so it has 
>to be sanitised before you can do so safely. I believe Searchlight has a 
>way of doing this. Mistral, as you can see from that patch, punted the 
>problem to the operator.


Searchlight for the most part discards everything except the payload (at least 
as far as an end-consumer is concerned). For some services we also restrict 
access to some information (Nova in particular has some fields that only 
administrators should have access to).


>
>I'd love to come up with some kind of cross-project approach to this (a 
>library?). I don't really care where people source their events from, 
>but if we're maintaining three different ways to do security-critical 
>access control for data produced independently by all of the different 
>OpenStack services, then we're headed for certain disaster.

I agree; we did it in Searchlight because there was no other option (and it 
took a long time to get traction for a self-contained project, let alone for a 
library that at the time would've had only one use case). We've been looking at 
having our listener process accept additional publishing endpoints (Zaqar being 
among them), but we'd certainly be open to make that sanitization code more 
reusable.

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

[openstack-dev] [all] The Future of OpenStack Needs You

[Ildiko Vancsa]

Hi All,

I’m reaching out to you because we are looking for people who would like to get 
involved in the __activities around on boarding and the Upstream training__ we 
are holding before the Summits.

We had a very successful training before the Barcelona Summit [1] with around 
90 attendees during the one and a half days of the course. The training format 
orients towards a more and more __hands-on practice__ and we are looking for 
experienced people within the Community to help the new comers understand our 
processes along with the large code base we have overall and even per project.

To get you more excited I’m happy to say that our mentors had a great time with 
the students and even they learnt new things based on the feedback so far. :)

We have also started to explore a modular setup for the class which makes it 
possible to pick up only parts of it at a time in the future. This way we hope 
to __bring a subset of the modules to local events__ like OpenStack Days and 
meet-ups around the globe to reach a broader group of possible contributors.

We would like to have You on our team to support this activity and get in touch 
with possible new members of our Community to make it a good experience for 
them and for you at the same time to ensure we have people joining who 
understand our principles from day 1, successful with contributions and stay 
around after the trainings/sessions.

If you are interested in the details on how you can get involved and help with 
this activity please reach out to me (ild...@openstack.org, IRC: ildikov) or 
Kendall Nelson (knel...@openstack.org, IRC: diablo_rojo). You can also check 
the current state of the material along with our mission statement on the 
training web page [2] or join our bi-weekly (even weeks) meetings [3].

Thanks and Best Regards,
Ildikó


[1] http://superuser.openstack.org/articles/openstack-upstream-training-revamp/ 
 
[2] http://docs.openstack.org/upstream-training/ 
 
[3] http://eavesdrop.openstack.org/#Training-guides_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] [neutron] Stepping down as testing lieutenant and from the core & drivers teams

[Kevin Benton]

Sorry to see you go, I hope you stick around to participate on any good
bike-shedding sessions!

On Mon, Nov 28, 2016 at 11:58 AM, Assaf Muller  wrote:

> Hi all,
>
> For the past few months I've been gaining more responsibilities within
> Red Hat. I have less time to dedicate to personal contribution and
> it's had a considerable tole on my ability to perform my duties
> upstream to the degree of effectiveness I am satisfied with. To that
> end, I've decided that the right thing to do is to hand over my
> testing lieutenant responsibilities to Jakub Libosvar, and to step
> down from the core and drivers team.
>
> This is a bitter sweet moment. I'm enormously proud to see the
> progress Neutron as a platform, community and as a reference
> implementation have made over the last 3 years and I'm thrilled to
> have taken part in that. It's grown from an experiment to a ubiquitous
> OpenStack project with a proven, robust and scalable
> batteries-included implementation used at the largest retail,
> insurance, banking, web and telco (And more!) companies in the world.
> My focus will remain on OpenStack networking but my contributions will
> be indirect through my amazing team members. The people leading
> Quantum when I joined are nearly all gone and luckily we've seen a
> continuous influx of fresh talent ready to take over leadership
> responsibilities. I'm confident the wheel will keep on spinning and
> the project will continue stepping down the right path.
>
> I'll still be on IRC and I'll be working over the upcoming couple of
> weeks to hand off any specific tasks I had going on. Have fun folks.
>
> __
> 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] [ironic] this week's priorities and subteam reports

[Loo, Ruby]

Hi,

We are nonplussed to present this week's priorities and subteam report for 
Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and 
formatted.

This Week's Priorities (as of the weekly ironic meeting)

1. portgroup: review code  
https://review.openstack.org/#/q/status:open+branch:master+topic:bug/1618754
2. attach/detach: review code (after sambetts updates): 
https://review.openstack.org/#/c/327046/
3. boot from volume: review volume connection work: 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1526231
4. next notifications: review code: 
https://review.openstack.org/#/q/topic:bug/1606520
5. rolling upgrades spec needs reviews: https://review.openstack.org/#/c/299245/
6. next driver composition patch: we need to move node_create to conductor, see 
the reasoning in the commit message: https://review.openstack.org/401311


Bugs (dtantsur)
===
- Stats (diff between 14 Nov 2016 and 21 Nov 2016)
- Ironic: 234 bugs (-4) + 220 wishlist items. 42 new (+1), 177 in progress 
(-6), 1 critical, 29 high (+2) and 21 incomplete (-2)
- Inspector: 12 bugs (-1) + 21 wishlist items. 2 new, 10 in progress (-1), 1 
critical, 1 high (-1) and 2 incomplete
- Nova bugs with Ironic tag: 10 (-1). 0 new, 0 critical, 1 high
- dtantsur is seriously behind the bug triaging due to his current assignments, 
help appreciated

Portgroups support (sambetts, vdrok)

* trello: https://trello.com/c/KvVjeK5j/29-portgroups-support
- status as of most recent weekly meeting:
- yet another multitenancy spec update, configuration-related fields in 
portgroup objects - https://review.openstack.org/396610 -- merged, working on 
code
- portgroups patches need reviews: 
https://review.openstack.org/#/q/topic:bug/1618754

CI refactoring (dtantsur, lucasagomes)
==
* trello: https://trello.com/c/c96zb3dm/32-ci-refactoring
- status as of most recent weekly meeting:
- (lucasagomes): postgres job with standard PXE deployment fixed

Rolling upgrades and grenade-partial (rloo, jlvillal)
=
* trello: 
https://trello.com/c/GAlhSzLm/2-rollindg-upgrades-and-grenade-with-multi-node
- status as of most recent weekly meeting:
- spec was updated, needs reviews: https://review.openstack.org/299245
- Work is ongoing for enabling Grenade with multi-tenant: 
https://review.openstack.org/389268

Security groups (jroll)
===
* trello: 
https://trello.com/c/klty7VVo/30-security-groups-for-provisioning-cleaning-network
- status as of most recent weekly meeting:
- merged last week: https://review.openstack.org/#/c/361451/
- last patch, documentation. Needs to be rebased and reviewed: 
https://review.openstack.org/#/c/393962/

Interface attach/detach API (sambetts)
==
* trello: https://trello.com/c/nryU4w58/39-interface-attach-detach-api
- status as of most recent weekly meeting:
- Spec merged and Nova BP approved
- Ironic patch up to date with latest version of spec, however we decided 
in Ironic/Neutron meeting to experiment with spliting it down for easier review 
(driver changes/RPC API changes/REST API changes)
- Ironic - https://review.openstack.org/327046
- Patches need updating still:
- Nova - https://review.openstack.org/364413
- IronicClient - https://review.openstack.org/364420

Generic boot-from-volume (TheJulia)
===
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- status as of most recent weekly meeting:
- We have started receiving reviews and traction with the volume connection 
substrate.  The first 2 patches have landed for volume connector 
database/object entries.
- reviews needed for volume connection work: 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1526231

Driver composition (dtantsur)
=
* trello: https://trello.com/c/fTya14y6/14-driver-composition
- gerrit topic: https://review.openstack.org/#/q/status:open+topic:bug/1524745
- status as of most recent weekly meeting:
- first patches are merged
- we need to move node_create to conductor, see the reasoning in the commit 
message: https://review.openstack.org/401311
- the (quite complex) patch introducing hardware types can use some reviews 
too: https://review.openstack.org/336626

Rescue mode (JayF)
==
* trello: https://trello.com/c/PwH1pexJ/23-rescue-mode
- status as of most recent weekly meeting:
- patch for API/Conductor methods needs review: 
https://review.openstack.org/#/c/350831/

etags in the REST API (gzholtkevych)

* trello: https://trello.com/c/MbNA4geB/33-rest-api-etags
- status as of most recent weekly 

Re: [openstack-dev] [neutron] Stepping down as testing lieutenant and from the core & drivers teams

[Edgar Magana]

Thanks a bunch for all hard work and contributions!

Edgar

On 11/28/16, 10:58 AM, "Assaf Muller"  wrote:

Hi all,

For the past few months I've been gaining more responsibilities within
Red Hat. I have less time to dedicate to personal contribution and
it's had a considerable tole on my ability to perform my duties
upstream to the degree of effectiveness I am satisfied with. To that
end, I've decided that the right thing to do is to hand over my
testing lieutenant responsibilities to Jakub Libosvar, and to step
down from the core and drivers team.

This is a bitter sweet moment. I'm enormously proud to see the
progress Neutron as a platform, community and as a reference
implementation have made over the last 3 years and I'm thrilled to
have taken part in that. It's grown from an experiment to a ubiquitous
OpenStack project with a proven, robust and scalable
batteries-included implementation used at the largest retail,
insurance, banking, web and telco (And more!) companies in the world.
My focus will remain on OpenStack networking but my contributions will
be indirect through my amazing team members. The people leading
Quantum when I joined are nearly all gone and luckily we've seen a
continuous influx of fresh talent ready to take over leadership
responsibilities. I'm confident the wheel will keep on spinning and
the project will continue stepping down the right path.

I'll still be on IRC and I'll be working over the upcoming couple of
weeks to hand off any specific tasks I had going on. Have fun folks.

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

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DgICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=AMaVtQG6uCVlyL7u56PDtnJSNfnrY_BpMbpY-lTyupc=yVjJ6g0cFXREQVPMb8cjQrvT7kFqKGMZ2HIk4O48yEM=
 


__
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][oslo] oslo.log 3.17.0 use_stderr default change

[Joshua Harlow]

Hello Glance team!


Hello Tony!


About a month ago the oslo team released 3.17.0 of oslo.log which contains [1]
which switches the default for use_stderr from True to False. It hasn't made
it into upper-constraints.txt because glance is failing[2]. There are 2 easy
fixes:

1) switch the glance test to look at stdout rather then stderr ; or
2) update the glance config files to explictly set "use_stderr = true"

I feel like Option 2 is correct as clearly preserves the existing behaviour the
operators/deployers can opt out if they want.


So, I'm not entirely certain we actually want use_stderr on for
everything by default. If you look at that failing test, it's
asserting there's stderr output from running one of Glance's
administrative commands (in this case glance-replicator, but it could
apply to any of the other ones). I think, what we *probably* want is
just to have stderr default to True for commands in glance.cmd
(probably excluding glance-api and glance-registry) so that operators
running those commands continue to see output.

I've been looking at this a little, and I think what we want is to do

CONF.set_override(name='use_stderr',  default=True, enforce_type=True)

Does this sound reasonable to everyone else? If so, I already made
https://review.openstack.org/403775 which does this and adds an
upgrade release note to document the change.

I don't want it to be merged without appropriate discussion, so I've
-1'd the Workflow.



Sounds reasonable to me, I'd like to get that merged since its the last 
current bug with the oslo periodic jobs for glance:


http://status.openstack.org/openstack-health/#/g/build_name/periodic-glance-py27-with-oslo-master 
(all of these)


-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] [neutron] Stepping down as testing lieutenant and from the core & drivers teams

[reedip banerjee]

Hey Assaf,
It was great to have you as a core member and we still learn a lot
from.your valuable blog on networking.

All the best of luck for your future endeavors

On Nov 29, 2016 00:35, "Vasudevan, Swaminathan (PNB Roseville)" <
swaminathan.vasude...@hpe.com> wrote:

> Hi Assaf,
> Sorry to hear that you are stepping down. Thanks for your contribution to
> neutron and making the test suite more stable.
> Wish you all success in your current job.
>
> Thanks
> Swami
>
> -Original Message-
> From: Assaf Muller [mailto:as...@redhat.com]
> Sent: Monday, November 28, 2016 10:59 AM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [neutron] Stepping down as testing lieutenant and
> from the core & drivers teams
>
> Hi all,
>
> For the past few months I've been gaining more responsibilities within Red
> Hat. I have less time to dedicate to personal contribution and it's had a
> considerable tole on my ability to perform my duties upstream to the degree
> of effectiveness I am satisfied with. To that end, I've decided that the
> right thing to do is to hand over my testing lieutenant responsibilities to
> Jakub Libosvar, and to step down from the core and drivers team.
>
> This is a bitter sweet moment. I'm enormously proud to see the progress
> Neutron as a platform, community and as a reference implementation have
> made over the last 3 years and I'm thrilled to have taken part in that.
> It's grown from an experiment to a ubiquitous OpenStack project with a
> proven, robust and scalable batteries-included implementation used at the
> largest retail, insurance, banking, web and telco (And more!) companies in
> the world.
> My focus will remain on OpenStack networking but my contributions will be
> indirect through my amazing team members. The people leading Quantum when I
> joined are nearly all gone and luckily we've seen a continuous influx of
> fresh talent ready to take over leadership responsibilities. I'm confident
> the wheel will keep on spinning and the project will continue stepping down
> the right path.
>
> I'll still be on IRC and I'll be working over the upcoming couple of weeks
> to hand off any specific tasks I had going on. Have fun folks.
>
> __
> 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] [heat][sahara][magnum][tripleo] Scaling nested stack validation

[Zane Bitter]

On 23/11/16 17:58, Zane Bitter wrote:

I also investigated another issue, which is that since the fix for
https://bugs.launchpad.net/heat/+bug/1388140 landed (in Kilo) I believe
we are validating nested stacks multiple times (specifically, m times,
where m is the stack's depth in the tree):

  root childgrandchild

  create
   -> validate --> validate --> validate
   -> Resource.create ===> create
-> validate --> validate
-> Resource.create ===> create
 -> validate

The only good news here is that ResourceGroup is smart enough to make
sure that it generates a nested stack with at most 1 resource to
validate when validate() is called. (However, when the nested stack is
created, and thus validated, it is of course full-sized.) Autoscaling
groups make no such allowances, but the patch above should actually have
the same effect. (We can't get rid of the special case for ResourceGroup
though, because of index substitution.)

An obvious fix would be to disable validation - or, more specifically,
validation of _resources_ - on create/update for stacks that have a
non-null owner_id (i.e. nested stacks), so that we had something like:

  root childgrandchild

  create
   -> validate --> validate --> validate
   -> Resource.create ===> create
-> Resource.create ===> create

That would eliminate the duplication/triplication/multiplication of
validation. It would also mean that we'd cut out the expensive part of
ResourceGroup validation with index substitution, leaving only the cheap
part.

One downside is that in the ResourceGroup/index substitution case we'd
be creating resources whose definitions hadn't _ever_ been validated. I
_think_ that's safe, in the sense that you'd just hear about errors
later, as opposed to everything falling over in a heap, but it's
difficult to be certain. Hearing about problems late is also not ideal
(since it may cause otherwise-healthy siblings to be cancelled), but I
would guess that heavy users like TripleO developers would say that it's
worth the tradeoff.


https://launchpad.net/bugs/1645336
https://review.openstack.org/#/c/403828/

- ZB

__
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][tc] Allowing Teams Based on Vendor-specific Drivers

[Jay Pipes]

On 11/28/2016 01:33 PM, Doug Hellmann wrote:

I'm raising this as an issue because it's not just a hypothetical
problem. The Cisco networking driver team, having been removed from
the Neutron stadium, is asking for status as a separate official
team [1]. I would very much like to find a way to say "yes, welcome
(back)!"


These questions are to the Cisco networking team.

What value do *you* think you derive from being an official OpenStack 
project team?


What value do you believe OpenStack *users* would get from you being an 
official OpenStack project team?


If you are *not* accepted as an official OpenStack project team, what 
actual impact would that have on OpenStack users, if any?


Thanks in advance for your answers.

Best,
-jay

__
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] Stepping down as testing lieutenant and from the core & drivers teams

[Vasudevan, Swaminathan (PNB Roseville)]

Hi Assaf,
Sorry to hear that you are stepping down. Thanks for your contribution to 
neutron and making the test suite more stable.
Wish you all success in your current job.

Thanks
Swami

-Original Message-
From: Assaf Muller [mailto:as...@redhat.com] 
Sent: Monday, November 28, 2016 10:59 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [neutron] Stepping down as testing lieutenant and from 
the core & drivers teams

Hi all,

For the past few months I've been gaining more responsibilities within Red Hat. 
I have less time to dedicate to personal contribution and it's had a 
considerable tole on my ability to perform my duties upstream to the degree of 
effectiveness I am satisfied with. To that end, I've decided that the right 
thing to do is to hand over my testing lieutenant responsibilities to Jakub 
Libosvar, and to step down from the core and drivers team.

This is a bitter sweet moment. I'm enormously proud to see the progress Neutron 
as a platform, community and as a reference implementation have made over the 
last 3 years and I'm thrilled to have taken part in that. It's grown from an 
experiment to a ubiquitous OpenStack project with a proven, robust and scalable 
batteries-included implementation used at the largest retail, insurance, 
banking, web and telco (And more!) companies in the world.
My focus will remain on OpenStack networking but my contributions will be 
indirect through my amazing team members. The people leading Quantum when I 
joined are nearly all gone and luckily we've seen a continuous influx of fresh 
talent ready to take over leadership responsibilities. I'm confident the wheel 
will keep on spinning and the project will continue stepping down the right 
path.

I'll still be on IRC and I'll be working over the upcoming couple of weeks to 
hand off any specific tasks I had going on. Have fun folks.

__
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] Stepping down as testing lieutenant and from the core & drivers teams

[Assaf Muller]

Hi all,

For the past few months I've been gaining more responsibilities within
Red Hat. I have less time to dedicate to personal contribution and
it's had a considerable tole on my ability to perform my duties
upstream to the degree of effectiveness I am satisfied with. To that
end, I've decided that the right thing to do is to hand over my
testing lieutenant responsibilities to Jakub Libosvar, and to step
down from the core and drivers team.

This is a bitter sweet moment. I'm enormously proud to see the
progress Neutron as a platform, community and as a reference
implementation have made over the last 3 years and I'm thrilled to
have taken part in that. It's grown from an experiment to a ubiquitous
OpenStack project with a proven, robust and scalable
batteries-included implementation used at the largest retail,
insurance, banking, web and telco (And more!) companies in the world.
My focus will remain on OpenStack networking but my contributions will
be indirect through my amazing team members. The people leading
Quantum when I joined are nearly all gone and luckily we've seen a
continuous influx of fresh talent ready to take over leadership
responsibilities. I'm confident the wheel will keep on spinning and
the project will continue stepping down the right path.

I'll still be on IRC and I'll be working over the upcoming couple of
weeks to hand off any specific tasks I had going on. Have fun folks.

__
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] [keytone] Pike PTL

[Dolph Mathews]

Thank you for your selfless community service, Steve! It takes a LOT of
commitment to be a successful PTL, and I think you delivered in spades. We
owe you a lot of gratitude.

-Dolph

On Mon, Nov 21, 2016 at 11:54 AM Steve Martinelli 
wrote:

> Keystoners,
>
> I do not intend to run for the PTL position of the Pike development cycle.
> I'm sending this out early so I can work with folks interested in the role,
> If you intend to run for PTL in Pike and are interested in learning the
> ropes (or just want to hear more about what the role means) then shoot me
> an email.
>
> It's been an unforgettable ride. Being PTL a is very rewarding experience,
> I encourage anyone interested to put your name forward. I'm not going
> away from OpenStack, I just think three terms as PTL has been enough. It'll
> be nice to have my evenings back :)
>
> To *all* the keystone contributors (cores and non-cores), thank you for
> all your time and commitment. More importantly thank you for putting up
> with my many questions, pings, pokes and -1s. Each of you are amazing and
> together you make an awesome team. It has been an absolute pleasure to
> serve as PTL, thank you for letting me do so.
>
> stevemar
>
>
> 
>
> Thanks for the idea Lana [1]
> [1]
> http://lists.openstack.org/pipermail/openstack-docs/2016-November/009357.html
> __
> 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
>
-- 
-Dolph
__
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] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

The OpenStack community wants to encourage collaboration by emphasizing
contributions to projects that abstract differences between
vendor-specific products, while still empowering vendors to integrate
their products with OpenStack through drivers that can be consumed
by the abstraction layers.

Some teams for projects that use drivers may not want to manage
some or all of the drivers that can be consumed by their project
because they have little insight into testing or debugging the code,
or do not have the resources needed to manage centrally a large
number of separate drivers. Vendors are of course free to produce
drivers to integrate with OpenStack completely outside of the
community, but because we value having the drivers as well as the
more general support of vendor companies, we want to encourage a
higher level of engagement by welcoming vendor-specific teams to
be a part of our community governance.

Our Requirements for New Projects list [0] includes a statement
about establishing a "level and open collaboration playing field"

  The project shall provide a level and open collaboration playing
  field for all contributors. The project shall not benefit a single
  vendor, or a single vendors product offerings; nor advantage
  contributors from a single vendor organization due to access to
  source code, hardware, resources or other proprietary technology
  available only to those contributors.

This requirement makes it difficult to support having teams focused
on producing a deliverable that primarily benefits a single vendor.
So, we have some tension between wanting to collaborate and have a
level playing field, while wanting to control the amount of driver
code that projects have to manage.

I'm raising this as an issue because it's not just a hypothetical
problem. The Cisco networking driver team, having been removed from
the Neutron stadium, is asking for status as a separate official
team [1]. I would very much like to find a way to say "yes, welcome
(back)!"

To that end, I've been working with fungi and ttx to identify all
of our options. We've come up with a "spectrum", which I will try
to summarize here but please read the associated governance patches
for the full details. (Please note that although we've split up the
work of writing the patches, each author may not necessarily support
all of the patches he has submitted.)

1. A resolution reaffirming the "level playing field" requirement,
   and acknowledging that it effectively precludes official status
   for teams which only develop drivers for proprietary systems
   (hard black) [2]

   This would have the immediate effect of denying the Cisco team's
   request, as well as precluding future requests from similar teams.

2. A resolution reaffirming the "level playing field" requirement,
   and acknowledging that it does not necessarily preclude official
   status for teams which only develop drivers for proprietary
   systems (soft black) [3]

   This would allow driver-specific teams for systems as long as
   those drivers can be developed without access to proprietary
   information. The TC would have to consider how this applies to
   each team's request as it is evaluated.

3. A resolution and policy change removing the "level playing field"
   requirement (hard white) [4]

   This would completely remove the problematic wording from the
   governance documents (eliminate the restriction on benefiting a
   single company and consider access to specific information for
   some contributors to not be a problem).

4. A resolution and policy change loosening the "level playing field"
   requirement (soft white) [5]

   This would add an exception to the existing wording in the
   governance documents to exempt teams working only on drivers.
   They would still be subject to all of our other policies, unless
   similar exceptions are included.

5. Consider driver teams to be a completely different animal, defined
   in drivers.yaml instead of projects.yaml (grey option) [6]

   This establishes drivers as second-order objects that are necessary
   for the success of the main projects, and for which requirements
   can be loosened. It would establish a new category of team without
   the level playing-field requirement and some of the other team
   requirements that seem not to apply to driver teams because they
   are essentially a public facet of a single vendor.

6. A resolution requiring projects that consume drivers to host all
   proposed drivers. (red option) [7]

   This would require teams with projects providing driver interfaces
   to also host, in some form, drivers from vendors that ask for
   hosting. The drivers would not need to be in the main project
   repo, but would need to be in a repository "owned" by the project
   team. Project teams would not be considered responsible for the
   quality of the resulting drivers.  Contributors to the driver
   repos would be considered part of the electorate for team PTL.

7. 

[openstack-dev] [charms] regular bug day

[James Page]

Hi Folks

We have an organised bug day prior to the OpenStack Summit in Barcelona; I
felt that this focused everyone onto collaborating on bugs in a good way,
and gave us a great checkpoint on what the key issues are that people are
hitting and reporting back on the charms.

I'd like to proposed that we have a regular month charm bug day on the
first Thursday of every month - starting this week on the 1st of December!

I'll (normally) send out a reminder a week in advance to remind everyone!

Cheers

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

[openstack-dev] [nova] away from Nova development for forseeable future

[Daniel P. Berrange]

Hi Folks,

I was recently tasked with spending some months working full time on
another project unrelated to OpenStack Nova. As such I am not likely
to be participating in any Nova related work for at least the Ocata
development cycle. At this time, I don't know whether I'll be returning
to Nova in the Pike cycle or not. I hope that other Red Hat folks will
be able to take over involvement in any work I was responsible for (eg in
particular os-vif related stuff or any libvirt driver work). Since I
won't be on IRC, if there's some show stopper that needs my help, I'd
encourage people to ping other Red Hat or Nova team members who should
have enough knowledge to help, or failing that, email me.

I've not resigned from Nova core, but realistically I'm not going to be
doing any reviews for 3-4 months at a minimum, so I'll leave it up to
PTL to decide what action to take, if any. Regardless I think that
Nova needs to look core membership more broadly given the recent loss of
Andrew from the team too.

Thus I'd encourage the project to either promote more community members
to the Nova core team to increase bandwidth, and/or consider alternative
strategies to reduce the core bottleneck, such as an intermediate layer
of people who have +2, but not +A.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] [infra][neutron] Intel NFV CI voting permission in Neutron

[Ihar Hrachyshka]

> On 28 Nov 2016, at 12:18, Ihar Hrachyshka  wrote:
> 
> I suggest we disable votes for the setup until it’s fixed.

UPD: done, the CI is disabled for voting.

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] [heat][zaqar][telemetry] Subscribing to events

[Zane Bitter]

On 28/10/16 08:32, Julien Danjou wrote:

> 2. Content Format
> The info/data forwarded by Aodh is alarm, not the original event. At here,
> I assume most of the users would like to see the original event, not the 
alarm.

That sounds easy. :)


Not that easy: https://review.openstack.org/#/c/356404/

oslo.messaging data is not supposed to be given out to users, so it has 
to be sanitised before you can do so safely. I believe Searchlight has a 
way of doing this. Mistral, as you can see from that patch, punted the 
problem to the operator.


I'd love to come up with some kind of cross-project approach to this (a 
library?). I don't really care where people source their events from, 
but if we're maintaining three different ways to do security-critical 
access control for data produced independently by all of the different 
OpenStack services, then we're headed for certain disaster.


cheers,
Zane.

__
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][oslo] oslo.log 3.17.0 use_stderr default change

[Ian Cordasco]

-Original Message-
From: Tony Breeds 
Reply: OpenStack Development Mailing List (not for usage questions)
, OpenStack Development Mailing
List 
Date: November 28, 2016 at 00:19:36
To: OpenStack Development Mailing List 
Subject:  [openstack-dev] [glance][oslo] oslo.log 3.17.0 use_stderr
default change

> Hello Glance team!

Hello Tony!

> About a month ago the oslo team released 3.17.0 of oslo.log which contains [1]
> which switches the default for use_stderr from True to False. It hasn't made
> it into upper-constraints.txt because glance is failing[2]. There are 2 easy
> fixes:
>
> 1) switch the glance test to look at stdout rather then stderr ; or
> 2) update the glance config files to explictly set "use_stderr = true"
>
> I feel like Option 2 is correct as clearly preserves the existing behaviour 
> the
> operators/deployers can opt out if they want.

So, I'm not entirely certain we actually want use_stderr on for
everything by default. If you look at that failing test, it's
asserting there's stderr output from running one of Glance's
administrative commands (in this case glance-replicator, but it could
apply to any of the other ones). I think, what we *probably* want is
just to have stderr default to True for commands in glance.cmd
(probably excluding glance-api and glance-registry) so that operators
running those commands continue to see output.

I've been looking at this a little, and I think what we want is to do

   CONF.set_override(name='use_stderr',  default=True, enforce_type=True)

Does this sound reasonable to everyone else? If so, I already made
https://review.openstack.org/403775 which does this and adds an
upgrade release note to document the change.

I don't want it to be merged without appropriate discussion, so I've
-1'd the Workflow.

--
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] [mistral] Team meeting - 11/28/2016

[Renat Akhmerov]

Hi,

This is a reminder that we’ll have a team meeting today at #openstack-meeting 
at 16.00 UTC.

Agenda:
* Review action items
* Current status (progress, issues, roadblocks, further plans)
* Custom Actions API update
* Open discussion

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] [tripleo] [ironic] Need to update kernel parameters on local boot

[Jay Faulkner]

> On Nov 28, 2016, at 7:36 AM, Yolanda Robla Mota  wrote:
> 
> Hi, good afternoon
> 
> I wanted to start an email thread about how to properly setup kernel 
> parameters on local boot, for our overcloud images on TripleO.
> These parameters may vary depending on the needs of our end users, and even 
> can be different ( for different roles ) per deployment. As an example, we 
> need it for:
> - enable FIPS kernel in terms of security 
> (https://bugs.launchpad.net/tripleo/+bug/1640235)
> - enable functionality for DPDK/SR-IOV 
> (https://review.openstack.org/#/c/331564/)
> - enable rd.iscsi.firmware=1 flag (this for the ramdisk image)
> - etc..
> 
> So far, the solutions we got were on several directions:
> 
> 1. Update the golden overcloud-full image with virt-customize, modifying 
> /etc/default/grub settings according to our needs: this is a manual process, 
> not really driven by TripleO. End users will want to avoid manual steps as 
> much as possible. Also if we announce that OpenStack ships features in 
> TripleO like DPDK, SR-IOV... doesn't make sense to tell end users that if 
> they want to consume that feature, they need to do manual updates on the 
> image. It shall be natively supported, or configurable per TripleO 
> environments.
> 
> 2. Create our own images using diskimage-builder and custom elements: in this 
> case, we have the problem that the partners will loose support, as building 
> their own images is good for upstream, but not accepted into the OSP 
> environment. Also the combination of images needed can be huge, that can be a 
> blocker for QA.
> 
> 3. Add Ironic support for it. Images can be uploaded to glance, and some 
> properties can be set on metadata, like a json with kernel parameters. Ironic 
> will modify these kernel parameters when deploying the image (in a similar 
> way that when it installs bootloader, or generates partitions).
> 

This has been proposed before in ironic-specs 
(https://review.openstack.org/#/c/331564/) and was rejected, as it would 
require Ironic to reach out and modify image contents, which traditionally has 
been considered out of scope for Ironic. I would personally recommend #4, as 
post-boot automation is the safest way to configure node-specific options 
inside an image.

Thanks,
Jay Faulkner
OSIC


> 4. Configure it post-deployment: there can be some puppet element that 
> updates kernel parameters. But it will need a node reboot to be applied, and 
> it's very far from being optimal and acceptable for the end users. Reboots 
> are slow, they can be a problem depending on the number of nodes/hardware, 
> and also the timing of reboot shall be totally controlled (after all puppet 
> has been applied properly).
> 
> 
> In the first three cases, we also hit the problem that TripleO only accepts 
> one single overcloud image for all deployments - there is no way to instruct 
> TripleO to upload and use several images, depending on the node type 
> (although Ironic supports it). Also, we are worried about upgrade paths if we 
> do image customizations. We need a clear way to move forward on it.
> 
> So, we'd like to discuss the possible options there and the action items to 
> take (raise bugs, create some blueprints...). To summarize, our end goal is 
> the following:
> 
> - need to map overcloud-full images to roles
> - need to be done in an automated way, no manual steps enforced, and in a way 
> that can pass properly quality controls
> - reboots are sub-optimal
> 
> What are your thoughts there?
> 
> Best,
> 
> 
> Yolanda Robla
> yrobl...@redhat.com
> Principal Software Engineer - NFV Partner Engineer
> 
> 
> __
> 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] [tripleo] [ironic] Need to update kernel parameters on local boot

[Yolanda Robla Mota]

Hi, good afternoon

I wanted to start an email thread about how to properly setup kernel parameters 
on local boot, for our overcloud images on TripleO.
These parameters may vary depending on the needs of our end users, and even can 
be different ( for different roles ) per deployment. As an example, we need it 
for:
- enable FIPS kernel in terms of security 
(https://bugs.launchpad.net/tripleo/+bug/1640235)
- enable functionality for DPDK/SR-IOV 
(https://review.openstack.org/#/c/331564/)
- enable rd.iscsi.firmware=1 flag (this for the ramdisk image)
- etc..

So far, the solutions we got were on several directions:

1. Update the golden overcloud-full image with virt-customize, modifying 
/etc/default/grub settings according to our needs: this is a manual process, 
not really driven by TripleO. End users will want to avoid manual steps as much 
as possible. Also if we announce that OpenStack ships features in TripleO like 
DPDK, SR-IOV... doesn't make sense to tell end users that if they want to 
consume that feature, they need to do manual updates on the image. It shall be 
natively supported, or configurable per TripleO environments.

2. Create our own images using diskimage-builder and custom elements: in this 
case, we have the problem that the partners will loose support, as building 
their own images is good for upstream, but not accepted into the OSP 
environment. Also the combination of images needed can be huge, that can be a 
blocker for QA.

3. Add Ironic support for it. Images can be uploaded to glance, and some 
properties can be set on metadata, like a json with kernel parameters. Ironic 
will modify these kernel parameters when deploying the image (in a similar way 
that when it installs bootloader, or generates partitions).

4. Configure it post-deployment: there can be some puppet element that updates 
kernel parameters. But it will need a node reboot to be applied, and it's very 
far from being optimal and acceptable for the end users. Reboots are slow, they 
can be a problem depending on the number of nodes/hardware, and also the timing 
of reboot shall be totally controlled (after all puppet has been applied 
properly).


In the first three cases, we also hit the problem that TripleO only accepts one 
single overcloud image for all deployments - there is no way to instruct 
TripleO to upload and use several images, depending on the node type (although 
Ironic supports it). Also, we are worried about upgrade paths if we do image 
customizations. We need a clear way to move forward on it.

So, we'd like to discuss the possible options there and the action items to 
take (raise bugs, create some blueprints...). To summarize, our end goal is the 
following:

- need to map overcloud-full images to roles
- need to be done in an automated way, no manual steps enforced, and in a way 
that can pass properly quality controls
- reboots are sub-optimal

What are your thoughts there?

Best,


Yolanda Robla
yrobl...@redhat.com
Principal Software Engineer - NFV Partner Engineer


__
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] [stackalytics][neutron] some big tent projects included into 'Neutron Official'

[Ilya Shakhat]

Hi Ihar,

This sounds like a bug - the contents of official group should be in sync
with the governance repo.
I'll take a look what went wrong with it.

Thanks,
Ilya

2016-11-26 2:28 GMT+03:00 Ihar Hrachyshka :

> Hi all,
>
> I am looking at http://stackalytics.com/?project_type=openstack=
> neutron-group and I see some reviews counted for projects that are for
> long out of neutron stadium (f.e. dragonflow or kuryr or
> networking-hyperv). How can we get them excluded from the official neutron
> stats?
>
> I’ve briefly looked at the code, and it seems like the project should
> reflect what’s defined in governance repo, but apparently it’s not the
> case. So what does it reflect?
>
> 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] CI scenarios design - how to add more services

[John Trowbridge]

On 11/22/2016 09:02 PM, Emilien Macchi wrote:
> == Context
> 
> In Newton we added new multinode jobs called "scenarios".
> The challenged we tried to solve was "how to test the maximum of
> services without overloading the nodes that run tests".
> 
> Each scenarios deploys a set of services, which allows us to
> horizontally scale the number of scenarios to increase the service
> testing coverage.
> See the result here:
> https://github.com/openstack-infra/tripleo-ci#service-testing-matrix
> 
> To implement this model, we took example of Puppet OpenStack CI:
> https://github.com/openstack/puppet-openstack-integration#description
> We even tried to keep consistent the services/scenarios relations, so
> it's consistent and easier to maintain.
> 
> Everything was fine until we had to add new services during Ocata cycles.
> Because tripleo-ci repository is not branched, adding Barbican service
> in the TripleO environment for scenario002 would break Newton CI jobs.
> During my vacations, the team created a new scenario, scenario004,
> that deploys Barbican and that is only run for Ocata jobs.
> I don't think we should proceed this way, and let me explain why.
> 
> == Problem
> 
> How to scale the number of services that we test without increasing
> the number of scenarios and therefore the complexity of maintaining
> them on long-term.
> 
> 
> == Solutions
> 
> The list is not exhaustive, feel free to add more.
> 
> 1) Re-use experience from Puppet OpenStack CI and have environments
> that are in a branched repository.
> environments.
> In Puppet OpenStack CI, the repository that deploys environments
> (puppet-openstack-integration) is branched. So if puppet-barbican is
> ready to be tested in Ocata, we'll patch
> puppet-openstack-integration/master to start testing it and it won't
> break stable jobs.
> Like this, we were successfully able to maintain a fair number of
> scenarios and keep our coverage increasing over each cycle.
> 
> I see 2 sub-options here:
> 
> a) Move CI environments and pingtest into
> tripleo-heat-templates/environments/ci/(scenarios|pingtest). This repo
> is branched and we could add a README to explain these files are used
> in CI and we don't guarantee they would work outside TripleO CI tools.

I also like this solution the best. It has the added benefit of being
able to review the CI for a new service in the same patch (or patch
chain) that adds the new service. We already have the low-memory
environment in tht, which while not CI specific, is definitely a CI
requirement.

> b) Branch tripleo-ci repository. Personally I don't like this solution
> because a lot of patches in this repo are not related to OpenStack
> versions, which means we would need to backport most of the things
> from master.
> 
> 2) Introduce branch-based scenario tests -
> https://review.openstack.org/#/c/396008/
> It duplicates a lot of code and it's imho not really effective, though
> this solution would correctly works.
> 
> 3) Introduce a new scenario each time we have new services (like we
> did with scenario004).
> By adding new scenarios at each release because we test new services
> is imho the wrong choice because:
> a) it adds complexity in our we're going to maintain these scenarios.
> b) it consumes more CI resources that we would need when some patches
> have to run all scenarios jobs.
> 
> 
> So I gave my opinion on the solutions, discussion is now open and my
> hope is that we find a consensus soon, so we can make progress in our
> testing coverage.
> Thanks,
> 

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

Re: [openstack-dev] [Openstack-operators] Destructive / HA / fail-over scenarios

[Adam Spiers]

Timur Nurlygayanov  wrote:
> Hi OpenStack developers and operators,
> 
> we are going to create the test suite for destructive testing of
> OpenStack clouds. We want to hear your feedback and ideas
> about possible destructive and failover scenarios which we need
> to check.
> 
> Which scenarios we need to check if we want to make sure that
> some OpenStack cluster is configured in High Availability mode
> and can be published as a "production/enterprise" cluster.
> 
> Your ideas are welcome, let's discuss the ideas of test scenarios in
> this email thread.

I applaud the effort to boost automated testing of failure scenarios!
And thanks a lot for polling the list before starting any work on
this.

Regarding the implementation, did you consider reusing Cloud 99, and
if not, please could you? :-) Obviously it would be good to avoid
reinventing wheels where possible.


https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/high-availability-and-resiliency-testing-strategies-for-openstack-clouds

https://github.com/cisco-oss-eng/Cloud99

If there are some gaps between Cloud99 and what is needed then it
would be worth evaluating them in order to determine whether it makes
sense to start from scratch versus simply develop Cloud99 further.

Also it would be great if you could join the #openstack-ha IRC channel
where you will find friendly folks from the broader OpenStack HA
sub-community who I'm sure will be happy to discuss this further.

You are also very welcome to join our weekly IRC meetings:

https://wiki.openstack.org/wiki/Meetings/HATeamMeeting

Thanks!
Adam

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

[openstack-dev] [Openstack-operators] Destructive / HA / fail-over scenarios

[Timur Nurlygayanov]

Hi OpenStack developers and operators,

we are going to create the test suite for destructive testing of
OpenStack clouds. We want to hear your feedback and ideas
about possible destructive and failover scenarios which we need
to check.

Which scenarios we need to check if we want to make sure that
some OpenStack cluster is configured in High Availability mode
and can be published as a "production/enterprise" cluster.

Your ideas are welcome, let's discuss the ideas of test scenarios in
this email thread.

The spec for High Availability testing is on review: [1]
The user story for destructive testing of OpenStack clouds is
on review: [2].

Thank you!

[1] https://review.openstack.org/#/c/399618/
[2] https://review.openstack.org/#/c/396142

-- 

Timur,
QA Manager
OpenStack Projects
Mirantis Inc
__
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][tc] Exposing project team's metadata in README files

[Flavio Percoco]

On 27/11/16 23:54 +0100, Thomas Goirand wrote:

On 10/12/2016 02:50 PM, Flavio Percoco wrote:

Greetings,

One of the common complains about the existing project organization in
the big
tent is that it's difficult to wrap our heads around the many projects
there
are, their current state (in/out the big tent), their tags, etc.

This information is available on the governance website[0]. Each official
project team has a page there containing the information related to the
deliverables managed by that team. Unfortunately, I don't think this
page is
checked often enough and I believe it's not known by everyone.

In the hope that we can make this information clearer to people browsing
the
many repos (most likely on github), I'd like to propose that we include the
information of each deliverable in the readme file. This information
would be
rendered along with the rest of the readme (at least on Github, which
might not
be our main repo but it's the place most humans go to to check our
projects).

Rather than duplicating this information, I'd like to find a way to just
"include it" in the Readme file. As far as showing the "official" badge
goes, I
believe it'd be quite simple. We can do it the same way CI tags are
exposed when
using travis (just include an image). As for the rest of the tags, it might
require some extra hacking.

So, before I start digging more into this, I wanted to get other
opinions/ideas
on this topic and how we can make this information more evident to the
rest of
the community (and people not as familiar with our processes as some of
us are).

Thanks in advance,
Flavio


Flavio,

While your work seem a good idea to me, you may have been a bit too
quick editing the deb-* repos. Let me explain.

You've opened hundreds of change requests on the openstack/deb-* Gerrit
repository. They are all failing the gate, which is expected.

1/ These changes have nothing to do there, they are to be done on
upstream code.

2/ Never one should touch the master branch of these repositories (only
debian/* are to be edited).

Please abandon all of your changes for the deb-* Gerrit repos.

Thanks for that work anyway,
Cheers,



Hey Thomas,

I actually wanted to reach out to you since I noticed the failures and I was
wondering what the right thing to do there is. Consider these patches abandoned
and thanks for reaching out. :)

Flavio


Thomas Goirand (zigo)


__
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


--
@flaper87
Flavio Percoco


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] [all][tc] Exposing project team's metadata in README files

[Flavio Percoco]

On 28/11/16 03:31 +, joehuang wrote:

Hello, Flavio,

Thank you to move this forward. Is it possible to put the badges at the bottom 
of README.rst file? Just from the code contributors point of view.



Hi :D

You're free to move it at the bottom if that's the preference for your project.
There's no restriction as to where the tags should be, although I'd prefer
readme's to be consistent.

They are not and I think it'll be hard to make them consistent in this round,
Thanks a bunch,
Flavio


Best Regards
Chaoyi Huang (joehuang)


From: Flavio Percoco [fla...@redhat.com]
Sent: 25 November 2016 20:26
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][tc] Exposing project team's metadata in  
README files

On 25/11/16 13:16 +0100, Flavio Percoco wrote:

On 25/11/16 12:38 +0100, Flavio Percoco wrote:

Greetings,

Just a heads up for everyone. The work on this front has moved forward and the
badges are now being generated as part of the governance CI[0].

You can find the list of badges here[1] and the pattern is quite obvious, the
name of the image is based on the project repo name.

I've edited the README files for all repositories listed in the projects.yaml
file and I've started to submit these patches[2]. I'm not a fan of "viral
changes" but I've done my best to explain what's changing, provide references
and examples on the commit message. These changes are being submitted using the
tag 'project-badges'[2].


I also wanted to add that these patches are just for projects that are using rst
for their README files (sorry markdown) and that each commit has a preview link
that you can go and look at.

If the layout doesn't look perfect and the whitespace under the svg image
annoyes you, let me tell you that it was improved in the new layout, which is
under review. Also, Github does some funky things to the svg when it renders the
README file, hence the whitespace that was added for the first layout.


One last thing. You may/may not like the placement of these badges in the README
file. It's fine if you don't. The reason they are at the top is because they
normally are at the top :) Putting them at the top also made it simple to
automate the process accross all the *very* (trust me VERY) different README
files across the community.

If you don't like the placement of these badges, you're free to move them around
as prefer. I've done the job to help pushing the first patch, you're all free to
take it over, modify it, reject it or just merge it as is.

Hope this helps,
Flavio


Flavio


Note that these badges are *JUST* a graphical representation of what's in the
governance repo. If you don't want to have them in the README file, I guess it's
fine. I'd, however, encourage everyone to add them to provide consistency and a
more immediate information of what the project is about, what some of the
project capabilities are and what its status is.

Ideally this should also be added in projects documentation as well but I'll
leave that to every team to do.

Happy to answer questions,
Flavio

P.S: The current layout is being improved[3], if you have better ideas please
help out.

[0] https://review.openstack.org/#/c/391588/
[1] http://governance.openstack.org/badges/
[2] https://review.openstack.org/#/q/topic:project-badges
[3] https://review.openstack.org/#/c/399278/

On 12/10/16 14:50 +0200, Flavio Percoco wrote:

Greetings,

One of the common complains about the existing project organization in the big
tent is that it's difficult to wrap our heads around the many projects there
are, their current state (in/out the big tent), their tags, etc.

This information is available on the governance website[0]. Each official
project team has a page there containing the information related to the
deliverables managed by that team. Unfortunately, I don't think this page is
checked often enough and I believe it's not known by everyone.

In the hope that we can make this information clearer to people browsing the
many repos (most likely on github), I'd like to propose that we include the
information of each deliverable in the readme file. This information would be
rendered along with the rest of the readme (at least on Github, which might not
be our main repo but it's the place most humans go to to check our projects).

Rather than duplicating this information, I'd like to find a way to just
"include it" in the Readme file. As far as showing the "official" badge goes, I
believe it'd be quite simple. We can do it the same way CI tags are exposed when
using travis (just include an image). As for the rest of the tags, it might
require some extra hacking.

So, before I start digging more into this, I wanted to get other opinions/ideas
on this topic and how we can make this information more evident to the rest of
the community (and people not as familiar with our processes as some of us are).

Thanks in advance,
Flavio

[0] 

Re: [openstack-dev] [kolla][release][requirements] providing constraints for transitive dependencies

[Steven Dake (stdake)]

Tony

A+ on the explanation.

Thanks, dude, you rock!  That solves the exact problem.  I think what we need 
is an override for upper-constraints.txt in Kolla.

Regards
-steve

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

Date: Monday, November 28, 2016 at 2:06 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla][release][requirements] providing 
constraints for transitive dependencies

On Mon, Nov 28, 2016 at 08:15:17AM +, Steven Dake (stdake) wrote:
> Tony,
> 
> Are you indicating that all transitive dependencies (e.g. nova depends on 
x
> depends on y, y = version of dep we want to specify) are in
> global-requirements.txt?

So in order to reduce confusion I'll try to explain this in a little more
detail but the TL;DR is:

No only nova's direct requirements are in global-requirements.txt.  *all*
requirements are in upper-constraints.txt.

Now the longer version:

 * nova requires oslo.messaging, which is listed in 
openstack/nova:requirements.txt.
 * openstack/nova:requirements.txt is regularly updated by the proposal-bot 
with
   the relevant parts of global-requirements.txt
 * the nova project runs the 'check-requirements' jobs ensuring that
   everything in:
openstack/nova:requirements.txt
openstack/nova:test-requirements.txt
and relevant parts of openstack/nova:setup.cfg
   are listed in global-requirements.
 * As oslo.messaging is an OpenStack project it's bound by the same rules 
above
 * However any non-OpenStack libraries used by either nova or oslo.messaging
   are not in global-requirements.txt.  There is a nightly job that installs
   all of global-requirements.txt (and dependencies) and tracks the exact
   version of each library in a file ... upper-constraints.txt

So anything you need to install to use any part of OpenStack[1] will be 
listed
in upper-constraints.txt.

So if you really need to install version $x of library $foo you can edit
upper-constraints.txt to state that.

There are a couple of gotchas.  I recommend you use edit-constraints from
openstack-requirements (on pypi) to actually edit the constraints files.  
Also if
you're doing anything "too funky" you're probably best actually editing a
requirements and then using generate-constraints to actually generate the
constraints file.  That's time/network expensive but will result in a valid 
set
where editing the constraints file at will could result in an
incompatible and thus uninstallable system.

I really hope that helps and hasn't just confused the situation.

Yours Tony.


__
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] [tap-as-a-service] stable/newton 'broken'

[Takashi Yamamoto]

Anil,

do you have any opinion?

i'm thinking to branch stable/newton at around
675af77205d4e404bc7c185c13ab6d86f300d185

On Thu, Nov 24, 2016 at 6:25 PM, Takashi Yamamoto  wrote:
> hi,
>
> On Thu, Nov 24, 2016 at 6:00 PM, Gary Kotton  wrote:
>> Please see - 
>> http://logs.openstack.org/82/401882/1/check/gate-vmware-nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-24_06_58_38_520273
>> Here we are pulling trunk as there is no stable version to use
>
> thank you.
> tap-as-a-service doesn't have any stable branches or releases yet.
>
> taas folks,
> given increasing demands (networking-midonet also will depend on it)
> i guess it makes sense to create newton branch.
> if we don't think it's mature enough, we can call it experimental or
> tech-preview or whatever.
> how do you think?
>
>>
>> On 11/24/16, 10:00 AM, "Takashi Yamamoto"  wrote:
>>
>> can you give me an example of breakage?
>>
>> On Thu, Nov 24, 2016 at 4:19 PM, Gary Kotton  wrote:
>> > Hi,
>> >
>> > The change https://review.openstack.org/#/c/386845/ that landed 
>> yesterday
>> > has caused a breakage in stable/newton. This is due to the fact that 
>> the
>> > following projects do not have stable/newton tags:
>> >
>> > -  
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_tap-2Das-2Da-2Dservice=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=dXUw9DykF46Tk1oluf1fQMVmbhNKHbwG_scuNyTpXrM=
>> >
>> > -  
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_networking-2Dl2gw=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=DFa6PGUhmT9xowY1VGPsddAUZYVmZX2YsX9NIHQMpK0=
>> >
>> > Can the relevant release teams of the projects above please create the
>> > relevant tags.
>> >
>> > 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
>> >
>>
>> 
>> __
>> 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] [QA] The end-user test suite for OpenStack clusters

[Timur Nurlygayanov]

Hi team,

here is a short update:

1) The QA user story for destructive testing of OpenStack cloud is on
review [1].
2) The spec for a new framework which will focus on HA/failover and
destructive testing is no review [2].
3) The commit for the new repository is on review [3] as well.

[1] https://review.openstack.org/#/c/396142
[2] https://review.openstack.org/#/c/399618
[3] https://review.openstack.org/#/c/374667


On Fri, Oct 14, 2016 at 3:47 AM, Ghanshyam Mann <
ghanshyam.m...@nectechnologies.in> wrote:

> I like os-faults library which can provide the abstraction over different
> destructive actions like reboot/poweroff node etc.
>
>
>
> But not much clear about Stepler that what all tests it will contain.
> Tempest do have scenario tests which can hit the production env with
> significant way of testing scenario.
>
> It can cover the end user scenario also which involves the interaction of
> public OpenStack APIs and always in enhancement state by adding more and
> more scenario tests.
>
>
>
> Few query over Stepler as separate project:
>
> 1.   Is Stepler will cover only tests which hits the node level
> action(reboot, HA etc)?
>
> 2.   This should not mix the scenario tests which are in Tempest
> scope because that can make confusion for developers (where to add scenario
> tests) as well as for tester(from where to run what scenario tests).
>
> 3.   How we make sure those tests run fine or at least run while
> adding.
>
> a.   I think devstack enhancement for multi-node etc can do this as
> mentioned by you also.
>
> b.  If so then why not adding those tests in Tempest only using
> os-faults lib ?
>
>
>
> Overall I feel os-faults  as lib is really nice idea but tests scope can
> go in Tempest under HW_scenario  (or something else) till it does not break
> basic principle of Tempest.
>
>
>
> Thanks
>
> gmann
>
>
>
> *From:* Timur Nurlygayanov [mailto:tnurlygaya...@mirantis.com]
> *Sent:* 06 October 2016 20:09
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [QA] The end-user test suite for OpenStack
> clusters
>
>
>
> Ken, it is a good idea!
>
>
>
> The plan is to develop os-faults as a library which will be able
>
> to manage cluster nodes and OpenStack services on these nodes.
>
> It is a good idea to add some Tempest tests which will use
>
> os-faults library as well for some API tests.
>
>
>
> The Stepler framework [1] will use os-faults to perform all destructive
>
> actions in the clouds (the reboot of nodes, restart of OpenStack services,
>
> enable/disable network interfaces or some firewall rules and etc).
>
>
>
> We need to get +1 from you in [1] to create the repository with
>
> advanced end-user scenario tests.
>
>
>
> Thank you!
>
>
>
> [1] https://review.openstack.org/#/c/374667/
>
>
>
> On Tue, Oct 4, 2016 at 8:53 PM, Yaroslav Lobankov 
> wrote:
>
> Hi Ken,
>
>
>
> OS-Faults doesn't have any scenarios in the tree yet (the project is two
> months old), but you can find some examples of the use in the
> os-faults/examples directory.
>
>
>
> Regards,
>
> Yaroslav Lobankov.
>
>
>
> On Tue, Oct 4, 2016 at 8:02 PM, Ken'ichi Ohmichi 
> wrote:
>
> Hi Timur,
>
> Thanks for your explanation.
>
>
> 2016-09-29 6:22 GMT-07:00 Timur Nurlygayanov :
> >
> >> I am guessing the above "restart nodes" is for verifying each
> >> OpenStack service restarts successfully, right?
> >
> > Yes, this is right. And we also will check that HA logic for these
> > services works correctly (for example, rescheduling of L3 Neutron
> > agents for networks).
> >
> >> But these service scripts are provided by distributors, and Devstack
> >> itself doesn't contain service scripts IIUC.
> >> So I'd like to know how to verify it on Devstack clouds.
> >
> > Yes, DevStack doesn't support many scenarios which are actual
> > and should be supported on the production clouds.
> > It will be not possible to run all advanced test scenarios for DevStack
> > clouds,
> > just because DevStack can't deploy OpenStack cloud with 3 controllers
> > now (so, probably it will be possible in the future).
> >
> > Of course, some advanced scenarios will support DevStack clouds,
> > for example, some test scenarios which are based on customer-found
> > issues from the real production clouds, like upload of the large images
> > (100+ Gb)
> > to Glance with Swift backend. Such cases are important for verification
> of
> > pre-production environments, but not very important for CI gate jobs.
> >
> > It is also important to note that in these advanced cases we are
> targeting
> > to check not only the logic of Python code, but also the correct
> > configuration
> > of all OpenStack components on some pre-production OpenStack clusters.
>
> I guessed some part of os-faults can be moved to Tempest if os-faults
> contains API tests for enabling/disabling OpenStack 

Re: [openstack-dev] [infra][neutron] Intel NFV CI voting permission in Neutron

[Ihar Hrachyshka]

> On 26 Nov 2016, at 00:06, Ihar Hrachyshka  wrote:
> 
>> 
>> On 14 Nov 2016, at 11:44, Znoinski, Waldemar  
>> wrote:
>> 
>> Hi Neutron, Infra Cores et al,
>> I would like to acquire voting (+/-1 Verified) permission for our Intel NFV 
>> CI.
>> 
>> 1. It's running on Neutron changes since Q1'2015.
>> 2. Wiki [1].
>> 3. It's using openstack-infra/puppet-openstackci [2] with Zuul 2.1.1 for 
>> last 8 months: zuul, gearman, Jenkins, nodepool, local Openstack cloud with 
>> VMs and baremetal servers (where needed).
>> 4. We have a team of 2 people + me + Nagios looking after it. Its problems 
>> are fixed promptly and rechecks triggered after non-code related issues. 
>> It's being reconciled against ci-watch [3] and gerrit using [4].
>> 5. It has a good record of testing for Nova, also voting for last 4 months 
>> [5].
>> 
>> [1] https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_NFV_CI
>> [2] https://github.com/openstack-infra/puppet-openstackci
>> [3] http://ci-watch.tintri.com/project?project=neutron
>> [4] https://review.openstack.org/#/c/382262/
>> [5] 
>> https://review.openstack.org/#/q/reviewer:%22Intel+NFV-CI+%253Copenstack-nfv-ci%2540intel.com%253E%22
>> 
> 
> This CI just -1d a patch that I don’t believe may break NFV: 
> https://review.openstack.org/#/c/308005/
> 
> Looking into logs, it seems like job took too much time, so it timed out. 
> It’s hard to tell why it happens, partly because console.html doesn’t give 
> proper timestamps. Per test times don’t look suspicious. BTW are tests 
> executed with a single test runner? (I see only {0} runner in the console 
> output).
> 
> Ihar

I see this CI voting -1 for all patches for silly reasons like "Temporary 
failure resolving ‘apt.ir.intel.com'":

http://intel-openstack-ci-logs.ovh/08/360908/31/check/tempest-dsvm-ovsdpdk-nfv-networking-xenial/bbf9f86/console.html

I suggest we disable votes for the setup until it’s fixed.

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] [stable][sahara] Drop icehouse branches from repositories

[Tony Breeds]

On Tue, Nov 22, 2016 at 06:17:59PM +0300, Vitaly Gridnev wrote:
> Hello,
> 
> Several days ago I’ve noticed that sahara-extra and sahara-image-elements
> repositories still have icehouse branch. Could someone help us with removing
> these branches? Thanks in advance. 

I can help you to take care of these.  It's on my list of things to do after I
complete the current liberty EOL.  I'll start with yours if you like :)

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] [ALU] [vitrage] common vs utils

[Weyl, Alexey (Nokia - IL)]

Sounds good to me ☺

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Monday, November 28, 2016 10:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] [openstack-dev] [vitrage] common vs utils

Currently, we have `common/utils.py`, `common/file_utils.py` and an empty 
module `utils` in `vitrage`.

In my understanding, `common` means common to vitrage package and utils are 
more general purpose utility functions.

Would it better that we move `utils.py`, `file_utils.py` and 
`datetime_utils.py` to `utils`?

--
Yujun
__
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] [new][nimble] New project: Nimble

[Zhenguo Niu]

On Mon, Nov 28, 2016 at 1:37 PM, Jay Pipes  wrote:
>
>
> For the RackScale Architecture stuff, the Valence project seems to be
> doing that and I'm not sure what role Nimble would play.
>

For Valence, as my understanding, it provides interfaces to help
compose/release nodes. Nimble will talk to Valence to compose nodes for
users' requests, then enroll the composed node to Ironic to provision it
like generic nodes. Another way is to add Valence to Nova as a driver or
integrate into ironic dirver, but I think it's not easiliy possible. Please
correct me if I misunderstand Valance, thanks!

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

Re: [openstack-dev] [kolla] Notes on Ansible fact gathering

[Christian Berendt]

> On 23 Nov 2016, at 12:12, Paul Bourke  wrote:
> 
> In the cases where users have 500 control nodes and want to add five more 
> sequentially (the value of doing more than one sequentially is still not 
> clear to me), we could look into turning on fact caching.

At https://betacloud.io/speedup-kolla-with-ansible-fact-caching/ I documented a 
few months ago how to enable fact caching for Kolla or for ansible in general. 
Possibly it is helpful for someone who wants to test it.

-- 
Christian Berendt
Chief Executive Officer (CEO)

Mail: bere...@betacloud-solutions.de
Web: https://www.betacloud-solutions.de

Betacloud Solutions GmbH
Teckstrasse 62 / 70190 Stuttgart / Deutschland

Geschäftsführer: Christian Berendt
Unternehmenssitz: Stuttgart
Amtsgericht: Stuttgart, HRB 756139


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

Re: [openstack-dev] [kolla] the alternative of log processing tool

[Christian Berendt]

> On 27 Nov 2016, at 06:55, Jeffrey Zhang  wrote:
> 
> * Fluentd
> * Logstash

I do not have a strong behaviour.

At the moment we use the E and K of the ELK stack. Because of that I think it 
makes sense to go with Logstash. In this way, we have a stack developed by one 
community and which is tuned to each other.

Christian.

-- 
Christian Berendt
Chief Executive Officer (CEO)

Mail: bere...@betacloud-solutions.de
Web: https://www.betacloud-solutions.de

Betacloud Solutions GmbH
Teckstrasse 62 / 70190 Stuttgart / Deutschland

Geschäftsführer: Christian Berendt
Unternehmenssitz: Stuttgart
Amtsgericht: Stuttgart, HRB 756139


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

Re: [openstack-dev] [kolla][release][requirements] providing constraints for transitive dependencies

[Tony Breeds]

On Mon, Nov 28, 2016 at 08:15:17AM +, Steven Dake (stdake) wrote:
> Tony,
> 
> Are you indicating that all transitive dependencies (e.g. nova depends on x
> depends on y, y = version of dep we want to specify) are in
> global-requirements.txt?

So in order to reduce confusion I'll try to explain this in a little more
detail but the TL;DR is:

No only nova's direct requirements are in global-requirements.txt.  *all*
requirements are in upper-constraints.txt.

Now the longer version:

 * nova requires oslo.messaging, which is listed in 
openstack/nova:requirements.txt.
 * openstack/nova:requirements.txt is regularly updated by the proposal-bot with
   the relevant parts of global-requirements.txt
 * the nova project runs the 'check-requirements' jobs ensuring that
   everything in:
openstack/nova:requirements.txt
openstack/nova:test-requirements.txt
and relevant parts of openstack/nova:setup.cfg
   are listed in global-requirements.
 * As oslo.messaging is an OpenStack project it's bound by the same rules above
 * However any non-OpenStack libraries used by either nova or oslo.messaging
   are not in global-requirements.txt.  There is a nightly job that installs
   all of global-requirements.txt (and dependencies) and tracks the exact
   version of each library in a file ... upper-constraints.txt

So anything you need to install to use any part of OpenStack[1] will be listed
in upper-constraints.txt.

So if you really need to install version $x of library $foo you can edit
upper-constraints.txt to state that.

There are a couple of gotchas.  I recommend you use edit-constraints from
openstack-requirements (on pypi) to actually edit the constraints files.  Also 
if
you're doing anything "too funky" you're probably best actually editing a
requirements and then using generate-constraints to actually generate the
constraints file.  That's time/network expensive but will result in a valid set
where editing the constraints file at will could result in an
incompatible and thus uninstallable system.

I really hope that helps and hasn't just confused the situation.

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] [vitrage] common vs utils

[Yujun Zhang]

Currently, we have `common/utils.py`, `common/file_utils.py` and an empty
module `utils` in `vitrage`.

In my understanding, `common` means *common to vitrage package* and utils
are more *general purpose utility* functions.

Would it better that we move `utils.py`, `file_utils.py` and
`datetime_utils.py` to `utils`?

--
Yujun
__
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] NeutronLibImpact: Adoption of db *_FIELD_SIZE constants from neutron-lib

[Gary Kotton]

Ok, makes sense. Lets continue as you proposed.

On 11/27/16, 10:44 PM, "Henry Gessau"  wrote:

Gary Kotton  wrote:
> Would it be worth considering have the three patches:
> https://review.openstack.org/399891, https://review.openstack.org/398113
> and  https://review.openstack.org/398489 based one on top of the other.
> Then all sub projects could take the top of the commit and base on top of
> that. That may make the process a little more efficient.

The problem is that the ExtensionDescriptor change has its own specific 
order
in which the patches must be done, as explained in
http://lists.openstack.org/pipermail/openstack-dev/2016-November/108005.html

My recommendation is that ExtensionDescriptor be done first. Then we could
stage the PLURALS and _FIELD_SIZES as you suggest, but the PLURALS change is
quite independent, so it could be done in parallel with ExtensionDescriptor.

Once ExtensionDescriptor, PLURALS and _FIELD_SIZES are done, then we will be
in a position to remove attributes.py from core neutron. That is the aim of
this little dance.

> Thanks
> Gary
>  
>
> 
> 
> On 11/26/16, 9:03 AM, "Henry Gessau"  wrote:
> 
> The following _MAX_LEN constants are being removed from
> neutron/api/v2/attributes.py in [1]. The corresponding DB field size
> constants from neutron_lib.db.constants should be used instead.
> 
> All subproject maintainers should update their code to use the
> the db *_FIELD_SIZE constants from neutron-lib.
> 
> I have submitted patches [2] for most subprojects.
> 
>  NAME_MAX_LEN  -->  NAME_FIELD_SIZE
>  TENANT_ID_MAX_LEN -->  PROJECT_ID_FIELD_SIZE
>  DESCRIPTION_MAX_LEN   -->  DESCRIPTION_FIELD_SIZE
>  LONG_DESCRIPTION_MAX_LEN  -->  LONG_DESCRIPTION_FIELD_SIZE
>  DEVICE_ID_MAX_LEN -->  DEVICE_ID_FIELD_SIZE
>  DEVICE_OWNER_MAX_LEN  -->  DEVICE_NAME_FIELD_SIZE
> 
> In alembic migration scripts, the raw numerical value shall be used.
> 
> For more information, see [3].
> 
> [1] https://review.openstack.org/399891
> [2] 
https://review.openstack.org/#/q/status:open+topic:use-db-field-sizes
> [3] 
http://lists.openstack.org/pipermail/openstack-dev/2016-October/105789.html
> 
> 
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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


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

Re: [openstack-dev] [kolla][release][requirements] providing constraints for transitive dependencies

[Steven Dake (stdake)]

Clark,

Cool didn’t know the transitive deps were specified in upper-constraints.txt.  
Learning new things 24/7 it seems ☺  I’m pretty sure we can work with that and 
just override the upper constraints file we use.

Regards
-steve


-Original Message-
From: Clark Boylan 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Sunday, November 27, 2016 at 8:02 PM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [kolla][release][requirements] providing 
constraints for transitive dependencies

On Sun, Nov 27, 2016, at 06:53 PM, Jeffrey Zhang wrote:
> FWIW, python dependencies are fixed.
> Kolla is using the following command in Dockerfile for source code
> installation.
> 
> pip install -u /requirements/upper-constrains.txt /nova

I think you need a to use the -c option to set the constraints file.

> 
> then all python dependencies installed will use a fixed version from
> upper-constrains.txt.

Yup, constraints apply to transitive deps as well. Keep in mind you
don't have to use the published upper-constraints either, but they are
an easy way to use a known tested set that works with upstream gating.

> 
> [0]
> 
https://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html
> [1]
> 
https://github.com/openstack/requirements/blob/master/upper-constraints.txt
> 
> On Mon, Nov 28, 2016 at 10:41 AM, Steven Dake (stdake) 
> wrote:
> 
> > Hey folks,
> >
> >
> >
> > I get a lot of requests for variance reduction of transitive 
dependencies
> > in Kolla’s containers.  As an example, we build from source nova.  Nova
> > itself we can specify a version to install in the containers during 
build
> > time.  Nova’s python dependencies, not so much.  Is there a best 
practice
> > for doing such in the python ecosystem?
> >
> >
> >
> > Binary distributions don’t typically suffer from this problem.  They
> > deliver one version of dependencies, and that is what you get.  That is
> > what a slew of folks are after with from source container builds.  Any
> > advice from the requirements team or release team welcome as the folks 
on
> > those teams have the most experience with this sort of thing.
> >
> >
> >
> > If this has been asked by someone else in a different context and
> > answered, a pointer to that discussion would work too J

> 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] [kolla][release][requirements] providing constraints for transitive dependencies

[Steven Dake (stdake)]

Tony,

Are you indicating that all transitive dependencies (e.g. nova depends on x 
depends on y, y = version of dep we want to specify) are in 
global-requirements.txt?

Regards
-steve


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

Date: Sunday, November 27, 2016 at 9:42 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla][release][requirements] providing 
constraints for transitive dependencies

On Mon, Nov 28, 2016 at 02:41:08AM +, Steven Dake (stdake) wrote:
> Hey folks,
> 
> I get a lot of requests for variance reduction of transitive dependencies 
in
> Kolla’s containers.  As an example, we build from source nova.  Nova 
itself
> we can specify a version to install in the containers during build time.
> Nova’s python dependencies, not so much.

I'm not certain I follow.  You're using upper-constraints for install time
consistent version selection, and that applies to *all* dependencies no 
matter
how many levels down they are.  You *could* extract and manipulate the 
upper-constraints
file for each container, and assuming 1 container 1 service that will 
probably
give you want you want.  The only trick is for data that is passed over the 
RPC
between services.  For example having different versions of oslo.context in 
the
nova conductor and nova-compute containers would be a bad thing.

Is that kinda what you're asking?

If not a more concrete example would be very helpful.

> Is there a best practice for doing such in the python ecosystem?

Nope.  in the python eco-system you more or less get what you ask for and 
it;s
up to you to find a spot on the prescriptive <-> flexible line.

Yours Tony.


__
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] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC Nov. 25 2016

[hu . zhijiang]

Minutes:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-11-25-08.00.html
 

Minutes (text): 
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-11-25-08.00.txt
 

Log:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-11-25-08.00.log.html
 


B.R.,
Zhijiang


__
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