Re: [openstack-dev] [Neutron] Newton blueprints call for action

[Sukhdev Kapur]

Hi Rossella,

Good to hear that you will follow through with this. Ironic is looking for
this API as well for bare metal deployments. We would love to work with you
to make sure that this API/Implementation works for all servers ( VMs as
well BMs)

Thanks
-Sukhdev


On Wed, Apr 6, 2016 at 4:32 AM, Rossella Sblendido 
wrote:

>
>
> On 04/05/2016 05:43 AM, Armando M. wrote:
> >
> > With this email I would like to appeal to the people in CC to report
> > back their interest in continuing working on these items in their
> > respective capacities, and/or the wider community, in case new owners
> > need to be identified.
> >
> > I look forward to hearing back, hoping we can find the right resources
> > to resume progress, and bring these important requirements to completion
> > in time for Newton.
>
> Count me in for the vlan-aware-vms. We have now a solid design, it's
> only a matter of putting it into code. I will help any way I can, I
> really want to see this feature in Newton.
>
> cheers,
>
> Rossella
>
> __
> OpenStack Development Mailing 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] [magnum][requirements][release] The introduction of package py2-ipaddress

[Hongbin Lu]

Hi requirements team,

In short, the recently introduced package py2-ipaddress [1] seems to break 
Magnum. In details, Magnum gate recently broke by an error: "'\xac\x18\x05\x07' 
does not appear to be an IPv4 or IPv6 address" [2] (the gate breakage has been 
temporarily fixed but we are looking for a permanent fix [3]). After 
investigation, I opened a ticket in Cryptography for help [4]. According to the 
feedback from Cryptography community, the problem is from py2-address, which 
was introduced to OpenStack recently [1].

I wonder if we can get any advice from requirements team in this regards. In 
particular, what is the proper way to handle the problematic package?

[1] https://review.openstack.org/#/c/302539/
[2] https://bugs.launchpad.net/magnum/+bug/1568212
[3] https://bugs.launchpad.net/magnum/+bug/1568427
[4] https://github.com/pyca/cryptography/issues/2870

Best regards,
Hongbin
__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Masayuki Igawa]

2016-04-11 10:31 GMT+09:00 Sheel Rana Insaan :
>> So should we add what we don't want
> to see people -1 for?
>
>>[1] http://docs.openstack.org/infra/manual/developers.html#peer-review
>
> This seems right way.. but concern is do everyone follow all docs?

Nice point. Yeah, I suppose that not everyone read all docs. But some
reviewers can
know our custom/culture through the docs. And we can indicate the
pointer if reviewers
don't know it.

Best Regards,
-- Masayuki Igawa

>
> But atleast we should document it somewhere.
>
> Regards,
> Sheel Rana
>
> On Apr 11, 2016 6:52 AM, "Masayuki Igawa"  wrote:
>
> 2016-04-11 9:46 GMT+09:00 Matt Riedemann :
>>
>>
>> On 4/10/2016 6:37 PM, Clint Byrum wrote:
>>>
>>> Excerpts from Matt Riedemann's message of 2016-04-09 06:42:54 -0700:

 There is also disincentive in +1ing a change that you don't understand
 and is wrong and then a core comes along and -1s it (you get dinged for
 the disagreement). And there is disincentive in -1ing a change for the
 wrong reasons (silly nits or asking questions for understanding). I ask
 a lot of questions in a lot of changes and I don't vote on those because
 it would be inappropriate.

>>>
>>> Why is disagreement a negative thing? IMO, reviewers who agree too much
>>> are just part of the echo chamber.
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> I'm not saying disagreement is a negative thing, I was saying there are
>> times when I've seen people -1 for crazy nits, e.g. there should be a
>> blank
>> line between the bug ref and change-id in the commit message, or for
>> asking
>> questions for understanding (which, btw, I'm fine with -1 for 'add a
>> comment
>> because this is complicated and I didn't get it at first'). And I'm also
>> not
>> crazy about piling on or agreeing with everything either. My point is I
>> think it's appropriate in a lot of cases to just not vote but still
>> comment.
>
> I think we have some/many implicit rules for our review. There's a
> document[1] for review
> but it doesn't mention crazy nits. So should we add what we don't want
> to see people -1 for?
>
> [1] http://docs.openstack.org/infra/manual/developers.html#peer-review
>
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing 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] [Docs] Austin Design Summit Sessions - Docs

[Lana Brindley]

The docs sessions are now in Sched, complete with etherpad links: 
https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Documentation%3A

Note the Install Guide working session is on Wednesday at 11:50, timed so that 
we can run into lunch if required. I strongly suggest you attend if you have an 
opinion: 
https://www.openstack.org/summit/austin-2016/summit-schedule/events/9226

Lana

On 01/04/16 09:49, Lana Brindley wrote:
> Hi everyone,
> 
> First of all, thanks for the amazing feedback on what docs sessions you would 
> like to see at the Austin Design Summit!
> 
> We have filled our entire allocation (and then some), and the schedule so far 
> looks something like this:
> 
> Fishbowls (40 min slot) x 4
> 
> Mitaka retro - Wed 11
> Toolchain/Infra session - Wed 16:30
> Contributor Guide - Thu 9:50
> Newton planning - Thu 13:30
> 
> Workrooms (40 min slot) x 4
> 
> API Guide Wed 9am
> Install Guide - Wed 11:50
> Security Guide - Thu 11
> Networking Guide - Thu 11:50
> 
> Meetup (Friday 14:00-17:30)
> 
> Contributors meetup. No agenda.
> 
> 
> And a note for those who noticed the Ops guide omission: this should take 
> place in the Ops track, and I'll let you know when that session will be.
> 
> Lana
> 

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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] [magnum] Enhance Mesos bay to a DCOS bay

[Kai Qiang Wu]

#2 seems more flexible, and if it be proved it can "make the SAME mesos bay
applied with mutilple frameworks." It would be great. Which means, one
mesos bay should support multiple frameworks.




Thanks


Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

Follow your heart. You are miracle!



From:   Hongbin Lu 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   11/04/2016 12:06 am
Subject:Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay



My preference is #1, but I don’t feel strong to exclude #2. I would agree
to go with #2 for now and switch back to #1 if there is a demand from
users. For Ton’s suggestion to push Marathon into the introduced
configuration hook, I think it is a good idea.

Best regards,
Hongbin

From: Ton Ngo [mailto:t...@us.ibm.com]
Sent: April-10-16 11:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay



