Re: [openstack-dev] [Senlin]Nominating Ruijie Yuan for Senlin core reviewer

[Qiming Teng]

+1 to this. Very happy to work with him.

- Qiming

On Fri, Nov 11, 2016 at 02:27:50PM +0800, Yanyan Hu wrote:
> Hi Senlin core team,
> 
> I'd like to nominate Ruijie Yuan(IRC name 'ruijie') for Senlin core
> reviewer.
> 
> Ruijie started to work on Senlin since the beginning of Newton cycle and he
> has made significant contribution to Senlin project in last three months
> including the batch policy support, versioned API support and etc.. He is
> also actively interacting with the team for bug fix, blueprint discussion
> and code review. I have talked with him and he expressed strong enthusiasm
> and will to contribute to Senlin project and I believe he will make a great
> addition to the core review team.
> 
> So please put your +1 or -1 here. Please note any -1 will be a veto for
> this nomination. I will collect the result in seven days.
> 
> Thanks you so much!
> 
> http://stackalytics.com/report/contribution/senlin-group/60
> 
> -- 
> Best regards,
> 
> Yanyan

> __
> 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] [Senlin]Nominating Ruijie Yuan for Senlin corereviewer

[吕冬兵]

+1, Welcome Ruijie Yuan
 
 
-- Original --
From:  "Yanyan Hu";
Date:  Fri, Nov 11, 2016 02:27 PM
To:  "openstack-dev"; 

Subject:  [openstack-dev] [Senlin]Nominating Ruijie Yuan for Senlin corereviewer

 
Hi Senlin core team, 
 
 I'd like to nominate Ruijie Yuan(IRC name 'ruijie') for Senlin core reviewer.
 
 
Ruijie started to work on Senlin since the beginning of Newton cycle and he has 
made significant contribution to Senlin project in last three months including 
the batch policy support, versioned API support and etc.. He is also actively 
interacting with the team for bug fix, blueprint discussion and code review. I 
have talked with him and he expressed strong enthusiasm and will to contribute 
to Senlin project and I believe he will make a great addition to the core 
review team.


So please put your +1 or -1 here. Please note any -1 will be a veto for this 
nomination. I will collect the result in seven days.



Thanks you so much!

http://stackalytics.com/report/contribution/senlin-group/60


-- 
Best regards,

Yanyan__
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] [Senlin]Nominating Ruijie Yuan for Senlin core reviewer

[Yanyan Hu]

Hi Senlin core team,

I'd like to nominate Ruijie Yuan(IRC name 'ruijie') for Senlin core
reviewer.

Ruijie started to work on Senlin since the beginning of Newton cycle and he
has made significant contribution to Senlin project in last three months
including the batch policy support, versioned API support and etc.. He is
also actively interacting with the team for bug fix, blueprint discussion
and code review. I have talked with him and he expressed strong enthusiasm
and will to contribute to Senlin project and I believe he will make a great
addition to the core review team.

So please put your +1 or -1 here. Please note any -1 will be a veto for
this nomination. I will collect the result in seven days.

Thanks you so much!

http://stackalytics.com/report/contribution/senlin-group/60

-- 
Best regards,

Yanyan
__
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] End of week wrap-up

[Richard Jones]

Hi folks,

We had our kickoff Keystone/Horizon cross-project meeting[1] which was
super productive, and we've settled on Thursday 2000UTC as the meeting
time going forward. We'll meet in #openstack-meeting-cp - details
here[2]. The range of topics was broad, both on the Horizon and
Keystone side. We'll be keeping the etherpad created at the summit
updated with our discussions and progress[3].

In our team meeting this week[4] we covered a few topics, notably:

- a status update of the priority patches
- xstatic-angular-ui-router is now an OpenStack project, and in
global-requirements, ready for use O-2 patches
- issues we need to consider around updating angular-bootstrap, and
not breaking stable Horizon
- discussion about the PTG

Ocata-1 will be tagged next week, so if you can it'd be super helpful
to focus reviews on the patches we really need to land in that
release[5].

Catch you next week in #openstack-horizon


 Richard

[1] 
http://eavesdrop.openstack.org/meetings/horizon_keystone/2016/horizon_keystone.2016-11-08-20.01.html
[2] http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting
[3] https://etherpad.openstack.org/p/ocata-keystone-horizon
[4] 
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-11-09-20.00.html
[5] https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status:open

__
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] Spec review sprint on Monday 11/14

[Matt Riedemann]

As discussed in the nova meeting today [1] we're going to have a spec 
review sprint on Monday 11/14 (next week). A few things to keep in mind:


1. Spec approval freeze is next Thursday 11/17. We'll get in what we can 
and may have some exceptions for priority specs after that if they are 
close, but not everything is going to get in.


2. If you have a spec that's up for review, please be available in the 
#openstack-nova IRC channel on Monday to answer any questions reviewers 
may have so we can be as efficient as possible. If you can't be in the 
channel, then please respond to comments in the spec as soon as possible 
to minimize review latency.


3. I've started an etherpad here [2] which is a list of top things I'm 
already tracking for the release based on discussions at the summit or 
other priorities. I'd like reviewers to use that list as a starting 
point and then move on to other open specs up for review once we can get 
through that list. That list may grow or shrink a bit, but please don't 
add your own specs to it. Ping me if you need to lobby to get something 
in there.


4. Finally, we already have 45 approved but not yet implemented 
blueprints targeted for Ocata [3]. We also have a shorter schedule and 
fewer core reviewers for the entire cycle, so we're going to be very 
selective about how much load we can take on so please understand if 
your blueprint doesn't get approved for Ocata and try to help out with 
getting the other things that are approved done. We can only take on new 
debt when we pay off the old, or at least that's the idea.


[1] 
http://eavesdrop.openstack.org/meetings/nova/2016/nova.2016-11-10-21.00.html

[2] https://etherpad.openstack.org/p/nova-ocata-spec-review-sprint
[3] https://blueprints.launchpad.net/nova/ocata

--

Thanks,

Matt Riedemann


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

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Nov. 11 2016

[hu . zhijiang]

Please feel free to add what you need to discuss.

1) Roll Call
2) OPNFV: Escalator Support
3) OPNFV: CI Progress
4) Core Code Abstraction
5) Newton




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

[openstack-dev] [Neutron] Transition to Ubuntu Xenial in the gate

[Armando M.]

Hi Neutrinos,

Some of you may be aware of our CI jobs have been transitioning to Xenial.
There are a few jobs still left and taking into account mail [1] we need to
accelerate the process a bit, especially for those jobs that affect our
gate queue or are voting.

Ajo put together [2], I also added a provisional 'xenial' launchpad bug tag
[3] to track fixes required to get us in tip-top shape.

Please help out as you can.

Cheers,
Armando

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-November/106906.html
[2] https://etherpad.openstack.org/p/moving-neutron-jobs-to-xenial
[3] https://bugs.launchpad.net/neutron/+bugs?field.tag=xenial
__
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

[Michael Johnson]

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
>>>
>>>+--+-
>>>-+++-+---
>>>+
>>> | ID   | Name
>>> | Status | Task State | Power State | Networks
>>> |
>>>
>>>+--+-
>>>-+++-+---
>>>+
>>> | 557a3de3-a32e-419d-bdf5-41d92dd2333b |
>>> amphora-dad2f14e-76b4-4bd8-9051-b7a5627c6699 | ACTIVE | -  |
>>>Running
>>> | lb-mgmt-net=192.168.0.4; vipnet=100.100.100.4 |
>>>
>>>+--+-
>>>-+++-+‹‹‹
>>>+

[openstack-dev] [charms] Default KeystoneV3 Creds

[James Beedy]

Concerning the Juju Keystone charm, and api v3, can someone shed some light
on how to find the default admin creds needed to access the keystone api,
or what the novarc file might look like? I'm setting the 'admin-password'
config of the keystone charm to "openstack", and am using this ->
http://paste.ubuntu.com/23458768/ for my .novarc, but am getting a 401 ->
http://paste.ubuntu.com/23458782/

Is there something I'm missing here?

thx
__
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] dhclient spawned by dhcp-all-interfaces doesn't exit when os-net-config runs

[Bob Fournier]

- Original Message -
> From: "Dan Sneddon" 
> To: openstack-dev@lists.openstack.org
> Sent: Wednesday, November 9, 2016 4:28:55 PM
> Subject: [openstack-dev] [TripleO] dhclient spawned by dhcp-all-interfaces 
> doesn't exit when os-net-config runs
> 
> I just opened a bug [1] for behavior which has recently been observed
> when deploying nodes with TripleO. The problem is that the dhclient
> processes that are being started by the dhcp-all-interfaces element in
> disk-image-builder are not stopping after os-net-config runs.
> 
> Step 1) Image deploys with udev rule to create
> dhcp-interface@.service, which configures each interface via DHCP.
> 
> Step 2) The deployment scripts run, including os-net-config, which
> configures and restarts the interfaces. The udev rule is removed.
> 
> At this point, the dhclient which was created by the udev rule is no
> longer needed, except it is still running and configuring IP and routes
> on the interface, possibly in conflict with the desired configuration.
> For instance, the same IP appearing on a bridge and on an interface, or
> a rogue default route and IP that hijack the default route.
> 
> I believe this behavior is new in RHEL 7.3, but I don't know if any
> versions of CentOS are affected yet (testing is in progress).
> 
> Running 'systemctl restart network' after os-net-config runs will kill
> the dhclient processes, so inserting that into the scripts after
> os-net-config is run is one possible workaround, although the brief
> interruption in networking might cause unknown issues in
> high-availability environments.
> 
> Does anyone have a suggestion for a kinder, gentler, less hacky
> approach than either restarting the network service or running kill on
> the dhclient processes? Also, does anyone have any idea why running
> "ifdown " followed by "ifup " doesn't stop the dhclient
> process started by the udev rule? Or why this behavior appears to be
> new to RHEL 7.3?

Dan,

Fix proposed here[2] to stop dhclient instances in os-net-config using
'-r' argument if the interface is not configured for DHCP. 

Bob 

[2]https://review.openstack.org/#/c/396446/

> 
> [1] - https://bugs.launchpad.net/tripleo/+bug/1640598
> 
> --
> Dan Sneddon |  Senior Principal OpenStack Engineer
> dsned...@redhat.com |  redhat.com/openstack
> dsneddon:irc|  @dxs:twitter
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [all][infra][requirements] Odd cases in requirements?

[Tony Breeds]

On Fri, Nov 11, 2016 at 12:08:04PM +1300, Robert Collins wrote:
> On 10 Nov 2016 9:29 PM, "Tony Breeds"  wrote:
> >
> > On Thu, Nov 10, 2016 at 08:48:16PM +1300, Robert Collins wrote:
> >
> > > We generate multiline constraints whenever versions are different
> > > between python 2 and 3 for the same package. That was happening when I
> > > wrote the tool in the first place - it was one of the reasons I wrote
> > > edit-constraints, to avoid writing silly-awkward sed. (A multiline
> > > constraint when sedd'd will error with 'requirement already supplied'
> > > or whatever the pip error string is.
> >
> > Okay.  It's unlikley that we'll hit that case but not impossible.
> 
> Currently happening to dnspython3 right now :)

Sure, but that's a little different to what we're talking about here.

I'd really like to hope[1] that we don't have any *openstack* projects that
have multiple lines of constratins.  Even if we did sed would handle that.

Regardless, we'll use edit-constratins as that'll work on windows.

Yours Tony.

[1] Yes I know "Hope is not a strategy" ;P


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] [Neutron][neutron-lbaas][octavia] Not be able to ping loadbalancer ip

[Wanjing Xu (waxu)]

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
>> 
>>+--+-
>>-+++-+---
>>+
>> | ID   | Name
>> | Status | Task State | Power State | Networks
>> |
>> 
>>+--+-
>>-+++-+---
>>+
>> | 557a3de3-a32e-419d-bdf5-41d92dd2333b |
>> amphora-dad2f14e-76b4-4bd8-9051-b7a5627c6699 | ACTIVE | -  |
>>Running
>> | lb-mgmt-net=192.168.0.4; vipnet=100.100.100.4 |
>> 
>>+--+-
>>-+++-+‹‹‹
>>+
>>
>> And it seemed that amphora created a port from the vipnet for its
>>vrrp_ip,
>> but now sure how it is used and how it is supposed to help packet to
>>reach
>> loadbalancer ip
>>
>> It will be great if somebody can help on this, especially on network
>>side.
>>
>> Thanks
>> Wanjing
>>
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 

Re: [openstack-dev] [all][infra][requirements] Odd cases in requirements?

[Robert Collins]

On 10 Nov 2016 9:29 PM, "Tony Breeds"  wrote:
>
> On Thu, Nov 10, 2016 at 08:48:16PM +1300, Robert Collins wrote:
>
> > We generate multiline constraints whenever versions are different
> > between python 2 and 3 for the same package. That was happening when I
> > wrote the tool in the first place - it was one of the reasons I wrote
> > edit-constraints, to avoid writing silly-awkward sed. (A multiline
> > constraint when sedd'd will error with 'requirement already supplied'
> > or whatever the pip error string is.
>
> Okay.  It's unlikley that we'll hit that case but not impossible.

Currently happening to dnspython3 right now :)

> > > I think the way forward is to get openstack_requirements on pypi so
we can just
> > > pip install openstack_requirements.
> > >
> > > That'd make the script simple and still retain the
cross-platform'ness needed.
> >
> > Yes. And/or do the long mooted refactoring to separate out the scripts
> > from the current constraints and requirements.
>
> Yup, that'll be part of it but a lower priority that the actual
publication.

+1

-rob
__
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] proposing Michele Baldessari part of core team

[Ben Nemec]

+1

On 11/04/2016 12:40 PM, Emilien Macchi wrote:

MIchele Baldessari (bandini on IRC) has consistently demonstrated high
levels of contributions in TripleO projects, specifically in High
Availability area where's he's for us a guru (I still don't understand
how pacemaker works, but hopefully he does).

