Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-24
15:20:29 efried yeah
15:20:56 jaypipes so, the "formula" would be just: {$PARENT_NAME}_{$CHILD_NAME}
15:21:08 efried well, since names have to be unique, that should work just fine.
15:21:09 jaypipes or whatever separator you wanted to use instead of _
15:21:37 efried So we have to establish the naming convention for $CHILD_NAME, which will be different for any given type of provider x hypervisor/virt
15:21:44 efried and document it
15:21:55 efried and then operators ought to be able to figure it out from there
15:21:56 efried if they need to
15:21:59 jaypipes efried: do we really though?
15:22:13 efried well, if we don't, then they have to do the two-step
15:22:28 efried ask placement, figure it out, use that to populate the file, which then gets used to update placement.
15:22:33 openstackgerrit Aditya Vaja proposed openstack/nova stable/queens: fix typo in IVS related privsep method https://review.openstack.org/604817
15:22:34 jaypipes efried: I mean if the "use case" is just for deployment tooling to be able to list the inventory for a compute node and its children, we already have the one heuristic that would be needed.
15:22:54 jaypipes efried: i.e. ansbile would always call `openstack provider inventory list $HYPERVISOR_HOSTNAME`
15:23:11 efried isn't there a chicken/egg though?
15:23:15 jaypipes efried: and to find the child providers it would be:
15:23:26 jaypipes `openstack provider list --in-tree $HYPERVISOR_HOSTNAME`
15:24:03 jaypipes efried: well, of course, there's not going to be any inventory or provider records until the nova-compute runs, but I don't think that's any different from today's landscape for ansible/deploy tools
15:24:23 efried it is
15:24:39 efried because in today's tooling, you can set cpu_allocation_ratio beforehand
15:25:08 jaypipes and?
15:25:26 efried Well, I don't know if we really care enough to feel it's worth the hoops of fire it would take to make this new world similarly configurable-before-deployment.
15:25:36 jaypipes what regarding the provider descriptor file format would prevent ansible from writing out an allocation ratio override for the compute node?
15:25:36 efried But if I'm understanding cdent's concern correctly, that was it.
15:26:01 efried oh, that's exactly the point. The allocation ratio for CPU may not *live* in the compute node provider.
15:26:07 efried It may live in the (multiple) NUMA node providers
15:26:29 efried which ansible would need a way to figure out how to identify before deployment, if we're wanting to keep this paradigm of pre-deployment configurability.
15:26:57 jaypipes efried: right, but we don't currently set any allocation ratio for NUMA node providers anywhere (certainly not in any config file)
15:27:10 efried NUMA is just an example.
15:27:16 efried and
15:27:27 efried we don't today, but might tomorrow
15:27:29 jaypipes efried: this is why I think setting data for inventory records using configuration files is silly.
15:27:48 efried you think it should be done by invoking placement after all the auto setup is done?
15:28:01 jaypipes as opposed to setting them en-masse after the records have been created.
15:28:07 jaypipes yes.
15:28:23 jaypipes but we have deployers who are insisting on the configuration files... soo....
15:28:27 efried I'd be cool with that. Requires a fundamental shift in the philosophy
15:34:03 efried basically each virt's update_provider_tree would have to agree to only muck with total and reserved.
15:34:21 efried which is not what we're doing today - today we overwrite everything.
15:34:34 efried but there's still the concern about how to set initial values.
15:34:54 efried The difficult part of that being how to tell that it's initial.
15:35:13 efried cdent suggested something about making use of the updated_at field.
15:36:23 efried bbar (that's "be back after reboot" - something's slowly eating up all my swap space)
15:40:31 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226
15:42:29 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226
15:43:22 efried belmoreira: did you get past your max_unit snafu from last week?
15:44:27 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226
15:46:36 belmoreira efried: we decided to not change it for now
15:47:10 efried belmoreira: Meaning you still can't deploy those flavors to those nodes?
15:48:42 belmoreira efried: correct. People with these flavors can't use them. We're informing the users for now and suggesting smaller flavors
15:48:50 efried okey
15:49:35 efried belmoreira: Have you crystallized any sense of how you'd ideally like to see this handled big-picture/long-term?
15:49:45 belmoreira efried: our main issue is that our compute nodes may be very overcommited (CPU) and for now is saffer to stop scheduling these large flavors
15:50:04 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226
15:52:40 belmoreira efried: last week I was debugging and we just realised the issue in the channel... I believe that letting the operator decide is a good practice. In my specific use case this is not a priority. If we allow these flavors again this is small downstream patch
15:53:02 efried roger that. Thanks for the update.
15:53:20 mriedem dansmith: so circling back on https://review.openstack.org/#/c/604687/3/nova/db/sqlalchemy/migrate_repo/versions/391_add_volume_type_to_bdm.py - you're cool with the compute API taking volume type name or ID yes?
15:54:24 dansmith mriedem: yes, but I'm not sure what that has to do with that migration.. it already has char(255) right?
15:54:34 mriedem yes
15:54:40 mriedem that's just what initiated the question
15:54:45 belmoreira efried cdent also was testing if there's any limitation creating VMs with more vcpus than cpus available in the node and can't find any issue
15:55:11 efried good to know.
16:02:42 openstackgerrit Balazs Gibizer proposed openstack/nova master: Consumer gen support for delete instance allocations https://review.openstack.org/591597
16:13:15 bauzas gibi: I'll start review your series tomorrow morning, can I ?
16:13:55 gibi bauzas: sure. There are comment already that I need to fix through the series but the content of the patches are ready for review
16:14:08 bauzas all cool then ++
16:14:15 bauzas aaaand then, calling it a day !
16:16:19 gibi bauzas: have a nice evening
16:18:41 openstackgerrit Balazs Gibizer proposed openstack/nova master: Consumer gen support for delete instance allocations https://review.openstack.org/591597
16:45:14 melwitt o/
16:45:54 sean-k-mooney o/
16:48:43 openstack Launchpad bug 1209101 in OpenStack Compute (nova) "Non-public flavor cannot be used in created tenant" [High,Fix released] - Assigned to Sumanth Nagadavalli (sumanth-nagadavalli)
16:48:43 s10 https://bugs.launchpad.net/nova/+bug/1209101 - please, reopen this bug
17:02:42 cfriesen mriedem: stephenfin: any chance you could take a look at a robustness fix around port binding in rebuild/reboot? https://review.openstack.org/603844
17:06:40 openstackgerrit Merged openstack/nova stable/pike: Fix message for unexpected external event https://review.openstack.org/589503
17:06:47 openstackgerrit Merged openstack/nova master: Rename "polling_changes-since_parameter.rst" https://review.openstack.org/604606
17:42:59 openstackgerrit Matthew Booth proposed openstack/nova master: Always check return of wait_for_versioned_notifications https://review.openstack.org/604859
17:43:20 mdbooth ^^^ took me all day :/
17:43:40 mdbooth The failure in my test, that is. I haven't actually checked locally if the above patch works.
17:45:03 mdbooth I wonder if it should just raise an exception instead, tbh. Would make it harder to misuse.
18:10:05 efried mdbooth: "it" the fixture or "it" the original method?
18:12:40 efried oh. it's only in the fixture
18:18:07 efried makes sense for it to raise on None, I reckon. But if you're going that far, you may as well make _Sub.wait_n raise on timeout too.
18:25:59 AJaeger mriedem, bauzas, melwitt , lyarwood, could you help reviewing the stable python3-first changes, please? https://review.openstack.org/#/q/topic:python3-first+status:open+(openstack/nova+OR+project:openstack/nova-specs+OR+openstack/os-traits+OR+openstack/os-vif+OR+openstack/osc-placement+OR+openstack/python-novaclient) gives list of open changes
18:27:05 sean-k-mooney AJaeger: looking at the list everything that is left is for stable branches
18:27:25 sean-k-mooney AJaeger: the trove change is likely the wrong channel
18:27:48 AJaeger sean-k-mooney: yeah, don't know why the query includes that one ;( Adn yes, it's all stable changes...
18:27:53 lyarwood AJaeger: ack will do
18:28:06 AJaeger thanks, lyarwood. If you have questions, feel free to ask ...
18:28:21 AJaeger lyarwood: and ignore the trove one, please
18:28:58 lyarwood AJaeger: ack, I can't +2 that anyway :)
18:29:39 openstackgerrit Alessandro Pilotti proposed openstack/python-novaclient master: Fixes Python3 issue in decoding password https://review.openstack.org/604870
18:31:41 melwitt AJaeger: thanks for the heads up
18:32:36 AJaeger melwitt: once those 15 changes are in, the python3-first goal is done for nova ;)
18:33:10 AJaeger Only 13, I miscounted
18:33:14 melwitt coolness, I'll make sure we get those in
18:33:37 AJaeger great
18:33:55 AJaeger you have at least changes that pass everywhere - compared to other projects ;/
18:34:29 melwitt that's fortunate :)
18:35:34 AJaeger indeed

Earlier   Later