[Openstack-operators] Canceled: [Fault Genes] WG Weekly Meeting

[Nematollah Bidokhti]

BEGIN:VCALENDAR
METHOD:CANCEL
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Nematollah Bidokhti:MAILTO:nematollah.bidok...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='openstack
 -operat...@lists.openstack.org':MAILTO:openstack-operators@lists.openstack
 .org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='user-comm
 it...@lists.openstack.org':MAILTO:user-commit...@lists.openstack.org
DESCRIPTION;LANGUAGE=en-US:When: Thursday\, November 24\, 2016 8:00 AM-9:00
  AM (UTC-08:00) Pacific Time (US & Canada).\nWhere: Conference Call\n\nNot
 e: The GMT offset above does not reflect daylight saving time adjustments.
 \n\n*~*~*~*~*~*~*~*~*~*\n\nStandard Agenda Items:\n-   Launchpad data 
 transformation to Fault Genes database\n-   Stackoverflow data capture
 \n-   User Interface for Operators\n-   Machine learning analysis 
 process\n-   Collaboration with other projects such as Congress\n-
Open items\n\n\n\n  Meeting Conference Link: https://www.connectmee
 ting.att.com\n  Meeting Number: 8887160594\n  Code: 3773562\n 
  USA Toll-Free: 888-716-0594\n  USA Caller Paid: 215-861-6199\nFor Oth
 er Countries:Click Here to View Global Conference Access Numbe
 rs\n\n\n\nThe link to the wiki https://wi
 ki.openstack.org/wiki/Fault_Genes_Working_Group\n\n\n\n
SUMMARY;LANGUAGE=en-US:Canceled: [Fault Genes] WG Weekly Meeting
DTSTART;TZID=Pacific Standard Time:20161124T08
DTEND;TZID=Pacific Standard Time:20161124T09
UID:04008200E00074C5B7101A82E00850B72A929FAAD101000
 0100028E111C3B604D445920643DCDC32B7B2
RECURRENCE-ID;TZID=Pacific Standard Time:20161124T08
CLASS:PUBLIC
PRIORITY:1
DTSTAMP:20161121T230508Z
TRANSP:OPAQUE
STATUS:CANCELLED
SEQUENCE:22
LOCATION;LANGUAGE=en-US:Conference Call
X-MICROSOFT-CDO-APPT-SEQUENCE:22
X-MICROSOFT-CDO-OWNERAPPTID:1315723232
X-MICROSOFT-CDO-BUSYSTATUS:FREE
X-MICROSOFT-CDO-INTENDEDSTATUS:FREE
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:2
X-MICROSOFT-CDO-INSTTYPE:3
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
END:VCALENDAR
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Canceled: [Fault Genes] WG Weekly Meeting

[Nematollah Bidokhti]

BEGIN:VCALENDAR
METHOD:CANCEL
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Nematollah Bidokhti:MAILTO:nematollah.bidok...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='openstack
 -operat...@lists.openstack.org':MAILTO:openstack-operators@lists.openstack
 .org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='user-comm
 it...@lists.openstack.org':MAILTO:user-commit...@lists.openstack.org
DESCRIPTION;LANGUAGE=en-US:When: Thursday\, November 24\, 2016 8:00 AM-9:00
  AM (UTC-08:00) Pacific Time (US & Canada).\nWhere: Conference Call\n\nNot
 e: The GMT offset above does not reflect daylight saving time adjustments.
 \n\n*~*~*~*~*~*~*~*~*~*\n\n\n\n\n  Meeting Conference Link: https://ww
 w.connectmeeting.att.com\n  Meeting Number: 8887160594\n  Code: 37
 73562\n  USA Toll-Free: 888-716-0594\n  USA Caller Paid: 215-861-6
 199\nFor Other Countries:Click Here to View Global Conference 
 Access Numbers\n\n\n\nThe link to the wik
 i https://wiki.openstack.org/wiki/Fault_Genes_Working_Group\n\n\n\n
SUMMARY;LANGUAGE=en-US:Canceled: [Fault Genes] WG Weekly Meeting
DTSTART;TZID=Pacific Standard Time:20161124T08
DTEND;TZID=Pacific Standard Time:20161124T09
UID:04008200E00074C5B7101A82E00850B72A929FAAD101000
 0100028E111C3B604D445920643DCDC32B7B2
