[Openstack-operators] [Forum] Fault Management/Monitoring for NFV/Edge/5G/IoT

[Yuki Kasuya]

Hi All,

I've created an etherpad for Fault Management/Monitoring for  
NFV/Edge/5G/IoT. It'll take place on Tuesday, May 22, 4:40pm-6:10pm @  
Room 221-222. If you have any usecase/idea/challenge for FM at these new  
area, could you join this forum and add any topic/comment to etherpad.


https://etherpad.openstack.org/p/YVR-fm-monitoring

Best regards,
Yuki

--
-
KDDI Research, Inc.
Integrated Core Network Control
And Management Laboratory
Yuki Kasuya
yu-kas...@kddilabs.jp
+81 80 9048 8405

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

Re: [Openstack-operators] attaching network cards to VMs taking a very long time

[Matt Riedemann]

On 5/16/2018 10:30 AM, Radu Popescu | eMAG, Technology wrote:

but I can see nova attaching the interface after a huge amount of time.


What specifically are you looking for in the logs when you see this?

Are you passing pre-created ports to attach to nova or are you passing a 
network ID so nova will create the port for you during the attach call?


This is where the ComputeManager calls the driver to plug the vif on the 
host:


https://github.com/openstack/nova/blob/stable/ocata/nova/compute/manager.py#L5187

Assuming you're using the libvirt driver, the host vif plug happens here:

https://github.com/openstack/nova/blob/stable/ocata/nova/virt/libvirt/driver.py#L1463

And the guest is updated here:

https://github.com/openstack/nova/blob/stable/ocata/nova/virt/libvirt/driver.py#L1472

vif_plugging_is_fatal and vif_plugging_timeout don't come into play here 
because we're attaching an interface to an existing server - or are you 
talking about during the initial creation of the guest, i.e. this code 
in the driver?


https://github.com/openstack/nova/blob/stable/ocata/nova/virt/libvirt/driver.py#L5257

Are you seeing this in the logs for the given port?

https://github.com/openstack/nova/blob/stable/ocata/nova/compute/manager.py#L6875

If not, it could mean that neutron-server never send the event to nova, 
so nova-compute timed out waiting for the vif plug callback event to 
tell us that the port is ready and the server can be changed to ACTIVE 
status.


The neutron-server logs should log when external events are being sent 
to nova for the given port, you probably need to trace the requests and 
compare the nova-compute and neutron logs for a given server create request.


--

Thanks,

Matt

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

[Openstack-operators] ocata octavia http loadbalancer error 503 Service Unavailable

[Ignazio Cassano]

Hi everyone,
I am using octavia on centos7 ocata.
When I define a http load balancer it does not work.
Accessing the load balancer address returns 503 error.
The above happens when the load balancer protocol specified is HTTP.

If the load balancer protocol specified is TCP , it works.

Probably the amphora instance haproxy is facing some issue with http health
check ?

Could anyone help me , please ?

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

Re: [Openstack-operators] ocata gnocchi file system : erasing old data

[Ignazio Cassano]

Many thanks
Ignazio

2018-05-16 16:45 GMT+02:00 gordon chung :

>
>
> On 2018-05-15 2:40 AM, Ignazio Cassano wrote:
> > gnocchi resource delete instance id
> >
> >
> > Does the above procedure remove data either from database or
> > /var/lib/gnocchi directory ?
>
> not immediately, it will mark the data for deletion. there is a
> 'janitor' service that runs periodically that will remove the data. this
> is defined by the `metric_cleanup_delay` in the configuration file.
>
> cheers,
>
> --
> gord
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] attaching network cards to VMs taking a very long time

[Radu Popescu | eMAG, Technology]

Hi all,

we have the following setup:
- Openstack Ocata deployed with Openstack Ansible (v15.1.7)
- 66 compute nodes, each having between 50 and 150 VMs, depending on their 
hardware configuration
- we don't use Ceilometer (so not adding extra load on RabbitMQ cluster)
- using Openvswitch HA with DVR
- all messaging are going through a 3 servers RabbitMQ cluster
- we now have 3 CCs hosting (initially had 2) hosting every other internal 
service

What happens is, when we create a large number of VMs (it's something we do on 
a daily basis, just to test different types of VMs and apps, around 300 VMs), 
there are some of them that don't get the network interface attached in a 
reasonable time.
After investigating, we can see that Neutron Openvswitch agent sees the port 
attached to the server, from an Openstack point of view, I can see the tap 
interface created in Openvswitch using both its logs and dmesg, but I can see 
nova attaching the interface after a huge amount of time. (I could see even 45 
minutes delay)

Since I can't see any reasonable errors I could take care of, my last chance is 
this mailing list.
Only thing I can think of, is that maybe libvirt is not able to attach the 
interface in a reasonable amount of time. But still, 45 minutes is way too much.

At the moment:
vif_plugging_is_fatal = True
vif_plugging_timeout = 600 (modified from default 300s)

That's because we needed VMs with networking. Otherwise, if either with error, 
either with no network, it's the same thing for us.

Thanks,

--

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

Re: [Openstack-operators] ocata gnocchi file system : erasing old data

[gordon chung]