He has done incredible work on composable services and also on
improving our HA configuration by following reference architectures.
Always here during meetings, and on #tripleo to give support to our
team, he's a great team player and we are lucky to have him onboard.
I believe he would be a great core reviewer on HA-related work and we
expect his review stats to continue improving as his scope broadens
over time.

As usual, feedback is welcome and please vote for this proposal!

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] [keystone][tripleo][ansible][puppet][all] changing default token format

[Lance Bragstad]

I've added my blog to the OpenStack blog feed and I've published a post
about switching/upgrading to Fernet [0].

I'm not sure when it will propagate to the OpenStack blog, but I published
it yesterday. Hopefully this helps!


[0]
http://lbragstad.com/what-you-need-to-know-about-keystones-new-default-token-format/

On Mon, Nov 7, 2016 at 9:46 AM, Matt Fischer  wrote:

> How to add yourself to Planet OpenStack: https://wiki.openstack.org/wiki/
> AddingYourBlog
>
> As for SuperUser you could reach out to them if you think it's interesting
> for users/operators. Generally they'll want to publish it there first then
> you follow-up with your blog post a few days later.
>
> On Mon, Nov 7, 2016 at 8:17 AM, Lance Bragstad 
> wrote:
>
>> That's a good idea. Is there a page detailing the process for
>> contributing to the OpenStack Blog? I did some checking but haven't found
>> any resources yet. I also asked in #openstack and #openstack-doc.
>>
>> On Thu, Nov 3, 2016 at 11:04 AM, Rochelle Grober <
>> rochelle.gro...@huawei.com> wrote:
>>
>>> a blog post on the OpenStack sore might be good. superuser? there are
>>> folks reading this who can help
>>>
>>> Sent from HUAWEI AnyOffice
>>> *From:*Lance Bragstad
>>> *To:*OpenStack Development Mailing List (not for usage questions),
>>> openstack-operat...@lists.openstack.org,
>>> *Date:*2016-11-03 08:11:20
>>> *Subject:*Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all]
>>> changing default token format
>>>
>>> I totally agree with communicating this the best we can. I'm adding the
>>> operator list to this thread to increase visibility.
>>>
>>> If there are any other methods folks think of for getting the word out,
>>> outside of what we've already done (release notes, email threads, etc.),
>>> please let me know. I'd be happy to drive those communications.
>>>
>>> On Thu, Nov 3, 2016 at 9:45 AM, Alex Schultz 
>>> wrote:
>>>
 Hey Steve,

 On Thu, Nov 3, 2016 at 8:29 AM, Steve Martinelli <
 s.martine...@gmail.com> wrote:
 > Thanks Alex and Emilien for the quick answer. This was brought up at
 the
 > summit by Adam, but I don't think we have to prevent keystone from
 changing
 > the default. TripleO and Puppet can still specify UUID as their
 desired
 > token format; it is not deprecated or slated for removal. Agreed?
 >

 My email was not to tell you to stop.I was just letting you know that
 your change does not affect the puppet modules because we define our
 default as UUID.  It was just as a heads up to others on this email
 that this change should not affect anyone consuming the puppet modules
 because our default is still UUID and will be even after keystone's
 default changes.

 Thanks,
 -Alex

 > On Thu, Nov 3, 2016 at 10:23 AM, Alex Schultz 
 wrote:
 >>
 >> Hey Steve,
 >>
 >> On Thu, Nov 3, 2016 at 8:11 AM, Steve Martinelli <
 s.martine...@gmail.com>
 >> wrote:
 >> > As a heads up to some of keystone's consuming projects, we will be
 >> > changing
 >> > the default token format from UUID to Fernet. Many patches have
 merged
 >> > to
 >> > make this possible [1]. The last 2 that you probably want to look
 at are
 >> > [2]
 >> > and [3]. The first flips a switch in devstack to make fernet the
 >> > selected
 >> > token format, the second makes it default in Keystone itself.
 >> >
 >> > [1] https://review.openstack.org/#/q/topic:make-fernet-default
 >> > [2] DevStack patch: https://review.openstack.org/#/c/367052/
 >> > [3] Keystone patch: https://review.openstack.org/#/c/345688/
 >> >
 >>
 >> Thanks for the heads up. In puppet openstack we had already
 >> anticipated this and attempted to do the same for the
 >> puppet-keystone[0] module as well.  Unfortunately after merging it,
 we
 >> found that tripleo wasn't yet prepared to handle the HA
 implementation
 >> of fernet tokens so we had to revert it[1].  This shouldn't impact
 >> anyone currently consuming puppet-keystone as we define uuid as the
 >> default for now. Our goal is to do something similar this cycle but
 >> there needs to be some further work in the downstream consumers to
 >> either define their expected default (of uuid) or support fernet key
 >> generation correctly.
 >>
 >> Thanks,
 >> -Alex
 >>
 >> [0] https://review.openstack.org/#/c/389322/
 >> [1] https://review.openstack.org/#/c/392332/
 >>
 >> >
 >> > 
 __
 >> > 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] Isolated Network Testing

[Ben Nemec]

On 10/12/2016 05:58 PM, Dan Sneddon wrote:

I recently evaluated our needs for testing coverage for TripleO
isolated networking. I wanted to post my thoughts on the matter for
discussion, which will hopefully lead to a shared understanding of what
improvements we need to make. I think we can cover the majority of
end-user requirements by testing the following minimum scenarios:

1. single-nic-vlans (one nic, all VLANs trunked, great for virt and POCs)

2. Provisioning + bond (to test basic bonding functionality)

3. Bonded provisioning (perhaps one bond with all VLANs)

4. Spine and leaf (in the near future)

Within those four scenarios, we should ensure that we are testing both
IPv4 and IPv6, and both traditional Neutron SNAT/Floating IPs and DVR.

The first scenario is well covered. I think scenario 2 is covered by a
review posted by Ben Nemec recently [1].

I would very much like to see us testing scenario 3 with a resilient
bond for the provisioning interface as well. This used to require LACP
and fallback to a single link, but I believe recent changes to the PXE
boot images may allow this over links without special switch
configuration. I'm currently doing testing in my lab, I hope I can work
with the TripleO CI team to help make this happen upstream.


Providing two provisioning interfaces to the overcloud nodes is pretty 
trivial now, so that shouldn't be a problem.




Spine and leaf (routed networks) support may require specific
configuration of the routing hardware in order to support PXE booting
across router boundaries. Specifically, a DHCP proxy needs to be
configured in order to forward DHCP requests from a remote VLAN to the
Undercloud. If this is not possible in our bare-metal CI environments,
then we may need to develop a method of testing this in OVB.

I'm very interested in finding out about whether it may be possible to
have DHCP proxy (or "DHCP helper-address") configured on the router
hardware for CI VLANs. If we can deploy this in bare metal, I think it
will save us a lot of time and effort over recreating a routed
environment in OVB. I believe we could use use Open Daylight or another
OpenFlow controller to simulate routers in virtual environments, or
perhaps use dnsmasq in DHCP proxy mode on the OVB host to forward
requests from the various bridges representing remote VLANs to the
Undercloud br-ctlplane bridge. But it would be a fair amount of work to
put that together.


Note that we can't do VLANs in OVB right now.  Our version of Neutron 
doesn't support VLAN-aware instances.  I know I've seen discussion of 
adding that to Neutron so it may be something we can do some day, but I 
have no idea when it will be possible.




I don't believe we currently test IPv6 or DVR (please correct me if I'm
mistaken). Do we have plans in the works to add these to any jobs?


The ipv6 jobs are unfortunately experimental right now, but we're 
discussing how to get it back into the regular jobs because it's clearly 
something we need (we fixed ipv6 and then broke it again in less than a 
month because we didn't have a voting job).


It seems like we could add DVR to pretty much any of the existing jobs. 
I guess it might require different net-iso templates for the compute 
nodes?  They're already wired up to the external network though so I 
think the environment should support it.




Finally, I wonder if we need to test any exotic configurations, such as
OVS+DPDK, OpenDaylight, etc.

OVS+DPDK would require compatible hardware. I'm interested in hearing
feedback about how critical this would be in the grand scheme of
things. It isn't yet clear to me that OVS+DPDK is going to have
widespread adoption, but I do recognize that there are some NFV users
that depend on this technology.


Things that require hardware are pretty much a no-go for upstream CI, 
other than maybe a periodic job.  The hardware requirements to run even 
a basic nonha job on baremetal for every patch would be absurd.  Plus, 
giving access to baremetal is problematic from a security perspective 
too.  I think this would have to be a third-party CI job that could be 
triggered by some trusted group of people on specific patches.




OpenDaylight does not require hardware changes AFAIK, but the drivers
and network interface config differs significantly from ML2+OVS. I'm
helping some ODL developers make changes that will allow deployment via
TripleO, but these changes won't be tested by CI.

Of course, there are elements of OVS+DPDK and ODL that get tested as
part of Neutron CI, but now we are implementing TripleO-based
deployment of these technologies, I wonder if we should endeavor to
test them in CI. I suppose that begs the question, if we are testing
those, then why not Contrail, etc.? I don't know where we draw the
line, but it seems that we might want to at least periodically test
deploying some other Neutron drivers via TripleO.


For stuff that is virt-friendly, I think we could probably add some ovb 
scenario jobs 

Re: [openstack-dev] [nova] Follow up on BCN review cadence discussions

[Chris Dent]

On Thu, 10 Nov 2016, Matt Riedemann wrote:

What's really baffling to me is when I'm in the hallway with you and Matt 
Booth and others talking about this stuff face to face in person, and 
explaining my side of the issue, and I'm listening to yours, we seem to all 
be nodding our heads and agreeing, or at least understanding a bit better. 
But then when we get back to the world it's all us vs them and 'a lot of 
people are saying nova sucks and they are ready to give up'.


I'm going to focus on this paragraph because it feels like the most
important part. You seem to think we disagree and that there is
some kind of us or them thing going on. For the most part we agree,
notably on the bit about saying "no". I think we need to do that
even more and I deeply sympathize with the soul crushing nature of
that constantly defensive position. It sucks for everyone involved
yet the truth is that it is probably sucks more for the person who
has to say no frequently (you, Dan, Sean) than it does for the
person who gets to hear "no" every now and again. I'm extremely
sorry all of you have to deal with that, I wish it wasn't the
case and it was easier to communicate the situation or spread the
load. The fact that the two camps that I mentioned have not
resolved to a solid and constantly republished decision makes your
life harder. It doesn't have to be like that.

You've somehow managed to cast me into the position of someone is
"not getting enough attention". I've said time and again that that
is not my concern. I can't be a top ten committer or reviewer (I've
been in and out of both of those groups for the past few months) in
nova and be suffering from a lack of attention.

My concern is with the long term health and pleasantness of Nova and
because of the way I think and the way I understand things my
tendency is to try to find the fundamental reasons things are the
way they are and the ways things are stuck and to try to have
converastions with people to either verify or dismiss that analysis
and to come up with ways to make some kind of forward progress.

This has turned out not to work so well because what it ends being
perceived as either me being a whiny little brat or turning over
rocks that shouldn't be turned because it upsets the status quo.
That's distressing when what I'm trying to do is be helpful. Over the
months I've had some excellent advice from Dan and Sean on how to be
a little more circumspect. I've not always been successful, but
I've tried and I'm thankful for their input.

The thing I learned in BCN, the thing that is the new ingredient in
my analysis (you know, in that continued search for fundamental
reasons things sometimes suck) is that I had the rumors (which I've
known for some time) of the deep rifts in trust that exist inter- and
intra- nova confirmed. How do I know this? Because people kept coming and
telling me: nova contributors, nova cores, people who gave up on
nova, members of the TC, random people I've never heard of. Yes that
'speaker of the people' thing really is tiring!

So when I saw that the conversation about mdbooth's proposal was
"stuck" I thought I would do that thing I try to do: point out what
appears to be some of the underlying reasons. I didn't say "omg all the
nova cores are big jerks and I hate them" because that would be a lie.
I suspect I could have been more explicit about "I'm saying these things
because I'd really like nova to be more fun and successful for everyone
involved".

I guess I assumed that would be inferred on faith. As in it would be
understood because of trust. Why isn't it?

I think we are a "we" and we want the same thing in the end. We may
disagree on how to get there but I view the process of resolving that
disagreement and reaching compromise as the critical path to reaching a
good outcome.

There, now I feel equally terrible and relieved. I really don't want to be 
anyone's barrier, and I feel great when I'm able to help someone out, new 
contributor or not. I don't really know what else to say. I know all of this 
probably doesn't mean anything and there will be a massive reply thread 
discounting each point and exquisite detail about how I'm wrong - that's 
fine, it's what I get for taking the bait to respond in detail to something 
like this. But I felt the need to do so.


I'm glad you did. I wish more people would. I really hate the way
that people think communicating is such a drag and a bad thing. I
know more now than I did before I read your message. Surely that's
a good thing? I'm not sure why you should feel terrible. Did you
tell the truth as you see it? Great. Good on you. I'm grateful. And
I'm glad you feel relieved.

Thank you.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

[openstack-dev] [neutron] Deprecation warnings

[Dariusz Śmigiel]

Hey Neutrinos & Co.
Lately, there were couple patches merged which removed deprecated
functions from neutron code [1][2][3][4][5]. It seems that at least
[1] caused [6].

If you see any problems, errors, disruptions, it could be caused by
one of these.
Please verify if all places with deprecation warnings have mitigations applied.

Hopefully, there won't be any other problems, but either way, possible
breakages will be announced during Team Meeting [7]

Thank you for your cooperation.
Darek


[1] https://review.openstack.org/#/c/379645/
[2] https://review.openstack.org/#/c/379767/
[3] https://review.openstack.org/#/c/379809/
[4] https://review.openstack.org/#/c/379651/
[5] https://review.openstack.org/#/c/379641/
[6] https://bugs.launchpad.net/vmware-nsx/+bug/1640319
[7] 
https://wiki.openstack.org/wiki/Network/Meetings#Neutron-lib_and_planned_neutron_refactoring

