Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-06-22
22:10:09 dansmith agreed
22:10:17 dansmith if not this, then the api needs more checks
22:11:19 sean-k-mooney making image copy admin only would be strange as the other import methods are not and i think it would be the same policy endpoint?
22:12:17 dansmith well, it's a different case I think
22:12:32 dansmith the other import methods are for actually importing the image
22:12:41 dansmith this import being used for copy is a little bit weird,
22:13:08 dansmith because for the others, you wouldn't have one person create the image and another provide its data generally,
22:13:10 dansmith but that's a little bit of what this is,
22:13:19 dansmith but since it's controlled enough I would think that allowing one user that can use an image to copy it to another store in the system is fine,
22:13:30 dansmith just like I said.. I could download and re-upload it myself to get the same effect
22:13:40 sean-k-mooney i mean by extening the import workflow to me i think that implies that they are treating glance as just another data source like a url or file
22:13:44 dansmith and of course, if we want to limit some users from being able to do this, we need a more fine-grained policy knobv
22:13:56 dansmith correct,
22:14:25 dansmith but for the other import mechanisms, you wouldn't want a non-admin-or-owner to be able to do the import from-url or whatever
22:14:37 dansmith which maybe means we should only do this admin context thing if we're doing copy-to-store, I dunno
22:14:42 dansmith but I'll let them opine
22:14:55 sean-k-mooney dansmith: well not for an image they can see but not own
22:15:58 sean-k-mooney if i was to redsign this i would be tempted to invert the workflow and make the copy part of get
22:16:35 sean-k-mooney e.g. if i try to get an image form a store where it is not currently present have it be copied on the backend in paralle to streaming it to the user
22:17:01 dansmith personally I think that this should be a PUT /images/foo {'stores': ['new-store', 'existing-store']
22:17:25 dansmith I think they had a task-based approach to image importing so they put this in there since it was the minimal amount of work
22:17:36 dansmith and this is what you get by bending one thing to do another
22:17:41 sean-k-mooney as in an image action
22:18:14 sean-k-mooney or create a new image form 'existing-store'
22:18:18 dansmith the move-on-demand streaming thing fundamentally won't work for the rbd case, which is the primary reason for this :)
22:18:42 sean-k-mooney dansmith: are there billing implication to this by the way
22:18:51 dansmith create a new image just creates an explosion for no reason.. we _want_ this to be the same image with multiple locations, else we lose the affinity
22:18:58 openstackgerrit Ghanshyam Mann proposed openstack/nova stable/stein: Make greande jobs n-v for EM and oldest stable https://review.opendev.org/737332
22:18:58 dansmith dunno
22:19:02 sean-k-mooney if you upload an image as public and i imported are you billed more?
22:19:25 dansmith no idea
22:19:27 sean-k-mooney i guess normal users cant upload public images
22:19:40 sean-k-mooney the can uplload shared images but public i think is admin only
22:21:01 sean-k-mooney ya at least on my kolla install my non admin account can only select private shared or community
22:21:17 sean-k-mooney public visablity is only avaiable in the admin role
22:21:48 sean-k-mooney im not really sure what the difference is between shared, comunity and public
22:22:50 sean-k-mooney ah https://wiki.openstack.org/wiki/Glance-v2-community-image-visibility-design#Visibility_Semantics
22:23:18 gmann melwitt: i am trying to test the stable gate(stein) with the fix on legacy base job, let's see if that fix the things - https://review.opendev.org/#/c/737332/3
22:24:44 gmann problem is that, neither devstack nor devstack-gate install virtualenv on subnode
22:24:56 sean-k-mooney gmann: that was recently changed
22:25:48 gmann since last week it is failing, devstack stable branch and neutron-grenade jobs are fixed but we have nova multinode jobs legacy one
22:25:51 sean-k-mooney http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015204.html
22:26:07 gmann sean-k-mooney: yeah, image update
22:26:59 sean-k-mooney didnt infra plan to fix all jobs
22:27:13 sean-k-mooney they had planned to propose patches to the base jobs
22:27:27 gmann :), no. legacy jobs are always less priority to fix.
22:27:58 melwitt gmann: cool thanks, I'll keep an eye on it
22:27:59 gmann zuulv3 native are easy to fix and add those roles wherever needed. like ensure-tox etc
22:33:51 gmann sean-k-mooney: and it depends on failure too, like 'tox not found' failure due to image updates needs to be fixed on wherever needed not in base job - #3 in this http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015559.html
22:34:10 gmann tox issue also started happening in neutron, horizon, and few more repo
22:34:39 gmann so we discussed not to fix in devstack base job instead on failure side.
22:35:33 sean-k-mooney ya the whitebox-tempest-plugin job also broke but we fixed it
22:35:53 sean-k-mooney that is zuulv3 so we just added ensure-pip
22:36:02 gmann putting everything in base job can overload the jobs who does not need these tools.
22:36:49 sean-k-mooney gmann: our issue with whitebox was our pre playboox uses pip before devstack runs and installs pip
22:37:11 sean-k-mooney so we just added ensure-pip
22:37:11 gmann ok
22:37:14 sean-k-mooney easy fix
22:39:55 gmann for xenial node ensure-vitualenv does ensure-pip also but for bionic yes we need to it in start - https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-virtualenv/tasks/Debian.yaml#L9
#openstack-nova - 2020-06-23
00:47:44 openstackgerrit Merged openstack/nova stable/train: Check cherry-pick hashes in pep8 tox target https://review.opendev.org/737279
00:57:58 openstackgerrit Ghanshyam Mann proposed openstack/nova stable/train: DNM: testing virtualenv not found fix https://review.opendev.org/737400
07:07:52 openstackgerrit Wenping Song proposed openstack/nova master: Delete resource provider in tree by top-down traversable order https://review.opendev.org/719163
07:25:47 openstackgerrit Wenping Song proposed openstack/nova master: Delete resource provider in tree by top-down traversable order https://review.opendev.org/719163
08:31:54 jcath hello,friends, how I can attach a volume to an exist instance as an ide disk/cdrom? whatever you set hw_disk_bus/hw_cdrom_bus in the image metadata, it does not work
09:34:11 openstackgerrit Hervé Beraud proposed openstack/nova master: Remove elementtree deprecated methods https://review.opendev.org/737472
10:48:14 nightmare_unreal a quick question can a cell have multiple compute nodes ?
11:06:44 gibi nightmare_unreal: yes a cell is a set of computes that has its own cell conductor, a cell db, and a cell message bus
11:07:59 nightmare_unreal thanks gibi , I forgot some stuff/terms
11:18:48 gibi stephenfin: I have a question in https://review.opendev.org/#/c/737026/
11:22:18 stephenfin gibi: I'll trade https://review.opendev.org/#/c/736964/6
11:23:04 gibi stephenfin: thanks
11:30:18 openstackgerrit Hervé Beraud proposed openstack/nova master: Remove lxml deprecated methods https://review.opendev.org/737472
11:47:37 nightmare_unreal how can i get list of all compute nodes in a cell ?
11:59:32 gibi nightmare_unreal: nova-manage cell_v2 list_hosts
12:01:01 nightmare_unreal Yeah found it . I am now looking to do it programatically is nova-manage part of python-novaclient ?
12:08:51 gibi nightmare_unreal: no. the cell is a deployment level thing, it is not exposed via the REST API
12:09:35 nightmare_unreal Ah, okay !!
12:14:52 openstackgerrit Balazs Gibizer proposed openstack/nova master: Prevent libvirt driver to start on non Linux platform https://review.opendev.org/737508
12:15:05 gibi stephenfin: ^^
12:16:25 openstackgerrit Dirk Mueller proposed openstack/nova master: Switch from unittest2 compat methods to Python 3.x methods https://review.opendev.org/737511
12:25:25 gibi stephenfin: responeded in https://review.opendev.org/#/c/736964 I don't get your comment about st_blocks
13:01:57 stephenfin gibi: Ah, ignore me: momentary lapse
13:07:51 gibi stephenfin: no worries. Thanks for reviewing
14:07:41 aarents dansmith: Let me know if those changes are ok: https://review.opendev.org/#/c/736169/ https://review.opendev.org/#/c/734776/
14:14:53 openstackgerrit Dan Smith proposed openstack/nova master: DNM: Try to make a glance multistore job https://review.opendev.org/734184
14:25:56 dansmith aarents: looks like it from a high level.. will try to get back to those today if I can
14:27:19 aarents dansmith: thks
14:35:14 sean-k-mooney dansmith: so based on https://review.opendev.org/#/c/737548/
14:35:30 sean-k-mooney dansmith: are we only going to then copy the image if we own it
14:35:45 sean-k-mooney or do you intned to have nova fall back to admin credetials
14:35:56 dansmith we're only going to be allowed to copy it if we own it at the moment, and we should not copy it with admin credentials
14:36:03 dansmith so basically, much less useful
14:36:16 sean-k-mooney ya that is what i was worreid about
14:36:26 sean-k-mooney but it also makes sense
14:36:32 dansmith the argument is that the owner of the image, despite being viewable, is "charged" to the owner for each location
14:36:39 dansmith although there isn't a resource usage report to convey this
14:36:49 sean-k-mooney yep
14:36:54 dansmith it seems to me that if an image is made public, charging the owner for it doesn't make much sense,
14:37:01 sean-k-mooney that is what i was wondering yesterday re billing
14:37:21 sean-k-mooney dansmith: the image can only be public if you are an admi

Earlier   Later