From fungi at yuggoth.org Mon Nov 19 00:04:26 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 19 Nov 2018 00:04:26 +0000 Subject: [all] We've combined the lists! Now what? In-Reply-To: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> Message-ID: <20181119000426.hpgshg6ln5652pvt@yuggoth.org> As previously discussed[0], proposed[1] and subsequently announced[2], the openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists are being replaced by this new mailing list to which you've subscribed. As of now it's officially open for posts from subscribers, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. Here follows few brief notes on the nature of this new list: 1. Like mentioned in the original announcement, there is an etherpad[3] where we can brainstorm subject tags we want to use. I think most of our needs are already covered there, but I'll give it a little longer to collect more ideas before I attempt to document them somewhere durable. We've already got these as a start: all, ops, dev, $projectname, $signame-sig, $groupname-wg, release, goals, uc, tc, ptl. Because we're interested in moving to Mailman 3 as our listserv in the not-too-distant future and the upstream Mailman maintainers decided to drop support for server-side topic filters, you'll need to set up client-side mail filtering if you're only interested in seeing messages for a subset of them. 2. As I've subscribed the new list to the old ones, cross-posts between them may result in some message duplication, but at least we won't have to endure it for long. 3. Remember there is no Subject header mangling on this list, so if you want to perform client-side matching it's strongly recommended you use the List-Id header to identify it. You'll likely also notice there is no list footer appended to every message. These changes in behavior from our previous lists are part of an effort to avoid creating unnecessary DMARC/DKIM violations. 4. This list is starting out with 280 early subscribers, but I expect a bunch more before the old lists are finally closed down in 3 weeks' time. [0] https://etherpad.openstack.org/p/infra-ptg-denver-2018 [1] http://lists.openstack.org/pipermail/openstack-dev/2018-August/134046.html [2] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html [3] https://etherpad.openstack.org/p/common-openstack-ml-topics -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From ken at jots.org Mon Nov 19 01:12:46 2018 From: ken at jots.org (Ken D'Ambrosio) Date: Sun, 18 Nov 2018 20:12:46 -0500 Subject: [Openstack] (Juno - *sigh*) Want non-admin access to hypervisor:VM association. In-Reply-To: References: <2bf0febb434f77cf5e717565117722b7@jots.org> Message-ID: <2cec061784872132eb7fdb514da64db1@jots.org> On 2018-11-18 09:11, Mohammed Naser wrote: > https://blueprints.launchpad.net/nova/+spec/openstack-api-hostid > > This should take care of it, don't know if it exists in Juno though. It *does* exist in Juno, it *can't*, however, do what I want -- at least, generically. The hostId that gets returned is a value that's (apparently) used to let you know, semi-anonymously, how affinity is (or isn't) working for your VMs. So you get a unique identifier for each hypervisor -- but it has no *obvious* bearing on the hostname. It's an id that's formed from the SHA224 hash of the ID of your tenant and the hostname of the hypervisor -- a bit of a catch-22, that, and prevents you from being able to make use of the hash if you don't know your back-end. But... I do. So I created an associative array with all the current (and, God willing, future) hypervisor hostnames in my company, with the key being the hostId/hash, and the value being the hypervisor name. Then I queried my VMs, got all the hostIds, used that as the index to query my associative array, and bingo! My hypervisor's name. Kinda fugly, but when you have a standardized hypervisor hostname nomenclature, it's sufficient, without having to go mucking about with changing poorly-documented Nova policy.json stuff in a four-year-old release of OpenStack. I'll take it. Thanks! -Ken > On Thu, Nov 15, 2018 at 1:49 PM Ken D'Ambrosio wrote: > >> Hey, all. We've got a Juno cloud, and we'd like various end-users to be >> able to see which hypervisors their VMs spring up on. >> /etc/nova/policy.json seems to have some relevant info, but it's hard to >> tell what does what. "compute_extension:hypervisors" looks like a >> possible candidate, but that's so vague that there's no telling what, >> exactly, is meant by "hypervisors". So: >> >> * Given that I just want the hypervisor:VM association, any suggestions >> as to which rule(s) to modify? >> * Failing that, wondering if there's any for-real documentation on what >> the various options in policy.json *do*. I've found many, many lists of >> what's in a generic policy.json, but nothing that went into detail about >> what does what. >> >> Thanks! >> >> -Ken >> >> _______________________________________________ >> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> Post to : openstack at lists.openstack.org >> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > -- > Mohammed Naser -- vexxhost > > ----------------------------------------------------- > D. 514-316-8872 > D. 800-910-1726 ext. 200 > E. mnaser at vexxhost.com > W. http://vexxhost.com [1] Links: ------ [1] http://vexxhost.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From yjf1970231893 at gmail.com Mon Nov 19 01:45:21 2018 From: yjf1970231893 at gmail.com (Jeff Yang) Date: Mon, 19 Nov 2018 09:45:21 +0800 Subject: [openstack-dev] [octavia] Please give me some comments about my patchs Message-ID: Hi, Octavia Team: There are two patches I committed: https://review.openstack.org/#/c/590620/ https://review.openstack.org/#/c/594040/ The first implement l7policy and l7rule's quota management. The second provides some restrictions about the protocol when listener is associated with pool. I think these functions are useful for users. I hope to receive some suggestions from you. Thinks. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From eumel at arcor.de Mon Nov 19 09:18:27 2018 From: eumel at arcor.de (Frank Kloeker) Date: Mon, 19 Nov 2018 10:18:27 +0100 Subject: [docs][i18n] Team meeting proposal Message-ID: Hello, in the last weeks we had some informal discussions about combined team meeting for documentation and translation team. There should be overlapping topics and other project teams or operator would have the same contact persons on the same place. We also save resources on meeting chairs. Here are my proposal: 1) Meeting room #openstack-meeting 2) Switch back from (informal) Office Hour to (formal) Team Meeting. Topics for upcoming meetings will be collected on a Wiki page. If there are no topic we would skip the meeting. So often we recorded empty sessions in the past. 3) Meeting time is Thursday 07:00 UTC (odd week), 16:00 UTC (even week) 4) First part (30 min) I18n topics, second part documentation topics, meetingbot will recorded two sessions, so it's easier to read specific topics later. 5) Rotating meeting chairs between the two teams. This should renew a little bit the conversation and we are more flexible and visible on the move. kind regards Frank (PTL I18n) From cdent+os at anticdent.org Mon Nov 19 10:56:19 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Mon, 19 Nov 2018 10:56:19 +0000 (GMT) Subject: [all] maintainers/reviewers/committers wanted for tiny projects Message-ID: I was recently going through the list of things to which I'm trying to pay attention and realized there are quite a few small software projects that are OpenStack-related that could do with additional attention because I'm either the sole or one of few maintainers. Some of these are hosted on OpenStack^wOpendev infra, some not. If you're interested in helping out, please have a look and feel free to ask me questions. Many are in some state of either disrepair or incompleteness because they were adopted from absentee owners. Paste: WSGI middleware management framework https://github.com/cdent/paste This was recently adopted because it had issues with Python 3.7 and there were concerns that OpenStack's continued use might present problems. I've also just inherited the pastedeploy package, and will be migrating it over to github too. It will also need some help. Use Flask instead. WSME: Web Service Made Easy (ha!) http://git.openstack.org/cgit/openstack/wsme For a brief period back in the day, this was the recommended way to make a web service in OpenStack. Soon after that it was abandoned by its maintainers and Lucas Gomez and I were press-ganged into maintaining it. It still gets the occasional patch to fix testing or Python 3 -related bugs. Does anyone still use this? Use Flask instead. microversion-parse: Library and WSGI middleware for parsing microversion headers http://git.openstack.org/cgit/openstack/microversion-parse This was extracted from placement's implementation for handling microversions. It tries to be framework agnostic, but is biased somewhat towards WebOb. It's nominally under the management of the API-SIG but it would be good to see it getting more use and thus more fixes. It's also used in Nova, not sure where else. wsgi-intercept: Intercept socket connection to wsgi applications for testing https://github.com/cdent/wsgi-intercept A convenient way to do functional testing of WSGI applications without needing to run a separate process but while still doing legit HTTP. Is used in nova and placement, and may still be used in the telemetry projects. It's old but very useful. It's at the core of gabbi. gabbi: Declarative HTTP Testing for Python and anything else https://github.com/cdent/gabbi YAML-driven testing of HTTP APIs that makes live _so_ _much_ _easier_. Was developed when I was working on telemetry, and is now central to the functional testing of placement. gabbi-tempest: A tempest plugin for using gabbi https://git.openstack.org/cgit/openstack/gabbi-tempest A tempest plugin + zuul job to make it super easy to use gabbi tests for driving integration tests in OpenStack, by mostly adding some YAML. If you're interested, great! Please let me know or simply start fixing things. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From eumel at arcor.de Mon Nov 19 11:20:28 2018 From: eumel at arcor.de (Frank Kloeker) Date: Mon, 19 Nov 2018 12:20:28 +0100 Subject: [ops][docs] operations-docs on StoryBoard Message-ID: <98fe25d40449a0c95532981ddb9e80ce@arcor.de> Hello, I've started today with a proposal on [1] to add docs for operations on StoryBoard [2].That could be useful to track bugs that people raise while reading the document. Also a rework for parts of the document could be planned in StoryBoard. A reference might be the work on the Contributor Guide which is mostly maintained in [3]. kind regards Frank [1] https://review.openstack.org/#/c/618722/ [2] https://storyboard.openstack.org [3] https://storyboard.openstack.org/#!/project/openstack/contributor-guide From tobias.urdin at binero.se Mon Nov 19 08:17:34 2018 From: tobias.urdin at binero.se (Tobias Urdin) Date: Mon, 19 Nov 2018 09:17:34 +0100 Subject: [openstack-dev] [puppet] [stable] Deprecation of newton branches Message-ID: <2ae10ca2-8c77-ccbc-c009-a22c1d3cfd69@binero.se> Hello, We've been talking for a while about the deprecation and removal of the stable/newton branches. I think it's time now that we get rid of them, we have no open patches and Newton is considered EOL. Could cores get back with a quick feedback and then the stable team can get rid of those whenever they have time. Best regards Tobias __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From melwittt at gmail.com Mon Nov 19 09:17:08 2018 From: melwittt at gmail.com (melanie witt) Date: Mon, 19 Nov 2018 10:17:08 +0100 Subject: [nova] Stein forum session notes Message-ID: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> Hey all, Here's some notes I took in forum sessions I attended -- feel free to add notes on sessions I missed. Etherpad links: https://wiki.openstack.org/wiki/Forum/Berlin2018 Cheers, -melanie TUE --- Cells v2 updates ================ - Went over the etherpad, no objections to anything - Not directly related to the session, but CERN (hallway track) and NeCTAR (dev ML) have both given feedback and asked that the policy-driven idea for handling quota for down cells be avoided. Revived the "propose counting quota in placement" spec to see if there's any way forward here Getting users involved in the project ===================================== - Disconnect between SIGs/WGs and project teams - Too steep a first step to get involved by subscribing to ML - People confused about how to participate Community outreach when culture, time zones, and language differ ================================================================ - Most discussion around how to synchronize real-time communication considering different time zones - Best to emphasize asynchronous communication. Discussion on ML and gerrit reviews - Helpful to create weekly meeting agenda in advance so contributors from other time zones can add notes/response to discussion items WED --- NFV/HPC pain points =================== Top issues for immediate action: NUMA-aware live migration (spec just needs re-approval), improved scheduler logging (resurrect cfriesen's patch and clean it up), distant third is SRIOV live migration BFV improvements ================ - Went over the etherpad, no major objections to anything - Agree: we should expose boot_index from the attachments API - Unclear what to do about post-create delete_on_termination. Being able to specify it for attach sounds reasonable, but is it enough for those asking? Or would it end up serving no one? Better expose what we produce ============================= - Project teams should propose patches to openstack/openstack-map to improve their project pages - Would be ideal if project pages included a longer paragraph explaining the project, have a diagram, list SIGs/WGs related to the project, etc Blazar reservations to new resource types ========================================= - For nova compute hosts, reservations are done by putting reserved hosts into "blazar" host aggregate and then a special scheduler filter is used to exclude those hosts from scheduling. But how to extend that concept to other projects? - Note: the nova approach will change from scheduler filter => placement request filter Edge use cases and requirements =============================== - Showed the reference architectures again - Most popular use case was "Mobile service provider 5G/4G virtual RAN deployment and Edge Cloud B2B2X" with seven +1s on the etherpad Deletion of project and project resources ========================================= - What is wanted: a delete API per service that takes a project_id and force deletes all resources owned by it with --dry-run component - Challenge to work out the dependencies for the order of deletion of all resources in all projects. Disable project, then delete things in order of dependency - Idea: turn os-purge into a REST API and each project implement a plugin for it Getting operators' bug fixes upstreamed ======================================= - Problem: operator reports a bug and provides a solution, for example, pastes a diff in launchpad or otherwise describes how to fix the bug. How can we increase the chances of those fixes making it to gerrit? - Concern: are there legal issues with accepting patches pasted into launchpad by someone who hasn't signed the ICLA? - Possible actions: create a best practices guide tailored for operators and socialize it among the ops docs/meetup/midcycle group. Example: guidance on how to indicate you don't have time to add test coverage, etc when you propose a patch THU --- Bug triage: why not all the community? ====================================== - Cruft and mixing tasks with defect reports makes triage more difficult to manage. Example: difference between a defect reported by a user vs an effective TODO added by a developer. If New bugs were reliably from end users, would we be more likely to triage? - Bug deputy weekly ML reporting could help - Action: copy the generic portion of the nova bug triage wiki doc into the contributor guide docs. The idea/hope being that easy-to-understand instructions available to the wider community might increase the chances of people outside of the project team being capable of triaging bugs, so all of it doesn't fall on project teams - Idea: should we remove the bug supervisor requirement from nova to allow people who haven't joined the bug team to set Status and Importance? Current state of volume encryption ================================== - Feedback: public clouds can't offer encryption because keys are stored in the cloud. Telcos are required to make sure admin can't access secrets. Action: SecuStack has a PoC for E2E key transfer, mnaser to help see what could be upstreamed - Features needed: ability for users to provide keys or use customer barbican or other key store. Thread: http://lists.openstack.org/pipermail/openstack-dev/2018-November/136258.html Cross-technical leadership session (OpenStack, Kata, StarlingX, Airship, Zuul) ======================================================================== - Took down the structure of how leadership positions work in each project on the etherpad, look at differences - StarlingX taking a new approach for upstreaming, New strategy: align with master, analyze what they need, and address the gaps (as opposed to pushing all the deltas up). Bug fixes still need to be brought forward, that won't change Concurrency limits for service instance creation ================================================ - Looking for ways to test and detect changes in performance as a community. Not straightforward because test hardware must stay consistent in order to detect performance deltas, release to release. Infra can't provide such an environment - Idea: it could help to write up a doc per project with a list of the usual tunables and basic info about how to use them Change of ownership of resources ================================ - Ignore the network piece for now, it's the most complicated. Being able to transfer everything else would solve 90% of City Network's use cases - Some ideas around having this be a keystone auth-based access granting instead of an update of project/user, but if keystone could hand user A a token for user B, that token would apply to all resources of user B's, not just the ones desired for transfer Update on placement extraction from nova ======================================== - Upgrade step additions from integrated placement to extracted placement in TripleO and OpenStackAnsible are being worked on now - Reshaper patches for libvirt and xenapi drivers are up for review - Lab test for vGPU upgrade and reshape + new schedule for libvirt driver patch has been done already - FFU script work needs an owner. Will need to query libvirtd to get mdevs and use PlacementDirect to populate placement Python bindings for the placement API ===================================== - Placement client code replicated in different projects: nova, blazar, neutron, cyborg. Want to commonize into python bindings lib - Consensus was that the placement bindings should go into openstacksdk and then projects will consume it from there T series community goal discussion ================================== - Most popular goal ideas: Finish moving legacy python-*client CLIs to python-openstackclient, Deletion of project resources as discussed in forum session earlier in the week, ensure all projects use ServiceTokens when calling one another with incoming token From jaosorior at redhat.com Mon Nov 19 10:15:13 2018 From: jaosorior at redhat.com (Juan Antonio Osorio Robles) Date: Mon, 19 Nov 2018 12:15:13 +0200 Subject: [openstack-dev] [tripleo] Proposing Enrique Llorente Pastora as a core reviewer for TripleO In-Reply-To: References: Message-ID: <756fbdc1-124c-7540-c769-badd57859988@redhat.com> +1 on making him tripleo-ci core. Great work! On 11/15/18 5:50 PM, Sagi Shnaidman wrote: > Hi, > I'd like to propose Quique (@quiquell) as a core reviewer for TripleO. > Quique is actively involved in improvements and development of TripleO > and TripleO CI. He also helps in other projects including but not > limited to Infrastructure. > He shows a very good understanding how TripleO and CI works and I'd > like suggest him as core reviewer of TripleO in CI related code. > > Please vote! > My +1 is here :) > > Thanks > -- > Best regards > Sagi Shnaidman > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From gcerami at redhat.com Mon Nov 19 11:44:29 2018 From: gcerami at redhat.com (Gabriele Cerami) Date: Mon, 19 Nov 2018 11:44:29 +0000 Subject: [openstack-dev] [tripleo] Proposing Enrique Llorente Pastora as a core reviewer for TripleO In-Reply-To: References: Message-ID: <20181119114429.6qoeir3bquor74tt@localhost> On 15 Nov, Sagi Shnaidman wrote: > Hi, > I'd like to propose Quique (@quiquell) as a core reviewer for TripleO. > Quique is actively involved in improvements and development of TripleO and > TripleO CI. He also helps in other projects including but not limited to > Infrastructure. It'll be grand. +1 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From amotoki at gmail.com Mon Nov 19 12:19:21 2018 From: amotoki at gmail.com (Akihiro Motoki) Date: Mon, 19 Nov 2018 21:19:21 +0900 Subject: [openstack-dev] [horizon] how to get horizon related logs to syslog? In-Reply-To: References: Message-ID: Hi, Horizon logging depends on Django configuration which supports full python logging [1]. [1] does not provide enough examples. Perhaps [2] will help you (though I haven't tested it). [1] https://docs.djangoproject.com/en/2.0/topics/logging/ [2] https://www.simonkrueger.com/2015/05/27/logging-django-apps-to-syslog.html Thanks, Akihiro 2018年11月16日(金) 18:47 Tikkanen, Viktor (Nokia - FI/Espoo) < viktor.tikkanen at nokia.com>: > Hi! > > For most openstack parts (e.g. Aodh, Cinder, Glance, Heat, Ironic, > Keystone, Neutron, Nova) it was easy to get logs to syslog. > > For example for Heat something similar to this (into file > templates/heat.conf.j2): > > # Syslog usage > {% if heat_syslog_enabled %} > use_syslog = True > syslog_log_facility = LOG_LOCAL3 > {% else %} > log_file = /var/log/heat/heat.log > {% endif %} > > But how to get Horizon related logs to syslog? > > -V. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From emilien at redhat.com Mon Nov 19 12:42:30 2018 From: emilien at redhat.com (Emilien Macchi) Date: Mon, 19 Nov 2018 07:42:30 -0500 Subject: [openstack-dev] [puppet] [stable] Deprecation of newton branches In-Reply-To: <2ae10ca2-8c77-ccbc-c009-a22c1d3cfd69@binero.se> References: <2ae10ca2-8c77-ccbc-c009-a22c1d3cfd69@binero.se> Message-ID: +1 for me, I haven't seen much interest in keeping these branches for puppet modules. I also would like to hear from our users though. On Mon, Nov 19, 2018 at 3:18 AM Tobias Urdin wrote: > Hello, > > We've been talking for a while about the deprecation and removal of the > stable/newton branches. > I think it's time now that we get rid of them, we have no open patches > and Newton is considered EOL. > > Could cores get back with a quick feedback and then the stable team can > get rid of those whenever they have time. > > Best regards > Tobias > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From mnaser at vexxhost.com Mon Nov 19 12:48:29 2018 From: mnaser at vexxhost.com (Mohammed Naser) Date: Mon, 19 Nov 2018 07:48:29 -0500 Subject: [openstack-dev] [puppet] [stable] Deprecation of newton branches In-Reply-To: References: <2ae10ca2-8c77-ccbc-c009-a22c1d3cfd69@binero.se> Message-ID: With my core hat, I would give it a +1. At this point, it has no open patches and the last one we merged was 7 months ago. https://review.openstack.org/#/q/projects:openstack/puppet-+-project:openstack/puppet-tripleo+branch:stable/newton+is:open https://review.openstack.org/#/q/projects:openstack/puppet-+-project:openstack/puppet-tripleo+branch:stable/newton+is:merged I can't speak about it as an operator as we don't run anything that old. On Mon, Nov 19, 2018 at 7:43 AM Emilien Macchi wrote: > +1 for me, I haven't seen much interest in keeping these branches for > puppet modules. > I also would like to hear from our users though. > > On Mon, Nov 19, 2018 at 3:18 AM Tobias Urdin > wrote: > >> Hello, >> >> We've been talking for a while about the deprecation and removal of the >> stable/newton branches. >> I think it's time now that we get rid of them, we have no open patches >> and Newton is considered EOL. >> >> Could cores get back with a quick feedback and then the stable team can >> get rid of those whenever they have time. >> >> Best regards >> Tobias >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > -- > Emilien Macchi > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser at vexxhost.com W. http://vexxhost.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From iurygregory at gmail.com Mon Nov 19 12:55:30 2018 From: iurygregory at gmail.com (Iury Gregory) Date: Mon, 19 Nov 2018 13:55:30 +0100 Subject: [openstack-dev] [puppet] [stable] Deprecation of newton branches In-Reply-To: References: <2ae10ca2-8c77-ccbc-c009-a22c1d3cfd69@binero.se> Message-ID: +1 for me Em seg, 19 de nov de 2018 às 13:51, Mohammed Naser escreveu: > With my core hat, I would give it a +1. At this point, it has no open > patches and the last one we merged was 7 months ago. > > > https://review.openstack.org/#/q/projects:openstack/puppet-+-project:openstack/puppet-tripleo+branch:stable/newton+is:open > > https://review.openstack.org/#/q/projects:openstack/puppet-+-project:openstack/puppet-tripleo+branch:stable/newton+is:merged > > I can't speak about it as an operator as we don't run anything that old. > > On Mon, Nov 19, 2018 at 7:43 AM Emilien Macchi wrote: > >> +1 for me, I haven't seen much interest in keeping these branches for >> puppet modules. >> I also would like to hear from our users though. >> >> On Mon, Nov 19, 2018 at 3:18 AM Tobias Urdin >> wrote: >> >>> Hello, >>> >>> We've been talking for a while about the deprecation and removal of the >>> stable/newton branches. >>> I think it's time now that we get rid of them, we have no open patches >>> and Newton is considered EOL. >>> >>> Could cores get back with a quick feedback and then the stable team can >>> get rid of those whenever they have time. >>> >>> Best regards >>> Tobias >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> -- >> Emilien Macchi >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > -- > Mohammed Naser — vexxhost > ----------------------------------------------------- > D. 514-316-8872 > D. 800-910-1726 ext. 200 > E. mnaser at vexxhost.com > W. http://vexxhost.com > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From lijie at unitedstack.com Mon Nov 19 12:58:31 2018 From: lijie at unitedstack.com (=?utf-8?B?UmFtYm8=?=) Date: Mon, 19 Nov 2018 20:58:31 +0800 Subject: [openstack-dev] [glance] about use shared image with each other Message-ID: Hi,all Recently, I want to use the shared image with each other.I find it isn't convenient that the producer notifies the consumer via email which the image has been shared and what its UUID is. In other words, why the image api v2 is no provision for producer-consumer communication? To make it is more convenient, if we can add a task to change the member_status from "pending" to "accepted" when we share the image with each other. It is similar to the resize_confirm in Nova, we can control the time interval in config. Can you tell me more about this?Thank you very much! Best Regards Rambo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From rosmaita.fossdev at gmail.com Mon Nov 19 13:15:21 2018 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Mon, 19 Nov 2018 08:15:21 -0500 Subject: [glance] time to adjust your ML filters Message-ID: <962d08ec-c711-39fd-c9dd-c8b62e219c61@gmail.com> Hello Glancers, This message is sent from the new openstack-discuss mailing list so that you have a reference point from which to adjust your email filters. See Jeremy's message from earlier today [0] for more information about the new ML. cheers, brian [0] http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000000.html From mriedemos at gmail.com Mon Nov 19 13:15:39 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Mon, 19 Nov 2018 07:15:39 -0600 Subject: [openstack-dev] [nova] Can we deprecate the server backup API please? In-Reply-To: References: <7778dd25-53f8-ca5c-55c5-0c0e6db29be4@gmail.com> Message-ID: On 11/18/2018 6:51 AM, Alex Xu wrote: > Sounds make sense to me, and then we needn't fix this strange behaviour > also https://review.openstack.org/#/c/409644/ The same discussion was had in the spec for that change: https://review.openstack.org/#/c/511825/ Ultimately it amounted to a big "meh, let's just not fix the bug but also no one really cares about deprecating the API either". The only thing deprecating the API would do is signal that it probably shouldn't be used. We would still support it on older microversions. If all anyone cares about is signalling not to use the API then deprecation is probably fine, but I personally don't feel too strongly about it either way. -- Thanks, Matt __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From jaypipes at gmail.com Mon Nov 19 13:31:59 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Mon, 19 Nov 2018 08:31:59 -0500 Subject: [openstack-dev] [nova] Stein forum session notes In-Reply-To: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> Message-ID: <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> Thanks for the highlights, Melanie. Appreciated. Some thoughts inline... On 11/19/2018 04:17 AM, melanie witt wrote: > Hey all, > > Here's some notes I took in forum sessions I attended -- feel free to > add notes on sessions I missed. > > Etherpad links: https://wiki.openstack.org/wiki/Forum/Berlin2018 > > Cheers, > -melanie > > > TUE > --- > > Cells v2 updates > ================ > - Went over the etherpad, no objections to anything > - Not directly related to the session, but CERN (hallway track) and > NeCTAR (dev ML) have both given feedback and asked that the > policy-driven idea for handling quota for down cells be avoided. Revived > the "propose counting quota in placement" spec to see if there's any way > forward here \o/ > Getting users involved in the project > ===================================== > - Disconnect between SIGs/WGs and project teams > - Too steep a first step to get involved by subscribing to ML > - People confused about how to participate Seriously? If subscribing to a mailing list is seen as too much of a burden for users to provide feedback, I'm wondering what the point is of having an open source community at all. > Community outreach when culture, time zones, and language differ > ================================================================ > - Most discussion around how to synchronize real-time communication > considering different time zones > - Best to emphasize asynchronous communication. Discussion on ML and > gerrit reviews +1 > - Helpful to create weekly meeting agenda in advance so contributors > from other time zones can add notes/response to discussion items +1, though I think it's also good to be able to say "look, nobody has brought up anything they'd like to discuss this week so let's not take time out of people's busy schedules if there's nothing to discuss". > WED > --- > > NFV/HPC pain points > =================== > Top issues for immediate action: NUMA-aware live migration (spec just > needs re-approval), improved scheduler logging (resurrect cfriesen's > patch and clean it up), distant third is SRIOV live migration > > BFV improvements > ================ > - Went over the etherpad, no major objections to anything > - Agree: we should expose boot_index from the attachments API > - Unclear what to do about post-create delete_on_termination. Being able > to specify it for attach sounds reasonable, but is it enough for those > asking? Or would it end up serving no one? > > Better expose what we produce > ============================= > - Project teams should propose patches to openstack/openstack-map to > improve their project pages > - Would be ideal if project pages included a longer paragraph explaining > the project, have a diagram, list SIGs/WGs related to the project, etc > > Blazar reservations to new resource types > ========================================= > - For nova compute hosts, reservations are done by putting reserved > hosts into "blazar" host aggregate and then a special scheduler filter > is used to exclude those hosts from scheduling. But how to extend that > concept to other projects? > - Note: the nova approach will change from scheduler filter => placement > request filter Didn't we agree in Denver to use a placement request filter that generated a forbidden aggregate request for this? I know Matt has had concerns about the proposed spec for forbidden aggregates not adequately explaining the Nova side configuration, but I was under the impression the general idea of using a forbidden aggregate placement request filter was a good one? > Edge use cases and requirements > =============================== > - Showed the reference architectures again > - Most popular use case was "Mobile service provider 5G/4G virtual RAN > deployment and Edge Cloud B2B2X" with seven +1s on the etherpad Snore. Until one of those +1s is willing to uncouple nova-compute's tight use of rabbitmq and RDBMS-over-rabbitmq that we use as our control plane in Nova, all the talk of "edge" this and "MEC" that is nothing more than ... well, talk. > Deletion of project and project resources > ========================================= > - What is wanted: a delete API per service that takes a project_id and > force deletes all resources owned by it with --dry-run component > - Challenge to work out the dependencies for the order of deletion of > all resources in all projects. Disable project, then delete things in > order of dependency > - Idea: turn os-purge into a REST API and each project implement a > plugin for it I don't see why a REST API would be needed. We could more easily implement the functionality by focusing on a plugin API for each service project and leaving it at that. > Getting operators' bug fixes upstreamed > ======================================= > - Problem: operator reports a bug and provides a solution, for example, > pastes a diff in launchpad or otherwise describes how to fix the bug. > How can we increase the chances of those fixes making it to gerrit? > - Concern: are there legal issues with accepting patches pasted into > launchpad by someone who hasn't signed the ICLA? > - Possible actions: create a best practices guide tailored for operators > and socialize it among the ops docs/meetup/midcycle group. Example: > guidance on how to indicate you don't have time to add test coverage, > etc when you propose a patch > > THU > --- > > Bug triage: why not all the community? > ====================================== > - Cruft and mixing tasks with defect reports makes triage more difficult > to manage. Example: difference between a defect reported by a user vs an > effective TODO added by a developer. If New bugs were reliably from end > users, would we be more likely to triage? > - Bug deputy weekly ML reporting could help > - Action: copy the generic portion of the nova bug triage wiki doc into > the contributor guide docs. The idea/hope being that easy-to-understand > instructions available to the wider community might increase the chances > of people outside of the project team being capable of triaging bugs, so > all of it doesn't fall on project teams > - Idea: should we remove the bug supervisor requirement from nova to > allow people who haven't joined the bug team to set Status and Importance? > > Current state of volume encryption > ================================== > - Feedback: public clouds can't offer encryption because keys are stored > in the cloud. Telcos are required to make sure admin can't access > secrets. Action: SecuStack has a PoC for E2E key transfer, mnaser to > help see what could be upstreamed > - Features needed: ability for users to provide keys or use customer > barbican or other key store. Thread: > http://lists.openstack.org/pipermail/openstack-dev/2018-November/136258.html > > > Cross-technical leadership session (OpenStack, Kata, StarlingX, Airship, > Zuul) > ======================================================================== > - Took down the structure of how leadership positions work in each > project on the etherpad, look at differences > - StarlingX taking a new approach for upstreaming, New strategy: align > with master, analyze what they need, and address the gaps (as opposed to > pushing all the deltas up). Bug fixes still need to be brought forward, > that won't change > > Concurrency limits for service instance creation > ================================================ > - Looking for ways to test and detect changes in performance as a > community. Not straightforward because test hardware must stay > consistent in order to detect performance deltas, release to release. > Infra can't provide such an environment > - Idea: it could help to write up a doc per project with a list of the > usual tunables and basic info about how to use them > > Change of ownership of resources > ================================ > - Ignore the network piece for now, it's the most complicated. Being > able to transfer everything else would solve 90% of City Network's use > cases > - Some ideas around having this be a keystone auth-based access granting > instead of an update of project/user, but if keystone could hand user A > a token for user B, that token would apply to all resources of user B's, > not just the ones desired for transfer Whatever happened with the os-chown project Dan started in Denver? https://github.com/kk7ds/oschown > Update on placement extraction from nova > ======================================== > - Upgrade step additions from integrated placement to extracted > placement in TripleO and OpenStackAnsible are being worked on now > - Reshaper patches for libvirt and xenapi drivers are up for review > - Lab test for vGPU upgrade and reshape + new schedule for libvirt > driver patch has been done already This is news to me. Can someone provide me a link to where I can get some more information about this? > - FFU script work needs an owner. Will need to query libvirtd to get > mdevs and use PlacementDirect to populate placement > > Python bindings for the placement API > ===================================== > - Placement client code replicated in different projects: nova, blazar, > neutron, cyborg. Want to commonize into python bindings lib > - Consensus was that the placement bindings should go into openstacksdk > and then projects will consume it from there > > T series community goal discussion > ================================== > - Most popular goal ideas: Finish moving legacy python-*client CLIs to > python-openstackclient, Deletion of project resources as discussed in > forum session earlier in the week, ensure all projects use ServiceTokens > when calling one another with incoming token > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From jaypipes at gmail.com Mon Nov 19 13:36:40 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Mon, 19 Nov 2018 08:36:40 -0500 Subject: [openstack-dev] [nova] Can we deprecate the server backup API please? In-Reply-To: References: <7778dd25-53f8-ca5c-55c5-0c0e6db29be4@gmail.com> Message-ID: On 11/19/2018 08:15 AM, Matt Riedemann wrote: > On 11/18/2018 6:51 AM, Alex Xu wrote: >> Sounds make sense to me, and then we needn't fix this strange >> behaviour also https://review.openstack.org/#/c/409644/ > > The same discussion was had in the spec for that change: > > https://review.openstack.org/#/c/511825/ > > Ultimately it amounted to a big "meh, let's just not fix the bug but > also no one really cares about deprecating the API either". So we'll let the apathy of the past dictate the actions of the future. > The only thing deprecating the API would do is signal that it probably > shouldn't be used. We would still support it on older microversions. If > all anyone cares about is signalling not to use the API then deprecation > is probably fine, but I personally don't feel too strongly about it > either way. Deprecating these kinds of APIs would, as I mentioned in my original post, signal that the Nova team is actually serious about cleaning up the cruft and getting rid of the debt from years past. And also that it is serious about Nova not being a dumping ground for orchestration and out-of-scope APIs not related to a Compute API. Best, -jay From smooney at redhat.com Mon Nov 19 13:54:26 2018 From: smooney at redhat.com (Sean Mooney) Date: Mon, 19 Nov 2018 13:54:26 +0000 Subject: [openstack-dev] [nova] Stein forum session notes In-Reply-To: <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> Message-ID: On Mon, 2018-11-19 at 08:31 -0500, Jay Pipes wrote: > Thanks for the highlights, Melanie. Appreciated. Some thoughts inline... > > On 11/19/2018 04:17 AM, melanie witt wrote: > > Hey all, > > > > Here's some notes I took in forum sessions I attended -- feel free to > > add notes on sessions I missed. > > > > Etherpad links: https://wiki.openstack.org/wiki/Forum/Berlin2018 > > > > Cheers, > > -melanie > > > > > > TUE > > --- > > > > Cells v2 updates > > ================ > > - Went over the etherpad, no objections to anything > > - Not directly related to the session, but CERN (hallway track) and > > NeCTAR (dev ML) have both given feedback and asked that the > > policy-driven idea for handling quota for down cells be avoided. Revived > > the "propose counting quota in placement" spec to see if there's any way > > forward here > > \o/ > > > Getting users involved in the project > > ===================================== > > - Disconnect between SIGs/WGs and project teams > > - Too steep a first step to get involved by subscribing to ML > > - People confused about how to participate > > Seriously? If subscribing to a mailing list is seen as too much of a > burden for users to provide feedback, I'm wondering what the point is of > having an open source community at all. > i know when i first started working on openstack i found the volume of mails/irc meeting and gerrit comments to be a little overwelming. them my company started sending 5 times the volume of internal mails and i learned how to use outlook filter to fix both issues and could narrow in on the topics that matter more to me. that said i often still miss things on the mailing list. i think it can be a little daunting but i would still prefer this to useing video confrencing exctra as our primay discution medium to have these types of discussion as that blocks async discussions. as a side note i personally found gerrit discciton much easier to engage with initally as it was eaisr to keep track of the topic i cared about. > > Community outreach when culture, time zones, and language differ > > ================================================================ > > - Most discussion around how to synchronize real-time communication > > considering different time zones > > - Best to emphasize asynchronous communication. Discussion on ML and > > gerrit reviews > > +1 > > > - Helpful to create weekly meeting agenda in advance so contributors > > from other time zones can add notes/response to discussion items > > +1, though I think it's also good to be able to say "look, nobody has > brought up anything they'd like to discuss this week so let's not take > time out of people's busy schedules if there's nothing to discuss". > > > WED > > --- > > > > NFV/HPC pain points > > =================== > > Top issues for immediate action: NUMA-aware live migration (spec just > > needs re-approval), improved scheduler logging (resurrect cfriesen's > > patch and clean it up), distant third is SRIOV live migration > > > > BFV improvements > > ================ > > - Went over the etherpad, no major objections to anything > > - Agree: we should expose boot_index from the attachments API > > - Unclear what to do about post-create delete_on_termination. Being able > > to specify it for attach sounds reasonable, but is it enough for those > > asking? Or would it end up serving no one? > > > > Better expose what we produce > > ============================= > > - Project teams should propose patches to openstack/openstack-map to > > improve their project pages > > - Would be ideal if project pages included a longer paragraph explaining > > the project, have a diagram, list SIGs/WGs related to the project, etc > > > > Blazar reservations to new resource types > > ========================================= > > - For nova compute hosts, reservations are done by putting reserved > > hosts into "blazar" host aggregate and then a special scheduler filter > > is used to exclude those hosts from scheduling. But how to extend that > > concept to other projects? > > - Note: the nova approach will change from scheduler filter => placement > > request filter > > Didn't we agree in Denver to use a placement request filter that > generated a forbidden aggregate request for this? I know Matt has had > concerns about the proposed spec for forbidden aggregates not adequately > explaining the Nova side configuration, but I was under the impression > the general idea of using a forbidden aggregate placement request filter > was a good one? yes that was the direction we agreed to in denver, e.g. a prefilter that ran before the placement call that detected the present or absence of a node or instance reservation uuid in placement and added the anti affintiy request for the blazar aggreate as appropriate we were going to add a not in tree syntax ?in_tree=! to placement to enable this. so all of this would happen before the placemetn call not as an addtion post placement filter. there was also some discussion if we shoudl hardcode a known uuid for the balzer az or if it should be a config option for the filter read from the nova.conf. i belive we also discussed if the prefilter would have to interact with blazers api to validate things such as the flavor requiremetn for the instance reservation case but i think that was TBD with the asuumtion that was not nessiarilly required or could be done post placemetn if needed. the same "not in tree" mechisum was proposed for use with the windows aggregate usecase that tusar rasied i belive but my memory is a little fuzzy on all the details. we captured them in the blazer etherpad howerver i think. > > > Edge use cases and requirements > > =============================== > > - Showed the reference architectures again > > - Most popular use case was "Mobile service provider 5G/4G virtual RAN > > deployment and Edge Cloud B2B2X" with seven +1s on the etherpad > > Snore. > > Until one of those +1s is willing to uncouple nova-compute's tight use > of rabbitmq and RDBMS-over-rabbitmq that we use as our control plane in > Nova, all the talk of "edge" this and "MEC" that is nothing more than > ... well, talk. > > > Deletion of project and project resources > > ========================================= > > - What is wanted: a delete API per service that takes a project_id and > > force deletes all resources owned by it with --dry-run component > > - Challenge to work out the dependencies for the order of deletion of > > all resources in all projects. Disable project, then delete things in > > order of dependency > > - Idea: turn os-purge into a REST API and each project implement a > > plugin for it > > I don't see why a REST API would be needed. We could more easily > implement the functionality by focusing on a plugin API for each service > project and leaving it at that. > > > Getting operators' bug fixes upstreamed > > ======================================= > > - Problem: operator reports a bug and provides a solution, for example, > > pastes a diff in launchpad or otherwise describes how to fix the bug. > > How can we increase the chances of those fixes making it to gerrit? > > - Concern: are there legal issues with accepting patches pasted into > > launchpad by someone who hasn't signed the ICLA? > > - Possible actions: create a best practices guide tailored for operators > > and socialize it among the ops docs/meetup/midcycle group. Example: > > guidance on how to indicate you don't have time to add test coverage, > > etc when you propose a patch > > > > THU > > --- > > > > Bug triage: why not all the community? > > ====================================== > > - Cruft and mixing tasks with defect reports makes triage more difficult > > to manage. Example: difference between a defect reported by a user vs an > > effective TODO added by a developer. If New bugs were reliably from end > > users, would we be more likely to triage? > > - Bug deputy weekly ML reporting could help > > - Action: copy the generic portion of the nova bug triage wiki doc into > > the contributor guide docs. The idea/hope being that easy-to-understand > > instructions available to the wider community might increase the chances > > of people outside of the project team being capable of triaging bugs, so > > all of it doesn't fall on project teams > > - Idea: should we remove the bug supervisor requirement from nova to > > allow people who haven't joined the bug team to set Status and Importance? > > > > Current state of volume encryption > > ================================== > > - Feedback: public clouds can't offer encryption because keys are stored > > in the cloud. Telcos are required to make sure admin can't access > > secrets. Action: SecuStack has a PoC for E2E key transfer, mnaser to > > help see what could be upstreamed > > - Features needed: ability for users to provide keys or use customer > > barbican or other key store. Thread: > > http://lists.openstack.org/pipermail/openstack-dev/2018-November/136258.html > > > > > > Cross-technical leadership session (OpenStack, Kata, StarlingX, Airship, > > Zuul) > > ======================================================================== > > - Took down the structure of how leadership positions work in each > > project on the etherpad, look at differences > > - StarlingX taking a new approach for upstreaming, New strategy: align > > with master, analyze what they need, and address the gaps (as opposed to > > pushing all the deltas up). Bug fixes still need to be brought forward, > > that won't change > > > > Concurrency limits for service instance creation > > ================================================ > > - Looking for ways to test and detect changes in performance as a > > community. Not straightforward because test hardware must stay > > consistent in order to detect performance deltas, release to release. > > Infra can't provide such an environment > > - Idea: it could help to write up a doc per project with a list of the > > usual tunables and basic info about how to use them > > > > Change of ownership of resources > > ================================ > > - Ignore the network piece for now, it's the most complicated. Being > > able to transfer everything else would solve 90% of City Network's use > > cases > > - Some ideas around having this be a keystone auth-based access granting > > instead of an update of project/user, but if keystone could hand user A > > a token for user B, that token would apply to all resources of user B's, > > not just the ones desired for transfer > > Whatever happened with the os-chown project Dan started in Denver? > > https://github.com/kk7ds/oschown > > > Update on placement extraction from nova > > ======================================== > > - Upgrade step additions from integrated placement to extracted > > placement in TripleO and OpenStackAnsible are being worked on now > > - Reshaper patches for libvirt and xenapi drivers are up for review > > - Lab test for vGPU upgrade and reshape + new schedule for libvirt > > driver patch has been done already > > This is news to me. Can someone provide me a link to where I can get > some more information about this? > > > - FFU script work needs an owner. Will need to query libvirtd to get > > mdevs and use PlacementDirect to populate placement > > > > Python bindings for the placement API > > ===================================== > > - Placement client code replicated in different projects: nova, blazar, > > neutron, cyborg. Want to commonize into python bindings lib > > - Consensus was that the placement bindings should go into openstacksdk > > and then projects will consume it from there > > > > T series community goal discussion > > ================================== > > - Most popular goal ideas: Finish moving legacy python-*client CLIs to > > python-openstackclient, Deletion of project resources as discussed in > > forum session earlier in the week, ensure all projects use ServiceTokens > > when calling one another with incoming token > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > From gmann at ghanshyammann.com Mon Nov 19 14:19:51 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 19 Nov 2018 23:19:51 +0900 Subject: [openstack-dev] [nova] Can we deprecate the server backup API please? In-Reply-To: References: <7778dd25-53f8-ca5c-55c5-0c0e6db29be4@gmail.com> Message-ID: <1672c5782e0.b862346189569.6141647533532380260@ghanshyammann.com> ---- On Mon, 19 Nov 2018 22:36:40 +0900 Jay Pipes wrote ---- > On 11/19/2018 08:15 AM, Matt Riedemann wrote: > > On 11/18/2018 6:51 AM, Alex Xu wrote: > >> Sounds make sense to me, and then we needn't fix this strange > >> behaviour also https://review.openstack.org/#/c/409644/ > > > > The same discussion was had in the spec for that change: > > > > https://review.openstack.org/#/c/511825/ +1 for deprecating those APIs. Current spec indicate the backup create API only which we can update to include image create also. -gmann > > > > Ultimately it amounted to a big "meh, let's just not fix the bug but > > also no one really cares about deprecating the API either". > > So we'll let the apathy of the past dictate the actions of the future. > > > The only thing deprecating the API would do is signal that it probably > > shouldn't be used. We would still support it on older microversions. If > > all anyone cares about is signalling not to use the API then deprecation > > is probably fine, but I personally don't feel too strongly about it > > either way. > > Deprecating these kinds of APIs would, as I mentioned in my original > post, signal that the Nova team is actually serious about cleaning up > the cruft and getting rid of the debt from years past. > > And also that it is serious about Nova not being a dumping ground for > orchestration and out-of-scope APIs not related to a Compute API. > > Best, > -jay > > From doug at doughellmann.com Mon Nov 19 15:06:56 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 19 Nov 2018 10:06:56 -0500 Subject: [openstack-dev] [nova] Stein forum session notes In-Reply-To: <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> Message-ID: Jay Pipes writes: > Thanks for the highlights, Melanie. Appreciated. Some thoughts inline... > > On 11/19/2018 04:17 AM, melanie witt wrote: >> Hey all, >> >> Here's some notes I took in forum sessions I attended -- feel free to >> add notes on sessions I missed. >> >> Etherpad links: https://wiki.openstack.org/wiki/Forum/Berlin2018 >> >> Cheers, >> -melanie >> >> >> TUE >> --- > >> Getting users involved in the project >> ===================================== >> - Disconnect between SIGs/WGs and project teams >> - Too steep a first step to get involved by subscribing to ML >> - People confused about how to participate > > Seriously? If subscribing to a mailing list is seen as too much of a > burden for users to provide feedback, I'm wondering what the point is of > having an open source community at all. IIRC, this was specifically about the *first* step of engaging with users and potential contributors. Throwing them into the deep end of the pool isn't a very gentle way to introduce them to the community, so even if we eventually need them to be able to join and participate on the mailing list maybe that's not the best answer to questions like "how do I get involved?" >> WED >> --- > >> Deletion of project and project resources >> ========================================= >> - What is wanted: a delete API per service that takes a project_id and >> force deletes all resources owned by it with --dry-run component >> - Challenge to work out the dependencies for the order of deletion of >> all resources in all projects. Disable project, then delete things in >> order of dependency >> - Idea: turn os-purge into a REST API and each project implement a >> plugin for it > > I don't see why a REST API would be needed. We could more easily > implement the functionality by focusing on a plugin API for each service > project and leaving it at that. A REST API is easier to trigger from self-service operations like a user closing their account. We talked about updating os-purge to use plugins and building an OSC command that uses os-purge, and I see the possibility of adding a REST API to a service like Adjutant in the future. But, one step at a time. -- Doug From doug at doughellmann.com Mon Nov 19 15:52:51 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 19 Nov 2018 10:52:51 -0500 Subject: [python3] RHEL 8 will include python 3.6 Message-ID: Now that the RHEL 8 beta is released, there is more official information about what is included. In particular, the question we've been waiting to have answered is "which version of python 3 will be the default?" The answer is 3.6, which means it should be safe to drop 3.5 testing for Stein. https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/ -- Doug From doug at doughellmann.com Mon Nov 19 15:56:32 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 19 Nov 2018 10:56:32 -0500 Subject: [docs] looking for help with sitemap generation Message-ID: During Rocky an intern for the OSF started working on a project to build sitemap files for docs.openstack.org. Megan has moved on, and we're looking for someone to pick up and finish that work. What we need is to have the tool to produce the per-doc-build sitemap finished [1], then to update the main doc site build to produce a full sitemap that links to the other existing sitemaps. If you have a little time and interest, please get in touch and I'll be happy to clarify and expand on that description. [1] https://review.openstack.org/#/c/524862/ -- Doug From edmondsw at us.ibm.com Mon Nov 19 16:01:12 2018 From: edmondsw at us.ibm.com (William M Edmonds) Date: Mon, 19 Nov 2018 11:01:12 -0500 Subject: [all] We've combined the lists! Now what? In-Reply-To: <20181119000426.hpgshg6ln5652pvt@yuggoth.org> References: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> <20181119000426.hpgshg6ln5652pvt@yuggoth.org> Message-ID: Jeremy Stanley wrote on 11/18/2018 07:04:26 PM: ... > 2. As I've subscribed the new list to the old ones, cross-posts > between them may result in some message duplication, but at least we > won't have to endure it for long. I don't think this is working. New things are appearing in openstack-dev that are not coming to openstack-discuss. E.g. http://lists.openstack.org/pipermail/openstack-dev/2018-November/136517.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From aj at suse.com Mon Nov 19 16:06:10 2018 From: aj at suse.com (Andreas Jaeger) Date: Mon, 19 Nov 2018 17:06:10 +0100 Subject: [all] We've combined the lists! Now what? In-Reply-To: References: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> <20181119000426.hpgshg6ln5652pvt@yuggoth.org> Message-ID: <4d7fdd2c-4a50-ea80-9bbf-f0809ba6852b@suse.com> On 19/11/2018 17.01, William M Edmonds wrote: > Jeremy Stanley wrote on 11/18/2018 07:04:26 PM: > ... >> 2. As I've subscribed the new list to the old ones, cross-posts >> between them may result in some message duplication, but at least we >> won't have to endure it for long. > > I don't think this is working. New things are appearing in openstack-dev > that are not coming to openstack-discuss. E.g. > http://lists.openstack.org/pipermail/openstack-dev/2018-November/136517.html Jeremy needs to manually approve them - he will do regularly, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 From ianyrchoi at gmail.com Mon Nov 19 16:13:51 2018 From: ianyrchoi at gmail.com (Ian Y. Choi) Date: Tue, 20 Nov 2018 01:13:51 +0900 Subject: [OpenStack-I18n] [docs][i18n] Team meeting proposal In-Reply-To: References: Message-ID: <3a2db232-44e0-4f17-3bf3-7411b0ea0ea8@gmail.com> +1 Thanks a lot for such a proposal - I briefly talked with Petr, Docs team PTL during the last PTG, but I link your detail proposal how to combine Docs + I18n IRC meeting. With many thanks, /Ian Remo Mattei wrote on 11/19/2018 11:14 PM: > Sounds good will try to make the meetings > > Il giorno 19 nov 2018, alle ore 05:46, SungJin Kang > > ha scritto: > >> Hi Frank, >> >> I agree :) >> >> Thanks. >> Sungjin >> >> 2018년 11월 19일 (월) 오후 6:18, Frank Kloeker > >님이 작성: >> >> Hello, >> >> in the last weeks we had some informal discussions about combined >> team >> meeting for documentation and translation team. There should be >> overlapping topics and other project teams or operator would have >> the >> same contact persons on the same place. We also save resources on >> meeting chairs. >> >> Here are my proposal: >> 1) Meeting room #openstack-meeting >> 2) Switch back from (informal) Office Hour to (formal) Team Meeting. >> Topics for upcoming meetings will be collected on a Wiki page. If >> there >> are no topic we would skip the meeting. So often we recorded empty >> sessions in the past. >> 3) Meeting time is Thursday 07:00 UTC (odd week), 16:00 UTC (even >> week) >> 4) First part (30 min) I18n topics, second part documentation >> topics, >> meetingbot will recorded two sessions, so it's easier to read >> specific >> topics later. >> 5) Rotating meeting chairs between the two teams. >> >> This should renew a little bit the conversation and we are more >> flexible >> and visible on the move. >> >> kind regards >> >> Frank (PTL I18n) >> >> >> _______________________________________________ >> OpenStack-I18n mailing list >> OpenStack-I18n at lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n >> >> _______________________________________________ >> OpenStack-I18n mailing list >> OpenStack-I18n at lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n > > _______________________________________________ > OpenStack-I18n mailing list > OpenStack-I18n at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n From mriedemos at gmail.com Mon Nov 19 13:38:46 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Mon, 19 Nov 2018 07:38:46 -0600 Subject: [openstack-dev] [nova] Stein forum session notes In-Reply-To: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> Message-ID: <6061a8e5-ad61-2075-223c-b540a911ebe1@gmail.com> On 11/19/2018 3:17 AM, melanie witt wrote: > - Not directly related to the session, but CERN (hallway track) and > NeCTAR (dev ML) have both given feedback and asked that the > policy-driven idea for handling quota for down cells be avoided. Revived > the "propose counting quota in placement" spec to see if there's any way > forward here Should this be abandoned then? https://review.openstack.org/#/c/614783/ Since there is no microversion impact to that change, it could be added separately as a bug fix for the down cell case if other operators want that functionality. But maybe we don't know what other operators want since no one else is at multi-cell cells v2 yet. -- Thanks, Matt __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From gang.sungjin at gmail.com Mon Nov 19 13:46:20 2018 From: gang.sungjin at gmail.com (SungJin Kang) Date: Mon, 19 Nov 2018 22:46:20 +0900 Subject: [OpenStack-I18n] [docs][i18n] Team meeting proposal In-Reply-To: References: Message-ID: Hi Frank, I agree :) Thanks. Sungjin 2018년 11월 19일 (월) 오후 6:18, Frank Kloeker 님이 작성: > Hello, > > in the last weeks we had some informal discussions about combined team > meeting for documentation and translation team. There should be > overlapping topics and other project teams or operator would have the > same contact persons on the same place. We also save resources on > meeting chairs. > > Here are my proposal: > 1) Meeting room #openstack-meeting > 2) Switch back from (informal) Office Hour to (formal) Team Meeting. > Topics for upcoming meetings will be collected on a Wiki page. If there > are no topic we would skip the meeting. So often we recorded empty > sessions in the past. > 3) Meeting time is Thursday 07:00 UTC (odd week), 16:00 UTC (even week) > 4) First part (30 min) I18n topics, second part documentation topics, > meetingbot will recorded two sessions, so it's easier to read specific > topics later. > 5) Rotating meeting chairs between the two teams. > > This should renew a little bit the conversation and we are more flexible > and visible on the move. > > kind regards > > Frank (PTL I18n) > > > _______________________________________________ > OpenStack-I18n mailing list > OpenStack-I18n at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rm at rm.ht Mon Nov 19 14:14:10 2018 From: rm at rm.ht (Remo Mattei) Date: Mon, 19 Nov 2018 06:14:10 -0800 Subject: [OpenStack-I18n] [docs][i18n] Team meeting proposal In-Reply-To: References: Message-ID: Sounds good will try to make the meetings > Il giorno 19 nov 2018, alle ore 05:46, SungJin Kang ha scritto: > > Hi Frank, > > I agree :) > > Thanks. > Sungjin > > 2018년 11월 19일 (월) 오후 6:18, Frank Kloeker 님이 작성: >> Hello, >> >> in the last weeks we had some informal discussions about combined team >> meeting for documentation and translation team. There should be >> overlapping topics and other project teams or operator would have the >> same contact persons on the same place. We also save resources on >> meeting chairs. >> >> Here are my proposal: >> 1) Meeting room #openstack-meeting >> 2) Switch back from (informal) Office Hour to (formal) Team Meeting. >> Topics for upcoming meetings will be collected on a Wiki page. If there >> are no topic we would skip the meeting. So often we recorded empty >> sessions in the past. >> 3) Meeting time is Thursday 07:00 UTC (odd week), 16:00 UTC (even week) >> 4) First part (30 min) I18n topics, second part documentation topics, >> meetingbot will recorded two sessions, so it's easier to read specific >> topics later. >> 5) Rotating meeting chairs between the two teams. >> >> This should renew a little bit the conversation and we are more flexible >> and visible on the move. >> >> kind regards >> >> Frank (PTL I18n) >> >> >> _______________________________________________ >> OpenStack-I18n mailing list >> OpenStack-I18n at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n > _______________________________________________ > OpenStack-I18n mailing list > OpenStack-I18n at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Mon Nov 19 14:26:00 2018 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Mon, 19 Nov 2018 09:26:00 -0500 Subject: [openstack-dev] [glance] about use shared image with each other In-Reply-To: References: Message-ID: <6d53c9e9-98f6-d594-bbfb-837c74d5fbae@gmail.com> On 11/19/18 7:58 AM, Rambo wrote: > Hi,all > >      Recently, I want to use the shared image with each other.I find it > isn't convenient that the producer notifies the consumer via email which > the image has been shared and what its UUID is. In other words, why the > image api v2 is no provision for producer-consumer communication? The design goal for Image API v2 image sharing was to provide an infrastructure for an "image marketplace" in an OpenStack cloud by (a) making it easy for cloud end users to share images, and (b) making it easy for end users not to be spammed by other end users taking advantage of (a). When v2 image sharing was introduced in the Grizzly release, we did not want to dictate how producer-consumer communication would work (because we had no idea how it would develop), so we left it up to operators and end users to figure this out. The advantage of email communication is that client side message filtering is available for whatever client a particular cloud end-user employs, and presumably that end-user knows how to manipulate the filters without learning some new scheme (or, if the end-user doesn't know, learning how to filter messages will apply beyond just image sharing, which is a plus). Also, email communication is just one way to handle producer-consumer communication. Some operators have adjusted their web interfaces so that when an end-user looks at the list of images available, a notification pops up if the end-user has any images that have been shared with them and are still in "pending" status. There are various other creative things you can do using the normal API calls with regular user credentials. In brief, we figured that if an image marketplace evolved in a particular cloud, producers and consumers would forge their own relationships in whatever way made the most sense for their particular use cases. So we left producer-consumer communication out-of-band. >       To make it is more convenient,  if we can add a task to change the > member_status from "pending" to "accepted" when we share the image with > each other. It is similar to the resize_confirm in Nova, we can control > the time interval in config. You could do this, but that would defeat the entire purpose of the member statuses implementation, and hence I do not recommend it. See OSSN-0005 [1] for more about this issue. Additionally, since the Ocata release, "community" images have been available. These do not have to be accepted by an end user (but they also don't show up in the default image-list response). Who can "communitize" an image is governed by policy. See [2] for a discussion of the various types of image sharing currently available in the Image API v2. The Image Service API v2 api-ref [3] contains a brief discussion of image visibility and image sharing that may also be useful. Finally, the Glance Ocata release notes [4] have an extensive discussion of image visibility. >        Can you tell me more about this?Thank you very much! The original design page on the wiki [5] has a list of 14 use cases we wanted to address; looking through those will give you a better idea of why we made the design choices we did. Hope this helps! cheers, brian [0] http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html [1] https://wiki.openstack.org/wiki/OSSN/1226078 [2] http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html [3] https://developer.openstack.org/api-ref/image/v2/ [4] https://docs.openstack.org/releasenotes/glance/ocata.html [5] https://wiki.openstack.org/wiki/Glance-api-v2-image-sharing > > Best Regards > Rambo > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From dangtrinhnt at gmail.com Mon Nov 19 14:39:57 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Mon, 19 Nov 2018 23:39:57 +0900 Subject: [openstack-dev] [Searchlight] New team meeting time Message-ID: Hello team, In order to welcome new contributors to the Searchlight project, we decided to change the meeting time [1]: - Time: 13:30 UCT - Meeting Channel: #openstack-searchlight - Meeting recurrence: bi-weekly starting from 19th Nov. 2018 [1] http://eavesdrop.openstack.org/irclogs/%23openstack-searchlight/latest.log.html Hope that there will be new blood into the project :D -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From doug at doughellmann.com Mon Nov 19 14:44:59 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 19 Nov 2018 09:44:59 -0500 Subject: [openstack-dev] [horizon] how to get horizon related logs to syslog? In-Reply-To: References: Message-ID: Akihiro Motoki writes: > Hi, > > Horizon logging depends on Django configuration which supports full python > logging [1]. > [1] does not provide enough examples. > Perhaps [2] will help you (though I haven't tested it). Based on https://docs.djangoproject.com/en/2.1/topics/logging/ it looks like it should be possible to have Horizon's settings module disable Django's logging configuration and call oslo.log to do that configuration. I wonder if it would make sense to do that, for consistency with the other services? Doug > > [1] https://docs.djangoproject.com/en/2.0/topics/logging/ > [2] > https://www.simonkrueger.com/2015/05/27/logging-django-apps-to-syslog.html > > Thanks, > Akihiro > > 2018年11月16日(金) 18:47 Tikkanen, Viktor (Nokia - FI/Espoo) < > viktor.tikkanen at nokia.com>: > >> Hi! >> >> For most openstack parts (e.g. Aodh, Cinder, Glance, Heat, Ironic, >> Keystone, Neutron, Nova) it was easy to get logs to syslog. >> >> For example for Heat something similar to this (into file >> templates/heat.conf.j2): >> >> # Syslog usage >> {% if heat_syslog_enabled %} >> use_syslog = True >> syslog_log_facility = LOG_LOCAL3 >> {% else %} >> log_file = /var/log/heat/heat.log >> {% endif %} >> >> But how to get Horizon related logs to syslog? >> >> -V. >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From dangtrinhnt at gmail.com Mon Nov 19 15:09:54 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Tue, 20 Nov 2018 00:09:54 +0900 Subject: [openstack-dev] [Searchlight] Weekly report, Stein R-21 Message-ID: Hello team, Here is the report for last week, Stein R-21. Please have a look: https://www.dangtrinh.com/2018/11/searchlight-weekly-report-stein-r-21.html Thanks, -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From aschultz at redhat.com Mon Nov 19 15:11:43 2018 From: aschultz at redhat.com (Alex Schultz) Date: Mon, 19 Nov 2018 08:11:43 -0700 Subject: [openstack-dev] [puppet] [stable] Deprecation of newton branches In-Reply-To: <2ae10ca2-8c77-ccbc-c009-a22c1d3cfd69@binero.se> References: <2ae10ca2-8c77-ccbc-c009-a22c1d3cfd69@binero.se> Message-ID: On Mon, Nov 19, 2018 at 1:18 AM Tobias Urdin wrote: > > Hello, > > We've been talking for a while about the deprecation and removal of the > stable/newton branches. > I think it's time now that we get rid of them, we have no open patches > and Newton is considered EOL. > > Could cores get back with a quick feedback and then the stable team can > get rid of those whenever they have time. > yes please. let's EOL them > Best regards > Tobias > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From surya.seetharaman9 at gmail.com Mon Nov 19 16:19:22 2018 From: surya.seetharaman9 at gmail.com (Surya Seetharaman) Date: Mon, 19 Nov 2018 17:19:22 +0100 Subject: [openstack-dev] [nova] Stein forum session notes In-Reply-To: <6061a8e5-ad61-2075-223c-b540a911ebe1@gmail.com> References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> <6061a8e5-ad61-2075-223c-b540a911ebe1@gmail.com> Message-ID: On Mon, Nov 19, 2018 at 2:39 PM Matt Riedemann wrote: > On 11/19/2018 3:17 AM, melanie witt wrote: > > - Not directly related to the session, but CERN (hallway track) and > > NeCTAR (dev ML) have both given feedback and asked that the > > policy-driven idea for handling quota for down cells be avoided. Revived > > the "propose counting quota in placement" spec to see if there's any > way > > forward here > > Should this be abandoned then? > > https://review.openstack.org/#/c/614783/ > > Since there is no microversion impact to that change, it could be added > separately as a bug fix for the down cell case if other operators want > that functionality. But maybe we don't know what other operators want > since no one else is at multi-cell cells v2 yet. > > I thought the policy check was needed until the "propose counting quota in placement" has been implemented as a workaround and that is what the "handling down cell" spec also proposed, unless the former spec would be implemented within this cycle in which case we do not need the policy check. -- Regards, Surya. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From fungi at yuggoth.org Mon Nov 19 16:32:21 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 19 Nov 2018 16:32:21 +0000 Subject: [all] We've combined the lists! Now what? In-Reply-To: <4d7fdd2c-4a50-ea80-9bbf-f0809ba6852b@suse.com> References: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> <20181119000426.hpgshg6ln5652pvt@yuggoth.org> <4d7fdd2c-4a50-ea80-9bbf-f0809ba6852b@suse.com> Message-ID: <20181119163220.zx64spsawzbttbfo@yuggoth.org> On 2018-11-19 17:06:10 +0100 (+0100), Andreas Jaeger wrote: > On 19/11/2018 17.01, William M Edmonds wrote: > > Jeremy Stanley wrote on 11/18/2018 07:04:26 PM: > > ... > >> 2. As I've subscribed the new list to the old ones, cross-posts > >> between them may result in some message duplication, but at least we > >> won't have to endure it for long. > > > > I don't think this is working. New things are appearing in openstack-dev > > that are not coming to openstack-discuss. E.g. > > http://lists.openstack.org/pipermail/openstack-dev/2018-November/136517.html > > Jeremy needs to manually approve them - he will do regularly, Correct. Messages to openstack-dev from folks who aren't subscribers to openstack-discuss will be caught in the openstack-discuss moderation queue. I'm flushing that regularly. They should also hopefully be getting a notification that their message was held for moderation due to not being a subscriber to openstack-discuss, though I haven't tested that personally. On a positive note, in the past ~16.5 hours since I opened this list to posts and subscribed it to the old lists, we've had 48 new subscribers (up from 280 to 328 as of a few seconds ago). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From yedhusastri at gmail.com Mon Nov 19 16:25:13 2018 From: yedhusastri at gmail.com (Yedhu Sastri) Date: Mon, 19 Nov 2018 17:25:13 +0100 Subject: [Openstack] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes?? Message-ID: Hello All, I have some use-cases which I want to test in PowerPC architecture(ppc64). As I dont have any Power machines I would like to try it with ppc64 VM's. Is it possible to run these kind of VM's on my OpenStack cluster(Queens) which runs on X86_64 architecture nodes(OS RHEL 7)?? I set the image property architecture=ppc64 to the ppc64 image I uploaded to glance but no success in launching VM with those images. I am using KVM as hypervisor(qemu 2.10.0) in my compute nodes and I think it is not built to support power architecture. For testing without OpenStack I manually built qemu on a x86_64 host with ppc64 support(qemu-ppc64) and then I am able to host the ppc64 VM. But I dont know how to do this on my OpenStack cluster. Whether I need to manually build qemu on compute nodes with ppc64 support or I need to add some lines in my nova.conf to do this?? Any help to solve this issue would be much appreciated. -- Thank you for your time and have a nice day, With kind regards, Yedhu Sastri -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From ken at jots.org Mon Nov 19 16:57:15 2018 From: ken at jots.org (Ken D'Ambrosio) Date: Mon, 19 Nov 2018 11:57:15 -0500 Subject: [Openstack] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes?? In-Reply-To: References: Message-ID: <9f1bdf3c463f3d788adb3401fc9777ee@jots.org> On 2018-11-19 11:25, Yedhu Sastri wrote: > Hello All, > > I have some use-cases which I want to test in PowerPC architecture(ppc64). As I dont have any Power machines I would like to try it with ppc64 VM's. Is it possible to run these kind of VM's on my OpenStack cluster(Queens) which runs on X86_64 architecture nodes(OS RHEL 7)?? I'm not 100% sure, but I'm 95% sure that the answer to your question is "No." While there's much emulation that occurs, the CPU isn't so much emulated, but more abstracted. Constructing and running a modern CPU in software would be non-trivial. -Ken > I set the image property architecture=ppc64 to the ppc64 image I uploaded to glance but no success in launching VM with those images. I am using KVM as hypervisor(qemu 2.10.0) in my compute nodes and I think it is not built to support power architecture. For testing without OpenStack I manually built qemu on a x86_64 host with ppc64 support(qemu-ppc64) and then I am able to host the ppc64 VM. But I dont know how to do this on my OpenStack cluster. Whether I need to manually build qemu on compute nodes with ppc64 support or I need to add some lines in my nova.conf to do this?? Any help to solve this issue would be much appreciated. > > -- > > Thank you for your time and have a nice day, > > With kind regards, Yedhu Sastri > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From andr.kurilin at gmail.com Mon Nov 19 18:08:49 2018 From: andr.kurilin at gmail.com (Andrey Kurilin) Date: Mon, 19 Nov 2018 10:08:49 -0800 Subject: [all] We've combined the lists! Now what? In-Reply-To: <20181119163220.zx64spsawzbttbfo@yuggoth.org> References: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> <20181119000426.hpgshg6ln5652pvt@yuggoth.org> <4d7fdd2c-4a50-ea80-9bbf-f0809ba6852b@suse.com> <20181119163220.zx64spsawzbttbfo@yuggoth.org> Message-ID: hi folks! As it was mentioned at [1], OpenStack-infra is going to become OpenDev. Are there any plans for mailing lists? I mean, is it planned to rename 'openstack-discuss' to 'opendev-discuss' or the will be separate mailing lists for different 'groups' again? [1] - http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html пн, 19 нояб. 2018 г. в 18:32, Jeremy Stanley : > On 2018-11-19 17:06:10 +0100 (+0100), Andreas Jaeger wrote: > > On 19/11/2018 17.01, William M Edmonds wrote: > > > Jeremy Stanley wrote on 11/18/2018 07:04:26 PM: > > > ... > > >> 2. As I've subscribed the new list to the old ones, cross-posts > > >> between them may result in some message duplication, but at least we > > >> won't have to endure it for long. > > > > > > I don't think this is working. New things are appearing in > openstack-dev > > > that are not coming to openstack-discuss. E.g. > > > > http://lists.openstack.org/pipermail/openstack-dev/2018-November/136517.html > > > > Jeremy needs to manually approve them - he will do regularly, > > Correct. Messages to openstack-dev from folks who aren't subscribers > to openstack-discuss will be caught in the openstack-discuss > moderation queue. I'm flushing that regularly. They should also > hopefully be getting a notification that their message was held for > moderation due to not being a subscriber to openstack-discuss, > though I haven't tested that personally. > > On a positive note, in the past ~16.5 hours since I opened this list > to posts and subscribed it to the old lists, we've had 48 new > subscribers (up from 280 to 328 as of a few seconds ago). > -- > Jeremy Stanley > -- Best regards, Andrey Kurilin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Mon Nov 19 18:14:09 2018 From: smooney at redhat.com (Sean Mooney) Date: Mon, 19 Nov 2018 18:14:09 +0000 Subject: [all] We've combined the lists! Now what? In-Reply-To: References: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> <20181119000426.hpgshg6ln5652pvt@yuggoth.org> <4d7fdd2c-4a50-ea80-9bbf-f0809ba6852b@suse.com> <20181119163220.zx64spsawzbttbfo@yuggoth.org> Message-ID: <8d0a82ab723c74cf3183eaea0aea9817684904a9.camel@redhat.com> On Mon, 2018-11-19 at 10:08 -0800, Andrey Kurilin wrote: > hi folks! > > As it was mentioned at [1], OpenStack-infra is going to become OpenDev. Are there any plans for mailing lists? > I mean, is it planned to rename 'openstack-discuss' to 'opendev-discuss' or the will be separate mailing lists for > different 'groups' again? > > [1] - http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html so on a related note i just going an from the openstack at lists.openstack.org email adress which im not a member of because if try to reply to it i get a message telling me so. i am subsibed to openstack-dev and i recently joined openstack-discuss but i think there are some other weridness how things are beign forwarded. when they are manually approved and forwarded is the reply-to auto updated to openstack-discuss? im assuming the mail from openstack at lists.openstack.org was one that was forwarded. > > пн, 19 нояб. 2018 г. в 18:32, Jeremy Stanley : > > On 2018-11-19 17:06:10 +0100 (+0100), Andreas Jaeger wrote: > > > On 19/11/2018 17.01, William M Edmonds wrote: > > > > Jeremy Stanley wrote on 11/18/2018 07:04:26 PM: > > > > ... > > > >> 2. As I've subscribed the new list to the old ones, cross-posts > > > >> between them may result in some message duplication, but at least we > > > >> won't have to endure it for long. > > > > > > > > I don't think this is working. New things are appearing in openstack-dev > > > > that are not coming to openstack-discuss. E.g. > > > > http://lists.openstack.org/pipermail/openstack-dev/2018-November/136517.html > > > > > > Jeremy needs to manually approve them - he will do regularly, > > > > Correct. Messages to openstack-dev from folks who aren't subscribers > > to openstack-discuss will be caught in the openstack-discuss > > moderation queue. I'm flushing that regularly. They should also > > hopefully be getting a notification that their message was held for > > moderation due to not being a subscriber to openstack-discuss, > > though I haven't tested that personally. > > > > On a positive note, in the past ~16.5 hours since I opened this list > > to posts and subscribed it to the old lists, we've had 48 new > > subscribers (up from 280 to 328 as of a few seconds ago). > > -- > > Jeremy Stanley > > From smooney at redhat.com Mon Nov 19 18:10:35 2018 From: smooney at redhat.com (Sean Mooney) Date: Mon, 19 Nov 2018 18:10:35 +0000 Subject: [openstack-dev] [Openstack] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes?? In-Reply-To: <36812fc83e71a08fbeb809fbfa26722a743aab78.camel@redhat.com> References: <9f1bdf3c463f3d788adb3401fc9777ee@jots.org> <36812fc83e71a08fbeb809fbfa26722a743aab78.camel@redhat.com> Message-ID: <7d06072569866475fd4f0efff25c7fea4df399f1.camel@redhat.com> adding openstack dev. On Mon, 2018-11-19 at 18:08 +0000, Sean Mooney wrote: > On Mon, 2018-11-19 at 11:57 -0500, Ken D'Ambrosio wrote: > > On 2018-11-19 11:25, Yedhu Sastri wrote: > > > Hello All, > > > > > > I have some use-cases which I want to test in PowerPC architecture(ppc64). As I dont have any Power machines I > > > would > > > like to try it with ppc64 VM's. Is it possible to run these kind of VM's on my OpenStack cluster(Queens) which > > > runs > > > on X86_64 architecture nodes(OS RHEL 7)?? > > > > > > > I'm not 100% sure, but I'm 95% sure that the answer to your question is "No." While there's much emulation that > > occurs, the CPU isn't so much emulated, but more abstracted. Constructing and running a modern CPU in software > > would > > be non-trivial. > > you can do this but not with kvm. > you need to revert the virt dirver in the nova.conf back to qemu to disable kvm to allow emulation of other > plathforms. > that said i have only emulated power on x86_64 using libvirt or qemu idrectly never with openstack but i belive we > used > to support this i just hav enot done it personally. > > > > -Ken > > > > > I set the image property architecture=ppc64 to the ppc64 image I uploaded to glance but no success in launching VM > > > with those images. I am using KVM as hypervisor(qemu 2.10.0) in my compute nodes and I think it is not built to > > > support power architecture. For testing without OpenStack I manually built qemu on a x86_64 host with ppc64 > > > support(qemu-ppc64) and then I am able to host the ppc64 VM. But I dont know how to do this on my OpenStack > > > cluster. > > > Whether I need to manually build qemu on compute nodes with ppc64 support or I need to add some lines in my > > > nova.conf to do this?? Any help to solve this issue would be much appreciated. > > > > > > > > > -- > > > Thank you for your time and have a nice day, > > > > > > With kind regards, > > > Yedhu Sastri > > > > > > _______________________________________________ > > > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > Post to : openstack at lists.openstack.org > > > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > _______________________________________________ > > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > Post to : openstack at lists.openstack.org > > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From fungi at yuggoth.org Mon Nov 19 18:19:02 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 19 Nov 2018 18:19:02 +0000 Subject: [all] We've combined the lists! Now what? In-Reply-To: References: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> <20181119000426.hpgshg6ln5652pvt@yuggoth.org> <4d7fdd2c-4a50-ea80-9bbf-f0809ba6852b@suse.com> <20181119163220.zx64spsawzbttbfo@yuggoth.org> Message-ID: <20181119181902.obsztzzcw2ad7a3r@yuggoth.org> On 2018-11-19 10:08:49 -0800 (-0800), Andrey Kurilin wrote: > As it was mentioned at [1], OpenStack-infra is going to become OpenDev. Are > there any plans for mailing lists? > I mean, is it planned to rename 'openstack-discuss' to 'opendev-discuss' or > the will be separate mailing lists for different 'groups' again? [...] The openstack-discuss list is for discussions about OpenStack. The OpenStack Infrastructure team which maintains developer and community services for OpenStack and other projects is becoming OpenDev, so the openstack-infra ML may be renamed/moved in the near future but that should have no bearing on the openstack-discuss ML which is very much OpenStack-specific and expected to remain so. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From fungi at yuggoth.org Mon Nov 19 19:02:45 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 19 Nov 2018 19:02:45 +0000 Subject: [all] We've combined the lists! Now what? In-Reply-To: <8d0a82ab723c74cf3183eaea0aea9817684904a9.camel@redhat.com> References: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> <20181119000426.hpgshg6ln5652pvt@yuggoth.org> <4d7fdd2c-4a50-ea80-9bbf-f0809ba6852b@suse.com> <20181119163220.zx64spsawzbttbfo@yuggoth.org> <8d0a82ab723c74cf3183eaea0aea9817684904a9.camel@redhat.com> Message-ID: <20181119190245.yk5usbtpxt5ksnkf@yuggoth.org> On 2018-11-19 18:14:09 +0000 (+0000), Sean Mooney wrote: > so on a related note i just going an from the > openstack at lists.openstack.org email adress which im not a member > of because if try to reply to it i get a message telling me so. > > i am subsibed to openstack-dev and i recently joined > openstack-discuss but i think there are some other weridness how > things are beign forwarded. Thanks for spotting this! I see that in the case of the message you mentioned Mailman is complaining because the actual openstack-discuss list address doesn't appear in either the To or Cc headers. I've hopefully solved this now by adding the addresses of the old lists as known aliases for this one so that it will treat their appearance in To or Cc as satisfactory for this check. > when they are manually approved and forwarded is the reply-to auto > updated to openstack-discuss? im assuming the mail from > openstack at lists.openstack.org was one that was forwarded. A great question... it doesn't seem to do so, no. I'll see if I can figure out whether there is a convenient option to make that happen. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From doug at doughellmann.com Mon Nov 19 19:08:02 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 19 Nov 2018 14:08:02 -0500 Subject: [tc] summary of 12 Nov 2018 joint leadership meeting Message-ID: On Monday 12 November, 2018 the OpenStack Foundation Board of Directors, staff, and project leadership held a joint meeting to discuss the project and foundation status [1]. We were hosted by Deutsche Telekom AG in their Berlin Representative Office. The meeting space was inside a room that housed their original telegraph offices built in 1861, and as someone who appreciates old architecture I can say that DT did an excellent job blending the feeling of the old building with the modern fittings needed for meetings like ours. The morning was taken up with a formal Board of Directors meeting, which Jonathan has already summarized at [2]. I won't repeat everything he wrote here, but there were a few topics that may be of particular interest to ATCs. The first is that the board has approved a set of bylaws changes [3] that declare that the Foundation will establish "Open Infrastructure Projects" (OIP), with the governance for each to be approved by the Board. Because the bylaws require a vote of the Foundation members to change, the details are left up to other documentation, which a subcommittee of the Board is going to begin preparing [4]. Completing that work is a prerequisite for Airship, Kata Containers, StarlingX, and Zuul to be confirmed as Foundation projects (they are "pilot" projects now). The current version of the bylaws includes details about the way OpenStack operates, by defining the membership and role of the Technical and User Committees. Those definitions will remain, to signal the "centrality" of the project and, and there are a few proposed wording changes to try to make election scheduling more flexible and to clarify the relationship between the OpenStack Technical and User Committees and the other OIPs. There is also a change to allow the Board and TC to update the "Technical Committee Member Policy" by voting on it together, rather than requiring a full vote of the Foundation members. There are also some minor cleanup and "modernization" of the language (removing obsolete references to bootstrapping directions, for example). There was not a lot of discussion of the changes in this meeting, because there had been several meetings to discuss and refine them before 12 November. Next, these changes need to be approved by the Platinum and Gold foundation members and then approved by the individual members. The goal is to have everything ready for approval during the board election this January. Please watch for the announcements for that vote and participate in the election, so that we have quorum and so the outcome of the vote is binding. The second topic I thought might be of interest is the discussion of the brand research the Foundation staff commissioned and which Wes previously summarized on the mailing list [5]. I was encouraged by the favorability numbers in the responses (67% of respondents rate OpenStack as "favorable" or "very favorable") as well as the 50-60% of overlap between people reporting an interest in OpenStack and in the existing OIPs. The "Open Infrastructure" renaming for the summit (announced last week) was also very popular in the survey results. After the Board meeting concluded, the Technical Committee presented a summary of the work done during Rocky, a preview of the work to be done during Stein (thank you to the PTLs who responded to my request for information) and some of the initiatives the TC is undertaking right now [6]. The Board was very interested in both the peer review culture change that Julia has been driving and the technical vision document that Zane has been writing [7]. Following the TC presentation, the User Committee presented updates on their work, the user survey, and work being done in adjacent communities such as Kubernetes [8]. We wrapped up the afternoon with presentations from each of the existing pilot projects on their mission and status [9]. [1] joint leadership meeting agenda https://wiki.openstack.org/wiki/Governance/Foundation/12Nov2018BoardMeeting [2] Jonathan’s summary of the Board meeting http://lists.openstack.org/pipermail/foundation/2018-November/002654.html [3] bylaws changes http://lists.openstack.org/pipermail/foundation-board/2018-November/000459.html [4] Board thread on creating acceptance criteria for OIPs http://lists.openstack.org/pipermail/foundation-board/2018-November/000462.html [5] OSF branch research results http://lists.openstack.org/pipermail/foundation/2018-October/002634.html [6] TC presentation https://docs.google.com/presentation/d/1wcG7InY2A5y67dt5lC14CI1gQHGZ3db8-yshOu-STk8/edit#slide=id.g46a6072f4a_0_308 [7] Vision for OpenStack Clouds https://governance.openstack.org/tc/reference/technical-vision.html [8] UC Presentation https://docs.google.com/presentation/d/1gLcChOupELCGItD-SzhECEhFMGQc4jf0PlQxAijDMhw/edit?usp=sharing [9] Pilot project presentations https://docs.google.com/presentation/d/1nsm6ht3kJRw7vZsbjLDcTfPA8d8gu3jSYinmKfgiENU/edit?usp=sharing -- Doug From shardy at redhat.com Mon Nov 19 19:07:12 2018 From: shardy at redhat.com (Steven Hardy) Date: Mon, 19 Nov 2018 19:07:12 +0000 Subject: [openstack-dev] [tripleo] Proposing Enrique Llorente Pastora as a core reviewer for TripleO In-Reply-To: References: Message-ID: On Thu, Nov 15, 2018 at 3:54 PM Sagi Shnaidman wrote: > > Hi, > I'd like to propose Quique (@quiquell) as a core reviewer for TripleO. Quique is actively involved in improvements and development of TripleO and TripleO CI. He also helps in other projects including but not limited to Infrastructure. > He shows a very good understanding how TripleO and CI works and I'd like suggest him as core reviewer of TripleO in CI related code. > > Please vote! > My +1 is here :) +1! __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From rfolco at redhat.com Mon Nov 19 19:25:43 2018 From: rfolco at redhat.com (Rafael Folco) Date: Mon, 19 Nov 2018 17:25:43 -0200 Subject: [openstack-dev] [Openstack] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes?? In-Reply-To: <7d06072569866475fd4f0efff25c7fea4df399f1.camel@redhat.com> References: <9f1bdf3c463f3d788adb3401fc9777ee@jots.org> <36812fc83e71a08fbeb809fbfa26722a743aab78.camel@redhat.com> <7d06072569866475fd4f0efff25c7fea4df399f1.camel@redhat.com> Message-ID: (not sure if my answer has been sent, sorry if duplicate) I don't touch ppc for a while but AFAIK this should work as long as you run full emulation (qemu, not kvm) as libvirt_type in nova.conf and get the qemu-system-ppc64le installed in the compute node. Assume also you get the ppc64le image to launch your instance. Expect poor performance though. On Mon, Nov 19, 2018 at 4:12 PM Sean Mooney wrote: > adding openstack dev. > On Mon, 2018-11-19 at 18:08 +0000, Sean Mooney wrote: > > On Mon, 2018-11-19 at 11:57 -0500, Ken D'Ambrosio wrote: > > > On 2018-11-19 11:25, Yedhu Sastri wrote: > > > > Hello All, > > > > > > > > I have some use-cases which I want to test in PowerPC > architecture(ppc64). As I dont have any Power machines I > > > > would > > > > like to try it with ppc64 VM's. Is it possible to run these kind of > VM's on my OpenStack cluster(Queens) which > > > > runs > > > > on X86_64 architecture nodes(OS RHEL 7)?? > > > > > > > > > > I'm not 100% sure, but I'm 95% sure that the answer to your question > is "No." While there's much emulation that > > > occurs, the CPU isn't so much emulated, but more abstracted. > Constructing and running a modern CPU in software > > > would > > > be non-trivial. > > > > you can do this but not with kvm. > > you need to revert the virt dirver in the nova.conf back to qemu to > disable kvm to allow emulation of other > > plathforms. > > that said i have only emulated power on x86_64 using libvirt or qemu > idrectly never with openstack but i belive we > > used > > to support this i just hav enot done it personally. > > > > > > -Ken > > > > > > > I set the image property architecture=ppc64 to the ppc64 image I > uploaded to glance but no success in launching VM > > > > with those images. I am using KVM as hypervisor(qemu 2.10.0) in my > compute nodes and I think it is not built to > > > > support power architecture. For testing without OpenStack I manually > built qemu on a x86_64 host with ppc64 > > > > support(qemu-ppc64) and then I am able to host the ppc64 VM. But I > dont know how to do this on my OpenStack > > > > cluster. > > > > Whether I need to manually build qemu on compute nodes with ppc64 > support or I need to add some lines in my > > > > nova.conf to do this?? Any help to solve this issue would be much > appreciated. > > > > > > > > > > > > -- > > > > Thank you for your time and have a nice day, > > > > > > > > With kind regards, > > > > Yedhu Sastri > > > > > > > > _______________________________________________ > > > > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > Post to : openstack at lists.openstack.org > > > > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > > _______________________________________________ > > > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > Post to : openstack at lists.openstack.org > > > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Rafael Folco Senior Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From rfolco at redhat.com Mon Nov 19 19:25:43 2018 From: rfolco at redhat.com (Rafael Folco) Date: Mon, 19 Nov 2018 17:25:43 -0200 Subject: [Openstack] [openstack-dev] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes?? In-Reply-To: <7d06072569866475fd4f0efff25c7fea4df399f1.camel@redhat.com> References: <9f1bdf3c463f3d788adb3401fc9777ee@jots.org> <36812fc83e71a08fbeb809fbfa26722a743aab78.camel@redhat.com> <7d06072569866475fd4f0efff25c7fea4df399f1.camel@redhat.com> Message-ID: (not sure if my answer has been sent, sorry if duplicate) I don't touch ppc for a while but AFAIK this should work as long as you run full emulation (qemu, not kvm) as libvirt_type in nova.conf and get the qemu-system-ppc64le installed in the compute node. Assume also you get the ppc64le image to launch your instance. Expect poor performance though. On Mon, Nov 19, 2018 at 4:12 PM Sean Mooney wrote: > adding openstack dev. > On Mon, 2018-11-19 at 18:08 +0000, Sean Mooney wrote: > > On Mon, 2018-11-19 at 11:57 -0500, Ken D'Ambrosio wrote: > > > On 2018-11-19 11:25, Yedhu Sastri wrote: > > > > Hello All, > > > > > > > > I have some use-cases which I want to test in PowerPC > architecture(ppc64). As I dont have any Power machines I > > > > would > > > > like to try it with ppc64 VM's. Is it possible to run these kind of > VM's on my OpenStack cluster(Queens) which > > > > runs > > > > on X86_64 architecture nodes(OS RHEL 7)?? > > > > > > > > > > I'm not 100% sure, but I'm 95% sure that the answer to your question > is "No." While there's much emulation that > > > occurs, the CPU isn't so much emulated, but more abstracted. > Constructing and running a modern CPU in software > > > would > > > be non-trivial. > > > > you can do this but not with kvm. > > you need to revert the virt dirver in the nova.conf back to qemu to > disable kvm to allow emulation of other > > plathforms. > > that said i have only emulated power on x86_64 using libvirt or qemu > idrectly never with openstack but i belive we > > used > > to support this i just hav enot done it personally. > > > > > > -Ken > > > > > > > I set the image property architecture=ppc64 to the ppc64 image I > uploaded to glance but no success in launching VM > > > > with those images. I am using KVM as hypervisor(qemu 2.10.0) in my > compute nodes and I think it is not built to > > > > support power architecture. For testing without OpenStack I manually > built qemu on a x86_64 host with ppc64 > > > > support(qemu-ppc64) and then I am able to host the ppc64 VM. But I > dont know how to do this on my OpenStack > > > > cluster. > > > > Whether I need to manually build qemu on compute nodes with ppc64 > support or I need to add some lines in my > > > > nova.conf to do this?? Any help to solve this issue would be much > appreciated. > > > > > > > > > > > > -- > > > > Thank you for your time and have a nice day, > > > > > > > > With kind regards, > > > > Yedhu Sastri > > > > > > > > _______________________________________________ > > > > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > Post to : openstack at lists.openstack.org > > > > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > > _______________________________________________ > > > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > Post to : openstack at lists.openstack.org > > > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Rafael Folco Senior Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From fungi at yuggoth.org Mon Nov 19 19:47:47 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 19 Nov 2018 19:47:47 +0000 Subject: [all] We've combined the lists! Now what? In-Reply-To: <20181119190245.yk5usbtpxt5ksnkf@yuggoth.org> References: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> <20181119000426.hpgshg6ln5652pvt@yuggoth.org> <4d7fdd2c-4a50-ea80-9bbf-f0809ba6852b@suse.com> <20181119163220.zx64spsawzbttbfo@yuggoth.org> <8d0a82ab723c74cf3183eaea0aea9817684904a9.camel@redhat.com> <20181119190245.yk5usbtpxt5ksnkf@yuggoth.org> Message-ID: <20181119194746.qqt5pycw5xthpcm3@yuggoth.org> On 2018-11-19 19:02:45 +0000 (+0000), Jeremy Stanley wrote: > On 2018-11-19 18:14:09 +0000 (+0000), Sean Mooney wrote: [...] > > when they are manually approved and forwarded is the reply-to auto > > updated to openstack-discuss? im assuming the mail from > > openstack at lists.openstack.org was one that was forwarded. > > A great question... it doesn't seem to do so, no. I'll see if I can > figure out whether there is a convenient option to make that happen. Our resident Mailman guru (James E. Blair) pointed me to the necessary magic to cause the old lists to transitively accept posts from subscribers of the new list, so at least new-list subscribers' replies to old-list threads will go to them without sticking in moderation now. Turning on Reply-To munging, even if only for the next few weeks, was more of a behavior change for openstack-discuss than we were comfortable enacting. Consciously updating To/Cc fields to go to openstack-discuss when you notice it would probably be a good tactic in lieu of something more automatic and insidious. After December 3 people trying to reply to old list addresses will just get rejections, but hopefully by then they will have figured this out (I'll also try to send some more reminders to them in the meantime). Thanks again for the deep thoughts regarding this transition, and PLEASE don't anyone hesitate to mention other similar problems they happen to spot. I know it's the week after the Summit and a holiday week for some chunk of the World, but I'll do my best to be around and act quickly on anything we need to keep this as smooth as we can manage. It's a big and potentially disruptive change so I really appreciate how positive everyone's been about it so far! -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From smooney at redhat.com Mon Nov 19 19:56:08 2018 From: smooney at redhat.com (Sean Mooney) Date: Mon, 19 Nov 2018 19:56:08 +0000 Subject: [openstack-dev] [Openstack] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes?? In-Reply-To: References: <9f1bdf3c463f3d788adb3401fc9777ee@jots.org> <36812fc83e71a08fbeb809fbfa26722a743aab78.camel@redhat.com> <7d06072569866475fd4f0efff25c7fea4df399f1.camel@redhat.com> Message-ID: <6e4346f08e047edf5d0d1a5722943b9fb5d0f477.camel@redhat.com> On Mon, 2018-11-19 at 17:25 -0200, Rafael Folco wrote: > (not sure if my answer has been sent, sorry if duplicate) > I don't touch ppc for a while but AFAIK this should work as long as you run full emulation (qemu, not kvm) as > libvirt_type in nova.conf and get the qemu-system-ppc64le installed in the compute node. Assume also you get the > ppc64le image to launch your instance. Expect poor performance though. that is my understanding also. the perfromace is accepable but not great if you can enabled the multithread tcg backend instead of the default singel tread tcg backend that is used when in qemu only mode but it still wont match kvm accleration or power on power performance. i dont think we have a way to enabel the multi thread accleration for qemu only backend via nova unfortunetly it would be triavial to add but no one has asked as far as i am aware. > > On Mon, Nov 19, 2018 at 4:12 PM Sean Mooney wrote: > > adding openstack dev. > > On Mon, 2018-11-19 at 18:08 +0000, Sean Mooney wrote: > > > On Mon, 2018-11-19 at 11:57 -0500, Ken D'Ambrosio wrote: > > > > On 2018-11-19 11:25, Yedhu Sastri wrote: > > > > > Hello All, > > > > > > > > > > I have some use-cases which I want to test in PowerPC architecture(ppc64). As I dont have any Power machines I > > > > > would > > > > > like to try it with ppc64 VM's. Is it possible to run these kind of VM's on my OpenStack cluster(Queens) which > > > > > runs > > > > > on X86_64 architecture nodes(OS RHEL 7)?? > > > > > > > > > > > > > I'm not 100% sure, but I'm 95% sure that the answer to your question is "No." While there's much emulation that > > > > occurs, the CPU isn't so much emulated, but more abstracted. Constructing and running a modern CPU in software > > > > would > > > > be non-trivial. > > > > > > you can do this but not with kvm. > > > you need to revert the virt dirver in the nova.conf back to qemu to disable kvm to allow emulation of other > > > plathforms. > > > that said i have only emulated power on x86_64 using libvirt or qemu idrectly never with openstack but i belive we > > > used > > > to support this i just hav enot done it personally. > > > > > > > > -Ken > > > > > > > > > I set the image property architecture=ppc64 to the ppc64 image I uploaded to glance but no success in > > launching VM > > > > > with those images. I am using KVM as hypervisor(qemu 2.10.0) in my compute nodes and I think it is not built > > to > > > > > support power architecture. For testing without OpenStack I manually built qemu on a x86_64 host with ppc64 > > > > > support(qemu-ppc64) and then I am able to host the ppc64 VM. But I dont know how to do this on my OpenStack > > > > > cluster. > > > > > Whether I need to manually build qemu on compute nodes with ppc64 support or I need to add some lines in my > > > > > nova.conf to do this?? Any help to solve this issue would be much appreciated. > > > > > > > > > > > > > > > -- > > > > > Thank you for your time and have a nice day, > > > > > > > > > > With kind regards, > > > > > Yedhu Sastri > > > > > > > > > > _______________________________________________ > > > > > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > Post to : openstack at lists.openstack.org > > > > > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > > > > _______________________________________________ > > > > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > Post to : openstack at lists.openstack.org > > > > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From smooney at redhat.com Mon Nov 19 19:56:08 2018 From: smooney at redhat.com (Sean Mooney) Date: Mon, 19 Nov 2018 19:56:08 +0000 Subject: [Openstack] [openstack-dev] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes?? In-Reply-To: References: <9f1bdf3c463f3d788adb3401fc9777ee@jots.org> <36812fc83e71a08fbeb809fbfa26722a743aab78.camel@redhat.com> <7d06072569866475fd4f0efff25c7fea4df399f1.camel@redhat.com> Message-ID: <6e4346f08e047edf5d0d1a5722943b9fb5d0f477.camel@redhat.com> On Mon, 2018-11-19 at 17:25 -0200, Rafael Folco wrote: > (not sure if my answer has been sent, sorry if duplicate) > I don't touch ppc for a while but AFAIK this should work as long as you run full emulation (qemu, not kvm) as > libvirt_type in nova.conf and get the qemu-system-ppc64le installed in the compute node. Assume also you get the > ppc64le image to launch your instance. Expect poor performance though. that is my understanding also. the perfromace is accepable but not great if you can enabled the multithread tcg backend instead of the default singel tread tcg backend that is used when in qemu only mode but it still wont match kvm accleration or power on power performance. i dont think we have a way to enabel the multi thread accleration for qemu only backend via nova unfortunetly it would be triavial to add but no one has asked as far as i am aware. > > On Mon, Nov 19, 2018 at 4:12 PM Sean Mooney wrote: > > adding openstack dev. > > On Mon, 2018-11-19 at 18:08 +0000, Sean Mooney wrote: > > > On Mon, 2018-11-19 at 11:57 -0500, Ken D'Ambrosio wrote: > > > > On 2018-11-19 11:25, Yedhu Sastri wrote: > > > > > Hello All, > > > > > > > > > > I have some use-cases which I want to test in PowerPC architecture(ppc64). As I dont have any Power machines I > > > > > would > > > > > like to try it with ppc64 VM's. Is it possible to run these kind of VM's on my OpenStack cluster(Queens) which > > > > > runs > > > > > on X86_64 architecture nodes(OS RHEL 7)?? > > > > > > > > > > > > > I'm not 100% sure, but I'm 95% sure that the answer to your question is "No." While there's much emulation that > > > > occurs, the CPU isn't so much emulated, but more abstracted. Constructing and running a modern CPU in software > > > > would > > > > be non-trivial. > > > > > > you can do this but not with kvm. > > > you need to revert the virt dirver in the nova.conf back to qemu to disable kvm to allow emulation of other > > > plathforms. > > > that said i have only emulated power on x86_64 using libvirt or qemu idrectly never with openstack but i belive we > > > used > > > to support this i just hav enot done it personally. > > > > > > > > -Ken > > > > > > > > > I set the image property architecture=ppc64 to the ppc64 image I uploaded to glance but no success in > > launching VM > > > > > with those images. I am using KVM as hypervisor(qemu 2.10.0) in my compute nodes and I think it is not built > > to > > > > > support power architecture. For testing without OpenStack I manually built qemu on a x86_64 host with ppc64 > > > > > support(qemu-ppc64) and then I am able to host the ppc64 VM. But I dont know how to do this on my OpenStack > > > > > cluster. > > > > > Whether I need to manually build qemu on compute nodes with ppc64 support or I need to add some lines in my > > > > > nova.conf to do this?? Any help to solve this issue would be much appreciated. > > > > > > > > > > > > > > > -- > > > > > Thank you for your time and have a nice day, > > > > > > > > > > With kind regards, > > > > > Yedhu Sastri > > > > > > > > > > _______________________________________________ > > > > > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > Post to : openstack at lists.openstack.org > > > > > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > > > > _______________________________________________ > > > > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > Post to : openstack at lists.openstack.org > > > > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From chris.friesen at windriver.com Mon Nov 19 20:48:45 2018 From: chris.friesen at windriver.com (Chris Friesen) Date: Mon, 19 Nov 2018 14:48:45 -0600 Subject: [Openstack] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes?? In-Reply-To: References: Message-ID: <031e51d9-6f0f-40de-3fff-6a0690ade675@windriver.com> On 11/19/2018 10:25 AM, Yedhu Sastri wrote: > Hello All, > > I have some use-cases which I want to test in PowerPC > architecture(ppc64). As I dont have any Power machines I would like to > try it with ppc64 VM's. Is it possible to run these kind of VM's on my > OpenStack cluster(Queens) which runs on X86_64 architecture nodes(OS > RHEL 7)?? > > I set the image property architecture=ppc64 to the ppc64 image I > uploaded to glance but no success in launching VM with those images. I > am using KVM as hypervisor(qemu 2.10.0) in my compute nodes and I think > it is not built to support power architecture. For testing without > OpenStack I manually built qemu on a x86_64 host with ppc64 > support(qemu-ppc64) and then I am able to host the ppc64 VM. But I dont > know how to do this on my OpenStack cluster. Whether I need to manually > build qemu on compute nodes with ppc64 support or I need to add some > lines in my nova.conf to do this?? Any help to solve this issue would be > much appreciated. I think that within an OpenStack cluster you'd have to dedicate a whole compute node to running ppc64 and have it advertise the architecture as ppc64. Then when you ask for "architecture=ppc64" it should land on that node. If this is for "development, testing or migration of applications to Power" have you checked out these people? They provide free Power VMs. http://openpower.ic.unicamp.br/minicloud/ Chris _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From zbitter at redhat.com Mon Nov 19 21:34:48 2018 From: zbitter at redhat.com (Zane Bitter) Date: Mon, 19 Nov 2018 16:34:48 -0500 Subject: [openstack-dev] [nova] Stein forum session notes In-Reply-To: <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> Message-ID: On 19/11/18 8:31 AM, Jay Pipes wrote: > >> Getting users involved in the project >> ===================================== >> - Disconnect between SIGs/WGs and project teams >> - Too steep a first step to get involved by subscribing to ML >> - People confused about how to participate > > Seriously? If subscribing to a mailing list is seen as too much of a > burden for users to provide feedback, I'm wondering what the point is of > having an open source community at all. The gist of the session was that the steps we have traditionally recommended were appropriate for somebody who has just been hired to work (substantially) full-time on upstream OpenStack, which at one time was not only common but arguably the best thing for us to concentrate on optimising. However, the same is not necessarily true for other types of contributors. For example, if someone is an operator of OpenStack with no time carved out to contribute, we still want them to push any patches they have upstream where possible, and some of those folks may even go on from there to become long-term contributors. (Ditto for end-users and bug reports.) For those folks, "sign up for ~17k p/a emails straight to your inbox and then maybe we'll talk" isn't the most helpful first step. FWIW, my input to the session was essentially this: * It isn't actually a great mystery how you retain and grow casual contributors: you make sure they get immediate, friendly, actionable, but most importantly immediate feedback any time they interact with the rest of the community. I believe that all of us understand this on some level. * If this were our top priority it would be completely feasible (though something else would certainly be sacrificed). * Revealed preferences suggest that it isn't, which is why we are discussing everything but that. cheers, Zane. From jungleboyj at gmail.com Mon Nov 19 21:37:06 2018 From: jungleboyj at gmail.com (Jay S Bryant) Date: Mon, 19 Nov 2018 15:37:06 -0600 Subject: [cinder] On-Boarding Session Slides Posted ... Message-ID: <415d3fd4-81f6-8a4a-f673-c182d3db7924@gmail.com> All, For those who are interested I have posted my Cinder Project On-Boarding slides here: [1] Thanks! Jay [1] https://www.slideshare.net/JayBryant2/cinder-onboarding-room-berlin-11132018 From smooney at redhat.com Mon Nov 19 21:39:19 2018 From: smooney at redhat.com (Sean Mooney) Date: Mon, 19 Nov 2018 21:39:19 +0000 Subject: [Openstack] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes?? In-Reply-To: <031e51d9-6f0f-40de-3fff-6a0690ade675@windriver.com> References: <031e51d9-6f0f-40de-3fff-6a0690ade675@windriver.com> Message-ID: <5b16085e300954633f0d724d3db643b8fa05c914.camel@redhat.com> On Mon, 2018-11-19 at 14:48 -0600, Chris Friesen wrote: > On 11/19/2018 10:25 AM, Yedhu Sastri wrote: > > Hello All, > > > > I have some use-cases which I want to test in PowerPC > > architecture(ppc64). As I dont have any Power machines I would like to > > try it with ppc64 VM's. Is it possible to run these kind of VM's on my > > OpenStack cluster(Queens) which runs on X86_64 architecture nodes(OS > > RHEL 7)?? > > > > I set the image property architecture=ppc64 to the ppc64 image I > > uploaded to glance but no success in launching VM with those images. I > > am using KVM as hypervisor(qemu 2.10.0) in my compute nodes and I think > > it is not built to support power architecture. For testing without > > OpenStack I manually built qemu on a x86_64 host with ppc64 > > support(qemu-ppc64) and then I am able to host the ppc64 VM. But I dont > > know how to do this on my OpenStack cluster. Whether I need to manually > > build qemu on compute nodes with ppc64 support or I need to add some > > lines in my nova.conf to do this?? Any help to solve this issue would be > > much appreciated. > > I think that within an OpenStack cluster you'd have to dedicate a whole > compute node to running ppc64 and have it advertise the architecture as > ppc64. Then when you ask for "architecture=ppc64" it should land on > that node. you know it says it for arm but you might be able to do this by setting hw_machine_type https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt-image.json#L34 i know you can set the hw_machine_type to set teh default for all instace on a host https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.hw_machine_type but i can rememebr it image property is alys used or if its just used for arm as the docs suggest. the hypervisor_type in the image should be set to qemu to make sure you avoid the kvm hosts as they will not work for cpu emulation. > > If this is for "development, testing or migration of applications to > Power" have you checked out these people? They provide free Power VMs. > > http://openpower.ic.unicamp.br/minicloud/ > > Chris > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From doug at doughellmann.com Tue Nov 20 00:28:37 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 19 Nov 2018 19:28:37 -0500 Subject: [goals][tc] community-wide goals for train development cycle Message-ID: Last week at the Forum in Berlin we met to discuss potential community-wide goals for the Train development cycle. We had a good list of proposals [1], although some of them do not meet the criteria for the goals program as currently defined [2]. We came up with a few suggestions that do fit the criteria, listed here in the order we discussed them: * Ensure that each project has contributor on-boarding documentation in a discoverable place in their documentation tree, and link to that from the contributor portal at openstack.org/community. (proposed by TheJulia) This should be relatively light-weight for teams to do, and will uncover some good opportunities for documentation reuse. * Deletion of project resources. (proposed by tobberydberg and adriant) This has been a long-standing request from operators, as discussed in forum session earlier in the week [3]. The propose next-steps are to establish a way for the existing os-purge program to accept plugins so that project teams can declare the relationships between resources that need to be deleted, to make orchestration easier. See the etherpad from the session for more details. * Finish moving legacy python-*client CLIs to python-openstackclient (proposed by mriedem on behalf of Tim Bell) This is another initiative that has been going on for a few years, and completing it would give users more clarity as well as providing a more consistent user interface. The general idea was to finish implementing all of the commands within OSC using the existing client libs, then update the SDK to support those features so we can drop the client libs from OSC as well, giving us 1 SDK and 1 CLI. That’s a multi-step process, so I think for the first phase targeting completing all of the commands within OSC using the various client libraries would be enough for 1 cycle. * Ensure all projects pass request-id when calling one another. (proposed by Pavlo Shchelokovskyy) Passing request-id allows us to chain requests together and trace them for debugging and profiling. We started this a while back and some projects are doing it but not all. * Rolling out oslo health-check middleware so each project provides that API. (proposed by mugsie) This came up at the PTG in Denver earlier this year [4]. There will be some up-front work to make the health check API able to support real backend checks for the database, message bus, etc. Then we would need to add the middleware to all services. In all of these cases, we have a bit more up-front work to do to be ready to accept the idea as a goal. There should be time during the remainder of the Stein cycle to make enough progress on that work to know if we could accept it as a goal. Our next steps are for the people proposing these goals to ensure that up-front work is done and be prepared to write up the goal document for review. If the proposes aren’t able/willing to act as goal champions, we need to identify someone else to fill that role. I propose we set a target of early March for having the formal goal proposals ready for review. That will give us time to approve them well before the next Summit/PTG, so that teams can use time during the PTG for planning their implementation. [1] https://etherpad.openstack.org/p/BER-t-series-goals [2] https://governance.openstack.org/tc/goals/index.html [3] https://etherpad.openstack.org/p/BER-deletion-of-project-resources [4] 1. https://etherpad.openstack.org/p/api-sig-stein-ptg (line 20) -- Doug From andrea.franceschini.rm at gmail.com Tue Nov 20 00:13:35 2018 From: andrea.franceschini.rm at gmail.com (Andrea Franceschini) Date: Tue, 20 Nov 2018 01:13:35 +0100 Subject: [openstack-dev] [omni] Has the Platform9's hybrid multicloud project been abandoned? Message-ID: Hello All, I'm trying to figure out if the project openstack/omni https://github.com/openstack/omni has been abandoned or superseded by another project, as it is no longer updated (at least not in the last year). Generally speaking, which is, if any, a project that aims at the same goal? In other words, which way should hybrid cloud be approached in Openstack? Do you have any idea/advice? Thanks a lot, Andrea __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From david.ames at canonical.com Tue Nov 20 00:30:27 2018 From: david.ames at canonical.com (David Ames) Date: Mon, 19 Nov 2018 16:30:27 -0800 Subject: [openstack-dev] [charms] 18.11 OpenStack Charms release Message-ID: Announcing the 18.11 release of the OpenStack Charms. The 18.11 charms have support for Nova cells v2 for deployments of Queens and later. The 18.11 release also has preview features including series upgrades and the Octavia load balancer charm. 47 bugs have been fixed and released across the OpenStack charms. For full details of the release, please refer to the release notes: https://docs.openstack.org/charm-guide/latest/1811.html Thanks go to the following contributors for this release: Alex Kavanagh Andrey Grebennikov Aymen Frikha Billy Olsen Chris MacNaughton Chris Sanders Corey Bryant David Ames Dmitrii Shcherbakov Drew Freiberger Edward Hope-Morley Felipe Reyes Frode Nordahl Fulvio Galeazzi James Page Liam Young Neiloy Mukerjee Pedro Guimarães Pete Vander Giessen Ryan Beisner Vladimir Grevtsev dongdong tao viswesuwara nathan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From xuchao at chinacloud.com.cn Tue Nov 20 02:26:12 2018 From: xuchao at chinacloud.com.cn (xuchao at chinacloud.com.cn) Date: Tue, 20 Nov 2018 10:26:12 +0800 Subject: [openstack-dev] =?gb2312?b?W1Nlbmxpbl0gRG9lcyBTZW5saW4gc3VwcG9y?= =?gb2312?b?dCBQcm9tZXRoZXVzo78=?= Message-ID: <201811201022041324405@chinacloud.com.cn> Hi， Senlin, Ceilometer/Aodh is currently integrated, does it support Prometheus ？ thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From lijie at unitedstack.com Tue Nov 20 03:32:59 2018 From: lijie at unitedstack.com (=?utf-8?B?UmFtYm8=?=) Date: Tue, 20 Nov 2018 11:32:59 +0800 Subject: [openstack-dev] [nova] about filter the flavor Message-ID: Hi,all I have an idea.Now we can't filter the special flavor according to the property.Can we achieve it?If we achieved this,we can filter the flavor according the property's key and value to filter the flavor. What do you think of the idea?Can you tell me more about this ?Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From blake at platform9.com Tue Nov 20 06:08:39 2018 From: blake at platform9.com (Blake Covarrubias) Date: Mon, 19 Nov 2018 22:08:39 -0800 Subject: [openstack-dev] [omni] Has the Platform9's hybrid multicloud project been abandoned? In-Reply-To: References: Message-ID: Hi Andrea, Omni has not been abandoned by Platform9. We're still developing Omni internally, and are working to open source additional code as well as improve docs so that others may more easily test & contribute. With that said, I too would be interested in hearing how others are enabling, or looking to enable, hybrid cloud use cases with OpenStack. I'm not aware of any other projects with similar goals as Omni, however its possible I just haven't been looking in the right places. Regards, On Mon, Nov 19, 2018 at 7:40 PM Andrea Franceschini < andrea.franceschini.rm at gmail.com> wrote: > Hello All, > > I'm trying to figure out if the project openstack/omni > > https://github.com/openstack/omni > > has been abandoned or superseded by another project, as it is no > longer updated (at least not in the last year). > > Generally speaking, which is, if any, a project that aims at the same goal? > > In other words, which way should hybrid cloud be approached in Openstack? > > Do you have any idea/advice? > > Thanks a lot, > > Andrea > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Blake Covarrubias | Product Manager -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From gmann at ghanshyammann.com Tue Nov 20 09:07:16 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 20 Nov 2018 18:07:16 +0900 Subject: [dev] [tc][all] TC office hours is started now on #openstack-tc Message-ID: <167305fb147.c17c26d4108100.2603609025274153561@ghanshyammann.com> Hi All, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - TC From lenikmutungi at gmail.com Tue Nov 20 09:15:48 2018 From: lenikmutungi at gmail.com (Leni Kadali Mutungi) Date: Tue, 20 Nov 2018 12:15:48 +0300 Subject: [all] maintainers/reviewers/committers wanted for tiny projects In-Reply-To: References: Message-ID: <1cbec8d6-b92b-3067-ec2e-99f822d2f695@gmail.com> Hi Chris! Would like to be a committer to paste, WSME, and gabbi. I can see that gabbi has the most issues of the three so maybe I could start there? Or is there a project which you think needs the attention more urgently? On 11/19/18 1:56 PM, Chris Dent wrote: > > I was recently going through the list of things to which I'm trying > to pay attention and realized there are quite a few small software > projects that are OpenStack-related that could do with additional > attention because I'm either the sole or one of few maintainers. > Some of these are hosted on OpenStack^wOpendev infra, some not. > > If you're interested in helping out, please have a look and feel > free to ask me questions. Many are in some state of either disrepair > or incompleteness because they were adopted from absentee owners. > > Paste: WSGI middleware management framework >     https://github.com/cdent/paste >     This was recently adopted because it had issues with Python 3.7 >     and there were concerns that OpenStack's continued use might >     present problems. > >     I've also just inherited the pastedeploy package, and will be >     migrating it over to github too. It will also need some help. > >     Use Flask instead. > > WSME: Web Service Made Easy (ha!) >     http://git.openstack.org/cgit/openstack/wsme >     For a brief period back in the day, this was the recommended way >     to make a web service in OpenStack. Soon after that it was >     abandoned by its maintainers and Lucas Gomez and I were >     press-ganged into maintaining it. It still gets the occasional >     patch to fix testing or Python 3 -related bugs. > >     Does anyone still use this? > >     Use Flask instead. > > microversion-parse: Library and WSGI middleware for parsing >                     microversion headers >     http://git.openstack.org/cgit/openstack/microversion-parse >     This was extracted from placement's implementation for handling >     microversions. It tries to be framework agnostic, but is biased >     somewhat towards WebOb. It's nominally under the management of >     the API-SIG but it would be good to see it getting more use and >     thus more fixes. It's also used in Nova, not sure where else. > > wsgi-intercept: Intercept socket connection to wsgi applications >                 for testing >     https://github.com/cdent/wsgi-intercept >     A convenient way to do functional testing of WSGI applications >     without needing to run a separate process but while still doing >     legit HTTP. Is used in nova and placement, and may still be used >     in the telemetry projects. It's old but very useful. It's at the >     core of gabbi. > > gabbi: Declarative HTTP Testing for Python and anything else >     https://github.com/cdent/gabbi >     YAML-driven testing of HTTP APIs that makes live _so_ _much_ >     _easier_. Was developed when I was working on telemetry, and is >     now central to the functional testing of placement. > > gabbi-tempest: A tempest plugin for using gabbi >     https://git.openstack.org/cgit/openstack/gabbi-tempest >     A tempest plugin + zuul job to make it super easy to use gabbi >     tests for driving integration tests in OpenStack, by mostly >     adding some YAML. > > If you're interested, great! Please let me know or simply start > fixing things. > -- -- Kind regards, Leni Kadali Mutungi From jean-philippe at evrard.me Tue Nov 20 09:32:36 2018 From: jean-philippe at evrard.me (Jean-Philippe Evrard) Date: Tue, 20 Nov 2018 10:32:36 +0100 Subject: [OpenStack-I18n][docs][i18n] Team meeting proposal In-Reply-To: <3a2db232-44e0-4f17-3bf3-7411b0ea0ea8@gmail.com> References: <3a2db232-44e0-4f17-3bf3-7411b0ea0ea8@gmail.com> Message-ID: <0feeddda87c9af9097192272559463d3b4dbeb1d.camel@evrard.me> On Tue, 2018-11-20 at 01:13 +0900, Ian Y. Choi wrote: > +1 > > Thanks a lot for such a proposal - I briefly talked with Petr, Docs > team > PTL during the last PTG, > but I link your detail proposal how to combine Docs + I18n IRC > meeting. > > > With many thanks, > > /Ian > > Remo Mattei wrote on 11/19/2018 11:14 PM: > > Sounds good will try to make the meetings > > > > Il giorno 19 nov 2018, alle ore 05:46, SungJin Kang > > > ha > > scritto: > > > > > Hi Frank, > > > > > > I agree :) > > > > > > Thanks. > > > Sungjin > > > > > > 2018년 11월 19일 (월) 오후 6:18, Frank Kloeker > > >님이 작성: > > > > > > Hello, > > > > > > in the last weeks we had some informal discussions about > > > combined > > > team > > > meeting for documentation and translation team. There should > > > be > > > overlapping topics and other project teams or operator would > > > have > > > the > > > same contact persons on the same place. We also save > > > resources on > > > meeting chairs. > > > > > > Here are my proposal: > > > 1) Meeting room #openstack-meeting > > > 2) Switch back from (informal) Office Hour to (formal) Team > > > Meeting. > > > Topics for upcoming meetings will be collected on a Wiki > > > page. If > > > there > > > are no topic we would skip the meeting. So often we recorded > > > empty > > > sessions in the past. > > > 3) Meeting time is Thursday 07:00 UTC (odd week), 16:00 UTC > > > (even > > > week) > > > 4) First part (30 min) I18n topics, second part documentation > > > topics, > > > meetingbot will recorded two sessions, so it's easier to read > > > specific > > > topics later. > > > 5) Rotating meeting chairs between the two teams. > > > > > > This should renew a little bit the conversation and we are > > > more > > > flexible > > > and visible on the move. > > > > > > kind regards > > > > > > Frank (PTL I18n) > > > > > > > > > _______________________________________________ > > > OpenStack-I18n mailing list > > > OpenStack-I18n at lists.openstack.org > > > > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n > > > > > > _______________________________________________ > > > OpenStack-I18n mailing list > > > OpenStack-I18n at lists.openstack.org > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n > > > > _______________________________________________ > > OpenStack-I18n mailing list > > OpenStack-I18n at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n > > I like the idea :) As long as people looking for the docs/i18n projects can find how to meet the team (please change eavesdrop's agenda and text when confirmed!), I am good with that change. Jean-Philippe Evrard (evrardjp) From melwittt at gmail.com Tue Nov 20 10:35:23 2018 From: melwittt at gmail.com (melanie witt) Date: Tue, 20 Nov 2018 11:35:23 +0100 Subject: [openstack-dev] [nova] Can we deprecate the server backup API please? In-Reply-To: References: <7778dd25-53f8-ca5c-55c5-0c0e6db29be4@gmail.com> Message-ID: On Mon, 19 Nov 2018 08:36:40 -0500, Jay Pipes wrote: > On 11/19/2018 08:15 AM, Matt Riedemann wrote: >> On 11/18/2018 6:51 AM, Alex Xu wrote: >>> Sounds make sense to me, and then we needn't fix this strange >>> behaviour also https://review.openstack.org/#/c/409644/ >> >> The same discussion was had in the spec for that change: >> >> https://review.openstack.org/#/c/511825/ >> >> Ultimately it amounted to a big "meh, let's just not fix the bug but >> also no one really cares about deprecating the API either". > > So we'll let the apathy of the past dictate the actions of the future. FWIW, my point of view on deprecating the API was/is, if people are using it to accomplish some task, why deprecate it if it's not hurting anything else? That is, I didn't want the aforementioned spec to amount to something like, someone proposes to fix a strange behavior they observed using the API and our answer is to deprecate the entire API. If it's clear that no one is using or benefiting from the API, then I am in support of deprecating it. But I haven't felt certain about whether that's the case so far. >> The only thing deprecating the API would do is signal that it probably >> shouldn't be used. We would still support it on older microversions. If >> all anyone cares about is signalling not to use the API then deprecation >> is probably fine, but I personally don't feel too strongly about it >> either way. > > Deprecating these kinds of APIs would, as I mentioned in my original > post, signal that the Nova team is actually serious about cleaning up > the cruft and getting rid of the debt from years past. > > And also that it is serious about Nova not being a dumping ground for > orchestration and out-of-scope APIs not related to a Compute API. That's fair enough, and if we can get a quick confirmation from operators we know (CERN, NeCTAR, Oath, Vexxhost, OVH, etc) that they don't use the API, I agree we should go ahead and deprecate it for the reasons you mention. -melanie From yedhusastri at gmail.com Tue Nov 20 10:39:37 2018 From: yedhusastri at gmail.com (Yedhu Sastri) Date: Tue, 20 Nov 2018 11:39:37 +0100 Subject: [Openstack] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes?? In-Reply-To: <5b16085e300954633f0d724d3db643b8fa05c914.camel@redhat.com> References: <031e51d9-6f0f-40de-3fff-6a0690ade675@windriver.com> <5b16085e300954633f0d724d3db643b8fa05c914.camel@redhat.com> Message-ID: Thank you all for the valuable informations. So I will try with one compute node which has qemu as libvirt_type in nova.conf and then I hope I can host ppc64 VM's on that node. On Mon, Nov 19, 2018 at 10:47 PM Sean Mooney wrote: > On Mon, 2018-11-19 at 14:48 -0600, Chris Friesen wrote: > > On 11/19/2018 10:25 AM, Yedhu Sastri wrote: > > > Hello All, > > > > > > I have some use-cases which I want to test in PowerPC > > > architecture(ppc64). As I dont have any Power machines I would like to > > > try it with ppc64 VM's. Is it possible to run these kind of VM's on my > > > OpenStack cluster(Queens) which runs on X86_64 architecture nodes(OS > > > RHEL 7)?? > > > > > > I set the image property architecture=ppc64 to the ppc64 image I > > > uploaded to glance but no success in launching VM with those images. I > > > am using KVM as hypervisor(qemu 2.10.0) in my compute nodes and I > think > > > it is not built to support power architecture. For testing without > > > OpenStack I manually built qemu on a x86_64 host with ppc64 > > > support(qemu-ppc64) and then I am able to host the ppc64 VM. But I > dont > > > know how to do this on my OpenStack cluster. Whether I need to > manually > > > build qemu on compute nodes with ppc64 support or I need to add some > > > lines in my nova.conf to do this?? Any help to solve this issue would > be > > > much appreciated. > > > > I think that within an OpenStack cluster you'd have to dedicate a whole > > compute node to running ppc64 and have it advertise the architecture as > > ppc64. Then when you ask for "architecture=ppc64" it should land on > > that node. > you know it says it for arm but you might be able to do this by setting > hw_machine_type > https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt-image.json#L34 > i know you can set the hw_machine_type to set teh default for all instace > on a host > > https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.hw_machine_type > but i can rememebr it image property is alys used or if its just used for > arm as the docs suggest. > > the hypervisor_type in the image should be set to qemu to make sure you > avoid the kvm hosts as they will not work > for cpu emulation. > > > > > > If this is for "development, testing or migration of applications to > > Power" have you checked out these people? They provide free Power VMs. > > > > http://openpower.ic.unicamp.br/minicloud/ > > > > Chris > > > > _______________________________________________ > > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > Post to : openstack at lists.openstack.org > > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Thank you for your time and have a nice day, With kind regards, Yedhu Sastri -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From melwittt at gmail.com Tue Nov 20 11:20:44 2018 From: melwittt at gmail.com (melanie witt) Date: Tue, 20 Nov 2018 12:20:44 +0100 Subject: [openstack-dev] [nova] Stein forum session notes In-Reply-To: <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> Message-ID: <0eccbebf-49bd-6ec9-e2f3-2958534038b9@gmail.com> On Mon, 19 Nov 2018 08:31:59 -0500, Jay Pipes wrote: > Thanks for the highlights, Melanie. Appreciated. Some thoughts inline... > > On 11/19/2018 04:17 AM, melanie witt wrote: >> Hey all, >> >> Here's some notes I took in forum sessions I attended -- feel free to >> add notes on sessions I missed. >> >> Etherpad links: https://wiki.openstack.org/wiki/Forum/Berlin2018 >> >> Cheers, >> -melanie >> >> >> TUE >> --- >> >> Cells v2 updates >> ================ >> - Went over the etherpad, no objections to anything >> - Not directly related to the session, but CERN (hallway track) and >> NeCTAR (dev ML) have both given feedback and asked that the >> policy-driven idea for handling quota for down cells be avoided. Revived >> the "propose counting quota in placement" spec to see if there's any way >> forward here > > \o/ > >> Getting users involved in the project >> ===================================== >> - Disconnect between SIGs/WGs and project teams >> - Too steep a first step to get involved by subscribing to ML >> - People confused about how to participate > > Seriously? If subscribing to a mailing list is seen as too much of a > burden for users to provide feedback, I'm wondering what the point is of > having an open source community at all. > >> Community outreach when culture, time zones, and language differ >> ================================================================ >> - Most discussion around how to synchronize real-time communication >> considering different time zones >> - Best to emphasize asynchronous communication. Discussion on ML and >> gerrit reviews > > +1 > >> - Helpful to create weekly meeting agenda in advance so contributors >> from other time zones can add notes/response to discussion items > > +1, though I think it's also good to be able to say "look, nobody has > brought up anything they'd like to discuss this week so let's not take > time out of people's busy schedules if there's nothing to discuss". > >> WED >> --- >> >> NFV/HPC pain points >> =================== >> Top issues for immediate action: NUMA-aware live migration (spec just >> needs re-approval), improved scheduler logging (resurrect cfriesen's >> patch and clean it up), distant third is SRIOV live migration >> >> BFV improvements >> ================ >> - Went over the etherpad, no major objections to anything >> - Agree: we should expose boot_index from the attachments API >> - Unclear what to do about post-create delete_on_termination. Being able >> to specify it for attach sounds reasonable, but is it enough for those >> asking? Or would it end up serving no one? >> >> Better expose what we produce >> ============================= >> - Project teams should propose patches to openstack/openstack-map to >> improve their project pages >> - Would be ideal if project pages included a longer paragraph explaining >> the project, have a diagram, list SIGs/WGs related to the project, etc >> >> Blazar reservations to new resource types >> ========================================= >> - For nova compute hosts, reservations are done by putting reserved >> hosts into "blazar" host aggregate and then a special scheduler filter >> is used to exclude those hosts from scheduling. But how to extend that >> concept to other projects? >> - Note: the nova approach will change from scheduler filter => placement >> request filter > > Didn't we agree in Denver to use a placement request filter that > generated a forbidden aggregate request for this? I know Matt has had > concerns about the proposed spec for forbidden aggregates not adequately > explaining the Nova side configuration, but I was under the impression > the general idea of using a forbidden aggregate placement request filter > was a good one? Yes, I think that is what was meant by the mention that the nova approach will change from the present scheduler filter (!blazar aggregate) to a placement request filter (the forbidden aggregate), going forward. I think the agreed idea you're talking about is what was mentioned in the session. >> Edge use cases and requirements >> =============================== >> - Showed the reference architectures again >> - Most popular use case was "Mobile service provider 5G/4G virtual RAN >> deployment and Edge Cloud B2B2X" with seven +1s on the etherpad > > Snore. > > Until one of those +1s is willing to uncouple nova-compute's tight use > of rabbitmq and RDBMS-over-rabbitmq that we use as our control plane in > Nova, all the talk of "edge" this and "MEC" that is nothing more than > ... well, talk. > >> Deletion of project and project resources >> ========================================= >> - What is wanted: a delete API per service that takes a project_id and >> force deletes all resources owned by it with --dry-run component >> - Challenge to work out the dependencies for the order of deletion of >> all resources in all projects. Disable project, then delete things in >> order of dependency >> - Idea: turn os-purge into a REST API and each project implement a >> plugin for it > > I don't see why a REST API would be needed. We could more easily > implement the functionality by focusing on a plugin API for each service > project and leaving it at that. > >> Getting operators' bug fixes upstreamed >> ======================================= >> - Problem: operator reports a bug and provides a solution, for example, >> pastes a diff in launchpad or otherwise describes how to fix the bug. >> How can we increase the chances of those fixes making it to gerrit? >> - Concern: are there legal issues with accepting patches pasted into >> launchpad by someone who hasn't signed the ICLA? >> - Possible actions: create a best practices guide tailored for operators >> and socialize it among the ops docs/meetup/midcycle group. Example: >> guidance on how to indicate you don't have time to add test coverage, >> etc when you propose a patch >> >> THU >> --- >> >> Bug triage: why not all the community? >> ====================================== >> - Cruft and mixing tasks with defect reports makes triage more difficult >> to manage. Example: difference between a defect reported by a user vs an >> effective TODO added by a developer. If New bugs were reliably from end >> users, would we be more likely to triage? >> - Bug deputy weekly ML reporting could help >> - Action: copy the generic portion of the nova bug triage wiki doc into >> the contributor guide docs. The idea/hope being that easy-to-understand >> instructions available to the wider community might increase the chances >> of people outside of the project team being capable of triaging bugs, so >> all of it doesn't fall on project teams >> - Idea: should we remove the bug supervisor requirement from nova to >> allow people who haven't joined the bug team to set Status and Importance? >> >> Current state of volume encryption >> ================================== >> - Feedback: public clouds can't offer encryption because keys are stored >> in the cloud. Telcos are required to make sure admin can't access >> secrets. Action: SecuStack has a PoC for E2E key transfer, mnaser to >> help see what could be upstreamed >> - Features needed: ability for users to provide keys or use customer >> barbican or other key store. Thread: >> http://lists.openstack.org/pipermail/openstack-dev/2018-November/136258.html >> >> >> Cross-technical leadership session (OpenStack, Kata, StarlingX, Airship, >> Zuul) >> ======================================================================== >> - Took down the structure of how leadership positions work in each >> project on the etherpad, look at differences >> - StarlingX taking a new approach for upstreaming, New strategy: align >> with master, analyze what they need, and address the gaps (as opposed to >> pushing all the deltas up). Bug fixes still need to be brought forward, >> that won't change >> >> Concurrency limits for service instance creation >> ================================================ >> - Looking for ways to test and detect changes in performance as a >> community. Not straightforward because test hardware must stay >> consistent in order to detect performance deltas, release to release. >> Infra can't provide such an environment >> - Idea: it could help to write up a doc per project with a list of the >> usual tunables and basic info about how to use them >> >> Change of ownership of resources >> ================================ >> - Ignore the network piece for now, it's the most complicated. Being >> able to transfer everything else would solve 90% of City Network's use >> cases >> - Some ideas around having this be a keystone auth-based access granting >> instead of an update of project/user, but if keystone could hand user A >> a token for user B, that token would apply to all resources of user B's, >> not just the ones desired for transfer > > Whatever happened with the os-chown project Dan started in Denver? > > https://github.com/kk7ds/oschown > >> Update on placement extraction from nova >> ======================================== >> - Upgrade step additions from integrated placement to extracted >> placement in TripleO and OpenStackAnsible are being worked on now >> - Reshaper patches for libvirt and xenapi drivers are up for review >> - Lab test for vGPU upgrade and reshape + new schedule for libvirt >> driver patch has been done already > > This is news to me. Can someone provide me a link to where I can get > some more information about this? So, I don't see a comment from Sylvain on the patch review itself, but I know that he has run the lab test on real hardware. I recall this IRC log, where he explained he ran the test before the "new schedule" patch landed: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-10-02.log.html#t2018-10-02T21:52:12 And here he confirms that a second test with reshape + new schedule works with the patch either after "new schedule" landed or rebased on top of: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-10-02.log.html#t2018-10-02T21:52:12 >> - FFU script work needs an owner. Will need to query libvirtd to get >> mdevs and use PlacementDirect to populate placement >> >> Python bindings for the placement API >> ===================================== >> - Placement client code replicated in different projects: nova, blazar, >> neutron, cyborg. Want to commonize into python bindings lib >> - Consensus was that the placement bindings should go into openstacksdk >> and then projects will consume it from there >> >> T series community goal discussion >> ================================== >> - Most popular goal ideas: Finish moving legacy python-*client CLIs to >> python-openstackclient, Deletion of project resources as discussed in >> forum session earlier in the week, ensure all projects use ServiceTokens >> when calling one another with incoming token >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > From melwittt at gmail.com Tue Nov 20 11:28:03 2018 From: melwittt at gmail.com (melanie witt) Date: Tue, 20 Nov 2018 12:28:03 +0100 Subject: [openstack-dev] [nova] Stein forum session notes In-Reply-To: References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> <6061a8e5-ad61-2075-223c-b540a911ebe1@gmail.com> Message-ID: <325ffcf6-b9a8-d7e4-fffd-4c9119c348bb@gmail.com> On Mon, 19 Nov 2018 17:19:22 +0100, Surya Seetharaman wrote: > > > On Mon, Nov 19, 2018 at 2:39 PM Matt Riedemann > wrote: > > On 11/19/2018 3:17 AM, melanie witt wrote: > > - Not directly related to the session, but CERN (hallway track) and > > NeCTAR (dev ML) have both given feedback and asked that the > > policy-driven idea for handling quota for down cells be avoided. > Revived > > the "propose counting quota in placement" spec to see if there's > any way > > forward here > > Should this be abandoned then? > > https://review.openstack.org/#/c/614783/ > > Since there is no microversion impact to that change, it could be added > separately as a bug fix for the down cell case if other operators want > that functionality. But maybe we don't know what other operators want > since no one else is at multi-cell cells v2 yet. > > > I thought the policy check was needed until the "propose counting quota > in placement" > has been implemented as a workaround and that is what the "handling down > cell" spec also proposed, > unless the former spec would be implemented within this cycle in which > case we do not need the > policy check. Right, I don't think that anyone _wants_ the policy check approach. That was just the workaround, last resort idea we had for dealing with down cells in the absence of being able to count quota usage from placement. The operators we've discussed with (CERN, NeCTAR, Oath) would like quota counting not to depend on cell databases, if possible. But they are understanding and will accept the policy-driven workaround if we can't move forward with counting quota usage from placement. If we can get agreement on the count quota usage from placement spec (I have updated it with new proposed details), then we should abandon the policy-driven behavior patch. I am eager to find out what everyone thinks of the latest proposal. Cheers, -melanie __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From manuel.sb at garvan.org.au Tue Nov 20 05:49:55 2018 From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros) Date: Tue, 20 Nov 2018 05:49:55 +0000 Subject: [Openstack] how to sync quota usage our of sync in Rocky release Message-ID: <9D8A2486E35F0941A60430473E29F15B017BAEB6FB@MXDB2.ad.garvan.unsw.edu.au> Dear Openstack community, I often have nova complaining that I have exceeded my quota, these normally happens when I node deployment fails and the resources allocated hasn't been released. Before Rocky I used to run the command below to resync, however it looks like it has been removed from Rocky. [root at TEST-openstack-controller ~]# docker exec -it -u root nova_scheduler nova-manage project quota_usage_refresh --project abc29399b91d423088549d7446766573 --user 02132c31dafa4d1d939bd52e0420b975 usage: nova-manage [-h] [--config-dir DIR] [--config-file PATH] [--debug] [--log-config-append PATH] [--log-date-format DATE_FORMAT] [--log-dir LOG_DIR] [--log-file PATH] [--nodebug] [--nopost-mortem] [--nouse-journal] [--nouse-json] [--nouse-syslog] [--nowatch-log-file] [--post-mortem] [--syslog-log-facility SYSLOG_LOG_FACILITY] [--use-journal] [--use-json] [--use-syslog] [--version] [--watch-log-file] [--remote_debug-host REMOTE_DEBUG_HOST] [--remote_debug-port REMOTE_DEBUG_PORT] {version,bash-completion,placement,network,cell_v2,db,cell,floating,api_db} ... nova-manage: error: argument category: invalid choice: 'project' (choose from 'version', 'bash-completion', 'placement', 'network', 'cell_v2', 'db', 'cell', 'floating', 'api_db') Any idea how can I refresh the quota usage in Rocky? Thank you very much Manuel Sopena Ballesteros | Big data Engineer Garvan Institute of Medical Research The Kinghorn Cancer Centre, 370 Victoria Street, Darlinghurst, NSW 2010 T: + 61 (0)2 9355 5760 | F: +61 (0)2 9295 8507 | E: manuel.sb at garvan.org.au NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From shardy at redhat.com Tue Nov 20 08:33:00 2018 From: shardy at redhat.com (Steven Hardy) Date: Tue, 20 Nov 2018 08:33:00 +0000 Subject: [openstack-dev] [omni] Has the Platform9's hybrid multicloud project been abandoned? In-Reply-To: References: Message-ID: On Tue, Nov 20, 2018 at 6:13 AM Blake Covarrubias wrote: > > Hi Andrea, > > Omni has not been abandoned by Platform9. We're still developing Omni internally, and are working to open source additional code as well as improve docs so that others may more easily test & contribute. It sounds like you're approaching this using an internal design process, so you may like to check: https://governance.openstack.org/tc/reference/opens.html The most recent commit was over a year ago, so it's understandably confusing to have an apparently unmaintained project, hosted under the openstack github org, which doesn't actually follow our comunity design/development process? > With that said, I too would be interested in hearing how others are enabling, or looking to enable, hybrid cloud use cases with OpenStack. I'm not aware of any other projects with similar goals as Omni, however its possible I just haven't been looking in the right places. Having design discussions in the open, and some way for others in the community to understand the goals and roadmap of the project is really the first step in engaging folks for this sort of discussion IME. Steve __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From lbragstad at gmail.com Tue Nov 20 12:33:50 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Tue, 20 Nov 2018 06:33:50 -0600 Subject: [keystone][nova] Availability zones and unified limits Message-ID: Unified limits cropped up in a few discussions last week. After describing the current implementation of limits, namely the attributes that make up a limit, someone asked if availability zones were on the roadmap. Ideally, it sounded like they had multiple AZs in a single region, and they wanted to be able to limit usage within the AZ. With the current implementation, regions would be the smallest unit of a deployment they could limit (e.g., limit project Foo to only using 64 compute cores within RegionOne). Instead, the idea would be to limit the number of resources for that project on an AZ within a region. What do people think about adding availability zones to limits? Should it be an official attribute in keystone? What other services would need this outside of nova? There were a few other interesting cases that popped up, but I figured we could start here. I can start another thread if needed and we can keep this specific to discussing limits + AZs. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaypipes at gmail.com Tue Nov 20 14:08:46 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Tue, 20 Nov 2018 09:08:46 -0500 Subject: [keystone][nova] Availability zones and unified limits In-Reply-To: References: Message-ID: <8f032c3c-73d1-6690-2465-bf11864d4316@gmail.com> On 11/20/2018 07:33 AM, Lance Bragstad wrote: > Unified limits cropped up in a few discussions last week. After > describing the current implementation of limits, namely the attributes > that make up a limit, someone asked if availability zones were on the > roadmap. > > Ideally, it sounded like they had multiple AZs in a single region, and > they wanted to be able to limit usage within the AZ. With the current > implementation, regions would be the smallest unit of a deployment they > could limit (e.g., limit project Foo to only using 64 compute cores > within RegionOne). Instead, the idea would be to limit the number of > resources for that project on an AZ within a region. > > What do people think about adding availability zones to limits? Should > it be an official attribute in keystone? What other services would need > this outside of nova? > > There were a few other interesting cases that popped up, but I figured > we could start here. I can start another thread if needed and we can > keep this specific to discussing limits + AZs. Keystone should have always been the thing that stores region and availability zone information. When I wrote the regions functionality for Keystone's catalog [1] I deliberately added the concept that a region can have zero or more sub-regions [2] to it. A region in Keystone wasn't (and AFAIK to this day isn't) specific to a geographic location. There's nothing preventing anyone from adding sub-regions that represent a nova availability zone [3] to Keystone. And since there's nothing preventing the existing Keystone limits API from associating a set of limits with a specific region [4] (yes, even a sub-region that represents an availability zone) I don't see any reason why the existing structures in Keystone could not be used to fulfill this functionality from the Keystone side. The problem is *always* going to be on the Nova side (and any project that made the unfortunate decision to copy nova's availability zone "implementation" [5]... hi Cinder! [6]). The way that the availability zone concept has been hacked into Nova means it's just going to be a hack on top of a hack to get per-AZ quotas working in Nova. I know this because Oath deploys this hack on top of a hack in order to divvy up resources per power domain and physical network (those two things and the site/DC essentially comprise what our availability zones are internally). Once again, not addressing the technical debt of years past -- which in this case is the lack of solid modeling of an availability zone concept in the Nova subsystems -- is hindering the forward progress of the project, which is sad. The long-term solution is to have Nova scrap it's availability zone code that relies on host aggregate metadata to work, use Keystone's /regions endpoint (and the hierarchy possible therein) as the single source of truth about availability zones, move the association of availability zone out of the Service model and onto the ComputeNode model, and have a cache of real AvailabilityZone data models stored in the Nova API top-level service. I fear that without truly tackling this underlying problem, we can make lots of progress on the Keystone side but things will slow to a crawl with people trying to figure out what the heck is going on in Nova with availability zones and how they could be tied in to quota handling. Sorry to be a pessimist^realist, -jay [1] https://github.com/openstack/keystone/commit/7c847578c8ed6a4921a24acb8a60f9264dd72aa1 [2] https://developer.openstack.org/api-ref/identity/v3/index.html#regions [3] As I've mentioned numerous times before, there's nothing "availability" about a nova availability zone. There's no guarantees about failure domains leaking across multiple nova availability zones. Nova's availability zones are an anachronism from when a nova endpoint serviced a single isolated set of compute resources. [4] https://developer.openstack.org/api-ref/identity/v3/index.html?expanded=create-limits-detail#create-limits [5] Behold, the availability zone implementation in Nova: https://github.com/openstack/nova/blob/ea26392239e67b9504801ee9a478e066ffa2951f/nova/availability_zones.py You'll notice there's no actual data model for an AvailabilityZone anywhere in either the nova_api or nova_cell databases: https://github.com/openstack/nova/blob/ea26392239e67b9504801ee9a478e066ffa2951f/nova/db/sqlalchemy/api_models.py https://github.com/openstack/nova/blob/ea26392239e67b9504801ee9a478e066ffa2951f/nova/db/sqlalchemy/models.py Which puts "availability zone" in rare company inside Nova as one of the only data concepts that has no actual data model behind it. It shares this distinction with one other data concept... yep, you guessed it... the "region". [6] Sorry, Cinder, you inherited the lack of a real data model for availability zones from Nova: https://github.com/openstack/cinder/blob/b8167a5c3e5952cc52ff8844804b7a5ab36459c8/cinder/volume/api.py#L115-L153 From mihalis68 at gmail.com Tue Nov 20 14:29:10 2018 From: mihalis68 at gmail.com (Chris Morgan) Date: Tue, 20 Nov 2018 09:29:10 -0500 Subject: quick report on microstack Message-ID: Mark Shuttleworth introduced 'microstack' at the conference last week. It's a snap based openstack install suitable for getting a quick instance up for playing with. Project here : https://github.com/CanonicalLtd/microstack Its's aimed at bring-up on an actual ubuntu-installed host, however I got it running on a virtual Ubuntu VM on my Mac with a trivial change (see https://github.com/CanonicalLtd/microstack/issues/41) I found it an quick, easy, even fun way to get a test openstack instance, it installed in just a few minutes for me. It's a single command: snap install microstack --classic --edge So far I got a cirros instance to launch, but didn't yet manage to ssh into that instance, but I only had about an hour playing with it so far. Definitely a fun toy. Chris -- Chris Morgan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrhillsman at gmail.com Tue Nov 20 14:37:35 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Tue, 20 Nov 2018 08:37:35 -0600 Subject: quick report on microstack In-Reply-To: References: Message-ID: I tried it as well, as a one off it seems useful, but after about an hour and looking at some of the issues on GitHub it is definitely in need of some TLC. Restarting and reconfiguring is a pickle to say the least. For example, if you want to access it from other than localhost. I do however like the simplicity of it out the gate. On Tue, Nov 20, 2018, 8:30 AM Chris Morgan Mark Shuttleworth introduced 'microstack' at the conference last week. > It's a snap based openstack install suitable for getting a quick instance > up for playing with. > > Project here : https://github.com/CanonicalLtd/microstack > > Its's aimed at bring-up on an actual ubuntu-installed host, however I got > it running on a virtual Ubuntu VM on my Mac with a trivial change (see > https://github.com/CanonicalLtd/microstack/issues/41) > > I found it an quick, easy, even fun way to get a test openstack instance, > it installed in just a few minutes for me. It's a single command: > > snap install microstack --classic --edge > > So far I got a cirros instance to launch, but didn't yet manage to ssh > into that instance, but I only had about an hour playing with it so far. > > Definitely a fun toy. > > Chris > -- > Chris Morgan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.urdin at binero.se Tue Nov 20 15:11:52 2018 From: tobias.urdin at binero.se (Tobias Urdin) Date: Tue, 20 Nov 2018 16:11:52 +0100 Subject: [keystone][nova] Availability zones and unified limits In-Reply-To: <8f032c3c-73d1-6690-2465-bf11864d4316@gmail.com> References: <8f032c3c-73d1-6690-2465-bf11864d4316@gmail.com> Message-ID: <3f0dc188-a6b3-7d0a-b22d-dedbb797f456@binero.se> I partially agree with your statements. I'm currently rolling the ball on availability zones in our deployments and it's a real pain and I think if there was an easier concept for a source of truth for AZs (and aggregates as well) there would be less confusion and a much better forward for inter-project support for such resources. My opinion though; quota's really make sense to store in Keystone since it's the source of truth for users and projects however I would say that AZs themselves is not on such a high level and isn't the same as Keystone knowing about the regions, it's region specific. I don't think Keystone should have a view on such a detailed level inside a region, I do agree that there is a void to be filled with something that gives the source of truth on AZs, host aggregates etc though. But moving that outside of a region defeats some purpose on the whole idea to isolate it in the first place. Best regards On 11/20/2018 03:10 PM, Jay Pipes wrote: > On 11/20/2018 07:33 AM, Lance Bragstad wrote: >> Unified limits cropped up in a few discussions last week. After >> describing the current implementation of limits, namely the attributes >> that make up a limit, someone asked if availability zones were on the >> roadmap. >> >> Ideally, it sounded like they had multiple AZs in a single region, and >> they wanted to be able to limit usage within the AZ. With the current >> implementation, regions would be the smallest unit of a deployment they >> could limit (e.g., limit project Foo to only using 64 compute cores >> within RegionOne). Instead, the idea would be to limit the number of >> resources for that project on an AZ within a region. >> >> What do people think about adding availability zones to limits? Should >> it be an official attribute in keystone? What other services would need >> this outside of nova? >> >> There were a few other interesting cases that popped up, but I figured >> we could start here. I can start another thread if needed and we can >> keep this specific to discussing limits + AZs. > Keystone should have always been the thing that stores region and > availability zone information. > > When I wrote the regions functionality for Keystone's catalog [1] I > deliberately added the concept that a region can have zero or more > sub-regions [2] to it. A region in Keystone wasn't (and AFAIK to this > day isn't) specific to a geographic location. There's nothing preventing > anyone from adding sub-regions that represent a nova availability zone > [3] to Keystone. > > And since there's nothing preventing the existing Keystone limits API > from associating a set of limits with a specific region [4] (yes, even a > sub-region that represents an availability zone) I don't see any reason > why the existing structures in Keystone could not be used to fulfill > this functionality from the Keystone side. > > The problem is *always* going to be on the Nova side (and any project > that made the unfortunate decision to copy nova's availability zone > "implementation" [5]... hi Cinder! [6]). The way that the availability > zone concept has been hacked into Nova means it's just going to be a > hack on top of a hack to get per-AZ quotas working in Nova. I know this > because Oath deploys this hack on top of a hack in order to divvy up > resources per power domain and physical network (those two things and > the site/DC essentially comprise what our availability zones are > internally). > > Once again, not addressing the technical debt of years past -- which in > this case is the lack of solid modeling of an availability zone concept > in the Nova subsystems -- is hindering the forward progress of the > project, which is sad. > > The long-term solution is to have Nova scrap it's availability zone code > that relies on host aggregate metadata to work, use Keystone's /regions > endpoint (and the hierarchy possible therein) as the single source of > truth about availability zones, move the association of availability > zone out of the Service model and onto the ComputeNode model, and have a > cache of real AvailabilityZone data models stored in the Nova API > top-level service. > > I fear that without truly tackling this underlying problem, we can make > lots of progress on the Keystone side but things will slow to a crawl > with people trying to figure out what the heck is going on in Nova with > availability zones and how they could be tied in to quota handling. > > Sorry to be a pessimist^realist, > -jay > > [1] > https://github.com/openstack/keystone/commit/7c847578c8ed6a4921a24acb8a60f9264dd72aa1 > > [2] https://developer.openstack.org/api-ref/identity/v3/index.html#regions > > [3] As I've mentioned numerous times before, there's nothing > "availability" about a nova availability zone. There's no guarantees > about failure domains leaking across multiple nova availability zones. > Nova's availability zones are an anachronism from when a nova endpoint > serviced a single isolated set of compute resources. > > [4] > https://developer.openstack.org/api-ref/identity/v3/index.html?expanded=create-limits-detail#create-limits > > [5] Behold, the availability zone implementation in Nova: > https://github.com/openstack/nova/blob/ea26392239e67b9504801ee9a478e066ffa2951f/nova/availability_zones.py > > You'll notice there's no actual data model for an AvailabilityZone > anywhere in either the nova_api or nova_cell databases: > > https://github.com/openstack/nova/blob/ea26392239e67b9504801ee9a478e066ffa2951f/nova/db/sqlalchemy/api_models.py > > https://github.com/openstack/nova/blob/ea26392239e67b9504801ee9a478e066ffa2951f/nova/db/sqlalchemy/models.py > > Which puts "availability zone" in rare company inside Nova as one of the > only data concepts that has no actual data model behind it. It shares > this distinction with one other data concept... yep, you guessed it... > the "region". > > [6] Sorry, Cinder, you inherited the lack of a real data model for > availability zones from Nova: > > https://github.com/openstack/cinder/blob/b8167a5c3e5952cc52ff8844804b7a5ab36459c8/cinder/volume/api.py#L115-L153 > > From jim at jimrollenhagen.com Tue Nov 20 15:19:03 2018 From: jim at jimrollenhagen.com (Jim Rollenhagen) Date: Tue, 20 Nov 2018 10:19:03 -0500 Subject: [openstack-dev] [nova] Can we deprecate the server backup API please? In-Reply-To: References: <7778dd25-53f8-ca5c-55c5-0c0e6db29be4@gmail.com> Message-ID: On Tue, Nov 20, 2018 at 5:35 AM melanie witt wrote: > On Mon, 19 Nov 2018 08:36:40 -0500, Jay Pipes wrote: > > On 11/19/2018 08:15 AM, Matt Riedemann wrote: > >> On 11/18/2018 6:51 AM, Alex Xu wrote: > >>> Sounds make sense to me, and then we needn't fix this strange > >>> behaviour also https://review.openstack.org/#/c/409644/ > >> > >> The same discussion was had in the spec for that change: > >> > >> https://review.openstack.org/#/c/511825/ > >> > >> Ultimately it amounted to a big "meh, let's just not fix the bug but > >> also no one really cares about deprecating the API either". > > > > So we'll let the apathy of the past dictate the actions of the future. > > FWIW, my point of view on deprecating the API was/is, if people are > using it to accomplish some task, why deprecate it if it's not hurting > anything else? That is, I didn't want the aforementioned spec to amount > to something like, someone proposes to fix a strange behavior they > observed using the API and our answer is to deprecate the entire API. > > If it's clear that no one is using or benefiting from the API, then I am > in support of deprecating it. But I haven't felt certain about whether > that's the case so far. > > >> The only thing deprecating the API would do is signal that it probably > >> shouldn't be used. We would still support it on older microversions. If > >> all anyone cares about is signalling not to use the API then deprecation > >> is probably fine, but I personally don't feel too strongly about it > >> either way. > > > > Deprecating these kinds of APIs would, as I mentioned in my original > > post, signal that the Nova team is actually serious about cleaning up > > the cruft and getting rid of the debt from years past. > > > > And also that it is serious about Nova not being a dumping ground for > > orchestration and out-of-scope APIs not related to a Compute API. > > That's fair enough, and if we can get a quick confirmation from > operators we know (CERN, NeCTAR, Oath, Vexxhost, OVH, etc) that they > don't use the API, I agree we should go ahead and deprecate it for the > reasons you mention. > Oath doesn't have any internal documentation or regression testing around the backup API - I can't guarantee it isn't used, but I think we'd be fine with it going away. // jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaypipes at gmail.com Tue Nov 20 15:41:18 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Tue, 20 Nov 2018 10:41:18 -0500 Subject: [keystone][nova] Availability zones and unified limits In-Reply-To: <3f0dc188-a6b3-7d0a-b22d-dedbb797f456@binero.se> References: <8f032c3c-73d1-6690-2465-bf11864d4316@gmail.com> <3f0dc188-a6b3-7d0a-b22d-dedbb797f456@binero.se> Message-ID: <1aab883e-de3f-f259-f199-34a40203c3ba@gmail.com> On 11/20/2018 10:11 AM, Tobias Urdin wrote: > I partially agree with your statements. > > I'm currently rolling the ball on availability zones in our deployments > and it's a real pain and I think if there was an > easier concept for a source of truth for AZs (and aggregates as well) > there would be less confusion and a much better > forward for inter-project support for such resources. Keep in mind that host aggregates are not something an end-user is aware of -- only operators can see information about host aggregates. This is not the same with availability zones, which the end user is aware of. > My opinion though; quota's really make sense to store in Keystone since > it's the source of truth for users and projects however > I would say that AZs themselves is not on such a high level and isn't > the same as Keystone knowing about the regions, it's region specific. What my point was is that Keystone's catalog can (and should) serve as the place to put regional and sub-region information. There is nothing in the Keystone concept of a region that denotes it as a geographic location nor anything in the concept of a region that prohibits a region from representing a smaller grouping of related compute resources -- a.k.a. a Nova availability zone. And if Keystone was used as the centralized catalog service that it was designed for, it just naturally makes sense to use the region and sub-region concept in Keystone's existing APIs to further partition quota limits for a project based on those regions. And there's nothing preventing anyone from creating a region in Keystone that represents a nova availability zone. > I don't think Keystone should have a view on such a detailed level > inside a region, I do agree that there is a void to be filled with > something > that gives the source of truth on AZs, host aggregates etc though. But > moving that outside of a region defeats some purpose on the whole idea > to isolate it in the first place. I haven't proposed "moving that outside of a region". Not sure where that's coming from. Could you elaborate? Best, -jay > Best regards > > On 11/20/2018 03:10 PM, Jay Pipes wrote: >> On 11/20/2018 07:33 AM, Lance Bragstad wrote: >>> Unified limits cropped up in a few discussions last week. After >>> describing the current implementation of limits, namely the attributes >>> that make up a limit, someone asked if availability zones were on the >>> roadmap. >>> >>> Ideally, it sounded like they had multiple AZs in a single region, and >>> they wanted to be able to limit usage within the AZ. With the current >>> implementation, regions would be the smallest unit of a deployment they >>> could limit (e.g., limit project Foo to only using 64 compute cores >>> within RegionOne). Instead, the idea would be to limit the number of >>> resources for that project on an AZ within a region. >>> >>> What do people think about adding availability zones to limits? Should >>> it be an official attribute in keystone? What other services would need >>> this outside of nova? >>> >>> There were a few other interesting cases that popped up, but I figured >>> we could start here. I can start another thread if needed and we can >>> keep this specific to discussing limits + AZs. >> Keystone should have always been the thing that stores region and >> availability zone information. >> >> When I wrote the regions functionality for Keystone's catalog [1] I >> deliberately added the concept that a region can have zero or more >> sub-regions [2] to it. A region in Keystone wasn't (and AFAIK to this >> day isn't) specific to a geographic location. There's nothing preventing >> anyone from adding sub-regions that represent a nova availability zone >> [3] to Keystone. >> >> And since there's nothing preventing the existing Keystone limits API >> from associating a set of limits with a specific region [4] (yes, even a >> sub-region that represents an availability zone) I don't see any reason >> why the existing structures in Keystone could not be used to fulfill >> this functionality from the Keystone side. >> >> The problem is *always* going to be on the Nova side (and any project >> that made the unfortunate decision to copy nova's availability zone >> "implementation" [5]... hi Cinder! [6]). The way that the availability >> zone concept has been hacked into Nova means it's just going to be a >> hack on top of a hack to get per-AZ quotas working in Nova. I know this >> because Oath deploys this hack on top of a hack in order to divvy up >> resources per power domain and physical network (those two things and >> the site/DC essentially comprise what our availability zones are >> internally). >> >> Once again, not addressing the technical debt of years past -- which in >> this case is the lack of solid modeling of an availability zone concept >> in the Nova subsystems -- is hindering the forward progress of the >> project, which is sad. >> >> The long-term solution is to have Nova scrap it's availability zone code >> that relies on host aggregate metadata to work, use Keystone's /regions >> endpoint (and the hierarchy possible therein) as the single source of >> truth about availability zones, move the association of availability >> zone out of the Service model and onto the ComputeNode model, and have a >> cache of real AvailabilityZone data models stored in the Nova API >> top-level service. >> >> I fear that without truly tackling this underlying problem, we can make >> lots of progress on the Keystone side but things will slow to a crawl >> with people trying to figure out what the heck is going on in Nova with >> availability zones and how they could be tied in to quota handling. >> >> Sorry to be a pessimist^realist, >> -jay >> >> [1] >> https://github.com/openstack/keystone/commit/7c847578c8ed6a4921a24acb8a60f9264dd72aa1 >> >> >> [2] >> https://developer.openstack.org/api-ref/identity/v3/index.html#regions >> >> [3] As I've mentioned numerous times before, there's nothing >> "availability" about a nova availability zone. There's no guarantees >> about failure domains leaking across multiple nova availability zones. >> Nova's availability zones are an anachronism from when a nova endpoint >> serviced a single isolated set of compute resources. >> >> [4] >> https://developer.openstack.org/api-ref/identity/v3/index.html?expanded=create-limits-detail#create-limits >> >> >> [5] Behold, the availability zone implementation in Nova: >> https://github.com/openstack/nova/blob/ea26392239e67b9504801ee9a478e066ffa2951f/nova/availability_zones.py >> >> >> You'll notice there's no actual data model for an AvailabilityZone >> anywhere in either the nova_api or nova_cell databases: >> >> https://github.com/openstack/nova/blob/ea26392239e67b9504801ee9a478e066ffa2951f/nova/db/sqlalchemy/api_models.py >> >> >> https://github.com/openstack/nova/blob/ea26392239e67b9504801ee9a478e066ffa2951f/nova/db/sqlalchemy/models.py >> >> >> Which puts "availability zone" in rare company inside Nova as one of the >> only data concepts that has no actual data model behind it. It shares >> this distinction with one other data concept... yep, you guessed it... >> the "region". >> >> [6] Sorry, Cinder, you inherited the lack of a real data model for >> availability zones from Nova: >> >> https://github.com/openstack/cinder/blob/b8167a5c3e5952cc52ff8844804b7a5ab36459c8/cinder/volume/api.py#L115-L153 >> >> >> > > From jimmy at openstack.org Tue Nov 20 17:13:40 2018 From: jimmy at openstack.org (Jimmy McArthur) Date: Tue, 20 Nov 2018 11:13:40 -0600 Subject: OpenStack Summit Berlin Presentation Videos & Slides Message-ID: <5BF440C4.4040801@openstack.org> Thank you to everyone for a great OpenStack Summit last week in Berlin! As you know, there were hundreds of breakout sessions to catch last week. Videos from the keynote sessions are currently available here [1], and our team is working to get the other breakout session videos loaded as quickly as possible. We're currently expecting all videos to be posted by mid-December, and if we get them up sooner, I'll update this thread. In the meantime, you can watch the keynotes videos [2] and watch this page [3] for updates. Please also note that we sent out a link to all presenters to upload their slides. As they are uploaded, they can be found on the details page for each presentation on the Berlin Summit Schedule [3] (along with videos, as they are processed). Cheers, Jimmy [1] https://www.openstack.org/videos/summits/berlin-2018 [2] https://www.openstack.org/videos/ [3] https://www.openstack.org/summit/berlin-2018/summit-schedule/ From duc.openstack at gmail.com Tue Nov 20 17:25:14 2018 From: duc.openstack at gmail.com (Duc Truong) Date: Tue, 20 Nov 2018 09:25:14 -0800 Subject: [openstack-dev] =?utf-8?q?=5BSenlin=5D_Does_Senlin_support_Promet?= =?utf-8?b?aGV1c++8nw==?= In-Reply-To: <201811201022041324405@chinacloud.com.cn> References: <201811201022041324405@chinacloud.com.cn> Message-ID: Senlin integrates with Aodh using webhooks. As shown in [1], you create a receiver of type webhook and then create a Aodh alarm to call this webhook [2] on the desired condition. Prometheus AlertManager supports notifications to webhooks [3]. While I have not tried this myself, I believe that it should be as simple as setting up Prometheus AlertManager to notify the webhook created in Senlin (see [1]). Regards, Duc (dtruong) [1] https://docs.openstack.org/senlin/latest/scenarios/autoscaling_ceilometer.html#step-2-create-receivers [2] https://docs.openstack.org/senlin/latest/scenarios/autoscaling_ceilometer.html#step-3-creating-aodh-alarms [3] https://prometheus.io/docs/alerting/configuration/#webhook_config On Mon, Nov 19, 2018 at 6:33 PM xuchao at chinacloud.com.cn wrote: > > Hi， > > Senlin, Ceilometer/Aodh is currently integrated, does it support Prometheus ？ > > > thanks > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From mrhillsman at gmail.com Tue Nov 20 17:27:29 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Tue, 20 Nov 2018 11:27:29 -0600 Subject: OpenStack Summit Berlin Presentation Videos & Slides In-Reply-To: <5BF440C4.4040801@openstack.org> References: <5BF440C4.4040801@openstack.org> Message-ID: Thanks for the update Jimmy! On Tue, Nov 20, 2018 at 11:15 AM Jimmy McArthur wrote: > Thank you to everyone for a great OpenStack Summit last week in Berlin! > As you know, there were hundreds of breakout sessions to catch last > week. Videos from the keynote sessions are currently available here [1], > and our team is working to get the other breakout session videos loaded > as quickly as possible. We're currently expecting all videos to be > posted by mid-December, and if we get them up sooner, I'll update this > thread. > > In the meantime, you can watch the keynotes videos [2] and watch this > page [3] for updates. Please also note that we sent out a link to all > presenters to upload their slides. As they are uploaded, they can be > found on the details page for each presentation on the Berlin Summit > Schedule [3] (along with videos, as they are processed). > > Cheers, > Jimmy > > > [1] https://www.openstack.org/videos/summits/berlin-2018 > [2] https://www.openstack.org/videos/ > [3] https://www.openstack.org/summit/berlin-2018/summit-schedule/ > > -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Tue Nov 20 18:25:06 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 20 Nov 2018 18:25:06 +0000 Subject: [tc] merging this list into openstack-discuss In-Reply-To: References: Message-ID: <20181120182506.jaly6z6vzgaaisqp@yuggoth.org> On 2018-11-20 08:18:34 -0500 (-0500), Doug Hellmann wrote: > As discussed previously in [1] and [2], this list is being merged into > the new openstack-discuss mailing list. Messages that previously would > have gone to this list should be sent to the new list using the subject > tag "[tc]" to attract Technical Committee members' attention. > > [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html > [2] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134924.html Per Doug's post to the (now former) openstack-tc ML, I have proceeded with its retirement. The archives will be retained indefinitely, but the list itself can no longer receive new messages. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From zbitter at redhat.com Tue Nov 20 20:19:26 2018 From: zbitter at redhat.com (Zane Bitter) Date: Tue, 20 Nov 2018 15:19:26 -0500 Subject: [openstack-dev] [omni] Has the Platform9's hybrid multicloud project been abandoned? In-Reply-To: References: Message-ID: On 20/11/18 3:33 AM, Steven Hardy wrote: > On Tue, Nov 20, 2018 at 6:13 AM Blake Covarrubias wrote: >> >> Hi Andrea, >> >> Omni has not been abandoned by Platform9. We're still developing Omni internally, and are working to open source additional code as well as improve docs so that others may more easily test & contribute. > > It sounds like you're approaching this using an internal design > process, so you may like to check: > > https://governance.openstack.org/tc/reference/opens.html To be clear, it's not an official project so they're not _obliged_ to follow the four opens. As long as the code is technically Open Source then it's up to them whether they want to succeed or fail at building a community. > The most recent commit was over a year ago, so it's understandably > confusing to have an apparently unmaintained project, hosted under the > openstack github org, which doesn't actually follow our comunity > design/development process? Yes, this is a confusing aspect of getting rid of the sourceforge namespace. Perhaps things will improve with the forthcoming OpenDev branding. >> With that said, I too would be interested in hearing how others are enabling, or looking to enable, hybrid cloud use cases with OpenStack. I'm not aware of any other projects with similar goals as Omni, however its possible I just haven't been looking in the right places. > > Having design discussions in the open, and some way for others in the > community to understand the goals and roadmap of the project is really > the first step in engaging folks for this sort of discussion IME. +1000 cheers, Zane. From klindgren at godaddy.com Tue Nov 20 22:06:02 2018 From: klindgren at godaddy.com (Kris G. Lindgren) Date: Tue, 20 Nov 2018 22:06:02 +0000 Subject: [neutron] Allowing multiple segments from a routed network to the same host Message-ID: Hello all, We have a use case where we need to allow multiple segments from the same routed network to a host. We have a spine-leaf L3 topology. Where the L2 domain exists only at the leaf level. In our use case we need to have multiple L2 vlans off the same switches pair mapped to all the servers on that switch. This is mainly done to split the L2 broadcast domains for that switch pair. Currently on our older clouds with non-routed networks we might have between 3 and 7 vlans each containing a /22 of ip address spacing, mapped to all the hosts on that switch. Where each of those vlans/subnets belong to the same L3 network segment, but are just used to keep the broadcast domains small on the switches. We are currently trying to implement the multi-segment to same host approach using ml2 + linuxbridge + vlan . We are running into a number of problems that we are working through, however before we go to much further I wanted to reach out and see if we are possibly just doing something wrong? Setup: 1.) Create a routed network with 2 segments, each segment is created with network_type: vlan with physical_network: fixed-net, using different vlans for the segments IE vlan 401 and vlan 402. 2.) Add one subnet per segment. 3.) Configure linuxbirdge agent - ml2.conf : [ml2] type_drivers = vlan tenant_network_types = vlan mechanism_drivers = linuxbridge extension_drivers = port_security [ml2_type_vlan] network_vlan_ranges = fixed-net:1:4095 [ml2_type_flat] flat_networks = physnet-mah [securitygroup] firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver [linux_bridge] #physical_interface_mappings = fixed-net:br0 bridge_mappings = fixed-net:br0 4.) Attempt to boot a vm Problems: 1.) The first issue that you hit will be the arbitrary more than 1 segment per host check that was added. If I remove: https://github.com/openstack/neutron/blob/master/neutron/objects/subnet.py#L319-L328 The vm will boot with an ip from the first segment/subnet and everything is bound correctly. 2.) If I create a port on the second segment and boot the vm using that port. The vm will boot successfully using that port, however the HV br0.402 is not mapped into the bridge. The logs indicate that the port was bound using the first segment vlan 401. This is because https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mech_agent.py#L106-L110 receives 2 segments for network object, both segments are bindable to the host, so the first segment that is returned is vlan 401 segment, and neutron says its bindable and uses that. The fix that I have working here is 2 fold. First, since the port has a fixed_ip’s dict in it with a subnet_id in the port object, and the subnet contains the segment_id with which the ip of the port is supposed to be associated with. I first modify: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L525 to add the segment_id into the fixed_ip dict, if the subnet_id has one: ) for ip in port['fixed_ips']: if 'subnet_id' in ip: subnet = self.get_subnet(orig_context._plugin_context, ip['subnet_id']) ip['segment_id'] = subnet['segment_id'] self._update_port_dict_binding(port, new_binding) Then, In the mech_agent I check if any of the fixed_ips has a segment_id and if it matches one of the segments on the network object, bind using that. if agent['alive']: ips = context.current['fixed_ips'] for ip in ips: if 'segment_id' in ip: for segment in context.segments_to_bind: if ip['segment_id'] == segment['id']: if self.try_to_bind_segment_for_agent(context, segment, agent): LOG.debug("Bound using segment: %s", segment) return for segment in context.segments_to_bind: This causes the correct segment_id to get sent to the agent and the agent creates br0.402 and assigns it to the bridge for the network. However, the agent assigns both br0.401 and br0.402 to the same linux bridge: -bash-4.2# brctl show brq3188bc9c-49 8000.9e8444c8e353 no br0.401 br0.402 tap1789c805-1c tap770e7357-be My guess is in order to correctly handle this neutron needs to create the brq interface based upon the segment vs's the network. I haven't yet started working on this particular issue. However, at this point I wanted to reach out to you guys to: 1.) Explain our use case. 2.) Get feedback on the path taken so far, as to be honest - while it works... its seems hacky. What we are trying to do is be able to use the vlan driver with segments and have the linuxbridge agents create the br0. interfaces for us dynamically based upon the vlan id that we create the segment with. This will allow us to be able to have multiple of those segments (from the same routed network) per switch mapped into a single host. We are trying to avoid, outside of neutron, creating all the vlan interfaces/bridges, then just giving neutron the mappings in physical_interface_mappings or bridge_mappings. My understanding was that if these were normal provider networks using the vlan driver, I can have both networks map to the same interface on different vlans, by using the same physical_network name, and neutron will do the correct thing for me. 3.). Determine the correct process to follow to start working on this upstream. Does this need a spec? a RFE? Regards, Kris Lindgren From raniaadouni at gmail.com Tue Nov 20 22:01:58 2018 From: raniaadouni at gmail.com (Rania Adouni) Date: Tue, 20 Nov 2018 23:01:58 +0100 Subject: [openstack-dev] [zun] Failed to create Container Message-ID: Hi , I am starting to use zun on openstack pike , and when I try to lunch container with cirros image , I get this reason : Docker internal error: 500 Server Error: Internal Server Error ("legacy plugin: Post http://192.168.1.10:23750/Plugin.Activate: dial tcp 192.168.1.10:23750: connect: connection refused"). you can find here the log on my compute node :https://pastebin.com/nZTiTZiV. some help with this will be great . Best Regards, Rania Adouni -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From mriedemos at gmail.com Tue Nov 20 22:07:14 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Tue, 20 Nov 2018 16:07:14 -0600 Subject: [openstack-dev] [nova] about filter the flavor In-Reply-To: References: Message-ID: On 11/19/2018 9:32 PM, Rambo wrote: >       I have an idea.Now we can't filter the special flavor according > to the property.Can we achieve it?If we achieved this,we can filter the > flavor according the property's key and value to filter the flavor. What > do you think of the idea?Can you tell me more about this ?Thank you very > much. To be clear, you want to filter flavors by extra spec key and/or value? So something like: GET /flavors?key=hw%3Acpu_policy would return all flavors with an extra spec with key "hw:cpu_policy". And: GET /flavors?key=hw%3Acpu_policy&value=dedicated would return all flavors with extra spec "hw:cpu_policy" with value "dedicated". The query parameter semantics are probably what gets messiest about this. Because I could see wanting to couple the key and value together, but I'm not sure how you do that, because I don't think you can do this: GET /flavors?spec=hw%3Acpu_policy=dedicated Maybe you'd do: GET /flavors?hw%3Acpu_policy=dedicated The problem with that is we wouldn't be able to perform any kind of request schema validation of it, especially since flavor extra specs are not standardized. -- Thanks, Matt __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From mriedemos at gmail.com Tue Nov 20 22:07:14 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Tue, 20 Nov 2018 16:07:14 -0600 Subject: [Openstack-operators] [openstack-dev] [nova] about filter the flavor In-Reply-To: References: Message-ID: On 11/19/2018 9:32 PM, Rambo wrote: >       I have an idea.Now we can't filter the special flavor according > to the property.Can we achieve it?If we achieved this,we can filter the > flavor according the property's key and value to filter the flavor. What > do you think of the idea?Can you tell me more about this ?Thank you very > much. To be clear, you want to filter flavors by extra spec key and/or value? So something like: GET /flavors?key=hw%3Acpu_policy would return all flavors with an extra spec with key "hw:cpu_policy". And: GET /flavors?key=hw%3Acpu_policy&value=dedicated would return all flavors with extra spec "hw:cpu_policy" with value "dedicated". The query parameter semantics are probably what gets messiest about this. Because I could see wanting to couple the key and value together, but I'm not sure how you do that, because I don't think you can do this: GET /flavors?spec=hw%3Acpu_policy=dedicated Maybe you'd do: GET /flavors?hw%3Acpu_policy=dedicated The problem with that is we wouldn't be able to perform any kind of request schema validation of it, especially since flavor extra specs are not standardized. -- Thanks, Matt _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From sorrison at gmail.com Tue Nov 20 22:52:02 2018 From: sorrison at gmail.com (Sam Morrison) Date: Wed, 21 Nov 2018 09:52:02 +1100 Subject: [Openstack] how to sync quota usage our of sync in Rocky release In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017BAEB6FB@MXDB2.ad.garvan.unsw.edu.au> References: <9D8A2486E35F0941A60430473E29F15B017BAEB6FB@MXDB2.ad.garvan.unsw.edu.au> Message-ID: <1964C018-A866-4E05-BC35-4792B4F7B7E1@gmail.com> Starting I think in Pike or Queens nova no longer caches quota usages and calculates it on the fly so there is now no need to the command as quotas can’t get out of sync anymore. Cheers, Sam > On 20 Nov 2018, at 4:49 pm, Manuel Sopena Ballesteros wrote: > > Dear Openstack community, > > I often have nova complaining that I have exceeded my quota, these normally happens when I node deployment fails and the resources allocated hasn’t been released. Before Rocky I used to run the command below to resync, however it looks like it has been removed from Rocky. > > [root at TEST-openstack-controller ~]# docker exec -it -u root nova_scheduler nova-manage project quota_usage_refresh --project abc29399b91d423088549d7446766573 --user 02132c31dafa4d1d939bd52e0420b975 > usage: nova-manage [-h] [--config-dir DIR] [--config-file PATH] [--debug] > [--log-config-append PATH] [--log-date-format DATE_FORMAT] > [--log-dir LOG_DIR] [--log-file PATH] [--nodebug] > [--nopost-mortem] [--nouse-journal] [--nouse-json] > [--nouse-syslog] [--nowatch-log-file] [--post-mortem] > [--syslog-log-facility SYSLOG_LOG_FACILITY] [--use-journal] > [--use-json] [--use-syslog] [--version] [--watch-log-file] > [--remote_debug-host REMOTE_DEBUG_HOST] > [--remote_debug-port REMOTE_DEBUG_PORT] > > {version,bash-completion,placement,network,cell_v2,db,cell,floating,api_db} > ... > nova-manage: error: argument category: invalid choice: 'project' (choose from 'version', 'bash-completion', 'placement', 'network', 'cell_v2', 'db', 'cell', 'floating', 'api_db') > > Any idea how can I refresh the quota usage in Rocky? > > Thank you very much > > Manuel Sopena Ballesteros | Big data Engineer > Garvan Institute of Medical Research > The Kinghorn Cancer Centre, 370 Victoria Street, Darlinghurst, NSW 2010 > T: + 61 (0)2 9355 5760 | F: +61 (0)2 9295 8507 | E: manuel.sb at garvan.org.au > > NOTICE > Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed. > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From sorrison at gmail.com Tue Nov 20 22:58:25 2018 From: sorrison at gmail.com (Sam Morrison) Date: Wed, 21 Nov 2018 09:58:25 +1100 Subject: [keystone][nova] Availability zones and unified limits In-Reply-To: References: Message-ID: <654D9624-1B1E-4D99-8BED-0E0501CF72C6@gmail.com> Nectar would absolutely love for this to get off the ground. We have just the one region with many AZ’s and to be able to quota on an AZ would be great. I can help in terms of use cases but we are pretty light on the developer front at the moment. We can throw money at someone else for this though I think. Cheers, Sam > On 20 Nov 2018, at 11:33 pm, Lance Bragstad wrote: > > Unified limits cropped up in a few discussions last week. After describing the current implementation of limits, namely the attributes that make up a limit, someone asked if availability zones were on the roadmap. > > Ideally, it sounded like they had multiple AZs in a single region, and they wanted to be able to limit usage within the AZ. With the current implementation, regions would be the smallest unit of a deployment they could limit (e.g., limit project Foo to only using 64 compute cores within RegionOne). Instead, the idea would be to limit the number of resources for that project on an AZ within a region. > > What do people think about adding availability zones to limits? Should it be an official attribute in keystone? What other services would need this outside of nova? > > There were a few other interesting cases that popped up, but I figured we could start here. I can start another thread if needed and we can keep this specific to discussing limits + AZs. > > Thoughts? > > From jburckhardt at pdvwireless.com Wed Nov 21 00:44:09 2018 From: jburckhardt at pdvwireless.com (Jacob Burckhardt) Date: Wed, 21 Nov 2018 00:44:09 +0000 Subject: [openstack-dev] [zun] Failed to create Container In-Reply-To: References: Message-ID: Your error message says it cannot connect to port 23750. That's the kuryr-libnetwork default listen port. On 192.168.1.10, run: lsof -iTCP -sTCP:LISTEN -P On my compute node, it outputs: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME … kuryr-ser 1976 root 6u IPv4 30896 0t0 TCP localhost:23750 (LISTEN) So, you can see that kuryr is listening on 23750. If lsof does not list a process listening on 23750, then check if kuryr is up by running: systemctl status kuryr-libnetwork You can also try restarting it by running: systemctl restart kuryr-libnetwork I installed that service by following: https://docs.openstack.org/kuryr-libnetwork/queens/install/compute-install-ubuntu.html That is the queens install guide which might help you since zun has no install guide in pike. If you see it listening, you can try this command: telnet 192.168.1.10 23750 If it fails to connect, then try: telnet localhost 23750 If it works with localhost but not 192.168.1.10, then I think that means you need to tell docker to connect to localhost instead of 192.168.1.10. Can you get the commands at the following web page to succeed? https://docs.openstack.org/kuryr-libnetwork/queens/install/verify.html Jacob Burckhardt Senior Software Engineer [pdvWireless] From: Rania Adouni Sent: Tuesday, November 20, 2018 2:02 PM To: openstack-dev at lists.openstack.org Subject: [openstack-dev] [zun] Failed to create Container [https://mailtrack.io/trace/mail/17bd40a2e38fcf449f8e80fdc1e7d9474dfbed19.png?u=2497697] Hi , I am starting to use zun on openstack pike , and when I try to lunch container with cirros image , I get this reason : Docker internal error: 500 Server Error: Internal Server Error ("legacy plugin: Post http://192.168.1.10:23750/Plugin.Activate: dial tcp 192.168.1.10:23750: connect: connection refused"). you can find here the log on my compute node :https://pastebin.com/nZTiTZiV. some help with this will be great . Best Regards, Rania Adouni -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 2499 bytes Desc: image003.jpg URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From jburckhardt at pdvwireless.com Wed Nov 21 01:20:19 2018 From: jburckhardt at pdvwireless.com (Jacob Burckhardt) Date: Wed, 21 Nov 2018 01:20:19 +0000 Subject: [openstack-dev] [zun] Failed to create Container In-Reply-To: References: Message-ID: The important part of the error message seems to be: NoSuchOptError: no such option driver in group [binding] In my /etc/kuryr/kuryr.conf file, all the text is commented out in the [binding] section. Some of the commented options have "driver" in the name. Since they are commented, I guess they have defaults. I suggest commenting any option that mentions "driver" and then restart kuryr-libnetwork. -Jacob Burckhardt From: Rania Adouni Sent: Tuesday, November 20, 2018 4:58 PM To: openstack-dev at lists.openstack.org Subject: Re: [openstack-dev] [zun] Failed to create Container hi ,  Thanks for your reply and yes the problem that kuryr-libnetwork  is failed to start with the error : ● kuryr-libnetwork.service - Kuryr-libnetwork - Docker network plugin for Neutron    Loaded: loaded (/etc/systemd/system/kuryr-libnetwork.service; enabled; vendor preset: enabled)    Active: failed (Result: exit-code) since mer. 2018-11-21 01:48:48 CET; 287ms ago   Process: 13974 ExecStart=/usr/local/bin/kuryr-server --config-file /etc/kuryr/kuryr.conf (code=exited, status=1/FAILURE)  Main PID: 13974 (code=exited, status=1/FAILURE) nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 13974 ERROR kuryr     value = self._do_get(name, group, namespace) nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 13974 ERROR kuryr   File "/usr/lib/python2.7/dist-packages/oslo_config/cfg.py", line 2942, in _ nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 13974 ERROR kuryr     info = self._get_opt_info(name, group) nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 13974 ERROR kuryr   File "/usr/lib/python2.7/dist-packages/oslo_config/cfg.py", line 3099, in _ nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 13974 ERROR kuryr     raise NoSuchOptError(opt_name, group) nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 13974 ERROR kuryr NoSuchOptError: no such option driver in group [binding] nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 13974 ERROR kuryr nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Main process exited, code=exited, status=1/FAILURE nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Unit entered failed state. nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Failed with result 'exit-code'. and also the command lsof -iTCP -sTCP:LISTEN -P doesn't show the kuryr service : COMMAND    PID         USER   FD   TYPE DEVICE SIZE/OFF NODE NAME dockerd   1144         root    5u  IPv4  20120      0t0  TCP compute:2375 (LISTEN) sshd      1288         root    3u  IPv4  19532      0t0  TCP *:22 (LISTEN) sshd      1288         root    4u  IPv6  19534      0t0  TCP *:22 (LISTEN) dnsmasq   1961       nobody    6u  IPv4  23450      0t0  TCP http://192.168.122.1:53 (LISTEN) sshd      4163       adouni    9u  IPv6  34950      0t0  TCP localhost:6010 (LISTEN) sshd      4163       adouni   10u  IPv4  34951      0t0  TCP localhost:6010 (LISTEN) qemu-syst 4621 libvirt-qemu   18u  IPv4  37121      0t0  TCP *:5900 (LISTEN)   !!! Le mer. 21 nov. 2018 à 01:45, Jacob Burckhardt a écrit : Your error message says it cannot connect to port 23750.  That's the kuryr-libnetwork default listen port.  On 192.168.1.10, run:   lsof -iTCP -sTCP:LISTEN -P   On my compute node, it outputs:   COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME … kuryr-ser 1976        root    6u  IPv4  30896      0t0  TCP localhost:23750 (LISTEN)   So, you can see that kuryr is listening on 23750.  If lsof does not list a process listening on 23750, then check if kuryr is up by running:   systemctl status kuryr-libnetwork   You can also try restarting it by running:   systemctl restart kuryr-libnetwork   I installed that service by following:   https://docs.openstack.org/kuryr-libnetwork/queens/install/compute-install-ubuntu.html   That is the queens install guide which might help you since zun has no install guide in pike.   If you see it listening, you can try this command:   telnet 192.168.1.10 23750   If it fails to connect, then try:   telnet localhost 23750   If it works with localhost but not 192.168.1.10, then I think that means you need to tell docker to connect to localhost instead of 192.168.1.10.   Can you get the commands at the following web page to succeed?   https://docs.openstack.org/kuryr-libnetwork/queens/install/verify.html   Jacob Burckhardt Senior Software Engineer   From: Rania Adouni Sent: Tuesday, November 20, 2018 2:02 PM To: mailto:openstack-dev at lists.openstack.org Subject: [openstack-dev] [zun] Failed to create Container     Hi ,   I am starting to use zun on openstack pike , and when I try to lunch container with cirros image , I get this reason : Docker internal error: 500 Server Error: Internal Server Error ("legacy plugin: Post http://192.168.1.10:23750/Plugin.Activate: dial tcp http://192.168.1.10:23750/: connect: connection refused").  you can find here the log on my compute node :https://pastebin.com/nZTiTZiV. some help with this will be great . Best Regards, Rania Adouni         __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: http://OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From gael.therond at gmail.com Wed Nov 21 08:04:29 2018 From: gael.therond at gmail.com (=?UTF-8?Q?Ga=C3=ABl_THEROND?=) Date: Wed, 21 Nov 2018 09:04:29 +0100 Subject: [OCTAVIA] How to monitor amphora Message-ID: Hi guys, As already discussed I had to test Octavia as our corporate LoadBalancer solution and it was a success. Thank to everyone on this list that assisted me and especially Michael Octavia is fully working and without weird nightmare glitches. Now that I validated the technical part of my project, I need to enter more operationals questions such as what’s the best way to monitor and log amphora? I would like to be able to get a monitoring and logging agent installed on the amphora in order to get proper metrics about what’s going on with the LoadBalancer, is it fully cpu loaded? Is it using all network resources available, are the file descriptors near the initial limits? How much xxx HTTP return code the loadBalancer is facing and send those logs to an ELK or something similar. Do you know if that something that I could achieve by adding more elements to the image at DIB time or are there any other better best-practices that I should be aware of ? As Octavia is creating a namespace for each HAProxy process, I am wandering if it’s even possible. Thanks a lot for your hard work guys. Kind regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From saphi070 at gmail.com Wed Nov 21 08:12:41 2018 From: saphi070 at gmail.com (Sa Pham) Date: Wed, 21 Nov 2018 15:12:41 +0700 Subject: [OCTAVIA] How to monitor amphora In-Reply-To: References: Message-ID: Hi, In Vietnam Openinfra Days 2018, I have a presentation about monitoring and logging for Octavia Amphora. We have to customize octavia source code to do this. I send you my presentation slide: https://drive.google.com/file/d/1dHXExEKrHDg4Cf3D1fBeulLDW_G-txLr/view?usp=sharing Best, On Wed, Nov 21, 2018 at 3:05 PM Gaël THEROND wrote: > Hi guys, > > As already discussed I had to test Octavia as our corporate LoadBalancer > solution and it was a success. > > Thank to everyone on this list that assisted me and especially Michael > Octavia is fully working and without weird nightmare glitches. > > Now that I validated the technical part of my project, I need to enter > more operationals questions such as what’s the best way to monitor and log > amphora? > > I would like to be able to get a monitoring and logging agent installed on > the amphora in order to get proper metrics about what’s going on with the > LoadBalancer, is it fully cpu loaded? Is it using all network resources > available, are the file descriptors near the initial limits? How much xxx > HTTP return code the loadBalancer is facing and send those logs to an ELK > or something similar. > > Do you know if that something that I could achieve by adding more elements > to the image at DIB time or are there any other better best-practices that > I should be aware of ? > > As Octavia is creating a namespace for each HAProxy process, I am > wandering if it’s even possible. > > Thanks a lot for your hard work guys. > > Kind regards, > > -- Sa Pham Dang Cloud RnD Team - VCCloud Phone/Telegram: 0986.849.582 Skype: great_bn -------------- next part -------------- An HTML attachment was scrubbed... URL: From stig.openstack at telfer.org Wed Nov 21 08:14:41 2018 From: stig.openstack at telfer.org (Stig Telfer) Date: Wed, 21 Nov 2018 08:14:41 +0000 Subject: [scientific-sig] IRC Meeting today 1100 UTC - Summit wash-up, Manila+Lustre Message-ID: <3D4CC944-EA42-4F85-BF1F-89C6A3A156E0@telfer.org> Hi All - We have a Scientific SIG IRC meeting today at 1100 UTC in channel #openstack-meeting. Everyone is welcome. This week we’ve got the summit activities to digest, plus similar activities at SC. We’d also like to find out if there’s anyone using Manila to manage Lustre filesystems. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_November_21st_2018 Details on how to join our meetings are here: http://eavesdrop.openstack.org/#Scientific_Working_Group Cheers, Stig From gael.therond at gmail.com Wed Nov 21 08:16:43 2018 From: gael.therond at gmail.com (=?UTF-8?Q?Ga=C3=ABl_THEROND?=) Date: Wed, 21 Nov 2018 09:16:43 +0100 Subject: [OCTAVIA] How to monitor amphora In-Reply-To: References: Message-ID: Hi! Thanks for this material, I’ll have a look at it. As our philosophy at work is to always push upstream all our patchs/features or bug fixes, I won’t modify and keep the source code on our own and if we need further features like that I think we will rather push for a Blueprint with all required commits. Did you already discussed that topic with the Octavia team? Thanks a lot. Le mer. 21 nov. 2018 à 09:12, Sa Pham a écrit : > Hi, > > In Vietnam Openinfra Days 2018, I have a presentation about monitoring and > logging for Octavia Amphora. We have to customize octavia source code to > do this. I send you my presentation slide: > > https://drive.google.com/file/d/1dHXExEKrHDg4Cf3D1fBeulLDW_G-txLr/view?usp=sharing > > Best, > > On Wed, Nov 21, 2018 at 3:05 PM Gaël THEROND > wrote: > >> Hi guys, >> >> As already discussed I had to test Octavia as our corporate LoadBalancer >> solution and it was a success. >> >> Thank to everyone on this list that assisted me and especially Michael >> Octavia is fully working and without weird nightmare glitches. >> >> Now that I validated the technical part of my project, I need to enter >> more operationals questions such as what’s the best way to monitor and log >> amphora? >> >> I would like to be able to get a monitoring and logging agent installed >> on the amphora in order to get proper metrics about what’s going on with >> the LoadBalancer, is it fully cpu loaded? Is it using all network resources >> available, are the file descriptors near the initial limits? How much xxx >> HTTP return code the loadBalancer is facing and send those logs to an ELK >> or something similar. >> >> Do you know if that something that I could achieve by adding more >> elements to the image at DIB time or are there any other better >> best-practices that I should be aware of ? >> >> As Octavia is creating a namespace for each HAProxy process, I am >> wandering if it’s even possible. >> >> Thanks a lot for your hard work guys. >> >> Kind regards, >> >> > > -- > Sa Pham Dang > Cloud RnD Team - VCCloud > Phone/Telegram: 0986.849.582 > Skype: great_bn > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Wed Nov 21 08:38:16 2018 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 21 Nov 2018 09:38:16 +0100 Subject: Let's use [dev] for development discussions Message-ID: Hi openstack-discuss, As part of the ML merge, we introduced a number of subject prefixes to help subscribers filter discussions. The most important ones are to use: [dev] For discussions that are purely development-oriented [ops] For discussions that are purely operations-oriented Of course (as we have realized with the amount of cross-posted topics), most discussions benefit from input from all our contributors, whether they come from an development or an operational background. For those, there is no need to apply [dev] and/or [ops] prefixes, just try to be informative by adding the project name, team name or other information instead. You can ping specific populations by adding: [tc] Discussions of interest for TC members [uc] Discussions of interest for UC members [ptl] Discussions of interest for all PTLs [release] Release team, release liaisons and PTLs You can also specifically use (with care): [all] For discussions that should really be of interest to EVERYONE See (and add!) other common subject prefixes at: https://etherpad.openstack.org/p/common-openstack-ml-topics Thanks for your help in making this common list more navigable. -- Thierry Carrez (ttx) From Tim.Bell at cern.ch Wed Nov 21 08:54:36 2018 From: Tim.Bell at cern.ch (Tim Bell) Date: Wed, 21 Nov 2018 08:54:36 +0000 Subject: [openstack-dev] [nova] Can we deprecate the server backup API please? In-Reply-To: References: <7778dd25-53f8-ca5c-55c5-0c0e6db29be4@gmail.com> Message-ID: <68418172-9B82-40CB-887C-90FA31232C11@cern.ch> I don’t think this is at use at CERN either. We use Mistral’s cron to schedule the backups if needed. Tim From: Jim Rollenhagen Date: Tuesday, 20 November 2018 at 16:19 To: "melwittt at gmail.com" Cc: "openstack-discuss at lists.openstack.org" Subject: Re: [openstack-dev] [nova] Can we deprecate the server backup API please? On Tue, Nov 20, 2018 at 5:35 AM melanie witt > wrote: On Mon, 19 Nov 2018 08:36:40 -0500, Jay Pipes wrote: > On 11/19/2018 08:15 AM, Matt Riedemann wrote: >> On 11/18/2018 6:51 AM, Alex Xu wrote: >>> Sounds make sense to me, and then we needn't fix this strange >>> behaviour also https://review.openstack.org/#/c/409644/ >> >> The same discussion was had in the spec for that change: >> >> https://review.openstack.org/#/c/511825/ >> >> Ultimately it amounted to a big "meh, let's just not fix the bug but >> also no one really cares about deprecating the API either". > > So we'll let the apathy of the past dictate the actions of the future. FWIW, my point of view on deprecating the API was/is, if people are using it to accomplish some task, why deprecate it if it's not hurting anything else? That is, I didn't want the aforementioned spec to amount to something like, someone proposes to fix a strange behavior they observed using the API and our answer is to deprecate the entire API. If it's clear that no one is using or benefiting from the API, then I am in support of deprecating it. But I haven't felt certain about whether that's the case so far. >> The only thing deprecating the API would do is signal that it probably >> shouldn't be used. We would still support it on older microversions. If >> all anyone cares about is signalling not to use the API then deprecation >> is probably fine, but I personally don't feel too strongly about it >> either way. > > Deprecating these kinds of APIs would, as I mentioned in my original > post, signal that the Nova team is actually serious about cleaning up > the cruft and getting rid of the debt from years past. > > And also that it is serious about Nova not being a dumping ground for > orchestration and out-of-scope APIs not related to a Compute API. That's fair enough, and if we can get a quick confirmation from operators we know (CERN, NeCTAR, Oath, Vexxhost, OVH, etc) that they don't use the API, I agree we should go ahead and deprecate it for the reasons you mention. Oath doesn't have any internal documentation or regression testing around the backup API - I can't guarantee it isn't used, but I think we'd be fine with it going away. // jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.urdin at binero.se Wed Nov 21 09:03:52 2018 From: tobias.urdin at binero.se (Tobias Urdin) Date: Wed, 21 Nov 2018 10:03:52 +0100 Subject: [keystone][nova] Availability zones and unified limits In-Reply-To: <1aab883e-de3f-f259-f199-34a40203c3ba@gmail.com> References: <8f032c3c-73d1-6690-2465-bf11864d4316@gmail.com> <3f0dc188-a6b3-7d0a-b22d-dedbb797f456@binero.se> <1aab883e-de3f-f259-f199-34a40203c3ba@gmail.com> Message-ID: <44465876-5c65-177a-a40e-7708563dc30e@binero.se> On 11/20/2018 04:42 PM, Jay Pipes wrote: > On 11/20/2018 10:11 AM, Tobias Urdin wrote: >> I partially agree with your statements. >> >> I'm currently rolling the ball on availability zones in our deployments >> and it's a real pain and I think if there was an >> easier concept for a source of truth for AZs (and aggregates as well) >> there would be less confusion and a much better >> forward for inter-project support for such resources. > Keep in mind that host aggregates are not something an end-user is aware > of -- only operators can see information about host aggregates. This is > not the same with availability zones, which the end user is aware of. My bad, keeping it to availability zones. > >> My opinion though; quota's really make sense to store in Keystone since >> it's the source of truth for users and projects however >> I would say that AZs themselves is not on such a high level and isn't >> the same as Keystone knowing about the regions, it's region specific. > What my point was is that Keystone's catalog can (and should) serve as > the place to put regional and sub-region information. There is nothing > in the Keystone concept of a region that denotes it as a geographic > location nor anything in the concept of a region that prohibits a region > from representing a smaller grouping of related compute resources -- > a.k.a. a Nova availability zone. > > And if Keystone was used as the centralized catalog service that it was > designed for, it just naturally makes sense to use the region and > sub-region concept in Keystone's existing APIs to further partition > quota limits for a project based on those regions. And there's nothing > preventing anyone from creating a region in Keystone that represents a > nova availability zone. I agree that this might be the currently best possible solution, and perhaps even the only viable solution instead of introducing more technical depth with for example an addition of more services, I just want to make sure we are aware of the dependency this would generate on Keystone which is my concern. Would your proposal be that AZs cease to exist in the current form? And instead it be replaced by a common community effort to move all existing projects to use Keystone as source of truth? I really like that concept but not convinced where we should do that. There is a great possibility for improvement here considering that Nova, Cinder and Neutron all provide the availability zone concept in, some cases, somewhat different ways. Since it's separated into the projects themselves and not moved out is causing pains to manage i.e the nova <-> cinder relationship for AZs. > >> I don't think Keystone should have a view on such a detailed level >> inside a region, I do agree that there is a void to be filled with >> something >> that gives the source of truth on AZs, host aggregates etc though. But >> moving that outside of a region defeats some purpose on the whole idea >> to isolate it in the first place. > I haven't proposed "moving that outside of a region". Not sure where > that's coming from. Could you elaborate? My biggest concern is that we are moving out logic that is internal to a region out to a central dependency that keystone is. I've always viewed Keystone (and Horizon deployed alongside it) as the central part of a OpenStack cloud (yes even though we stretch databases between regions and deploy Keystone there, or do federation) which does not interact with regions except for those high-level shared resources that comes with authentication and catalog. After sleeping on it though, I understand your perspective and what I really like is that it's pretty much already there. Not sure that this would still be considered availability zones as we see them today, more of a partitioned region into sub-regions, so we move down a layer further which means you can schedule resources in a sub-region. Does that mean a gradual move away and deprecation of availability zones or is just aliasing the Keystone region concept under another name? I must say this seems like very important work, the cross-project involvement is huge but the win for all projects here sounds substantial and a community goal would probably benefit a lot of users. Best regards Tobias > > Best, > -jay > >> Best regards >> >> On 11/20/2018 03:10 PM, Jay Pipes wrote: >>> On 11/20/2018 07:33 AM, Lance Bragstad wrote: >>>> Unified limits cropped up in a few discussions last week. After >>>> describing the current implementation of limits, namely the attributes >>>> that make up a limit, someone asked if availability zones were on the >>>> roadmap. >>>> >>>> Ideally, it sounded like they had multiple AZs in a single region, and >>>> they wanted to be able to limit usage within the AZ. With the current >>>> implementation, regions would be the smallest unit of a deployment they >>>> could limit (e.g., limit project Foo to only using 64 compute cores >>>> within RegionOne). Instead, the idea would be to limit the number of >>>> resources for that project on an AZ within a region. >>>> >>>> What do people think about adding availability zones to limits? Should >>>> it be an official attribute in keystone? What other services would need >>>> this outside of nova? >>>> >>>> There were a few other interesting cases that popped up, but I figured >>>> we could start here. I can start another thread if needed and we can >>>> keep this specific to discussing limits + AZs. >>> Keystone should have always been the thing that stores region and >>> availability zone information. >>> >>> When I wrote the regions functionality for Keystone's catalog [1] I >>> deliberately added the concept that a region can have zero or more >>> sub-regions [2] to it. A region in Keystone wasn't (and AFAIK to this >>> day isn't) specific to a geographic location. There's nothing preventing >>> anyone from adding sub-regions that represent a nova availability zone >>> [3] to Keystone. >>> >>> And since there's nothing preventing the existing Keystone limits API >>> from associating a set of limits with a specific region [4] (yes, even a >>> sub-region that represents an availability zone) I don't see any reason >>> why the existing structures in Keystone could not be used to fulfill >>> this functionality from the Keystone side. >>> >>> The problem is *always* going to be on the Nova side (and any project >>> that made the unfortunate decision to copy nova's availability zone >>> "implementation" [5]... hi Cinder! [6]). The way that the availability >>> zone concept has been hacked into Nova means it's just going to be a >>> hack on top of a hack to get per-AZ quotas working in Nova. I know this >>> because Oath deploys this hack on top of a hack in order to divvy up >>> resources per power domain and physical network (those two things and >>> the site/DC essentially comprise what our availability zones are >>> internally). >>> >>> Once again, not addressing the technical debt of years past -- which in >>> this case is the lack of solid modeling of an availability zone concept >>> in the Nova subsystems -- is hindering the forward progress of the >>> project, which is sad. >>> >>> The long-term solution is to have Nova scrap it's availability zone code >>> that relies on host aggregate metadata to work, use Keystone's /regions >>> endpoint (and the hierarchy possible therein) as the single source of >>> truth about availability zones, move the association of availability >>> zone out of the Service model and onto the ComputeNode model, and have a >>> cache of real AvailabilityZone data models stored in the Nova API >>> top-level service. >>> >>> I fear that without truly tackling this underlying problem, we can make >>> lots of progress on the Keystone side but things will slow to a crawl >>> with people trying to figure out what the heck is going on in Nova with >>> availability zones and how they could be tied in to quota handling. >>> >>> Sorry to be a pessimist^realist, >>> -jay >>> >>> [1] >>> https://github.com/openstack/keystone/commit/7c847578c8ed6a4921a24acb8a60f9264dd72aa1 >>> >>> >>> [2] >>> https://developer.openstack.org/api-ref/identity/v3/index.html#regions >>> >>> [3] As I've mentioned numerous times before, there's nothing >>> "availability" about a nova availability zone. There's no guarantees >>> about failure domains leaking across multiple nova availability zones. >>> Nova's availability zones are an anachronism from when a nova endpoint >>> serviced a single isolated set of compute resources. >>> >>> [4] >>> https://developer.openstack.org/api-ref/identity/v3/index.html?expanded=create-limits-detail#create-limits >>> >>> >>> [5] Behold, the availability zone implementation in Nova: >>> https://github.com/openstack/nova/blob/ea26392239e67b9504801ee9a478e066ffa2951f/nova/availability_zones.py >>> >>> >>> You'll notice there's no actual data model for an AvailabilityZone >>> anywhere in either the nova_api or nova_cell databases: >>> >>> https://github.com/openstack/nova/blob/ea26392239e67b9504801ee9a478e066ffa2951f/nova/db/sqlalchemy/api_models.py >>> >>> >>> https://github.com/openstack/nova/blob/ea26392239e67b9504801ee9a478e066ffa2951f/nova/db/sqlalchemy/models.py >>> >>> >>> Which puts "availability zone" in rare company inside Nova as one of the >>> only data concepts that has no actual data model behind it. It shares >>> this distinction with one other data concept... yep, you guessed it... >>> the "region". >>> >>> [6] Sorry, Cinder, you inherited the lack of a real data model for >>> availability zones from Nova: >>> >>> https://github.com/openstack/cinder/blob/b8167a5c3e5952cc52ff8844804b7a5ab36459c8/cinder/volume/api.py#L115-L153 >>> >>> >>> >> > From thomas.morin at orange.com Wed Nov 21 09:57:49 2018 From: thomas.morin at orange.com (Thomas Morin) Date: Wed, 21 Nov 2018 10:57:49 +0100 Subject: OpenStack Summit Berlin Presentation Videos & Slides In-Reply-To: <5BF440C4.4040801@openstack.org> References: <5BF440C4.4040801@openstack.org> Message-ID: <9e0517e1-149c-9234-5f25-23439dd352e8@orange.com> Hi Jimmy, On 20/11/2018 18:13, Jimmy McArthur wrote: > As you know, there were hundreds of breakout sessions to catch last > week. Videos from the keynote sessions are currently available here > [1], and our team is working to get the other breakout session videos > loaded as quickly as possible. We're currently expecting all videos to > be posted by mid-December, and if we get them up sooner, I'll update > this thread. During previous summits, it was great to have the video available shortly after the summit (sometimes as shortly as the same day). That allowed to catch up sessions one could not attend, or suggests interesting sessions to colleagues that could not attend. "Strike while the iron is hot", this kind of things :) Perhaps we just got used too much to this form of luxury :) So I don't want to ask for the impossible for the summit team, which did a wonderful job, but I'm curious: is it possible to have an idea why this can't be the case this time ? Thanks, -Thomas From thierry at openstack.org Wed Nov 21 10:04:10 2018 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 21 Nov 2018 11:04:10 +0100 Subject: Let's use [dev] for development discussions In-Reply-To: References: Message-ID: <346dbd59-b15c-727a-ba68-ca7413e69dc9@openstack.org> To be clearer, since I realize now my subject title (ironically) was a bit poor... The goal here is definitely to have common discussions around OpenStack between all contributors. But while most topics benefit from wide input, some are very specific, and applying appropriate subject prefixes will people efficiently filter the discussions they are the most interested about. Upgrading a version of pep8 has little user-visible impact, for example, and would benefit from being tagged [dev]. Cheers, -- Thierry Carrez (ttx) From amotoki at gmail.com Wed Nov 21 10:16:28 2018 From: amotoki at gmail.com (Akihiro Motoki) Date: Wed, 21 Nov 2018 19:16:28 +0900 Subject: Let's use [dev] for development discussions In-Reply-To: References: Message-ID: I believe it is better to mention combined version of tags to clarify the intended usage. Even if a project specific topic, both [dev] and [ops] topics are possible. For nova development, do we use [dev] [nova] or simply [nova]? Some guidance would help subscribers. Thanks, Akihiro 2018年11月21日(水) 17:40 Thierry Carrez : > Hi openstack-discuss, > > As part of the ML merge, we introduced a number of subject prefixes to > help subscribers filter discussions. The most important ones are to use: > > [dev] For discussions that are purely development-oriented > [ops] For discussions that are purely operations-oriented > > Of course (as we have realized with the amount of cross-posted topics), > most discussions benefit from input from all our contributors, whether > they come from an development or an operational background. For those, > there is no need to apply [dev] and/or [ops] prefixes, just try to be > informative by adding the project name, team name or other information > instead. > > You can ping specific populations by adding: > > [tc] Discussions of interest for TC members > [uc] Discussions of interest for UC members > [ptl] Discussions of interest for all PTLs > [release] Release team, release liaisons and PTLs > > You can also specifically use (with care): > > [all] For discussions that should really be of interest to EVERYONE > > See (and add!) other common subject prefixes at: > https://etherpad.openstack.org/p/common-openstack-ml-topics > > Thanks for your help in making this common list more navigable. > > -- > Thierry Carrez (ttx) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Wed Nov 21 10:28:14 2018 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 21 Nov 2018 11:28:14 +0100 Subject: Let's use [dev] for development discussions In-Reply-To: References: Message-ID: Akihiro Motoki wrote: > I believe it is better to mention combined version of tags to clarify > the intended usage. > Even if a project specific topic, both [dev] and [ops] topics are possible. > For nova development, do we use [dev] [nova] or simply [nova]? Personally I would only use [dev] if the topic is *only* of interest to contributors coming from a more developer-oriented angle. Extreme examples: [dev][nova] Enabling py37 unit tests in gate [nova] Can we deprecate the server backup API? > Some guidance would help subscribers. It might be a bit early to emit stronger guidance. I suspect usage will drive the norm... -- Thierry Carrez (ttx) From rico.lin.guanyu at gmail.com Wed Nov 21 10:42:42 2018 From: rico.lin.guanyu at gmail.com (Rico Lin) Date: Wed, 21 Nov 2018 18:42:42 +0800 Subject: [heat] Meeting canceled this week Message-ID: Hi team Since we just have summit last week, let's not over-occupied all member's time. we shall resume meeting next week -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Wed Nov 21 11:21:35 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Wed, 21 Nov 2018 12:21:35 +0100 Subject: [Openstack] [OpenStack][Compute-Neutron] Is it possible to create flat network from different NICs In-Reply-To: References: Message-ID: <9E359876-421D-466C-A5B6-9F9B94331E74@redhat.com> Hi, Yes, that should be possible. You can create 4 bridges on compute node and add all of them to bridge_mappings config option. Then You can create 4 networks with different physical_network for each of them and agent will know which bridge should be used for ports from each network. It is described e.g. in [1]. [1] https://ask.openstack.org/en/question/94206/how-to-understand-the-bridge_mappings/?answer=94230#post-id-94230 > Wiadomość napisana przez Soheil Pourbafrani w dniu 21.11.2018, o godz. 12:08: > > Hi, > > I installed OpenStack on One node (for test) and creating a flat external network I could connect VMs to the provider network (internet). > > In the production environment, we have 4 NIC on each server and each server (compute node) will run 4 instances. My question is, is it possible to create a separate external network based on each NIC (so 4 external networks) and run each instance using one of them? > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack — Slawek Kaplonski Senior software engineer Red Hat _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From mark at stackhpc.com Wed Nov 21 11:39:45 2018 From: mark at stackhpc.com (Mark Goddard) Date: Wed, 21 Nov 2018 11:39:45 +0000 Subject: [kayobe] Forum summary Message-ID: Hi, Thanks to those who attended the kayobe forum session. I'll try to summarise the key points here. The etherpad is here: https://etherpad.openstack.org/p/BER-18-kayobe-feedback-roadmap. - Several people were keen for a Rocky release. We're working on this currently, and aim to make it a small one so that we can move to Stein. - The point was raised that the locally installed environment can be hard to keep in sync, and the installation procedure is too complex. We hope to resolve this for the rocky release via https://storyboard.openstack.org/#!/story/2004252 and https://storyboard.openstack.org/#!/story/2004367. - Documentation is lacking in a few areas. We aim to improve this for rocky: https://storyboard.openstack.org/#!/story/2004360. - Ability to import configuration of an existing deployment from kolla-ansible: https://storyboard.openstack.org/#!/story/2004364 - Document/automate bifrost backup procedure: https://storyboard.openstack.org/#!/story/2004359 A few people also requested that we start a regular IRC meeting. Up to now we've favoured ad-hoc IRC communication, but I tend to agree that the time is right. I'll send out a separate email with a poll. Cheers, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaypipes at gmail.com Wed Nov 21 12:45:34 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Wed, 21 Nov 2018 07:45:34 -0500 Subject: Let's use [dev] for development discussions In-Reply-To: References: Message-ID: On 11/21/2018 05:28 AM, Thierry Carrez wrote: > [nova] Can we deprecate the server backup API? I'd like to point out that my original subject line contained the word "please" in it :P -jay From cdent+os at anticdent.org Wed Nov 21 12:59:44 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Wed, 21 Nov 2018 12:59:44 +0000 (GMT) Subject: [infra] [zuul] [placement] Minimizing size/time of test node Message-ID: I have a work in progress to run a little job in placement that gathers very simple performance numbers on some queries. This is being done as a sort of sanity check. As with many such things it is a bit rough around the edges and I'd like to make it smoother in a variety of ways. The WIP is at https://review.openstack.org/#/c/602484/ One of the ways I'd like to change it is to not rely on devstack. I need only mysql, uwsgi, python and the current revision of placement on the node. The current job uses devstack-minimal as its base but that's overkill and slow. What is the correct base job to use which, as long as I put the files in the right place, will gather the logs I want? Thanks. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From emilien at redhat.com Wed Nov 21 02:18:23 2018 From: emilien at redhat.com (Emilien Macchi) Date: Tue, 20 Nov 2018 21:18:23 -0500 Subject: [openstack-dev] [tripleo] Feedback about our project at Summit Message-ID: Hi folks, I wasn't at the Summit but I was interested by the feedback people gave about TripleO so I've discussed with a few people who made the trip. I would like to see what actions we can take on short and long term to address it. I collected some thoughts here: https://etherpad.openstack.org/p/BER-tripleo-feedback Which is based on https://etherpad.openstack.org/p/BER-deployment-tools-feedback initially. Feel fee to add more feedback if missing, and also comment what was written. If you're aware of some WIP that address the feedback, adjust some wording if needed or just put some links if something exists and is documented already. I believe it is critical to us to listen this feedback and include some of it into our short term roadmap, so we can reduce some frustration that we can hear sometimes. Thanks for your help, -- Emilien Macchi -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From liliueecg at gmail.com Wed Nov 21 05:00:13 2018 From: liliueecg at gmail.com (Li Liu) Date: Wed, 21 Nov 2018 00:00:13 -0500 Subject: [openstack-dev] [cyborg] [weekly-meeting] Message-ID: There is no weekly IRC meeting for the week of Nov 21st as most of the people are still recovering from the jetlag after the summit. I will follow up with individuals offline. -- Thank you Regards Li -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From raniaadouni at gmail.com Wed Nov 21 00:58:11 2018 From: raniaadouni at gmail.com (Rania Adouni) Date: Wed, 21 Nov 2018 01:58:11 +0100 Subject: [openstack-dev] [zun] Failed to create Container In-Reply-To: References: Message-ID: hi , Thanks for your reply and yes the problem that kuryr-libnetwork is failed to start with the error : ● kuryr-libnetwork.service - Kuryr-libnetwork - Docker network plugin for Neutron Loaded: loaded (/etc/systemd/system/kuryr-libnetwork.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since mer. 2018-11-21 01:48:48 CET; 287ms ago Process: 13974 ExecStart=/usr/local/bin/kuryr-server --config-file /etc/kuryr/kuryr.conf (code=exited, status=1/FAILURE) Main PID: 13974 (code=exited, status=1/FAILURE) nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 13974 ERROR kuryr value = self._do_get(name, group, namespace) nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 13974 ERROR kuryr File "/usr/lib/python2.7/dist-packages/oslo_config/cfg.py", line 2942, in _ nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 13974 ERROR kuryr info = self._get_opt_info(name, group) nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 13974 ERROR kuryr File "/usr/lib/python2.7/dist-packages/oslo_config/cfg.py", line 3099, in _ nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 13974 ERROR kuryr raise NoSuchOptError(opt_name, group) nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 13974 ERROR kuryr NoSuchOptError: no such option driver in group [binding] nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 13974 ERROR kuryr nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Main process exited, code=exited, status=1/FAILURE nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Unit entered failed state. nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Failed with result 'exit-code'. and also the command lsof -iTCP -sTCP:LISTEN -P doesn't show the kuryr service : COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME dockerd 1144 root 5u IPv4 20120 0t0 TCP compute:2375 (LISTEN) sshd 1288 root 3u IPv4 19532 0t0 TCP *:22 (LISTEN) sshd 1288 root 4u IPv6 19534 0t0 TCP *:22 (LISTEN) dnsmasq 1961 nobody 6u IPv4 23450 0t0 TCP 192.168.122.1:53 (LISTEN) sshd 4163 adouni 9u IPv6 34950 0t0 TCP localhost:6010 (LISTEN) sshd 4163 adouni 10u IPv4 34951 0t0 TCP localhost:6010 (LISTEN) qemu-syst 4621 libvirt-qemu 18u IPv4 37121 0t0 TCP *:5900 (LISTEN) !!! Le mer. 21 nov. 2018 à 01:45, Jacob Burckhardt a écrit : > Your error message says it cannot connect to port 23750. That's the > kuryr-libnetwork default listen port. On 192.168.1.10, run: > > > > lsof -iTCP -sTCP:LISTEN -P > > > > On my compute node, it outputs: > > > > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > > … > > kuryr-ser 1976 root 6u IPv4 30896 0t0 TCP > localhost:23750 (LISTEN) > > > > So, you can see that kuryr is listening on 23750. If lsof does not list a > process listening on 23750, then check if kuryr is up by running: > > > > systemctl status kuryr-libnetwork > > > > You can also try restarting it by running: > > > > systemctl restart kuryr-libnetwork > > > > I installed that service by following: > > > > > https://docs.openstack.org/kuryr-libnetwork/queens/install/compute-install-ubuntu.html > > > > That is the queens install guide which might help you since zun has no > install guide in pike. > > > > If you see it listening, you can try this command: > > > > telnet 192.168.1.10 23750 > > > > If it fails to connect, then try: > > > > telnet localhost 23750 > > > > If it works with localhost but not 192.168.1.10, then I think that means > you need to tell docker to connect to localhost instead of 192.168.1.10. > > > > Can you get the commands at the following web page to succeed? > > > > https://docs.openstack.org/kuryr-libnetwork/queens/install/verify.html > > > > *Jacob Burckhardt* > > Senior Software Engineer > > [image: pdvWireless] > > > > *From:* Rania Adouni > *Sent:* Tuesday, November 20, 2018 2:02 PM > *To:* openstack-dev at lists.openstack.org > *Subject:* [openstack-dev] [zun] Failed to create Container > > > > > > Hi , > > > > I am starting to use zun on openstack pike , and when I try to lunch > container with cirros image , I get this reason : Docker internal error: > 500 Server Error: Internal Server Error ("legacy plugin: Post > http://192.168.1.10:23750/Plugin.Activate: dial tcp 192.168.1.10:23750: > connect: connection refused"). > > you can find here the log on my compute node : > https://pastebin.com/nZTiTZiV. > > some help with this will be great . > > Best Regards, > > Rania Adouni > > > > > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 2499 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 2499 bytes Desc: not available URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From hongbin034 at gmail.com Wed Nov 21 01:26:22 2018 From: hongbin034 at gmail.com (Hongbin Lu) Date: Tue, 20 Nov 2018 20:26:22 -0500 Subject: [openstack-dev] [zun] Failed to create Container In-Reply-To: References: Message-ID: Hi Rania, The config option 'driver' was recently renamed, so I guess the problem is the version of kuryr-lib is not right. The Pike release of Zun is matched to kuryr-lib 0.6.0 so you might want to confirm the version of kuryr-lib. $ sudo pip freeze | grep kuryr If the version is not right, uninstall and re-install the kuryr-lib, then restart kuryr-libnetwork. Let me know if it still doesn't work. Best regards, Hongbin On Tue, Nov 20, 2018 at 8:01 PM Rania Adouni wrote: > hi , > Thanks for your reply and yes the problem that kuryr-libnetwork is failed > to start with the error : > ● kuryr-libnetwork.service - Kuryr-libnetwork - Docker network plugin for > Neutron > Loaded: loaded (/etc/systemd/system/kuryr-libnetwork.service; enabled; > vendor preset: enabled) > Active: failed (Result: exit-code) since mer. 2018-11-21 01:48:48 CET; > 287ms ago > Process: 13974 ExecStart=/usr/local/bin/kuryr-server --config-file > /etc/kuryr/kuryr.conf (code=exited, status=1/FAILURE) > Main PID: 13974 (code=exited, status=1/FAILURE) > > nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 > 13974 ERROR kuryr value = self._do_get(name, group, namespace) > nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 > 13974 ERROR kuryr File > "/usr/lib/python2.7/dist-packages/oslo_config/cfg.py", line 2942, in _ > nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 > 13974 ERROR kuryr info = self._get_opt_info(name, group) > nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 > 13974 ERROR kuryr File > "/usr/lib/python2.7/dist-packages/oslo_config/cfg.py", line 3099, in _ > nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 > 13974 ERROR kuryr raise NoSuchOptError(opt_name, group) > nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 > 13974 ERROR kuryr NoSuchOptError: no such option driver in group [binding] > nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 > 13974 ERROR kuryr > nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Main > process exited, code=exited, status=1/FAILURE > nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Unit > entered failed state. > nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Failed with > result 'exit-code'. > > > and also the command lsof -iTCP -sTCP:LISTEN -P doesn't show the kuryr > service : > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > dockerd 1144 root 5u IPv4 20120 0t0 TCP compute:2375 > (LISTEN) > sshd 1288 root 3u IPv4 19532 0t0 TCP *:22 (LISTEN) > sshd 1288 root 4u IPv6 19534 0t0 TCP *:22 (LISTEN) > dnsmasq 1961 nobody 6u IPv4 23450 0t0 TCP > 192.168.122.1:53 (LISTEN) > sshd 4163 adouni 9u IPv6 34950 0t0 TCP > localhost:6010 (LISTEN) > sshd 4163 adouni 10u IPv4 34951 0t0 TCP > localhost:6010 (LISTEN) > qemu-syst 4621 libvirt-qemu 18u IPv4 37121 0t0 TCP *:5900 > (LISTEN) > > !!! > > > Le mer. 21 nov. 2018 à 01:45, Jacob Burckhardt < > jburckhardt at pdvwireless.com> a écrit : > >> Your error message says it cannot connect to port 23750. That's the >> kuryr-libnetwork default listen port. On 192.168.1.10, run: >> >> >> >> lsof -iTCP -sTCP:LISTEN -P >> >> >> >> On my compute node, it outputs: >> >> >> >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >> >> … >> >> kuryr-ser 1976 root 6u IPv4 30896 0t0 TCP >> localhost:23750 (LISTEN) >> >> >> >> So, you can see that kuryr is listening on 23750. If lsof does not list >> a process listening on 23750, then check if kuryr is up by running: >> >> >> >> systemctl status kuryr-libnetwork >> >> >> >> You can also try restarting it by running: >> >> >> >> systemctl restart kuryr-libnetwork >> >> >> >> I installed that service by following: >> >> >> >> >> https://docs.openstack.org/kuryr-libnetwork/queens/install/compute-install-ubuntu.html >> >> >> >> That is the queens install guide which might help you since zun has no >> install guide in pike. >> >> >> >> If you see it listening, you can try this command: >> >> >> >> telnet 192.168.1.10 23750 >> >> >> >> If it fails to connect, then try: >> >> >> >> telnet localhost 23750 >> >> >> >> If it works with localhost but not 192.168.1.10, then I think that means >> you need to tell docker to connect to localhost instead of 192.168.1.10. >> >> >> >> Can you get the commands at the following web page to succeed? >> >> >> >> https://docs.openstack.org/kuryr-libnetwork/queens/install/verify.html >> >> >> >> *Jacob Burckhardt* >> >> Senior Software Engineer >> >> [image: pdvWireless] >> >> >> >> *From:* Rania Adouni >> *Sent:* Tuesday, November 20, 2018 2:02 PM >> *To:* openstack-dev at lists.openstack.org >> *Subject:* [openstack-dev] [zun] Failed to create Container >> >> >> >> >> >> Hi , >> >> >> >> I am starting to use zun on openstack pike , and when I try to lunch >> container with cirros image , I get this reason : Docker internal error: >> 500 Server Error: Internal Server Error ("legacy plugin: Post >> http://192.168.1.10:23750/Plugin.Activate: dial tcp 192.168.1.10:23750: >> connect: connection refused"). >> >> you can find here the log on my compute node : >> https://pastebin.com/nZTiTZiV. >> >> some help with this will be great . >> >> Best Regards, >> >> Rania Adouni >> >> >> >> >> >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From raniaadouni at gmail.com Wed Nov 21 01:34:35 2018 From: raniaadouni at gmail.com (Rania Adouni) Date: Wed, 21 Nov 2018 02:34:35 +0100 Subject: [openstack-dev] [zun] Failed to create Container In-Reply-To: References: Message-ID: Hi Hongbin, Yes the version of kuryr-lib is :0.8.0 , So I think I should remove it ! I should remove only the kuryr-lib ! if you have some command they can help me to unisntall it , it will be nice to provide it . Best Regards, Rania Le mer. 21 nov. 2018 à 02:27, Hongbin Lu a écrit : > Hi Rania, > > The config option 'driver' was recently renamed, so I guess the problem is > the version of kuryr-lib is not right. The Pike release of Zun is matched > to kuryr-lib 0.6.0 so you might want to confirm the version of kuryr-lib. > > $ sudo pip freeze | grep kuryr > > If the version is not right, uninstall and re-install the kuryr-lib, then > restart kuryr-libnetwork. Let me know if it still doesn't work. > > Best regards, > Hongbin > > On Tue, Nov 20, 2018 at 8:01 PM Rania Adouni > wrote: > >> hi , >> Thanks for your reply and yes the problem that kuryr-libnetwork is >> failed to start with the error : >> ● kuryr-libnetwork.service - Kuryr-libnetwork - Docker network plugin for >> Neutron >> Loaded: loaded (/etc/systemd/system/kuryr-libnetwork.service; enabled; >> vendor preset: enabled) >> Active: failed (Result: exit-code) since mer. 2018-11-21 01:48:48 CET; >> 287ms ago >> Process: 13974 ExecStart=/usr/local/bin/kuryr-server --config-file >> /etc/kuryr/kuryr.conf (code=exited, status=1/FAILURE) >> Main PID: 13974 (code=exited, status=1/FAILURE) >> >> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >> 13974 ERROR kuryr value = self._do_get(name, group, namespace) >> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >> 13974 ERROR kuryr File >> "/usr/lib/python2.7/dist-packages/oslo_config/cfg.py", line 2942, in _ >> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >> 13974 ERROR kuryr info = self._get_opt_info(name, group) >> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >> 13974 ERROR kuryr File >> "/usr/lib/python2.7/dist-packages/oslo_config/cfg.py", line 3099, in _ >> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >> 13974 ERROR kuryr raise NoSuchOptError(opt_name, group) >> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >> 13974 ERROR kuryr NoSuchOptError: no such option driver in group [binding] >> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >> 13974 ERROR kuryr >> nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Main >> process exited, code=exited, status=1/FAILURE >> nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Unit >> entered failed state. >> nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Failed >> with result 'exit-code'. >> >> >> and also the command lsof -iTCP -sTCP:LISTEN -P doesn't show the kuryr >> service : >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >> dockerd 1144 root 5u IPv4 20120 0t0 TCP compute:2375 >> (LISTEN) >> sshd 1288 root 3u IPv4 19532 0t0 TCP *:22 (LISTEN) >> sshd 1288 root 4u IPv6 19534 0t0 TCP *:22 (LISTEN) >> dnsmasq 1961 nobody 6u IPv4 23450 0t0 TCP >> 192.168.122.1:53 (LISTEN) >> sshd 4163 adouni 9u IPv6 34950 0t0 TCP >> localhost:6010 (LISTEN) >> sshd 4163 adouni 10u IPv4 34951 0t0 TCP >> localhost:6010 (LISTEN) >> qemu-syst 4621 libvirt-qemu 18u IPv4 37121 0t0 TCP *:5900 >> (LISTEN) >> >> !!! >> >> >> Le mer. 21 nov. 2018 à 01:45, Jacob Burckhardt < >> jburckhardt at pdvwireless.com> a écrit : >> >>> Your error message says it cannot connect to port 23750. That's the >>> kuryr-libnetwork default listen port. On 192.168.1.10, run: >>> >>> >>> >>> lsof -iTCP -sTCP:LISTEN -P >>> >>> >>> >>> On my compute node, it outputs: >>> >>> >>> >>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >>> >>> … >>> >>> kuryr-ser 1976 root 6u IPv4 30896 0t0 TCP >>> localhost:23750 (LISTEN) >>> >>> >>> >>> So, you can see that kuryr is listening on 23750. If lsof does not list >>> a process listening on 23750, then check if kuryr is up by running: >>> >>> >>> >>> systemctl status kuryr-libnetwork >>> >>> >>> >>> You can also try restarting it by running: >>> >>> >>> >>> systemctl restart kuryr-libnetwork >>> >>> >>> >>> I installed that service by following: >>> >>> >>> >>> >>> https://docs.openstack.org/kuryr-libnetwork/queens/install/compute-install-ubuntu.html >>> >>> >>> >>> That is the queens install guide which might help you since zun has no >>> install guide in pike. >>> >>> >>> >>> If you see it listening, you can try this command: >>> >>> >>> >>> telnet 192.168.1.10 23750 >>> >>> >>> >>> If it fails to connect, then try: >>> >>> >>> >>> telnet localhost 23750 >>> >>> >>> >>> If it works with localhost but not 192.168.1.10, then I think that means >>> you need to tell docker to connect to localhost instead of 192.168.1.10. >>> >>> >>> >>> Can you get the commands at the following web page to succeed? >>> >>> >>> >>> https://docs.openstack.org/kuryr-libnetwork/queens/install/verify.html >>> >>> >>> >>> *Jacob Burckhardt* >>> >>> Senior Software Engineer >>> >>> [image: pdvWireless] >>> >>> >>> >>> *From:* Rania Adouni >>> *Sent:* Tuesday, November 20, 2018 2:02 PM >>> *To:* openstack-dev at lists.openstack.org >>> *Subject:* [openstack-dev] [zun] Failed to create Container >>> >>> >>> >>> >>> >>> Hi , >>> >>> >>> >>> I am starting to use zun on openstack pike , and when I try to lunch >>> container with cirros image , I get this reason : Docker internal >>> error: 500 Server Error: Internal Server Error ("legacy plugin: Post >>> http://192.168.1.10:23750/Plugin.Activate: dial tcp 192.168.1.10:23750: >>> connect: connection refused"). >>> >>> you can find here the log on my compute node : >>> https://pastebin.com/nZTiTZiV. >>> >>> some help with this will be great . >>> >>> Best Regards, >>> >>> Rania Adouni >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From raniaadouni at gmail.com Wed Nov 21 01:55:18 2018 From: raniaadouni at gmail.com (Rania Adouni) Date: Wed, 21 Nov 2018 02:55:18 +0100 Subject: [openstack-dev] [zun] Failed to create Container In-Reply-To: References: Message-ID: Hi Hongbin , thanks for your advice I did fix it with changing the kuryr-lib to 0.6.0 and my service just work fine and also with lsof -iTCP -sTCP:LISTEN -P I can see it in the list : *kuryr-ser 16581 root 5u IPv4 91929 0t0 TCP localhost:23750 (LISTEN)* ------------> that is great. + but I have two questions : 1- How I can change the localhost to my compute address ( 192.168.1.10:23750) because it is still the same error when trying to create container " Docker internal error: 500 Server Error: Internal Server Error ("legacy plugin: Post http://192.168.1.10:23750/Plugin.Activate: dial tcp 192.168.1.10:23750: connect: connection refused"). ? 2- my other question is about the log of zun why I can find it under my directory /var/log ? Best Regards, Rania Adouni Le mer. 21 nov. 2018 à 02:34, Rania Adouni a écrit : > Hi Hongbin, > Yes the version of kuryr-lib is :0.8.0 , So I think I should remove it ! > I should remove only the kuryr-lib ! if you have some command they can > help me to unisntall it , it will be nice to provide it . > > Best Regards, > Rania > > > Le mer. 21 nov. 2018 à 02:27, Hongbin Lu a écrit : > >> Hi Rania, >> >> The config option 'driver' was recently renamed, so I guess the problem >> is the version of kuryr-lib is not right. The Pike release of Zun is >> matched to kuryr-lib 0.6.0 so you might want to confirm the version of >> kuryr-lib. >> >> $ sudo pip freeze | grep kuryr >> >> If the version is not right, uninstall and re-install the kuryr-lib, then >> restart kuryr-libnetwork. Let me know if it still doesn't work. >> >> Best regards, >> Hongbin >> >> On Tue, Nov 20, 2018 at 8:01 PM Rania Adouni >> wrote: >> >>> hi , >>> Thanks for your reply and yes the problem that kuryr-libnetwork is >>> failed to start with the error : >>> ● kuryr-libnetwork.service - Kuryr-libnetwork - Docker network plugin >>> for Neutron >>> Loaded: loaded (/etc/systemd/system/kuryr-libnetwork.service; >>> enabled; vendor preset: enabled) >>> Active: failed (Result: exit-code) since mer. 2018-11-21 01:48:48 >>> CET; 287ms ago >>> Process: 13974 ExecStart=/usr/local/bin/kuryr-server --config-file >>> /etc/kuryr/kuryr.conf (code=exited, status=1/FAILURE) >>> Main PID: 13974 (code=exited, status=1/FAILURE) >>> >>> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >>> 13974 ERROR kuryr value = self._do_get(name, group, namespace) >>> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >>> 13974 ERROR kuryr File >>> "/usr/lib/python2.7/dist-packages/oslo_config/cfg.py", line 2942, in _ >>> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >>> 13974 ERROR kuryr info = self._get_opt_info(name, group) >>> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >>> 13974 ERROR kuryr File >>> "/usr/lib/python2.7/dist-packages/oslo_config/cfg.py", line 3099, in _ >>> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >>> 13974 ERROR kuryr raise NoSuchOptError(opt_name, group) >>> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >>> 13974 ERROR kuryr NoSuchOptError: no such option driver in group [binding] >>> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >>> 13974 ERROR kuryr >>> nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Main >>> process exited, code=exited, status=1/FAILURE >>> nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Unit >>> entered failed state. >>> nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Failed >>> with result 'exit-code'. >>> >>> >>> and also the command lsof -iTCP -sTCP:LISTEN -P doesn't show the kuryr >>> service : >>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >>> dockerd 1144 root 5u IPv4 20120 0t0 TCP >>> compute:2375 (LISTEN) >>> sshd 1288 root 3u IPv4 19532 0t0 TCP *:22 >>> (LISTEN) >>> sshd 1288 root 4u IPv6 19534 0t0 TCP *:22 >>> (LISTEN) >>> dnsmasq 1961 nobody 6u IPv4 23450 0t0 TCP >>> 192.168.122.1:53 (LISTEN) >>> sshd 4163 adouni 9u IPv6 34950 0t0 TCP >>> localhost:6010 (LISTEN) >>> sshd 4163 adouni 10u IPv4 34951 0t0 TCP >>> localhost:6010 (LISTEN) >>> qemu-syst 4621 libvirt-qemu 18u IPv4 37121 0t0 TCP *:5900 >>> (LISTEN) >>> >>> !!! >>> >>> >>> Le mer. 21 nov. 2018 à 01:45, Jacob Burckhardt < >>> jburckhardt at pdvwireless.com> a écrit : >>> >>>> Your error message says it cannot connect to port 23750. That's the >>>> kuryr-libnetwork default listen port. On 192.168.1.10, run: >>>> >>>> >>>> >>>> lsof -iTCP -sTCP:LISTEN -P >>>> >>>> >>>> >>>> On my compute node, it outputs: >>>> >>>> >>>> >>>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >>>> >>>> … >>>> >>>> kuryr-ser 1976 root 6u IPv4 30896 0t0 TCP >>>> localhost:23750 (LISTEN) >>>> >>>> >>>> >>>> So, you can see that kuryr is listening on 23750. If lsof does not >>>> list a process listening on 23750, then check if kuryr is up by running: >>>> >>>> >>>> >>>> systemctl status kuryr-libnetwork >>>> >>>> >>>> >>>> You can also try restarting it by running: >>>> >>>> >>>> >>>> systemctl restart kuryr-libnetwork >>>> >>>> >>>> >>>> I installed that service by following: >>>> >>>> >>>> >>>> >>>> https://docs.openstack.org/kuryr-libnetwork/queens/install/compute-install-ubuntu.html >>>> >>>> >>>> >>>> That is the queens install guide which might help you since zun has no >>>> install guide in pike. >>>> >>>> >>>> >>>> If you see it listening, you can try this command: >>>> >>>> >>>> >>>> telnet 192.168.1.10 23750 >>>> >>>> >>>> >>>> If it fails to connect, then try: >>>> >>>> >>>> >>>> telnet localhost 23750 >>>> >>>> >>>> >>>> If it works with localhost but not 192.168.1.10, then I think that >>>> means you need to tell docker to connect to localhost instead of >>>> 192.168.1.10. >>>> >>>> >>>> >>>> Can you get the commands at the following web page to succeed? >>>> >>>> >>>> >>>> https://docs.openstack.org/kuryr-libnetwork/queens/install/verify.html >>>> >>>> >>>> >>>> *Jacob Burckhardt* >>>> >>>> Senior Software Engineer >>>> >>>> [image: pdvWireless] >>>> >>>> >>>> >>>> *From:* Rania Adouni >>>> *Sent:* Tuesday, November 20, 2018 2:02 PM >>>> *To:* openstack-dev at lists.openstack.org >>>> *Subject:* [openstack-dev] [zun] Failed to create Container >>>> >>>> >>>> >>>> >>>> >>>> Hi , >>>> >>>> >>>> >>>> I am starting to use zun on openstack pike , and when I try to lunch >>>> container with cirros image , I get this reason : Docker internal >>>> error: 500 Server Error: Internal Server Error ("legacy plugin: Post >>>> http://192.168.1.10:23750/Plugin.Activate: dial tcp 192.168.1.10:23750: >>>> connect: connection refused"). >>>> >>>> you can find here the log on my compute node : >>>> https://pastebin.com/nZTiTZiV. >>>> >>>> some help with this will be great . >>>> >>>> Best Regards, >>>> >>>> Rania Adouni >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From soheil.ir08 at gmail.com Wed Nov 21 11:08:04 2018 From: soheil.ir08 at gmail.com (Soheil Pourbafrani) Date: Wed, 21 Nov 2018 14:38:04 +0330 Subject: [Openstack] [OpenStack][Compute-Neutron] Is it possible to create flat network from different NICs Message-ID: Hi, I installed OpenStack on One node (for test) and creating a flat external network I could connect VMs to the provider network (internet). In the production environment, we have 4 NIC on each server and each server (compute node) will run 4 instances. My question is, is it possible to create a separate external network based on each NIC (so 4 external networks) and run each instance using one of them? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From soheil.ir08 at gmail.com Wed Nov 21 11:38:01 2018 From: soheil.ir08 at gmail.com (Soheil Pourbafrani) Date: Wed, 21 Nov 2018 15:08:01 +0330 Subject: [Openstack] [OpenStack][Compute-Neutron] Is it possible to create flat network from different NICs In-Reply-To: <9E359876-421D-466C-A5B6-9F9B94331E74@redhat.com> References: <9E359876-421D-466C-A5B6-9F9B94331E74@redhat.com> Message-ID: Thanks a lot. On Wed, Nov 21, 2018 at 2:51 PM Slawomir Kaplonski wrote: > Hi, > > Yes, that should be possible. You can create 4 bridges on compute node and > add all of them to bridge_mappings config option. > Then You can create 4 networks with different physical_network for each of > them and agent will know which bridge should be used for ports from each > network. > It is described e.g. in [1]. > > [1] > https://ask.openstack.org/en/question/94206/how-to-understand-the-bridge_mappings/?answer=94230#post-id-94230 > > > Wiadomość napisana przez Soheil Pourbafrani w > dniu 21.11.2018, o godz. 12:08: > > > > Hi, > > > > I installed OpenStack on One node (for test) and creating a flat > external network I could connect VMs to the provider network (internet). > > > > In the production environment, we have 4 NIC on each server and each > server (compute node) will run 4 instances. My question is, is it possible > to create a separate external network based on each NIC (so 4 external > networks) and run each instance using one of them? > > _______________________________________________ > > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > Post to : openstack at lists.openstack.org > > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > — > Slawek Kaplonski > Senior software engineer > Red Hat > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From wjstk16 at gmail.com Wed Nov 21 11:18:23 2018 From: wjstk16 at gmail.com (Won) Date: Wed, 21 Nov 2018 20:18:23 +0900 Subject: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage. In-Reply-To: References: Message-ID: Hi, I attached four log files. I collected the logs from about 17:14 to 17:42. I created an instance of 'deltesting3' at 17:17. 7minutes later, at 17:24, the entity graph showed the dentesting3 and vitrage colletor and graph logs are appeared. When creating an instance in ubuntu server, it appears immediately in the entity graph and logs, but when creating an instance in computer1 (multi node), it appears about 5~10 minutes later. I deleted an instance of 'deltesting3' around 17:26. > After ~20minutes, there was only Apigateway. Does it make sense? did you > delete the instances on ubuntu, in addition to deltesting? > I only deleted 'deltesting'. After that, only the logs from 'apigateway' and 'kube-master' were collected. But other instances were working well. I don't know why only two instances are collected in the log. NOV 19 In this log, 'agigateway' and 'kube-master' were continuously collected in a short period of time, but other instances were sometimes collected in long periods. In any case, I would expect to see the instances deleted from the graph at > this stage, since they were not returned by get_all. > Can you please send me the log of vitrage-graph at the same time (Nov 15, > 16:35-17:10)? > Information 'deldtesting3' that has already been deleted continues to be collected in vitrage-graph.service. Br, Won 2018년 11월 15일 (목) 오후 10:13, Ifat Afek 님이 작성: > > On Thu, Nov 15, 2018 at 10:28 AM Won wrote: > >> Looking at the logs, I see two issues: >>> 1. On ubuntu server, you get a notification about the vm deletion, while >>> on compute1 you don't get it. >>> Please make sure that Nova sends notifications to >>> 'vitrage_notifications' - it should be configured in /etc/nova/nova.conf. >>> 2. Once in 10 minutes (by default) nova.instance datasource queries all >>> instances. The deleted vm is supposed to be deleted in Vitrage at this >>> stage, even if the notification was lost. >>> Please check in your collector log for the a message of "novaclient.v2.client >>> [-] RESP BODY" before and after the deletion, and send me its content. >> >> >> I attached two log files. I created a VM in computer1 which is a >> computer node and deleted it a few minutes later. Log for 30 minutes from >> VM creation. >> The first is the log of the vitrage-collect that grep instance name. >> The second is the noovaclient.v2.clinet [-] RESP BODY log. >> After I deleted the VM, no log of the instance appeared in the collector >> log no matter how long I waited. >> >> I added the following to Nova.conf on the computer1 node.(attached file >> 'compute_node_local_conf.txt') >> notification_topics = notifications,vitrage_notifications >> notification_driver = messagingv2 >> vif_plugging_timeout = 300 >> notify_on_state_change = vm_and_task_state >> instance_usage_audit_period = hour >> instance_usage_audit = True >> > > Hi, > > From the collector log RESP BODY messages I understand that in the > beginning there were the following servers: > compute1: deltesting > ubuntu: Apigateway, KubeMaster and others > > After ~20minutes, there was only Apigateway. Does it make sense? did you > delete the instances on ubuntu, in addition to deltesting? > In any case, I would expect to see the instances deleted from the graph at > this stage, since they were not returned by get_all. > Can you please send me the log of vitrage-graph at the same time (Nov 15, > 16:35-17:10)? > > There is still the question of why we don't see a notification from Nova, > but let's try to solve the issues one by one. > > Thanks, > Ifat > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vitrage_collect_logs_grep_Instance_name Type: application/octet-stream Size: 2182 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vitrage_collect_logs_grep_RESPBODY Type: application/octet-stream Size: 105514 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vitrage_graph_logs_grep_Instance_name Type: application/octet-stream Size: 810274 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vitrage_graph_logs Type: application/octet-stream Size: 16992590 bytes Desc: not available URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From lijie at unitedstack.com Wed Nov 21 12:16:20 2018 From: lijie at unitedstack.com (=?utf-8?B?UmFtYm8=?=) Date: Wed, 21 Nov 2018 20:16:20 +0800 Subject: [openstack-dev] [glance] about use shared image with each other In-Reply-To: <6d53c9e9-98f6-d594-bbfb-837c74d5fbae@gmail.com> References: <6d53c9e9-98f6-d594-bbfb-837c74d5fbae@gmail.com> Message-ID: yes, but I also have a question, Do we have the quota limit for requests to share the image to each other? For example, someone shares the image with me without stop, how do we deal with it? ------------------ Original ------------------ From: "Brian Rosmaita"; Date: Mon, Nov 19, 2018 10:26 PM To: "OpenStack Developmen"; Subject: Re: [openstack-dev] [glance] about use shared image with each other On 11/19/18 7:58 AM, Rambo wrote: > Hi,all > > Recently, I want to use the shared image with each other.I find it > isn't convenient that the producer notifies the consumer via email which > the image has been shared and what its UUID is. In other words, why the > image api v2 is no provision for producer-consumer communication? The design goal for Image API v2 image sharing was to provide an infrastructure for an "image marketplace" in an OpenStack cloud by (a) making it easy for cloud end users to share images, and (b) making it easy for end users not to be spammed by other end users taking advantage of (a). When v2 image sharing was introduced in the Grizzly release, we did not want to dictate how producer-consumer communication would work (because we had no idea how it would develop), so we left it up to operators and end users to figure this out. The advantage of email communication is that client side message filtering is available for whatever client a particular cloud end-user employs, and presumably that end-user knows how to manipulate the filters without learning some new scheme (or, if the end-user doesn't know, learning how to filter messages will apply beyond just image sharing, which is a plus). Also, email communication is just one way to handle producer-consumer communication. Some operators have adjusted their web interfaces so that when an end-user looks at the list of images available, a notification pops up if the end-user has any images that have been shared with them and are still in "pending" status. There are various other creative things you can do using the normal API calls with regular user credentials. In brief, we figured that if an image marketplace evolved in a particular cloud, producers and consumers would forge their own relationships in whatever way made the most sense for their particular use cases. So we left producer-consumer communication out-of-band. > To make it is more convenient, if we can add a task to change the > member_status from "pending" to "accepted" when we share the image with > each other. It is similar to the resize_confirm in Nova, we can control > the time interval in config. You could do this, but that would defeat the entire purpose of the member statuses implementation, and hence I do not recommend it. See OSSN-0005 [1] for more about this issue. Additionally, since the Ocata release, "community" images have been available. These do not have to be accepted by an end user (but they also don't show up in the default image-list response). Who can "communitize" an image is governed by policy. See [2] for a discussion of the various types of image sharing currently available in the Image API v2. The Image Service API v2 api-ref [3] contains a brief discussion of image visibility and image sharing that may also be useful. Finally, the Glance Ocata release notes [4] have an extensive discussion of image visibility. > Can you tell me more about this?Thank you very much! The original design page on the wiki [5] has a list of 14 use cases we wanted to address; looking through those will give you a better idea of why we made the design choices we did. Hope this helps! cheers, brian [0] http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html [1] https://wiki.openstack.org/wiki/OSSN/1226078 [2] http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html [3] https://developer.openstack.org/api-ref/image/v2/ [4] https://docs.openstack.org/releasenotes/glance/ocata.html [5] https://wiki.openstack.org/wiki/Glance-api-v2-image-sharing > > Best Regards > Rambo > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From raniaadouni at gmail.com Wed Nov 21 12:24:40 2018 From: raniaadouni at gmail.com (Rania Adouni) Date: Wed, 21 Nov 2018 13:24:40 +0100 Subject: [openstack-dev] [ZUN] [kuryr-libnetwork] Message-ID: Hi everyone, I was trying to create container but I just ended up by this error : *Docker internal error: 500 Server Error: Internal Server Error ("failed to update store for object type *libnetwork.endpointCnt: dial tcp 192.168.1.20:2379 : connect: connection refused").* Then I back to Verify operation of the kuryr-libnetwork, if it work fine or not with command : *docker network create --driver kuryr --ipam-driver kuryr --subnet 10.10.0.0/16 --gateway=10.10.0.1 test_net * But i get this error : *Error response from daemon: failed to update store for object type *libnetwork.endpointCnt: dial tcp 192.168.1.20:2379 : connect: connection refused * *Ps: 192.168.1.20 is the address of my controller Node !!* some help will be nice and thanks . Best Regards, Rania Adouni -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From srikanthkumar.lingala at gmail.com Wed Nov 21 13:08:40 2018 From: srikanthkumar.lingala at gmail.com (Srikanth Kumar Lingala) Date: Wed, 21 Nov 2018 18:38:40 +0530 Subject: [openstack-dev] VM stalls with the console log "Exiting boot services and installing virtual address map" Message-ID: Hi, I am working with OpenStack stable/pike release in Ubuntu 18.04. When I am trying to spawn VM, which is worked in the earlier OpenStack releases, VM is stalled with the following log in the VM console logs: EFI stub: Booting Linux Kernel... EFI stub: Generating empty DTB EFI stub: Exiting boot services and installing virtual address map... I am observing that VM is in Running status, without any error logs. And, VM is booting with UEFI support. But, I am not able to get VM Console. Earlier I didn't observe this. How can I disable UEFI support, while spawning VM's in OpenStack Nova-Compute. My Libvirt version is 4.0.0. Can someone help me to fix the issue. Regards, Srikanth. -- ---- Srikanth. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From e0ne at e0ne.info Wed Nov 21 14:30:49 2018 From: e0ne at e0ne.info (Ivan Kolodyazhny) Date: Wed, 21 Nov 2018 16:30:49 +0200 Subject: [openstack-dev] [horizon] Do we want new meeting time? In-Reply-To: References: Message-ID: Hi all, Due to the low activity on our weekly meeting, I would like to raise this question again. Do we want a new meeting day and/or time? I'm available any day except Tuesday and Wednesday. I'm going to get some feedback before I create a new poll. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Thu, Apr 5, 2018 at 1:42 PM Ivan Kolodyazhny wrote: > Hi team, > > It's a friendly reminder that we've got voting open [1] until next > meeting. If you would like to attend Horizon meetings, please, select > comfortable options for you. > > [1] https://doodle.com/poll/ei5gstt73d8v3a35 > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > On Wed, Mar 21, 2018 at 6:40 PM, Ivan Kolodyazhny wrote: > >> Hi team, >> >> As was discussed at PTG, usually we've got a very few participants on our >> weekly meetings. I hope, mostly it's because of not comfort meeting time >> for many of us. >> >> Let's try to re-schedule Horizon weekly meetings and get more attendees >> there. I've created a doodle for it [1]. Please, vote for the best time for >> you. >> >> >> [1] https://doodle.com/poll/ei5gstt73d8v3a35 >> >> Regards, >> Ivan Kolodyazhny, >> http://blog.e0ne.info/ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From doug at doughellmann.com Wed Nov 21 14:47:18 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 21 Nov 2018 09:47:18 -0500 Subject: Let's use [dev] for development discussions In-Reply-To: References: Message-ID: Thierry Carrez writes: > Hi openstack-discuss, > > As part of the ML merge, we introduced a number of subject prefixes to > help subscribers filter discussions. The most important ones are to use: > > [dev] For discussions that are purely development-oriented > [ops] For discussions that are purely operations-oriented > > Of course (as we have realized with the amount of cross-posted topics), > most discussions benefit from input from all our contributors, whether > they come from an development or an operational background. For those, > there is no need to apply [dev] and/or [ops] prefixes, just try to be > informative by adding the project name, team name or other information > instead. > > You can ping specific populations by adding: > > [tc] Discussions of interest for TC members > [uc] Discussions of interest for UC members > [ptl] Discussions of interest for all PTLs > [release] Release team, release liaisons and PTLs > > You can also specifically use (with care): > > [all] For discussions that should really be of interest to EVERYONE > > See (and add!) other common subject prefixes at: > https://etherpad.openstack.org/p/common-openstack-ml-topics > > Thanks for your help in making this common list more navigable. > > -- > Thierry Carrez (ttx) > Should we start moving this information into the project team guide? -- Doug From hberaud at redhat.com Wed Nov 21 14:47:25 2018 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 21 Nov 2018 15:47:25 +0100 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch Message-ID: Hey all! Here is a thread to coordinate all the teams (oslo, nova, stable, requirements) working on the update of the oslo.service constraint in the Rocky requirements. # Summary Usage of threading event with eventlet caused inefficient code (causing many useless system calls and high CPU usage). This issue was already fixed on oslo.service master and we also want to fix it in stable/rocky. Our main issue is how to fix the high CPU usage on stable/rocky without break the nova CI. Indeed, we already have backported the eventlet related fix to oslo.service but this fix requires also a nova update to avoid nova CI errors due to threading removal on oslo.service that introduce the nova CI errors. A fix was proposed and merged on oslo.service master to introduce a new feature (fixture) that avoid the nova CI errors, but backporting the master fix to Rocky introduces a new feature into a stable branch so this is also an issue. So we need to discuss with all the teams to find a proper solution. # History A few weeks ago this issue was opened on oslo.service ( https://bugs.launchpad.net/oslo.service/+bug/1798774) and it was fixed by this submited patch on the master branch ( https://review.openstack.org/#/c/611807/ ). This change use the proper event primitive to fix the performance issue. A new version of oslo.service was released (1.32.1) Since these changes was introduced into oslo.service master, nova facing some issues into the master CI process, due to the threading changes, and they was fixed by these patches ( https://review.openstack.org/#/c/615724/, https://review.openstack.org/#/c/617989/ ) into master. Few weeks ago I have backport to oslo.service some changes ( https://review.openstack.org/#/c/614489/ ) from master to stable/rocky to also fix the problem in the rocky release. When this backport was merged we have created a new release of oslo.service (1.31.6) ( https://review.openstack.org/#/c/616505/ ) (stable/rocky version). Then the openstack proposal bot submit a patch to requirements on stable rocky to update the oslo.service version with the latest version (1.31.6) but if we'll use it we'll then break the CI https://review.openstack.org/#/c/618834/ so this patch is currently blocked to avoid nova CI error. # Issue Since the oslo.services threading changes were backported to rocky we risk to faces the same issues inside the nova rocky CI if we update the requirements. In parallel in oslo.service we have started to backport a new patch who introduces fixture ( https://review.openstack.org/#/c/617989/ ) from master to rocky, and also we start to backport on nova rocky branch ( https://review.openstack.org/619019, https://review.openstack.org/619022 ) patches who use oslo.service.fixture and who solve the nova CI issue. The patch on oslo.service exposes a public oslo_service.fixture.SleepFixture for this purpose. It can be maintained opaquely as internals change without affecting its consumers. The main problem is that the patch bring a new functionality to a stable branch (oslo.service rocky) but this patch help to fix the nova issue. Also openstack proposal bot submit a patch to requirements on stable rocky to update the oslo.service version with the latest version (1.31.6) but if we'll use it we'll then break the CI https://review.openstack.org/#/c/618834/ since the oslo service 1.31.6 is incompatible with novas stable rocky unittest due to the threading changes. # Questions and proposed solutions This thread try to summarize the current situation. We need to find how to be able to proceed, so this thread aim to allow to discuss between team to find the best way to fix. 1. Do we need to continue to try to backport fixture on oslo.service to fix the CI problem (https://review.openstack.org/#/c/617989/) ? 2. Do we need to find an another approach like mocking oslo.service.loopingcall._Event.wait in nova instead of mocking oslo_service.loopingcall._ThreadingEvent.wait (example: https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py) ? This is only a fix on the nova side and it allows us to update oslo.service requirements and allows us to fix the high CPU usage issue. I've submit this patch (https://review.openstack.org/619246) who implement the description above. Personaly I think we need to find an another approach like the mocking remplacement (c.f 2). We need to decide which way we use and to discuss about other solutions. -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Wed Nov 21 14:53:48 2018 From: smooney at redhat.com (Sean Mooney) Date: Wed, 21 Nov 2018 14:53:48 +0000 Subject: [infra] [zuul] [placement] Minimizing size/time of test node In-Reply-To: References: Message-ID: <17b9e12f947973ae8e7c363209373294dfe620f7.camel@redhat.com> On Wed, 2018-11-21 at 12:59 +0000, Chris Dent wrote: > I have a work in progress to run a little job in placement that > gathers very simple performance numbers on some queries. This is > being done as a sort of sanity check. As with many such things it is > a bit rough around the edges and I'd like to make it smoother in a > variety of ways. > > The WIP is at https://review.openstack.org/#/c/602484/ > > One of the ways I'd like to change it is to not rely on devstack. I > need only mysql, uwsgi, python and the current revision of placement > on the node. The current job uses devstack-minimal as its base but > that's overkill and slow. out of interest if you did devstack-minimal then set disable-all-services or whatever the macro is and then just enabled mariadb and placement service would there be much of a delta in job time? > > What is the correct base job to use which, as long as I put the > files in the right place, will gather the logs I want? > > Thanks. > From doug at doughellmann.com Wed Nov 21 14:57:02 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 21 Nov 2018 09:57:02 -0500 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: References: Message-ID: Herve Beraud writes: > Hey all! > > Here is a thread to coordinate all the teams (oslo, nova, stable, > requirements) working on the update of the oslo.service constraint in the > Rocky requirements. > > # Summary > > Usage of threading event with eventlet caused inefficient code (causing > many useless system calls and high CPU usage). > This issue was already fixed on oslo.service master and we also want to fix > it in stable/rocky. > > Our main issue is how to fix the high CPU usage on stable/rocky without > break the nova CI. > > Indeed, we already have backported the eventlet related fix to oslo.service > but this fix requires also a nova update to avoid nova CI errors due to > threading removal on oslo.service that introduce the nova CI errors. > > A fix was proposed and merged on oslo.service master to introduce a new > feature (fixture) that avoid the nova CI errors, but > backporting the master fix to Rocky introduces a new feature into a stable > branch so this is also an issue. > > So we need to discuss with all the teams to find a proper solution. > > # History > > A few weeks ago this issue was opened on oslo.service ( > https://bugs.launchpad.net/oslo.service/+bug/1798774) and it was fixed by > this submited patch on the master branch ( > https://review.openstack.org/#/c/611807/ ). > > This change use the proper event primitive to fix the performance issue. > > A new version of oslo.service was released (1.32.1) > > Since these changes was introduced into oslo.service master, nova facing > some issues into the master CI process, due to the threading changes, and > they was fixed by these patches ( https://review.openstack.org/#/c/615724/, > https://review.openstack.org/#/c/617989/ ) into master. > > Few weeks ago I have backport to oslo.service some changes ( > https://review.openstack.org/#/c/614489/ ) from master to stable/rocky to > also fix the problem in the rocky release. > > When this backport was merged we have created a new release of oslo.service > (1.31.6) ( https://review.openstack.org/#/c/616505/ ) (stable/rocky > version). > > Then the openstack proposal bot submit a patch to requirements on stable > rocky to update the oslo.service version with the latest version (1.31.6) > but if we'll use it we'll then break the CI > https://review.openstack.org/#/c/618834/ so this patch is currently blocked > to avoid nova CI error. > > # Issue > > Since the oslo.services threading changes were backported to rocky we risk > to faces the same issues inside the nova rocky CI if we update the > requirements. > > In parallel in oslo.service we have started to backport a new patch who > introduces fixture ( https://review.openstack.org/#/c/617989/ ) from > master to rocky, and also we start to backport on nova rocky branch ( > https://review.openstack.org/619019, https://review.openstack.org/619022 ) > patches who use oslo.service.fixture and who solve the nova CI issue. The > patch on oslo.service exposes a public oslo_service.fixture.SleepFixture > for this purpose. It can be maintained opaquely as internals change without > affecting its consumers. > > The main problem is that the patch bring a new functionality to a stable > branch (oslo.service rocky) but this patch help to fix the nova issue. > > Also openstack proposal bot submit a patch to requirements on stable rocky > to update the oslo.service version with the latest version (1.31.6) but if > we'll use it we'll then break the CI > https://review.openstack.org/#/c/618834/ since the oslo service 1.31.6 is > incompatible with novas stable rocky unittest due to the threading changes. > > # Questions and proposed solutions > > This thread try to summarize the current situation. > > We need to find how to be able to proceed, so this thread aim to allow to > discuss between team to find the best way to fix. > > 1. Do we need to continue to try to backport fixture on oslo.service to fix > the CI problem (https://review.openstack.org/#/c/617989/) ? > > 2. Do we need to find an another approach like mocking > oslo.service.loopingcall._Event.wait in nova instead of mocking > oslo_service.loopingcall._ThreadingEvent.wait (example: > https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py) > ? > This is only a fix on the nova side and it allows us to update oslo.service > requirements and allows us to fix the high CPU usage issue. I've submit > this patch (https://review.openstack.org/619246) who implement the > description above. > > Personaly I think we need to find an another approach like the mocking > remplacement (c.f 2). > > We need to decide which way we use and to discuss about other solutions. > > -- > Hervé Beraud > Senior Software Engineer > Red Hat - Openstack Oslo > irc: hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- Thank you for summarizing this issue, Hervé, and for working on the patches we need. I think I would be happy with either solution. Using clean backports seems less risky, and even though we are adding a new feature to oslo.service it's only a unit test fixture. On the other hand if we want to be very strict about not adding features in stable branches and we are OK with creating a change to nova's unit tests that is not backported from master, then that works for me, too. I have a slight preference for the first proposal, but not strong enough to vote fight for it if the majority decides to go with the second option. -- Doug From smooney at redhat.com Wed Nov 21 15:02:00 2018 From: smooney at redhat.com (Sean Mooney) Date: Wed, 21 Nov 2018 15:02:00 +0000 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: References: Message-ID: On Wed, 2018-11-21 at 09:57 -0500, Doug Hellmann wrote: > Herve Beraud writes: > > > Hey all! > > > > Here is a thread to coordinate all the teams (oslo, nova, stable, > > requirements) working on the update of the oslo.service constraint in the > > Rocky requirements. > > > > # Summary > > > > Usage of threading event with eventlet caused inefficient code (causing > > many useless system calls and high CPU usage). > > This issue was already fixed on oslo.service master and we also want to fix > > it in stable/rocky. > > > > Our main issue is how to fix the high CPU usage on stable/rocky without > > break the nova CI. > > > > Indeed, we already have backported the eventlet related fix to oslo.service > > but this fix requires also a nova update to avoid nova CI errors due to > > threading removal on oslo.service that introduce the nova CI errors. > > > > A fix was proposed and merged on oslo.service master to introduce a new > > feature (fixture) that avoid the nova CI errors, but > > backporting the master fix to Rocky introduces a new feature into a stable > > branch so this is also an issue. > > > > So we need to discuss with all the teams to find a proper solution. > > > > # History > > > > A few weeks ago this issue was opened on oslo.service ( > > https://bugs.launchpad.net/oslo.service/+bug/1798774) and it was fixed by > > this submited patch on the master branch ( > > https://review.openstack.org/#/c/611807/ ). > > > > This change use the proper event primitive to fix the performance issue. > > > > A new version of oslo.service was released (1.32.1) > > > > Since these changes was introduced into oslo.service master, nova facing > > some issues into the master CI process, due to the threading changes, and > > they was fixed by these patches ( https://review.openstack.org/#/c/615724/, > > https://review.openstack.org/#/c/617989/ ) into master. > > > > Few weeks ago I have backport to oslo.service some changes ( > > https://review.openstack.org/#/c/614489/ ) from master to stable/rocky to > > also fix the problem in the rocky release. > > > > When this backport was merged we have created a new release of oslo.service > > (1.31.6) ( https://review.openstack.org/#/c/616505/ ) (stable/rocky > > version). > > > > Then the openstack proposal bot submit a patch to requirements on stable > > rocky to update the oslo.service version with the latest version (1.31.6) > > but if we'll use it we'll then break the CI > > https://review.openstack.org/#/c/618834/ so this patch is currently blocked > > to avoid nova CI error. > > > > # Issue > > > > Since the oslo.services threading changes were backported to rocky we risk > > to faces the same issues inside the nova rocky CI if we update the > > requirements. > > > > In parallel in oslo.service we have started to backport a new patch who > > introduces fixture ( https://review.openstack.org/#/c/617989/ ) from > > master to rocky, and also we start to backport on nova rocky branch ( > > https://review.openstack.org/619019, https://review.openstack.org/619022 ) > > patches who use oslo.service.fixture and who solve the nova CI issue. The > > patch on oslo.service exposes a public oslo_service.fixture.SleepFixture > > for this purpose. It can be maintained opaquely as internals change without > > affecting its consumers. > > > > The main problem is that the patch bring a new functionality to a stable > > branch (oslo.service rocky) but this patch help to fix the nova issue. > > > > Also openstack proposal bot submit a patch to requirements on stable rocky > > to update the oslo.service version with the latest version (1.31.6) but if > > we'll use it we'll then break the CI > > https://review.openstack.org/#/c/618834/ since the oslo service 1.31.6 is > > incompatible with novas stable rocky unittest due to the threading changes. > > > > # Questions and proposed solutions > > > > This thread try to summarize the current situation. > > > > We need to find how to be able to proceed, so this thread aim to allow to > > discuss between team to find the best way to fix. > > > > 1. Do we need to continue to try to backport fixture on oslo.service to fix > > the CI problem (https://review.openstack.org/#/c/617989/) ? > > > > 2. Do we need to find an another approach like mocking > > oslo.service.loopingcall._Event.wait in nova instead of mocking > > oslo_service.loopingcall._ThreadingEvent.wait (example: > > https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py) > > ? > > This is only a fix on the nova side and it allows us to update oslo.service > > requirements and allows us to fix the high CPU usage issue. I've submit > > this patch (https://review.openstack.org/619246) who implement the > > description above. > > > > Personaly I think we need to find an another approach like the mocking > > remplacement (c.f 2). > > > > We need to decide which way we use and to discuss about other solutions. > > > > -- > > Hervé Beraud > > Senior Software Engineer > > Red Hat - Openstack Oslo > > irc: hberaud > > -----BEGIN PGP SIGNATURE----- > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > v6rDpkeNksZ9fFSyoY2o > > =ECSj > > -----END PGP SIGNATURE----- > > Thank you for summarizing this issue, Hervé, and for working on the > patches we need. > > I think I would be happy with either solution. Using clean backports > seems less risky, and even though we are adding a new feature to > oslo.service it's only a unit test fixture. On the other hand if we want > to be very strict about not adding features in stable branches and we > are OK with creating a change to nova's unit tests that is not > backported from master, then that works for me, too. it should be noted this is not just a blocker for the nova ci if we dont fix the unit test it will break ditrobution that run the unitest as part of there packaging of nova downstream. i would prefer to backport the fixture personally and do a clean backport of the nova patches also rather then a stable only patch. while thecnically a feature i dont really consider a test fixture to be a feature in the normal sense and it is relitivly small and self contained. > > I have a slight preference for the first proposal, but not strong enough > to vote fight for it if the majority decides to go with the second > option. > From cdent+os at anticdent.org Wed Nov 21 15:15:00 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Wed, 21 Nov 2018 15:15:00 +0000 (GMT) Subject: [infra] [zuul] [placement] Minimizing size/time of test node In-Reply-To: <17b9e12f947973ae8e7c363209373294dfe620f7.camel@redhat.com> References: <17b9e12f947973ae8e7c363209373294dfe620f7.camel@redhat.com> Message-ID: On Wed, 21 Nov 2018, Sean Mooney wrote: > On Wed, 2018-11-21 at 12:59 +0000, Chris Dent wrote: >> I have a work in progress to run a little job in placement that >> gathers very simple performance numbers on some queries. This is >> being done as a sort of sanity check. As with many such things it is >> a bit rough around the edges and I'd like to make it smoother in a >> variety of ways. >> >> The WIP is at https://review.openstack.org/#/c/602484/ >> >> One of the ways I'd like to change it is to not rely on devstack. I >> need only mysql, uwsgi, python and the current revision of placement >> on the node. The current job uses devstack-minimal as its base but >> that's overkill and slow. > out of interest if you did devstack-minimal then set disable-all-services > or whatever the macro is and then just enabled mariadb and placement service > would there be much of a delta in job time? That's what the WIP is pretty much doing (now), except that it includes keystone (as lib/placement expects it). It's not super slow, but nor is it super fast, and it seems wasteful for something as tiny as this to not be super fast. I have a followup in progress which is uses the "base" job, but it is taking some time to get right. P.S. Can we make the default reply-to for the new list be the list? This is one of several areas where I disagree with jwz. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From hberaud at redhat.com Wed Nov 21 15:28:21 2018 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 21 Nov 2018 16:28:21 +0100 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: References: Message-ID: I agree this is not a feature in the normal sense. Fixture is isolated from the rest and doesn't affecting the oslo.service consumers. I have a slight preference for the second solution but I've no problems to use the first proposed solution (backport). Le mer. 21 nov. 2018 à 16:02, Sean Mooney a écrit : > On Wed, 2018-11-21 at 09:57 -0500, Doug Hellmann wrote: > > Herve Beraud writes: > > > > > Hey all! > > > > > > Here is a thread to coordinate all the teams (oslo, nova, stable, > > > requirements) working on the update of the oslo.service constraint in > the > > > Rocky requirements. > > > > > > # Summary > > > > > > Usage of threading event with eventlet caused inefficient code (causing > > > many useless system calls and high CPU usage). > > > This issue was already fixed on oslo.service master and we also want > to fix > > > it in stable/rocky. > > > > > > Our main issue is how to fix the high CPU usage on stable/rocky without > > > break the nova CI. > > > > > > Indeed, we already have backported the eventlet related fix to > oslo.service > > > but this fix requires also a nova update to avoid nova CI errors due to > > > threading removal on oslo.service that introduce the nova CI errors. > > > > > > A fix was proposed and merged on oslo.service master to introduce a new > > > feature (fixture) that avoid the nova CI errors, but > > > backporting the master fix to Rocky introduces a new feature into a > stable > > > branch so this is also an issue. > > > > > > So we need to discuss with all the teams to find a proper solution. > > > > > > # History > > > > > > A few weeks ago this issue was opened on oslo.service ( > > > https://bugs.launchpad.net/oslo.service/+bug/1798774) and it was > fixed by > > > this submited patch on the master branch ( > > > https://review.openstack.org/#/c/611807/ ). > > > > > > This change use the proper event primitive to fix the performance > issue. > > > > > > A new version of oslo.service was released (1.32.1) > > > > > > Since these changes was introduced into oslo.service master, nova > facing > > > some issues into the master CI process, due to the threading changes, > and > > > they was fixed by these patches ( > https://review.openstack.org/#/c/615724/, > > > https://review.openstack.org/#/c/617989/ ) into master. > > > > > > Few weeks ago I have backport to oslo.service some changes ( > > > https://review.openstack.org/#/c/614489/ ) from master to > stable/rocky to > > > also fix the problem in the rocky release. > > > > > > When this backport was merged we have created a new release of > oslo.service > > > (1.31.6) ( https://review.openstack.org/#/c/616505/ ) (stable/rocky > > > version). > > > > > > Then the openstack proposal bot submit a patch to requirements on > stable > > > rocky to update the oslo.service version with the latest version > (1.31.6) > > > but if we'll use it we'll then break the CI > > > https://review.openstack.org/#/c/618834/ so this patch is currently > blocked > > > to avoid nova CI error. > > > > > > # Issue > > > > > > Since the oslo.services threading changes were backported to rocky we > risk > > > to faces the same issues inside the nova rocky CI if we update the > > > requirements. > > > > > > In parallel in oslo.service we have started to backport a new patch who > > > introduces fixture ( https://review.openstack.org/#/c/617989/ ) from > > > master to rocky, and also we start to backport on nova rocky branch ( > > > https://review.openstack.org/619019, > https://review.openstack.org/619022 ) > > > patches who use oslo.service.fixture and who solve the nova CI issue. > The > > > patch on oslo.service exposes a public > oslo_service.fixture.SleepFixture > > > for this purpose. It can be maintained opaquely as internals change > without > > > affecting its consumers. > > > > > > The main problem is that the patch bring a new functionality to a > stable > > > branch (oslo.service rocky) but this patch help to fix the nova issue. > > > > > > Also openstack proposal bot submit a patch to requirements on stable > rocky > > > to update the oslo.service version with the latest version (1.31.6) > but if > > > we'll use it we'll then break the CI > > > https://review.openstack.org/#/c/618834/ since the oslo service > 1.31.6 is > > > incompatible with novas stable rocky unittest due to the threading > changes. > > > > > > # Questions and proposed solutions > > > > > > This thread try to summarize the current situation. > > > > > > We need to find how to be able to proceed, so this thread aim to allow > to > > > discuss between team to find the best way to fix. > > > > > > 1. Do we need to continue to try to backport fixture on oslo.service > to fix > > > the CI problem (https://review.openstack.org/#/c/617989/) ? > > > > > > 2. Do we need to find an another approach like mocking > > > oslo.service.loopingcall._Event.wait in nova instead of mocking > > > oslo_service.loopingcall._ThreadingEvent.wait (example: > > > > https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py > ) > > > ? > > > This is only a fix on the nova side and it allows us to update > oslo.service > > > requirements and allows us to fix the high CPU usage issue. I've submit > > > this patch (https://review.openstack.org/619246) who implement the > > > description above. > > > > > > Personaly I think we need to find an another approach like the mocking > > > remplacement (c.f 2). > > > > > > We need to decide which way we use and to discuss about other > solutions. > > > > > > -- > > > Hervé Beraud > > > Senior Software Engineer > > > Red Hat - Openstack Oslo > > > irc: hberaud > > > -----BEGIN PGP SIGNATURE----- > > > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > > v6rDpkeNksZ9fFSyoY2o > > > =ECSj > > > -----END PGP SIGNATURE----- > > > > Thank you for summarizing this issue, Hervé, and for working on the > > patches we need. > > > > I think I would be happy with either solution. Using clean backports > > seems less risky, and even though we are adding a new feature to > > oslo.service it's only a unit test fixture. On the other hand if we want > > to be very strict about not adding features in stable branches and we > > are OK with creating a change to nova's unit tests that is not > > backported from master, then that works for me, too. > > it should be noted this is not just a blocker for the nova ci > if we dont fix the unit test it will break ditrobution that run > the unitest as part of there packaging of nova downstream. > i would prefer to backport the fixture personally and do a clean backport > of the nova patches > also rather then a stable only patch. while thecnically a feature i dont > really consider a > test fixture to be a feature in the normal sense and it is relitivly small > and self contained. > > > > I have a slight preference for the first proposal, but not strong enough > > to vote fight for it if the majority decides to go with the second > > option. > > > -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Wed Nov 21 15:41:08 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 21 Nov 2018 15:41:08 +0000 Subject: [infra] ML configuration (was: Minimizing size/time of test node) In-Reply-To: References: <17b9e12f947973ae8e7c363209373294dfe620f7.camel@redhat.com> Message-ID: <20181121154108.r42jyiit35tlrqtb@yuggoth.org> On 2018-11-21 15:15:00 +0000 (+0000), Chris Dent wrote: [...] > Can we make the default reply-to for the new list be the list? > This is one of several areas where I disagree with jwz. We discussed it a bit on Monday and concluded that it was better to endure a few weeks of people's replies going to the old lists for messages which came from there through the new list, rather than enact a change in behavior for the new list just after people had started to settle into it. Problem with Reply-To is that you are stuck deciding whether to override the author's Reply-To (if provided) or inconsistently add one for the ML when the author didn't have one. Most modern E-mail clients have a reply-to-list option you can use when replying on mailing lists which include proper RFC 2369 List-* headers (though I too will admit I forget which one to hit sometimes when I'm not paying attention). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From morgan.fainberg at gmail.com Wed Nov 21 15:52:19 2018 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Wed, 21 Nov 2018 07:52:19 -0800 Subject: [infra] ML configuration (was: Minimizing size/time of test node) In-Reply-To: <20181121154108.r42jyiit35tlrqtb@yuggoth.org> References: <17b9e12f947973ae8e7c363209373294dfe620f7.camel@redhat.com> <20181121154108.r42jyiit35tlrqtb@yuggoth.org> Message-ID: The issue is a few very popular web clients (maybe one that I use) and some mobile mail apps do not have clear implementations of this feature. Until we have an explicit reply-to, I have to modify every single email I am sending to openstack-discuss so it doesn't also send directly (in this case to you) to the sender as well as the OpenStack-Discuss list. Reply-to-all also doesn't solve this problem, as it (in this case) would add you and openstack-discuss. I agree with Chris on this point. However, as long as we're planning on fixing the reply-to bits for openstack-discuss I'll weather the transitional period. --Morgan On Wed, Nov 21, 2018 at 7:45 AM Jeremy Stanley wrote: > On 2018-11-21 15:15:00 +0000 (+0000), Chris Dent wrote: > [...] > > Can we make the default reply-to for the new list be the list? > > This is one of several areas where I disagree with jwz. > > We discussed it a bit on Monday and concluded that it was better to > endure a few weeks of people's replies going to the old lists for > messages which came from there through the new list, rather than > enact a change in behavior for the new list just after people had > started to settle into it. Problem with Reply-To is that you are > stuck deciding whether to override the author's Reply-To (if > provided) or inconsistently add one for the ML when the author > didn't have one. Most modern E-mail clients have a reply-to-list > option you can use when replying on mailing lists which include > proper RFC 2369 List-* headers (though I too will admit I forget > which one to hit sometimes when I'm not paying attention). > -- > Jeremy Stanley > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openstack at fried.cc Wed Nov 21 16:15:06 2018 From: openstack at fried.cc (Eric Fried) Date: Wed, 21 Nov 2018 10:15:06 -0600 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: References: Message-ID: <89a82d2d-c6df-e596-5514-451a3d04e269@fried.cc> I have no preference. For #1, the backports won't be perfectly clean, because the requirements files will have different versions of oslo.service in them. But that's no big deal. It's also more "work", but the patches are already proposed, so meh. For #2, the original objection [1] was that it's still mocking private things from a 3rd-party library. But that's not as big a deal for stable, which is less likely to yank the rug out. (You know, except for the backport that led to this issue...) -efried [1] https://review.openstack.org/#/c/615724/1/nova/tests/unit/compute/test_compute_mgr.py at 6440 On 11/21/18 09:28, Herve Beraud wrote: > I agree this is not a feature in the normal sense. > Fixture is isolated from the rest and doesn't affecting the oslo.service > consumers. > I have a slight preference for the second solution but I've no problems > to use the first proposed solution (backport). > > Le mer. 21 nov. 2018 à 16:02, Sean Mooney > a écrit : > > On Wed, 2018-11-21 at 09:57 -0500, Doug Hellmann wrote: > > Herve Beraud > writes: > > > > > Hey all! > > > > > > Here is a thread to coordinate all the teams (oslo, nova, stable, > > > requirements) working on the update of the oslo.service > constraint in the > > > Rocky requirements. > > > > > > # Summary > > > > > > Usage of threading event with eventlet caused inefficient code > (causing > > > many useless system calls and  high CPU usage). > > > This issue was already fixed on oslo.service master and we also > want to fix > > > it in stable/rocky. > > > > > > Our main issue is how to fix the high CPU usage on stable/rocky > without > > > break the nova CI. > > > > > > Indeed, we already have backported the eventlet related fix to > oslo.service > > > but this fix requires also a nova update to avoid nova CI errors > due to > > > threading removal on oslo.service that introduce the nova CI errors. > > > > > > A fix was proposed and merged on oslo.service master to > introduce a new > > > feature (fixture) that avoid the nova CI errors, but > > > backporting the master fix to Rocky introduces a new feature > into a stable > > > branch so this is also an issue. > > > > > > So we need to discuss with all the teams to find a proper solution. > > > > > > # History > > > > > > A few weeks ago this issue was opened on oslo.service ( > > > https://bugs.launchpad.net/oslo.service/+bug/1798774) and it was > fixed by > > > this submited patch on the master branch ( > > > https://review.openstack.org/#/c/611807/ ). > > > > > > This change use the proper event primitive to fix the > performance issue. > > > > > > A new version of oslo.service was released (1.32.1) > > > > > > Since these changes was introduced into oslo.service master, > nova facing > > > some issues into the master CI process, due to the threading > changes, and > > > they was fixed by these patches ( > https://review.openstack.org/#/c/615724/, > > > https://review.openstack.org/#/c/617989/ ) into master. > > > > > > Few weeks ago I have backport to oslo.service some changes ( > > > https://review.openstack.org/#/c/614489/ ) from master to > stable/rocky to > > > also fix the problem in the rocky release. > > > > > > When this backport was merged we have created a new release of > oslo.service > > > (1.31.6) ( https://review.openstack.org/#/c/616505/ ) (stable/rocky > > > version). > > > > > > Then the openstack proposal bot submit a patch to requirements > on stable > > > rocky to update the oslo.service version with the latest version > (1.31.6) > > > but if we'll use it we'll then break the CI > > > https://review.openstack.org/#/c/618834/ so this patch is > currently blocked > > > to avoid nova CI error. > > > > > > # Issue > > > > > > Since the oslo.services threading changes were backported to > rocky we risk > > > to  faces the same issues inside the nova rocky CI if we update the > > > requirements. > > > > > > In parallel in oslo.service we have started to backport a new > patch who > > > introduces fixture  ( https://review.openstack.org/#/c/617989/ ) > from > > > master to rocky, and also we start to backport on nova rocky > branch ( > > > https://review.openstack.org/619019, > https://review.openstack.org/619022 ) > > > patches who use oslo.service.fixture and who solve the nova CI > issue. The > > > patch on oslo.service exposes a public > oslo_service.fixture.SleepFixture > > > for this purpose. It can be maintained opaquely as internals > change without > > > affecting its consumers. > > > > > > The main problem is that the patch bring a new functionality to > a stable > > > branch (oslo.service rocky) but this patch help to fix the nova > issue. > > > > > > Also openstack proposal bot submit a patch to requirements on > stable rocky > > > to update the oslo.service version with the latest version > (1.31.6) but if > > > we'll use it we'll then break the CI > > > https://review.openstack.org/#/c/618834/ since the oslo service > 1.31.6 is > > > incompatible with novas stable rocky unittest due to the > threading changes. > > > > > > # Questions and proposed solutions > > > > > > This thread try to summarize the current situation. > > > > > > We need to find how to be able to proceed, so this thread aim to > allow to > > > discuss between team to find the best way to fix. > > > > > > 1. Do we need to continue to try to backport fixture on > oslo.service to fix > > > the CI problem (https://review.openstack.org/#/c/617989/) ? > > > > > > 2. Do we need to find an another approach like mocking > > > oslo.service.loopingcall._Event.wait in nova instead of mocking > > > oslo_service.loopingcall._ThreadingEvent.wait (example: > > > > https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py) > > > ? > > > This is only a fix on the nova side and it allows us to update > oslo.service > > > requirements and allows us to fix the high CPU usage issue. I've > submit > > > this patch (https://review.openstack.org/619246) who implement the > > > description above. > > > > > > Personaly I think we need to find an another approach like the > mocking > > > remplacement (c.f 2). > > > > > > We need to decide which way we use and to discuss about other > solutions. > > > > > > -- > > > Hervé Beraud > > > Senior Software Engineer > > > Red Hat - Openstack Oslo > > > irc: hberaud > > > -----BEGIN PGP SIGNATURE----- > > > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > > v6rDpkeNksZ9fFSyoY2o > > > =ECSj > > > -----END PGP SIGNATURE----- > > > > Thank you for summarizing this issue, Hervé, and for working on the > > patches we need. > > > > I think I would be happy with either solution. Using clean backports > > seems less risky, and even though we are adding a new feature to > > oslo.service it's only a unit test fixture. On the other hand if > we want > > to be very strict about not adding features in stable branches and we > > are OK with creating a change to nova's unit tests that is not > > backported from master, then that works for me, too. > > it should be noted this is not just a blocker for the nova ci > if we dont fix the unit test it will break ditrobution that run > the unitest as part of there packaging of nova downstream. > i would prefer to backport the fixture personally and do a clean > backport of the nova patches > also rather then a stable only patch. while thecnically a feature i > dont really consider a > test fixture to be a feature in the normal sense and it is relitivly > small and self contained. > > > > I have a slight preference for the first proposal, but not strong > enough > > to vote fight for it if the majority decides to go with the second > > option. > > > > > > -- > Hervé Beraud > Senior Software Engineer > Red Hat - Openstack Oslo > irc: hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > From jimmy at openstack.org Wed Nov 21 16:53:54 2018 From: jimmy at openstack.org (Jimmy McArthur) Date: Wed, 21 Nov 2018 10:53:54 -0600 Subject: OpenStack Summit Berlin Presentation Videos & Slides In-Reply-To: <9e0517e1-149c-9234-5f25-23439dd352e8@orange.com> References: <5BF440C4.4040801@openstack.org> <9e0517e1-149c-9234-5f25-23439dd352e8@orange.com> Message-ID: <5BF58DA2.9080606@openstack.org> Hi Thomas- Thanks for your question. The extended timeframe is due to constraints with onsite network bandwidth at the Berlin conference center. This has required we ship drives to the US for editing and upload (different from recent Summits). Mid December is the latest we anticipate; however, we are trying to get them up as soon as possible. We will follow up on this email thread as soon as they are live. Please let us know if you have any further questions. Cheers, Jimmy > Thomas Morin > November 21, 2018 at 3:57 AM > Hi Jimmy, > > > > During previous summits, it was great to have the video available > shortly after the summit (sometimes as shortly as the same day). > That allowed to catch up sessions one could not attend, or suggests > interesting sessions to colleagues that could not attend. > "Strike while the iron is hot", this kind of things :) > > Perhaps we just got used too much to this form of luxury :) > So I don't want to ask for the impossible for the summit team, which > did a wonderful job, but I'm curious: is it possible to have an idea > why this can't be the case this time ? > > Thanks, > > -Thomas > > > > Jimmy McArthur > November 20, 2018 at 11:13 AM > Thank you to everyone for a great OpenStack Summit last week in > Berlin! As you know, there were hundreds of breakout sessions to catch > last week. Videos from the keynote sessions are currently available > here [1], and our team is working to get the other breakout session > videos loaded as quickly as possible. We're currently expecting all > videos to be posted by mid-December, and if we get them up sooner, > I'll update this thread. > > In the meantime, you can watch the keynotes videos [2] and watch this > page [3] for updates. Please also note that we sent out a link to all > presenters to upload their slides. As they are uploaded, they can be > found on the details page for each presentation on the Berlin Summit > Schedule [3] (along with videos, as they are processed). > > Cheers, > Jimmy > > > [1] https://www.openstack.org/videos/summits/berlin-2018 > [2] https://www.openstack.org/videos/ > [3] https://www.openstack.org/summit/berlin-2018/summit-schedule/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabarren at gmail.com Wed Nov 21 17:07:40 2018 From: dabarren at gmail.com (Eduardo Gonzalez) Date: Wed, 21 Nov 2018 18:07:40 +0100 Subject: [openstack-dev] [kolla] Berlin summit resume Message-ID: Hi kollagues, During the Berlin Summit kolla team had a few talks and forum discussions, as well as other cross-project related topics [0] First session was ``Kolla project onboarding``, the room was full of people interested in contribute to kolla, many of them already using kolla in production environments whiling to make upstream some work they've done downstream. I can say this talk was a total success and we hope to see many new faces during this release putting features and bug fixes into kolla. Slides of the session at [1] Second session was ``Kolla project update``, was a brief resume of what work has been done during rocky release and some items will be implemented in the future. Number of attendees to this session was massive, no more people could enter the room. Slides at [2] Then forum sessions.. First one was ``Kolla user feedback``, many users came over the room. We've notice a big increase in production deployments and some PoC migrating to production soon, many of those environments are huge. Overall the impressions was that kolla is great and don't have any big issue or requirement, ``it works great`` became a common phrase to listen. Here's a resume of the user feedback needs [3] - Improve operational usage for add, remove, change and stop/start nodes and services. - Database backup and recovery - Lack of documentation is the bigger request, users need to read the code to know how to configure other than core/default services - Multi cells_v2 - New services request, cyborg, masakari and tricircle were the most requested - SElinux enabled - More SDN services such as Contrail and calico - Possibility to include user's ansible tasks during deploy as well as support custom config.json - HTTPS for internal networks Second one was about ``kolla for the edge``, we've meet with Edge computing group and others interested in edge deployments to identify what's missing in kolla and where we can help. Things we've identified are: - Kolla seems good at how the service split can be done, tweaking inventory file and config values can deploy independent environments easily. - Missing keystone federation - Glance cache support is not a hard requirement but improves efficiency (already merged) - Multi cells v2 - Multi storage per edge/far-edge - A documentation or architecture reference would be nice to have. Last one was ``kolla for NFV``, few people came over to discuss about NUMA, GPU, SRIOV. Nothing noticiable from this session, mainly was support DPDK for CentOS/RHEL,OracleLinux and few service addition covered by previous discussions. [0] https://etherpad.openstack.org/p/kolla-stein-summit [1] https://es.slideshare.net/EduardoGonzalezGutie/kolla-project-onboarding-openstack-summit-berlin-2018 [2] https://es.slideshare.net/EduardoGonzalezGutie/openstack-kolla-project-update-rocky-release [3] https://etherpad.openstack.org/p/berlin-2018-kolla-user-feedback [4] https://etherpad.openstack.org/p/berlin-2018-kolla-edge [5] https://etherpad.openstack.org/p/berlin-2018-kolla-nfv -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From dabarren at gmail.com Wed Nov 21 17:07:40 2018 From: dabarren at gmail.com (Eduardo Gonzalez) Date: Wed, 21 Nov 2018 18:07:40 +0100 Subject: [Openstack-operators] [kolla] Berlin summit resume Message-ID: Hi kollagues, During the Berlin Summit kolla team had a few talks and forum discussions, as well as other cross-project related topics [0] First session was ``Kolla project onboarding``, the room was full of people interested in contribute to kolla, many of them already using kolla in production environments whiling to make upstream some work they've done downstream. I can say this talk was a total success and we hope to see many new faces during this release putting features and bug fixes into kolla. Slides of the session at [1] Second session was ``Kolla project update``, was a brief resume of what work has been done during rocky release and some items will be implemented in the future. Number of attendees to this session was massive, no more people could enter the room. Slides at [2] Then forum sessions.. First one was ``Kolla user feedback``, many users came over the room. We've notice a big increase in production deployments and some PoC migrating to production soon, many of those environments are huge. Overall the impressions was that kolla is great and don't have any big issue or requirement, ``it works great`` became a common phrase to listen. Here's a resume of the user feedback needs [3] - Improve operational usage for add, remove, change and stop/start nodes and services. - Database backup and recovery - Lack of documentation is the bigger request, users need to read the code to know how to configure other than core/default services - Multi cells_v2 - New services request, cyborg, masakari and tricircle were the most requested - SElinux enabled - More SDN services such as Contrail and calico - Possibility to include user's ansible tasks during deploy as well as support custom config.json - HTTPS for internal networks Second one was about ``kolla for the edge``, we've meet with Edge computing group and others interested in edge deployments to identify what's missing in kolla and where we can help. Things we've identified are: - Kolla seems good at how the service split can be done, tweaking inventory file and config values can deploy independent environments easily. - Missing keystone federation - Glance cache support is not a hard requirement but improves efficiency (already merged) - Multi cells v2 - Multi storage per edge/far-edge - A documentation or architecture reference would be nice to have. Last one was ``kolla for NFV``, few people came over to discuss about NUMA, GPU, SRIOV. Nothing noticiable from this session, mainly was support DPDK for CentOS/RHEL,OracleLinux and few service addition covered by previous discussions. [0] https://etherpad.openstack.org/p/kolla-stein-summit [1] https://es.slideshare.net/EduardoGonzalezGutie/kolla-project-onboarding-openstack-summit-berlin-2018 [2] https://es.slideshare.net/EduardoGonzalezGutie/openstack-kolla-project-update-rocky-release [3] https://etherpad.openstack.org/p/berlin-2018-kolla-user-feedback [4] https://etherpad.openstack.org/p/berlin-2018-kolla-edge [5] https://etherpad.openstack.org/p/berlin-2018-kolla-nfv -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From fungi at yuggoth.org Wed Nov 21 17:11:39 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 21 Nov 2018 17:11:39 +0000 Subject: [infra] ML configuration (was: Minimizing size/time of test node) In-Reply-To: References: <17b9e12f947973ae8e7c363209373294dfe620f7.camel@redhat.com> <20181121154108.r42jyiit35tlrqtb@yuggoth.org> Message-ID: <20181121171139.d26bniohymkbzl24@yuggoth.org> On 2018-11-21 07:52:19 -0800 (-0800), Morgan Fainberg wrote: > The issue is a few very popular web clients (maybe one that I use) > and some mobile mail apps do not have clear implementations of > this feature. Until we have an explicit reply-to, I have to modify > every single email I am sending to openstack-discuss so it doesn't > also send directly (in this case to you) to the sender as well as > the OpenStack-Discuss list. Yes, if RFC 2369 parsing support is lacking, it's a good opportunity to encourage those services to add it. The client in question also seems to encourage you to top-post, not trim quoted material, and include an unnecessary HTML copy (thankfully it doesn't seem to call remote sites so they can track anyone who reads it without appropriate precautions in their browser). Doesn't seem to me to be a particularly effective platform for participating in technical mailing lists. > Reply-to-all also doesn't solve this problem, as it (in this case) > would add you and openstack-discuss. I agree with Chris on this > point. However, as long as we're planning on fixing the reply-to > bits for openstack-discuss I'll weather the transitional period. [...] Well, I'm not sure what plan you're thinking is going to "fix" this. We need to avoid adding/modifying Reply-To headers as they are likely to be covered in DKIM signatures. I haven't performed a comprehensive analysis of DKIM-Signature headers found in our archives to determine how many (if any) include Reply-To in their "h" list, but I find plenty of examples on the Internet of MTA configurations doing that so I expect it's a relatively common choice. Also, note that this is a behavior change from the openstack-dev and openstack-sigs MLs (they had reply_goes_to_list=1 set) but not for the openstack and openstack-operators MLs (where it was already reply_goes_to_list=0 instead). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From hongbin034 at gmail.com Wed Nov 21 15:44:05 2018 From: hongbin034 at gmail.com (Hongbin Lu) Date: Wed, 21 Nov 2018 10:44:05 -0500 Subject: [openstack-dev] [zun] Failed to create Container In-Reply-To: References: Message-ID: Rania, For question #1, you can do the followings in *each compute node*: * In your kuryr config file (i.e. /etc/kuryr/kuryr.conf), change the config [DEFAULT]kuryr_uri . For example: [DEFAULT] kuryr_uri = http://192.168.1.10:23750 This config decides the IP address and port that the kuryr-libnetwork process will listen to. By default, it listens to localhost which should be good enough for most of the cases. Therefore, change it only if it is necessary. * In the file: /usr/lib/docker/plugins/kuryr/kuryr.spec , change the URL so that docker will know how to connect to kuryr-libnetwork. The value must match the kuryr_uri config above. Again, change it only if it is necessary. Then, restart the docker and kuryr-libnetwork process. Let me know if it still doesn't work for you. For question #2, I remembered all processes are running in systemd, so you can retrieve logs by using journalctl. For example: $ journalctl -u kuryr-libnetwork > kuryr.log $ journalctl -u zun-compute > zun-compute.log $ journalctl -u zun-api > zun-api.log Best regards, Hongbin On Tue, Nov 20, 2018 at 9:01 PM Rania Adouni wrote: > Hi Hongbin , > thanks for your advice I did fix it with changing the kuryr-lib to 0.6.0 > and my service just work fine and also with lsof -iTCP -sTCP:LISTEN -P > > I can see it in the list : > *kuryr-ser 16581 root 5u IPv4 91929 0t0 TCP > localhost:23750 (LISTEN)* ------------> that is great. > > + but I have two questions : > 1- How I can change the localhost to my compute address ( > 192.168.1.10:23750) because it is still the same error when trying to > create container " Docker internal error: 500 Server Error: Internal > Server Error ("legacy plugin: Post > http://192.168.1.10:23750/Plugin.Activate: dial tcp 192.168.1.10:23750: > connect: connection refused"). ? > > 2- my other question is about the log of zun why I can find it under > my directory /var/log ? > > Best Regards, > Rania Adouni > > > Le mer. 21 nov. 2018 à 02:34, Rania Adouni a > écrit : > >> Hi Hongbin, >> Yes the version of kuryr-lib is :0.8.0 , So I think I should remove it ! >> I should remove only the kuryr-lib ! if you have some command they can >> help me to unisntall it , it will be nice to provide it . >> >> Best Regards, >> Rania >> >> >> Le mer. 21 nov. 2018 à 02:27, Hongbin Lu a écrit : >> >>> Hi Rania, >>> >>> The config option 'driver' was recently renamed, so I guess the problem >>> is the version of kuryr-lib is not right. The Pike release of Zun is >>> matched to kuryr-lib 0.6.0 so you might want to confirm the version of >>> kuryr-lib. >>> >>> $ sudo pip freeze | grep kuryr >>> >>> If the version is not right, uninstall and re-install the kuryr-lib, >>> then restart kuryr-libnetwork. Let me know if it still doesn't work. >>> >>> Best regards, >>> Hongbin >>> >>> On Tue, Nov 20, 2018 at 8:01 PM Rania Adouni >>> wrote: >>> >>>> hi , >>>> Thanks for your reply and yes the problem that kuryr-libnetwork is >>>> failed to start with the error : >>>> ● kuryr-libnetwork.service - Kuryr-libnetwork - Docker network plugin >>>> for Neutron >>>> Loaded: loaded (/etc/systemd/system/kuryr-libnetwork.service; >>>> enabled; vendor preset: enabled) >>>> Active: failed (Result: exit-code) since mer. 2018-11-21 01:48:48 >>>> CET; 287ms ago >>>> Process: 13974 ExecStart=/usr/local/bin/kuryr-server --config-file >>>> /etc/kuryr/kuryr.conf (code=exited, status=1/FAILURE) >>>> Main PID: 13974 (code=exited, status=1/FAILURE) >>>> >>>> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >>>> 13974 ERROR kuryr value = self._do_get(name, group, namespace) >>>> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >>>> 13974 ERROR kuryr File >>>> "/usr/lib/python2.7/dist-packages/oslo_config/cfg.py", line 2942, in _ >>>> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >>>> 13974 ERROR kuryr info = self._get_opt_info(name, group) >>>> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >>>> 13974 ERROR kuryr File >>>> "/usr/lib/python2.7/dist-packages/oslo_config/cfg.py", line 3099, in _ >>>> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >>>> 13974 ERROR kuryr raise NoSuchOptError(opt_name, group) >>>> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >>>> 13974 ERROR kuryr NoSuchOptError: no such option driver in group [binding] >>>> nov. 21 01:48:48 compute kuryr-server[13974]: 2018-11-21 01:48:48.542 >>>> 13974 ERROR kuryr >>>> nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Main >>>> process exited, code=exited, status=1/FAILURE >>>> nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Unit >>>> entered failed state. >>>> nov. 21 01:48:48 compute systemd[1]: kuryr-libnetwork.service: Failed >>>> with result 'exit-code'. >>>> >>>> >>>> and also the command lsof -iTCP -sTCP:LISTEN -P doesn't show the kuryr >>>> service : >>>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >>>> dockerd 1144 root 5u IPv4 20120 0t0 TCP >>>> compute:2375 (LISTEN) >>>> sshd 1288 root 3u IPv4 19532 0t0 TCP *:22 >>>> (LISTEN) >>>> sshd 1288 root 4u IPv6 19534 0t0 TCP *:22 >>>> (LISTEN) >>>> dnsmasq 1961 nobody 6u IPv4 23450 0t0 TCP >>>> 192.168.122.1:53 (LISTEN) >>>> sshd 4163 adouni 9u IPv6 34950 0t0 TCP >>>> localhost:6010 (LISTEN) >>>> sshd 4163 adouni 10u IPv4 34951 0t0 TCP >>>> localhost:6010 (LISTEN) >>>> qemu-syst 4621 libvirt-qemu 18u IPv4 37121 0t0 TCP *:5900 >>>> (LISTEN) >>>> >>>> !!! >>>> >>>> >>>> Le mer. 21 nov. 2018 à 01:45, Jacob Burckhardt < >>>> jburckhardt at pdvwireless.com> a écrit : >>>> >>>>> Your error message says it cannot connect to port 23750. That's the >>>>> kuryr-libnetwork default listen port. On 192.168.1.10, run: >>>>> >>>>> >>>>> >>>>> lsof -iTCP -sTCP:LISTEN -P >>>>> >>>>> >>>>> >>>>> On my compute node, it outputs: >>>>> >>>>> >>>>> >>>>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >>>>> >>>>> … >>>>> >>>>> kuryr-ser 1976 root 6u IPv4 30896 0t0 TCP >>>>> localhost:23750 (LISTEN) >>>>> >>>>> >>>>> >>>>> So, you can see that kuryr is listening on 23750. If lsof does not >>>>> list a process listening on 23750, then check if kuryr is up by running: >>>>> >>>>> >>>>> >>>>> systemctl status kuryr-libnetwork >>>>> >>>>> >>>>> >>>>> You can also try restarting it by running: >>>>> >>>>> >>>>> >>>>> systemctl restart kuryr-libnetwork >>>>> >>>>> >>>>> >>>>> I installed that service by following: >>>>> >>>>> >>>>> >>>>> >>>>> https://docs.openstack.org/kuryr-libnetwork/queens/install/compute-install-ubuntu.html >>>>> >>>>> >>>>> >>>>> That is the queens install guide which might help you since zun has no >>>>> install guide in pike. >>>>> >>>>> >>>>> >>>>> If you see it listening, you can try this command: >>>>> >>>>> >>>>> >>>>> telnet 192.168.1.10 23750 >>>>> >>>>> >>>>> >>>>> If it fails to connect, then try: >>>>> >>>>> >>>>> >>>>> telnet localhost 23750 >>>>> >>>>> >>>>> >>>>> If it works with localhost but not 192.168.1.10, then I think that >>>>> means you need to tell docker to connect to localhost instead of >>>>> 192.168.1.10. >>>>> >>>>> >>>>> >>>>> Can you get the commands at the following web page to succeed? >>>>> >>>>> >>>>> >>>>> https://docs.openstack.org/kuryr-libnetwork/queens/install/verify.html >>>>> >>>>> >>>>> >>>>> *Jacob Burckhardt* >>>>> >>>>> Senior Software Engineer >>>>> >>>>> [image: pdvWireless] >>>>> >>>>> >>>>> >>>>> *From:* Rania Adouni >>>>> *Sent:* Tuesday, November 20, 2018 2:02 PM >>>>> *To:* openstack-dev at lists.openstack.org >>>>> *Subject:* [openstack-dev] [zun] Failed to create Container >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Hi , >>>>> >>>>> >>>>> >>>>> I am starting to use zun on openstack pike , and when I try to lunch >>>>> container with cirros image , I get this reason : Docker internal >>>>> error: 500 Server Error: Internal Server Error ("legacy plugin: Post >>>>> http://192.168.1.10:23750/Plugin.Activate: dial tcp 192.168.1.10:23750: >>>>> connect: connection refused"). >>>>> >>>>> you can find here the log on my compute node : >>>>> https://pastebin.com/nZTiTZiV. >>>>> >>>>> some help with this will be great . >>>>> >>>>> Best Regards, >>>>> >>>>> Rania Adouni >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From hongbin034 at gmail.com Wed Nov 21 15:46:20 2018 From: hongbin034 at gmail.com (Hongbin Lu) Date: Wed, 21 Nov 2018 10:46:20 -0500 Subject: [openstack-dev] [ZUN] [kuryr-libnetwork] In-Reply-To: References: Message-ID: Hi Rania, See if this helps: http://lists.openstack.org/pipermail/openstack-dev/2018-November/136547.html Best regards, Hongbin On Wed, Nov 21, 2018 at 7:27 AM Rania Adouni wrote: > Hi everyone, > > I was trying to create container but I just ended up by this error : > *Docker internal error: 500 Server Error: Internal Server Error ("failed > to update store for object type *libnetwork.endpointCnt: dial tcp > 192.168.1.20:2379 : connect: connection > refused").* > > Then I back to Verify operation of the kuryr-libnetwork, if it work fine > or not with command : > *docker network create --driver kuryr --ipam-driver kuryr --subnet > 10.10.0.0/16 --gateway=10.10.0.1 test_net * > > But i get this error : > *Error response from daemon: failed to update store for object type > *libnetwork.endpointCnt: dial tcp 192.168.1.20:2379 > : connect: connection refused * > *Ps: 192.168.1.20 is the address of my controller Node !!* > > some help will be nice and thanks . > > Best Regards, > Rania Adouni > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From dabarren at gmail.com Wed Nov 21 17:07:40 2018 From: dabarren at gmail.com (Eduardo Gonzalez) Date: Wed, 21 Nov 2018 18:07:40 +0100 Subject: [Openstack] [kolla] Berlin summit resume Message-ID: Hi kollagues, During the Berlin Summit kolla team had a few talks and forum discussions, as well as other cross-project related topics [0] First session was ``Kolla project onboarding``, the room was full of people interested in contribute to kolla, many of them already using kolla in production environments whiling to make upstream some work they've done downstream. I can say this talk was a total success and we hope to see many new faces during this release putting features and bug fixes into kolla. Slides of the session at [1] Second session was ``Kolla project update``, was a brief resume of what work has been done during rocky release and some items will be implemented in the future. Number of attendees to this session was massive, no more people could enter the room. Slides at [2] Then forum sessions.. First one was ``Kolla user feedback``, many users came over the room. We've notice a big increase in production deployments and some PoC migrating to production soon, many of those environments are huge. Overall the impressions was that kolla is great and don't have any big issue or requirement, ``it works great`` became a common phrase to listen. Here's a resume of the user feedback needs [3] - Improve operational usage for add, remove, change and stop/start nodes and services. - Database backup and recovery - Lack of documentation is the bigger request, users need to read the code to know how to configure other than core/default services - Multi cells_v2 - New services request, cyborg, masakari and tricircle were the most requested - SElinux enabled - More SDN services such as Contrail and calico - Possibility to include user's ansible tasks during deploy as well as support custom config.json - HTTPS for internal networks Second one was about ``kolla for the edge``, we've meet with Edge computing group and others interested in edge deployments to identify what's missing in kolla and where we can help. Things we've identified are: - Kolla seems good at how the service split can be done, tweaking inventory file and config values can deploy independent environments easily. - Missing keystone federation - Glance cache support is not a hard requirement but improves efficiency (already merged) - Multi cells v2 - Multi storage per edge/far-edge - A documentation or architecture reference would be nice to have. Last one was ``kolla for NFV``, few people came over to discuss about NUMA, GPU, SRIOV. Nothing noticiable from this session, mainly was support DPDK for CentOS/RHEL,OracleLinux and few service addition covered by previous discussions. [0] https://etherpad.openstack.org/p/kolla-stein-summit [1] https://es.slideshare.net/EduardoGonzalezGutie/kolla-project-onboarding-openstack-summit-berlin-2018 [2] https://es.slideshare.net/EduardoGonzalezGutie/openstack-kolla-project-update-rocky-release [3] https://etherpad.openstack.org/p/berlin-2018-kolla-user-feedback [4] https://etherpad.openstack.org/p/berlin-2018-kolla-edge [5] https://etherpad.openstack.org/p/berlin-2018-kolla-nfv -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From fungi at yuggoth.org Wed Nov 21 17:21:53 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 21 Nov 2018 17:21:53 +0000 Subject: Let's use [dev] for development discussions In-Reply-To: References: Message-ID: <20181121172153.xmfkhsl5fu6dubn5@yuggoth.org> On 2018-11-21 09:47:18 -0500 (-0500), Doug Hellmann wrote: > Thierry Carrez writes: [...] > > See (and add!) other common subject prefixes at: > > https://etherpad.openstack.org/p/common-openstack-ml-topics > > > > Thanks for your help in making this common list more navigable. > > Should we start moving this information into the project team guide? That was the plan, I just wanted to give people a little more time to add things they thought were relevant before we up the bar for additions to submitting them as code-reviewed changes. The Project Teams Guide seems like the most appropriate place for it (with a link added in the listserv's description text). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From miguel at mlavalle.com Wed Nov 21 17:28:03 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Wed, 21 Nov 2018 11:28:03 -0600 Subject: [openstack-dev] [neutron] [drivers] Cancelling weekly meeting on November 23rd Message-ID: Dear Neutron team, Due to the Thanksgiving Holiday in the USA, several members of the team will not be able to attend the weekly meeting. Let's cancel it and resume normally on the 30th of November Best regards Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From miguel at mlavalle.com Wed Nov 21 18:11:50 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Wed, 21 Nov 2018 12:11:50 -0600 Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack master Message-ID: Hi Stackers, One of the key goals of StarlingX during the current cycle is to converge with the OpenStack projects master branches. In order to accomplish this goal, the Technical Steering Committee put together a gap analysis that shows the specs and patches that need to merge in the different OpenStack projects by the end of Stein. The attached PDF document shows this analysis. Although other projects are involved, most of the work has to be done in Nova, Neutron and Horizon. Hopefully all the involved projects will help StarlingX achieve this important goal. It has to be noted that work is still on-going to refine this gap analysis, so there might be some updates to it in the near future. Best regards Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: stx_openstack_gaps.pdf Type: application/pdf Size: 152044 bytes Desc: not available URL: From mark at stackhpc.com Wed Nov 21 18:44:56 2018 From: mark at stackhpc.com (Mark Goddard) Date: Wed, 21 Nov 2018 18:44:56 +0000 Subject: [openstack-dev] [kolla] Berlin summit resume In-Reply-To: References: Message-ID: Thanks for the write up Eduardo. I thought you and Surya did a good job of presenting and moderating those sessions. Mark On Wed, 21 Nov 2018 at 17:08, Eduardo Gonzalez wrote: > Hi kollagues, > > During the Berlin Summit kolla team had a few talks and forum discussions, > as well as other cross-project related topics [0] > > First session was ``Kolla project onboarding``, the room was full of > people interested in contribute to kolla, many of them already using kolla > in production environments whiling to make upstream some work they've done > downstream. I can say this talk was a total success and we hope to see many > new faces during this release putting features and bug fixes into kolla. > Slides of the session at [1] > > Second session was ``Kolla project update``, was a brief resume of what > work has been done during rocky release and some items will be implemented > in the future. Number of attendees to this session was massive, no more > people could enter the room. Slides at [2] > > > Then forum sessions.. > > First one was ``Kolla user feedback``, many users came over the room. > We've notice a big increase in production deployments and some PoC > migrating to production soon, many of those environments are huge. > Overall the impressions was that kolla is great and don't have any big > issue or requirement, ``it works great`` became a common phrase to listen. > Here's a resume of the user feedback needs [3] > > - Improve operational usage for add, remove, change and stop/start nodes > and services. > - Database backup and recovery > - Lack of documentation is the bigger request, users need to read the code > to know how to configure other than core/default services > - Multi cells_v2 > - New services request, cyborg, masakari and tricircle were the most > requested > - SElinux enabled > - More SDN services such as Contrail and calico > - Possibility to include user's ansible tasks during deploy as well as > support custom config.json > - HTTPS for internal networks > > Second one was about ``kolla for the edge``, we've meet with Edge > computing group and others interested in edge deployments to identify > what's missing in kolla and where we can help. > Things we've identified are: > > - Kolla seems good at how the service split can be done, tweaking > inventory file and config values can deploy independent environments easily. > - Missing keystone federation > - Glance cache support is not a hard requirement but improves efficiency > (already merged) > - Multi cells v2 > - Multi storage per edge/far-edge > - A documentation or architecture reference would be nice to have. > > Last one was ``kolla for NFV``, few people came over to discuss about > NUMA, GPU, SRIOV. > Nothing noticiable from this session, mainly was support DPDK for > CentOS/RHEL,OracleLinux and few service addition covered by previous > discussions. > > [0] https://etherpad.openstack.org/p/kolla-stein-summit > [1] > https://es.slideshare.net/EduardoGonzalezGutie/kolla-project-onboarding-openstack-summit-berlin-2018 > [2] > https://es.slideshare.net/EduardoGonzalezGutie/openstack-kolla-project-update-rocky-release > [3] https://etherpad.openstack.org/p/berlin-2018-kolla-user-feedback > [4] https://etherpad.openstack.org/p/berlin-2018-kolla-edge > [5] https://etherpad.openstack.org/p/berlin-2018-kolla-nfv > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From mark at stackhpc.com Wed Nov 21 18:44:56 2018 From: mark at stackhpc.com (Mark Goddard) Date: Wed, 21 Nov 2018 18:44:56 +0000 Subject: [Openstack-operators] [openstack-dev] [kolla] Berlin summit resume In-Reply-To: References: Message-ID: Thanks for the write up Eduardo. I thought you and Surya did a good job of presenting and moderating those sessions. Mark On Wed, 21 Nov 2018 at 17:08, Eduardo Gonzalez wrote: > Hi kollagues, > > During the Berlin Summit kolla team had a few talks and forum discussions, > as well as other cross-project related topics [0] > > First session was ``Kolla project onboarding``, the room was full of > people interested in contribute to kolla, many of them already using kolla > in production environments whiling to make upstream some work they've done > downstream. I can say this talk was a total success and we hope to see many > new faces during this release putting features and bug fixes into kolla. > Slides of the session at [1] > > Second session was ``Kolla project update``, was a brief resume of what > work has been done during rocky release and some items will be implemented > in the future. Number of attendees to this session was massive, no more > people could enter the room. Slides at [2] > > > Then forum sessions.. > > First one was ``Kolla user feedback``, many users came over the room. > We've notice a big increase in production deployments and some PoC > migrating to production soon, many of those environments are huge. > Overall the impressions was that kolla is great and don't have any big > issue or requirement, ``it works great`` became a common phrase to listen. > Here's a resume of the user feedback needs [3] > > - Improve operational usage for add, remove, change and stop/start nodes > and services. > - Database backup and recovery > - Lack of documentation is the bigger request, users need to read the code > to know how to configure other than core/default services > - Multi cells_v2 > - New services request, cyborg, masakari and tricircle were the most > requested > - SElinux enabled > - More SDN services such as Contrail and calico > - Possibility to include user's ansible tasks during deploy as well as > support custom config.json > - HTTPS for internal networks > > Second one was about ``kolla for the edge``, we've meet with Edge > computing group and others interested in edge deployments to identify > what's missing in kolla and where we can help. > Things we've identified are: > > - Kolla seems good at how the service split can be done, tweaking > inventory file and config values can deploy independent environments easily. > - Missing keystone federation > - Glance cache support is not a hard requirement but improves efficiency > (already merged) > - Multi cells v2 > - Multi storage per edge/far-edge > - A documentation or architecture reference would be nice to have. > > Last one was ``kolla for NFV``, few people came over to discuss about > NUMA, GPU, SRIOV. > Nothing noticiable from this session, mainly was support DPDK for > CentOS/RHEL,OracleLinux and few service addition covered by previous > discussions. > > [0] https://etherpad.openstack.org/p/kolla-stein-summit > [1] > https://es.slideshare.net/EduardoGonzalezGutie/kolla-project-onboarding-openstack-summit-berlin-2018 > [2] > https://es.slideshare.net/EduardoGonzalezGutie/openstack-kolla-project-update-rocky-release > [3] https://etherpad.openstack.org/p/berlin-2018-kolla-user-feedback > [4] https://etherpad.openstack.org/p/berlin-2018-kolla-edge > [5] https://etherpad.openstack.org/p/berlin-2018-kolla-nfv > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From tpb at dyncloud.net Wed Nov 21 18:47:42 2018 From: tpb at dyncloud.net (Tom Barron) Date: Wed, 21 Nov 2018 13:47:42 -0500 Subject: [manila] no meeting this week Message-ID: <20181121184742.zyefgxpwptihl6b2@barron.net> Just a reminder that there will be no manila community meeting this week. Next manila meeting will be Thursday, 29 November, at 1500 UTC in #openstack-meeting-alt on freenode. Agenda here [1] - Feel free to add ... -- Tom Barron (tbarron) [1] https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting From doug at doughellmann.com Wed Nov 21 18:50:03 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 21 Nov 2018 13:50:03 -0500 Subject: Let's use [dev] for development discussions In-Reply-To: <20181121172153.xmfkhsl5fu6dubn5@yuggoth.org> References: <20181121172153.xmfkhsl5fu6dubn5@yuggoth.org> Message-ID: Jeremy Stanley writes: > On 2018-11-21 09:47:18 -0500 (-0500), Doug Hellmann wrote: >> Thierry Carrez writes: > [...] >> > See (and add!) other common subject prefixes at: >> > https://etherpad.openstack.org/p/common-openstack-ml-topics >> > >> > Thanks for your help in making this common list more navigable. >> >> Should we start moving this information into the project team guide? > > That was the plan, I just wanted to give people a little more time > to add things they thought were relevant before we up the bar for > additions to submitting them as code-reviewed changes. The Project > Teams Guide seems like the most appropriate place for it (with a > link added in the listserv's description text). > -- > Jeremy Stanley Sounds good. Feel free to add me as a reviewer to help land the patch. -- Doug From mark at stackhpc.com Wed Nov 21 18:44:56 2018 From: mark at stackhpc.com (Mark Goddard) Date: Wed, 21 Nov 2018 18:44:56 +0000 Subject: [Openstack] [openstack-dev] [kolla] Berlin summit resume In-Reply-To: References: Message-ID: Thanks for the write up Eduardo. I thought you and Surya did a good job of presenting and moderating those sessions. Mark On Wed, 21 Nov 2018 at 17:08, Eduardo Gonzalez wrote: > Hi kollagues, > > During the Berlin Summit kolla team had a few talks and forum discussions, > as well as other cross-project related topics [0] > > First session was ``Kolla project onboarding``, the room was full of > people interested in contribute to kolla, many of them already using kolla > in production environments whiling to make upstream some work they've done > downstream. I can say this talk was a total success and we hope to see many > new faces during this release putting features and bug fixes into kolla. > Slides of the session at [1] > > Second session was ``Kolla project update``, was a brief resume of what > work has been done during rocky release and some items will be implemented > in the future. Number of attendees to this session was massive, no more > people could enter the room. Slides at [2] > > > Then forum sessions.. > > First one was ``Kolla user feedback``, many users came over the room. > We've notice a big increase in production deployments and some PoC > migrating to production soon, many of those environments are huge. > Overall the impressions was that kolla is great and don't have any big > issue or requirement, ``it works great`` became a common phrase to listen. > Here's a resume of the user feedback needs [3] > > - Improve operational usage for add, remove, change and stop/start nodes > and services. > - Database backup and recovery > - Lack of documentation is the bigger request, users need to read the code > to know how to configure other than core/default services > - Multi cells_v2 > - New services request, cyborg, masakari and tricircle were the most > requested > - SElinux enabled > - More SDN services such as Contrail and calico > - Possibility to include user's ansible tasks during deploy as well as > support custom config.json > - HTTPS for internal networks > > Second one was about ``kolla for the edge``, we've meet with Edge > computing group and others interested in edge deployments to identify > what's missing in kolla and where we can help. > Things we've identified are: > > - Kolla seems good at how the service split can be done, tweaking > inventory file and config values can deploy independent environments easily. > - Missing keystone federation > - Glance cache support is not a hard requirement but improves efficiency > (already merged) > - Multi cells v2 > - Multi storage per edge/far-edge > - A documentation or architecture reference would be nice to have. > > Last one was ``kolla for NFV``, few people came over to discuss about > NUMA, GPU, SRIOV. > Nothing noticiable from this session, mainly was support DPDK for > CentOS/RHEL,OracleLinux and few service addition covered by previous > discussions. > > [0] https://etherpad.openstack.org/p/kolla-stein-summit > [1] > https://es.slideshare.net/EduardoGonzalezGutie/kolla-project-onboarding-openstack-summit-berlin-2018 > [2] > https://es.slideshare.net/EduardoGonzalezGutie/openstack-kolla-project-update-rocky-release > [3] https://etherpad.openstack.org/p/berlin-2018-kolla-user-feedback > [4] https://etherpad.openstack.org/p/berlin-2018-kolla-edge > [5] https://etherpad.openstack.org/p/berlin-2018-kolla-nfv > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From doug at doughellmann.com Wed Nov 21 19:31:43 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 21 Nov 2018 14:31:43 -0500 Subject: [tc][python3] next steps for resolution on tracking python 3 releases Message-ID: We currently have 3 changes up for review related to our python 3 testing plans. I think if we line them up in a series it will be clearer how they relate to each other and how we can move ahead with them as a set. I think first we need Zane's resolution [1], since that describes the process we want to use. We're dealing with some final wording questions there, but I think it's very close to ready as it is now. Next, we want Sean's patch that sets the versions we want tested for Stein [2]. Zane proposed that we should have goal champions designated in that change, so we could find someone to do that or we could go ahead and take it as-is and add that information later. Finally, we need a variation of Jeremy's patch that makes the PTI less detailed [3]. One update we could make there is to describe how to find (or link to) the information in the previous patch instead of using any specific versions at all. Thoughts? [1] https://review.openstack.org/#/c/613145/ [2] https://review.openstack.org/#/c/611080/ [3] https://review.openstack.org/#/c/611010/ -- Doug From eumel at arcor.de Wed Nov 21 19:36:03 2018 From: eumel at arcor.de (Frank Kloeker) Date: Wed, 21 Nov 2018 20:36:03 +0100 Subject: OpenStack Summit Berlin Presentation Videos & Slides In-Reply-To: <5BF58DA2.9080606@openstack.org> References: <5BF440C4.4040801@openstack.org> <9e0517e1-149c-9234-5f25-23439dd352e8@orange.com> <5BF58DA2.9080606@openstack.org> Message-ID: Sorry, Jimmy, that Internet thing is still Neuland for us. Frank Am 2018-11-21 17:53, schrieb Jimmy McArthur: > Hi Thomas- > > Thanks for your question. The extended timeframe is due to constraints > with onsite network bandwidth at the Berlin conference center. This > has required we ship drives to the US for editing and upload > (different from recent Summits). Mid December is the latest we > anticipate; however, we are trying to get them up as soon as possible. > > > We will follow up on this email thread as soon as they are live. > Please let us know if you have any further questions. > > Cheers, > Jimmy > >> Thomas Morin >> November 21, 2018 at 3:57 AM >> Hi Jimmy, >> >> During previous summits, it was great to have the video available >> shortly after the summit (sometimes as shortly as the same day). >> That allowed to catch up sessions one could not attend, or suggests >> interesting sessions to colleagues that could not attend. >> "Strike while the iron is hot", this kind of things :) >> >> Perhaps we just got used too much to this form of luxury :) >> So I don't want to ask for the impossible for the summit team, which >> did a wonderful job, but I'm curious: is it possible to have an idea >> why this can't be the case this time ? >> >> Thanks, >> >> -Thomas >> >> Jimmy McArthur >> November 20, 2018 at 11:13 AM >> Thank you to everyone for a great OpenStack Summit last week in >> Berlin! As you know, there were hundreds of breakout sessions to >> catch last week. Videos from the keynote sessions are currently >> available here [1], and our team is working to get the other >> breakout session videos loaded as quickly as possible. We're >> currently expecting all videos to be posted by mid-December, and if >> we get them up sooner, I'll update this thread. >> >> In the meantime, you can watch the keynotes videos [2] and watch >> this page [3] for updates. Please also note that we sent out a link >> to all presenters to upload their slides. As they are uploaded, they >> can be found on the details page for each presentation on the Berlin >> Summit Schedule [3] (along with videos, as they are processed). >> >> Cheers, >> Jimmy >> >> [1] https://www.openstack.org/videos/summits/berlin-2018 >> [2] https://www.openstack.org/videos/ >> [3] https://www.openstack.org/summit/berlin-2018/summit-schedule/ From zbitter at redhat.com Wed Nov 21 19:38:12 2018 From: zbitter at redhat.com (Zane Bitter) Date: Wed, 21 Nov 2018 14:38:12 -0500 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: References: Message-ID: <0f7e2d67-e899-66d7-295b-19c043c6a379@redhat.com> On 21/11/18 9:47 AM, Herve Beraud wrote: > # Questions and proposed solutions > > This thread try to summarize the current situation. > > We need to find how to be able to proceed, so this thread aim to allow > to discuss between team to find the best way to fix. > > 1. Do we need to continue to try to backport fixture on oslo.service to > fix the CI problem (https://review.openstack.org/#/c/617989/)? > > 2. Do we need to find an another approach like mocking > oslo.service.loopingcall._Event.wait in nova instead of mocking > oslo_service.loopingcall._ThreadingEvent.wait (example: > https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py)? 3. Doesn't this get solved if we add a line like: _ThreadingEvent = _Event in oslo.service on stable/rocky? That seems harmless and the easiest way to maintain the same sort-of-public interface so nothing else ought to break either. And with no change in Nova people won't need to worry about needing to update oslo.service at the same time they update Nova to avoid breakage. Here's a patch: https://review.openstack.org/619342 cheers, Zane. > This is only a fix on the nova side and itallowsus to update > oslo.service requirements and allowsus to fix the high CPU usage issue. > I've submit this patch (https://review.openstack.org/619246)who > implement the description above. > > Personaly I think we need to find an another approach like the mocking > remplacement (c.f 2). > > We need to decide which way we use and to discuss about other solutions. > From jimmy at openstack.org Wed Nov 21 19:45:50 2018 From: jimmy at openstack.org (Jimmy McArthur) Date: Wed, 21 Nov 2018 13:45:50 -0600 Subject: OpenStack Summit Berlin Presentation Videos & Slides In-Reply-To: References: <5BF440C4.4040801@openstack.org> <9e0517e1-149c-9234-5f25-23439dd352e8@orange.com> <5BF58DA2.9080606@openstack.org> Message-ID: Ha! It was an amazing city and venue :) just some strict IT policies. > On Nov 21, 2018, at 1:36 PM, Frank Kloeker wrote: > > Sorry, Jimmy, that Internet thing is still Neuland for us. > > Frank > > Am 2018-11-21 17:53, schrieb Jimmy McArthur: >> Hi Thomas- >> Thanks for your question. The extended timeframe is due to constraints >> with onsite network bandwidth at the Berlin conference center. This >> has required we ship drives to the US for editing and upload >> (different from recent Summits). Mid December is the latest we >> anticipate; however, we are trying to get them up as soon as possible. >> We will follow up on this email thread as soon as they are live. >> Please let us know if you have any further questions. >> Cheers, >> Jimmy >>> Thomas Morin >>> November 21, 2018 at 3:57 AM >>> Hi Jimmy, >>> During previous summits, it was great to have the video available >>> shortly after the summit (sometimes as shortly as the same day). >>> That allowed to catch up sessions one could not attend, or suggests >>> interesting sessions to colleagues that could not attend. >>> "Strike while the iron is hot", this kind of things :) >>> Perhaps we just got used too much to this form of luxury :) >>> So I don't want to ask for the impossible for the summit team, which >>> did a wonderful job, but I'm curious: is it possible to have an idea >>> why this can't be the case this time ? >>> Thanks, >>> -Thomas >>> Jimmy McArthur >>> November 20, 2018 at 11:13 AM >>> Thank you to everyone for a great OpenStack Summit last week in >>> Berlin! As you know, there were hundreds of breakout sessions to >>> catch last week. Videos from the keynote sessions are currently >>> available here [1], and our team is working to get the other >>> breakout session videos loaded as quickly as possible. We're >>> currently expecting all videos to be posted by mid-December, and if >>> we get them up sooner, I'll update this thread. >>> In the meantime, you can watch the keynotes videos [2] and watch >>> this page [3] for updates. Please also note that we sent out a link >>> to all presenters to upload their slides. As they are uploaded, they >>> can be found on the details page for each presentation on the Berlin >>> Summit Schedule [3] (along with videos, as they are processed). >>> Cheers, >>> Jimmy >>> [1] https://www.openstack.org/videos/summits/berlin-2018 >>> [2] https://www.openstack.org/videos/ >>> [3] https://www.openstack.org/summit/berlin-2018/summit-schedule/ > From smooney at redhat.com Wed Nov 21 19:50:13 2018 From: smooney at redhat.com (Sean Mooney) Date: Wed, 21 Nov 2018 19:50:13 +0000 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: <0f7e2d67-e899-66d7-295b-19c043c6a379@redhat.com> References: <0f7e2d67-e899-66d7-295b-19c043c6a379@redhat.com> Message-ID: <55d6613d3c208cce688f9e671511928bca2fb4a8.camel@redhat.com> On Wed, 2018-11-21 at 14:38 -0500, Zane Bitter wrote: > On 21/11/18 9:47 AM, Herve Beraud wrote: > > # Questions and proposed solutions > > > > This thread try to summarize the current situation. > > > > We need to find how to be able to proceed, so this thread aim to allow > > to discuss between team to find the best way to fix. > > > > 1. Do we need to continue to try to backport fixture on oslo.service to > > fix the CI problem (https://review.openstack.org/#/c/617989/)? > > > > 2. Do we need to find an another approach like mocking > > oslo.service.loopingcall._Event.wait in nova instead of mocking > > oslo_service.loopingcall._ThreadingEvent.wait (example: > > https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py)? > > 3. Doesn't this get solved if we add a line like: > > _ThreadingEvent = _Event > > in oslo.service on stable/rocky? That seems harmless and the easiest way > to maintain the same sort-of-public interface so nothing else ought to > break either. And with no change in Nova people won't need to worry > about needing to update oslo.service at the same time they update Nova > to avoid breakage. > > Here's a patch: https://review.openstack.org/619342 a stable only patch is not really any better in my view then 2 you are also chaning the loopingcall modules semantics as it is a different type even if you are allowing previously syntaxly vaild code to execute it does not maintain backwards compatiblity. we are not using a staticaly compiled language so we dont need to consider abi breakage this would result in for c or c++ but it i would stonglely prefer 1 or 2. > > cheers, > Zane. > > > This is only a fix on the nova side and itallowsus to update > > oslo.service requirements and allowsus to fix the high CPU usage issue. > > I've submit this patch (https://review.openstack.org/619246)who > > implement the description above. > > > > Personaly I think we need to find an another approach like the mocking > > remplacement (c.f 2). > > > > We need to decide which way we use and to discuss about other solutions. > > > > From fungi at yuggoth.org Wed Nov 21 20:18:18 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 21 Nov 2018 20:18:18 +0000 Subject: [tc][python3] next steps for resolution on tracking python 3 releases In-Reply-To: References: Message-ID: <20181121201818.c3alhvtc5islcnwo@yuggoth.org> On 2018-11-21 14:31:43 -0500 (-0500), Doug Hellmann wrote: [...] > I think first we need Zane's resolution [...] > Next, we want Sean's patch [...] > Finally, we need a variation of Jeremy's patch [...] I love this plan. I'm excited to be a part of it. Let's do it. ;) -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From melwittt at gmail.com Wed Nov 21 20:23:51 2018 From: melwittt at gmail.com (melanie witt) Date: Wed, 21 Nov 2018 21:23:51 +0100 Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack master In-Reply-To: References: Message-ID: <7566c269-c7e9-c803-fe23-21840004a58e@gmail.com> On Wed, 21 Nov 2018 12:11:50 -0600, Miguel Lavalle wrote: > One of the key goals of StarlingX during the current cycle is to > converge with the OpenStack projects master branches. In order to > accomplish this goal, the Technical Steering Committee put together a > gap analysis that shows the specs and patches that need to merge in the > different OpenStack projects by the end of Stein. The attached PDF > document shows this analysis. Although other projects are involved, most > of the work has to be done in Nova, Neutron and Horizon. Hopefully all > the involved projects will help StarlingX achieve this important goal. > > It has to be noted that work is still on-going to refine this gap > analysis, so there might be some updates to it in the near future. Thanks for sending this out. I'm going to reply about what I know of the status of nova-related planned upstream features. On NUMA-aware live migration, it was identified as the top priority issue in the NFV/HPC pain points forum session [1]. The spec has been approved before in the past for the Rocky cycle, so it's a matter of re-proposing it for re-approval in Stein. We need to confirm with artom and/or stephenfin whether one of them can pick it up this cycle. I don't know as much about the shared/dedicated vCPUs on a single host or the shared vCPU extension, but the cited spec [2] has one +2 already. If we can find a second approver, we can work on this too in Stein. The vTPM support spec was merged about two weeks ago and we are awaiting implementation patches from cfriesen. The HPET support spec was merged about two weeks ago and the implementation patch is under active review in a runway with one +2 now. For vCPU model, I'm not aware of any new proposed spec for Stein from the STX community as of today. Let us know if/when the spec is proposed. For disk performance fixes, the specless blueprint patch is currently under active review in a runway. The extra spec validation spec [3] is under active review now. For the bits that will be addressed using upstream features that are already available, I assume the STX community will take care of this. Please reach out to us in #openstack-nova or on the ML if there are questions/issues. For the bugs, again feel free to reach out to us for reviews/help. Cheers, -melanie [1] https://etherpad.openstack.org/p/BER-nfv-hpc-pain-points [2] https://review.openstack.org/555081 [3] https://review.openstack.org/618542 From tpb at dyncloud.net Wed Nov 21 20:30:41 2018 From: tpb at dyncloud.net (Tom Barron) Date: Wed, 21 Nov 2018 15:30:41 -0500 Subject: [k8s] [manila] Manila CSI driver plan Message-ID: <20181121203041.a7dsoo5twdcr2h4f@barron.net> [Robert Vasek, Red Hat colleagues working in this space: please correct any mis-understandings or omissions below] At the Berlin Summit SIG-K8s Working session [1] [2], we agreed to follow up with a note to the larger community summarizing our plan to enable Manila as RWX storage provider for k8s and other container orchestrators. Here it is :) Today there are kubernetes external service providers [3] [4] for Manila with NFS protocol back ends, as well as a way to use an external service provider on the master host in combination with a CSI CephFS node-host plugin [5]. We propose to target an end-to-end, multi-protocol Manila CSI plugin -- aiming at CSI 1.0, which should get support in container orchestrators early in 2019. Converging on CSI will: * provide support for multiple Container Orchestrators, not just k8s * de-couple storage plugin development from k8s life-cycle going forwards * unify development efforts and distributions and set clear expectations for operators and deployers Since manila needs to support multiple file system protocols such as CephFS native and NFS, we propose that work align to the multiplexing CSI architecture outlined here [6]. High level work plan: * Write master host multiplexing controller and node proxy plugins. * Use CephFS node-only plugin from [5] * Write NFS node-only plugin NFS and CephFS are immediate priorities - other file system protocols supported by manila can be added over time if there is interest. -- Tom Barron (irc: tbarron) [1] https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22752/sig-k8s-working-session [2] https://etherpad.openstack.org/p/sig-k8s-2018-berlin-summit [3] https://github.com/kubernetes-incubator/external-storage [4] https://github.com/kubernetes/cloud-provider-openstack [5] https://www.openstack.org/summit/berlin-2018/summit-schedule/events/21997/dynamic-storage-provisioning-of-manilacephfs-shares-on-kubernetes [6] https://github.com/container-storage-interface/spec/issues/263#issuecomment-411471611 From fungi at yuggoth.org Wed Nov 21 20:34:09 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 21 Nov 2018 20:34:09 +0000 Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack master In-Reply-To: <7566c269-c7e9-c803-fe23-21840004a58e@gmail.com> References: <7566c269-c7e9-c803-fe23-21840004a58e@gmail.com> Message-ID: <20181121203409.ipquymbzgh7mqvz6@yuggoth.org> On 2018-11-21 21:23:51 +0100 (+0100), melanie witt wrote: [...] > The vTPM support spec was merged about two weeks ago and we are > awaiting implementation patches from cfriesen. [...] Thanks, I had somehow missed noticing this spec up to now. I'm curious to follow the implementation and find out how we go about making sure users don't get the impression that an emulated TPM provides anywhere near the same sorts of guarantees as real one. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From mnaser at vexxhost.com Wed Nov 21 19:54:59 2018 From: mnaser at vexxhost.com (Mohammed Naser) Date: Wed, 21 Nov 2018 14:54:59 -0500 Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack master In-Reply-To: References: Message-ID: Thanks for doing this in the open and working with the upstream teams to reduce divergence! On Wed, Nov 21, 2018 at 1:17 PM Miguel Lavalle wrote: > Hi Stackers, > > One of the key goals of StarlingX during the current cycle is to converge > with the OpenStack projects master branches. In order to accomplish this > goal, the Technical Steering Committee put together a gap analysis that > shows the specs and patches that need to merge in the different OpenStack > projects by the end of Stein. The attached PDF document shows this > analysis. Although other projects are involved, most of the work has to be > done in Nova, Neutron and Horizon. Hopefully all the involved projects will > help StarlingX achieve this important goal. > > It has to be noted that work is still on-going to refine this gap > analysis, so there might be some updates to it in the near future. > > Best regards > > Miguel > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser at vexxhost.com W. http://vexxhost.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From melwittt at gmail.com Wed Nov 21 20:38:30 2018 From: melwittt at gmail.com (melanie witt) Date: Wed, 21 Nov 2018 21:38:30 +0100 Subject: [openstack-dev] [nova] Stein forum session notes In-Reply-To: <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> Message-ID: On Mon, 19 Nov 2018 08:31:59 -0500, Jay Pipes wrote: > Thanks for the highlights, Melanie. Appreciated. Some thoughts inline... > > On 11/19/2018 04:17 AM, melanie witt wrote: >> Hey all, >> >> Here's some notes I took in forum sessions I attended -- feel free to >> add notes on sessions I missed. >> >> Etherpad links: https://wiki.openstack.org/wiki/Forum/Berlin2018 >> >> Cheers, >> -melanie >> >> >> TUE >> --- >> >> Cells v2 updates >> ================ >> - Went over the etherpad, no objections to anything >> - Not directly related to the session, but CERN (hallway track) and >> NeCTAR (dev ML) have both given feedback and asked that the >> policy-driven idea for handling quota for down cells be avoided. Revived >> the "propose counting quota in placement" spec to see if there's any way >> forward here > > \o/ > >> Getting users involved in the project >> ===================================== >> - Disconnect between SIGs/WGs and project teams >> - Too steep a first step to get involved by subscribing to ML >> - People confused about how to participate > > Seriously? If subscribing to a mailing list is seen as too much of a > burden for users to provide feedback, I'm wondering what the point is of > having an open source community at all. > >> Community outreach when culture, time zones, and language differ >> ================================================================ >> - Most discussion around how to synchronize real-time communication >> considering different time zones >> - Best to emphasize asynchronous communication. Discussion on ML and >> gerrit reviews > > +1 > >> - Helpful to create weekly meeting agenda in advance so contributors >> from other time zones can add notes/response to discussion items > > +1, though I think it's also good to be able to say "look, nobody has > brought up anything they'd like to discuss this week so let's not take > time out of people's busy schedules if there's nothing to discuss". > >> WED >> --- >> >> NFV/HPC pain points >> =================== >> Top issues for immediate action: NUMA-aware live migration (spec just >> needs re-approval), improved scheduler logging (resurrect cfriesen's >> patch and clean it up), distant third is SRIOV live migration >> >> BFV improvements >> ================ >> - Went over the etherpad, no major objections to anything >> - Agree: we should expose boot_index from the attachments API >> - Unclear what to do about post-create delete_on_termination. Being able >> to specify it for attach sounds reasonable, but is it enough for those >> asking? Or would it end up serving no one? >> >> Better expose what we produce >> ============================= >> - Project teams should propose patches to openstack/openstack-map to >> improve their project pages >> - Would be ideal if project pages included a longer paragraph explaining >> the project, have a diagram, list SIGs/WGs related to the project, etc >> >> Blazar reservations to new resource types >> ========================================= >> - For nova compute hosts, reservations are done by putting reserved >> hosts into "blazar" host aggregate and then a special scheduler filter >> is used to exclude those hosts from scheduling. But how to extend that >> concept to other projects? >> - Note: the nova approach will change from scheduler filter => placement >> request filter > > Didn't we agree in Denver to use a placement request filter that > generated a forbidden aggregate request for this? I know Matt has had > concerns about the proposed spec for forbidden aggregates not adequately > explaining the Nova side configuration, but I was under the impression > the general idea of using a forbidden aggregate placement request filter > was a good one? > >> Edge use cases and requirements >> =============================== >> - Showed the reference architectures again >> - Most popular use case was "Mobile service provider 5G/4G virtual RAN >> deployment and Edge Cloud B2B2X" with seven +1s on the etherpad > > Snore. > > Until one of those +1s is willing to uncouple nova-compute's tight use > of rabbitmq and RDBMS-over-rabbitmq that we use as our control plane in > Nova, all the talk of "edge" this and "MEC" that is nothing more than > ... well, talk. > >> Deletion of project and project resources >> ========================================= >> - What is wanted: a delete API per service that takes a project_id and >> force deletes all resources owned by it with --dry-run component >> - Challenge to work out the dependencies for the order of deletion of >> all resources in all projects. Disable project, then delete things in >> order of dependency >> - Idea: turn os-purge into a REST API and each project implement a >> plugin for it > > I don't see why a REST API would be needed. We could more easily > implement the functionality by focusing on a plugin API for each service > project and leaving it at that. > >> Getting operators' bug fixes upstreamed >> ======================================= >> - Problem: operator reports a bug and provides a solution, for example, >> pastes a diff in launchpad or otherwise describes how to fix the bug. >> How can we increase the chances of those fixes making it to gerrit? >> - Concern: are there legal issues with accepting patches pasted into >> launchpad by someone who hasn't signed the ICLA? >> - Possible actions: create a best practices guide tailored for operators >> and socialize it among the ops docs/meetup/midcycle group. Example: >> guidance on how to indicate you don't have time to add test coverage, >> etc when you propose a patch >> >> THU >> --- >> >> Bug triage: why not all the community? >> ====================================== >> - Cruft and mixing tasks with defect reports makes triage more difficult >> to manage. Example: difference between a defect reported by a user vs an >> effective TODO added by a developer. If New bugs were reliably from end >> users, would we be more likely to triage? >> - Bug deputy weekly ML reporting could help >> - Action: copy the generic portion of the nova bug triage wiki doc into >> the contributor guide docs. The idea/hope being that easy-to-understand >> instructions available to the wider community might increase the chances >> of people outside of the project team being capable of triaging bugs, so >> all of it doesn't fall on project teams >> - Idea: should we remove the bug supervisor requirement from nova to >> allow people who haven't joined the bug team to set Status and Importance? >> >> Current state of volume encryption >> ================================== >> - Feedback: public clouds can't offer encryption because keys are stored >> in the cloud. Telcos are required to make sure admin can't access >> secrets. Action: SecuStack has a PoC for E2E key transfer, mnaser to >> help see what could be upstreamed >> - Features needed: ability for users to provide keys or use customer >> barbican or other key store. Thread: >> http://lists.openstack.org/pipermail/openstack-dev/2018-November/136258.html >> >> >> Cross-technical leadership session (OpenStack, Kata, StarlingX, Airship, >> Zuul) >> ======================================================================== >> - Took down the structure of how leadership positions work in each >> project on the etherpad, look at differences >> - StarlingX taking a new approach for upstreaming, New strategy: align >> with master, analyze what they need, and address the gaps (as opposed to >> pushing all the deltas up). Bug fixes still need to be brought forward, >> that won't change >> >> Concurrency limits for service instance creation >> ================================================ >> - Looking for ways to test and detect changes in performance as a >> community. Not straightforward because test hardware must stay >> consistent in order to detect performance deltas, release to release. >> Infra can't provide such an environment >> - Idea: it could help to write up a doc per project with a list of the >> usual tunables and basic info about how to use them >> >> Change of ownership of resources >> ================================ >> - Ignore the network piece for now, it's the most complicated. Being >> able to transfer everything else would solve 90% of City Network's use >> cases >> - Some ideas around having this be a keystone auth-based access granting >> instead of an update of project/user, but if keystone could hand user A >> a token for user B, that token would apply to all resources of user B's, >> not just the ones desired for transfer > > Whatever happened with the os-chown project Dan started in Denver? > > https://github.com/kk7ds/oschown What we distilled from the forum session is that at the heart of it, what is actually wanted is to be able to grant access to a resource owned by project A to project B, for example. It's not so much about wanting to literally change project_id/user_id from A to B. So, we asked the question, "what if project A could grant access to its resources to project B via keystone?" This could work if it is OK for project B to gain access to _all_ of project A's resources (since we currently have no way to scope access to specific resources). For a use case where it is OK for project A to grant access to all of project B's resources, the idea of accomplishing this is keystone-only, could work. Doing it auth-based through keystone-only would leave project_id/user_id and all dependencies intact, making the change only at the auth/project level. It is simpler and cleaner. However, for a use case where it is not OK for project B to gain access to all of project A's resources, because we lack the ability to scope access to specific resources, the os-chown approach is the only proposal we know of that can address it. So, depending on the use cases, we might be able to explore a keystone approach. From what I gathered in the forum session, it sounded like City Network might be OK with a project-wide access grant, but Oath might need a resource-specific scoped access grant. If those are both the case, we would find use in both a keystone access approach and the os-chown approach. >> Update on placement extraction from nova >> ======================================== >> - Upgrade step additions from integrated placement to extracted >> placement in TripleO and OpenStackAnsible are being worked on now >> - Reshaper patches for libvirt and xenapi drivers are up for review >> - Lab test for vGPU upgrade and reshape + new schedule for libvirt >> driver patch has been done already > > This is news to me. Can someone provide me a link to where I can get > some more information about this? > >> - FFU script work needs an owner. Will need to query libvirtd to get >> mdevs and use PlacementDirect to populate placement >> >> Python bindings for the placement API >> ===================================== >> - Placement client code replicated in different projects: nova, blazar, >> neutron, cyborg. Want to commonize into python bindings lib >> - Consensus was that the placement bindings should go into openstacksdk >> and then projects will consume it from there >> >> T series community goal discussion >> ================================== >> - Most popular goal ideas: Finish moving legacy python-*client CLIs to >> python-openstackclient, Deletion of project resources as discussed in >> forum session earlier in the week, ensure all projects use ServiceTokens >> when calling one another with incoming token >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > From melwittt at gmail.com Wed Nov 21 20:42:13 2018 From: melwittt at gmail.com (melanie witt) Date: Wed, 21 Nov 2018 21:42:13 +0100 Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack master In-Reply-To: <20181121203409.ipquymbzgh7mqvz6@yuggoth.org> References: <7566c269-c7e9-c803-fe23-21840004a58e@gmail.com> <20181121203409.ipquymbzgh7mqvz6@yuggoth.org> Message-ID: On Wed, 21 Nov 2018 20:34:09 +0000, Jeremy Stanley wrote: > On 2018-11-21 21:23:51 +0100 (+0100), melanie witt wrote: > [...] >> The vTPM support spec was merged about two weeks ago and we are >> awaiting implementation patches from cfriesen. > [...] > > Thanks, I had somehow missed noticing this spec up to now. I'm > curious to follow the implementation and find out how we go about > making sure users don't get the impression that an emulated TPM > provides anywhere near the same sorts of guarantees as real one. Here's a link to the spec: https://review.openstack.org/571111 and you can follow the implementation (once it's proposed) via the gerrit topic. Cheers, -melanie From mriedemos at gmail.com Wed Nov 21 21:11:57 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 21 Nov 2018 15:11:57 -0600 Subject: [nova][cinder] Why can't nova in stein work with cinder from queens? Message-ID: <3a1ed017-f9f0-b444-4f56-673c44c3d35f@gmail.com> A change in nova [1] was approved which makes an assertion that we (nova? openstack?) do not support running nova from stein with cinder from queens, and I guess I'd like to know where that support statement is written down? Granted, I know we don't gate that way but I'm not aware of anything preventing it from working given we use microversions and nova, as the client, should be able to work with cinder from v1, v2 or v3 assuming it's doing version discovery correctly (which we've been doing in nova since queens when we needed to start using the cinder v3.44 volume attachments API for multiattach - but it's not required). In fact, nova-api still has compatibility code for older versions of cinder to determine what it should do about working with volume attachments [2]. I've been thinking lately about how to drop that code which would at the very least require a release note saying nova requires cinder >= queens, but nothing like that was requested in the change that drops support for cinder v1 from nova and asserts that nova in stein requires cinder >= queens. Maybe I'm just yelling at kids to get off my lawn, but I don't really want this to be precedent without some discussion because I know at various times operators have complained about upgrades being hard because they assume all of the services must be upgraded to the same release at the same time, and I don't think that is true, or should be true, because if it is, we're doing a really bad job of defining versioned interfaces between the services. [1] https://review.openstack.org/#/c/617927/ [2] https://github.com/openstack/nova/blob/7217e38bafb75e8a613763835b64e48e6b2c8ece/nova/compute/api.py#L4260-L4264 -- Thanks, Matt From zbitter at redhat.com Wed Nov 21 22:03:29 2018 From: zbitter at redhat.com (Zane Bitter) Date: Wed, 21 Nov 2018 17:03:29 -0500 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: <55d6613d3c208cce688f9e671511928bca2fb4a8.camel@redhat.com> References: <0f7e2d67-e899-66d7-295b-19c043c6a379@redhat.com> <55d6613d3c208cce688f9e671511928bca2fb4a8.camel@redhat.com> Message-ID: <514024c3-27e5-104d-898c-ee882745bdcb@redhat.com> On 21/11/18 2:50 PM, Sean Mooney wrote: > On Wed, 2018-11-21 at 14:38 -0500, Zane Bitter wrote: >> On 21/11/18 9:47 AM, Herve Beraud wrote: >>> # Questions and proposed solutions >>> >>> This thread try to summarize the current situation. >>> >>> We need to find how to be able to proceed, so this thread aim to allow >>> to discuss between team to find the best way to fix. >>> >>> 1. Do we need to continue to try to backport fixture on oslo.service to >>> fix the CI problem (https://review.openstack.org/#/c/617989/)? This is the worst option, because you won't be able to use either an older nova with a newer oslo.service, nor an older oslo.service with a newer nova. In fact, if I'm interpreting Matt's comment on https://review.openstack.org/619246 correctly, then this may be a non-starter because increasing lower-constraints is not allowed on stable branches. >>> 2. Do we need to find an another approach like mocking >>> oslo.service.loopingcall._Event.wait in nova instead of mocking >>> oslo_service.loopingcall._ThreadingEvent.wait (example: >>> https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py)? This is marginally better, provided that it's done in a backwards-compatible way (i.e. that doesn't require bumping the lower-constraints like https://review.openstack.org/619246 and https://review.openstack.org/619022 do). Here's an example that should do the trick: https://review.openstack.org/619360 However, this does still mean that you can't use an older Nova with a newer oslo.service. Which is bound to cause trouble for somebody. It also relies on a different private interface, although we're less likely to need to change this one in stable/rocky. >> 3. Doesn't this get solved if we add a line like: >> >> _ThreadingEvent = _Event >> >> in oslo.service on stable/rocky? That seems harmless and the easiest way >> to maintain the same sort-of-public interface so nothing else ought to >> break either. And with no change in Nova people won't need to worry >> about needing to update oslo.service at the same time they update Nova >> to avoid breakage. >> >> Here's a patch: https://review.openstack.org/619342 > a stable only patch is not really any better in my view then 2 Surely being able to update oslo.service and nova independently is objectively better than having to upgrade them in lock-step. Would it make you feel better if this patch were also on master? Why? > you are also chaning the loopingcall modules semantics > as it is a different type even if you are allowing previously syntaxly > vaild code to execute it does not maintain backwards compatiblity. This is a fair point; only the clear()/wait()/stop() methods are the same. is_running() changes to is_set() and done() changes to set(). So it is a bit hacky. But it still solves the instance of the problem we know about (and FWIW any instance of the problem that *could*, in principle, be solved by the fixture). > we are not using a staticaly compiled language so we dont need to consider > abi breakage this would result in for c or c++ but it i would stonglely prefer 1 or 2. > >> >> cheers, >> Zane. >> >>> This is only a fix on the nova side and itallowsus to update >>> oslo.service requirements and allowsus to fix the high CPU usage issue. >>> I've submit this patch (https://review.openstack.org/619246)who >>> implement the description above. >>> >>> Personaly I think we need to find an another approach like the mocking >>> remplacement (c.f 2). >>> >>> We need to decide which way we use and to discuss about other solutions. >>> >> >> From melwittt at gmail.com Wed Nov 21 22:06:20 2018 From: melwittt at gmail.com (melanie witt) Date: Wed, 21 Nov 2018 23:06:20 +0100 Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack master In-Reply-To: <7566c269-c7e9-c803-fe23-21840004a58e@gmail.com> References: <7566c269-c7e9-c803-fe23-21840004a58e@gmail.com> Message-ID: <3b126d54-e7d7-188f-461c-09de196924dd@gmail.com> On Wed, 21 Nov 2018 21:23:51 +0100, Melanie Witt wrote: > On Wed, 21 Nov 2018 12:11:50 -0600, Miguel Lavalle wrote: >> One of the key goals of StarlingX during the current cycle is to >> converge with the OpenStack projects master branches. In order to >> accomplish this goal, the Technical Steering Committee put together a >> gap analysis that shows the specs and patches that need to merge in the >> different OpenStack projects by the end of Stein. The attached PDF >> document shows this analysis. Although other projects are involved, most >> of the work has to be done in Nova, Neutron and Horizon. Hopefully all >> the involved projects will help StarlingX achieve this important goal. >> >> It has to be noted that work is still on-going to refine this gap >> analysis, so there might be some updates to it in the near future. > > Thanks for sending this out. I'm going to reply about what I know of the > status of nova-related planned upstream features. > > On NUMA-aware live migration, it was identified as the top priority > issue in the NFV/HPC pain points forum session [1]. The spec has been > approved before in the past for the Rocky cycle, so it's a matter of > re-proposing it for re-approval in Stein. We need to confirm with artom > and/or stephenfin whether one of them can pick it up this cycle. Turns out this spec has already been re-proposed for Stein as of Sep 4: https://review.openstack.org/599587 and is under active review now. Apologies for missing this in my previous reply. > I don't know as much about the shared/dedicated vCPUs on a single host > or the shared vCPU extension, but the cited spec [2] has one +2 already. > If we can find a second approver, we can work on this too in Stein. > > The vTPM support spec was merged about two weeks ago and we are awaiting > implementation patches from cfriesen. > > The HPET support spec was merged about two weeks ago and the > implementation patch is under active review in a runway with one +2 now. > > For vCPU model, I'm not aware of any new proposed spec for Stein from > the STX community as of today. Let us know if/when the spec is proposed. > > For disk performance fixes, the specless blueprint patch is currently > under active review in a runway. > > The extra spec validation spec [3] is under active review now. > > For the bits that will be addressed using upstream features that are > already available, I assume the STX community will take care of this. > Please reach out to us in #openstack-nova or on the ML if there are > questions/issues. > > For the bugs, again feel free to reach out to us for reviews/help. > > Cheers, > -melanie > > [1] https://etherpad.openstack.org/p/BER-nfv-hpc-pain-points > [2] https://review.openstack.org/555081 > [3] https://review.openstack.org/618542 > > > From smooney at redhat.com Wed Nov 21 22:11:12 2018 From: smooney at redhat.com (Sean Mooney) Date: Wed, 21 Nov 2018 22:11:12 +0000 Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack master In-Reply-To: References: <7566c269-c7e9-c803-fe23-21840004a58e@gmail.com> <20181121203409.ipquymbzgh7mqvz6@yuggoth.org> Message-ID: <28fbede7628cb196a6ee1b5dfcc7d0724b14e3b3.camel@redhat.com> sorry to top post but wanted to provide some feedback on the pdf. on future revisions of the pdf the live migration with pinning and numa topology item shoudl be updated to the stein version of the spec. https://review.openstack.org/#/c/599587 the main reson for me to respond however is the "SR-IOV/PT best effort scheduling policy" item. this feature was not completed in queens and is possibly broken. as part of the implementation the flavor extra specs and image metadata items that were part of the spec were removed meaning that neutron sriov port and numa affinity policies for hardware offloaded ovs where lost. the spec was retro activly updated to reflect what lanned in https://review.openstack.org/#/c/555000 the first spec to introduce the concpet of pci numa affintiy was https://specs.openstack.org/openstack/nova-specs/specs/juno/approved/input-output-based-numa-scheduling.html which clearly calls out that this was inteded for NFV workloads and makes reference to the 2 specs intoducing neutron contoled sriov interface to nova and guest numa topologies for libvirt. at the time my team at intel had our own implemtations of hugepages,vhost user and we hand a complete working implmentation of pci numa affinity with 3 policys (strict affinity, best effort affinity and any device) when the spec was repropsed for kilo the neutron aspect was left out based on feedback that it added noise since neutron controled sriov was just anoter way of useing pci passthough. https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/input-output-based-numa-scheduling.html in queens after an interlude where work on this got out sourced and abandoned twice we finally got around to proposing the policies that where in the original juno code https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/share-pci-between-numa-nodes.html if you look at the current version of that spec you will notice that flavor extras specs and image metadata values are missing but it was updated by https://review.openstack.org/#/c/555000 however it still contians the section decibing what happens if the flavor and image metadata dissagree "If both image and flavor properties are not set (equals None) the legacy policy will be used. If one of image or flavor property is not set (equals None) but the other property is set then the value of the set property will be used. In a case of conflicts between flavor and image properties (both properties are set and they are not equal) an exception will be raised." there have been report at the vacovour summit and more recently on mailing list http://lists.openstack.org/pipermail/openstack-dev/2018-November/136461.html that this fuctionality is broken even for the restrited case of using alias. there has also been a direct request/bug opened to track the neutron support https://bugs.launchpad.net/nova/+bug/1795920. so if we want to close this gap we have to first do an audit of the code an figure out what works/dosent and reprose the queens spec. ill be trying test this over the next two days but i wanted to highlight this a risk. On Wed, 2018-11-21 at 21:42 +0100, melanie witt wrote: > On Wed, 21 Nov 2018 20:34:09 +0000, Jeremy Stanley wrote: > > On 2018-11-21 21:23:51 +0100 (+0100), melanie witt wrote: > > [...] > > > The vTPM support spec was merged about two weeks ago and we are > > > awaiting implementation patches from cfriesen. > > > > [...] > > > > Thanks, I had somehow missed noticing this spec up to now. I'm > > curious to follow the implementation and find out how we go about > > making sure users don't get the impression that an emulated TPM > > provides anywhere near the same sorts of guarantees as real one. > > Here's a link to the spec: > > https://review.openstack.org/571111 > > and you can follow the implementation (once it's proposed) via the > gerrit topic. > > Cheers, > -melanie > > > > > From smooney at redhat.com Wed Nov 21 22:35:30 2018 From: smooney at redhat.com (Sean Mooney) Date: Wed, 21 Nov 2018 22:35:30 +0000 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: <514024c3-27e5-104d-898c-ee882745bdcb@redhat.com> References: <0f7e2d67-e899-66d7-295b-19c043c6a379@redhat.com> <55d6613d3c208cce688f9e671511928bca2fb4a8.camel@redhat.com> <514024c3-27e5-104d-898c-ee882745bdcb@redhat.com> Message-ID: On Wed, 2018-11-21 at 17:03 -0500, Zane Bitter wrote: > On 21/11/18 2:50 PM, Sean Mooney wrote: > > On Wed, 2018-11-21 at 14:38 -0500, Zane Bitter wrote: > > > On 21/11/18 9:47 AM, Herve Beraud wrote: > > > > # Questions and proposed solutions > > > > > > > > This thread try to summarize the current situation. > > > > > > > > We need to find how to be able to proceed, so this thread aim to allow > > > > to discuss between team to find the best way to fix. > > > > > > > > 1. Do we need to continue to try to backport fixture on oslo.service to > > > > fix the CI problem (https://review.openstack.org/#/c/617989/)? > > This is the worst option, because you won't be able to use either an > older nova with a newer oslo.service, nor an older oslo.service with a > newer nova. > > In fact, if I'm interpreting Matt's comment on > https://review.openstack.org/619246 correctly, then this may be a > non-starter because increasing lower-constraints is not allowed on > stable branches. you also cannot use a newer versions then are in upper-constaints this thread arose from the fact that performacne feature/bug fix form 1.32.x is being backported to 1.31.6. upper-constainst set a limit on oslo.service of 1.31.x so you are not expect to be able to use newer relases of oslo.service with the rocky release of nova. > > > > > 2. Do we need to find an another approach like mocking > > > > oslo.service.loopingcall._Event.wait in nova instead of mocking > > > > oslo_service.loopingcall._ThreadingEvent.wait (example: > > > > https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py)? > > This is marginally better, provided that it's done in a > backwards-compatible way (i.e. that doesn't require bumping the > lower-constraints like https://review.openstack.org/619246 and > https://review.openstack.org/619022 do). Here's an example that should > do the trick: > > https://review.openstack.org/619360 > > However, this does still mean that you can't use an older Nova with a > newer oslo.service. Which is bound to cause trouble for somebody. > > It also relies on a different private interface, although we're less > likely to need to change this one in stable/rocky. > > > > 3. Doesn't this get solved if we add a line like: > > > > > > _ThreadingEvent = _Event > > > > > > in oslo.service on stable/rocky? That seems harmless and the easiest way > > > to maintain the same sort-of-public interface so nothing else ought to > > > break either. And with no change in Nova people won't need to worry > > > about needing to update oslo.service at the same time they update Nova > > > to avoid breakage. > > > > > > Here's a patch: https://review.openstack.org/619342 > > > > a stable only patch is not really any better in my view then 2 > > Surely being able to update oslo.service and nova independently is > objectively better than having to upgrade them in lock-step. > > Would it make you feel better if this patch were also on master? Why? > > > you are also chaning the loopingcall modules semantics > > as it is a different type even if you are allowing previously syntaxly > > vaild code to execute it does not maintain backwards compatiblity. > > This is a fair point; only the clear()/wait()/stop() methods are the > same. is_running() changes to is_set() and done() changes to set(). So > it is a bit hacky. But it still solves the instance of the problem we > know about (and FWIW any instance of the problem that *could*, in > principle, be solved by the fixture). if we go with this appoch and are doing a stable only change then instead of just doing _ThreadingEvent =_Event could we either use the debtcoltor moduel to make it as deprecated or stub out the signigure of the old interface and have it log a warning if invoked nova is only using this in test but if we are consusred about people upgrading then when we remove this workaourd at some point e.g. we shoudl at least warn other that might have done the same and depended on the ThredingEvents. > > > we are not using a staticaly compiled language so we dont need to consider > > abi breakage this would result in for c or c++ but it i would stonglely prefer 1 or 2. > > > > > > > > cheers, > > > Zane. > > > > > > > This is only a fix on the nova side and itallowsus to update > > > > oslo.service requirements and allowsus to fix the high CPU usage issue. > > > > I've submit this patch (https://review.openstack.org/619246)who > > > > implement the description above. > > > > > > > > Personaly I think we need to find an another approach like the mocking > > > > remplacement (c.f 2). > > > > > > > > We need to decide which way we use and to discuss about other solutions. > > > > > > > > > > > > From smooney at redhat.com Wed Nov 21 22:59:29 2018 From: smooney at redhat.com (Sean Mooney) Date: Wed, 21 Nov 2018 22:59:29 +0000 Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack master In-Reply-To: <20181121203409.ipquymbzgh7mqvz6@yuggoth.org> References: <7566c269-c7e9-c803-fe23-21840004a58e@gmail.com> <20181121203409.ipquymbzgh7mqvz6@yuggoth.org> Message-ID: <15d341108bc6fa99a69ecdc21ad22b75051352ad.camel@redhat.com> On Wed, 2018-11-21 at 20:34 +0000, Jeremy Stanley wrote: > On 2018-11-21 21:23:51 +0100 (+0100), melanie witt wrote: > [...] > > The vTPM support spec was merged about two weeks ago and we are > > awaiting implementation patches from cfriesen. > > [...] > > Thanks, I had somehow missed noticing this spec up to now. I'm > curious to follow the implementation and find out how we go about > making sure users don't get the impression that an emulated TPM > provides anywhere near the same sorts of guarantees as real one. while its out of scope of the proposed spec it does methion the posiblity of passing through a host tpm at some point if there was a demand for that. on a side note who was aware that out of tree hyperv dirver already support vtpm http://git.openstack.org/cgit/openstack/compute-hyperv/tree/compute_hyperv/nova/vmops.py#n1334 there was a spec for the hyperv support back to liberty and mitaka. and was completed in tech preview as part of https://blueprints.launchpad.net/nova/+spec/hyper-v-vtpm-devices The current specs referenced in the starlinX gaps is for libvirt specifically but it would be good to see vtpm feature in other driver in the future. i dont know if the hyperv folk still want to get there vTPM feature into the intree driver but it woudl be interesting to see if this will show up in the powervm or vmware drivers at some point. From raniaadouni at gmail.com Wed Nov 21 23:16:10 2018 From: raniaadouni at gmail.com (Rania Adouni) Date: Thu, 22 Nov 2018 00:16:10 +0100 Subject: [openstack-dev] [ZUN] [kuryr-libnetwork] In-Reply-To: References: Message-ID: Hi hongbin, Finally , I had to move and using queens because after all I think when I set up ZUN , it has effect on my nova-compute service was down .and for more secure work I move to queens . and now my kuryr work fine , but when I try container I had this error : *Docker internal error: 400 Client Error: Bad Request ("OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/bin/bash\": stat /bin/bash: no such file or directory": unknown").* some suggestion to fix it please and thanks . Best Regards, Rania Adouni [image: Mailtrack] Sender notified by Mailtrack 11/22/18, 12:15:06 AM Le mer. 21 nov. 2018 à 16:47, Hongbin Lu a écrit : > Hi Rania, > > See if this helps: > http://lists.openstack.org/pipermail/openstack-dev/2018-November/136547.html > > Best regards, > Hongbin > > On Wed, Nov 21, 2018 at 7:27 AM Rania Adouni > wrote: > >> Hi everyone, >> >> I was trying to create container but I just ended up by this error : >> *Docker internal error: 500 Server Error: Internal Server Error ("failed >> to update store for object type *libnetwork.endpointCnt: dial tcp >> 192.168.1.20:2379 : connect: connection >> refused").* >> >> Then I back to Verify operation of the kuryr-libnetwork, if it work fine >> or not with command : >> *docker network create --driver kuryr --ipam-driver kuryr --subnet >> 10.10.0.0/16 --gateway=10.10.0.1 test_net * >> >> But i get this error : >> *Error response from daemon: failed to update store for object type >> *libnetwork.endpointCnt: dial tcp 192.168.1.20:2379 >> : connect: connection refused * >> *Ps: 192.168.1.20 is the address of my controller Node !!* >> >> some help will be nice and thanks . >> >> Best Regards, >> Rania Adouni >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From david.j.ivey at gmail.com Wed Nov 21 23:55:53 2018 From: david.j.ivey at gmail.com (David Ivey) Date: Wed, 21 Nov 2018 18:55:53 -0500 Subject: [openstack-dev] [ZUN] [kuryr-libnetwork] In-Reply-To: References: Message-ID: Hi Rania, I am assuming you are spinning up a cirros container still. Iirc the cirros container does not have /bin/bash. Try just executing /bin/sh. David On Wed, Nov 21, 2018, 6:26 PM Rania Adouni Hi hongbin, > > Finally , I had to move and using queens because after all I think when I > set up ZUN , it has effect on my nova-compute service was down .and for > more secure work I move to queens . and now my kuryr work fine , but when I > try container I had this error : > *Docker internal error: 400 Client Error: Bad Request ("OCI runtime create > failed: container_linux.go:348: starting container process caused "exec: > \"/bin/bash\": stat /bin/bash: no such file or directory": unknown").* > some suggestion to fix it please and thanks . > > Best Regards, > Rania Adouni > > > [image: Mailtrack] > Sender > notified by > Mailtrack > 11/22/18, > 12:15:06 AM > > Le mer. 21 nov. 2018 à 16:47, Hongbin Lu a écrit : > >> Hi Rania, >> >> See if this helps: >> http://lists.openstack.org/pipermail/openstack-dev/2018-November/136547.html >> >> Best regards, >> Hongbin >> >> On Wed, Nov 21, 2018 at 7:27 AM Rania Adouni >> wrote: >> >>> Hi everyone, >>> >>> I was trying to create container but I just ended up by this error : >>> *Docker internal error: 500 Server Error: Internal Server Error ("failed >>> to update store for object type *libnetwork.endpointCnt: dial tcp >>> 192.168.1.20:2379 : connect: connection >>> refused").* >>> >>> Then I back to Verify operation of the kuryr-libnetwork, if it work fine >>> or not with command : >>> *docker network create --driver kuryr --ipam-driver kuryr --subnet >>> 10.10.0.0/16 --gateway=10.10.0.1 test_net * >>> >>> But i get this error : >>> *Error response from daemon: failed to update store for object type >>> *libnetwork.endpointCnt: dial tcp 192.168.1.20:2379 >>> : connect: connection refused * >>> *Ps: 192.168.1.20 is the address of my controller Node !!* >>> >>> some help will be nice and thanks . >>> >>> Best Regards, >>> Rania Adouni >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From zbitter at redhat.com Thu Nov 22 00:07:09 2018 From: zbitter at redhat.com (Zane Bitter) Date: Wed, 21 Nov 2018 19:07:09 -0500 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: References: <0f7e2d67-e899-66d7-295b-19c043c6a379@redhat.com> <55d6613d3c208cce688f9e671511928bca2fb4a8.camel@redhat.com> <514024c3-27e5-104d-898c-ee882745bdcb@redhat.com> Message-ID: <5492b6ea-ad52-a56d-17a9-d22abb9eda0a@redhat.com> On 21/11/18 5:35 PM, Sean Mooney wrote: > On Wed, 2018-11-21 at 17:03 -0500, Zane Bitter wrote: >> On 21/11/18 2:50 PM, Sean Mooney wrote: >>> On Wed, 2018-11-21 at 14:38 -0500, Zane Bitter wrote: >>>> On 21/11/18 9:47 AM, Herve Beraud wrote: >>>>> # Questions and proposed solutions >>>>> >>>>> This thread try to summarize the current situation. >>>>> >>>>> We need to find how to be able to proceed, so this thread aim to allow >>>>> to discuss between team to find the best way to fix. >>>>> >>>>> 1. Do we need to continue to try to backport fixture on oslo.service to >>>>> fix the CI problem (https://review.openstack.org/#/c/617989/)? >> >> This is the worst option, because you won't be able to use either an >> older nova with a newer oslo.service, nor an older oslo.service with a >> newer nova. >> >> In fact, if I'm interpreting Matt's comment on >> https://review.openstack.org/619246 correctly, then this may be a >> non-starter because increasing lower-constraints is not allowed on >> stable branches. > you also cannot use a newer versions then are in upper-constaints > this thread arose from the fact that performacne feature/bug fix form 1.32.x is being > backported to 1.31.6. upper-constainst set a limit on oslo.service of 1.31.x so you are > not expect to be able to use newer relases of oslo.service with the rocky release of nova. Right, but the whole point of this discussion is that once we fix this we can bump the upper-constraints to 1.31.6 or 1.31.7. Whereas apparently we *cannot* bump the lower-constraints. >>>>> 2. Do we need to find an another approach like mocking >>>>> oslo.service.loopingcall._Event.wait in nova instead of mocking >>>>> oslo_service.loopingcall._ThreadingEvent.wait (example: >>>>> https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py)? >> >> This is marginally better, provided that it's done in a >> backwards-compatible way (i.e. that doesn't require bumping the >> lower-constraints like https://review.openstack.org/619246 and >> https://review.openstack.org/619022 do). Here's an example that should >> do the trick: >> >> https://review.openstack.org/619360 >> >> However, this does still mean that you can't use an older Nova with a >> newer oslo.service. Which is bound to cause trouble for somebody. >> >> It also relies on a different private interface, although we're less >> likely to need to change this one in stable/rocky. >> >>>> 3. Doesn't this get solved if we add a line like: >>>> >>>> _ThreadingEvent = _Event >>>> >>>> in oslo.service on stable/rocky? That seems harmless and the easiest way >>>> to maintain the same sort-of-public interface so nothing else ought to >>>> break either. And with no change in Nova people won't need to worry >>>> about needing to update oslo.service at the same time they update Nova >>>> to avoid breakage. >>>> >>>> Here's a patch: https://review.openstack.org/619342 >>> >>> a stable only patch is not really any better in my view then 2 >> >> Surely being able to update oslo.service and nova independently is >> objectively better than having to upgrade them in lock-step. >> >> Would it make you feel better if this patch were also on master? Why? >> >>> you are also chaning the loopingcall modules semantics >>> as it is a different type even if you are allowing previously syntaxly >>> vaild code to execute it does not maintain backwards compatiblity. >> >> This is a fair point; only the clear()/wait()/stop() methods are the >> same. is_running() changes to is_set() and done() changes to set(). So >> it is a bit hacky. But it still solves the instance of the problem we >> know about (and FWIW any instance of the problem that *could*, in >> principle, be solved by the fixture). > if we go with this appoch and are doing a stable only change then > instead of just doing _ThreadingEvent =_Event > could we either use the debtcoltor moduel to make it as deprecated Sadly, this won't work because if they're not referring to the same object then stubbing out the method won't have the desired effect. > or stub out the signigure of the old interface and have it log a warning if invoked Happy to do this. > nova is only using this in test but if we are consusred about people upgrading then > when we remove this workaourd at some point e.g. we shoudl at least warn other that might > have done the same and depended on the ThredingEvents. Well, we already removed it because it's long gone on master. So I doubt that adding deprecation warnings in a stable branch will catch any interesting cases that haven't been found already. cheers, Zane. From raniaadouni at gmail.com Thu Nov 22 00:13:39 2018 From: raniaadouni at gmail.com (Rania Adouni) Date: Thu, 22 Nov 2018 01:13:39 +0100 Subject: [openstack-dev] [ZUN] [kuryr-libnetwork] In-Reply-To: References: Message-ID: Yes david thanks for reply, it was the problem with the command /bin/bash when i just modified with sh my container was up and running. Thanks for all the team openstack dev for the help . Best regards, Rania adouni Le jeu. 22 nov. 2018 à 00:57, David Ivey a écrit : > Hi Rania, > > I am assuming you are spinning up a cirros container still. Iirc the > cirros container does not have /bin/bash. Try just executing /bin/sh. > > David > > > On Wed, Nov 21, 2018, 6:26 PM Rania Adouni >> Hi hongbin, >> >> Finally , I had to move and using queens because after all I think when I >> set up ZUN , it has effect on my nova-compute service was down .and for >> more secure work I move to queens . and now my kuryr work fine , but when I >> try container I had this error : >> *Docker internal error: 400 Client Error: Bad Request ("OCI runtime >> create failed: container_linux.go:348: starting container process caused >> "exec: \"/bin/bash\": stat /bin/bash: no such file or directory": >> unknown").* >> some suggestion to fix it please and thanks . >> >> Best Regards, >> Rania Adouni >> >> >> [image: Mailtrack] >> Sender >> notified by >> Mailtrack >> 11/22/18, >> 12:15:06 AM >> >> Le mer. 21 nov. 2018 à 16:47, Hongbin Lu a écrit : >> >>> Hi Rania, >>> >>> See if this helps: >>> http://lists.openstack.org/pipermail/openstack-dev/2018-November/136547.html >>> >>> Best regards, >>> Hongbin >>> >>> On Wed, Nov 21, 2018 at 7:27 AM Rania Adouni >>> wrote: >>> >>>> Hi everyone, >>>> >>>> I was trying to create container but I just ended up by this error : >>>> *Docker internal error: 500 Server Error: Internal Server Error >>>> ("failed to update store for object type *libnetwork.endpointCnt: dial tcp >>>> 192.168.1.20:2379 : connect: connection >>>> refused").* >>>> >>>> Then I back to Verify operation of the kuryr-libnetwork, if it work >>>> fine or not with command : >>>> *docker network create --driver kuryr --ipam-driver kuryr --subnet >>>> 10.10.0.0/16 --gateway=10.10.0.1 test_net * >>>> >>>> But i get this error : >>>> *Error response from daemon: failed to update store for object type >>>> *libnetwork.endpointCnt: dial tcp 192.168.1.20:2379 >>>> : connect: connection refused * >>>> *Ps: 192.168.1.20 is the address of my controller Node !!* >>>> >>>> some help will be nice and thanks . >>>> >>>> Best Regards, >>>> Rania Adouni >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From chenjie.xu at intel.com Thu Nov 22 03:20:53 2018 From: chenjie.xu at intel.com (Xu, Chenjie) Date: Thu, 22 Nov 2018 03:20:53 +0000 Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack master In-Reply-To: References: Message-ID: Hi Miguel, There is another RFE “Add l2pop support for floating IP resources” proposed to Launchpad. This RFE also comes from StarlingX and the link is below: https://bugs.launchpad.net/neutron/+bug/1803494 Could you please help review this RFE? I think this RFE can be added to the gap analysis. What’s more, there is a bug and a RFE relating to l2pop and neutron-dynamic-routing is being written and is expected to be released next week. Best Regards, Xu, Chenjie From: Miguel Lavalle [mailto:miguel at mlavalle.com] Sent: Thursday, November 22, 2018 2:12 AM To: openstack-discuss at lists.openstack.org; OpenStack Development Mailing List > Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack master Hi Stackers, One of the key goals of StarlingX during the current cycle is to converge with the OpenStack projects master branches. In order to accomplish this goal, the Technical Steering Committee put together a gap analysis that shows the specs and patches that need to merge in the different OpenStack projects by the end of Stein. The attached PDF document shows this analysis. Although other projects are involved, most of the work has to be done in Nova, Neutron and Horizon. Hopefully all the involved projects will help StarlingX achieve this important goal. It has to be noted that work is still on-going to refine this gap analysis, so there might be some updates to it in the near future. Best regards Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at bakeyournoodle.com Thu Nov 22 04:55:07 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Thu, 22 Nov 2018 15:55:07 +1100 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: References: Message-ID: <20181122045506.GC24690@thor.bakeyournoodle.com> HI folks, I admit my initial response to this was mor pragmatic 'take the bakport' but as I thought it through I saw more problems with that approach. On Wed, Nov 21, 2018 at 03:47:25PM +0100, Herve Beraud wrote: > Since these changes was introduced into oslo.service master, nova facing > some issues into the master CI process, due to the threading changes, and > they was fixed by these patches ( https://review.openstack.org/#/c/615724/, > https://review.openstack.org/#/c/617989/ ) into master. > > Few weeks ago I have backport to oslo.service some changes ( > https://review.openstack.org/#/c/614489/ ) from master to stable/rocky to > also fix the problem in the rocky release. Okay that was a mistake, backporting a patch from master to stable that is known to break consumers, I admit this isn't explicitly called out in the stable policy but it is kind of the spirit of the stable policy. The quickest fix would be to revert 614489, release 1.31.7 and blacklist 1.31.6. Yes this leaves the High CPU usage bug open on rocky. That isn't great but it also isn't terrible. > When this backport was merged we have created a new release of oslo.service > (1.31.6) ( https://review.openstack.org/#/c/616505/ ) (stable/rocky > version). > > Then the openstack proposal bot submit a patch to requirements on stable > rocky to update the oslo.service version with the latest version (1.31.6) > but if we'll use it we'll then break the CI > https://review.openstack.org/#/c/618834/ so this patch is currently blocked > to avoid nova CI error. Huzzah for cross-project gateing! > # Issue > > Since the oslo.services threading changes were backported to rocky we risk > to faces the same issues inside the nova rocky CI if we update the > requirements. > > In parallel in oslo.service we have started to backport a new patch who > introduces fixture ( https://review.openstack.org/#/c/617989/ ) from > master to rocky, and also we start to backport on nova rocky branch ( > https://review.openstack.org/619019, https://review.openstack.org/619022 ) > patches who use oslo.service.fixture and who solve the nova CI issue. The > patch on oslo.service exposes a public oslo_service.fixture.SleepFixture > for this purpose. It can be maintained opaquely as internals change without > affecting its consumers. > > The main problem is that the patch bring a new functionality to a stable > branch (oslo.service rocky) but this patch help to fix the nova issue. > > Also openstack proposal bot submit a patch to requirements on stable rocky > to update the oslo.service version with the latest version (1.31.6) but if > we'll use it we'll then break the CI > https://review.openstack.org/#/c/618834/ since the oslo service 1.31.6 is > incompatible with novas stable rocky unittest due to the threading changes. > > # Questions and proposed solutions > > This thread try to summarize the current situation. > > We need to find how to be able to proceed, so this thread aim to allow to > discuss between team to find the best way to fix. > > 1. Do we need to continue to try to backport fixture on oslo.service to fix > the CI problem (https://review.openstack.org/#/c/617989/) ? Doing this is a violation of the stable policy. I get that the new feature is just a testing only fixture but that doesn't really matter it's still a feature. To use it consumers would need to raise the value for oslo.service in lower-constraints.txt which is a policy violation. The is an additional complication that this backport adds fixtures to requirements.txt for oslo.service, at the very least this would mean we're into a minor semver bump (1.32.X, which is already taken). This also means the vendors need to ensure that there is a 'fixtures' package available. Now I expect that all packagers have such a thing but there is a small chance that it exists as a build only package and needs to be exposed/published. We're previously said to vendors we wouldn't do that on stable branches. > 2. Do we need to find an another approach like mocking > oslo.service.loopingcall._Event.wait in nova instead of mocking > oslo_service.loopingcall._ThreadingEvent.wait (example: > https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py) > ? > This is only a fix on the nova side and it allows us to update oslo.service > requirements and allows us to fix the high CPU usage issue. I've submit > this patch (https://review.openstack.org/619246) who implement the > description above. > > Personaly I think we need to find an another approach like the mocking > remplacement (c.f 2). > > We need to decide which way we use and to discuss about other solutions. I think the only way forward is the revert, release and block path. The existing open reviews just add more policy violations. Yours Tony. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From gmann at ghanshyammann.com Thu Nov 22 06:26:52 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 22 Nov 2018 15:26:52 +0900 Subject: [openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04) In-Reply-To: References: <20181106210549.4nv6co64qbqk5l7f@skaplons-mac> <20181106212533.v6eapwxd2ksggrlo@yuggoth.org> <4C6DAE05-6FFB-4671-89DA-5EB07229DB26@redhat.com> <166eb10f8fb.117c25ba675341.116732651371514382@ghanshyammann.com> Message-ID: <1673a198ed5.ffd33ea931022.2184156112862411416@ghanshyammann.com> Hi All, Let's go with approach 1 means migrating the Devstack and Tempest base jobs to Bionic. This will move most of the jobs to Bionic. We have two patches up which move all Devstack and Tempest jobs to Bionic and it's working fine. 1. All DevStack jobs to Bionic - https://review.openstack.org/#/c/610977/ - This will move devstack-minimal, devstack, devstack-ipv6, devstack-multinode jobs to bionic only for master which means it will be stein onwards. All these jobs will use xenial till stable/rocky. 2. All Tempest base jobs (except stable branches job running on master) to Bionic - https://review.openstack.org/#/c/618169/ - This will move devstack-tempest, tempest-all, devstack-tempest-ipv6, tempest-full, tempest-full-py3, tempest-multinode-full, tempest-slow jobs to bionic. Note- Even Tempest is branchless and these tempest jobs have been moved to Bionic, they will still use xenial for all stable branches(till stable/rocky) testing. with zuulv3 magic and devstack base jobs nodeset for stable branch (xenial) and master (stein onwards -bionic) will take care of that. Tested on [1] and working fine. Thanks corvus and clarkb for guiding to this optimized way. 3. Legacy jobs are not migrated to bionic. They should get migrated to Bionic while they are moved to zuulv3 native. So if your projects have many legacy jobs then, they will still run on xenial. Any job inherits from those base jobs will behave the same way (running on bionic from stein onwards and xenial till stable/rocky). I am writing the plan and next action item to complete this migration activity: 1 Project teams: need to test their jobs 1. which are inherited from devstack/tempest base jobs and should pass as it is 2. Any zuulv3 jobs not using devstack/tempest base job required to migrate to use bionic (Devstack patch provide the bionic nodeset) and test it. Start writing the results on etherpad[2] 2 QA team will merge the above patches by 10th Dec so that we can find and fix any issues as early and to avoid the same during release time. Let's finish the pre-testing till 10th Dec and then merge the bionic migration patches. [1] https://review.openstack.org/#/c/618181/ https://review.openstack.org/#/c/618176/ [2] https://etherpad.openstack.org/p/devstack-bionic -gmann ---- On Wed, 07 Nov 2018 08:45:45 +0900 Doug Hellmann wrote ---- > Ghanshyam Mann writes: > > > ---- On Wed, 07 Nov 2018 06:51:32 +0900 Slawomir Kaplonski wrote ---- > > > Hi, > > > > > > > Wiadomość napisana przez Jeremy Stanley w dniu 06.11.2018, o godz. 22:25: > > > > > > > > On 2018-11-06 22:05:49 +0100 (+0100), Slawek Kaplonski wrote: > > > > [...] > > > >> also add jobs like "devstack-xenial" and "tempest-full-xenial" > > > >> which projects can use still for some time if their job on Bionic > > > >> would be broken now? > > > > [...] > > > > > > > > That opens the door to piecemeal migration, which (as we similarly > > > > saw during the Trusty to Xenial switch) will inevitably lead to > > > > projects who no longer gate on Xenial being unable to integration > > > > test against projects who don't yet support Bionic. At the same > > > > time, projects which have switched to Bionic will start merging > > > > changes which only work on Bionic without realizing it, so that > > > > projects which test on Xenial can't use them. In short, you'll be > > > > broken either way. On top of that, you can end up with projects that > > > > don't get around to switching completely before release comes, and > > > > then they're stuck having to manage a test platform transition on a > > > > stable branch. > > > > > > I understand Your point here but will option 2) from first email lead to the same issues then? > > > > seems so. approach 1 is less risky for such integrated testing issues and requires less work. In approach 1, we can coordinate the base job migration with project side testing with bionic. > > > > -gmann > > I like the approach of updating the devstack jobs to move everything to > Bionic at one time because it sounds like it presents less risk of us > ending up with something that looks like it works together but doesn't > actually because it's tested on a different platform, as well as being > less likely to cause us to have to do major porting work in stable > branches after the release. > > We'll need to take the same approach when updating the version of Python > 3 used inside of devstack. > > Doug > From hberaud at redhat.com Thu Nov 22 08:31:16 2018 From: hberaud at redhat.com (Herve Beraud) Date: Thu, 22 Nov 2018 09:31:16 +0100 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: <20181122045506.GC24690@thor.bakeyournoodle.com> References: <20181122045506.GC24690@thor.bakeyournoodle.com> Message-ID: Le jeu. 22 nov. 2018 à 05:55, Tony Breeds a écrit : > > HI folks, > I admit my initial response to this was mor pragmatic 'take the > bakport' but as I thought it through I saw more problems with that > approach. > > On Wed, Nov 21, 2018 at 03:47:25PM +0100, Herve Beraud wrote: > > > Since these changes was introduced into oslo.service master, nova facing > > some issues into the master CI process, due to the threading changes, and > > they was fixed by these patches ( > https://review.openstack.org/#/c/615724/, > > https://review.openstack.org/#/c/617989/ ) into master. > > > > Few weeks ago I have backport to oslo.service some changes ( > > https://review.openstack.org/#/c/614489/ ) from master to stable/rocky > to > > also fix the problem in the rocky release. > > Okay that was a mistake, backporting a patch from master to stable that > is known to break consumers, I admit this isn't explicitly called out in > the stable policy but it is kind of the spirit of the stable policy. > > The quickest fix would be to revert 614489, release 1.31.7 and blacklist > 1.31.6. > > Yes this leaves the High CPU usage bug open on rocky. That isn't great > but it also isn't terrible. > > > When this backport was merged we have created a new release of > oslo.service > > (1.31.6) ( https://review.openstack.org/#/c/616505/ ) (stable/rocky > > version). > > > > Then the openstack proposal bot submit a patch to requirements on stable > > rocky to update the oslo.service version with the latest version (1.31.6) > > but if we'll use it we'll then break the CI > > https://review.openstack.org/#/c/618834/ so this patch is currently > blocked > > to avoid nova CI error. > > Huzzah for cross-project gateing! > > > # Issue > > > > Since the oslo.services threading changes were backported to rocky we > risk > > to faces the same issues inside the nova rocky CI if we update the > > requirements. > > > > In parallel in oslo.service we have started to backport a new patch who > > introduces fixture ( https://review.openstack.org/#/c/617989/ ) from > > master to rocky, and also we start to backport on nova rocky branch ( > > https://review.openstack.org/619019, https://review.openstack.org/619022 > ) > > patches who use oslo.service.fixture and who solve the nova CI issue. The > > patch on oslo.service exposes a public oslo_service.fixture.SleepFixture > > for this purpose. It can be maintained opaquely as internals change > without > > affecting its consumers. > > > > The main problem is that the patch bring a new functionality to a stable > > branch (oslo.service rocky) but this patch help to fix the nova issue. > > > > Also openstack proposal bot submit a patch to requirements on stable > rocky > > to update the oslo.service version with the latest version (1.31.6) but > if > > we'll use it we'll then break the CI > > https://review.openstack.org/#/c/618834/ since the oslo service 1.31.6 > is > > incompatible with novas stable rocky unittest due to the threading > changes. > > > > # Questions and proposed solutions > > > > This thread try to summarize the current situation. > > > > We need to find how to be able to proceed, so this thread aim to allow to > > discuss between team to find the best way to fix. > > > > 1. Do we need to continue to try to backport fixture on oslo.service to > fix > > the CI problem (https://review.openstack.org/#/c/617989/) ? > > Doing this is a violation of the stable policy. I get that the new > feature is just a testing only fixture but that doesn't really matter > it's still a feature. To use it consumers would need to raise > the value for oslo.service in lower-constraints.txt which is a policy > violation. > > The is an additional complication that this backport adds fixtures to > requirements.txt for oslo.service, at the very least this would mean > we're into a minor semver bump (1.32.X, which is already taken). This > also means the vendors need to ensure that there is a 'fixtures' package > available. Now I expect that all packagers have such a thing but there > is a small chance that it exists as a build only package and needs to be > exposed/published. We're previously said to vendors we wouldn't do that > on stable branches. > I agree this solution come with a minor bump and issues to keep the semver coherent. > > > 2. Do we need to find an another approach like mocking > > oslo.service.loopingcall._Event.wait in nova instead of mocking > > oslo_service.loopingcall._ThreadingEvent.wait (example: > > > https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py > ) > > ? > > This is only a fix on the nova side and it allows us to update > oslo.service > > requirements and allows us to fix the high CPU usage issue. I've submit > > this patch (https://review.openstack.org/619246) who implement the > > description above. > > > > Personaly I think we need to find an another approach like the mocking > > remplacement (c.f 2). > > > > We need to decide which way we use and to discuss about other solutions. > > I think the only way forward is the revert, release and block path. The > existing open reviews just add more policy violations. > > Yours Tony. > -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Thu Nov 22 08:36:45 2018 From: hberaud at redhat.com (Herve Beraud) Date: Thu, 22 Nov 2018 09:36:45 +0100 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: References: <20181122045506.GC24690@thor.bakeyournoodle.com> Message-ID: I'm waiting for a consensus between us to update my reviews if needed or abandon them in the case we choose an another approach. Le jeu. 22 nov. 2018 à 09:31, Herve Beraud a écrit : > > > Le jeu. 22 nov. 2018 à 05:55, Tony Breeds a > écrit : > >> >> HI folks, >> I admit my initial response to this was mor pragmatic 'take the >> bakport' but as I thought it through I saw more problems with that >> approach. >> >> On Wed, Nov 21, 2018 at 03:47:25PM +0100, Herve Beraud wrote: >> >> > Since these changes was introduced into oslo.service master, nova facing >> > some issues into the master CI process, due to the threading changes, >> and >> > they was fixed by these patches ( >> https://review.openstack.org/#/c/615724/, >> > https://review.openstack.org/#/c/617989/ ) into master. >> > >> > Few weeks ago I have backport to oslo.service some changes ( >> > https://review.openstack.org/#/c/614489/ ) from master to stable/rocky >> to >> > also fix the problem in the rocky release. >> >> Okay that was a mistake, backporting a patch from master to stable that >> is known to break consumers, I admit this isn't explicitly called out in >> the stable policy but it is kind of the spirit of the stable policy. >> >> The quickest fix would be to revert 614489, release 1.31.7 and blacklist >> 1.31.6. >> >> Yes this leaves the High CPU usage bug open on rocky. That isn't great >> but it also isn't terrible. >> >> > When this backport was merged we have created a new release of >> oslo.service >> > (1.31.6) ( https://review.openstack.org/#/c/616505/ ) (stable/rocky >> > version). >> > >> > Then the openstack proposal bot submit a patch to requirements on stable >> > rocky to update the oslo.service version with the latest version >> (1.31.6) >> > but if we'll use it we'll then break the CI >> > https://review.openstack.org/#/c/618834/ so this patch is currently >> blocked >> > to avoid nova CI error. >> >> Huzzah for cross-project gateing! >> >> > # Issue >> > >> > Since the oslo.services threading changes were backported to rocky we >> risk >> > to faces the same issues inside the nova rocky CI if we update the >> > requirements. >> > >> > In parallel in oslo.service we have started to backport a new patch who >> > introduces fixture ( https://review.openstack.org/#/c/617989/ ) from >> > master to rocky, and also we start to backport on nova rocky branch ( >> > https://review.openstack.org/619019, >> https://review.openstack.org/619022 ) >> > patches who use oslo.service.fixture and who solve the nova CI issue. >> The >> > patch on oslo.service exposes a public oslo_service.fixture.SleepFixture >> > for this purpose. It can be maintained opaquely as internals change >> without >> > affecting its consumers. >> > >> > The main problem is that the patch bring a new functionality to a stable >> > branch (oslo.service rocky) but this patch help to fix the nova issue. >> > >> > Also openstack proposal bot submit a patch to requirements on stable >> rocky >> > to update the oslo.service version with the latest version (1.31.6) but >> if >> > we'll use it we'll then break the CI >> > https://review.openstack.org/#/c/618834/ since the oslo service 1.31.6 >> is >> > incompatible with novas stable rocky unittest due to the threading >> changes. >> > >> > # Questions and proposed solutions >> > >> > This thread try to summarize the current situation. >> > >> > We need to find how to be able to proceed, so this thread aim to allow >> to >> > discuss between team to find the best way to fix. >> > >> > 1. Do we need to continue to try to backport fixture on oslo.service to >> fix >> > the CI problem (https://review.openstack.org/#/c/617989/) ? >> >> Doing this is a violation of the stable policy. I get that the new >> feature is just a testing only fixture but that doesn't really matter >> it's still a feature. To use it consumers would need to raise >> the value for oslo.service in lower-constraints.txt which is a policy >> violation. >> >> The is an additional complication that this backport adds fixtures to >> requirements.txt for oslo.service, at the very least this would mean >> we're into a minor semver bump (1.32.X, which is already taken). This >> also means the vendors need to ensure that there is a 'fixtures' package >> available. Now I expect that all packagers have such a thing but there >> is a small chance that it exists as a build only package and needs to be >> exposed/published. We're previously said to vendors we wouldn't do that >> on stable branches. >> > > I agree this solution come with a minor bump and issues to keep the semver > coherent. > > >> >> > 2. Do we need to find an another approach like mocking >> > oslo.service.loopingcall._Event.wait in nova instead of mocking >> > oslo_service.loopingcall._ThreadingEvent.wait (example: >> > >> https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py >> ) >> > ? >> > This is only a fix on the nova side and it allows us to update >> oslo.service >> > requirements and allows us to fix the high CPU usage issue. I've submit >> > this patch (https://review.openstack.org/619246) who implement the >> > description above. >> > >> > Personaly I think we need to find an another approach like the mocking >> > remplacement (c.f 2). >> > >> > We need to decide which way we use and to discuss about other solutions. >> >> I think the only way forward is the revert, release and block path. The >> existing open reviews just add more policy violations. >> > >> Yours Tony. >> > > > -- > Hervé Beraud > Senior Software Engineer > Red Hat - Openstack Oslo > irc: hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyarwood at redhat.com Thu Nov 22 09:46:51 2018 From: lyarwood at redhat.com (Lee Yarwood) Date: Thu, 22 Nov 2018 09:46:51 +0000 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: <20181122045506.GC24690@thor.bakeyournoodle.com> References: <20181122045506.GC24690@thor.bakeyournoodle.com> Message-ID: <20181122094651.v6htgbzmuympyn57@lyarwood.usersys.redhat.com> On 22-11-18 15:55:07, Tony Breeds wrote: > > HI folks, > I admit my initial response to this was mor pragmatic 'take the > bakport' but as I thought it through I saw more problems with that > approach. > > On Wed, Nov 21, 2018 at 03:47:25PM +0100, Herve Beraud wrote: > > > Since these changes was introduced into oslo.service master, nova facing > > some issues into the master CI process, due to the threading changes, and > > they was fixed by these patches ( https://review.openstack.org/#/c/615724/, > > https://review.openstack.org/#/c/617989/ ) into master. > > > > Few weeks ago I have backport to oslo.service some changes ( > > https://review.openstack.org/#/c/614489/ ) from master to stable/rocky to > > also fix the problem in the rocky release. > > Okay that was a mistake, backporting a patch from master to stable that > is known to break consumers, I admit this isn't explicitly called out in > the stable policy but it is kind of the spirit of the stable policy. > > The quickest fix would be to revert 614489, release 1.31.7 and blacklist > 1.31.6. > > Yes this leaves the High CPU usage bug open on rocky. That isn't great > but it also isn't terrible. Agreed, I'm in favor of doing this and asking the oslo.service team to rework the original fix on stable/rocky into something that doesn't break Nova CI. > > When this backport was merged we have created a new release of oslo.service > > (1.31.6) ( https://review.openstack.org/#/c/616505/ ) (stable/rocky > > version). > > > > Then the openstack proposal bot submit a patch to requirements on stable > > rocky to update the oslo.service version with the latest version (1.31.6) > > but if we'll use it we'll then break the CI > > https://review.openstack.org/#/c/618834/ so this patch is currently blocked > > to avoid nova CI error. > > Huzzah for cross-project gateing! > > > # Issue > > > > Since the oslo.services threading changes were backported to rocky we risk > > to faces the same issues inside the nova rocky CI if we update the > > requirements. > > > > In parallel in oslo.service we have started to backport a new patch who > > introduces fixture ( https://review.openstack.org/#/c/617989/ ) from > > master to rocky, and also we start to backport on nova rocky branch ( > > https://review.openstack.org/619019, https://review.openstack.org/619022 ) > > patches who use oslo.service.fixture and who solve the nova CI issue. The > > patch on oslo.service exposes a public oslo_service.fixture.SleepFixture > > for this purpose. It can be maintained opaquely as internals change without > > affecting its consumers. > > > > The main problem is that the patch bring a new functionality to a stable > > branch (oslo.service rocky) but this patch help to fix the nova issue. > > > > Also openstack proposal bot submit a patch to requirements on stable rocky > > to update the oslo.service version with the latest version (1.31.6) but if > > we'll use it we'll then break the CI > > https://review.openstack.org/#/c/618834/ since the oslo service 1.31.6 is > > incompatible with novas stable rocky unittest due to the threading changes. > > > > # Questions and proposed solutions > > > > This thread try to summarize the current situation. > > > > We need to find how to be able to proceed, so this thread aim to allow to > > discuss between team to find the best way to fix. > > > > 1. Do we need to continue to try to backport fixture on oslo.service to fix > > the CI problem (https://review.openstack.org/#/c/617989/) ? > > Doing this is a violation of the stable policy. I get that the new > feature is just a testing only fixture but that doesn't really matter > it's still a feature. To use it consumers would need to raise > the value for oslo.service in lower-constraints.txt which is a policy > violation. I'm being slightly dense this morning, I can't seem to find a reference to this lower-constraints.txt policy anywhere in the stable docs: https://docs.openstack.org/project-team-guide/stable-branches.html > The is an additional complication that this backport adds fixtures to > requirements.txt for oslo.service, at the very least this would mean > we're into a minor semver bump (1.32.X, which is already taken). This > also means the vendors need to ensure that there is a 'fixtures' package > available. Now I expect that all packagers have such a thing but there > is a small chance that it exists as a build only package and needs to be > exposed/published. We're previously said to vendors we wouldn't do that > on stable branches. I wouldn't be concerned with the impact on packagers and more that we can't use 1.32.x anyway thus blocking this approach. > > 2. Do we need to find an another approach like mocking > > oslo.service.loopingcall._Event.wait in nova instead of mocking > > oslo_service.loopingcall._ThreadingEvent.wait (example: > > https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py) > > ? > > This is only a fix on the nova side and it allows us to update oslo.service > > requirements and allows us to fix the high CPU usage issue. I've submit > > this patch (https://review.openstack.org/619246) who implement the > > description above. > > > > Personaly I think we need to find an another approach like the mocking > > remplacement (c.f 2). > > > > We need to decide which way we use and to discuss about other solutions. > > I think the only way forward is the revert, release and block path. The > existing open reviews just add more policy violations. Again I agree. Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: not available URL: From Bhagyashri.Shewale at nttdata.com Thu Nov 22 10:04:32 2018 From: Bhagyashri.Shewale at nttdata.com (Shewale, Bhagyashri) Date: Thu, 22 Nov 2018 10:04:32 +0000 Subject: [openstack-dev][tacker] seeking feedback for HealVnfRequest implementation Message-ID: Hi All, As discussed in the summit, "vdu_autoheal" monitoring policy action implementation should be as per ETSI standard HealVnfRequest interface [1] (refer comment given on patch https://review.openstack.org/#/c/612595/9 ) Started working on the same but have some quires so needs some feedback and inputs. As per the ETSI doc [1] the data model for HealVnfRequest contains two request parameters (cause anddditionalParams) (Check section: 5.5.2.9 Type: HealVnfReques from [1]) The Request Payload for HealVnfRequest (ETSI data structure: HealVnfRequest) should be the dictionary as mentioned in [2] (Check section: Healing VNFs Using ETSI API from [2]) But the “addtionalParams” parameter should be part of "HealVnfOpConfig” and that expects two parameters (cause and parameter) as mentioned in [3] (Check section: 7.1.5.6 HealVnfOpConfig information element from [3]) So accordingly I have designed the request data for vdu_autoheal monitoring policy action as below: Heal Request Data for monitoring: { "cause": "", "additionalParams": [ {“parameter”: , “cause”: []}, {“parameter”: , “cause”: [ From cdent+os at anticdent.org Thu Nov 22 11:57:24 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Thu, 22 Nov 2018 11:57:24 +0000 (GMT) Subject: [oslo] [config] Using environment variables for config options Message-ID: I don't recall seeing any specific announcement for this, and I think it is a pretty useful feature, so I thought I'd write about some functionality that I added to oslo.config and was released in 6.7.0. Especially since a lot of people I've mentioned this to thought we already had it. The new version is able to satisfy any registered config option by looking in the process environment for a variable with a predictable name and using its value if set. Options are satisfied in this order: * command line args * environment * config file(s) * everything else (using the new(ish) "sources" concept) In the past it was possible to get config from the environment if the option had been pre-defined as using something in the environment as its default. This new way is much more flexible, and in my experience ideal for container-based environments where you would like an immutable container but want small differences between multiple instances of the same container to be easy to control. Or if you don't need much config at all, you can avoid using a config file entirely. I've been using this with placement, where it's possible to set up a testable placement service with just two environment variables: OS_PLACEMENT_DATABASE__CONNECTION=mysql+pymysql://root:secret at 127.0.0.1/placement?charset=utf8 OS_API__AUTH_STRATEGY=noauth2 This shows the pattern of the environment variable name: OS___ There are some docs at https://docs.openstack.org/oslo.config/latest/reference/drivers.html#module-oslo_config.sources._environment I hope this proves as useful for other people as it has for me. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From ifatafekn at gmail.com Thu Nov 22 12:30:20 2018 From: ifatafekn at gmail.com (Ifat Afek) Date: Thu, 22 Nov 2018 14:30:20 +0200 Subject: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage. In-Reply-To: References: Message-ID: Hi, A deleted instance should be removed from Vitrage in one of two ways: 1. By reacting to a notification from Nova 2. If no notification is received, then after a while the instance vertex in Vitrage is considered "outdated" and is deleted Regarding #1, it is clear from your logs that you don't get notifications from Nova on the second compute. Do you have on one of your nodes, in addition to nova.conf, also a nova-cpu.conf? if so, please make the same change in this file: notification_topics = notifications,vitrage_notifications notification_driver = messagingv2 And please make sure to restart nova compute service on that node. Regarding #2, as a second-best solution, the instances should be deleted from the graph after not being updated for a while. I realized that we have a bug in this area and I will push a fix to gerrit later today. In the meantime, you can add to InstanceDriver class the following function: @staticmethod def should_delete_outdated_entities(): return True Let me know if it solved your problem, Ifat On Wed, Nov 21, 2018 at 1:50 PM Won wrote: > I attached four log files. > I collected the logs from about 17:14 to 17:42. I created an instance of > 'deltesting3' at 17:17. 7minutes later, at 17:24, the entity graph showed > the dentesting3 and vitrage colletor and graph logs are appeared. > When creating an instance in ubuntu server, it appears immediately in the > entity graph and logs, but when creating an instance in computer1 (multi > node), it appears about 5~10 minutes later. > I deleted an instance of 'deltesting3' around 17:26. > > >> After ~20minutes, there was only Apigateway. Does it make sense? did you >> delete the instances on ubuntu, in addition to deltesting? >> > > I only deleted 'deltesting'. After that, only the logs from 'apigateway' > and 'kube-master' were collected. But other instances were working well. I > don't know why only two instances are collected in the log. > NOV 19 In this log, 'agigateway' and 'kube-master' were continuously > collected in a short period of time, but other instances were sometimes > collected in long periods. > > In any case, I would expect to see the instances deleted from the graph at >> this stage, since they were not returned by get_all. >> Can you please send me the log of vitrage-graph at the same time (Nov 15, >> 16:35-17:10)? >> > > Information 'deldtesting3' that has already been deleted continues to be > collected in vitrage-graph.service. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From moguimar at redhat.com Thu Nov 22 13:15:11 2018 From: moguimar at redhat.com (Moises Guimaraes de Medeiros) Date: Thu, 22 Nov 2018 14:15:11 +0100 Subject: [oslo] [config] Using environment variables for config options In-Reply-To: References: Message-ID: Chris, Have you thought on how to populate options of type ListOpt like DEFAULT/config_source? [ ]'s Moisés Em qui, 22 de nov de 2018 às 12:57, Chris Dent escreveu: > > > I don't recall seeing any specific announcement for this, and I > think it is a pretty useful feature, so I thought I'd write about > some functionality that I added to oslo.config and was released in > 6.7.0. Especially since a lot of people I've mentioned this to > thought we already had it. > > The new version is able to satisfy any registered config option by > looking in the process environment for a variable with a predictable > name and using its value if set. Options are satisfied in this > order: > > * command line args > * environment > * config file(s) > * everything else (using the new(ish) "sources" concept) > > In the past it was possible to get config from the environment if > the option had been pre-defined as using something in the > environment as its default. > > This new way is much more flexible, and in my experience ideal for > container-based environments where you would like an immutable > container but want small differences between multiple instances of > the same container to be easy to control. Or if you don't need much > config at all, you can avoid using a config file entirely. > > I've been using this with placement, where it's possible to set up a > testable placement service with just two environment variables: > > OS_PLACEMENT_DATABASE__CONNECTION=mysql+pymysql://root:secret at 127.0.0.1/placement?charset=utf8 > OS_API__AUTH_STRATEGY=noauth2 > > This shows the pattern of the environment variable name: > > OS___ > > There are some docs at https://docs.openstack.org/oslo.config/latest/reference/drivers.html#module-oslo_config.sources._environment > > I hope this proves as useful for other people as it has for me. > > -- > Chris Dent ٩◔̯◔۶ https://anticdent.org/ > freenode: cdent tw: @anticdent From ahm.jawad118 at gmail.com Thu Nov 22 10:03:54 2018 From: ahm.jawad118 at gmail.com (Jawad Ahmed) Date: Thu, 22 Nov 2018 11:03:54 +0100 Subject: [Openstack-operators] openstack-annsible networking layout before running playbooks Message-ID: Hi all, I am deploying openstack-ansible in test environment where I need to use br-mgmt bridge for both storage and management traffic (same bridge for both) so that container interfaces eth1 and eth2 will connect to br-mgmt for mgmt and storage traffic at same time.Does it make sense if I ll setup provider networks openstack_user_config.yml as below? tunnel_bridge: "br-vxlan" //separate bridge for vxlan though management_bridge: "br-mgmt" provider_networks: - network: container_bridge: "br-mgmt" container_type: "veth" container_interface: "eth1" ip_from_q: "container" type: "raw" group_binds: - all_containers - hosts is_container_address: true is_ssh_address: true - network: container_bridge: "br-mgmt" container_type: "veth" container_interface: "eth2" ip_from_q: "storage" type: "raw" group_binds: - glance_api - cinder_api - cinder_volume - nova_compute Help would be appreciated. -- Greetings, Jawad Ahmed -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From zigo at debian.org Thu Nov 22 15:01:14 2018 From: zigo at debian.org (Thomas Goirand) Date: Thu, 22 Nov 2018 16:01:14 +0100 Subject: [oslo] [config] Using environment variables for config options In-Reply-To: References: Message-ID: <69b7d7eb-1852-465a-7661-874e5ac58972@debian.org> On 11/22/18 12:57 PM, Chris Dent wrote: > I hope this proves as useful for other people as it has for me. It really is useful. Thanks a lot for writing this and telling about it. Cheers, Thomas Goirand (zigo) From thierry at openstack.org Thu Nov 22 16:26:11 2018 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 22 Nov 2018 17:26:11 +0100 Subject: [forum] Summary of the "Better expose what we produce" session Message-ID: <0d6683cd-67ea-10eb-1da1-8c8098284795@openstack.org> Hi everyone, The OpenStack community produces a complex landscape of services and other deliverables. Presenting those to the rest of the world in a way that is comprehensive, makes sense and is not overwhelming has been a constant challenge. During this forum session in Berlin we presented the status of various efforts and websites, and discussed next steps. You can see the notes of the session at: https://etherpad.openstack.org/p/BER-better-expose-what-we-produce The plan going forward is to: 1. Continue improving the information presented on openstack.org/software and make more elements driven by the openstack/openstack-map repository YAML files. Immediate next steps include rolling out a new "Overview" page, providing an example YAML template, adding project update video links to the YAML for easier update, and finishing compiling "dependency" information from teams. We will also consider adding diagrams, although it creates a lot of consistency challenges. 2. Make the pages less about the teams and more about the software. That involves creating team pages (or enriching those from the governance website) and link to them instead of displaying information on the software page. 3. Brainstorm ways to move the "drivers list" (currently displayed in the "marketplace" using outdated data from stackalytics Drivers page) directly on the software page 4. For deployment tools, include data from the deployment tool comparison effort (discussed in another session), and consider making room for third-party tools as well. Also as a comparison point see https://kubernetes.io/docs/setup/pick-right-solution/ 5. For SDKs, include non-developed-locally language SDKs in a separate tab, and engage with the groups working on SDK certification / validation to see if there is any additional information we can show. Also as a comparison point see https://kubernetes.io/docs/reference/using-api/client-libraries/ Thanks ! -- Thierry Carrez (ttx) From hberaud at redhat.com Thu Nov 22 16:58:08 2018 From: hberaud at redhat.com (Herve Beraud) Date: Thu, 22 Nov 2018 17:58:08 +0100 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: References: Message-ID: Just a tiny report to summarize the situation to offer a big picture and to analyze proposed solutions since peoples have submits new patches and some other people have shared their opinions. Each solution contains the impacted projects, the related gerrit reviews, pro/cons. ### 1 - Backport master changer and also backport new feature into a stable branch impacted projects: oslo.service, nova related reviews: - https://review.openstack.org/617989 - https://review.openstack.org/619022 - https://review.openstack.org/619019 pros: - follow the master changes - just use a backport cons: - backport a new feature into a stable branch and then this a violation of the stable policy - introduce a semver minor bump and a version 1.32 already exist - won't be able to use either an older nova with a newer oslo.service - increasing lower-constraints is not allowed on stable branches - vendors need to ensure that there is a 'fixture' package available ### 2 - Update the nova test to mock the new private interface impacted projects: nova reviews: - https://review.openstack.org/619246 pros: - straightforward cons: - still mocking a private inferface - stable only patches ### 3 - Maintain a private interface for ThreadingEvent only on stable/rocky impacted projects: oslo.service related reviews: - https://review.openstack.org/619342/ pros: - straightforward cons: - Changing the loopingcall module semantics as it is different type - stable only patches - misunderstoud service customer between Threading, eventlet, etc.. and master behavior ### 4 - Don't use private interface in oslo.service impacted projects: nova related reviews: - https://review.openstack.org/#/c/619360/ pros: - straightforward cons: - this could work but it is not the same sematics as before as the type has changed - stable only patches - misunderstoud service customer between Threading, eventlet, etc.. and master behavior ### 5 - Leave the CPU bug open on rocky impacted projects: oslo.service related reviews: - pros: - Nova project doesn't impacted cons: - reintroduce the CPU issue ### 6 - Revert CPU fix and totally rework it into someting that doesn't break the Nova CI impacted projects: oslo.service related reviews: - pros: - Nova project doesn't impacted cons: - potentially introduce more rewrites in the futures that depends on fix on oslo.service loopingcall master - stable only patches - increase potential backport difficulties on oslo.service upstream and downstream - increase work load on upstream and downstream Personally: - I prefer the #4 or the #2 and they seem to be smooth changes without earthquake or anything like this - the #6 seems to be the worst solution on my side - the #1 introduce semver issue and policy violations so I don't think we can continue with it Thoughts? I hope this summarize help you to have a better overview :) I hope I have not forgotten anything and if so I apologize in advance. Le mer. 21 nov. 2018 à 15:47, Herve Beraud a écrit : > Hey all! > > Here is a thread to coordinate all the teams (oslo, nova, stable, > requirements) working on the update of the oslo.service constraint in the > Rocky requirements. > > # Summary > > Usage of threading event with eventlet caused inefficient code (causing > many useless system calls and high CPU usage). > This issue was already fixed on oslo.service master and we also want to > fix it in stable/rocky. > > Our main issue is how to fix the high CPU usage on stable/rocky without > break the nova CI. > > Indeed, we already have backported the eventlet related fix to > oslo.service but this fix requires also a nova update to avoid nova CI > errors due to threading removal on oslo.service that introduce the nova CI > errors. > > A fix was proposed and merged on oslo.service master to introduce a new > feature (fixture) that avoid the nova CI errors, but > backporting the master fix to Rocky introduces a new feature into a > stable branch so this is also an issue. > > So we need to discuss with all the teams to find a proper solution. > > # History > > A few weeks ago this issue was opened on oslo.service ( > https://bugs.launchpad.net/oslo.service/+bug/1798774) and it was fixed by > this submited patch on the master branch ( > https://review.openstack.org/#/c/611807/ ). > > This change use the proper event primitive to fix the performance issue. > > A new version of oslo.service was released (1.32.1) > > Since these changes was introduced into oslo.service master, nova facing > some issues into the master CI process, due to the threading changes, and > they was fixed by these patches ( https://review.openstack.org/#/c/615724/, > https://review.openstack.org/#/c/617989/ ) into master. > > Few weeks ago I have backport to oslo.service some changes ( > https://review.openstack.org/#/c/614489/ ) from master to stable/rocky to > also fix the problem in the rocky release. > > When this backport was merged we have created a new release of > oslo.service (1.31.6) ( https://review.openstack.org/#/c/616505/ ) > (stable/rocky version). > > Then the openstack proposal bot submit a patch to requirements on stable > rocky to update the oslo.service version with the latest version (1.31.6) > but if we'll use it we'll then break the CI > https://review.openstack.org/#/c/618834/ so this patch is currently > blocked to avoid nova CI error. > > # Issue > > Since the oslo.services threading changes were backported to rocky we > risk to faces the same issues inside the nova rocky CI if we update the > requirements. > > In parallel in oslo.service we have started to backport a new patch who > introduces fixture ( https://review.openstack.org/#/c/617989/ ) from > master to rocky, and also we start to backport on nova rocky branch ( > https://review.openstack.org/619019, https://review.openstack.org/619022 > ) patches who use oslo.service.fixture and who solve the nova CI issue. The > patch on oslo.service exposes a public oslo_service.fixture.SleepFixture > for this purpose. It can be maintained opaquely as internals change without > affecting its consumers. > > The main problem is that the patch bring a new functionality to a stable > branch (oslo.service rocky) but this patch help to fix the nova issue. > > Also openstack proposal bot submit a patch to requirements on stable rocky > to update the oslo.service version with the latest version (1.31.6) but if > we'll use it we'll then break the CI > https://review.openstack.org/#/c/618834/ since the oslo service 1.31.6 is > incompatible with novas stable rocky unittest due to the threading changes. > > # Questions and proposed solutions > > This thread try to summarize the current situation. > > We need to find how to be able to proceed, so this thread aim to allow to > discuss between team to find the best way to fix. > > 1. Do we need to continue to try to backport fixture on oslo.service to > fix the CI problem (https://review.openstack.org/#/c/617989/) ? > > 2. Do we need to find an another approach like mocking > oslo.service.loopingcall._Event.wait in nova instead of mocking > oslo_service.loopingcall._ThreadingEvent.wait (example: > https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py) > ? > This is only a fix on the nova side and it allows us to update > oslo.service requirements and allows us to fix the high CPU usage issue. > I've submit this patch (https://review.openstack.org/619246) who > implement the description above. > > Personaly I think we need to find an another approach like the mocking > remplacement (c.f 2). > > We need to decide which way we use and to discuss about other solutions. > > -- > Hervé Beraud > Senior Software Engineer > Red Hat - Openstack Oslo > irc: hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Thu Nov 22 15:10:04 2018 From: mnaser at vexxhost.com (Mohammed Naser) Date: Thu, 22 Nov 2018 10:10:04 -0500 Subject: [Openstack-operators] openstack-annsible networking layout before running playbooks In-Reply-To: References: Message-ID: Hey there, You can just have one br-mgmt and skip the second one and everything will go over br-mgmt :) Thanks, Mohammed On Thu, Nov 22, 2018 at 5:05 AM Jawad Ahmed wrote: > Hi all, > I am deploying openstack-ansible in test environment where I need to use > br-mgmt bridge for both storage and management traffic (same bridge for > both) so that container interfaces eth1 and eth2 will connect to br-mgmt > for mgmt and storage traffic at same time.Does it make sense if I ll setup > provider networks openstack_user_config.yml as below? > > tunnel_bridge: "br-vxlan" //separate bridge for vxlan though > management_bridge: "br-mgmt" > > provider_networks: > - network: > container_bridge: "br-mgmt" > container_type: "veth" > container_interface: "eth1" > ip_from_q: "container" > type: "raw" > group_binds: > - all_containers > - hosts > is_container_address: true > is_ssh_address: true > > > - network: > container_bridge: "br-mgmt" > container_type: "veth" > container_interface: "eth2" > ip_from_q: "storage" > type: "raw" > group_binds: > - glance_api > - cinder_api > - cinder_volume > - nova_compute > > Help would be appreciated. > > -- > Greetings, > Jawad Ahmed > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser at vexxhost.com W. http://vexxhost.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From pkliczew at redhat.com Thu Nov 22 15:23:31 2018 From: pkliczew at redhat.com (Piotr Kliczewski) Date: Thu, 22 Nov 2018 16:23:31 +0100 Subject: [Openstack] =?utf-8?q?Fwd=3A__FOSDEM=E2=80=9819_Virtualization_?= =?utf-8?q?=26_IaaS_Devroom_CfP?= In-Reply-To: References: Message-ID: A friendly reminder that Cfp is due by 1st of December. Please submit your proposal using: https://penta.fosdem.org/submission/FOSDEM19 ---------- Forwarded message --------- From: Piotr Kliczewski Date: Wed, Oct 17, 2018 at 9:41 AM Subject: [Openstack] FOSDEM‘19 Virtualization & IaaS Devroom CfP To: We are excited to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2019, to be hosted on February 2nd 2019. This year will mark FOSDEM’s 19th anniversary as one of the longest-running free and open source software developer events, attracting thousands of developers and users from all over the world. FOSDEM will be held once again in Brussels, Belgium, on February 2nd & 3rd, 2019. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, oVirt, QEMU, KVM, and Foreman. We would like to invite all those who are involved in these fields to submit your proposals by December 1st, 2018. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors and virtual machine managers such as Xen Project, KVM, bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, oVirt, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Important Dates Submission deadline: 1 December 2019 Acceptance notifications: 14 December 2019 Final schedule announcement: 21 December 2019 Devroom: 2nd February 2019 Submit Your Proposal All submissions must be made via the Pentabarf event planning site[1]. If you have not used Pentabarf before, you will need to create an account. If you submitted proposals for FOSDEM in previous years, you can use your existing account. After creating the account, select Create Event to start the submission process. Make sure to select Virtualization and IaaS devroom from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. Submission Guidelines We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, ." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Speaker Mentoring Program As a part of the rising efforts to grow our communities and encourage a diverse and inclusive conference ecosystem, we're happy to announce that we'll be offering mentoring for new speakers. Our mentors can help you with tasks such as reviewing your abstract, reviewing your presentation outline or slides, or practicing your talk with you. You may apply to the mentoring program as a newcomer speaker if you: Never presented before or Presented only lightning talks or Presented full-length talks at small meetups (<50 ppl) Submission Guidelines Mentored presentations will have 25-minute slots, where 20 minutes will include the presentation and 5 minutes will be reserved for questions. The number of newcomer session slots is limited, so we will probably not be able to accept all applications. You must submit your talk and abstract to apply for the mentoring program, our mentors are volunteering their time and will happily provide feedback but won't write your presentation for you! If you are experiencing problems with Pentabarf, the proposal submission interface, or have other questions, you can email our devroom mailing list[2] and we will try to help you. How to Apply In addition to agreeing to video recording and confirming that you can attend FOSDEM in case your session is accepted, please write "speaker mentoring program application" in the "Submission notes" field, and list any prior speaking experience or other relevant information for your application. Call for Mentors Interested in mentoring newcomer speakers? We'd love to have your help! Please email iaas-virt-devroom at lists.fosdem.org with a short speaker biography and any specific fields of expertise (for example, KVM, OpenStack, storage, etc.) so that we can match you with a newcomer speaker from a similar field. Estimated time investment can be as low as a 5-10 hours in total, usually distributed weekly or bi-weekly. Never mentored a newcomer speaker but interested to try? As the mentoring program coordinator, email Brian Proffitt[3] and he will be happy to answer your questions! Code of Conduct Following the release of the updated code of conduct for FOSDEM, we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Call for Volunteers We are also looking for volunteers to help run the devroom. We need assistance watching time for the speakers, and helping with video for the devroom. Please contact Brian Proffitt, for more information. Questions? If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] https://penta.fosdem.org/submission/FOSDEM19 [2] iaas-virt-devroom at lists.fosdem.org [3] bkp at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From cdent+os at anticdent.org Thu Nov 22 19:19:38 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Thu, 22 Nov 2018 19:19:38 +0000 (GMT) Subject: [all] maintainers/reviewers/committers wanted for tiny projects In-Reply-To: References: Message-ID: On Mon, 19 Nov 2018, Chris Dent wrote: > Paste: WSGI middleware management framework > https://github.com/cdent/paste > This was recently adopted because it had issues with Python 3.7 > and there were concerns that OpenStack's continued use might > present problems. > > I've also just inherited the pastedeploy package, and will be > migrating it over to github too. It will also need some help. In a nice stroke of luck, the Pylons project noticed pastedeploy was moving and we've worked out that is should live under their github organization: https://github.com/Pylons/pastedeploy -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From smooney at redhat.com Thu Nov 22 21:01:18 2018 From: smooney at redhat.com (Sean Mooney) Date: Thu, 22 Nov 2018 21:01:18 +0000 Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack master In-Reply-To: References: Message-ID: hi just following up form yesterday. i just finished testing the pci numa policy feature and i can confirm that the prefer policy which allow use of non local pci devices does not work. the test case was relitively simple 1 host with 2 numa nodes 1 pci device attach to numa node 0 and vcpu pin set configured to allow only numa node 1 in this case booting a vm with a passthrough alias and a passthrough alias fails. [stack at cloud-3 devstack]$ openstack flavor show 42 +----------------------------+-----------------------------------------------------+ | Field | Value | +----------------------------+-----------------------------------------------------+ | OS-FLV-DISABLED:disabled | False | | OS-FLV-EXT-DATA:ephemeral | 0 | | access_project_ids | None | | disk | 0 | | id | 42 | | name | m1.nano | | os-flavor-access:is_public | True | | properties | hw:numa_nodes='1', pci_passthrough:alias='nic-pf:1' | | ram | 64 | | rxtx_factor | 1.0 | | swap | | | vcpus | 1 | +----------------------------+-----------------------------------------------------+ passthrough_whitelist = { "address": "0000:01:00.1" } alias = { "vendor_id":"8086", "product_id":"10c9", "device_type":"type-PF", "name":"nic-pf", "numa_policy": "preferred"} removeing the hw:numa_nodes='1' extra spec allow the vm to boot as it nolonger has a numa topology. the vm passes scheduling in both casess but when the vm has a virtual numa toplogy of 1 node we fail in the resocue tracker on the compute node when claiming resouces for the instance. i will submit a bug for this and repose the spec next week to track closing this gap. On Thu, 2018-11-22 at 03:20 +0000, Xu, Chenjie wrote: > Hi Miguel, > There is another RFE “Add l2pop support for floating IP resources” proposed to Launchpad. This RFE also comes from > StarlingX and the link is below: > https://bugs.launchpad.net/neutron/+bug/1803494 > Could you please help review this RFE? I think this RFE can be added to the gap analysis. What’s more, there is a bug > and a RFE relating to l2pop and neutron-dynamic-routing is being written and is expected to be released next week. > > Best Regards, > Xu, Chenjie > > From: Miguel Lavalle [mailto:miguel at mlavalle.com] > Sent: Thursday, November 22, 2018 2:12 AM > To: openstack-discuss at lists.openstack.org; OpenStack Development Mailing List > Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack master > > Hi Stackers, > > One of the key goals of StarlingX during the current cycle is to converge with the OpenStack projects master branches. > In order to accomplish this goal, the Technical Steering Committee put together a gap analysis that shows the specs > and patches that need to merge in the different OpenStack projects by the end of Stein. The attached PDF document > shows this analysis. Although other projects are involved, most of the work has to be done in Nova, Neutron and > Horizon. Hopefully all the involved projects will help StarlingX achieve this important goal. > > It has to be noted that work is still on-going to refine this gap analysis, so there might be some updates to it in > the near future. > > Best regards > > Miguel From tony at bakeyournoodle.com Thu Nov 22 22:02:06 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Fri, 23 Nov 2018 09:02:06 +1100 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: <20181122094651.v6htgbzmuympyn57@lyarwood.usersys.redhat.com> References: <20181122045506.GC24690@thor.bakeyournoodle.com> <20181122094651.v6htgbzmuympyn57@lyarwood.usersys.redhat.com> Message-ID: <20181122220206.GD24690@thor.bakeyournoodle.com> On Thu, Nov 22, 2018 at 09:46:51AM +0000, Lee Yarwood wrote: > Agreed, I'm in favor of doing this and asking the oslo.service team to > rework the original fix on stable/rocky into something that doesn't > break Nova CI. Depending on how that looks maybe? I'm really not a fan of doing development on stable branches :( But I guess if the impact really is limited to CI it's probably okay. > I'm being slightly dense this morning, I can't seem to find a reference > to this lower-constraints.txt policy anywhere in the stable docs: > > https://docs.openstack.org/project-team-guide/stable-branches.html Nope your density is the same as always ;P It isn't covered in the stable docs (but should be) The closest we have written is: https://docs.openstack.org/project-team-guide/dependency-management.html#stable-branch-maintenance and even then it's only a passing comment about raising effective minimums. Those docs are outdated WRT the new lower-constraints.txt and extended maintenance work. Yours Tony. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From francois.magimel at alumni.enseeiht.fr Thu Nov 22 22:50:44 2018 From: francois.magimel at alumni.enseeiht.fr (=?UTF-8?Q?Fran=c3=a7ois_Magimel?=) Date: Thu, 22 Nov 2018 23:50:44 +0100 Subject: [forum] Summary of the "Better expose what we produce" session In-Reply-To: <0d6683cd-67ea-10eb-1da1-8c8098284795@openstack.org> References: <0d6683cd-67ea-10eb-1da1-8c8098284795@openstack.org> Message-ID: Hi Thierry, Thanks about your summary. I was not be able to be at this presentation to ask my question, so I'll go with this mail. Where can we open bugs for this project ? Is there an IRC channel ? And where yaml files are translated to HTML ? Thank you again for this useful map, François Le 22/11/2018 à 17:26, Thierry Carrez a écrit : > Hi everyone, > > The OpenStack community produces a complex landscape of services and other deliverables. Presenting those to the rest of the world in a way that is comprehensive, makes sense and is not overwhelming has been a constant challenge. > > During this forum session in Berlin we presented the status of various efforts and websites, and discussed next steps. You can see the notes of the session at: > > https://etherpad.openstack.org/p/BER-better-expose-what-we-produce > > The plan going forward is to: > > 1. Continue improving the information presented on openstack.org/software and make more elements driven by the openstack/openstack-map repository YAML files. Immediate next steps include rolling out a new "Overview" page, providing an example YAML template, adding project update video links to the YAML for easier update, and finishing compiling "dependency" information from teams. We will also consider adding diagrams, although it creates a lot of consistency challenges. > > 2. Make the pages less about the teams and more about the software. That involves creating team pages (or enriching those from the governance website) and link to them instead of displaying information on the software page. > > 3. Brainstorm ways to move the "drivers list" (currently displayed in the "marketplace" using outdated data from stackalytics Drivers page) directly on the software page > > 4. For deployment tools, include data from the deployment tool comparison effort (discussed in another session), and consider making room for third-party tools as well. Also as a comparison point see https://kubernetes.io/docs/setup/pick-right-solution/ > > 5. For SDKs, include non-developed-locally language SDKs in a separate tab, and engage with the groups working on SDK certification / validation to see if there is any additional information we can show. Also as a comparison point see https://kubernetes.io/docs/reference/using-api/client-libraries/ > > Thanks ! > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From soheil.ir08 at gmail.com Thu Nov 22 19:38:47 2018 From: soheil.ir08 at gmail.com (Soheil Pourbafrani) Date: Thu, 22 Nov 2018 23:08:47 +0330 Subject: [Openstack] [PackStack][Cinder]Save Volumes in The Compute nodes In-Reply-To: <90950AF3-ED04-4015-BE09-E4235F0DFAC9@gmail.com> References: <90950AF3-ED04-4015-BE09-E4235F0DFAC9@gmail.com> Message-ID: Thanks! and Does it need to cinder module to be installed on compute nodes? On Sat, Nov 17, 2018 at 1:13 PM Bernd Bausch wrote: > Yes. You need to enable Cinder’s InstanceLocalityFilter, see > > https://docs.openstack.org/cinder/latest/configuration/block-storage/scheduler-filters.html > . > > Here a tip: > https://ask.openstack.org/en/question/92001/cinder-lvm-volume-local-to-instance/ > > Bernd > > On Nov 17, 2018, at 8:38, Soheil Pourbafrani > wrote: > > Hi, > I have 8 servers with just local HDD disk. I want to use one server as the > controller and network node and the other (7 servers) as the compute node. > > I was wondering if it's possible to install PackStack that every compute > node to store its volumes in it's HDD local disk? (I guess the Cinder > should be installed on every Compute node alongside other settings) > > Thanks > > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From tony at bakeyournoodle.com Thu Nov 22 23:43:40 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Fri, 23 Nov 2018 10:43:40 +1100 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: References: Message-ID: <20181122234340.GE24690@thor.bakeyournoodle.com> On Thu, Nov 22, 2018 at 05:58:08PM +0100, Herve Beraud wrote: > Just a tiny report to summarize the situation to offer a big picture and to > analyze proposed solutions since peoples have submits new patches and some > other people have shared their opinions. > > Each solution contains the impacted projects, the related gerrit reviews, > pro/cons. > > ### 1 - Backport master changer and also backport new feature into a stable > branch > impacted projects: oslo.service, nova > related reviews: > - https://review.openstack.org/617989 > - https://review.openstack.org/619022 > - https://review.openstack.org/619019 > > pros: > - follow the master changes > - just use a backport > cons: > - backport a new feature into a stable branch and then this a violation of > the stable policy > - introduce a semver minor bump and a version 1.32 already exist > - won't be able to use either an older nova with a newer oslo.service > - increasing lower-constraints is not allowed on stable branches > - vendors need to ensure that there is a 'fixture' package available My position is that this is a non-starter. > ### 2 - Update the nova test to mock the new private interface > impacted projects: nova > reviews: > - https://review.openstack.org/619246 > > pros: > - straightforward > cons: > - still mocking a private inferface > - stable only patches This one is also a stable policy issue in that it forces nova to require a newer version of oslo.service and IIUC will never land as this approach can never be compatible with both oslo.service < 1.31.6 and 1.31.6 > ### 3 - Maintain a private interface for ThreadingEvent only on stable/rocky > impacted projects: oslo.service > related reviews: > - https://review.openstack.org/619342/ > > pros: > - straightforward > cons: > - Changing the loopingcall module semantics as it is different type > - stable only patches > - misunderstoud service customer between Threading, eventlet, etc.. and > master behavior A variation of this (without adding the debtcollector requirement) might work as IIUC all versions of oslo.service < 1.32.0 (except 1.31.6) would work and doesn't introduce any new policy violations. Adding debcollector is great but introduces at least the semver issues from option #1 > ### 4 - Don't use private interface in oslo.service > impacted projects: nova > related reviews: > - https://review.openstack.org/#/c/619360/ > > pros: > - straightforward > cons: > - this could work but it is not the same sematics as before as the type has > changed > - stable only patches > - misunderstoud service customer between Threading, eventlet, etc.. and > master behavior I think this is more or less the same as Option #3 in terms of impact. If that's right it could be acceptable. > ### 5 - Leave the CPU bug open on rocky > impacted projects: oslo.service > related reviews: - > > pros: > - Nova project doesn't impacted > cons: > - reintroduce the CPU issue I think if #3, or #4 works we can avoid the revert part of this but regardless we're going to need to block 1.31.6 so I've created: https://review.openstack.org/#/c/619655/ ; and abandoned https://review.openstack.org/#/c/618834/ > ### 6 - Revert CPU fix and totally rework it into someting that doesn't > break the Nova CI > impacted projects: oslo.service > related reviews: - > > pros: > - Nova project doesn't impacted > cons: > - potentially introduce more rewrites in the futures that depends on fix on > oslo.service loopingcall master > - stable only patches > - increase potential backport difficulties on oslo.service upstream and > downstream > - increase work load on upstream and downstream > > Personally: > - I prefer the #4 or the #2 and they seem to be smooth changes without > earthquake or anything like this > - the #6 seems to be the worst solution on my side > - the #1 introduce semver issue and policy violations so I don't think we > can continue with it I'm not certain how this is really different to the options already presented but I agree anything substantial on stable branches is pretty much a non-starter. > Thoughts? My preference is for a modified version of #3, unless I'm beaten to it I'll create a matrix that tests old and new olso.service against old and new nova to ensure that we're not missing something. > I hope this summarize help you to have a better overview :) Thanks! > I hope I have not forgotten anything and if so I apologize in advance. Really appreciate you keeping this on track and pulling the information together. Thanks! Tony. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From fungi at yuggoth.org Fri Nov 23 00:07:23 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 23 Nov 2018 00:07:23 +0000 Subject: [forum] Summary of the "Better expose what we produce" session In-Reply-To: References: <0d6683cd-67ea-10eb-1da1-8c8098284795@openstack.org> Message-ID: <20181123000723.d2lub2bc5gdad3fq@yuggoth.org> On 2018-11-22 23:50:44 +0100 (+0100), François Magimel wrote: > Thanks about your summary. I was not be able to be at this > presentation to ask my question, so I'll go with this mail. Where > can we open bugs for this project ? Is there an IRC channel ? And > where yaml files are translated to HTML ? [...] The source code is available from https://git.openstack.org/cgit/openstack/openstack-map/tree/ and patches can be submitted through the Gerrit instance at https://review.openstack.org/ but I don't see any defect tracker set up for that repository (yet anyway). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From cdent+os at anticdent.org Fri Nov 23 15:06:53 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Fri, 23 Nov 2018 15:06:53 +0000 (GMT) Subject: [placement] update 18-47 Message-ID: HTML: https://anticdent.org/placement-update-18-47.html It's been a while since the last placement update. Summit happened. Seemed pretty okay, except for the food. People have things they'd like to do with placement. # Most Important We're starting to approach the point where we're thinking about the possibility of maybe turning off placement-in-nova. We're not there yet, and as is always the case with these kinds of things, it's the details at the end that present the challenges. As such there are a mass of changes spread around nova, placement, devstack, grenade, puppet and openstack-ansible related to making things go. More details on those below, but what we need is the same as ever: reviews. Don't be shy. If you're not a core or not familiar with placement, reviews are still very helpful. A lot of the patches take the form of "this _might_ be the right way to do this". # What's Changed There is now a placement-manage command which can do database migrations, driven by alembic. This means that the devstack patch which uses the extracted placement can merge soon. Several other testing related (turning on tempest and grenade for placement) changes depend-on that. Matt did a placement-status command which has a no-op we-are-here upgrade check. We've already met the python3 goals (I think?), so I reckon placement is good to go on community-wide goals. Woot. The PlacementFixture that placement provides for other projects to do functional tests with it has merged. There's a patch for [nova using it](https://review.openstack.org/#/c/617941/). The spec for [counting quota usage in placement](https://review.openstack.org/#/c/509042/) has been revived after learning at summit that a proposed workaround that didn't use placement wasn't really all that good for people using cells v2. # Bugs * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 17. +1. * [In progress placement bugs](https://goo.gl/vzGGDQ) 13. +2 # Specs Summit and U.S. Thanksgiving has disrupted progress on some of these, but there are still plenty of specs awaiting their future. _Many_ of these have unaddressed negative review comments. * Account for host agg allocation ratio in placement (Still in rocky/) * Add subtree filter for GET /resource_providers * Resource provider - request group mapping in allocation candidate * VMware: place instances on resource pool (still in rocky/) * Standardize CPU resource tracking * Allow overcommit of dedicated CPU (Has an alternative which changes allocations to a float) * Modelling passthrough devices for report to placement * Nova Cyborg interaction specification. * supporting virtual NVDIMM devices * Spec: Support filtering by forbidden aggregate * Proposes NUMA topology with RPs * Count quota based on resource class * Adds spec for instance live resize * Provider config YAML file * Propose counting quota usage from placement and API database * Resource modeling in cyborg. # Main Themes ## Making Nested Useful Progress is being made on gpu-reshaping for libvirt and xen: * Making use of nested is bandwidth-resource-provider: * Somewhat related to nested are a stack of changes to how often the ProviderTree in the resource tracker is checked against placement, and a variety of other "let's make this more right" changes in the same neighborhood: * Stack at: ## Extraction (There's an [etherpad](https://etherpad.openstack.org/p/placement-extract-stein-4) which tracks some of the work related to extraction. Please refer to that for additional information.) TripleO and OpenStack-Ansible are both working on tooling to install and/or upgrade to extracted placement: * * libvirt support for GPU reshaping: * Grenade and tempest testing for extracted placement: * Extracted placement in devstack: * Turning on tests: * Some fixes to grenade using python3: A replacement for `placeload` performance testing that was in the `nova-next` job: . This might be of interest to people trying to do testing of live services without devstack. It starts with a basic node, turns on mysql, runs placement with uwsgi, and does the placeload testing. Note that this found a pretty strange [bug in _ensure_aggregates](https://bugs.launchpad.net/nova/+bug/1804453). Documentation tuneups: * Front page: * Release-notes: This is blocked until we refactor the release notes to reflect _now_ better. * The main remaining task here is participating in [openstack-manuals](https://docs.openstack.org/doc-contrib-guide/doc-index.html). We've been putting off making a decision about os-resource-classes. Anyone have strong opinions? # Other Besides the 20 or so [open changes](https://review.openstack.org/#/q/status:open+project:openstack/placement) in placement itself, and those mentioned above, here are some other changes that may be of interest. * Improve handling of default allocation ratios * Neutron minimum bandwidth implementation * Add OWNERSHIP $SERVICE traits * zun: Use placement for unified resource management * Using gabbi-tempest for integration tests. * Blazar using the placement-api * Tenks doing some node management, with a bit of optional placement. * Extracted placement in loci * Extracted placement in kolla * Extracted placement in kolla-ansible # End Lot going on. Thanks to everyone for their contributions. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From hongbin034 at gmail.com Fri Nov 23 16:10:25 2018 From: hongbin034 at gmail.com (Hongbin Lu) Date: Fri, 23 Nov 2018 11:10:25 -0500 Subject: [Openstack-operators] Openstack zun on centos??? In-Reply-To: References: Message-ID: Hi Edoardo, It looks you gets your answer from others. I just want to add a few more comments. We (the Zun team) would like to have CentOS included in our installation guide and I have created a ticket for that: https://blueprints.launchpad.net/zun/+spec/installation-guide-for-centos . It will be picked up by contributors if someone interests to work on it. I expect the steps would be very similar as Ubuntu expect a few necessary tweaks. Right now, there is no Debian or RPM packages for Zun so we instruct users to install from source, which might be a bit painful. I would like to see Zun included in distro packages and I will see if we can recruit contributors to work on that, or I will work on that myself. Best regards, Hongbin On Wed, Nov 14, 2018 at 1:51 PM Ignazio Cassano wrote: > Hi Edoardo, > does it mean openstack kolla installs zun using pip ? > I did not find any zun rpm package > Regards > Ignazio > > Il giorno Mer 14 Nov 2018 18:38 Eduardo Gonzalez ha > scritto: > >> Hi Cassano, you can use zun in centos deployed by kolla-ansible. >> >> https://docs.openstack.org/kolla-ansible/latest/reference/zun-guide.html >> >> Regards >> >> El mié., 14 nov. 2018 17:11, Ignazio Cassano >> escribió: >> >>> Hi All, >>> I'd like to know if openstack zun will be released for centos. >>> Reading documentation at docs.openstack.org only ubuntu installation is >>> reported. >>> Many thanks >>> Ignazio >>> _______________________________________________ >>> OpenStack-operators mailing list >>> OpenStack-operators at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >> _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From jimmy at openstack.org Fri Nov 23 16:24:56 2018 From: jimmy at openstack.org (Jimmy McArthur) Date: Fri, 23 Nov 2018 10:24:56 -0600 Subject: [forum] Summary of the "Better expose what we produce" session In-Reply-To: <20181123000723.d2lub2bc5gdad3fq@yuggoth.org> References: <0d6683cd-67ea-10eb-1da1-8c8098284795@openstack.org> <20181123000723.d2lub2bc5gdad3fq@yuggoth.org> Message-ID: <5BF829D8.2080100@openstack.org> And the yaml to html translation occurs here: https://github.com/OpenStackweb/openstack-org/tree/master/software We're actually testing many of the new features Thierry mentioned on the master branch now. > Jeremy Stanley > November 22, 2018 at 6:07 PM > [...] > > The source code is available from > https://git.openstack.org/cgit/openstack/openstack-map/tree/ and > patches can be submitted through the Gerrit instance at > https://review.openstack.org/ but I don't see any defect tracker set > up for that repository (yet anyway). > François Magimel > November 22, 2018 at 4:50 PM > Hi Thierry, > > Thanks about your summary. I was not be able to be at this > presentation to ask my question, so I'll go with this mail. Where can > we open bugs for this project ? Is there an IRC channel ? And where > yaml files are translated to HTML ? > > Thank you again for this useful map, > François > > > > Thierry Carrez > November 22, 2018 at 10:26 AM > Hi everyone, > > The OpenStack community produces a complex landscape of services and > other deliverables. Presenting those to the rest of the world in a way > that is comprehensive, makes sense and is not overwhelming has been a > constant challenge. > > During this forum session in Berlin we presented the status of various > efforts and websites, and discussed next steps. You can see the notes > of the session at: > > https://etherpad.openstack.org/p/BER-better-expose-what-we-produce > > The plan going forward is to: > > 1. Continue improving the information presented on > openstack.org/software and make more elements driven by the > openstack/openstack-map repository YAML files. Immediate next steps > include rolling out a new "Overview" page, providing an example YAML > template, adding project update video links to the YAML for easier > update, and finishing compiling "dependency" information from teams. > We will also consider adding diagrams, although it creates a lot of > consistency challenges. > > 2. Make the pages less about the teams and more about the software. > That involves creating team pages (or enriching those from the > governance website) and link to them instead of displaying information > on the software page. > > 3. Brainstorm ways to move the "drivers list" (currently displayed in > the "marketplace" using outdated data from stackalytics Drivers page) > directly on the software page > > 4. For deployment tools, include data from the deployment tool > comparison effort (discussed in another session), and consider making > room for third-party tools as well. Also as a comparison point see > https://kubernetes.io/docs/setup/pick-right-solution/ > > 5. For SDKs, include non-developed-locally language SDKs in a separate > tab, and engage with the groups working on SDK certification / > validation to see if there is any additional information we can show. > Also as a comparison point see > https://kubernetes.io/docs/reference/using-api/client-libraries/ > > Thanks ! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From soheil.ir08 at gmail.com Fri Nov 23 22:41:36 2018 From: soheil.ir08 at gmail.com (Soheil Pourbafrani) Date: Sat, 24 Nov 2018 02:11:36 +0330 Subject: [Openstack] [OpenStack][Glance]Getting instance snapshot result in size 0 byte Message-ID: Hi, I have many instances running on OpenStack and I wanted to export them. So I create a snapshot of an instance and it results in a new record in images in the format of Qcow2 and size of 0 bytes! It just created a volume snapshot of the instance, too. I tried with both command line and horizon but the same results! How can I export instances in the correct way? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From ahm.jawad118 at gmail.com Fri Nov 23 23:28:48 2018 From: ahm.jawad118 at gmail.com (Jawad Ahmed) Date: Sat, 24 Nov 2018 00:28:48 +0100 Subject: [Openstack-operators] urlopen error [Errno 113] No route to host Message-ID: Hi all, Has anyone come across this error with utility container.I am running CentOS7 with Queens. After running setup-infrastructure.yml getting into this error while rest is success.Any workaround ? internal_lb_vip_address: 172.25.30.101 fatal: [rmq-db_utility_container-8e503460]: FAILED! => {"changed": false, "content": "", "msg": "Status code was -1 and not [200]: Request failed: ", "redirected": false, "status": -1, "url": " http://172.25.30.101:8181/os-releases/18.0.0/centos-7.5-x86_64/requirements_absolute_requirements.txt "} Thank you. -- Greetings, Jawad Ahmed -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From cdent+os at anticdent.org Sat Nov 24 12:13:10 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Sat, 24 Nov 2018 12:13:10 +0000 (GMT) Subject: [oslo] [config] Using environment variables for config options In-Reply-To: References: Message-ID: On Thu, 22 Nov 2018, Moises Guimaraes de Medeiros wrote: > Have you thought on how to populate options of type ListOpt like > DEFAULT/config_source? We discussed that briefly on the spec [1] and the (temporary?) resolution there was: * Let's wait to figure that out until someone really wants to do that. The thinking being that if they want to use the complex Opt types, using environment variables for setting them may not be the right choice. * "that may just be another reason to not use those types of options" Basically, we'll cross that bridge when someone has a demand for it. My specific need was to be able to control String and Bool Opts which gets many, if not most, of the common things one might like to change _per instance_ of the service. [1] https://review.openstack.org/#/c/576860/ -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From mnaser at vexxhost.com Sat Nov 24 15:05:16 2018 From: mnaser at vexxhost.com (Mohammed Naser) Date: Sat, 24 Nov 2018 10:05:16 -0500 Subject: [Openstack] [OpenStack][Glance]Getting instance snapshot result in size 0 byte In-Reply-To: References: Message-ID: Are they boot from volume instances? On Fri, Nov 23, 2018 at 5:57 PM Soheil Pourbafrani wrote: > Hi, > > I have many instances running on OpenStack and I wanted to export them. So > I create a snapshot of an instance and it results in a new record in images > in the format of Qcow2 and size of 0 bytes! It just created a volume > snapshot of the instance, too. > > I tried with both command line and horizon but the same results! > > How can I export instances in the correct way? > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser at vexxhost.com W. http://vexxhost.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From soheil.ir08 at gmail.com Sat Nov 24 15:04:07 2018 From: soheil.ir08 at gmail.com (Soheil Pourbafrani) Date: Sat, 24 Nov 2018 18:34:07 +0330 Subject: [Openstack] [OpenStack][Keystone] the controller is node listening on port 5000 Message-ID: Hi, I installed keystone step by step according to the OpenStack Doc but the http server is not listening on the port 5000! The only difference is my hostname (address) is "controller.a.b" instead of "controller". In verifying part of the document I could do all (like creating a user, project, ....) but after installing glance, I found out the Glance API is not running properly and it's because of Keystone is not listening on port 5000! Here are AUTH variables: export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_NAME=admin export OS_USERNAME=admin export OS_PASSWORD=XXX export OS_AUTH_URL=http://controller.a.b:5000/v3 export OS_IDENTITY_API_VERSION=3 export OS_IMAGE_API_VERSION=2 When I try "glance image-list", I got: "http://controller.a.b:9292/v2/images?limit=20&sort_key=name&sort_dir=asc: Unable to establish connection" Here is TCP listening ports: tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1614/master tcp 0 0 0.0.0.0:9191 0.0.0.0:* LISTEN 961/python2 tcp 0 0 0.0.0.0:25672 0.0.0.0:* LISTEN 957/beam.smp tcp 0 0 192.168.0.31:3306 0.0.0.0:* LISTEN 1622/mysqld tcp 0 0 192.168.0.31:2379 0.0.0.0:* LISTEN 963/etcd tcp 0 0 192.168.0.31:11211 0.0.0.0:* LISTEN 952/memcached tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 952/memcached tcp 0 0 192.168.0.31:2380 0.0.0.0:* LISTEN 963/etcd tcp 0 0 0.0.0.0:4369 0.0.0.0:* LISTEN 1/systemd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 953/sshd tcp6 0 0 ::1:25 :::* LISTEN 1614/master tcp6 0 0 :::5000 :::* LISTEN 960/httpd tcp6 0 0 :::5672 :::* LISTEN 957/beam.smp tcp6 0 0 ::1:11211 :::* LISTEN 952/memcached tcp6 0 0 :::80 :::* LISTEN 960/httpd tcp6 0 0 :::22 :::* LISTEN 953/sshd As you can see httpd is listening on port 5000 IPV6, but it's not active for IPV4! Here is keystone.log: 2018-11-24 15:55:59.685 17325 INFO keystone.common.wsgi [req-9fedd505-5d98-4c12-a6ad-967f28c766e7 - - - - -] POST http://controller.a.b:5000/v3/auth/tokens 2018-11-24 15:56:00.275 17327 INFO keystone.common.wsgi [req-ca93da87-1d9f-4611-835c-d6972054b8e1 - - - - -] POST http://controller.a.b:5000/v3/auth/tokens 2018-11-24 15:56:00.929 17328 INFO keystone.common.wsgi [req-cf8c6af8-342d-4b14-9826-ba27e5f2897a 1b96f6b67f08495092e98a9b60476152 b33579097090499499625154e92724ee - default default] GET http://controller.a.b:5000/v3/domains/default 2018-11-24 15:56:14.753 17325 INFO keystone.common.wsgi [req-cca0e4a5-0ef9-40d8-a2f4-56c1f0acafcc 1b96f6b67f08495092e98a9b60476152 b33579097090499499625154e92724ee - default default] POST http://controller.a.b:5000/v3/users 2018-11-24 15:56:14.773 17325 WARNING py.warnings [req-cca0e4a5-0ef9-40d8-a2f4-56c1f0acafcc 1b96f6b67f08495092e98a9b60476152 b33579097090499499625154e92724ee - default default] /usr/lib/python2.7/site-packages/oslo_policy/policy.py:896: UserWarning: Policy identity:create_user failed scope check. The token used to make the request was project scoped but the policy requires ['system'] scope. This behavior may change in the future where using the intended scope is required warnings.warn(msg) Another difference between my system and document is that I use static IP and here are interface settings: TYPE="Ethernet" PROXY_METHOD="none" BROWSER_ONLY="no" BOOTPROTO="none" DEFROUTE="yes" IPV4_FAILURE_FATAL="no" IPV6INIT="yes" IPV6_AUTOCONF="yes" IPV6_DEFROUTE="yes" IPV6_FAILURE_FATAL="no" IPV6_ADDR_GEN_MODE="stable-privacy" NAME="enp2s0" UUID="62aa5ce8-64da-41b4-abd3-293fd43584fa" DEVICE="enp2s0" ONBOOT="yes" IPADDR="192.168.0.X" PREFIX="24" GATEWAY="192.168.0.1" DNS1="192.168.0.1" DNS2="8.8.8.8" IPV6_PRIVACY="no" What can be the cause? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From skaplons at redhat.com Sun Nov 25 09:40:55 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Sun, 25 Nov 2018 10:40:55 +0100 Subject: [Openstack] [openstack][neutron]Iptables snat not work when securitygroup is on In-Reply-To: <2c4de9d2.18c0.16749ab70c2.Coremail.qishiyexu2@126.com> References: <2c4de9d2.18c0.16749ab70c2.Coremail.qishiyexu2@126.com> Message-ID: Hi, Security groups driver in Neutron is not doing any „magic” with iptables. All what is done there is implemented by iptables rules. So I think You should turn on security groups again and then dump all iptables rule, e.g. with „iptables-save” command and check what is blocking Your packets. You can also use „iptables -nvL” command to display number of packets going through each of rules - then You can easily find where You packets are dropped if You don’t have a lot of different traffic on this host :) > Wiadomość napisana przez 陈炤 w dniu 25.11.2018, o godz. 08:00: > > Hi, > > I am building an openstack all-in-one environment in a CentOS7.4 machine. For some reason I have only one network interface(eth0) and one ip address, so I created a linux bridge(br0), and forwarded datas to eth0 using iptables command: > > iptables -t nat -A POSTROUTING -s {bridge virtual ip} -j SNAT --to {eth0 ip} > > But it seems not work. > > When I ping to 8.8.8.8 from br0 and run tcpdump, I can see that datas can be forwared to eth0 and be sent to 8.8.8.8, but when datas are sent back to eth0, they can not be forwarded to br0. > > Ip forwarding, net.bridge.bridge-nf-call-iptables and net.bridge.bridge-nf-call-ip6tablesare set to 1. > > If I close security group by setting securitygroup = false, this rule works fine, but if I use iptables -F instead, the rule is not work. Does the securitygroup have a magic to trap iptables? > > BR > > Don > > > > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack — Slawek Kaplonski Senior software engineer Red Hat From zhu.bingbing at 99cloud.net Sun Nov 25 04:06:38 2018 From: zhu.bingbing at 99cloud.net (zhubingbing) Date: Sun, 25 Nov 2018 12:06:38 +0800 (GMT+08:00) Subject: [openstack-dev] =?utf-8?q?=5Bkolla=5D_Berlin_summit_resume?= In-Reply-To: Message-ID: thanks Eduardo Gonzalez From: Eduardo Gonzalez Date: 2018-11-22 01:07:40 To: "OpenStack Development Mailing List (not for usage questions)" ,OpenStack Operators ,openstack at lists.openstack.org Subject: [openstack-dev] [kolla] Berlin summit resume Hi kollagues, During the Berlin Summit kolla team had a few talks and forum discussions, as well as other cross-project related topics [0] First session was ``Kolla project onboarding``, the room was full of people interested in contribute to kolla, many of them already using kolla in production environments whiling to make upstream some work they've done downstream. I can say this talk was a total success and we hope to see many new faces during this release putting features and bug fixes into kolla . Slides of the session at [1] Second session was ``Kolla project update``, was a brief resume of what work has been done during rocky release and some items will be implemented in the future. Number of attendees to this session was massive, no more people could enter the room. Slides at [2] Then forum sessions.. First one was ``Kolla user feedback``, many users came over the room. We've notice a big increase in production deployments and some PoC migrating to production soon, many of those environments are huge. Overall the impressions was that kolla is great and don't have any big issue or requirement, ``it works great`` became a common phrase to listen. Here's a resume of the user feedback needs [3] - Improve operational usage for add, remove , change and stop/start nodes and services. - Database backup and recovery - Lack of documentation is the bigger request, users need to read the code to know how to configure other than core/default services - Multi cells_v2 - New services request, cyborg, masakari and tricircle were the most requested - SElinux enabled - More SDN services such as Contrail and calico - Possibility to include user's ansible tasks during deploy as well as support custom config.json - HTTPS for internal networks Second one was about ``kolla for the edge``, we've meet with Edge computing group and others interested in edge deployments to identify what's missing in kolla and where we can help. Things we've identified are: - Kolla seems good at how the service split can be done, tweaking inventory file and config values can deploy independent environments easily. - Missing keystone federation - Glance cache support is not a hard requirement but improves efficiency (already merged) - Multi cells v2 - Multi storage per edge/far-edge - A documentation or architecture reference would be nice to have. Last one was ``kolla for NFV` `, few people came over to discuss about NUMA, GPU, SRIOV. Nothing noticiable from this session, mainly was support DPDK for CentOS/RHEL,OracleLinux and few service addition covered by previous discussions. [0] https://etherpad.openstack .org/p/kolla-stein-summit [1] https://es.slideshare.net/EduardoGonzalezGutie/kolla-project-onboarding-openstack-summit-berlin-2018 [2] https://es.slideshare.net /EduardoGonzalezGutie/openstack-kolla-project-update-rocky-release [3] https://etherpad.openstack.org/p/berlin-2018-kolla-user-feedback [4] https://etherpad.openstack.org/p/berlin-2018-kolla-edge [5] https ://etherpad.openstack.org/p/berlin-2018-kolla-nfv -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From qishiyexu2 at 126.com Sun Nov 25 07:00:31 2018 From: qishiyexu2 at 126.com (=?GBK?B?s8Ke3Q==?=) Date: Sun, 25 Nov 2018 15:00:31 +0800 (CST) Subject: [Openstack] [openstack][neutron]Iptables snat not work when securitygroup is on Message-ID: <2c4de9d2.18c0.16749ab70c2.Coremail.qishiyexu2@126.com> Hi, I am building an openstack all-in-one environment in a CentOS7.4 machine. For some reason I have only one network interface(eth0) and one ip address, so I created a linux bridge(br0), and forwarded datas to eth0 using iptables command: iptables -t nat -A POSTROUTING -s {bridge virtual ip} -j SNAT --to {eth0 ip} But it seems not work. When I ping to 8.8.8.8 from br0 and run tcpdump, I can see that datas can be forwared to eth0 and be sent to 8.8.8.8, but when datas are sent back to eth0, they can not be forwarded to br0. Ip forwarding, net.bridge.bridge-nf-call-iptables and net.bridge.bridge-nf-call-ip6tablesare set to 1. If I close security group by setting securitygroup = false, this rule works fine, but if I use iptables -F instead, the rule is not work. Does the securitygroup have a magic to trap iptables? BR Don -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From saphi070 at gmail.com Mon Nov 26 03:23:26 2018 From: saphi070 at gmail.com (Sa Pham) Date: Mon, 26 Nov 2018 10:23:26 +0700 Subject: [OCTAVIA] How to monitor amphora In-Reply-To: References: Message-ID: yes. I have discussed with the Octavia team. PTL Johnson has suggested me to use gnocchi to store octavia amphora metric. On Wed, Nov 21, 2018 at 3:16 PM Gaël THEROND wrote: > Hi! Thanks for this material, I’ll have a look at it. > > As our philosophy at work is to always push upstream all our > patchs/features or bug fixes, I won’t modify and keep the source code on > our own and if we need further features like that I think we will rather > push for a Blueprint with all required commits. > > Did you already discussed that topic with the Octavia team? > > Thanks a lot. > > Le mer. 21 nov. 2018 à 09:12, Sa Pham a écrit : > >> Hi, >> >> In Vietnam Openinfra Days 2018, I have a presentation about monitoring >> and logging for Octavia Amphora. We have to customize octavia source code >> to do this. I send you my presentation slide: >> >> https://drive.google.com/file/d/1dHXExEKrHDg4Cf3D1fBeulLDW_G-txLr/view?usp=sharing >> >> Best, >> >> On Wed, Nov 21, 2018 at 3:05 PM Gaël THEROND >> wrote: >> >>> Hi guys, >>> >>> As already discussed I had to test Octavia as our corporate LoadBalancer >>> solution and it was a success. >>> >>> Thank to everyone on this list that assisted me and especially Michael >>> Octavia is fully working and without weird nightmare glitches. >>> >>> Now that I validated the technical part of my project, I need to enter >>> more operationals questions such as what’s the best way to monitor and log >>> amphora? >>> >>> I would like to be able to get a monitoring and logging agent installed >>> on the amphora in order to get proper metrics about what’s going on with >>> the LoadBalancer, is it fully cpu loaded? Is it using all network resources >>> available, are the file descriptors near the initial limits? How much xxx >>> HTTP return code the loadBalancer is facing and send those logs to an ELK >>> or something similar. >>> >>> Do you know if that something that I could achieve by adding more >>> elements to the image at DIB time or are there any other better >>> best-practices that I should be aware of ? >>> >>> As Octavia is creating a namespace for each HAProxy process, I am >>> wandering if it’s even possible. >>> >>> Thanks a lot for your hard work guys. >>> >>> Kind regards, >>> >>> >> >> -- >> Sa Pham Dang >> Cloud RnD Team - VCCloud >> Phone/Telegram: 0986.849.582 >> Skype: great_bn >> >> >> -- Sa Pham Dang Cloud RnD Team - VCCloud Phone/Telegram: 0986.849.582 Skype: great_bn -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.therond at gmail.com Mon Nov 26 06:45:27 2018 From: gael.therond at gmail.com (=?UTF-8?Q?Ga=C3=ABl_THEROND?=) Date: Mon, 26 Nov 2018 07:45:27 +0100 Subject: [OCTAVIA] How to monitor amphora In-Reply-To: References: Message-ID: Hi! I’ve taken some time to read your presentation and I have to say thank you for your wonderful work ! It’s pretty much complete and with code example which is really cool. It’s exactly what I was looking for. If I could just suggest one thing, it would be to give operators freedom to choose which logging and which metrics clients they want to use. Doing so would avoid having to rely on gnocchi as you would be able to choose the clients type at amphora build time and specify clients target at runtime using the amphora-agent. On another hand, it might we’ll be tricky to do so as everything is namespaced into the amphora instance. As suggested using gnocchi to store HAProxy logs may well be the easiest short path actually, I’m wondering if it would be possible for searchlight to use that logs at some point. Anyway, thanks for the awesome job. For now I’ll keep it simple and just use the API for basic status. Kind regards, G. Le lun. 26 nov. 2018 à 04:23, Sa Pham a écrit : > yes. I have discussed with the Octavia team. PTL Johnson has suggested me > to use gnocchi to store octavia amphora metric. > > > > On Wed, Nov 21, 2018 at 3:16 PM Gaël THEROND > wrote: > >> Hi! Thanks for this material, I’ll have a look at it. >> >> As our philosophy at work is to always push upstream all our >> patchs/features or bug fixes, I won’t modify and keep the source code on >> our own and if we need further features like that I think we will rather >> push for a Blueprint with all required commits. >> >> Did you already discussed that topic with the Octavia team? >> >> Thanks a lot. >> >> Le mer. 21 nov. 2018 à 09:12, Sa Pham a écrit : >> >>> Hi, >>> >>> In Vietnam Openinfra Days 2018, I have a presentation about monitoring >>> and logging for Octavia Amphora. We have to customize octavia source code >>> to do this. I send you my presentation slide: >>> >>> https://drive.google.com/file/d/1dHXExEKrHDg4Cf3D1fBeulLDW_G-txLr/view?usp=sharing >>> >>> Best, >>> >>> On Wed, Nov 21, 2018 at 3:05 PM Gaël THEROND >>> wrote: >>> >>>> Hi guys, >>>> >>>> As already discussed I had to test Octavia as our corporate >>>> LoadBalancer solution and it was a success. >>>> >>>> Thank to everyone on this list that assisted me and especially Michael >>>> Octavia is fully working and without weird nightmare glitches. >>>> >>>> Now that I validated the technical part of my project, I need to enter >>>> more operationals questions such as what’s the best way to monitor and log >>>> amphora? >>>> >>>> I would like to be able to get a monitoring and logging agent installed >>>> on the amphora in order to get proper metrics about what’s going on with >>>> the LoadBalancer, is it fully cpu loaded? Is it using all network resources >>>> available, are the file descriptors near the initial limits? How much xxx >>>> HTTP return code the loadBalancer is facing and send those logs to an ELK >>>> or something similar. >>>> >>>> Do you know if that something that I could achieve by adding more >>>> elements to the image at DIB time or are there any other better >>>> best-practices that I should be aware of ? >>>> >>>> As Octavia is creating a namespace for each HAProxy process, I am >>>> wandering if it’s even possible. >>>> >>>> Thanks a lot for your hard work guys. >>>> >>>> Kind regards, >>>> >>>> >>> >>> -- >>> Sa Pham Dang >>> Cloud RnD Team - VCCloud >>> Phone/Telegram: 0986.849.582 >>> Skype: great_bn >>> >>> >>> > > -- > Sa Pham Dang > Cloud RnD Team - VCCloud > Phone/Telegram: 0986.849.582 > Skype: great_bn > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamamoto at midokura.com Mon Nov 26 07:25:19 2018 From: yamamoto at midokura.com (Takashi Yamamoto) Date: Mon, 26 Nov 2018 16:25:19 +0900 Subject: [neutron] LP tag for python 3 Message-ID: hi, currently we seem to have an official tag "py34" on the LP. and "py35" is documented in the contributor guide. https://docs.openstack.org/neutron/latest/contributor/policies/bugs.html#py35 i'd like to propose to replace them with "py3" mechanically. From ssbarnea at redhat.com Mon Nov 26 09:04:39 2018 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Mon, 26 Nov 2018 09:04:39 +0000 Subject: [neutron] LP tag for python 3 In-Reply-To: References: Message-ID: I think that there is no single answer to this. Also the subject applies to any openstack project, not only neutron. I personally used common sense, using py3 for generic 3.x bugs and more granular ones like py34,...py37 when there were bugs specific to one of these version. I also try to include py3 on the more granular ones to ease searching. Replacing tags is dangerous as you may loose important information or even break so queries/tools. -- sorin > On 26 Nov 2018, at 07:25, Takashi Yamamoto wrote: > > hi, > > currently we seem to have an official tag "py34" on the LP. > > and "py35" is documented in the contributor guide. > https://docs.openstack.org/neutron/latest/contributor/policies/bugs.html#py35 > > i'd like to propose to replace them with "py3" mechanically. > From jpena at redhat.com Mon Nov 26 09:36:09 2018 From: jpena at redhat.com (Javier Pena) Date: Mon, 26 Nov 2018 04:36:09 -0500 (EST) Subject: [Openstack] [PackStack][Cinder]Save Volumes in The Compute nodes In-Reply-To: References: <90950AF3-ED04-4015-BE09-E4235F0DFAC9@gmail.com> Message-ID: <1926809770.53738230.1543224969471.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Thanks! and Does it need to cinder module to be installed on compute nodes? You will need to run the cinder-volume service in the compute nodes. You will have to set it up manually, though, because Packstack only installs it on the controller. Regards, Javier > On Sat, Nov 17, 2018 at 1:13 PM Bernd Bausch < berndbausch at gmail.com > wrote: > > Yes. You need to enable Cinder’s InstanceLocalityFilter, see > > > https://docs.openstack.org/cinder/latest/configuration/block-storage/scheduler-filters.html > > . > > > Here a tip: > > https://ask.openstack.org/en/question/92001/cinder-lvm-volume-local-to-instance/ > > > Bernd > > > On Nov 17, 2018, at 8:38, Soheil Pourbafrani < soheil.ir08 at gmail.com > > > wrote: > > > > Hi, > > > > > > I have 8 servers with just local HDD disk. I want to use one server as > > > the > > > controller and network node and the other (7 servers) as the compute > > > node. > > > > > > I was wondering if it's possible to install PackStack that every compute > > > node > > > to store its volumes in it's HDD local disk? (I guess the Cinder should > > > be > > > installed on every Compute node alongside other settings) > > > > > > Thanks > > > > > > _______________________________________________ > > > > > > Mailing list: > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > > Post to : openstack at lists.openstack.org > > > > > > Unsubscribe : > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From soheil.ir08 at gmail.com Mon Nov 26 05:42:20 2018 From: soheil.ir08 at gmail.com (Soheil Pourbafrani) Date: Mon, 26 Nov 2018 09:12:20 +0330 Subject: [Openstack] [OpenStack][Cinder] Config Volumes to Store on Compute nodes Message-ID: Hi, I want to configure cinder to store Volumes on the Compute nodes. I know I should use the InstanceLocalityFilter. Suppose we have one Controller and two Compute node, should I install the Cinder on each node (Controller and Compute)? I will be appreciated if you suggest me any instruction about this. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From soheil.ir08 at gmail.com Mon Nov 26 06:32:08 2018 From: soheil.ir08 at gmail.com (Soheil Pourbafrani) Date: Mon, 26 Nov 2018 10:02:08 +0330 Subject: [Openstack] [OpenStack][Cinder]How config cinder.conf [nova] part for InstanceLocalityFilter Message-ID: Hi, I want to enable InstanceLocalityFiletr for the Cinder. I set scheduler_default_filters = AvailabilityZoneFilter,CapacityFilter,CapabilitiesFilter,InstanceLocality But the document said we should specify an account with privileged rights for Nova in Cinder configuration (configure a keystone authentication plugin in the [nova] section), but I can't find an example for such configuration. Can anyone give an example? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From soheil.ir08 at gmail.com Mon Nov 26 10:07:31 2018 From: soheil.ir08 at gmail.com (Soheil Pourbafrani) Date: Mon, 26 Nov 2018 13:37:31 +0330 Subject: [Openstack] [PackStack][Cinder]Save Volumes in The Compute nodes In-Reply-To: <1926809770.53738230.1543224969471.JavaMail.zimbra@redhat.com> References: <90950AF3-ED04-4015-BE09-E4235F0DFAC9@gmail.com> <1926809770.53738230.1543224969471.JavaMail.zimbra@redhat.com> Message-ID: Thanks a lot! On Mon, Nov 26, 2018 at 1:06 PM Javier Pena wrote: > > > ------------------------------ > > Thanks! and Does it need to cinder module to be installed on compute nodes? > > > You will need to run the cinder-volume service in the compute nodes. You > will have to set it up manually, though, because Packstack only installs it > on the controller. > > Regards, > Javier > > On Sat, Nov 17, 2018 at 1:13 PM Bernd Bausch > wrote: > >> Yes. You need to enable Cinder’s InstanceLocalityFilter, see >> >> https://docs.openstack.org/cinder/latest/configuration/block-storage/scheduler-filters.html >> . >> >> Here a tip: >> https://ask.openstack.org/en/question/92001/cinder-lvm-volume-local-to-instance/ >> >> Bernd >> >> On Nov 17, 2018, at 8:38, Soheil Pourbafrani >> wrote: >> >> Hi, >> I have 8 servers with just local HDD disk. I want to use one server as >> the controller and network node and the other (7 servers) as the compute >> node. >> >> I was wondering if it's possible to install PackStack that every compute >> node to store its volumes in it's HDD local disk? (I guess the Cinder >> should be installed on every Compute node alongside other settings) >> >> Thanks >> >> _______________________________________________ >> Mailing list: >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> Post to : openstack at lists.openstack.org >> Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> >> > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From naichuan.sun at citrix.com Mon Nov 26 10:45:57 2018 From: naichuan.sun at citrix.com (Naichuan Sun) Date: Mon, 26 Nov 2018 10:45:57 +0000 Subject: [openstack-dev] [nova][placement] Please help to review XenServer vgpu related patches Message-ID: Hi, Sylvain, Jay, Eric and Matt, I saw the n-rp and reshaper patches in upstream have almost finished. Could you help to review XenServer vGPU related patches when you have the time? https://review.openstack.org/#/c/520313/ https://review.openstack.org/#/c/521041/ https://review.openstack.org/#/c/521717/ Thank you very much. BR. Naichuan Sun __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From zufardhiyaulhaq at gmail.com Mon Nov 26 10:45:33 2018 From: zufardhiyaulhaq at gmail.com (Zufar Dhiyaulhaq) Date: Mon, 26 Nov 2018 17:45:33 +0700 Subject: [Openstack] unexpected distribution of compute instances in queens Message-ID: Hi, I am deploying OpenStack with 3 compute node, but I am seeing an abnormal distribution of instance, the instance is only deployed in a specific compute node, and not distribute among other compute node. this is my nova.conf from the compute node. (template jinja2 based) [DEFAULT] osapi_compute_listen = {{ hostvars[inventory_hostname]['ansible_ens3f1'][ 'ipv4']['address'] }} metadata_listen = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4'][ 'address'] }} enabled_apis = osapi_compute,metadata transport_url = rabbit://openstack:{{ rabbitmq_pw }}@{{ controller1_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ controller2_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ controller3_ip_man }}:5672 my_ip = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} use_neutron = True firewall_driver = nova.virt.firewall.NoopFirewallDriver [api] auth_strategy = keystone [api_database] connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_api [barbican] [cache] backend=oslo_cache.memcache_pool enabled=true memcache_servers={{ controller1_ip_man }}:11211,{{ controller2_ip_man }}:11211,{{ controller3_ip_man }}:11211 [cells] [cinder] os_region_name = RegionOne [compute] [conductor] [console] [consoleauth] [cors] [crypto] [database] connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova [devices] [ephemeral_storage_encryption] [filter_scheduler] [glance] api_servers = http://{{ vip }}:9292 [guestfs] [healthcheck] [hyperv] [ironic] [key_manager] [keystone] [keystone_authtoken] auth_url = http://{{ vip }}:5000/v3 memcached_servers = {{ controller1_ip_man }}:11211,{{ controller2_ip_man }}:11211,{{ controller3_ip_man }}:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = nova password = {{ nova_pw }} [libvirt] [matchmaker_redis] [metrics] [mks] [neutron] url = http://{{ vip }}:9696 auth_url = http://{{ vip }}:35357 auth_type = password project_domain_name = default user_domain_name = default region_name = RegionOne project_name = service username = neutron password = {{ neutron_pw }} service_metadata_proxy = true metadata_proxy_shared_secret = {{ metadata_secret }} [notifications] [osapi_v21] [oslo_concurrency] lock_path = /var/lib/nova/tmp [oslo_messaging_amqp] [oslo_messaging_kafka] [oslo_messaging_notifications] [oslo_messaging_rabbit] [oslo_messaging_zmq] [oslo_middleware] [oslo_policy] [pci] [placement] os_region_name = RegionOne project_domain_name = Default project_name = service auth_type = password user_domain_name = Default auth_url = http://{{ vip }}:5000/v3 username = placement password = {{ placement_pw }} [quota] [rdp] [remote_debug] [scheduler] discover_hosts_in_cells_interval = 300 [serial_console] [service_user] [spice] [upgrade_levels] [vault] [vendordata_dynamic_auth] [vmware] [vnc] enabled = true keymap=en-us novncproxy_base_url = https://{{ vip }}:6080/vnc_auto.html novncproxy_host = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4'][ 'address'] }} [workarounds] [wsgi] [xenserver] [xvp] [placement_database] connection=mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_placement what is the problem? I have lookup the openstack-nova-scheduler in the controller node but it's running well with only warning nova-scheduler[19255]: /usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py:332: NotSupportedWarning: Configuration option(s) ['use_tpool'] not supported the result I want is the instance is distributed in all compute node. Thank you. -- *Regards,* *Zufar Dhiyaulhaq* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From akamyshnikova at mirantis.com Mon Nov 26 13:41:28 2018 From: akamyshnikova at mirantis.com (Anna Taraday) Date: Mon, 26 Nov 2018 17:41:28 +0400 Subject: [openstack-dev] [Octavia] Multinode setup Message-ID: Hello everyone! I'm looking into how to run Octavia services (controller worker, housekeeper, health manager) on several network nodes and get confused with setup guide [1]. Is there any special config option for such case? (controller_ip_port_list probably) What manuals/docs/examples do we have except [2] ? [1] - https://docs.openstack.org/octavia/queens/contributor/guides/dev-quick-start.html [2] - https://github.com/openstack/octavia/blob/stable/queens/devstack/samples/multinode/local-2.conf -- Regards, Ann Taraday -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From saphi070 at gmail.com Mon Nov 26 13:56:16 2018 From: saphi070 at gmail.com (Sa Pham) Date: Mon, 26 Nov 2018 20:56:16 +0700 Subject: [openstack-dev] [Octavia] Multinode setup In-Reply-To: References: Message-ID: <7D8C6984-1733-4AAD-B8F0-8A3FEF122E32@gmail.com> Hi, The controller_ip_port_list option is list of all IP of node which is deployed octavia-health-manager. > On Nov 26, 2018, at 8:41 PM, Anna Taraday wrote: > > Hello everyone! > > I'm looking into how to run Octavia services (controller worker, housekeeper, health manager) on several network nodes and get confused with setup guide [1]. > Is there any special config option for such case? (controller_ip_port_list probably) > What manuals/docs/examples do we have except [2] ? > > [1] - https://docs.openstack.org/octavia/queens/contributor/guides/dev-quick-start.html > [2] -https://github.com/openstack/octavia/blob/stable/queens/devstack/samples/multinode/local-2.conf -- > Regards, > Ann Taraday > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Sa Pham Dang Cloud RnD Team - VCCloud / VCCorp Phone: 0986.849.582 Skype: great_bn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From bdobreli at redhat.com Mon Nov 26 14:12:55 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Mon, 26 Nov 2018 15:12:55 +0100 Subject: [openstack-dev] [tripleo] Zuul Queue backlogs and resource usage Message-ID: <118afcca-b6a4-4529-3286-11dfefda68b4@redhat.com> Here is a related bug [1] and implementation [1] for that. PTAL folks! [0] https://bugs.launchpad.net/tripleo/+bug/1804822 [1] https://review.openstack.org/#/q/topic:base-container-reduction > Let's also think of removing puppet-tripleo from the base container. > It really brings the world-in (and yum updates in CI!) each job and each > container! > So if we did so, we should then either install puppet-tripleo and co on > the host and bind-mount it for the docker-puppet deployment task steps > (bad idea IMO), OR use the magical --volumes-from > option to mount volumes from some "puppet-config" sidecar container > inside each of the containers being launched by docker-puppet tooling. On Wed, Oct 31, 2018 at 11:16 AM Harald Jensås wrote: > We add this to all images: > > https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646e535cf972c98ef/container-images/tripleo_kolla_template_overrides.j2#L35 > > /bin/sh -c yum -y install iproute iscsi-initiator-utils lvm2 python > socat sudo which openstack-tripleo-common-container-base rsync cronie > crudini openstack-selinux ansible python-shade puppet-tripleo python2- > kubernetes && yum clean all && rm -rf /var/cache/yum 276 MB > > Is the additional 276 MB reasonable here? > openstack-selinux <- This package run relabling, does that kind of > touching the filesystem impact the size due to docker layers? > > Also: python2-kubernetes is a fairly large package (18007990) do we use > that in every image? I don't see any tripleo related repos importing > from that when searching on Hound? The original commit message[1] > adding it states it is for future convenience. > > On my undercloud we have 101 images, if we are downloading every 18 MB > per image thats almost 1.8 GB for a package we don't use? (I hope it's > not like this? With docker layers, we only download that 276 MB > transaction once? Or?) > > > [1] https://review.openstack.org/527927 -- Best regards, Bogdan Dobrelya, Irc #bogdando From rosmaita.fossdev at gmail.com Mon Nov 26 14:21:37 2018 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Mon, 26 Nov 2018 09:21:37 -0500 Subject: [openstack-dev] [glance] about use shared image with each other In-Reply-To: References: <6d53c9e9-98f6-d594-bbfb-837c74d5fbae@gmail.com> Message-ID: On 11/21/18 7:16 AM, Rambo wrote: > yes, but I also have a question, Do we have the quota limit for requests > to share the image to each other? For example, someone shares the image > with me without stop, how do we deal with it? Given that the producer-consumer notifications are not handled by Glance, this is not a problem. (Or, to be more precise, not a problem for Glance.) A producer can share an image with you multiple times, but since the producer cannot change your member-status, it will remain in 'pending' (or 'rejected' if you've already rejected it). So there is no quota necessary for this operation. >   > ------------------ Original ------------------ > *From: * "Brian Rosmaita"; > *Date: * Mon, Nov 19, 2018 10:26 PM > *To: * "OpenStack Developmen"; > *Subject: * Re: [openstack-dev] [glance] about use shared image with > each other >   > On 11/19/18 7:58 AM, Rambo wrote: >> Hi,all >> >>      Recently, I want to use the shared image with each other.I find it >> isn't convenient that the producer notifies the consumer via email which >> the image has been shared and what its UUID is. In other words, why the >> image api v2 is no provision for producer-consumer communication? > > The design goal for Image API v2 image sharing was to provide an > infrastructure for an "image marketplace" in an OpenStack cloud by (a) > making it easy for cloud end users to share images, and (b) making it > easy for end users not to be spammed by other end users taking advantage > of (a).  When v2 image sharing was introduced in the Grizzly release, we > did not want to dictate how producer-consumer communication would work > (because we had no idea how it would develop), so we left it up to > operators and end users to figure this out. > > The advantage of email communication is that client side message > filtering is available for whatever client a particular cloud end-user > employs, and presumably that end-user knows how to manipulate the > filters without learning some new scheme (or, if the end-user doesn't > know, learning how to filter messages will apply beyond just image > sharing, which is a plus). > > Also, email communication is just one way to handle producer-consumer > communication.  Some operators have adjusted their web interfaces so > that when an end-user looks at the list of images available, a > notification pops up if the end-user has any images that have been > shared with them and are still in "pending" status.  There are various > other creative things you can do using the normal API calls with regular > user credentials. > > In brief, we figured that if an image marketplace evolved in a > particular cloud, producers and consumers would forge their own > relationships in whatever way made the most sense for their particular > use cases.  So we left producer-consumer communication out-of-band. > >>       To make it is more convenient,  if we can add a task to change the >> member_status from "pending" to "accepted" when we share the image with >> each other. It is similar to the resize_confirm in Nova, we can control >> the time interval in config. > > You could do this, but that would defeat the entire purpose of the > member statuses implementation, and hence I do not recommend it.  See > OSSN-0005 [1] for more about this issue. > > Additionally, since the Ocata release, "community" images have been > available.  These do not have to be accepted by an end user (but they > also don't show up in the default image-list response).  Who can > "communitize" an image is governed by policy. > > See [2] for a discussion of the various types of image sharing currently > available in the Image API v2.  The Image Service API v2 api-ref [3] > contains a brief discussion of image visibility and image sharing that > may also be useful.  Finally, the Glance Ocata release notes [4] have an > extensive discussion of image visibility. > >>        Can you tell me more about this?Thank you very much! > > The original design page on the wiki [5] has a list of 14 use cases we > wanted to address; looking through those will give you a better idea of > why we made the design choices we did. > > Hope this helps! > > cheers, > brian > > [0] > http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html > [1] https://wiki.openstack.org/wiki/OSSN/1226078 > [2] > http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html > [3] https://developer.openstack.org/api-ref/image/v2/ > [4] https://docs.openstack.org/releasenotes/glance/ocata.html > [5] https://wiki.openstack.org/wiki/Glance-api-v2-image-sharing > > >> >> Best Regards >> Rambo >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From mnaser at vexxhost.com Mon Nov 26 15:30:47 2018 From: mnaser at vexxhost.com (Mohammed Naser) Date: Mon, 26 Nov 2018 10:30:47 -0500 Subject: [Openstack] Way to see VMs under all tenants by non-admin? In-Reply-To: References: Message-ID: Hi Ken: https://github.com/openstack/nova/blob/juno-eol/nova/api/openstack/compute/servers.py#L588-L590 Good luck (with your upgrades ;)) Mohammed On Mon, Nov 26, 2018 at 9:39 AM Ken D'Ambrosio wrote: > Hey, all. I've had a request for a non-admin user to see all the VMs > currently running, irrespective of project. I've gone through the > policy.json file (this is Juno) and enabled everything I could think of > that seemed appropriate, to no avail. Is there any way to do this > without granting him flat-out admin? > > Thanks! > > -Ken > > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser at vexxhost.com W. http://vexxhost.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From zbitter at redhat.com Mon Nov 26 15:47:10 2018 From: zbitter at redhat.com (Zane Bitter) Date: Mon, 26 Nov 2018 10:47:10 -0500 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: <20181122234340.GE24690@thor.bakeyournoodle.com> References: <20181122234340.GE24690@thor.bakeyournoodle.com> Message-ID: <1ca0e1a7-58a1-8f91-617b-7be7b0df0e1b@redhat.com> On 22/11/18 6:43 PM, Tony Breeds wrote: >> ### 3 - Maintain a private interface for ThreadingEvent only on stable/rocky >> impacted projects: oslo.service >> related reviews: >> -https://review.openstack.org/619342/ >> >> pros: >> - straightforward >> cons: >> - Changing the loopingcall module semantics as it is different type >> - stable only patches >> - misunderstoud service customer between Threading, eventlet, etc.. and >> master behavior > A variation of this (without adding the debtcollector requirement) might > work as IIUC all versions of oslo.service < 1.32.0 (except 1.31.6) would > work and doesn't introduce any new policy violations. > > Adding debcollector is great but introduces at least the semver issues > from option #1 Hey Tony, can you explain the debtcollector issue a bit more? Is it just that we generally promise to not adding anything to requirements.txt on stable branches? In this case, debtcollector, appears to already be a transitive dependency of something that oslo.service already requires (it appears in lower-constraints.txt, at least), so I was assuming that there wouldn't be any real-world consequences. Does that change things? TBH it would be trivial to do something equivalent without adding the new requirement, so I guess the easiest thing is if I just update the patch to do that. >> ### 4 - Don't use private interface in oslo.service >> impacted projects: nova >> related reviews: >> -https://review.openstack.org/#/c/619360/ >> >> pros: >> - straightforward >> cons: >> - this could work but it is not the same sematics as before as the type has >> changed >> - stable only patches >> - misunderstoud service customer between Threading, eventlet, etc.. and >> master behavior > I think this is more or less the same as Option #3 in terms of impact. > If that's right it could be acceptable. It's slightly higher impact, because you wouldn't be able to upgrade oslo.service past 1.31.5 and still run the unit tests on old versions of Nova. Whereas with option #3 you could just upgrade oslo.service to 1.31.7, or just upgrade Nova, and either way everything would work. Not that we shouldn't do this *as well*, but IMHO we still need to do #3. >> ### 5 - Leave the CPU bug open on rocky >> impacted projects: oslo.service >> related reviews: - >> >> pros: >> - Nova project doesn't impacted >> cons: >> - reintroduce the CPU issue > > I think if #3, or #4 works we can avoid the revert part of this but > regardless we're going to need to block 1.31.6 so I've created: > > https://review.openstack.org/#/c/619655/ ; and abandonedhttps://review.openstack.org/#/c/618834/ I think with #4 we wouldn't need to block, but I agree that blocking 1.31.6 and merging some version of #3 is the better solution. >> Personally: >> - I prefer the #4 or the #2 and they seem to be smooth changes without >> earthquake or anything like this >> - the #6 seems to be the worst solution on my side >> - the #1 introduce semver issue and policy violations so I don't think we >> can continue with it > I'm not certain how this is really different to the options already > presented but I agree anything substantial on stable branches is pretty > much a non-starter. > >> Thoughts? > My preference is for a modified version of #3, unless I'm beaten to it +1 cheers, Zane. From ken at jots.org Mon Nov 26 14:32:51 2018 From: ken at jots.org (Ken D'Ambrosio) Date: Mon, 26 Nov 2018 09:32:51 -0500 Subject: [Openstack] Way to see VMs under all tenants by non-admin? Message-ID: Hey, all. I've had a request for a non-admin user to see all the VMs currently running, irrespective of project. I've gone through the policy.json file (this is Juno) and enabled everything I could think of that seemed appropriate, to no avail. Is there any way to do this without granting him flat-out admin? Thanks! -Ken _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From cdent+os at anticdent.org Mon Nov 26 15:51:07 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Mon, 26 Nov 2018 15:51:07 +0000 (GMT) Subject: [nova] [placement] placement functional testing Message-ID: When https://review.openstack.org/#/c/617941/ merges (probably today), nova will be running its functional tests against openstack/placement and the existing unit and functional tests in nova that were solely testing placement will be gone. Tests like those in functional/test_servers.py will still be testing against real placement code, using a PlacementFixture that establishes a in-process placement service and an in-RAM database. If you have changes in progress that use placement anywhere in your functional tests it is quite likely you will have some merge conflicts. I tried to make it so that in most cases you don't need to do anything to have a working placement: If you're using the Intergated Helpers, it ought to just work. But if it doesn't please ask here, or find me in IRC and I can try to help. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From smooney at redhat.com Mon Nov 26 16:13:33 2018 From: smooney at redhat.com (Sean Mooney) Date: Mon, 26 Nov 2018 16:13:33 +0000 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: Message-ID: On Mon, 2018-11-26 at 17:45 +0700, Zufar Dhiyaulhaq wrote: > Hi, > > I am deploying OpenStack with 3 compute node, but I am seeing an abnormal distribution of instance, the instance is > only deployed in a specific compute node, and not distribute among other compute node. > > this is my nova.conf from the compute node. (template jinja2 based) hi, the default behavior of nova used to be spread not pack and i belive it still is. the default behavior with placement however is closer to a packing behavior as allcoation candiates are retrunidn in an undefined but deterministic order. on a busy cloud this does not strictly pack instaces but on a quite cloud it effectivly does you can try and enable randomisation of the allocation candiates by setting this config option in the nova.conf of the shcduler to true. https://docs.openstack.org/nova/latest/configuration/config.html#placement.randomize_allocation_candidates on that note can you provide the nova.conf for the schduelr is used instead of the compute node nova.conf. if you have not overriden any of the nova defaults the ram and cpu weigher should spread instances withing the allocation candiates returned by placement. > > [DEFAULT] > osapi_compute_listen = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} > metadata_listen = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} > enabled_apis = osapi_compute,metadata > transport_url = rabbit://openstack:{{ rabbitmq_pw }}@{{ controller1_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ > controller2_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ controller3_ip_man }}:5672 > my_ip = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} > use_neutron = True > firewall_driver = nova.virt.firewall.NoopFirewallDriver > [api] > auth_strategy = keystone > [api_database] > connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_api > [barbican] > [cache] > backend=oslo_cache.memcache_pool > enabled=true > memcache_servers={{ controller1_ip_man }}:11211,{{ controller2_ip_man }}:11211,{{ controller3_ip_man }}:11211 > [cells] > [cinder] > os_region_name = RegionOne > [compute] > [conductor] > [console] > [consoleauth] > [cors] > [crypto] > [database] > connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova > [devices] > [ephemeral_storage_encryption] > [filter_scheduler] > [glance] > api_servers = http://{{ vip }}:9292 > [guestfs] > [healthcheck] > [hyperv] > [ironic] > [key_manager] > [keystone] > [keystone_authtoken] > auth_url = http://{{ vip }}:5000/v3 > memcached_servers = {{ controller1_ip_man }}:11211,{{ controller2_ip_man }}:11211,{{ controller3_ip_man }}:11211 > auth_type = password > project_domain_name = default > user_domain_name = default > project_name = service > username = nova > password = {{ nova_pw }} > [libvirt] > [matchmaker_redis] > [metrics] > [mks] > [neutron] > url = http://{{ vip }}:9696 > auth_url = http://{{ vip }}:35357 > auth_type = password > project_domain_name = default > user_domain_name = default > region_name = RegionOne > project_name = service > username = neutron > password = {{ neutron_pw }} > service_metadata_proxy = true > metadata_proxy_shared_secret = {{ metadata_secret }} > [notifications] > [osapi_v21] > [oslo_concurrency] > lock_path = /var/lib/nova/tmp > [oslo_messaging_amqp] > [oslo_messaging_kafka] > [oslo_messaging_notifications] > [oslo_messaging_rabbit] > [oslo_messaging_zmq] > [oslo_middleware] > [oslo_policy] > [pci] > [placement] > os_region_name = RegionOne > project_domain_name = Default > project_name = service > auth_type = password > user_domain_name = Default > auth_url = http://{{ vip }}:5000/v3 > username = placement > password = {{ placement_pw }} > [quota] > [rdp] > [remote_debug] > [scheduler] > discover_hosts_in_cells_interval = 300 > [serial_console] > [service_user] > [spice] > [upgrade_levels] > [vault] > [vendordata_dynamic_auth] > [vmware] > [vnc] > enabled = true > keymap=en-us > novncproxy_base_url = https://{{ vip }}:6080/vnc_auto.html > novncproxy_host = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} > [workarounds] > [wsgi] > [xenserver] > [xvp] > [placement_database] > connection=mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_placement > > what is the problem? I have lookup the openstack-nova-scheduler in the controller node but it's running well with only > warning > > nova-scheduler[19255]: /usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py:332: NotSupportedWarning: > Configuration option(s) ['use_tpool'] not supported > > the result I want is the instance is distributed in all compute node. > Thank you. > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From mriedemos at gmail.com Mon Nov 26 16:43:47 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Mon, 26 Nov 2018 10:43:47 -0600 Subject: [openstack-dev] [nova] Stein forum session notes In-Reply-To: References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> Message-ID: On 11/21/2018 2:38 PM, melanie witt wrote: >> Update on placement extraction from nova >> ======================================== >> - Upgrade step additions from integrated placement to extracted >> placement in TripleO and OpenStackAnsible are being worked on now >> - Reshaper patches for libvirt and xenapi drivers are up for review >> - Lab test for vGPU upgrade and reshape + new schedule for libvirt >> driver patch has been done already > > This is news to me. Can someone provide me a link to where I can get > some more information about this? It was in the original checklist from the impromptu meeting in Denver: http://lists.openstack.org/pipermail/openstack-dev/2018-September/134541.html -- Thanks, Matt From jaypipes at gmail.com Mon Nov 26 16:55:22 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Mon, 26 Nov 2018 11:55:22 -0500 Subject: [openstack-dev] [nova] Stein forum session notes In-Reply-To: References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> Message-ID: On 11/26/2018 11:43 AM, Matt Riedemann wrote: > On 11/21/2018 2:38 PM, melanie witt wrote: >>> Update on placement extraction from nova >>> ======================================== >>> - Upgrade step additions from integrated placement to extracted >>> placement in TripleO and OpenStackAnsible are being worked on now >>> - Reshaper patches for libvirt and xenapi drivers are up for review >>> - Lab test for vGPU upgrade and reshape + new schedule for libvirt >>> driver patch has been done already >> >> This is news to me. Can someone provide me a link to where I can get >> some more information about this? > > It was in the original checklist from the impromptu meeting in Denver: > > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134541.html What was news to me was the "has been done already" part of the Lab test for vGPU upgrade. I was asking for information on where I can see that Lab test. Thanks, -jay From ken at jots.org Mon Nov 26 16:07:46 2018 From: ken at jots.org (Ken D'Ambrosio) Date: Mon, 26 Nov 2018 11:07:46 -0500 Subject: [Openstack] Way to see VMs under all tenants by non-admin? In-Reply-To: References: Message-ID: <70a159872f99aa58e3c73c9b70c922ca@jots.org> On 2018-11-26 10:30, Mohammed Naser wrote: > Hi Ken: > > https://github.com/openstack/nova/blob/juno-eol/nova/api/openstack/compute/servers.py#L588-L590 OK, I feel kinda dumb, but I never realized I could go and search for policy.json policy in the pertinent Python files. That's awesome! Doesn't exactly help me now, but will certainly come in handy in the future. Thanks, -Ken > Good luck (with your upgrades ;)) > > Mohammed > > On Mon, Nov 26, 2018 at 9:39 AM Ken D'Ambrosio wrote: > >> Hey, all. I've had a request for a non-admin user to see all the VMs >> currently running, irrespective of project. I've gone through the >> policy.json file (this is Juno) and enabled everything I could think of >> that seemed appropriate, to no avail. Is there any way to do this >> without granting him flat-out admin? >> >> Thanks! >> >> -Ken >> >> _______________________________________________ >> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> Post to : openstack at lists.openstack.org >> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > -- > Mohammed Naser -- vexxhost > > ----------------------------------------------------- > D. 514-316-8872 > D. 800-910-1726 ext. 200 > E. mnaser at vexxhost.com > W. http://vexxhost.com [1] Links: ------ [1] http://vexxhost.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From mriedemos at gmail.com Mon Nov 26 17:01:10 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Mon, 26 Nov 2018 11:01:10 -0600 Subject: [openstack-dev] [nova] Stein forum session notes In-Reply-To: References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> Message-ID: <73e6cd98-ebba-1e67-9c48-032fac04946c@gmail.com> On 11/26/2018 10:55 AM, Jay Pipes wrote: > What was news to me was the "has been done already" part of the Lab test > for vGPU upgrade. > > I was asking for information on where I can see that Lab test. Oh, heh. It's in Sylvain's brain somewhere. -- Thanks, Matt From smooney at redhat.com Mon Nov 26 17:15:57 2018 From: smooney at redhat.com (Sean Mooney) Date: Mon, 26 Nov 2018 17:15:57 +0000 Subject: [openstack-dev] [nova] Stein forum session notes In-Reply-To: <73e6cd98-ebba-1e67-9c48-032fac04946c@gmail.com> References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> <73e6cd98-ebba-1e67-9c48-032fac04946c@gmail.com> Message-ID: <1afe33bfaadbd459b3329ae9ba6b31a7141293ec.camel@redhat.com> On Mon, 2018-11-26 at 11:01 -0600, Matt Riedemann wrote: > On 11/26/2018 10:55 AM, Jay Pipes wrote: > > What was news to me was the "has been done already" part of the Lab test > > for vGPU upgrade. > > > > I was asking for information on where I can see that Lab test. > > Oh, heh. It's in Sylvain's brain somewhere. sylvain posted some past bins to irc a while ago sometime after denver and before the summit i want to say mid to late october. i dont recall a ML post but there may have been one. basicially if i recall the irc converstation and pastbin contence correctly he deployed master, took a snapshot of the placemnet inventories, checked out the reshaper chage and restarted nova services took a snapshot of the reshaped placemetn invetories. > From johnsomor at gmail.com Mon Nov 26 17:55:49 2018 From: johnsomor at gmail.com (Michael Johnson) Date: Mon, 26 Nov 2018 09:55:49 -0800 Subject: [all] maintainers/reviewers/committers wanted for tiny projects In-Reply-To: References: Message-ID: Octavia is using WSME and I am still an active core reviewer. Michael On Thu, Nov 22, 2018 at 11:23 AM Chris Dent wrote: > > On Mon, 19 Nov 2018, Chris Dent wrote: > > > Paste: WSGI middleware management framework > > https://github.com/cdent/paste > > This was recently adopted because it had issues with Python 3.7 > > and there were concerns that OpenStack's continued use might > > present problems. > > > > I've also just inherited the pastedeploy package, and will be > > migrating it over to github too. It will also need some help. > > In a nice stroke of luck, the Pylons project noticed pastedeploy > was moving and we've worked out that is should live under their > github organization: > > https://github.com/Pylons/pastedeploy > > -- > Chris Dent ٩◔̯◔۶ https://anticdent.org/ > freenode: cdent tw: @anticdent From yamamoto at midokura.com Mon Nov 26 17:59:04 2018 From: yamamoto at midokura.com (Takashi Yamamoto) Date: Tue, 27 Nov 2018 02:59:04 +0900 Subject: [neutron] bug deputy report Message-ID: Critical https://bugs.launchpad.net/neutron/+bug/1803745 neutron-dynamic-routing: unit test failures with master branch of neutron High https://bugs.launchpad.net/neutron/+bug/1804180 Neutron ovs cleanup cannot run on Windows https://bugs.launchpad.net/neutron/+bug/1794718 Neutron VPNAAS don't update site connections on python3 https://bugs.launchpad.net/neutron/+bug/1799737 l3 agent external_network_bridge broken with ovs Medium https://bugs.launchpad.net/neutron/+bug/1804327 occasional connection reset on SNATed after tcp retries Low https://bugs.launchpad.net/neutron/+bug/1803723 [fwaas] _is_supported_by_fw_l2_driver method is hard linked to the default ML2/OVS core plugin implementation https://bugs.launchpad.net/neutron/+bug/1804274 Neutron error agreggation interfaces https://bugs.launchpad.net/neutron/+bug/1804259 DB: sorting on elements which are AssociationProxy fails Undecided https://bugs.launchpad.net/neutron/+bug/1802971 tempest volume_boot_pattern and basic_ops running concurrently causing timeouts RFE https://bugs.launchpad.net/neutron/+bug/1804634 [RFE] l3_agent should separate router_info creation logic Incomplete https://bugs.launchpad.net/neutron/+bug/1803919 [L2] dataplane down during ovs-agent restart https://bugs.launchpad.net/neutron/+bug/1804842 When kill(sometines doesn't restart) the ovs switch or restart it in the compute nodes vm conectivity is lost https://bugs.launchpad.net/neutron/+bug/1804173 Metadata proxy server SSL handshake problem if Python >= 3 https://bugs.launchpad.net/neutron/+bug/1802736 Reporting to Jaeger with OSProfiler doesn't work https://bugs.launchpad.net/neutron/+bug/1801738 Assigning a FIP to NLBaaS VIP port doesn't affect Designate https://bugs.launchpad.net/neutron/+bug/1801779 Policy rule rule:create_port:fixed_ips:subnet_id doesn't allow non-admin to create port on specific subnet From jimmy at openstack.org Mon Nov 26 18:01:25 2018 From: jimmy at openstack.org (Jimmy McArthur) Date: Mon, 26 Nov 2018 12:01:25 -0600 Subject: [Openstack] my ask.openstack.org question has waited for moderator approval for 17 days In-Reply-To: References: Message-ID: <5BFC34F5.2080108@openstack.org> Hi all - Just a quick follow up on this... I just discovered a quirky UX bug that might explain some frustration people have been having with the moderation. There were messages dating back to March 2018. Basically, when you click to approve/disapprove/etc... it appears that the queue is cleared. But if you go to the menu and go back to the moderation page (or just reload), you get a whole new batch. My guess is moderators have been thinking they're clearing things out, but not. I know that's what happened to me multiple times over a period of many months. I've since really and truly cleared out the queue. I found about 25 users that were spammers and blocked all of them. I also auto-approved anyone that was a valid poster so they can post without moderation moving forward. Ask.openstack.org is still a valued tool for our community and another way for people to engage outside of the mls. It's full of not just valid questions, but a lot of valid answers. I highly encourage those that are curious about becoming a moderator to check it out and let me know. I'm happy to elevate your user to a moderator if you want to contribute. Cheers, Jimmy > Bernd Bausch > October 29, 2018 at 6:16 PM > If there is a shortage of moderators, I volunteer. > > > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Jacob Burckhardt > October 29, 2018 at 6:03 PM > My question on ask.openstack.org says "This post is awaiting moderation". > > It has been like that for 17 days. If you are a moderator, I'd > appreciate if you'd decide whether to publicly post my question: > > https://ask.openstack.org/en/question/116591/is-there-example-of-using-python-zunclient-api/ > > Thanks. > > -Jacob Burckhardt > > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdent+os at anticdent.org Mon Nov 26 18:01:34 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Mon, 26 Nov 2018 18:01:34 +0000 (GMT) Subject: [all] maintainers/reviewers/committers wanted for tiny projects In-Reply-To: References: Message-ID: On Mon, 26 Nov 2018, Michael Johnson wrote: > Octavia is using WSME and I am still an active core reviewer. Ah, excellent. Glad to hear that someone is still watching there, I'll feel less anxious about that one then. Do you like WSME or is it more of a case of it was there? -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From mrhillsman at gmail.com Mon Nov 26 18:06:24 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Mon, 26 Nov 2018 12:06:24 -0600 Subject: [Openstack] my ask.openstack.org question has waited for moderator approval for 17 days In-Reply-To: <5BFC34F5.2080108@openstack.org> References: <5BFC34F5.2080108@openstack.org> Message-ID: Thanks Jimmy On Mon, Nov 26, 2018 at 12:02 PM Jimmy McArthur wrote: > Hi all - > > Just a quick follow up on this... I just discovered a quirky UX bug that > might explain some frustration people have been having with the > moderation. There were messages dating back to March 2018. Basically, > when you click to approve/disapprove/etc... it appears that the queue is > cleared. But if you go to the menu and go back to the moderation page (or > just reload), you get a whole new batch. My guess is moderators have been > thinking they're clearing things out, but not. I know that's what happened > to me multiple times over a period of many months. > > I've since really and truly cleared out the queue. I found about 25 users > that were spammers and blocked all of them. I also auto-approved anyone > that was a valid poster so they can post without moderation moving forward. > > Ask.openstack.org is still a valued tool for our community and another > way for people to engage outside of the mls. It's full of not just valid > questions, but a lot of valid answers. I highly encourage those that are > curious about becoming a moderator to check it out and let me know. I'm > happy to elevate your user to a moderator if you want to contribute. > > Cheers, > Jimmy > > > > Bernd Bausch > October 29, 2018 at 6:16 PM > If there is a shortage of moderators, I volunteer. > > > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Jacob Burckhardt > October 29, 2018 at 6:03 PM > My question on ask.openstack.org says "This post is awaiting moderation". > > It has been like that for 17 days. If you are a moderator, I'd appreciate > if you'd decide whether to publicly post my question: > > > https://ask.openstack.org/en/question/116591/is-there-example-of-using-python-zunclient-api/ > > Thanks. > > -Jacob Burckhardt > > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnsomor at gmail.com Mon Nov 26 18:15:20 2018 From: johnsomor at gmail.com (Michael Johnson) Date: Mon, 26 Nov 2018 10:15:20 -0800 Subject: [OCTAVIA] How to monitor amphora In-Reply-To: References: Message-ID: This is an area we have been talking about recently at the PTGs. Adding connection log offloading is on our short term road map. Someone had signed up for that, but has pivoted to work on other items. Due to that I can't say if it will make it for Stein or not. If someone is interested in picking this up, I can help point you to the documentation of our discussions at the PTGs. If not, I would expect it to land late in Stein or early in Train. As for other monitoring, CPU, etc. this is area we currently leave to the operator, but would like to do some work on. As mentioned above gnocchi appears to be a nice time-series database for metrics collection. We would need to have some design discussions on what and how to collect the data. As you mentioned, monitoring agents can be added to the amphora image at build time if the operator would like to add a local tool set. As with most parts of Octavia, we try to make things "plug-able" so that operators have a choice of tools. Both the log offloading and metrics should follow that design principle. Michael On Sun, Nov 25, 2018 at 10:49 PM Gaël THEROND wrote: > > Hi! > > I’ve taken some time to read your presentation and I have to say thank you for your wonderful work ! It’s pretty much complete and with code example which is really cool. > > It’s exactly what I was looking for. > If I could just suggest one thing, it would be to give operators freedom to choose which logging and which metrics clients they want to use. > > Doing so would avoid having to rely on gnocchi as you would be able to choose the clients type at amphora build time and specify clients target at runtime using the amphora-agent. > > On another hand, it might we’ll be tricky to do so as everything is namespaced into the amphora instance. > > As suggested using gnocchi to store HAProxy logs may well be the easiest short path actually, I’m wondering if it would be possible for searchlight to use that logs at some point. > > Anyway, thanks for the awesome job. > For now I’ll keep it simple and just use the API for basic status. > > Kind regards, > G. > > Le lun. 26 nov. 2018 à 04:23, Sa Pham a écrit : >> >> yes. I have discussed with the Octavia team. PTL Johnson has suggested me to use gnocchi to store octavia amphora metric. >> >> >> >> On Wed, Nov 21, 2018 at 3:16 PM Gaël THEROND wrote: >>> >>> Hi! Thanks for this material, I’ll have a look at it. >>> >>> As our philosophy at work is to always push upstream all our patchs/features or bug fixes, I won’t modify and keep the source code on our own and if we need further features like that I think we will rather push for a Blueprint with all required commits. >>> >>> Did you already discussed that topic with the Octavia team? >>> >>> Thanks a lot. >>> >>> Le mer. 21 nov. 2018 à 09:12, Sa Pham a écrit : >>>> >>>> Hi, >>>> >>>> In Vietnam Openinfra Days 2018, I have a presentation about monitoring and logging for Octavia Amphora. We have to customize octavia source code to do this. I send you my presentation slide: >>>> https://drive.google.com/file/d/1dHXExEKrHDg4Cf3D1fBeulLDW_G-txLr/view?usp=sharing >>>> >>>> Best, >>>> >>>> On Wed, Nov 21, 2018 at 3:05 PM Gaël THEROND wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> As already discussed I had to test Octavia as our corporate LoadBalancer solution and it was a success. >>>>> >>>>> Thank to everyone on this list that assisted me and especially Michael Octavia is fully working and without weird nightmare glitches. >>>>> >>>>> Now that I validated the technical part of my project, I need to enter more operationals questions such as what’s the best way to monitor and log amphora? >>>>> >>>>> I would like to be able to get a monitoring and logging agent installed on the amphora in order to get proper metrics about what’s going on with the LoadBalancer, is it fully cpu loaded? Is it using all network resources available, are the file descriptors near the initial limits? How much xxx HTTP return code the loadBalancer is facing and send those logs to an ELK or something similar. >>>>> >>>>> Do you know if that something that I could achieve by adding more elements to the image at DIB time or are there any other better best-practices that I should be aware of ? >>>>> >>>>> As Octavia is creating a namespace for each HAProxy process, I am wandering if it’s even possible. >>>>> >>>>> Thanks a lot for your hard work guys. >>>>> >>>>> Kind regards, >>>>> >>>> >>>> >>>> -- >>>> Sa Pham Dang >>>> Cloud RnD Team - VCCloud >>>> Phone/Telegram: 0986.849.582 >>>> Skype: great_bn >>>> >>>> >> >> >> -- >> Sa Pham Dang >> Cloud RnD Team - VCCloud >> Phone/Telegram: 0986.849.582 >> Skype: great_bn >> >> From johnsomor at gmail.com Mon Nov 26 18:28:34 2018 From: johnsomor at gmail.com (Michael Johnson) Date: Mon, 26 Nov 2018 10:28:34 -0800 Subject: [openstack-dev] [Octavia] Multinode setup In-Reply-To: <7D8C6984-1733-4AAD-B8F0-8A3FEF122E32@gmail.com> References: <7D8C6984-1733-4AAD-B8F0-8A3FEF122E32@gmail.com> Message-ID: At the moment that is all we have for a setup guide. That said, all of the Octavia controller processes are fully HA capable. The one setting I can think of is the controller_ip_port_list setting mentioned above. It will need to contain an entry for each health manager IP/port as Sa Pham mentioned. You will also want to load balance connections across your API instances. Load balancing for the other processes is built into the design and does not require any additional load balancing. Michael On Mon, Nov 26, 2018 at 5:59 AM Sa Pham wrote: > > Hi, > > The controller_ip_port_list option is list of all IP of node which is deployed octavia-health-manager. > > > > On Nov 26, 2018, at 8:41 PM, Anna Taraday wrote: > > Hello everyone! > > I'm looking into how to run Octavia services (controller worker, housekeeper, health manager) on several network nodes and get confused with setup guide [1]. > Is there any special config option for such case? (controller_ip_port_list probably) > What manuals/docs/examples do we have except [2] ? > > [1] - https://docs.openstack.org/octavia/queens/contributor/guides/dev-quick-start.html > [2] -https://github.com/openstack/octavia/blob/stable/queens/devstack/samples/multinode/local-2.conf > -- > Regards, > Ann Taraday > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > Sa Pham Dang > Cloud RnD Team - VCCloud / VCCorp > Phone: 0986.849.582 > Skype: great_bn > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From johnsomor at gmail.com Mon Nov 26 18:34:26 2018 From: johnsomor at gmail.com (Michael Johnson) Date: Mon, 26 Nov 2018 10:34:26 -0800 Subject: [all] maintainers/reviewers/committers wanted for tiny projects In-Reply-To: References: Message-ID: In general we like it. It has some corner cases that can be challenging to work around, but so far we have accomplished everything we need. We developed our API during the window where WSME was the "future", so we used it to be "good OpenStack citizens". We do not have any immediate plans to stop using it. Michael On Mon, Nov 26, 2018 at 10:04 AM Chris Dent wrote: > > On Mon, 26 Nov 2018, Michael Johnson wrote: > > > Octavia is using WSME and I am still an active core reviewer. > > Ah, excellent. Glad to hear that someone is still watching > there, I'll feel less anxious about that one then. > > Do you like WSME or is it more of a case of it was there? > > -- > Chris Dent ٩◔̯◔۶ https://anticdent.org/ > freenode: cdent tw: @anticdent From mriedemos at gmail.com Mon Nov 26 20:40:51 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Mon, 26 Nov 2018 14:40:51 -0600 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: Message-ID: On 11/26/2018 10:13 AM, Sean Mooney wrote: > hi, the default behavior of nova used to be spread not pack and i belive it still is. > the default behavior with placement however is closer to a packing behavior as > allcoation candiates are retrunidn in an undefined but deterministic order. > > on a busy cloud this does not strictly pack instaces but on a quite cloud it effectivly does > > you can try and enable randomisation of the allocation candiates by setting this config option in > the nova.conf of the shcduler to true. > https://docs.openstack.org/nova/latest/configuration/config.html#placement.randomize_allocation_candidates > > on that note can you provide the nova.conf for the schduelr is used instead of the compute node nova.conf. > if you have not overriden any of the nova defaults the ram and cpu weigher should spread instances withing > the allocation candiates returned by placement. Or simply the other hosts are being filtered out, either because they aren't reporting into placement or some other filter is removing them. You should be able to see which hosts are being filtered if you enable debug logging in the nova-scheduler process (via the "debug" configuration option). -- Thanks, Matt From mriedemos at gmail.com Mon Nov 26 20:43:49 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Mon, 26 Nov 2018 14:43:49 -0600 Subject: [Openstack] Way to see VMs under all tenants by non-admin? In-Reply-To: <70a159872f99aa58e3c73c9b70c922ca@jots.org> References: <70a159872f99aa58e3c73c9b70c922ca@jots.org> Message-ID: <5cbb68e9-a540-14ad-b647-f6d2f7e65666@gmail.com> On 11/26/2018 10:07 AM, Ken D'Ambrosio wrote: > OK, I feel kinda dumb, but I never realized I could go and search for > policy.json policy in the pertinent Python files.  That's awesome! > Doesn't exactly help me now, but will certainly come in handy in the future. Once you get to a release new enough where the policy rules are documented, you shouldn't have to look in the code, e.g.: https://docs.openstack.org/nova/latest/configuration/policy.html Note that ^ is for master (Stein) so you'd need to replace "latest" with whatever release you're on, and we didn't generate those docs in Juno (policy-in-code was added in newton [1]). [1] https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/policy-in-code.html -- Thanks, Matt From openstack at nemebean.com Mon Nov 26 21:36:04 2018 From: openstack at nemebean.com (Ben Nemec) Date: Mon, 26 Nov 2018 15:36:04 -0600 Subject: Any way to reply to archived messages? Message-ID: Let's say hypothetically someone procrastinated too long on the mailing list switchover and missed some messages on openstack-discuss, but now wants to reply to them. Is there any way to do that without breaking the threading in people's clients? Perhaps some way to request a message from the archive to be sent to me (err, this hypothetical person ;-). -Ben From fungi at yuggoth.org Mon Nov 26 22:31:16 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 26 Nov 2018 22:31:16 +0000 Subject: Any way to reply to archived messages? In-Reply-To: References: Message-ID: <20181126223115.x5qlf2olghhpvnx5@yuggoth.org> On 2018-11-26 15:36:04 -0600 (-0600), Ben Nemec wrote: > Let's say hypothetically someone procrastinated too long on the > mailing list switchover and missed some messages on > openstack-discuss, but now wants to reply to them. Is there any > way to do that without breaking the threading in people's clients? > Perhaps some way to request a message from the archive to be sent > to me (err, this hypothetical person ;-). Sure! It's *slightly* hacky but looking at the archive of your message, for example: http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000234.html You'll see that your obfuscated E-mail address near the top is a hyperlink. The "In-Reply-To" parameter content can be turned into a message header of the same name like: In-Reply-To: ...and added to the other headers in the reply you're composing. This should preserve threading for everyone just fine. If you want to scrape it from the HTML, just note that the "<", ">" and "@" characters are %-encoded as "%3C", "%3E" and "%40" respectively so you'll need to decode them before putting them into the header. An alternative solution is to visit the top archive index at http://lists.openstack.org/pipermail/openstack-discuss/ and you'll see that next to each month (in this case we only have November so far) there's a "Downloadable version" linked. Following that link will simply bring up a concatenated plaintext version of the month's archive in mbox format (new messages start with "From " at the beginning of the line) and keyword search for the message you're looking for, then copy the content of its "Message-ID" header into an "In-Reply-To" header for your reply. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From flux.adam at gmail.com Mon Nov 26 23:13:10 2018 From: flux.adam at gmail.com (Adam Harwell) Date: Mon, 26 Nov 2018 15:13:10 -0800 Subject: [OCTAVIA] How to monitor amphora In-Reply-To: References: Message-ID: I would also note (though I'm guessing you've heard this from Michael already) that logging and metrics for internal amphora data (like Haproxy logs, agent logs, etc) is on our roadmap to officially expose via some mechanism. We discussed possible ways to do this at the last PTG, but we were just waiting on someone to have time to do a blueprint for review. If you'd like to help get support for this upstream, you're welcome (actually, highly encouraged!) to hop into our IRC channel #openstack-lbaas and we can even help you get started. Hope to see you there! --Adam Harwell (rm_work) On Mon, Nov 26, 2018, 10:19 Michael Johnson wrote: > This is an area we have been talking about recently at the PTGs. > > Adding connection log offloading is on our short term road map. > Someone had signed up for that, but has pivoted to work on other > items. > Due to that I can't say if it will make it for Stein or not. If > someone is interested in picking this up, I can help point you to the > documentation of our discussions at the PTGs. If not, I would expect > it to land late in Stein or early in Train. > > As for other monitoring, CPU, etc. this is area we currently leave to > the operator, but would like to do some work on. As mentioned above > gnocchi appears to be a nice time-series database for metrics > collection. We would need to have some design discussions on what and > how to collect the data. As you mentioned, monitoring agents can be > added to the amphora image at build time if the operator would like to > add a local tool set. > > As with most parts of Octavia, we try to make things "plug-able" so > that operators have a choice of tools. Both the log offloading and > metrics should follow that design principle. > > Michael > > On Sun, Nov 25, 2018 at 10:49 PM Gaël THEROND > wrote: > > > > Hi! > > > > I’ve taken some time to read your presentation and I have to say thank > you for your wonderful work ! It’s pretty much complete and with code > example which is really cool. > > > > It’s exactly what I was looking for. > > If I could just suggest one thing, it would be to give operators freedom > to choose which logging and which metrics clients they want to use. > > > > Doing so would avoid having to rely on gnocchi as you would be able to > choose the clients type at amphora build time and specify clients target at > runtime using the amphora-agent. > > > > On another hand, it might we’ll be tricky to do so as everything is > namespaced into the amphora instance. > > > > As suggested using gnocchi to store HAProxy logs may well be the easiest > short path actually, I’m wondering if it would be possible for searchlight > to use that logs at some point. > > > > Anyway, thanks for the awesome job. > > For now I’ll keep it simple and just use the API for basic status. > > > > Kind regards, > > G. > > > > Le lun. 26 nov. 2018 à 04:23, Sa Pham a écrit : > >> > >> yes. I have discussed with the Octavia team. PTL Johnson has suggested > me to use gnocchi to store octavia amphora metric. > >> > >> > >> > >> On Wed, Nov 21, 2018 at 3:16 PM Gaël THEROND > wrote: > >>> > >>> Hi! Thanks for this material, I’ll have a look at it. > >>> > >>> As our philosophy at work is to always push upstream all our > patchs/features or bug fixes, I won’t modify and keep the source code on > our own and if we need further features like that I think we will rather > push for a Blueprint with all required commits. > >>> > >>> Did you already discussed that topic with the Octavia team? > >>> > >>> Thanks a lot. > >>> > >>> Le mer. 21 nov. 2018 à 09:12, Sa Pham a écrit : > >>>> > >>>> Hi, > >>>> > >>>> In Vietnam Openinfra Days 2018, I have a presentation about > monitoring and logging for Octavia Amphora. We have to customize octavia > source code to do this. I send you my presentation slide: > >>>> > https://drive.google.com/file/d/1dHXExEKrHDg4Cf3D1fBeulLDW_G-txLr/view?usp=sharing > >>>> > >>>> Best, > >>>> > >>>> On Wed, Nov 21, 2018 at 3:05 PM Gaël THEROND > wrote: > >>>>> > >>>>> Hi guys, > >>>>> > >>>>> As already discussed I had to test Octavia as our corporate > LoadBalancer solution and it was a success. > >>>>> > >>>>> Thank to everyone on this list that assisted me and especially > Michael Octavia is fully working and without weird nightmare glitches. > >>>>> > >>>>> Now that I validated the technical part of my project, I need to > enter more operationals questions such as what’s the best way to monitor > and log amphora? > >>>>> > >>>>> I would like to be able to get a monitoring and logging agent > installed on the amphora in order to get proper metrics about what’s going > on with the LoadBalancer, is it fully cpu loaded? Is it using all network > resources available, are the file descriptors near the initial limits? How > much xxx HTTP return code the loadBalancer is facing and send those logs to > an ELK or something similar. > >>>>> > >>>>> Do you know if that something that I could achieve by adding more > elements to the image at DIB time or are there any other better > best-practices that I should be aware of ? > >>>>> > >>>>> As Octavia is creating a namespace for each HAProxy process, I am > wandering if it’s even possible. > >>>>> > >>>>> Thanks a lot for your hard work guys. > >>>>> > >>>>> Kind regards, > >>>>> > >>>> > >>>> > >>>> -- > >>>> Sa Pham Dang > >>>> Cloud RnD Team - VCCloud > >>>> Phone/Telegram: 0986.849.582 > >>>> Skype: great_bn > >>>> > >>>> > >> > >> > >> -- > >> Sa Pham Dang > >> Cloud RnD Team - VCCloud > >> Phone/Telegram: 0986.849.582 > >> Skype: great_bn > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundar.nadathur at intel.com Mon Nov 26 23:08:19 2018 From: sundar.nadathur at intel.com (Nadathur, Sundar) Date: Mon, 26 Nov 2018 15:08:19 -0800 Subject: [openstack-dev] [cyborg] New time for Cyborg weekly IRC meetings Message-ID: <80cd0921-8472-d4b7-252c-9cdc85a703ae@intel.com> Hi,      The current time for the weekly Cyborg IRC meeting is 1400 UTC, which is 6 am Pacific and 10pm China time. That is a bad time for most people in the call. Please vote in this doodle for what time you prefer. If you need more options, please respond in this thread. [1] https://doodle.com/poll/eqy3hp8hfqtf2qyn Thanks & Regards, Sundar __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From joseph.davis at suse.com Tue Nov 27 00:11:21 2018 From: joseph.davis at suse.com (Joseph Davis) Date: Mon, 26 Nov 2018 16:11:21 -0800 Subject: [OCTAVIA] How to monitor amphora Message-ID: Hello Sa Pham and others, Just to throw another option in to your discussion, the monasca-agent would also be able to monitor the cpu, memory, etc. on an amphora. Similar to how the Ceilometer agent -> Gnocchi publishing would work, you could then use Monasca services to track usage and set alarms. And Monasca handles storage in a time series database (Cassandra or InfluxDB). https://github.com/openstack/monasca-agent/blob/master/docs/Agent.md has some details, an you can always ask questions in #openstack-monasca. joseph Adam Harwell wrote: I would also note (though I'm guessing you've heard this from Michael already) that logging and metrics for internal amphora data (like Haproxy logs, agent logs, etc) is on our roadmap to officially expose via some mechanism. We discussed possible ways to do this at the last PTG, but we were just waiting on someone to have time to do a blueprint for review. If you'd like to help get support for this upstream, you're welcome (actually, highly encouraged!) to hop into our IRC channel #openstack-lbaas and we can even help you get started. Hope to see you there! --Adam Harwell (rm_work) On Mon, Nov 26, 2018, 10:19 Michael Johnson wrote: > This is an area we have been talking about recently at the PTGs. > > Adding connection log offloading is on our short term road map. > Someone had signed up for that, but has pivoted to work on other > items. > Due to that I can't say if it will make it for Stein or not. If > someone is interested in picking this up, I can help point you to the > documentation of our discussions at the PTGs. If not, I would expect > it to land late in Stein or early in Train. > > As for other monitoring, CPU, etc. this is area we currently leave to > the operator, but would like to do some work on. As mentioned above > gnocchi appears to be a nice time-series database for metrics > collection. We would need to have some design discussions on what and > how to collect the data. As you mentioned, monitoring agents can be > added to the amphora image at build time if the operator would like to > add a local tool set. > > As with most parts of Octavia, we try to make things "plug-able" so > that operators have a choice of tools. Both the log offloading and > metrics should follow that design principle. > > Michael > > On Sun, Nov 25, 2018 at 10:49 PM Gaël THEROND > wrote: >> Hi! >> >> I’ve taken some time to read your presentation and I have to say thank > you for your wonderful work ! It’s pretty much complete and with code > example which is really cool. >> It’s exactly what I was looking for. >> If I could just suggest one thing, it would be to give operators freedom > to choose which logging and which metrics clients they want to use. >> Doing so would avoid having to rely on gnocchi as you would be able to > choose the clients type at amphora build time and specify clients target at > runtime using the amphora-agent. >> On another hand, it might we’ll be tricky to do so as everything is > namespaced into the amphora instance. >> As suggested using gnocchi to store HAProxy logs may well be the easiest > short path actually, I’m wondering if it would be possible for searchlight > to use that logs at some point. >> Anyway, thanks for the awesome job. >> For now I’ll keep it simple and just use the API for basic status. >> >> Kind regards, >> G. >> >> Le lun. 26 nov. 2018 à 04:23, Sa Pham a écrit : >>> yes. I have discussed with the Octavia team. PTL Johnson has suggested > me to use gnocchi to store octavia amphora metric. >>> >>> On Wed, Nov 21, 2018 at 3:16 PM Gaël THEROND > wrote: >>>> Hi! Thanks for this material, I’ll have a look at it. >>>> >>>> As our philosophy at work is to always push upstream all our > patchs/features or bug fixes, I won’t modify and keep the source code on > our own and if we need further features like that I think we will rather > push for a Blueprint with all required commits. >>>> Did you already discussed that topic with the Octavia team? >>>> >>>> Thanks a lot. >>>> >>>> Le mer. 21 nov. 2018 à 09:12, Sa Pham a écrit : >>>>> Hi, >>>>> >>>>> In Vietnam Openinfra Days 2018, I have a presentation about > monitoring and logging for Octavia Amphora. We have to customize octavia > source code to do this. I send you my presentation slide: > https://drive.google.com/file/d/1dHXExEKrHDg4Cf3D1fBeulLDW_G-txLr/view?usp=sharing >>>>> Best, >>>>> >>>>> On Wed, Nov 21, 2018 at 3:05 PM Gaël THEROND > wrote: >>>>>> Hi guys, >>>>>> >>>>>> As already discussed I had to test Octavia as our corporate > LoadBalancer solution and it was a success. >>>>>> Thank to everyone on this list that assisted me and especially > Michael Octavia is fully working and without weird nightmare glitches. >>>>>> Now that I validated the technical part of my project, I need to > enter more operationals questions such as what’s the best way to monitor > and log amphora? >>>>>> I would like to be able to get a monitoring and logging agent > installed on the amphora in order to get proper metrics about what’s going > on with the LoadBalancer, is it fully cpu loaded? Is it using all network > resources available, are the file descriptors near the initial limits? How > much xxx HTTP return code the loadBalancer is facing and send those logs to > an ELK or something similar. >>>>>> Do you know if that something that I could achieve by adding more > elements to the image at DIB time or are there any other better > best-practices that I should be aware of ? >>>>>> As Octavia is creating a namespace for each HAProxy process, I am > wandering if it’s even possible. >>>>>> Thanks a lot for your hard work guys. >>>>>> >>>>>> Kind regards, >>>>>> >>>>> -- >>>>> Sa Pham Dang >>>>> Cloud RnD Team - VCCloud >>>>> Phone/Telegram: 0986.849.582 >>>>> Skype: great_bn >>>>> >>>>> >>> -- >>> Sa Pham Dang >>> Cloud RnD Team - VCCloud >>> Phone/Telegram: 0986.849.582 >>> Skype: great_bn >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangtrinhnt at gmail.com Tue Nov 27 00:44:30 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Tue, 27 Nov 2018 09:44:30 +0900 Subject: [OCTAVIA] How to monitor amphora In-Reply-To: References: Message-ID: Hi Gaël, The Searchlight team has submitted a blueprint to add support for Octavia [1]. If it's something you're interested in, please let me know so I can ping you for comments? [1] https://storyboard.openstack.org/#!/story/2004383 Bests, On Mon, Nov 26, 2018 at 3:46 PM Gaël THEROND wrote: > Hi! > > I’ve taken some time to read your presentation and I have to say thank you > for your wonderful work ! It’s pretty much complete and with code example > which is really cool. > > It’s exactly what I was looking for. > If I could just suggest one thing, it would be to give operators freedom > to choose which logging and which metrics clients they want to use. > > Doing so would avoid having to rely on gnocchi as you would be able to > choose the clients type at amphora build time and specify clients target at > runtime using the amphora-agent. > > On another hand, it might we’ll be tricky to do so as everything is > namespaced into the amphora instance. > > As suggested using gnocchi to store HAProxy logs may well be the easiest > short path actually, I’m wondering if it would be possible for searchlight > to use that logs at some point. > > Anyway, thanks for the awesome job. > For now I’ll keep it simple and just use the API for basic status. > > Kind regards, > G. > > Le lun. 26 nov. 2018 à 04:23, Sa Pham a écrit : > >> yes. I have discussed with the Octavia team. PTL Johnson has suggested me >> to use gnocchi to store octavia amphora metric. >> >> >> >> On Wed, Nov 21, 2018 at 3:16 PM Gaël THEROND >> wrote: >> >>> Hi! Thanks for this material, I’ll have a look at it. >>> >>> As our philosophy at work is to always push upstream all our >>> patchs/features or bug fixes, I won’t modify and keep the source code on >>> our own and if we need further features like that I think we will rather >>> push for a Blueprint with all required commits. >>> >>> Did you already discussed that topic with the Octavia team? >>> >>> Thanks a lot. >>> >>> Le mer. 21 nov. 2018 à 09:12, Sa Pham a écrit : >>> >>>> Hi, >>>> >>>> In Vietnam Openinfra Days 2018, I have a presentation about monitoring >>>> and logging for Octavia Amphora. We have to customize octavia source code >>>> to do this. I send you my presentation slide: >>>> >>>> https://drive.google.com/file/d/1dHXExEKrHDg4Cf3D1fBeulLDW_G-txLr/view?usp=sharing >>>> >>>> Best, >>>> >>>> On Wed, Nov 21, 2018 at 3:05 PM Gaël THEROND >>>> wrote: >>>> >>>>> Hi guys, >>>>> >>>>> As already discussed I had to test Octavia as our corporate >>>>> LoadBalancer solution and it was a success. >>>>> >>>>> Thank to everyone on this list that assisted me and especially Michael >>>>> Octavia is fully working and without weird nightmare glitches. >>>>> >>>>> Now that I validated the technical part of my project, I need to enter >>>>> more operationals questions such as what’s the best way to monitor and log >>>>> amphora? >>>>> >>>>> I would like to be able to get a monitoring and logging agent >>>>> installed on the amphora in order to get proper metrics about what’s going >>>>> on with the LoadBalancer, is it fully cpu loaded? Is it using all network >>>>> resources available, are the file descriptors near the initial limits? How >>>>> much xxx HTTP return code the loadBalancer is facing and send those logs to >>>>> an ELK or something similar. >>>>> >>>>> Do you know if that something that I could achieve by adding more >>>>> elements to the image at DIB time or are there any other better >>>>> best-practices that I should be aware of ? >>>>> >>>>> As Octavia is creating a namespace for each HAProxy process, I am >>>>> wandering if it’s even possible. >>>>> >>>>> Thanks a lot for your hard work guys. >>>>> >>>>> Kind regards, >>>>> >>>>> >>>> >>>> -- >>>> Sa Pham Dang >>>> Cloud RnD Team - VCCloud >>>> Phone/Telegram: 0986.849.582 >>>> Skype: great_bn >>>> >>>> >>>> >> >> -- >> Sa Pham Dang >> Cloud RnD Team - VCCloud >> Phone/Telegram: 0986.849.582 >> Skype: great_bn >> >> >> -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Tue Nov 27 09:00:08 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 27 Nov 2018 18:00:08 +0900 Subject: [dev] [tc][all] TC office hours is started now on #openstack-tc Message-ID: <1675465a9fa.d04212cc126659.1559859901304710721@ghanshyammann.com> Hi All, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - TC From zufardhiyaulhaq at gmail.com Tue Nov 27 09:55:08 2018 From: zufardhiyaulhaq at gmail.com (Zufar Dhiyaulhaq) Date: Tue, 27 Nov 2018 16:55:08 +0700 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: Message-ID: Hi Smooney, thank you for your help. I am trying to enable randomization but not working. The instance I have created is still in the same node. Below is my nova configuration (added randomization from your suggestion) from the master node (Template jinja2 based). [DEFAULT] enabled_apis = osapi_compute,metadata transport_url = rabbit://openstack:{{ rabbitmq_pw }}@{{ controller1_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ controller2_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ controller3_ip_man }}:5672 my_ip = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} use_neutron = True firewall_driver = nova.virt.firewall.NoopFirewallDriver [api] auth_strategy = keystone [api_database] [barbican] [cache] backend=oslo_cache.memcache_pool enabled=true memcache_servers={{ controller1_ip_man }}:11211,{{ controller2_ip_man }}:11211,{{ controller3_ip_man }}:11211 [cells] [cinder] [compute] [conductor] [console] [consoleauth] [cors] [crypto] [database] [devices] [ephemeral_storage_encryption] [filter_scheduler] [glance] api_servers = http://{{ vip }}:9292 [guestfs] [healthcheck] [hyperv] [ironic] [key_manager] [keystone] [keystone_authtoken] auth_url = http://{{ vip }}:5000/v3 memcached_servers = {{ controller1_ip_man }}:11211,{{ controller2_ip_man }}:11211,{{ controller3_ip_man }}:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = nova password = {{ nova_pw }} [libvirt] virt_type = kvm [matchmaker_redis] [metrics] [mks] [neutron] url = http://{{ vip }}:9696 auth_url = http://{{ vip }}:35357 auth_type = password project_domain_name = default user_domain_name = default region_name = RegionOne project_name = service username = neutron password = {{ neutron_pw }} [notifications] [osapi_v21] [oslo_concurrency] lock_path = /var/lib/nova/tmp [oslo_messaging_amqp] [oslo_messaging_kafka] [oslo_messaging_notifications] [oslo_messaging_rabbit] [oslo_messaging_zmq] [oslo_middleware] [oslo_policy] [pci] [placement] os_region_name = RegionOne project_domain_name = Default project_name = service auth_type = password user_domain_name = Default auth_url = http://{{ vip }}:5000/v3 username = placement password = {{ placement_pw }} [quota] [rdp] [remote_debug] [scheduler] [serial_console] [service_user] [spice] [upgrade_levels] [vault] [vendordata_dynamic_auth] [vmware] [vnc] enabled = True keymap=en-us server_listen = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4'][ 'address'] }} server_proxyclient_address = {{ hostvars[inventory_hostname][ 'ansible_ens3f1']['ipv4']['address'] }} novncproxy_base_url = https://{{ vip }}:6080/vnc_auto.html [workarounds] [wsgi] [xenserver] [xvp] Thank you, Best Regards, Zufar Dhiyaulhaq On Mon, Nov 26, 2018 at 11:13 PM Sean Mooney wrote: > On Mon, 2018-11-26 at 17:45 +0700, Zufar Dhiyaulhaq wrote: > > Hi, > > > > I am deploying OpenStack with 3 compute node, but I am seeing an > abnormal distribution of instance, the instance is > > only deployed in a specific compute node, and not distribute among other > compute node. > > > > this is my nova.conf from the compute node. (template jinja2 based) > > hi, the default behavior of nova used to be spread not pack and i belive > it still is. > the default behavior with placement however is closer to a packing > behavior as > allcoation candiates are retrunidn in an undefined but deterministic order. > > on a busy cloud this does not strictly pack instaces but on a quite cloud > it effectivly does > > you can try and enable randomisation of the allocation candiates by > setting this config option in > the nova.conf of the shcduler to true. > > https://docs.openstack.org/nova/latest/configuration/config.html#placement.randomize_allocation_candidates > > on that note can you provide the nova.conf for the schduelr is used > instead of the compute node nova.conf. > if you have not overriden any of the nova defaults the ram and cpu weigher > should spread instances withing > the allocation candiates returned by placement. > > > > > [DEFAULT] > > osapi_compute_listen = {{ > hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} > > metadata_listen = {{ > hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} > > enabled_apis = osapi_compute,metadata > > transport_url = rabbit://openstack:{{ rabbitmq_pw }}@{{ > controller1_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ > > controller2_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ > controller3_ip_man }}:5672 > > my_ip = {{ > hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} > > use_neutron = True > > firewall_driver = nova.virt.firewall.NoopFirewallDriver > > [api] > > auth_strategy = keystone > > [api_database] > > connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_api > > [barbican] > > [cache] > > backend=oslo_cache.memcache_pool > > enabled=true > > memcache_servers={{ controller1_ip_man }}:11211,{{ controller2_ip_man > }}:11211,{{ controller3_ip_man }}:11211 > > [cells] > > [cinder] > > os_region_name = RegionOne > > [compute] > > [conductor] > > [console] > > [consoleauth] > > [cors] > > [crypto] > > [database] > > connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova > > [devices] > > [ephemeral_storage_encryption] > > [filter_scheduler] > > [glance] > > api_servers = http://{{ vip }}:9292 > > [guestfs] > > [healthcheck] > > [hyperv] > > [ironic] > > [key_manager] > > [keystone] > > [keystone_authtoken] > > auth_url = http://{{ vip }}:5000/v3 > > memcached_servers = {{ controller1_ip_man }}:11211,{{ controller2_ip_man > }}:11211,{{ controller3_ip_man }}:11211 > > auth_type = password > > project_domain_name = default > > user_domain_name = default > > project_name = service > > username = nova > > password = {{ nova_pw }} > > [libvirt] > > [matchmaker_redis] > > [metrics] > > [mks] > > [neutron] > > url = http://{{ vip }}:9696 > > auth_url = http://{{ vip }}:35357 > > auth_type = password > > project_domain_name = default > > user_domain_name = default > > region_name = RegionOne > > project_name = service > > username = neutron > > password = {{ neutron_pw }} > > service_metadata_proxy = true > > metadata_proxy_shared_secret = {{ metadata_secret }} > > [notifications] > > [osapi_v21] > > [oslo_concurrency] > > lock_path = /var/lib/nova/tmp > > [oslo_messaging_amqp] > > [oslo_messaging_kafka] > > [oslo_messaging_notifications] > > [oslo_messaging_rabbit] > > [oslo_messaging_zmq] > > [oslo_middleware] > > [oslo_policy] > > [pci] > > [placement] > > os_region_name = RegionOne > > project_domain_name = Default > > project_name = service > > auth_type = password > > user_domain_name = Default > > auth_url = http://{{ vip }}:5000/v3 > > username = placement > > password = {{ placement_pw }} > > [quota] > > [rdp] > > [remote_debug] > > [scheduler] > > discover_hosts_in_cells_interval = 300 > > [serial_console] > > [service_user] > > [spice] > > [upgrade_levels] > > [vault] > > [vendordata_dynamic_auth] > > [vmware] > > [vnc] > > enabled = true > > keymap=en-us > > novncproxy_base_url = https://{{ vip }}:6080/vnc_auto.html > > novncproxy_host = {{ > hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} > > [workarounds] > > [wsgi] > > [xenserver] > > [xvp] > > [placement_database] > > connection=mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_placement > > > > what is the problem? I have lookup the openstack-nova-scheduler in the > controller node but it's running well with only > > warning > > > > nova-scheduler[19255]: > /usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py:332: > NotSupportedWarning: > > Configuration option(s) ['use_tpool'] not supported > > > > the result I want is the instance is distributed in all compute node. > > Thank you. > > > > _______________________________________________ > > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > Post to : openstack at lists.openstack.org > > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From zufardhiyaulhaq at gmail.com Tue Nov 27 10:01:19 2018 From: zufardhiyaulhaq at gmail.com (Zufar Dhiyaulhaq) Date: Tue, 27 Nov 2018 17:01:19 +0700 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: Message-ID: Hi Smooney, sorry for the last reply. I am attaching wrong configuration files. This is my nova configuration (added randomization from your suggestion) from the master node (Template jinja2 based). [DEFAULT] osapi_compute_listen = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} metadata_listen = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} enabled_apis = osapi_compute,metadata transport_url = rabbit://openstack:{{ rabbitmq_pw }}@{{ controller1_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ controller2_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ controller3_ip_man }}:5672 my_ip = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} use_neutron = True firewall_driver = nova.virt.firewall.NoopFirewallDriver [api] auth_strategy = keystone [api_database] connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_api [barbican] [cache] backend=oslo_cache.memcache_pool enabled=true memcache_servers={{ controller1_ip_man }}:11211,{{ controller2_ip_man }}:11211,{{ controller3_ip_man }}:11211 [cells] [cinder] os_region_name = RegionOne [compute] [conductor] [console] [consoleauth] [cors] [crypto] [database] connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova [devices] [ephemeral_storage_encryption] [filter_scheduler] [glance] api_servers = http://{{ vip }}:9292 [guestfs] [healthcheck] [hyperv] [ironic] [key_manager] [keystone] [keystone_authtoken] auth_url = http://{{ vip }}:5000/v3 memcached_servers = {{ controller1_ip_man }}:11211,{{ controller2_ip_man }}:11211,{{ controller3_ip_man }}:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = nova password = {{ nova_pw }} [libvirt] [matchmaker_redis] [metrics] [mks] [neutron] url = http://{{ vip }}:9696 auth_url = http://{{ vip }}:35357 auth_type = password project_domain_name = default user_domain_name = default region_name = RegionOne project_name = service username = neutron password = {{ neutron_pw }} service_metadata_proxy = true metadata_proxy_shared_secret = {{ metadata_secret }} [notifications] [osapi_v21] [oslo_concurrency] lock_path = /var/lib/nova/tmp [oslo_messaging_amqp] [oslo_messaging_kafka] [oslo_messaging_notifications] [oslo_messaging_rabbit] [oslo_messaging_zmq] [oslo_middleware] [oslo_policy] [pci] [placement] os_region_name = RegionOne project_domain_name = Default project_name = service auth_type = password user_domain_name = Default auth_url = http://{{ vip }}:5000/v3 username = placement password = {{ placement_pw }} randomize_allocation_candidates = true [quota] [rdp] [remote_debug] [scheduler] discover_hosts_in_cells_interval = 300 [serial_console] [service_user] [spice] [upgrade_levels] [vault] [vendordata_dynamic_auth] [vmware] [vnc] enabled = true keymap=en-us novncproxy_base_url = https://{{ vip }}:6080/vnc_auto.html novncproxy_host = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} [workarounds] [wsgi] [xenserver] [xvp] [placement_database] connection=mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_placement Thank you Best Regards, Zufar Dhiyaulhaq On Tue, Nov 27, 2018 at 4:55 PM Zufar Dhiyaulhaq wrote: > Hi Smooney, > > thank you for your help. I am trying to enable randomization but not > working. The instance I have created is still in the same node. Below is my > nova configuration (added randomization from your suggestion) from the > master node (Template jinja2 based). > > [DEFAULT] > enabled_apis = osapi_compute,metadata > transport_url = rabbit://openstack:{{ rabbitmq_pw }}@{{ controller1_ip_man > }}:5672,openstack:{{ rabbitmq_pw }}@{{ controller2_ip_man > }}:5672,openstack:{{ rabbitmq_pw }}@{{ controller3_ip_man }}:5672 > my_ip = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4'][ > 'address'] }} > use_neutron = True > firewall_driver = nova.virt.firewall.NoopFirewallDriver > [api] > auth_strategy = keystone > [api_database] > [barbican] > [cache] > backend=oslo_cache.memcache_pool > enabled=true > memcache_servers={{ controller1_ip_man }}:11211,{{ controller2_ip_man > }}:11211,{{ controller3_ip_man }}:11211 > [cells] > [cinder] > [compute] > [conductor] > [console] > [consoleauth] > [cors] > [crypto] > [database] > [devices] > [ephemeral_storage_encryption] > [filter_scheduler] > [glance] > api_servers = http://{{ vip }}:9292 > [guestfs] > [healthcheck] > [hyperv] > [ironic] > [key_manager] > [keystone] > [keystone_authtoken] > auth_url = http://{{ vip }}:5000/v3 > memcached_servers = {{ controller1_ip_man }}:11211,{{ controller2_ip_man > }}:11211,{{ controller3_ip_man }}:11211 > auth_type = password > project_domain_name = default > user_domain_name = default > project_name = service > username = nova > password = {{ nova_pw }} > [libvirt] > virt_type = kvm > [matchmaker_redis] > [metrics] > [mks] > [neutron] > url = http://{{ vip }}:9696 > auth_url = http://{{ vip }}:35357 > auth_type = password > project_domain_name = default > user_domain_name = default > region_name = RegionOne > project_name = service > username = neutron > password = {{ neutron_pw }} > [notifications] > [osapi_v21] > [oslo_concurrency] > lock_path = /var/lib/nova/tmp > [oslo_messaging_amqp] > [oslo_messaging_kafka] > [oslo_messaging_notifications] > [oslo_messaging_rabbit] > [oslo_messaging_zmq] > [oslo_middleware] > [oslo_policy] > [pci] > [placement] > os_region_name = RegionOne > project_domain_name = Default > project_name = service > auth_type = password > user_domain_name = Default > auth_url = http://{{ vip }}:5000/v3 > username = placement > password = {{ placement_pw }} > [quota] > [rdp] > [remote_debug] > [scheduler] > [serial_console] > [service_user] > [spice] > [upgrade_levels] > [vault] > [vendordata_dynamic_auth] > [vmware] > [vnc] > enabled = True > keymap=en-us > server_listen = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4'][ > 'address'] }} > server_proxyclient_address = {{ hostvars[inventory_hostname][ > 'ansible_ens3f1']['ipv4']['address'] }} > novncproxy_base_url = https://{{ vip }}:6080/vnc_auto.html > [workarounds] > [wsgi] > [xenserver] > [xvp] > > Thank you, > > Best Regards, > Zufar Dhiyaulhaq > > On Mon, Nov 26, 2018 at 11:13 PM Sean Mooney wrote: > >> On Mon, 2018-11-26 at 17:45 +0700, Zufar Dhiyaulhaq wrote: >> > Hi, >> > >> > I am deploying OpenStack with 3 compute node, but I am seeing an >> abnormal distribution of instance, the instance is >> > only deployed in a specific compute node, and not distribute among >> other compute node. >> > >> > this is my nova.conf from the compute node. (template jinja2 based) >> >> hi, the default behavior of nova used to be spread not pack and i belive >> it still is. >> the default behavior with placement however is closer to a packing >> behavior as >> allcoation candiates are retrunidn in an undefined but deterministic >> order. >> >> on a busy cloud this does not strictly pack instaces but on a quite cloud >> it effectivly does >> >> you can try and enable randomisation of the allocation candiates by >> setting this config option in >> the nova.conf of the shcduler to true. >> >> https://docs.openstack.org/nova/latest/configuration/config.html#placement.randomize_allocation_candidates >> >> on that note can you provide the nova.conf for the schduelr is used >> instead of the compute node nova.conf. >> if you have not overriden any of the nova defaults the ram and cpu >> weigher should spread instances withing >> the allocation candiates returned by placement. >> >> > >> > [DEFAULT] >> > osapi_compute_listen = {{ >> hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} >> > metadata_listen = {{ >> hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} >> > enabled_apis = osapi_compute,metadata >> > transport_url = rabbit://openstack:{{ rabbitmq_pw }}@{{ >> controller1_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ >> > controller2_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ >> controller3_ip_man }}:5672 >> > my_ip = {{ >> hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} >> > use_neutron = True >> > firewall_driver = nova.virt.firewall.NoopFirewallDriver >> > [api] >> > auth_strategy = keystone >> > [api_database] >> > connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_api >> > [barbican] >> > [cache] >> > backend=oslo_cache.memcache_pool >> > enabled=true >> > memcache_servers={{ controller1_ip_man }}:11211,{{ controller2_ip_man >> }}:11211,{{ controller3_ip_man }}:11211 >> > [cells] >> > [cinder] >> > os_region_name = RegionOne >> > [compute] >> > [conductor] >> > [console] >> > [consoleauth] >> > [cors] >> > [crypto] >> > [database] >> > connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova >> > [devices] >> > [ephemeral_storage_encryption] >> > [filter_scheduler] >> > [glance] >> > api_servers = http://{{ vip }}:9292 >> > [guestfs] >> > [healthcheck] >> > [hyperv] >> > [ironic] >> > [key_manager] >> > [keystone] >> > [keystone_authtoken] >> > auth_url = http://{{ vip }}:5000/v3 >> > memcached_servers = {{ controller1_ip_man }}:11211,{{ >> controller2_ip_man }}:11211,{{ controller3_ip_man }}:11211 >> > auth_type = password >> > project_domain_name = default >> > user_domain_name = default >> > project_name = service >> > username = nova >> > password = {{ nova_pw }} >> > [libvirt] >> > [matchmaker_redis] >> > [metrics] >> > [mks] >> > [neutron] >> > url = http://{{ vip }}:9696 >> > auth_url = http://{{ vip }}:35357 >> > auth_type = password >> > project_domain_name = default >> > user_domain_name = default >> > region_name = RegionOne >> > project_name = service >> > username = neutron >> > password = {{ neutron_pw }} >> > service_metadata_proxy = true >> > metadata_proxy_shared_secret = {{ metadata_secret }} >> > [notifications] >> > [osapi_v21] >> > [oslo_concurrency] >> > lock_path = /var/lib/nova/tmp >> > [oslo_messaging_amqp] >> > [oslo_messaging_kafka] >> > [oslo_messaging_notifications] >> > [oslo_messaging_rabbit] >> > [oslo_messaging_zmq] >> > [oslo_middleware] >> > [oslo_policy] >> > [pci] >> > [placement] >> > os_region_name = RegionOne >> > project_domain_name = Default >> > project_name = service >> > auth_type = password >> > user_domain_name = Default >> > auth_url = http://{{ vip }}:5000/v3 >> > username = placement >> > password = {{ placement_pw }} >> > [quota] >> > [rdp] >> > [remote_debug] >> > [scheduler] >> > discover_hosts_in_cells_interval = 300 >> > [serial_console] >> > [service_user] >> > [spice] >> > [upgrade_levels] >> > [vault] >> > [vendordata_dynamic_auth] >> > [vmware] >> > [vnc] >> > enabled = true >> > keymap=en-us >> > novncproxy_base_url = https://{{ vip }}:6080/vnc_auto.html >> > novncproxy_host = {{ >> hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} >> > [workarounds] >> > [wsgi] >> > [xenserver] >> > [xvp] >> > [placement_database] >> > connection=mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_placement >> > >> > what is the problem? I have lookup the openstack-nova-scheduler in the >> controller node but it's running well with only >> > warning >> > >> > nova-scheduler[19255]: >> /usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py:332: >> NotSupportedWarning: >> > Configuration option(s) ['use_tpool'] not supported >> > >> > the result I want is the instance is distributed in all compute node. >> > Thank you. >> > >> > _______________________________________________ >> > Mailing list: >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> > Post to : openstack at lists.openstack.org >> > Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From chhagarw at in.ibm.com Tue Nov 27 12:52:10 2018 From: chhagarw at in.ibm.com (Chhavi Agarwal) Date: Tue, 27 Nov 2018 18:22:10 +0530 Subject: [Openstack] [Cinder] Cinder New Tag Release In-Reply-To: <1926809770.53738230.1543224969471.JavaMail.zimbra@redhat.com> References: <90950AF3-ED04-4015-BE09-E4235F0DFAC9@gmail.com> <1926809770.53738230.1543224969471.JavaMail.zimbra@redhat.com> Message-ID: Hi All, With the current tagged release of Openstack Cinder ( 13.0.1 ) https://github.com/openstack/cinder/releases/tag/13.0.1 we are hitting the below issue https://bugs.launchpad.net/cinder/+bug/1796759 This got fixed with change set https://review.openstack.org/#/c/608768/ which is not a part of the tagged release. Want to know if we can have a new Cinder tag release to incorporate the new fixes. Thanks & Regards, Chhavi Agarwal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From bdobreli at redhat.com Tue Nov 27 15:24:44 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Tue, 27 Nov 2018 16:24:44 +0100 Subject: [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes Message-ID: <9dee4044-2744-3ab6-3a15-bd79702ff35a@redhat.com> Changing the topic to follow the subject. [tl;dr] it's time to rearchitect container images to stop incluiding config-time only (puppet et al) bits, which are not needed runtime and pose security issues, like CVEs, to maintain daily. Background: 1) For the Distributed Compute Node edge case, there is potentially tens of thousands of a single-compute-node remote edge sites connected over WAN to a single control plane, which is having high latency, like a 100ms or so, and limited bandwith. Reducing the base layer size becomes a decent goal there. See the security background below. 2) For a generic security (Day 2, maintenance) case, when puppet/ruby/systemd/name-it gets a CVE fixed, the base layer has to be updated and all layers on top - to be rebuild, and all of those layers, to be re-fetched for cloud hosts and all containers to be restarted... And all of that because of some fixes that have nothing to OpenStack. By the remote edge sites as well, remember of "tens of thousands", high latency and limited bandwith?.. 3) TripleO CI updates (including puppet*) packages in containers, not in a common base layer of those. So each a CI job has to update puppet* and its dependencies - ruby/systemd as well. Reducing numbers of packages to update for each container makes sense for CI as well. Implementation related: WIP patches [0],[1] for early review, uses a config "pod" approach, does not require to maintain a two sets of config vs runtime images. Future work: a) cronie requires systemd, we'd want to fix that also off the base layer. b) rework to podman pods for docker-puppet.py instead of --volumes-from a side car container (can't be backported for Queens then, which is still nice to have a support for the Edge DCN case, at least downstream only perhaps). Some questions raised on IRC: Q: is having a service be able to configure itself really need to involve a separate pod? A: Highly likely yes, removing not-runtime things is a good idea and pods is an established PaaS paradigm already. That will require some changes in the architecture though (see the topic with WIP patches). Q: that's (fetching a config container) actually more data that about to download otherwise A: It's not, if thinking of Day 2, when have to re-fetch the base layer and top layers, when some unrelated to openstack CVEs got fixed there for ruby/puppet/systemd. Avoid the need to restart service containers because of those minor updates puched is also a nice thing. Q: the best solution here would be using packages on the host, generating the config files on the host. And then having an all-in-one container for all the services which lets them run in an isolated mannner. A: I think for Edge cases, that's a no go as we might want to consider tiny low footprint OS distros like former known Container Linux or Atomic. Also, an all-in-one container looks like an anti-pattern from the world of VMs. [0] https://review.openstack.org/#/q/topic:base-container-reduction [1] https://review.rdoproject.org/r/#/q/topic:base-container-reduction > Here is a related bug [1] and implementation [1] for that. PTAL folks! > > [0] https://bugs.launchpad.net/tripleo/+bug/1804822 > [1] https://review.openstack.org/#/q/topic:base-container-reduction > >> Let's also think of removing puppet-tripleo from the base container. >> It really brings the world-in (and yum updates in CI!) each job and each >> container! >> So if we did so, we should then either install puppet-tripleo and co on >> the host and bind-mount it for the docker-puppet deployment task steps >> (bad idea IMO), OR use the magical --volumes-from >> option to mount volumes from some "puppet-config" sidecar container >> inside each of the containers being launched by docker-puppet tooling. > > On Wed, Oct 31, 2018 at 11:16 AM Harald Jensås > wrote: >> We add this to all images: >> >> https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646e535cf972c98ef/container-images/tripleo_kolla_template_overrides.j2#L35 >> >> /bin/sh -c yum -y install iproute iscsi-initiator-utils lvm2 python >> socat sudo which openstack-tripleo-common-container-base rsync cronie >> crudini openstack-selinux ansible python-shade puppet-tripleo python2- >> kubernetes && yum clean all && rm -rf /var/cache/yum 276 MB >> >> Is the additional 276 MB reasonable here? >> openstack-selinux <- This package run relabling, does that kind of >> touching the filesystem impact the size due to docker layers? >> >> Also: python2-kubernetes is a fairly large package (18007990) do we use >> that in every image? I don't see any tripleo related repos importing >> from that when searching on Hound? The original commit message[1] >> adding it states it is for future convenience. >> >> On my undercloud we have 101 images, if we are downloading every 18 MB >> per image thats almost 1.8 GB for a package we don't use? (I hope it's >> not like this? With docker layers, we only download that 276 MB >> transaction once? Or?) >> >> >> [1] https://review.openstack.org/527927 > > > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando -- Best regards, Bogdan Dobrelya, Irc #bogdando From marios at redhat.com Tue Nov 27 15:44:57 2018 From: marios at redhat.com (Marios Andreou) Date: Tue, 27 Nov 2018 17:44:57 +0200 Subject: [tripleo] Let's improve upstream docs Message-ID: Hi folks, as just mentioned in the tripleo weekly irc meeting [1] some of us are trying to make small weekly improvements to the tripleo docs [2]. We are using this bug [3] for tracking and this effort is a result of some feedback during the recent Berlin summit. The general idea is 1 per week (or more if you can and want) - improvement/removal of stale content/identifying missing sections, or anything else you might care to propose. Please join us if you can, just add "Related-Bug: #1804642" to your commit message thanks [1] https://wiki.openstack.org/wiki/Meetings/TripleO [2] https://docs.openstack.org/tripleo-docs/latest/ [3] https://bugs.launchpad.net/tripleo/+bug/1804642 -------------- next part -------------- An HTML attachment was scrubbed... URL: From witold.bedyk at est.fujitsu.com Tue Nov 27 16:20:39 2018 From: witold.bedyk at est.fujitsu.com (Bedyk, Witold) Date: Tue, 27 Nov 2018 16:20:39 +0000 Subject: [OCTAVIA] How to monitor amphora Message-ID: <3c954b49a0eb4d7e9c682210d5852a2e@R01UKEXCASM126.r01.fujitsu.local> Hi everyone, Monasca is the service which offers centralized monitoring and logging. As Joseph has written, you can probably use the monasca-agent and configure the existing system[1] and process[2] checks. If you need Octavia specific metrics, you can instrument your code using monasca-statsd library [3]. Best greetings Witek [1] https://github.com/openstack/monasca-agent/blob/master/docs/Plugins.md#system-metrics [2] https://github.com/openstack/monasca-agent/blob/master/docs/Plugins.md#process-checks [3] https://github.com/openstack/monasca-statsd From dms at danplanet.com Tue Nov 27 16:32:40 2018 From: dms at danplanet.com (Dan Smith) Date: Tue, 27 Nov 2018 08:32:40 -0800 Subject: [openstack-dev] [nova] Stein forum session notes References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> Message-ID: >>> Change of ownership of resources >>> ================================ >>> - Ignore the network piece for now, it's the most complicated. Being >>> able to transfer everything else would solve 90% of City Network's use >>> cases >>> - Some ideas around having this be a keystone auth-based access granting >>> instead of an update of project/user, but if keystone could hand user A >>> a token for user B, that token would apply to all resources of user B's, >>> not just the ones desired for transfer >> >> Whatever happened with the os-chown project Dan started in Denver? >> >> https://github.com/kk7ds/oschown > > What we distilled from the forum session is that at the heart of it, > what is actually wanted is to be able to grant access to a resource > owned by project A to project B, for example. It's not so much about > wanting to literally change project_id/user_id from A to B. So, we > asked the question, "what if project A could grant access to its > resources to project B via keystone?" This could work if it is OK for > project B to gain access to _all_ of project A's resources (since we > currently have no way to scope access to specific resources). For a > use case where it is OK for project A to grant access to all of > project B's resources, the idea of accomplishing this is > keystone-only, could work. Doing it auth-based through keystone-only > would leave project_id/user_id and all dependencies intact, making the > change only at the auth/project level. It is simpler and cleaner. > > However, for a use case where it is not OK for project B to gain > access to all of project A's resources, because we lack the ability to > scope access to specific resources, the os-chown approach is the only > proposal we know of that can address it. > > So, depending on the use cases, we might be able to explore a keystone > approach. From what I gathered in the forum session, it sounded like > City Network might be OK with a project-wide access grant, but Oath > might need a resource-specific scoped access grant. If those are both > the case, we would find use in both a keystone access approach and the > os-chown approach. FWIW, this is not what I gathered from the discussion, and I don't see anything about that on the etherpad: https://etherpad.openstack.org/p/BER-change-ownership-of-resources I know the self-service project-wide grant of access was brought up, but I don't recall any of the operators present saying that would actually solve their use cases (including City Network). I'm not really sure how granting another project access to all resources of another is really anything other than a temporary solution applicable in cases where supreme trust exists. I could be wrong, but I thought they specifically still wanted an API in each project that would forcibly transfer (i.e. actually change userid/project on) resources. Did I miss something in the hallway track afterwards? --Dan From mnaser at vexxhost.com Tue Nov 27 16:50:12 2018 From: mnaser at vexxhost.com (Mohammed Naser) Date: Tue, 27 Nov 2018 11:50:12 -0500 Subject: [openstack-ansible] Evaluating meeting schedule + method Message-ID: Hey everyone: Over the past few weeks, the OpenStack Ansible meetings have had increasingly less attendance. In addition, the engagement seems to be decreased as well. I think IRC meetings are generally awful and it's really hard to come up with a proper engagement, because you get pulled into 60 other things and the meeting gets forgotten. I'd like to suggest a few things: - Look into a voice-based meeting system which is recorded + notes: This will help with engagement and discussion, we'll actually be able to get things done. - Change meeting topics: perhaps people don't care about what we discuss? - Change meetings to once every 2 weeks or month (or even cancel them). I'm sending this to the community to hear what they have to say about this. Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser at vexxhost.com W. http://vexxhost.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at openstack.org Tue Nov 27 16:51:39 2018 From: chris at openstack.org (Chris Hoge) Date: Tue, 27 Nov 2018 08:51:39 -0800 Subject: [loci] Project Technical Leadership Change Message-ID: <4D0C8716-FCBF-4BFD-A3FA-D53BEB7B9A04@openstack.org> After discussion with the current Loci PTL, team members, and the OpenStack TC at the Berlin Summit, I will be stepping in as interim PTL for the Loci project for the remainder of the development cycle. If you have any questions or concerns about this, please feel free to reach out to me directly. As a reminder, Loci has weekly team meetings on Friday at 1500 UTC in the #openstack-loci channel that we will be resuming this week. Thanks, Chris Hoge From ltoscano at redhat.com Tue Nov 27 16:59:51 2018 From: ltoscano at redhat.com (Luigi Toscano) Date: Tue, 27 Nov 2018 17:59:51 +0100 Subject: [openstack-ansible] Evaluating meeting schedule + method In-Reply-To: References: Message-ID: <1913981.aYPTVNe1F8@whitebase.usersys.redhat.com> On Tuesday, 27 November 2018 17:50:12 CET Mohammed Naser wrote: > Hey everyone: > > Over the past few weeks, the OpenStack Ansible meetings have had > increasingly less attendance. In addition, the engagement seems to be > decreased as well. > > I think IRC meetings are generally awful and it's really hard to come up > with a proper engagement, because you get pulled into 60 other things and > the meeting gets forgotten. I'd like to suggest a few things: > > - Look into a voice-based meeting system which is recorded + notes: This > will help with engagement and discussion, we'll actually be able to get > things done. > - Change meeting topics: perhaps people don't care about what we discuss? > - Change meetings to once every 2 weeks or month (or even cancel them). Did you try to check what are the people the attended before and are not attending anymore? In the last weeks there was also the summit and few vacations in the Europe and in the US. Yes, a chat system allows you to multitask and do other things, but, personally speaking, when I hear about a voice-based meeting, I think I would not join at all (while I can quickly skim through the chat logs meeting). -- Luigi From fungi at yuggoth.org Tue Nov 27 17:22:30 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 27 Nov 2018 17:22:30 +0000 Subject: [loci][tc] Project Technical Leadership Change In-Reply-To: <4D0C8716-FCBF-4BFD-A3FA-D53BEB7B9A04@openstack.org> References: <4D0C8716-FCBF-4BFD-A3FA-D53BEB7B9A04@openstack.org> Message-ID: <20181127172227.x2juoz4yxb4u35xs@yuggoth.org> On 2018-11-27 08:51:39 -0800 (-0800), Chris Hoge wrote: > After discussion with the current Loci PTL, team members, and the > OpenStack TC at the Berlin Summit, I will be stepping in as > interim PTL for the Loci project for the remainder of the > development cycle. [...] Thanks for stepping up! Please propose an update to https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml so that the TC can officially confirm this interim change of leadership. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From chris at openstack.org Tue Nov 27 17:31:53 2018 From: chris at openstack.org (Chris Hoge) Date: Tue, 27 Nov 2018 09:31:53 -0800 Subject: [loci][tc] Project Technical Leadership Change In-Reply-To: <20181127172227.x2juoz4yxb4u35xs@yuggoth.org> References: <4D0C8716-FCBF-4BFD-A3FA-D53BEB7B9A04@openstack.org> <20181127172227.x2juoz4yxb4u35xs@yuggoth.org> Message-ID: <836FF68B-F3E1-4123-BFD1-80C54977BEBA@openstack.org> Project update review here: https://review.openstack.org/620370 > On Nov 27, 2018, at 9:22 AM, Jeremy Stanley wrote: > > Thanks for stepping up! Please propose an update to > https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml > so that the TC can officially confirm this interim change of > leadership. > -- > Jeremy Stanley From ignaziocassano at gmail.com Tue Nov 27 17:32:48 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Tue, 27 Nov 2018 18:32:48 +0100 Subject: [Openstack-operators] Nova hypervisor uuid Message-ID: Hi All, Please anyone know where hypervisor uuid is retrived? Sometime updating kmv nodes with yum update it changes and in nova database 2 uuids are assigned to the same node. regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From jungleboyj at gmail.com Tue Nov 27 17:45:46 2018 From: jungleboyj at gmail.com (Jay S Bryant) Date: Tue, 27 Nov 2018 11:45:46 -0600 Subject: [Openstack] [Cinder] Cinder New Tag Release In-Reply-To: References: <90950AF3-ED04-4015-BE09-E4235F0DFAC9@gmail.com> <1926809770.53738230.1543224969471.JavaMail.zimbra@redhat.com> Message-ID: Chhavi, I saw your messages on IRC yesterday and did request a new release.  I now see, however, that the fix you want released hasn't been backported yet.  I will do the backport and re-request the 13.0.2 release. Thanks! Jay On 11/27/2018 6:52 AM, Chhavi Agarwal wrote: > > Hi All, > > With the current tagged release of Openstack Cinder ( 13.0.1 ) > https://github.com/openstack/cinder/releases/tag/13.0.1we are hitting > the below issue > > https://bugs.launchpad.net/cinder/+bug/1796759 > > This got fixed with change set > https://review.openstack.org/#/c/608768/which is not a part of the > tagged release. > > Want to know if we can have a new Cinder tag release to incorporate > the new fixes. > > Thanks & Regards, > Chhavi Agarwal > > > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jungleboyj at gmail.com Tue Nov 27 18:00:20 2018 From: jungleboyj at gmail.com (Jay S Bryant) Date: Tue, 27 Nov 2018 12:00:20 -0600 Subject: [nova][cinder] Why can't nova in stein work with cinder from queens? In-Reply-To: <3a1ed017-f9f0-b444-4f56-673c44c3d35f@gmail.com> References: <3a1ed017-f9f0-b444-4f56-673c44c3d35f@gmail.com> Message-ID: Matt, As far as I know this is news to the Cinder team.  Will bring it up in our weekly meeting to see if anyone was aware of this stance. Thanks, Jay On 11/21/2018 3:11 PM, Matt Riedemann wrote: > A change in nova [1] was approved which makes an assertion that we > (nova? openstack?) do not support running nova from stein with cinder > from queens, and I guess I'd like to know where that support statement > is written down? Granted, I know we don't gate that way but I'm not > aware of anything preventing it from working given we use > microversions and nova, as the client, should be able to work with > cinder from v1, v2 or v3 assuming it's doing version discovery > correctly (which we've been doing in nova since queens when we needed > to start using the cinder v3.44 volume attachments API for multiattach > - but it's not required). > > In fact, nova-api still has compatibility code for older versions of > cinder to determine what it should do about working with volume > attachments [2]. I've been thinking lately about how to drop that code > which would at the very least require a release note saying nova > requires cinder >= queens, but nothing like that was requested in the > change that drops support for cinder v1 from nova and asserts that > nova in stein requires cinder >= queens. > > Maybe I'm just yelling at kids to get off my lawn, but I don't really > want this to be precedent without some discussion because I know at > various times operators have complained about upgrades being hard > because they assume all of the services must be upgraded to the same > release at the same time, and I don't think that is true, or should be > true, because if it is, we're doing a really bad job of defining > versioned interfaces between the services. > > [1] https://review.openstack.org/#/c/617927/ > [2] > https://github.com/openstack/nova/blob/7217e38bafb75e8a613763835b64e48e6b2c8ece/nova/compute/api.py#L4260-L4264 > From mriedemos at gmail.com Tue Nov 27 18:02:25 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Tue, 27 Nov 2018 12:02:25 -0600 Subject: [Openstack-operators] Nova hypervisor uuid In-Reply-To: References: Message-ID: <63283d3b-0661-7620-aaea-8ffbe9e483d8@gmail.com> On 11/27/2018 11:32 AM, Ignazio Cassano wrote: > Hi  All, > Please anyone know where hypervisor uuid is retrived? > Sometime updating kmv nodes with yum update it changes and in nova > database 2 uuids are assigned to the same node. > regards > Ignazio > > > > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > To be clear, do you mean the computes_nodes.uuid column value in the cell database? Which is also used for the GET /os-hypervisors response 'id' value if using microversion >= 2.53. If so, that is generated randomly* when the compute_nodes table record is created: https://github.com/openstack/nova/blob/8545ba2af7476e0884b5e7fb90965bef92d605bc/nova/compute/resource_tracker.py#L588 https://github.com/openstack/nova/blob/8545ba2af7476e0884b5e7fb90965bef92d605bc/nova/objects/compute_node.py#L312 When you hit this problem, are you sure the hostname on the compute host is not changing? Because when nova-compute starts up, it should look for the existing compute node record by host name and node name, which for the libvirt driver should be the same. That lookup code is here: https://github.com/openstack/nova/blob/8545ba2af7476e0884b5e7fb90965bef92d605bc/nova/compute/resource_tracker.py#L815 So the only way nova-compute should create a new compute_nodes table record for the same host is if the host/node name changes during the upgrade. Is the deleted value in the database the same (0) for both of those records? * The exception to this is for the ironic driver which re-uses the ironic node uuid as of this change: https://review.openstack.org/#/c/571535/ -- Thanks, Matt _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From dprince at redhat.com Tue Nov 27 18:10:50 2018 From: dprince at redhat.com (Dan Prince) Date: Tue, 27 Nov 2018 13:10:50 -0500 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <9dee4044-2744-3ab6-3a15-bd79702ff35a@redhat.com> References: <9dee4044-2744-3ab6-3a15-bd79702ff35a@redhat.com> Message-ID: <089336b7a431cab76e1350a959b7bb566175134b.camel@redhat.com> On Tue, 2018-11-27 at 16:24 +0100, Bogdan Dobrelya wrote: > Changing the topic to follow the subject. > > [tl;dr] it's time to rearchitect container images to stop incluiding > config-time only (puppet et al) bits, which are not needed runtime > and > pose security issues, like CVEs, to maintain daily. I think your assertion that we need to rearchitect the config images to container the puppet bits is incorrect here. After reviewing the patches you linked to below it appears that you are proposing we use --volumes-from to bind mount application binaries from one container into another. I don't believe this is a good pattern for containers. On baremetal if we followed the same pattern it would be like using an /nfs share to obtain access to binaries across the network to optimize local storage. Now... some people do this (like maybe high performance computing would launch an MPI job like this) but I don't think we should consider it best practice for our containers in TripleO. Each container should container its own binaries and libraries as much as possible. And while I do think we should be using --volumes-from more often in TripleO it would be for sharing *data* between containers, not binaries. > > Background: > 1) For the Distributed Compute Node edge case, there is potentially > tens > of thousands of a single-compute-node remote edge sites connected > over > WAN to a single control plane, which is having high latency, like a > 100ms or so, and limited bandwith. Reducing the base layer size > becomes > a decent goal there. See the security background below. The reason we put Puppet into the base layer was in fact to prevent it from being downloaded multiple times. If we were to re-architect the image layers such that the child layers all contained their own copies of Puppet for example there would actually be a net increase in bandwidth and disk usage. So I would argue we are already addressing the goal of optimizing network and disk space. Moving it out of the base layer so that you can patch it more often without disrupting other services is a valid concern. But addressing this concern while also preserving our definiation of a container (see above, a container should contain all of its binaries) is going to cost you something, namely disk and network space because Puppet would need to be duplicated in each child container. As Puppet is used to configure a majority of the services in TripleO having it in the base container makes most sense. And yes, if there are security patches for Puppet/Ruby those might result in a bunch of containers getting pushed. But let Docker layers take care of this I think... Don't try to solve things by constructing your own custom mounts and volumes to work around the issue. > 2) For a generic security (Day 2, maintenance) case, when > puppet/ruby/systemd/name-it gets a CVE fixed, the base layer has to > be > updated and all layers on top - to be rebuild, and all of those > layers, > to be re-fetched for cloud hosts and all containers to be > restarted... > And all of that because of some fixes that have nothing to OpenStack. > By > the remote edge sites as well, remember of "tens of thousands", high > latency and limited bandwith?.. > 3) TripleO CI updates (including puppet*) packages in containers, not > in > a common base layer of those. So each a CI job has to update puppet* > and > its dependencies - ruby/systemd as well. Reducing numbers of packages > to > update for each container makes sense for CI as well. > > Implementation related: > > WIP patches [0],[1] for early review, uses a config "pod" approach, > does > not require to maintain a two sets of config vs runtime images. > Future > work: a) cronie requires systemd, we'd want to fix that also off the > base layer. b) rework to podman pods for docker-puppet.py instead of > --volumes-from a side car container (can't be backported for Queens > then, which is still nice to have a support for the Edge DCN case, > at > least downstream only perhaps). > > Some questions raised on IRC: > > Q: is having a service be able to configure itself really need to > involve a separate pod? > A: Highly likely yes, removing not-runtime things is a good idea and > pods is an established PaaS paradigm already. That will require some > changes in the architecture though (see the topic with WIP patches). I'm a little confused on this one. Are you suggesting that we have 2 containers for each service? One with Puppet and one without? That is certainly possible, but to pull it off would likely require you to have things built like this: |base container| --> |service container| --> |service container w/ Puppet installed| The end result would be Puppet being duplicated in a layer for each services "config image". Very inefficient. Again, I'm ansering this assumping we aren't violating our container constraints and best practices where each container has the binaries its needs to do its own configuration. > > Q: that's (fetching a config container) actually more data that > about to > download otherwise > A: It's not, if thinking of Day 2, when have to re-fetch the base > layer > and top layers, when some unrelated to openstack CVEs got fixed > there > for ruby/puppet/systemd. Avoid the need to restart service > containers > because of those minor updates puched is also a nice thing. Puppet is used only for configuration in TripleO. While security issues do need to be addressed at any layer I'm not sure there would be an urgency to re-deploy your cluster simply for a Puppet security fix alone. Smart change management would help eliminate blindly deploying new containers in the case where they provide very little security benefit. I think the focus on Puppet, and Ruby here is perhaps a bad example as they are config time only. Rather than just think about them we should also consider the rest of the things in our base container images as well. This is always going to be a "balancing act". There are pros and cons of having things in the base layer vs. the child/leaf layers. > > Q: the best solution here would be using packages on the host, > generating the config files on the host. And then having an all-in- > one > container for all the services which lets them run in an isolated > mannner. > A: I think for Edge cases, that's a no go as we might want to > consider > tiny low footprint OS distros like former known Container Linux or > Atomic. Also, an all-in-one container looks like an anti-pattern > from > the world of VMs. This was suggested on IRC because it likely gives you the smallest network/storage footprint for each edge node. The container would get used for everything: running all the services, and configuring all the services. Sort of a golden image approach. It may be an anti-pattern but initially I thought you were looking to optimize these things. I think a better solution might be to have container registries, or container mirrors (reverse proxies or whatever) that allow you to cache things as you deploy to the edge and thus optimize the network traffic. > > [0] https://review.openstack.org/#/q/topic:base-container-reduction > [1] > https://review.rdoproject.org/r/#/q/topic:base-container-reduction > > > Here is a related bug [1] and implementation [1] for that. PTAL > > folks! > > > > [0] https://bugs.launchpad.net/tripleo/+bug/1804822 > > [1] https://review.openstack.org/#/q/topic:base-container-reduction > > > > > Let's also think of removing puppet-tripleo from the base > > > container. > > > It really brings the world-in (and yum updates in CI!) each job > > > and each > > > container! > > > So if we did so, we should then either install puppet-tripleo and > > > co on > > > the host and bind-mount it for the docker-puppet deployment task > > > steps > > > (bad idea IMO), OR use the magical --volumes-from > > container> > > > option to mount volumes from some "puppet-config" sidecar > > > container > > > inside each of the containers being launched by docker-puppet > > > tooling. > > > > On Wed, Oct 31, 2018 at 11:16 AM Harald Jensås > redhat.com> > > wrote: > > > We add this to all images: > > > > > > https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646e535cf972c98ef/container-images/tripleo_kolla_template_overrides.j2#L35 > > > > > > /bin/sh -c yum -y install iproute iscsi-initiator-utils lvm2 > > > python > > > socat sudo which openstack-tripleo-common-container-base rsync > > > cronie > > > crudini openstack-selinux ansible python-shade puppet-tripleo > > > python2- > > > kubernetes && yum clean all && rm -rf /var/cache/yum 276 MB > > > > > > Is the additional 276 MB reasonable here? > > > openstack-selinux <- This package run relabling, does that kind > > > of > > > touching the filesystem impact the size due to docker layers? > > > > > > Also: python2-kubernetes is a fairly large package (18007990) do > > > we use > > > that in every image? I don't see any tripleo related repos > > > importing > > > from that when searching on Hound? The original commit message[1] > > > adding it states it is for future convenience. > > > > > > On my undercloud we have 101 images, if we are downloading every > > > 18 MB > > > per image thats almost 1.8 GB for a package we don't use? (I hope > > > it's > > > not like this? With docker layers, we only download that 276 MB > > > transaction once? Or?) > > > > > > > > > [1] https://review.openstack.org/527927 > > > > > > -- > > Best regards, > > Bogdan Dobrelya, > > Irc #bogdando > > From fungi at yuggoth.org Tue Nov 27 18:23:22 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 27 Nov 2018 18:23:22 +0000 Subject: [openstack-dev] IMPORTANT: We're combining the lists! In-Reply-To: <20181119000352.lgrg57kyjylbrmx6@yuggoth.org> References: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> <20181119000352.lgrg57kyjylbrmx6@yuggoth.org> Message-ID: <20181127182322.jznby55ktuafcwet@yuggoth.org> REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-discuss at lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From fungi at yuggoth.org Tue Nov 27 18:23:58 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 27 Nov 2018 18:23:58 +0000 Subject: [Openstack-sigs] IMPORTANT: We're combining the lists! In-Reply-To: <20181119000403.xdl45y5ghkwndyor@yuggoth.org> References: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> <20181119000403.xdl45y5ghkwndyor@yuggoth.org> Message-ID: <20181127182358.hseunpye3wg37wzc@yuggoth.org> REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-discuss at lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openstack-sigs mailing list openstack-sigs at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs From fungi at yuggoth.org Tue Nov 27 18:25:01 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 27 Nov 2018 18:25:01 +0000 Subject: [Openstack-operators] IMPORTANT: We're combining the lists! In-Reply-To: <20181119000414.u675z4z3s7esymat@yuggoth.org> References: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> <20181119000414.u675z4z3s7esymat@yuggoth.org> Message-ID: <20181127182501.vjdxgrg2ncmwcnl3@yuggoth.org> REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-discuss at lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From fungi at yuggoth.org Tue Nov 27 18:22:30 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 27 Nov 2018 18:22:30 +0000 Subject: [Openstack] IMPORTANT: We're combining the lists! In-Reply-To: <20181119000342.46kpr5wcunjq2bfn@yuggoth.org> References: <20180830170350.wrz4wlanb276kncb@yuggoth.org> <20180920163248.oia5t7zjqcfwluwz@yuggoth.org> <20181029165346.vm6ptoqq5wkqban6@yuggoth.org> <20181109181447.qhutsauxl4fuinnh@yuggoth.org> <20181119000342.46kpr5wcunjq2bfn@yuggoth.org> Message-ID: <20181127182230.2u3wffobjmxggkrz@yuggoth.org> REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-discuss at lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From murali.annamneni at oracle.com Tue Nov 27 18:39:10 2018 From: murali.annamneni at oracle.com (Murali Annamneni) Date: Tue, 27 Nov 2018 18:39:10 +0000 Subject: [openstack-dev] [pacemaker] Live migration with VirtualDomain resource-agent Message-ID: <8237a933-eb9b-d193-948f-eb28fcd332b1@oracle.com> Hi, I'm trying to setup pacemaker for live-migration when a compute node hosting the VM goes down. So, I created cluster resource for the compute-instance (demo1) with 'VirtualDomain' resource agent.      >>> pcs resource create demo1 VirtualDomain migrateuri="qemu+tcp://:16509/system" config="/etc/pacemaker/demo1.xml" migration_transport="tcp"  meta allow-migrate="true" op start timeout="120s" op stop timeout="180s" And I manually shutdown the compute node hosting the vm, but, I don't see the migration is happening. Can someone please help me what I am missing here ? Thanks & Regards, Murali -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From iain.macdonnell at oracle.com Tue Nov 27 18:52:48 2018 From: iain.macdonnell at oracle.com (iain MacDonnell) Date: Tue, 27 Nov 2018 10:52:48 -0800 Subject: [Openstack] [Cinder] Cinder New Tag Release In-Reply-To: References: <90950AF3-ED04-4015-BE09-E4235F0DFAC9@gmail.com> <1926809770.53738230.1543224969471.JavaMail.zimbra@redhat.com> Message-ID: <0b7b6cf0-e772-e6e3-8f0f-87ea2161b8c1@oracle.com> On 11/27/18 4:52 AM, Chhavi Agarwal wrote: > With the current tagged release of Openstack Cinder ( 13.0.1 ) > https://github.com/openstack/cinder/releases/tag/13.0.1 > we are hitting the below issue > > https://bugs.launchpad.net/cinder/+bug/1796759 > > This got fixed with change set https://review.openstack.org/#/c/608768/ > which is not a part of the tagged release. > > Want to know if we can have a new Cinder tag release to incorporate the > new fixes. [attempting to cross-post to openstack-discuss] Cinder 13.x releases are OpenStack Rocky, and the upper-constraints for Rocky [1] says oslo.messaging===8.1.2, so there should be no need to backport this fix. Are you trying to run the unit tests when you see this? When I run tox on stable/rocky, it installs 8.1.2 as one of the dependencies, although, to be honest, I'm really not sure how tox knows that that's the right version. Or are you trying to run Cinder from Rocky with newer oslo.messaging, and getting the same symptom as the unit test failures in that bug, when running the cinder services? If so, a) it's an unsupported combination (I believe) and b) you'd (at least) need to update your configuration to remove use of that deprecated rpc_backend option. ~iain [1] https://github.com/openstack/requirements/blob/stable/rocky/upper-constraints.txt From iain.macdonnell at oracle.com Tue Nov 27 19:05:00 2018 From: iain.macdonnell at oracle.com (iain MacDonnell) Date: Tue, 27 Nov 2018 11:05:00 -0800 Subject: [Openstack] [Cinder] Cinder New Tag Release In-Reply-To: <0b7b6cf0-e772-e6e3-8f0f-87ea2161b8c1@oracle.com> References: <90950AF3-ED04-4015-BE09-E4235F0DFAC9@gmail.com> <1926809770.53738230.1543224969471.JavaMail.zimbra@redhat.com> <0b7b6cf0-e772-e6e3-8f0f-87ea2161b8c1@oracle.com> Message-ID: <2cd493e9-e4a3-38e2-5295-9d7c1cd7dd29@oracle.com> On 11/27/18 10:52 AM, iain MacDonnell wrote: > > On 11/27/18 4:52 AM, Chhavi Agarwal wrote: >> With the current tagged release of Openstack Cinder ( 13.0.1 ) >> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_cinder_releases_tag_13.0.1&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=_-mGtryix-GE-7_xbOpH7F0ZS4jQxE3RJZ72LghieKQ&s=WMS_BqRFKcnhRVhLF7Etzpoinel262YhUoKvNL19508&e= >> we are hitting the below issue >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_cinder_-2Bbug_1796759&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=_-mGtryix-GE-7_xbOpH7F0ZS4jQxE3RJZ72LghieKQ&s=N4sIIITOxdF357oNgPI0vmwp7UyMtpyfwoe48FNGVec&e= >> >> This got fixed with change set >> https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_608768_&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=_-mGtryix-GE-7_xbOpH7F0ZS4jQxE3RJZ72LghieKQ&s=16ZhumVOFprhADv1v553c2wwyMfG84cP0a9Z3VHaVuM&e= >> which is not a part of the tagged release. >> >> Want to know if we can have a new Cinder tag release to incorporate >> the new fixes. > > [attempting to cross-post to openstack-discuss] > > Cinder 13.x releases are OpenStack Rocky, and the upper-constraints for > Rocky [1] says oslo.messaging===8.1.2, so there should be no need to > backport this fix. > > Are you trying to run the unit tests when you see this? When I run tox > on stable/rocky, it installs 8.1.2 as one of the dependencies, although, > to be honest, I'm really not sure how tox knows that that's the right > version. Ahh, here's how it knows :- $ grep install_command tox.ini install_command = pip install -c{env:UPPER_CONSTRAINTS_FILE:https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt?h=stable/rocky} {opts} {packages} $ ~iain > Or are you trying to run Cinder from Rocky with newer oslo.messaging, > and getting the same symptom as the unit test failures in that bug, when > running the cinder services? If so, a) it's an unsupported combination > (I believe) and b) you'd (at least) need to update your configuration to > remove use of that deprecated rpc_backend option. > >     ~iain > > > [1] > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_requirements_blob_stable_rocky_upper-2Dconstraints.txt&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=_-mGtryix-GE-7_xbOpH7F0ZS4jQxE3RJZ72LghieKQ&s=RyhzI0PUIxfPaQuJLH1iAf8Z4TjI1LWsI1DoUhBeYnc&e= > > From sean.mcginnis at gmail.com Tue Nov 27 19:08:58 2018 From: sean.mcginnis at gmail.com (Sean McGinnis) Date: Tue, 27 Nov 2018 13:08:58 -0600 Subject: [Openstack] [Cinder] Cinder New Tag Release In-Reply-To: <2cd493e9-e4a3-38e2-5295-9d7c1cd7dd29@oracle.com> References: <90950AF3-ED04-4015-BE09-E4235F0DFAC9@gmail.com> <1926809770.53738230.1543224969471.JavaMail.zimbra@redhat.com> <0b7b6cf0-e772-e6e3-8f0f-87ea2161b8c1@oracle.com> <2cd493e9-e4a3-38e2-5295-9d7c1cd7dd29@oracle.com> Message-ID: On Tue, Nov 27, 2018 at 1:05 PM iain MacDonnell wrote: > > >> Want to know if we can have a new Cinder tag release to incorporate > >> the new fixes. > > > > [attempting to cross-post to openstack-discuss] > > > > Cinder 13.x releases are OpenStack Rocky, and the upper-constraints for > > Rocky [1] says oslo.messaging===8.1.2, so there should be no need to > > backport this fix. > > > > Are you trying to run the unit tests when you see this? When I run tox > > on stable/rocky, it installs 8.1.2 as one of the dependencies, although, > > to be honest, I'm really not sure how tox knows that that's the right > > version. > > Ahh, here's how it knows :- > > $ grep install_command tox.ini > install_command = pip install > -c{env:UPPER_CONSTRAINTS_FILE: > https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt?h=stable/rocky} > > {opts} {packages} > $ > > ~iain > Yeah, we shouldn't need to backport something like this. We have upper constraints specifically to avoid needing to handle cases like this. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From stig.openstack at telfer.org Tue Nov 27 20:15:04 2018 From: stig.openstack at telfer.org (Stig Telfer) Date: Tue, 27 Nov 2018 20:15:04 +0000 Subject: [scientific] IRC meeting today 2100 UTC - Handling controlled-access data Message-ID: Hi All - We have a Scientific SIG IRC meeting at 2100 UTC (about 45 minute’s time) in IRC channel #openstack-meeting. Everyone is welcome. Today we’d like to gather interested parties for reporting on best practice on handling sensitive data (for example, genomics or medical data, but not limited to that). We’d also like to talk on best practices for intensive AI & ML. The full agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_November_27th_2018 Cheers, Stig From kennelson11 at gmail.com Tue Nov 27 21:38:25 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Tue, 27 Nov 2018 13:38:25 -0800 Subject: [ops][docs] The Contributor Guide: Ops Feedback Session Summary Message-ID: Hello! For the long version, feel free to look over the etherpad[1]. It should be noted that this session was in relation to the operator section of the contributor guide, not the operations guide, though they should be closely related and link to one another. Basically the changes requested can be boiled down to two types of changes: cosmetic and missing content. Cosmetic Changes: - Timestamps so people can know when the last change was made to a given doc (dhellmann volunteered to help here)[2] - Floating bug report button and some mechanism for auto populating which page a bug is on so that the reader doesn’t have to know what rst file in what repo has the issue to file a bug[3] - Maybe not cosmetic exactly, but it was requested that the entirety of the contributor guide be translated into as many languages as possible (stevenK volunteered to help get the framework setup so that things could be imported into Zanata for translation)[4] - Link to source somewhere on the page so those interested in fixing issues that don’t know the repo structure can find and fix issues right away[5] Missing Content: - Links to the docs in the Operator guide (HA guide, etc)[6] - A guide to ‘I fixed this bug locally, how do I get it upstream?’[7] If there are any unclaimed items you are interested in working on, please do! The contributor guide work items are tracked in StoryBoard here[8]! -Kendall (diablo_rojo) [1] https://etherpad.openstack.org/p/BER-Contrib-Guide-Ops [2] https://storyboard.openstack.org/#!/story/2004436 [3] https://storyboard.openstack.org/#!/story/2004437 [4] https://storyboard.openstack.org/#!/story/2004438 [5] https://storyboard.openstack.org/#!/story/2004439 [6] https://storyboard.openstack.org/#!/story/2004441 [7] https://storyboard.openstack.org/#!/story/2004442 [8]https://storyboard.openstack.org/#!/project/openstack/contributor-guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From aj at suse.com Tue Nov 27 21:52:11 2018 From: aj at suse.com (Andreas Jaeger) Date: Tue, 27 Nov 2018 16:52:11 -0500 Subject: [ops][docs] The Contributor Guide: Ops Feedback Session Summary In-Reply-To: References: Message-ID: <5938a4e0-3eb1-5448-3af5-f56bf3452e9c@suse.com> On 11/27/18 4:38 PM, Kendall Nelson wrote: > Hello! > > > For the long version, feel free to look over the etherpad[1]. > > > It should be noted that this session was in relation to the operator > section of the contributor guide, not the operations guide, though they > should be closely related and link to one another. > > > Basically the changes requested can be boiled down to two types of > changes: cosmetic and missing content. > > > Cosmetic Changes: > > * > > Timestamps so people can know when the last change was made to a > given doc (dhellmann volunteered to help here)[2] > > * > > Floating bug report button and some mechanism for auto populating > which page a bug is on so that the reader doesn’t have to know what > rst file in what repo has the issue to file a bug[3] This is something probably for openstackdocstheme to have it everywhere. With launchpad, the information on RST file is part of the "Report a bug" process. We do not have an equivelent "Report a bug" process for storyboard that allows prepopulating content - otherwise, we could update openstackdocstheme to pass this on. Andreas > > * > > Maybe not cosmetic exactly, but it was requested that the entirety > of the contributor guide be translated into as many languages as > possible (stevenK volunteered to help get the framework setup so > that things could be imported into Zanata for translation)[4] > > * > > Link to source somewhere on the page so those interested in fixing > issues that don’t know the repo structure can find and fix issues > right away[5] > > > Missing Content: > > * > > Links to the docs in the Operator guide (HA guide, etc)[6] > > * > > A guide to ‘I fixed this bug locally, how do I get it upstream?’[7] > > > If there are any unclaimed items you are interested in working on, > please do! The contributor guide work items are tracked in StoryBoard > here[8]! > > > -Kendall (diablo_rojo) > > [1] https://etherpad.openstack.org/p/BER-Contrib-Guide-Ops > > [2] https://storyboard.openstack.org/#!/story/2004436 > > [3] https://storyboard.openstack.org/#!/story/2004437 > > [4] https://storyboard.openstack.org/#!/story/2004438 > > [5] https://storyboard.openstack.org/#!/story/2004439 > > [6] https://storyboard.openstack.org/#!/story/2004441 > > [7] https://storyboard.openstack.org/#!/story/2004442 > > [8]https://storyboard.openstack.org/#!/project/openstack/contributor-guide > > -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 From kennelson11 at gmail.com Tue Nov 27 21:58:25 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Tue, 27 Nov 2018 13:58:25 -0800 Subject: [all][docs] Making the Contributor Portal More Useful Summary Message-ID: Hello! If you’re interested in starting with the etherpad from this forum session, you can peruse that here[1]. The biggest part of the discussion here was that the page[2] is overloaded and most users don’t make it down the page to other information they might be looking for. It’s trying to be too many things at once and we need to simplify the pages. The plan is to split into one focused on contribution information and another focused more on general community info. If you have opinions on how the split should go and weren’t in the forum session, please let us know! Another idea that was discussed was some sort of wizard/decision tree to help people find the part of the portal they want based on 3ish questions: Know what project you’re looking for? (would open to project section of code and docs contribution type) Brand new to OpenStack? (would point to contributor guide or where we need help) Or Interested in a particular topic? (would open to project groups in code and docs contribution type) The rest of discussion centered on smaller changes to the contribution topics in the page. Adding tooltips, making certain things more obvious (like the think to the actual contributor guide), making sure Docs & i18n get included in the code & docs section since that pulls from the project navigator. If you’re interested in getting involved with this page, let me know! We don’t have this work currently tracked in Launchpad or StoryBoard because the page is maintained by the Foundation, but we are working to change that! -Kendall (diablo_rojo) [1]https://etherpad.openstack.org/p/BER-Contrib-Portal [2]https://www.openstack.org/community/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Tue Nov 27 22:02:58 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Tue, 27 Nov 2018 16:02:58 -0600 Subject: [dev] Extracted placement repo is now used in devstack/grenade jobs on master Message-ID: <784d24cd-4fa3-f282-d4a2-d5227422fa85@gmail.com> Now that [1] is merged, the extracted openstack/placement repo is being used in devstack and grenade testing for changes on master. This is part of a series of changes for the extraction [2] from nova but it's likely the one that will have the most impact (if any) to other projects on a daily basis because of our CI system. So this is just an FYI in case something goes off the rails in the near future, hit us in the mailing list or #openstack-placement (or #openstack-nova) IRC channels. [1] https://review.openstack.org/#/c/600162/ [2] https://etherpad.openstack.org/p/BER-placement-extract -- Thanks, Matt From kennelson11 at gmail.com Tue Nov 27 22:45:11 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Tue, 27 Nov 2018 14:45:11 -0800 Subject: [all] [infra] StoryBoard Migration: The Remaining Blockers Summary Message-ID: Hello! As with all of my other summaries, if you are looking for the long etherpad version, you can find it here[1]. Somewhere along the way I used the wrong etherpad for notes and so we ended up doing the StoryBoard things in the etherpad originally meant for another session so pardon the name. Anywho. Overall the session went really well, there weren’t any huge glaring issues that anyone brought up. The majority of things were all smaller usability things. Just about all of which are definitely doable. The only slightly larger feature request (that we hadn't previously discussed) was a separate interface for filing stories- similar to the one LP provides. Something simple so the user doesn’t feel like they need to fill in all this information, but can just provide the minimum. I haven’t quite gotten around to making stories for all of the things discussed in the etherpad, but should have them up soon! You will be able to see them here[2], once they’ve been created. If you have opinions about any of what we discussed or have something you wanted to bring up but could not attend the session please drop into #storyboard and chat with us, or join us at our weekly meeting on Wednesday at 19:00 UTC. -Kendall (diablo_rojo) [1]https://etherpad.openstack.org/p/BER-Contrib-Portal-Feedback (yes, I know the name doesn’t seem right..) [2] https://storyboard.openstack.org/#!/story/list?status=active&project_group_id=57 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Tue Nov 27 22:52:53 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 27 Nov 2018 22:52:53 +0000 Subject: [ops][docs] The Contributor Guide: Ops Feedback Session Summary In-Reply-To: <5938a4e0-3eb1-5448-3af5-f56bf3452e9c@suse.com> References: <5938a4e0-3eb1-5448-3af5-f56bf3452e9c@suse.com> Message-ID: <20181127225253.z27foreia7sd7zu5@yuggoth.org> On 2018-11-27 16:52:11 -0500 (-0500), Andreas Jaeger wrote: [...] > We do not have an equivelent "Report a bug" process for storyboard > that allows prepopulating content [...] Since https://review.openstack.org/526219 merged in February, the new story creation URL allows passing HTTP GET parameters which can include default Story title and description content along with a project ID for the initial task. This could be used with some templating to inject the file path as part of a suggested description. https://storyboard.openstack.org/#!/story/new?project_id=456&title=foo&description=bar%20baz It could stand to have a project_name parameter so that something like project_name=openstack-infra/storyboard would be possible rather than the current project_id=456 construct, but I don't think that will be tough to add if someone's interested in using it. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From aj at suse.com Tue Nov 27 23:20:38 2018 From: aj at suse.com (Andreas Jaeger) Date: Tue, 27 Nov 2018 18:20:38 -0500 Subject: [ops][docs] The Contributor Guide: Ops Feedback Session Summary In-Reply-To: <20181127225253.z27foreia7sd7zu5@yuggoth.org> References: <5938a4e0-3eb1-5448-3af5-f56bf3452e9c@suse.com> <20181127225253.z27foreia7sd7zu5@yuggoth.org> Message-ID: <6a6814c7-cf7c-d442-4902-3e65a80006c0@suse.com> On 11/27/18 5:52 PM, Jeremy Stanley wrote: > On 2018-11-27 16:52:11 -0500 (-0500), Andreas Jaeger wrote: > [...] >> We do not have an equivelent "Report a bug" process for storyboard >> that allows prepopulating content > [...] > > Since https://review.openstack.org/526219 merged in February, the > new story creation URL allows passing HTTP GET parameters which can > include default Story title and description content along with a > project ID for the initial task. This could be used with some > templating to inject the file path as part of a suggested > description. > > https://storyboard.openstack.org/#!/story/new?project_id=456&title=foo&description=bar%20baz > > It could stand to have a project_name parameter so that something > like project_name=openstack-infra/storyboard would be possible > rather than the current project_id=456 construct, but I don't think > that will be tough to add if someone's interested in using it. Great, wasn't aware of it - now we need somebody to work on openstackdocstheme for that ;) I filed bug https://bugs.launchpad.net/openstack-doc-tools/+bug/1805514 for this, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 From openstack at nemebean.com Tue Nov 27 23:30:42 2018 From: openstack at nemebean.com (Ben Nemec) Date: Tue, 27 Nov 2018 17:30:42 -0600 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: <1ca0e1a7-58a1-8f91-617b-7be7b0df0e1b@redhat.com> References: <20181122234340.GE24690@thor.bakeyournoodle.com> <1ca0e1a7-58a1-8f91-617b-7be7b0df0e1b@redhat.com> Message-ID: <32c01016-6f23-d00c-356f-be68aa0cb29e@nemebean.com> On 11/26/18 9:47 AM, Zane Bitter wrote: > On 22/11/18 6:43 PM, Tony Breeds wrote: >>> ### 3 - Maintain a private interface for ThreadingEvent only on >>> stable/rocky >>> impacted projects: oslo.service >>> related reviews: >>> -https://review.openstack.org/619342/ >>> >>> pros: >>> - straightforward >>> cons: >>> - Changing the loopingcall module semantics as it is different type >>> - stable only patches >>> - misunderstoud service customer between Threading, eventlet, etc.. and >>> master behavior >> A variation of this (without adding the debtcollector requirement) might >> work as IIUC all versions of oslo.service < 1.32.0 (except 1.31.6) would >> work and doesn't introduce any new policy violations. >> >> Adding debcollector is great but introduces at least the semver issues >> from option #1 > > Hey Tony, can you explain the debtcollector issue a bit more? Is it just > that we generally promise to not adding anything to requirements.txt on > stable branches? In this case, debtcollector, appears to already be a > transitive dependency of something that oslo.service already requires > (it appears in lower-constraints.txt, at least), so I was assuming that > there wouldn't be any real-world consequences. Does that change things? Technically adding a new dep requires a minor version update per our release guidelines. I guess it gets a little fuzzy when you're adding a dep that's already part of the transitive set, but I'm guessing that's what Tony was referring to. That said, as I mentioned on the review I don't feel any particular need to debtcollector this. It's in a private module that nobody should ever have been using and we're only doing this because we prioritize fixing the bug over absolute API purity. :-) In any case, I'm +1 on doing this to avoid creating weird version dependencies on a stable branch. > > TBH it would be trivial to do something equivalent without adding the > new requirement, so I guess the easiest thing is if I just update the > patch to do that. > >>> ### 4 - Don't use private interface in oslo.service >>> impacted projects: nova >>> related reviews: >>> -https://review.openstack.org/#/c/619360/ >>> >>> pros: >>> - straightforward >>> cons: >>> - this could work but it is not the same sematics as before as the >>> type has >>> changed >>> - stable only patches >>> - misunderstoud service customer between Threading, eventlet, etc.. and >>> master behavior >> I think this is more or less the same as Option #3 in terms of impact. >> If that's right it could be acceptable. > > It's slightly higher impact, because you wouldn't be able to upgrade > oslo.service past 1.31.5 and still run the unit tests on old versions of > Nova. Whereas with option #3 you could just upgrade oslo.service to > 1.31.7, or just upgrade Nova, and either way everything would work. > > Not that we shouldn't do this *as well*, but IMHO we still need to do #3. > I like doing this as well. If we need an argument as to why it's okay to do this stable-only patch, it would be that this is essentially a backport of the original Nova fix proposed before we decided to do the fixture. In retrospect maybe we should have gone ahead and merged that simple, backportable fix and done the fixture as a followup, but in spirit this has the same effect. -Ben From openstack at nemebean.com Tue Nov 27 23:36:13 2018 From: openstack at nemebean.com (Ben Nemec) Date: Tue, 27 Nov 2018 17:36:13 -0600 Subject: Any way to reply to archived messages? In-Reply-To: <20181126223115.x5qlf2olghhpvnx5@yuggoth.org> References: <20181126223115.x5qlf2olghhpvnx5@yuggoth.org> Message-ID: <833345f7-3e85-a110-076e-dfd9dff8d012@nemebean.com> On 11/26/18 4:31 PM, Jeremy Stanley wrote: > On 2018-11-26 15:36:04 -0600 (-0600), Ben Nemec wrote: >> Let's say hypothetically someone procrastinated too long on the >> mailing list switchover and missed some messages on >> openstack-discuss, but now wants to reply to them. Is there any >> way to do that without breaking the threading in people's clients? >> Perhaps some way to request a message from the archive to be sent >> to me (err, this hypothetical person ;-). > > Sure! It's *slightly* hacky but looking at the archive of your > message, for example: > > http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000234.html > > You'll see that your obfuscated E-mail address near the top is a > hyperlink. The "In-Reply-To" parameter content can be turned into a > message header of the same name like: > > In-Reply-To: > > ...and added to the other headers in the reply you're composing. > This should preserve threading for everyone just fine. If you want > to scrape it from the HTML, just note that the "<", ">" and "@" > characters are %-encoded as "%3C", "%3E" and "%40" respectively so > you'll need to decode them before putting them into the header. Nice, thanks! Dan Smith sent me the thread so I could reply directly, but I did play around with this a bit and was able to send an email with the header present so it looks like that would have worked. > > An alternative solution is to visit the top archive index at > http://lists.openstack.org/pipermail/openstack-discuss/ and you'll > see that next to each month (in this case we only have November so > far) there's a "Downloadable version" linked. Following that link > will simply bring up a concatenated plaintext version of the month's > archive in mbox format (new messages start with "From " at the > beginning of the line) and keyword search for the message you're > looking for, then copy the content of its "Message-ID" header into > an "In-Reply-To" header for your reply. > From gmann at ghanshyammann.com Wed Nov 28 01:03:04 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 28 Nov 2018 10:03:04 +0900 Subject: [dev] [tc][all] TC office hours is started now on #openstack-tc Message-ID: <16757d7421d.eb56d9bc153258.4930750432211506610@ghanshyammann.com> Hi All, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - TC From Kevin.Fox at pnnl.gov Wed Nov 28 00:31:24 2018 From: Kevin.Fox at pnnl.gov (Fox, Kevin M) Date: Wed, 28 Nov 2018 00:31:24 +0000 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <089336b7a431cab76e1350a959b7bb566175134b.camel@redhat.com> References: <9dee4044-2744-3ab6-3a15-bd79702ff35a@redhat.com>, <089336b7a431cab76e1350a959b7bb566175134b.camel@redhat.com> Message-ID: <1A3C52DFCD06494D8528644858247BF01C248BF7@EX10MBOX03.pnnl.gov> The pod concept allows you to have one tool per container do one thing and do it well. You can have a container for generating config, and another container for consuming it. In a Kubernetes pod, if you still wanted to do puppet, you could have a pod that: 1. had an init container that ran puppet and dumped the resulting config to an emptyDir volume. 2. had your main container pull its config from the emptyDir volume. Then each container would have no dependency on each other. In full blown Kubernetes cluster you might have puppet generate a configmap though and ship it to your main container directly. Thats another matter though. I think the example pod example above is still usable without k8s? Thanks, Kevin ________________________________________ From: Dan Prince [dprince at redhat.com] Sent: Tuesday, November 27, 2018 10:10 AM To: OpenStack Development Mailing List (not for usage questions); openstack-discuss at lists.openstack.org Subject: Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes On Tue, 2018-11-27 at 16:24 +0100, Bogdan Dobrelya wrote: > Changing the topic to follow the subject. > > [tl;dr] it's time to rearchitect container images to stop incluiding > config-time only (puppet et al) bits, which are not needed runtime > and > pose security issues, like CVEs, to maintain daily. I think your assertion that we need to rearchitect the config images to container the puppet bits is incorrect here. After reviewing the patches you linked to below it appears that you are proposing we use --volumes-from to bind mount application binaries from one container into another. I don't believe this is a good pattern for containers. On baremetal if we followed the same pattern it would be like using an /nfs share to obtain access to binaries across the network to optimize local storage. Now... some people do this (like maybe high performance computing would launch an MPI job like this) but I don't think we should consider it best practice for our containers in TripleO. Each container should container its own binaries and libraries as much as possible. And while I do think we should be using --volumes-from more often in TripleO it would be for sharing *data* between containers, not binaries. > > Background: > 1) For the Distributed Compute Node edge case, there is potentially > tens > of thousands of a single-compute-node remote edge sites connected > over > WAN to a single control plane, which is having high latency, like a > 100ms or so, and limited bandwith. Reducing the base layer size > becomes > a decent goal there. See the security background below. The reason we put Puppet into the base layer was in fact to prevent it from being downloaded multiple times. If we were to re-architect the image layers such that the child layers all contained their own copies of Puppet for example there would actually be a net increase in bandwidth and disk usage. So I would argue we are already addressing the goal of optimizing network and disk space. Moving it out of the base layer so that you can patch it more often without disrupting other services is a valid concern. But addressing this concern while also preserving our definiation of a container (see above, a container should contain all of its binaries) is going to cost you something, namely disk and network space because Puppet would need to be duplicated in each child container. As Puppet is used to configure a majority of the services in TripleO having it in the base container makes most sense. And yes, if there are security patches for Puppet/Ruby those might result in a bunch of containers getting pushed. But let Docker layers take care of this I think... Don't try to solve things by constructing your own custom mounts and volumes to work around the issue. > 2) For a generic security (Day 2, maintenance) case, when > puppet/ruby/systemd/name-it gets a CVE fixed, the base layer has to > be > updated and all layers on top - to be rebuild, and all of those > layers, > to be re-fetched for cloud hosts and all containers to be > restarted... > And all of that because of some fixes that have nothing to OpenStack. > By > the remote edge sites as well, remember of "tens of thousands", high > latency and limited bandwith?.. > 3) TripleO CI updates (including puppet*) packages in containers, not > in > a common base layer of those. So each a CI job has to update puppet* > and > its dependencies - ruby/systemd as well. Reducing numbers of packages > to > update for each container makes sense for CI as well. > > Implementation related: > > WIP patches [0],[1] for early review, uses a config "pod" approach, > does > not require to maintain a two sets of config vs runtime images. > Future > work: a) cronie requires systemd, we'd want to fix that also off the > base layer. b) rework to podman pods for docker-puppet.py instead of > --volumes-from a side car container (can't be backported for Queens > then, which is still nice to have a support for the Edge DCN case, > at > least downstream only perhaps). > > Some questions raised on IRC: > > Q: is having a service be able to configure itself really need to > involve a separate pod? > A: Highly likely yes, removing not-runtime things is a good idea and > pods is an established PaaS paradigm already. That will require some > changes in the architecture though (see the topic with WIP patches). I'm a little confused on this one. Are you suggesting that we have 2 containers for each service? One with Puppet and one without? That is certainly possible, but to pull it off would likely require you to have things built like this: |base container| --> |service container| --> |service container w/ Puppet installed| The end result would be Puppet being duplicated in a layer for each services "config image". Very inefficient. Again, I'm ansering this assumping we aren't violating our container constraints and best practices where each container has the binaries its needs to do its own configuration. > > Q: that's (fetching a config container) actually more data that > about to > download otherwise > A: It's not, if thinking of Day 2, when have to re-fetch the base > layer > and top layers, when some unrelated to openstack CVEs got fixed > there > for ruby/puppet/systemd. Avoid the need to restart service > containers > because of those minor updates puched is also a nice thing. Puppet is used only for configuration in TripleO. While security issues do need to be addressed at any layer I'm not sure there would be an urgency to re-deploy your cluster simply for a Puppet security fix alone. Smart change management would help eliminate blindly deploying new containers in the case where they provide very little security benefit. I think the focus on Puppet, and Ruby here is perhaps a bad example as they are config time only. Rather than just think about them we should also consider the rest of the things in our base container images as well. This is always going to be a "balancing act". There are pros and cons of having things in the base layer vs. the child/leaf layers. > > Q: the best solution here would be using packages on the host, > generating the config files on the host. And then having an all-in- > one > container for all the services which lets them run in an isolated > mannner. > A: I think for Edge cases, that's a no go as we might want to > consider > tiny low footprint OS distros like former known Container Linux or > Atomic. Also, an all-in-one container looks like an anti-pattern > from > the world of VMs. This was suggested on IRC because it likely gives you the smallest network/storage footprint for each edge node. The container would get used for everything: running all the services, and configuring all the services. Sort of a golden image approach. It may be an anti-pattern but initially I thought you were looking to optimize these things. I think a better solution might be to have container registries, or container mirrors (reverse proxies or whatever) that allow you to cache things as you deploy to the edge and thus optimize the network traffic. > > [0] https://review.openstack.org/#/q/topic:base-container-reduction > [1] > https://review.rdoproject.org/r/#/q/topic:base-container-reduction > > > Here is a related bug [1] and implementation [1] for that. PTAL > > folks! > > > > [0] https://bugs.launchpad.net/tripleo/+bug/1804822 > > [1] https://review.openstack.org/#/q/topic:base-container-reduction > > > > > Let's also think of removing puppet-tripleo from the base > > > container. > > > It really brings the world-in (and yum updates in CI!) each job > > > and each > > > container! > > > So if we did so, we should then either install puppet-tripleo and > > > co on > > > the host and bind-mount it for the docker-puppet deployment task > > > steps > > > (bad idea IMO), OR use the magical --volumes-from > > container> > > > option to mount volumes from some "puppet-config" sidecar > > > container > > > inside each of the containers being launched by docker-puppet > > > tooling. > > > > On Wed, Oct 31, 2018 at 11:16 AM Harald Jensås > redhat.com> > > wrote: > > > We add this to all images: > > > > > > https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646e535cf972c98ef/container-images/tripleo_kolla_template_overrides.j2#L35 > > > > > > /bin/sh -c yum -y install iproute iscsi-initiator-utils lvm2 > > > python > > > socat sudo which openstack-tripleo-common-container-base rsync > > > cronie > > > crudini openstack-selinux ansible python-shade puppet-tripleo > > > python2- > > > kubernetes && yum clean all && rm -rf /var/cache/yum 276 MB > > > > > > Is the additional 276 MB reasonable here? > > > openstack-selinux <- This package run relabling, does that kind > > > of > > > touching the filesystem impact the size due to docker layers? > > > > > > Also: python2-kubernetes is a fairly large package (18007990) do > > > we use > > > that in every image? I don't see any tripleo related repos > > > importing > > > from that when searching on Hound? The original commit message[1] > > > adding it states it is for future convenience. > > > > > > On my undercloud we have 101 images, if we are downloading every > > > 18 MB > > > per image thats almost 1.8 GB for a package we don't use? (I hope > > > it's > > > not like this? With docker layers, we only download that 276 MB > > > transaction once? Or?) > > > > > > > > > [1] https://review.openstack.org/527927 > > > > > > -- > > Best regards, > > Bogdan Dobrelya, > > Irc #bogdando > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From senrique at redhat.com Wed Nov 28 02:23:48 2018 From: senrique at redhat.com (Sofia Enriquez) Date: Tue, 27 Nov 2018 23:23:48 -0300 Subject: [ops][docs] The Contributor Guide: Ops Feedback Session Summary In-Reply-To: <6a6814c7-cf7c-d442-4902-3e65a80006c0@suse.com> References: <5938a4e0-3eb1-5448-3af5-f56bf3452e9c@suse.com> <20181127225253.z27foreia7sd7zu5@yuggoth.org> <6a6814c7-cf7c-d442-4902-3e65a80006c0@suse.com> Message-ID: HI all, Sorry if my question is too silly: are you going to modify the Developer's Guide too? [1]. I have some suggestions for the Starting Work on a New Project section. On the other hand, I think I could help to translate the guide to Spanish (since I'm Spanish native speaker). Let me know if you need help. Thanks, Sofia [1] https://docs.openstack.org/infra/manual/developers.html. On Tue, Nov 27, 2018 at 8:22 PM Andreas Jaeger wrote: > On 11/27/18 5:52 PM, Jeremy Stanley wrote: > > On 2018-11-27 16:52:11 -0500 (-0500), Andreas Jaeger wrote: > > [...] > >> We do not have an equivelent "Report a bug" process for storyboard > >> that allows prepopulating content > > [...] > > > > Since https://review.openstack.org/526219 merged in February, the > > new story creation URL allows passing HTTP GET parameters which can > > include default Story title and description content along with a > > project ID for the initial task. This could be used with some > > templating to inject the file path as part of a suggested > > description. > > > > > https://storyboard.openstack.org/#!/story/new?project_id=456&title=foo&description=bar%20baz > > > > It could stand to have a project_name parameter so that something > > like project_name=openstack-infra/storyboard would be possible > > rather than the current project_id=456 construct, but I don't think > > that will be tough to add if someone's interested in using it. > > Great, wasn't aware of it - now we need somebody to work on > openstackdocstheme for that ;) > > I filed bug https://bugs.launchpad.net/openstack-doc-tools/+bug/1805514 > for this, > > Andreas > -- > Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer, Jane Smithard, Graham Norton, > HRB 21284 (AG Nürnberg) > GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 > > > -- Laura Sofia Enriquez Associate Software Engineer Red Hat PnT Ingeniero Butty 240, Piso 14 (C1001AFB) Buenos Aires - Argentina +541143297471 (8426471) senrique at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-philippe at evrard.me Wed Nov 28 09:47:08 2018 From: jean-philippe at evrard.me (Jean-Philippe Evrard) Date: Wed, 28 Nov 2018 10:47:08 +0100 Subject: [openstack-ansible] Evaluating meeting schedule + method In-Reply-To: <1913981.aYPTVNe1F8@whitebase.usersys.redhat.com> References: <1913981.aYPTVNe1F8@whitebase.usersys.redhat.com> Message-ID: <8c59e2dbcd07bda4d4e12952e5d5af0bf8c839f2.camel@evrard.me> > Yes, a chat system allows you to multitask and do other things, but, > I think the problem IS multitasking. It can become a really frustrating experience for meeting chair tbh. We have faced this fluctuating attendance in the past. I proposed to change meeting time, change of topics, and change of frequency. All of the above lead to a temporary increase in the meeting attendance for a week or two, followed by a return to the status quo. We can replace the status update of last week/focus of the week by a regular mail to the ML. That could be the equivalent of the WHOA (What's happening in OpenStack-Ansible, featuring Keanu Reeves' memes) Major wrote in the past. Open Discussion is something we achieve generally in our channel outside meetings. Having an office hour there could ensure people could come to a certain time and we'd be there. Attendance would be identitical though, but it's not really an issue to me. Only one section remains, bug triage. Bug triage had not only a goal of triaging bugs, but we also actively engage with people to get contributions. I am not sure how this can be adapted, as we need people actively working together at the same time. Maybe organising more regular bug smashes instead? Regards, Jean-Philippe Evrard (evrardjp) From tobias.rydberg at citynetwork.eu Wed Nov 28 09:57:18 2018 From: tobias.rydberg at citynetwork.eu (Tobias Rydberg) Date: Wed, 28 Nov 2018 10:57:18 +0100 Subject: [openstack-dev] [nova] Stein forum session notes In-Reply-To: References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> Message-ID: <4f4f66d7-fb0a-1a61-a06b-cd6b5a848cba@citynetwork.eu> On 2018-11-21 21:38, melanie witt wrote: >>> Change of ownership of resources >>> ================================ >>> - Ignore the network piece for now, it's the most complicated. Being >>> able to transfer everything else would solve 90% of City Network's use >>> cases >>> - Some ideas around having this be a keystone auth-based access >>> granting >>> instead of an update of project/user, but if keystone could hand user A >>> a token for user B, that token would apply to all resources of user >>> B's, >>> not just the ones desired for transfer >> >> Whatever happened with the os-chown project Dan started in Denver? >> >> https://github.com/kk7ds/oschown > > What we distilled from the forum session is that at the heart of it, > what is actually wanted is to be able to grant access to a resource > owned by project A to project B, for example. It's not so much about > wanting to literally change project_id/user_id from A to B. So, we > asked the question, "what if project A could grant access to its > resources to project B via keystone?" This could work if it is OK for > project B to gain access to _all_ of project A's resources (since we > currently have no way to scope access to specific resources). For a > use case where it is OK for project A to grant access to all of > project B's resources, the idea of accomplishing this is > keystone-only, could work. Doing it auth-based through keystone-only > would leave project_id/user_id and all dependencies intact, making the > change only at the auth/project level. It is simpler and cleaner. > > However, for a use case where it is not OK for project B to gain > access to all of project A's resources, because we lack the ability to > scope access to specific resources, the os-chown approach is the only > proposal we know of that can address it. > > So, depending on the use cases, we might be able to explore a keystone > approach. From what I gathered in the forum session, it sounded like > City Network might be OK with a project-wide access grant, but Oath > might need a resource-specific scoped access grant. If those are both > the case, we would find use in both a keystone access approach and the > os-chown approach. If you and others understood me that way I might have expressed me in the wrong way. For us, the use case we see is actually "transfer resources between tenants". Would say that basically all requests are for VMs and volumes, so that would cover most of that. As formulated in the forum session description, "As seamless as possible", can mean many different things for people, but offline approach is totally fine for my use case. What we discussed (or touched) during the session was to use similar approach as for glance image access, but in this case use that invite/accept approach for the actual ownership transfer (to be clear - not allow someone else access to my resources). Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Wed Nov 28 10:03:36 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 28 Nov 2018 19:03:36 +0900 Subject: [dev] [nova] API updates week 18-48 Message-ID: <16759c62204.1056cf734156973.5334291088439730026@ghanshyammann.com> Hi All, Please find the Nova API highlights of this week. Weekly Office Hour: =============== No Office hour (Alex was not online) - I did bug triage during that time. Triaged 5 bugs and updated the API bug report etherpad. Planned Features : ============== Below are the API related features for Stein. Ref - https://etherpad.openstack.org/p/stein-nova-subteam-tracking (feel free to add API item there if you are working or found any). NOTE: sequence order are not the priority, they are listed as per their start date. 1. Handling a down cell - https://blueprints.launchpad.net/nova/+spec/handling-down-cell - https://review.openstack.org/#/q/topic:bp/handling-down-cell+(status:open+OR+status:merged) - Weekly Progress: tssurya has progress on this and discussin with matt and melanie . 2. Servers Ips non-unique network names : - https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names - Spec Merged - https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged) - Weekly Progress: No progress. I will take care of this after api policy improvement spec update. 3. Volume multiattach enhancements: - https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements - https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(status:open+OR+status:merged) - Weekly Progress: No progress. 4. Add API ref guideline for body text (takashin) - https://review.openstack.org/#/c/605628/ - Weekly Progress: It has one +2 and need one more +2. 5. Detach and attach boot volumes: - https://blueprints.launchpad.net/nova/+spec/detach-boot-volume - https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+OR+status:merged) - Weekly Progress: No progress. Specs: 6. Nova API policy updates https://blueprints.launchpad.net/nova/+spec/granular-api-policy Spec: https://review.openstack.org/#/c/547850/ - Weekly Progress: No progress in this week. I will update the spec next week. 7. Nova API cleanup https://blueprints.launchpad.net/nova/+spec/api-consistency-cleanup Spec: https://review.openstack.org/#/c/603969/ - Weekly Progress: Updated the spec with review comment and added 2 more cleanup listed in etherpad 8. Support deleting data volume when destroy instance(Brin Zhang) - https://review.openstack.org/#/c/580336/ - Weekly Progress: No Progress this week. Waiting for spec review. COMPLETED: 1. API Extensions merge work - https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-stein - https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/api-extensions-merge-stein+status:open - Weekly Progress: This was COMPLETED few weeks back itself. 2. Boot instance specific storage backend - https://blueprints.launchpad.net/nova/+spec/boot-instance-specific-storage-backend - https://review.openstack.org/#/q/topic:bp/boot-instance-specific-storage-backend+(status:open+OR+status:merged) - Weekly Progress: COMPLETED Bugs: ==== This week Bug Progress: https://etherpad.openstack.org/p/nova-api-weekly-bug-report Critical: 0->0 High importance: 1->1 By Status: New: 5->2 Confirmed/Triage: 32-> 32 In-progress: 36->35 Incomplete: 5->6 ===== Total: 78->75 NOTE- There might be some bug which are not tagged as 'api' or 'api-ref', those are not in above list. Tag such bugs so that we can keep our eyes. -gmann From dabarren at gmail.com Wed Nov 28 10:06:57 2018 From: dabarren at gmail.com (Eduardo Gonzalez) Date: Wed, 28 Nov 2018 11:06:57 +0100 Subject: [kolla] Meeting 28-nov-2018 canceled Message-ID: Dear Kolla Team, Due to many people wont be able to attend today meeting, the Kolla weekly meeting on Wednesday 28th is canceled. Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdobreli at redhat.com Wed Nov 28 11:45:54 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Wed, 28 Nov 2018 12:45:54 +0100 Subject: [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: Message-ID: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> To follow up and explain the patches for code review: The "header" patch https://review.openstack.org/620310 -> (requires) https://review.rdoproject.org/r/#/c/17534/, and also https://review.openstack.org/620061 -> (which in turn requires) https://review.openstack.org/619744 -> (Kolla change, the 1st to go) https://review.openstack.org/619736 Please also read the commit messages, I tried to explain all "Whys" very carefully. Just to sum up it here as well: The current self-containing (config and runtime bits) architecture of containers badly affects: * the size of the base layer and all containers images as an additional 300MB (adds an extra 30% of size). * Edge cases, where we have containers images to be distributed, at least once to hit local registries, over high-latency and limited bandwith, highly unreliable WAN connections. * numbers of packages to update in CI for all containers for all services (CI jobs do not rebuild containers so each container gets updated for those 300MB of extra size). * security and the surface of attacks, by introducing systemd et al as additional subjects for CVE fixes to maintain for all containers. * services uptime, by additional restarts of services related to security maintanence of irrelevant to openstack components sitting as a dead weight in containers images for ever. On 11/27/18 4:08 PM, Bogdan Dobrelya wrote: > Changing the topic to follow the subject. > > [tl;dr] it's time to rearchitect container images to stop incluiding > config-time only (puppet et al) bits, which are not needed runtime and > pose security issues, like CVEs, to maintain daily. > > Background: 1) For the Distributed Compute Node edge case, there is > potentially tens of thousands of a single-compute-node remote edge sites > connected over WAN to a single control plane, which is having high > latency, like a 100ms or so, and limited bandwith. > 2) For a generic security case, > 3) TripleO CI updates all > > Challenge: > >> Here is a related bug [1] and implementation [1] for that. PTAL folks! >> >> [0] https://bugs.launchpad.net/tripleo/+bug/1804822 >> [1] https://review.openstack.org/#/q/topic:base-container-reduction >> >>> Let's also think of removing puppet-tripleo from the base container. >>> It really brings the world-in (and yum updates in CI!) each job and >>> each container! >>> So if we did so, we should then either install puppet-tripleo and co >>> on the host and bind-mount it for the docker-puppet deployment task >>> steps (bad idea IMO), OR use the magical --volumes-from >>> option to mount volumes from some >>> "puppet-config" sidecar container inside each of the containers being >>> launched by docker-puppet tooling. >> >> On Wed, Oct 31, 2018 at 11:16 AM Harald Jensås >> wrote: >>> We add this to all images: >>> >>> https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646e535cf972c98ef/container-images/tripleo_kolla_template_overrides.j2#L35 >>> >>> >>> /bin/sh -c yum -y install iproute iscsi-initiator-utils lvm2 python >>> socat sudo which openstack-tripleo-common-container-base rsync cronie >>> crudini openstack-selinux ansible python-shade puppet-tripleo python2- >>> kubernetes && yum clean all && rm -rf /var/cache/yum 276 MB >>> Is the additional 276 MB reasonable here? >>> openstack-selinux <- This package run relabling, does that kind of >>> touching the filesystem impact the size due to docker layers? >>> >>> Also: python2-kubernetes is a fairly large package (18007990) do we use >>> that in every image? I don't see any tripleo related repos importing >>> from that when searching on Hound? The original commit message[1] >>> adding it states it is for future convenience. >>> >>> On my undercloud we have 101 images, if we are downloading every 18 MB >>> per image thats almost 1.8 GB for a package we don't use? (I hope it's >>> not like this? With docker layers, we only download that 276 MB >>> transaction once? Or?) >>> >>> >>> [1] https://review.openstack.org/527927 >> >> >> >> -- >> Best regards, >> Bogdan Dobrelya, >> Irc #bogdando > > -- Best regards, Bogdan Dobrelya, Irc #bogdando From rico.lin.guanyu at gmail.com Wed Nov 28 12:00:03 2018 From: rico.lin.guanyu at gmail.com (Rico Lin) Date: Wed, 28 Nov 2018 20:00:03 +0800 Subject: [all][ptl][heat][senlin][magnum]New SIG for Autoscaling? plus Session Summary: Autoscaling Integration, improvement, and feedback Message-ID: Dear all Tl;dr; I gonna use this ML to give a summary of the forum [1] and asking for feedback for the idea of new SIG. We have a plan to create a new SIG for autoscaling which to cover the common library, docs, and tests for cross-project services (Senlin, Heat, Monasca, etc.) and cross-community (OpenStack, Kubernetes, etc). And the goal is not just to have a place to keep those resources that make sure we can guarantee the availability for use cases, also to have a force to keep push the effort to integrate across services or at least make sure we don't go to a point where everyone just do their own service and don't care about any duplication. So if you have any thoughts for the new SIG (good or bad) please share it here. Here I summarize our discussion in the forum session `Autoscaling Integration, improvement, and feedback`. If you like to learn more or input your thoughts, feel free to put it in etherpad [1] or simply reply to this email. In the forum, we have been discussed the scope and possibility to integrate effort from Heat, Senlin, and also autoscaling across OpenStack to K8s. There are some long-term goals that we can start on like create a document for general Autoscaling on OpenStack, Common library for cross-project usage, or create real scenario cases to test on our CI. And the most important part is how can we help users and satisfied use cases without confuse them or making too much duplication effort across communities/projects. So here's an action we agree on, is to trigger discussion for either we need to create a new SIG for autoscaling. We need to define the scope and the goal for this new SIG before we go ahead and create one. The new SIG will cover the common library, docs, and tests for cross-project services (Senlin, Heat, Monasca, etc.) and cross-community (OpenStack, Kubernetes, etc). And the goal is not just to have a place to keep those resources that make sure we can guarantee the availability for use cases, also to have a force to keep push the effort to integrate across services or at least make sure we don't go to a point where everyone just do their own service and don't care about any duplication. For example, we can have a document about do autoscaling in OpenStack, but we need a place to put it and keep maintain it. And we can even have a place to set up CI to test all scenario for autoscaling. I think it's possible to extend the definition of this SIG, but we have to clear our goal and make sure we actually doing a good thing and make everyone's life easier. On the other hand we also need to make sure we do not duplicate the effort of other SIGs/WGs. Also The reason I add `ptl` tag for this ML is that this SIG or the concept of `autoscaling` might be very deferent to different projects. So I really wish to hear from anyone and any projects who are interested in this topic. [1] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin -------------- next part -------------- An HTML attachment was scrubbed... URL: From chhagarw at in.ibm.com Wed Nov 28 04:42:33 2018 From: chhagarw at in.ibm.com (Chhavi Agarwal) Date: Wed, 28 Nov 2018 10:12:33 +0530 Subject: [Openstack] [Cinder] Cinder New Tag Release In-Reply-To: References: <90950AF3-ED04-4015-BE09-E4235F0DFAC9@gmail.com> <1926809770.53738230.1543224969471.JavaMail.zimbra@redhat.com> <0b7b6cf0-e772-e6e3-8f0f-87ea2161b8c1@oracle.com> <2cd493e9-e4a3-38e2-5295-9d7c1cd7dd29@oracle.com> Message-ID: I could see that the Unit tests are run against the latest oslo.messaging from the master, and source tree is old. http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt oslo.messaging===9.2.1 [root at ip9-114-192-185 cinder-es]# grep install_command tox.ini install_command = pip install -c{env:UPPER_CONSTRAINTS_FILE: https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt } {opts} {packages} [root at ip9-114-192-185 cinder-es]# Will get the configuration fixed. Thanks for the clarification. Thanks & Regards, Chhavi Agarwal Cloud System Software Group. From: Sean McGinnis To: iain.macdonnell at oracle.com Cc: chhagarw at in.ibm.com, openstack at lists.openstack.org, openstack-discuss at lists.openstack.org, jungleboyj at electronicjungle.net, John Griffith Date: 11/28/2018 12:39 AM Subject: Re: [Openstack] [Cinder] Cinder New Tag Release On Tue, Nov 27, 2018 at 1:05 PM iain MacDonnell wrote: >> Want to know if we can have a new Cinder tag release to incorporate >> the new fixes. > > [attempting to cross-post to openstack-discuss] > > Cinder 13.x releases are OpenStack Rocky, and the upper-constraints for > Rocky [1] says oslo.messaging===8.1.2, so there should be no need to > backport this fix. > > Are you trying to run the unit tests when you see this? When I run tox > on stable/rocky, it installs 8.1.2 as one of the dependencies, although, > to be honest, I'm really not sure how tox knows that that's the right > version. Ahh, here's how it knows :- $ grep install_command tox.ini install_command = pip install -c{env:UPPER_CONSTRAINTS_FILE: https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt?h=stable/rocky } {opts} {packages} $      ~iain Yeah, we shouldn't need to backport something like this. We have upper constraints specifically to avoid needing to handle cases like this. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From liliueecg at gmail.com Wed Nov 28 05:04:32 2018 From: liliueecg at gmail.com (Li Liu) Date: Tue, 27 Nov 2018 21:04:32 -0800 Subject: [openstack-dev] [Cyborg] IRC meeting still happens at usual time this Wednesday Message-ID: Hi Team, I know there is a polling on the new IRC meeting time, but before we gather more inputs, let's keep using the old time slot for this week (10PM Beijing Time/9AM EST/6AM PST) Agenda for this week's meeting: 1. Status update on NOVA interaction spec 2. Status update on DB scheme spec 3. Status tracking on all the open patches -- Thank you Regards Li -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From zufardhiyaulhaq at gmail.com Wed Nov 28 07:50:32 2018 From: zufardhiyaulhaq at gmail.com (Zufar Dhiyaulhaq) Date: Wed, 28 Nov 2018 14:50:32 +0700 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: Message-ID: Hi, Thank you. I am able to fix this issue by adding this configuration into nova configuration file in controller node. driver=filter_scheduler Best Regards Zufar Dhiyaulhaq On Tue, Nov 27, 2018 at 5:01 PM Zufar Dhiyaulhaq wrote: > Hi Smooney, > sorry for the last reply. I am attaching wrong configuration files. This > is my nova configuration (added randomization from your suggestion) from > the master node (Template jinja2 based). > > [DEFAULT] > osapi_compute_listen = {{ > hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} > metadata_listen = {{ > hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} > enabled_apis = osapi_compute,metadata > transport_url = rabbit://openstack:{{ rabbitmq_pw }}@{{ controller1_ip_man > }}:5672,openstack:{{ rabbitmq_pw }}@{{ controller2_ip_man > }}:5672,openstack:{{ rabbitmq_pw }}@{{ controller3_ip_man }}:5672 > my_ip = {{ > hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} > use_neutron = True > firewall_driver = nova.virt.firewall.NoopFirewallDriver > [api] > auth_strategy = keystone > [api_database] > connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_api > [barbican] > [cache] > backend=oslo_cache.memcache_pool > enabled=true > memcache_servers={{ controller1_ip_man }}:11211,{{ controller2_ip_man > }}:11211,{{ controller3_ip_man }}:11211 > [cells] > [cinder] > os_region_name = RegionOne > [compute] > [conductor] > [console] > [consoleauth] > [cors] > [crypto] > [database] > connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova > [devices] > [ephemeral_storage_encryption] > [filter_scheduler] > [glance] > api_servers = http://{{ vip }}:9292 > [guestfs] > [healthcheck] > [hyperv] > [ironic] > [key_manager] > [keystone] > [keystone_authtoken] > auth_url = http://{{ vip }}:5000/v3 > memcached_servers = {{ controller1_ip_man }}:11211,{{ controller2_ip_man > }}:11211,{{ controller3_ip_man }}:11211 > auth_type = password > project_domain_name = default > user_domain_name = default > project_name = service > username = nova > password = {{ nova_pw }} > [libvirt] > [matchmaker_redis] > [metrics] > [mks] > [neutron] > url = http://{{ vip }}:9696 > auth_url = http://{{ vip }}:35357 > auth_type = password > project_domain_name = default > user_domain_name = default > region_name = RegionOne > project_name = service > username = neutron > password = {{ neutron_pw }} > service_metadata_proxy = true > metadata_proxy_shared_secret = {{ metadata_secret }} > [notifications] > [osapi_v21] > [oslo_concurrency] > lock_path = /var/lib/nova/tmp > [oslo_messaging_amqp] > [oslo_messaging_kafka] > [oslo_messaging_notifications] > [oslo_messaging_rabbit] > [oslo_messaging_zmq] > [oslo_middleware] > [oslo_policy] > [pci] > [placement] > os_region_name = RegionOne > project_domain_name = Default > project_name = service > auth_type = password > user_domain_name = Default > auth_url = http://{{ vip }}:5000/v3 > username = placement > password = {{ placement_pw }} > randomize_allocation_candidates = true > [quota] > [rdp] > [remote_debug] > [scheduler] > discover_hosts_in_cells_interval = 300 > [serial_console] > [service_user] > [spice] > [upgrade_levels] > [vault] > [vendordata_dynamic_auth] > [vmware] > [vnc] > enabled = true > keymap=en-us > novncproxy_base_url = https://{{ vip }}:6080/vnc_auto.html > novncproxy_host = {{ > hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} > [workarounds] > [wsgi] > [xenserver] > [xvp] > [placement_database] > connection=mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_placement > > Thank you > > Best Regards, > Zufar Dhiyaulhaq > > > On Tue, Nov 27, 2018 at 4:55 PM Zufar Dhiyaulhaq < > zufardhiyaulhaq at gmail.com> wrote: > >> Hi Smooney, >> >> thank you for your help. I am trying to enable randomization but not >> working. The instance I have created is still in the same node. Below is my >> nova configuration (added randomization from your suggestion) from the >> master node (Template jinja2 based). >> >> [DEFAULT] >> enabled_apis = osapi_compute,metadata >> transport_url = rabbit://openstack:{{ rabbitmq_pw }}@{{ >> controller1_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ >> controller2_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ >> controller3_ip_man }}:5672 >> my_ip = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4'][ >> 'address'] }} >> use_neutron = True >> firewall_driver = nova.virt.firewall.NoopFirewallDriver >> [api] >> auth_strategy = keystone >> [api_database] >> [barbican] >> [cache] >> backend=oslo_cache.memcache_pool >> enabled=true >> memcache_servers={{ controller1_ip_man }}:11211,{{ controller2_ip_man >> }}:11211,{{ controller3_ip_man }}:11211 >> [cells] >> [cinder] >> [compute] >> [conductor] >> [console] >> [consoleauth] >> [cors] >> [crypto] >> [database] >> [devices] >> [ephemeral_storage_encryption] >> [filter_scheduler] >> [glance] >> api_servers = http://{{ vip }}:9292 >> [guestfs] >> [healthcheck] >> [hyperv] >> [ironic] >> [key_manager] >> [keystone] >> [keystone_authtoken] >> auth_url = http://{{ vip }}:5000/v3 >> memcached_servers = {{ controller1_ip_man }}:11211,{{ controller2_ip_man >> }}:11211,{{ controller3_ip_man }}:11211 >> auth_type = password >> project_domain_name = default >> user_domain_name = default >> project_name = service >> username = nova >> password = {{ nova_pw }} >> [libvirt] >> virt_type = kvm >> [matchmaker_redis] >> [metrics] >> [mks] >> [neutron] >> url = http://{{ vip }}:9696 >> auth_url = http://{{ vip }}:35357 >> auth_type = password >> project_domain_name = default >> user_domain_name = default >> region_name = RegionOne >> project_name = service >> username = neutron >> password = {{ neutron_pw }} >> [notifications] >> [osapi_v21] >> [oslo_concurrency] >> lock_path = /var/lib/nova/tmp >> [oslo_messaging_amqp] >> [oslo_messaging_kafka] >> [oslo_messaging_notifications] >> [oslo_messaging_rabbit] >> [oslo_messaging_zmq] >> [oslo_middleware] >> [oslo_policy] >> [pci] >> [placement] >> os_region_name = RegionOne >> project_domain_name = Default >> project_name = service >> auth_type = password >> user_domain_name = Default >> auth_url = http://{{ vip }}:5000/v3 >> username = placement >> password = {{ placement_pw }} >> [quota] >> [rdp] >> [remote_debug] >> [scheduler] >> [serial_console] >> [service_user] >> [spice] >> [upgrade_levels] >> [vault] >> [vendordata_dynamic_auth] >> [vmware] >> [vnc] >> enabled = True >> keymap=en-us >> server_listen = {{ hostvars[inventory_hostname]['ansible_ens3f1']['ipv4' >> ]['address'] }} >> server_proxyclient_address = {{ hostvars[inventory_hostname][ >> 'ansible_ens3f1']['ipv4']['address'] }} >> novncproxy_base_url = https://{{ vip }}:6080/vnc_auto.html >> [workarounds] >> [wsgi] >> [xenserver] >> [xvp] >> >> Thank you, >> >> Best Regards, >> Zufar Dhiyaulhaq >> >> On Mon, Nov 26, 2018 at 11:13 PM Sean Mooney wrote: >> >>> On Mon, 2018-11-26 at 17:45 +0700, Zufar Dhiyaulhaq wrote: >>> > Hi, >>> > >>> > I am deploying OpenStack with 3 compute node, but I am seeing an >>> abnormal distribution of instance, the instance is >>> > only deployed in a specific compute node, and not distribute among >>> other compute node. >>> > >>> > this is my nova.conf from the compute node. (template jinja2 based) >>> >>> hi, the default behavior of nova used to be spread not pack and i belive >>> it still is. >>> the default behavior with placement however is closer to a packing >>> behavior as >>> allcoation candiates are retrunidn in an undefined but deterministic >>> order. >>> >>> on a busy cloud this does not strictly pack instaces but on a quite >>> cloud it effectivly does >>> >>> you can try and enable randomisation of the allocation candiates by >>> setting this config option in >>> the nova.conf of the shcduler to true. >>> >>> https://docs.openstack.org/nova/latest/configuration/config.html#placement.randomize_allocation_candidates >>> >>> on that note can you provide the nova.conf for the schduelr is used >>> instead of the compute node nova.conf. >>> if you have not overriden any of the nova defaults the ram and cpu >>> weigher should spread instances withing >>> the allocation candiates returned by placement. >>> >>> > >>> > [DEFAULT] >>> > osapi_compute_listen = {{ >>> hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} >>> > metadata_listen = {{ >>> hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} >>> > enabled_apis = osapi_compute,metadata >>> > transport_url = rabbit://openstack:{{ rabbitmq_pw }}@{{ >>> controller1_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ >>> > controller2_ip_man }}:5672,openstack:{{ rabbitmq_pw }}@{{ >>> controller3_ip_man }}:5672 >>> > my_ip = {{ >>> hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} >>> > use_neutron = True >>> > firewall_driver = nova.virt.firewall.NoopFirewallDriver >>> > [api] >>> > auth_strategy = keystone >>> > [api_database] >>> > connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova_api >>> > [barbican] >>> > [cache] >>> > backend=oslo_cache.memcache_pool >>> > enabled=true >>> > memcache_servers={{ controller1_ip_man }}:11211,{{ controller2_ip_man >>> }}:11211,{{ controller3_ip_man }}:11211 >>> > [cells] >>> > [cinder] >>> > os_region_name = RegionOne >>> > [compute] >>> > [conductor] >>> > [console] >>> > [consoleauth] >>> > [cors] >>> > [crypto] >>> > [database] >>> > connection = mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip }}/nova >>> > [devices] >>> > [ephemeral_storage_encryption] >>> > [filter_scheduler] >>> > [glance] >>> > api_servers = http://{{ vip }}:9292 >>> > [guestfs] >>> > [healthcheck] >>> > [hyperv] >>> > [ironic] >>> > [key_manager] >>> > [keystone] >>> > [keystone_authtoken] >>> > auth_url = http://{{ vip }}:5000/v3 >>> > memcached_servers = {{ controller1_ip_man }}:11211,{{ >>> controller2_ip_man }}:11211,{{ controller3_ip_man }}:11211 >>> > auth_type = password >>> > project_domain_name = default >>> > user_domain_name = default >>> > project_name = service >>> > username = nova >>> > password = {{ nova_pw }} >>> > [libvirt] >>> > [matchmaker_redis] >>> > [metrics] >>> > [mks] >>> > [neutron] >>> > url = http://{{ vip }}:9696 >>> > auth_url = http://{{ vip }}:35357 >>> > auth_type = password >>> > project_domain_name = default >>> > user_domain_name = default >>> > region_name = RegionOne >>> > project_name = service >>> > username = neutron >>> > password = {{ neutron_pw }} >>> > service_metadata_proxy = true >>> > metadata_proxy_shared_secret = {{ metadata_secret }} >>> > [notifications] >>> > [osapi_v21] >>> > [oslo_concurrency] >>> > lock_path = /var/lib/nova/tmp >>> > [oslo_messaging_amqp] >>> > [oslo_messaging_kafka] >>> > [oslo_messaging_notifications] >>> > [oslo_messaging_rabbit] >>> > [oslo_messaging_zmq] >>> > [oslo_middleware] >>> > [oslo_policy] >>> > [pci] >>> > [placement] >>> > os_region_name = RegionOne >>> > project_domain_name = Default >>> > project_name = service >>> > auth_type = password >>> > user_domain_name = Default >>> > auth_url = http://{{ vip }}:5000/v3 >>> > username = placement >>> > password = {{ placement_pw }} >>> > [quota] >>> > [rdp] >>> > [remote_debug] >>> > [scheduler] >>> > discover_hosts_in_cells_interval = 300 >>> > [serial_console] >>> > [service_user] >>> > [spice] >>> > [upgrade_levels] >>> > [vault] >>> > [vendordata_dynamic_auth] >>> > [vmware] >>> > [vnc] >>> > enabled = true >>> > keymap=en-us >>> > novncproxy_base_url = https://{{ vip }}:6080/vnc_auto.html >>> > novncproxy_host = {{ >>> hostvars[inventory_hostname]['ansible_ens3f1']['ipv4']['address'] }} >>> > [workarounds] >>> > [wsgi] >>> > [xenserver] >>> > [xvp] >>> > [placement_database] >>> > connection=mysql+pymysql://nova:{{ nova_dbpw }}@{{ vip >>> }}/nova_placement >>> > >>> > what is the problem? I have lookup the openstack-nova-scheduler in the >>> controller node but it's running well with only >>> > warning >>> > >>> > nova-scheduler[19255]: >>> /usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py:332: >>> NotSupportedWarning: >>> > Configuration option(s) ['use_tpool'] not supported >>> > >>> > the result I want is the instance is distributed in all compute node. >>> > Thank you. >>> > >>> > _______________________________________________ >>> > Mailing list: >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>> > Post to : openstack at lists.openstack.org >>> > Unsubscribe : >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From jtomasek at redhat.com Wed Nov 28 10:11:12 2018 From: jtomasek at redhat.com (Jiri Tomasek) Date: Wed, 28 Nov 2018 11:11:12 +0100 Subject: [openstack-dev] [tripleo] Workflows Squad changes Message-ID: Hi all, Recently, the workflows squad has been reorganized and people from the squad are joining different squads. I would like to discuss how we are going to adjust to this situation to make sure that tripleo-common development is not going to be blocked in terms of feature work and reviews. With this change, most of the tripleo-common maintenance work goes naturally to UI & Validations squad as CLI and GUI are the consumers of the API provided by tripleo-common. Adriano Petrich from workflows squad has joined UI squad to take on this work. As a possible solution, I would like to propose Adriano as a core reviewer to tripleo-common and adding tripleo-ui cores right to +2 tripleo-common patches. It would be great to hear opinions especially former members of Workflows squad and regular contributors to tripleo-common on these changes and in general on how to establish regular reviews and maintenance to ensure that tripleo-common codebase is moved towards converging the CLI and GUI deployment workflow. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From ignaziocassano at gmail.com Wed Nov 28 10:19:53 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Wed, 28 Nov 2018 11:19:53 +0100 Subject: [Openstack-operators] Fwd: Nova hypervisor uuid In-Reply-To: References: <63283d3b-0661-7620-aaea-8ffbe9e483d8@gmail.com> Message-ID: Hi Matt, sorry but I lost your answer and Gianpiero forwarded it to me. I am sure kvm nodes names are note changed. Tables where uuid are duplicated are: dataresource_providers in nova_api db compute_nodes in nova db Regards Ignazio Il 28/Nov/2018 11:09 AM, "Gianpiero Ardissono" ha scritto: > > ---------- Forwarded message --------- > From: Matt Riedemann > Date: mar 27 nov 2018, 19:03 > Subject: Re: [Openstack-operators] Nova hypervisor uuid > To: > > > On 11/27/2018 11:32 AM, Ignazio Cassano wrote: > > Hi All, > > Please anyone know where hypervisor uuid is retrived? > > Sometime updating kmv nodes with yum update it changes and in nova > > database 2 uuids are assigned to the same node. > > regards > > Ignazio > > > > > > > > > > _______________________________________________ > > OpenStack-operators mailing list > > OpenStack-operators at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > To be clear, do you mean the computes_nodes.uuid column value in the > cell database? Which is also used for the GET /os-hypervisors response > 'id' value if using microversion >= 2.53. If so, that is generated > randomly* when the compute_nodes table record is created: > > > https://github.com/openstack/nova/blob/8545ba2af7476e0884b5e7fb90965bef92d605bc/nova/compute/resource_tracker.py#L588 > > > https://github.com/openstack/nova/blob/8545ba2af7476e0884b5e7fb90965bef92d605bc/nova/objects/compute_node.py#L312 > > When you hit this problem, are you sure the hostname on the compute host > is not changing? Because when nova-compute starts up, it should look for > the existing compute node record by host name and node name, which for > the libvirt driver should be the same. That lookup code is here: > > > https://github.com/openstack/nova/blob/8545ba2af7476e0884b5e7fb90965bef92d605bc/nova/compute/resource_tracker.py#L815 > > So the only way nova-compute should create a new compute_nodes table > record for the same host is if the host/node name changes during the > upgrade. Is the deleted value in the database the same (0) for both of > those records? > > * The exception to this is for the ironic driver which re-uses the > ironic node uuid as of this change: > https://review.openstack.org/#/c/571535/ > > -- > > Thanks, > > Matt > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From dprince at redhat.com Wed Nov 28 13:31:52 2018 From: dprince at redhat.com (Dan Prince) Date: Wed, 28 Nov 2018 08:31:52 -0500 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <1A3C52DFCD06494D8528644858247BF01C248BF7@EX10MBOX03.pnnl.gov> References: <9dee4044-2744-3ab6-3a15-bd79702ff35a@redhat.com> , <089336b7a431cab76e1350a959b7bb566175134b.camel@redhat.com> <1A3C52DFCD06494D8528644858247BF01C248BF7@EX10MBOX03.pnnl.gov> Message-ID: <7364ab27a3f50e40a44c2af4305bde97816944fd.camel@redhat.com> On Wed, 2018-11-28 at 00:31 +0000, Fox, Kevin M wrote: > The pod concept allows you to have one tool per container do one > thing and do it well. > > You can have a container for generating config, and another container > for consuming it. > > In a Kubernetes pod, if you still wanted to do puppet, > you could have a pod that: > 1. had an init container that ran puppet and dumped the resulting > config to an emptyDir volume. > 2. had your main container pull its config from the emptyDir volume. We have basically implemented the same workflow in TripleO today. First we execute Puppet in an "init container" (really just an ephemeral container that generates the config files and then goes away). Then we bind mount those configs into the service container. One improvement we could make (which we aren't doing yet) is to use a data container/volume to store the config files instead of using the host. Sharing *data* within a 'pod' (set of containers, etc.) is certainly a valid use of container volumes. None of this is what we are really talking about in this thread though. Most of the suggestions and patches are about making our base container(s) smaller in size. And the means by which the patches do that is to share binaries/applications across containers with custom mounts/volumes. I don't think it is a good idea at all as it violates encapsulation of the containers in general, regardless of whether we use pods or not. Dan > > Then each container would have no dependency on each other. > > In full blown Kubernetes cluster you might have puppet generate a > configmap though and ship it to your main container directly. Thats > another matter though. I think the example pod example above is still > usable without k8s? > > Thanks, > Kevin > ________________________________________ > From: Dan Prince [dprince at redhat.com] > Sent: Tuesday, November 27, 2018 10:10 AM > To: OpenStack Development Mailing List (not for usage questions); > openstack-discuss at lists.openstack.org > Subject: Re: [openstack-dev] [TripleO][Edge] Reduce base layer of > containers for security and size of images (maintenance) sakes > > On Tue, 2018-11-27 at 16:24 +0100, Bogdan Dobrelya wrote: > > Changing the topic to follow the subject. > > > > [tl;dr] it's time to rearchitect container images to stop > > incluiding > > config-time only (puppet et al) bits, which are not needed runtime > > and > > pose security issues, like CVEs, to maintain daily. > > I think your assertion that we need to rearchitect the config images > to > container the puppet bits is incorrect here. > > After reviewing the patches you linked to below it appears that you > are > proposing we use --volumes-from to bind mount application binaries > from > one container into another. I don't believe this is a good pattern > for > containers. On baremetal if we followed the same pattern it would be > like using an /nfs share to obtain access to binaries across the > network to optimize local storage. Now... some people do this (like > maybe high performance computing would launch an MPI job like this) > but > I don't think we should consider it best practice for our containers > in > TripleO. > > Each container should container its own binaries and libraries as > much > as possible. And while I do think we should be using --volumes-from > more often in TripleO it would be for sharing *data* between > containers, not binaries. > > > > Background: > > 1) For the Distributed Compute Node edge case, there is potentially > > tens > > of thousands of a single-compute-node remote edge sites connected > > over > > WAN to a single control plane, which is having high latency, like a > > 100ms or so, and limited bandwith. Reducing the base layer size > > becomes > > a decent goal there. See the security background below. > > The reason we put Puppet into the base layer was in fact to prevent > it > from being downloaded multiple times. If we were to re-architect the > image layers such that the child layers all contained their own > copies > of Puppet for example there would actually be a net increase in > bandwidth and disk usage. So I would argue we are already addressing > the goal of optimizing network and disk space. > > Moving it out of the base layer so that you can patch it more often > without disrupting other services is a valid concern. But addressing > this concern while also preserving our definiation of a container > (see > above, a container should contain all of its binaries) is going to > cost > you something, namely disk and network space because Puppet would > need > to be duplicated in each child container. > > As Puppet is used to configure a majority of the services in TripleO > having it in the base container makes most sense. And yes, if there > are > security patches for Puppet/Ruby those might result in a bunch of > containers getting pushed. But let Docker layers take care of this I > think... Don't try to solve things by constructing your own custom > mounts and volumes to work around the issue. > > > > 2) For a generic security (Day 2, maintenance) case, when > > puppet/ruby/systemd/name-it gets a CVE fixed, the base layer has to > > be > > updated and all layers on top - to be rebuild, and all of those > > layers, > > to be re-fetched for cloud hosts and all containers to be > > restarted... > > And all of that because of some fixes that have nothing to > > OpenStack. > > By > > the remote edge sites as well, remember of "tens of thousands", > > high > > latency and limited bandwith?.. > > 3) TripleO CI updates (including puppet*) packages in containers, > > not > > in > > a common base layer of those. So each a CI job has to update > > puppet* > > and > > its dependencies - ruby/systemd as well. Reducing numbers of > > packages > > to > > update for each container makes sense for CI as well. > > > > Implementation related: > > > > WIP patches [0],[1] for early review, uses a config "pod" approach, > > does > > not require to maintain a two sets of config vs runtime images. > > Future > > work: a) cronie requires systemd, we'd want to fix that also off > > the > > base layer. b) rework to podman pods for docker-puppet.py instead > > of > > --volumes-from a side car container (can't be backported for Queens > > then, which is still nice to have a support for the Edge DCN case, > > at > > least downstream only perhaps). > > > > Some questions raised on IRC: > > > > Q: is having a service be able to configure itself really need to > > involve a separate pod? > > A: Highly likely yes, removing not-runtime things is a good idea > > and > > pods is an established PaaS paradigm already. That will require > > some > > changes in the architecture though (see the topic with WIP > > patches). > > I'm a little confused on this one. Are you suggesting that we have 2 > containers for each service? One with Puppet and one without? > > That is certainly possible, but to pull it off would likely require > you > to have things built like this: > > |base container| --> |service container| --> |service container w/ > Puppet installed| > > The end result would be Puppet being duplicated in a layer for each > services "config image". Very inefficient. > > Again, I'm ansering this assumping we aren't violating our container > constraints and best practices where each container has the binaries > its needs to do its own configuration. > > > Q: that's (fetching a config container) actually more data that > > about to > > download otherwise > > A: It's not, if thinking of Day 2, when have to re-fetch the base > > layer > > and top layers, when some unrelated to openstack CVEs got fixed > > there > > for ruby/puppet/systemd. Avoid the need to restart service > > containers > > because of those minor updates puched is also a nice thing. > > Puppet is used only for configuration in TripleO. While security > issues > do need to be addressed at any layer I'm not sure there would be an > urgency to re-deploy your cluster simply for a Puppet security fix > alone. Smart change management would help eliminate blindly deploying > new containers in the case where they provide very little security > benefit. > > I think the focus on Puppet, and Ruby here is perhaps a bad example > as > they are config time only. Rather than just think about them we > should > also consider the rest of the things in our base container images as > well. This is always going to be a "balancing act". There are pros > and > cons of having things in the base layer vs. the child/leaf layers. > > > > Q: the best solution here would be using packages on the host, > > generating the config files on the host. And then having an all-in- > > one > > container for all the services which lets them run in an isolated > > mannner. > > A: I think for Edge cases, that's a no go as we might want to > > consider > > tiny low footprint OS distros like former known Container Linux or > > Atomic. Also, an all-in-one container looks like an anti-pattern > > from > > the world of VMs. > > This was suggested on IRC because it likely gives you the smallest > network/storage footprint for each edge node. The container would get > used for everything: running all the services, and configuring all > the > services. Sort of a golden image approach. It may be an anti-pattern > but initially I thought you were looking to optimize these things. > > I think a better solution might be to have container registries, or > container mirrors (reverse proxies or whatever) that allow you to > cache > things as you deploy to the edge and thus optimize the network > traffic. > > > > [0] https://review.openstack.org/#/q/topic:base-container-reduction > > [1] > > https://review.rdoproject.org/r/#/q/topic:base-container-reduction > > > > > Here is a related bug [1] and implementation [1] for that. PTAL > > > folks! > > > > > > [0] https://bugs.launchpad.net/tripleo/+bug/1804822 > > > [1] > > > https://review.openstack.org/#/q/topic:base-container-reduction > > > > > > > Let's also think of removing puppet-tripleo from the base > > > > container. > > > > It really brings the world-in (and yum updates in CI!) each job > > > > and each > > > > container! > > > > So if we did so, we should then either install puppet-tripleo > > > > and > > > > co on > > > > the host and bind-mount it for the docker-puppet deployment > > > > task > > > > steps > > > > (bad idea IMO), OR use the magical --volumes-from > > > container> > > > > option to mount volumes from some "puppet-config" sidecar > > > > container > > > > inside each of the containers being launched by docker-puppet > > > > tooling. > > > > > > On Wed, Oct 31, 2018 at 11:16 AM Harald Jensås > > redhat.com> > > > wrote: > > > > We add this to all images: > > > > > > > > https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646e535cf972c98ef/container-images/tripleo_kolla_template_overrides.j2#L35 > > > > > > > > /bin/sh -c yum -y install iproute iscsi-initiator-utils lvm2 > > > > python > > > > socat sudo which openstack-tripleo-common-container-base rsync > > > > cronie > > > > crudini openstack-selinux ansible python-shade puppet-tripleo > > > > python2- > > > > kubernetes && yum clean all && rm -rf /var/cache/yum 276 MB > > > > > > > > Is the additional 276 MB reasonable here? > > > > openstack-selinux <- This package run relabling, does that kind > > > > of > > > > touching the filesystem impact the size due to docker layers? > > > > > > > > Also: python2-kubernetes is a fairly large package (18007990) > > > > do > > > > we use > > > > that in every image? I don't see any tripleo related repos > > > > importing > > > > from that when searching on Hound? The original commit > > > > message[1] > > > > adding it states it is for future convenience. > > > > > > > > On my undercloud we have 101 images, if we are downloading > > > > every > > > > 18 MB > > > > per image thats almost 1.8 GB for a package we don't use? (I > > > > hope > > > > it's > > > > not like this? With docker layers, we only download that 276 MB > > > > transaction once? Or?) > > > > > > > > > > > > [1] https://review.openstack.org/527927 > > > > > > -- > > > Best regards, > > > Bogdan Dobrelya, > > > Irc #bogdando > > _____________________________________________________________________ > _____ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From bdobreli at redhat.com Wed Nov 28 13:56:55 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Wed, 28 Nov 2018 14:56:55 +0100 Subject: [TripleO][Edge][Kolla] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> Message-ID: <9b2836a5-18e3-f94d-88e4-16e9f4762f71@redhat.com> Added Kolla tag as we all together might want to do something to that systemd included in containers via *multiple* package dependencies, like [0]. Ideally, that might be properly packaging all/some (like those names listed in [1]) of the places having it as a dependency, to stop doing that as of now it's Containers Time?.. As a temporary security band-aiding I was thinking of removing systemd via footers [1] as an extra layer added on top, but not sure that buys something good long-term. [0] https://pastebin.com/RSaRsYgZ [1] https://review.openstack.org/#/c/620310/2/container-images/tripleo_kolla_template_overrides.j2 at 680 On 11/28/18 12:45 PM, Bogdan Dobrelya wrote: > To follow up and explain the patches for code review: > > The "header" patch https://review.openstack.org/620310 -> (requires) > https://review.rdoproject.org/r/#/c/17534/, and also > https://review.openstack.org/620061 -> (which in turn requires) > https://review.openstack.org/619744 -> (Kolla change, the 1st to go) > https://review.openstack.org/619736 > > Please also read the commit messages, I tried to explain all "Whys" very > carefully. Just to sum up it here as well: > > The current self-containing (config and runtime bits) architecture of > containers badly affects: > > * the size of the base layer and all containers images as an >   additional 300MB (adds an extra 30% of size). > * Edge cases, where we have containers images to be distributed, at >   least once to hit local registries, over high-latency and limited >   bandwith, highly unreliable WAN connections. > * numbers of packages to update in CI for all containers for all >   services (CI jobs do not rebuild containers so each container gets >   updated for those 300MB of extra size). > * security and the surface of attacks, by introducing systemd et al as >   additional subjects for CVE fixes to maintain for all containers. > * services uptime, by additional restarts of services related to >   security maintanence of irrelevant to openstack components sitting >   as a dead weight in containers images for ever. > > On 11/27/18 4:08 PM, Bogdan Dobrelya wrote: >> Changing the topic to follow the subject. >> >> [tl;dr] it's time to rearchitect container images to stop incluiding >> config-time only (puppet et al) bits, which are not needed runtime and >> pose security issues, like CVEs, to maintain daily. >> >> Background: 1) For the Distributed Compute Node edge case, there is >> potentially tens of thousands of a single-compute-node remote edge >> sites connected over WAN to a single control plane, which is having >> high latency, like a 100ms or so, and limited bandwith. >> 2) For a generic security case, >> 3) TripleO CI updates all >> >> Challenge: >> >>> Here is a related bug [1] and implementation [1] for that. PTAL folks! >>> >>> [0] https://bugs.launchpad.net/tripleo/+bug/1804822 >>> [1] https://review.openstack.org/#/q/topic:base-container-reduction >>> >>>> Let's also think of removing puppet-tripleo from the base container. >>>> It really brings the world-in (and yum updates in CI!) each job and >>>> each container! >>>> So if we did so, we should then either install puppet-tripleo and co >>>> on the host and bind-mount it for the docker-puppet deployment task >>>> steps (bad idea IMO), OR use the magical --volumes-from >>>> option to mount volumes from some >>>> "puppet-config" sidecar container inside each of the containers >>>> being launched by docker-puppet tooling. >>> >>> On Wed, Oct 31, 2018 at 11:16 AM Harald Jensås >> redhat.com> wrote: >>>> We add this to all images: >>>> >>>> https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646e535cf972c98ef/container-images/tripleo_kolla_template_overrides.j2#L35 >>>> >>>> >>>> /bin/sh -c yum -y install iproute iscsi-initiator-utils lvm2 python >>>> socat sudo which openstack-tripleo-common-container-base rsync cronie >>>> crudini openstack-selinux ansible python-shade puppet-tripleo python2- >>>> kubernetes && yum clean all && rm -rf /var/cache/yum 276 MB >>>> Is the additional 276 MB reasonable here? >>>> openstack-selinux <- This package run relabling, does that kind of >>>> touching the filesystem impact the size due to docker layers? >>>> >>>> Also: python2-kubernetes is a fairly large package (18007990) do we use >>>> that in every image? I don't see any tripleo related repos importing >>>> from that when searching on Hound? The original commit message[1] >>>> adding it states it is for future convenience. >>>> >>>> On my undercloud we have 101 images, if we are downloading every 18 MB >>>> per image thats almost 1.8 GB for a package we don't use? (I hope it's >>>> not like this? With docker layers, we only download that 276 MB >>>> transaction once? Or?) >>>> >>>> >>>> [1] https://review.openstack.org/527927 >>> >>> >>> >>> -- >>> Best regards, >>> Bogdan Dobrelya, >>> Irc #bogdando >> >> > > -- Best regards, Bogdan Dobrelya, Irc #bogdando From dprince at redhat.com Wed Nov 28 13:58:45 2018 From: dprince at redhat.com (Dan Prince) Date: Wed, 28 Nov 2018 08:58:45 -0500 Subject: [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> Message-ID: <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> On Wed, 2018-11-28 at 12:45 +0100, Bogdan Dobrelya wrote: > To follow up and explain the patches for code review: > > The "header" patch https://review.openstack.org/620310 -> (requires) > https://review.rdoproject.org/r/#/c/17534/, and also > https://review.openstack.org/620061 -> (which in turn requires) > https://review.openstack.org/619744 -> (Kolla change, the 1st to go) > https://review.openstack.org/619736 This email was cross-posted to multiple lists and I think we may have lost some of the context in the process as the subject was changed. Most of the suggestions and patches are about making our base container(s) smaller in size. And the means by which the patches do that is to share binaries/applications across containers with custom mounts/volumes. I've -2'd most of them. What concerns me however is that some of the TripleO cores seemed open to this idea yesterday on IRC. Perhaps I've misread things but what you appear to be doing here is quite drastic I think we need to consider any of this carefully before proceeding with any of it. > > Please also read the commit messages, I tried to explain all "Whys" > very > carefully. Just to sum up it here as well: > > The current self-containing (config and runtime bits) architecture > of > containers badly affects: > > * the size of the base layer and all containers images as an > additional 300MB (adds an extra 30% of size). You are accomplishing this by removing Puppet from the base container, but you are also creating another container in the process. This would still be required on all nodes as Puppet is our config tool. So you would still be downloading some of this data anyways. Understood your reasons for doing this are that it avoids rebuilding all containers when there is a change to any of these packages in the base container. What you are missing however is how often is it the case that Puppet is updated that something else in the base container isn't? I would wager that it is more rare than you'd think. Perhaps looking at the history of an OpenStack distribution would be a valid way to assess this more critically. Without this data to backup the numbers I'm afraid what you are doing here falls into "pre-optimization" territory for me and I don't think the means used in the patches warrent the benefits you mention here. > * Edge cases, where we have containers images to be distributed, at > least once to hit local registries, over high-latency and limited > bandwith, highly unreliable WAN connections. > * numbers of packages to update in CI for all containers for all > services (CI jobs do not rebuild containers so each container gets > updated for those 300MB of extra size). It would seem to me there are other ways to solve the CI containers update problems. Rebuilding the base layer more often would solve this right? If we always build our service containers off of a base layer that is recent there should be no updates to the system/puppet packages there in our CI pipelines. > * security and the surface of attacks, by introducing systemd et al > as > additional subjects for CVE fixes to maintain for all containers. We aren't actually using systemd within our containers. I think those packages are getting pulled in by an RPM dependency elsewhere. So rather than using 'rpm -ev --nodeps' to remove it we could create a sub-package for containers in those cases and install it instead. In short rather than hack this to remove them why not pursue a proper packaging fix? In general I am a fan of getting things out of the base container we don't need... so yeah lets do this. But lets do it properly. > * services uptime, by additional restarts of services related to > security maintanence of irrelevant to openstack components sitting > as a dead weight in containers images for ever. Like I said above how often is it that these packages actually change where something else in the base container doesn't? Perhaps we should get more data here before blindly implementing a solution we aren't sure really helps out in the real world. > > On 11/27/18 4:08 PM, Bogdan Dobrelya wrote: > > Changing the topic to follow the subject. > > > > [tl;dr] it's time to rearchitect container images to stop > > incluiding > > config-time only (puppet et al) bits, which are not needed runtime > > and > > pose security issues, like CVEs, to maintain daily. > > > > Background: 1) For the Distributed Compute Node edge case, there > > is > > potentially tens of thousands of a single-compute-node remote edge > > sites > > connected over WAN to a single control plane, which is having high > > latency, like a 100ms or so, and limited bandwith. > > 2) For a generic security case, > > 3) TripleO CI updates all > > > > Challenge: > > > > > Here is a related bug [1] and implementation [1] for that. PTAL > > > folks! > > > > > > [0] https://bugs.launchpad.net/tripleo/+bug/1804822 > > > [1] > > > https://review.openstack.org/#/q/topic:base-container-reduction > > > > > > > Let's also think of removing puppet-tripleo from the base > > > > container. > > > > It really brings the world-in (and yum updates in CI!) each job > > > > and > > > > each container! > > > > So if we did so, we should then either install puppet-tripleo > > > > and co > > > > on the host and bind-mount it for the docker-puppet deployment > > > > task > > > > steps (bad idea IMO), OR use the magical --volumes-from > > > > option to mount volumes from some > > > > "puppet-config" sidecar container inside each of the containers > > > > being > > > > launched by docker-puppet tooling. > > > > > > On Wed, Oct 31, 2018 at 11:16 AM Harald Jensås > > redhat.com> > > > wrote: > > > > We add this to all images: > > > > > > > > https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646e535cf972c98ef/container-images/tripleo_kolla_template_overrides.j2#L35 > > > > > > > > > > > > /bin/sh -c yum -y install iproute iscsi-initiator-utils lvm2 > > > > python > > > > socat sudo which openstack-tripleo-common-container-base rsync > > > > cronie > > > > crudini openstack-selinux ansible python-shade puppet-tripleo > > > > python2- > > > > kubernetes && yum clean all && rm -rf /var/cache/yum 276 MB > > > > Is the additional 276 MB reasonable here? > > > > openstack-selinux <- This package run relabling, does that kind > > > > of > > > > touching the filesystem impact the size due to docker layers? > > > > > > > > Also: python2-kubernetes is a fairly large package (18007990) > > > > do we use > > > > that in every image? I don't see any tripleo related repos > > > > importing > > > > from that when searching on Hound? The original commit > > > > message[1] > > > > adding it states it is for future convenience. > > > > > > > > On my undercloud we have 101 images, if we are downloading > > > > every 18 MB > > > > per image thats almost 1.8 GB for a package we don't use? (I > > > > hope it's > > > > not like this? With docker layers, we only download that 276 MB > > > > transaction once? Or?) > > > > > > > > > > > > [1] https://review.openstack.org/527927 > > > > > > > > > -- > > > Best regards, > > > Bogdan Dobrelya, > > > Irc #bogdando > > From bdobreli at redhat.com Wed Nov 28 14:12:08 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Wed, 28 Nov 2018 15:12:08 +0100 Subject: [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> Message-ID: <4121346a-7341-184f-2dcb-32092409196b@redhat.com> On 11/28/18 2:58 PM, Dan Prince wrote: > On Wed, 2018-11-28 at 12:45 +0100, Bogdan Dobrelya wrote: >> To follow up and explain the patches for code review: >> >> The "header" patch https://review.openstack.org/620310 -> (requires) >> https://review.rdoproject.org/r/#/c/17534/, and also >> https://review.openstack.org/620061 -> (which in turn requires) >> https://review.openstack.org/619744 -> (Kolla change, the 1st to go) >> https://review.openstack.org/619736 > > This email was cross-posted to multiple lists and I think we may have > lost some of the context in the process as the subject was changed. > > Most of the suggestions and patches are about making our base > container(s) smaller in size. And the means by which the patches do > that is to share binaries/applications across containers with custom > mounts/volumes. I've -2'd most of them. What concerns me however is > that some of the TripleO cores seemed open to this idea yesterday on > IRC. Perhaps I've misread things but what you appear to be doing here > is quite drastic I think we need to consider any of this carefully > before proceeding with any of it. > > >> >> Please also read the commit messages, I tried to explain all "Whys" >> very >> carefully. Just to sum up it here as well: >> >> The current self-containing (config and runtime bits) architecture >> of >> containers badly affects: >> >> * the size of the base layer and all containers images as an >> additional 300MB (adds an extra 30% of size). > > You are accomplishing this by removing Puppet from the base container, > but you are also creating another container in the process. This would > still be required on all nodes as Puppet is our config tool. So you > would still be downloading some of this data anyways. Understood your > reasons for doing this are that it avoids rebuilding all containers > when there is a change to any of these packages in the base container. > What you are missing however is how often is it the case that Puppet is > updated that something else in the base container isn't? For CI jobs updating all containers, its quite an often to have changes in openstack/tripleo puppet modules to pull in. IIUC, that automatically picks up any updates for all of its dependencies and for the dependencies of dependencies, and all that multiplied by a hundred of total containers to get it updated. That is a *pain* we're used to have these day for quite often timing out CI jobs... Ofc, the main cause is delayed promotions though. For real deployments, I have no data for the cadence of minor updates in puppet and tripleo & openstack modules for it, let's ask operators (as we're happened to be in the merged openstack-discuss list)? For its dependencies though, like systemd and ruby, I'm pretty sure it's quite often to have CVEs fixed there. So I expect what "in the fields" security fixes delivering for those might bring some unwanted hassle for long-term maintenance of LTS releases. As Tengu noted on IRC: "well, between systemd, puppet and ruby, there are many security concernes, almost every month... and also, what's the point keeping them in runtime containers when they are useless?" > > I would wager that it is more rare than you'd think. Perhaps looking at > the history of an OpenStack distribution would be a valid way to assess > this more critically. Without this data to backup the numbers I'm > afraid what you are doing here falls into "pre-optimization" territory > for me and I don't think the means used in the patches warrent the > benefits you mention here. > > >> * Edge cases, where we have containers images to be distributed, at >> least once to hit local registries, over high-latency and limited >> bandwith, highly unreliable WAN connections. >> * numbers of packages to update in CI for all containers for all >> services (CI jobs do not rebuild containers so each container gets >> updated for those 300MB of extra size). > > It would seem to me there are other ways to solve the CI containers > update problems. Rebuilding the base layer more often would solve this > right? If we always build our service containers off of a base layer > that is recent there should be no updates to the system/puppet packages > there in our CI pipelines. > >> * security and the surface of attacks, by introducing systemd et al >> as >> additional subjects for CVE fixes to maintain for all containers. > > We aren't actually using systemd within our containers. I think those > packages are getting pulled in by an RPM dependency elsewhere. So > rather than using 'rpm -ev --nodeps' to remove it we could create a > sub-package for containers in those cases and install it instead. In > short rather than hack this to remove them why not pursue a proper > packaging fix? > > In general I am a fan of getting things out of the base container we > don't need... so yeah lets do this. But lets do it properly. > >> * services uptime, by additional restarts of services related to >> security maintanence of irrelevant to openstack components sitting >> as a dead weight in containers images for ever. > > Like I said above how often is it that these packages actually change > where something else in the base container doesn't? Perhaps we should > get more data here before blindly implementing a solution we aren't > sure really helps out in the real world. > >> >> On 11/27/18 4:08 PM, Bogdan Dobrelya wrote: >>> Changing the topic to follow the subject. >>> >>> [tl;dr] it's time to rearchitect container images to stop >>> incluiding >>> config-time only (puppet et al) bits, which are not needed runtime >>> and >>> pose security issues, like CVEs, to maintain daily. >>> >>> Background: 1) For the Distributed Compute Node edge case, there >>> is >>> potentially tens of thousands of a single-compute-node remote edge >>> sites >>> connected over WAN to a single control plane, which is having high >>> latency, like a 100ms or so, and limited bandwith. >>> 2) For a generic security case, >>> 3) TripleO CI updates all >>> >>> Challenge: >>> >>>> Here is a related bug [1] and implementation [1] for that. PTAL >>>> folks! >>>> >>>> [0] https://bugs.launchpad.net/tripleo/+bug/1804822 >>>> [1] >>>> https://review.openstack.org/#/q/topic:base-container-reduction >>>> >>>>> Let's also think of removing puppet-tripleo from the base >>>>> container. >>>>> It really brings the world-in (and yum updates in CI!) each job >>>>> and >>>>> each container! >>>>> So if we did so, we should then either install puppet-tripleo >>>>> and co >>>>> on the host and bind-mount it for the docker-puppet deployment >>>>> task >>>>> steps (bad idea IMO), OR use the magical --volumes-from >>>>> option to mount volumes from some >>>>> "puppet-config" sidecar container inside each of the containers >>>>> being >>>>> launched by docker-puppet tooling. >>>> >>>> On Wed, Oct 31, 2018 at 11:16 AM Harald Jensås >>> redhat.com> >>>> wrote: >>>>> We add this to all images: >>>>> >>>>> https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646e535cf972c98ef/container-images/tripleo_kolla_template_overrides.j2#L35 >>>>> >>>>> >>>>> /bin/sh -c yum -y install iproute iscsi-initiator-utils lvm2 >>>>> python >>>>> socat sudo which openstack-tripleo-common-container-base rsync >>>>> cronie >>>>> crudini openstack-selinux ansible python-shade puppet-tripleo >>>>> python2- >>>>> kubernetes && yum clean all && rm -rf /var/cache/yum 276 MB >>>>> Is the additional 276 MB reasonable here? >>>>> openstack-selinux <- This package run relabling, does that kind >>>>> of >>>>> touching the filesystem impact the size due to docker layers? >>>>> >>>>> Also: python2-kubernetes is a fairly large package (18007990) >>>>> do we use >>>>> that in every image? I don't see any tripleo related repos >>>>> importing >>>>> from that when searching on Hound? The original commit >>>>> message[1] >>>>> adding it states it is for future convenience. >>>>> >>>>> On my undercloud we have 101 images, if we are downloading >>>>> every 18 MB >>>>> per image thats almost 1.8 GB for a package we don't use? (I >>>>> hope it's >>>>> not like this? With docker layers, we only download that 276 MB >>>>> transaction once? Or?) >>>>> >>>>> >>>>> [1] https://review.openstack.org/527927 >>>> >>>> >>>> -- >>>> Best regards, >>>> Bogdan Dobrelya, >>>> Irc #bogdando >> >> > -- Best regards, Bogdan Dobrelya, Irc #bogdando From soheil.ir08 at gmail.com Wed Nov 28 12:26:21 2018 From: soheil.ir08 at gmail.com (Soheil Pourbafrani) Date: Wed, 28 Nov 2018 15:56:21 +0330 Subject: [Openstack] [OpenStack][cinder]Does cinder allocate disk to the volumes dynamically? Message-ID: Hi, I was wondering if the Cinder allocates disk to volumes statically or dynamically? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From nickeysgo at gmail.com Wed Nov 28 12:37:02 2018 From: nickeysgo at gmail.com (Minjun Hong) Date: Wed, 28 Nov 2018 21:37:02 +0900 Subject: [Openstack] [Nova] Instance creation problem Message-ID: Hi. I'm setting up a Openstack system on the servers of my laboratory. While I try to create an instance, a problem has occurred! Instance creation was failed and it seems that libvirt failed to attaching the vif to the instance. When I create a virtual machine by using virsh tool (libvirt) manually, there was no problem. I add the logs as follows: 1. controller node > "/var/log/nova/nova-conductor.log" > 2018-11-28 21:18:13.033 2657 ERROR nova.scheduler.utils > [req-291fdb2d-fa94-461c-9f5f-68d340791c77 3367829d9c004653bdc9102443bd4736 > 47270e4fb58045dc88b6f0f736286ffc - default default] [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] Error from last host: node1 (node > node1): [u'Traceback (most recent call last):\n', u' File > "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1840, in > _do_build_and_run_instance\n filter_properties, request_spec)\n', u' > File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2120, > in _build_and_run_instance\n instance_uuid=instance.uuid, > reason=six.text_type(e))\n', u"RescheduledException: Build of instance > 9c2d08f3-0680-4709-a64d-ae1729a11304 was re-scheduled: internal error: > libxenlight failed to create new domain 'instance-00000008'\n"] > 2018-11-28 21:18:13.033 2657 WARNING nova.scheduler.utils > [req-291fdb2d-fa94-461c-9f5f-68d340791c77 3367829d9c004653bdc9102443bd4736 > 47270e4fb58045dc88b6f0f736286ffc - default default] Failed to > compute_task_build_instances: Exceeded maximum number of retries. Exceeded > max scheduling attempts 3 for instance > 9c2d08f3-0680-4709-a64d-ae1729a11304. Last exception: internal error: > libxenlight failed to create new domain 'instance-00000008': > MaxRetriesExceeded: Exceeded maximum number of retries. Exceeded max > scheduling attempts 3 for instance 9c2d08f3-0680-4709-a64d-ae1729a11304. > Last exception: internal error: libxenlight failed to create new domain > 'instance-00000008' > 2018-11-28 21:18:13.034 2657 WARNING nova.scheduler.utils > [req-291fdb2d-fa94-461c-9f5f-68d340791c77 3367829d9c004653bdc9102443bd4736 > 47270e4fb58045dc88b6f0f736286ffc - default default] [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] Setting instance to ERROR state.: > MaxRetriesExceeded: Exceeded maximum number of retries. Exceeded max > scheduling attempts 3 for instance 9c2d08f3-0680-4709-a64d-ae1729a11304. > Last exception: internal error: libxenlight failed to create new domain > 'instance-00000008' > 2018-11-28 21:18:13.067 2657 WARNING oslo_config.cfg > [req-291fdb2d-fa94-461c-9f5f-68d340791c77 3367829d9c004653bdc9102443bd4736 > 47270e4fb58045dc88b6f0f736286ffc - default default] Option "url" from group > "neutron" is deprecated for removal (Endpoint lookup uses the service > catalog via common keystoneauth1 Adapter configuration options. In the > current release, "url" will override this behavior, but will be ignored > and/or removed in a future release. To achieve the same result, use the > endpoint_override option instead.). Its value may be silently ignored in > the future. > "/var/log/neutron/neutron-linuxbridge-agent.log" > 2018-11-28 17:41:45.593 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] > Interface mappings: {'provider': 'enp1s0f1'} > 2018-11-28 17:41:45.593 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] > Bridge mappings: {} > 2018-11-28 17:41:45.624 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] > Agent initialized successfully, now running... > 2018-11-28 17:41:45.901 2476 INFO > neutron.plugins.ml2.drivers.agent._common_agent > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] RPC agent_id: > lba0369fa2714a > 2018-11-28 17:41:45.907 2476 INFO neutron.agent.agent_extensions_manager > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Loaded agent > extensions: [] > 2018-11-28 17:41:46.121 2476 INFO > neutron.plugins.ml2.drivers.agent._common_agent > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Linux bridge agent > Agent RPC Daemon Started! > 2018-11-28 17:41:46.122 2476 INFO > neutron.plugins.ml2.drivers.agent._common_agent > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Linux bridge agent > Agent out of sync with plugin! > 2018-11-28 17:41:46.512 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.arp_protect > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Clearing orphaned ARP > spoofing entries for devices [] > 2018-11-28 17:41:47.020 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.arp_protect > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Clearing orphaned ARP > spoofing entries for devices [] > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent [-] Failed reporting > state!: MessagingTimeout: Timed out waiting for a reply to message ID > 20ef587240864120b878559ab821adbf > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent Traceback (most recent call > last): > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/agent/_common_agent.py", > line 128, in _report_state > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent True) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/neutron/agent/rpc.py", line 93, in > report_state > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent return method(context, > 'report_state', **kwargs) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 174, > in call > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent retry=self.retry) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 131, > in _send > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent timeout=timeout, > retry=retry) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", > line 559, in send > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent retry=retry) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", > line 548, in _send > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent result = > self._waiter.wait(msg_id, timeout) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", > line 440, in wait > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent message = > self.waiters.get(msg_id, timeout=timeout) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", > line 328, in get > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent 'to message ID %s' % > msg_id) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent MessagingTimeout: Timed out > waiting for a reply to message ID 20ef587240864120b878559ab821adbf > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent > 2018-11-28 17:42:45.986 2476 WARNING oslo.service.loopingcall [-] Function > 'neutron.plugins.ml2.drivers.agent._common_agent.CommonAgentLoop._report_state' > run outlasted interval by 30.07 sec > 2018-11-28 17:42:46.055 2476 INFO > neutron.plugins.ml2.drivers.agent._common_agent [-] Linux bridge agent > Agent has just been revived. Doing a full sync. > 2018-11-28 17:42:46.156 2476 INFO > neutron.plugins.ml2.drivers.agent._common_agent > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Linux bridge agent > Agent out of sync with plugin! > 2018-11-28 17:43:40.189 2476 INFO neutron.agent.securitygroups_rpc > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Preparing filters for > devices set(['tap4a09374a-7f']) > 2018-11-28 17:43:40.935 2476 INFO > neutron.plugins.ml2.drivers.agent._common_agent > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Port tap4a09374a-7f > updated. Details: {u'profile': {}, u'network_qos_policy_id': None, > u'qos_policy_id': None, u'allowed_address_pairs': [], u'admin_state_up': > True, u'network_id': u'87fa0d9c-5ed3-4332-8782-0d4139eed7f3', > u'segmentation_id': None, u'mtu': 1500, u'device_owner': u'network:dhcp', > u'physical_network': u'provider', u'mac_address': u'fa:16:3e:ab:0e:84', > u'device': u'tap4a09374a-7f', u'port_security_enabled': False, u'port_id': > u'4a09374a-7fa5-42c2-9430-67a0cd65336c', u'fixed_ips': [{u'subnet_id': > u'e95946a8-070c-42c4-877e-279e6e7acc7e', u'ip_address': u'192.0.10.4'}], > u'network_type': u'flat'} > 2018-11-28 17:43:41.124 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.arp_protect > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Skipping ARP spoofing > rules for port 'tap4a09374a-7f' because it has port security disabled "/var/log/neutron/neutron-server.log" > 2018-11-28 17:30:02.130 15995 INFO neutron.pecan_wsgi.hooks.translation > [req-e7554d70-c84d-46d5-8ff6-a536fb35664c 29a3a16fd2484ee9bed834a3835545af > 5ebe3484974848b182a381127cb35a22 - default default] GET failed (client > error): The resource could not be found. > 2018-11-28 17:30:02.130 15995 INFO neutron.wsgi > [req-e7554d70-c84d-46d5-8ff6-a536fb35664c 29a3a16fd2484ee9bed834a3835545af > 5ebe3484974848b182a381127cb35a22 - default default] 10.150.21.183 "GET > /v2.0/floatingips?fixed_ip_address=192.0.10.10&port_id=8ab0d544-ec5b-4e69-95f4-1f06f7b53bb4 > HTTP/1.1" status: 404 len: 309 time: 0.0072770 > 2018-11-28 17:30:02.167 15995 INFO neutron.wsgi > [req-a2b5f53b-8992-4178-b0b6-55be9d1a0f32 29a3a16fd2484ee9bed834a3835545af > 5ebe3484974848b182a381127cb35a22 - default default] 10.150.21.183 "GET > /v2.0/subnets?id=e95946a8-070c-42c4-877e-279e6e7acc7e HTTP/1.1" status: > 200 len: 822 time: 0.0341990 > 2018-11-28 17:30:02.199 15995 INFO neutron.wsgi > [req-9e1a51e9-9ccc-4226-a78f-0420ff95c147 29a3a16fd2484ee9bed834a3835545af > 5ebe3484974848b182a381127cb35a22 - default default] 10.150.21.183 "GET > /v2.0/ports?network_id=87fa0d9c-5ed3-4332-8782-0d4139eed7f3&device_owner=network%3Adhcp > HTTP/1.1" status: 200 len: 1080 time: 0.0300300 > 2018-11-28 17:30:02.584 15995 INFO neutron.notifiers.nova [-] Nova event > response: {u'status': u'completed', u'tag': > u'8ab0d544-ec5b-4e69-95f4-1f06f7b53bb4', u'name': u'network-changed', > u'server_uuid': u'a9afc2d4-f4c9-429b-9773-4de8a3eaefa5', u'code': 200} > 2018-11-28 17:30:02.628 15995 INFO neutron.wsgi > [req-73265cf5-5f0d-4217-b716-caa2fb906abf 29a3a16fd2484ee9bed834a3835545af > 5ebe3484974848b182a381127cb35a22 - default default] 10.150.21.183 "GET > /v2.0/ports?tenant_id=47270e4fb58045dc88b6f0f736286ffc&device_id=a9afc2d4-f4c9-429b-9773-4de8a3eaefa5 > HTTP/1.1" status: 200 len: 1062 time: 0.0316660 > 2018-11-28 17:30:02.696 15995 INFO neutron.wsgi > [req-ed53b92c-3033-4b4a-ade4-fdc5a3463e8c 29a3a16fd2484ee9bed834a3835545af > 5ebe3484974848b182a381127cb35a22 - default default] 10.150.21.183 "GET > /v2.0/networks?id=87fa0d9c-5ed3-4332-8782-0d4139eed7f3 HTTP/1.1" status: > 200 len: 872 time: 0.0655539 > 2018-11-28 17:30:02.702 15995 WARNING neutron.pecan_wsgi.controllers.root > [req-ccd8c9b8-d2cf-40f7-b53b-5936bd0c9a6d 29a3a16fd2484ee9bed834a3835545af > 5ebe3484974848b182a381127cb35a22 - default default] No controller found > for: floatingips - returning response code 404: PecanNotFound 2. compute node > "/var/log/libvirt/libxl/libxl-driver.log" > 2018-11-28 08:40:31.920+0000: libxl: > libxl_event.c:681:libxl__ev_xswatch_deregister: remove watch for path > @releaseDomain: Bad file descriptor > 2018-11-28 09:57:01.707+0000: libxl: > libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/vif-bridge > online [2536] exited with error status 1 > 2018-11-28 09:57:01.708+0000: libxl: > libxl_device.c:1286:device_hotplug_child_death_cb: script: ip link set > vif1.0 name tape5a239a8-6e failed > 2018-11-28 09:57:01.708+0000: libxl: > libxl_create.c:1522:domcreate_attach_devices: Domain 1:unable to add vif > devices "/var/log/xen/xen-hotplug.log" > RTNETLINK answers: Device or resource busy "/var/log/nova/nova-compute.log" > : libvirtError: internal error: libxenlight failed to create new domain > 'instance-00000008' > 2018-11-28 21:18:11.350 2384 ERROR nova.virt.libvirt.driver > [req-b3e761b7-00fa-4930-bd9e-4330f8440c03 48086750fa13420888601964bb6a9d0d > 5ebe3484974848b182a381127cb35a22 - default default] [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] Failed to start libvirt guest: > libvirtError: internal error: libxenlight failed to create new domain > 'instance-00000008' > 2018-11-28 21:18:11.352 2384 INFO os_vif > [req-b3e761b7-00fa-4930-bd9e-4330f8440c03 48086750fa13420888601964bb6a9d0d > 5ebe3484974848b182a381127cb35a22 - default default] Successfully unplugged > vif > VIFBridge(active=False,address=fa:16:3e:6b:e4:b7,bridge_name='brq87fa0d9c-5e',has_traffic_filtering=True,id=484807ca-8c7c-4509-a5f5-ed7e5fd2078f,network=Network(87fa0d9c-5ed3-4332-8782-0d4139eed7f3),plugin='linux_bridge',port_profile=,preserve_on_delete=False,vif_name='tap484807ca-8c') > 2018-11-28 21:18:11.554 2384 INFO nova.virt.libvirt.driver > [req-b3e761b7-00fa-4930-bd9e-4330f8440c03 48086750fa13420888601964bb6a9d0d > 5ebe3484974848b182a381127cb35a22 - default default] [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] Deleting instance files > /var/lib/nova/instances/9c2d08f3-0680-4709-a64d-ae1729a11304_del > 2018-11-28 21:18:11.556 2384 INFO nova.virt.libvirt.driver > [req-b3e761b7-00fa-4930-bd9e-4330f8440c03 48086750fa13420888601964bb6a9d0d > 5ebe3484974848b182a381127cb35a22 - default default] [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] Deletion of > /var/lib/nova/instances/9c2d08f3-0680-4709-a64d-ae1729a11304_del complete > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager > [req-b3e761b7-00fa-4930-bd9e-4330f8440c03 48086750fa13420888601964bb6a9d0d > 5ebe3484974848b182a381127cb35a22 - default default] [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] Instance failed to spawn: > libvirtError: internal error: libxenlight failed to create new domain > 'instance-00000008' > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] Traceback (most recent call last): > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2251, in > _build_resources > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] yield resources > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2031, in > _build_and_run_instance > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] > block_device_info=block_device_info) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 3089, > in spawn > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] destroy_disks_on_failure=True) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5614, > in _create_domain_and_network > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] destroy_disks_on_failure) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in > __exit__ > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] self.force_reraise() > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in > force_reraise > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] six.reraise(self.type_, > self.value, self.tb) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5583, > in _create_domain_and_network > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] > post_xml_callback=post_xml_callback) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5502, > in _create_domain > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] guest.launch(pause=pause) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/guest.py", line 144, in > launch > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] self._encoded_xml, > errors='ignore') > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in > __exit__ > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] self.force_reraise() > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in > force_reraise > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] six.reraise(self.type_, > self.value, self.tb) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/guest.py", line 139, in > launch > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] return > self._domain.createWithFlags(flags) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 186, in doit > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] result = > proxy_call(self._autowrap, f, *args, **kwargs) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 144, in > proxy_call > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] rv = execute(f, *args, **kwargs) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 125, in execute > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] six.reraise(c, e, tb) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 83, in tworker > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] rv = meth(*args, **kwargs) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/libvirt.py", line 1092, in createWithFlags > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] if ret == -1: raise libvirtError > ('virDomainCreateWithFlags() failed', dom=self) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] libvirtError: internal error: > libxenlight failed to create new domain 'instance-00000008' Anyone help me please. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From soheil.ir08 at gmail.com Wed Nov 28 12:40:21 2018 From: soheil.ir08 at gmail.com (Soheil Pourbafrani) Date: Wed, 28 Nov 2018 16:10:21 +0330 Subject: [Openstack] [OpenStack][cinder]Does cinder allocate disk to the volumes dynamically? In-Reply-To: References: Message-ID: When I installed OpenStack using PackStack, the size of LVM group was 20G but I could create 18 volume each of which 20G size (so in the PackStack the Cinder allocate volumes dynamically), but installing OpenStack from repository, the Cinder allocate disk to volume statically because I have volume group in size 140G but I only can create 7 volume of size 20G. So How Can I configure Cinder to allocate disk dynamically? On Wed, Nov 28, 2018 at 3:56 PM Soheil Pourbafrani wrote: > Hi, > > I was wondering if the Cinder allocates disk to volumes statically or > dynamically? > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From dprince at redhat.com Wed Nov 28 14:25:13 2018 From: dprince at redhat.com (Dan Prince) Date: Wed, 28 Nov 2018 09:25:13 -0500 Subject: [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <4121346a-7341-184f-2dcb-32092409196b@redhat.com> References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> Message-ID: <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> On Wed, 2018-11-28 at 15:12 +0100, Bogdan Dobrelya wrote: > On 11/28/18 2:58 PM, Dan Prince wrote: > > On Wed, 2018-11-28 at 12:45 +0100, Bogdan Dobrelya wrote: > > > To follow up and explain the patches for code review: > > > > > > The "header" patch https://review.openstack.org/620310 -> > > > (requires) > > > https://review.rdoproject.org/r/#/c/17534/, and also > > > https://review.openstack.org/620061 -> (which in turn requires) > > > https://review.openstack.org/619744 -> (Kolla change, the 1st to > > > go) > > > https://review.openstack.org/619736 > > > > This email was cross-posted to multiple lists and I think we may > > have > > lost some of the context in the process as the subject was changed. > > > > Most of the suggestions and patches are about making our base > > container(s) smaller in size. And the means by which the patches do > > that is to share binaries/applications across containers with > > custom > > mounts/volumes. I've -2'd most of them. What concerns me however is > > that some of the TripleO cores seemed open to this idea yesterday > > on > > IRC. Perhaps I've misread things but what you appear to be doing > > here > > is quite drastic I think we need to consider any of this carefully > > before proceeding with any of it. > > > > > > > Please also read the commit messages, I tried to explain all > > > "Whys" > > > very > > > carefully. Just to sum up it here as well: > > > > > > The current self-containing (config and runtime bits) > > > architecture > > > of > > > containers badly affects: > > > > > > * the size of the base layer and all containers images as an > > > additional 300MB (adds an extra 30% of size). > > > > You are accomplishing this by removing Puppet from the base > > container, > > but you are also creating another container in the process. This > > would > > still be required on all nodes as Puppet is our config tool. So you > > would still be downloading some of this data anyways. Understood > > your > > reasons for doing this are that it avoids rebuilding all containers > > when there is a change to any of these packages in the base > > container. > > What you are missing however is how often is it the case that > > Puppet is > > updated that something else in the base container isn't? > > For CI jobs updating all containers, its quite an often to have > changes > in openstack/tripleo puppet modules to pull in. IIUC, that > automatically > picks up any updates for all of its dependencies and for the > dependencies of dependencies, and all that multiplied by a hundred > of > total containers to get it updated. That is a *pain* we're used to > have > these day for quite often timing out CI jobs... Ofc, the main cause > is > delayed promotions though. Regarding CI I made a separate suggestion on that below in that rebuilding the base layer more often could be a good solution here. I don't think the puppet-tripleo package is that large however so we could just live with it. > > For real deployments, I have no data for the cadence of minor updates > in > puppet and tripleo & openstack modules for it, let's ask operators > (as > we're happened to be in the merged openstack-discuss list)? For its > dependencies though, like systemd and ruby, I'm pretty sure it's > quite > often to have CVEs fixed there. So I expect what "in the fields" > security fixes delivering for those might bring some unwanted hassle > for > long-term maintenance of LTS releases. As Tengu noted on IRC: > "well, between systemd, puppet and ruby, there are many security > concernes, almost every month... and also, what's the point keeping > them > in runtime containers when they are useless?" Reiterating again on previous points: -I'd be fine removing systemd. But lets do it properly and not via 'rpm -ev --nodeps'. -Puppet and Ruby *are* required for configuration. We can certainly put them in a separate container outside of the runtime service containers but doing so would actually cost you much more space/bandwidth for each service container. As both of these have to get downloaded to each node anyway in order to generate config files with our current mechanisms I'm not sure this buys you anything. We are going in circles here I think.... Dan > > > I would wager that it is more rare than you'd think. Perhaps > > looking at > > the history of an OpenStack distribution would be a valid way to > > assess > > this more critically. Without this data to backup the numbers I'm > > afraid what you are doing here falls into "pre-optimization" > > territory > > for me and I don't think the means used in the patches warrent the > > benefits you mention here. > > > > > > > * Edge cases, where we have containers images to be distributed, > > > at > > > least once to hit local registries, over high-latency and > > > limited > > > bandwith, highly unreliable WAN connections. > > > * numbers of packages to update in CI for all containers for all > > > services (CI jobs do not rebuild containers so each container > > > gets > > > updated for those 300MB of extra size). > > > > It would seem to me there are other ways to solve the CI containers > > update problems. Rebuilding the base layer more often would solve > > this > > right? If we always build our service containers off of a base > > layer > > that is recent there should be no updates to the system/puppet > > packages > > there in our CI pipelines. > > > > > * security and the surface of attacks, by introducing systemd et > > > al > > > as > > > additional subjects for CVE fixes to maintain for all > > > containers. > > > > We aren't actually using systemd within our containers. I think > > those > > packages are getting pulled in by an RPM dependency elsewhere. So > > rather than using 'rpm -ev --nodeps' to remove it we could create a > > sub-package for containers in those cases and install it instead. > > In > > short rather than hack this to remove them why not pursue a proper > > packaging fix? > > > > In general I am a fan of getting things out of the base container > > we > > don't need... so yeah lets do this. But lets do it properly. > > > > > * services uptime, by additional restarts of services related to > > > security maintanence of irrelevant to openstack components > > > sitting > > > as a dead weight in containers images for ever. > > > > Like I said above how often is it that these packages actually > > change > > where something else in the base container doesn't? Perhaps we > > should > > get more data here before blindly implementing a solution we aren't > > sure really helps out in the real world. > > > > > On 11/27/18 4:08 PM, Bogdan Dobrelya wrote: > > > > Changing the topic to follow the subject. > > > > > > > > [tl;dr] it's time to rearchitect container images to stop > > > > incluiding > > > > config-time only (puppet et al) bits, which are not needed > > > > runtime > > > > and > > > > pose security issues, like CVEs, to maintain daily. > > > > > > > > Background: 1) For the Distributed Compute Node edge case, > > > > there > > > > is > > > > potentially tens of thousands of a single-compute-node remote > > > > edge > > > > sites > > > > connected over WAN to a single control plane, which is having > > > > high > > > > latency, like a 100ms or so, and limited bandwith. > > > > 2) For a generic security case, > > > > 3) TripleO CI updates all > > > > > > > > Challenge: > > > > > > > > > Here is a related bug [1] and implementation [1] for that. > > > > > PTAL > > > > > folks! > > > > > > > > > > [0] https://bugs.launchpad.net/tripleo/+bug/1804822 > > > > > [1] > > > > > https://review.openstack.org/#/q/topic:base-container-reduction > > > > > > > > > > > Let's also think of removing puppet-tripleo from the base > > > > > > container. > > > > > > It really brings the world-in (and yum updates in CI!) each > > > > > > job > > > > > > and > > > > > > each container! > > > > > > So if we did so, we should then either install puppet- > > > > > > tripleo > > > > > > and co > > > > > > on the host and bind-mount it for the docker-puppet > > > > > > deployment > > > > > > task > > > > > > steps (bad idea IMO), OR use the magical --volumes-from > > > > > > option to mount volumes from some > > > > > > "puppet-config" sidecar container inside each of the > > > > > > containers > > > > > > being > > > > > > launched by docker-puppet tooling. > > > > > > > > > > On Wed, Oct 31, 2018 at 11:16 AM Harald Jensås > > > > redhat.com> > > > > > wrote: > > > > > > We add this to all images: > > > > > > > > > > > > https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646e535cf972c98ef/container-images/tripleo_kolla_template_overrides.j2#L35 > > > > > > > > > > > > > > > > > > /bin/sh -c yum -y install iproute iscsi-initiator-utils > > > > > > lvm2 > > > > > > python > > > > > > socat sudo which openstack-tripleo-common-container-base > > > > > > rsync > > > > > > cronie > > > > > > crudini openstack-selinux ansible python-shade puppet- > > > > > > tripleo > > > > > > python2- > > > > > > kubernetes && yum clean all && rm -rf /var/cache/yum 276 MB > > > > > > Is the additional 276 MB reasonable here? > > > > > > openstack-selinux <- This package run relabling, does that > > > > > > kind > > > > > > of > > > > > > touching the filesystem impact the size due to docker > > > > > > layers? > > > > > > > > > > > > Also: python2-kubernetes is a fairly large package > > > > > > (18007990) > > > > > > do we use > > > > > > that in every image? I don't see any tripleo related repos > > > > > > importing > > > > > > from that when searching on Hound? The original commit > > > > > > message[1] > > > > > > adding it states it is for future convenience. > > > > > > > > > > > > On my undercloud we have 101 images, if we are downloading > > > > > > every 18 MB > > > > > > per image thats almost 1.8 GB for a package we don't use? > > > > > > (I > > > > > > hope it's > > > > > > not like this? With docker layers, we only download that > > > > > > 276 MB > > > > > > transaction once? Or?) > > > > > > > > > > > > > > > > > > [1] https://review.openstack.org/527927 > > > > > > > > > > -- > > > > > Best regards, > > > > > Bogdan Dobrelya, > > > > > Irc #bogdando > > From natal at redhat.com Wed Nov 28 14:33:02 2018 From: natal at redhat.com (=?UTF-8?Q?Natal_Ng=C3=A9tal?=) Date: Wed, 28 Nov 2018 15:33:02 +0100 Subject: [openstack-dev] [tripleo] Let's improve upstream docs In-Reply-To: References: Message-ID: On Tue, Nov 27, 2018 at 4:50 PM Marios Andreou wrote: > as just mentioned in the tripleo weekly irc meeting [1] some of us are trying to make small weekly improvements to the tripleo docs [2]. We are using this bug [3] for tracking and this effort is a result of some feedback during the recent Berlin summit. It's a good idea. The documentation of a project it's very important. > The general idea is 1 per week (or more if you can and want) - improvement/removal of stale content/identifying missing sections, or anything else you might care to propose. Please join us if you can, just add "Related-Bug: #1804642" to your commit message I'm going to try to help you on this ticket. I started to make code review. I would to know if you have more details about that. I mean, do you have examples of part able improved or something like that. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From jaypipes at gmail.com Wed Nov 28 14:56:26 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Wed, 28 Nov 2018 09:56:26 -0500 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: Message-ID: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> On 11/28/2018 02:50 AM, Zufar Dhiyaulhaq wrote: > Hi, > > Thank you. I am able to fix this issue by adding this configuration into > nova configuration file in controller node. > > driver=filter_scheduler That's the default: https://docs.openstack.org/ocata/config-reference/compute/config-options.html So that was definitely not the solution to your problem. My guess is that Sean's suggestion to randomize the allocation candidates fixed your issue. Best, -jay _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From marios at redhat.com Wed Nov 28 15:15:02 2018 From: marios at redhat.com (Marios Andreou) Date: Wed, 28 Nov 2018 17:15:02 +0200 Subject: [openstack-dev] [tripleo] Let's improve upstream docs In-Reply-To: References: Message-ID: On Wed, Nov 28, 2018 at 4:33 PM Natal Ngétal wrote: > On Tue, Nov 27, 2018 at 4:50 PM Marios Andreou wrote: > > as just mentioned in the tripleo weekly irc meeting [1] some of us are > trying to make small weekly improvements to the tripleo docs [2]. We are > using this bug [3] for tracking and this effort is a result of some > feedback during the recent Berlin summit. > It's a good idea. The documentation of a project it's very important. > > > The general idea is 1 per week (or more if you can and want) - > improvement/removal of stale content/identifying missing sections, or > anything else you might care to propose. Please join us if you can, just > add "Related-Bug: #1804642" to your commit message > I'm going to try to help you on this ticket. I started to make code > great you are very welcome ! > review. I would to know if you have more details about that. I mean, > do you have examples of part able improved or something like that. > > not really, I mean "anything goes" as long as it's an improvement ( and the usual review process will determine if it is or not :) ). Could be as small as typos or broken links/images, through to reorganising sections or even bigger contributions like completely new sections if you can and want. Take a look at the existing patches that are on the bug for ideas thanks > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From natal at redhat.com Wed Nov 28 15:28:23 2018 From: natal at redhat.com (=?UTF-8?Q?Natal_Ng=C3=A9tal?=) Date: Wed, 28 Nov 2018 16:28:23 +0100 Subject: [openstack-dev] [tripleo] Let's improve upstream docs In-Reply-To: References: Message-ID: On Wed, Nov 28, 2018 at 4:19 PM Marios Andreou wrote: > great you are very welcome ! Thanks. > not really, I mean "anything goes" as long as it's an improvement ( and the usual review process will determine if it is or not :) ). Could be as small as typos or broken links/images, through to reorganising sections or even bigger contributions like completely new sections if you can and want. Take a look at the existing patches that are on the bug for ideas I see. I have made a first patch and I'm going to find what I can do and continue to make code review. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From massimo.sgaravatto at gmail.com Wed Nov 28 15:38:26 2018 From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto) Date: Wed, 28 Nov 2018 16:38:26 +0100 Subject: [ops] [nova] How to get CPUtime and wallclokctime consumed by a project (without using ceilometer) ? Message-ID: Hi I was wondering if nova allows to get the CPUtime and wallclocktime consumed by a project in a certain time period, without using ceilometer Among the data returned by the command "openstack usage show" there is also a "CPU Hours" but, if I am not wrong, this is actually the WallClockTime. Did I get it right ? If so, it is also possible to get the CPUTime ? Thanks, Massimo -------------- next part -------------- An HTML attachment was scrubbed... URL: From msm at redhat.com Wed Nov 28 15:53:50 2018 From: msm at redhat.com (Michael McCune) Date: Wed, 28 Nov 2018 10:53:50 -0500 Subject: [openstack-ansible] Evaluating meeting schedule + method In-Reply-To: <8c59e2dbcd07bda4d4e12952e5d5af0bf8c839f2.camel@evrard.me> References: <1913981.aYPTVNe1F8@whitebase.usersys.redhat.com> <8c59e2dbcd07bda4d4e12952e5d5af0bf8c839f2.camel@evrard.me> Message-ID: On Wed, Nov 28, 2018 at 4:49 AM Jean-Philippe Evrard wrote: > Having an office hour there could ensure people could come to a certain > time and we'd be there. Attendance would be identitical though, but > it's not really an issue to me. > just wanted to add another data point here. the API-SIG recently migrated from regular meeting times to office hours. one of the big reasons for this was that our regular weekly meeting attendance had dropped to minimal levels. so far we've found that the office hours have lessened the strain on the chairs and organizers while still giving us a few very visible times for the community to interact with us. the API-SIG isn't quite the same as a code central project, but i think the pattern of meeting migration is more general in nature. hope this helps =) peace o/ From sean.mcginnis at gmx.com Wed Nov 28 16:03:38 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Wed, 28 Nov 2018 10:03:38 -0600 Subject: [Openstack] [OpenStack][cinder]Does cinder allocate disk to the volumes dynamically? In-Reply-To: References: Message-ID: <20181128160337.GA5164@sm-workstation> On Wed, Nov 28, 2018 at 04:10:21PM +0330, Soheil Pourbafrani wrote: > When I installed OpenStack using PackStack, the size of LVM group was 20G > but I could create 18 volume each of which 20G size (so in the PackStack > the Cinder allocate volumes dynamically), but installing OpenStack from > repository, the Cinder allocate disk to volume statically because I have > volume group in size 140G but I only can create 7 volume of size 20G. So > How Can I configure Cinder to allocate disk dynamically? > Not sure why you would be seeing a difference, but the default for Cinder is to thin provision volumes. This is controller through the following option in cinder.conf: # Use thin provisioning for SAN volumes? (boolean value) #san_thin_provision = true Specific to LVM there is also the type option: # Type of LVM volumes to deploy; (default, thin, or auto). Auto defaults to # thin if thin is supported. (string value) # Possible values: # default - Thick-provisioned LVM. # thin - Thin-provisioned LVM. # auto - Defaults to thin when supported. #lvm_type = auto With the "auto" setting, that should thin provision the volumes unless you had already configured the volume group ahead of time to not support it. That's probably the most likely thing I can think of. Sean _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From emilien at redhat.com Wed Nov 28 16:39:18 2018 From: emilien at redhat.com (Emilien Macchi) Date: Wed, 28 Nov 2018 11:39:18 -0500 Subject: [openstack-dev] [tripleo] Workflows Squad changes In-Reply-To: References: Message-ID: On Wed, Nov 28, 2018 at 5:13 AM Jiri Tomasek wrote: [...] > As a possible solution, I would like to propose Adriano as a core reviewer > to tripleo-common and adding tripleo-ui cores right to +2 tripleo-common > patches. > [...] Not a member of the squad but +2 to the idea Thanks for proposing, -- Emilien Macchi -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From Kevin.Fox at pnnl.gov Wed Nov 28 16:46:16 2018 From: Kevin.Fox at pnnl.gov (Fox, Kevin M) Date: Wed, 28 Nov 2018 16:46:16 +0000 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <7364ab27a3f50e40a44c2af4305bde97816944fd.camel@redhat.com> References: <9dee4044-2744-3ab6-3a15-bd79702ff35a@redhat.com> , <089336b7a431cab76e1350a959b7bb566175134b.camel@redhat.com> <1A3C52DFCD06494D8528644858247BF01C248BF7@EX10MBOX03.pnnl.gov>, <7364ab27a3f50e40a44c2af4305bde97816944fd.camel@redhat.com> Message-ID: <1A3C52DFCD06494D8528644858247BF01C24924B@EX10MBOX03.pnnl.gov> Ok, so you have the workflow in place, but it sounds like the containers are not laid out to best use that workflow. Puppet is in the base layer. That means whenever puppet gets updated, all the other containers must be too. And other such update coupling issues. I'm with you, that binaries should not be copied from one container to another though. Thanks, Kevin ________________________________________ From: Dan Prince [dprince at redhat.com] Sent: Wednesday, November 28, 2018 5:31 AM To: Former OpenStack Development Mailing List, use openstack-discuss now; openstack-discuss at lists.openstack.org Subject: Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes On Wed, 2018-11-28 at 00:31 +0000, Fox, Kevin M wrote: > The pod concept allows you to have one tool per container do one > thing and do it well. > > You can have a container for generating config, and another container > for consuming it. > > In a Kubernetes pod, if you still wanted to do puppet, > you could have a pod that: > 1. had an init container that ran puppet and dumped the resulting > config to an emptyDir volume. > 2. had your main container pull its config from the emptyDir volume. We have basically implemented the same workflow in TripleO today. First we execute Puppet in an "init container" (really just an ephemeral container that generates the config files and then goes away). Then we bind mount those configs into the service container. One improvement we could make (which we aren't doing yet) is to use a data container/volume to store the config files instead of using the host. Sharing *data* within a 'pod' (set of containers, etc.) is certainly a valid use of container volumes. None of this is what we are really talking about in this thread though. Most of the suggestions and patches are about making our base container(s) smaller in size. And the means by which the patches do that is to share binaries/applications across containers with custom mounts/volumes. I don't think it is a good idea at all as it violates encapsulation of the containers in general, regardless of whether we use pods or not. Dan > > Then each container would have no dependency on each other. > > In full blown Kubernetes cluster you might have puppet generate a > configmap though and ship it to your main container directly. Thats > another matter though. I think the example pod example above is still > usable without k8s? > > Thanks, > Kevin > ________________________________________ > From: Dan Prince [dprince at redhat.com] > Sent: Tuesday, November 27, 2018 10:10 AM > To: OpenStack Development Mailing List (not for usage questions); > openstack-discuss at lists.openstack.org > Subject: Re: [openstack-dev] [TripleO][Edge] Reduce base layer of > containers for security and size of images (maintenance) sakes > > On Tue, 2018-11-27 at 16:24 +0100, Bogdan Dobrelya wrote: > > Changing the topic to follow the subject. > > > > [tl;dr] it's time to rearchitect container images to stop > > incluiding > > config-time only (puppet et al) bits, which are not needed runtime > > and > > pose security issues, like CVEs, to maintain daily. > > I think your assertion that we need to rearchitect the config images > to > container the puppet bits is incorrect here. > > After reviewing the patches you linked to below it appears that you > are > proposing we use --volumes-from to bind mount application binaries > from > one container into another. I don't believe this is a good pattern > for > containers. On baremetal if we followed the same pattern it would be > like using an /nfs share to obtain access to binaries across the > network to optimize local storage. Now... some people do this (like > maybe high performance computing would launch an MPI job like this) > but > I don't think we should consider it best practice for our containers > in > TripleO. > > Each container should container its own binaries and libraries as > much > as possible. And while I do think we should be using --volumes-from > more often in TripleO it would be for sharing *data* between > containers, not binaries. > > > > Background: > > 1) For the Distributed Compute Node edge case, there is potentially > > tens > > of thousands of a single-compute-node remote edge sites connected > > over > > WAN to a single control plane, which is having high latency, like a > > 100ms or so, and limited bandwith. Reducing the base layer size > > becomes > > a decent goal there. See the security background below. > > The reason we put Puppet into the base layer was in fact to prevent > it > from being downloaded multiple times. If we were to re-architect the > image layers such that the child layers all contained their own > copies > of Puppet for example there would actually be a net increase in > bandwidth and disk usage. So I would argue we are already addressing > the goal of optimizing network and disk space. > > Moving it out of the base layer so that you can patch it more often > without disrupting other services is a valid concern. But addressing > this concern while also preserving our definiation of a container > (see > above, a container should contain all of its binaries) is going to > cost > you something, namely disk and network space because Puppet would > need > to be duplicated in each child container. > > As Puppet is used to configure a majority of the services in TripleO > having it in the base container makes most sense. And yes, if there > are > security patches for Puppet/Ruby those might result in a bunch of > containers getting pushed. But let Docker layers take care of this I > think... Don't try to solve things by constructing your own custom > mounts and volumes to work around the issue. > > > > 2) For a generic security (Day 2, maintenance) case, when > > puppet/ruby/systemd/name-it gets a CVE fixed, the base layer has to > > be > > updated and all layers on top - to be rebuild, and all of those > > layers, > > to be re-fetched for cloud hosts and all containers to be > > restarted... > > And all of that because of some fixes that have nothing to > > OpenStack. > > By > > the remote edge sites as well, remember of "tens of thousands", > > high > > latency and limited bandwith?.. > > 3) TripleO CI updates (including puppet*) packages in containers, > > not > > in > > a common base layer of those. So each a CI job has to update > > puppet* > > and > > its dependencies - ruby/systemd as well. Reducing numbers of > > packages > > to > > update for each container makes sense for CI as well. > > > > Implementation related: > > > > WIP patches [0],[1] for early review, uses a config "pod" approach, > > does > > not require to maintain a two sets of config vs runtime images. > > Future > > work: a) cronie requires systemd, we'd want to fix that also off > > the > > base layer. b) rework to podman pods for docker-puppet.py instead > > of > > --volumes-from a side car container (can't be backported for Queens > > then, which is still nice to have a support for the Edge DCN case, > > at > > least downstream only perhaps). > > > > Some questions raised on IRC: > > > > Q: is having a service be able to configure itself really need to > > involve a separate pod? > > A: Highly likely yes, removing not-runtime things is a good idea > > and > > pods is an established PaaS paradigm already. That will require > > some > > changes in the architecture though (see the topic with WIP > > patches). > > I'm a little confused on this one. Are you suggesting that we have 2 > containers for each service? One with Puppet and one without? > > That is certainly possible, but to pull it off would likely require > you > to have things built like this: > > |base container| --> |service container| --> |service container w/ > Puppet installed| > > The end result would be Puppet being duplicated in a layer for each > services "config image". Very inefficient. > > Again, I'm ansering this assumping we aren't violating our container > constraints and best practices where each container has the binaries > its needs to do its own configuration. > > > Q: that's (fetching a config container) actually more data that > > about to > > download otherwise > > A: It's not, if thinking of Day 2, when have to re-fetch the base > > layer > > and top layers, when some unrelated to openstack CVEs got fixed > > there > > for ruby/puppet/systemd. Avoid the need to restart service > > containers > > because of those minor updates puched is also a nice thing. > > Puppet is used only for configuration in TripleO. While security > issues > do need to be addressed at any layer I'm not sure there would be an > urgency to re-deploy your cluster simply for a Puppet security fix > alone. Smart change management would help eliminate blindly deploying > new containers in the case where they provide very little security > benefit. > > I think the focus on Puppet, and Ruby here is perhaps a bad example > as > they are config time only. Rather than just think about them we > should > also consider the rest of the things in our base container images as > well. This is always going to be a "balancing act". There are pros > and > cons of having things in the base layer vs. the child/leaf layers. > > > > Q: the best solution here would be using packages on the host, > > generating the config files on the host. And then having an all-in- > > one > > container for all the services which lets them run in an isolated > > mannner. > > A: I think for Edge cases, that's a no go as we might want to > > consider > > tiny low footprint OS distros like former known Container Linux or > > Atomic. Also, an all-in-one container looks like an anti-pattern > > from > > the world of VMs. > > This was suggested on IRC because it likely gives you the smallest > network/storage footprint for each edge node. The container would get > used for everything: running all the services, and configuring all > the > services. Sort of a golden image approach. It may be an anti-pattern > but initially I thought you were looking to optimize these things. > > I think a better solution might be to have container registries, or > container mirrors (reverse proxies or whatever) that allow you to > cache > things as you deploy to the edge and thus optimize the network > traffic. > > > > [0] https://review.openstack.org/#/q/topic:base-container-reduction > > [1] > > https://review.rdoproject.org/r/#/q/topic:base-container-reduction > > > > > Here is a related bug [1] and implementation [1] for that. PTAL > > > folks! > > > > > > [0] https://bugs.launchpad.net/tripleo/+bug/1804822 > > > [1] > > > https://review.openstack.org/#/q/topic:base-container-reduction > > > > > > > Let's also think of removing puppet-tripleo from the base > > > > container. > > > > It really brings the world-in (and yum updates in CI!) each job > > > > and each > > > > container! > > > > So if we did so, we should then either install puppet-tripleo > > > > and > > > > co on > > > > the host and bind-mount it for the docker-puppet deployment > > > > task > > > > steps > > > > (bad idea IMO), OR use the magical --volumes-from > > > container> > > > > option to mount volumes from some "puppet-config" sidecar > > > > container > > > > inside each of the containers being launched by docker-puppet > > > > tooling. > > > > > > On Wed, Oct 31, 2018 at 11:16 AM Harald Jensås > > redhat.com> > > > wrote: > > > > We add this to all images: > > > > > > > > https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646e535cf972c98ef/container-images/tripleo_kolla_template_overrides.j2#L35 > > > > > > > > /bin/sh -c yum -y install iproute iscsi-initiator-utils lvm2 > > > > python > > > > socat sudo which openstack-tripleo-common-container-base rsync > > > > cronie > > > > crudini openstack-selinux ansible python-shade puppet-tripleo > > > > python2- > > > > kubernetes && yum clean all && rm -rf /var/cache/yum 276 MB > > > > > > > > Is the additional 276 MB reasonable here? > > > > openstack-selinux <- This package run relabling, does that kind > > > > of > > > > touching the filesystem impact the size due to docker layers? > > > > > > > > Also: python2-kubernetes is a fairly large package (18007990) > > > > do > > > > we use > > > > that in every image? I don't see any tripleo related repos > > > > importing > > > > from that when searching on Hound? The original commit > > > > message[1] > > > > adding it states it is for future convenience. > > > > > > > > On my undercloud we have 101 images, if we are downloading > > > > every > > > > 18 MB > > > > per image thats almost 1.8 GB for a package we don't use? (I > > > > hope > > > > it's > > > > not like this? With docker layers, we only download that 276 MB > > > > transaction once? Or?) > > > > > > > > > > > > [1] https://review.openstack.org/527927 > > > > > > -- > > > Best regards, > > > Bogdan Dobrelya, > > > Irc #bogdando > > _____________________________________________________________________ > _____ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From mriedemos at gmail.com Wed Nov 28 16:54:00 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 28 Nov 2018 10:54:00 -0600 Subject: [Openstack-operators] Fwd: Nova hypervisor uuid In-Reply-To: References: <63283d3b-0661-7620-aaea-8ffbe9e483d8@gmail.com> Message-ID: On 11/28/2018 4:19 AM, Ignazio Cassano wrote: > Hi Matt, sorry but I lost your answer and Gianpiero forwarded it to me. > I am sure kvm nodes names are note changed. > Tables where uuid are duplicated are: > dataresource_providers in nova_api db > compute_nodes in nova db > Regards > Ignazio It would be easier if you simply dumped the result of a select query on the compute_nodes table where the duplicate nodes exist (you said duplicate UUIDs but I think you mean duplicate host/node names with different UUIDs, correct?). There is a unique constraint on host/hypervisor_hostname (nodename)/deleted: schema.UniqueConstraint( 'host', 'hypervisor_hostname', 'deleted', name="uniq_compute_nodes0host0hypervisor_hostname0deleted"), So I'm wondering if the deleted field is not 0 on one of those because if one is marked as deleted, then the compute service will create a new compute_nodes table record on startup (and associated resource provider). -- Thanks, Matt _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From mriedemos at gmail.com Wed Nov 28 16:58:51 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 28 Nov 2018 10:58:51 -0600 Subject: [Openstack] [Nova] Instance creation problem In-Reply-To: References: Message-ID: On 11/28/2018 6:37 AM, Minjun Hong wrote: > "/var/log/neutron/neutron-linuxbridge-agent.log" > 2018-11-28 17:41:45.593 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent > [-] Interface mappings: {'provider': 'enp1s0f1'} > 2018-11-28 17:41:45.593 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent > [-] Bridge mappings: {} > 2018-11-28 17:41:45.624 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent > [-] Agent initialized successfully, now running... > 2018-11-28 17:41:45.901 2476 INFO > neutron.plugins.ml2.drivers.agent._common_agent > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] RPC agent_id: > lba0369fa2714a > 2018-11-28 17:41:45.907 2476 INFO neutron.agent.agent_extensions_manager > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Loaded agent > extensions: [] > 2018-11-28 17:41:46.121 2476 INFO > neutron.plugins.ml2.drivers.agent._common_agent > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Linux bridge agent > Agent RPC Daemon Started! > 2018-11-28 17:41:46.122 2476 INFO > neutron.plugins.ml2.drivers.agent._common_agent > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Linux bridge agent > Agent out of sync with plugin! > 2018-11-28 17:41:46.512 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.arp_protect > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Clearing orphaned > ARP spoofing entries for devices [] > 2018-11-28 17:41:47.020 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.arp_protect > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Clearing orphaned > ARP spoofing entries for devices [] > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent [-] Failed reporting > state!: MessagingTimeout: Timed out waiting for a reply to message ID > 20ef587240864120b878559ab821adbf Your neutron linuxbridge agent is failing to communicate with the neutron server over RPC, so vif plugging (on the compute host) is failing. Check the RPC configuration between the neutron linuxbridge agent and the server and make sure the agent is reporting in (I think there is a neutron services or agents command or something to make sure it's "up"). -- Thanks, Matt From doug at doughellmann.com Wed Nov 28 17:12:35 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 28 Nov 2018 12:12:35 -0500 Subject: [ops][docs] The Contributor Guide: Ops Feedback Session Summary In-Reply-To: <5938a4e0-3eb1-5448-3af5-f56bf3452e9c@suse.com> References: <5938a4e0-3eb1-5448-3af5-f56bf3452e9c@suse.com> Message-ID: Andreas Jaeger writes: > On 11/27/18 4:38 PM, Kendall Nelson wrote: >> Hello! >> >> >> For the long version, feel free to look over the etherpad[1]. >> >> >> It should be noted that this session was in relation to the operator >> section of the contributor guide, not the operations guide, though they >> should be closely related and link to one another. >> >> >> Basically the changes requested can be boiled down to two types of >> changes: cosmetic and missing content. >> >> >> Cosmetic Changes: >> >> * >> >> Timestamps so people can know when the last change was made to a >> given doc (dhellmann volunteered to help here)[2] >> >> * >> >> Floating bug report button and some mechanism for auto populating >> which page a bug is on so that the reader doesn’t have to know what >> rst file in what repo has the issue to file a bug[3] > > This is something probably for openstackdocstheme to have it > everywhere. Yes, that was the idea. We already have some code that pulls the timestamp from git in the governance repo, so I was going to move that over to the theme for better reuse. -- Doug From jaypipes at gmail.com Wed Nov 28 17:14:42 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Wed, 28 Nov 2018 12:14:42 -0500 Subject: [ops] [nova] How to get CPUtime and wallclokctime consumed by a project (without using ceilometer) ? In-Reply-To: References: Message-ID: <30e17c26-3ead-02f0-1222-cc5f1f23e696@gmail.com> On 11/28/2018 10:38 AM, Massimo Sgaravatto wrote: > Hi > > I was wondering if nova allows to get the CPUtime and wallclocktime > consumed by a project in a certain time period, without using ceilometer > > Among the data returned by the command "openstack usage show" there is > also a "CPU Hours" but, if I am not wrong, this is actually the > WallClockTime. Did I get it right ? It's neither. It's the calculated time that the VM has been "up" multiplied by the number of vCPUs the VM consumes. It's basically worthless as anything more than a simplistic indicator of rough resource consumption. You can see how the calculation is done by following the fairly convoluted code in the os-simple-tenant-usage API: This calculates the "hours used": https://github.com/openstack/nova/blob/62245235bc15da6abcdfd3df1c24bd856d69fbb4/nova/api/openstack/compute/simple_tenant_usage.py#L51-L82 And here is where that is multiplied by the VM's vCPUs: https://github.com/openstack/nova/blob/62245235bc15da6abcdfd3df1c24bd856d69fbb4/nova/api/openstack/compute/simple_tenant_usage.py#L213 > If so, it is also possible to get the CPUTime ? If you are referring to getting the amount of time a *physical host CPU* has spent performing tasks for a particular VM, the closest you can get to this would be the "server diagnostics" API: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/views/server_diagnostics.py That said, the server diagnostics API is a very thin shim over a virt-driver-specific interface: https://github.com/openstack/nova/blob/62245235bc15da6abcdfd3df1c24bd856d69fbb4/nova/compute/manager.py#L4698 The libvirt driver's get_server_diagnostics() (host-specific) and get_instance_diagnostics() (VM-specific) implementation is here: https://github.com/openstack/nova/blob/62245235bc15da6abcdfd3df1c24bd856d69fbb4/nova/virt/libvirt/driver.py#L8543-L8678 You might want to look at that code and implement a simple collectd/statsd/fluentd/telegraf collector to grab those stats directly from the libvirt daemon on the compute nodes themselves. Best, -jay From sgolovat at redhat.com Wed Nov 28 16:36:50 2018 From: sgolovat at redhat.com (Sergii Golovatiuk) Date: Wed, 28 Nov 2018 17:36:50 +0100 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <089336b7a431cab76e1350a959b7bb566175134b.camel@redhat.com> References: <9dee4044-2744-3ab6-3a15-bd79702ff35a@redhat.com> <089336b7a431cab76e1350a959b7bb566175134b.camel@redhat.com> Message-ID: Hi, On Tue, Nov 27, 2018 at 7:13 PM Dan Prince wrote: > On Tue, 2018-11-27 at 16:24 +0100, Bogdan Dobrelya wrote: > > Changing the topic to follow the subject. > > > > [tl;dr] it's time to rearchitect container images to stop incluiding > > config-time only (puppet et al) bits, which are not needed runtime > > and > > pose security issues, like CVEs, to maintain daily. > > I think your assertion that we need to rearchitect the config images to > container the puppet bits is incorrect here. > > After reviewing the patches you linked to below it appears that you are > proposing we use --volumes-from to bind mount application binaries from > one container into another. I don't believe this is a good pattern for > containers. On baremetal if we followed the same pattern it would be > like using an /nfs share to obtain access to binaries across the > network to optimize local storage. Now... some people do this (like > maybe high performance computing would launch an MPI job like this) but > I don't think we should consider it best practice for our containers in > TripleO. > > Each container should container its own binaries and libraries as much > as possible. And while I do think we should be using --volumes-from > more often in TripleO it would be for sharing *data* between > containers, not binaries. > > > > > > Background: > > 1) For the Distributed Compute Node edge case, there is potentially > > tens > > of thousands of a single-compute-node remote edge sites connected > > over > > WAN to a single control plane, which is having high latency, like a > > 100ms or so, and limited bandwith. Reducing the base layer size > > becomes > > a decent goal there. See the security background below. > > The reason we put Puppet into the base layer was in fact to prevent it > from being downloaded multiple times. If we were to re-architect the > image layers such that the child layers all contained their own copies > of Puppet for example there would actually be a net increase in > bandwidth and disk usage. So I would argue we are already addressing > the goal of optimizing network and disk space. > > Moving it out of the base layer so that you can patch it more often > without disrupting other services is a valid concern. But addressing > this concern while also preserving our definiation of a container (see > above, a container should contain all of its binaries) is going to cost > you something, namely disk and network space because Puppet would need > to be duplicated in each child container. > > As Puppet is used to configure a majority of the services in TripleO > having it in the base container makes most sense. And yes, if there are > security patches for Puppet/Ruby those might result in a bunch of > containers getting pushed. But let Docker layers take care of this I > think... Don't try to solve things by constructing your own custom > mounts and volumes to work around the issue. > > > > 2) For a generic security (Day 2, maintenance) case, when > > puppet/ruby/systemd/name-it gets a CVE fixed, the base layer has to > > be > > updated and all layers on top - to be rebuild, and all of those > > layers, > > to be re-fetched for cloud hosts and all containers to be > > restarted... > > And all of that because of some fixes that have nothing to OpenStack. > > By > > the remote edge sites as well, remember of "tens of thousands", high > > latency and limited bandwith?.. > > 3) TripleO CI updates (including puppet*) packages in containers, not > > in > > a common base layer of those. So each a CI job has to update puppet* > > and > > its dependencies - ruby/systemd as well. Reducing numbers of packages > > to > > update for each container makes sense for CI as well. > > > > Implementation related: > > > > WIP patches [0],[1] for early review, uses a config "pod" approach, > > does > > not require to maintain a two sets of config vs runtime images. > > Future > > work: a) cronie requires systemd, we'd want to fix that also off the > > base layer. b) rework to podman pods for docker-puppet.py instead of > > --volumes-from a side car container (can't be backported for Queens > > then, which is still nice to have a support for the Edge DCN case, > > at > > least downstream only perhaps). > > > > Some questions raised on IRC: > > > > Q: is having a service be able to configure itself really need to > > involve a separate pod? > > A: Highly likely yes, removing not-runtime things is a good idea and > > pods is an established PaaS paradigm already. That will require some > > changes in the architecture though (see the topic with WIP patches). > > I'm a little confused on this one. Are you suggesting that we have 2 > containers for each service? One with Puppet and one without? > > That is certainly possible, but to pull it off would likely require you > to have things built like this: > > |base container| --> |service container| --> |service container w/ > Puppet installed| > > The end result would be Puppet being duplicated in a layer for each > services "config image". Very inefficient. > > Again, I'm ansering this assumping we aren't violating our container > constraints and best practices where each container has the binaries > its needs to do its own configuration. > > > > > Q: that's (fetching a config container) actually more data that > > about to > > download otherwise > > A: It's not, if thinking of Day 2, when have to re-fetch the base > > layer > > and top layers, when some unrelated to openstack CVEs got fixed > > there > > for ruby/puppet/systemd. Avoid the need to restart service > > containers > > because of those minor updates puched is also a nice thing. > > Puppet is used only for configuration in TripleO. While security issues > do need to be addressed at any layer I'm not sure there would be an > urgency to re-deploy your cluster simply for a Puppet security fix > alone. Smart change management would help eliminate blindly deploying > new containers in the case where they provide very little security > benefit. > > I think the focus on Puppet, and Ruby here is perhaps a bad example as > they are config time only. Rather than just think about them we should > also consider the rest of the things in our base container images as > well. This is always going to be a "balancing act". There are pros and > cons of having things in the base layer vs. the child/leaf layers. > It's interesting as puppet is required for config time only, but it is kept in every image whole its life. There is a pattern of side cars in Kubernetes where side container configures what's needed for main container and dies. > > > > > > Q: the best solution here would be using packages on the host, > > generating the config files on the host. And then having an all-in- > > one > > container for all the services which lets them run in an isolated > > mannner. > > A: I think for Edge cases, that's a no go as we might want to > > consider > > tiny low footprint OS distros like former known Container Linux or > > Atomic. Also, an all-in-one container looks like an anti-pattern > > from > > the world of VMs. > > This was suggested on IRC because it likely gives you the smallest > network/storage footprint for each edge node. The container would get > used for everything: running all the services, and configuring all the > services. Sort of a golden image approach. It may be an anti-pattern > but initially I thought you were looking to optimize these things. > It is antipattern indeed. The smaller container is the better. Less chance of security issues, less data to transfer over network, less storage. In programming there are a lot of patterns to reuse code (OOP is a sample). So the same pattern should be applied to containers rather than blindly copy data to every container. > > I think a better solution might be to have container registries, or > container mirrors (reverse proxies or whatever) that allow you to cache > things as you deploy to the edge and thus optimize the network traffic. > This solution is good addition but containers should be tiny and not fat. > > > > > > [0] https://review.openstack.org/#/q/topic:base-container-reduction > > [1] > > https://review.rdoproject.org/r/#/q/topic:base-container-reduction > > > > > Here is a related bug [1] and implementation [1] for that. PTAL > > > folks! > > > > > > [0] https://bugs.launchpad.net/tripleo/+bug/1804822 > > > [1] https://review.openstack.org/#/q/topic:base-container-reduction > > > > > > > Let's also think of removing puppet-tripleo from the base > > > > container. > > > > It really brings the world-in (and yum updates in CI!) each job > > > > and each > > > > container! > > > > So if we did so, we should then either install puppet-tripleo and > > > > co on > > > > the host and bind-mount it for the docker-puppet deployment task > > > > steps > > > > (bad idea IMO), OR use the magical --volumes-from > > > container> > > > > option to mount volumes from some "puppet-config" sidecar > > > > container > > > > inside each of the containers being launched by docker-puppet > > > > tooling. > > > > > > On Wed, Oct 31, 2018 at 11:16 AM Harald Jensås > > redhat.com> > > > wrote: > > > > We add this to all images: > > > > > > > > > https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646e535cf972c98ef/container-images/tripleo_kolla_template_overrides.j2#L35 > > > > > > > > /bin/sh -c yum -y install iproute iscsi-initiator-utils lvm2 > > > > python > > > > socat sudo which openstack-tripleo-common-container-base rsync > > > > cronie > > > > crudini openstack-selinux ansible python-shade puppet-tripleo > > > > python2- > > > > kubernetes && yum clean all && rm -rf /var/cache/yum 276 MB > > > > > > > > Is the additional 276 MB reasonable here? > > > > openstack-selinux <- This package run relabling, does that kind > > > > of > > > > touching the filesystem impact the size due to docker layers? > > > > > > > > Also: python2-kubernetes is a fairly large package (18007990) do > > > > we use > > > > that in every image? I don't see any tripleo related repos > > > > importing > > > > from that when searching on Hound? The original commit message[1] > > > > adding it states it is for future convenience. > > > > > > > > On my undercloud we have 101 images, if we are downloading every > > > > 18 MB > > > > per image thats almost 1.8 GB for a package we don't use? (I hope > > > > it's > > > > not like this? With docker layers, we only download that 276 MB > > > > transaction once? Or?) > > > > > > > > > > > > [1] https://review.openstack.org/527927 > > > > > > > > > -- > > > Best regards, > > > Bogdan Dobrelya, > > > Irc #bogdando > > > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Regards, Sergii Golovatiuk -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From rbrady at redhat.com Wed Nov 28 16:51:32 2018 From: rbrady at redhat.com (Ryan Brady) Date: Wed, 28 Nov 2018 11:51:32 -0500 Subject: [openstack-dev] [tripleo] Workflows Squad changes In-Reply-To: References: Message-ID: On Wed, Nov 28, 2018 at 5:13 AM Jiri Tomasek wrote: > Hi all, > > Recently, the workflows squad has been reorganized and people from the > squad are joining different squads. I would like to discuss how we are > going to adjust to this situation to make sure that tripleo-common > development is not going to be blocked in terms of feature work and reviews. > > With this change, most of the tripleo-common maintenance work goes > naturally to UI & Validations squad as CLI and GUI are the consumers of the > API provided by tripleo-common. Adriano Petrich from workflows squad has > joined UI squad to take on this work. > > As a possible solution, I would like to propose Adriano as a core reviewer > to tripleo-common and adding tripleo-ui cores right to +2 tripleo-common > patches. > > It would be great to hear opinions especially former members of Workflows > squad and regular contributors to tripleo-common on these changes and in > general on how to establish regular reviews and maintenance to ensure that > tripleo-common codebase is moved towards converging the CLI and GUI > deployment workflow. > Well, I'm not really going that far and plan to continue working in tripleo-common for the time being. If that isn't sustainable during the next cycle, I'll make sure to shout. > Thanks > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- RYAN BRADY SENIOR SOFTWARE ENGINEER Red Hat Inc rbrady at redhat.com T: (919)-890-8925 IM: rbrady @redhatway @redhatinc @redhatsnaps -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From jistr at redhat.com Wed Nov 28 17:02:47 2018 From: jistr at redhat.com (=?UTF-8?B?SmnFmcOtIFN0csOhbnNrw70=?=) Date: Wed, 28 Nov 2018 18:02:47 +0100 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> Message-ID: <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> > > Reiterating again on previous points: > > -I'd be fine removing systemd. But lets do it properly and not via 'rpm > -ev --nodeps'. > -Puppet and Ruby *are* required for configuration. We can certainly put > them in a separate container outside of the runtime service containers > but doing so would actually cost you much more space/bandwidth for each > service container. As both of these have to get downloaded to each node > anyway in order to generate config files with our current mechanisms > I'm not sure this buys you anything. +1. I was actually under the impression that we concluded yesterday on IRC that this is the only thing that makes sense to seriously consider. But even then it's not a win-win -- we'd gain some security by leaner production images, but pay for it with space+bandwidth by duplicating image content (IOW we can help achieve one of the goals we had in mind by worsening the situation w/r/t the other goal we had in mind.) Personally i'm not sold yet but it's something that i'd consider if we got measurements of how much more space/bandwidth usage this would consume, and if we got some further details/examples about how serious are the security concerns if we leave config mgmt tools in runtime images. IIRC the other options (that were brought forward so far) were already dismissed in yesterday's IRC discussion and on the reviews. Bin/lib bind mounting being too hacky and fragile, and nsenter not really solving the problem (because it allows us to switch to having different bins/libs available, but it does not allow merging the availability of bins/libs from two containers into a single context). > > We are going in circles here I think.... +1. I think too much of the discussion focuses on "why it's bad to have config tools in runtime images", but IMO we all sorta agree that it would be better not to have them there, if it came at no cost. I think to move forward, it would be interesting to know: if we do this (i'll borrow Dan's drawing): |base container| --> |service container| --> |service container w/ Puppet installed| How much more space and bandwidth would this consume per node (e.g. separately per controller, per compute). This could help with decision making. > > Dan > Thanks Jirka __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From chris at openstack.org Wed Nov 28 17:19:22 2018 From: chris at openstack.org (Chris Hoge) Date: Wed, 28 Nov 2018 09:19:22 -0800 Subject: [loci][tc] Project Technical Leadership Change In-Reply-To: <836FF68B-F3E1-4123-BFD1-80C54977BEBA@openstack.org> References: <4D0C8716-FCBF-4BFD-A3FA-D53BEB7B9A04@openstack.org> <20181127172227.x2juoz4yxb4u35xs@yuggoth.org> <836FF68B-F3E1-4123-BFD1-80C54977BEBA@openstack.org> Message-ID: <1CB7D66A-39E4-41AF-9936-79B9915A3DA2@openstack.org> Somewhat related, I am also nominating Jean-Philippe Evrard to Loci Core. His contributions over the last few months have had a significant and positive impact to the project, and his insight into Suse Leap has extended support to cover Suse as well as Ubuntu and Centos. -Chris > On Nov 27, 2018, at 9:31 AM, Chris Hoge wrote: > > Project update review here: https://review.openstack.org/620370 > >> On Nov 27, 2018, at 9:22 AM, Jeremy Stanley wrote: >> >> Thanks for stepping up! Please propose an update to >> https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml >> so that the TC can officially confirm this interim change of >> leadership. >> -- >> Jeremy Stanley > > From bdobreli at redhat.com Wed Nov 28 17:29:41 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Wed, 28 Nov 2018 18:29:41 +0100 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> Message-ID: On 11/28/18 6:02 PM, Jiří Stránský wrote: > > >> >> Reiterating again on previous points: >> >> -I'd be fine removing systemd. But lets do it properly and not via 'rpm >> -ev --nodeps'. >> -Puppet and Ruby *are* required for configuration. We can certainly put >> them in a separate container outside of the runtime service containers >> but doing so would actually cost you much more space/bandwidth for each >> service container. As both of these have to get downloaded to each node >> anyway in order to generate config files with our current mechanisms >> I'm not sure this buys you anything. > > +1. I was actually under the impression that we concluded yesterday on > IRC that this is the only thing that makes sense to seriously consider. > But even then it's not a win-win -- we'd gain some security by leaner > production images, but pay for it with space+bandwidth by duplicating > image content (IOW we can help achieve one of the goals we had in mind > by worsening the situation w/r/t the other goal we had in mind.) > > Personally i'm not sold yet but it's something that i'd consider if we > got measurements of how much more space/bandwidth usage this would > consume, and if we got some further details/examples about how serious > are the security concerns if we leave config mgmt tools in runtime images. > > IIRC the other options (that were brought forward so far) were already > dismissed in yesterday's IRC discussion and on the reviews. Bin/lib bind > mounting being too hacky and fragile, and nsenter not really solving the > problem (because it allows us to switch to having different bins/libs > available, but it does not allow merging the availability of bins/libs > from two containers into a single context). > >> >> We are going in circles here I think.... > > +1. I think too much of the discussion focuses on "why it's bad to have > config tools in runtime images", but IMO we all sorta agree that it > would be better not to have them there, if it came at no cost. > > I think to move forward, it would be interesting to know: if we do this > (i'll borrow Dan's drawing): > > |base container| --> |service container| --> |service container w/ > Puppet installed| > > How much more space and bandwidth would this consume per node (e.g. > separately per controller, per compute). This could help with decision > making. As I've already evaluated in the related bug, that is: puppet-* modules and manifests ~ 16MB puppet with dependencies ~61MB dependencies of the seemingly largest a dependency, systemd ~190MB that would be an extra layer size for each of the container images to be downloaded/fetched into registries. Given that we should decouple systemd from all/some of the dependencies (an example topic for RDO [0]), that could save a 190MB. But it seems we cannot break the love of puppet and systemd as it heavily relies on the latter and changing packaging like that would higly likely affect baremetal deployments with puppet and systemd co-operating. Long story short, we cannot shoot both rabbits with a single shot, not with puppet :) May be we could with ansible replacing puppet fully... So splitting config and runtime images is the only choice yet to address the raised security concerns. And let's forget about edge cases for now. Tossing around a pair of extra bytes over 40,000 WAN-distributed computes ain't gonna be our the biggest problem for sure. [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction > >> >> Dan >> > > Thanks > > Jirka > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Bogdan Dobrelya, Irc #bogdando From jungleboyj at gmail.com Wed Nov 28 17:40:18 2018 From: jungleboyj at gmail.com (Jay S Bryant) Date: Wed, 28 Nov 2018 11:40:18 -0600 Subject: [nova][cinder] Why can't nova in stein work with cinder from queens? In-Reply-To: <3a1ed017-f9f0-b444-4f56-673c44c3d35f@gmail.com> References: <3a1ed017-f9f0-b444-4f56-673c44c3d35f@gmail.com> Message-ID: <1d3a43e3-e638-180c-3db0-9af3b48fb4d1@gmail.com> Matt, We discussed this in our team meeting today and it appears that the source of the problem is a misunderstanding based on Sean's commit message. Sean had made that comment because we only test N with N-1.  So, that is the only tested configuration.  There is no reason that we know of, however, that using Nova with older versions of Cinder wouldn't work.  Assuming that versioning works the way that it is supposed to, then other combinations should work.  We, however, don't recommend using combinations other than Nova at N and Cinder at N-1 as that is what is tested. Let me know if you have further questions. Thanks! Jay On 11/21/2018 3:11 PM, Matt Riedemann wrote: > A change in nova [1] was approved which makes an assertion that we > (nova? openstack?) do not support running nova from stein with cinder > from queens, and I guess I'd like to know where that support statement > is written down? Granted, I know we don't gate that way but I'm not > aware of anything preventing it from working given we use > microversions and nova, as the client, should be able to work with > cinder from v1, v2 or v3 assuming it's doing version discovery > correctly (which we've been doing in nova since queens when we needed > to start using the cinder v3.44 volume attachments API for multiattach > - but it's not required). > > In fact, nova-api still has compatibility code for older versions of > cinder to determine what it should do about working with volume > attachments [2]. I've been thinking lately about how to drop that code > which would at the very least require a release note saying nova > requires cinder >= queens, but nothing like that was requested in the > change that drops support for cinder v1 from nova and asserts that > nova in stein requires cinder >= queens. > > Maybe I'm just yelling at kids to get off my lawn, but I don't really > want this to be precedent without some discussion because I know at > various times operators have complained about upgrades being hard > because they assume all of the services must be upgraded to the same > release at the same time, and I don't think that is true, or should be > true, because if it is, we're doing a really bad job of defining > versioned interfaces between the services. > > [1] https://review.openstack.org/#/c/617927/ > [2] > https://github.com/openstack/nova/blob/7217e38bafb75e8a613763835b64e48e6b2c8ece/nova/compute/api.py#L4260-L4264 > From gael.therond at gmail.com Wed Nov 28 18:04:22 2018 From: gael.therond at gmail.com (=?UTF-8?Q?Ga=C3=ABl_THEROND?=) Date: Wed, 28 Nov 2018 19:04:22 +0100 Subject: [OCTAVIA] How to monitor amphora In-Reply-To: References: Message-ID: Hi everyone, Sorry for this late answer, I’ve been quite busy this week finalizing our Octavia deployment. Sure Trinh, whenever you want, I’ll be happy to help on this topic. Michael, Adam, I’m glad to see that some of you already started to think about that topic, I’ll be happy to help with any required documentation/redaction. I can’t work on code for now as I honestly don’t get allocated time for that currently as we’re in a launch period, but for sure as our company is fairly large and worldwide spanned I can humbly give you feedback about our expectations etc. Kind regards, G. Le mar. 27 nov. 2018 à 01:44, Trinh Nguyen a écrit : > Hi Gaël, > > The Searchlight team has submitted a blueprint to add support for Octavia > [1]. If it's something you're interested in, please let me know so I can > ping you for comments? > > [1] https://storyboard.openstack.org/#!/story/2004383 > > Bests, > > On Mon, Nov 26, 2018 at 3:46 PM Gaël THEROND > wrote: > >> Hi! >> >> I’ve taken some time to read your presentation and I have to say thank >> you for your wonderful work ! It’s pretty much complete and with code >> example which is really cool. >> >> It’s exactly what I was looking for. >> If I could just suggest one thing, it would be to give operators freedom >> to choose which logging and which metrics clients they want to use. >> >> Doing so would avoid having to rely on gnocchi as you would be able to >> choose the clients type at amphora build time and specify clients target at >> runtime using the amphora-agent. >> >> On another hand, it might we’ll be tricky to do so as everything is >> namespaced into the amphora instance. >> >> As suggested using gnocchi to store HAProxy logs may well be the easiest >> short path actually, I’m wondering if it would be possible for searchlight >> to use that logs at some point. >> >> Anyway, thanks for the awesome job. >> For now I’ll keep it simple and just use the API for basic status. >> >> Kind regards, >> G. >> >> Le lun. 26 nov. 2018 à 04:23, Sa Pham a écrit : >> >>> yes. I have discussed with the Octavia team. PTL Johnson has suggested >>> me to use gnocchi to store octavia amphora metric. >>> >>> >>> >>> On Wed, Nov 21, 2018 at 3:16 PM Gaël THEROND >>> wrote: >>> >>>> Hi! Thanks for this material, I’ll have a look at it. >>>> >>>> As our philosophy at work is to always push upstream all our >>>> patchs/features or bug fixes, I won’t modify and keep the source code on >>>> our own and if we need further features like that I think we will rather >>>> push for a Blueprint with all required commits. >>>> >>>> Did you already discussed that topic with the Octavia team? >>>> >>>> Thanks a lot. >>>> >>>> Le mer. 21 nov. 2018 à 09:12, Sa Pham a écrit : >>>> >>>>> Hi, >>>>> >>>>> In Vietnam Openinfra Days 2018, I have a presentation about monitoring >>>>> and logging for Octavia Amphora. We have to customize octavia source code >>>>> to do this. I send you my presentation slide: >>>>> >>>>> https://drive.google.com/file/d/1dHXExEKrHDg4Cf3D1fBeulLDW_G-txLr/view?usp=sharing >>>>> >>>>> Best, >>>>> >>>>> On Wed, Nov 21, 2018 at 3:05 PM Gaël THEROND >>>>> wrote: >>>>> >>>>>> Hi guys, >>>>>> >>>>>> As already discussed I had to test Octavia as our corporate >>>>>> LoadBalancer solution and it was a success. >>>>>> >>>>>> Thank to everyone on this list that assisted me and especially >>>>>> Michael Octavia is fully working and without weird nightmare glitches. >>>>>> >>>>>> Now that I validated the technical part of my project, I need to >>>>>> enter more operationals questions such as what’s the best way to monitor >>>>>> and log amphora? >>>>>> >>>>>> I would like to be able to get a monitoring and logging agent >>>>>> installed on the amphora in order to get proper metrics about what’s going >>>>>> on with the LoadBalancer, is it fully cpu loaded? Is it using all network >>>>>> resources available, are the file descriptors near the initial limits? How >>>>>> much xxx HTTP return code the loadBalancer is facing and send those logs to >>>>>> an ELK or something similar. >>>>>> >>>>>> Do you know if that something that I could achieve by adding more >>>>>> elements to the image at DIB time or are there any other better >>>>>> best-practices that I should be aware of ? >>>>>> >>>>>> As Octavia is creating a namespace for each HAProxy process, I am >>>>>> wandering if it’s even possible. >>>>>> >>>>>> Thanks a lot for your hard work guys. >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Sa Pham Dang >>>>> Cloud RnD Team - VCCloud >>>>> Phone/Telegram: 0986.849.582 >>>>> Skype: great_bn >>>>> >>>>> >>>>> >>> >>> -- >>> Sa Pham Dang >>> Cloud RnD Team - VCCloud >>> Phone/Telegram: 0986.849.582 >>> Skype: great_bn >>> >>> >>> > > -- > *Trinh Nguyen* > *www.edlab.xyz * > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Wed Nov 28 18:18:13 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 28 Nov 2018 12:18:13 -0600 Subject: [nova][cinder] Why can't nova in stein work with cinder from queens? In-Reply-To: <1d3a43e3-e638-180c-3db0-9af3b48fb4d1@gmail.com> References: <3a1ed017-f9f0-b444-4f56-673c44c3d35f@gmail.com> <1d3a43e3-e638-180c-3db0-9af3b48fb4d1@gmail.com> Message-ID: On 11/28/2018 11:40 AM, Jay S Bryant wrote: > We discussed this in our team meeting today and it appears that the > source of the problem is a misunderstanding based on Sean's commit message. > > Sean had made that comment because we only test N with N-1.  So, that is > the only tested configuration.  There is no reason that we know of, > however, that using Nova with older versions of Cinder wouldn't work. > Assuming that versioning works the way that it is supposed to, then > other combinations should work.  We, however, don't recommend using > combinations other than Nova at N and Cinder at N-1 as that is what is > tested. > > Let me know if you have further questions. Cool, thanks Sean/Jay for discussing it. As noted in the original email, I want to remove the old Cinder Queens compat code from the compute API in Stein anyway, so I plan on doing *something* there, at least dropping it and providing a release note - at most maybe a nova-status upgrade check to make sure Cinder 3.44 is available before upgrading to Stein. -- Thanks, Matt From james.slagle at gmail.com Wed Nov 28 18:28:59 2018 From: james.slagle at gmail.com (James Slagle) Date: Wed, 28 Nov 2018 13:28:59 -0500 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> Message-ID: On Wed, Nov 28, 2018 at 12:31 PM Bogdan Dobrelya wrote: > Long story short, we cannot shoot both rabbits with a single shot, not > with puppet :) May be we could with ansible replacing puppet fully... > So splitting config and runtime images is the only choice yet to address > the raised security concerns. And let's forget about edge cases for now. > Tossing around a pair of extra bytes over 40,000 WAN-distributed > computes ain't gonna be our the biggest problem for sure. I think it's this last point that is the crux of this discussion. We can agree to disagree about the merits of this proposal and whether it's a pre-optimzation or micro-optimization, which I admit are somewhat subjective terms. Ultimately, it seems to be about the "why" do we need to do this as to the reason why the conversation seems to be going in circles a bit. I'm all for reducing container image size, but the reality is that this proposal doesn't necessarily help us with the Edge use cases we are talking about trying to solve. Why would we even run the exact same puppet binary + manifest individually 40,000 times so that we can produce the exact same set of configuration files that differ only by things such as IP address, hostnames, and passwords? Maybe we should instead be thinking about how we can do that *1* time centrally, and produce a configuration that can be reused across 40,000 nodes with little effort. The opportunity for a significant impact in terms of how we can scale TripleO is much larger if we consider approaching these problems with a wider net of what we could do. There's opportunity for a lot of better reuse in TripleO, configuration is just one area. The plan and Heat stack (within the ResourceGroup) are some other areas. At the same time, if some folks want to work on smaller optimizations (such as container image size), with an approach that can be agreed upon, then they should do so. We just ought to be careful about how we justify those changes so that we can carefully weigh the effort vs the payoff. In this specific case, I don't personally see this proposal helping us with Edge use cases in a meaningful way given the scope of the changes. That's not to say there aren't other use cases that could justify it though (such as the security points brought up earlier). -- -- James Slagle -- From cdent+os at anticdent.org Wed Nov 28 18:42:45 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Wed, 28 Nov 2018 18:42:45 +0000 (GMT) Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> Message-ID: On Wed, 28 Nov 2018, James Slagle wrote: > Why would we even run the exact same puppet binary + manifest > individually 40,000 times so that we can produce the exact same set of > configuration files that differ only by things such as IP address, > hostnames, and passwords? This has been my confusion and question throughout this entire thread. It sounds like containers are being built (and configured) at something akin to runtime, instead of built once and then configured (only) at runtime. Isn't it more the "norm" to, when there's a security fix, build again, once, and cause the stuff at edge (keeping its config) to re-instantiate fetching newly built stuff? Throughout the discussion I've been assuming I must be missing some critical detail because isn't the whole point to have immutable stuff? Maybe it is immutable and you all are talking about it in ways that make it seem otherwise. I dunno. I suspect I am missing some bit of operational experience. In any case, the "differ only by things..." situation is exactly why I added the get-config-from-environment support to oslo.config, so that the different bits can be in the orchestrator, not the containers themselves. More on that at: http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000173.html -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From aschultz at redhat.com Wed Nov 28 19:27:42 2018 From: aschultz at redhat.com (Alex Schultz) Date: Wed, 28 Nov 2018 12:27:42 -0700 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> Message-ID: On Wed, Nov 28, 2018 at 11:44 AM Chris Dent wrote: > > On Wed, 28 Nov 2018, James Slagle wrote: > > > Why would we even run the exact same puppet binary + manifest > > individually 40,000 times so that we can produce the exact same set of > > configuration files that differ only by things such as IP address, > > hostnames, and passwords? > > This has been my confusion and question throughout this entire > thread. It sounds like containers are being built (and configured) at > something akin to runtime, instead of built once and then configured > (only) at runtime. Isn't it more the "norm" to, when there's a security > fix, build again, once, and cause the stuff at edge (keeping its config) > to re-instantiate fetching newly built stuff? > No we aren't building container items, we're building configurations. The way it work s in tripleo is that we use the same containers to generate the configurations as we do to run the services themselves. These configurations are mounted off the host as to not end up in the container. This is primarily because things like the puppet modules assume certain chunks of software/configuration files exist. So we're generating the configuration files to be mounted into the run time container. The puppet providers are extremely mature and allow for in place editing and no templates which is how we can get away with this in containers. The containers themselves are not build or modified on the fly in this case. IMHO this is a side effect of configurations (files) for openstack services and their service dependencies where we need to somehow inject the running config into the container rather than being able to load it from an external source (remember the etcd oslo stuff from a few cycles ago?). Our problem is our reliance on puppet due to existing established configuration patterns and the sheer amount of code required to configure openstack & company. So we end up having to carry these package dependencies in the service containers because that's where we generate the configs. There are additional dependencies on being able to know about hardware specifics (facts) that come into play with the configurations such that we may not be able to generate the configs off the deployment host and just ship those with the containers. > Throughout the discussion I've been assuming I must be missing some > critical detail because isn't the whole point to have immutable > stuff? Maybe it is immutable and you all are talking about it in > ways that make it seem otherwise. I dunno. I suspect I am missing > some bit of operational experience. > The application is immutable, but the configs need to be generated depending on where they end up or the end users desired configuration. For some service that includes pulling in some information about the host and including that (SRIOV, pci, etc). > In any case, the "differ only by things..." situation is exactly why > I added the get-config-from-environment support to oslo.config, so > that the different bits can be in the orchestrator, not the > containers themselves. More on that at: > > http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000173.html > Given the vast amount of configurations exposed in each service, i'm not sure environment variables help here. Additionally that doesn't solve for non-oslo services (mysql/rabbitmq/etc) so then you'd end up having two ways of having to configure the containers/services. > -- > Chris Dent ٩◔̯◔۶ https://anticdent.org/ > freenode: cdent tw: @anticdent From doug at doughellmann.com Wed Nov 28 19:55:14 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 28 Nov 2018 14:55:14 -0500 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> Message-ID: <98BA1205-9F08-4B0F-8F3A-EAB2058F518A@doughellmann.com> > On Nov 28, 2018, at 2:27 PM, Alex Schultz wrote: > >> On Wed, Nov 28, 2018 at 11:44 AM Chris Dent wrote: >> >>> On Wed, 28 Nov 2018, James Slagle wrote: >>> >>> Why would we even run the exact same puppet binary + manifest >>> individually 40,000 times so that we can produce the exact same set of >>> configuration files that differ only by things such as IP address, >>> hostnames, and passwords? >> >> This has been my confusion and question throughout this entire >> thread. It sounds like containers are being built (and configured) at >> something akin to runtime, instead of built once and then configured >> (only) at runtime. Isn't it more the "norm" to, when there's a security >> fix, build again, once, and cause the stuff at edge (keeping its config) >> to re-instantiate fetching newly built stuff? >> > > No we aren't building container items, we're building configurations. > The way it work s in tripleo is that we use the same containers to > generate the configurations as we do to run the services themselves. > These configurations are mounted off the host as to not end up in the > container. This is primarily because things like the puppet modules > assume certain chunks of software/configuration files exist. So we're > generating the configuration files to be mounted into the run time > container. The puppet providers are extremely mature and allow for in > place editing and no templates which is how we can get away with this > in containers. The containers themselves are not build or modified on > the fly in this case. > > IMHO this is a side effect of configurations (files) for openstack > services and their service dependencies where we need to somehow > inject the running config into the container rather than being able to > load it from an external source (remember the etcd oslo stuff from a > few cycles ago?). I thought the preferred solution for more complex settings was config maps. Did that approach not work out? Regardless, now that the driver work is done if someone wants to take another stab at etcd integration it’ll be more straightforward today. Doug From smooney at redhat.com Wed Nov 28 21:18:44 2018 From: smooney at redhat.com (Sean Mooney) Date: Wed, 28 Nov 2018 21:18:44 +0000 Subject: [ops] [nova] How to get CPUtime and wallclokctime consumed by a project (without using ceilometer) ? In-Reply-To: <30e17c26-3ead-02f0-1222-cc5f1f23e696@gmail.com> References: <30e17c26-3ead-02f0-1222-cc5f1f23e696@gmail.com> Message-ID: On Wed, 2018-11-28 at 12:14 -0500, Jay Pipes wrote: > On 11/28/2018 10:38 AM, Massimo Sgaravatto wrote: > > Hi > > > > I was wondering if nova allows to get the CPUtime and wallclocktime > > consumed by a project in a certain time period, without using ceilometer > > > > Among the data returned by the command "openstack usage show" there is > > also a "CPU Hours" but, if I am not wrong, this is actually the > > WallClockTime. Did I get it right ? > > It's neither. It's the calculated time that the VM has been "up" > multiplied by the number of vCPUs the VM consumes. > > It's basically worthless as anything more than a simplistic indicator of > rough resource consumption. > > You can see how the calculation is done by following the fairly > convoluted code in the os-simple-tenant-usage API: > > This calculates the "hours used": > > https://github.com/openstack/nova/blob/62245235bc15da6abcdfd3df1c24bd856d69fbb4/nova/api/openstack/compute/simple_tena > nt_usage.py#L51-L82 > > And here is where that is multiplied by the VM's vCPUs: > > https://github.com/openstack/nova/blob/62245235bc15da6abcdfd3df1c24bd856d69fbb4/nova/api/openstack/compute/simple_tena > nt_usage.py#L213 > > > If so, it is also possible to get the CPUTime ? > > If you are referring to getting the amount of time a *physical host CPU* > has spent performing tasks for a particular VM, the closest you can get > to this would be the "server diagnostics" API: > > https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/views/server_diagnostics.py > > That said, the server diagnostics API is a very thin shim over a > virt-driver-specific interface: > > https://github.com/openstack/nova/blob/62245235bc15da6abcdfd3df1c24bd856d69fbb4/nova/compute/manager.py#L4698 > > The libvirt driver's get_server_diagnostics() (host-specific) and > get_instance_diagnostics() (VM-specific) implementation is here: > > https://github.com/openstack/nova/blob/62245235bc15da6abcdfd3df1c24bd856d69fbb4/nova/virt/libvirt/driver.py#L8543-L867 > 8 > > You might want to look at that code and implement a simple > collectd/statsd/fluentd/telegraf collector to grab those stats directly if you go the collectd route the libvirt plugin was modifed about 2 years ago to be able to use the domain uuid instaed the domain instance name when reporting stats and since we set the domain uuid to the nova uuid it makes it really easy to map back to the instance later. so ihink the colloectd libvirt plugin may be able to give you this info already and you can then just export that ot influxdb or gnnoci use later. the other monitoring solution can proably do the same but nova does not really track vm cpu usage that closely. > from the libvirt daemon on the compute nodes themselves. > > Best, > -jay > From dprince at redhat.com Wed Nov 28 22:22:56 2018 From: dprince at redhat.com (Dan Prince) Date: Wed, 28 Nov 2018 17:22:56 -0500 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> Message-ID: <5cbe32fb549b2e107a57aa3c13d4451a6fc6a35e.camel@redhat.com> On Wed, 2018-11-28 at 13:28 -0500, James Slagle wrote: > On Wed, Nov 28, 2018 at 12:31 PM Bogdan Dobrelya > wrote: > > Long story short, we cannot shoot both rabbits with a single shot, > > not > > with puppet :) May be we could with ansible replacing puppet > > fully... > > So splitting config and runtime images is the only choice yet to > > address > > the raised security concerns. And let's forget about edge cases for > > now. > > Tossing around a pair of extra bytes over 40,000 WAN-distributed > > computes ain't gonna be our the biggest problem for sure. > > I think it's this last point that is the crux of this discussion. We > can agree to disagree about the merits of this proposal and whether > it's a pre-optimzation or micro-optimization, which I admit are > somewhat subjective terms. Ultimately, it seems to be about the "why" > do we need to do this as to the reason why the conversation seems to > be going in circles a bit. > > I'm all for reducing container image size, but the reality is that > this proposal doesn't necessarily help us with the Edge use cases we > are talking about trying to solve. > > Why would we even run the exact same puppet binary + manifest > individually 40,000 times so that we can produce the exact same set > of > configuration files that differ only by things such as IP address, > hostnames, and passwords? Maybe we should instead be thinking about > how we can do that *1* time centrally, and produce a configuration > that can be reused across 40,000 nodes with little effort. The > opportunity for a significant impact in terms of how we can scale > TripleO is much larger if we consider approaching these problems with > a wider net of what we could do. There's opportunity for a lot of > better reuse in TripleO, configuration is just one area. The plan and > Heat stack (within the ResourceGroup) are some other areas. We run Puppet for configuration because that is what we did on baremetal and we didn't break backwards compatability for our configuration options for upgrades. Our Puppet model relies on being executed on each local host in order to splice in the correct IP address and hostname. It executes in a distributed fashion, and works fairly well considering the history of the project. It is robust, guarantees no duplicate configs are being set, and is backwards compatible with all the options TripleO supported on baremetal. Puppet is arguably better for configuration than Ansible (which is what I hear people most often suggest we replace it with). It suits our needs fine, but it is perhaps a bit overkill considering we are only generating config files. I think the answer here is moving to something like Etcd. Perhaps skipping over Ansible entirely as a config management tool (it is arguably less capable than Puppet in this category anyway). Or we could use Ansible for "legacy" services only, switch to Etcd for a majority of the OpenStack services, and drop Puppet entirely (my favorite option). Consolidating our technology stack would be wise. We've already put some work and analysis into the Etcd effort. Just need to push on it some more. Looking at the previous Kubernetes prototypes for TripleO would be the place to start. Config management migration is going to be tedious. Its technical debt that needs to be handled at some point anyway. I think it is a general TripleO improvement that could benefit all clouds, not just Edge. Dan > > At the same time, if some folks want to work on smaller optimizations > (such as container image size), with an approach that can be agreed > upon, then they should do so. We just ought to be careful about how > we > justify those changes so that we can carefully weigh the effort vs > the > payoff. In this specific case, I don't personally see this proposal > helping us with Edge use cases in a meaningful way given the scope of > the changes. That's not to say there aren't other use cases that > could > justify it though (such as the security points brought up earlier). > From duc.openstack at gmail.com Wed Nov 28 23:38:08 2018 From: duc.openstack at gmail.com (Duc Truong) Date: Wed, 28 Nov 2018 15:38:08 -0800 Subject: [all][ptl][heat][senlin][magnum]New SIG for Autoscaling? plus Session Summary: Autoscaling Integration, improvement, and feedback In-Reply-To: References: Message-ID: On Wed, Nov 28, 2018 at 4:00 AM Rico Lin wrote: > > We have a plan to create a new SIG for autoscaling which to cover > the common library, docs, and tests for cross-project services > (Senlin, Heat, Monasca, etc.) and cross-community (OpenStack, > Kubernetes, etc). Thanks for getting this started, Rico. One comment I have is that I would like to avoid including the term 'common library' in the scope or goal of this SIG. Rather I would like this SIG to drive the discussion towards a common autoscaling solution. Whether this solution is a common library or something else will be the outcome of the discussion in this SIG. > For example, we can have a document about do autoscaling in > OpenStack, but we need a place to put it and keep maintain it. > And we can even have a place to set up CI to test all scenario for > autoscaling. +1 for documenting the current state of autoscaling and creating autoscaling scenario tests. Another goal of this SIG should be to gather user/operator feedback and document the autoscaling use cases. Regards, Duc (dtruong) From mriedemos at gmail.com Thu Nov 29 00:05:51 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 28 Nov 2018 18:05:51 -0600 Subject: [nova] Heads up on default policy change for zero-disk flavors Message-ID: <723c191f-3a85-289a-54cd-44d5330d4606@gmail.com> Coming back to a security bug there is a change in nova [1] in Stein to change the value on the "os_compute_api:servers:create:zero_disk_flavor" policy rule to make it admin-only by default. This makes server create fail for non-admins users who are using flavors with root_gb=0 *unless* they are booting from volume. If you already have this configuration set before upgrading to stein then your deployment tooling shouldn't overwrite the configured policy and you won't notice any changes, but if you have an empty policy file and upgrade and have 0 root_gb flavors, your users could see server create failures. Let us know if you have any issues with this, or would like to see something done in the way of further documentation/communication and/or a nova-status upgrade check. [1] https://review.openstack.org/#/c/603910/ -- Thanks, Matt From berndbausch at gmail.com Thu Nov 29 03:57:05 2018 From: berndbausch at gmail.com (Bernd Bausch) Date: Thu, 29 Nov 2018 12:57:05 +0900 Subject: [glance] Interoperable Image Import: Plugin configuration ignored Message-ID: Exploring image import on Rocky. My cloud is a Devstack. To permit image import, I modified it so that it runs Glance not as uwsgi processes behind Apache, but as standalone processes. The glance-direct image import process (create, stage, import) works - except that the configured plugin is simply ignored. /etc/glance/glance-image-import.conf: [image_import_opts] image_import_plugins = [inject_image_metadata] [inject_metadata_properties] inject = "import-type":"user-import" ignore_user_roles = admin /etc/glance/policy.json contains:     "get_task": "",     "get_tasks": "",     "add_task": "",     "modify_task": "",     "tasks_api_access": "role:admin", Yet imported images are lacking the configured metadata. I added a few LOG calls. get_import_plugins() in glance/async/flows/plugins/__init__.py tells me that image_import_plugins = []. It looks like the configuration in glance-image-import.conf is ignored or not read at all. How can I find out what I am doing wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3609 bytes Desc: S/MIME Cryptographic Signature URL: From sbauza at redhat.com Thu Nov 29 06:48:29 2018 From: sbauza at redhat.com (Sylvain Bauza) Date: Thu, 29 Nov 2018 07:48:29 +0100 Subject: [openstack-dev] [nova] Stein forum session notes In-Reply-To: <73e6cd98-ebba-1e67-9c48-032fac04946c@gmail.com> References: <9614718a-77d4-f9ca-a7ba-73bc9af28795@gmail.com> <69ad0921-852a-3eaa-9f34-293a30766fdb@gmail.com> <73e6cd98-ebba-1e67-9c48-032fac04946c@gmail.com> Message-ID: Le lun. 26 nov. 2018 à 18:03, Matt Riedemann a écrit : > On 11/26/2018 10:55 AM, Jay Pipes wrote: > > What was news to me was the "has been done already" part of the Lab test > > for vGPU upgrade. > > > > I was asking for information on where I can see that Lab test. > > Oh, heh. It's in Sylvain's brain somewhere. > +Oops sorry about the reply delay I surely miscommunicated this when I tested it. Like Sean said, I proceeded with an existing instance, restarting the Compute service and then asking again for a VGPU flavor. I can try to find the pastebin or just test it again, it should be easy. -Sylvain > > -- > > Thanks, > > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdobreli at redhat.com Thu Nov 29 09:28:27 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Thu, 29 Nov 2018 10:28:27 +0100 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <5cbe32fb549b2e107a57aa3c13d4451a6fc6a35e.camel@redhat.com> References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> <5cbe32fb549b2e107a57aa3c13d4451a6fc6a35e.camel@redhat.com> Message-ID: On 11/28/18 8:55 PM, Doug Hellmann wrote: > I thought the preferred solution for more complex settings was config maps. Did that approach not work out? > > Regardless, now that the driver work is done if someone wants to take another stab at etcd integration it’ll be more straightforward today. > > Doug > While sharing configs is a feasible option to consider for large scale configuration management, Etcd only provides a strong consistency, which is also known as "Unavailable" [0]. For edge scenarios, to configure 40,000 remote computes over WAN connections, we'd rather want instead weaker consistency models, like "Sticky Available" [0]. That would allow services to fetch their configuration either from a central "uplink" or locally as well, when the latter is not accessible from remote edge sites. Etcd cannot provide 40,000 local endpoints to fit that case I'm afraid, even if those would be read only replicas. That is also something I'm highlighting in the paper [1] drafted for ICFC-2019. But had we such a sticky available key value storage solution, we would indeed have solved the problem of multiple configuration management system execution for thousands of nodes as James describes it. [0] https://jepsen.io/consistency [1] https://github.com/bogdando/papers-ieee/blob/master/ICFC-2019/LaTeX/position_paper_1570506394.pdf On 11/28/18 11:22 PM, Dan Prince wrote: > On Wed, 2018-11-28 at 13:28 -0500, James Slagle wrote: >> On Wed, Nov 28, 2018 at 12:31 PM Bogdan Dobrelya >> wrote: >>> Long story short, we cannot shoot both rabbits with a single shot, >>> not >>> with puppet :) May be we could with ansible replacing puppet >>> fully... >>> So splitting config and runtime images is the only choice yet to >>> address >>> the raised security concerns. And let's forget about edge cases for >>> now. >>> Tossing around a pair of extra bytes over 40,000 WAN-distributed >>> computes ain't gonna be our the biggest problem for sure. >> >> I think it's this last point that is the crux of this discussion. We >> can agree to disagree about the merits of this proposal and whether >> it's a pre-optimzation or micro-optimization, which I admit are >> somewhat subjective terms. Ultimately, it seems to be about the "why" >> do we need to do this as to the reason why the conversation seems to >> be going in circles a bit. >> >> I'm all for reducing container image size, but the reality is that >> this proposal doesn't necessarily help us with the Edge use cases we >> are talking about trying to solve. >> >> Why would we even run the exact same puppet binary + manifest >> individually 40,000 times so that we can produce the exact same set >> of >> configuration files that differ only by things such as IP address, >> hostnames, and passwords? Maybe we should instead be thinking about >> how we can do that *1* time centrally, and produce a configuration >> that can be reused across 40,000 nodes with little effort. The >> opportunity for a significant impact in terms of how we can scale >> TripleO is much larger if we consider approaching these problems with >> a wider net of what we could do. There's opportunity for a lot of >> better reuse in TripleO, configuration is just one area. The plan and >> Heat stack (within the ResourceGroup) are some other areas. > > We run Puppet for configuration because that is what we did on > baremetal and we didn't break backwards compatability for our > configuration options for upgrades. Our Puppet model relies on being > executed on each local host in order to splice in the correct IP > address and hostname. It executes in a distributed fashion, and works > fairly well considering the history of the project. It is robust, > guarantees no duplicate configs are being set, and is backwards > compatible with all the options TripleO supported on baremetal. Puppet > is arguably better for configuration than Ansible (which is what I hear > people most often suggest we replace it with). It suits our needs fine, > but it is perhaps a bit overkill considering we are only generating > config files. > > I think the answer here is moving to something like Etcd. Perhaps Not Etcd I think, see my comment above. But you're absolutely right Dan. > skipping over Ansible entirely as a config management tool (it is > arguably less capable than Puppet in this category anyway). Or we could > use Ansible for "legacy" services only, switch to Etcd for a majority > of the OpenStack services, and drop Puppet entirely (my favorite > option). Consolidating our technology stack would be wise. > > We've already put some work and analysis into the Etcd effort. Just > need to push on it some more. Looking at the previous Kubernetes > prototypes for TripleO would be the place to start. > > Config management migration is going to be tedious. Its technical debt > that needs to be handled at some point anyway. I think it is a general > TripleO improvement that could benefit all clouds, not just Edge. > > Dan > >> >> At the same time, if some folks want to work on smaller optimizations >> (such as container image size), with an approach that can be agreed >> upon, then they should do so. We just ought to be careful about how >> we >> justify those changes so that we can carefully weigh the effort vs >> the >> payoff. In this specific case, I don't personally see this proposal >> helping us with Edge use cases in a meaningful way given the scope of >> the changes. That's not to say there aren't other use cases that >> could >> justify it though (such as the security points brought up earlier). >> > -- Best regards, Bogdan Dobrelya, Irc #bogdando From witold.bedyk at est.fujitsu.com Thu Nov 29 09:32:17 2018 From: witold.bedyk at est.fujitsu.com (Bedyk, Witold) Date: Thu, 29 Nov 2018 09:32:17 +0000 Subject: [all][ptl][heat][senlin][magnum]New SIG for Autoscaling? plus Session Summary: Autoscaling Integration, improvement, and feedback In-Reply-To: References: Message-ID: Hi Rico, Thanks for this initiative. I think the SIG could be a good channel to coordinate this work across the projects. From Monasca perspective, I would like to make sure that we provide all necessary monitoring data to cover the defined use cases and that Monasca alarms can be seamlessly consumed by the integrated services. We’re also interested in contributing documentation in the central place. I’m sure operators will be thankful for having a channel for providing dedicated feedback. Cheers Witek -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdent+os at anticdent.org Thu Nov 29 10:29:20 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Thu, 29 Nov 2018 10:29:20 +0000 (GMT) Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> Message-ID: On Wed, 28 Nov 2018, Alex Schultz wrote: [stuff where I'm clearly in over my head, am missing critical context, and don't know what I'm talking about, so just gonna stay out, deleted] >> Throughout the discussion I've been assuming I must be missing some >> critical detail because isn't the whole point to have immutable >> stuff? Maybe it is immutable and you all are talking about it in >> ways that make it seem otherwise. I dunno. I suspect I am missing >> some bit of operational experience. > > The application is immutable, but the configs need to be generated > depending on where they end up or the end users desired configuration. > For some service that includes pulling in some information about the > host and including that (SRIOV, pci, etc). Presumably most of the config is immutable as well and there are only a (relatively) small number of per-instance-of-thing differences? > Given the vast amount of configurations exposed in each service, i'm > not sure environment variables help here. Additionally that doesn't > solve for non-oslo services (mysql/rabbitmq/etc) so then you'd end up > having two ways of having to configure the containers/services. The idea is for the environment variables to only be used for the small number of differences, not everything. As what amount to overrides. What I'm trying to understand is why this trope of container management doesn't apply here: A: How do I manage configuration _in_ my containers? B: Don't. A: ? B: Manage it from the outside, tell the container its config when it starts. If the config needs to change, start a new container. I'm pretty sure this isn't really germane to the original point of this thread, so apologies for adding to the noise, but it was hard to resist. I'll try harder. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From thierry at openstack.org Thu Nov 29 10:38:31 2018 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 29 Nov 2018 11:38:31 +0100 Subject: [loci] Release management for LOCI Message-ID: Hi, loci folks, The release management team has been conducting a review of OpenStack official deliverables, to make sure nothing was falling between the cracks release-management-wise. As part of that review, we added a "release-management:" key to deliverables defined in the project governance repository in case they were not to be handled by the release management team using the openstack/releases repository. For example, some deliverables (like docs) are continuously published and therefore marked "release-management:none". Others (like charms) are released manually on 3rd-party platforms and therefore marked "release-management:external". In that context, the situation of the loci deliverable (openstack/loci repository) is unclear. Is it: 1. meant to be released through the openstack/releases repository, but just not ready yet (any hint of when it will be ?) 2. not meant to be "released" or tagged but more like continuously published (in which case we should add "release-management:none" to it) 3. meant to be released, but on a 3rd-party platform like the Docker Hub and not using openstack/releases to drive it (in which case we should add "release-management:external" to it) From previous discussions it appears (2) would best describe the loci situation, but I wanted to doublecheck it was still the case. Thanks, -- Thierry Carrez (ttx) From tobias.urdin at binero.se Thu Nov 29 10:38:45 2018 From: tobias.urdin at binero.se (Tobias Urdin) Date: Thu, 29 Nov 2018 11:38:45 +0100 Subject: [openstack-dev] [puppet] [stable] Deprecation of newton branches In-Reply-To: References: <2ae10ca2-8c77-ccbc-c009-a22c1d3cfd69@binero.se> Message-ID: Hello, This got lost way down in my mailbox. I think we have a consensus about getting rid of the newton branches. Does anybody in Stable release team have time to deprecate the stable/newton branches? Best regards Tobias On 11/19/2018 06:21 PM, Alex Schultz wrote: > On Mon, Nov 19, 2018 at 1:18 AM Tobias Urdin wrote: >> Hello, >> >> We've been talking for a while about the deprecation and removal of the >> stable/newton branches. >> I think it's time now that we get rid of them, we have no open patches >> and Newton is considered EOL. >> >> Could cores get back with a quick feedback and then the stable team can >> get rid of those whenever they have time. >> > yes please. let's EOL them > >> Best regards >> Tobias >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From massimo.sgaravatto at gmail.com Thu Nov 29 10:57:40 2018 From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto) Date: Thu, 29 Nov 2018 11:57:40 +0100 Subject: [ops] [nova] How to get CPUtime and wallclokctime consumed by a project (without using ceilometer) ? In-Reply-To: References: <30e17c26-3ead-02f0-1222-cc5f1f23e696@gmail.com> Message-ID: Thanks a lot for the useful information ! Cheers, Massimo On Wed, Nov 28, 2018 at 10:20 PM Sean Mooney wrote: > On Wed, 2018-11-28 at 12:14 -0500, Jay Pipes wrote: > > On 11/28/2018 10:38 AM, Massimo Sgaravatto wrote: > > > Hi > > > > > > I was wondering if nova allows to get the CPUtime and wallclocktime > > > consumed by a project in a certain time period, without using > ceilometer > > > > > > Among the data returned by the command "openstack usage show" there is > > > also a "CPU Hours" but, if I am not wrong, this is actually the > > > WallClockTime. Did I get it right ? > > > > It's neither. It's the calculated time that the VM has been "up" > > multiplied by the number of vCPUs the VM consumes. > > > > It's basically worthless as anything more than a simplistic indicator of > > rough resource consumption. > > > > You can see how the calculation is done by following the fairly > > convoluted code in the os-simple-tenant-usage API: > > > > This calculates the "hours used": > > > > > https://github.com/openstack/nova/blob/62245235bc15da6abcdfd3df1c24bd856d69fbb4/nova/api/openstack/compute/simple_tena > > nt_usage.py#L51-L82 > > > > And here is where that is multiplied by the VM's vCPUs: > > > > > https://github.com/openstack/nova/blob/62245235bc15da6abcdfd3df1c24bd856d69fbb4/nova/api/openstack/compute/simple_tena > > nt_usage.py#L213 > > > > > If so, it is also possible to get the CPUTime ? > > > > If you are referring to getting the amount of time a *physical host CPU* > > has spent performing tasks for a particular VM, the closest you can get > > to this would be the "server diagnostics" API: > > > > > https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/views/server_diagnostics.py > > > > That said, the server diagnostics API is a very thin shim over a > > virt-driver-specific interface: > > > > > https://github.com/openstack/nova/blob/62245235bc15da6abcdfd3df1c24bd856d69fbb4/nova/compute/manager.py#L4698 > > > > The libvirt driver's get_server_diagnostics() (host-specific) and > > get_instance_diagnostics() (VM-specific) implementation is here: > > > > > https://github.com/openstack/nova/blob/62245235bc15da6abcdfd3df1c24bd856d69fbb4/nova/virt/libvirt/driver.py#L8543-L867 > > 8 > > > > You might want to look at that code and implement a simple > > collectd/statsd/fluentd/telegraf collector to grab those stats directly > if you go the collectd route the libvirt plugin was modifed about 2 years > ago to be able to use the domain uuid > instaed the domain instance name when reporting stats and since we set the > domain uuid to the nova uuid it makes it > really easy to map back to the instance later. so ihink the colloectd > libvirt plugin may be able to give you this info > already and you can then just export that ot influxdb or gnnoci use later. > the other monitoring solution can proably do > the same but nova does not really track vm cpu usage that closely. > > from the libvirt daemon on the compute nodes themselves. > > > > Best, > > -jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eblock at nde.ag Thu Nov 29 11:01:14 2018 From: eblock at nde.ag (Eugen Block) Date: Thu, 29 Nov 2018 11:01:14 +0000 Subject: [Openstack] [Ocata] config option show_multiple_locations Message-ID: <20181129110114.Horde.4Gg4zad307OB-rz65PVSr5R@webmail.nde.ag> Hello list, I have a strange issue I'd like to report here, I'm not sure whether this could be a bug or a config issue on my side. The environment has developed from Liberty to Ocata over the last 3 years, backend for glance, cinder and nova is Ceph since Mitaka release. So according to [1] these two config options should be set to true. > show_multiple_locations = True > show_image_direct_url = True This setup has worked just fine, live snapshots of nova worked as expected. Last year the environment was upgraded to Ocata (successfully), and some time later I decided to clean up the configs, I set show_multiple_locations to false, also because glance reports: > Option "show_multiple_locations" from group "DEFAULT" is deprecated > for removal. Its value may be silently ignored in the future. Since this change the nova live snapshots stopped working, resulting in this stack trace: ---cut here--- [req-5bd2fef2-2155-4a89-b346-e20fb0b0d14a df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] Failed to snapshot image Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 1626, in snapshot purge_props=False) File "/usr/lib/python2.7/site-packages/nova/image/api.py", line 132, in update purge_props=purge_props) File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 733, in update _reraise_translated_image_exception(image_id) File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 1050, in _reraise_translated_image_exception six.reraise(type(new_exc), new_exc, exc_trace) File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 731, in update image = self._update_v2(context, sent_service_image_meta, data) File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 745, in _update_v2 image = self._add_location(context, image_id, location) File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 630, in _add_location location, {}) File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 168, in call result = getattr(controller, method)(*args, **kwargs) File "/usr/lib/python2.7/site-packages/glanceclient/v2/images.py", line 340, in add_location response = self._send_image_update_request(image_id, add_patch) File "/usr/lib/python2.7/site-packages/glanceclient/common/utils.py", line 535, in inner return RequestIdProxy(wrapped(*args, **kwargs)) File "/usr/lib/python2.7/site-packages/glanceclient/v2/images.py", line 324, in _send_image_update_request data=json.dumps(patch_body)) File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 294, in patch return self._request('PATCH', url, **kwargs) File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 277, in _request resp, body_iter = self._handle_response(resp) File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 107, in _handle_response raise exc.from_response(resp, resp.content) ImageNotAuthorized: Not authorized for image e99b2dfd-db33-4475-a51f-af4b913a7041. INFO nova.compute.manager [req-5bd2fef2-2155-4a89-b346-e20fb0b0d14a df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] [instance: 751b3731-de0d-42cd-a105-b92e326294aa] Successfully reverted task state from image_uploading on failure for instance. ---cut here--- A couple of weeks passed until this problem occured (oviously nobody took snapshots), so I didn't immediately connect it to the config change, but when I followed the stack trace, I found this comment: ---cut here--- def _add_location(self, context, image_id, location): # 'show_multiple_locations' must be enabled in glance api conf file. [...] ---cut here--- I wouldn't expect this dependency if the option is marked as deprecated. Is this my misunderstanding or did I forget other configs that would prevent this behavior? Thank you for any information about this topic. Regards, Eugen [1] http://docs.ceph.com/docs/master/rbd/rbd-openstack/#for-mitaka-only From jean-philippe at evrard.me Thu Nov 29 11:18:37 2018 From: jean-philippe at evrard.me (Jean-Philippe Evrard) Date: Thu, 29 Nov 2018 12:18:37 +0100 Subject: [loci] Release management for LOCI In-Reply-To: References: Message-ID: Chris has proposed to discuss this in LOCI's next community meeting, which happens Friday. More news tomorrow! Regards, Jean-Philippe Evrard (evrardjp) From gmann at ghanshyammann.com Thu Nov 29 12:23:00 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 29 Nov 2018 21:23:00 +0900 Subject: [all] [infra] StoryBoard Migration: The Remaining Blockers Summary In-Reply-To: References: Message-ID: <1675f6c1eed.10dfd565213161.955867480698696118@ghanshyammann.com> ---- On Wed, 28 Nov 2018 07:45:11 +0900 Kendall Nelson wrote ---- > Hello! > As with all of my other summaries, if you are looking for the long etherpad version, you can find it here[1]. Somewhere along the way I used the wrong etherpad for notes and so we ended up doing the StoryBoard things in the etherpad originally meant for another session so pardon the name. > > Anywho. > > Overall the session went really well, there weren’t any huge glaring issues that anyone brought up. The majority of things were all smaller usability things. Just about all of which are definitely doable. > > The only slightly larger feature request (that we hadn't previously discussed) was a separate interface for filing stories- similar to the one LP provides. Something simple so the user doesn’t feel like they need to fill in all this information, but can just provide the minimum. I haven’t quite gotten around to making stories for all of the things discussed in the etherpad, but should have them up soon! You will be able to see them here[2], once they’ve been created. > > If you have opinions about any of what we discussed or have something you wanted to bring up but could not attend the session please drop into #storyboard and chat with us, or join us at our weekly meeting on Wednesday at 19:00 UTC. Thanks diablo_rojo for summary. To followup the discussion from QA PTG denver sessions, I have logged three stories[1] for QA requirement to start the migration. [1] https://storyboard.openstack.org/#!/story/2004465 https://storyboard.openstack.org/#!/story/2004466 https://storyboard.openstack.org/#!/story/2004467 -gmann > > -Kendall (diablo_rojo) > > [1]https://etherpad.openstack.org/p/BER-Contrib-Portal-Feedback (yes, I know the name doesn’t seem right..) > [2] https://storyboard.openstack.org/#!/story/list?status=active&project_group_id=57 > From jaypipes at gmail.com Thu Nov 29 12:38:44 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Thu, 29 Nov 2018 07:38:44 -0500 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> Message-ID: <78677688-a358-bd66-b4ca-02f734b37d98@gmail.com> On 11/29/2018 05:29 AM, Chris Dent wrote: > On Wed, 28 Nov 2018, Alex Schultz wrote: > > [stuff where I'm clearly in over my head, am missing critical > context, and don't know what I'm talking about, so just gonna stay > out, deleted] > >>> Throughout the discussion I've been assuming I must be missing some >>> critical detail because isn't the whole point to have immutable >>> stuff? Maybe it is immutable and you all are talking about it in >>> ways that make it seem otherwise. I dunno. I suspect I am missing >>> some bit of operational experience. >> >> The application is immutable, but the configs need to be generated >> depending on where they end up or the end users desired configuration. >> For some service that includes pulling in some information about the >> host and including that (SRIOV, pci, etc). > > Presumably most of the config is immutable as well and there are > only a (relatively) small number of per-instance-of-thing > differences? > >> Given the vast amount of configurations exposed in each service, i'm >> not sure environment variables help here. Additionally that doesn't >> solve for non-oslo services (mysql/rabbitmq/etc) so then you'd end up >> having two ways of having to configure the containers/services. Not sure about RabbitMQ, but certainly MySQL/MariaDB takes command line argument overrides if the container running MySQL server actually has the mysql server as its entrypoint. I'm not actually sure how the Triple-O container for MySQL/MariaDB is constructed, though. I tried finding where MySQL/MariaDB container was constructed in the dozens of tripleo-related repositories on github but gave up. Maybe someone with knowledge of triple-o's internals can point me to that Dockerfile? > The idea is for the environment variables to only be used for the > small number of differences, not everything. As what amount to > overrides. > > What I'm trying to understand is why this trope of container > management doesn't apply here: > > A: How do I manage configuration _in_ my containers? > B: Don't. > A: ? > B: Manage it from the outside, tell the container its config when it >    starts. If the config needs to change, start a new container. Precisely my thoughts as well. However, if the containers you are using aren't really application containers (having single-process entrypoints) and are really just lightweight VMs in disguise as containers, then you pretty much throw the above trope out the window and are back to square one using legacy [1] configuration management techniques to configure the "containers" as you would configure a baremetal host or VM. In any case, it sounds like the triple-o team is attempting to find any ways they can put their containers on a diet, and I fully support that effort, as I'm sure you do as well. -jay [1] legacy now equals between 3 and 5 years old. :( From smooney at redhat.com Thu Nov 29 12:53:31 2018 From: smooney at redhat.com (Sean Mooney) Date: Thu, 29 Nov 2018 12:53:31 +0000 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <78677688-a358-bd66-b4ca-02f734b37d98@gmail.com> References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> <78677688-a358-bd66-b4ca-02f734b37d98@gmail.com> Message-ID: On Thu, 2018-11-29 at 07:38 -0500, Jay Pipes wrote: > On 11/29/2018 05:29 AM, Chris Dent wrote: > > On Wed, 28 Nov 2018, Alex Schultz wrote: > > > > [stuff where I'm clearly in over my head, am missing critical > > context, and don't know what I'm talking about, so just gonna stay > > out, deleted] > > > > > > Throughout the discussion I've been assuming I must be missing some > > > > critical detail because isn't the whole point to have immutable > > > > stuff? Maybe it is immutable and you all are talking about it in > > > > ways that make it seem otherwise. I dunno. I suspect I am missing > > > > some bit of operational experience. > > > > > > The application is immutable, but the configs need to be generated > > > depending on where they end up or the end users desired configuration. > > > For some service that includes pulling in some information about the > > > host and including that (SRIOV, pci, etc). > > > > Presumably most of the config is immutable as well and there are > > only a (relatively) small number of per-instance-of-thing > > differences? > > > > > Given the vast amount of configurations exposed in each service, i'm > > > not sure environment variables help here. Additionally that doesn't > > > solve for non-oslo services (mysql/rabbitmq/etc) so then you'd end up > > > having two ways of having to configure the containers/services. > > Not sure about RabbitMQ, but certainly MySQL/MariaDB takes command line > argument overrides if the container running MySQL server actually has > the mysql server as its entrypoint. the containers come from kolla https://github.com/openstack/kolla/blob/master/docker/mariadb/Dockerfile.j2 the entry point is the kolla_start script which does a few things to normalise all the kolla continer "abi" then runs the command specifed via a json file. https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/mariadb/templates/mariadb.json.j2 so basicaly it makes sure the config files esists and the permissions are correct then calls /usr/bin/mysqld_safe > > I'm not actually sure how the Triple-O container for MySQL/MariaDB is > constructed, though. I tried finding where MySQL/MariaDB container was > constructed in the dozens of tripleo-related repositories on github but > gave up. Maybe someone with knowledge of triple-o's internals can point > me to that Dockerfile? ya the fact triplo uses kolla container make them hard to find unless you know that. alther tripleo uses a template override file to modify the kolla container a little for tis needs but in generall they should be the same as the vanila kolla ones. > > > The idea is for the environment variables to only be used for the > > small number of differences, not everything. As what amount to > > overrides. i dont know if docker has fixed this but you used to be unable to change env vars set after a contier was created which mean to go to debug mode logging you had to destroy and recreate the container which is annoying vs config change and sighup for servies that support mutable config. > > > > What I'm trying to understand is why this trope of container > > management doesn't apply here: > > > > A: How do I manage configuration _in_ my containers? > > B: Don't. > > A: ? > > B: Manage it from the outside, tell the container its config when it > > starts. If the config needs to change, start a new container. > > Precisely my thoughts as well. > > However, if the containers you are using aren't really application > containers (having single-process entrypoints) and are really just > lightweight VMs in disguise as containers, then you pretty much throw > the above trope out the window and are back to square one using legacy > [1] configuration management techniques to configure the "containers" as > you would configure a baremetal host or VM. > > In any case, it sounds like the triple-o team is attempting to find any > ways they can put their containers on a diet, and I fully support that > effort, as I'm sure you do as well. > > -jay > > [1] legacy now equals between 3 and 5 years old. :( > From rafaelweingartner at gmail.com Thu Nov 29 01:23:51 2018 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Wed, 28 Nov 2018 23:23:51 -0200 Subject: [Openstack] OpenStack federation and WAYF process with multiple IdPs Message-ID: Hello Openstackers, I am testing the integration of OpenStack (acting as a service provider) using Keycloak (as an identity provider) with OpenId Connect protocol. So far everything is working, but when I enable more than one IdP, I get an odd behavior. The “where are you from (WAYF)” process is happening twice, one in Horizon (where the user selects the authentication provider A.K.A IdP), and another one in Keystone via the Apache HTTPD OIDC module. I assume this is happening because the actual application being authenticated via OIDC is Keystone, and just afterwards, the other systems will authenticate themselves via Keystone. Has anybody else experienced/”dealt with” this situation? Is this by design? Am I missing a parameter/configuration or something else? The version of OpenStack that I am using is Rocky. -- Rafael Weingärtner -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From mranga at gmail.com Thu Nov 29 01:40:52 2018 From: mranga at gmail.com (M. Ranganathan) Date: Wed, 28 Nov 2018 20:40:52 -0500 Subject: [Openstack] TAPaaS on Queens? Message-ID: Hello all, I want to experiment with SNORT as a service on OpenStack. I looked at the TAPaaS project. However, I am not sure it runs on OpenStack Queens. I don't see it in the queens release https://releases.openstack.org/queens/index.html so I am wondering if this project is still alive (?) Thanks, Ranga -- M. Ranganathan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From mranga at gmail.com Thu Nov 29 01:53:20 2018 From: mranga at gmail.com (M. Ranganathan) Date: Wed, 28 Nov 2018 20:53:20 -0500 Subject: [Openstack] How to create a tap port using openstack API? Message-ID: Hello, I want to write my own VNF. For this I need to : 1. Create a network namespace. 2. Create a ovs internal port on a bridge with an appropriate tag. 3. Send the port to the network namespace. 4. Run a service in the network namespace that could (for example) read packets. Are there "openstack networking" commands to do steps 1-3 above or should this be done manually? ( What I want to do, essentially is to create a tap port and read packets from this tap port. Incidentally, the TAPaaS project was doing something like this but it seems to be unsupported.) Thanks, Ranga -- M. Ranganathan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From reedip14 at gmail.com Thu Nov 29 05:48:46 2018 From: reedip14 at gmail.com (reedip banerjee) Date: Thu, 29 Nov 2018 11:18:46 +0530 Subject: [Openstack] TAPaaS on Queens? In-Reply-To: References: Message-ID: Hi M.Ranganathan, Tap-as-a-Service has a release for Stable/Queens and Stable/Rocky. However, its not yet an official project in Openstack, so it might not be listed there. On Thu, Nov 29, 2018 at 7:21 AM M. Ranganathan wrote: > Hello all, > > I want to experiment with SNORT as a service on OpenStack. I looked at the > TAPaaS project. However, I am not sure it runs on OpenStack Queens. I don't > see it in the queens release > https://releases.openstack.org/queens/index.html so I am wondering if > this project is still alive (?) > > > Thanks, > > Ranga > > -- > M. Ranganathan > > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack at lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -- Thanks and Regards, Reedip Banerjee IRC: reedip -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From ignaziocassano at gmail.com Thu Nov 29 06:49:21 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Thu, 29 Nov 2018 07:49:21 +0100 Subject: [Openstack-operators] Fwd: Nova hypervisor uuid In-Reply-To: References: <63283d3b-0661-7620-aaea-8ffbe9e483d8@gmail.com> Message-ID: Hello Mattm Yes I mean sometimes I have same host/node names with different uuid in compute_nodes table in nova database I must delete nodes with uuid those not match with nova-hypervisor list command. At this time I have the following: MariaDB [nova]> select hypervisor_hostname,uuid,deleted from compute_nodes; +---------------------+--------------------------------------+---------+ | hypervisor_hostname | uuid | deleted | +---------------------+--------------------------------------+---------+ | tst2-kvm02 | 802b21c2-11fb-4426-86b9-bf25c8a5ae1d | 0 | | tst2-kvm01 | ce27803b-06cd-44a7-b927-1fa42c813b0f | 0 | +---------------------+--------------------------------------+---------+ 2 rows in set (0,00 sec) But sometimes old uuid are inserted in the table . I deleted again them. I restarted kvm nodes and now the table is ok. I also restarded each controller and the tables is ok. I do not know because 3 days ago I had same compute nodes names with different uuids. Thanks and Regards Ignazio Il giorno mer 28 nov 2018 alle ore 17:54 Matt Riedemann ha scritto: > On 11/28/2018 4:19 AM, Ignazio Cassano wrote: > > Hi Matt, sorry but I lost your answer and Gianpiero forwarded it to me. > > I am sure kvm nodes names are note changed. > > Tables where uuid are duplicated are: > > dataresource_providers in nova_api db > > compute_nodes in nova db > > Regards > > Ignazio > > It would be easier if you simply dumped the result of a select query on > the compute_nodes table where the duplicate nodes exist (you said > duplicate UUIDs but I think you mean duplicate host/node names with > different UUIDs, correct?). > > There is a unique constraint on host/hypervisor_hostname > (nodename)/deleted: > > schema.UniqueConstraint( > 'host', 'hypervisor_hostname', 'deleted', > name="uniq_compute_nodes0host0hypervisor_hostname0deleted"), > > So I'm wondering if the deleted field is not 0 on one of those because > if one is marked as deleted, then the compute service will create a new > compute_nodes table record on startup (and associated resource provider). > > -- > > Thanks, > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From renat.akhmerov at gmail.com Thu Nov 29 09:23:43 2018 From: renat.akhmerov at gmail.com (Renat Akhmerov) Date: Thu, 29 Nov 2018 16:23:43 +0700 Subject: [openstack-dev] [mistral] Renat is on vacation until Dec 17th Message-ID: <9e3e6449-5162-42f7-a851-f754deb0dcc0@Spark> Hi, I’ll be on vacation till Dec 17th. I’ll be replying emails but with delays. Thanks Renat Akhmerov @Nokia -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From ervikrant06 at gmail.com Thu Nov 29 11:12:05 2018 From: ervikrant06 at gmail.com (Vikrant Aggarwal) Date: Thu, 29 Nov 2018 16:42:05 +0530 Subject: [openstack-dev] [magnum] [Rocky] K8 deployment on fedora-atomic is failed Message-ID: Hello Team, Trying to deploy on K8 on fedora atomic. Here is the output of cluster template: ~~~ [root at packstack1 k8s_fedora_atomic_v1(keystone_admin)]# magnum cluster-template-show 16eb91f7-18fe-4ce3-98db-c732603f2e57 WARNING: The magnum client is deprecated and will be removed in a future release. Use the OpenStack client to avoid seeing this message. +-----------------------+--------------------------------------+ | Property | Value | +-----------------------+--------------------------------------+ | insecure_registry | - | | labels | {} | | updated_at | - | | floating_ip_enabled | True | | fixed_subnet | - | | master_flavor_id | - | | user_id | 203617849df9490084dde1897b28eb53 | | uuid | 16eb91f7-18fe-4ce3-98db-c732603f2e57 | | no_proxy | - | | https_proxy | - | | tls_disabled | False | | keypair_id | kubernetes | | project_id | 45a6706c831c42d5bf2da928573382b1 | | public | False | | http_proxy | - | | docker_volume_size | 10 | | server_type | vm | | external_network_id | external1 | | cluster_distro | fedora-atomic | | image_id | f5954340-f042-4de3-819e-a3b359591770 | | volume_driver | - | | registry_enabled | False | | docker_storage_driver | devicemapper | | apiserver_port | - | | name | coe-k8s-template | | created_at | 2018-11-28T12:58:21+00:00 | | network_driver | flannel | | fixed_network | - | | coe | kubernetes | | flavor_id | m1.small | | master_lb_enabled | False | | dns_nameserver | 8.8.8.8 | +-----------------------+--------------------------------------+ ~~~ Found couple of issues in the logs of VM started by magnum. - etcd was not getting started because of incorrect permission on file "/etc/etcd/certs/server.key". This file is owned by root by default have 0440 as permission. Changed the permission to 0444 so that etcd can read the file. After that etcd started successfully. - etcd DB doesn't contain anything: [root at kube-cluster1-qobaagdob75g-master-0 ~]# etcdctl ls / -r [root at kube-cluster1-qobaagdob75g-master-0 ~]# - Flanneld is stuck in activating status. ~~~ [root at kube-cluster1-qobaagdob75g-master-0 ~]# systemctl status flanneld ● flanneld.service - Flanneld overlay address etcd agent Loaded: loaded (/usr/lib/systemd/system/flanneld.service; enabled; vendor preset: disabled) Active: activating (start) since Thu 2018-11-29 11:05:39 UTC; 14s ago Main PID: 6491 (flanneld) Tasks: 6 (limit: 4915) Memory: 4.7M CPU: 53ms CGroup: /system.slice/flanneld.service └─6491 /usr/bin/flanneld -etcd-endpoints=http://127.0.0.1:2379 -etcd-prefix=/atomic.io/network Nov 29 11:05:44 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:44.569376 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:45 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:45.584532 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:46 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:46.646255 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:47 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:47.673062 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:48 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:48.686919 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:49 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:49.709136 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:50 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:50.729548 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:51 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:51.749425 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:52 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:52.776612 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:53 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:53.790418 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] ~~~ - Continuously in the jouralctl logs following messages are printed. ~~~ Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal kube-apiserver[6888]: F1129 11:06:39.338416 6888 server.go:269] Invalid Authorization Config: Unknown authorization mode Node specified Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: kube-apiserver.service: Main process exited, code=exited, status=255/n/a Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal kube-scheduler[2540]: E1129 11:06:39.408272 2540 reflector.go:199] k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:463: Failed to list *api.Node: Get http://127.0.0.1:8080/api/v1/nodes?resourceVersion=0: dial tcp 127.0.0.1:8080: getsockopt: connection refused Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal kube-scheduler[2540]: E1129 11:06:39.444737 2540 reflector.go:199] k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:460: Failed to list *api.Pod: Get http://127.0.0.1:8080/api/v1/pods?fieldSelector=spec.nodeName%21%3D%2Cstatus.phase%21%3DFailed%2Cstatus.phase%21%3DSucceeded&resourceVersion=0: dial tcp 127.0.0.1:8080: getsockopt: connection refused Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal kube-scheduler[2540]: E1129 11:06:39.445793 2540 reflector.go:199] k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:466: Failed to list *api.PersistentVolume: Get http://127.0.0.1:8080/api/v1/persistentvolumes?resourceVersion=0: dial tcp 127.0.0.1:8080: getsockopt: connection refused Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=kube-apiserver comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: Failed to start Kubernetes API Server. Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: kube-apiserver.service: Unit entered failed state. Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: kube-apiserver.service: Failed with result 'exit-code'. Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal kube-scheduler[2540]: E1129 11:06:39.611699 2540 reflector.go:199] k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:481: Failed to list *extensions.ReplicaSet: Get http://127.0.0.1:8080/apis/extensions/v1beta1/replicasets?resourceVersion=0: dial tcp 127.0.0.1:8080: getsockopt: connection refused ~~~ Any help on above issue is highly appreciated. Thanks & Regards, Vikrant Aggarwal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From jaypipes at gmail.com Thu Nov 29 13:00:15 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Thu, 29 Nov 2018 08:00:15 -0500 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> <5cbe32fb549b2e107a57aa3c13d4451a6fc6a35e.camel@redhat.com> Message-ID: <12ef613d-5040-12ef-7e39-ee1827311cfb@gmail.com> On 11/29/2018 04:28 AM, Bogdan Dobrelya wrote: > On 11/28/18 8:55 PM, Doug Hellmann wrote: >> I thought the preferred solution for more complex settings was config >> maps. Did that approach not work out? >> >> Regardless, now that the driver work is done if someone wants to take >> another stab at etcd integration it’ll be more straightforward today. >> >> Doug >> > > While sharing configs is a feasible option to consider for large scale > configuration management, Etcd only provides a strong consistency, which > is also known as "Unavailable" [0]. For edge scenarios, to configure > 40,000 remote computes over WAN connections, we'd rather want instead > weaker consistency models, like "Sticky Available" [0]. That would allow > services to fetch their configuration either from a central "uplink" or > locally as well, when the latter is not accessible from remote edge > sites. Etcd cannot provide 40,000 local endpoints to fit that case I'm > afraid, even if those would be read only replicas. That is also > something I'm highlighting in the paper [1] drafted for ICFC-2019. > > But had we such a sticky available key value storage solution, we would > indeed have solved the problem of multiple configuration management > system execution for thousands of nodes as James describes it. It's not that etcd is incapable of providing something like this. It's that a *single* etcd KVS used by 40K compute nodes across a disaggregated control plane would not be available to all of those nodes simultaneously. But you could certainly use etcd as the data store to build a sticky available configuration data store. If, for example, you had many local [1] etcd KVS that stored local data and synchronized the local data set with other etcd KVS endpoints when a network partition was restored, you could get such a system that was essentially "sticky available" for all intents and purposes. Come to think of it, you could do the same with a SQLite DB, ala Swift's replication of SQLite DBs via rsync. But, at the risk of sounding like a broken record, at the end of the day, many of OpenStack's core services -- notably Nova -- were not designed for disaggregated control planes. They were designed for the datacenter, with tightly-packed compute resources and low-latency links for the control plane. The entire communication bus and state management system would need to be redesigned from the nova-compute to the nova-conductor for (far) edge case clouds to be a true reality. Instead of sending all data updates synchronously from each nova-compute to nova-conductor, the communication bus needs to be radically redesigned so that the nova-compute uses a local data store *as its primary data storage* and then asynchronously sends batched updates to known control plane endpoints when those regular network partitions correct themselves. The nova-compute manager will need to be substantially hardened to keep itself up and running (and writing to that local state storage) for long periods of time and contain all the logic to resync itself when network uplinks become available again. Finally, if those local nova-computes need to actually *do* anything other than keep existing VMs/baremetal machines up and running, then a local Compute API service needs to be made available in the far edge sites themselves -- offering some subset of Compute API functionality to control the VMs in that local site. Otherwise, the whole "multiple department stores running an edge OpenStack site that can tolerate the Mother Ship being down" isn't a thing that will work. Like I said, pretty much a complete redesign of the nova control plane... Best, -jay [1] or local-ish, think POPs or even local to the compute node itself... > [0] https://jepsen.io/consistency > [1] > https://github.com/bogdando/papers-ieee/blob/master/ICFC-2019/LaTeX/position_paper_1570506394.pdf > > > On 11/28/18 11:22 PM, Dan Prince wrote: >> On Wed, 2018-11-28 at 13:28 -0500, James Slagle wrote: >>> On Wed, Nov 28, 2018 at 12:31 PM Bogdan Dobrelya >>> wrote: >>>> Long story short, we cannot shoot both rabbits with a single shot, >>>> not >>>> with puppet :) May be we could with ansible replacing puppet >>>> fully... >>>> So splitting config and runtime images is the only choice yet to >>>> address >>>> the raised security concerns. And let's forget about edge cases for >>>> now. >>>> Tossing around a pair of extra bytes over 40,000 WAN-distributed >>>> computes ain't gonna be our the biggest problem for sure. >>> >>> I think it's this last point that is the crux of this discussion. We >>> can agree to disagree about the merits of this proposal and whether >>> it's a pre-optimzation or micro-optimization, which I admit are >>> somewhat subjective terms. Ultimately, it seems to be about the "why" >>> do we need to do this as to the reason why the conversation seems to >>> be going in circles a bit. >>> >>> I'm all for reducing container image size, but the reality is that >>> this proposal doesn't necessarily help us with the Edge use cases we >>> are talking about trying to solve. >>> >>> Why would we even run the exact same puppet binary + manifest >>> individually 40,000 times so that we can produce the exact same set >>> of >>> configuration files that differ only by things such as IP address, >>> hostnames, and passwords? Maybe we should instead be thinking about >>> how we can do that *1* time centrally, and produce a configuration >>> that can be reused across 40,000 nodes with little effort. The >>> opportunity for a significant impact in terms of how we can scale >>> TripleO is much larger if we consider approaching these problems with >>> a wider net of what we could do. There's opportunity for a lot of >>> better reuse in TripleO, configuration is just one area. The plan and >>> Heat stack (within the ResourceGroup) are some other areas. >> >> We run Puppet for configuration because that is what we did on >> baremetal and we didn't break backwards compatability for our >> configuration options for upgrades. Our Puppet model relies on being >> executed on each local host in order to splice in the correct IP >> address and hostname. It executes in a distributed fashion, and works >> fairly well considering the history of the project. It is robust, >> guarantees no duplicate configs are being set, and is backwards >> compatible with all the options TripleO supported on baremetal. Puppet >> is arguably better for configuration than Ansible (which is what I hear >> people most often suggest we replace it with). It suits our needs fine, >> but it is perhaps a bit overkill considering we are only generating >> config files. >> >> I think the answer here is moving to something like Etcd. Perhaps > > Not Etcd I think, see my comment above. But you're absolutely right Dan. > >> skipping over Ansible entirely as a config management tool (it is >> arguably less capable than Puppet in this category anyway). Or we could >> use Ansible for "legacy" services only, switch to Etcd for a majority >> of the OpenStack services, and drop Puppet entirely (my favorite >> option). Consolidating our technology stack would be wise. >> >> We've already put some work and analysis into the Etcd effort. Just >> need to push on it some more. Looking at the previous Kubernetes >> prototypes for TripleO would be the place to start. >> >> Config management migration is going to be tedious. Its technical debt >> that needs to be handled at some point anyway. I think it is a general >> TripleO improvement that could benefit all clouds, not just Edge. >> >> Dan >> >>> >>> At the same time, if some folks want to work on smaller optimizations >>> (such as container image size), with an approach that can be agreed >>> upon, then they should do so. We just ought to be careful about how >>> we >>> justify those changes so that we can carefully weigh the effort vs >>> the >>> payoff. In this specific case, I don't personally see this proposal >>> helping us with Edge use cases in a meaningful way given the scope of >>> the changes. That's not to say there aren't other use cases that >>> could >>> justify it though (such as the security points brought up earlier). >>> >> > > From mark at stackhpc.com Thu Nov 29 13:07:28 2018 From: mark at stackhpc.com (Mark Goddard) Date: Thu, 29 Nov 2018 13:07:28 +0000 Subject: [kayobe] IRC meetings Message-ID: Hi, The community has requested that we start holding regular IRC meetings for kayobe, and I agree. I suggest we start with meeting every other week, in the #openstack-kayobe channel. I've created a Doodle poll [1] with each hour between 2pm and 6pm UTC available every weekday. Please respond on the poll with your availability. Thanks, Mark [1] https://doodle.com/poll/6di3pddsahg6h66k -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.slagle at gmail.com Thu Nov 29 13:22:52 2018 From: james.slagle at gmail.com (James Slagle) Date: Thu, 29 Nov 2018 08:22:52 -0500 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> Message-ID: On Thu, Nov 29, 2018 at 5:31 AM Chris Dent wrote: > > On Wed, 28 Nov 2018, Alex Schultz wrote: > > [stuff where I'm clearly in over my head, am missing critical > context, and don't know what I'm talking about, so just gonna stay > out, deleted] > > >> Throughout the discussion I've been assuming I must be missing some > >> critical detail because isn't the whole point to have immutable > >> stuff? Maybe it is immutable and you all are talking about it in > >> ways that make it seem otherwise. I dunno. I suspect I am missing > >> some bit of operational experience. > > > > The application is immutable, but the configs need to be generated > > depending on where they end up or the end users desired configuration. > > For some service that includes pulling in some information about the > > host and including that (SRIOV, pci, etc). > > Presumably most of the config is immutable as well and there are > only a (relatively) small number of per-instance-of-thing > differences? Yes exactly. I don't think we actually do that much based on individual system facts other than IP's and hostnames. Which is why generating the config individually on each node seems like a good area for optimization. Especially when we are talking about large groups of nodes that will be identical (same number of cores, memory, etc). > > > Given the vast amount of configurations exposed in each service, i'm > > not sure environment variables help here. Additionally that doesn't > > solve for non-oslo services (mysql/rabbitmq/etc) so then you'd end up > > having two ways of having to configure the containers/services. > > The idea is for the environment variables to only be used for the > small number of differences, not everything. As what amount to > overrides. > > What I'm trying to understand is why this trope of container > management doesn't apply here: > > A: How do I manage configuration _in_ my containers? > B: Don't. > A: ? > B: Manage it from the outside, tell the container its config when it > starts. If the config needs to change, start a new container. > > I'm pretty sure this isn't really germane to the original point of > this thread, so apologies for adding to the noise, but it was hard > to resist. I'll try harder. Is it explained earlier in the thread? http://lists.openstack.org/pipermail/openstack-dev/2018-November/136582.html With additional context as to the "why" here: http://lists.openstack.org/pipermail/openstack-dev/2018-November/136597.html I'm fairly sure this addresses your question, but happy to offer more details if not. -- -- James Slagle -- From hberaud at redhat.com Thu Nov 29 13:56:26 2018 From: hberaud at redhat.com (Herve Beraud) Date: Thu, 29 Nov 2018 14:56:26 +0100 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: <32c01016-6f23-d00c-356f-be68aa0cb29e@nemebean.com> References: <20181122234340.GE24690@thor.bakeyournoodle.com> <1ca0e1a7-58a1-8f91-617b-7be7b0df0e1b@redhat.com> <32c01016-6f23-d00c-356f-be68aa0cb29e@nemebean.com> Message-ID: FYI Introducing oslo.service 1.31.7 with the latest merged changes. These refers to #3. https://review.openstack.org/#/c/620913/ Le mer. 28 nov. 2018 à 00:31, Ben Nemec a écrit : > > > On 11/26/18 9:47 AM, Zane Bitter wrote: > > On 22/11/18 6:43 PM, Tony Breeds wrote: > >>> ### 3 - Maintain a private interface for ThreadingEvent only on > >>> stable/rocky > >>> impacted projects: oslo.service > >>> related reviews: > >>> -https://review.openstack.org/619342/ > >>> > >>> pros: > >>> - straightforward > >>> cons: > >>> - Changing the loopingcall module semantics as it is different type > >>> - stable only patches > >>> - misunderstoud service customer between Threading, eventlet, etc.. and > >>> master behavior > >> A variation of this (without adding the debtcollector requirement) might > >> work as IIUC all versions of oslo.service < 1.32.0 (except 1.31.6) would > >> work and doesn't introduce any new policy violations. > >> > >> Adding debcollector is great but introduces at least the semver issues > >> from option #1 > > > > Hey Tony, can you explain the debtcollector issue a bit more? Is it just > > that we generally promise to not adding anything to requirements.txt on > > stable branches? In this case, debtcollector, appears to already be a > > transitive dependency of something that oslo.service already requires > > (it appears in lower-constraints.txt, at least), so I was assuming that > > there wouldn't be any real-world consequences. Does that change things? > > Technically adding a new dep requires a minor version update per our > release guidelines. I guess it gets a little fuzzy when you're adding a > dep that's already part of the transitive set, but I'm guessing that's > what Tony was referring to. > > That said, as I mentioned on the review I don't feel any particular need > to debtcollector this. It's in a private module that nobody should ever > have been using and we're only doing this because we prioritize fixing > the bug over absolute API purity. :-) > > In any case, I'm +1 on doing this to avoid creating weird version > dependencies on a stable branch. > > > > > TBH it would be trivial to do something equivalent without adding the > > new requirement, so I guess the easiest thing is if I just update the > > patch to do that. > > > >>> ### 4 - Don't use private interface in oslo.service > >>> impacted projects: nova > >>> related reviews: > >>> -https://review.openstack.org/#/c/619360/ > >>> > >>> pros: > >>> - straightforward > >>> cons: > >>> - this could work but it is not the same sematics as before as the > >>> type has > >>> changed > >>> - stable only patches > >>> - misunderstoud service customer between Threading, eventlet, etc.. and > >>> master behavior > >> I think this is more or less the same as Option #3 in terms of impact. > >> If that's right it could be acceptable. > > > > It's slightly higher impact, because you wouldn't be able to upgrade > > oslo.service past 1.31.5 and still run the unit tests on old versions of > > Nova. Whereas with option #3 you could just upgrade oslo.service to > > 1.31.7, or just upgrade Nova, and either way everything would work. > > > > Not that we shouldn't do this *as well*, but IMHO we still need to do #3. > > > > I like doing this as well. If we need an argument as to why it's okay to > do this stable-only patch, it would be that this is essentially a > backport of the original Nova fix proposed before we decided to do the > fixture. In retrospect maybe we should have gone ahead and merged that > simple, backportable fix and done the fixture as a followup, but in > spirit this has the same effect. > > -Ben > > -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Thu Nov 29 13:59:57 2018 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Thu, 29 Nov 2018 08:59:57 -0500 Subject: [Openstack] [Ocata] config option show_multiple_locations In-Reply-To: <20181129110114.Horde.4Gg4zad307OB-rz65PVSr5R@webmail.nde.ag> References: <20181129110114.Horde.4Gg4zad307OB-rz65PVSr5R@webmail.nde.ag> Message-ID: <5b31b24a-c865-7050-cd2e-f6caa2265832@gmail.com> Apoologies for top-posting, but the answer is that show_multiple_locations is deprecated, but its removal has been postponed, so you should continue to use it (but keep an eye on the Glance release notes). The original idea behind the deprecation was that because image locations are also governed by policies, it would simplify things to use only policies and eliminate the configuration option. In the meantime, an OSSN [0] was issued where the easiest way to mitigate the exploit is to set show_multiple_locations=False, so the deprecation period was extended [1]. Finally, closer inspection has revealed that show_multiple_locations cannot be removed without some major refactoring. There's a draft spec explaining the situation [2], but no one has been able to commit time to work on the issue (or even finish the spec). The Glance team would be happy to discuss this more with anyone interested in working on the issue. cheers, brian [0] https://wiki.openstack.org/wiki/OSSN/OSSN-0065 [1] https://docs.openstack.org/releasenotes/glance/ocata.html#relnotes-14-0-0-origin-stable-ocata-other-notes [2] https://review.openstack.org/#/c/528021/ On 11/29/18 6:01 AM, Eugen Block wrote: > Hello list, > > I have a strange issue I'd like to report here, I'm not sure whether > this could be a bug or a config issue on my side. > > The environment has developed from Liberty to Ocata over the last 3 > years, backend for glance, cinder and nova is Ceph since Mitaka release. > So according to [1] these two config options should be set to true. > >> show_multiple_locations = True >> show_image_direct_url = True > > This setup has worked just fine, live snapshots of nova worked as > expected. Last year the environment was upgraded to Ocata > (successfully), and some time later I decided to clean up the configs, I > set show_multiple_locations to false, also because glance reports: > >> Option "show_multiple_locations" from group "DEFAULT" is deprecated >> for removal.  Its value may be silently ignored in the future. > > Since this change the nova live snapshots stopped working, resulting in > this stack trace: > > ---cut here--- >  [req-5bd2fef2-2155-4a89-b346-e20fb0b0d14a > df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e > 2e3c3f3822124a3fa9fd905164f519ae - - -] Failed to snapshot image >  Traceback (most recent call last): >    File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", > line 1626, in snapshot >      purge_props=False) >    File "/usr/lib/python2.7/site-packages/nova/image/api.py", line 132, > in update >      purge_props=purge_props) >    File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line > 733, in update >      _reraise_translated_image_exception(image_id) >    File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line > 1050, in _reraise_translated_image_exception >      six.reraise(type(new_exc), new_exc, exc_trace) >    File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line > 731, in update >      image = self._update_v2(context, sent_service_image_meta, data) >    File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line > 745, in _update_v2 >      image = self._add_location(context, image_id, location) >    File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line > 630, in _add_location >      location, {}) >    File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line > 168, in call >      result = getattr(controller, method)(*args, **kwargs) >    File "/usr/lib/python2.7/site-packages/glanceclient/v2/images.py", > line 340, in add_location >      response = self._send_image_update_request(image_id, add_patch) >    File "/usr/lib/python2.7/site-packages/glanceclient/common/utils.py", > line 535, in inner >      return RequestIdProxy(wrapped(*args, **kwargs)) >    File "/usr/lib/python2.7/site-packages/glanceclient/v2/images.py", > line 324, in _send_image_update_request >      data=json.dumps(patch_body)) >    File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", > line 294, in patch >      return self._request('PATCH', url, **kwargs) >    File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", > line 277, in _request >      resp, body_iter = self._handle_response(resp) >    File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", > line 107, in _handle_response >      raise exc.from_response(resp, resp.content) >  ImageNotAuthorized: Not authorized for image > e99b2dfd-db33-4475-a51f-af4b913a7041. > >  INFO nova.compute.manager [req-5bd2fef2-2155-4a89-b346-e20fb0b0d14a > df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e > 2e3c3f3822124a3fa9fd905164f519ae - - -] [instance: > 751b3731-de0d-42cd-a105-b92e326294aa] Successfully reverted task state > from image_uploading on failure for instance. > ---cut here--- > > A couple of weeks passed until this problem occured (oviously nobody > took snapshots), so I didn't immediately connect it to the config > change, but when I followed the stack trace, I found this comment: > > ---cut here--- >     def _add_location(self, context, image_id, location): >         # 'show_multiple_locations' must be enabled in glance api conf > file. > [...] > ---cut here--- > > I wouldn't expect this dependency if the option is marked as deprecated. > Is this my misunderstanding or did I forget other configs that would > prevent this behavior? > > Thank you for any information about this topic. > > Regards, > Eugen > > [1] http://docs.ceph.com/docs/master/rbd/rbd-openstack/#for-mitaka-only > > From eblock at nde.ag Thu Nov 29 14:26:45 2018 From: eblock at nde.ag (Eugen Block) Date: Thu, 29 Nov 2018 14:26:45 +0000 Subject: [Openstack] [Ocata] config option show_multiple_locations In-Reply-To: <5b31b24a-c865-7050-cd2e-f6caa2265832@gmail.com> References: <20181129110114.Horde.4Gg4zad307OB-rz65PVSr5R@webmail.nde.ag> <5b31b24a-c865-7050-cd2e-f6caa2265832@gmail.com> Message-ID: <20181129142645.Horde.A41j9MaUAwFuYuT1BmGm1MT@webmail.nde.ag> Thank you very much for the explanation, Brian. I'll keep the config option (it doesn't work without, so what choice is there?). Thank! Eugen Zitat von Brian Rosmaita : > Apoologies for top-posting, but the answer is that > show_multiple_locations is deprecated, but its removal has been > postponed, so you should continue to use it (but keep an eye on the > Glance release notes). > > The original idea behind the deprecation was that because image > locations are also governed by policies, it would simplify things to use > only policies and eliminate the configuration option. In the meantime, > an OSSN [0] was issued where the easiest way to mitigate the exploit is > to set show_multiple_locations=False, so the deprecation period was > extended [1]. > > Finally, closer inspection has revealed that show_multiple_locations > cannot be removed without some major refactoring. There's a draft spec > explaining the situation [2], but no one has been able to commit time to > work on the issue (or even finish the spec). > > The Glance team would be happy to discuss this more with anyone > interested in working on the issue. > > cheers, > brian > > [0] https://wiki.openstack.org/wiki/OSSN/OSSN-0065 > [1] > https://docs.openstack.org/releasenotes/glance/ocata.html#relnotes-14-0-0-origin-stable-ocata-other-notes > [2] https://review.openstack.org/#/c/528021/ > > > On 11/29/18 6:01 AM, Eugen Block wrote: >> Hello list, >> >> I have a strange issue I'd like to report here, I'm not sure whether >> this could be a bug or a config issue on my side. >> >> The environment has developed from Liberty to Ocata over the last 3 >> years, backend for glance, cinder and nova is Ceph since Mitaka release. >> So according to [1] these two config options should be set to true. >> >>> show_multiple_locations = True >>> show_image_direct_url = True >> >> This setup has worked just fine, live snapshots of nova worked as >> expected. Last year the environment was upgraded to Ocata >> (successfully), and some time later I decided to clean up the configs, I >> set show_multiple_locations to false, also because glance reports: >> >>> Option "show_multiple_locations" from group "DEFAULT" is deprecated >>> for removal.  Its value may be silently ignored in the future. >> >> Since this change the nova live snapshots stopped working, resulting in >> this stack trace: >> >> ---cut here--- >>  [req-5bd2fef2-2155-4a89-b346-e20fb0b0d14a >> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e >> 2e3c3f3822124a3fa9fd905164f519ae - - -] Failed to snapshot image >>  Traceback (most recent call last): >>    File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", >> line 1626, in snapshot >>      purge_props=False) >>    File "/usr/lib/python2.7/site-packages/nova/image/api.py", line 132, >> in update >>      purge_props=purge_props) >>    File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line >> 733, in update >>      _reraise_translated_image_exception(image_id) >>    File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line >> 1050, in _reraise_translated_image_exception >>      six.reraise(type(new_exc), new_exc, exc_trace) >>    File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line >> 731, in update >>      image = self._update_v2(context, sent_service_image_meta, data) >>    File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line >> 745, in _update_v2 >>      image = self._add_location(context, image_id, location) >>    File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line >> 630, in _add_location >>      location, {}) >>    File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line >> 168, in call >>      result = getattr(controller, method)(*args, **kwargs) >>    File "/usr/lib/python2.7/site-packages/glanceclient/v2/images.py", >> line 340, in add_location >>      response = self._send_image_update_request(image_id, add_patch) >>    File "/usr/lib/python2.7/site-packages/glanceclient/common/utils.py", >> line 535, in inner >>      return RequestIdProxy(wrapped(*args, **kwargs)) >>    File "/usr/lib/python2.7/site-packages/glanceclient/v2/images.py", >> line 324, in _send_image_update_request >>      data=json.dumps(patch_body)) >>    File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", >> line 294, in patch >>      return self._request('PATCH', url, **kwargs) >>    File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", >> line 277, in _request >>      resp, body_iter = self._handle_response(resp) >>    File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", >> line 107, in _handle_response >>      raise exc.from_response(resp, resp.content) >>  ImageNotAuthorized: Not authorized for image >> e99b2dfd-db33-4475-a51f-af4b913a7041. >> >>  INFO nova.compute.manager [req-5bd2fef2-2155-4a89-b346-e20fb0b0d14a >> df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e >> 2e3c3f3822124a3fa9fd905164f519ae - - -] [instance: >> 751b3731-de0d-42cd-a105-b92e326294aa] Successfully reverted task state >> from image_uploading on failure for instance. >> ---cut here--- >> >> A couple of weeks passed until this problem occured (oviously nobody >> took snapshots), so I didn't immediately connect it to the config >> change, but when I followed the stack trace, I found this comment: >> >> ---cut here--- >>     def _add_location(self, context, image_id, location): >>         # 'show_multiple_locations' must be enabled in glance api conf >> file. >> [...] >> ---cut here--- >> >> I wouldn't expect this dependency if the option is marked as deprecated. >> Is this my misunderstanding or did I forget other configs that would >> prevent this behavior? >> >> Thank you for any information about this topic. >> >> Regards, >> Eugen >> >> [1] http://docs.ceph.com/docs/master/rbd/rbd-openstack/#for-mitaka-only >> >> From bdobreli at redhat.com Thu Nov 29 14:37:24 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Thu, 29 Nov 2018 15:37:24 +0100 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: Message-ID: On 11/29/18 2:00 PM, Jay Pipes wrote: > On 11/29/2018 04:28 AM, Bogdan Dobrelya wrote: >> On 11/28/18 8:55 PM, Doug Hellmann wrote: >>> I thought the preferred solution for more complex settings was config >>> maps. Did that approach not work out? >>> >>> Regardless, now that the driver work is done if someone wants to take >>> another stab at etcd integration it’ll be more straightforward today. >>> >>> Doug >>> >> >> While sharing configs is a feasible option to consider for large scale >> configuration management, Etcd only provides a strong consistency, >> which is also known as "Unavailable" [0]. For edge scenarios, to >> configure 40,000 remote computes over WAN connections, we'd rather >> want instead weaker consistency models, like "Sticky Available" [0]. >> That would allow services to fetch their configuration either from a >> central "uplink" or locally as well, when the latter is not accessible >> from remote edge sites. Etcd cannot provide 40,000 local endpoints to >> fit that case I'm afraid, even if those would be read only replicas. >> That is also something I'm highlighting in the paper [1] drafted for >> ICFC-2019. >> >> But had we such a sticky available key value storage solution, we >> would indeed have solved the problem of multiple configuration >> management system execution for thousands of nodes as James describes it. > > It's not that etcd is incapable of providing something like this. It's > that a *single* etcd KVS used by 40K compute nodes across a > disaggregated control plane would not be available to all of those nodes > simultaneously. > > But you could certainly use etcd as the data store to build a sticky > available configuration data store. If, for example, you had many local > [1] etcd KVS that stored local data and synchronized the local data set > with other etcd KVS endpoints when a network partition was restored, you > could get such a system that was essentially "sticky available" for all > intents and purposes. > > Come to think of it, you could do the same with a SQLite DB, ala Swift's > replication of SQLite DBs via rsync. > > But, at the risk of sounding like a broken record, at the end of the > day, many of OpenStack's core services -- notably Nova -- were not > designed for disaggregated control planes. They were designed for the > datacenter, with tightly-packed compute resources and low-latency links > for the control plane. > > The entire communication bus and state management system would need to > be redesigned from the nova-compute to the nova-conductor for (far) edge > case clouds to be a true reality. > > Instead of sending all data updates synchronously from each nova-compute > to nova-conductor, the communication bus needs to be radically > redesigned so that the nova-compute uses a local data store *as its > primary data storage* and then asynchronously sends batched updates to > known control plane endpoints when those regular network partitions > correct themselves. > > The nova-compute manager will need to be substantially hardened to keep > itself up and running (and writing to that local state storage) for long > periods of time and contain all the logic to resync itself when network > uplinks become available again. > > Finally, if those local nova-computes need to actually *do* anything > other than keep existing VMs/baremetal machines up and running, then a > local Compute API service needs to be made available in the far edge > sites themselves -- offering some subset of Compute API functionality to > control the VMs in that local site. Otherwise, the whole "multiple > department stores running an edge OpenStack site that can tolerate the > Mother Ship being down" isn't a thing that will work. > > Like I said, pretty much a complete redesign of the nova control plane... We derived a little bit off the topic... but that all is valid for the post-MVP Edge architecture phases [0] targeted for multiple (aka disaggregated/autonomous/local vs central) control planes, indeed. Although there are more options than that complete redesign. IIUC, does the latter assume supporting alternative to SQL/AMQP-ish data/messaging backends for Nova and OpenStack in general? That is only an option (see such backends examples [1][2]), though I love it the most :) Other options may be creating client libraries acting on top of APIs or existing DB/MQ backends and performing low-level data synchronization, or acting as an API re-translators, over multiple control planes. And AFAICT that would *not* require complete redesign of supported backends nor types of transactions in Nova et al. And for MQ, a brokerless qdr or something (there was a nice presentation at the summit)... But in the end, indeed, it is kinda proved in multiple R&D papers, like [3],[4] that only causal sticky consistent synchronization with advanced conflicts resolving [5] is the best Edge-y/Fog-y choice for both such client libraries and causal consistent DB/KVS/MQ backends. I think that is something similar what you (Jay) diescribed for multiple Etcd cluster exchanging its data? So for that example, such client libraries should be maintaining sticky sessions to groups of those Etcd clusters and replicate data around doing it the best of causal consistent ways. PS. That a nice SQLight & rsync combo would not provide us the best of eventual consistency world, no, it would rather be something of a "Total Available" [6] thing, the lowest of it, like Read Uncommited or Monotonic Writes, and would be a very (very) poor choice IMO. [0] https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#Features_2 [1] https://www.ronpub.com/OJDB_2015v2i1n02_Elbushra.pdf [2] http://rainbowfs.lip6.fr/data/RainbowFS-2016-04-12.pdf [3] https://www.cs.cmu.edu/~dga/papers/cops-sosp2011.pdf [4] http://www.cs.cornell.edu/lorenzo/papers/cac-tr.pdf [5] https://ieeexplore.ieee.org/document/8104644 [6] https://jepsen.io/consistency > > Best, > -jay > > [1] or local-ish, think POPs or even local to the compute node itself... > >> [0] https://jepsen.io/consistency >> [1] >> https://github.com/bogdando/papers-ieee/blob/master/ICFC-2019/LaTeX/position_paper_1570506394.pdf -- Best regards, Bogdan Dobrelya, Irc #bogdando From sean.mcginnis at gmx.com Thu Nov 29 14:55:51 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Thu, 29 Nov 2018 08:55:51 -0600 Subject: [release][ptl] Holding all release activity Message-ID: <20181129145550.GA22659@sm-workstation> Hey everyone, There have been a rash of Pypi and other issues lately that have led to release job failures. We will be holding off on processing any more releases until we've seen some evidence that things have been resolved. I would guess this means that there will be no releases done until early next week. If you have a critical need for a release, please come talk to us in the #openstack-release channel and we can see if there is anything we can do in the interim. Thanks! Sean From gmann at ghanshyammann.com Thu Nov 29 15:01:14 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 30 Nov 2018 00:01:14 +0900 Subject: [dev] [tc][all] TC office hours is started now on #openstack-tc Message-ID: <1675ffcfc7c.127d21cc320083.6530131399546676655@ghanshyammann.com> Hi All, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - TC From mriedemos at gmail.com Thu Nov 29 15:28:46 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 29 Nov 2018 09:28:46 -0600 Subject: Fwd: [Openstack-operators] Nova hypervisor uuid In-Reply-To: References: <63283d3b-0661-7620-aaea-8ffbe9e483d8@gmail.com> Message-ID: <26bd8ef8-293e-20c6-0bf0-83ab076f843e@gmail.com> On 11/29/2018 12:49 AM, Ignazio Cassano wrote: > Hello Mattm > Yes I mean sometimes I have same host/node names with different uuid in > compute_nodes table in nova database > I must delete nodes with uuid those not match with nova-hypervisor list > command. > At this time I have the following: > MariaDB [nova]> select hypervisor_hostname,uuid,deleted from compute_nodes; > +---------------------+--------------------------------------+---------+ > | hypervisor_hostname | uuid                                 | deleted | > +---------------------+--------------------------------------+---------+ > | tst2-kvm02          | 802b21c2-11fb-4426-86b9-bf25c8a5ae1d |       0 | > | tst2-kvm01          | ce27803b-06cd-44a7-b927-1fa42c813b0f |       0 | > +---------------------+--------------------------------------+---------+ > 2 rows in set (0,00 sec) > > > But sometimes old uuid are inserted in the table . > I deleted again them. > I restarted kvm nodes and now the table is ok. > I also restarded each controller and the tables is ok. > I do not know because 3 days ago I had same compute nodes names with > different uuids. > > Thanks and Regards > Ignazio OK I guess if it happens again, please get the host/hypervisor_hostname/uuid/deleted values from the compute_nodes table before you cleanup any entries. Also, when you're deleting the resources from the DB, are you doing it in the DB directly or via the DELETE /os-services/{service_id} API? Because the latter cleans up other related resources to the nova-compute service (the services table record, the compute_nodes table record, the related resource_providers table record in placement, and the host_mappings table record in the nova API DB). The resource provider/host mappings cleanup when deleting a compute service is a more recent bug fix though which depending on your release you might not have: https://review.openstack.org/#/q/I7b8622b178d5043ed1556d7bdceaf60f47e5ac80 -- Thanks, Matt From sean.mcginnis at gmx.com Thu Nov 29 16:09:18 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Thu, 29 Nov 2018 10:09:18 -0600 Subject: [release] Release countdown for week R-18, Dec 3-7 Message-ID: <20181129160918.GA29100@sm-workstation> Welcome back from the Summit and holidays. Back to our regularly scheduled countdown emails. Development Focus ----------------- With the longer development cycle we are still a few weeks out until milestone 2. Hopefully folks got some good input and feedback and the Summit and Forum. Teams should be taking input and adjusting any earlier plans as needed based on this. General Information ------------------- Now may be a good time for teams to check on any stable releases that need to be done for your deliverables. If you have bugfixes that have been backported, but no stable release getting those. If you are unsure what is out there committed but not released, in the openstack/releases repo, running the command "tools/list_stable_unreleased_changes.sh " gives a nice report. Upcoming Deadlines & Dates -------------------------- Start using openstack-discuss ML: November 19 (in case you missed it) Stein-2 Milestone: January 10 -- Sean McGinnis (smcginnis) From gmann at ghanshyammann.com Thu Nov 29 16:17:05 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 30 Nov 2018 01:17:05 +0900 Subject: [Interop-wg] [dev] [cinder] [qa] Strict Validation for Volume API using JSON Schema Message-ID: <16760426d56.ef4c345622903.2195899647060980382@ghanshyammann.com> Hello everyone, Tempest is planning to add the strict API validation using JSON schema for Volume test [1]. We do the same for all the compute test. With *Strict* JSON schema validation, all the API response will be validated with predefined schema with additionalProperties=False. additionalProperties=False will not allow any additional attribute in API response than what upstream APIs has in their current version. For example: If any vendor has modified the API response and returning additional attributes then Tempest tests going to fail. This will help: - To improve the OpenStack interoperability. Strict validation of API response is always helpful to maintain the interoperability. - To improve the volume API testing to avoid the backward compatible changes. Sometime we accidentally change the API in backward incompatible way and strict validation with JSON schema help to block those. We want to hear from cinder and interop team about any impact of this change to them. [1] https://blueprints.launchpad.net/tempest/+spec/volume-response-schema-validation -gmann From thierry at openstack.org Thu Nov 29 16:22:48 2018 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 29 Nov 2018 17:22:48 +0100 Subject: [dev][qa][devstack] Release management for QA toold and plugins Message-ID: <20f06939-9590-4b93-3381-02c32570b990@openstack.org> Hi, QA folks, The release management team has been conducting a review of OpenStack official deliverables, to make sure nothing was falling between the cracks release-management-wise. As part of that review, we added a "release-management:" key to deliverables defined in the project governance repository in case they were not to be handled by the release management team using the openstack/releases repository. For example, some deliverables (like docs) are continuously published and therefore marked "release-management:none". Others (like charms) are released manually on 3rd-party platforms and therefore marked "release-management:external". In that context, several QA-maintained tools or related repos are a bit in limbo: * eslint-config-openstack: used to be released regularly, but was never released since we introduced openstack/releases. Should we just consider it cycle-independent, or drop the repository from governance ? * devstack-vagrant: never released, no change over the past year. Is it meant to be released in the future (cycle-independent) or considered continuously published (release-management:none) or should it be retired ? * karma-subunit-reporter: saw some early releases two years ago but not in recent times. Should we just consider it cycle-independent, or drop the repository from governance ? * devstack-plugin-*: Some of those were branched using openstack/releases back in Queens, but only devstack-plugin-container. was branched in Rocky. Some consistency here would be good. Should those all be branched every cycle in the future, or should we just branch none of them and consider them all continuously published (release-management:none) ? * devstack-tools: saw some early releases two years ago but not in recent times. Should we just consider it cycle-independent, or consider it abandoned ? Thanks in advance for your guidance, -- Thierry Carrez (ttx) On behalf of the release management team From mriedemos at gmail.com Thu Nov 29 16:28:53 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 29 Nov 2018 10:28:53 -0600 Subject: Fwd: [Openstack-operators] Nova hypervisor uuid In-Reply-To: References: <63283d3b-0661-7620-aaea-8ffbe9e483d8@gmail.com> <26bd8ef8-293e-20c6-0bf0-83ab076f843e@gmail.com> Message-ID: <097b1056-a883-48ec-8bc6-15267a987342@gmail.com> On 11/29/2018 10:27 AM, Ignazio Cassano wrote: > I did in the DB directly. > I am using queens now. > Any python client command to delete hold records or I must use api ? You can use the CLI: https://docs.openstack.org/python-novaclient/latest/cli/nova.html#nova-service-delete https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/compute-service.html#compute-service-delete -- Thanks, Matt From ignaziocassano at gmail.com Thu Nov 29 16:27:36 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Thu, 29 Nov 2018 17:27:36 +0100 Subject: Fwd: [Openstack-operators] Nova hypervisor uuid In-Reply-To: <26bd8ef8-293e-20c6-0bf0-83ab076f843e@gmail.com> References: <63283d3b-0661-7620-aaea-8ffbe9e483d8@gmail.com> <26bd8ef8-293e-20c6-0bf0-83ab076f843e@gmail.com> Message-ID: Hi Matt, I did in the DB directly. I am using queens now. Any python client command to delete hold records or I must use api ? Thanks & Regards Ignazio Il giorno gio 29 nov 2018 alle ore 16:28 Matt Riedemann ha scritto: > On 11/29/2018 12:49 AM, Ignazio Cassano wrote: > > Hello Mattm > > Yes I mean sometimes I have same host/node names with different uuid in > > compute_nodes table in nova database > > I must delete nodes with uuid those not match with nova-hypervisor list > > command. > > At this time I have the following: > > MariaDB [nova]> select hypervisor_hostname,uuid,deleted from > compute_nodes; > > +---------------------+--------------------------------------+---------+ > > | hypervisor_hostname | uuid | deleted | > > +---------------------+--------------------------------------+---------+ > > | tst2-kvm02 | 802b21c2-11fb-4426-86b9-bf25c8a5ae1d | 0 | > > | tst2-kvm01 | ce27803b-06cd-44a7-b927-1fa42c813b0f | 0 | > > +---------------------+--------------------------------------+---------+ > > 2 rows in set (0,00 sec) > > > > > > But sometimes old uuid are inserted in the table . > > I deleted again them. > > I restarted kvm nodes and now the table is ok. > > I also restarded each controller and the tables is ok. > > I do not know because 3 days ago I had same compute nodes names with > > different uuids. > > > > Thanks and Regards > > Ignazio > > OK I guess if it happens again, please get the > host/hypervisor_hostname/uuid/deleted values from the compute_nodes > table before you cleanup any entries. > > Also, when you're deleting the resources from the DB, are you doing it > in the DB directly or via the DELETE /os-services/{service_id} API? > Because the latter cleans up other related resources to the nova-compute > service (the services table record, the compute_nodes table record, the > related resource_providers table record in placement, and the > host_mappings table record in the nova API DB). The resource > provider/host mappings cleanup when deleting a compute service is a more > recent bug fix though which depending on your release you might not have: > > https://review.openstack.org/#/q/I7b8622b178d5043ed1556d7bdceaf60f47e5ac80 > > -- > > Thanks, > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekuvaja at redhat.com Thu Nov 29 16:50:12 2018 From: ekuvaja at redhat.com (ekuvaja at redhat.com) Date: Thu, 29 Nov 2018 16:50:12 +0000 Subject: [glance][ops][users]OpenStack Glance default visibility survey Message-ID: <000000000000eaea2a057bd079d5@google.com> I've invited you to fill out the following form: OpenStack Glance default visibility survey To fill it out, visit: https://docs.google.com/forms/d/e/1FAIpQLScbbmeLQrx34P84U-Wr2RoLOpXdWMEZg-XniBzVvSZnXzCYKg/viewform?vc=0&c=0&w=1&usp=mail_form_link Hello all, Time for another very quick survey from Glance team. This time we would like to get your feedback on if we should set the default visibility of newly created images to "private" or not. Please note this survey closes in a week and we will take the action based on the results provided. Erno jokke Kuvaja I've invited you to fill out a form: Google Forms: Create and analyze surveys. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mcginnis at gmx.com Thu Nov 29 17:07:50 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Thu, 29 Nov 2018 11:07:50 -0600 Subject: [release][ptl] Holding all release activity In-Reply-To: <20181129145550.GA22659@sm-workstation> References: <20181129145550.GA22659@sm-workstation> Message-ID: <20181129170750.GA3526@sm-workstation> On Thu, Nov 29, 2018 at 08:55:51AM -0600, Sean McGinnis wrote: > Hey everyone, > > There have been a rash of Pypi and other issues lately that have led to release > job failures. We will be holding off on processing any more releases until > we've seen some evidence that things have been resolved. I would guess this > means that there will be no releases done until early next week. > It appears the issues have been resolved and rerunning some of the previously failed jobs have now successfully completed. Thanks fungi for reenqueing those and all of the infra team for working through whatever the issues were. We can now start processing release requests again and will be monitoring them closely for any other issues. If you notice anything unusual, please let us know. Thanks! Sean From openstack at nemebean.com Thu Nov 29 17:10:19 2018 From: openstack at nemebean.com (Ben Nemec) Date: Thu, 29 Nov 2018 11:10:19 -0600 Subject: [dev][qa][devstack] Release management for QA toold and plugins In-Reply-To: <20f06939-9590-4b93-3381-02c32570b990@openstack.org> References: <20f06939-9590-4b93-3381-02c32570b990@openstack.org> Message-ID: <62b51db0-66c0-f173-d7eb-ab03f471187f@nemebean.com> On 11/29/18 10:22 AM, Thierry Carrez wrote: > Hi, QA folks, > > The release management team has been conducting a review of OpenStack > official deliverables, to make sure nothing was falling between the > cracks release-management-wise. > > As part of that review, we added a "release-management:" key to > deliverables defined in the project governance repository in case they > were not to be handled by the release management team using the > openstack/releases repository. For example, some deliverables (like > docs) are continuously published and therefore marked > "release-management:none". Others (like charms) are released manually on > 3rd-party platforms and therefore marked "release-management:external". > > In that context, several QA-maintained tools or related repos are a bit > in limbo: > > * eslint-config-openstack: used to be released regularly, but was never > released since we introduced openstack/releases. Should we just consider > it cycle-independent, or drop the repository from governance ? > > * devstack-vagrant: never released, no change over the past year. Is it > meant to be released in the future (cycle-independent) or considered > continuously published (release-management:none) or should it be retired ? > > * karma-subunit-reporter: saw some early releases two years ago but not > in recent times.  Should we just consider it cycle-independent, or drop > the repository from governance ? > > * devstack-plugin-*: Some of those were branched using > openstack/releases back in Queens, but only devstack-plugin-container. > was branched in Rocky. Some consistency here would be good. Should those > all be branched every cycle in the future, or should we just branch none > of them and consider them all continuously published > (release-management:none) ? For the messaging plugins, we had intended to start branching them every cycle: https://review.openstack.org/#/c/556602 It seems I forgot to submit the review to do so for the rocky release though. I'm not sure if it's too late to do that, but I submitted the review: https://review.openstack.org/620962 It's also on my end-of-release todo list now. > > * devstack-tools: saw some early releases two years ago but not in > recent times.  Should we just consider it cycle-independent, or consider > it abandoned ? > > Thanks in advance for your guidance, > From chris at openstack.org Thu Nov 29 17:17:13 2018 From: chris at openstack.org (Chris Hoge) Date: Thu, 29 Nov 2018 09:17:13 -0800 Subject: [loci] Release management for LOCI In-Reply-To: References: Message-ID: <3855B170-6E38-4DB9-A91C-9389D16D387F@openstack.org> It’s worthwhile to talk the current goals of Loci and how they relate to the project release. Loci is a set of Dockerfiles and scripts that builds OpenStack service containers from source. Loci can target container builds for three distributions (Ubuntu, CentOS, and Suse) and for all of the major OpenStack services. By default builds are from HEAD of master from each project, but can be set to build from stable project branches. What does this mean for release management of Loci? As of right now, any API changes to Loci remain backwards compatible. If you are using Loci to build container images, you will most likely benefit from running from master. We haven't made an official a release of Loci because that would imply that we believed an end user would benefit from a stable release point. So far, the Loci team has not felt that way. However, there is the possibility that for auditing purposes one would want to know the exact code that was used to build container images. To this end we'll discuss possible release version process at our weekly meeting tomorrow. If you are a user or potential user of Loci and have an opinion about this, please attend the meeting tomorrow (Friday November 30 at 1500 UTC in the #openstack-loci channel) or reply to this thread. There's also the possibility that to add major new features, like building container images from packages rather than source, we will have to introduce major API changes which would be useful to signal to end users. Right now no work has been done to advance package builds. As for artifacts created by Loci. The Loci gate publishes images to Docker Hub as part of its testing process. These are builds of OpenStack services from HEAD of master for each of these projects, and should not be used in production. The Loci team strongly encourages consumers of Loci containers to build and maintain their own image sets. This is considered best practice for security and maintainability. To answer your question, as of right now we are at 2: "not meant to be "released" or tagged but more like continuously published". This may change after the meeting tomorrow. Thanks, Chris > On Nov 29, 2018, at 2:38 AM, Thierry Carrez wrote: > > Hi, loci folks, > > The release management team has been conducting a review of OpenStack official deliverables, to make sure nothing was falling between the cracks release-management-wise. > > As part of that review, we added a "release-management:" key to deliverables defined in the project governance repository in case they were not to be handled by the release management team using the openstack/releases repository. For example, some deliverables (like docs) are continuously published and therefore marked "release-management:none". Others (like charms) are released manually on 3rd-party platforms and therefore marked "release-management:external". > > In that context, the situation of the loci deliverable (openstack/loci repository) is unclear. Is it: > > 1. meant to be released through the openstack/releases repository, but just not ready yet (any hint of when it will be ?) > > 2. not meant to be "released" or tagged but more like continuously published (in which case we should add "release-management:none" to it) > > 3. meant to be released, but on a 3rd-party platform like the Docker Hub and not using openstack/releases to drive it (in which case we should add "release-management:external" to it) > > From previous discussions it appears (2) would best describe the loci situation, but I wanted to doublecheck it was still the case. > > Thanks, > > -- > Thierry Carrez (ttx) > From ignaziocassano at gmail.com Thu Nov 29 17:22:21 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Thu, 29 Nov 2018 18:22:21 +0100 Subject: Fwd: [Openstack-operators] Nova hypervisor uuid In-Reply-To: <097b1056-a883-48ec-8bc6-15267a987342@gmail.com> References: <63283d3b-0661-7620-aaea-8ffbe9e483d8@gmail.com> <26bd8ef8-293e-20c6-0bf0-83ab076f843e@gmail.com> <097b1056-a883-48ec-8bc6-15267a987342@gmail.com> Message-ID: Many thks Matt. If the issue will happen again I hope openstack commands will show duplicate entries and let me clean them. When happened nova-hypervisor list command did not show duplcated entries but I saw them only in the database. Regards Ignazio Il giorno Gio 29 Nov 2018 17:28 Matt Riedemann ha scritto: > On 11/29/2018 10:27 AM, Ignazio Cassano wrote: > > I did in the DB directly. > > I am using queens now. > > Any python client command to delete hold records or I must use api ? > > You can use the CLI: > > > https://docs.openstack.org/python-novaclient/latest/cli/nova.html#nova-service-delete > > > https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/compute-service.html#compute-service-delete > > -- > > Thanks, > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jistr at redhat.com Thu Nov 29 17:42:08 2018 From: jistr at redhat.com (=?UTF-8?B?SmnFmcOtIFN0csOhbnNrw70=?=) Date: Thu, 29 Nov 2018 18:42:08 +0100 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> Message-ID: On 28. 11. 18 18:29, Bogdan Dobrelya wrote: > On 11/28/18 6:02 PM, Jiří Stránský wrote: >> >> >>> >>> Reiterating again on previous points: >>> >>> -I'd be fine removing systemd. But lets do it properly and not via 'rpm >>> -ev --nodeps'. >>> -Puppet and Ruby *are* required for configuration. We can certainly put >>> them in a separate container outside of the runtime service containers >>> but doing so would actually cost you much more space/bandwidth for each >>> service container. As both of these have to get downloaded to each node >>> anyway in order to generate config files with our current mechanisms >>> I'm not sure this buys you anything. >> >> +1. I was actually under the impression that we concluded yesterday on >> IRC that this is the only thing that makes sense to seriously consider. >> But even then it's not a win-win -- we'd gain some security by leaner >> production images, but pay for it with space+bandwidth by duplicating >> image content (IOW we can help achieve one of the goals we had in mind >> by worsening the situation w/r/t the other goal we had in mind.) >> >> Personally i'm not sold yet but it's something that i'd consider if we >> got measurements of how much more space/bandwidth usage this would >> consume, and if we got some further details/examples about how serious >> are the security concerns if we leave config mgmt tools in runtime images. >> >> IIRC the other options (that were brought forward so far) were already >> dismissed in yesterday's IRC discussion and on the reviews. Bin/lib bind >> mounting being too hacky and fragile, and nsenter not really solving the >> problem (because it allows us to switch to having different bins/libs >> available, but it does not allow merging the availability of bins/libs >> from two containers into a single context). >> >>> >>> We are going in circles here I think.... >> >> +1. I think too much of the discussion focuses on "why it's bad to have >> config tools in runtime images", but IMO we all sorta agree that it >> would be better not to have them there, if it came at no cost. >> >> I think to move forward, it would be interesting to know: if we do this >> (i'll borrow Dan's drawing): >> >> |base container| --> |service container| --> |service container w/ >> Puppet installed| >> >> How much more space and bandwidth would this consume per node (e.g. >> separately per controller, per compute). This could help with decision >> making. > > As I've already evaluated in the related bug, that is: > > puppet-* modules and manifests ~ 16MB > puppet with dependencies ~61MB > dependencies of the seemingly largest a dependency, systemd ~190MB > > that would be an extra layer size for each of the container images to be > downloaded/fetched into registries. Thanks, i tried to do the math of the reduction vs. inflation in sizes as follows. I think the crucial point here is the layering. If we do this image layering: |base| --> |+ service| --> |+ Puppet| we'd drop ~267 MB from base image, but we'd be installing that to the topmost level, per-component, right? In my basic deployment, undercloud seems to have 17 "components" (49 containers), overcloud controller 15 components (48 containers), and overcloud compute 4 components (7 containers). Accounting for overlaps, the total number of "components" used seems to be 19. (By "components" here i mean whatever uses a different ConfigImage than other services. I just eyeballed it but i think i'm not too far off the correct number.) So we'd subtract 267 MB from base image and add that to 19 leaf images used in this deployment. That means difference of +4.8 GB to the current image sizes. My /var/lib/registry dir on undercloud with all the images currently has 5.1 GB. We'd almost double that to 9.9 GB. Going from 5.1 to 9.9 GB seems like a lot of extra traffic for the CDNs (both external and e.g. internal within OpenStack Infra CI clouds). And for internal traffic between local registry and overcloud nodes, it gives +3.7 GB per controller and +800 MB per compute. That may not be so critical but still feels like a considerable downside. Another gut feeling is that this way of image layering would take longer time to build and to run the modify-image Ansible role which we use in CI, so that could endanger how our CI jobs fit into the time limit. We could also probably measure this but i'm not sure if it's worth spending the time. All in all i'd argue we should be looking at different options still. > > Given that we should decouple systemd from all/some of the dependencies > (an example topic for RDO [0]), that could save a 190MB. But it seems we > cannot break the love of puppet and systemd as it heavily relies on the > latter and changing packaging like that would higly likely affect > baremetal deployments with puppet and systemd co-operating. Ack :/ > > Long story short, we cannot shoot both rabbits with a single shot, not > with puppet :) May be we could with ansible replacing puppet fully... > So splitting config and runtime images is the only choice yet to address > the raised security concerns. And let's forget about edge cases for now. > Tossing around a pair of extra bytes over 40,000 WAN-distributed > computes ain't gonna be our the biggest problem for sure. > > [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction > >> >>> >>> Dan >>> >> >> Thanks >> >> Jirka >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From aschultz at redhat.com Thu Nov 29 18:09:16 2018 From: aschultz at redhat.com (Alex Schultz) Date: Thu, 29 Nov 2018 11:09:16 -0700 Subject: [tripleo] gate is backed up (again) Message-ID: Ahoy folks. We're running into a massive backlog and it's messing with everyone again. As stop gap, we're clearing the gate and will need to land the patches to switch them back to non-voting and remove the scenarios[0] from the gate in stable branches. We had switched them back to voting ~2 weeks ago because they were still in the gate (but non-voting). I thought we weren't going to run into as many issues in the stable branches but we've been backporting a bit more lately. We are proposing this because in the gate we've had a bunch of scenario failures[1] not related to code but just time outs. Additionally we're making progress on converting the master scenario jobs to standalone versions which may be backportable to stable/rocky. So in the mean time, we're asking that you not approve or recheck anything until the CI has stabilized. We'll send out a note when we're clear. Thanks, -Alex [0] https://review.openstack.org/#/q/topic:scenarios-nv+(status:open+OR+status:merged) [1] http://zuul.openstack.org/builds?pipeline=gate&result=failure&result=timed_out&result=post_failure&project=openstack%2Ftripleo-common&project=openstack%2Ftripleo-heat-templates&project=openstack%2Fpython-tripleoclient From mtreinish at kortar.org Thu Nov 29 19:16:36 2018 From: mtreinish at kortar.org (Matthew Treinish) Date: Thu, 29 Nov 2018 14:16:36 -0500 Subject: [dev][qa][devstack] Release management for QA toold and plugins In-Reply-To: <20f06939-9590-4b93-3381-02c32570b990@openstack.org> References: <20f06939-9590-4b93-3381-02c32570b990@openstack.org> Message-ID: <20181129191636.GA26514@sinanju.localdomain> On Thu, Nov 29, 2018 at 05:22:48PM +0100, Thierry Carrez wrote: > Hi, QA folks, > > The release management team has been conducting a review of OpenStack > official deliverables, to make sure nothing was falling between the cracks > release-management-wise. > > As part of that review, we added a "release-management:" key to deliverables > defined in the project governance repository in case they were not to be > handled by the release management team using the openstack/releases > repository. For example, some deliverables (like docs) are continuously > published and therefore marked "release-management:none". Others (like > charms) are released manually on 3rd-party platforms and therefore marked > "release-management:external". > > In that context, several QA-maintained tools or related repos are a bit in > limbo: > > * eslint-config-openstack: used to be released regularly, but was never > released since we introduced openstack/releases. Should we just consider it > cycle-independent, or drop the repository from governance ? This is a cycle independent tool, it's the equivalent of hacking but for js code. I know that projects are still using it, even if it's not super active the rules are pretty static and haven't need an update in a while. > > * devstack-vagrant: never released, no change over the past year. Is it > meant to be released in the future (cycle-independent) or considered > continuously published (release-management:none) or should it be retired ? I'll wait for gmann to weigh in on retiring it or not, but it doesn't need releases, it's just a tool repo for deploying a VM and setting up devstack using vagrant. It hasn't been active in a couple years, personally I've never used it so I don't know if it even works still or not. I'd vote for retiring it, but I haven't paid attention to it in a long time, so maybe it's still useful. > > * karma-subunit-reporter: saw some early releases two years ago but not in > recent times. Should we just consider it cycle-independent, or drop the > repository from governance ? This is also cycle independent, it's a tool for generating subunit streams from karma test runs. It's something we use for js unit tests and getting results into openstack-health and similar tools. It's also used externally a couple places. > > * devstack-plugin-*: Some of those were branched using openstack/releases > back in Queens, but only devstack-plugin-container. was branched in Rocky. > Some consistency here would be good. Should those all be branched every > cycle in the future, or should we just branch none of them and consider them > all continuously published (release-management:none) ? These would only ever be branched, since like devstack there aren't actually releases for it, just branches. As for the status of the plugins different ones are maintained by different teams depending on the plugins. I know a few fall under QA, but I personally don't know the status of them or whether they still work or not. > > * devstack-tools: saw some early releases two years ago but not in recent > times. Should we just consider it cycle-independent, or consider it > abandoned ? This is a package that is also cycle-independent, it's a support tool for devstack which is still used there. It just performs some operations which were much easier to write in python then in bash (mainly around manipulating config files iirc). Its usage is pretty stable right now so we haven't needed to release it in a while. -Matt Treinish -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From Kevin.Fox at pnnl.gov Thu Nov 29 19:20:14 2018 From: Kevin.Fox at pnnl.gov (Fox, Kevin M) Date: Thu, 29 Nov 2018 19:20:14 +0000 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> , Message-ID: <1A3C52DFCD06494D8528644858247BF01C24AC91@EX10MBOX03.pnnl.gov> If the base layers are shared, you won't pay extra for the separate puppet container unless you have another container also installing ruby in an upper layer. With OpenStack, thats unlikely. the apparent size of a container is not equal to its actual size. Thanks, Kevin ________________________________________ From: Jiří Stránský [jistr at redhat.com] Sent: Thursday, November 29, 2018 9:42 AM To: openstack-dev at lists.openstack.org Subject: Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes On 28. 11. 18 18:29, Bogdan Dobrelya wrote: > On 11/28/18 6:02 PM, Jiří Stránský wrote: >> >> >>> >>> Reiterating again on previous points: >>> >>> -I'd be fine removing systemd. But lets do it properly and not via 'rpm >>> -ev --nodeps'. >>> -Puppet and Ruby *are* required for configuration. We can certainly put >>> them in a separate container outside of the runtime service containers >>> but doing so would actually cost you much more space/bandwidth for each >>> service container. As both of these have to get downloaded to each node >>> anyway in order to generate config files with our current mechanisms >>> I'm not sure this buys you anything. >> >> +1. I was actually under the impression that we concluded yesterday on >> IRC that this is the only thing that makes sense to seriously consider. >> But even then it's not a win-win -- we'd gain some security by leaner >> production images, but pay for it with space+bandwidth by duplicating >> image content (IOW we can help achieve one of the goals we had in mind >> by worsening the situation w/r/t the other goal we had in mind.) >> >> Personally i'm not sold yet but it's something that i'd consider if we >> got measurements of how much more space/bandwidth usage this would >> consume, and if we got some further details/examples about how serious >> are the security concerns if we leave config mgmt tools in runtime images. >> >> IIRC the other options (that were brought forward so far) were already >> dismissed in yesterday's IRC discussion and on the reviews. Bin/lib bind >> mounting being too hacky and fragile, and nsenter not really solving the >> problem (because it allows us to switch to having different bins/libs >> available, but it does not allow merging the availability of bins/libs >> from two containers into a single context). >> >>> >>> We are going in circles here I think.... >> >> +1. I think too much of the discussion focuses on "why it's bad to have >> config tools in runtime images", but IMO we all sorta agree that it >> would be better not to have them there, if it came at no cost. >> >> I think to move forward, it would be interesting to know: if we do this >> (i'll borrow Dan's drawing): >> >> |base container| --> |service container| --> |service container w/ >> Puppet installed| >> >> How much more space and bandwidth would this consume per node (e.g. >> separately per controller, per compute). This could help with decision >> making. > > As I've already evaluated in the related bug, that is: > > puppet-* modules and manifests ~ 16MB > puppet with dependencies ~61MB > dependencies of the seemingly largest a dependency, systemd ~190MB > > that would be an extra layer size for each of the container images to be > downloaded/fetched into registries. Thanks, i tried to do the math of the reduction vs. inflation in sizes as follows. I think the crucial point here is the layering. If we do this image layering: |base| --> |+ service| --> |+ Puppet| we'd drop ~267 MB from base image, but we'd be installing that to the topmost level, per-component, right? In my basic deployment, undercloud seems to have 17 "components" (49 containers), overcloud controller 15 components (48 containers), and overcloud compute 4 components (7 containers). Accounting for overlaps, the total number of "components" used seems to be 19. (By "components" here i mean whatever uses a different ConfigImage than other services. I just eyeballed it but i think i'm not too far off the correct number.) So we'd subtract 267 MB from base image and add that to 19 leaf images used in this deployment. That means difference of +4.8 GB to the current image sizes. My /var/lib/registry dir on undercloud with all the images currently has 5.1 GB. We'd almost double that to 9.9 GB. Going from 5.1 to 9.9 GB seems like a lot of extra traffic for the CDNs (both external and e.g. internal within OpenStack Infra CI clouds). And for internal traffic between local registry and overcloud nodes, it gives +3.7 GB per controller and +800 MB per compute. That may not be so critical but still feels like a considerable downside. Another gut feeling is that this way of image layering would take longer time to build and to run the modify-image Ansible role which we use in CI, so that could endanger how our CI jobs fit into the time limit. We could also probably measure this but i'm not sure if it's worth spending the time. All in all i'd argue we should be looking at different options still. > > Given that we should decouple systemd from all/some of the dependencies > (an example topic for RDO [0]), that could save a 190MB. But it seems we > cannot break the love of puppet and systemd as it heavily relies on the > latter and changing packaging like that would higly likely affect > baremetal deployments with puppet and systemd co-operating. Ack :/ > > Long story short, we cannot shoot both rabbits with a single shot, not > with puppet :) May be we could with ansible replacing puppet fully... > So splitting config and runtime images is the only choice yet to address > the raised security concerns. And let's forget about edge cases for now. > Tossing around a pair of extra bytes over 40,000 WAN-distributed > computes ain't gonna be our the biggest problem for sure. > > [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction > >> >>> >>> Dan >>> >> >> Thanks >> >> Jirka >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From kennelson11 at gmail.com Thu Nov 29 19:26:54 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Thu, 29 Nov 2018 11:26:54 -0800 Subject: [all] [infra] StoryBoard Migration: The Remaining Blockers Summary In-Reply-To: <1675f6c1eed.10dfd565213161.955867480698696118@ghanshyammann.com> References: <1675f6c1eed.10dfd565213161.955867480698696118@ghanshyammann.com> Message-ID: Thanks Ghanshyam! We'll check them out. -Kendall (diablo_rojo) On Thu, Nov 29, 2018 at 4:23 AM Ghanshyam Mann wrote: > ---- On Wed, 28 Nov 2018 07:45:11 +0900 Kendall Nelson < > kennelson11 at gmail.com> wrote ---- > > Hello! > > As with all of my other summaries, if you are looking for the long > etherpad version, you can find it here[1]. Somewhere along the way I used > the wrong etherpad for notes and so we ended up doing the StoryBoard things > in the etherpad originally meant for another session so pardon the name. > > > > Anywho. > > > > Overall the session went really well, there weren’t any huge glaring > issues that anyone brought up. The majority of things were all smaller > usability things. Just about all of which are definitely doable. > > > > The only slightly larger feature request (that we hadn't previously > discussed) was a separate interface for filing stories- similar to the one > LP provides. Something simple so the user doesn’t feel like they need to > fill in all this information, but can just provide the minimum. I haven’t > quite gotten around to making stories for all of the things discussed in > the etherpad, but should have them up soon! You will be able to see them > here[2], once they’ve been created. > > > > If you have opinions about any of what we discussed or have something > you wanted to bring up but could not attend the session please drop into > #storyboard and chat with us, or join us at our weekly meeting on Wednesday > at 19:00 UTC. > > Thanks diablo_rojo for summary. To followup the discussion from QA PTG > denver sessions, I have logged three stories[1] for QA requirement to > start the migration. > > [1] > https://storyboard.openstack.org/#!/story/2004465 > https://storyboard.openstack.org/#!/story/2004466 > https://storyboard.openstack.org/#!/story/2004467 > > -gmann > > > > > -Kendall (diablo_rojo) > > > > [1]https://etherpad.openstack.org/p/BER-Contrib-Portal-Feedback (yes, > I know the name doesn’t seem right..) > > [2] > https://storyboard.openstack.org/#!/story/list?status=active&project_group_id=57 > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.davis at suse.com Thu Nov 29 19:30:00 2018 From: joseph.davis at suse.com (Joseph Davis) Date: Thu, 29 Nov 2018 11:30:00 -0800 Subject: [all][ptl][heat][senlin][magnum]New SIG for Autoscaling? plus, Session Summary: Autoscaling Integration, improvement, and feedback Message-ID: I agree with Duc and Witek that this communication could be really good. One of the first items for a new SIG would be to define the relationship with the Self-Healing SIG. The two SIGs have a lot in common but some important differences. They can both use some of the same tools and data (Heat, Monasca, Senlin, Vitrage, etc) to achieve their purpose, but Self-Healing is about recovering a cloud when something goes wrong, while Autoscaling is about adjusting resources to avoid something going wrong. Having a clear statement may help a new user or contributor understand where there interests lie and how they can be part of the group. Writing some clear use cases will be really valuable for all the component teams to reference. It may also be of value to identify a few reference architectures or configurations to illustrate how the use cases could be addressed. I'm thinking of stories like "A cloud with Monasca and Senlin services has 20 active VMs. When Monasca recognizes the 20 VMs have hit 90% utilization each it raises an alarm and Senlin triggers the creation of 5 more VMs to meet expected loads." Plus lots of details I just skipped over. :) joseph On Wed, Nov 28, 2018 at 4:00 AM Rico Lin wrote: > > I gonna use this ML to give a summary of the forum [1] and asking for > feedback for the idea of new SIG. > > So if you have any thoughts for the new SIG (good or bad) please share it > here. > > [1] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback On Thu, 29 Nov 2018 09:32:17 "Bedyk, Witold" wrote: > Hi Rico, > > Thanks for this initiative. I think the SIG could be a good channel to coordinate this work across the projects. > > From Monasca perspective, I would like to make sure that we provide all necessary monitoring data to cover the defined use cases and that Monasca alarms can be seamlessly consumed by the integrated services. > We’re also interested in contributing documentation in the central place. > > I’m sure operators will be thankful for having a channel for providing dedicated feedback. > > Cheers > Witek From Kevin.Fox at pnnl.gov Thu Nov 29 19:38:17 2018 From: Kevin.Fox at pnnl.gov (Fox, Kevin M) Date: Thu, 29 Nov 2018 19:38:17 +0000 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <1A3C52DFCD06494D8528644858247BF01C24AC91@EX10MBOX03.pnnl.gov> References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> , , <1A3C52DFCD06494D8528644858247BF01C24AC91@EX10MBOX03.pnnl.gov> Message-ID: <1A3C52DFCD06494D8528644858247BF01C24ACE9@EX10MBOX03.pnnl.gov> Oh, rereading the conversation again, the concern is having shared deps move up layers? so more systemd related then ruby? The conversation about --nodeps makes it sound like its not actually used. Just an artifact of how the rpms are built... What about creating a dummy package that provides(systemd)? That avoids using --nodeps. Thanks, Kevin ________________________________________ From: Fox, Kevin M [Kevin.Fox at pnnl.gov] Sent: Thursday, November 29, 2018 11:20 AM To: Former OpenStack Development Mailing List, use openstack-discuss now Subject: Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes If the base layers are shared, you won't pay extra for the separate puppet container unless you have another container also installing ruby in an upper layer. With OpenStack, thats unlikely. the apparent size of a container is not equal to its actual size. Thanks, Kevin ________________________________________ From: Jiří Stránský [jistr at redhat.com] Sent: Thursday, November 29, 2018 9:42 AM To: openstack-dev at lists.openstack.org Subject: Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes On 28. 11. 18 18:29, Bogdan Dobrelya wrote: > On 11/28/18 6:02 PM, Jiří Stránský wrote: >> >> >>> >>> Reiterating again on previous points: >>> >>> -I'd be fine removing systemd. But lets do it properly and not via 'rpm >>> -ev --nodeps'. >>> -Puppet and Ruby *are* required for configuration. We can certainly put >>> them in a separate container outside of the runtime service containers >>> but doing so would actually cost you much more space/bandwidth for each >>> service container. As both of these have to get downloaded to each node >>> anyway in order to generate config files with our current mechanisms >>> I'm not sure this buys you anything. >> >> +1. I was actually under the impression that we concluded yesterday on >> IRC that this is the only thing that makes sense to seriously consider. >> But even then it's not a win-win -- we'd gain some security by leaner >> production images, but pay for it with space+bandwidth by duplicating >> image content (IOW we can help achieve one of the goals we had in mind >> by worsening the situation w/r/t the other goal we had in mind.) >> >> Personally i'm not sold yet but it's something that i'd consider if we >> got measurements of how much more space/bandwidth usage this would >> consume, and if we got some further details/examples about how serious >> are the security concerns if we leave config mgmt tools in runtime images. >> >> IIRC the other options (that were brought forward so far) were already >> dismissed in yesterday's IRC discussion and on the reviews. Bin/lib bind >> mounting being too hacky and fragile, and nsenter not really solving the >> problem (because it allows us to switch to having different bins/libs >> available, but it does not allow merging the availability of bins/libs >> from two containers into a single context). >> >>> >>> We are going in circles here I think.... >> >> +1. I think too much of the discussion focuses on "why it's bad to have >> config tools in runtime images", but IMO we all sorta agree that it >> would be better not to have them there, if it came at no cost. >> >> I think to move forward, it would be interesting to know: if we do this >> (i'll borrow Dan's drawing): >> >> |base container| --> |service container| --> |service container w/ >> Puppet installed| >> >> How much more space and bandwidth would this consume per node (e.g. >> separately per controller, per compute). This could help with decision >> making. > > As I've already evaluated in the related bug, that is: > > puppet-* modules and manifests ~ 16MB > puppet with dependencies ~61MB > dependencies of the seemingly largest a dependency, systemd ~190MB > > that would be an extra layer size for each of the container images to be > downloaded/fetched into registries. Thanks, i tried to do the math of the reduction vs. inflation in sizes as follows. I think the crucial point here is the layering. If we do this image layering: |base| --> |+ service| --> |+ Puppet| we'd drop ~267 MB from base image, but we'd be installing that to the topmost level, per-component, right? In my basic deployment, undercloud seems to have 17 "components" (49 containers), overcloud controller 15 components (48 containers), and overcloud compute 4 components (7 containers). Accounting for overlaps, the total number of "components" used seems to be 19. (By "components" here i mean whatever uses a different ConfigImage than other services. I just eyeballed it but i think i'm not too far off the correct number.) So we'd subtract 267 MB from base image and add that to 19 leaf images used in this deployment. That means difference of +4.8 GB to the current image sizes. My /var/lib/registry dir on undercloud with all the images currently has 5.1 GB. We'd almost double that to 9.9 GB. Going from 5.1 to 9.9 GB seems like a lot of extra traffic for the CDNs (both external and e.g. internal within OpenStack Infra CI clouds). And for internal traffic between local registry and overcloud nodes, it gives +3.7 GB per controller and +800 MB per compute. That may not be so critical but still feels like a considerable downside. Another gut feeling is that this way of image layering would take longer time to build and to run the modify-image Ansible role which we use in CI, so that could endanger how our CI jobs fit into the time limit. We could also probably measure this but i'm not sure if it's worth spending the time. All in all i'd argue we should be looking at different options still. > > Given that we should decouple systemd from all/some of the dependencies > (an example topic for RDO [0]), that could save a 190MB. But it seems we > cannot break the love of puppet and systemd as it heavily relies on the > latter and changing packaging like that would higly likely affect > baremetal deployments with puppet and systemd co-operating. Ack :/ > > Long story short, we cannot shoot both rabbits with a single shot, not > with puppet :) May be we could with ansible replacing puppet fully... > So splitting config and runtime images is the only choice yet to address > the raised security concerns. And let's forget about edge cases for now. > Tossing around a pair of extra bytes over 40,000 WAN-distributed > computes ain't gonna be our the biggest problem for sure. > > [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction > >> >>> >>> Dan >>> >> >> Thanks >> >> Jirka >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From jistr at redhat.com Thu Nov 29 19:44:46 2018 From: jistr at redhat.com (=?UTF-8?B?SmnFmcOtIFN0csOhbnNrw70=?=) Date: Thu, 29 Nov 2018 20:44:46 +0100 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <1A3C52DFCD06494D8528644858247BF01C24AC91@EX10MBOX03.pnnl.gov> References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> <1A3C52DFCD06494D8528644858247BF01C24AC91@EX10MBOX03.pnnl.gov> Message-ID: <96f1bbd8-0519-cddb-19f3-ea3c61fe09f6@redhat.com> On 29. 11. 18 20:20, Fox, Kevin M wrote: > If the base layers are shared, you won't pay extra for the separate puppet container Yes, and that's the state we're in right now. >unless you have another container also installing ruby in an upper layer. Not just Ruby but also Puppet and Systemd. I think that's what the proposal we're discussing here suggests -- removing this content from the base layer (so that we can get service runtime images without this content present) and putting this content *on top* of individual service images. Unless i'm missing some trick to start sharing *top* layers rather than *base* layers, i think that effectively disables the space sharing for the Ruby+Puppet+Systemd content. > With OpenStack, thats unlikely. > > the apparent size of a container is not equal to its actual size. Yes. :) Thanks Jirka > > Thanks, > Kevin > ________________________________________ > From: Jiří Stránský [jistr at redhat.com] > Sent: Thursday, November 29, 2018 9:42 AM > To: openstack-dev at lists.openstack.org > Subject: Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes > > On 28. 11. 18 18:29, Bogdan Dobrelya wrote: >> On 11/28/18 6:02 PM, Jiří Stránský wrote: >>> >>> >>>> >>>> Reiterating again on previous points: >>>> >>>> -I'd be fine removing systemd. But lets do it properly and not via 'rpm >>>> -ev --nodeps'. >>>> -Puppet and Ruby *are* required for configuration. We can certainly put >>>> them in a separate container outside of the runtime service containers >>>> but doing so would actually cost you much more space/bandwidth for each >>>> service container. As both of these have to get downloaded to each node >>>> anyway in order to generate config files with our current mechanisms >>>> I'm not sure this buys you anything. >>> >>> +1. I was actually under the impression that we concluded yesterday on >>> IRC that this is the only thing that makes sense to seriously consider. >>> But even then it's not a win-win -- we'd gain some security by leaner >>> production images, but pay for it with space+bandwidth by duplicating >>> image content (IOW we can help achieve one of the goals we had in mind >>> by worsening the situation w/r/t the other goal we had in mind.) >>> >>> Personally i'm not sold yet but it's something that i'd consider if we >>> got measurements of how much more space/bandwidth usage this would >>> consume, and if we got some further details/examples about how serious >>> are the security concerns if we leave config mgmt tools in runtime images. >>> >>> IIRC the other options (that were brought forward so far) were already >>> dismissed in yesterday's IRC discussion and on the reviews. Bin/lib bind >>> mounting being too hacky and fragile, and nsenter not really solving the >>> problem (because it allows us to switch to having different bins/libs >>> available, but it does not allow merging the availability of bins/libs >>> from two containers into a single context). >>> >>>> >>>> We are going in circles here I think.... >>> >>> +1. I think too much of the discussion focuses on "why it's bad to have >>> config tools in runtime images", but IMO we all sorta agree that it >>> would be better not to have them there, if it came at no cost. >>> >>> I think to move forward, it would be interesting to know: if we do this >>> (i'll borrow Dan's drawing): >>> >>> |base container| --> |service container| --> |service container w/ >>> Puppet installed| >>> >>> How much more space and bandwidth would this consume per node (e.g. >>> separately per controller, per compute). This could help with decision >>> making. >> >> As I've already evaluated in the related bug, that is: >> >> puppet-* modules and manifests ~ 16MB >> puppet with dependencies ~61MB >> dependencies of the seemingly largest a dependency, systemd ~190MB >> >> that would be an extra layer size for each of the container images to be >> downloaded/fetched into registries. > > Thanks, i tried to do the math of the reduction vs. inflation in sizes > as follows. I think the crucial point here is the layering. If we do > this image layering: > > |base| --> |+ service| --> |+ Puppet| > > we'd drop ~267 MB from base image, but we'd be installing that to the > topmost level, per-component, right? > > In my basic deployment, undercloud seems to have 17 "components" (49 > containers), overcloud controller 15 components (48 containers), and > overcloud compute 4 components (7 containers). Accounting for overlaps, > the total number of "components" used seems to be 19. (By "components" > here i mean whatever uses a different ConfigImage than other services. I > just eyeballed it but i think i'm not too far off the correct number.) > > So we'd subtract 267 MB from base image and add that to 19 leaf images > used in this deployment. That means difference of +4.8 GB to the current > image sizes. My /var/lib/registry dir on undercloud with all the images > currently has 5.1 GB. We'd almost double that to 9.9 GB. > > Going from 5.1 to 9.9 GB seems like a lot of extra traffic for the CDNs > (both external and e.g. internal within OpenStack Infra CI clouds). > > And for internal traffic between local registry and overcloud nodes, it > gives +3.7 GB per controller and +800 MB per compute. That may not be so > critical but still feels like a considerable downside. > > Another gut feeling is that this way of image layering would take longer > time to build and to run the modify-image Ansible role which we use in > CI, so that could endanger how our CI jobs fit into the time limit. We > could also probably measure this but i'm not sure if it's worth spending > the time. > > All in all i'd argue we should be looking at different options still. > >> >> Given that we should decouple systemd from all/some of the dependencies >> (an example topic for RDO [0]), that could save a 190MB. But it seems we >> cannot break the love of puppet and systemd as it heavily relies on the >> latter and changing packaging like that would higly likely affect >> baremetal deployments with puppet and systemd co-operating. > > Ack :/ > >> >> Long story short, we cannot shoot both rabbits with a single shot, not >> with puppet :) May be we could with ansible replacing puppet fully... >> So splitting config and runtime images is the only choice yet to address >> the raised security concerns. And let's forget about edge cases for now. >> Tossing around a pair of extra bytes over 40,000 WAN-distributed >> computes ain't gonna be our the biggest problem for sure. >> >> [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction >> >>> >>>> >>>> Dan >>>> >>> >>> Thanks >>> >>> Jirka >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From juliaashleykreger at gmail.com Thu Nov 29 20:06:56 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Thu, 29 Nov 2018 12:06:56 -0800 Subject: [ironic] Finding a time to discuss cleaning/deployment steps visibility Message-ID: Greetings everyone, As discussed previously, I'd like to find a time when we can get on a higher bandwidth medium to discuss making clean and deployment steps visible. Generally we've struggled to gain consensus and I'd like for us to focus on trying to reach a minimally viable feature. I've created a doodle at: https://doodle.com/poll/yan4wyvztf7mpq46 Most recent specification: https://review.openstack.org/#/c/606199/ -Julia -------------- next part -------------- An HTML attachment was scrubbed... URL: From feilong at catalyst.net.nz Thu Nov 29 21:06:52 2018 From: feilong at catalyst.net.nz (Feilong Wang) Date: Fri, 30 Nov 2018 10:06:52 +1300 Subject: [openstack-dev] [magnum] [Rocky] K8 deployment on fedora-atomic is failed In-Reply-To: References: Message-ID: Hi Vikrant, Before we dig more, it would be nice if you can let us know the version of your Magnum and Heat. Cheers. On 30/11/18 12:12 AM, Vikrant Aggarwal wrote: > Hello Team, > > Trying to deploy on K8 on fedora atomic. > > Here is the output of cluster template: > ~~~ > [root at packstack1 k8s_fedora_atomic_v1(keystone_admin)]# magnum > cluster-template-show 16eb91f7-18fe-4ce3-98db-c732603f2e57 > WARNING: The magnum client is deprecated and will be removed in a > future release. > Use the OpenStack client to avoid seeing this message. > +-----------------------+--------------------------------------+ > | Property              | Value                                | > +-----------------------+--------------------------------------+ > | insecure_registry     | -                                    | > | labels                | {}                                   | > | updated_at            | -                                    | > | floating_ip_enabled   | True                                 | > | fixed_subnet          | -                                    | > | master_flavor_id      | -                                    | > | user_id               | 203617849df9490084dde1897b28eb53     | > | uuid                  | 16eb91f7-18fe-4ce3-98db-c732603f2e57 | > | no_proxy              | -                                    | > | https_proxy           | -                                    | > | tls_disabled          | False                                | > | keypair_id            | kubernetes                           | > | project_id            | 45a6706c831c42d5bf2da928573382b1     | > | public                | False                                | > | http_proxy            | -                                    | > | docker_volume_size    | 10                                   | > | server_type           | vm                                   | > | external_network_id   | external1                            | > | cluster_distro        | fedora-atomic                        | > | image_id              | f5954340-f042-4de3-819e-a3b359591770 | > | volume_driver         | -                                    | > | registry_enabled      | False                                | > | docker_storage_driver | devicemapper                         | > | apiserver_port        | -                                    | > | name                  | coe-k8s-template                     | > | created_at            | 2018-11-28T12:58:21+00:00            | > | network_driver        | flannel                              | > | fixed_network         | -                                    | > | coe                   | kubernetes                           | > | flavor_id             | m1.small                             | > | master_lb_enabled     | False                                | > | dns_nameserver        | 8.8.8.8                              | > +-----------------------+--------------------------------------+ > ~~~ > Found couple of issues in the logs of VM started by magnum. > > - etcd was not getting started because of incorrect permission on file > "/etc/etcd/certs/server.key". This file is owned by root by default > have 0440 as permission. Changed the permission to 0444 so that etcd > can read the file. After that etcd started successfully. > > - etcd DB doesn't contain anything: > > [root at kube-cluster1-qobaagdob75g-master-0 ~]# etcdctl ls / -r > [root at kube-cluster1-qobaagdob75g-master-0 ~]# > > - Flanneld is stuck in activating status. > ~~~ > [root at kube-cluster1-qobaagdob75g-master-0 ~]# systemctl status flanneld > ● flanneld.service - Flanneld overlay address etcd agent >    Loaded: loaded (/usr/lib/systemd/system/flanneld.service; enabled; > vendor preset: disabled) >    Active: activating (start) since Thu 2018-11-29 11:05:39 UTC; 14s ago >  Main PID: 6491 (flanneld) >     Tasks: 6 (limit: 4915) >    Memory: 4.7M >       CPU: 53ms >    CGroup: /system.slice/flanneld.service >            └─6491 /usr/bin/flanneld > -etcd-endpoints=http://127.0.0.1:2379 -etcd-prefix=/atomic.io/network > > > Nov 29 11:05:44 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:44.569376    6491 network.go:102] failed > to retrieve network config: 100: Key not found (/atomic.io > ) [3] > Nov 29 11:05:45 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:45.584532    6491 network.go:102] failed > to retrieve network config: 100: Key not found (/atomic.io > ) [3] > Nov 29 11:05:46 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:46.646255    6491 network.go:102] failed > to retrieve network config: 100: Key not found (/atomic.io > ) [3] > Nov 29 11:05:47 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:47.673062    6491 network.go:102] failed > to retrieve network config: 100: Key not found (/atomic.io > ) [3] > Nov 29 11:05:48 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:48.686919    6491 network.go:102] failed > to retrieve network config: 100: Key not found (/atomic.io > ) [3] > Nov 29 11:05:49 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:49.709136    6491 network.go:102] failed > to retrieve network config: 100: Key not found (/atomic.io > ) [3] > Nov 29 11:05:50 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:50.729548    6491 network.go:102] failed > to retrieve network config: 100: Key not found (/atomic.io > ) [3] > Nov 29 11:05:51 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:51.749425    6491 network.go:102] failed > to retrieve network config: 100: Key not found (/atomic.io > ) [3] > Nov 29 11:05:52 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:52.776612    6491 network.go:102] failed > to retrieve network config: 100: Key not found (/atomic.io > ) [3] > Nov 29 11:05:53 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:53.790418    6491 network.go:102] failed > to retrieve network config: 100: Key not found (/atomic.io > ) [3] > ~~~ > > - Continuously in the jouralctl logs following messages are printed. > > ~~~ > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal > kube-apiserver[6888]: F1129 11:06:39.338416    6888 server.go:269] > Invalid Authorization Config: Unknown authorization mode Node specified > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal > systemd[1]: kube-apiserver.service: Main process exited, code=exited, > status=255/n/a > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal > kube-scheduler[2540]: E1129 11:06:39.408272    2540 reflector.go:199] > k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:463 > : > Failed to list *api.Node: Get > http://127.0.0.1:8080/api/v1/nodes?resourceVersion=0: dial tcp > 127.0.0.1:8080 : getsockopt: connection refused > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal > kube-scheduler[2540]: E1129 11:06:39.444737    2540 reflector.go:199] > k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:460 > : > Failed to list *api.Pod: Get > http://127.0.0.1:8080/api/v1/pods?fieldSelector=spec.nodeName%21%3D%2Cstatus.phase%21%3DFailed%2Cstatus.phase%21%3DSucceeded&resourceVersion=0: > dial tcp 127.0.0.1:8080 : getsockopt: > connection refused > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal > kube-scheduler[2540]: E1129 11:06:39.445793    2540 reflector.go:199] > k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:466 > : > Failed to list *api.PersistentVolume: Get > http://127.0.0.1:8080/api/v1/persistentvolumes?resourceVersion=0: dial > tcp 127.0.0.1:8080 : getsockopt: connection refused > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal > audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 > subj=system_u:system_r:init_t:s0 msg='unit=kube-apiserver > comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? > terminal=? res=failed' > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal > systemd[1]: Failed to start Kubernetes API Server. > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal > systemd[1]: kube-apiserver.service: Unit entered failed state. > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal > systemd[1]: kube-apiserver.service: Failed with result 'exit-code'. > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal > kube-scheduler[2540]: E1129 11:06:39.611699    2540 reflector.go:199] > k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:481 > : > Failed to list *extensions.ReplicaSet: Get > http://127.0.0.1:8080/apis/extensions/v1beta1/replicasets?resourceVersion=0: > dial tcp 127.0.0.1:8080 : getsockopt: > connection refused > ~~~ > > Any help on above issue is highly appreciated. > > Thanks & Regards, > Vikrant Aggarwal > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Cheers & Best regards, Feilong Wang (王飞龙) -------------------------------------------------------------------------- Senior Cloud Software Engineer Tel: +64-48032246 Email: flwang at catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington -------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From mrhillsman at gmail.com Thu Nov 29 21:18:59 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Thu, 29 Nov 2018 15:18:59 -0600 Subject: [openlab] November Update Message-ID: Hi everyone, We should have been doing this - totally my fault here - and hope you find updates at least monthly re OpenLab useful. In order to allow all people participating in OpenLab to provide details on the updates we are using etherpad: https://etherpad.openlabtesting.org/p/november2018update Thanks to all the community members helping to make OpenLab successful! -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mcginnis at gmx.com Thu Nov 29 21:47:43 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Thu, 29 Nov 2018 15:47:43 -0600 Subject: [openlab] November Update In-Reply-To: References: Message-ID: <20181129214742.GA21732@sm-workstation> On Thu, Nov 29, 2018 at 03:18:59PM -0600, Melvin Hillsman wrote: > Hi everyone, > > We should have been doing this - totally my fault here - and hope you find > updates at least monthly re OpenLab useful. In order to allow all people > participating in OpenLab to provide details on the updates we are using > etherpad: > > https://etherpad.openlabtesting.org/p/november2018update > > Thanks to all the community members helping to make OpenLab successful! > Thanks for sending this out Melvin. Looks like a lot of great stuff happening with OpenLab. Very cool to see it grow. Sean From jillr at redhat.com Fri Nov 30 00:21:08 2018 From: jillr at redhat.com (Jill Rouleau) Date: Thu, 29 Nov 2018 17:21:08 -0700 Subject: [tripleo] Expose healthchecks via systemd for podman Message-ID: <1543537268.4569.20.camel@redhat.com> The healthchecks currently in use in tripleo depend on the the docker healthcheck implementation, so podman/oci containers will not expose them.  The /openstack/healthcheck script is still available in the images, we just need a way to run the checks and expose the result. https://review.openstack.org/#/c/620372/ proposes having paunch write out a $service-healthcheck systemd unit and corresponding timer. Interested in what folks think about the approach. -Jill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mriedemos at gmail.com Fri Nov 30 02:28:24 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 29 Nov 2018 20:28:24 -0600 Subject: [Interop-wg] [dev] [cinder] [qa] Strict Validation for Volume API using JSON Schema In-Reply-To: <16760426d56.ef4c345622903.2195899647060980382@ghanshyammann.com> References: <16760426d56.ef4c345622903.2195899647060980382@ghanshyammann.com> Message-ID: <29d271ff-d5a7-2a28-53c1-3be7b868ad20@gmail.com> On 11/29/2018 10:17 AM, Ghanshyam Mann wrote: > - To improve the volume API testing to avoid the backward compatible changes. Sometime we accidentally change the API in backward incompatible way and strict validation with JSON schema help to block those. +1 this is very useful to avoid unintentionally breaking the API. > > We want to hear from cinder and interop team about any impact of this change to them. I'm mostly interested in what the interop WG would do about this given it's a potentially breaking change for interop without changes to the guidelines. Would there be some sort of grace period for clouds to conform to the changes in tempest? -- Thanks, Matt From gmann at ghanshyammann.com Fri Nov 30 02:39:16 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 30 Nov 2018 11:39:16 +0900 Subject: [dev][qa][devstack] Release management for QA toold and plugins In-Reply-To: <20181129191636.GA26514@sinanju.localdomain> References: <20f06939-9590-4b93-3381-02c32570b990@openstack.org> <20181129191636.GA26514@sinanju.localdomain> Message-ID: <167627c0fb2.fedfd67828981.6889702971134127091@ghanshyammann.com> ---- On Fri, 30 Nov 2018 04:16:36 +0900 Matthew Treinish wrote ---- > On Thu, Nov 29, 2018 at 05:22:48PM +0100, Thierry Carrez wrote: > > Hi, QA folks, > > > > The release management team has been conducting a review of OpenStack > > official deliverables, to make sure nothing was falling between the cracks > > release-management-wise. > > > > As part of that review, we added a "release-management:" key to deliverables > > defined in the project governance repository in case they were not to be > > handled by the release management team using the openstack/releases > > repository. For example, some deliverables (like docs) are continuously > > published and therefore marked "release-management:none". Others (like > > charms) are released manually on 3rd-party platforms and therefore marked > > "release-management:external". > > > > In that context, several QA-maintained tools or related repos are a bit in > > limbo: > > > > * eslint-config-openstack: used to be released regularly, but was never > > released since we introduced openstack/releases. Should we just consider it > > cycle-independent, or drop the repository from governance ? > > This is a cycle independent tool, it's the equivalent of hacking but for js > code. I know that projects are still using it, even if it's not super active > the rules are pretty static and haven't need an update in a while. Yeah, This and other few QA tools are kind of not required much development and static but they are being used. As matt mentioned, they are cycle independent tool and get a release on the need basis. As they do not require much resource bandwidth and might be used by someone, there is no harm to keeping them in QA. I am not sure which release tag we should give to them ("release-management:none" and "release-management:external" does not fit for them) but I am ok to keep their release model as it is and give some appropriate tag. > > > > > * devstack-vagrant: never released, no change over the past year. Is it > > meant to be released in the future (cycle-independent) or considered > > continuously published (release-management:none) or should it be retired ? > > I'll wait for gmann to weigh in on retiring it or not, but it doesn't need > releases, it's just a tool repo for deploying a VM and setting up devstack > using vagrant. It hasn't been active in a couple years, personally I've never > used it so I don't know if it even works still or not. I'd vote for retiring > it, but I haven't paid attention to it in a long time, so maybe it's still > useful. I am ok to retire this based on no one using it. And honestly saying, it is hard to judge that no one using it especially from the users who are not engaged in community communication etc. But i can start the ML and summit/PTG discussion to check its usage and then take the decision. > > > > > * karma-subunit-reporter: saw some early releases two years ago but not in > > recent times. Should we just consider it cycle-independent, or drop the > > repository from governance ? > > This is also cycle independent, it's a tool for generating subunit streams > from karma test runs. It's something we use for js unit tests and getting > results into openstack-health and similar tools. It's also used externally > a couple places. ditto as eslint-config-openstack. > > > > > * devstack-plugin-*: Some of those were branched using openstack/releases > > back in Queens, but only devstack-plugin-container. was branched in Rocky. > > Some consistency here would be good. Should those all be branched every > > cycle in the future, or should we just branch none of them and consider them > > all continuously published (release-management:none) ? > > These would only ever be branched, since like devstack there aren't actually > releases for it, just branches. As for the status of the plugins different ones > are maintained by different teams depending on the plugins. I know a few fall > under QA, but I personally don't know the status of them or whether they still > work or not. I am not aware of all plugins but plugins under QA are: - devstack-plugin-container - as you mentioned, it is branched. - devstack-plugin-ceph - This is branchless. About branching them consistently, I will say it depends on plugin scope whether that needs to be branched or not. For example, devstack-plugin-ceph was not required as branched as no branch specific things in that. ceph configuration is all same for all branch. Doing branch on this will be unnecessary work. > > > > > * devstack-tools: saw some early releases two years ago but not in recent > > times. Should we just consider it cycle-independent, or consider it > > abandoned ? > > This is a package that is also cycle-independent, it's a support tool for > devstack which is still used there. It just performs some operations which > were much easier to write in python then in bash (mainly around manipulating > config files iirc). Its usage is pretty stable right now so we haven't > needed to release it in a while. Ditto as eslint-config-openstack -gmann > > -Matt Treinish > From duc.openstack at gmail.com Fri Nov 30 05:29:24 2018 From: duc.openstack at gmail.com (Duc Truong) Date: Thu, 29 Nov 2018 21:29:24 -0800 Subject: [dev][qa][devstack] Release management for QA toold and plugins In-Reply-To: <167627c0fb2.fedfd67828981.6889702971134127091@ghanshyammann.com> References: <20f06939-9590-4b93-3381-02c32570b990@openstack.org> <20181129191636.GA26514@sinanju.localdomain> <167627c0fb2.fedfd67828981.6889702971134127091@ghanshyammann.com> Message-ID: On Thu, Nov 29, 2018 at 6:39 PM Ghanshyam Mann wrote: > > > > * devstack-vagrant: never released, no change over the past year. Is it > > > meant to be released in the future (cycle-independent) or considered > > > continuously published (release-management:none) or should it be retired ? > > > > I am ok to retire this based on no one using it. I actually use devstack-vagrant and find it useful to setup consistent devstack environments with minimal effort. Duc From gmann at ghanshyammann.com Fri Nov 30 07:27:56 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 30 Nov 2018 16:27:56 +0900 Subject: [dev][qa][devstack] Release management for QA toold and plugins In-Reply-To: References: <20f06939-9590-4b93-3381-02c32570b990@openstack.org> <20181129191636.GA26514@sinanju.localdomain> <167627c0fb2.fedfd67828981.6889702971134127091@ghanshyammann.com> Message-ID: <167638457ad.fe9b8693739.8314446462346139058@ghanshyammann.com> ---- On Fri, 30 Nov 2018 14:29:24 +0900 Duc Truong wrote ---- > On Thu, Nov 29, 2018 at 6:39 PM Ghanshyam Mann wrote: > > > > > > * devstack-vagrant: never released, no change over the past year. Is it > > > > meant to be released in the future (cycle-independent) or considered > > > > continuously published (release-management:none) or should it be retired ? > > > > > > > I am ok to retire this based on no one using it. > > I actually use devstack-vagrant and find it useful to setup consistent > devstack environments with minimal effort. Ok, then we can keep that. I will be happy to add you as maintainer of that if you would like to. I saw you have done some commit and review in Tempest and will be good to have you as devstack-vagrant . -gmann > > Duc > From mike.carden at gmail.com Fri Nov 30 07:53:12 2018 From: mike.carden at gmail.com (Mike Carden) Date: Fri, 30 Nov 2018 18:53:12 +1100 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> Message-ID: I'm seeing a similar issue in Queens deployed via tripleo. Two x86 compute nodes and one ppc64le node and host aggregates for virtual instances and baremetal (x86) instances. Baremetal on x86 is working fine. All VMs get deployed to compute-0. I can live migrate VMs to compute-1 and all is well, but I tire of being the 'meatspace scheduler'. I've looked at the nova.conf in the various nova-xxx containers on the controllers, but I have failed to discern the root of this issue. Anyone have a suggestion? -- MC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdobreli at redhat.com Fri Nov 30 09:31:15 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Fri, 30 Nov 2018 10:31:15 +0100 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> Message-ID: On 11/29/18 6:42 PM, Jiří Stránský wrote: > On 28. 11. 18 18:29, Bogdan Dobrelya wrote: >> On 11/28/18 6:02 PM, Jiří Stránský wrote: >>> >>> >>>> >>>> Reiterating again on previous points: >>>> >>>> -I'd be fine removing systemd. But lets do it properly and not via 'rpm >>>> -ev --nodeps'. >>>> -Puppet and Ruby *are* required for configuration. We can certainly put >>>> them in a separate container outside of the runtime service containers >>>> but doing so would actually cost you much more space/bandwidth for each >>>> service container. As both of these have to get downloaded to each node >>>> anyway in order to generate config files with our current mechanisms >>>> I'm not sure this buys you anything. >>> >>> +1. I was actually under the impression that we concluded yesterday on >>> IRC that this is the only thing that makes sense to seriously consider. >>> But even then it's not a win-win -- we'd gain some security by leaner >>> production images, but pay for it with space+bandwidth by duplicating >>> image content (IOW we can help achieve one of the goals we had in mind >>> by worsening the situation w/r/t the other goal we had in mind.) >>> >>> Personally i'm not sold yet but it's something that i'd consider if we >>> got measurements of how much more space/bandwidth usage this would >>> consume, and if we got some further details/examples about how serious >>> are the security concerns if we leave config mgmt tools in runtime >>> images. >>> >>> IIRC the other options (that were brought forward so far) were already >>> dismissed in yesterday's IRC discussion and on the reviews. Bin/lib bind >>> mounting being too hacky and fragile, and nsenter not really solving the >>> problem (because it allows us to switch to having different bins/libs >>> available, but it does not allow merging the availability of bins/libs >>> from two containers into a single context). >>> >>>> >>>> We are going in circles here I think.... >>> >>> +1. I think too much of the discussion focuses on "why it's bad to have >>> config tools in runtime images", but IMO we all sorta agree that it >>> would be better not to have them there, if it came at no cost. >>> >>> I think to move forward, it would be interesting to know: if we do this >>> (i'll borrow Dan's drawing): >>> >>> |base container| --> |service container| --> |service container w/ >>> Puppet installed| >>> >>> How much more space and bandwidth would this consume per node (e.g. >>> separately per controller, per compute). This could help with decision >>> making. >> >> As I've already evaluated in the related bug, that is: >> >> puppet-* modules and manifests ~ 16MB >> puppet with dependencies ~61MB >> dependencies of the seemingly largest a dependency, systemd ~190MB >> >> that would be an extra layer size for each of the container images to be >> downloaded/fetched into registries. > > Thanks, i tried to do the math of the reduction vs. inflation in sizes > as follows. I think the crucial point here is the layering. If we do > this image layering: > > |base| --> |+ service| --> |+ Puppet| > > we'd drop ~267 MB from base image, but we'd be installing that to the > topmost level, per-component, right? Given we detached systemd from puppet, cronie et al, that would be 267-190MB, so the math below would be looking much better > > In my basic deployment, undercloud seems to have 17 "components" (49 > containers), overcloud controller 15 components (48 containers), and > overcloud compute 4 components (7 containers). Accounting for overlaps, > the total number of "components" used seems to be 19. (By "components" > here i mean whatever uses a different ConfigImage than other services. I > just eyeballed it but i think i'm not too far off the correct number.) > > So we'd subtract 267 MB from base image and add that to 19 leaf images > used in this deployment. That means difference of +4.8 GB to the current > image sizes. My /var/lib/registry dir on undercloud with all the images > currently has 5.1 GB. We'd almost double that to 9.9 GB. > > Going from 5.1 to 9.9 GB seems like a lot of extra traffic for the CDNs > (both external and e.g. internal within OpenStack Infra CI clouds). > > And for internal traffic between local registry and overcloud nodes, it > gives +3.7 GB per controller and +800 MB per compute. That may not be so > critical but still feels like a considerable downside. > > Another gut feeling is that this way of image layering would take longer > time to build and to run the modify-image Ansible role which we use in > CI, so that could endanger how our CI jobs fit into the time limit. We > could also probably measure this but i'm not sure if it's worth spending > the time. > > All in all i'd argue we should be looking at different options still. > >> >> Given that we should decouple systemd from all/some of the dependencies >> (an example topic for RDO [0]), that could save a 190MB. But it seems we >> cannot break the love of puppet and systemd as it heavily relies on the >> latter and changing packaging like that would higly likely affect >> baremetal deployments with puppet and systemd co-operating. > > Ack :/ > >> >> Long story short, we cannot shoot both rabbits with a single shot, not >> with puppet :) May be we could with ansible replacing puppet fully... >> So splitting config and runtime images is the only choice yet to address >> the raised security concerns. And let's forget about edge cases for now. >> Tossing around a pair of extra bytes over 40,000 WAN-distributed >> computes ain't gonna be our the biggest problem for sure. >> >> [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction >> >>> >>>> >>>> Dan >>>> >>> >>> Thanks >>> >>> Jirka >>> >>> __________________________________________________________________________ >>> >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Bogdan Dobrelya, Irc #bogdando From thierry at openstack.org Fri Nov 30 10:05:36 2018 From: thierry at openstack.org (Thierry Carrez) Date: Fri, 30 Nov 2018 11:05:36 +0100 Subject: [dev][qa][devstack] Release management for QA toold and plugins In-Reply-To: <167638457ad.fe9b8693739.8314446462346139058@ghanshyammann.com> References: <20f06939-9590-4b93-3381-02c32570b990@openstack.org> <20181129191636.GA26514@sinanju.localdomain> <167627c0fb2.fedfd67828981.6889702971134127091@ghanshyammann.com> <167638457ad.fe9b8693739.8314446462346139058@ghanshyammann.com> Message-ID: <6be6bbf3-a862-df85-5120-b90f5c74c1cf@openstack.org> Ghanshyam Mann wrote: > ---- On Fri, 30 Nov 2018 14:29:24 +0900 Duc Truong wrote ---- > > On Thu, Nov 29, 2018 at 6:39 PM Ghanshyam Mann wrote: > > > > > > > > * devstack-vagrant: never released, no change over the past year. Is it > > > > > meant to be released in the future (cycle-independent) or considered > > > > > continuously published (release-management:none) or should it be retired ? > > > > > > > > > > I am ok to retire this based on no one using it. > > > > I actually use devstack-vagrant and find it useful to setup consistent > > devstack environments with minimal effort. > > Ok, then we can keep that. I will be happy to add you as maintainer of that if you would like to. I saw you have done some commit and review in Tempest and will be good to have you as devstack-vagrant . OK so in summary: eslint-config-openstack, karma-subunit-reporter, devstack-tools -> should be considered cycle-independent (with older releases history imported). Any future release would be done through openstack/releases devstack-vagrant -> does not need releases or release management, will be marked release-management:none in governance devstack-plugin-ceph -> does not need releases or cycle-related branching, so will be marked release-management:none in governance Other devstack-plugins maintainers should pick whether they need to be branched every cycle or not. Oslo-maintained plugins like devstack-plugin-zmq and devstack-plugin-pika will, for example. Unless someone objects, I'll push the related changes where needed. Thanks for the clarification ! -- Thierry Carrez (ttx) From hberaud at redhat.com Fri Nov 30 10:07:38 2018 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 30 Nov 2018 11:07:38 +0100 Subject: [oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch In-Reply-To: References: <20181122234340.GE24690@thor.bakeyournoodle.com> <1ca0e1a7-58a1-8f91-617b-7be7b0df0e1b@redhat.com> <32c01016-6f23-d00c-356f-be68aa0cb29e@nemebean.com> Message-ID: For resume we decide to use: - #4 (https://review.openstack.org/#/c/619360/) - #3 (https://review.openstack.org/#/c/619342/) Also I've propose the oslo.service 1.31.7 since #3 have been merged ( https://review.openstack.org/#/c/619342/) : https://review.openstack.org/#/c/620913/ Le jeu. 29 nov. 2018 à 14:56, Herve Beraud a écrit : > FYI Introducing oslo.service 1.31.7 with the latest merged changes. > These refers to #3. > https://review.openstack.org/#/c/620913/ > > Le mer. 28 nov. 2018 à 00:31, Ben Nemec a écrit : > >> >> >> On 11/26/18 9:47 AM, Zane Bitter wrote: >> > On 22/11/18 6:43 PM, Tony Breeds wrote: >> >>> ### 3 - Maintain a private interface for ThreadingEvent only on >> >>> stable/rocky >> >>> impacted projects: oslo.service >> >>> related reviews: >> >>> -https://review.openstack.org/619342/ >> >>> >> >>> pros: >> >>> - straightforward >> >>> cons: >> >>> - Changing the loopingcall module semantics as it is different type >> >>> - stable only patches >> >>> - misunderstoud service customer between Threading, eventlet, etc.. >> and >> >>> master behavior >> >> A variation of this (without adding the debtcollector requirement) >> might >> >> work as IIUC all versions of oslo.service < 1.32.0 (except 1.31.6) >> would >> >> work and doesn't introduce any new policy violations. >> >> >> >> Adding debcollector is great but introduces at least the semver issues >> >> from option #1 >> > >> > Hey Tony, can you explain the debtcollector issue a bit more? Is it >> just >> > that we generally promise to not adding anything to requirements.txt on >> > stable branches? In this case, debtcollector, appears to already be a >> > transitive dependency of something that oslo.service already requires >> > (it appears in lower-constraints.txt, at least), so I was assuming that >> > there wouldn't be any real-world consequences. Does that change things? >> >> Technically adding a new dep requires a minor version update per our >> release guidelines. I guess it gets a little fuzzy when you're adding a >> dep that's already part of the transitive set, but I'm guessing that's >> what Tony was referring to. >> >> That said, as I mentioned on the review I don't feel any particular need >> to debtcollector this. It's in a private module that nobody should ever >> have been using and we're only doing this because we prioritize fixing >> the bug over absolute API purity. :-) >> >> In any case, I'm +1 on doing this to avoid creating weird version >> dependencies on a stable branch. >> >> > >> > TBH it would be trivial to do something equivalent without adding the >> > new requirement, so I guess the easiest thing is if I just update the >> > patch to do that. >> > >> >>> ### 4 - Don't use private interface in oslo.service >> >>> impacted projects: nova >> >>> related reviews: >> >>> -https://review.openstack.org/#/c/619360/ >> >>> >> >>> pros: >> >>> - straightforward >> >>> cons: >> >>> - this could work but it is not the same sematics as before as the >> >>> type has >> >>> changed >> >>> - stable only patches >> >>> - misunderstoud service customer between Threading, eventlet, etc.. >> and >> >>> master behavior >> >> I think this is more or less the same as Option #3 in terms of impact. >> >> If that's right it could be acceptable. >> > >> > It's slightly higher impact, because you wouldn't be able to upgrade >> > oslo.service past 1.31.5 and still run the unit tests on old versions >> of >> > Nova. Whereas with option #3 you could just upgrade oslo.service to >> > 1.31.7, or just upgrade Nova, and either way everything would work. >> > >> > Not that we shouldn't do this *as well*, but IMHO we still need to do >> #3. >> > >> >> I like doing this as well. If we need an argument as to why it's okay to >> do this stable-only patch, it would be that this is essentially a >> backport of the original Nova fix proposed before we decided to do the >> fixture. In retrospect maybe we should have gone ahead and merged that >> simple, backportable fix and done the fixture as a followup, but in >> spirit this has the same effect. >> >> -Ben >> >> > > -- > Hervé Beraud > Senior Software Engineer > Red Hat - Openstack Oslo > irc: hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbooth at redhat.com Fri Nov 30 12:06:56 2018 From: mbooth at redhat.com (Matthew Booth) Date: Fri, 30 Nov 2018 12:06:56 +0000 Subject: [openstack-dev] [nova] Would an api option to create an instance without powering on be useful? Message-ID: I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on. This would involve an api change, and a hopefully very small change in drivers to support it. Technically I don't see it as an issue. However, is it a change we'd be willing to accept? Is there any good reason not to do this? Are there any less esoteric workflows which might use this feature? Matt -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG Phone: +442070094448 (UK) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From mbooth at redhat.com Fri Nov 30 12:06:56 2018 From: mbooth at redhat.com (Matthew Booth) Date: Fri, 30 Nov 2018 12:06:56 +0000 Subject: [Openstack-operators] [nova] Would an api option to create an instance without powering on be useful? Message-ID: I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on. This would involve an api change, and a hopefully very small change in drivers to support it. Technically I don't see it as an issue. However, is it a change we'd be willing to accept? Is there any good reason not to do this? Are there any less esoteric workflows which might use this feature? Matt -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG Phone: +442070094448 (UK) _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From dprince at redhat.com Fri Nov 30 12:52:08 2018 From: dprince at redhat.com (Dan Prince) Date: Fri, 30 Nov 2018 07:52:08 -0500 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> Message-ID: <7d2fce52ca8bb5156b753a95cbb9e2df7ad741c8.camel@redhat.com> On Fri, 2018-11-30 at 10:31 +0100, Bogdan Dobrelya wrote: > On 11/29/18 6:42 PM, Jiří Stránský wrote: > > On 28. 11. 18 18:29, Bogdan Dobrelya wrote: > > > On 11/28/18 6:02 PM, Jiří Stránský wrote: > > > > > > > > > > > > > Reiterating again on previous points: > > > > > > > > > > -I'd be fine removing systemd. But lets do it properly and > > > > > not via 'rpm > > > > > -ev --nodeps'. > > > > > -Puppet and Ruby *are* required for configuration. We can > > > > > certainly put > > > > > them in a separate container outside of the runtime service > > > > > containers > > > > > but doing so would actually cost you much more > > > > > space/bandwidth for each > > > > > service container. As both of these have to get downloaded to > > > > > each node > > > > > anyway in order to generate config files with our current > > > > > mechanisms > > > > > I'm not sure this buys you anything. > > > > > > > > +1. I was actually under the impression that we concluded > > > > yesterday on > > > > IRC that this is the only thing that makes sense to seriously > > > > consider. > > > > But even then it's not a win-win -- we'd gain some security by > > > > leaner > > > > production images, but pay for it with space+bandwidth by > > > > duplicating > > > > image content (IOW we can help achieve one of the goals we had > > > > in mind > > > > by worsening the situation w/r/t the other goal we had in > > > > mind.) > > > > > > > > Personally i'm not sold yet but it's something that i'd > > > > consider if we > > > > got measurements of how much more space/bandwidth usage this > > > > would > > > > consume, and if we got some further details/examples about how > > > > serious > > > > are the security concerns if we leave config mgmt tools in > > > > runtime > > > > images. > > > > > > > > IIRC the other options (that were brought forward so far) were > > > > already > > > > dismissed in yesterday's IRC discussion and on the reviews. > > > > Bin/lib bind > > > > mounting being too hacky and fragile, and nsenter not really > > > > solving the > > > > problem (because it allows us to switch to having different > > > > bins/libs > > > > available, but it does not allow merging the availability of > > > > bins/libs > > > > from two containers into a single context). > > > > > > > > > We are going in circles here I think.... > > > > > > > > +1. I think too much of the discussion focuses on "why it's bad > > > > to have > > > > config tools in runtime images", but IMO we all sorta agree > > > > that it > > > > would be better not to have them there, if it came at no cost. > > > > > > > > I think to move forward, it would be interesting to know: if we > > > > do this > > > > (i'll borrow Dan's drawing): > > > > > > > > > base container| --> |service container| --> |service > > > > > container w/ > > > > Puppet installed| > > > > > > > > How much more space and bandwidth would this consume per node > > > > (e.g. > > > > separately per controller, per compute). This could help with > > > > decision > > > > making. > > > > > > As I've already evaluated in the related bug, that is: > > > > > > puppet-* modules and manifests ~ 16MB > > > puppet with dependencies ~61MB > > > dependencies of the seemingly largest a dependency, systemd > > > ~190MB > > > > > > that would be an extra layer size for each of the container > > > images to be > > > downloaded/fetched into registries. > > > > Thanks, i tried to do the math of the reduction vs. inflation in > > sizes > > as follows. I think the crucial point here is the layering. If we > > do > > this image layering: > > > > > base| --> |+ service| --> |+ Puppet| > > > > we'd drop ~267 MB from base image, but we'd be installing that to > > the > > topmost level, per-component, right? > > Given we detached systemd from puppet, cronie et al, that would be > 267-190MB, so the math below would be looking much better Would it be worth writing a spec that summarizes what action items are bing taken to optimize our base image with regards to the systemd? It seems like the general consenses is that cleaning up some of the RPM dependencies so that we don't install Systemd is the biggest win. What confuses me is why are there still patches posted to move Puppet out of the base layer when we agree moving it out of the base layer would actually cause our resulting container image set to be larger in size. Dan > > > In my basic deployment, undercloud seems to have 17 "components" > > (49 > > containers), overcloud controller 15 components (48 containers), > > and > > overcloud compute 4 components (7 containers). Accounting for > > overlaps, > > the total number of "components" used seems to be 19. (By > > "components" > > here i mean whatever uses a different ConfigImage than other > > services. I > > just eyeballed it but i think i'm not too far off the correct > > number.) > > > > So we'd subtract 267 MB from base image and add that to 19 leaf > > images > > used in this deployment. That means difference of +4.8 GB to the > > current > > image sizes. My /var/lib/registry dir on undercloud with all the > > images > > currently has 5.1 GB. We'd almost double that to 9.9 GB. > > > > Going from 5.1 to 9.9 GB seems like a lot of extra traffic for the > > CDNs > > (both external and e.g. internal within OpenStack Infra CI clouds). > > > > And for internal traffic between local registry and overcloud > > nodes, it > > gives +3.7 GB per controller and +800 MB per compute. That may not > > be so > > critical but still feels like a considerable downside. > > > > Another gut feeling is that this way of image layering would take > > longer > > time to build and to run the modify-image Ansible role which we use > > in > > CI, so that could endanger how our CI jobs fit into the time limit. > > We > > could also probably measure this but i'm not sure if it's worth > > spending > > the time. > > > > All in all i'd argue we should be looking at different options > > still. > > > > > Given that we should decouple systemd from all/some of the > > > dependencies > > > (an example topic for RDO [0]), that could save a 190MB. But it > > > seems we > > > cannot break the love of puppet and systemd as it heavily relies > > > on the > > > latter and changing packaging like that would higly likely affect > > > baremetal deployments with puppet and systemd co-operating. > > > > Ack :/ > > > > > Long story short, we cannot shoot both rabbits with a single > > > shot, not > > > with puppet :) May be we could with ansible replacing puppet > > > fully... > > > So splitting config and runtime images is the only choice yet to > > > address > > > the raised security concerns. And let's forget about edge cases > > > for now. > > > Tossing around a pair of extra bytes over 40,000 WAN-distributed > > > computes ain't gonna be our the biggest problem for sure. > > > > > > [0] > > > https://review.rdoproject.org/r/#/q/topic:base-container-reduction > > > > > > > > Dan > > > > > > > > > > > > > Thanks > > > > > > > > Jirka > > > > > > > > _______________________________________________________________ > > > > ___________ > > > > > > > > OpenStack Development Mailing List (not for usage questions) > > > > Unsubscribe: > > > > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___________________________________________________________________ > > _______ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsu > > bscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > From dprince at redhat.com Fri Nov 30 13:13:25 2018 From: dprince at redhat.com (Dan Prince) Date: Fri, 30 Nov 2018 08:13:25 -0500 Subject: [tripleo] Expose healthchecks via systemd for podman In-Reply-To: <1543537268.4569.20.camel@redhat.com> References: <1543537268.4569.20.camel@redhat.com> Message-ID: <8557589b0bbcbefb248243f0143595b9df1635f0.camel@redhat.com> On Thu, 2018-11-29 at 17:21 -0700, Jill Rouleau wrote: > The healthchecks currently in use in tripleo depend on the the docker > healthcheck implementation, so podman/oci containers will not expose > them. The /openstack/healthcheck script is still available in the > images, we just need a way to run the checks and expose the result. > > https://review.openstack.org/#/c/620372/ proposes having paunch write > out a $service-healthcheck systemd unit and corresponding timer. With Docker our health checks weren't used for anything other than information if I recall. Is the idea here that you would use systemd to obtain the healthcheck status for any given service? And then monitoring tools could call that periodically as a crude means of obtaining the status of each service? Or is the intent here to go a step further and have systemd take some kind of action if things are healthy like restarting the service. Dan > > Interested in what folks think about the approach. > > -Jill From cdent+os at anticdent.org Fri Nov 30 13:15:20 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Fri, 30 Nov 2018 13:15:20 +0000 (GMT) Subject: [placement] update 18-48 Message-ID: HTML: https://anticdent.org/placement-update-18-48.html Here's a placement update. It's been a rather busy week in placement-land: Gibi and I, with the help of others, have been getting the functional tests in nova working with an external placement. It is working now, which is great, but much work was done, more details within. # Most Important Progress continues on the work in ansible, puppet/tripleo, kolla, loci to package placement up and establish upgrade processes. All of these things need review (see below). Work on GPU reshaping in virt drivers is getting close. # What's Changed * Devstack installs placement from openstack/placement, not nova. * Placement now runs tempest and grenade (in py3) in CI. This is great because real integration tests and sad because our once really fast CI runs are gone. * The placement service can now start without a conf file. This is basically fixing a bug: we required a single config file in a specific location, rather than the defaults (which includes no file). We require an explicit database connection. # Bugs * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 19. +2. * [In progress placement bugs](https://goo.gl/vzGGDQ) 14. +1 # Specs Spec freeze is milestone 2, the week of January 7th. None of the specs listed last week have merged. * Account for host agg allocation ratio in placement (Still in rocky/) * Add subtree filter for GET /resource_providers * Resource provider - request group mapping in allocation candidate * VMware: place instances on resource pool (still in rocky/) * Standardize CPU resource tracking * Allow overcommit of dedicated CPU (Has an alternative which changes allocations to a float) * Modelling passthrough devices for report to placement * Nova Cyborg interaction specification. * supporting virtual NVDIMM devices * Spec: Support filtering by forbidden aggregate * Proposes NUMA topology with RPs * Count quota based on resource class * Adds spec for instance live resize * Provider config YAML file * Propose counting quota usage from placement and API database * Resource modeling in cyborg. * Support filtering of allocation_candidates by forbidden aggregates # Main Themes ## Making Nested Useful Progress is being made on gpu-reshaping for libvirt and xen: * Also making use of nested is bandwidth-resource-provider: * Eric's in the process of doing lots of cleanups to how often the ProviderTree in the resource tracker is checked against placement, and a variety of other "let's make this more right" changes in the same neighborhood: * Stack at: ## Extraction (There's an [etherpad](https://etherpad.openstack.org/p/placement-extract-stein-4) which tracks some of the work related to extraction. Please refer to that for additional information.) Several deployment tools are working on making things work with the extracted placement: * [TripleO](https://review.openstack.org/#/q/topic:tripleo-placement-extraction) * [OpenStack Ansible](https://review.openstack.org/#/q/project:openstack/openstack-ansible-os_placement) * [Kolla](https://review.openstack.org/#/c/613589/) * [Kolla Ansible](https://review.openstack.org/#/c/613629/) * [Loci](https://review.openstack.org/#/c/617273/) A replacement for `placeload` performance testing that was in the `nova-next` job: . This might be of interest to people trying to do testing of live services without devstack. It starts with a basic node, turns on mysql, runs placement with uwsgi, and does the placeload testing. Note that this found a pretty strange [bug in _ensure_aggregates](https://bugs.launchpad.net/nova/+bug/1804453). Documentation tuneups: * Release-notes: This is blocked until we refactor the release notes to reflect _now_ better. * The main remaining task here is participating in [openstack-manuals](https://docs.openstack.org/doc-contrib-guide/doc-index.html). **The functional tests in nova** excitement this week has led to some interesting changes. The biggest of these is changing placement to [no longer use global config](https://review.openstack.org/#/c/619121/). That patch is an aggregate of the many things done to remove a race condition in the [nova functional tests](https://review.openstack.org/#/c/617941/). Trying to use the config of two different projects in the same process space is hard if they are both global. So now placement doesn't. This is a win in many ways. Getting those two patches merged _soon_ is important. We've been putting off making a decision about os-resource-classes. Anyone have strong opinions? # Other There are 12 or so [open changes](https://review.openstack.org/#/q/status:open+project:openstack/placement) in placement itself. Of those these two are the most important: * Stop using global oslo_config * Correct lower-constraints.txt and the related tox job Outside of placement itself, here are some related changes: * Improve handling of default allocation ratios * Neutron minimum bandwidth implementation * Add OWNERSHIP $SERVICE traits * zun: Use placement for unified resource management * Blazar using the placement-api * Tenks doing some node management, with a bit of optional placement. * Sync placement database to the current version (in grenade) * Address nits on lib/placement for extracted placement (in devstack) # End That was the November that was. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From bdobreli at redhat.com Fri Nov 30 13:31:13 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Fri, 30 Nov 2018 14:31:13 +0100 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <7d2fce52ca8bb5156b753a95cbb9e2df7ad741c8.camel@redhat.com> References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> <7d2fce52ca8bb5156b753a95cbb9e2df7ad741c8.camel@redhat.com> Message-ID: On 11/30/18 1:52 PM, Dan Prince wrote: > On Fri, 2018-11-30 at 10:31 +0100, Bogdan Dobrelya wrote: >> On 11/29/18 6:42 PM, Jiří Stránský wrote: >>> On 28. 11. 18 18:29, Bogdan Dobrelya wrote: >>>> On 11/28/18 6:02 PM, Jiří Stránský wrote: >>>>> >>>>> >>>>>> Reiterating again on previous points: >>>>>> >>>>>> -I'd be fine removing systemd. But lets do it properly and >>>>>> not via 'rpm >>>>>> -ev --nodeps'. >>>>>> -Puppet and Ruby *are* required for configuration. We can >>>>>> certainly put >>>>>> them in a separate container outside of the runtime service >>>>>> containers >>>>>> but doing so would actually cost you much more >>>>>> space/bandwidth for each >>>>>> service container. As both of these have to get downloaded to >>>>>> each node >>>>>> anyway in order to generate config files with our current >>>>>> mechanisms >>>>>> I'm not sure this buys you anything. >>>>> >>>>> +1. I was actually under the impression that we concluded >>>>> yesterday on >>>>> IRC that this is the only thing that makes sense to seriously >>>>> consider. >>>>> But even then it's not a win-win -- we'd gain some security by >>>>> leaner >>>>> production images, but pay for it with space+bandwidth by >>>>> duplicating >>>>> image content (IOW we can help achieve one of the goals we had >>>>> in mind >>>>> by worsening the situation w/r/t the other goal we had in >>>>> mind.) >>>>> >>>>> Personally i'm not sold yet but it's something that i'd >>>>> consider if we >>>>> got measurements of how much more space/bandwidth usage this >>>>> would >>>>> consume, and if we got some further details/examples about how >>>>> serious >>>>> are the security concerns if we leave config mgmt tools in >>>>> runtime >>>>> images. >>>>> >>>>> IIRC the other options (that were brought forward so far) were >>>>> already >>>>> dismissed in yesterday's IRC discussion and on the reviews. >>>>> Bin/lib bind >>>>> mounting being too hacky and fragile, and nsenter not really >>>>> solving the >>>>> problem (because it allows us to switch to having different >>>>> bins/libs >>>>> available, but it does not allow merging the availability of >>>>> bins/libs >>>>> from two containers into a single context). >>>>> >>>>>> We are going in circles here I think.... >>>>> >>>>> +1. I think too much of the discussion focuses on "why it's bad >>>>> to have >>>>> config tools in runtime images", but IMO we all sorta agree >>>>> that it >>>>> would be better not to have them there, if it came at no cost. >>>>> >>>>> I think to move forward, it would be interesting to know: if we >>>>> do this >>>>> (i'll borrow Dan's drawing): >>>>> >>>>>> base container| --> |service container| --> |service >>>>>> container w/ >>>>> Puppet installed| >>>>> >>>>> How much more space and bandwidth would this consume per node >>>>> (e.g. >>>>> separately per controller, per compute). This could help with >>>>> decision >>>>> making. >>>> >>>> As I've already evaluated in the related bug, that is: >>>> >>>> puppet-* modules and manifests ~ 16MB >>>> puppet with dependencies ~61MB >>>> dependencies of the seemingly largest a dependency, systemd >>>> ~190MB >>>> >>>> that would be an extra layer size for each of the container >>>> images to be >>>> downloaded/fetched into registries. >>> >>> Thanks, i tried to do the math of the reduction vs. inflation in >>> sizes >>> as follows. I think the crucial point here is the layering. If we >>> do >>> this image layering: >>> >>>> base| --> |+ service| --> |+ Puppet| >>> >>> we'd drop ~267 MB from base image, but we'd be installing that to >>> the >>> topmost level, per-component, right? >> >> Given we detached systemd from puppet, cronie et al, that would be >> 267-190MB, so the math below would be looking much better > > Would it be worth writing a spec that summarizes what action items are > bing taken to optimize our base image with regards to the systemd? Perhaps it would be. But honestly, I see nothing biggie to require a full blown spec. Just changing RPM deps and layers for containers images. I'm tracking systemd changes here [0],[1],[2], btw (if accepted, it should be working as of fedora28(or 29) I hope) [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction [1] https://bugzilla.redhat.com/show_bug.cgi?id=1654659 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1654672 > > It seems like the general consenses is that cleaning up some of the RPM > dependencies so that we don't install Systemd is the biggest win. > > What confuses me is why are there still patches posted to move Puppet > out of the base layer when we agree moving it out of the base layer > would actually cause our resulting container image set to be larger in > size. > > Dan > > >> >>> In my basic deployment, undercloud seems to have 17 "components" >>> (49 >>> containers), overcloud controller 15 components (48 containers), >>> and >>> overcloud compute 4 components (7 containers). Accounting for >>> overlaps, >>> the total number of "components" used seems to be 19. (By >>> "components" >>> here i mean whatever uses a different ConfigImage than other >>> services. I >>> just eyeballed it but i think i'm not too far off the correct >>> number.) >>> >>> So we'd subtract 267 MB from base image and add that to 19 leaf >>> images >>> used in this deployment. That means difference of +4.8 GB to the >>> current >>> image sizes. My /var/lib/registry dir on undercloud with all the >>> images >>> currently has 5.1 GB. We'd almost double that to 9.9 GB. >>> >>> Going from 5.1 to 9.9 GB seems like a lot of extra traffic for the >>> CDNs >>> (both external and e.g. internal within OpenStack Infra CI clouds). >>> >>> And for internal traffic between local registry and overcloud >>> nodes, it >>> gives +3.7 GB per controller and +800 MB per compute. That may not >>> be so >>> critical but still feels like a considerable downside. >>> >>> Another gut feeling is that this way of image layering would take >>> longer >>> time to build and to run the modify-image Ansible role which we use >>> in >>> CI, so that could endanger how our CI jobs fit into the time limit. >>> We >>> could also probably measure this but i'm not sure if it's worth >>> spending >>> the time. >>> >>> All in all i'd argue we should be looking at different options >>> still. >>> >>>> Given that we should decouple systemd from all/some of the >>>> dependencies >>>> (an example topic for RDO [0]), that could save a 190MB. But it >>>> seems we >>>> cannot break the love of puppet and systemd as it heavily relies >>>> on the >>>> latter and changing packaging like that would higly likely affect >>>> baremetal deployments with puppet and systemd co-operating. >>> >>> Ack :/ >>> >>>> Long story short, we cannot shoot both rabbits with a single >>>> shot, not >>>> with puppet :) May be we could with ansible replacing puppet >>>> fully... >>>> So splitting config and runtime images is the only choice yet to >>>> address >>>> the raised security concerns. And let's forget about edge cases >>>> for now. >>>> Tossing around a pair of extra bytes over 40,000 WAN-distributed >>>> computes ain't gonna be our the biggest problem for sure. >>>> >>>> [0] >>>> https://review.rdoproject.org/r/#/q/topic:base-container-reduction >>>> >>>>>> Dan >>>>>> >>>>> >>>>> Thanks >>>>> >>>>> Jirka >>>>> >>>>> _______________________________________________________________ >>>>> ___________ >>>>> >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> ___________________________________________________________________ >>> _______ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsu >>> bscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > -- Best regards, Bogdan Dobrelya, Irc #bogdando From ervikrant06 at gmail.com Fri Nov 30 03:43:30 2018 From: ervikrant06 at gmail.com (Vikrant Aggarwal) Date: Fri, 30 Nov 2018 09:13:30 +0530 Subject: [openstack-dev] [magnum] [Rocky] K8 deployment on fedora-atomic is failed In-Reply-To: References: Message-ID: Hi Feilong, Thanks for your reply. Kindly find the below outputs. [root at packstack1 ~]# rpm -qa | grep -i magnum python-magnum-7.0.1-1.el7.noarch openstack-magnum-conductor-7.0.1-1.el7.noarch openstack-magnum-ui-5.0.1-1.el7.noarch openstack-magnum-api-7.0.1-1.el7.noarch puppet-magnum-13.3.1-1.el7.noarch python2-magnumclient-2.10.0-1.el7.noarch openstack-magnum-common-7.0.1-1.el7.noarch [root at packstack1 ~]# rpm -qa | grep -i heat openstack-heat-ui-1.4.0-1.el7.noarch openstack-heat-api-cfn-11.0.0-1.el7.noarch openstack-heat-engine-11.0.0-1.el7.noarch puppet-heat-13.3.1-1.el7.noarch python2-heatclient-1.16.1-1.el7.noarch openstack-heat-api-11.0.0-1.el7.noarch openstack-heat-common-11.0.0-1.el7.noarch Thanks & Regards, Vikrant Aggarwal On Fri, Nov 30, 2018 at 2:44 AM Feilong Wang wrote: > Hi Vikrant, > > Before we dig more, it would be nice if you can let us know the version of > your Magnum and Heat. Cheers. > > > On 30/11/18 12:12 AM, Vikrant Aggarwal wrote: > > Hello Team, > > Trying to deploy on K8 on fedora atomic. > > Here is the output of cluster template: > ~~~ > [root at packstack1 k8s_fedora_atomic_v1(keystone_admin)]# magnum > cluster-template-show 16eb91f7-18fe-4ce3-98db-c732603f2e57 > WARNING: The magnum client is deprecated and will be removed in a future > release. > Use the OpenStack client to avoid seeing this message. > +-----------------------+--------------------------------------+ > | Property | Value | > +-----------------------+--------------------------------------+ > | insecure_registry | - | > | labels | {} | > | updated_at | - | > | floating_ip_enabled | True | > | fixed_subnet | - | > | master_flavor_id | - | > | user_id | 203617849df9490084dde1897b28eb53 | > | uuid | 16eb91f7-18fe-4ce3-98db-c732603f2e57 | > | no_proxy | - | > | https_proxy | - | > | tls_disabled | False | > | keypair_id | kubernetes | > | project_id | 45a6706c831c42d5bf2da928573382b1 | > | public | False | > | http_proxy | - | > | docker_volume_size | 10 | > | server_type | vm | > | external_network_id | external1 | > | cluster_distro | fedora-atomic | > | image_id | f5954340-f042-4de3-819e-a3b359591770 | > | volume_driver | - | > | registry_enabled | False | > | docker_storage_driver | devicemapper | > | apiserver_port | - | > | name | coe-k8s-template | > | created_at | 2018-11-28T12:58:21+00:00 | > | network_driver | flannel | > | fixed_network | - | > | coe | kubernetes | > | flavor_id | m1.small | > | master_lb_enabled | False | > | dns_nameserver | 8.8.8.8 | > +-----------------------+--------------------------------------+ > ~~~ > Found couple of issues in the logs of VM started by magnum. > > - etcd was not getting started because of incorrect permission on file > "/etc/etcd/certs/server.key". This file is owned by root by default have > 0440 as permission. Changed the permission to 0444 so that etcd can read > the file. After that etcd started successfully. > > - etcd DB doesn't contain anything: > > [root at kube-cluster1-qobaagdob75g-master-0 ~]# etcdctl ls / -r > [root at kube-cluster1-qobaagdob75g-master-0 ~]# > > - Flanneld is stuck in activating status. > ~~~ > [root at kube-cluster1-qobaagdob75g-master-0 ~]# systemctl status flanneld > ● flanneld.service - Flanneld overlay address etcd agent > Loaded: loaded (/usr/lib/systemd/system/flanneld.service; enabled; > vendor preset: disabled) > Active: activating (start) since Thu 2018-11-29 11:05:39 UTC; 14s ago > Main PID: 6491 (flanneld) > Tasks: 6 (limit: 4915) > Memory: 4.7M > CPU: 53ms > CGroup: /system.slice/flanneld.service > └─6491 /usr/bin/flanneld -etcd-endpoints=http://127.0.0.1:2379 > -etcd-prefix=/atomic.io/network > > Nov 29 11:05:44 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:44.569376 6491 network.go:102] failed to > retrieve network config: 100: Key not found (/atomic.io) [3] > Nov 29 11:05:45 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:45.584532 6491 network.go:102] failed to > retrieve network config: 100: Key not found (/atomic.io) [3] > Nov 29 11:05:46 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:46.646255 6491 network.go:102] failed to > retrieve network config: 100: Key not found (/atomic.io) [3] > Nov 29 11:05:47 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:47.673062 6491 network.go:102] failed to > retrieve network config: 100: Key not found (/atomic.io) [3] > Nov 29 11:05:48 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:48.686919 6491 network.go:102] failed to > retrieve network config: 100: Key not found (/atomic.io) [3] > Nov 29 11:05:49 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:49.709136 6491 network.go:102] failed to > retrieve network config: 100: Key not found (/atomic.io) [3] > Nov 29 11:05:50 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:50.729548 6491 network.go:102] failed to > retrieve network config: 100: Key not found (/atomic.io) [3] > Nov 29 11:05:51 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:51.749425 6491 network.go:102] failed to > retrieve network config: 100: Key not found (/atomic.io) [3] > Nov 29 11:05:52 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:52.776612 6491 network.go:102] failed to > retrieve network config: 100: Key not found (/atomic.io) [3] > Nov 29 11:05:53 kube-cluster1-qobaagdob75g-master-0.novalocal > flanneld[6491]: E1129 11:05:53.790418 6491 network.go:102] failed to > retrieve network config: 100: Key not found (/atomic.io) [3] > ~~~ > > - Continuously in the jouralctl logs following messages are printed. > > ~~~ > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal > kube-apiserver[6888]: F1129 11:06:39.338416 6888 server.go:269] Invalid > Authorization Config: Unknown authorization mode Node specified > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: > kube-apiserver.service: Main process exited, code=exited, status=255/n/a > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal > kube-scheduler[2540]: E1129 11:06:39.408272 2540 reflector.go:199] > k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:463: Failed to > list *api.Node: Get http://127.0.0.1:8080/api/v1/nodes?resourceVersion=0: > dial tcp 127.0.0.1:8080: getsockopt: connection refused > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal > kube-scheduler[2540]: E1129 11:06:39.444737 2540 reflector.go:199] > k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:460: Failed to > list *api.Pod: Get > http://127.0.0.1:8080/api/v1/pods?fieldSelector=spec.nodeName%21%3D%2Cstatus.phase%21%3DFailed%2Cstatus.phase%21%3DSucceeded&resourceVersion=0: > dial tcp 127.0.0.1:8080: getsockopt: connection refused > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal > kube-scheduler[2540]: E1129 11:06:39.445793 2540 reflector.go:199] > k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:466: Failed to > list *api.PersistentVolume: Get > http://127.0.0.1:8080/api/v1/persistentvolumes?resourceVersion=0: dial > tcp 127.0.0.1:8080: getsockopt: connection refused > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal audit[1]: > SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 > subj=system_u:system_r:init_t:s0 msg='unit=kube-apiserver comm="systemd" > exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: > Failed to start Kubernetes API Server. > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: > kube-apiserver.service: Unit entered failed state. > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: > kube-apiserver.service: Failed with result 'exit-code'. > Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal > kube-scheduler[2540]: E1129 11:06:39.611699 2540 reflector.go:199] > k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:481: Failed to > list *extensions.ReplicaSet: Get > http://127.0.0.1:8080/apis/extensions/v1beta1/replicasets?resourceVersion=0: > dial tcp 127.0.0.1:8080: getsockopt: connection refused > ~~~ > > Any help on above issue is highly appreciated. > > Thanks & Regards, > Vikrant Aggarwal > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- > Cheers & Best regards, > Feilong Wang (王飞龙) > -------------------------------------------------------------------------- > Senior Cloud Software Engineer > Tel: +64-48032246 > Email: flwang at catalyst.net.nz > Catalyst IT Limited > Level 6, Catalyst House, 150 Willis Street, Wellington > -------------------------------------------------------------------------- > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From ervikrant06 at gmail.com Fri Nov 30 04:04:43 2018 From: ervikrant06 at gmail.com (Vikrant Aggarwal) Date: Fri, 30 Nov 2018 09:34:43 +0530 Subject: [openstack-dev] [kuryr] kuryr libnetwork installation inside the vm is failing Message-ID: Started one Fedora 29 VM on openstack using official qcow2 image. I followed this doc for kuryr installation inside the VM. https://docs.openstack.org/kuryr-libnetwork/latest/readme.html My objective is to run the nested docker i.e inside the VM. While installing the kuryr-libbetwork from the source. it's getting failed with following error: ~~~ [root at vm0 kuryr-libnetwork]# pip install . WARNING: Running pip install with root privileges is generally not a good idea. Try `pip install --user` instead. Processing /root/kuryr-libnetwork Requirement already satisfied: Babel!=2.4.0,>=2.3.4 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (2.6.0) Requirement already satisfied: Flask!=0.11,>=0.10 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (1.0.2) Requirement already satisfied: ipaddress>=1.0.17 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (1.0.22) Requirement already satisfied: jsonschema<3.0.0,>=2.6.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (2.6.0) Collecting kuryr-lib>=0.5.0 (from kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/19/f0/8a425cb4a34ce641e32c5bba3cddc19abf1cd7034537ec7acb9c96ec305d/kuryr_lib-0.8.0-py2.py3-none-any.whl Requirement already satisfied: neutron-lib>=1.13.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (1.20.0) Collecting os-client-config>=1.28.0 (from kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/e5/af/2f3bf859a25c98993f85ff1eb17762aa49b2f894630ebe99c389545b0502/os_client_config-1.31.2-py2.py3-none-any.whl Requirement already satisfied: oslo.concurrency>=3.25.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (3.29.0) Requirement already satisfied: oslo.config>=5.2.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (6.7.0) Requirement already satisfied: oslo.log>=3.36.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (3.41.0) Requirement already satisfied: oslo.utils>=3.33.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (3.37.1) Requirement already satisfied: pbr!=2.1.0,>=2.0.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (5.1.1) Collecting python-neutronclient>=6.7.0 (from kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/cd/40/2fee7f7f2b562f987c59dfa499ed084af44b57e3c7e342ed2fa5b41d73aa/python_neutronclient-6.11.0-py2.py3-none-any.whl Requirement already satisfied: six>=1.10.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (1.11.0) Requirement already satisfied: pytz>=0a in /usr/lib/python2.7/site-packages (from Babel!=2.4.0,>=2.3.4->kuryr-libnetwork==2.0.1.dev20) (2018.7) Requirement already satisfied: Werkzeug>=0.14 in /usr/lib/python2.7/site-packages (from Flask!=0.11,>=0.10->kuryr-libnetwork==2.0.1.dev20) (0.14.1) Requirement already satisfied: click>=5.1 in /usr/lib64/python2.7/site-packages (from Flask!=0.11,>=0.10->kuryr-libnetwork==2.0.1.dev20) (7.0) Requirement already satisfied: itsdangerous>=0.24 in /usr/lib/python2.7/site-packages (from Flask!=0.11,>=0.10->kuryr-libnetwork==2.0.1.dev20) (1.1.0) Requirement already satisfied: Jinja2>=2.10 in /usr/lib/python2.7/site-packages (from Flask!=0.11,>=0.10->kuryr-libnetwork==2.0.1.dev20) (2.10) Requirement already satisfied: functools32; python_version == "2.7" in /usr/lib/python2.7/site-packages (from jsonschema<3.0.0,>=2.6.0->kuryr-libnetwork==2.0.1.dev20) (3.2.3.post2) Requirement already satisfied: keystoneauth1>=3.4.0 in /usr/lib/python2.7/site-packages (from kuryr-lib>=0.5.0->kuryr-libnetwork==2.0.1.dev20) (3.11.1) Requirement already satisfied: oslo.i18n>=3.15.3 in /usr/lib/python2.7/site-packages (from kuryr-lib>=0.5.0->kuryr-libnetwork==2.0.1.dev20) (3.23.0) Requirement already satisfied: pyroute2>=0.4.21; sys_platform != "win32" in /usr/lib/python2.7/site-packages (from kuryr-lib>=0.5.0->kuryr-libnetwork==2.0.1.dev20) (0.5.3) Requirement already satisfied: SQLAlchemy!=1.1.5,!=1.1.6,!=1.1.7,!=1.1.8,>=1.0.10 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.2.14) Requirement already satisfied: osprofiler>=1.4.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.5.1) Requirement already satisfied: oslo.versionedobjects>=1.31.2 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.34.1) Requirement already satisfied: oslo.context>=2.19.2 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.21.0) Requirement already satisfied: oslo.policy>=1.30.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.41.1) Requirement already satisfied: oslo.db>=4.27.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (4.42.0) Requirement already satisfied: os-traits>=0.9.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.10.0) Requirement already satisfied: oslo.serialization!=2.19.1,>=2.18.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.28.1) Requirement already satisfied: oslo.service!=1.28.1,>=1.24.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.33.0) Requirement already satisfied: WebOb>=1.7.1 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.8.4) Requirement already satisfied: oslo.messaging>=5.29.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (9.2.1) Requirement already satisfied: stevedore>=1.20.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.30.0) Requirement already satisfied: weakrefmethod>=1.0.2; python_version == "2.7" in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.0.3) Requirement already satisfied: pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.3.2) Collecting openstacksdk>=0.13.0 (from os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/05/e1/38b3fe8b3fa8b78c8917bc78e2aa3f1a13312bc810ee83d5d8f285514245/openstacksdk-0.19.0-py2.py3-none-any.whl Requirement already satisfied: enum34>=1.0.4; python_version == "2.7" or python_version == "2.6" or python_version == "3.3" in /usr/lib/python2.7/site-packages (from oslo.concurrency>=3.25.0->kuryr-libnetwork==2.0.1.dev20) (1.1.6) Requirement already satisfied: fasteners>=0.7.0 in /usr/lib/python2.7/site-packages (from oslo.concurrency>=3.25.0->kuryr-libnetwork==2.0.1.dev20) (0.14.1) Requirement already satisfied: rfc3986>=0.3.1 in /usr/lib/python2.7/site-packages (from oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (1.1.0) Requirement already satisfied: netaddr>=0.7.18 in /usr/lib/python2.7/site-packages (from oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (0.7.19) Requirement already satisfied: PyYAML>=3.12 in /usr/lib64/python2.7/site-packages (from oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (3.13) Requirement already satisfied: requests>=2.18.0 in /usr/lib/python2.7/site-packages (from oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (2.20.1) Requirement already satisfied: debtcollector>=1.2.0 in /usr/lib/python2.7/site-packages (from oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (1.20.0) Requirement already satisfied: monotonic>=1.4 in /usr/lib/python2.7/site-packages (from oslo.log>=3.36.0->kuryr-libnetwork==2.0.1.dev20) (1.5) Requirement already satisfied: python-dateutil>=2.7.0 in /usr/lib/python2.7/site-packages (from oslo.log>=3.36.0->kuryr-libnetwork==2.0.1.dev20) (2.7.5) Requirement already satisfied: pyinotify>=0.9.6; sys_platform != "win32" and sys_platform != "darwin" and sys_platform != "sunos5" in /usr/lib/python2.7/site-packages (from oslo.log>=3.36.0->kuryr-libnetwork==2.0.1.dev20) (0.9.6) Requirement already satisfied: netifaces>=0.10.4 in /usr/lib64/python2.7/site-packages (from oslo.utils>=3.33.0->kuryr-libnetwork==2.0.1.dev20) (0.10.7) Requirement already satisfied: pyparsing>=2.1.0 in /usr/lib/python2.7/site-packages (from oslo.utils>=3.33.0->kuryr-libnetwork==2.0.1.dev20) (2.3.0) Requirement already satisfied: funcsigs>=1.0.0; python_version == "2.7" or python_version == "2.6" in /usr/lib/python2.7/site-packages (from oslo.utils>=3.33.0->kuryr-libnetwork==2.0.1.dev20) (1.0.2) Requirement already satisfied: iso8601>=0.1.11 in /usr/lib/python2.7/site-packages (from oslo.utils>=3.33.0->kuryr-libnetwork==2.0.1.dev20) (0.1.12) Collecting osc-lib>=1.8.0 (from python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/8d/a8/b63a53baed828a3e46ff2d1ee5cb63f794e9e071f05e99229642edfc46a5/osc-lib-1.11.1.tar.gz Collecting python-keystoneclient>=3.8.0 (from python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/51/48/c25bb60d7b95294cc5e49a406ae0b9e10f3e0ff533d0df149501abf70300/python_keystoneclient-3.18.0-py2.py3-none-any.whl Collecting cliff!=2.9.0,>=2.8.0 (from python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/8e/1a/5404afee3d83a2e5f27e0d20ac7012c9f07bd8e9b03d0ae1fd9bb3e63037/cliff-2.14.0-py2.py3-none-any.whl Collecting simplejson>=3.5.1 (from python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/e3/24/c35fb1c1c315fc0fffe61ea00d3f88e85469004713dab488dee4f35b0aff/simplejson-3.16.0.tar.gz Requirement already satisfied: MarkupSafe>=0.23 in /usr/lib64/python2.7/site-packages (from Jinja2>=2.10->Flask!=0.11,>=0.10->kuryr-libnetwork==2.0.1.dev20) (1.1.0) Requirement already satisfied: os-service-types>=1.2.0 in /usr/lib/python2.7/site-packages (from keystoneauth1>=3.4.0->kuryr-lib>=0.5.0->kuryr-libnetwork==2.0.1.dev20) (1.3.0) Requirement already satisfied: PrettyTable<0.8,>=0.7.2 in /usr/lib/python2.7/site-packages (from osprofiler>=1.4.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.7.2) Requirement already satisfied: testscenarios>=0.4 in /usr/lib/python2.7/site-packages (from oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.5.0) Requirement already satisfied: alembic>=0.9.6 in /usr/lib/python2.7/site-packages (from oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.0.5) Requirement already satisfied: testresources>=2.0.0 in /usr/lib/python2.7/site-packages (from oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.0.1) Requirement already satisfied: sqlalchemy-migrate>=0.11.0 in /usr/lib/python2.7/site-packages (from oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.11.0) Requirement already satisfied: msgpack>=0.5.2 in /usr/lib64/python2.7/site-packages (from oslo.serialization!=2.19.1,>=2.18.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.5.6) Requirement already satisfied: Paste>=2.0.2 in /usr/lib/python2.7/site-packages (from oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (3.0.4) Requirement already satisfied: PasteDeploy>=1.5.0 in /usr/lib/python2.7/site-packages (from oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.5.2) Requirement already satisfied: greenlet>=0.4.10 in /usr/lib64/python2.7/site-packages (from oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.4.15) Requirement already satisfied: Routes>=2.3.1 in /usr/lib/python2.7/site-packages (from oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.4.1) Requirement already satisfied: fixtures>=3.0.0 in /usr/lib/python2.7/site-packages (from oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (3.0.0) Requirement already satisfied: eventlet!=0.18.3,!=0.20.1,>=0.18.2 in /usr/lib/python2.7/site-packages (from oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.24.1) Requirement already satisfied: kombu!=4.0.2,>=4.0.0 in /usr/lib/python2.7/site-packages (from oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (4.2.1) Requirement already satisfied: oslo.middleware>=3.31.0 in /usr/lib/python2.7/site-packages (from oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (3.36.0) Requirement already satisfied: cachetools>=2.0.0 in /usr/lib/python2.7/site-packages (from oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (3.0.0) Requirement already satisfied: futurist>=1.2.0 in /usr/lib/python2.7/site-packages (from oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.8.0) Requirement already satisfied: amqp>=2.3.0 in /usr/lib/python2.7/site-packages (from oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.3.2) Requirement already satisfied: logutils>=0.3 in /usr/lib/python2.7/site-packages (from pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.3.5) Requirement already satisfied: singledispatch in /usr/lib/python2.7/site-packages (from pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (3.4.0.3) Requirement already satisfied: Mako>=0.4.0 in /usr/lib/python2.7/site-packages (from pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.0.7) Requirement already satisfied: WebTest>=1.3.1 in /usr/lib/python2.7/site-packages (from pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.0.32) Collecting dogpile.cache>=0.6.2 (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/73/bf/0cbed594e4f0f9360bfb98e7276131bf32e1af1d15e6c11a9dd8bd93a12f/dogpile.cache-0.6.8.tar.gz Requirement already satisfied: decorator>=3.4.0 in /usr/lib/python2.7/site-packages (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) (4.3.0) Requirement already satisfied: futures>=3.0.0; python_version == "2.7" or python_version == "2.6" in /usr/lib/python2.7/site-packages (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) (3.2.0) Collecting requestsexceptions>=1.2.0 (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/01/8c/49ca60ea8c907260da4662582c434bec98716177674e88df3fd340acf06d/requestsexceptions-1.4.0-py2.py3-none-any.whl Collecting cryptography>=2.1 (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/7f/ba/383b51cc26e3141c689ce988814385c7659f5ba01c4b5f2de38233010b5f/cryptography-2.4.2-cp27-cp27mu-manylinux1_x86_64.whl Collecting munch>=2.1.0 (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/68/f4/260ec98ea840757a0da09e0ed8135333d59b8dfebe9752a365b04857660a/munch-2.3.2.tar.gz Collecting appdirs>=1.3.0 (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/56/eb/810e700ed1349edde4cbdc1b2a21e28cdf115f9faf263f6bbf8447c1abf3/appdirs-1.4.3-py2.py3-none-any.whl Collecting jsonpatch!=1.20,>=1.16 (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/a0/e6/d50d526ae2218b765ddbdb2dda14d65e19f501ce07410b375bc43ad20b7a/jsonpatch-1.23-py2.py3-none-any.whl Collecting jmespath>=0.9.0 (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/b7/31/05c8d001f7f87f0f07289a5fc0fc3832e9a57f2dbd4d3b0fee70e0d51365/jmespath-0.9.3-py2.py3-none-any.whl Requirement already satisfied: idna<2.8,>=2.5 in /usr/lib/python2.7/site-packages (from requests>=2.18.0->oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (2.7) Requirement already satisfied: chardet<3.1.0,>=3.0.2 in /usr/lib/python2.7/site-packages (from requests>=2.18.0->oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (3.0.4) Requirement already satisfied: urllib3<1.25,>=1.21.1 in /usr/lib/python2.7/site-packages (from requests>=2.18.0->oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (1.24.1) Requirement already satisfied: certifi>=2017.4.17 in /usr/lib/python2.7/site-packages (from requests>=2.18.0->oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (2018.10.15) Requirement already satisfied: wrapt>=1.7.0 in /usr/lib/python2.7/site-packages (from debtcollector>=1.2.0->oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (1.10.11) Collecting cmd2!=0.8.3,<0.9.0; python_version < "3.0" (from cliff!=2.9.0,>=2.8.0->python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/e9/40/a71caa2aaff10c73612a7106e2d35f693e85b8cf6e37ab0774274bca3cf9/cmd2-0.8.9-py2.py3-none-any.whl Collecting unicodecsv>=0.8.0; python_version < "3.0" (from cliff!=2.9.0,>=2.8.0->python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/6f/a4/691ab63b17505a26096608cc309960b5a6bdf39e4ba1a793d5f9b1a53270/unicodecsv-0.14.1.tar.gz Requirement already satisfied: testtools in /usr/lib/python2.7/site-packages (from testscenarios>=0.4->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.3.0) Requirement already satisfied: python-editor>=0.3 in /usr/lib/python2.7/site-packages (from alembic>=0.9.6->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.0.3) Requirement already satisfied: sqlparse in /usr/lib/python2.7/site-packages (from sqlalchemy-migrate>=0.11.0->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.2.4) Requirement already satisfied: Tempita>=0.4 in /usr/lib/python2.7/site-packages (from sqlalchemy-migrate>=0.11.0->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.5.2) Requirement already satisfied: repoze.lru>=0.3 in /usr/lib/python2.7/site-packages (from Routes>=2.3.1->oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.7) Requirement already satisfied: dnspython>=1.15.0 in /usr/lib/python2.7/site-packages (from eventlet!=0.18.3,!=0.20.1,>=0.18.2->oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.15.0) Requirement already satisfied: statsd>=3.2.1 in /usr/lib/python2.7/site-packages (from oslo.middleware>=3.31.0->oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (3.3.0) Requirement already satisfied: contextlib2>=0.4.0; python_version < "3.0" in /usr/lib/python2.7/site-packages (from futurist>=1.2.0->oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.5.5) Requirement already satisfied: vine>=1.1.3 in /usr/lib/python2.7/site-packages (from amqp>=2.3.0->oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.1.4) Requirement already satisfied: beautifulsoup4 in /usr/lib/python2.7/site-packages (from WebTest>=1.3.1->pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (4.6.3) Requirement already satisfied: waitress>=0.8.5 in /usr/lib/python2.7/site-packages (from WebTest>=1.3.1->pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.1.0) Collecting cffi!=1.11.3,>=1.7 (from cryptography>=2.1->openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/14/dd/3e7a1e1280e7d767bd3fa15791759c91ec19058ebe31217fe66f3e9a8c49/cffi-1.11.5-cp27-cp27mu-manylinux1_x86_64.whl Collecting asn1crypto>=0.21.0 (from cryptography>=2.1->openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/ea/cd/35485615f45f30a510576f1a56d1e0a7ad7bd8ab5ed7cdc600ef7cd06222/asn1crypto-0.24.0-py2.py3-none-any.whl Collecting jsonpointer>=1.9 (from jsonpatch!=1.20,>=1.16->openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/18/b0/a80d29577c08eea401659254dfaed87f1af45272899e1812d7e01b679bc5/jsonpointer-2.0-py2.py3-none-any.whl Requirement already satisfied: pyperclip in /usr/lib/python2.7/site-packages (from cmd2!=0.8.3,<0.9.0; python_version < "3.0"->cliff!=2.9.0,>=2.8.0->python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) (1.7.0) Requirement already satisfied: wcwidth; sys_platform != "win32" in /usr/lib/python2.7/site-packages (from cmd2!=0.8.3,<0.9.0; python_version < "3.0"->cliff!=2.9.0,>=2.8.0->python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) (0.1.7) Collecting subprocess32; python_version < "3.0" (from cmd2!=0.8.3,<0.9.0; python_version < "3.0"->cliff!=2.9.0,>=2.8.0->python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/be/2b/beeba583e9877e64db10b52a96915afc0feabf7144dcbf2a0d0ea68bf73d/subprocess32-3.5.3.tar.gz Requirement already satisfied: extras>=1.0.0 in /usr/lib/python2.7/site-packages (from testtools->testscenarios>=0.4->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.0.0) Requirement already satisfied: unittest2>=1.0.0 in /usr/lib/python2.7/site-packages (from testtools->testscenarios>=0.4->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.1.0) Requirement already satisfied: traceback2 in /usr/lib/python2.7/site-packages (from testtools->testscenarios>=0.4->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.4.0) Requirement already satisfied: python-mimeparse in /usr/lib/python2.7/site-packages (from testtools->testscenarios>=0.4->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.6.0) Collecting pycparser (from cffi!=1.11.3,>=1.7->cryptography>=2.1->openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/68/9e/49196946aee219aead1290e00d1e7fdeab8567783e83e1b9ab5585e6206a/pycparser-2.19.tar.gz Requirement already satisfied: argparse in /usr/lib/python2.7/site-packages (from unittest2>=1.0.0->testtools->testscenarios>=0.4->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.4.0) Requirement already satisfied: linecache2 in /usr/lib/python2.7/site-packages (from traceback2->testtools->testscenarios>=0.4->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.0.0) Installing collected packages: subprocess32, cmd2, unicodecsv, cliff, dogpile.cache, requestsexceptions, pycparser, cffi, asn1crypto, cryptography, munch, appdirs, jsonpointer, jsonpatch, jmespath, openstacksdk, simplejson, osc-lib, python-keystoneclient, os-client-config, python-neutronclient, kuryr-lib, kuryr-libnetwork Running setup.py install for subprocess32 ... error Complete output from command /usr/bin/python2 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-tVH19b/subprocess32/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-_SN4DI/install-record.txt --single-version-externally-managed --compile: running install running build running build_py creating build creating build/lib.linux-x86_64-2.7 copying subprocess32.py -> build/lib.linux-x86_64-2.7 running build_ext running build_configure checking for gcc... no checking for cc... no checking for cl.exe... no configure: error: in `/tmp/pip-install-tVH19b/subprocess32': configure: error: no acceptable C compiler found in $PATH See `config.log' for more details Traceback (most recent call last): File "", line 1, in File "/tmp/pip-install-tVH19b/subprocess32/setup.py", line 120, in main() File "/tmp/pip-install-tVH19b/subprocess32/setup.py", line 114, in main 'Programming Language :: Python :: Implementation :: CPython', File "/usr/lib/python2.7/site-packages/setuptools/__init__.py", line 140, in setup return distutils.core.setup(**attrs) File "/usr/lib64/python2.7/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib64/python2.7/distutils/dist.py", line 953, in run_commands self.run_command(cmd) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/usr/lib/python2.7/site-packages/setuptools/command/install.py", line 61, in run return orig.install.run(self) File "/usr/lib64/python2.7/distutils/command/install.py", line 563, in run self.run_command('build') File "/usr/lib64/python2.7/distutils/cmd.py", line 326, in run_command self.distribution.run_command(command) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/usr/lib64/python2.7/distutils/command/build.py", line 127, in run self.run_command(cmd_name) File "/usr/lib64/python2.7/distutils/cmd.py", line 326, in run_command self.distribution.run_command(command) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/tmp/pip-install-tVH19b/subprocess32/setup.py", line 41, in run self.run_command(command) File "/usr/lib64/python2.7/distutils/cmd.py", line 326, in run_command self.distribution.run_command(command) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/tmp/pip-install-tVH19b/subprocess32/setup.py", line 26, in run raise RuntimeError(configure_command + ' failed.') RuntimeError: sh ./configure failed. ---------------------------------------- Command "/usr/bin/python2 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-tVH19b/subprocess32/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-_SN4DI/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-install-tVH19b/subprocess32/ ~~~ python-dev and docker is already installed on the machine. Any help is highly appreciated. Thanks & Regards, Vikrant Aggarwal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From ervikrant06 at gmail.com Fri Nov 30 04:08:13 2018 From: ervikrant06 at gmail.com (Vikrant Aggarwal) Date: Fri, 30 Nov 2018 09:38:13 +0530 Subject: [openstack-dev] [kuryr] can we start kuryr libnetwork in container inside the nova VM. Message-ID: Hello Team, I have seen the steps of starting the kuryr libnetwork container on compute node. But If I need to run the same container inside the VM running on compute node, is't possible to do that? I am not sure how can I map the /var/run/openvswitch inside the nested VM because this is present on compute node. https://docs.openstack.org/kuryr-libnetwork/latest/readme.html Thanks & Regards, Vikrant Aggarwal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From wjstk16 at gmail.com Fri Nov 30 07:40:18 2018 From: wjstk16 at gmail.com (Won) Date: Fri, 30 Nov 2018 16:40:18 +0900 Subject: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage. In-Reply-To: References: Message-ID: Hi, I checked that both of the methods you propose work well. After I add 'should_delete_outdated_entities' function to InstanceDriver, it took about 10 minutes to clear the old Instance. And I added two sentences you said to Nova-cpu.conf, so the vitrage collector get notifications well. Thank you for your help. Best regards, Won 2018년 11월 22일 (목) 오후 9:35, Ifat Afek 님이 작성: > Hi, > > A deleted instance should be removed from Vitrage in one of two ways: > 1. By reacting to a notification from Nova > 2. If no notification is received, then after a while the instance vertex > in Vitrage is considered "outdated" and is deleted > > Regarding #1, it is clear from your logs that you don't get notifications > from Nova on the second compute. > Do you have on one of your nodes, in addition to nova.conf, also a > nova-cpu.conf? if so, please make the same change in this file: > > notification_topics = notifications,vitrage_notifications > > notification_driver = messagingv2 > > And please make sure to restart nova compute service on that node. > > Regarding #2, as a second-best solution, the instances should be deleted > from the graph after not being updated for a while. > I realized that we have a bug in this area and I will push a fix to gerrit > later today. In the meantime, you can add to > InstanceDriver class the following function: > > @staticmethod > def should_delete_outdated_entities(): > return True > > Let me know if it solved your problem, > Ifat > > > On Wed, Nov 21, 2018 at 1:50 PM Won wrote: > >> I attached four log files. >> I collected the logs from about 17:14 to 17:42. I created an instance of >> 'deltesting3' at 17:17. 7minutes later, at 17:24, the entity graph showed >> the dentesting3 and vitrage colletor and graph logs are appeared. >> When creating an instance in ubuntu server, it appears immediately in the >> entity graph and logs, but when creating an instance in computer1 (multi >> node), it appears about 5~10 minutes later. >> I deleted an instance of 'deltesting3' around 17:26. >> >> >>> After ~20minutes, there was only Apigateway. Does it make sense? did you >>> delete the instances on ubuntu, in addition to deltesting? >>> >> >> I only deleted 'deltesting'. After that, only the logs from 'apigateway' >> and 'kube-master' were collected. But other instances were working well. I >> don't know why only two instances are collected in the log. >> NOV 19 In this log, 'agigateway' and 'kube-master' were continuously >> collected in a short period of time, but other instances were sometimes >> collected in long periods. >> >> In any case, I would expect to see the instances deleted from the graph >>> at this stage, since they were not returned by get_all. >>> Can you please send me the log of vitrage-graph at the same time (Nov >>> 15, 16:35-17:10)? >>> >> >> Information 'deldtesting3' that has already been deleted continues to be >> collected in vitrage-graph.service. >> >> __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From jaypipes at gmail.com Fri Nov 30 13:57:32 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Fri, 30 Nov 2018 08:57:32 -0500 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> Message-ID: On 11/30/2018 02:53 AM, Mike Carden wrote: > I'm seeing a similar issue in Queens deployed via tripleo. > > Two x86 compute nodes and one ppc64le node and host aggregates for > virtual instances and baremetal (x86) instances. Baremetal on x86 is > working fine. > > All VMs get deployed to compute-0. I can live migrate VMs to compute-1 > and all is well, but I tire of being the 'meatspace scheduler'. LOL, I love that term and will have to remember to use it in the future. > I've looked at the nova.conf in the various nova-xxx containers on the > controllers, but I have failed to discern the root of this issue. Have you set the placement_randomize_allocation_candidates CONF option and are still seeing the packing behaviour? Best, -jay From mnaser at vexxhost.com Fri Nov 30 14:40:00 2018 From: mnaser at vexxhost.com (Mohammed Naser) Date: Fri, 30 Nov 2018 09:40:00 -0500 Subject: [openstack-dev] [Openstack-operators] [nova] Would an api option to create an instance without powering on be useful? In-Reply-To: References: Message-ID: On Fri, Nov 30, 2018 at 7:07 AM Matthew Booth wrote: > I have a request to do $SUBJECT in relation to a V2V workflow. The use > case here is conversion of a VM/Physical which was previously powered > off. We want to move its data, but we don't want to be powering on > stuff which wasn't previously on. > > This would involve an api change, and a hopefully very small change in > drivers to support it. Technically I don't see it as an issue. > > However, is it a change we'd be willing to accept? Is there any good > reason not to do this? Are there any less esoteric workflows which > might use this feature? > If you upload an image of said VM which you don't boot, you'd really be accomplishing the same thing, no? Unless you want to be in a state where you want the VM to be there but sitting in SHUTOFF state > Matt > -- > Matthew Booth > Red Hat OpenStack Engineer, Compute DFG > > Phone: +442070094448 (UK) > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser at vexxhost.com W. http://vexxhost.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From mnaser at vexxhost.com Fri Nov 30 14:40:00 2018 From: mnaser at vexxhost.com (Mohammed Naser) Date: Fri, 30 Nov 2018 09:40:00 -0500 Subject: [Openstack-operators] [nova] Would an api option to create an instance without powering on be useful? In-Reply-To: References: Message-ID: On Fri, Nov 30, 2018 at 7:07 AM Matthew Booth wrote: > I have a request to do $SUBJECT in relation to a V2V workflow. The use > case here is conversion of a VM/Physical which was previously powered > off. We want to move its data, but we don't want to be powering on > stuff which wasn't previously on. > > This would involve an api change, and a hopefully very small change in > drivers to support it. Technically I don't see it as an issue. > > However, is it a change we'd be willing to accept? Is there any good > reason not to do this? Are there any less esoteric workflows which > might use this feature? > If you upload an image of said VM which you don't boot, you'd really be accomplishing the same thing, no? Unless you want to be in a state where you want the VM to be there but sitting in SHUTOFF state > Matt > -- > Matthew Booth > Red Hat OpenStack Engineer, Compute DFG > > Phone: +442070094448 (UK) > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser at vexxhost.com W. http://vexxhost.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From alex at privacysystems.eu Fri Nov 30 14:24:18 2018 From: alex at privacysystems.eu (Alexandru Sorodoc) Date: Fri, 30 Nov 2018 16:24:18 +0200 Subject: [Openstack] [Pike][Neutron] L3 metering with DVR doesn't work In-Reply-To: References: <9ea77aca-0878-20b2-da0c-537b47e8b3f0@privacysystems.eu> Message-ID: Hello Brian, Thanks for the info. I looked into the code for the metering agent and discovered the following: 1. The metering agent on compute nodes doesn't get notified about DVR routers running on the node. 2. For DVR routers it tries to meter the rfp- interface(for floating ips) on the snat- namespace. This is wrong. The rfp- interface lies on the qrouter- namespace on compute nodes. Also, there is a qg- interface on the snat- namespace on network nodes (for performing NAT) which should be metered too. 3. There is a race condition whereby the metering agent is notified about a router before its namespaces are created. The agent ends up not adding the metering rules for those namespaces and this leads to unrecorded traffic. I addressed those issues in a change: https://review.openstack.org/#/c/621165/. Any feedback is appreciated. Best regards, Alex On 26/10/2018 21:49, Brian Haley wrote: > On 10/25/2018 08:06 AM, Alexandru Sorodoc wrote: >> Hello, >> >> I'm trying to set up metering for neutron in Pike. I tested it with a >> centralized router and it works, but when I try with a distributed >> router it >> doesn't record any usage samples. I have one compute node and one >> network node >> and I've created an instance with a floating ip. > > The metering agent isn't very well maintained, and I don't see any > open bugs similar to this issue.  The only thing I can remember is > this abandoned change regarding traffic counters for DVR routers - > https://review.openstack.org/#/c/486493/ but there was no follow-on > from the author. > > The best thing to do would be to try and reproduce it on the master > branch (or Rocky) and file a bug. > > > I think this is because the router is running on network1. Why is it > > running on > > network1 and why does it seem that the l3 agent on compute1 does the > actual > > routing? > > The compute node will do all the routing when a floating IP is > associated, the router on network1 is for default snat traffic when > there is no floating IP and the instance tries to communicate out the > external network. > > -Brian > >> >> openstack router show public-router2 >> +-------------------------+----------------------------------------------------+ >> >> | Field                   | >> Value                                              | >> +-------------------------+----------------------------------------------------+ >> >> | admin_state_up          | >> UP                                                 | >> | availability_zone_hints >> |                                                    | >> | availability_zones      | >> nova                                               | >> | created_at              | >> 2018-10-05T12:07:32Z                               | >> | description |                                                    | >> | distributed             | >> True                                               | >> | external_gateway_info   | {"network_id": >> "b96473ce-                          | >> |                         | 94f6-464f-a703-5285fb8ff3d3", >> "enable_snat": true, | >> |                         | "external_fixed_ips": >> [{"subnet_id":               | >> |                         | >> "6c08c3d9-7df1-4bec-b847-19f80b9d1764",            | >> |                         | "ip_address": >> "192.168.252.102"}]}                 | >> | flavor_id               | >> None                                               | >> | ha                      | >> False                                              | >> | id                      | >> 37c1794b-58d1-4d0d-b34b-944ca411b86b               | >> | name                    | >> public-router2                                     | >> | project_id              | >> fe203109e67f4e39b066c9529f9fc35d                   | >> | revision_number         | >> 5                                                  | >> | routes |                                                    | >> | status                  | >> ACTIVE                                             | >> | tags |                                                    | >> | updated_at              | >> 2018-10-05T12:09:36Z                               | >> +-------------------------+----------------------------------------------------+ >> >> >> openstack network agent list >> +-----------+------------+-----------+-------------------+-------+-------+--------------+ >> >> | ID        | Agent Type | Host      | Availability Zone | Alive | >> State | Binary       | >> +-----------+------------+-----------+-------------------+-------+-------+--------------+ >> >> | 14b9ea75- | L3 agent   | compute1. | nova | :-)   | UP    | >> neutron-l3-a | >> | 1dc1-4e37 |            | localdoma | |       |       | gent         | >> | -a2b0-508 |            | in        | |       | |              | >> | 3d336916d |            |           | |       | |              | >> | 26139ec1- | Metering   | compute1. | None | :-)   | UP    | >> neutron-     | >> | f4f9-4bb3 | agent      | localdoma | |       |       | metering-    | >> | -aebb-c35 |            | in        | |       |       | agent        | >> | 3a36ed79c |            |           | |       | |              | >> | 2a54971f- | DHCP agent | network1. | nova | :-)   | UP    | >> neutron-     | >> | 9849-4ed2 |            | localdoma | |       |       | dhcp-agent   | >> | -b009-00e |            | in        | |       | |              | >> | 45eb4d255 |            |           | |       | |              | >> | 443c0b49- | Open       | compute1. | None | :-)   | UP    | >> neutron-     | >> | 4484-44d2 | vSwitch    | localdoma | |       |       | openvswitch- | >> | -a704-32a | agent      | in        | |       |       | agent        | >> | 92ffe6982 |            |           | |       | |              | >> | 5d00a219  | L3 agent   | network1. | nova | :-)   | UP    | >> neutron-vpn- | >> | -abce-    |            | localdoma | |       |       | agent        | >> | 48ca-     |            | in        | |       | |              | >> | ba1e-d962 |            |           | |       | |              | >> | 01bd7de3  |            |           | |       | |              | >> | bc3458b4  | Open       | network1. | None | :-)   | UP    | >> neutron-     | >> | -250e-    | vSwitch    | localdoma | |       |       | openvswitch- | >> | 4adf-90e0 | agent      | in        | |       |       | agent        | >> | -110a1a7f |            |           | |       | |              | >> | 6ccb      |            |           | |       | |              | >> | c29f9da8- | Metering   | network1. | None | :-)   | UP    | >> neutron-     | >> | ca58-4a11 | agent      | localdoma | |       |       | metering-    | >> | -b500-a25 |            | in        | |       |       | agent        | >> | 3f820808e |            |           | |       | |              | >> | cdce667d- | Metadata   | network1. | None | :-)   | UP    | >> neutron-     | >> | faa4      | agent      | localdoma | |       |       | metadata-    | >> | -49ed-    |            | in        | |       |       | agent        | >> | 83ee-e0e5 |            |           | |       | |              | >> | a352d482  |            |           | |       | |              | >> | cf5ae104- | Metadata   | compute1. | None | :-)   | UP    | >> neutron-     | >> | 49d7-4c85 | agent      | localdoma | |       |       | metadata-    | >> | -a252-cc5 |            | in        | |       |       | agent        | >> | 9a9a12789 |            |           | |       | |              | >> +-----------+------------+-----------+-------------------+-------+-------+--------------+ >> >> >> If I check the node on which my distributed router is running it >> tells me that >> it's running on the network node: >> >> neutron l3-agent-list-hosting-router >> 37c1794b-58d1-4d0d-b34b-944ca411b86b >> +--------------------------------------+----------------------+----------------+-------+----------+ >> >> | id                                   | host                 | >> admin_state_up | alive | ha_state | >> +--------------------------------------+----------------------+----------------+-------+----------+ >> >> | 5d00a219-abce-48ca-ba1e-d96201bd7de3 | network1.localdomain | >> True           | :-)   |          | >> +--------------------------------------+----------------------+----------------+-------+----------+ >> >> >> If I check the iptable rules for the router on the compute and >> network nodes by running: >> >> ip netns exec qrouter-37c1794b-58d1-4d0d-b34b-944ca411b86b iptables >> -nv -L >> >> I see that compute1 records the traffic while network1 doesn't. Also, >> I did some >> debugging and found out that the metering agent on compute1 receives >> an empty >> list of routers when querying the routers that it should monitor. >> >> Source: >> >> https://github.com/openstack/neutron/blob/stable/pike/neutron/services/metering/agents/metering_agent.py#L177-L189 >> >> >> https://github.com/openstack/neutron/blob/stable/pike/neutron/db/metering/metering_rpc.py#L33-L57 >> >> >> I think this is because the router is running on network1. Why is it >> running on >> network1 and why does it seem that the l3 agent on compute1 does the >> actual >> routing? >> >> Thanks, >> Alex >> >> >> >> _______________________________________________ >> Mailing list: >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> Post to     : openstack at lists.openstack.org >> Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack From colleen at gazlene.net Fri Nov 30 15:35:44 2018 From: colleen at gazlene.net (Colleen Murphy) Date: Fri, 30 Nov 2018 16:35:44 +0100 Subject: [dev][keystone] Message-ID: <1543592144.2754484.1594460320.42149A24@webmail.messagingengine.com> # Keystone Team Update - Week of 26 November 2018 ## News ### Forum Recap Two weeks ago some of us attended the OpenStack Summit in Berlin, where we had a couple of keystone-specific sessions and had some discussions with Edge computing operators and public cloud operators about keystone use cases. Lance wrote up a recap[1]. [1] https://www.lbragstad.com/blog/openstack-summit-berlin-recap ### Refreshable application credentials We had a short discussion on how refreshable application credentials will be implemented[2]. The summary is that new fields should be added to the existing model, renewed_at and renewable_roles. We had discussed adding a new expiration field or reusing the existing expiration field, but decided that for the refresh use case, application credentials shouldn't be using expiration but instead a static comparison of the last refresh time and a configurable TTL tied to the IdP. The existing expiration field will remain user-configurable. [2] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-11-29.log.html#t2018-11-29T14:12:45 ## Open Specs Stein specs: https://bit.ly/2Pi6dGj Ongoing specs: https://bit.ly/2OyDLTh The JWT spec[3] and the domain support for limits spec[4] are ready to go, please have a look. There are also several specs not proposed for Stein but instead proposed as "ongoing" that need reviews. [3] https://review.openstack.org/541903 [4] https://review.openstack.org/599491 ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 20 changes this week. ## Changes that need Attention Search query: https://bit.ly/2RLApdA There are 82 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. Most of them are from Lance to incorporate our new default roles into our own policies. ## Bugs This week we opened 14 new bugs and closed 4. Bugs opened (14)  Bug #1805400 (keystone:High) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805400  Bug #1805363 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805363  Bug #1805366 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805366  Bug #1805368 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805368  Bug #1805369 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805369  Bug #1805371 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805371  Bug #1805372 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805372  Bug #1805402 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805402  Bug #1805403 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805403  Bug #1805406 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805406  Bug #1805880 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805880  Bug #1805409 (keystone:Wishlist) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805409  Bug #1805165 (keystone:Undecided) opened by Boris Bobrov https://bugs.launchpad.net/keystone/+bug/1805165  Bug #1805817 (keystone:Undecided) opened by Robert Duncan https://bugs.launchpad.net/keystone/+bug/1805817  Bugs fixed (4)  Bug #1735250 (keystone:High) fixed by wangxiyuan https://bugs.launchpad.net/keystone/+bug/1735250  Bug #1792026 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1792026  Bug #1781536 (keystone:Low) fixed by Gage Hugo https://bugs.launchpad.net/keystone/+bug/1781536  Bug #1802357 (oslo.policy:Undecided) fixed by no one https://bugs.launchpad.net/oslo.policy/+bug/1802357 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html There is just over a month left until the Stein spec freeze. Please have a look at the currently proposed specs for Stein. ## Shout-outs Thanks Jens Harbott for helping us out with our Zuul job issues[5][6]! [5] https://review.openstack.org/611563 [6] https://review.openstack.org/620553 ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter Dashboard generated using gerrit-dash-creator and https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67 From colleen at gazlene.net Fri Nov 30 15:37:13 2018 From: colleen at gazlene.net (Colleen Murphy) Date: Fri, 30 Nov 2018 16:37:13 +0100 Subject: [dev][keystone] Keystone Team Update - Week of 26 November 2018 In-Reply-To: <1543592144.2754484.1594460320.42149A24@webmail.messagingengine.com> References: <1543592144.2754484.1594460320.42149A24@webmail.messagingengine.com> Message-ID: <1543592233.2754761.1594460640.1789786A@webmail.messagingengine.com> (failed subject line) On Fri, Nov 30, 2018, at 4:35 PM, Colleen Murphy wrote: > # Keystone Team Update - Week of 26 November 2018 > > ## News > > ### Forum Recap > > Two weeks ago some of us attended the OpenStack Summit in Berlin, where > we had a couple of keystone-specific sessions and had some discussions > with Edge computing operators and public cloud operators about keystone > use cases. Lance wrote up a recap[1]. > > [1] https://www.lbragstad.com/blog/openstack-summit-berlin-recap > > ### Refreshable application credentials > > We had a short discussion on how refreshable application credentials > will be implemented[2]. The summary is that new fields should be added > to the existing model, renewed_at and renewable_roles. We had discussed > adding a new expiration field or reusing the existing expiration field, > but decided that for the refresh use case, application credentials > shouldn't be using expiration but instead a static comparison of the > last refresh time and a configurable TTL tied to the IdP. The existing > expiration field will remain user-configurable. > > [2] > http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-11-29.log.html#t2018-11-29T14:12:45 > > ## Open Specs > > Stein specs: https://bit.ly/2Pi6dGj > > Ongoing specs: https://bit.ly/2OyDLTh > > The JWT spec[3] and the domain support for limits spec[4] are ready to > go, please have a look. There are also several specs not proposed for > Stein but instead proposed as "ongoing" that need reviews. > > [3] https://review.openstack.org/541903 > [4] https://review.openstack.org/599491 > > ## Recently Merged Changes > > Search query: https://bit.ly/2pquOwT > > We merged 20 changes this week. > > ## Changes that need Attention > > Search query: https://bit.ly/2RLApdA > > There are 82 changes that are passing CI, not in merge conflict, have no > negative reviews and aren't proposed by bots. Most of them are from > Lance to incorporate our new default roles into our own policies. > > ## Bugs > > This week we opened 14 new bugs and closed 4. > > Bugs opened (14)  > Bug #1805400 (keystone:High) opened by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1805400  > Bug #1805363 (keystone:Medium) opened by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1805363  > Bug #1805366 (keystone:Medium) opened by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1805366  > Bug #1805368 (keystone:Medium) opened by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1805368  > Bug #1805369 (keystone:Medium) opened by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1805369  > Bug #1805371 (keystone:Medium) opened by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1805371  > Bug #1805372 (keystone:Medium) opened by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1805372  > Bug #1805402 (keystone:Medium) opened by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1805402  > Bug #1805403 (keystone:Medium) opened by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1805403  > Bug #1805406 (keystone:Medium) opened by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1805406  > Bug #1805880 (keystone:Medium) opened by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1805880  > Bug #1805409 (keystone:Wishlist) opened by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1805409  > Bug #1805165 (keystone:Undecided) opened by Boris Bobrov > https://bugs.launchpad.net/keystone/+bug/1805165  > Bug #1805817 (keystone:Undecided) opened by Robert Duncan > https://bugs.launchpad.net/keystone/+bug/1805817  > > Bugs fixed (4)  > Bug #1735250 (keystone:High) fixed by wangxiyuan > https://bugs.launchpad.net/keystone/+bug/1735250  > Bug #1792026 (keystone:Medium) fixed by Lance Bragstad > https://bugs.launchpad.net/keystone/+bug/1792026  > Bug #1781536 (keystone:Low) fixed by Gage Hugo > https://bugs.launchpad.net/keystone/+bug/1781536  > Bug #1802357 (oslo.policy:Undecided) fixed by no one > https://bugs.launchpad.net/oslo.policy/+bug/1802357 > > ## Milestone Outlook > > https://releases.openstack.org/stein/schedule.html > > There is just over a month left until the Stein spec freeze. Please have > a look at the currently proposed specs for Stein. > > ## Shout-outs > > Thanks Jens Harbott for helping us out with our Zuul job issues[5][6]! > > [5] https://review.openstack.org/611563 > [6] https://review.openstack.org/620553 > > ## Help with this newsletter > > Help contribute to this newsletter by editing the etherpad: > https://etherpad.openstack.org/p/keystone-team-newsletter > Dashboard generated using gerrit-dash-creator and > https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67 From jaypipes at gmail.com Fri Nov 30 15:52:07 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Fri, 30 Nov 2018 10:52:07 -0500 Subject: [Openstack-operators] [nova] Would an api option to create an instance without powering on be useful? In-Reply-To: References: Message-ID: <72c6897a-7de8-c290-b4bf-b9fd6a79be14@gmail.com> On 11/30/2018 07:06 AM, Matthew Booth wrote: > I have a request to do $SUBJECT in relation to a V2V workflow. The use > case here is conversion of a VM/Physical which was previously powered > off. We want to move its data, but we don't want to be powering on > stuff which wasn't previously on. > > This would involve an api change, and a hopefully very small change in > drivers to support it. Technically I don't see it as an issue. > > However, is it a change we'd be willing to accept? Is there any good > reason not to do this? Are there any less esoteric workflows which > might use this feature? It's similar to the node import use case from Ironic. I can see use cases for registering pre-created instances (or creating batches of instance records from previously non-OpenStack-managed workloads). Lots of corner cases would need to be fleshed out, though. I know at Oath we've got some pretty nasty code to register non-OpenStack baremetal workloads with OpenStack and make sure they cannot be scheduled and are not reimaged/cleaned by Ironic. So, I'm generally supportive of the idea. But devil's in the details of course. :) Best, -jay From mdulko at redhat.com Fri Nov 30 16:01:05 2018 From: mdulko at redhat.com (=?UTF-8?Q?Micha=C5=82?= Dulko) Date: Fri, 30 Nov 2018 17:01:05 +0100 Subject: [openstack-dev] [kuryr] can we start kuryr libnetwork in container inside the nova VM. In-Reply-To: References: Message-ID: <7b585278013291fda1d55b5d74965b26d317e637.camel@redhat.com> On Fri, 2018-11-30 at 09:38 +0530, Vikrant Aggarwal wrote: > Hello Team, > > I have seen the steps of starting the kuryr libnetwork container on > compute node. But If I need to run the same container inside the VM > running on compute node, is't possible to do that? > > I am not sure how can I map the /var/run/openvswitch inside the > nested VM because this is present on compute node. I think that if you want to run Neutron-networked Docker containers on an OpenStack VM, you'll need OpenvSwitch and neutron-agent installed on that VM as well. A better-suited approach would be to run K8s on OpenStack and use kuryr-kubernetes instead. That way Neutron subports are used to network pods. We have such a K8s-on-VM use case described in the docs [1]. [1] https://docs.openstack.org/kuryr-kubernetes/latest/installation/devstack/nested-vlan.html > https://docs.openstack.org/kuryr-libnetwork/latest/readme.html > > Thanks & Regards, > Vikrant Aggarwal From openstack at nemebean.com Fri Nov 30 16:22:31 2018 From: openstack at nemebean.com (Ben Nemec) Date: Fri, 30 Nov 2018 10:22:31 -0600 Subject: [dev][qa][devstack] Release management for QA toold and plugins In-Reply-To: <6be6bbf3-a862-df85-5120-b90f5c74c1cf@openstack.org> References: <20f06939-9590-4b93-3381-02c32570b990@openstack.org> <20181129191636.GA26514@sinanju.localdomain> <167627c0fb2.fedfd67828981.6889702971134127091@ghanshyammann.com> <167638457ad.fe9b8693739.8314446462346139058@ghanshyammann.com> <6be6bbf3-a862-df85-5120-b90f5c74c1cf@openstack.org> Message-ID: <3379d4c8-9318-ab9f-7ad7-2fa9cf97dd34@nemebean.com> On 11/30/18 4:05 AM, Thierry Carrez wrote: > Ghanshyam Mann wrote: >>   ---- On Fri, 30 Nov 2018 14:29:24 +0900 Duc Truong >> wrote ---- >>   > On Thu, Nov 29, 2018 at 6:39 PM Ghanshyam Mann >> wrote: >>   > > >>   > >  > > * devstack-vagrant: never released, no change over the past >> year. Is it >>   > >  > > meant to be released in the future (cycle-independent) or >> considered >>   > >  > > continuously published (release-management:none) or should >> it be retired ? >>   > >  > >>   > > >>   > > I am ok to retire this based on no one using it. >>   > >>   > I actually use devstack-vagrant and find it useful to setup >> consistent >>   > devstack environments with minimal effort. >> >> Ok, then we can keep that. I will be happy to add you as maintainer of >> that if you would like to. I saw you have done some commit and review >> in Tempest and will be good to have you as devstack-vagrant . > > OK so in summary: > > eslint-config-openstack, karma-subunit-reporter, devstack-tools -> > should be considered cycle-independent (with older releases history > imported). Any future release would be done through openstack/releases > > devstack-vagrant -> does not need releases or release management, will > be marked release-management:none in governance > > devstack-plugin-ceph -> does not need releases or cycle-related > branching, so will be marked release-management:none in governance > > Other devstack-plugins maintainers should pick whether they need to be > branched every cycle or not. Oslo-maintained plugins like > devstack-plugin-zmq and devstack-plugin-pika will, for example. Oh right, those exist too. :-) Both the zmq and pika drivers have been removed from oslo.messaging so those two repos can actually be retired once we no longer ci releases that contain the drivers. In the meantime there isn't any need to branch them since there isn't any development going on. Not sure whether that affects your plans but I thought I should clarify our plans for those two repos. > > Unless someone objects, I'll push the related changes where needed. > Thanks for the clarification ! > From openstack at nemebean.com Fri Nov 30 16:34:47 2018 From: openstack at nemebean.com (Ben Nemec) Date: Fri, 30 Nov 2018 10:34:47 -0600 Subject: [openstack-dev] [nova] Would an api option to create an instance without powering on be useful? In-Reply-To: References: Message-ID: <81627e78-4f92-2909-f209-284b4847ae09@nemebean.com> On 11/30/18 6:06 AM, Matthew Booth wrote: > I have a request to do $SUBJECT in relation to a V2V workflow. The use > case here is conversion of a VM/Physical which was previously powered > off. We want to move its data, but we don't want to be powering on > stuff which wasn't previously on. > > This would involve an api change, and a hopefully very small change in > drivers to support it. Technically I don't see it as an issue. > > However, is it a change we'd be willing to accept? Is there any good > reason not to do this? Are there any less esoteric workflows which > might use this feature? I don't know if it qualifies as less esoteric, but I would use this for OVB[1]. When we create the "baremetal" VMs there's no need to actually power them on since the first thing we do with them is shut them down again. Their initial footprint is pretty small so it's not a huge deal, but it is another potential use case for this feature. 1: https://openstack-virtual-baremetal.readthedocs.io/en/latest/introduction.html __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From openstack at nemebean.com Fri Nov 30 16:34:47 2018 From: openstack at nemebean.com (Ben Nemec) Date: Fri, 30 Nov 2018 10:34:47 -0600 Subject: [Openstack-operators] [openstack-dev] [nova] Would an api option to create an instance without powering on be useful? In-Reply-To: References: Message-ID: <81627e78-4f92-2909-f209-284b4847ae09@nemebean.com> On 11/30/18 6:06 AM, Matthew Booth wrote: > I have a request to do $SUBJECT in relation to a V2V workflow. The use > case here is conversion of a VM/Physical which was previously powered > off. We want to move its data, but we don't want to be powering on > stuff which wasn't previously on. > > This would involve an api change, and a hopefully very small change in > drivers to support it. Technically I don't see it as an issue. > > However, is it a change we'd be willing to accept? Is there any good > reason not to do this? Are there any less esoteric workflows which > might use this feature? I don't know if it qualifies as less esoteric, but I would use this for OVB[1]. When we create the "baremetal" VMs there's no need to actually power them on since the first thing we do with them is shut them down again. Their initial footprint is pretty small so it's not a huge deal, but it is another potential use case for this feature. 1: https://openstack-virtual-baremetal.readthedocs.io/en/latest/introduction.html _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From thierry at openstack.org Fri Nov 30 17:16:02 2018 From: thierry at openstack.org (Thierry Carrez) Date: Fri, 30 Nov 2018 18:16:02 +0100 Subject: [dev][qa][devstack] Release management for QA toold and plugins In-Reply-To: <3379d4c8-9318-ab9f-7ad7-2fa9cf97dd34@nemebean.com> References: <20f06939-9590-4b93-3381-02c32570b990@openstack.org> <20181129191636.GA26514@sinanju.localdomain> <167627c0fb2.fedfd67828981.6889702971134127091@ghanshyammann.com> <167638457ad.fe9b8693739.8314446462346139058@ghanshyammann.com> <6be6bbf3-a862-df85-5120-b90f5c74c1cf@openstack.org> <3379d4c8-9318-ab9f-7ad7-2fa9cf97dd34@nemebean.com> Message-ID: <8fee3e8f-91ad-4152-d6b0-a09ea95857fb@openstack.org> Ben Nemec wrote: > On 11/30/18 4:05 AM, Thierry Carrez wrote: >> [...] >> Other devstack-plugins maintainers should pick whether they need to be >> branched every cycle or not. Oslo-maintained plugins like >> devstack-plugin-zmq and devstack-plugin-pika will, for example. > > Oh right, those exist too. :-) > > Both the zmq and pika drivers have been removed from oslo.messaging so > those two repos can actually be retired once we no longer ci releases > that contain the drivers. In the meantime there isn't any need to branch > them since there isn't any development going on. > > Not sure whether that affects your plans but I thought I should clarify > our plans for those two repos. Thanks, I was indeed confused and filed https://review.openstack.org/621245 to revert. We probably need a specific release-management:no-more-needed or something to track such things that are not released anymore but are not ripe for removal just yet... -- Thierry Carrez (ttx) From openstack at fried.cc Fri Nov 30 17:28:20 2018 From: openstack at fried.cc (Eric Fried) Date: Fri, 30 Nov 2018 11:28:20 -0600 Subject: [placement] update 18-48 In-Reply-To: References: Message-ID: <7e8bfb9b-71e9-2a14-fae8-52b7a5d03ab1@fried.cc> > We've been putting off making a decision about os-resource-classes. > Anyone have strong opinions? Only that we get out of analysis paralysis mode and do it. Pretty much any of the suggested routes will be fine. (Do we have an etherpad or something that summarizes those?) -efried From sam.bouwari at verizon.com Fri Nov 30 16:28:41 2018 From: sam.bouwari at verizon.com (sam.bouwari at verizon.com) Date: Fri, 30 Nov 2018 16:28:41 +0000 Subject: Horizon Logging Question Message-ID: Hello Horizon Proj Developers. In previous (older) Openstack/Horizon versions (version 7 or 8), the /var/log/horizon.log file used to reveal "remote address" information when a user attempts to login to Horizon GUI with wrong password, or if someone is trying to guess a password, then a log entry similar to this would be logged: 2018-11-01 19:39:35,728 3711 WARNING openstack_auth.forms Login failed for user "admin", remote address 192.168.1.12. In newer OSP/Horizon versions, the "remote address" field seems to have been truncated from the log and all we see now is a login entry in /var/log/horizon.log similar to this: 2018-11-30 14:23:10,912 473292 WARNING openstack_auth.forms Login failed for user "admin". Is there any valid reason as to why this feature was removed from newer version of Horizon? Logging the "remote address" information is very useful from security/IR and log monitoring standpoint where an analyst can identify if someone is trying to guess passwords, or trying to brute force the Horizon GUI, and other useful scenarios. Is there a configuration parameter in Horizon that can be turned on to log the "remote address" infromation again? Or is this feature just not available anymore in the product? Your help is greatly appreciated! Thanks Sam Bouwari -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfolco at redhat.com Fri Nov 30 17:48:23 2018 From: rfolco at redhat.com (Rafael Folco) Date: Fri, 30 Nov 2018 15:48:23 -0200 Subject: [openstack-dev][tripleo] TripleO CI Summary: Sprint 22 Message-ID: Greetings, The TripleO CI team has just completed Sprint 22 (Nov 08 thru Nov 28). The following is a summary of completed work during this sprint cycle: - Converted multinode scenarios(1-4) to standalone job. This effort will allow us to replace multinode scenario jobs that are consuming most of upstream resources. Replacement of multinode scenario jobs is starting immediately and should be complete by Jan 2019. - Improved python and ansible support on Fedora 28 job, which is successfully deploying TripleO, but still requires further work on Tempest packaging before becoming a voting job. This is the first step in using upstream CI to validate python3 and RHEL8 work. - Investigated alternative solutions for the reproducer to approximate with the zuulv3 workflow. A PoC has been developed to run Zuul in a container as the reproducer script for TripleO CI. - Tested a new CI environment for OVB jobs on RDO cloud. Experiments for refectoring ovb deployment to be incorporated into CI code without te-broker bits. - https://tree.taiga.io/project/tripleo-ci-board/epic/298 - Initial testing of CentOS 7.6 looks good - https://tree.taiga.io/project/tripleo-ci-board/issue/309?kanban-status=2027733 The sprint task board for CI team is tracked on Taiga [1] and the Ruck and Rover notes for this sprint has been tracked in the etherpad [2]. The planned work for the next sprint focuses in completing the upstream standalone job for Fedora 28 by eliminating all related issues. It also includes moving the multinode scenarios to the standalone jobs that has started in the previous sprint. The team continues to work on the reproducer and preparing a CI environment for OVB. The only new item for the sprint is to start building the production pipeline promotion jobs for Fedora 28. The Ruck and Rover for this sprint are Marios Andreou (marios) and Sorin Sbarnea (ssbarnea). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Thanks, Folco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/sprint-23unified-sprint-2 [2] https://review.rdoproject.org/etherpad/p/ruckrover-sprint22 -- Rafael Folco Senior Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kevin.Fox at pnnl.gov Fri Nov 30 17:48:42 2018 From: Kevin.Fox at pnnl.gov (Fox, Kevin M) Date: Fri, 30 Nov 2018 17:48:42 +0000 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: References: <429cdff5-77b8-8417-8024-ef99ee2234dc@redhat.com> <48ec22eab4c90f248779b8bf7677b9a9a5bacc2f.camel@redhat.com> <4121346a-7341-184f-2dcb-32092409196b@redhat.com> <4efc561819a8ff90628902117e1514262f03b9cd.camel@redhat.com> <29497a3a-ce90-b7ec-d0f8-3f98c90016ce@redhat.com> <7d2fce52ca8bb5156b753a95cbb9e2df7ad741c8.camel@redhat.com>, Message-ID: <1A3C52DFCD06494D8528644858247BF01C24B507@EX10MBOX03.pnnl.gov> Still confused by: [base] -> [service] -> [+ puppet] not: [base] -> [puppet] and [base] -> [service] ? Thanks, Kevin ________________________________________ From: Bogdan Dobrelya [bdobreli at redhat.com] Sent: Friday, November 30, 2018 5:31 AM To: Dan Prince; openstack-dev at lists.openstack.org; openstack-discuss at lists.openstack.org Subject: Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes On 11/30/18 1:52 PM, Dan Prince wrote: > On Fri, 2018-11-30 at 10:31 +0100, Bogdan Dobrelya wrote: >> On 11/29/18 6:42 PM, Jiří Stránský wrote: >>> On 28. 11. 18 18:29, Bogdan Dobrelya wrote: >>>> On 11/28/18 6:02 PM, Jiří Stránský wrote: >>>>> >>>>> >>>>>> Reiterating again on previous points: >>>>>> >>>>>> -I'd be fine removing systemd. But lets do it properly and >>>>>> not via 'rpm >>>>>> -ev --nodeps'. >>>>>> -Puppet and Ruby *are* required for configuration. We can >>>>>> certainly put >>>>>> them in a separate container outside of the runtime service >>>>>> containers >>>>>> but doing so would actually cost you much more >>>>>> space/bandwidth for each >>>>>> service container. As both of these have to get downloaded to >>>>>> each node >>>>>> anyway in order to generate config files with our current >>>>>> mechanisms >>>>>> I'm not sure this buys you anything. >>>>> >>>>> +1. I was actually under the impression that we concluded >>>>> yesterday on >>>>> IRC that this is the only thing that makes sense to seriously >>>>> consider. >>>>> But even then it's not a win-win -- we'd gain some security by >>>>> leaner >>>>> production images, but pay for it with space+bandwidth by >>>>> duplicating >>>>> image content (IOW we can help achieve one of the goals we had >>>>> in mind >>>>> by worsening the situation w/r/t the other goal we had in >>>>> mind.) >>>>> >>>>> Personally i'm not sold yet but it's something that i'd >>>>> consider if we >>>>> got measurements of how much more space/bandwidth usage this >>>>> would >>>>> consume, and if we got some further details/examples about how >>>>> serious >>>>> are the security concerns if we leave config mgmt tools in >>>>> runtime >>>>> images. >>>>> >>>>> IIRC the other options (that were brought forward so far) were >>>>> already >>>>> dismissed in yesterday's IRC discussion and on the reviews. >>>>> Bin/lib bind >>>>> mounting being too hacky and fragile, and nsenter not really >>>>> solving the >>>>> problem (because it allows us to switch to having different >>>>> bins/libs >>>>> available, but it does not allow merging the availability of >>>>> bins/libs >>>>> from two containers into a single context). >>>>> >>>>>> We are going in circles here I think.... >>>>> >>>>> +1. I think too much of the discussion focuses on "why it's bad >>>>> to have >>>>> config tools in runtime images", but IMO we all sorta agree >>>>> that it >>>>> would be better not to have them there, if it came at no cost. >>>>> >>>>> I think to move forward, it would be interesting to know: if we >>>>> do this >>>>> (i'll borrow Dan's drawing): >>>>> >>>>>> base container| --> |service container| --> |service >>>>>> container w/ >>>>> Puppet installed| >>>>> >>>>> How much more space and bandwidth would this consume per node >>>>> (e.g. >>>>> separately per controller, per compute). This could help with >>>>> decision >>>>> making. >>>> >>>> As I've already evaluated in the related bug, that is: >>>> >>>> puppet-* modules and manifests ~ 16MB >>>> puppet with dependencies ~61MB >>>> dependencies of the seemingly largest a dependency, systemd >>>> ~190MB >>>> >>>> that would be an extra layer size for each of the container >>>> images to be >>>> downloaded/fetched into registries. >>> >>> Thanks, i tried to do the math of the reduction vs. inflation in >>> sizes >>> as follows. I think the crucial point here is the layering. If we >>> do >>> this image layering: >>> >>>> base| --> |+ service| --> |+ Puppet| >>> >>> we'd drop ~267 MB from base image, but we'd be installing that to >>> the >>> topmost level, per-component, right? >> >> Given we detached systemd from puppet, cronie et al, that would be >> 267-190MB, so the math below would be looking much better > > Would it be worth writing a spec that summarizes what action items are > bing taken to optimize our base image with regards to the systemd? Perhaps it would be. But honestly, I see nothing biggie to require a full blown spec. Just changing RPM deps and layers for containers images. I'm tracking systemd changes here [0],[1],[2], btw (if accepted, it should be working as of fedora28(or 29) I hope) [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction [1] https://bugzilla.redhat.com/show_bug.cgi?id=1654659 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1654672 > > It seems like the general consenses is that cleaning up some of the RPM > dependencies so that we don't install Systemd is the biggest win. > > What confuses me is why are there still patches posted to move Puppet > out of the base layer when we agree moving it out of the base layer > would actually cause our resulting container image set to be larger in > size. > > Dan > > >> >>> In my basic deployment, undercloud seems to have 17 "components" >>> (49 >>> containers), overcloud controller 15 components (48 containers), >>> and >>> overcloud compute 4 components (7 containers). Accounting for >>> overlaps, >>> the total number of "components" used seems to be 19. (By >>> "components" >>> here i mean whatever uses a different ConfigImage than other >>> services. I >>> just eyeballed it but i think i'm not too far off the correct >>> number.) >>> >>> So we'd subtract 267 MB from base image and add that to 19 leaf >>> images >>> used in this deployment. That means difference of +4.8 GB to the >>> current >>> image sizes. My /var/lib/registry dir on undercloud with all the >>> images >>> currently has 5.1 GB. We'd almost double that to 9.9 GB. >>> >>> Going from 5.1 to 9.9 GB seems like a lot of extra traffic for the >>> CDNs >>> (both external and e.g. internal within OpenStack Infra CI clouds). >>> >>> And for internal traffic between local registry and overcloud >>> nodes, it >>> gives +3.7 GB per controller and +800 MB per compute. That may not >>> be so >>> critical but still feels like a considerable downside. >>> >>> Another gut feeling is that this way of image layering would take >>> longer >>> time to build and to run the modify-image Ansible role which we use >>> in >>> CI, so that could endanger how our CI jobs fit into the time limit. >>> We >>> could also probably measure this but i'm not sure if it's worth >>> spending >>> the time. >>> >>> All in all i'd argue we should be looking at different options >>> still. >>> >>>> Given that we should decouple systemd from all/some of the >>>> dependencies >>>> (an example topic for RDO [0]), that could save a 190MB. But it >>>> seems we >>>> cannot break the love of puppet and systemd as it heavily relies >>>> on the >>>> latter and changing packaging like that would higly likely affect >>>> baremetal deployments with puppet and systemd co-operating. >>> >>> Ack :/ >>> >>>> Long story short, we cannot shoot both rabbits with a single >>>> shot, not >>>> with puppet :) May be we could with ansible replacing puppet >>>> fully... >>>> So splitting config and runtime images is the only choice yet to >>>> address >>>> the raised security concerns. And let's forget about edge cases >>>> for now. >>>> Tossing around a pair of extra bytes over 40,000 WAN-distributed >>>> computes ain't gonna be our the biggest problem for sure. >>>> >>>> [0] >>>> https://review.rdoproject.org/r/#/q/topic:base-container-reduction >>>> >>>>>> Dan >>>>>> >>>>> >>>>> Thanks >>>>> >>>>> Jirka >>>>> >>>>> _______________________________________________________________ >>>>> ___________ >>>>> >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> ___________________________________________________________________ >>> _______ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsu >>> bscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > -- Best regards, Bogdan Dobrelya, Irc #bogdando From mvoelker at vmware.com Fri Nov 30 17:58:45 2018 From: mvoelker at vmware.com (Mark Voelker) Date: Fri, 30 Nov 2018 17:58:45 +0000 Subject: [Interop-wg] [dev] [cinder] [qa] Strict Validation for Volume API using JSON Schema In-Reply-To: <29d271ff-d5a7-2a28-53c1-3be7b868ad20@gmail.com> References: <16760426d56.ef4c345622903.2195899647060980382@ghanshyammann.com> <29d271ff-d5a7-2a28-53c1-3be7b868ad20@gmail.com> Message-ID: <8337FB0D-81D3-4E6C-9039-47BD749C3862@vmware.com> > On Nov 29, 2018, at 9:28 PM, Matt Riedemann wrote: > > On 11/29/2018 10:17 AM, Ghanshyam Mann wrote: >> - To improve the volume API testing to avoid the backward compatible changes. Sometime we accidentally change the API in backward incompatible way and strict validation with JSON schema help to block those. > > +1 this is very useful to avoid unintentionally breaking the API. > >> We want to hear from cinder and interop team about any impact of this change to them. > > I'm mostly interested in what the interop WG would do about this given it's a potentially breaking change for interop without changes to the guidelines. Would there be some sort of grace period for clouds to conform to the changes in tempest? > That’s more or less what eventually happened when we began enforcing strict validation on Nova a few years ago after considerable debate. Clouds that were compliant with the interop guidelines before the strict validation patch landed and started failing once it went in could apply for a waiver while they worked on removing or upstreaming the nonstandard stuff. For those not familiar, here’s the patch that created a waiver program: https://review.openstack.org/#/c/333067/ Note that this expired with the 2017.01 Guideline: https://review.openstack.org/#/c/512447/ While not everyone was totally happy with the solution, it seemed to work out as a middle ground solution that helped get clouds on a better path in the end. I think we’ll discuss whether we’d need to do something like this again here. I’d love to hear: 1.) If anyone knows of clouds/products that would be fail interop testing because of this. Not looking to name and shame, just to get an idea of whether or not we have a concrete problem and how big it is. 2.) Opinions on how the waiver program went last time and whether the rest of the community feels like it’s something we should consider again. Personally I’m supportive of the general notion of improving API interoperability here…as usual it’s figuring out the mechanics of the transition that take a little figuring. =) At Your Service, Mark T. Voelker > -- > > Thanks, > > Matt > > _______________________________________________ > Interop-wg mailing list > Interop-wg at lists.openstack.org > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Finterop-wg&data=02%7C01%7Cmvoelker%40vmware.com%7C82a07fe28afe488c2eea08d6566b9734%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636791417437738014&sdata=lEx%2BbbTVzC%2FRC7ebmARDrFhfMsToM7Rwx8EKYtE7iFM%3D&reserved=0 From jillr at redhat.com Fri Nov 30 20:38:10 2018 From: jillr at redhat.com (Jill Rouleau) Date: Fri, 30 Nov 2018 13:38:10 -0700 Subject: [tripleo] Expose healthchecks via systemd for podman In-Reply-To: <8557589b0bbcbefb248243f0143595b9df1635f0.camel@redhat.com> References: <1543537268.4569.20.camel@redhat.com> <8557589b0bbcbefb248243f0143595b9df1635f0.camel@redhat.com> Message-ID: <1543610290.3758.6.camel@redhat.com> On Fri, 2018-11-30 at 08:13 -0500, Dan Prince wrote: > On Thu, 2018-11-29 at 17:21 -0700, Jill Rouleau wrote: > > > > The healthchecks currently in use in tripleo depend on the the > > docker > > healthcheck implementation, so podman/oci containers will not expose > > them.  The /openstack/healthcheck script is still available in the > > images, we just need a way to run the checks and expose the result. > > > > https://review.openstack.org/#/c/620372/ proposes having paunch > > write > > out a $service-healthcheck systemd unit and corresponding timer. > With Docker our health checks weren't used for anything other than > information if I recall. Is the idea here that you would use systemd > to > obtain the healthcheck status for any given service? And then > monitoring tools could call that periodically as a crude means of > obtaining the status of each service? Right, for now it's just to maintain the functionality of providing a means to run the check on a schedule and see the check output without having to rewrite the healthchecks, extend podman/varlink, or build significant new monitoring interfaces. > > Or is the intent here to go a step further and have systemd take some > kind of action if things are healthy like restarting the service. It's an option we could do in the future, by using systemd's OnFailure=$do_something, but beyond the scope of this initial patch. > > Dan > > > > > > > Interested in what folks think about the approach. > > > > -Jill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From smooney at redhat.com Fri Nov 30 20:57:41 2018 From: smooney at redhat.com (Sean Mooney) Date: Fri, 30 Nov 2018 20:57:41 +0000 Subject: [dev] [os-vif][nova][neutron][kuryr] os-vif serialisation, persistence and version compatiablity moving to v2.0 Message-ID: Hi I wanted to raise the topic of os-vif, its public api what client are allowed to do and how that related to serialisation, persistence of os-vif objects and version compatibility. sorry this is a bit of a long mail so here is a TL;DR and I have separated the mail into a background and future section. - we are planning to refine our data model in os-vf for hardware offloads. https://review.openstack.org/#/c/607610/ - we have been talking on and off about using os-vif on for nova neutron port binding and negotiation. to do that we will need to support serialisation in the future. - there are some uses of os-vif in kuryr-kubenetes that are currently out of contract that we would like to correct as they may break in the future. https://github.com/openstack/kuryr-kubernetes/blob/master/kuryr_kubernetes/objects/vif.py - what would we like to see in an os-vif 2.0 background ========== Before I get to the topic of os-vif I wanted to take an aside to set the basis of how I wanted to frame the topic. So in C++ land, there is an international standard that defines the language and the standard library for the C++ language. one of the stipulations of that standard is that users of the standard library are allowed to construct types defined by the standard library and you can call functions and methods defined by the library. C++ has different semantics then python so the implication of the statement you can call functions may not be apparent. In C++ it is technically undefined behaviour to take the address of a standard library function you may only call it. This allows the library author to implement it as a macro,lambda, function, function object or any other callable. So, in other words, there is a clear delineation between the public API and host that API is implemented. Bringing this back to os-vif we also have a finite public API and seperate internal implementation and I want to talk about internal changes that may affect observable features from the client perspective. specifically things that client can depend on and things they cannot. first of all the public api of os-vif is defined by https://github.com/openstack/os-vif/blob/master/os_vif/plugin.py this module defined the base class of all plugins and is the only class a plugin must inherit from and the only class defined in os-vif that a plugin or client of os-vif may inherit from outside of the exception classes defined in https://github.com/openstack/os-vif/blob/master/os_vif/exception.py. the second part of os-vif public api is a collection of data structures defined in https://github.com/openstack/os-vif/tree/master/os_vif/objects that clients are expected to _construct_ and plugins may _read_ from. I highlight construct and read as that is the extent to which we currently promise to clients or plugins. specifically today our version compatibility for objects is partially enabled by our use of oslo versioned objects. since os-vif objects are OVOs they have additional methods such as obj_to_primitive and obj_from_primitive that exist but that are _not_ part of the public api. Because serialisation (out side of serialisation via privsep) and persistence of os-vif longer then the lifetime of a function call, is not today part of the supported use cases of os-vif, that has enabled us to be less strict with version compatible then we would have to be If we supported those features. For example, we have in general added obj_make_compatible methods to objects when we modify os-vif objects https://github.com/openstack/os-vif/blob/master/os_vif/objects/vif.py#L120-L142 but we have often discussed should we add these functions as there are no current uses. future ====== That brings me to the topic of how os-vif is used in kuryr and how we would like to use it in neutron in the future. Part of the reason we do not allow clients to extend VIF objects is to ensure that os-vif plugins are not required on controller nodes and so we can control the set of vocabulary types that are exchanged and version them. To help us move to passing os-vif object via the api we need to remove the out of tree vif types that in use in kuryr and move them to os-vif. https://github.com/openstack/kuryr-kubernetes/blob/master/kuryr_kubernetes/objects/vif.py#L47-L82 we had mentioned this 2 or 3 releases ago but the change that prompted this email was https://github.com/openstack/kuryr-kubernetes/commit/7cc187806b42fee5ea660f86d33ad2f59b009754 i would like to know how kuryr-kubernetes is currently using the serialised os-vif objects. - are they being stored? - to disk - in a db - in etcd - are they bining sent to other services - are how are you serialising them. - obj_to_primitive - other - are you depending on obj_make_compatible - how can we help you not use them until we actually support this use case. In the future, we will support serialising os-vif object but the topic of should we use ovo has been raised. Initially, we had planned to serialise os-vif objects by calling obj_to_primitive and then passing that to oslo.serialsiation json utils. For python client, this makes it relatively trivial to serialise and deserialise the objects when calling into neutron but it has a disadvantage in that the format of the payload crated is specific to OpenStack, it is very verbose and it is not the most friendly format for human consumption. The other options that have come up in the past few months have been removing OVOs and validating with json schema or more recently replacing OVOs with protobufs. now we won't be doing either in the stein cycle but we had considered flattening our data models once https://review.openstack.org/#/c/607610/ is implemented and removing some unused filed as part of a 2.0 release in preparation for future neutron integration in Train. To that end, I would like to start the discussion about what we would want from a 2.0 release if and when we create one, how we can better docuemnt and enformce our public api/ supported usage patterens and are there any other users of os-vif outside of nova and kuryr today. regards sean. From mriedemos at gmail.com Fri Nov 30 21:27:27 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Fri, 30 Nov 2018 15:27:27 -0600 Subject: [dev][nova] Yay Friday gate regressions! Message-ID: <07708c7b-5b34-f5ab-1f22-dfc8f1d75fc0@gmail.com> Just FYI there are a couple of regressions hitting nova unit and functional test jobs right now: https://bugs.launchpad.net/nova/+bug/1806123 ^ Is likely due to mocking a global for the new I/O concurrency semaphore stuff in the libvirt driver. I'm not sure what we should do about that one. During the code review I suggested writing a fixture which would essentially maintain the context manager (so we have __enter__ and __exit__) but just make it a noop, but we still want to make sure it's called in places where it's used. https://bugs.launchpad.net/nova/+bug/1806126 ^ Is a bit hairier since I'm seeing both weird, potentially global mock, failures and also timeouts, also potentially because of mocking globals. Since there is no functional code change tied to that one yet (it's still being reviewed, this was a recreate test change only), I have proposed a revert to try and stem the bleeding unless someone (mdbooth?) can root cause and fix it faster. Happy rechecking! -- Thanks, Matt From smooney at redhat.com Fri Nov 30 21:28:39 2018 From: smooney at redhat.com (Sean Mooney) Date: Fri, 30 Nov 2018 21:28:39 +0000 Subject: [openstack-dev] [Openstack-operators] [nova] Would an api option to create an instance without powering on be useful? In-Reply-To: References: Message-ID: <58ed5a65770e77128b2b14a819ec37a4dc8401d8.camel@redhat.com> On Fri, 2018-11-30 at 09:40 -0500, Mohammed Naser wrote: > > > On Fri, Nov 30, 2018 at 7:07 AM Matthew Booth wrote: > > I have a request to do $SUBJECT in relation to a V2V workflow. The use > > case here is conversion of a VM/Physical which was previously powered > > off. We want to move its data, but we don't want to be powering on > > stuff which wasn't previously on. > > > > This would involve an api change, and a hopefully very small change in > > drivers to support it. Technically I don't see it as an issue. > > > > However, is it a change we'd be willing to accept? Is there any good > > reason not to do this? Are there any less esoteric workflows which > > might use this feature? > > If you upload an image of said VM which you don't boot, you'd really be > accomplishing the same thing, no? > > Unless you want to be in a state where you want the VM to be there but > sitting in SHUTOFF state i think the intent was to have a vm ready to go with ips/ports, volumes exctra all created so you can quickly start it when needed. if that is the case another alternitive which might be more public cloud freidly form a wallet perspecitve would be the ablity to create a shelved isntace. that way all the ports ectra would be logically created but it would not be consumeing any compute resources. > > > Matt > > -- > > Matthew Booth > > Red Hat OpenStack Engineer, Compute DFG > > > > Phone: +442070094448 (UK) > > > > _______________________________________________ > > OpenStack-operators mailing list > > OpenStack-operators at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From smooney at redhat.com Fri Nov 30 21:28:39 2018 From: smooney at redhat.com (Sean Mooney) Date: Fri, 30 Nov 2018 21:28:39 +0000 Subject: [Openstack-operators] [openstack-dev] [nova] Would an api option to create an instance without powering on be useful? In-Reply-To: References: Message-ID: <58ed5a65770e77128b2b14a819ec37a4dc8401d8.camel@redhat.com> On Fri, 2018-11-30 at 09:40 -0500, Mohammed Naser wrote: > > > On Fri, Nov 30, 2018 at 7:07 AM Matthew Booth wrote: > > I have a request to do $SUBJECT in relation to a V2V workflow. The use > > case here is conversion of a VM/Physical which was previously powered > > off. We want to move its data, but we don't want to be powering on > > stuff which wasn't previously on. > > > > This would involve an api change, and a hopefully very small change in > > drivers to support it. Technically I don't see it as an issue. > > > > However, is it a change we'd be willing to accept? Is there any good > > reason not to do this? Are there any less esoteric workflows which > > might use this feature? > > If you upload an image of said VM which you don't boot, you'd really be > accomplishing the same thing, no? > > Unless you want to be in a state where you want the VM to be there but > sitting in SHUTOFF state i think the intent was to have a vm ready to go with ips/ports, volumes exctra all created so you can quickly start it when needed. if that is the case another alternitive which might be more public cloud freidly form a wallet perspecitve would be the ablity to create a shelved isntace. that way all the ports ectra would be logically created but it would not be consumeing any compute resources. > > > Matt > > -- > > Matthew Booth > > Red Hat OpenStack Engineer, Compute DFG > > > > Phone: +442070094448 (UK) > > > > _______________________________________________ > > OpenStack-operators mailing list > > OpenStack-operators at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From mike.carden at gmail.com Fri Nov 30 22:52:13 2018 From: mike.carden at gmail.com (Mike Carden) Date: Sat, 1 Dec 2018 09:52:13 +1100 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> Message-ID: > > > Have you set the placement_randomize_allocation_candidates CONF option > and are still seeing the packing behaviour? > > No I haven't. Where would be the place to do that? In a nova.conf somewhere that the nova-scheduler containers on the controller hosts could pick it up? Just about to deploy for realz with about forty x86 compute nodes, so it would be really nice to sort this first. :) -- MC -------------- next part -------------- An HTML attachment was scrubbed... URL: From duc.openstack at gmail.com Fri Nov 30 23:59:04 2018 From: duc.openstack at gmail.com (Duc Truong) Date: Fri, 30 Nov 2018 15:59:04 -0800 Subject: [senlin] New meeting time for odd weeks Message-ID: As discussed in our last Senlin meeting [1], I would like to propose holding the weekly meeting during odd weeks at a time that is more convenient for US and Europe. The proposal is to have the meeting at 19:00 UTC (11am PST) for odd weeks, while the meeting time for even weeks stays at the current time of 5:30 UTC. If accepted, the meeting times for upcoming weeks would be as follows: - Thursday, December 6, 2018 at 19:00:00 UTC - Friday, December 14, 2018 at 05:30:00 UTC - Thursday, December 20, 2018 at 19:00:00 UTC ... Please reply with any feedback. Regards, Duc (dtruong) [1] http://eavesdrop.openstack.org/meetings/senlin/2018/senlin.2018-11-30-05.30.log.html#l-44