__
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] Global changes to CI jobs using neutron

[Chris Dent]

On Thu, 10 Nov 2016, Matt Riedemann wrote:


Heads up, we are a GO for neutron by default in Ocata jobs:


This. Is. Awesome.

Nice work by everyone involved.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Weekly Policy Meeting

[Steve Martinelli]

Thanks for taking the initiative Lance! It'll be great to hear some ideas
that are capable of making policy more fine grained, and keeping things
backwards compatible.

On Thu, Nov 10, 2016 at 3:30 PM, Lance Bragstad  wrote:

> Hi folks,
>
> After hearing the recaps from the summit, it sounds like policy was a hot
> topic (per usual). This is also reinforced by the fact every release we
> have specifications proposed to re-do policy in some way.
>
> It's no doubt policy in OpenStack needs work. Let's dedicate an hour a
> week to policy, analyze what we have currently, design an ideal solution,
> and aim for that. We can bring our progress to the PTG in Atlanta.
>
> We'll hold the meeting openly using Google Hangouts and record our notes
> using etherpad.
>
> Our first meeting will be Wednesday, November 16th from 10:00 AM – 11:00
> AM Central (16:00 - 17:00 UTC) and it will reoccur weekly.
>
> Hangout: https://hangouts.google.com/call/pd36j4qv5zfbldmhxeeatq6f7ae
> Etherpad: https://etherpad.openstack.org/p/keystone-policy-meeting
>
> Let me know if you have any other questions, comments or concerns. I look
> forward to the first meeting!
>
> Lance
>
> __
> 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] [keystone] Weekly Policy Meeting

[Lance Bragstad]

Hi folks,

After hearing the recaps from the summit, it sounds like policy was a hot
topic (per usual). This is also reinforced by the fact every release we
have specifications proposed to re-do policy in some way.

It's no doubt policy in OpenStack needs work. Let's dedicate an hour a week
to policy, analyze what we have currently, design an ideal solution, and
aim for that. We can bring our progress to the PTG in Atlanta.

We'll hold the meeting openly using Google Hangouts and record our notes
using etherpad.

Our first meeting will be Wednesday, November 16th from 10:00 AM – 11:00 AM
Central (16:00 - 17:00 UTC) and it will reoccur weekly.

Hangout: https://hangouts.google.com/call/pd36j4qv5zfbldmhxeeatq6f7ae
Etherpad: https://etherpad.openstack.org/p/keystone-policy-meeting

Let me know if you have any other questions, comments or concerns. I look
forward to the first meeting!

Lance
__
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] Follow up on BCN review cadence discussions

[Matt Riedemann]

On 11/10/2016 6:15 AM, Chris Dent wrote:

On Tue, 8 Nov 2016, Chris Friesen wrote:


That said, I don't know that there's an easy solution to this in nova
due to the fact that it's a distributed system with a central shared
data store. Enhancing a sched filter might require new data, which
means modifying the DB model and the DB migrations, and updating the
InstanceNUMATopology object and tweaking nova-api to request
additional attrs, and it might have implications for upgrade, etc.


The symptoms that you are describing here are pretty much the crux
of the biscuit.


I really hesitate to even respond to this but I feel the need to, but at 
the same time feel as though I'm going to regret it, and it won't help 
change anyone's mind, and I'll probably get in trouble from the 
Foundation or TC or some other group that monitors what PTLs/cores/etc 
say in public. But here goes!




As much as I think having additional cores or subsystem maintainers
with +2 but not +W would probably be useful, I don't think it will
do much to fix the fundamental problem -- the crux above -- so the
concerns that people have about the risks will continue, will continue
to be valid and can't just be dismissed.

That's a technology crux. There's also a social crux.

It was very clear in BCN that there is significant disagreement in
the community over the volume of code that nova ought to be accepting.
Even in an ideal world where a lot of the roadblocks that people are
experiencing aren't there, there would be disagreement between at least
two (idealized, not literal) camps: One that says any code which doesn't
break stuff and is vaguely in the domain of what nova is about should be
merged and another that says nova should have a clear and focused
vision and contributions that don't fit that vision should be rejected.


Believe it or not, those of us that say no to things aren't super happy 
saying no to people all of the time. It gets pretty soul-crushing after 
awhile. However, for those of us that have worked on Nova for several 
years and have seen where saying, 'sure, what the hell, this magical 
little vendor snowflake can't possibly harm us, right? btw, don't worry 
about maintaining this or CI testing it...we'll trust you to do that out 
of tree and report/fix those problems 4 years from now' - that creates 
an innate hesitation to more and more magical unicorn vendor-specific 
changes. Because it's those kinds of things that get in the way of us 
being able to make broader necessary changes later, like with the 
placement service/scheduler stuff, and capabilities in the API. With so 
much random custom use case code, it's really hard to know what changes 
will break something else you thought was unrelated.


Also, we have consistently had operators give feedback at summits that 
basically say, 'nova is the most boring project in my deployment, and 
that's a good thing' - that's about the best compliment we can get: 
stability matters.


And for that matter, the OpenStack community has said that 
interoperability matters, and as most have seen we've been working on 
removing plugin and extension points over the last several releases to 
get to that end. Having said that, it's an entirely whole other topic 
unto itself and I have mixed feelings about it personally, i.e. if I'm 
building a private devops cloud and don't care about 
defcore/refstack/interoperability needed for marketing a product, then 
what's wrong with me having configuration and extension point freedom 
coming out of my ears? That's a valid point, I understand that. I also 
understand that we don't test any of that stuff upstream and we break 
it, and then get people shouting at us for breaking things that broke 
their snowflake configuration.




At the moment both of these cruxes seem to be treated as things that
are too hard to change, or at least too hard discuss.


Chris, I keep hearing this, especially from you. I don't know what needs 
to happen to move past this. We talked about this at length at the BCN 
summit. We talked about new contributors and ways to help there at the 
ATX summit. So it's not like no one is willing to discuss these things - 
we obviously have already. But saying things like 'no one is willing to 
even discuss this' is really frustrating to continue hearing, and what's 
even more frustrating is I get the feeling that if I even mention that, 
it's going to somehow justify the point. "See, he said he's tired of 
talking about this, which means he doesn't want to talk about it."




On the tech crux some people claim that the decomposition (and the
related boundary hardening) that would lead to safe contracts between
subsystems have already gone as far as they can or taking them
further requires such a huge amount of effort that given resources
and other commitments it can't happen. That smacks of a lack of
imagination and hope.


I also don't agree with this. I think the sentiment at the summit, if 
we're talking about the 

Re: [openstack-dev] [release] change in plan for releases repo data model updates

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2016-11-08 12:28:28 -0500:
> At the summit we said we would move the data that tells us the type
> and release model for each deliverable out of the governance
> repository and into the releases repository where it is easier to
> change over time, but that we needed to think more about what might
> break by making that change. After giving it more consideration, I
> think we have to use the option 2 we discussed instead (allow local
> values to override the global values).
> 
> The list-repos command would not be able to filter on the type or
> model values early in a cycle because not enough deliverable files
> would even exist until the first milestone. That limitation would
> make the command essentially useless until close to the end of each
> cycle. Using option 2 means list-repos would continue to work all the
> time.
> 
> Using option 2 also means that instead of us having to do extra
> work to build and publish a single unified file for the project
> navigator team, they can continue to use the same input data without
> changes to their project at all.
> 
> I propose adding "type" and "model" fields, as we discussed, but
> making them optional. If they are not present, the values can be
> derived from the governance tags for the deliverable. Teams who
> want to change either value can then make the update in the releases
> repository with a separate patch to update the governance repo, and
> not have releases blocked by the governance change.
> 
> Thoughts?
> Doug
> 

Based on the mixed feedback, I went ahead and prepared a series of
patches to import the tags into the releases repo [1] and another patch
to remove the data from the governance repo [2].

Doug

[1] https://review.openstack.org/#/q/topic:move-release-tags-out-of-gov
[2] https://review.openstack.org/396360

__
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] Global changes to CI jobs using neutron

[Matt Riedemann]

On 11/2/2016 2:48 PM, Matt Riedemann wrote:

nova-network was deprecated in newton. Nova is working on moving the CI
jobs that run against it to use Neutron only in Ocata. I'm tracking that
work here:

https://etherpad.openstack.org/p/removing-nova-network

In an effort to make this more of a global switch in Ocata, clarkb has
proposed a change to devstack-gate to change the default value of
DEVSTACK_GATE_NEUTRON from 0 (nova-net) to 1 (neutron):

https://review.openstack.org/#/c/392934/

There are conditions on that which are:

1. If a job definition in project-confg sets DEVSTACK_GATE_NEUTRON
explicitly, that's honored.

2. If not explicitly defined and the job is running against a stable
branch, then nova-network is still the default.

There are a few jobs which are definitely nova-network specific, like
some of the nova-net specific grenade jobs and the cells v1 job. Those
are being explicitly handled in a series here:

https://review.openstack.org/#/c/392942/

So why should you care, you ask? First, thanks for asking. Second, as
noted in the commit message to ^ there are several grenade jobs which
don't explicitly define DEVSTACK_GATE_NEUTRON, like for designate and
trove. With that change those grenade jobs will now start using neutron
when upgrading from newton to ocata. This might work, it might not. If
it does not work, and you know it won't work, please speak up now.
Otherwise if things break we'll have to either (a) explicitly set
DEVSTACK_GATE_NEUTRON=0 in those jobs or (b) cap them at stable/newton -
either way those affected projects would have to sort out a path forward
for continued upgrade testing in Ocata.



Heads up, we are a GO for neutron by default in Ocata jobs:

https://review.openstack.org/#/c/392934/

There were several changes made before this seen here:

https://review.openstack.org/#/q/topic:neutron-default

If your jobs start failing on master after that d-g change lands, find 
me in #openstack-infra.


--

Thanks,

Matt Riedemann


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

[openstack-dev] [all][ptg] how are cross-project sessions scheduled?

[John Dickinson]

I've been fielding questions about the upcoming PTG, but one has come
up that I don't know how to answer.

How will cross-project sessions at the PTG be scheduled?

>From looking at the "Event Layout" section on
https://www.openstack.org/ptg, it seems to imply that each team in the
left column will likely set their own schedule. So if there's some
cross-project topic someone wants to bring up, then that person should
figure out which team it best fits under and petition that team to
include the topic. Is that correct?


--John







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

[openstack-dev] [glance] [stable] New stable releases (Was: [release] Release countdown for week R-14, 14-18 Nov, Ocata-1 milestone)

[Ian Cordasco]

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

Date: November 10, 2016 at 13:13:02
To: openstack-dev 
Subject:  [openstack-dev] [release] Release countdown for week R-14,
14-18 Nov, Ocata-1 milestone

> Release Actions
> ---
>
> Release liaisons for projects following the cycle-with-milestones
> release model should prepare a patch to add the tag for the first
> milestone by Thursday. Milestones are considered betas, and should
> have version numbers like X.0.0.0b1 where X is the next major version
> number for your deliverables.
>
> This is a good time to coordinate with the stable maintenance team
> on releases from stable branches.

Hi all,

As the Glance Release Liaison, I'm wondering if you all agree that we
should also be proposing patches for new patch releases from our
stable branches next week. I know we have a few priorities to wrap up,
but I'm more hoping to get a sense of when we want to tag a new stable
release of Glance.

Cheers,
--
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] [release] Release countdown for week R-14, 14-18 Nov, Ocata-1 milestone

[Doug Hellmann]

Focus
-

Teams should be focusing on wrapping up incomplete work left over
from the end of the Newton cycle, finalizing and announcing plans
from the summit, and completing specs and blueprints.

The first milestone deadline is Thursday 17 Nov.

General Notes
-

Keep in mind that the release team prefers to handle releases of
libraries and other things with dependencies early in the week, and
may postpone processing a release request on a Friday until the
next week.

The release team is in the process of moving the tags defining
deliverable type and release model from the governance repository
into the releases repository. This will make it easier to change
the values over time, since only one patch in the releases repository
will be necessary. If you see unexpected validation errors in your
deliverable files, please refer to the README.rst for instructions about
filling in the new values.

Keep in mind that stable releases for projects claiming to follow
the stable policy will be reviewed by the stable team in addition
to the release team.

Release Actions
---

Release liaisons for projects following the cycle-with-milestones
release model should prepare a patch to add the tag for the first
milestone by Thursday. Milestones are considered betas, and should
have version numbers like X.0.0.0b1 where X is the next major version
number for your deliverables.

This is a good time to coordinate with the stable maintenance team
on releases from stable branches.

PTLs should add their acknowledgement of the Ocata series community
goal to 
http://governance.openstack.org/goals/ocata/remove-incubated-oslo-code.html
with a patch to the openstack/governance repository before the first
milestone.

Important Dates
---

Ocata 1 Milestone: 17 Nov

Ocata release schedule: http://releases.openstack.org/ocata/schedule.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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Doug Hellmann]

Excerpts from Pete Zaitcev's message of 2016-11-10 11:00:27 -0700:
> On Wed, 9 Nov 2016 11:14:32 + (GMT)
> Chris Dent  wrote:
> 
> > The conversations about additional languages in this community have
> > been one our most alarmingly regressive and patronizing. They seem
> > to be bred out of fear rather than hope and out of lack of faith in
> > each other than in trust. We've got people who want to build stuff.
> > Isn't that the important part?
> 
> I dunno, it seems fine to discuss. I'm disappointed that TC voted Golang
> down on August 2, but I can see where they come from.
> 
> The problem we're grappling with on the Swift side is (in my view) mainly
> that the Go reimplementation provides essential performance advantages
> which manifest at a certain scale (around 100 PB with current technology).
> For this reason, ignoring Hummingbird and prohibiting Go is not going to
> suppress them. As the operators deploy Hummingbird in preference to the
> Python implementation, the focus of the development is going to migrate,
> and the end result is going to be an effective exile of a founding
> project from the OpenStack.

