Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-07-27
16:57:15 bauzas melwitt: cool, will read tomorrow
16:57:42 melwitt thanks bauzas++
16:59:26 sean-k-mooney melwitt: bauzas this is a summary of my view on the WIP patch https://review.opendev.org/c/openstack/nova/+/688802/2#message-70a28bde99719c723c954c947d0af17227a344e9
17:00:00 melwitt thanks sean-k-mooney
17:00:13 sean-k-mooney melwitt: there are other reasonce lients can recive a 409 namely locked instances so we can go either way with it
17:00:28 melwitt I feel strongly that delete (by an end user) should never fail
17:00:46 melwitt internals can handle 409s if there is some reason to
17:00:47 sean-k-mooney right but the api contract is it must fail if the instance is locked
17:01:38 melwitt well, yeah, agree that is expected
17:01:42 melwitt that's the point (or one of the points) of locking
17:02:08 sean-k-mooney https://docs.openstack.org/api-ref/compute/?expanded=force-delete-server-forcedelete-action-detail#force-delete-server-forcedelete-action im kind of suprised force delete can also return a 409
17:02:43 melwitt yeah :\
17:02:48 sean-k-mooney force-delet i do expect to never fail
17:03:04 sean-k-mooney well 401/403/404 sire
17:03:07 sean-k-mooney *sure
17:03:10 sean-k-mooney but not 409
17:03:38 melwitt yeah
17:08:24 melwitt fyi there's a new spec proposed around migrating instances between projects that I had -2ed the implementation proposal as this majorly needs a spec https://review.opendev.org/c/openstack/nova-specs/+/802034
17:20:48 sean-k-mooney melwitt: oh i forgot to bring this up in the meeting
17:21:05 sean-k-mooney melwitt: bauzas how do you feel about approving/reviewing yoga specs now?
17:21:37 sean-k-mooney we normally wait untill around m3 but ^ and any other specs can be targeted again the yoga release now
17:21:43 sean-k-mooney we have the folder created
17:23:13 sean-k-mooney melwitt: and ya that needs a spec
17:23:36 melwitt I personally think review is welcome at any time. approval I think is natural post PTG at least but obviously it doesn't have to be
17:23:39 sean-k-mooney we sould also need support in every other serivce to move the ownership of the resouces
17:24:19 sean-k-mooney we have approved spec pre ptg before but mostly onse that missed the previous cycle
17:24:32 melwitt yeah. we've talked about it many times as we know, and some of the proposal were to only support the project move within nova and then let other tools call all the different projects' APIs
17:24:59 sean-k-mooney os-chown was the latest iteration of that right
17:25:34 sean-k-mooney https://github.com/kk7ds/oschown
17:26:03 sean-k-mooney i think there was a sepereate repo created form dansmith poc
17:26:19 melwitt yeah there is that and I didn't know about a separate repo
17:26:55 sean-k-mooney the only one i can find is os-migrate
17:27:02 sean-k-mooney but that is different
17:27:12 sean-k-mooney that is inter cloud migration
17:28:16 sean-k-mooney melwitt: so i think my issue with nova just doing the nova bits is we end up in a situration where for a time the ownser ship of each resouce is split between multipel porojects/users/domains
17:28:38 opendevreview Stephen Finucane proposed openstack/placement master: tests: Silence noisy tests https://review.opendev.org/c/openstack/placement/+/801101
17:28:39 opendevreview Stephen Finucane proposed openstack/placement master: tox: Remove psycopg2 warning filter https://review.opendev.org/c/openstack/placement/+/800911
17:28:39 opendevreview Stephen Finucane proposed openstack/placement master: setup: Replace dashes with underscores https://review.opendev.org/c/openstack/placement/+/801102
17:28:40 opendevreview Stephen Finucane proposed openstack/placement master: db: Replace implicit conversion of SELECT into FROM https://review.opendev.org/c/openstack/placement/+/800910
17:28:40 opendevreview Stephen Finucane proposed openstack/placement master: db: Replace 'as_scalar()' with 'scalar_subquery()' https://review.opendev.org/c/openstack/placement/+/801100
17:28:41 opendevreview Stephen Finucane proposed openstack/placement master: db: Update 'select()' calls https://review.opendev.org/c/openstack/placement/+/801103
17:28:41 opendevreview Stephen Finucane proposed openstack/placement master: db: Remove use of non-integer/slice indices https://review.opendev.org/c/openstack/placement/+/801104
17:28:42 opendevreview Stephen Finucane proposed openstack/placement master: db: Replace deprecated 'FromClause.select().whereclause' parameter https://review.opendev.org/c/openstack/placement/+/801105
17:28:42 opendevreview Stephen Finucane proposed openstack/placement master: db: Use explicit transactions https://review.opendev.org/c/openstack/placement/+/801106
17:28:44 opendevreview Stephen Finucane proposed openstack/placement master: db: Remove unnecessary use of '_mapping' https://review.opendev.org/c/openstack/placement/+/801107
17:28:44 opendevreview Stephen Finucane proposed openstack/placement master: tox: Enable SQLAlchemy 2.0 warnings https://review.opendev.org/c/openstack/placement/+/801108
17:29:16 sean-k-mooney for example what happens if you move the ownwer ship of the neutron port of cinder volumes first before the nova instance
17:29:30 sean-k-mooney if we created the port and volume and delete on terminate is set
17:29:36 sean-k-mooney then you delete the instance
17:29:47 melwitt yeah... I think that's why we've nacked it in the past. if we add something like that, it needs a big fat warning on it. and maybe a dragon icon
17:29:48 sean-k-mooney what do we do then
17:30:05 sean-k-mooney but dragons are cool
17:30:21 sean-k-mooney we should put a honey badger on it instead
17:30:24 melwitt "if you do this and it messes stuff up, you are on your own"
17:30:33 melwitt hehe
17:31:07 dansmith how about we only allow the transition if the instance is locked?
17:31:24 dansmith I don't remember how much lock really restricts, and we've probably not done a good job of honoring lock everywhere,
17:31:39 melwitt yeah true dragons might attract people to call the API
17:31:43 dansmith but it would at least be something procedural
17:31:49 sean-k-mooney dansmith: admin bypass lock by default apparently which is fun
17:32:11 dansmith sean-k-mooney: sure, but this change ownership call could ... not
17:32:19 sean-k-mooney dansmith: but i get your point we could take some of the rough edges off with lock
17:32:43 melwitt conceptually I think that's a good idea. require some kind of freezing of it before allowing project migration
17:32:45 dansmith if a compute rebooted in the middle or something I think you'd still get magic smoke
17:33:30 sean-k-mooney i assume this woudl ba an admin only api by default too
17:33:46 dansmith for sure
17:33:58 sean-k-mooney although a domain admin might have a usecase for it to not be
17:34:02 melwitt yes, haha I can't imagine it being open to normal users by default
17:34:26 sean-k-mooney melwitt: well not project member anyway or likely even project admin
17:34:45 sean-k-mooney but in new rbac world i coudl see domain_admin or system_admin having a use case for it
17:35:03 dansmith not project admin either, I wouldn't think
17:35:41 sean-k-mooney unless you did it liek cinder? i think it cinder that has a volume transfer api
17:35:52 sean-k-mooney that allows you to transfer volumes between tenatns
17:35:58 melwitt yeah that would seem weird to be able to move something into another project if you're not admin in that project. I guess if you were project admin in the source and destination projects?
17:36:02 sean-k-mooney that has a request and accpet model
17:36:13 dansmith well, if you did that, I guess you could also freeze all operations on the instance if it had a pending transfer,
17:36:16 dansmith which maybe would be good
17:36:17 dansmith I dunno
17:36:20 sean-k-mooney if i rememebr correct both side have to agree to the transfer
17:36:28 melwitt that sounds familiar
17:36:46 dansmith I dunno, I have a hard time ever seeing this being not fraught with pain
17:36:53 sean-k-mooney so i think the work flow is project a start the tansfer then project b acclets it
17:37:01 dansmith transferring a volume in isolation is a lot simpler than an instance with tentacles
17:37:11 sean-k-mooney yes true
17:37:51 sean-k-mooney but i like the idea of the transfering state as you said and potentally blocking all or most operation when its in that state
17:38:12 sean-k-mooney we might still want to supprot apport or delete
17:38:17 sean-k-mooney *abort
17:38:42 sean-k-mooney aborting and roling back though is anohter can of worms
17:38:54 dansmith yeah, for serious
17:40:07 sean-k-mooney so the current spec is for instance that dont have volumes only but honestly im not sure how useful it is at that point
17:40:36 dansmith well, you will always have a port, maybe more, so the problem is already bad without volumes
17:40:42 dansmith might as well include the volumes of course
17:40:48 sean-k-mooney also they are adding that stiplulation to avoid the cinder interaction but its still there for neutron and cyborg so really unless we have a solution for all the things im not sure i see the point
17:41:02 sean-k-mooney yep
17:41:02 dansmith what about backups? aren't those somehow linked to the instance?
17:41:14 sean-k-mooney hehe i was just thinking about snapshots in glance
17:41:34 sean-k-mooney which might be store in swift or cinder on the backend
17:41:37 melwitt +1 there are so many worms. but I'm not completely closed off to the idea if other people think it's worth the trouble
17:42:16 sean-k-mooney although i think the volumes / objecst are technialy onwed by glance in that case not the ownere of the image but still
17:42:23 dansmith correct

Earlier   Later