On 2018-05-15 2:40 AM, Ignazio Cassano wrote:
> gnocchi resource delete instance id
> 
> 
> Does the above procedure remove data either from database or 
> /var/lib/gnocchi directory ?

not immediately, it will mark the data for deletion. there is a 
'janitor' service that runs periodically that will remove the data. this 
is defined by the `metric_cleanup_delay` in the configuration file.

cheers,

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

[Openstack-operators] [I18n] [Docs] Forum session Vancouver

[Frank Kloeker]

Good morning,

just a quick note when packing the suitcase: We have a Docs/I18n Forum 
session on Monday 21th, 13:30, direct after lunch [1]. Take the chance 
to discuss topics about project onboarding with translation or 
documentation, usage of translated documents or tools. Or just come to 
say Hello :-)

Looking forward to see you there!

kind regards

Frank (PTL I18n)


[1] 
https://etherpad.openstack.org/p/docs-i18n-project-onboarding-vancouver


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

Re: [Openstack-operators] [openstack-dev][heat][all] Heat now migrated to StoryBoard!!

[Rico Lin]

Bump the last time

Hi all,
As we keep adding more info to the migration guideline [1], you might like
to take a look again.
And do hope it will make things easier for you. If not, please find me in
irc or mail.

[1] https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info


2018-05-10 18:42 GMT+08:00 Rico Lin :

> Hi all,
> As we keep adding more info to the migration guideline [1], you might like
> to take a look again.
> And do hope it will make things easier for you. If not, please find me in
> irc or mail.
>
> [1] https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info
>
> Here's the quick hint for you, your bug id is exactly your story id.
>
> 2018-05-07 18:27 GMT+08:00 Rico Lin :
>
>> Hi all,
>>
>> I updated more information to this guideline in [1].
>> Please must take a view on [1] to see what's been updated.
>> will likely to keep update on that etherpad if new Q or issue found.
>>
>> Will keep trying to make this process as painless for you as possible,
>> so please endure with us for now, and sorry for any inconvenience
>>
>> *[1] https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info
>> *
>>
>> 2018-05-05 12:15 GMT+08:00 Rico Lin :
>>
>>> looping heat-dashboard team
>>>
>>> 2018-05-05 12:02 GMT+08:00 Rico Lin :
>>>
 Dear all Heat members and friends

 As you might award, OpenStack projects are scheduled to migrating ([5])
 from Launchpad to StoryBoard [1].
 For whom who like to know where to file a bug/blueprint, here are some
 heads up for you.

 *What's StoryBoard?*
 StoryBoard is a cross-project task-tracker, contains numbers of
 ``project``, each project contains numbers of ``story`` which you can think
 it as an issue or blueprint. Within each story, contains one or multiple
 ``task`` (task separate stories into the tasks to resolve/implement). To
 learn more about StoryBoard or how to make a good story, you can reference
 [6].

 *How to file a bug?*
 This is actually simple, use your current ubuntu-one id to access to
 storyboard. Then find the corresponding project in [2] and create a story
 to it with a description of your issue. We should try to create tasks which
 to reference with patches in Gerrit.

 *How to work on a spec (blueprint)?*
 File a story like you used to file a Blueprint. Create tasks for your
 plan. Also you might want to create a task for adding spec( in heat-spec
 repo) if your blueprint needs documents to explain.
 I still leave current blueprint page open, so if you like to create a
 story from BP, you can still get information. Right now we will start work
 as task-driven workflow, so BPs should act no big difference with a bug in
 StoryBoard (which is a story with many tasks).

 *Where should I put my story?*
 We migrate all heat sub-projects to StoryBoard to try to keep the
 impact to whatever you're doing as small as possible. However, if you plan
 to create a new story, *please create it under heat project [4]* and
 tag it with what it might affect with (like python-heatclint,
 heat-dashboard, heat-agents). We do hope to let users focus their stories
 in one place so all stories will get better attention and project
 maintainers don't need to go around separate places to find it.

 *How to connect from Gerrit to StoryBoard?*
 We usually use following key to reference Launchpad
 Closes-Bug: ###
 Partial-Bug: ###
 Related-Bug: ###

 Now in StoryBoard, you can use following key.
 Task: ##
 Story: ##
 you can find more info in [3].

 *What I need to do for my exists bug/bps?*
 Your bug is automatically migrated to StoryBoard, however, the
 reference in your patches ware not, so you need to change your commit
 message to replace the old link to launchpad to new links to StoryBoard.

 *Do we still need Launchpad after all this migration are done?*
 As the plan, we won't need Launchpad for heat anymore once we have done
 with migrating. Will forbid new bugs/bps filed in Launchpad. Also, try to
 provide new information as many as possible. Hopefully, we can make
 everyone happy. For those newly created bugs during/after migration, don't
 worry we will disallow further create new bugs/bps and do a second migrate
 so we won't missed yours.

 [1] https://storyboard.openstack.org/
 [2] https://storyboard.openstack.org/#!/project_group/82
 [3] https://docs.openstack.org/infra/manual/developers.html#
 development-workflow
 [4] https://storyboard.openstack.org/#!/project/989
 [5] https://docs.openstack.org/infra/storyboard/migration.html
 [6]