That doesn't have to be the case. I don't want to speak for anyone
else on the TC, but my reason for saying "not yet" was a lack of
faith that some of the issues Flavio is putting together will be
addressed in the process of trying to add Go to the community.  My
request has been to demonstrate not just that Swift needs Go, but
that Swift is willing to help the rest of the community in the
adoption. I'm starting to see signs of that happening, for example
with some discussions about how oslo.config can be used in the
current version of swift.

> (Even if happens, it's probably not a big deal. Just look how well Ceph
> is doing, community-wise. Operators aren't crying bloody tears either,
> do they?)
> 
> The conflict is that since re-writing e.g. Newtron in Go does not confer
> the same performance advantage (AFAIK -- your VLANs aren't going to set
> up and tear down 80 times faster), the disruption isn't worth the trouble
> for the majority of OpenStack projects. This is why TC voted us down.

That is not why I voted against the most recent request.

> And the talk about the community is mostly there to heal psychologically.

I'm not sure what you mean by that sentence. Can you rephrase it?

> So, it wasn't "regressive" or "patronizing", just business. See how Flavio
> outlined specific steps in a constructive manner.
> 
> I'm quite glad that Ash wants to do something about CI. And I'm going
> to look into fully supporting existing configurations. Maybe share it with
> Designate and thus create something like a proto-"oslo.go.config".
> Of course we need to have some code to share first.

That's good news, thank you.

> 
> -- Pete
> 

__
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] Embracing new languages in OpenStack

[Davanum Srinivas]

Pete,

Please see below:

On Thu, Nov 10, 2016 at 1:00 PM, Pete Zaitcev  wrote:
> On Wed, 9 Nov 2016 11:14:32 + (GMT)
> Chris Dent  wrote:
>
>> The conversations about additional languages in this community have
>> been one our most alarmingly regressive and patronizing. They seem
>> to be bred out of fear rather than hope and out of lack of faith in
>> each other than in trust. We've got people who want to build stuff.
>> Isn't that the important part?
>
> I dunno, it seems fine to discuss. I'm disappointed that TC voted Golang
> down on August 2, but I can see where they come from.
>
> The problem we're grappling with on the Swift side is (in my view) mainly
> that the Go reimplementation provides essential performance advantages
> which manifest at a certain scale (around 100 PB with current technology).
> For this reason, ignoring Hummingbird and prohibiting Go is not going to
> suppress them. As the operators deploy Hummingbird in preference to the
> Python implementation, the focus of the development is going to migrate,
> and the end result is going to be an effective exile of a founding
> project from the OpenStack.
>
> (Even if happens, it's probably not a big deal. Just look how well Ceph
> is doing, community-wise. Operators aren't crying bloody tears either,
> do they?)
>
> The conflict is that since re-writing e.g. Newtron in Go does not confer
> the same performance advantage (AFAIK -- your VLANs aren't going to set
> up and tear down 80 times faster), the disruption isn't worth the trouble
> for the majority of OpenStack projects. This is why TC voted us down.
> And the talk about the community is mostly there to heal psychologically.

Please read the long comment from Doug Hellmann: (time stamp Aug 2 5:01 PM)
https://review.openstack.org/#/c/339175/

> So, it wasn't "regressive" or "patronizing", just business. See how Flavio
> outlined specific steps in a constructive manner.
>
> I'm quite glad that Ash wants to do something about CI. And I'm going
> to look into fully supporting existing configurations. Maybe share it with
> Designate and thus create something like a proto-"oslo.go.config".
> Of course we need to have some code to share first.
>
> -- Pete
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] Embracing new languages in OpenStack

[Joshua Harlow]

Ed Leafe wrote:

On Nov 9, 2016, at 5:14 AM, Chris Dent  wrote:


Something that feels like it gets under-emphasised in this conversation
is that change is coming whatever we do. As a community we can either
move quickly and stay ahead of the change and see it as a productive
development that we can surf or we can dilly dally and get drowned by a
wave that collapses over us.

Ecosystems must evolve and change because the world evolves and changes.
If we try to control this stuff too much what we will be doing is taking
the oxygen out of the system and snuffing the flame of excitement and
innovation.


That is, of course, a series of obvious statements. We need to change or die.

What I think is missing from this conversation is that there are a lot of 
people who are used to the way things happen in the startup world, where you 
get an idea, work like crazy to get an MVP out the door, and then iterate from 
there. The problem is that OpenStack is the exact opposite of a startup; it’s a 
giant legacy application.



That's only because some (? I'm not sure who they are ?) believe this is 
the way that it *must* be. There are also folks that don't believe this 
is the way it needs to be (including myself), though I get what u are 
saying.



Don’t like the word “legacy”? Well, what would you call something that has to 
support users who haven’t upgraded in several years? What would you call 
something that can never have a greatly-improved but backwards-incompatible 
change? Sure, that might be possible in some of the add-ons for the OpenStack 
ecosystem, but for any of the core projects (yes, I said that word), that is 
simply not an option.

> So yes, of course we’re going to drive off those who want to work 
with the coolest and latest stuff. This isn’t “exciting” work in that 
sense of the word.


I understand what u are saying with the above, but I don't necessarily 
feel it is something we as a community can not resolve (fate is what we 
make).


Why aren't we asking the question of why can't we figure out a way to do 
breaking changes, why can't we move quicker... Instead of assuming there 
is no way that can happen, what happens if we ask ourselves 'what are 
the ways we can make such a thing happen, what are the reasons people 
are stuck on releases of several years behind...' and work through 
fixing those.


Perhaps that involves some very tough questions and perhaps some 
potentially 'radical' answers, but so what... I'd rather have those 
kinds of questions than just assume we are all stuck doing not exciting 
work on some legacy application(s) that never change because existing 
users are stuck.


I mean if we get stuck in the support X users of things for all of time, 
we sort of miss out on the Y users that we can gain by fixing it (even 
if such changes are radical) and making it better; perhaps at the end u 
get X + Y users total (which is even better) or perhaps u don't and u 
move on and learn from the attempt.


-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] [all] Embracing new languages in OpenStack

[Pete Zaitcev]

On Wed, 9 Nov 2016 11:14:32 + (GMT)
Chris Dent  wrote:

> The conversations about additional languages in this community have
> been one our most alarmingly regressive and patronizing. They seem
> to be bred out of fear rather than hope and out of lack of faith in
> each other than in trust. We've got people who want to build stuff.
> Isn't that the important part?

I dunno, it seems fine to discuss. I'm disappointed that TC voted Golang
down on August 2, but I can see where they come from.

The problem we're grappling with on the Swift side is (in my view) mainly
that the Go reimplementation provides essential performance advantages
which manifest at a certain scale (around 100 PB with current technology).
For this reason, ignoring Hummingbird and prohibiting Go is not going to
suppress them. As the operators deploy Hummingbird in preference to the
Python implementation, the focus of the development is going to migrate,
and the end result is going to be an effective exile of a founding
project from the OpenStack.

(Even if happens, it's probably not a big deal. Just look how well Ceph
is doing, community-wise. Operators aren't crying bloody tears either,
do they?)

The conflict is that since re-writing e.g. Newtron in Go does not confer
the same performance advantage (AFAIK -- your VLANs aren't going to set
up and tear down 80 times faster), the disruption isn't worth the trouble
for the majority of OpenStack projects. This is why TC voted us down.
And the talk about the community is mostly there to heal psychologically.

So, it wasn't "regressive" or "patronizing", just business. See how Flavio
outlined specific steps in a constructive manner.

I'm quite glad that Ash wants to do something about CI. And I'm going
to look into fully supporting existing configurations. Maybe share it with
Designate and thus create something like a proto-"oslo.go.config".
Of course we need to have some code to share first.

-- Pete

__
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] Embracing new languages in OpenStack

[Clint Byrum]

Excerpts from Chris Dent's message of 2016-11-10 15:54:39 +:
> On Thu, 10 Nov 2016, Clint Byrum wrote:
> > Excerpts from Chris Dent's message of 2016-11-09 11:14:32 +:
> >> Let's just get on with making stuff and work out the problems (and of
> >> course there will be many, there always are) as they happen. That's
> >> what we do.
> >
> > Apologies for the stretched analogy. What you're suggesting is that we go
> > build without building codes and without a city plan, because there's a
> > market force that we must capture. But when we let the tenants move in
> > (the operators) and the other tenants sewers back up and their roads
> > are backed up with traffic, we'll just deal with that later. I don't
> > think that's fair to anyone.
> 
> Sorry, I think you are extrapolating _far_ too much from what I've
> said. I've not said we should have no plan, no process, anarchy,
> cats and dogs living together[1]. I've said we should work out the
> problems as we go.
> 
> The current process to create a plan (nevermind actually following
> it) is weighted (to me) too far in the direction of trying to be
> prepared for as much as possible. That's a recipe for getting it
> wrong; because we are humans who can't see the future.
> 

Agreed, probably went a bit far there.

> > I don't think we have to have a PERFECT plan, but we need to _acknowledge_
> > that this is the price of diversity and expansion. I personally think
> > it's worth it, but let's own the chaos and at least start with a rough
> > hypothesis of how each new language might effect the overall system, and
> > a plan to measure and react quickly.
> 
> Yes, let's talk about it and acknowledge it. There will be a price
> of diversity and expansaion, yes. I'm very happy to hear that you
> agree it is worth it. I'm also happy to hear you acknowledge that
> it will be chaotic.
> 
> However -- to push the current thread further into the extreme than it
> actually is, to make a point -- we don't need to reimplement oslo in
> every candidate language before we actually build and distribute
> something useful with real users in whatever that language might be.
> We've got to have some faith in ourselves as developers, users and
> operators that we have the capacity to adapt and learn for sake of new
> stuff that is good.
> 

It actually sounds like we agree on most if not all fundamental points.

__
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] Embracing new languages in OpenStack

[Ed Leafe]

On Nov 9, 2016, at 5:14 AM, Chris Dent  wrote:

> Something that feels like it gets under-emphasised in this conversation
> is that change is coming whatever we do. As a community we can either
> move quickly and stay ahead of the change and see it as a productive
> development that we can surf or we can dilly dally and get drowned by a
> wave that collapses over us.
> 
> Ecosystems must evolve and change because the world evolves and changes.
> If we try to control this stuff too much what we will be doing is taking
> the oxygen out of the system and snuffing the flame of excitement and
> innovation.

That is, of course, a series of obvious statements. We need to change or die.

What I think is missing from this conversation is that there are a lot of 
people who are used to the way things happen in the startup world, where you 
get an idea, work like crazy to get an MVP out the door, and then iterate from 
there. The problem is that OpenStack is the exact opposite of a startup; it’s a 
giant legacy application.

Don’t like the word “legacy”? Well, what would you call something that has to 
support users who haven’t upgraded in several years? What would you call 
something that can never have a greatly-improved but backwards-incompatible 
change? Sure, that might be possible in some of the add-ons for the OpenStack 
ecosystem, but for any of the core projects (yes, I said that word), that is 
simply not an option.

So yes, of course we’re going to drive off those who want to work with the 
coolest and latest stuff. This isn’t “exciting” work in that sense of the word. 

-- Ed Leafe






__
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] Embracing new languages in OpenStack

[Flavio Percoco]

On 10/11/16 15:54 +, Chris Dent wrote:

On Thu, 10 Nov 2016, Clint Byrum wrote:

Excerpts from Chris Dent's message of 2016-11-09 11:14:32 +:

Let's just get on with making stuff and work out the problems (and of
course there will be many, there always are) as they happen. That's
what we do.


Apologies for the stretched analogy. What you're suggesting is that we go
build without building codes and without a city plan, because there's a
market force that we must capture. But when we let the tenants move in
(the operators) and the other tenants sewers back up and their roads
are backed up with traffic, we'll just deal with that later. I don't
think that's fair to anyone.


Sorry, I think you are extrapolating _far_ too much from what I've
said. I've not said we should have no plan, no process, anarchy,
cats and dogs living together[1]. I've said we should work out the
problems as we go.

The current process to create a plan (nevermind actually following
it) is weighted (to me) too far in the direction of trying to be
prepared for as much as possible. That's a recipe for getting it
wrong; because we are humans who can't see the future.


I don't think we have to have a PERFECT plan, but we need to _acknowledge_
that this is the price of diversity and expansion. I personally think
it's worth it, but let's own the chaos and at least start with a rough
hypothesis of how each new language might effect the overall system, and
a plan to measure and react quickly.


Yes, let's talk about it and acknowledge it. There will be a price
of diversity and expansaion, yes. I'm very happy to hear that you
agree it is worth it. I'm also happy to hear you acknowledge that
it will be chaotic.

However -- to push the current thread further into the extreme than it
actually is, to make a point -- we don't need to reimplement oslo in
every candidate language before we actually build and distribute
something useful with real users in whatever that language might be.
We've got to have some faith in ourselves as developers, users and
operators that we have the capacity to adapt and learn for sake of new
stuff that is good.


If you mean Oslo as the team that manages the shared code across projects then
yes, I think we have to and we need a way for sharing code. If instead you mean
oslo libraries then no, I don't think we need to re-implement them all in the
new language. What we need, however, is to guarantee compatibility for operators
and other devs. Having inconsistencies in the way config files are managed, the
RPC protocol is implemented, messages are logged is a recipe for a chaotic
adoption of the new language. This is what I'd like us to avoid.

There's some work that needs to be done up-front. I agree the discussion of
adding new languages have nnot been perfect but that's also what we do. We
evaluate our options, we study, we work out a way to embrace change and
innovate. That's what I'm trying to do here, work out a way for us to embrace
new languages and move on to the next change.

As Clint put ir, we need to own the change and the chaos that will come with it.
Not having these processes would just make it unmanageable for everyone.

Flavio


--
@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] Embracing new languages in OpenStack

[Pete Zaitcev]

On Mon, 07 Nov 2016 15:53:51 -0800
Joshua Harlow  wrote:

> Standards though exist for a reason (and ini files are pretty common 
> across languages and such); though of course oslo.config has some very 
> tight integration with openstack, the underlying ini concept it 
> eventually reads/writes really isn't that special (so hopefully such a 
> thing existing isn't that hard).

Swift in Go demonstrated that it's not the ini format that's the problem
for reimplementation, the paste-deploy is. In particular, the names from
pipeline= define section names, and egg names define what code is executed.
So one can have "pipeline=keystone app", but [keystone] section is actually
use=egg:swift#tempauth, not Keystone. It's pefectly legal and will work
today, even if such a configuration is a hostile move against future
coworkers.

-- Pete

__
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] [MassivelyDistributed] bi-weekly meeting - Timeslot - 15 UTC Wednesday (odd week)

[lebre . adrien]

Thanks Thierry 

@all: 
Massively distributed IRC meetings every Wednesday (odd week) at 15:00 UTC
The first official meeting will be on Wednesday November, the 23rd. 
The agenda is available at  
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2016

++
ad_rien_

- Mail original -
> De: "Thierry Carrez" 
> À: openstack-dev@lists.openstack.org, openstack-operat...@lists.openstack.org
> Envoyé: Mercredi 9 Novembre 2016 17:31:13
> Objet: Re: [openstack-dev] [MassivelyDistributed] bi-weekly meeting - 
> Timeslot ?
> 
> Thierry Carrez wrote:
> > lebre.adr...@free.fr wrote:
> >> After Thierry's cleaning, the possibilities are the following
> >> ones:
> >>
> >> Wednesday 14 UTC (odd week)
> >> Wednesday 17 UTC
> >> Thursday 14 UTC (odd week)
> >> Thursday 16 UTC (even week)
> >> Thursday 17 UTC (even week)
> > 
> > Thursday 15 UTC is also an option.
> > 
> > Also note that Thursday 14 UTC is currently taken. Trying to free
> > up the
> > slot with https://review.openstack.org/#/c/395509 but they may want
> > to
> > keep it.
> 
> A slot just opened for Wednesday 15 UTC, so I revived your original
> proposal[1]. If you're still interested in that one let me know and
> I'll
> approve the change.
> 
> https://review.openstack.org/#/c/393899
> 
> --
> Thierry Carrez (ttx)
>

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

Re: [openstack-dev] [tripleo] Is it time to reconsider how we configure OVS bridges in the overcloud?

[Dan Sneddon]

On 11/10/2016 07:22 AM, Brent Eagles wrote:
> Hi all,
> 
> 
> A recent critical issue that has come up that has compelled me to
> propose reconsidering our default and OVS based network configuration
> examples :   
> 
> https://bugs.launchpad.net/tripleo/+bug/1640812 - Network connectivity
> lost on node reboot
> 
> I've been thinking about it for awhile, but you could say this bug was
> the "last straw". 
> 
> While the precise root cause of this issue is still in question, part
> of the problem is that the overcloud nodes communicate with the
> undercloud and each other through an OVS bridge which is also used by
> the overcloud neutron service for external network traffic. For several
> valid reasons, neutron sets the OVS bridge fail_mode to secure (details
> in respective man pages, etc, etc). This mode is stored persistently so
> when the system is rebooted, the bridge is recreated with the secure
> fail_mode in place, blocking network traffic - including DHCP - until
> something comes along and starts setting up flow rules to allow traffic
> to flow.  Without an IP address, the node is effectively "unplugged".
> For some reason this isn't happening 100% of the time on the current
> version of CentOS (7.2), but seems to be pretty much 100% on RHEL 7.3. 
> 
> It raises the question if it is valid for neutron to modify an OVS
> bridge that it *did not create* in a fundamental way like this. If so,
> it implies a contract between the deployer and neutron that the
> deployer can make "no assumptions" about what will happen with the
> bridge once neutron has been configured to access it. If this implied
> contract is valid, required and acceptable, then bridges used for
> neutron should not be used for anything else. The implications with
> respect to tripleo is that we should reconsider how we use OVS bridges
> for network configuration in the overcloud. For example, in single NIC
> situations, instead of having:
> 
> (triple configured)
> - eth0
>   - br-ex -used for control plane access, internal api, management,
> external, etc. also neutron is configured to use this for the external
> traffic e.g. dataplane in our defaults, which is why the fail_mode gets
> altered
> 
> (neutron configured)
> 
> - br-int
> - br-tun
> 
> To something like:
> (triple configured)
> - eth0
>  - br-ctl - used as br-ex is currently used except neutron knows
> nothing about it.
> - br-ex -patched to br-ctl - ostensibly for external traffic and this
> is what neutron in the overcloud is configured to use
> (neutron configured)
> - br-int
> - br-tun
> 
> (In all cases, neutron configures patches, etc. between bridges *it
> knows about* as needed. That is, in the second case, tripleo would
> configure the patch between br-ctl and br-ex)
> 
> At the cost of an extra bridge (ovs bridge to ovs bridge with patch
> ports is allegedly cheap btw) we get:
>  1. an independently configured bridge for overcloud traffic insulates
> non-tenant node traffic against changes to neutron, including upgrades,
> neutron bugs, etc.
>  2. insulates neutron from changes to the underlying network that it
> doesn't "care" about.
>  3. In OVS only environments, the difference between a single nic
> environment and one where there is a dedicated nic for external traffic
> is, instead of a patch port from br-ctl to br-ex, it is directly
> connected to the nic for the external traffic. 
> 
> Even without the issue that instigated this message, I think that this
> is a change worth considering. 
> 
> 
> Cheers,
> 
> 
> Brent
> 
> 
> 
> __
> 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
> 

Brent,

Thanks for taking the time to analyze this situation. I see a couple of
potential issues with the topology you are suggesting.

First of all, what about the scenario where a system has only 2x10Gb
NICs, and the operator wishes to bond these together on a single
bridge? If we require separate bridges for Neutron than we do for the
control plane, then it would be impossible to configure a system with
only 2 NICs in a fault-tolerant way.

Second, there will be a large percentage of users who already have a
shared br-ex that wish to upgrade. Do we tell them that due to an
architectural change, they now must redeploy a new cloud with a new
topology to use the latest version?

So while I would be on-board with changing our default for new
installations, I don't think that relieves us of the responsibility to
figure out how to handle the edge cases where a separate bridge is not
feasible.

-- 
Dan Sneddon |  Senior Principal OpenStack Engineer
dsned...@redhat.com |  redhat.com/openstack
dsneddon:irc|  @dxs:twitter

__
OpenStack Development Mailing List 

Re: [openstack-dev] [tripleo] possible backports for stable/newton

[Brent Eagles]

Hi Alan,

On Wed, Nov 9, 2016 at 6:10 AM, Alan Pevec  wrote:

> > Since our cherry picks don't seem to be considered equivalents by git
> > (probably because of modified commit messages)
>
> I'd like to understand why is that, do you have an example?
> It should work when recommendation[*] is followed.
>
> Cheers,
> Alan
>

​I was referring to running git log with the --cherry-pick option. e.g. git
log --cherry-pick --no-merge origin/stable/newton..origin/master​

The docs for git imply that if the cherry-picks were equivalent patches
they would be removed from the log. Could be I'm misunderstanding what the
intent of that git feature is. I haven't tested if it does what *I* think
it does with a identical cherry-pick (i.e. no change to the commit message).

Cheers,

Brent
__
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] How tied is kolla to matching 1:1 releases of openstack?

[Joshua Harlow]

Paul Bourke wrote:

Hi Joshua,

Thanks for sharing your workflow, interesting to see.

To answer your question, there is a 1:1 relationship between Kolla and
OpenStack releases. As Kevin outlined, you may get lucky, currently in
Oracle we deploy OpenStack Mitaka with Kolla Newton and for the most
part it works fine. But it's not recommended from an upstream point of
view.


Thanks Paul, good to hear that I'm not the only one asking this :-P

Can u describe more of the 'most part it works fine'?

Anything that you've hit that I don't have to would be nice to know ;)



Maybe we need more discussion on that as it's something I see popping up
frequently. We also have a warning in the docs around this, see
http://docs.openstack.org/developer/kolla/quickstart.html#building-container-images



Yes +1

A matrix of kolla release to what openstack release would be nice,

Especially taking into account the fact that the image building process 
will likely work across many releases but the deployment part may not 
(which is fine with me, all I want right now is the docker image 
building, the deployment we already have existing tooling that we are 
working through and adjusting anyway).


PS: this likely won't be a permanent question but is more situational as 
godaddy moves from liberty to a newer release (once we get our processes 
streamlined we shouldn't be so far behind...).




-Paul



__
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] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

[Kosnik, Lubosz]

Octavia is using own DB and LBaaS v2 has his own. Because of that like Michael 
said we’re working on aligning this DBs and we’re planning to provide migration 
mechanism.

Cheers,
Lubosz Kosnik
Cloud Software Engineer OSIC

On Nov 10, 2016, at 1:13 AM, Gary Kotton 
> wrote:

Will the same DB be maintained or will the LBaaS DB be moved to that of 
Octavia. I am really concerned about this and I feel that it will cause 
production problems.

From: Kevin Benton >
Reply-To: OpenStack List 
>
Date: Wednesday, November 9, 2016 at 11:43 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS 
retrospective and next steps recap

The people working on the migration are ensuring API compatibility and are even 
leaving in a shim on the Neutron side for some time so you don't even have to 
change endpoints initially. It should be a seamless change.

On Wed, Nov 9, 2016 at 12:28 PM, Fox, Kevin M 
> wrote:
Just please don't make this a lbv3 thing that completely breaks compatibility 
of existing lb's yet again. If its just an "point url endpoint from thing like 
x to thing like y" in one place, thats ok. I still have v1 lb's in existence 
though I have to deal with and a backwards incompatible v3 would just cause me 
to abandon lbaas all together I think as it would show the lbaas stuff is just 
not maintainable.

Thanks,
Kevin

From: Armando M. [arma...@gmail.com]
Sent: Wednesday, November 09, 2016 8:05 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS 
retrospective and next steps recap


On 9 November 2016 at 05:50, Gary Kotton 
> wrote:
Hi,
What about neutron-lbaas project? Is this project still alive and kicking to 
the merge is done or are we going to continue to maintain it? I feel like we 
are between a rock and a hard place here. LBaaS is in production and it is not 
clear the migration process. Will Octavia have the same DB models as LBaaS or 
will there be a migration?
Sorry for the pessimism but I feel that things are very unclear and that we 
cannot even indicate to our community/consumers what to use/expect.
Thanks
Gary

http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html


On 11/8/16, 1:36 AM, "Michael Johnson" 
> wrote:

Ocata LBaaS retrospective and next steps recap
--

This session lightly touched on the work in the newton cycle, but
primarily focused on planning for the Ocata release and the LBaaS spin
out of neutron and merge into the octavia project [1].  Notes were
captured on the etherpad [1].

The focus of work for Ocata in neutron-lbaas and octavia will be on
the spin out/merge and not new features.

Work has started on merging neutron-lbaas into the octavia project
with API sorting/pagination, quota support, keystone integration,
neutron-lbaas driver shim, and documentation updates.  Work is still
needed for policy support, the API shim to handle capability gaps
(example: stats are by listener in octavia, but by load balancer in
neturon-lbaas), neutron api proxy, a database migration script from
the neutron database to the octavia database for existing non-octavia
load balancers, and adding the "bug for bug" neutron-lbaas v2 API to
the octavia API server.

The room agreed that since we will have a shim/proxy in neutron for
some time, updating the OpenStack client can be deferred to a future
cycle.

There is a lot of concern about Ocata being a short cycle and the
amount of work to be done.  There is hope that additional resources
will help out with this task to allow us to complete the spin
out/merge for Ocata.

We discussed the current state of the active/active topology patches
and agreed that it is unlikely this will merge in Ocata.  There are a
lot of open comments and work to do on the patches.  It appears that
these patches may have been created against an old release and require
significant updating.

Finally there was a question about when octavia would implement
metadata tags.  When we dug into the need for the tags we found that
what was really wanted is a full implementation of the flavors
framework [3] [4].  Some vendors expressed interest in finishing the
flavors framework for Octavia.

Thank you to everyone that participated in our design session and etherpad.

Michael

[1] 

[openstack-dev] [RefStack] No RefStack Special Meeting Today ( 19 UTC, Nov 10, 2016 )

[Catherine Cuong Diep]

Hi everyone,

Due to team members' schedule conflict, the special meeting previously
scheduled at 19 UTC today (Nov 10, 2016) has been canceled.  I will
follow-up with the new time later.  Sorry for the late notice!

Catherine
__
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] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

[Michael Johnson]

Hi Gary,

The LBaaS DB table contents will be moved into the Octavia database as
part of the migration process/tool.

Michael