I would agree that #2 is the most flexible option, providing a well defined
path for additional frameworks such as Kubernetes and Swarm.
I would suggest that the current Marathon framework be refactored to use
this new hook, to serve as an example and to be the supported
framework in Magnum. This will also be useful to users who want other
frameworks but not Marathon.
Ton,

Inactive hide details for Adrian Otto ---04/08/2016 08:49:52 PM---On Apr 8,
2016, at 3:15 PM, Hongbin Lu > wrote:

From: Adrian Otto 
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Date: 04/08/2016 08:49 PM
Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay



On Apr 8, 2016, at 3:15 PM, Hongbin Lu 
wrote:

Hi team,
I would like to give an update for this thread. In the last
team, we discussed several options to introduce Chronos to our
mesos bay:
1. Add Chronos to the mesos bay. With this option,
the mesos bay will have two mesos frameworks by
default (Marathon and Chronos).
2. Add a configuration hook for users to configure
additional mesos frameworks, such as Chronos. With
this option, Magnum team doesn’t need to maintain
extra framework configuration. However, users need
to do it themselves.

This is my preference.

Adrian
3. Create a dedicated bay type for Chronos. With
this option, we separate Marathon and Chronos into
two different bay types. As a result, each bay type
becomes easier to maintain, but those two mesos
framework cannot share resources (a key feature of
mesos is to have different frameworks running on
the same cluster to increase resource utilization).
Which option you prefer? Or you have other suggestions? Advices
are welcome.

Best regards,
Hongbin

From: Guz Egor [mailto:guz_e...@yahoo.com]
Sent: March-28-16 12:19 AM
To: OpenStack Development Mailing List (not for usage
questions)
Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a
DCOS bay

Jay,

just keep in mind that Chronos can be run by Marathon.

---
Egor

From: Jay Lau 
To: OpenStack Development Mailing List (not for usage
questions) 
Sent: Friday, March 25, 2016 7:01 PM
Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a
DCOS bay

Yes, that's exactly what I want to do, adding dcos cli and also
add Chronos to Mesos Bay to make it can handle both long
running services and batch jobs.

Thanks,

On Fri, Mar 25, 2016 at 5:25 PM, Michal Rostecki <
michal.roste...@gmail.com> wrote:

On 03/25/2016 07:57 AM, Jay Lau wrote:

Hi Magnum,

The 

Re: [openstack-dev] [Ironic] Failed to update Neutron port

[Haomeng, Wang]

Hi,

With my experence, for such "2016-04-08 16:31:38.690 31893 ERROR
ironic.dhcp.neutron
[-] Failed to update Neutron port 7fb98457-90e6-43be-a353-f03ea1959912."
issue, some cases are that root cause is we did not register baremetal's
mac into ironic, so neutron can not bind mac for baremetal dhcp/pxe, and
set DHCP BOOT option for port, so run below command if it is missing:

ironic port-create -n $NODE_UUID -a $MAC_ADDRESS

Good luck!


On Fri, Apr 8, 2016 at 10:00 PM, Senthilprabu Shanmugavel <
senthilprab...@gmail.com> wrote:

> Hello,
>
> I am deploying an ARMv8 board using Ironic integrated with Openstack
> Liberty on Ubuntu 12.04 host. I am using fake_pxe driver and doing the
> power on manually. Deploy image created from disk image creator tool
>
> Nova boot starts the deployment, deployment image is booted, ironic-agent
> is able to communicate with ironic conductor. After this, scsi connection
> is established, I can see this in syslog in ironic conductor node
>
>
> Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.620364] scsi
> host10: iSCSI Initiator over TCP/IP
> Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.885579] scsi
> 10:0:0:0: RAID  IET  Controller   0001 PQ: 0 ANSI: 5
> Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.886404] scsi
> 10:0:0:0: Attached scsi generic sg2 type 12
> Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.887088] scsi
> 10:0:0:1: Direct-Access IET  VIRTUAL-DISK 0001 PQ: 0 ANSI: 5
> Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.888157] sd
> 10:0:0:1: Attached scsi generic sg3 type 0
> Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.888490] sd
> 10:0:0:1: [sdc] 15240576 512-byte logical blocks: (7.80 GB/7.26 GiB)
> Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.889114] sd
> 10:0:0:1: [sdc] Write Protect is off
> Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.889118] sd
> 10:0:0:1: [sdc] Mode Sense: 69 00 10 08
> Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.889462] sd
> 10:0:0:1: [sdc] Write cache: enabled, read cache: enabled, supports DPO and
> FUA
> Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.894611]  sdc:
> unknown partition table
> Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.896728] sd
> 10:0:0:1: [sdc] Attached SCSI disk
> Apr  8 16:31:35 lionfish-ocp-controller iscsid: Connection4:0 to [target:
> iqn.2008-10.org.openstack:5044c5ab-a4f5-4ba1-9e3d-01a0cc9bb9e0, portal:
> 192.168.2.161,3260] through [iface: default] is operational now
>
> On my node console, I see below messages
>
> root@ubuntu:~# SysRq : Emergency Sync
> SysRq : Power Off
> reboot: Power down
>
> I think this is triggered by scsi driver (also seen in ironic conductor
> syslog) but node did not reboot due to known problem. So I powered off
> manually and powered on.
>
> Apr  8 16:31:38 lionfish-ocp-controller kernel: [16.290404] sd
> 10:0:0:1: [sdc] Synchronizing SCSI cache
> Apr  8 16:31:38 lionfish-ocp-controller iscsid: Connection4:0 to [target:
> iqn.2008-10.org.openstack:5044c5ab-a4f5-4ba1-9e3d-01a0cc9bb9e0, portal:
> 192.168.2.161,3260] through [iface: default] is shutdown.
>
> So far looks good. I was expecting user image download via scsi is
> successful and should be booted after going down.
>
> By then ironic conductor log says deployment failed due to neutron failing
> to set DHCP BOOT option for port.
>
>
> 2016-04-08 16:31:14.229 31893 INFO
> ironic.drivers.modules.agent_base_vendor
> [req-c1e50ceb-1e11-47ea-9260-e30a2f10605d - - - - -] Initial lookup for
> node 5044c5ab-a4f5-4ba1-9e3d-01a0cc9bb9e0 succeeded, agent is running and
> waiting for commands
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron [-] Failed to
> update Neutron port 7fb98457-90e6-43be-a353-f03ea1959912.
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron Traceback (most
> recent call last):
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron   File
> "/usr/lib/python2.7/dist-packages/ironic/dhcp/neutron.py", line 126, in
> update_port_dhcp_opts
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron
> _build_client(token).update_port(port_id, port_req_body)
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron   File
> "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 102,
> in with_params
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron ret =
> self.function(instance, *args, **kwargs)
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron   File
> "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 562,
> in update_port
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron return
> self.put(self.port_path % (port), body=body)
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron   File
> "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 302,
> in put
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron
> headers=headers, params=params)
> 2016-04-08 16:31:38.690 

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Sheel Rana Insaan]