RECURRENCE-ID;TZID=Pacific Standard Time:20161124T08
CLASS:PUBLIC
PRIORITY:1
DTSTAMP:20161121T230040Z
TRANSP:OPAQUE
STATUS:CANCELLED
SEQUENCE:21
LOCATION;LANGUAGE=en-US:Conference Call
X-MICROSOFT-CDO-APPT-SEQUENCE:21
X-MICROSOFT-CDO-OWNERAPPTID:1315723232
X-MICROSOFT-CDO-BUSYSTATUS:FREE
X-MICROSOFT-CDO-INTENDEDSTATUS:FREE
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:2
X-MICROSOFT-CDO-INSTTYPE:3
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
END:VCALENDAR
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Fault Genes] WG Weekly Meeting

[Nematollah Bidokhti]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Nematollah Bidokhti:MAILTO:nematollah.bidok...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='openstack
 -operat...@lists.openstack.org':MAILTO:openstack-operators@lists.openstack
 .org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='user-comm
 it...@lists.openstack.org':MAILTO:user-commit...@lists.openstack.org
DESCRIPTION;LANGUAGE=en-US:When: Occurs every Thursday effective 5/19/2016 
 from 8:00 AM to 9:00 AM (UTC-08:00) Pacific Time (US & Canada).\nWhere: Co
 nference Call\n\nNote: The GMT offset above does not reflect daylight savi
 ng time adjustments.\n\n*~*~*~*~*~*~*~*~*~*\n\n\n\n\n  Meeting Confere
 nce Link: https://www.connectmeeting.att.com\n  Meeting Number: 888716
 0594\n  Code: 3773562\n  USA Toll-Free: 888-716-0594\n  USA Ca
 ller Paid: 215-861-6199\nFor Other Countries:Click Here to Vie
 w Global Conference Access Numbers\n\n\n\
 nThe link to the wiki https://wiki.openstack.org/wiki/Fault_Genes_Working_
 Group\n\n\n\n
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TH;WKST=SU
EXDATE;TZID=Pacific Standard Time:20161124T08
SUMMARY;LANGUAGE=en-US:[Fault Genes] WG Weekly Meeting
DTSTART;TZID=Pacific Standard Time:20160519T08
DTEND;TZID=Pacific Standard Time:20160519T09
UID:04008200E00074C5B7101A82E00850B72A929FAAD101000
 0100028E111C3B604D445920643DCDC32B7B2
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20161121T230039Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:21
LOCATION;LANGUAGE=en-US:Conference Call
X-MICROSOFT-CDO-APPT-SEQUENCE:21
X-MICROSOFT-CDO-OWNERAPPTID:1315723232
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:1
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
BEGIN:VEVENT
SUMMARY:[Fault Genes] WG Weekly Meeting
DTSTART;TZID=Pacific Standard Time:20161103T08
DTEND;TZID=Pacific Standard Time:20161103T09
UID:04008200E00074C5B7101A82E00850B72A929FAAD101000
 0100028E111C3B604D445920643DCDC32B7B2
RECURRENCE-ID;TZID=Pacific Standard Time:20161103T00
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20161121T230039Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:21
LOCATION:Conference Call
X-MICROSOFT-CDO-APPT-SEQUENCE:21
X-MICROSOFT-CDO-OWNERAPPTID:1315723232
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:1
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
BEGIN:VEVENT
SUMMARY:[Fault Genes] WG Weekly Meeting
DTSTART;TZID=Pacific Standard Time:20161110T08
DTEND;TZID=Pacific Standard Time:20161110T09
UID:04008200E00074C5B7101A82E00850B72A929FAAD101000
 0100028E111C3B604D445920643DCDC32B7B2
RECURRENCE-ID;TZID=Pacific Standard Time:20161110T00
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20161121T230039Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:21
LOCATION:Conference Call
X-MICROSOFT-CDO-APPT-SEQUENCE:21
X-MICROSOFT-CDO-OWNERAPPTID:1315723232
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:1
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
END:VCALENDAR
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [ceilometer] what is cpu_util: directly measured or derived?

[Danek Duvall]

gordon chung wrote:

> i'm not entirely sure your plans but if in Solaris, you are able to poll 
> for cpu utilisation directly, you can just modify the pipeline and drop 
> cpu_util transform.