On Wed, Nov 9, 2016 at 11:13 PM, Gary Kotton  wrote:
> Will the same DB be maintained or will the LBaaS DB be moved to that of
> Octavia. I am really concerned about this and I feel that it will cause
> production problems.
>
>
>
> From: Kevin Benton 
> Reply-To: OpenStack List 
> Date: Wednesday, November 9, 2016 at 11:43 PM
> To: OpenStack List 
>
>
> Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS
> retrospective and next steps recap
>
>
>
> The people working on the migration are ensuring API compatibility and are
> even leaving in a shim on the Neutron side for some time so you don't even
> have to change endpoints initially. It should be a seamless change.
>
>
>
> On Wed, Nov 9, 2016 at 12:28 PM, Fox, Kevin M  wrote:
>
> Just please don't make this a lbv3 thing that completely breaks
> compatibility of existing lb's yet again. If its just an "point url endpoint
> from thing like x to thing like y" in one place, thats ok. I still have v1
> lb's in existence though I have to deal with and a backwards incompatible v3
> would just cause me to abandon lbaas all together I think as it would show
> the lbaas stuff is just not maintainable.
>
> Thanks,
> Kevin
>
> 
>
> From: Armando M. [arma...@gmail.com]
> Sent: Wednesday, November 09, 2016 8:05 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS
> retrospective and next steps recap
>
>
>
>
>
> On 9 November 2016 at 05:50, Gary Kotton  wrote:
>
> Hi,
> What about neutron-lbaas project? Is this project still alive and kicking to
> the merge is done or are we going to continue to maintain it? I feel like we
> are between a rock and a hard place here. LBaaS is in production and it is
> not clear the migration process. Will Octavia have the same DB models as
> LBaaS or will there be a migration?
> Sorry for the pessimism but I feel that things are very unclear and that we
> cannot even indicate to our community/consumers what to use/expect.
> Thanks
> Gary
>
>
>
> http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html
>
>
>
>
> On 11/8/16, 1:36 AM, "Michael Johnson"  wrote:
>
> Ocata LBaaS retrospective and next steps recap
> --
>
> This session lightly touched on the work in the newton cycle, but
> primarily focused on planning for the Ocata release and the LBaaS spin
> out of neutron and merge into the octavia project [1].  Notes were
> captured on the etherpad [1].
>
> The focus of work for Ocata in neutron-lbaas and octavia will be on
> the spin out/merge and not new features.
>
> Work has started on merging neutron-lbaas into the octavia project
> with API sorting/pagination, quota support, keystone integration,
> neutron-lbaas driver shim, and documentation updates.  Work is still
> needed for policy support, the API shim to handle capability gaps
> (example: stats are by listener in octavia, but by load balancer in
> neturon-lbaas), neutron api proxy, a database migration script from
> the neutron database to the octavia database for existing non-octavia
> load balancers, and adding the "bug for bug" neutron-lbaas v2 API to
> the octavia API server.
>
> The room agreed that since we will have a shim/proxy in neutron for
> some time, updating the OpenStack client can be deferred to a future
> cycle.
>
> There is a lot of concern about Ocata being a short cycle and the
> amount of work to be done.  There is hope that additional resources
> will help out with this task to allow us to complete the spin
> out/merge for Ocata.
>
> We discussed the current state of the active/active topology patches
> and agreed that it is unlikely this will merge in Ocata.  There are a
> lot of open comments and work to do on the patches.  It appears that
> these patches may have been created against an old release and require
> significant updating.
>
> Finally there was a question about when octavia would implement
> metadata tags.  When we dug into the need for the tags we found that
> what was really wanted is a full implementation of the flavors
> framework [3] [4].  Some vendors expressed interest in finishing the
> flavors framework for Octavia.
>
> Thank you to everyone that participated in our design session and
> etherpad.
>
> Michael
>
> [1]
> https://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html
> [2] 

[openstack-dev] [all][api] POST /api-wg/news

[Chris Dent]

Greetings OpenStack community,

Just me (cdent) and edleafe today. We burned through the agenda, quickly 
merging the frozen guidelines that were ready to merge. See below. If you think 
they are not complete please considering submitting a patch or bug [4] to get 
them cleaned up.

The guidelines listed in the "currently under review" section below are 
important. If you are itching to participate this would be a great time.

# New guidelines

The following guidelines merged this week:

* Clarify why CRUD is not a great descriptor
  https://review.openstack.org/#/c/392156/

* Add guidelines for complex queries
  https://review.openstack.org/#/c/386614/

* Specify time intervals based filtering queries
  https://review.openstack.org/#/c/383862/

# API guidelines that have been recently merged

No recent guidelines.

# API guidelines proposed for freeze

No guidelines are frozen at the moment.

# Guidelines currently under review [6]

Both of these are going to require quite a bit of input from a wide audience. 
Both have been tried a few times in the past.

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/

* WIP Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working group 
about changes which would benefit from wider inspection by group members and 
liaisons. While the working group will attempt to address these reviews 
whenever possible, it is highly recommended that interested parties attend the 
API WG meetings [2] to promote communication surrounding their reviews.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [3].

Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[6]: https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z


--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] When should a project be under Ironic's governance?

[Arkady.Kanevsky]

Second try

-Original Message-
From: Kanevsky, Arkady 
Sent: Thursday, November 10, 2016 10:08 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: RE: [openstack-dev] [ironic] When should a project be under Ironic's 
governance?

Fully agree.
How do we propose to handle dependency of Ironic  version on specific version 
of a driver? 
Clearly distros can do it but we will not have a version for user of upstream 
to use without building it themselves.
I am only referring to ironic drivers that do pass CI voting that user expect 
availability of.
Thanks,
Arkady

-Original Message-
From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com]
Sent: Wednesday, November 02, 2016 9:37 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [ironic] When should a project be under Ironic's 
governance?

On Mon, Oct 17, 2016 at 4:27 PM, Michael Turek  
wrote:
> Hello ironic!
>
> At today's IRC meeting, the questions "what should and should not be a 
> project be under Ironic's governance" and "what does it mean to be 
> under Ironic's governance" were raised. Log here:
>
> http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-10-17-
> 17.00.log.html#l-176
>
> See http://governance.openstack.org/reference/projects/ironic.html for 
> a list of projects currently under Ironic's governance.
>
> Is it as simple as "any project that aides in openstack baremetal 
> deployment should be under Ironic's governance"? This is probably too 
> general (nova arguably fits here) but it might be a good starting point.
>
> Another angle to look at might be that a project belongs under the 
> Ironic governance when both Ironic (the main services) and the 
> candidate subproject would benefit from being under the same 
> governance. A hypothetical example of this is when Ironic and the candidate 
> project need to release together.
>
> Just some initial thoughts to get the ball rolling. What does everyone 
> else think?

We discussed this during our contributor's meetup at the summit, and came to 
consensus in the room, that in order for a repository to be under ironic's 
governance:

* it must roughly fall within the TC's rules for a new project:
  http://governance.openstack.org/reference/new-projects-requirements.html
* it must not be intended for use with only a single vendor's hardware (e.g. a 
library
  to handle iLO is not okay, a library to handle IPMI is okay).
* it must align with ironic's mission statement: "To produce an OpenStack 
service
  and associated libraries capable of managing and provisioning physical 
machines,
  and to do this in a security-aware and fault-tolerant manner."
* lack of contributor diversity is a chicken-egg problem, and as such a 
repository
  where only a single company is contributing is okay.

I've proposed this as a docs patch: https://review.openstack.org/392685

We decided we should get consensus from all cores on that patch - meaning 80% 
or more agree, and any that disagree will still agree to live by the decision. 
So, cores, please chime in on gerrit. :)

Once that patch lands, I'll submit a patch to openstack/governance to shuffle 
projects around where they do or don't fit.

// jim

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

__
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] [acceleration]Team Biweekly Meeting 2016.11.10 minutes

[Zhipeng Huang]

Hi Team,

Thanks for attending today's meeting and again sorry for not be able to
host it on yesterday.

Since we don't have a meetbot now associated with a fix channel, I recorded
the irc chat in a doc file and you could find it in the attachment.

Key Takeaways:
1. Nomad project will be renamed to Cyborg (what a cool name) based upon
our final tally on the etherpad

2. Moshe introduced Nacsa project proposal, and an initial design doc has
been shared among the team. We will make the doc public after a few rounds
of review and discussion
3. Reminder for the team to take a look at the Scientific Working Group
etherpad  for
use cases

Our next meeting will be on Nov 23th, 10:00am on irc

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado


cyborg team biweekly meeting 2016.11.10.docx
Description: MS-Word 2007 document
__
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] Embracing new languages in OpenStack

[Chris Dent]

On Thu, 10 Nov 2016, Clint Byrum wrote:

Excerpts from Chris Dent's message of 2016-11-09 11:14:32 +:

Let's just get on with making stuff and work out the problems (and of
course there will be many, there always are) as they happen. That's
what we do.


Apologies for the stretched analogy. What you're suggesting is that we go
build without building codes and without a city plan, because there's a
market force that we must capture. But when we let the tenants move in
(the operators) and the other tenants sewers back up and their roads
are backed up with traffic, we'll just deal with that later. I don't
think that's fair to anyone.


Sorry, I think you are extrapolating _far_ too much from what I've
said. I've not said we should have no plan, no process, anarchy,
cats and dogs living together[1]. I've said we should work out the
problems as we go.

The current process to create a plan (nevermind actually following
it) is weighted (to me) too far in the direction of trying to be
prepared for as much as possible. That's a recipe for getting it
wrong; because we are humans who can't see the future.


I don't think we have to have a PERFECT plan, but we need to _acknowledge_
that this is the price of diversity and expansion. I personally think
it's worth it, but let's own the chaos and at least start with a rough
hypothesis of how each new language might effect the overall system, and
a plan to measure and react quickly.


Yes, let's talk about it and acknowledge it. There will be a price
of diversity and expansaion, yes. I'm very happy to hear that you
agree it is worth it. I'm also happy to hear you acknowledge that
it will be chaotic.

However -- to push the current thread further into the extreme than it
actually is, to make a point -- we don't need to reimplement oslo in
every candidate language before we actually build and distribute
something useful with real users in whatever that language might be.
We've got to have some faith in ourselves as developers, users and
operators that we have the capacity to adapt and learn for sake of new
stuff that is good.

[1] This is in fact a world I might want to live in, I like cats and
dogs and dood, anarchy now, please. But I wouldn't presume to impose
that here.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
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] spec proposal freeze

[Ian Cordasco]

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

Date: November 9, 2016 at 16:10:05
To: OpenStack Development Mailing List (not for usage questions)

Subject:  [openstack-dev] [glance] spec proposal freeze

> Just a friendly reminder that the Glance Spec Proposal Freeze is imminent:
> All Glance, python-glanceclient, and glance_store specs must be proposed
> as patches to the glance-specs repository by 23:59 UTC on Thursday 10
> November 2016.
>
> The purpose of the proposal freeze is to allow sufficient time for the
> specs to be reviewed, revised, and merged before the Spec Freeze on Friday
> 25 November at 23:59 UTC.
>
> cheers,
> brian

One last reminder to everyone that the proposal deadline is now not far off.

--
Ian Cordasco

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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Clint Byrum]

Excerpts from Chris Dent's message of 2016-11-09 11:14:32 +:
> On Tue, 8 Nov 2016, Ash wrote:
> 
> > I couldn't agree more. I don't like change for the sake of change (in any
> > aspect of my life). So in my mind this would have to be a way to better
> > bind us.
> 
> Here, have some tortured metaphors:
> 
> Something that feels like it gets under-emphasised in this conversation
> is that change is coming whatever we do. As a community we can either
> move quickly and stay ahead of the change and see it as a productive
> development that we can surf or we can dilly dally and get drowned by a
> wave that collapses over us.
> 
> Ecosystems must evolve and change because the world evolves and changes.
> If we try to control this stuff too much what we will be doing is taking
> the oxygen out of the system and snuffing the flame of excitement and
> innovation.
> 
> As a community we don't want to be bound together by rules, we want
> to be enabled by processes that support making and doing things
> effectively. The things that we make and do is what binds us
> together.
> 

What you argue for above, is anarchy. The rules are not what binds us,
our will is. However, the rules are what helps us preserve and grow the
commons that we all share.

It seems like there is enough will to expand the scope of the rules,
but we all must acknowledge that doing so will also require expanding
the commons, and be prepared for the strain that will put on the existing
infrastructure.

And I don't just mean "infra". I mean the infrastructure of python
development knowledge, deployer understanding, and overall communication
overhead.

> The conversations about additional languages in this community have
> been one our most alarmingly regressive and patronizing. They seem
> to be bred out of fear rather than hope and out of lack of faith in
> each other than in trust. We've got people who want to build stuff.
> Isn't that the important part?
> 
> Let's just get on with making stuff and work out the problems (and of
> course there will be many, there always are) as they happen. That's
> what we do.
> 

Apologies for the stretched analogy. What you're suggesting is that we go
build without building codes and without a city plan, because there's a
market force that we must capture. But when we let the tenants move in
(the operators) and the other tenants sewers back up and their roads
are backed up with traffic, we'll just deal with that later. I don't
think that's fair to anyone.

I don't think we have to have a PERFECT plan, but we need to _acknowledge_
that this is the price of diversity and expansion. I personally think
it's worth it, but let's own the chaos and at least start with a rough
hypothesis of how each new language might effect the overall system, and
a plan to measure and react quickly.

__
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] Embracing new languages in OpenStack

[Doug Wiegley]

> On Nov 10, 2016, at 7:24 AM, Russell Bryant  wrote:
> 
> 
> 
> On Wed, Nov 9, 2016 at 3:14 AM, Chris Dent  > wrote:
> On Tue, 8 Nov 2016, Ash wrote:
> 
> I couldn't agree more. I don't like change for the sake of change (in any
> aspect of my life). So in my mind this would have to be a way to better
> bind us.
> 
> Here, have some tortured metaphors:
> 
> Something that feels like it gets under-emphasised in this conversation
> is that change is coming whatever we do. As a community we can either
> move quickly and stay ahead of the change and see it as a productive
> development that we can surf or we can dilly dally and get drowned by a
> wave that collapses over us.
> 
> Ecosystems must evolve and change because the world evolves and changes.
> If we try to control this stuff too much what we will be doing is taking
> the oxygen out of the system and snuffing the flame of excitement and
> innovation.
> 
> As a community we don't want to be bound together by rules, we want
> to be enabled by processes that support making and doing things
> effectively. The things that we make and do is what binds us
> together.
> 
> The conversations about additional languages in this community have
> been one our most alarmingly regressive and patronizing. They seem
> to be bred out of fear rather than hope and out of lack of faith in
> each other than in trust. We've got people who want to build stuff.
> Isn't that the important part?
> 
> Let's just get on with making stuff and work out the problems (and of
> course there will be many, there always are) as they happen. That's
> what we do.
> 
> ​Agreed, Chris.  I think this topic has reflected quite poorly on OpenStack, 
> so far.

Also agreed. Like it or not, this topic is a proxy debate for whether it’s 
worth the risk to invest in OpenStack for new things. And doubling down on more 
process is not sending a great message.

Thanks,
doug

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