> So should we add what we don't want
to see people -1 for?

>[1] http://docs.openstack.org/infra/manual/developers.html#peer-review

This seems right way.. but concern is do everyone follow all docs?

But atleast we should document it somewhere.

Regards,
Sheel Rana
On Apr 11, 2016 6:52 AM, "Masayuki Igawa"  wrote:

2016-04-11 9:46 GMT+09:00 Matt Riedemann :
>
>
> On 4/10/2016 6:37 PM, Clint Byrum wrote:
>>
>> Excerpts from Matt Riedemann's message of 2016-04-09 06:42:54 -0700:
>>>
>>> There is also disincentive in +1ing a change that you don't understand
>>> and is wrong and then a core comes along and -1s it (you get dinged for
>>> the disagreement). And there is disincentive in -1ing a change for the
>>> wrong reasons (silly nits or asking questions for understanding). I ask
>>> a lot of questions in a lot of changes and I don't vote on those because
>>> it would be inappropriate.
>>>
>>
>> Why is disagreement a negative thing? IMO, reviewers who agree too much
>> are just part of the echo chamber.
>>
>>
__
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> I'm not saying disagreement is a negative thing, I was saying there are
> times when I've seen people -1 for crazy nits, e.g. there should be a
blank
> line between the bug ref and change-id in the commit message, or for
asking
> questions for understanding (which, btw, I'm fine with -1 for 'add a
comment
> because this is complicated and I didn't get it at first'). And I'm also
not
> crazy about piling on or agreeing with everything either. My point is I
> think it's appropriate in a lot of cases to just not vote but still
comment.

I think we have some/many implicit rules for our review. There's a
document[1] for review
but it doesn't mention crazy nits. So should we add what we don't want
to see people -1 for?

[1] http://docs.openstack.org/infra/manual/developers.html#peer-review

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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Masayuki Igawa]

2016-04-11 9:46 GMT+09:00 Matt Riedemann :
>
>
> On 4/10/2016 6:37 PM, Clint Byrum wrote:
>>
>> Excerpts from Matt Riedemann's message of 2016-04-09 06:42:54 -0700:
>>>
>>> There is also disincentive in +1ing a change that you don't understand
>>> and is wrong and then a core comes along and -1s it (you get dinged for
>>> the disagreement). And there is disincentive in -1ing a change for the
>>> wrong reasons (silly nits or asking questions for understanding). I ask
>>> a lot of questions in a lot of changes and I don't vote on those because
>>> it would be inappropriate.
>>>
>>
>> Why is disagreement a negative thing? IMO, reviewers who agree too much
>> are just part of the echo chamber.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> I'm not saying disagreement is a negative thing, I was saying there are
> times when I've seen people -1 for crazy nits, e.g. there should be a blank
> line between the bug ref and change-id in the commit message, or for asking
> questions for understanding (which, btw, I'm fine with -1 for 'add a comment
> because this is complicated and I didn't get it at first'). And I'm also not
> crazy about piling on or agreeing with everything either. My point is I
> think it's appropriate in a lot of cases to just not vote but still comment.

I think we have some/many implicit rules for our review. There's a
document[1] for review
but it doesn't mention crazy nits. So should we add what we don't want
to see people -1 for?

[1] http://docs.openstack.org/infra/manual/developers.html#peer-review

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

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

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Matt Riedemann]

On 4/10/2016 6:37 PM, Clint Byrum wrote:

Excerpts from Matt Riedemann's message of 2016-04-09 06:42:54 -0700:

There is also disincentive in +1ing a change that you don't understand
and is wrong and then a core comes along and -1s it (you get dinged for
the disagreement). And there is disincentive in -1ing a change for the
wrong reasons (silly nits or asking questions for understanding). I ask
a lot of questions in a lot of changes and I don't vote on those because
it would be inappropriate.



Why is disagreement a negative thing? IMO, reviewers who agree too much
are just part of the echo chamber.

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



I'm not saying disagreement is a negative thing, I was saying there are 
times when I've seen people -1 for crazy nits, e.g. there should be a 
blank line between the bug ref and change-id in the commit message, or 
for asking questions for understanding (which, btw, I'm fine with -1 for 
'add a comment because this is complicated and I didn't get it at 
first'). And I'm also not crazy about piling on or agreeing with 
everything either. My point is I think it's appropriate in a lot of 
cases to just not vote but still comment.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Clint Byrum]

Excerpts from Morgan Fainberg's message of 2016-04-10 16:47:28 -0700:
> On Sun, Apr 10, 2016 at 4:37 PM, Clint Byrum  wrote:
> 
> > Excerpts from Matt Riedemann's message of 2016-04-09 06:42:54 -0700:
> > > There is also disincentive in +1ing a change that you don't understand
> > > and is wrong and then a core comes along and -1s it (you get dinged for
> > > the disagreement). And there is disincentive in -1ing a change for the
> > > wrong reasons (silly nits or asking questions for understanding). I ask
> > > a lot of questions in a lot of changes and I don't vote on those because
> > > it would be inappropriate.
> > >
> >
> > Why is disagreement a negative thing? IMO, reviewers who agree too much
> > are just part of the echo chamber.
> >
> >
> There is no problem with disagreement IMHO. However, we track it as a stat,
> and people don't want to feel as though they are in disagreement with the
> cores. I think this is just some level of psychology.
> 
> I very, very rarely look at disagreement stat for anything (now or when I
> was PTL).
> 

Agreed, as a number, it can be highly misleading and is especially hard
to compare to any of the other numbers.

However, in meta-reviews, I found actual occurrences very useful to
analyze how a reviewer handles confronting the other cores and how
confident they are in their understanding of the code base. So it worries
me that new people might be somehow discouraged from disagreement.

So let me just say it here, disagreeing with the core reviewers when
there is a valid reason _is what somebody who wants to be a core reviewer
should be doing_.

