[Openstack-operators] [nova] [neutron] Should we continue providing FQDNs for instance hostnames?
[Re-posting (in edited from) from openstack-dev] Nova has a feature whereby it will provide instance host names that cloud-init can extract and use inside the guest, i.e. this won't happen without cloud- init. These host names are fully qualified domain names (FQDNs) based upon the instance name and local domain name. However, as noted in bug #1698010 [1], the domain name part of this is based up nova's 'dhcp_domain' option, which is a nova-network option that has been deprecated [2]. My idea to fix this bug was to start consuming this information from neutron instead, via the . However, per the feedback in the (WIP) fix [3], this requires requires that the 'DNS Integration' extension works and will introduce a regression for users currently relying on the 'dhcp_domain' option. This suggests it might not be the best approach to take but, alas, I don't have any cleverer ones yet. My initial question to openstack-dev was "are FQDNs a valid thing to use as a hostname in a guest" and it seems they definitely are, even if they're not consistently used [4][5]. However, based on other comments [6], it seems there are alternative approaches and even openstack-infra don't use this functionality (preferring instead to configure hostnames using their orchestration software, if that's what nodepool could be seen as?). As a result, I have a new question: "should nova be in the business of providing this information (via cloud-init and the metadata service) at all"? I don't actually have any clever ideas regarding how we can solve this. As such, I'm open to any and all input. Cheers, Stephen [1] https://bugs.launchpad.net/nova/+bug/1698010 [2] https://review.openstack.org/#/c/395683/ [3] https://review.openstack.org/#/c/480616/ [4] http://lists.openstack.org/pipermail/openstack-dev/2017-September/121948.ht ml [5] http://lists.openstack.org/pipermail/openstack-dev/2017-September/121794.ht ml [6] http://lists.openstack.org/pipermail/openstack-dev/2017-September/121877.ht ml ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [Openstack-sigs] [all] Bringing the community together (combine the lists!)
On Fri, 2018-08-31 at 10:03 +1000, Tony Breeds wrote: > On Thu, Aug 30, 2018 at 09:12:57PM +, Jeremy Stanley wrote: > > On 2018-08-31 01:13:58 +0800 (+0800), Rico Lin wrote: > > [...] > > > What needs to be done for this is full topic categories support > > > under `options` page so people get to filter emails properly. > > > > [...] > > > > Unfortunately, topic filtering is one of the MM2 features the > > Mailman community decided nobody used (or at least not enough to > > warrant preserving it in MM3). I do think we need to be consistent > > about tagging subjects to make client-side filtering more effective > > for people who want that, but if we _do_ want to be able to upgrade > > we shouldn't continue to rely on server-side filtering support in > > Mailman unless we can somehow work with them to help in > > reimplementing it. > > The suggestion is to implement it as a 3rd party plugin or work with the > mm community to implement: > https://wiki.mailman.psf.io/DEV/Dynamic%20Sublists > > So if we decide we really want that in mm3 we have options. > > Yours Tony. I've tinked with mailman 3 before so I could probably take a shot at this over the next few week(end)s; however, I've no idea how this feature is supposed to work. Any chance an admin of the current list could send me a couple of screenshots of the feature in mailman 2 along with a brief description of the feature? Alternatively, maybe we could upload them to the wiki page Tony linked above or, better yet, to the technical details page for same: https://wiki.mailman.psf.io/DEV/Brief%20Technical%20Details Cheers, Stephen ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [nova] nova-xvpvncproxy CLI options
tl;dr: Is anyone calling 'nova-novncproxy' or 'nova-serialproxy' with CLI arguments instead of a configuration file? I've been doing some untangling of the console proxy services that nova provides and trying to clean up the documentation for same [1]. As part of these fixes, I noted a couple of inconsistencies in how we manage the CLI options for these services. Firstly, the 'nova-novncproxy' and 'nova-serialproxy' services accept CLI configuration options while the 'nova-xvpvncproxy' service does not. $ nova-novncproxy --help usage: nova-novncproxy [-h] [--vnc-auth_schemes VNC_AUTH_SCHEMES] [--vnc-novncproxy_host VNC_NOVNCPROXY_HOST] [--vnc-novncproxy_port VNC_NOVNCPROXY_PORT] [--vnc-vencrypt_ca_certs VNC_VENCRYPT_CA_CERTS] [--vnc-vencrypt_client_cert VNC_VENCRYPT_CLIENT_CERT] [--vnc-vencrypt_client_key VNC_VENCRYPT_CLIENT_KEY] [--cert CERT] [--config-dir DIR] [--config-file PATH] ... [--remote_debug-port REMOTE_DEBUG_PORT] $ nova-xvpvncproxy --help usage: nova-xvpvncproxy [-h] [--remote_debug-host REMOTE_DEBUG_HOST] [--remote_debug-port REMOTE_DEBUG_PORT] ... [--version] [--watch-log-file] This means that you could, conceivably, run 'nova-novncproxy' without a configuration file but the same would not be possible with the 'nova- xvpvncproxy' service. Secondly, the 'nova-novncproxy' CLI options are added to a 'vnc' group, meaning they appear with an unnecessary 'vnc-' prefix (e.g. '--vnc-novncproxy_host'), and the 'nova-serialproxy' CLI options are prefixed with 'serial-' for the same reason. Finally, none of these options are documented anywhere. My initial plan [2] to resolve all of the above had been to add the CLI options to the 'nova-xvpvncproxy' service and then go figure out how to get oslo.config autodocumenting these for us in our man pages. However, a quick search through GitHub, codesearch.o.o and Google turned up no hits so I wonder if anyone is configuring these things by CLI? If not, maybe we should just go and remove this code and insist on configuration via config file? Cheers, Stephen [1] https://review.openstack.org/606148 [2] https://review.openstack.org/606929 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [nova][xenapi] can we deprecate the xenapi-specific 'nova-console' service?
On Thu, 2018-10-04 at 12:03 +, Bob Ball wrote: > Hi Melanie, > > We recommend using novncproxy_base_url with > vncserver_proxyclient_address set to the dom0's management IP > address. > > We don't currently use nova-console, so deprecation would be the best > approach. > > Thanks, > > Bob What about nova-xvpvncproxy [1]? This would be configured using xvpvncproxy_base_url. This is also Xen-specific (as the name, Xen VNC Proxy, would suggest). If the noVNC-based console is now recommended, can we also deprecate the XVP one? Stephen [1] https://review.openstack.org/#/c/606148/5/doc/source/admin/remote-console-access.rst@313 > -Original Message- > From: melanie witt [mailto:melwi...@gmail.com] > Sent: 03 October 2018 23:08 > To: OpenStack Development Mailing List (not for usage questions) < > openstack-...@lists.openstack.org>; > openstack-operators@lists.openstack.org > Subject: [openstack-dev] [nova][xenapi] can we deprecate the xenapi- > specific 'nova-console' service? > > Greetings Devs and Ops, > > Today I noticed that our code does not handle the 'nova-console' > service properly in a multi-cell deployment and given that no one has > complained or reported bugs about it, we're wondering if anyone still > uses the nova-console service. The documentation [1] says that the > nova-console service is a "XenAPI-specific service that most recent > VNC proxy architectures do not use." > > Can anyone from xenapi land shed some light on whether the nova- > console service is still useful in deployments using the xenapi > driver, or is it an old relic that we should deprecate and remove? > > Thanks for your help, > -melanie > > [1] > https://docs.openstack.org/nova/latest/admin/remote-console-access.html > class="Apple-tab-span" style="white-space:pre"> > > _ > _ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _ > _ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