__
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] Is it time to reconsider how we configure OVS bridges in the overcloud?

[Brent Eagles]

Hi all,


A recent critical issue that has come up that has compelled me to propose
reconsidering our default and OVS based network configuration examples :

https://bugs.launchpad.net/tripleo/+bug/1640812 - Network connectivity lost
on node reboot

I've been thinking about it for awhile, but you could say this bug was the
"last straw".

While the precise root cause of this issue is still in question, part of
the problem is that the overcloud nodes communicate with the undercloud and
each other through an OVS bridge which is also used by the overcloud
neutron service for external network traffic. For several valid reasons,
neutron sets the OVS bridge fail_mode to secure (details in respective man
pages, etc, etc). This mode is stored persistently so when the system is
rebooted, the bridge is recreated with the secure fail_mode in place,
blocking network traffic - including DHCP - until something comes along and
starts setting up flow rules to allow traffic to flow.  Without an IP
address, the node is effectively "unplugged". For some reason this isn't
happening 100% of the time on the current version of CentOS (7.2), but
seems to be pretty much 100% on RHEL 7.3.

It raises the question if it is valid for neutron to modify an OVS bridge
that it *did not create* in a fundamental way like this. If so, it implies
a contract between the deployer and neutron that the deployer can make "no
assumptions" about what will happen with the bridge once neutron has been
configured to access it. If this implied contract is valid, required and
acceptable, then bridges used for neutron should not be used for anything
else. The implications with respect to tripleo is that we should reconsider
how we use OVS bridges for network configuration in the overcloud. For
example, in single NIC situations, instead of having:

(triple configured)
- eth0
  - br-ex -used for control plane access, internal api, management,
external, etc. also neutron is configured to use this for the external
traffic e.g. dataplane in our defaults, which is why the fail_mode gets
altered

(neutron configured)

- br-int
- br-tun

To something like:
(triple configured)
- eth0
 - br-ctl - used as br-ex is currently used except neutron knows nothing
about it.
- br-ex -patched to br-ctl - ostensibly for external traffic and this is
what neutron in the overcloud is configured to use
(neutron configured)
- br-int
- br-tun

(In all cases, neutron configures patches, etc. between bridges *it knows
about* as needed. That is, in the second case, tripleo would configure the
patch between br-ctl and br-ex)

At the cost of an extra bridge (ovs bridge to ovs bridge with patch ports
is allegedly cheap btw) we get:
 1. an independently configured bridge for overcloud traffic insulates
non-tenant node traffic against changes to neutron, including upgrades,
neutron bugs, etc.
 2. insulates neutron from changes to the underlying network that it
doesn't "care" about.
 3. In OVS only environments, the difference between a single nic
environment and one where there is a dedicated nic for external traffic is,
instead of a patch port from br-ctl to br-ex, it is directly connected to
the nic for the external traffic.

Even without the issue that instigated this message, I think that this is a
change worth considering.


Cheers,


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

[openstack-dev] [fuel] Weekly meeting Nov 10 is canceled

[Alexey Shtokolov]

Nothing is on the agenda [0] this week, so I'm calling to cancel the meeting.
If you have anything to discuss. Please come chat in #fuel or add it to the
agenda to discuss next week.

[0] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda

---
WBR, Alexey Shtokolov
OpenStack Fuel PTL
__
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] vendordata plugin for freeIPA host enrollment

[Rob Crittenden]

Wanted to let you know I'm working on a nova metadata vendordata plugin
that will help automate instance enrollment into a freeIPA server.

This will do a number of things for a user:
- provide centralized user identity, sudo and host-based access control
for the instances
- provide the instance an identity it can use for itself
- using this identity a host can obtain SSL certificates for itself from
your freeIPA CA

If ipa_enroll is set to True in the instance metadata (or in the image
metadata) when a nova instance is spawned then a one-time password will
be created and IPA enrollment will occur during the cloud-init stage.

Code is currently at https://github.com/rcritten/novajoin

rob

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

Re: [openstack-dev] [fuel][tripleo] Fuel and TripleO Cross-Project Integration

[Aleksandr Didenko]

Hi,

> 3. Consider integration of Fuel provisioning, network configuration and
disk partitioning with Ironic and TripleO

As a part of this, I'd like to propose "l23network" puppet module [0]
separation from fuel-library. This would allow anyone to reuse it for
software-defined network configuration of OpenStack nodes. This module
already supports pretty complex configurations, such as bonds (including
LACP and other bond properties), OVS, SR-IOV, OVS-DPDK, etc.

Regards,
Alex

[0]
https://github.com/openstack/fuel-library/tree/master/deployment/puppet/l23network

On Wed, Nov 9, 2016 at 3:37 PM, Vladimir Kuklin 
wrote:

> Stackers
>
> During OpenStack summit in Barcelona we had a rather productive
> cross-project integration session between Fuel and TripleO projects [0].
> More precisely we discussed the following:
>
> 1. Services composition and deployment workflow control
> 2. Complex networking configuration (bonds, offloading, etc.)
> 3. Post-deployment cluster management, i.e. day-2 operations
> 4. Approaches to reference architecture recomposition, e.g. in-flight
> database vertical scaling
> 5. Upgrades
> 6. Provisioning and disks partitioning
>
> The most interesting part of integration would be to consider integration
> of deployment and post-deployment orchestration approaches and services
> composition. The further steps are to start working on:
>
> 1. Cross-project specification on workflow management, e.g. for upgrades
> and day-2 operations
> 2. Look into possibility of Mistral integration as a workflow execution
> tool within the designed model
> 3. Consider integration of Fuel provisioning, network configuration and
> disk partitioning with Ironic and TripleO
>
> [0] https://etherpad.openstack.org/p/fuel-ocata-fuel-tripleo-integration
>
> I would suggest that we add discussing this into TripleO or Fuel IRC
> meeting agenda next week.
>
> Please let me know what are you thoughts on this.
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for O-1

[Brian Rosmaita]

Hello Glancers,

O-1 is around the corner (i.e., next week).  The priority for Glance is
Community Images.

Please review the following patches:

https://review.openstack.org/#/c/369110/
https://review.openstack.org/#/c/387660/
https://review.openstack.org/#/c/391968/

Also, don't forget about the virtual design session on rolling upgrades
tomorrow (Friday 11 Nov) at 14:00 UTC.  Link to the google hangout will be
posted in #openstack-glance around 13:50 UTC.

cheers,
brian


__
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] Embracing new languages in OpenStack

[Russell Bryant]

On Wed, Nov 9, 2016 at 3:14 AM, Chris Dent  wrote:

> On Tue, 8 Nov 2016, Ash wrote:
>
> I couldn't agree more. I don't like change for the sake of change (in any
>> aspect of my life). So in my mind this would have to be a way to better
>> bind us.
>>
>
> Here, have some tortured metaphors:
>
> Something that feels like it gets under-emphasised in this conversation
> is that change is coming whatever we do. As a community we can either
> move quickly and stay ahead of the change and see it as a productive
> development that we can surf or we can dilly dally and get drowned by a
> wave that collapses over us.
>
> Ecosystems must evolve and change because the world evolves and changes.
> If we try to control this stuff too much what we will be doing is taking
> the oxygen out of the system and snuffing the flame of excitement and
> innovation.
>
> As a community we don't want to be bound together by rules, we want
> to be enabled by processes that support making and doing things
> effectively. The things that we make and do is what binds us
> together.
>
> The conversations about additional languages in this community have
> been one our most alarmingly regressive and patronizing. They seem
> to be bred out of fear rather than hope and out of lack of faith in
> each other than in trust. We've got people who want to build stuff.
> Isn't that the important part?
>
> Let's just get on with making stuff and work out the problems (and of
> course there will be many, there always are) as they happen. That's
> what we do.
>

​Agreed, Chris.  I think this topic has reflected quite poorly on
OpenStack, so far.

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

Re: [openstack-dev] [openstack-ansible] How do you haproxy?

[Ian Cordasco]

-Original Message-
From: Jean-Philippe Evrard 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: November 10, 2016 at 06:40:00
To: openstack-dev@lists.openstack.org 
Subject:  [openstack-dev] [openstack-ansible] How do you haproxy?

> Hello,
>
> In openstack-ansible, we are using haproxy (and keepalived) as load balancer 
> mechanism.
> We’ve been recommending to use hardware load balancers for a while, but I 
> think it’s time
> to improve haproxy configuration flexibility and testing.
>
> I’m gathering requirements of what you’d like to see in haproxy.
>
> I have an etherpad set up, and I’d be happy if you could fill your comments 
> there:
> https://etherpad.openstack.org/p/openstack-ansible-haproxy-improvements
>
> Thank you in advance.
>
> Best regards,
> Jean-Philippe Evrard (evrardjp)

There are numerous existing HAProxy Ansible roles on Galaxy
(https://galaxy.ansible.com/list#/roles?page=1_size=10=haproxy).
Ostensibly one or more of these are already flexible enough for what
users might need. Why not adopt one of those and contribute back to it
instead of creating yet another HAProxy role?

--
Ian Cordasco

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

Re: [openstack-dev] [openstack-ansible] Debugging slow Xenial gate

[Major Hayden]

On 11/02/2016 08:51 AM, Major Hayden wrote:
> At this point, I'm still trying to test some additional theories. Does anyone 
> have any other ideas?

Here's an update for today.  There are a few bugs open now:

  OpenStack-Ansible bug: 
https://bugs.launchpad.net/openstack-ansible/+bug/1637494
  Ubuntu python2.7 bug: 
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1638695

The suggestion from the python2.7 bug is to compile python 2.7.12 with gcc-4.8 
on 16.04 to see if the performance issue is related to GCC.  I haven't had a 
chance to test that out yet, but if someone else has a moment to try it, I'd be 
much obliged. ;)

There is also a private bug opened with Canonical that has been escalated as 
part of my company's support contract with Canonical.  I'll provide relevant 
updates from that bug when I get them.

--
Major Hayden



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

Re: [openstack-dev] Mirantis Fuel 9.1 slave node UEFI mode

[Kostyantyn Volenbovskyi]

Hi,

you should use openstack or openstack-operators mailing list or 
ask.openstack.org 

[1] indicates that UEFI support in Fuel is not yet there. But I think your 
HW/BIOS/RAID vendor
should allow configuration of RAID for Legacy mode as well.

BR, 
Konstantin
[1] https://blueprints.launchpad.net/fuel/+spec/uefi-support 



> On Nov 10, 2016, at 1:32 PM, Saravanakkumar Sr  
> wrote:
> 
> Hi Team,
> 
> I am trying PXE boot in UEFI mode for slave node. But it is not working. 
> 
> PXE boot works if i changed to legacy bios mode.. unfortunately RAID is not 
> supported in legacy bios mode.
> 
> Can you please confirm if it is supported or not ?.
> 
> if not what is the alternate method, i can try.
> 
> -- 
> Have a nice day.
> Thanks and Regards
> 
> S.R.Saravanakkumar
> +91-9591564646 
> 
> __
> 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] [openstack-ansible] How do you haproxy?

[Jean-Philippe Evrard]

Hello,

In openstack-ansible, we are using haproxy (and keepalived) as load balancer 
mechanism.
We’ve been recommending to use hardware load balancers for a while, but I think 
it’s time to improve haproxy configuration flexibility and testing.

I’m gathering requirements of what you’d like to see in haproxy.

I have an etherpad set up, and I’d be happy if you could fill your comments 
there:
https://etherpad.openstack.org/p/openstack-ansible-haproxy-improvements

Thank you in advance.

Best regards,
Jean-Philippe Evrard (evrardjp)


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
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] Mirantis Fuel 9.1 slave node UEFI mode

[Saravanakkumar Sr]

Hi Team,

I am trying PXE boot in UEFI mode for slave node. But it is not working.

PXE boot works if i changed to legacy bios mode.. unfortunately RAID is not
supported in legacy bios mode.

Can you please confirm if it is supported or not ?.

if not what is the alternate method, i can try.

-- 
Have a nice day.
Thanks and Regards

S.R.Saravanakkumar
+91-9591564646
__
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] Follow up on BCN review cadence discussions

[Chris Dent]

On Tue, 8 Nov 2016, Chris Friesen wrote:

That said, I don't know that there's an easy solution to this in nova due to 
the fact that it's a distributed system with a central shared data store. 
Enhancing a sched filter might require new data, which means modifying the DB 
model and the DB migrations, and updating the InstanceNUMATopology object and 
tweaking nova-api to request additional attrs, and it might have implications 
for upgrade, etc.


The symptoms that you are describing here are pretty much the crux
of the biscuit.

As much as I think having additional cores or subsystem maintainers
with +2 but not +W would probably be useful, I don't think it will
do much to fix the fundamental problem -- the crux above -- so the
concerns that people have about the risks will continue, will continue
to be valid and can't just be dismissed.

That's a technology crux. There's also a social crux.

It was very clear in BCN that there is significant disagreement in
the community over the volume of code that nova ought to be accepting.
Even in an ideal world where a lot of the roadblocks that people are
experiencing aren't there, there would be disagreement between at least
two (idealized, not literal) camps: One that says any code which doesn't
break stuff and is vaguely in the domain of what nova is about should be
merged and another that says nova should have a clear and focused
vision and contributions that don't fit that vision should be rejected.

At the moment both of these cruxes seem to be treated as things that
are too hard to change, or at least too hard discuss.

On the tech crux some people claim that the decomposition (and the
related boundary hardening) that would lead to safe contracts between
subsystems have already gone as far as they can or taking them
further requires such a huge amount of effort that given resources
and other commitments it can't happen. That smacks of a lack of
imagination and hope.

On the social crux, the impression I got is that people are either
too exhausted, too busy, too angry, or too scared to actually talk
things out and reach a conclusion and instead bitch behind each other's
backs about the lack of agreement and some other core who will either
reject or accept code they shouldn't be. We need to be honest about
this lack of trust if we want to make it better. And we need resolve
the vision of the project, in a concrete fashion.