__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Morgan Fainberg]

On Sun, Apr 10, 2016 at 4:37 PM, Clint Byrum  wrote:

> Excerpts from Matt Riedemann's message of 2016-04-09 06:42:54 -0700:
> > There is also disincentive in +1ing a change that you don't understand
> > and is wrong and then a core comes along and -1s it (you get dinged for
> > the disagreement). And there is disincentive in -1ing a change for the
> > wrong reasons (silly nits or asking questions for understanding). I ask
> > a lot of questions in a lot of changes and I don't vote on those because
> > it would be inappropriate.
> >
>
> Why is disagreement a negative thing? IMO, reviewers who agree too much
> are just part of the echo chamber.
>
>
There is no problem with disagreement IMHO. However, we track it as a stat,
and people don't want to feel as though they are in disagreement with the
cores. I think this is just some level of psychology.

I very, very rarely look at disagreement stat for anything (now or when I
was PTL).

--Morgan
__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Clint Byrum]

Excerpts from Matt Riedemann's message of 2016-04-09 06:42:54 -0700:
> There is also disincentive in +1ing a change that you don't understand 
> and is wrong and then a core comes along and -1s it (you get dinged for 
> the disagreement). And there is disincentive in -1ing a change for the 
> wrong reasons (silly nits or asking questions for understanding). I ask 
> a lot of questions in a lot of changes and I don't vote on those because 
> it would be inappropriate.
> 

Why is disagreement a negative thing? IMO, reviewers who agree too much
are just part of the echo chamber.

__
OpenStack Development Mailing 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][stackalytics] Gaming the Stackalytics stats

[Amrith Kumar]

Thanks Nikhil, appreciate the comment on the gerrit bug. 

-amrith

> -Original Message-
> From: Nikhil Komawar [mailto:nik.koma...@gmail.com]
> Sent: Sunday, April 10, 2016 10:27 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics
> stats
> 
> Thanks Amrith!
> 
> I am a big supporter on including +0s.
> 
> On 4/9/16 6:31 PM, Amrith Kumar wrote:
> > Thanks to Dims and Steve for bringing this up.
> >
> > It has long been my opinion that +0's are invaluable for the
> question asking, and for getting to understand software, and unfortunately
> +0's are lost in the noise. So a while ago, I posted to the ML [1] asking
> about making +0's more visible. I signed up to submit a request on gerrit
> upstream (and promptly forgot to do that). This mail thread has reminded
> me of that. I have now posted a request for the upstream gerrit folks to
> fix [2].
> >
> > I believe that people don't use +0's enough because they often get
> ignored. I know that one can be cynical and say it is because it gives one
> no credit in stackalytics; I choose not to be that person.
> >
> > I post +0's a lot. But, I find that they are often ignored. If you
> agree with me that +0's are useful, and could be highlighted better in the
> gerrit review screen, please post a comment on [2].
> >
> > Thanks,
> >
> > -amrith
> >
> > [1] http://openstack.markmail.org/thread/nj4onttaibjmfxew
> > [2] https://code.google.com/p/gerrit/issues/detail?id=4050
> >
> >> -Original Message-
> >> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> >> Sent: Saturday, April 09, 2016 9:43 AM
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [all][stackalytics] Gaming the
> >> Stackalytics stats
> >>
> >>
> >>
> >> On 4/8/2016 5:54 PM, Jay Faulkner wrote:
> >>> I know a lot of folks explicitly avoid a +0 vote with a comment
> >>> because you don't get "credit" for it in statistics. Whether or not
> >>> that should matter is another discussion, but there is a significant
> >>> disincentive to no-voting right now.
> >>>
> >>>
> >>> -
> >>>
> >>> Jay Faulkner
> >>>
> >>>
> >>>
> >>> 
> >>> --
> >>> --
> >>> *From:* Dolph Mathews 
> >>> *Sent:* Friday, April 8, 2016 1:54 PM
> >>> *To:* OpenStack Development Mailing List (not for usage questions)
> >>> *Subject:* Re: [openstack-dev] [all][stackalytics] Gaming the
> >>> Stackalytics stats
> >>>
> >>>
> >>> On Friday, April 8, 2016, John Dickinson  >>> >
> >>> wrote:
> >>>
> >>>
> >>>
> >>> On 8 Apr 2016, at 13:35, Jeremy Stanley wrote:
> >>>
> >>>  > On 2016-04-08 19:42:18 +0200 (+0200), Dmitry Tantsur wrote:
> >>>  >> There are many ways to game a simple +1 counter, such as
> +1'ing
> >>> changes
> >>>  >> that already have at least 1x +2, or which already approved,
> or
> >>> which need
> >>>  >> rechecking...
> >>>  > [...]
> >>>  >
> >>>  > The behavior which baffles me, and also seems to be on the rise
> >>>  > lately, is random +1 votes on changes whose commit messages
> >> and/or
> >>>  > status clearly indicate they should not merged and do not
> >>> need to
> >> be
> >>>  > reviewed. I suppose that's another an easy way to avoid the
> >> dreaded
> >>>  > "disagreements" counter?
> >>>  > --
> >>>  > Jeremy Stanley
> >>>
> >>>
> >>> I have been told that some OpenStack on boarding teaches new
> members
> >>> of the community to do reviews. And they say, effectively, "muddle
> >>> through as you can. You won't understand it all at first, but do
> >>> your best. When you're done, add a +1 and move to the next one"
> >>>
> >>>
> >>> I advocate for basically this, but instead of a +1, leave a +0 and
> >>> ask questions. The new reviewer will inevitably learn something and
> >>> the author will benefit by explaining their change (teaching is the
> >>> best way to learn).
> >>>
> >>>
> >>> I've been working to correct this when I've seen it, but +1
> reviews
> >>> with no comments might not be people trying to game. It might
> simply
> >>> be people trying to get involved that don't know any better yet.
> >>>
> >>> --John
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>> __  OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >> There is also disincentive in +1ing a change that you don't
> >> understand and is wrong and then a core comes along and -1s it (you
> >> get dinged for the disagreement). And there is disincentive in -1ing
> >> a change for the wrong reasons (silly nits or asking questions for
> >> understanding). I ask a 

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Ricardo Carrillo Cruz]

++, exactly my thoughts.

I believe most people don't vote 0 for questions about the change because
'it won't count'.
That's really bad, IMHO 0 should be for asking things not clear in the
patch, whereas a -1 should be a 'this code here is not right'.

