| obre | Hi all! I wonder if it is possible for me to propse a small change to nova? In short I would like to add a config-option allowing us to specify the value nova-compute reports to placement for VCPU:max_unit. The use-case is to avoid having instances consuming all CPU's of a compute-node (ex: I do not want instances using 24 cores to end up on my hypervisor with 24 cores; Id | 07:38 |
|---|---|---|
| obre | rather want them on larger hypervisors). Does it make sense? | 07:38 |
| obre | I am able to write the changes needed in nova/virt/libvirt/driver.py and nova/conf/compute.py, I just wonder if this is something that makes sense for me to try push upstream; or if there are obvious blockers I dont see? | 07:40 |
| gibi | obre: I'm wondering. it might be already possible with a provider.yaml file https://docs.openstack.org/nova/latest/admin/managing-resource-providers.html | 07:40 |
| gibi | but if not, then I would enhance that facility to configure max_unit | 07:41 |
| obre | gibi: Only for resources named CUSTOM_* | 07:41 |
| obre | gibi: AFAIK | 07:41 |
| gibi | could be. so I would suggest to extend that for non CUSTOM_ resources too | 07:41 |
| gibi | so if somebody wants to do the max_unit on memory tomorrow then we have a generic solution | 07:42 |
| obre | I think the reason for only allowing CUSTOM is to avoid having conflicts within nova; as nova already reports values for VCPU, MEMORY_MB and DISK_GB in its virt drivers. | 07:43 |
| obre | So I guess that if we extend the provider.yaml to also allow setting these we need to do major work to ensure that it does not create conflicts? | 07:44 |
| obre | Thats why I am basicly thinking that something similar to reserved_host_memory_mb, reserved_host_cpus and reserved_host_disk_mb is tempting for min/max_unit for these values. | 07:45 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (db) https://review.opendev.org/c/openstack/nova/+/831193 | 07:47 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (objects) https://review.opendev.org/c/openstack/nova/+/839401 | 07:47 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194 | 07:47 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (drivers and compute manager part) https://review.opendev.org/c/openstack/nova/+/833090 | 07:47 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (api) https://review.opendev.org/c/openstack/nova/+/836830 | 07:47 |
| opendevreview | ribaudr proposed openstack/nova master: Bump compute version and check shares support https://review.opendev.org/c/openstack/nova/+/850499 | 07:47 |
| opendevreview | ribaudr proposed openstack/nova master: Add metadata for shares https://review.opendev.org/c/openstack/nova/+/850500 | 07:47 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach notification https://review.opendev.org/c/openstack/nova/+/850501 | 07:47 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach notification https://review.opendev.org/c/openstack/nova/+/851028 | 07:48 |
| opendevreview | ribaudr proposed openstack/nova master: Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029 | 07:48 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.power_on_error notification https://review.opendev.org/c/openstack/nova/+/852084 | 07:48 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.power_off_error notification https://review.opendev.org/c/openstack/nova/+/852278 | 07:48 |
| opendevreview | ribaudr proposed openstack/nova master: Add helper methods to attach/detach shares https://review.opendev.org/c/openstack/nova/+/852085 | 07:48 |
| opendevreview | ribaudr proposed openstack/nova master: Add libvirt test to ensure metadata are working. https://review.opendev.org/c/openstack/nova/+/852086 | 07:48 |
| opendevreview | ribaudr proposed openstack/nova master: Add virt/libvirt error test cases https://review.opendev.org/c/openstack/nova/+/852087 | 07:48 |
| opendevreview | ribaudr proposed openstack/nova master: Add share_info parameter to reboot method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/854823 | 07:48 |
| opendevreview | ribaudr proposed openstack/nova master: Support rebooting an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/854824 | 07:48 |
| opendevreview | ribaudr proposed openstack/nova master: Change microversion to 2.94 https://review.opendev.org/c/openstack/nova/+/852088 | 07:48 |
| obre | gibi: I am unable to find the real reason to only allow specifying CUSTOM inventories/traits through provider.yaml, but I guess there is a reason for this limitation? And that you not really want me to create a patch simply removing the check that traits/inventories specified in provider.yaml starts with "CUSTOM_"? | 08:16 |
| gibi | obre: good point about the possible conflict. | 08:17 |
| gibi | obre: I think max_unit will not be a conflict as nova never specify that other than 1 | 08:17 |
| gibi | obre: as of why we have the limitation today, I think we wanted to avoid thinking through all the possible conflict scenarios when we first introduced the provider.yaml to limit the scope of that first step. | 08:18 |
| gibi | obre: I agree that defining VCPU.total via provider.yaml needs thinking and some agreement what does that mean, which input has higher priority the virt driver or the provider.yaml one | 08:19 |
| gibi | but I don't think you need VCPU.total you only need RC.max_unit to be allowed for your use case | 08:19 |
| obre | Yes; it is basiclu max_unit which is relevant; but the driver sets that to the same value as "total" quite explicitly: | 08:20 |
| obre | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L8797-L8804 | 08:22 |
| obre | And since we have the CONF.reserved_host_cpus, it seemed like a similar solution for max_unit (and even min_unit) would make sense, and be consistent with something that already exists. | 08:23 |
| opendevreview | Amit Uniyal proposed openstack/nova master: Adds check if blk_dev_info has correct flavor.swap https://review.opendev.org/c/openstack/nova/+/857339 | 08:50 |
| gibi | obre: I'm not saying having a dedicated CONF is not a valid alternative. I think both direction worth thinking. | 09:05 |
| gibi | obre: there are couple of ways to get a bit wider input for the ideas | 09:05 |
| gibi | i) try to put it on the agenda of the next nova meeting https://wiki.openstack.org/wiki/Meetings/Nova 2) try to file a blueprint and a spec describing the alternatives https://specs.openstack.org/openstack/nova-specs/#process 3) raise this as a Project Team Gathering topic in https://etherpad.opendev.org/p/nova-antelope-ptg | 09:07 |
| auniyal_ | O/ | 09:12 |
| opendevreview | Eigil Obrestad proposed openstack/nova master: Config parameters for min/max cpu/memory allocation. https://review.opendev.org/c/openstack/nova/+/857595 | 09:12 |
| auniyal_ | please review this -https://review.opendev.org/c/openstack/nova/+/852737 | 09:12 |
| auniyal_ | https://review.opendev.org/c/openstack/nova/+/857339 | 09:13 |
| obre | gibi: I submitted a change to illustrate what I consider to be the simplest solution. Ill have a look at your three alternatives in a little while. First I need to eat and do a little bit of other work. | 09:14 |
| gibi | obre: sure :) | 09:15 |
| opendevreview | Ghanshyam proposed openstack/osc-placement master: Switch to 2023.1 Python3 unit tests and generic template name https://review.opendev.org/c/openstack/osc-placement/+/856787 | 09:25 |
| opendevreview | Ghanshyam proposed openstack/os-vif master: Switch to 2023.1 Python3 unit tests and generic template name https://review.opendev.org/c/openstack/os-vif/+/856783 | 09:28 |
| opendevreview | Ghanshyam proposed openstack/python-novaclient master: Switch to 2023.1 Python3 unit tests and generic template name https://review.opendev.org/c/openstack/python-novaclient/+/856791 | 09:29 |
| obre | gibi: To "try to put it on the agenda of the next nova meeting"; is that simply updating the agenda on the wikipage? | 10:15 |
| gibi | obre: there is an #topic Open discussion and under that you can add your topic | 10:15 |
| opendevreview | Takashi Natsume proposed openstack/nova master: Update min supported service version for Zed https://review.opendev.org/c/openstack/nova/+/856895 | 11:32 |
| sean-k-mooney | bauzas: gibi can we land this before RC1 https://review.opendev.org/c/openstack/nova/+/831844 | 11:32 |
| sean-k-mooney | its addign the centos 9 fips job to the weekly periodic | 11:33 |
| sean-k-mooney | pipelien and experimental | 11:33 |
| sean-k-mooney | its finally passing again so it woudl be nice to include that so it can run on stable | 11:33 |
| sean-k-mooney | without having to backport it explcitly to stable when the branch is cut | 11:34 |
| sean-k-mooney | gmann:^ you have reviewd that before | 11:34 |
| gmann | sean-k-mooney: +W | 11:36 |
| sean-k-mooney | gmann++ many thanks | 11:37 |
| sean-k-mooney | gmann: did you see my question here https://review.opendev.org/c/openstack/os-vif/+/856783/2#message-3aaeaa39501922e15ae5bfebb78fdf8e5c4c262c | 11:37 |
| sean-k-mooney | are we goign to branch the openstack-python3-jobs via job vairiant | 11:38 |
| sean-k-mooney | to make sure that the jobs in that template do not change on stable branches | 11:38 |
| gmann | sean-k-mooney: yes, replied, like this we can do - https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/856903/2/zuul.d/project-templates.yaml#1600 | 11:41 |
| gmann | we will pin the changed job for stable and master once new release and change in python version jobs | 11:41 |
| sean-k-mooney | ack thats all i needed to know. i assuemd ye would use job variant and the branches key | 11:44 |
| sean-k-mooney | gmann: so with this change if we do it on nova and all the other compute deliverable we never need to review/merge these defualt job template paches again right :) | 11:46 |
| sean-k-mooney | its just the central review going forward for the job variant | 11:46 |
| gmann | sean-k-mooney: right. we do not need to update template name in nova side | 11:55 |
| sean-k-mooney | that will be nice | 11:56 |
| sean-k-mooney | its not like this takes much time but less manual stuff every release it a good thing | 11:56 |
| bauzas | cores, can we please review https://review.opendev.org/c/openstack/nova/+/857467 (prelude) | 13:09 |
| bauzas | this becomes critical | 13:09 |
| bauzas | sean-k-mooney: gibi: others | 13:09 |
| * gibi clicks | 13:09 | |
| sean-k-mooney | oh the prelude | 13:09 |
| sean-k-mooney | sure ill do it now | 13:09 |
| bauzas | gracias and danke | 13:10 |
| sean-k-mooney | i tought we had already merge that but it was the release highlights i was thinking of | 13:10 |
| sean-k-mooney | for marketing | 13:10 |
| bauzas | correct | 13:10 |
| bauzas | cycle highlights go to some other website | 13:11 |
| bauzas | here, the prelude is just for ops not wanting to read the long list of things we have in the relnotes | 13:11 |
| sean-k-mooney | -1 i think you ment zed https://review.opendev.org/c/openstack/nova/+/857467/1/releasenotes/notes/zed-prelude-a3cddb8b2ac8e293.yaml | 13:11 |
| sean-k-mooney | otherwise i think it looks ok to me | 13:12 |
| sean-k-mooney | if you fix that im +1 | 13:13 |
| sean-k-mooney | or +2 i guess | 13:13 |
| sean-k-mooney | also set review priorty lable on that | 13:13 |
| sean-k-mooney | bauzas: you were on pto when i had this converstaion with gibi and stephenfin | 13:14 |
| bauzas | sean-k-mooney: I can respin quickly | 13:14 |
| sean-k-mooney | bauzas: but the tl;dr is that review priorty is a littel weird for core so i use it slightly differnt then the doc | 13:14 |
| bauzas | sean-k-mooney: honestly, I was about to write a topic for the PTG agenda about the use of review-prio | 13:15 |
| sean-k-mooney | bauzas: if i set +1 it means im looking at it but im not askign other cores to look at it if i set +2 it means im looking at it and would like other cores to look at it too | 13:15 |
| bauzas | and how we could make this better | 13:15 |
| sean-k-mooney | so im using +1 to comunicate to the author that they have my attention | 13:15 |
| sean-k-mooney | and +2 to comunciate to the core team that i think its imporant for them to look at too | 13:16 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Prelude section for Zed release https://review.opendev.org/c/openstack/nova/+/857467 | 13:16 |
| sean-k-mooney | im not commiting them to but usign it to signal asyc that i think its more important for wider review | 13:16 |
| bauzas | sean-k-mooney ack, then let's discuss this at the PTG | 13:16 |
| sean-k-mooney | cool | 13:16 |
| bauzas | sean-k-mooney: gibi: updated prelude ^ | 13:16 |
| sean-k-mooney | im trying to decople priorty from quality | 13:16 |
| sean-k-mooney | i.e. rp +2 my be with a buch of -1 but may have topic that need wider input | 13:17 |
| sean-k-mooney | bauzas: when will that move to zed https://6bc7844fa7b995ed5b77-cdf523d3b16150ab0b9ddc512a79d512.ssl.cf2.rackcdn.com/857467/1/check/build-openstack-releasenotes/b8db3f7/docs/unreleased.html should that also be in the patch or is it when we cut the stable branch | 13:19 |
| bauzas | sean-k-mooney: ah | 13:20 |
| sean-k-mooney | stephenfin: ^ pbr has some magic based on commit messages right it it tied into that or do we need to do somethign esle | 13:20 |
| bauzas | you mean when it will be told "zed" | 13:20 |
| sean-k-mooney | yep | 13:20 |
| bauzas | sean-k-mooney: that's because reno works with git branches | 13:20 |
| sean-k-mooney | this shoudl be rended under zed in rc1 right | 13:20 |
| bauzas | for the moment, we haven't released zed | 13:20 |
| bauzas | even with rc1 | 13:21 |
| sean-k-mooney | so on stable zed this will render under zed automatically | 13:21 |
| sean-k-mooney | have you checked that locally? | 13:21 |
| bauzas | yup, because it branches | 13:21 |
| bauzas | no, this is just the releases team which creates the correct new pages | 13:21 |
| bauzas | https://6bc7844fa7b995ed5b77-cdf523d3b16150ab0b9ddc512a79d512.ssl.cf2.rackcdn.com/857467/1/check/build-openstack-releasenotes/b8db3f7/docs/unreleased.html#relnotes-25-0-0-195 will be seen <sha1_something>-rc1 | 13:21 |
| sean-k-mooney | ok +2 then i captured that in the review message | 13:23 |
| bauzas | sean-k-mooney: example of a release patch creating the yoga page https://github.com/openstack/nova/commit/d2cba990a6205e5b0361e750c173850cf209a9e6 | 13:23 |
| sean-k-mooney | right i tought we needed one like that i woudl prefer to do that before rc1 | 13:24 |
| sean-k-mooney | we can do it after but i find that messier | 13:24 |
| bauzas | https://review.opendev.org/c/openstack/nova/+/833243 was the patch | 13:24 |
| sean-k-mooney | yep so why are we not doing that in the prelude patch or at least proposing it now | 13:25 |
| bauzas | as you see in the "included in", this was merged *after* yoga GA | 13:25 |
| sean-k-mooney | so we can merge both together | 13:25 |
| bauzas | you can't | 13:25 |
| sean-k-mooney | right i think that is wrong | 13:25 |
| bauzas | prelude has to be merged before RC1 | 13:25 |
| sean-k-mooney | yes and after RC1 master is A | 13:26 |
| opendevreview | Merged openstack/nova master: Test setting the nova job to centos-9-stream https://review.opendev.org/c/openstack/nova/+/831844 | 13:26 |
| bauzas | correct | 13:26 |
| sean-k-mooney | so we would have to backport it to stable | 13:26 |
| sean-k-mooney | i would like to avoid that backport | 13:26 |
| bauzas | correct, we did it once and we had hard times with ops | 13:26 |
| sean-k-mooney | by merging it at RC1 | 13:26 |
| bauzas | we merged prelude after RC1 | 13:26 |
| sean-k-mooney | and using it as the base of the rc tag | 13:26 |
| bauzas | in Newton IIRC | 13:26 |
| bauzas | that's the usual thing we do | 13:26 |
| bauzas | but prelude can be merged a bit earler | 13:27 |
| sean-k-mooney | yep that fin i would just like to also incldue the other patch in rc1 | 13:27 |
| sean-k-mooney | the zed version of https://review.opendev.org/c/openstack/nova/+/833243 | 13:27 |
| sean-k-mooney | so we can proceed with the prelude patch as is | 13:27 |
| bauzas | yup, was in Newton https://docs.openstack.org/releasenotes/nova/newton.html#release-notes-14-0-1-stable-newton | 13:28 |
| sean-k-mooney | but i was trying to avoid another review cycle for the trivail rel note change | 13:28 |
| bauzas | as a consequence, we were only able to provide the prelude section once we released a stable release | 13:28 |
| bauzas | operators were angry about it | 13:29 |
| sean-k-mooney | sure but your not listenting to what im saying | 13:29 |
| sean-k-mooney | im not talking about not providing the prelude in rc1 | 13:29 |
| sean-k-mooney | we should | 13:29 |
| bauzas | ah, the zed file creation | 13:29 |
| sean-k-mooney | im saying please add zed to the index in rc1 | 13:29 |
| sean-k-mooney | yes | 13:29 |
| bauzas | no, again, we can't | 13:29 |
| bauzas | this isn't logical | 13:30 |
| sean-k-mooney | why yes it is | 13:30 |
| bauzas | we haven't released officially Zed yet | 13:30 |
| sean-k-mooney | right but its the release candiate | 13:30 |
| bauzas | hence the "unreleased" | 13:30 |
| bauzas | correct | 13:30 |
| bauzas | but a candidate | 13:30 |
| bauzas | not a release | 13:30 |
| sean-k-mooney | and ideally there shoudl be no change in that and the final release | 13:30 |
| bauzas | there could be | 13:30 |
| bauzas | some regression bugfix adding notes | 13:30 |
| sean-k-mooney | right but in the case that there is no change required we should use the same sha | 13:30 |
| sean-k-mooney | meaning the candiate should have the same content as the final releas package | 13:31 |
| bauzas | as you see, this is an automated bot https://review.opendev.org/c/openstack/nova/+/833243 | 13:31 |
| bauzas | and the release team is doing this for all the managed projects | 13:31 |
| sean-k-mooney | ok fine lest keep the extra paperwork for now | 13:31 |
| sean-k-mooney | but this is pointless extra work that we shoudl try and avoid going forward | 13:32 |
| sean-k-mooney | we can maybe chat to the release team about this going forward | 13:32 |
| sean-k-mooney | its forceing that RC1 can never be the release package | 13:32 |
| sean-k-mooney | by doing it this way we always have to do a release of a diffenrt sha for the offical release | 13:33 |
| sean-k-mooney | bauzas: can you hit https://review.opendev.org/c/openstack/os-vif/+/856782 | 13:36 |
| sean-k-mooney | bauzas: and the folloing patch if you can too | 13:36 |
| bauzas | done | 13:37 |
| bauzas | was in the list of https://etherpad.opendev.org/p/nova-zed-rc-potential | 13:38 |
| sean-k-mooney | ack just saw the request form elodilles in my inbox hence the poke to actully land does | 13:40 |
| sean-k-mooney | *those | 13:40 |
| opendevreview | Merged openstack/os-vif master: Update master for stable/zed https://review.opendev.org/c/openstack/os-vif/+/856782 | 13:46 |
| Uggla | question about my_block_storage_ip. This flag can be available on each compute nodes or the default is the compute ip. Am I right ? | 13:50 |
| sean-k-mooney | yes | 13:50 |
| Uggla | is there a way to get this parameter from the api or it can be only provided by the compute node itself ? | 13:51 |
| sean-k-mooney | only on the compute | 13:52 |
| sean-k-mooney | that is why you need to do the grant on the compute not the api | 13:52 |
| sean-k-mooney | or conductor | 13:52 |
| sean-k-mooney | it has to be done in the compute agent | 13:52 |
| Uggla | so it needs a new "entry" in the compute API for this. Correct ? | 13:53 |
| sean-k-mooney | for share attament yes you need that anyway | 13:54 |
| sean-k-mooney | this is an internal detail or the attach_share rpc call | 13:55 |
| Uggla | so far there is no rpc call for attach. As everything could be done in the API. | 13:56 |
| sean-k-mooney | that would never work | 13:56 |
| sean-k-mooney | we need a call to the compute to actully do the mounting of the share ectra | 13:56 |
| *** Guest305 is now known as dasm | 13:57 | |
| sean-k-mooney | were you jsut goign to put that into spawn or something? | 13:57 |
| Uggla | attach is just an entry within the db. And mount + real work is done at power_on | 13:57 |
| sean-k-mooney | i have not look at this in a while so i dont remember the details | 13:57 |
| sean-k-mooney | i guess that work today only because we require the vm to be off/shelved | 13:58 |
| sean-k-mooney | but the rpc would be required if we supprot live attach in the future | 13:58 |
| Uggla | yes off | 13:58 |
| sean-k-mooney | ya so unless yo defer the grant to the power on stage | 13:58 |
| sean-k-mooney | your going to need an attach_share rpc call | 13:58 |
| sean-k-mooney | however hard reboot should not really call any external services | 13:59 |
| sean-k-mooney | like it should not udpate cinder attachment or neutron prot bindings | 13:59 |
| sean-k-mooney | so i woudl find it odd for it to update manila grants | 13:59 |
| Uggla | ok I can implement that in rpc. Can I just make a sync call to rpc get the result and do the rest in the API ? | 14:00 |
| Uggla | result = get the ip | 14:00 |
| Uggla | or is it better to call the rpc and do the required work in the rpc ? | 14:00 |
| gibi | bauzas: I left feedback on the prelude | 14:04 |
| bauzas | ack, looing | 14:04 |
| * bauzas doing 3 things at the same time | 14:04 | |
| stephenfin | sean-k-mooney: the release note will be moved to zed when the tag is created | 14:06 |
| stephenfin | (sorry, my VPN disconnected and I never noticed) | 14:06 |
| stephenfin | (my ZNC deployment is now behind VPN) | 14:07 |
| sean-k-mooney | no worries | 14:09 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Prelude section for Zed release https://review.opendev.org/c/openstack/nova/+/857467 | 14:10 |
| bauzas | gibi: sean-k-mooney: updated ^ | 14:10 |
| bauzas | stephenfin: well, not automatically | 14:11 |
| stephenfin | wdym? | 14:11 |
| bauzas | stephenfin: we need to tell reno to look at the new stable/zed branch | 14:11 |
| gibi | bauzas: that was fast :) | 14:11 |
| bauzas | stephenfin: I mean, by for example https://review.opendev.org/c/openstack/nova/+/833243 | 14:12 |
| stephenfin | bauzas: oh yeah, but the bot will do that | 14:12 |
| bauzas | stephenfin: if we don't merge this file, then none of the files look at the new stable branch | 14:12 |
| stephenfin | you're right though | 14:12 |
| sean-k-mooney | bauzas: that also has the pbr tag in the commit | 14:12 |
| bauzas | so we need to merge it quickly after the new branch | 14:12 |
| stephenfin | it'll appear under the 26.0.0 tag but the zed page won't exist until created | 14:13 |
| opendevreview | Merged openstack/os-vif master: Switch to 2023.1 Python3 unit tests and generic template name https://review.opendev.org/c/openstack/os-vif/+/856783 | 15:18 |
| opendevreview | Merged openstack/python-novaclient master: Switch to 2023.1 Python3 unit tests and generic template name https://review.opendev.org/c/openstack/python-novaclient/+/856791 | 15:36 |
| opendevreview | Merged openstack/nova master: Bump min oslo.concurrencty to >= 5.0.1 https://review.opendev.org/c/openstack/nova/+/857491 | 15:46 |
| opendevreview | Merged openstack/nova master: Update compute rpc version alias for zed https://review.opendev.org/c/openstack/nova/+/855706 | 16:50 |
| opendevreview | Merged openstack/nova master: Prelude section for Zed release https://review.opendev.org/c/openstack/nova/+/857467 | 17:13 |
| nicolasbock | Hi! I am trying to get Neutron/Designate integration to work and am running into the following issue: | 17:29 |
| nicolasbock | 1. Created network with dns_domain | 17:29 |
| nicolasbock | 2. Created zone | 17:29 |
| nicolasbock | 3. Created server on network | 17:29 |
| nicolasbock | The server's port will get a dns_assignment with the generic domain from neutron.conf in the fqdn instead of the dns domain from the network. This breaks reverse DNS lookups from the VM. | 17:29 |
| nicolasbock | Am I missing something? | 17:29 |
| *** dasm is now known as dasm|off | 21:27 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!