Simple enough; thanks!

Danek

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Setting default MTU for project networks?

[Jonathan Proulx]

On Mon, Nov 21, 2016 at 09:31:04PM +0100, Kostyantyn Volenbovskyi wrote:
:Hi,
:
:it really sounds that it path_mtu = 9000 was done in ‘wrong place’, see inline 
below 
:The fact that you indicate ml2.ini 

 and not ml2_conf.ini is a bit ‘suspicious'


Yes it is suspicious (and wrong) seems that [ml2] section is actually
in neutron/plugins/ml2/openvswitch_agent.ini so yes putting that in
the right place would probably fix things :)


:Reading the recent it sounds that in your exact case
:global_physnet_mtu should be equal to path_mtu and that should be 9000. That 
will result in MTU for VXLAN to be 8950 and MTU for VLAN - 9000
:
:So I don’t reason to use ‘9134’ or 9004 in your environment.

OK makes sense. So ignore the extra 4B for VLAN headers here.

Not that it matters but for the curious 9134 is what matches the
switch port MTU.  I no longer remember why but network folks had
initially (long before openstack) wanted a slightly larger than 9000
MTU for $REASONS. But in reality some hardware we needed on those
networks only supported 9000, so after seting the network hardware for
higher we turned back the MTU on all the stations to 9000


:All in all I think that [1] and [2] will be helpful.
:
:(and yes, it should be noted that my description is for Mitaka onwards)
:
:BR, 
:Konstantin
:
:[1] http://docs.openstack.org/draft/networking-guide/config-mtu.html 

:[2] https://bugzilla.redhat.com/show_bug.cgi?id=1374795 

:
:> 
:> :Setting the following in your server config (not agent), should be enough
:> :for VXLAN networks to use a jumbo MTU.
:> :
:> :[DEFAULT]
:> :global_physnet_mtu = 9000
:> 
:> Got that one
:> 
:> :[ml2]
:> :path_mtu = 9000
:> 
:> So I don't have an [ml2] section in neutron.conf referenced by the
:> neutron-server processes.  I do have that in the agent.ini referenced
:> by neutron-openvswitch-agent on the network node.
:Well, typically you would have /etc/neutron/plugins/ml2/ml2_conf.ini, 
symlinked 
:from /etc/neutron/plugin.ini and neutron-server should use that.
:
:
:> I additonally have:
:> 
:> [agent]
:> veth_mtu=9004
:> 
:> in agent.ini on network node.
:> 
:> On hypervisors I have:
:> 
:> [ml2]
:> path_mtu = 0
:> physical_network_mtus =trunk:9004
:> 
:> [agent]
:> veth_mtu=9004
:> 
:> Obviously the hypervisor stuff won't effect how networks are created,
:> but don't want that to start biting me in a different way if I get
:> server side doing what I want.
:> 
:> 
:> Note 9004 is the pysical interface MTU in this example.  We have
:> provider netorks that are VLAN based so their MTU should be (is)
:> 9000.  The pre-existing provider networks are properly set though
:> manual hackery I've only added 1 since the cloud was initially created
:> 4 years ago, so not a common action.  Am I right in setting 9004 above
:> or should I still lie a little and provide the untagged MTU of 9000?
:> 
:> Thanks,
:> -Jon
:> 
:> :
:> :On Tue, Nov 8, 2016 at 8:31 AM, Jonathan Proulx > wrote:
:> :
:> :> On Mon, Nov 07, 2016 at 02:12:14PM -0800, Kevin Benton wrote:
:> :> :Which version of Neutron are you on now? Changing the config options had
:> :> no
:> :> :impact on existing networks in Mitaka. After updating the config, only 
new
:> :> :networks will be affected. You will need to use an SQL query to update 
the
:> :> :existing network MTUs.
:> :>
:> :> Mitaka
:> :>
:> :> I understand that old MTU's won't change, but new overlays are gettign
:> :> created with 1458 MTU despite the configs I thnk should tell it the
:> :> jumbo underlay size, so I'm probably missing something :)
:> :>
:> :> I did discover since neutron is now MTU aware I can simply drop the
:> :> dhcp-option=26,9000 and (after poking the DB for the existing jumbo
:> :> networks which had 'Null' MTUs) the old stuff and new stuff work just
:> :> new stuff has overly restrictive MTU.
:> :>
:> :> :This was changed in Newton (https://review.openstack.org/#/c/336805/ 
) but
:> :> :we couldn't back-port it because of the behavior change.
:> :>
:> :> Neat I didn't know support form changing MTU was even planned, but I
:> :> gues it's here (well not quite *here* but...)
:> :>
:> :> -Jon
:> :>
:> :> :
:> :> :
:> :> :On Fri, Nov 4, 2016 at 10:34 AM, Jonathan Proulx >
:> :> wrote:
:> :> :
:> :> :> Hi All,
:> :> :>
:> :> :>
:> :> :> So long story short how do I get my ml2/ovs GRE tenant network to
:> :> default
:> :> :> to
:> :> :> MTU 9000 in Mitaka - or - get dhcp agents on on netork node to give
:> :> :> out different MTUs to different networks?
:> :> :>
:> :> :>
:> :> :> Seems between Kilo (my last release) and Mitaka (my  current production
:> :> :> world) Neutron got a lot cleverer about MTUs and teh simple
:> :> :> 