I believe the 0s should be tracked somehow.

Regards

2016-04-10 18:08 GMT+02:00 Joshua Harlow :

> +1 from me also,
>
> I also use +0 for question asking and the like, because IMHO that's not
> what -1 are for. As for myself losing stackalytics stats when *I* do this
> (ie using +0 instead of -1), meh, I got better things in my life to
> think/care about :-P
>
> -Josh
>
>
> Nikhil Komawar wrote:
>
>> Thanks Amrith!
>>
>> I am a big supporter on including +0s.
>>
>> On 4/9/16 6:31 PM, Amrith Kumar wrote:
>>
>>> Thanks to Dims and Steve for bringing this up.
>>>
>>> It has long been my opinion that +0's are invaluable for the
>>> question asking, and for getting to understand software, and unfortunately
>>> +0's are lost in the noise. So a while ago, I posted to the ML [1] asking
>>> about making +0's more visible. I signed up to submit a request on gerrit
>>> upstream (and promptly forgot to do that). This mail thread has reminded me
>>> of that. I have now posted a request for the upstream gerrit folks to fix
>>> [2].
>>>
>>> I believe that people don't use +0's enough because they often
>>> get ignored. I know that one can be cynical and say it is because it gives
>>> one no credit in stackalytics; I choose not to be that person.
>>>
>>> I post +0's a lot. But, I find that they are often ignored. If
>>> you agree with me that +0's are useful, and could be highlighted better in
>>> the gerrit review screen, please post a comment on [2].
>>>
>>> Thanks,
>>>
>>> -amrith
>>>
>>> [1] http://openstack.markmail.org/thread/nj4onttaibjmfxew
>>> [2] https://code.google.com/p/gerrit/issues/detail?id=4050
>>>
>>> -Original Message-
 From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
 Sent: Saturday, April 09, 2016 9:43 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics
 stats



 On 4/8/2016 5:54 PM, Jay Faulkner wrote:

> I know a lot of folks explicitly avoid a +0 vote with a comment
> because you don't get "credit" for it in statistics. Whether or not
> that should matter is another discussion, but there is a significant
> disincentive to no-voting right now.
>
>
> -
>
> Jay Faulkner
>
>
>
> --
> --
> *From:* Dolph Mathews
> *Sent:* Friday, April 8, 2016 1:54 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [all][stackalytics] Gaming the
> Stackalytics stats
>
>
> On Friday, April 8, 2016, John Dickinson >
> wrote:
>
>
>
>  On 8 Apr 2016, at 13:35, Jeremy Stanley wrote:
>
>   >  On 2016-04-08 19:42:18 +0200 (+0200), Dmitry Tantsur wrote:
>   >>  There are many ways to game a simple +1 counter, such as
> +1'ing
>  changes
>   >>  that already have at least 1x +2, or which already approved,
> or
>  which need
>   >>  rechecking...
>   >  [...]
>   >
>   >  The behavior which baffles me, and also seems to be on the
> rise
>   >  lately, is random +1 votes on changes whose commit messages
>
 and/or

>   >  status clearly indicate they should not merged and do not
> need to
>
 be

>   >  reviewed. I suppose that's another an easy way to avoid the
>
 dreaded

>   >  "disagreements" counter?
>   >  --
>   >  Jeremy Stanley
>
>
>  I have been told that some OpenStack on boarding teaches new
> members
>  of the community to do reviews. And they say, effectively, "muddle
>  through as you can. You won't understand it all at first, but do
>  your best. When you're done, add a +1 and move to the next one"
>
>
> I advocate for basically this, but instead of a +1, leave a +0 and ask
> questions. The new reviewer will inevitably learn something and the
> author will benefit by explaining their change (teaching is the best
> way to learn).
>
>
>  I've been working to correct this when I've seen it, but +1
> reviews
>  with no comments might not be people trying to game. It might
> simply
>  be people trying to get involved that don't know any better yet.
>
>  --John
>
>
>
>
>
> __
>  OpenStack Development Mailing List (not for usage 

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Joshua Harlow]

+1 from me also,

I also use +0 for question asking and the like, because IMHO that's not 
what -1 are for. As for myself losing stackalytics stats when *I* do 
this (ie using +0 instead of -1), meh, I got better things in my life to 
think/care about :-P


-Josh

Nikhil Komawar wrote:

Thanks Amrith!

I am a big supporter on including +0s.

On 4/9/16 6:31 PM, Amrith Kumar wrote:

Thanks to Dims and Steve for bringing this up.

It has long been my opinion that +0's are invaluable for the question 
asking, and for getting to understand software, and unfortunately +0's are lost 
in the noise. So a while ago, I posted to the ML [1] asking about making +0's 
more visible. I signed up to submit a request on gerrit upstream (and promptly 
forgot to do that). This mail thread has reminded me of that. I have now posted 
a request for the upstream gerrit folks to fix [2].

I believe that people don't use +0's enough because they often get 
ignored. I know that one can be cynical and say it is because it gives one no 
credit in stackalytics; I choose not to be that person.

I post +0's a lot. But, I find that they are often ignored. If you 
agree with me that +0's are useful, and could be highlighted better in the 
gerrit review screen, please post a comment on [2].

Thanks,

-amrith

[1] http://openstack.markmail.org/thread/nj4onttaibjmfxew
[2] https://code.google.com/p/gerrit/issues/detail?id=4050


-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
Sent: Saturday, April 09, 2016 9:43 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics
stats



On 4/8/2016 5:54 PM, Jay Faulkner wrote:

I know a lot of folks explicitly avoid a +0 vote with a comment
because you don't get "credit" for it in statistics. Whether or not
that should matter is another discussion, but there is a significant
disincentive to no-voting right now.


-

Jay Faulkner



--
--
*From:* Dolph Mathews
*Sent:* Friday, April 8, 2016 1:54 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [all][stackalytics] Gaming the
Stackalytics stats


On Friday, April 8, 2016, John Dickinson>
wrote:



 On 8 Apr 2016, at 13:35, Jeremy Stanley wrote:

  >  On 2016-04-08 19:42:18 +0200 (+0200), Dmitry Tantsur wrote:
  >>  There are many ways to game a simple +1 counter, such as +1'ing
 changes
  >>  that already have at least 1x +2, or which already approved, or
 which need
  >>  rechecking...
  >  [...]
  >
  >  The behavior which baffles me, and also seems to be on the rise
  >  lately, is random +1 votes on changes whose commit messages

