Earlier  
Posted Nick Remark
#openstack-nova - 2021-02-25
16:46:26 sean-k-mooney the issue here is its both
16:47:37 gibi OK then I don't have enough knowledge on the networking side of this.
16:48:04 gibi sean-k-mooney: ooh we have a nova policy for this
16:48:19 sean-k-mooney thats ok. external networks are network whose subnets are sued for floating ip and neutron router gateway ports
16:48:27 sean-k-mooney gibi: yes we do
16:48:39 sean-k-mooney i dont think neutron supported this when we added the policy
16:48:50 gibi so the admin when creates the external net for a tenant can give the tenant servers_policies.NETWORK_ATTACH_EXTERNAL rights in nova, and then it will work
16:49:23 sean-k-mooney via custom plolicy rules yes
16:50:01 gibi then it is a config issue on the admin side
16:50:11 gibi the admin only did half of the work to provide the access for the tenant
16:50:21 sean-k-mooney yep
16:50:36 sean-k-mooney the issue is we do not supprot custom policy in our product
16:50:37 gibi would that be a good answer for your BZ?
16:50:42 gibi aaah
16:50:43 gibi I see
16:50:50 sean-k-mooney so we are being asked is this policy valid anymore
16:50:54 sean-k-mooney and can it be removed
16:51:19 sean-k-mooney im trying to understand if there is a usecase for this now or should we allow neutron to enforce this
16:51:46 sean-k-mooney my concern is that the precednce around policy changes is to have a deprecation cylce
16:52:16 sean-k-mooney meaning we could only change or remove this in xena even if we deperacted its current value this cycle
16:52:56 sean-k-mooney we can support this for a customer explicty via a supprot excption downstream
16:53:18 sean-k-mooney im just not sure im comfortable changing the default downstream without fully understaind all the implication of that policy
16:57:12 gibi I don't have the networking background to decide on if having a tenant attaching to an external net is a valid use case
16:57:42 sean-k-mooney ya i think we are going to start a mailing list post on this topic
16:59:01 gibi good idea
17:11:23 sean-k-mooney gibi: thanks for looking by the way
17:11:31 gibi no problem
18:16:23 openstackgerrit Sylvain Bauza proposed openstack/nova master: WIP: Bump the Compute RPC API to version 6.0 https://review.opendev.org/c/openstack/nova/+/761452
18:16:55 bauzas oh f**** we just merged interface attach which conflicts with ^
18:17:06 bauzas I'm a sad panda
18:17:33 bauzas oh man, wait
18:20:57 openstackgerrit Sylvain Bauza proposed openstack/nova master: WIP: Bump the Compute RPC API to version 6.0 https://review.opendev.org/c/openstack/nova/+/761452
18:20:57 sean-k-mooney didnt that merge a few days ago
18:21:16 bauzas sean-k-mooney: yup, don't know why my local rebase didn't get it previously
18:21:28 bauzas anyway, just done
18:21:36 sean-k-mooney looks like you fixed it quickly in anycase
18:21:43 bauzas sean-k-mooney: and fwiw, I'll need to respin my work for your vDPA change
18:21:55 bauzas as I forgot we look at the service level
18:22:17 bauzas which is bumped everytime we provide a new object field
18:24:09 sean-k-mooney its not a new field
18:24:17 sean-k-mooney its a new value for an existing field
18:24:32 sean-k-mooney so object verion is bumpted but not service version right
18:24:43 sean-k-mooney either tat or i need to add a service version bump to that patch
18:25:00 bauzas ahha no, then
18:25:40 sean-k-mooney its a small change let me show you https://review.opendev.org/c/openstack/nova/+/777481
18:26:18 sean-k-mooney im trying to keep them small and self contianed
18:56:09 openstackgerrit Merged openstack/nova master: Fixes the elapsed time logged during a live migration https://review.opendev.org/c/openstack/nova/+/776428
20:38:45 openstackgerrit sean mooney proposed openstack/nova master: support per port numa policies with sriov https://review.opendev.org/c/openstack/nova/+/773792
21:06:11 openstackgerrit sean mooney proposed openstack/nova master: fix sr-iov support on Cavium ThunderX hosts. https://review.opendev.org/c/openstack/nova/+/777679
21:25:55 openstackgerrit sean mooney proposed openstack/nova master: fix sr-iov support on Cavium ThunderX hosts. https://review.opendev.org/c/openstack/nova/+/777679
21:26:13 openstackgerrit Ade Lee proposed openstack/nova master: Replace md5 for fips https://review.opendev.org/c/openstack/nova/+/777686
23:34:02 openstackgerrit Merged openstack/nova stable/pike: [placement] Add status and links fields to version document at / https://review.opendev.org/c/openstack/nova/+/751240
#openstack-nova - 2021-02-26
01:33:02 openstackgerrit Merged openstack/nova stable/ussuri: only wait for plugtime events in pre-live-migration https://review.opendev.org/c/openstack/nova/+/770745
07:58:44 openstackgerrit Yongli He proposed openstack/nova master: Smartnic support - cyborg drive https://review.opendev.org/c/openstack/nova/+/771362
07:58:45 openstackgerrit Yongli He proposed openstack/nova master: smartnic support - new vnic type https://review.opendev.org/c/openstack/nova/+/771363
07:58:46 openstackgerrit Yongli He proposed openstack/nova master: smartnic support https://review.opendev.org/c/openstack/nova/+/758944
08:13:04 yonglihe gibi: few test case may missing, but coming soon. thanks that comments.
08:26:04 gibi yonglihe: thanks
15:51:16 openstackgerrit Balazs Gibizer proposed openstack/nova stable/pike: Update resources once in update_available_resource https://review.opendev.org/c/openstack/nova/+/612295
17:05:47 gibi what a silent friday
17:06:45 gmann Recharge day...
17:09:04 gibi ohh that explanse a lot
20:11:15 atmark Hello, I have PCI passthrough configure in nova configs and also set an alias in the flavor but I'm getting this error when I create an instance
20:11:18 atmark Invalid PCI alias definition: [{'vendor_id': '1344', 'product_id': '51b2', 'device_type': 'type-PF', 'name': 'pf1'}] is not of type 'object'
20:11:37 atmark Here is my config http://paste.openstack.org/show/803047/
#openstack-nova - 2021-02-27
05:06:00 openstackgerrit Merged openstack/nova stable/ussuri: compute: Lock by instance.uuid lock during swap_volume https://review.opendev.org/c/openstack/nova/+/758732
16:04:14 legochen hey guys, I’m trying "Launch an instance from a volume”
16:04:22 legochen I refer to this doc - https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#server-create
16:04:52 legochen and found this option - “—boot-from-volume <volume-size>”
16:05:09 legochen As I have multiple volume types in my system.
16:05:46 legochen looks like it doesn’t support to specify which volume-type to create volume.
16:06:23 legochen the error shows - aborted: The request cannot be fulfilled as the default volume type cannot be found.
16:07:25 legochen could someone let me know how to specify volume-type in “openstack server create” command?
17:47:28 openstackgerrit Merged openstack/nova master: apidb: Compact Liberty database migrations https://review.opendev.org/c/openstack/nova/+/759399
19:05:47 legochen hmm, I think the option “—boot-from-volume <volume-size>” need to also support specifying “volume-type”? is that make sense?
19:06:56 legochen I thought I can use this way … --block-device-mapping vda=f8967165-3250-472e-bd25-aea938a38bb2:volume:80:false , but, it prompts me an error
19:06:59 legochen The volume cannot be assigned the same device name as the root device vda (HTTP 400) (Request-ID: req-7425e48b-0cb1-46ea-90eb-afd62086a431)
19:07:08 legochen :( no idea then.
19:08:25 legochen 1. create a volume first, 2. boot an instance with that volume, ex: --block-device source=volume,id=33ecc63a-ccc1-496b-ae9a-61babe615568,dest=volume,shutdown=preserve
19:08:44 legochen but, in openstack command, this is also not allowed
19:09:22 legochen hope someone can give some ideas about this :) thanks
#openstack-nova - 2021-02-28
19:40:06 grami[m] Hi all I'm struggling a little with trying to make a custom nova scheduler. The biggest problem is I want to get a count of running instances in the project. I have seen some people write in the whole keystone client sdk and have conf username and password but as this is already nova can this be done? could I import say nova.api.servers or something else
21:04:50 openstackgerrit Jessie Lass proposed openstack/nova master: Add emulation support if host arch != guest arch. https://review.opendev.org/c/openstack/nova/+/772156
21:33:17 legochen looks like ocata version OSC supports --block-device , but newer version doesn’t have that. https://docs.openstack.org/ocata/user-guide/cli-nova-launch-instance-from-volume.html
21:33:28 legochen can we still provide that option in new OSC?
21:52:47 legochen if someone familiar with “Launch an instance from a volume”, please ping me directly… thanks :)
21:53:06 legochen per the doc - https://docs.openstack.org/nova/latest/user/launch-instance-from-volume.html
21:54:01 legochen after some tests, I feel the behavior of “Boot an instance from an image and attach a non-bootable volume.” is most efficient way to do this?
21:54:27 legochen the behavior of “Create a volume from an image and boot an instance from that volume.” and “Boot from an existing source image, volume, or snapshot.” seems are similar.
21:55:49 legochen On the host that running cinder service will need to
21:55:55 legochen 1. download image to image_conversion_dir
21:56:15 legochen 2. create block volume and attach that host
21:56:43 legochen 3. create a bootable volume by that download image.
21:56:58 legochen 4. attach volume to host and boot.
21:59:26 legochen but, the behavior of “Boot an instance from an image and attach a non-bootable volume.” seems the same as create VM on hypervisor and use hypervisor local store.
21:59:49 legochen the image download process will happen on the hypervisor instead of the host that running cinder service.
#openstack-nova - 2021-03-01
02:58:59 openstackgerrit Xing Zhang proposed openstack/nova stable/train: replace the "hide_hypervisor_id" to "hw:hide_hypervisor_id" https://review.opendev.org/c/openstack/nova/+/768736
05:02:31 yonglihe atmark: the pci alias is not a list.
07:37:46 brinzhang gmann: are you around?
07:38:55 brinzhang gmann: I dont understand what are you point *'groups' data* in https://review.opendev.org/c/openstack/nova/+/766726/17/nova/tests/unit/api/openstack/compute/test_security_groups.py#1005

Earlier   Later