Re: [Openstack-operators] [ceilometer] what is cpu_util: directly measured or derived?

[gordon chung]

On 18/11/16 05:10 PM, Danek Duvall wrote:

>> this pollster is used by other hypervisor polling.  there was a patch for
>> libvirt driver to use libvirt native functionality to retrieve cpu_util
>> info rather than computing it[3]. unfortunately, at the time, the
>> functionality was in a version too new to match with Nova libvirt
>> requirements.
>
> If I'm reading this correctly, it's more than that.  Solving the overcommit
> issue is different, and requires the new meters.  But simply keeping the
> more naive definition of cpu_util wouldn't have.  Even the libvirt has an
> inspect_cpu_util() call whose data, feeding into the cpu_util meter defined
> by ceilometer.cpu.CPUUtilPollster will presumably be masked by the the
> cpu_util meter defined by the pipeline.

i'm not sure it requires new meters but i'm not entirely sure. some of 
the code in that patch was actually deferred to libvirt rather than 
having a ceilometer specific implementation.

the derived cpu_util meter in the pipeline is uniquely a libvirt/hyperv 
meter. those two solutions can't query for cpu utilisation so it's 
compute. if you look at xenapi/vsphere, they are able to provide 
cpu_util so they don't actually generate cpu time meter and therefore 
never derive the cpu_util meter in pipeline.

>
> It's that masking I'm wondering about, and the change you reference doesn't
> get rid of it, either.

i originally assumed the patch would allow us to query cpu utilisation 
directly but it seems that might be a wrong assumption.
>
> It might be easier for me to drop my implementation of inspect_cpu_util()
> and let the ceilometer-computed version of cpu_util take care of it, but
> since we have a way of getting the number directly, it might be nice to use
> it.
>

i'm not entirely sure your plans but if in Solaris, you are able to poll 
for cpu utilisation directly, you can just modify the pipeline and drop 
cpu_util transform.

cheers,

-- 
gord
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Setting default MTU for project networks?

[Kostyantyn Volenbovskyi]

Hi,

it really sounds that it path_mtu = 9000 was done in ‘wrong place’, see inline 
below 
The fact that you indicate ml2.ini 

 and not ml2_conf.ini is a bit ‘suspicious'

Reading the recent it sounds that in your exact case
global_physnet_mtu should be equal to path_mtu and that should be 9000. That 
will result in MTU for VXLAN to be 8950 and MTU for VLAN - 9000

So I don’t reason to use ‘9134’ or 9004 in your environment.

All in all I think that [1] and [2] will be helpful.

(and yes, it should be noted that my description is for Mitaka onwards)

BR, 
Konstantin

[1] http://docs.openstack.org/draft/networking-guide/config-mtu.html 

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1374795 


> 
> :Setting the following in your server config (not agent), should be enough
> :for VXLAN networks to use a jumbo MTU.
> :
> :[DEFAULT]
> :global_physnet_mtu = 9000
> 
> Got that one
> 
> :[ml2]
> :path_mtu = 9000
> 
> So I don't have an [ml2] section in neutron.conf referenced by the
> neutron-server processes.  I do have that in the agent.ini referenced
> by neutron-openvswitch-agent on the network node.
Well, typically you would have /etc/neutron/plugins/ml2/ml2_conf.ini, symlinked 
from /etc/neutron/plugin.ini and neutron-server should use that.