and/or

  >  status clearly indicate they should not merged and do not need to

be

  >  reviewed. I suppose that's another an easy way to avoid the

dreaded

  >  "disagreements" counter?
  >  --
  >  Jeremy Stanley


 I have been told that some OpenStack on boarding teaches new members
 of the community to do reviews. And they say, effectively, "muddle
 through as you can. You won't understand it all at first, but do
 your best. When you're done, add a +1 and move to the next one"


I advocate for basically this, but instead of a +1, leave a +0 and ask
questions. The new reviewer will inevitably learn something and the
author will benefit by explaining their change (teaching is the best
way to learn).


 I've been working to correct this when I've seen it, but +1 reviews
 with no comments might not be people trying to game. It might simply
 be people trying to get involved that don't know any better yet.

 --John





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


There is also disincentive in +1ing a change that you don't understand and
is wrong and then a core comes along and -1s it (you get dinged for the
disagreement). And there is disincentive in -1ing a change for the wrong
reasons (silly nits or asking questions for understanding). I ask a lot of
questions in a lot of changes and I don't vote on those because it would
be inappropriate.

I also notice when "newcomers" are asking good questions for understanding
and not voting on them, it shows me they are trying to learn and are
getting invested in the project, not just trying to pad stats. Those are
the people we look to mentor into bigger roles in the project team, be
that working on subteams or eventually looking at for the core reviewer
team.

--

Thanks,

Matt Riedemann


__

Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay

[Hongbin Lu]

My preference is #1, but I don’t feel strong to exclude #2. I would agree to go 
with #2 for now and switch back to #1 if there is a demand from users. For 
Ton’s suggestion to push Marathon into the introduced configuration hook, I 
think it is a good idea.

Best regards,
Hongbin

From: Ton Ngo [mailto:t...@us.ibm.com]
Sent: April-10-16 11:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay


I would agree that #2 is the most flexible option, providing a well defined 
path for additional frameworks such as Kubernetes and Swarm.
I would suggest that the current Marathon framework be refactored to use this 
new hook, to serve as an example and to be the supported
framework in Magnum. This will also be useful to users who want other 
frameworks but not Marathon.
Ton,

[Inactive hide details for Adrian Otto ---04/08/2016 08:49:52 PM---On Apr 8, 
2016, at 3:15 PM, Hongbin Lu > wrote:

From: Adrian Otto >
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: 04/08/2016 08:49 PM
Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay




On Apr 8, 2016, at 3:15 PM, Hongbin Lu 
> wrote:

Hi team,
I would like to give an update for this thread. In the last team, we discussed 
several options to introduce Chronos to our mesos bay:
1. Add Chronos to the mesos bay. With this option, the mesos bay will have two 
mesos frameworks by default (Marathon and Chronos).
2. Add a configuration hook for users to configure additional mesos frameworks, 
such as Chronos. With this option, Magnum team doesn’t need to maintain extra 
framework configuration. However, users need to do it themselves.

This is my preference.

Adrian
3. Create a dedicated bay type for Chronos. With this option, we separate 
Marathon and Chronos into two different bay types. As a result, each bay type 
becomes easier to maintain, but those two mesos framework cannot share 
resources (a key feature of mesos is to have different frameworks running on 
the same cluster to increase resource utilization).
Which option you prefer? Or you have other suggestions? Advices are welcome.

Best regards,
Hongbin

From: Guz Egor [mailto:guz_e...@yahoo.com]
Sent: March-28-16 12:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay

Jay,

just keep in mind that Chronos can be run by Marathon.

---
Egor

From: Jay Lau >
To: OpenStack Development Mailing List (not for usage questions) 
>
Sent: Friday, March 25, 2016 7:01 PM
Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay

Yes, that's exactly what I want to do, adding dcos cli and also add Chronos to 
Mesos Bay to make it can handle both long running services and batch jobs.

Thanks,

On Fri, Mar 25, 2016 at 5:25 PM, Michal Rostecki 
> wrote:

On 03/25/2016 07:57 AM, Jay Lau wrote:

Hi Magnum,

The current mesos bay only include mesos and marathon, it is better to
enhance the mesos bay have more components and finally enhance it to a
DCOS which focus on container service based on mesos.

For more detail, please refer to
https://docs.mesosphere.com/getting-started/installing/installing-enterprise-edition/

The mesosphere now has a template on AWS which can help customer deploy
a DCOS on AWS, it would be great if Magnum can also support it based on
OpenStack.

I filed a bp here
https://blueprints.launchpad.net/magnum/+spec/mesos-dcos , please show
your comments if any.

--
Thanks,

Jay Lau (Guangya Liu)

Sorry if I'm missing something, but isn't DCOS a closed source software?

However, the "DCOS cli"[1] seems to be working perfectly with Marathon and 
Mesos installed by any way if you configure it well. I think that the thing 
which can be done in Magnum is to make the experience with "DOCS" tools as easy 
as possible by using open source components from Mesosphere.

Cheers,
Michal

[1] https://github.com/mesosphere/dcos-cli

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




--
Thanks,
Jay Lau (Guangya Liu)

Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay

[Ton Ngo]

I would agree that #2 is the most flexible option, providing a well defined
path for additional frameworks such as Kubernetes and Swarm.
I would suggest that the current Marathon framework be refactored to use
this new hook, to serve as an example and to be the supported
framework in Magnum.  This will also be useful to users who want other
frameworks but not Marathon.
Ton,



From:   Adrian Otto 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   04/08/2016 08:49 PM
Subject:Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay




  On Apr 8, 2016, at 3:15 PM, Hongbin Lu  wrote:

  Hi team,
  I would like to give an update for this thread. In the last team, we
  discussed several options to introduce Chronos to our mesos bay:
1.   Add Chronos to the mesos bay. With this option, the
mesos bay will have two mesos frameworks by default (Marathon
and Chronos).
2.   Add a configuration hook for users to configure
additional mesos frameworks, such as Chronos. With this option,
Magnum team doesn’t need to maintain extra framework
configuration. However, users need to do it themselves.

This is my preference.

Adrian

3.   Create a dedicated bay type for Chronos. With this
option, we separate Marathon and Chronos into two different bay
types. As a result, each bay type becomes easier to maintain,
but those two mesos framework cannot share resources (a key
feature of mesos is to have different frameworks running on the
same cluster to increase resource utilization).
  Which option you prefer? Or you have other suggestions? Advices are
  welcome.

  Best regards,
  Hongbin

  From: Guz Egor [mailto:guz_e...@yahoo.com]
  Sent: March-28-16 12:19 AM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay

  Jay,

  just keep in mind that Chronos can be run by Marathon.

  ---
  Egor


  From: Jay Lau 
  To: OpenStack Development Mailing List (not for usage questions) <
  openstack-dev@lists.openstack.org>
  Sent: Friday, March 25, 2016 7:01 PM
  Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay

  Yes, that's exactly what I want to do, adding dcos cli and also add
  Chronos to Mesos Bay to make it can handle both long running services
  and batch jobs.

  Thanks,

  On Fri, Mar 25, 2016 at 5:25 PM, Michal Rostecki <
  michal.roste...@gmail.com> wrote:

  On 03/25/2016 07:57 AM, Jay Lau wrote:

  Hi Magnum,

  The current mesos bay only include mesos and marathon, it is better
  to
  enhance the mesos bay have more components and finally enhance it to
  a
  DCOS which focus on container service based on mesos.

  For more detail, please refer to
  
https://docs.mesosphere.com/getting-started/installing/installing-enterprise-edition/


  The mesosphere now has a template on AWS which can help customer
  deploy
  a DCOS on AWS, it would be great if Magnum can also support it based
  on
  OpenStack.

  I filed a bp here
  https://blueprints.launchpad.net/magnum/+spec/mesos-dcos , please
  show
  your comments if any.

  --
  Thanks,

  Jay Lau (Guangya Liu)

  Sorry if I'm missing something, but isn't DCOS a closed source
  software?

  However, the "DCOS cli"[1] seems to be working perfectly with
  Marathon and Mesos installed by any way if you configure it well. I
  think that the thing which can be done in Magnum is to make the
  experience with "DOCS" tools as easy as possible by using open source
  components from Mesosphere.

  Cheers,
  Michal

  [1] https://github.com/mesosphere/dcos-cli

  __

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




  --
  Thanks,
  Jay Lau (Guangya Liu)

  __

  OpenStack Development Mailing 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
  

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Nikhil Komawar]

