[Openstack-operators] Snapshot residual data cleaning

Hi everyone， I am using a virtual machine to create a snapshot, and then use this snapshot to create other virtual machines.Will encounter residual data didn't clean the problem, this will lead to network card information is inaccurate, puppet certificate conflict etc. The current practice is to

[Openstack-operators] Overview - Openstack Dashboard - Mismatched

Hi Folks, I am running openstack ice-house version, there is mismatched value that i am getting on project overview and what actual i have instances running, for eg. for given tenant i have actual instance running is 16 and in overview page i am getting number as 28, this same scenario is exist wi

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

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

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

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:16010101T02000

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

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

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

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:16010101T02000

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

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 maili

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

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_

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

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

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

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 exa

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

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 wha

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

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

Re: [Openstack-operators] VM monitoring suggestions

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