> I additonally have:
> 
> [agent]
> veth_mtu=9004
> 
> in agent.ini on network node.
> 
> On hypervisors I have:
> 
> [ml2]
> path_mtu = 0
> physical_network_mtus =trunk:9004
> 
> [agent]
> veth_mtu=9004
> 
> Obviously the hypervisor stuff won't effect how networks are created,
> but don't want that to start biting me in a different way if I get
> server side doing what I want.
> 
> 
> Note 9004 is the pysical interface MTU in this example.  We have
> provider netorks that are VLAN based so their MTU should be (is)
> 9000.  The pre-existing provider networks are properly set though
> manual hackery I've only added 1 since the cloud was initially created
> 4 years ago, so not a common action.  Am I right in setting 9004 above
> or should I still lie a little and provide the untagged MTU of 9000?
> 
> Thanks,
> -Jon
> 
> :
> :On Tue, Nov 8, 2016 at 8:31 AM, Jonathan Proulx  > wrote:
> :
> :> On Mon, Nov 07, 2016 at 02:12:14PM -0800, Kevin Benton wrote:
> :> :Which version of Neutron are you on now? Changing the config options had
> :> no
> :> :impact on existing networks in Mitaka. After updating the config, only new
> :> :networks will be affected. You will need to use an SQL query to update the
> :> :existing network MTUs.
> :>
> :> Mitaka
> :>
> :> I understand that old MTU's won't change, but new overlays are gettign
> :> created with 1458 MTU despite the configs I thnk should tell it the
> :> jumbo underlay size, so I'm probably missing something :)
> :>
> :> I did discover since neutron is now MTU aware I can simply drop the
> :> dhcp-option=26,9000 and (after poking the DB for the existing jumbo
> :> networks which had 'Null' MTUs) the old stuff and new stuff work just
> :> new stuff has overly restrictive MTU.
> :>
> :> :This was changed in Newton (https://review.openstack.org/#/c/336805/ 
> ) but
> :> :we couldn't back-port it because of the behavior change.
> :>
> :> Neat I didn't know support form changing MTU was even planned, but I
> :> gues it's here (well not quite *here* but...)
> :>
> :> -Jon
> :>
> :> :
> :> :
> :> :On Fri, Nov 4, 2016 at 10:34 AM, Jonathan Proulx  >
> :> wrote:
> :> :
> :> :> Hi All,
> :> :>
> :> :>
> :> :> So long story short how do I get my ml2/ovs GRE tenant network to
> :> default
> :> :> to
> :> :> MTU 9000 in Mitaka - or - get dhcp agents on on netork node to give
> :> :> out different MTUs to different networks?
> :> :>
> :> :>
> :> :> Seems between Kilo (my last release) and Mitaka (my  current production
> :> :> world) Neutron got a lot cleverer about MTUs and teh simple
> :> :> workarounds I had to make by jumbo frames go are now causing some
> :> :> issues for newly created project networks.
> :> :>
> :> :> Because I'm setting 'dhcp-option=26,9000' in /etc/neutron/dnsmasq.conf
> :> :> everything get an MTU of 9000 inside the guest OS. I only *really*
> :> :> care about this for our provider vlans, for project networks I only
> :> :> care that they work.
> :> :>
> :> :> CUrrently when a new project network is created it get an MTU of 1458
> :> :> (1500 less GRE overhead) this is reflected in teh neutron DB and the
> :> :> various virtual interfaces on the hypervisor and network node, but
> :> :> DHCP configures inside the host to be 9000 and hilarity ensues.
> :> :>
> :> :> I tried setting DEFAULT/global_physnet_mtu=9134 in neutron.conf and
> :> :> ml2/path_mtu=9134 in ml2.ini (which is the actual 

Re: [Openstack-operators] Setting default MTU for project networks?

[Jonathan D. Proulx]

On Sun, Nov 20, 2016 at 02:59:14AM -0800, Kevin Benton wrote:
:Sorry about the delay, a couple of questions.

No worries "working" was the important bit (which I got).  Working
correctly, well we can take our time :)

:You're not setting network_device_mtu, right?

no though maybe I should read what that is.