Thanks Amrith!

I am a big supporter on including +0s.

On 4/9/16 6:31 PM, Amrith Kumar wrote:
> Thanks to Dims and Steve for bringing this up.
>
>   It has long been my opinion that +0's are invaluable for the question 
> asking, and for getting to understand software, and unfortunately +0's are 
> lost in the noise. So a while ago, I posted to the ML [1] asking about making 
> +0's more visible. I signed up to submit a request on gerrit upstream (and 
> promptly forgot to do that). This mail thread has reminded me of that. I have 
> now posted a request for the upstream gerrit folks to fix [2].
>
>   I believe that people don't use +0's enough because they often get 
> ignored. I know that one can be cynical and say it is because it gives one no 
> credit in stackalytics; I choose not to be that person.
>
>   I post +0's a lot. But, I find that they are often ignored. If you 
> agree with me that +0's are useful, and could be highlighted better in the 
> gerrit review screen, please post a comment on [2].
>
> Thanks,
>
> -amrith
>
> [1] http://openstack.markmail.org/thread/nj4onttaibjmfxew
> [2] https://code.google.com/p/gerrit/issues/detail?id=4050
>
>> -Original Message-
>> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
>> Sent: Saturday, April 09, 2016 9:43 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics
>> stats
>>
>>
>>
>> On 4/8/2016 5:54 PM, Jay Faulkner wrote:
>>> I know a lot of folks explicitly avoid a +0 vote with a comment
>>> because you don't get "credit" for it in statistics. Whether or not
>>> that should matter is another discussion, but there is a significant
>>> disincentive to no-voting right now.
>>>
>>>
>>> -
>>>
>>> Jay Faulkner
>>>
>>>
>>>
>>> --
>>> --
>>> *From:* Dolph Mathews 
>>> *Sent:* Friday, April 8, 2016 1:54 PM
>>> *To:* OpenStack Development Mailing List (not for usage questions)
>>> *Subject:* Re: [openstack-dev] [all][stackalytics] Gaming the
>>> Stackalytics stats
>>>
>>>
>>> On Friday, April 8, 2016, John Dickinson >> >
>>> wrote:
>>>
>>>
>>>
>>> On 8 Apr 2016, at 13:35, Jeremy Stanley wrote:
>>>
>>>  > On 2016-04-08 19:42:18 +0200 (+0200), Dmitry Tantsur wrote:
>>>  >> There are many ways to game a simple +1 counter, such as +1'ing
>>> changes
>>>  >> that already have at least 1x +2, or which already approved, or
>>> which need
>>>  >> rechecking...
>>>  > [...]
>>>  >
>>>  > The behavior which baffles me, and also seems to be on the rise
>>>  > lately, is random +1 votes on changes whose commit messages
>> and/or
>>>  > status clearly indicate they should not merged and do not need to
>> be
>>>  > reviewed. I suppose that's another an easy way to avoid the
>> dreaded
>>>  > "disagreements" counter?
>>>  > --
>>>  > Jeremy Stanley
>>>
>>>
>>> I have been told that some OpenStack on boarding teaches new members
>>> of the community to do reviews. And they say, effectively, "muddle
>>> through as you can. You won't understand it all at first, but do
>>> your best. When you're done, add a +1 and move to the next one"
>>>
>>>
>>> I advocate for basically this, but instead of a +1, leave a +0 and ask
>>> questions. The new reviewer will inevitably learn something and the
>>> author will benefit by explaining their change (teaching is the best
>>> way to learn).
>>>
>>>
>>> I've been working to correct this when I've seen it, but +1 reviews
>>> with no comments might not be people trying to game. It might simply
>>> be people trying to get involved that don't know any better yet.
>>>
>>> --John
>>>
>>>
>>>
>>>
>>>
>>> __
>>>  OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> There is also disincentive in +1ing a change that you don't understand and
>> is wrong and then a core comes along and -1s it (you get dinged for the
>> disagreement). And there is disincentive in -1ing a change for the wrong
>> reasons (silly nits or asking questions for understanding). I ask a lot of
>> questions in a lot of changes and I don't vote on those because it would
>> be inappropriate.
>>
>> I also notice when "newcomers" are asking good questions for understanding
>> and not voting on them, it shows me they are trying to learn and are
>> getting invested in the project, not just trying to pad stats. Those are
>> the people we look to mentor into bigger roles in the project team, be
>> that working on subteams or eventually looking at for the core reviewer
>> team.
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> 