Until at least one of those cruxes is resolved it's going to be
really hard to make substantial progress and many of the strategies
we try are going to be tactical band-aids.

mdbooth's proposal is somewhat different from some of the other
options because implementing it requires a leap of faith over
both cruxes into what could be a self-reinforcing environment: we will
trust one another because we've said we will, and we will build the
stronger contracts because we need them in order to be able to trust
people, and we will talk about it all (better than we do now) because it
won't work if we don't.

That might work. It could be a mess, but it is better than an
alternative which is feeling increasingly likely: People go elsewhere.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
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] [OSSN-0066] (Errata) MongoDB guest instance allows any user to connect

[Luke Hinds]

MongoDB guest instance allows any user to connect
---

### Summary ###
When creating a new MongoDB single instance or cluster the default
setting in MongoDB `security.authorization` was set as disabled. This
resulted in no need to provide user credentials to connect to the mongo
instance and perform read / write operations from any network that is
attached on instance create.

### Affected Services / Software ###
Trove, Liberty

### Discussion ###
MongoDB contains a security config set within `mongo.conf` as follows:

security:
authorization: "enabled"

When creating a new MongoDB instance, or cluster within Trove the
`security` value was not populated resulting in MongoDB adopting the
default value of `disabled`. With security authorization disabled there
would be no enforcement of user authentification, allowing users to
connect and perform read/write data operations from any network that is
attached on instance create.

A fix was implemented within Mitaka and back ported to Liberty that
addresses the problem by enabling authorization by default on single
instances. This can be toggled via configuration groups.

Cluster security is determined by the Trove config variable
`mongodb.cluster_secure`. This cannot be toggled once the cluster is
created.

### Recommended Actions ###
Single instances now use role based access control (RBAC) by default. To
disable RBAC, the Trove user can attach a security group with
`security.authorization` set to `disabled`. It can be re-enabled by
detaching the security group or changing the value to `enabled`.

The Trove config variable `mongodb.cluster_secure`
(boolean type, in `trove.conf`) determines the RBAC state of MongoDB
clusters that are created. Setting this to true enables RBAC while false
disables it. This applies to all MongoDB clusters, and requires a
restart of the trove-api service to change, and cannot be toggled on
running clusters.

Existing mongoDB instances can be secured by using the following changes
to `mongo.conf`

   security:
   authorization: "enabled

### Errata ###
This OSSN previously incorrectly stated that the fix was back ported to
Liberty release. This is not the case and the fix was applied only to
Mitaka.

### Contacts / References ###
Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0066
Original LaunchPad Bug : https://bugs.launchpad.net/trove/+bug/1507841
Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg



0x3C202614.asc
Description: application/pgp-keys


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

Re: [openstack-dev] [OpenStack-docs] [openstack deployment] Adding deployment guides to docs.o.o

[Gyorgy Szombathelyi]

> -Original Message-
> 
> We're talking here about deployment guides for official OpenStack projects -
> and thus OpenStack-Ansible - that are part of their repositories,
> 
Ah, I just realized that after my email was sent :)
Sorry for the noise.

> Andreas
Br,
György
__
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-docs] [openstack deployment] Adding deployment guides to docs.o.o

[Andreas Jaeger]

On 11/10/2016 05:32 AM, Gyorgy Szombathelyi wrote:


Hi everyone,


Hi Alexandra,





If any of the deployment projects are interested in getting involved, let us
know and we can work together to make this transition :)


We have an ansible-based deployment project for Ubuntu. This is used 
successfully in production at our company, and heard about it is tested at some 
other companies.
It is aimed for the 'old-school' Linux admins, using .deb packages, and not 
forcing to put everything into containers (but does not prevent you to separate 
services).

It can be found at:
https://github.com/DoclerLabs/openstack

Since it is aimed for production use, it also contains a monitoring project 
(maybe it will be split into a separate repo somewhere in the future).

We would be happy, if we can add it to the official docs (of course after 
cleaning out our rather sparse documentation).


We're talking here about deployment guides for official OpenStack 
projects - and thus OpenStack-Ansible - that are part of their repositories,


Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] Barcelona summit "neutron-agent retrospective" recap

[Vega Cai]

It's cool to store tunnel termination endpoint information in the port
model. Will this information support updating so external devices or
controllers can inject the tunnel termination endpoints via the API? This
is very useful to support VxLAN type external network, which there are
already some patches working on it[1,2].

[1] https://review.openstack.org/#/c/282180
[2] https://review.openstack.org/#/c/317309

BR
Zhiyuan

On Thu, 10 Nov 2016 at 04:31 Kevin Benton  wrote:

> There were three main topics discussed during the neutron-agent
> retrospective session: deprecating the CLI OVS interfaces, refactoring the
> agent to use the callback framework, and eliminating the L2pop driver.
>
> Deprecating the CLI OVS Interfaces
> 
> We now have native replacements for shelling out to ovs-vsctl and
> ovs-ofctl using a python ovsdb interface and the RYU openflow code,
> respectively. Currently, it's an operator configuration option to choose
> the native vs legacy interfaces. The native interfaces were the default for
> the last cycle, so we would like to deprecate the legacy interfaces and
> remove them in Pike.
>
> This appeared to have general consensus, contingent on fixing a few parity
> bugs with the CLI interface for handling flows. If using the CLI interfaces
> is critical to a use case, please reply to this email because we will
> proceed with the deprecation otherwise.
>
> Refactoring the agent to use the callback framework
> --
> We need to refactor some of the main OVS agent file to make it more
> maintainable. The file itself contains over 2000 lines of python and the
> methods are insanely long and complex, making unit testing difficult and
> questionable in its efficacy. This makes adding new features scary, which
> slows down development.
>
> While there was nobody against refactoring the agent, we decided to defer
> this work due to the short nature of this cycle and the potential conflicts
> it will have with the next bullet point.
>
> However, any refactoring required for other development activities
> (features or fixes), will not be blocked.
>
> Eliminating L2pop as a mechanism driver
> 
> L2pop calculates information on the fly to determine tunnel termination
> endpoints. This is racey (out of order tunnel notifications are not
> handled) and leads to lots of complexity involving lookups to agent tables,
> etc. This also makes it very difficult to integrate external devices
> because they have no way of informing the agents of their tunnel
> termination endpoint.
>
> We'd like to formalize the tunnel termination point by adding it to the
> port binding data model just like other encapsulation details (bound
> segment, segmentation id, etc). This will allow mech drivers to bind ports
> not based on agents and allow seamless integration with agent-based ports.
> The L2pop server-side logic would go away since agents would setup
> forwarding entries just based on the latest data on the port models
> delivered via push notifications.
>
> This will require some changes on the server side in the port binding
> process to have the mech drivers provide the tunnel termination point as
> part of the binding details. The agent side will also require a few changes
> to have its tunnel forming logic be derived from push notifications instead
> of tunnel and fdb notifications.
>
> This change will likely need a small spec to scope out the new port
> binding process.
>
> Cheers,
> Kevin Benton
> __
> 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
>
-- 
BR
Zhiyuan
__
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-docs] [openstack deployment] Adding deployment guides to docs.o.o

[Gyorgy Szombathelyi]

> 
> Hi everyone,
> 
Hi Alexandra,

> 
> 
> 
> If any of the deployment projects are interested in getting involved, let us
> know and we can work together to make this transition :)
> 
We have an ansible-based deployment project for Ubuntu. This is used 
successfully in production at our company, and heard about it is tested at some 
other companies.
It is aimed for the 'old-school' Linux admins, using .deb packages, and not 
forcing to put everything into containers (but does not prevent you to separate 
services).

It can be found at:
https://github.com/DoclerLabs/openstack

Since it is aimed for production use, it also contains a monitoring project 
(maybe it will be split into a separate repo somewhere in the future).

We would be happy, if we can add it to the official docs (of course after 
cleaning out our rather sparse documentation).
> 
> 
> Thanks,

> 
> 
> 
> Alexandra Settle
> 
> 
> 
> Information Developer II
> 
> Rackspace Private Cloud Powered By OpenStack
> 
> London, United Kingdom
> 
> 
Br,
György
OpenStack 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] [kolla] How tied is kolla to matching 1:1 releases of openstack?

[Paul Bourke]

Hi Joshua,

Thanks for sharing your workflow, interesting to see.

To answer your question, there is a 1:1 relationship between Kolla and 
OpenStack releases. As Kevin outlined, you may get lucky, currently in 
Oracle we deploy OpenStack Mitaka with Kolla Newton and for the most 
part it works fine. But it's not recommended from an upstream point of view.


Maybe we need more discussion on that as it's something I see popping up 
frequently. We also have a warning in the docs around this, see 
http://docs.openstack.org/developer/kolla/quickstart.html#building-container-images


-Paul

On 09/11/16 17:28, Joshua Harlow wrote:

Hi kolla folks,

As I am (and others at godaddy) are working through integrating kolla
image building into our jenkins pipeline(s),

Currently the pipeline is the following (taking an example of glance),

# Checkout stage
1. Checkout kolla at X tag/branch
2. Checkout glance at Y tag/branch
3. Checkout internal-deploy repo (which has patches for various
projects) at Z tag/branch
4. Checkout requirements repo at Y tag/branch (same Y as #2)

# Test stage
5. Create a virtualenv for glance using constraints from #4
6. Run testr and capture the results of tests and make sure those work
(or fail here)
7. Patch glance using patches from #3
8. Retest glance using same routine as #6 and make sure those work (or
fail here)

# Kolla stage
9. Setup kolla-build.conf with sections for glance (setup to take the
glance tested as a local
directory) and sections for openstack-base (which == the
requirements repo from #4) and
create a template-overrides.j2 with various specific kolla overrides
10. Build images (or fail here)
11. Upload images to artifactory (WIP here)

 Stage next 

So the general question I have is that kolla has tags/branches that
match glance and other openstack releases but I'm not really sure how
tightly bound kolla is to those same tags/branches,

For example right now I am taking kolla at stable/newton but glance and
requirements at stable/liberty,

This seems to work (ya!) but I don't quite know if this is really
recommended, is kolla really tied to the same branches of the other
openstack projects,

With the projects moving to more independent releases is there any
suggested policy, will kolla work with what project releases?

Some range of releases that will work, won't work...?

Ie, kolla stable/newton for example will work with A, B, C, ... branches
of [neutron, glance...]?

Should kolla have a known working list, stating the above in some
location inside of the kolla repo (so people know)?

Thoughts? Comments?

-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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][infra][requirements] Odd cases in requirements?

[Tony Breeds]

On Thu, Nov 10, 2016 at 08:48:16PM +1300, Robert Collins wrote:

> We generate multiline constraints whenever versions are different
> between python 2 and 3 for the same package. That was happening when I
> wrote the tool in the first place - it was one of the reasons I wrote
> edit-constraints, to avoid writing silly-awkward sed. (A multiline
> constraint when sedd'd will error with 'requirement already supplied'
> or whatever the pip error string is.

Okay.  It's unlikley that we'll hit that case but not impossible.
 
> > I think the way forward is to get openstack_requirements on pypi so we can 
> > just
> > pip install openstack_requirements.
> >
> > That'd make the script simple and still retain the cross-platform'ness 
> > needed.
> 
> Yes. And/or do the long mooted refactoring to separate out the scripts
> from the current constraints and requirements.

Yup, that'll be part of it but a lower priority that the actual publication.

Thanks Robert

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] Proposing Zhang Guoqing as core for cloudkitty

[Gauvain Pocentek]

+1

Le 2016-11-04 19:13, Christophe Sauthier a écrit :

Hello developer mailing list folks,

I'd like to propose that we add Zhang Guoqing (zhangguoqing) as an
OpenStack cloudkitty
core reviewer.

He has been a member of our community for many months, contributing
very seriously in cloudkitty and cloudkitty-dashboard. He also
provided many reviews on both projects part as you can se in his
activity logs

http://stackalytics.com/report/contribution/cloudkitty/60
http://stackalytics.com/report/contribution/cloudkitty-dashboard/60

During that time he learned from the mistakes he did and improved
both his communication and participation.

Overall I think Zhang Guoqing would make a great addition to the core
review team.

Current Cloudkitty cores, please respond with +1 or explain your
opinion if voting against... If there are no objection in the next 5
days I'll add him.

All the best,

Christophe


Christophe Sauthier   Mail :
christophe.sauth...@objectif-libre.com
CEO   Mob : +33 (0) 6 16 98 63 96
Objectif LibreURL : www.objectif-libre.com
Au service de votre Cloud Twitter : @objectiflibre

Suivez les actualités OpenStack en français en vous abonnant à la
Pause OpenStack
http://olib.re/pause-openstack

__
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


Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.com
phone: +33 972 54 98 01 / +33 611 60 84 25

__
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] Proposing Maxime Cottret as core for cloudkitty

[Gauvain Pocentek]

+1

Le 2016-11-04 19:19, Christophe Sauthier a écrit :

Hello developer mailing list folks,

I'd like to propose that we add Maxime Cottret (aolwas) as an
OpenStack cloudkitty
core reviewer.

He has been a member of our community for a few months. Working
mainly on the stabilisation/bug fixing of our project he really showed
some great communication capacity.

Those are all the reasons why I think Maxime Cottret would make a
great addition to the core review team.

Current Cloudkitty cores, please respond with +1 or explain your
opinion if voting against... If there are no objection in the next 5
days I'll add him.

All the best,

Christophe

http://stackalytics.com/report/contribution/cloudkitty/60
http://stackalytics.com/report/contribution/cloudkitty-dashboard/60


Christophe Sauthier   Mail :
christophe.sauth...@objectif-libre.com
CEO   Mob : +33 (0) 6 16 98 63 96
Objectif LibreURL : www.objectif-libre.com
Au service de votre Cloud Twitter : @objectiflibre

Suivez les actualités OpenStack en français en vous abonnant à la
Pause OpenStack
http://olib.re/pause-openstack

__
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


Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.com
phone: +33 972 54 98 01 / +33 611 60 84 25

__
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