:Also, when you see the 1458 MTU, is that in the API response from neutron
:on a 'neutron net-show', Or is that just what you are seeing in the
:interfaces on the compute nodes?

this is how the interfaces are getting created and what teh instaces
are getting from DHCP (now anyway, fixing that was my pressing issue).

:Setting the following in your server config (not agent), should be enough
:for VXLAN networks to use a jumbo MTU.
:
:[DEFAULT]
:global_physnet_mtu = 9000

Got that one

:[ml2]
:path_mtu = 9000

So I don't have an [ml2] section in neutron.conf referenced by the
neutron-server processes.  I do have that in the agent.ini referenced
by neutron-openvswitch-agent on the network node.

I additonally have:

[agent]
veth_mtu=9004

in agent.ini on network node.

On hypervisors I have:

[ml2]
path_mtu = 0
physical_network_mtus =trunk:9004

[agent]
veth_mtu=9004

Obviously the hypervisor stuff won't effect how networks are created,
but don't want that to start biting me in a different way if I get
server side doing what I want.


Note 9004 is the pysical interface MTU in this example.  We have
provider netorks that are VLAN based so their MTU should be (is)
9000.  The pre-existing provider networks are properly set though
manual hackery I've only added 1 since the cloud was initially created
4 years ago, so not a common action.  Am I right in setting 9004 above
or should I still lie a little and provide the untagged MTU of 9000?

Thanks,
-Jon

:
:On Tue, Nov 8, 2016 at 8:31 AM, Jonathan Proulx  wrote:
:
:> On Mon, Nov 07, 2016 at 02:12:14PM -0800, Kevin Benton wrote:
:> :Which version of Neutron are you on now? Changing the config options had
:> no
:> :impact on existing networks in Mitaka. After updating the config, only new
:> :networks will be affected. You will need to use an SQL query to update the
:> :existing network MTUs.
:>
:> Mitaka
:>
:> I understand that old MTU's won't change, but new overlays are gettign
:> created with 1458 MTU despite the configs I thnk should tell it the
:> jumbo underlay size, so I'm probably missing something :)
:>
:> I did discover since neutron is now MTU aware I can simply drop the
:> dhcp-option=26,9000 and (after poking the DB for the existing jumbo
:> networks which had 'Null' MTUs) the old stuff and new stuff work just
:> new stuff has overly restrictive MTU.
:>
:> :This was changed in Newton (https://review.openstack.org/#/c/336805/) but
:> :we couldn't back-port it because of the behavior change.
:>
:> Neat I didn't know support form changing MTU was even planned, but I
:> gues it's here (well not quite *here* but...)
:>
:> -Jon
:>
:> :
:> :
:> :On Fri, Nov 4, 2016 at 10:34 AM, Jonathan Proulx 
:> wrote:
:> :
:> :> Hi All,
:> :>
:> :>
:> :> So long story short how do I get my ml2/ovs GRE tenant network to
:> default
:> :> to
:> :> MTU 9000 in Mitaka - or - get dhcp agents on on netork node to give
:> :> out different MTUs to different networks?
:> :>
:> :>
:> :> Seems between Kilo (my last release) and Mitaka (my  current production
:> :> world) Neutron got a lot cleverer about MTUs and teh simple
:> :> workarounds I had to make by jumbo frames go are now causing some
:> :> issues for newly created project networks.
:> :>
:> :> Because I'm setting 'dhcp-option=26,9000' in /etc/neutron/dnsmasq.conf
:> :> everything get an MTU of 9000 inside the guest OS. I only *really*
:> :> care about this for our provider vlans, for project networks I only
:> :> care that they work.
:> :>
:> :> CUrrently when a new project network is created it get an MTU of 1458
:> :> (1500 less GRE overhead) this is reflected in teh neutron DB and the
:> :> various virtual interfaces on the hypervisor and network node, but
:> :> DHCP configures inside the host to be 9000 and hilarity ensues.
:> :>
:> :> I tried setting DEFAULT/global_physnet_mtu=9134 in neutron.conf and
:> :> ml2/path_mtu=9134 in ml2.ini (which is the actual MTU of L2 links),
:> :> agent/veth_mtu=9134 was previously set. I thought this would result in
:> :> virtualdevices large enough to pass the 9000 traffic but seems to have
:> :> made no difference.
:> :>
:> :> I can kludge around by specifying MTU on network creation (or some
:> :> post facto DB hackery) but this isn't do able through my Horizon UI so
:> :> my users won't do it.
:> :>
:> :> Thanks,
:> :> -Jon
:> :>
:> :>
:> :> ___
:> :> OpenStack-operators mailing list
:> :> OpenStack-operators@lists.openstack.org
:> :> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
:> :>
:>
:> --
:>

-- 

___

Re: [Openstack-operators] [publicClouds-wg] Public Cloud Working Group

[matt Jarvis]

Whoops, just realised I can't send to these lists with multiple additional
recipients, so sending again separately ..

Thank you for all of your interest in this proposal. In order to move
things to the next stage I need to organise a first IRC meeting, and I
think it's probably most appropriate to book one of the openstack-meeting
channels rather than use openstack-operators. Having looked at the current
usage, it looks like every 2 weeks on a Wednesday would work initially, and
there are two times which look possible, 14:00 and 19:00 UTC. The meeting
schedule is fairly complicated, so there may be other options if neither of
these works for a quorum, but can I suggest we start with these options and
work from there ? I've put together a Doodle poll with the two options, and
I'd appreciate your participation in the poll before I go ahead and try to
book a slot.

http://doodle.com/poll/be43ysxhg5iq3uha

On Tue, Nov 15, 2016 at 10:43 AM, matt Jarvis 
wrote:

> So after input from a variety of sources over the last few weeks, I'd very
> much like to try and put together a public cloud working group, with the
> very high level goal of representing the interests of the public cloud
> provider community around the globe.
>
> I'd like to propose that, in line with the new process for creation of
> working groups, we set up some initial IRC meetings for all interested
> parties. The goals for these initial meetings would be :
>
> 1. Define the overall scope and mission statement for the working group
> 2. Set out the constituency for the group - communication methods,
> definitions of public clouds, meeting schedules, chairs etc.
> 3. Identify areas of interest - eg. technical issues, collaboration
> opportunities
>
> Before I go ahead and schedule first meetings, I'd very much like to
> gather input from the community on interested parties, and if this seems
> like a reasonable first step forward. My thought initially was to schedule
> a first meeting on #openstack-operators and then decide on best timings,
> locations and communication methods from there, but again I'd welcome
> input.
>
> At this point it would seem to me that one of the key metrics for this
> working group to be successful is participation as widely as possible
> within the public cloud provider community, currently approximately 21
> companies globally according to https://www.openstack.org/
> marketplace/public-clouds/. If we could get representation from all of
> those companies in any potential working group, then that would clearly be
> the best outcome, although that may be optimistic ! As has become clear at
> recent Ops events, it may be that not all of those companies are
> represented on these lists, so I'd welcome any input on the best way to
> reach out to those folks.
>
> Matt
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] VM monitoring suggestions