Re: [openstack-dev] [Infra] Gerrit performance

[Andreas Jaeger]

Jeremy has restarted gerrit now (Thanks!), should be fine now.

Next time, please report on IRC #openstack-infra directly,

Andreas - you didn't know that the whole world waited on gerrit
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Infra] Gerrit performance

[Jeremy Stanley]

On 2016-04-10 12:43:06 +0300 (+0300), Andrey Kurilin wrote:
> https://twitter.com/andrey_kurilin/status/681861838263443457

A lot of the Infra team (me included) aren't on social media Web
sites like that one, but Andreas Jaeger helpfully mentioned it in
the #openstack-infra IRC channel on Freenode a few minutes ago and I
restarted the service.

We're still on track to replace the server with one tomorrow that
has twice the memory capacity, and are hoping that relieves the load
issues from the JVM's periodic GC runs.

http://lists.openstack.org/pipermail/openstack-dev/2016-April/091274.html
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Infra] Gerrit performance

[Andrey Kurilin]

https://twitter.com/andrey_kurilin/status/681861838263443457

On Sun, Apr 10, 2016 at 10:39 AM, Gary Kotton  wrote:

> Hi,
> Is anyone else having problems with gerrit:
>
>1. Sometimes get a proxy error
>2. Performance is very bad
>
> Thanks
> Gary
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing 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] [nova] scheduling bandwidth resources / NIC_BW_KB resource class

[Moshe Levi]

From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com]
Sent: Friday, April 08, 2016 4:17 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [neutron] [nova] scheduling bandwidth resources / 
NIC_BW_KB resource class


Hi!,

   In the context of [1] (generic resource pools / scheduling in nova) and [2] 
(minimum bandwidth guarantees -egress- in neutron), I had a talk a few weeks 
ago with Jay Pipes,

   The idea was leveraging the generic resource pools and scheduling mechanisms 
defined in [1] to find the right hosts and track the total available bandwidth 
per host (and per host "physical network"), something in neutron (still to be 
defined where) would notify the new API about the total amount of "NIC_BW_KB" 
available on every host/physnet.
I believe that NIC bandwidth can be taken from Libvirt see [4] and the only 
piece that is missing is to tell nova the mapping of physnet to network 
interface name. (In case of SR-IOV this is already known)
I see bandwidth (speed)  as one of many capabilities of NIC, therefore I think 
we should take all of them in the same way in this case libvirt.  I was think 
of adding a new NIC as new resource to nova.

[4] - 
  net_enp129s0_e4_1d_2d_2d_8c_41
  /sys/devices/pci:80/:80:01.0/:81:00.0/net/enp129s0
  pci__81_00_0
  
enp129s0
e4:1d:2d:2d:8c:41












  


   That part is quite clear to me,

   From [1] I'm not sure which blueprint introduces the ability to schedule 
based on the resource allocation/availability itself, 
("resource-providers-scheduler" seems more like an optimization to the 
schedule/DB interaction, right?)
My understating is that the resource provider blueprint is just a rough filter 
of compute nodes before passing them to the scheduler filters. The existing 
filters here [6] will do the  accurate filtering of resources.
see [5]

[5] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2016-04-04.log.html#t2016-04-04T16:24:10
[6] - http://docs.openstack.org/developer/nova/filter_scheduler.html

And, that brings me to another point: at the moment of filtering hosts, 
nova  I guess, will have the neutron port information, it has to somehow 
identify if the port is tied to a minimum bandwidth QoS policy.

That would require identifying that the port has a "qos_policy_id" attached 
to it, and then, asking neutron for the specific QoS policy  [3], then look out 
for a minimum bandwidth rule (still to be defined), and extract the required 
bandwidth from it.
I am not sure if that is the correct  way to do it, but you can create NIC 
bandwidth filter (or NIC capabilities filter)  and in it you can implement the 
way to retrieve Qos policy information by using neutron client.

   That moves, again some of the responsibility to examine and understand 
external resources to nova.

Could it make sense to make that part pluggable via stevedore?, so we would 
provide something that takes the "resource id" (for a port in this case) and 
returns the requirements translated to resource classes (NIC_BW_KB in this 
case).


Best regards,
Miguel Ángel Ajo


[1] http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html
[2] https://bugs.launchpad.net/neutron/+bug/1560963
[3] http://developer.openstack.org/api-ref-networking-v2-ext.html#showPolicy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Vitrage] putting overlapping-templates-basic-support on the back-burner

[Afek, Ifat (Nokia - IL)]

> -Original Message-
> From: Rosensweig, Elisha (Nokia - IL)
> [mailto:elisha.rosensw...@nokia.com]
>
> Hi All,
> 
> Since
> * the overlapping templates BP
> (https://blueprints.launchpad.net/vitrage/+spec/overlapping-templates-
> basic-support) is a large one, which deserves a lot of design and
> discussion
> * there is a lot of focus on stability and clarity for the summit
> 
> I'll be putting working on this BP on hold for the coming week, and
> focus instead on Austin-tasks. Specifically, today I think I'll work on
> reviewing the Vitrage documentation.
> 
> In parallel, I'll be trying to automate the nagios installation as part
> of the vitrage "Stack"
> 
> If anyone has any issue with the above, please let me know.
> 
> Thanks,
> 
> Elisha Rosensweig, Ph.D.
> 

+1 

BTW, in the coming days I'll start moving the open blueprints from mitaka to 
newton, so your blueprint will move as well.

Ifat.


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

[openstack-dev] [Infra] Gerrit performance

[Gary Kotton]

Hi,
Is anyone else having problems with gerrit:

  1.  Sometimes get a proxy error
  2.  Performance is very bad

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

[openstack-dev] [Vitrage] putting overlapping-templates-basic-support on the back-burner

[Rosensweig, Elisha (Nokia - IL)]

Hi All,

Since 
* the overlapping templates BP 
(https://blueprints.launchpad.net/vitrage/+spec/overlapping-templates-basic-support)
 is a large one, which deserves a lot of design and discussion
* there is a lot of focus on stability and clarity for the summit

I'll be putting working on this BP on hold for the coming week, and focus 
instead on Austin-tasks. Specifically, today I think I'll work on reviewing the 
Vitrage documentation. 

In parallel, I'll be trying to automate the nagios installation as part of the 
vitrage "Stack"

If anyone has any issue with the above, please let me know.

Thanks,

Elisha Rosensweig, Ph.D.


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