| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-19 | |||
| 08:56:42 | hrw | bauzas: morning | |
| 08:57:28 | hrw | my patch to control pcie ports is ready for reviews: https://review.openstack.org/545034 - there are tests for aarch64 and for x86-64 | |
| 08:57:40 | hrw | release note present, config entry commented | |
| 09:17:30 | bauzas | hrw: I beg you for my ignorance about PCIe ports, but when you say "libvirt adds pcie ports as it needs" in https://review.openstack.org/#/c/545034/8//COMMIT_MSG, WDYM ? | |
| 09:18:06 | bauzas | hrw: when you say "libvirt", it means libvirtd, right? not the nova libvirt driver | |
| 09:19:45 | ameeda | Hello when I remove pycrypto as this bug needed https://bugs.launchpad.net/openstack-requirements/+bug/1749574, I got this error https://pasteboard.co/H8l6IC4.png | |
| 09:19:45 | openstack | Launchpad bug 1749574 in OpenStack DBaaS (Trove) "[tracking] removal and migration of pycrypto" [Undecided,In progress] - Assigned to Ameed Ashour (ameeda) | |
| 09:19:45 | hrw | bauzas: when I say libvirt I mean upstream libvirt so yes, libvirtd | |
| 09:20:28 | hrw | ameeda: migrating pycrypto -> cryphography? | |
| 09:22:49 | ameeda | hrw: requirements.txt file already has cryphography | |
| 09:23:31 | ameeda | https://github.com/openstack/barbican/blob/master/requirements.txt#L7 | |
| 09:24:26 | hrw | sure | |
| 09:28:35 | ameeda | hrw: as I saw, the error caused by test_dogtag, what do you think ? | |
| 09:28:36 | bauzas | hrw: had some comments | |
| 09:28:50 | bauzas | hrw: the main one is that I think you should create a blueprint for your feature | |
| 09:29:02 | bauzas | hrw: and engage with the community whether you need a spec | |
| 09:29:14 | bauzas | it's better for tracking your feature | |
| 09:29:40 | bauzas | you're also adding a new config option, that properly needs to be released | |
| 09:30:09 | bauzas | hrw: see https://docs.openstack.org/nova/latest/contributor/blueprints.html for the process-ish thingy | |
| 09:30:36 | bauzas | hrw: I'm personnally on the side that a blueprint is enough, we don't really need a spec | |
| 09:31:36 | bauzas | but devil could be in details, and somehow some people could argue about your implementation design that would mean a spec is needed | |
| 09:33:56 | hrw | bauzas: thanks. will create bp | |
| 09:35:30 | bauzas | hrw: add your blueprint in the next nova meeting agenda then | |
| 09:35:41 | hrw | ok | |
| 09:35:41 | bauzas | and be present at the nova meeting | |
| 09:35:44 | hrw | sure | |
| 09:35:53 | bauzas | so we could validate your blueprint or ask you for a spec | |
| 09:36:09 | bauzas | you're not in a rush, we're just beginning to review specs :) | |
| 09:36:31 | hrw | bauzas: would love to backport it to queens one day | |
| 09:36:58 | bauzas | in case you're not familiar with the release cadence, we generally stop approving specs and blueprints past the first milestone | |
| 09:37:14 | bauzas | hrw: well, that's a feature, and we don't feature backport upstream | |
| 09:37:39 | hrw | please rephrase last sentence | |
| 09:37:48 | bauzas | hrw: feel free to do whatever you want in your downstream product, but there are no chances that a change including a features relnote could be backported | |
| 09:38:01 | hrw | ok. | |
| 09:38:24 | bauzas | speaking of the differences between the upstream nova project and any other distribution | |
| 09:39:07 | bauzas | hrw: I guess you're not familiar with the stable branches procedure, lemme find you some doc | |
| 09:39:27 | bauzas | hrw: https://docs.openstack.org/project-team-guide/stable-branches.html | |
| 09:39:30 | hrw | bauzas: so far backported just simple changes | |
| 09:42:01 | bauzas | hrw: np, not all of us are familiar with all the procedures, I get that :p | |
| 09:42:22 | hrw | yep | |
| 09:58:10 | hrw | bauzas: replied | |
| 09:58:34 | hrw | bauzas: and thanks for detailed review | |
| 10:05:07 | hrw | https://blueprints.launchpad.net/nova/+spec/configure-amount-of-pcie-ports | |
| 10:41:08 | hrw | bauzas: where in meeting agenda would you suggest to add spec link? | |
| 10:41:35 | bauzas | hrw: in the nova meeting agenda, lemme find it | |
| 10:41:48 | hrw | https://wiki.openstack.org/wiki/Meetings/Nova | |
| 10:41:58 | hrw | bauzas: I mean "which part of meeting" | |
| 10:51:35 | bauzas | hrw: sorry got distracted | |
| 10:51:48 | hrw | bauzas: no problem. work is work | |
| 10:52:09 | bauzas | hrw: so, in https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting (seems a bit stale, you should comment that it's for the 22th), in Open Discussion | |
| 10:52:16 | hrw | thx | |
| 10:52:20 | bauzas | saying "specless BP approval" | |
| 10:54:17 | hrw | bauzas: added | |
| 10:56:50 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: Allow to configure amount of PCIe ports https://review.openstack.org/545034 | |
| 10:58:10 | hrw | commit message partially rewritten + BP link. some suggested code changes | |
| 11:09:00 | openstackgerrit | Chris Dent proposed openstack/nova master: Fix PatternPropertiesTestCase for py 3.6 https://review.openstack.org/545798 | |
| 11:47:34 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova-specs master: Support shared/dedicated vCPUs in one instance https://review.openstack.org/545734 | |
| 12:23:15 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova-specs master: Support shared and dedicated VMs in one host https://review.openstack.org/543805 | |
| 12:32:57 | openstackgerrit | Tetiana Lashchova proposed openstack/python-novaclient master: Fix the docstring for the update method https://review.openstack.org/545819 | |
| 12:42:27 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Extending delete_cell --force to delete instance_mappings https://review.openstack.org/540073 | |
| 12:49:46 | sean-k-mooney | stephenfin: enhancing your specs with images http://logs.openstack.org/90/541290/4/check/build-openstack-sphinx-docs/da8d825/html/specs/rocky/approved/numa-aware-vswitches.html thats almost cheating :P | |
| 12:51:29 | cdent | I thought the same thing | |
| 12:55:59 | sean-k-mooney | cdent: you can tell being on the docs team is rubing off on him :) that said the fact that he uses images to help explain numa rather then 10 paragraps of text no one will follow might be a reason he is a good person to be on the docs team. | |
| 12:56:10 | cdent | indeed | |
| 13:41:51 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Account for host agg allocation ratio in placement https://review.openstack.org/544683 | |
| 13:48:49 | cdent | sean-k-mooney: live migration is for virtualisers not cloud native people! true or false? | |
| 13:51:33 | kashyap | False | |
| 13:51:37 | kashyap | cdent: Because: | |
| 13:52:18 | cdent | kashyap for context https://review.openstack.org/#/c/541290/4/specs/rocky/approved/numa-aware-vswitches.rst@241 (in other words I was mostly making a joke, but still want to know the because) | |
| 13:52:38 | kashyap | People say Cloud is all about 'cattle' (sorry, can't think of a less trite analogy), but people _do_ care about live migratability in Cloud | |
| 13:53:11 | kashyap | cdent: I realized you're joking with a straight face (also with the exclamation) :P | |
| 13:54:34 | cdent | much of that spec has trouble aligning with cattle-ness, but people do care about it | |
| 13:55:26 | edleafe | Scheduler subteam meeting in 5 minutes in #openstack-meeting-alt | |
| 13:55:49 | kashyap | cdent: Saw asomething else on the spec, will comment there too | |
| 13:59:44 | sean-k-mooney | cdent: cloud native people should be able to have there application live migrated too. | |
| 14:00:16 | cdent | sean-k-mooney: for sake of getting your point of view, why? Shouldn't it just be restarted somewhere else? | |
| 14:00:16 | sean-k-mooney | cdent: live migration is really to allow operators to do maintenace when they done really know what the tenant is running | |
| 14:01:03 | edmondsw | restarting somewhere else means possible downtime | |
| 14:01:22 | sean-k-mooney | cdent: live migration in openstack is admin only so its tenant initiated its operator driven | |
| 14:01:53 | sean-k-mooney | edmondsw: yes that said livemigration could still violate your sla with your tenant | |
| 14:02:08 | cdent | surely every service should have at least two instances of itself all the time :) | |
| 14:02:17 | edmondsw | cdent ha! if only | |
| 14:02:31 | sean-k-mooney | cdent: the best example counter example to that is a provider edge router | |
| 14:02:32 | edmondsw | sean-k-mooney that all depends | |
| 14:02:41 | edmondsw | hence your "could", I'm sure :) | |
| 14:03:20 | cdent | shadow provider edge router | |
| 14:03:27 | sean-k-mooney | cdent: you cant have ha by design as it is respocible for ratelimiting your broadband connection so all traffic from one endpoint most be handeled by 1 PE router | |
| 14:04:10 | sean-k-mooney | cdent: you dont want to reboot in this case because it can thke 10+ minutes to rebuild your peering relationships with other PE routers | |
| 14:06:11 | kashyap | cdent: High availability, is it... | |
| 14:06:30 | kashyap | Yeah, sean-k-mooney explained it clearer -- about migratability | |
| 14:06:49 | cdent | I hear and ack what you're saying. | |
| 14:06:59 | cdent | But will remain frustrated :) | |
| 14:07:06 | kashyap | Just take a look at the number of config knobs we have for live migration | |
| 14:07:23 | kashyap | A common scenario for it in OpenStack context is upgrades | |
| 14:07:42 | edmondsw | also think about dev on the cloud... I'm still developing this service and haven't setup HA yet, but I don't want you restarting it while I'm working | |
| 14:07:43 | kashyap | Where you update Compute-B, migrate all instances from Compute-A to B | |
| 14:07:46 | kashyap | And so forth | |
| 14:07:46 | sean-k-mooney | cdent: well live migration cannot always be assumed to be available in a cloud and even if it is it my not be viable due to your perfromce constratints | |
| 14:08:19 | kashyap | Yeah, random restarts that catch tenant users off-guard are completely undesirable | |
| 14:09:13 | kashyap | sean-k-mooney: Yeah, that's also why, as you pointed out, tenant users don't get to migrate instances. It is admins that drive it. | |