Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey
[Resending for a colleague who's not on openstack-dev-- SL.] Yeap, because of the bug [#1677217] in the standard AggregateImagePropertiesIsolation filter, we have written a custom Nova scheduler filter. The filter AggregateImageOsDistroIsolation is a simplified version the AggregateImagePropertiesIsolation, based only on the 'os_distro' image property. https://github.com/valerytschopp/nova/blob/aggregate_image_isolation/nova/scheduler/filters/aggregate_image_os_distro_isolation.py [#1677217] https://bugs.launchpad.net/nova/+bug/1677217 Cheers, Valery On 29/04/18, 23:29 , "Ed Leafe" wrote: > On Apr 29, 2018, at 1:34 PM, Artom Lifshitz wrote: >> >> Based on that, we can definitely say that SameHostFilter and >> DifferentHostFilter do *not* belong in the defaults. In fact, we got >> our defaults pretty spot on, based on this admittedly very limited >> dataset. The only frequently occurring filter that's not in our >> defaults is AggregateInstanceExtraSpecsFilter. > Another data point that might be illuminating is: how many sites > use a custom (i.e., not in-tree) filter or weigher? One of the > original design tenets of the scheduler was that we did not want to > artificially limit what people could use to control their deployments, > but inside of Nova there is a lot of confusion as to whether anyone is > using anything but the included filters. > So - does anyone out there rely on a filter and/or weigher that they > wrote themselves, and maintain outside of OpenStack? > -- Ed Leafe > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [designate] Meeting Times - change to office hours?
Graham Hayes writes: > I would like to suggest we have an office hours style meeting, with > one in the UTC evening and one in the UTC morning. > If this seems reasonable - when and what frequency should we do > them? What times suit the current set of contributors? In general, I prefer 0700-1700 UTC, but 1600-2100 UTC are also doable. The current slot (1400 UTC) is ideal for me, except that in Winter (outside EU DST) it collides with another (regional OpenStack-related) teleconference every other week. Moving the current Designate meeting slot to bi-weekly would provide an easy way to fix my collision. -- Simon. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Default scheduler filters survey
Artom Lifshitz writes: > To that end, we'd like to know what filters operators are enabling in > their deployment. If you can, please reply to this email with your > [filter_scheduler]/enabled_filters (or > [DEFAULT]/scheduler_default_filters if you're using an older version) > option from nova.conf. Any other comments are welcome as well :) We have the following enabled on our semi-public (academic community) cloud, which runs on Newton: AggregateInstanceExtraSpecsFilter AvailabilityZoneFilter ComputeCapabilitiesFilter ComputeFilter ImagePropertiesFilter PciPassthroughFilter RamFilter RetryFilter ServerGroupAffinityFilter ServerGroupAntiAffinityFilter (sorted alphabetically) Recently we've also been trying AggregateImagePropertiesIsolation ...but it looks like we'll replace it with our own because it's a bit awkward to use for our purpose (scheduling Windows instance to licensed compute nodes). -- Simon. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [k8s][octavia][lbaas] Experiences on using the LB APIs with K8s
Joe Topjian writes: > Terraform hat! I want to slightly nit-pick this one since the words > "leak" and "admin-priv" can sound scary: Terraform technically wasn't > doing anything wrong. The problem was that Octavia was creating > resources but not setting ownership to the tenant. When it came time > to delete the resources, Octavia was correctly refusing, though it > incorrectly created said resources. I dunno... if Octavia created those lower-layer resources on behalf of the user, then Octavia shouldn't refuse to remove those resources when the same user later asks it to - independent of what ownership Octavia chose to apply to those resources. (It would be different it Neutron or Nova were asked by the user directly to remove the resources created by Octavia.) > From reviewing the discussion, other parties were discovering this > issue and patching in parallel to your discovery. Both xgerman and > Vexxhost jumped in to confirm the behavior seen by Terraform. Vexxhost > quickly applied the patch. It was a really awesome collaboration > between yourself, dims, xgerman, and Vexxhost. Speaking as another operator: Does anyone seriously expect us to deploy a service (Octavia) in production at a stage where it exhibits this kind of behavior? Having to clean up leftover resources because the users who created them cannot remove them is not my idea of fun. (And note that like most operators, we're a few releases behind, so we might not even get access to backports IF this gets fixed.) In our case we're not a compute-oriented cloud provider, and some of our customers would really like to have a good LBaaS as part of our IaaS offering. But our experience with this was so-so in the past - for example, we had to help customers migrate from LBaaSv1 to LBaaSv2. Our resources (people, tolerance to user-affecting bugs and forced upgrades etc.) are limited, so we've become careful. For users who want to use Kubernetes on our OpenStack service, we rather point them to Kubernetes's Ingress controller, which performs the LB function without requiring much from the underlying cloud. Seems like a fine solution. -- Simon. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Policy regarding template customisation
Paul Bourke writes: > So I think everyone is in agreement that it should be option 2. I'm > leaning towards this also but I'm wondering how much of this makes > things easier for us as developers rather than operators. > How committed this are we in practice? For example, if we take > nova.conf[0], if we follow option 2, theoretically all alternate > hypervisor options (vmware/xen/nova-fake) etc. should come out and be > left to override files. As should options templating options such as > metadata_workers, listen ports, etc. globals.yml could probably be > half the size it currently is. But if we go this route how many > operators will stick with kolla? [...] Operator here. I've been following this discussion. Background: We have been using puppet-openstack combined with our own Puppet "integration classes" for several years. All configuration parameters are neatly in Hiera. So we're used to the "batteries-included" way that Paul describes under (1). For various reasons, we are also looking at new ways of provisioning our control plane, including Kolla. In hindsight, and in my personal opinion, while our previous approach (1) has somehow felt like the proper way to do things, it hasn't really paid off for us as an operator, and I would happily try approach (2). The perceived downside of (2) - or a perceived advantage of (1) - is that in an ideal world, (1) isolates us from the arcane configuration file details that the crazy devs of individual services come up with. In practice, it turns out that (a) those files aren't rocket science (b) as an operator you need to understand them anyway, at the latest when you need to debug stuff, and (c) the deployment tool can easily become a bottlenecks for deploying new features. This is why I'm happy to embrace the current Kolla philosophy (2). Sorry if I'm just repeating arguments that led to its adoption in the first place - I wasn't there when that happened. -- Simon. > Maybe it won't be a big deal, the issue currently is the line is > blurred on what gets templated and what doesn't. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive
Ihar Hrachyshka writes: > I just saw the plan merged in master: > https://review.openstack.org/#/c/451492/ That's cool! Can we also > backport the change to Ocata and maybe Newton so that we don't hit the > same bug there? The backport is already up: > https://review.openstack.org/#/c/456506/ For Ocata this makes sense, but note that the Newton UCA doesn't include the libvirt-bin package. -- Simon. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][nova] Config drive claims ipv6_dhcp, neutron api says slaac
Clark Boylan writes:
[...]
> {
> "id": "network1",
> "link": "tap14b906ba-8c",
> "network_id": "7ee08c00-7323-4f18-94bb-67e081520e70",
> "type": "ipv6_dhcp"
> }
> ],
> "services": []
> }
> You'll notice that the network1 entry has a type of ipv6_dhcp; however,
> if you ask the neutron api it tells slaac is the ipv6_address_mode and
> ipv6_ra_mode. But enable_dhcp is also set to True. So which is it? Is
> there a bug here or am I missing something obvious? At the very least it
> appears that the config drive info is incomplete and does not include
> the slaac info.
Here's my hypothesis... "type ipvX_dhcp" really means "Neutron will
manage ipvX addresses", not necessarily that it will use the DHCP
protocol. For IPv4 it will always imply DHCP, but for IPv6 the method
to tell the port user (instance) the address might be SLAAC (for the
"slaac" and "dhcpv6-stateless" modes) or Stateful DHCPv6 (for the
"dhcpv6-stateful" mode).
I think it would indeed be useful to convey the ipv6_address_mode (and
maybe also ipv6_ra_mode) in the metadata; but in principle a system
should be able to infer the supported mode by looking at the flags in
the RAs (Router Advertisements). It's just that most GNU/Linux
distributions ignore what the RAs say :-( so you need to configure
/etc/network/interfaces explicitly for either "auto" (SLAAC) or "dhcp"
(DHCPv6).)
--
Simon.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder
Emilien Macchi writes: > DIB folks: please confirm on this thread that you're ok to move out > DIB from TripleO and be an independent project. As a DIB user (and occasional contributor of patches in the past) and TripleO non-user, I'm in favor of the separation. > Also please decide if we want it part of the Big Tent or not (it will > require a PTL). No opinion. -- Simon. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [DIB] [TripleO] Should we have a DIB meeting?
Stephane Miller writes: > I'm proposing that we have a regular, IRC-based meeting for the > project. This could be done on its own, or as part of the TripleO > meeting. I don't think we necessarily need to do this every week, but > a fortnightly chance to get together to chat about big changes, > design, etc would be great. > DIB and TripleO DIB community, what are your thoughts? +1 As a DIB (but otherwise not TripleO) user, I would welcome this. -- Simon. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it
Martinx writes: > 1- Create and maintain a Ubuntu PPA Archive to host Neutron with IPv6 > patches (from Nephos6 / Shixiong?). [...] > Let me know if there are interest on this... Great initiative! We're building a new Icehouse cluster soon and are very interested in trying these packages, because we really want to support IPv6 properly. I see you already got some help from the developers - cool! -- Simon. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Meeting time - change to 1300 UTC or 1500 UTC?
Collins, Sean writes: > Looking at the calendar, our options for 1500 UTC require us to change > the day that we meet. The following days are available: > * Tuesdays > * Fridays > Thoughts? For what it's worth (I haven't been contributing so far but I'm very interested in the topic and would eventually like to help), I also have a slight preference for Tuesdays. -- Simon. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
