| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-24 | |||
| 21:16:36 | efried | ++ | |
| 21:42:47 | tonyb | sean-k-mooney: We needed to do it in requirements in order to *generate* constraints | |
| 21:45:04 | tonyb | sean-k-mooney: You say it's breaking the requirements-check job but I don't see that | |
| 21:45:37 | tonyb | sean-k-mooney: Given our, lack, of TZ overlap might be best to do this via email? | |
| 21:45:53 | sean-k-mooney | im here | |
| 21:46:14 | sean-k-mooney | we do not generate constratis to project anymore | |
| 21:46:23 | sean-k-mooney | at least the lower constratits | |
| 21:47:21 | sean-k-mooney | the reason i say i breaks the requirement check is https://review.opendev.org/#/c/666651/2/doc/requirements.txt | |
| 21:47:56 | sean-k-mooney | simply addint a comment or otherwise modifying the requiremetns file cause the requirements-check job to fail | |
| 21:48:42 | sean-k-mooney | we can see the error here | |
| 21:48:45 | sean-k-mooney | http://logs.openstack.org/51/666651/2/check/requirements-check/c8c82c5/job-output.txt.gz#_2019-06-20_17_39_08_901350 | |
| 21:48:49 | sean-k-mooney | tonyb: ^ | |
| 21:48:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add placement request filter for disabled computes https://review.opendev.org/654596 | |
| 21:49:09 | tonyb | sean-k-mooney: okay so there are a couple of things | |
| 21:49:53 | tonyb | sean-k-mooney: the requirements team needs to generate constraints (upper) daily and without capping sphinx (and others) in g-r we can't do that | |
| 21:50:32 | sean-k-mooney | ah so when you said generate you ment upper-constraitns not requirement files for projects | |
| 21:50:48 | tonyb | sean-k-mooney: and also the 'fix' to that error is to just merge the chnage that caps sphinx, which is the expected process albeit a little ugly now that we don't auto-sync | |
| 21:51:08 | tonyb | sean-k-mooney: correct | |
| 21:51:30 | sean-k-mooney | yes we have a patch for that but my understdaint is project are not ment to cap any package in ther own reqiuremets file | |
| 21:51:57 | sean-k-mooney | the can balcklis tthing the know do not work but if cap we can break compatiobliy for the intergrated services | |
| 21:52:07 | tonyb | sean-k-mooney: In general we try very hard not to cap in g-r or per project but it isn't "forbidden" | |
| 21:52:25 | tonyb | sean-k-mooney: and with this whole no more py2 support thing we don't have a choice | |
| 21:52:53 | sean-k-mooney | well that is due to useing gloabl-requiremtns for two thing | |
| 21:53:13 | sean-k-mooney | generatihing upper-constratints and capping python2 things | |
| 21:53:36 | tonyb | sean-k-mooney: and listing "approved libraries" so that's 3 things | |
| 21:53:42 | sean-k-mooney | well no it because we use it for generating uppercontratitgs | |
| 21:53:48 | sean-k-mooney | ya | |
| 21:54:14 | sean-k-mooney | so the last point is what i thought its priamary pourpous was | |
| 21:54:35 | sean-k-mooney | listing the appoved libs that wee know are compatiable and are manged by the requiremetns project | |
| 21:54:51 | tonyb | sean-k-mooney: I'm interested in your statement "if cap we can break compatiobliy for the intergrated services" can you elaborate? | |
| 21:55:33 | sean-k-mooney | os-vif say mock < X some other poject requires mock > x | |
| 21:55:48 | sean-k-mooney | os-vif and that service can nolonger be installed together | |
| 21:56:10 | tonyb | sean-k-mooney: ahhh okay .... that's handled in the generate-constraints job so it *shouldn't* be possible | |
| 21:56:34 | tonyb | sean-k-mooney: for *upper* constraints for lower all bets are off | |
| 21:56:37 | sean-k-mooney | can you explain breifly how upper-constratis is generated | |
| 21:56:59 | sean-k-mooney | i.e. how is gr used for uc | |
| 21:57:14 | tonyb | sean-k-mooney: basically we pip install -r global-requirements.txt and "freeze" the output | |
| 21:57:18 | sean-k-mooney | i was not aware uc was generated for gr | |
| 21:57:34 | sean-k-mooney | i though uc was manually updated as needed | |
| 21:57:57 | sean-k-mooney | rathar then auto updating as upstream releases? | |
| 21:58:03 | sean-k-mooney | i guess that is not the case? | |
| 21:58:16 | tonyb | for master it's a daily update and then "fixed" if needed, for stable it's all manual | |
| 21:58:39 | sean-k-mooney | ah ok so master allows latest unless we know somthing is broken | |
| 21:58:53 | sean-k-mooney | is gr used to pin things that are broken in that case ? | |
| 21:58:59 | tonyb | https://review.opendev.org/#/c/666981/ was last night's auto generate | |
| 21:59:33 | tonyb | sean-k-mooney: Yes, if lib $foo has a broken version we add a != in g-r to avoid it | |
| 21:59:47 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Libvirt: add vPMU spec for train https://review.opendev.org/651269 | |
| 22:00:22 | sean-k-mooney | and we are now using sphinx < 2.0 as a shorthad to cover all the non py27 versions | |
| 22:01:45 | sean-k-mooney | ok i can approve https://review.opendev.org/#/c/666387/ but its kind of regretable that we will have to modify requirement every time gr is modifed to reflect a new cap. | |
| 22:02:08 | sean-k-mooney | if the cap was only done via upper-constratits then it would just automaticlly work | |
| 22:02:19 | tonyb | sean-k-mooney: Yes, we've always needed to do that but it's just more obvious now | |
| 22:02:35 | tonyb | sean-k-mooney: I agre it's ugly but we can't think of a better way with the tools we have | |
| 22:02:45 | sean-k-mooney | nova os-vif and other project that generate docs form code need to use uc to pin to compatible verions anyway otherwise they can fail | |
| 22:03:13 | tonyb | sean-k-mooney: correct | |
| 22:03:45 | tonyb | sean-k-mooney: gotta disappear I'll be back in a bit | |
| 22:04:27 | sean-k-mooney | hehe im going to drop too. i was playing games on my desktop but its late enough now that i should praobbly call it a day o/ | |
| 22:04:40 | sean-k-mooney | tonyb: thanks for explainin | |
| 22:05:33 | sean-k-mooney | i had taken the view that capping in requiremetn in repo was nolonger allowed but ill adjust to allowing it if it is capped that way in gr going forward | |
| 22:27:09 | tonyb | sean-k-mooney: we (the requirements team) clearly need better reference docs or a FAQ or something | |
| 22:47:14 | openstackgerrit | Merged openstack/nova master: bdm: store empty object as connection_info by default https://review.opendev.org/645352 | |
| #openstack-nova - 2019-06-25 | |||
| 00:04:29 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Add a guide to add a new microversion support https://review.opendev.org/667002 | |
| 00:07:45 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Support for changing deleted_on_termination after boot https://review.opendev.org/580336 | |
| 00:08:08 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Support delete_on_termination in volume attach api https://review.opendev.org/612949 | |
| 01:12:52 | openstackgerrit | Alex Xu proposed openstack/nova master: Correct the comment of RequestSpec's network_metadata https://review.opendev.org/667061 | |
| 03:40:46 | openstackgerrit | huichen proposed openstack/nova master: Support pagination for sever groups by sql https://review.opendev.org/667259 | |
| 05:50:52 | cf__ | Hi! I asked in cinder channel yesterday regarding delete_on_termination and they pointed me towards nova, which make sense, however, when I do nova show <uuid>, I do not receive any information about delete_on_termination, even that I did set it when creating the instance.. What am I doing wrong, to check if the volume is going to be deleted on instance termnination? | |
| 05:56:29 | cf__ | $ nova show 83fcdb58-045a-4475-b4eb-5b9287daebcc |grep volume | |
| 05:56:30 | cf__ | | os-extended-volumes:volumes_attached | [{"id": "f3e192b6-f8b0-4a9b-8512-4e7ffa37756d"}] | |
| 06:05:31 | brinzhang__ | cf__: What about your volume? root disk? or data disk ? | |
| 06:06:05 | cf__ | brinzhang__: it's my root disk | |
| 06:06:22 | brinzhang__ | cf__: If it's a root disk, you can see the delete_on_termination from 'nova show server_id' | |
| 06:06:39 | brinzhang__ | [root@localhost ~]# nova show ec939a46-9e1e-4126-8214-6ceb3b95676a |grep volume | |
| 06:06:39 | brinzhang__ | | image | Attempt to boot from volume - no image supplied | | |
| 06:06:39 | brinzhang__ | | os-extended-volumes:volumes_attached | [{"id": "df191675-0ac1-4101-a590-7ad2f7607e89", "delete_on_termination": true}] | | |
| 06:07:27 | cf__ | The thing is, the person that started a bunch of instances did it with config_drive enabled which is kinda destroying the idea of a flexible environment, by making it extremely hard to live migrate running instances | |
| 06:08:48 | cf__ | Yeah, that's what i'm trying to find, however as pasted above, it dosnt show.. This is a test instance I made with delete_on_termination true, but I wanted to check if I was able to see it anywhere because for my production instances, i cannot risk to lose my volumes when i'm forced to delete the running instances and create new ones with the existing volumes in order to get rid of config_drive | |
| 06:10:04 | cf__ | for a random production instance i get: | |
| 06:10:04 | cf__ | stack@j3499-cp1-c1-m1-mgmt:~$ nova show f0c664e6-f161-41ac-93bd-cc2500644583 |grep volume | |
| 06:10:05 | cf__ | | image | Attempt to boot from volume - no image supplied | | |
| 06:10:05 | cf__ | | os-extended-volumes:volumes_attached | [{"id": "d86ea1ef-1b31-435d-8d3c-f106b61501ec"}, {"id": "d6fc7a5b-2cc0-4764-9a47-8cc89a609e0f"}, {"id": "9ff316b7-ff6d-4f63-a3fe-97dde0ba8803"}] | | |
| 06:11:08 | cf__ | ofcause this one, I do not know if delete_on_termination was set uppon creation - however it is on the first one I pasted, which was made only to check if I was able to find the info about delete_on_termination | |
| 06:12:01 | brinzhang__ | cf__: I think you can check it in block_device_mapping table, is that the delete_on_termination was set? | |
| 06:12:35 | cf__ | brinzhang__: so check the database? or is there a way to check it from cli? | |
| 06:13:14 | brinzhang__ | Because there is no scene for you, you can’t be sure that the problem exists. | |
| 06:13:45 | cf__ | Yeah, i just want to make sure not to lose data when I delete the running instances :) | |
| 06:15:40 | brinzhang__ | Currently, the delete_on_termination can only set when the server boot, there are two specs want to support config and reconfig that change, but not start working ... | |
| 06:16:39 | cf__ | It make sense.. maybe I should just create some backup before testing this :P | |
| 06:17:46 | brinzhang__ | Thanks, you can try test this, and report a but on launchpad https://bugs.launchpad.net/nova | |
| 06:18:16 | brinzhang__ | If ensure that issue exist :P | |
| 06:19:01 | cf__ | Will do, thanks :) | |
| 06:19:44 | cf__ | Oh btw, it's worth mentioning that this is a rather old instance of openstack since we're currently running Newton, but I guess that shouldnt do much of a difference | |
| 06:24:49 | brinzhang__ | Oh.. good luck. | |
| 06:33:14 | openstackgerrit | Yongli He proposed openstack/nova master: Clean up orphan instances virt driver https://review.opendev.org/648912 | |
| 06:33:15 | openstackgerrit | Yongli He proposed openstack/nova master: clean up orphan instances https://review.opendev.org/627765 | |
| 06:54:27 | cf__ | brinzhang__: I found it! Turns out that the easiest way was to check it in the nova database... | |
| 06:54:40 | cf__ | mysql> select delete_on_termination from block_device_mapping where instance_uuid = '83fcdb58-045a-4475-b4eb-5b9287daebcc'; | |
| 06:54:40 | cf__ | | delete_on_termination | | |
| 06:54:40 | cf__ | +-----------------------+ | |
| 06:54:40 | cf__ | | 1 | | |
| 06:54:41 | cf__ | +-----------------------+ | |