| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-16 | |||
| 01:01:03 | mriedem | also, i think i'm *this* close to getting this functional test to pass | |
| 01:01:10 | mriedem | fixtures up the wazoo | |
| 01:06:08 | mriedem | melwitt: i also went with your idea to stub out Claim.__init__, that was a good idea | |
| 01:08:56 | mriedem | oh f yes it works now | |
| 01:20:03 | mriedem | here it comes | |
| 01:20:19 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add populate_retry to schedule_and_build_instances https://review.openstack.org/444106 | |
| 01:20:20 | openstack | bug 1671648 in OpenStack Compute (nova) "Instances are not rescheduled after deploy fails" [High,In progress] https://launchpad.net/bugs/1671648 - Assigned to Shunli Zhou (shunliz) | |
| 01:20:20 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add a functional regression/recreate test for bug 1671648 https://review.openstack.org/446209 | |
| 01:41:26 | openstackgerrit | Ken'ichi Ohmichi proposed openstack/nova master: Clarify os-start API description https://review.openstack.org/446264 | |
| 03:25:26 | openstackgerrit | Wang Shilong proposed openstack/nova master: Lustre support https://review.openstack.org/446288 | |
| 04:34:18 | openstackgerrit | Maho Koshiya proposed openstack/nova master: Add confirm resized server functional negative tests https://review.openstack.org/421074 | |
| 05:29:40 | jith | Hi all, I have configured openstack kilo setup in debian jessie with one controller node and two compute nodes. I have used glusterfs for shared storage. I have mounted the shared storage in /var/lib/nova/instances on both nodes. I can do migration of vm’s between nodes.. But live-migration throws following error.. Pls do guide me.. http://pastebin.com/DHPWEkaZ | |
| 05:56:24 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova master: Permit Live Migration of Rescued Instances https://review.openstack.org/308198 | |
| 06:49:02 | jith | Hi all, I have configured openstack kilo setup in debian jessie with one controller node and two compute nodes. I have used glusterfs for shared storage. I have mounted the shared storage in /var/lib/nova/instances on both nodes. I can do migration of vm’s between nodes.. But live-migration throws following error.. Pls do guide me.. http://pastebin.com/DHPWEkaZ | |
| 06:55:55 | openstackgerrit | lcsong proposed openstack/nova master: Modify some grammatical mistakes. https://review.openstack.org/446321 | |
| 07:05:17 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova master: API changes for live migration of rescued instance https://review.openstack.org/328280 | |
| 07:13:36 | alexey_weyl | Hi, I have a small question about the availability zone. | |
| 07:14:53 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova master: Port binding based on events during live migration https://review.openstack.org/434870 | |
| 07:14:59 | alexey_weyl | When I change the name or the availability zone itself in the host aggregates I don't receive an update event on the oslo bus. Is nove supposed to send such an event? | |
| 07:15:09 | alexey_weyl | *nove=nova | |
| 07:36:23 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova-specs master: Live Migration of Rescued Instances https://review.openstack.org/347161 | |
| 07:41:47 | openstackgerrit | Mikhail Feoktistov proposed openstack/nova master: Add is_vz_container function https://review.openstack.org/445947 | |
| 07:55:40 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova-specs master: Live Migration of Rescued Instances https://review.openstack.org/347161 | |
| 07:58:37 | nirendra | Nova evacuate on Ocata is failing. Is there any known bug corresponding to this or a workaround | |
| 08:10:11 | gmann | alex_xu: hi | |
| 08:10:53 | alex_xu | gmann: hi | |
| 08:11:20 | gmann | alex_xu: show_extensions seems to enforce all extension discovery policy - https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/extension_info.py#L285 | |
| 08:11:40 | gmann | alex_xu: instead of asked extension discovery policy only | |
| 08:12:14 | gmann | self._get_extensions(context) is being called in show and it checks all extension discovery policy | |
| 08:13:00 | alexey_weyl | Hi, I wanted to ask please why there is no id for the availability-zone? | |
| 08:13:54 | alex_xu | gmann: emm...looks like yes | |
| 08:14:30 | alex_xu | gmann: but it works correctly? | |
| 08:15:55 | gmann | alex_xu: because of fatal=False on L226 right? | |
| 08:16:42 | gmann | if anyone disabled other extension on policy discovery then it would not affect of getting asked extension right? | |
| 08:17:16 | alex_xu | gmann: yes | |
| 08:18:20 | gmann | alex_xu: yea, actually it came up on https://review.openstack.org/#/c/431740/4 i am not sure why they cannot use show_extension for all, let me check with author | |
| 08:20:07 | Kevin_Zheng | ping gibi | |
| 08:20:44 | alexey_weyl | can anyone please help me | |
| 08:20:50 | alexey_weyl | I wanted to ask please why there is no id for the availability-zone? | |
| 08:21:43 | alex_xu | gmann: emm....strange | |
| 08:22:48 | gmann | alex_xu: yea from user point of view show_extension will be same, its only internal implementation which does extra checks on policies | |
| 08:24:06 | gmann | alexey_weyl: for AZ we have only name | |
| 08:24:12 | alex_xu | gmann: but the discovery policy is something we deprecated? | |
| 08:24:21 | alex_xu | why people still depend on it | |
| 08:24:46 | gmann | alexey_weyl: i mean its always different name so id not needed | |
| 08:25:32 | gmann | alex_xu: you mean extensions right or discovery policy also we deprecated ? | |
| 08:27:48 | bauzas | good morning Nova | |
| 08:28:03 | alex_xu | gmann: i think the discovery policy | |
| 08:28:33 | alex_xu | gmann: https://review.openstack.org/#/c/427872/ johnthetubaguy propose to remove in it in that spec | |
| 08:28:53 | alex_xu | gmann: not suer whether we have note to say it already deprecated | |
| 08:29:30 | gmann | alex_xu: yea, i was thinking the same. i think we do not have as there was no good way to deprecate policy... | |
| 08:29:45 | openstackgerrit | jichenjc proposed openstack/nova master: Prevent delete cell0 in nova-manage command https://review.openstack.org/433476 | |
| 08:29:56 | alexey_weyl | gmann: that is correct, but if i change the name of the availability zone then vitrage don't know of which zone it was originally | |
| 08:30:46 | alexey_weyl | gmann: meanning, Vitrage don't know what zone was changed, because the previous name doesn't appear. | |
| 08:30:48 | alex_xu | gmann: not like config opt | |
| 08:34:11 | gmann | alex_xu: yea | |
| 08:34:51 | gmann | alexey_weyl: humm, yea name change, changes the AZ completely | |
| 08:35:47 | alexey_weyl | gmann: so how can Vitrage know which availability zone was changed besides storing a cache of all of the different availability zones? | |
| 08:35:52 | gmann | alexey_weyl: but you can get the old AZ from GET server | |
| 08:36:39 | gmann | alexey_weyl: i mean servers booted with AZ will be having the same | |
| 08:39:30 | alexey_weyl | gmann: do you think I can open a bug that we would like the availability zone to have an ID? | |
| 08:40:30 | alexey_weyl | gmann: but still when Vitrage is doing get all availability zones it won't know what AZ was changed. | |
| 08:40:33 | openstackgerrit | Béla Vancsics proposed openstack/nova master: Reduce code complexity - libvirt/config.py https://review.openstack.org/359879 | |
| 08:40:53 | bauzas | FWIW, I'm personnally opposed to accept the AZ changing its name unless there are no left instances in there | |
| 08:41:03 | bauzas | it's a source of confusion | |
| 08:41:27 | gmann | bauzas: yea me too, alexey_weyl is it much required use case? | |
| 08:41:36 | bauzas | creating an AZ is possibly one of the most important things to make sure | |
| 08:42:05 | bauzas | for example, you can default instances to have an AZ by modifying the config to name the default AZ | |
| 08:42:21 | gmann | AZ is something managed with name so changing name is all if you do not want to deal with old one | |
| 08:42:39 | bauzas | it's also an end-user UX | |
| 08:42:46 | bauzas | meaning that users see the AZs | |
| 08:42:57 | gmann | yea | |
| 08:43:07 | bauzas | when you want to modify a name, then you trample all your users | |
| 08:45:42 | alexey_weyl | bauzas: But shouldn't the AZs have and ID. like for every entity in the Database, that its properties are changed, so we will know whos data was changed by the ID. | |
| 08:46:14 | alexey_weyl | bauzas: gmann: another question, how can I receive update events of the AZ on oslo messaging bus? | |
| 08:46:19 | bauzas | alexey_weyl: AZs are just an aggregate metadata | |
| 08:46:51 | bauzas | alexey_weyl: it's not a nova specific object, neither persisted like you think | |
| 08:47:47 | alexey_weyl | bauzas: Let me explain to you our use case in Vitrage, and lets see what can be done. | |
| 08:49:24 | alexey_weyl | bauzas: In Vitrage we have many entities of different projects in Openstack and physical entities as well that Vitrage monitors and shows to the user and to the system as well so all the alarms and the root cause alarms in the system can be shown. | |
| 08:50:04 | alexey_weyl | bauzas: Thus, when a user changes the AZ name, it needs to be reflected in the Vitrage entity graph that has the AZ vertex in it. | |
| 08:50:40 | openstackgerrit | Béla Vancsics proposed openstack/nova master: Reduce code complexity - libvirt/config.py https://review.openstack.org/359879 | |
| 08:50:46 | alexey_weyl | bauzas: When vitrage receive the updated data from nova about the AZs in nova it doesn't know which AZ was changed or deleted or what has happened. | |
| 08:51:10 | alexey_weyl | bauzas: Thus if the AZ will have and ID Vitrage will know what AZ was changed or deleted. | |
| 08:51:24 | bauzas | alexey_weyl: I'm personnally in favor of not accepting to change the AZ if there are already some instances | |
| 08:51:45 | bauzas | I could write a spec | |
| 08:52:20 | bauzas | so it would mean a behavioural change, but post that microversion, it shouldn't be possible to change an AZ name | |
| 08:52:46 | alexey_weyl | bauzas: Does it sound as a reasonable use case from your side? | |
| 08:53:25 | alexey_weyl | bauzas: didn't quite understoud your last sentence. | |
| 08:54:30 | bauzas | alexey_weyl: lemme rephrase | |
| 08:55:02 | bauzas | alexey_weyl: since the AZ information is just an aggregate metadata that is user-facing, we already have the ID you need | |
| 08:55:19 | gmann | alexey_weyl: "when a user changes the AZ name" user you mean admin/operator right | |
| 08:55:27 | bauzas | changing that metadata value for that specific key is source of confusion, so I'm not in favor of accepting that | |
| 08:55:29 | alexey_weyl | bauzas: of course | |
| 08:55:54 | alexey_weyl | bauzas: so, you have that id already? can we get from somewhere? | |
| 08:56:08 | bauzas | it's just an aggregate... | |
| 08:59:13 | alexey_weyl | bauzas: don't quite understand. what can I do? | |
| 09:00:13 | bauzas | alexey_weyl: do you know https://docs.openstack.org/developer/nova/aggregates.html#availability-zones-azs ? | |
| 09:00:20 | gmann | alexey_weyl: we have id for aggregate not for AZ | |
| 09:01:41 | alexey_weyl | gmann: I am familiar with the ID in the aggregate host. | |
| 09:02:25 | bauzas | alexey_weyl: https://developer.openstack.org/api-ref/compute/?expanded=show-aggregate-details-detail tells you that availability_zone is just a specific metadata key for an aggregate | |