Re: [openstack-dev] StarlingX gap analysis to converge with OpenStack master
hi
just following up form yesterday.
i just finished testing the pci numa policy feature
and i can confirm that the prefer policy which allow use of non
local pci devices does not work.
the test case was relitively simple
1 host with 2 numa nodes
1 pci device attach to numa node 0
and vcpu pin set configured to allow only numa node 1
in this case booting a vm with a passthrough alias and a passthrough alias
fails.
[stack@cloud-3 devstack]$ openstack flavor show 42
++-+
| Field | Value
|
++-+
| OS-FLV-DISABLED:disabled | False
|
| OS-FLV-EXT-DATA:ephemeral | 0
|
| access_project_ids | None
|
| disk | 0
|
| id | 42
|
| name | m1.nano
|
| os-flavor-access:is_public | True
|
| properties | hw:numa_nodes='1',
pci_passthrough:alias='nic-pf:1' |
| ram| 64
|
| rxtx_factor| 1.0
|
| swap |
|
| vcpus | 1
|
++-+
passthrough_whitelist = { "address": ":01:00.1" }
alias = { "vendor_id":"8086", "product_id":"10c9", "device_type":"type-PF",
"name":"nic-pf", "numa_policy": "preferred"}
removeing the hw:numa_nodes='1' extra spec allow the vm to boot as it nolonger
has a numa topology.
the vm passes scheduling in both casess but when the vm has a virtual numa
toplogy of 1 node
we fail in the resocue tracker on the compute node when claiming resouces for
the instance.
i will submit a bug for this and repose the spec next week to track closing
this gap.
On Thu, 2018-11-22 at 03:20 +, Xu, Chenjie wrote:
> Hi Miguel,
> There is another RFE “Add l2pop support for floating IP resources” proposed
> to Launchpad. This RFE also comes from
> StarlingX and the link is below:
> https://bugs.launchpad.net/neutron/+bug/1803494
> Could you please help review this RFE? I think this RFE can be added to the
> gap analysis. What’s more, there is a bug
> and a RFE relating to l2pop and neutron-dynamic-routing is being written and
> is expected to be released next week.
>
> Best Regards,
> Xu, Chenjie
>
> From: Miguel Lavalle [mailto:mig...@mlavalle.com]
> Sent: Thursday, November 22, 2018 2:12 AM
> To: openstack-disc...@lists.openstack.org; OpenStack Development Mailing List
>
> Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack
> master
>
> Hi Stackers,
>
> One of the key goals of StarlingX during the current cycle is to converge
> with the OpenStack projects master branches.
> In order to accomplish this goal, the Technical Steering Committee put
> together a gap analysis that shows the specs
> and patches that need to merge in the different OpenStack projects by the end
> of Stein. The attached PDF document
> shows this analysis. Although other projects are involved, most of the work
> has to be done in Nova, Neutron and
> Horizon. Hopefully all the involved projects will help StarlingX achieve this
> important goal.
>
> It has to be noted that work is still on-going to refine this gap analysis,
> so there might be some updates to it in
> the near future.
>
> Best regards
>
> Miguel
__
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] I have some problems with Prometheus alarms in vitrage.
Hi, A deleted instance should be removed from Vitrage in one of two ways: 1. By reacting to a notification from Nova 2. If no notification is received, then after a while the instance vertex in Vitrage is considered "outdated" and is deleted Regarding #1, it is clear from your logs that you don't get notifications from Nova on the second compute. Do you have on one of your nodes, in addition to nova.conf, also a nova-cpu.conf? if so, please make the same change in this file: notification_topics = notifications,vitrage_notifications notification_driver = messagingv2 And please make sure to restart nova compute service on that node. Regarding #2, as a second-best solution, the instances should be deleted from the graph after not being updated for a while. I realized that we have a bug in this area and I will push a fix to gerrit later today. In the meantime, you can add to InstanceDriver class the following function: @staticmethod def should_delete_outdated_entities(): return True Let me know if it solved your problem, Ifat On Wed, Nov 21, 2018 at 1:50 PM Won wrote: > I attached four log files. > I collected the logs from about 17:14 to 17:42. I created an instance of > 'deltesting3' at 17:17. 7minutes later, at 17:24, the entity graph showed > the dentesting3 and vitrage colletor and graph logs are appeared. > When creating an instance in ubuntu server, it appears immediately in the > entity graph and logs, but when creating an instance in computer1 (multi > node), it appears about 5~10 minutes later. > I deleted an instance of 'deltesting3' around 17:26. > > >> After ~20minutes, there was only Apigateway. Does it make sense? did you >> delete the instances on ubuntu, in addition to deltesting? >> > > I only deleted 'deltesting'. After that, only the logs from 'apigateway' > and 'kube-master' were collected. But other instances were working well. I > don't know why only two instances are collected in the log. > NOV 19 In this log, 'agigateway' and 'kube-master' were continuously > collected in a short period of time, but other instances were sometimes > collected in long periods. > > In any case, I would expect to see the instances deleted from the graph at >> this stage, since they were not returned by get_all. >> Can you please send me the log of vitrage-graph at the same time (Nov 15, >> 16:35-17:10)? >> > > Information 'deldtesting3' that has already been deleted continues to be > collected in vitrage-graph.service. > > __ 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