[Van Leeuwen, Robert]

>>I know that ceilometer may be an option, but I believe operators use all kind 
>>of tools for their own ressource usage monitoring. So what do you people use?
>>
>>(For this use case, we're looking for something that can be used without 
>>installing an agent in the VM, which makes it impossible to get a VM's load 
>>metric. I would be satisfied with cpu/memory/network/io metrics though.)


Although I’d like to re-evaluate ceilometer at some point we currently use 
something very simple with the infra we already had in place.

We use the collectd libvirt plugin and push the metrics to graphite.
https://collectd.org/wiki/index.php/Plugin:virt

If you use the following format you get the instance uuid in the metric name:
HostnameFormat "hostname uuid"

The output of those graphite keys is not exactly what we want (IIRC you get 
hostname_uuid instead of hostname.uuid)
We rewrite it a bit with carbon-(c-)relay daemon to something more usable so 
you get:
computenode.libvirt.UUID.metrics

We made a grafana dashboard where you can select the uuid and get the stats of 
the instance.

Pros:
* Simple, just needs collectd on compute nodes
* Graphite scales (with the proper setup)

Cons:
* No tenant-id in the metric name  (I guess with some scripting you can make a 
mapping-tree in graphite)
* No metrics in Horizon. (We still have to make some time to integrate these 
metrics into horizon but that should be doable.)
* Just instance metrics nothing else

Cheers,
Robert van Leeuwen
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators