From mikal at stillhq.com Sat Dec 1 11:17:27 2018 From: mikal at stillhq.com (Michael Still) Date: Sat, 1 Dec 2018 22:17:27 +1100 Subject: [dev][nova] Yay Friday gate regressions! In-Reply-To: <07708c7b-5b34-f5ab-1f22-dfc8f1d75fc0@gmail.com> References: <07708c7b-5b34-f5ab-1f22-dfc8f1d75fc0@gmail.com> Message-ID: The first one of those was trivial (although I am confused as to why it didn't fail for the test run where the patch was proposed, I can't see an obvious race condition). I have proposed a fix at https://review.openstack.org/#/c/621346/ . Michael On Sat, Dec 1, 2018 at 8:30 AM Matt Riedemann wrote: > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ervikrant06 at gmail.com Sun Dec 2 04:03:56 2018 From: ervikrant06 at gmail.com (Vikrant Aggarwal) Date: Sun, 2 Dec 2018 09:33:56 +0530 Subject: [openstack-dev] [kuryr] can we start kuryr libnetwork in container inside the nova VM. In-Reply-To: <7b585278013291fda1d55b5d74965b26d317e637.camel@redhat.com> References: <7b585278013291fda1d55b5d74965b26d317e637.camel@redhat.com> Message-ID: Thanks Michal. Yes, my scenario is same which you mentioned. But I don't want to use COE atm. So. the OVS and neutron-agent running inside the VM will be communicating with compute node neutron agent? Thanks & Regards, Vikrant Aggarwal On Fri, Nov 30, 2018 at 9:31 PM Michał Dulko wrote: > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juliaashleykreger at gmail.com Sun Dec 2 14:43:46 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Sun, 2 Dec 2018 06:43:46 -0800 Subject: Proposing KaiFeng Wang for ironic-core Message-ID: I'd like to propose adding KaiFeng to the ironic-core reviewer group. Previously, we had granted KaiFeng rights on ironic-inspector-core and I personally think they have done a great job there. Kaifeng has also been reviewing other repositories in ironic's scope[1]. Their reviews and feedback have been insightful and meaningful. They have also been very active[2] at reviewing which is an asset for any project. I believe they will be an awesome addition to the team. -Julia [1]: http://stackalytics.com/?module=ironic-group&user_id=kaifeng [2]: http://stackalytics.com/report/contribution/ironic-group/90 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ichihara.hirofumi at gmail.com Sun Dec 2 14:08:25 2018 From: ichihara.hirofumi at gmail.com (Hirofumi Ichihara) Date: Sun, 2 Dec 2018 23:08:25 +0900 Subject: [openstack-dev] Stepping down from Neutron core team Message-ID: Hi all, I’m stepping down from the core team because my role changed and I cannot have responsibilities of neutron core. My start of neutron was 5 years ago. I had many good experiences from neutron team. Today neutron is great project. Neutron gets new reviewers, contributors and, users. Keep on being a great community. Thanks, Hirofumi -------------- 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 Sun Dec 2 20:57:30 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Sun, 2 Dec 2018 14:57:30 -0600 Subject: [openstack-dev] Stepping down from Neutron core team In-Reply-To: References: Message-ID: Hi Hirofumi, Thanks for your contributions to the project over these years. You will be missed. We also wish the best in your future endeavors. Best regards Miguel On Sun, Dec 2, 2018 at 8:11 AM Hirofumi Ichihara < ichihara.hirofumi at gmail.com> wrote: > Hi all, > > > I’m stepping down from the core team because my role changed and I cannot > have responsibilities of neutron core. > > > My start of neutron was 5 years ago. I had many good experiences from > neutron team. > > Today neutron is great project. Neutron gets new reviewers, contributors > and, users. > > Keep on being a great community. > > > Thanks, > > Hirofumi > __________________________________________________________________________ > 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 gmann at ghanshyammann.com Mon Dec 3 01:24:11 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 03 Dec 2018 10:24:11 +0900 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: <16771aa6641.f7035e7c28699.479407897586326349@ghanshyammann.com> ---- On Fri, 30 Nov 2018 19:05:36 +0900 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. > > Unless someone objects, I'll push the related changes where needed. > Thanks for the clarification ! +1. Those looks good. Thanks. -gmann > > -- > Thierry Carrez (ttx) > > From gmann at ghanshyammann.com Mon Dec 3 01:58:51 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 03 Dec 2018 10:58:51 +0900 Subject: [Interop-wg] [dev] [cinder] [qa] Strict Validation for Volume API using JSON Schema In-Reply-To: <8337FB0D-81D3-4E6C-9039-47BD749C3862@vmware.com> References: <16760426d56.ef4c345622903.2195899647060980382@ghanshyammann.com> <29d271ff-d5a7-2a28-53c1-3be7b868ad20@gmail.com> <8337FB0D-81D3-4E6C-9039-47BD749C3862@vmware.com> Message-ID: <16771ca2086.c57557fb28769.9145911937981210050@ghanshyammann.com> ---- On Sat, 01 Dec 2018 02:58:45 +0900 Mark Voelker wrote ---- > > > 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. =) Thanks Mark for response. I think point 1 is important, it is good to get the list of clouds or failure due to this this strict validation change. And accordingly, we can wait on Tempest side to merge those changes for this cycle (but personally I do not want to delay that if everything is fine), so that we can avoid the immediate failure of interop program. -gmann > > 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 lijie at unitedstack.com Mon Dec 3 02:02:05 2018 From: lijie at unitedstack.com (=?utf-8?B?UmFtYm8=?=) Date: Mon, 3 Dec 2018 10:02:05 +0800 Subject: [openstack-dev] [nova] about notification in nova Message-ID: Hi, all： I have a question about the notification in nova, that is the actual operator is different from the operator was record in panko. Such as the delete action, we create the VM as user1, and we delete the VM as user2， but the operator is user1 who delete the VM in panko event, not the actual operator user2. 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 dangtrinhnt at gmail.com Mon Dec 3 02:06:28 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Mon, 3 Dec 2018 11:06:28 +0900 Subject: [Searchlight] Meeting today at 13:30 UTC Message-ID: Hi team, We will have the team meeting today at 13:30 UTC on #openstack-searchlight. Please join me and the others! Bests, -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From zbitter at redhat.com Mon Dec 3 03:24:42 2018 From: zbitter at redhat.com (Zane Bitter) Date: Mon, 3 Dec 2018 16:24:42 +1300 Subject: [forum][tc] Summary of the Vision for OpenStack Clouds session Message-ID: <7c223ec3-5deb-718f-573f-98903a40089c@redhat.com> During the Berlin summit there were a couple of discussions about the Vision for OpenStack Clouds, culminating in the initial version being merged. You can find it published here: https://governance.openstack.org/tc/reference/technical-vision.html During the joint leadership meeting on the Monday before the Summit, the TC presented the latest draft of the vision to the Foundation Board.[1] All of the feedback we received from board members was positive. Paper copies of the draft were available at the meeting, and it was also posted to the foundation mailing list afterwards.[2] This was followed on Thursday by a Forum session to discuss the next steps: https://etherpad.openstack.org/p/BER-cloud-vision With the review having already accumulated the required number of votes from the TC and nobody objecting, we determined that the next step should be to approve the draft and publish it. This is intended to be a living document, so in that spirit we'll continue to make ongoing tweaks based on feedback. A number of evolutionary improvements have been suggested (my summary): * (mordred) The SDK supports a use case where each Region in a cloud has its own Keystone endpoint, with the data synced behind the scenes. The definition of 'region' contained in the vision does not cover this. ayoung will submit a patch to update the wording. * (gmann) We could mention something about feature discovery in the section on OpenStack-specific considerations, to help ensure interoperability. * (fungi) We could also more explicitly declare that leaking implementation details into the API and beyond is something we're trying to avoid for interoperability reasons. fungi will submit a patch to do that. Doug also suggested that we should try to get this document incorporated into the main openstack.org website somehow, since the governance site is not especially visible even within the technical community and might as well not exist for those outside it. There are technical challenges with keeping a non-static document in sync to openstack.org, and publishing a forward-looking document like this verbatim to a wider audience might risk creating some confusion. However, it would be a shame to squander this opportunity for the technical community to collaborate more with the Foundation's marketing team in how we portray the goals of the OpenStack project. I will contact Lauren Sell on behalf of the TC to start a discussion on how we can make the best use of the document. [1] https://docs.google.com/presentation/d/1wcG7InY2A5y67dt5lC14CI1gQHGZ3db8-yshOu-STk8/edit?usp=sharing#slide=id.g46a6072f4a_0_276 [2] http://lists.openstack.org/pipermail/foundation/2018-November/002657.html From shiina.hironori at fujitsu.com Mon Dec 3 06:09:20 2018 From: shiina.hironori at fujitsu.com (shiina.hironori at fujitsu.com) Date: Mon, 3 Dec 2018 06:09:20 +0000 Subject: Proposing KaiFeng Wang for ironic-core In-Reply-To: References: Message-ID: +1 --- Hironori > -----Original Message----- > From: Julia Kreger [mailto:juliaashleykreger at gmail.com] > Sent: Sunday, December 2, 2018 11:44 PM > To: openstack-discuss at lists.openstack.org > Subject: Proposing KaiFeng Wang for ironic-core > > I'd like to propose adding KaiFeng to the ironic-core reviewer group. Previously, we had granted KaiFeng rights > on ironic-inspector-core and I personally think they have done a great job there. > > Kaifeng has also been reviewing other repositories in ironic's scope[1]. Their reviews and feedback have been > insightful and meaningful. They have also been very active[2] at reviewing which is an asset for any project. > > I believe they will be an awesome addition to the team. > > -Julia > > [1]: http://stackalytics.com/?module=ironic-group&user_id=kaifeng > > [2]: http://stackalytics.com/report/contribution/ironic-group/90 > From skaplons at redhat.com Mon Dec 3 08:09:48 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Mon, 3 Dec 2018 09:09:48 +0100 Subject: [openstack-dev] Stepping down from Neutron core team In-Reply-To: References: Message-ID: <1588BF61-D40E-4CD4-BB2E-BBDEEC8B5C75@redhat.com> Hi, Thanks for all Your work in Neutron and good luck in Your new role. — Slawek Kaplonski Senior software engineer Red Hat > Wiadomość napisana przez Hirofumi Ichihara w dniu 02.12.2018, o godz. 15:08: > > Hi all, > > I’m stepping down from the core team because my role changed and I cannot have responsibilities of neutron core. > > My start of neutron was 5 years ago. I had many good experiences from neutron team. > Today neutron is great project. Neutron gets new reviewers, contributors and, users. > Keep on being a great community. > > Thanks, > Hirofumi > __________________________________________________________________________ > 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 bdobreli at redhat.com Mon Dec 3 09:34:50 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Mon, 3 Dec 2018 10:34:50 +0100 Subject: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes In-Reply-To: <1A3C52DFCD06494D8528644858247BF01C24B507@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> <7d2fce52ca8bb5156b753a95cbb9e2df7ad741c8.camel@redhat.com> <1A3C52DFCD06494D8528644858247BF01C24B507@EX10MBOX03.pnnl.gov> Message-ID: Hi Kevin. Puppet not only creates config files but also executes a service dependent steps, like db sync, so neither '[base] -> [puppet]' nor '[base] -> [service]' would not be enough on its own. That requires some services specific code to be included into *config* images as well. PS. There is a related spec [0] created by Dan, please take a look and propose you feedback [0] https://review.openstack.org/620062 On 11/30/18 6:48 PM, Fox, Kevin M wrote: > 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 > -- Best regards, Bogdan Dobrelya, Irc #bogdando From bdobreli at redhat.com Mon Dec 3 09:37:57 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Mon, 3 Dec 2018 10:37:57 +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> <7d2fce52ca8bb5156b753a95cbb9e2df7ad741c8.camel@redhat.com> <1A3C52DFCD06494D8528644858247BF01C24B507@EX10MBOX03.pnnl.gov> Message-ID: On 12/3/18 10:34 AM, Bogdan Dobrelya wrote: > Hi Kevin. > Puppet not only creates config files but also executes a service > dependent steps, like db sync, so neither '[base] -> [puppet]' nor > '[base] -> [service]' would not be enough on its own. That requires some > services specific code to be included into *config* images as well. > > PS. There is a related spec [0] created by Dan, please take a look and > propose you feedback > > [0] https://review.openstack.org/620062 I'm terribly sorry, but that's a corrected link [0] to that spec. [0] https://review.openstack.org/620909 > > On 11/30/18 6:48 PM, Fox, Kevin M wrote: >> 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 >> > > -- Best regards, Bogdan Dobrelya, Irc #bogdando From tenobreg at redhat.com Mon Dec 3 12:06:46 2018 From: tenobreg at redhat.com (Telles Nobrega) Date: Mon, 3 Dec 2018 09:06:46 -0300 Subject: [openstack-dev][sahara] Sahara APIv2 Worklist Message-ID: Hi Saharans, One of the main focus of this cycle, and it has been for a while now, is the work on APIv2. During the last Sahara meeting we came up with a list of the reamining work left so we can release APIv2 as stable this cycle. I created a worklist[1] on storyboard so we can more easily track the progress of the few remaining tasks. Thanks all, [1] https://storyboard.openstack.org/#!/worklist/533 -- TELLES NOBREGA SOFTWARE ENGINEER Red Hat Brasil Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo tenobreg at redhat.com TRIED. TESTED. TRUSTED. Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil pelo Great Place to Work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ranjankrchaubey at gmail.com Mon Dec 3 01:57:25 2018 From: ranjankrchaubey at gmail.com (Ranjan Krchaubey) Date: Mon, 3 Dec 2018 07:27:25 +0530 Subject: [openstack-dev] Stepping down from Neutron core team In-Reply-To: References: Message-ID: <1778B743-99D8-4735-B057-6C19A457BF05@gmail.com> Hi Team , I am getting error of Http 500 server not fullfill request by id please help me how to fix Thanks & Regards Ranjan Kumar Mob: 9284158762 > On 03-Dec-2018, at 2:27 AM, Miguel Lavalle wrote: > > Hi Hirofumi, > > Thanks for your contributions to the project over these years. You will be missed. We also wish the best in your future endeavors. > > Best regards > > Miguel > >> On Sun, Dec 2, 2018 at 8:11 AM Hirofumi Ichihara wrote: >> Hi all, >> >> I’m stepping down from the core team because my role changed and I cannot have responsibilities of neutron core. >> >> My start of neutron was 5 years ago. I had many good experiences from neutron team. >> Today neutron is great project. Neutron gets new reviewers, contributors and, users. >> Keep on being a great community. >> >> Thanks, >> Hirofumi >> __________________________________________________________________________ >> 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 zhengzhenyulixi at gmail.com Mon Dec 3 02:31:02 2018 From: zhengzhenyulixi at gmail.com (Zhenyu Zheng) Date: Mon, 3 Dec 2018 10:31:02 +0800 Subject: [openstack-dev] [nova] about notification in nova In-Reply-To: References: Message-ID: Hi, Are you using versioned notification? If you are using versioned nofitication, you should get an ``action_initiator_user`` and an ``action_initiator_project`` indicating who initiated this action, we had them since I649d8a27baa8840bc1bb567fef027c749c663432 . If you are not using versioned notification, then versioned notification will be recommanded. Thanks On Mon, Dec 3, 2018 at 10:06 AM Rambo wrote: > Hi, all： > I have a question about the notification in nova, that is the > actual operator is different from the operator was record in panko. Such > as the delete action, we create the VM as user1, and we delete the VM as > user2， but the operator is user1 who delete the VM in panko event, not the > actual operator user2. > Can you tell me more about this?Thank you very much. > > > > > > > > > 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 -------------- 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 ranjankrchaubey at gmail.com Mon Dec 3 02:40:06 2018 From: ranjankrchaubey at gmail.com (Ranjan Krchaubey) Date: Mon, 3 Dec 2018 08:10:06 +0530 Subject: [openstack-dev] [nova] about notification in nova In-Reply-To: References: Message-ID: <07726B1E-643C-40CF-A7E9-D906B909699F@gmail.com> This regarding keystone ? Thanks & Regards Ranjan Kumar Mob: 9284158762 > On 03-Dec-2018, at 8:01 AM, Zhenyu Zheng wrote: > > Hi, > > Are you using versioned notification? If you are using versioned nofitication, you should get an ``action_initiator_user`` and an ``action_initiator_project`` > indicating who initiated this action, we had them since I649d8a27baa8840bc1bb567fef027c749c663432 . If you are not using versioned notification, then > versioned notification will be recommanded. > > Thanks > >> On Mon, Dec 3, 2018 at 10:06 AM Rambo wrote: >> Hi, all： >> I have a question about the notification in nova, that is the actual operator is different from the operator was record in panko. Such as the delete action, we create the VM as user1, and we delete the VM as user2， but the operator is user1 who delete the VM in panko event, not the actual operator user2. >> Can you tell me more about this?Thank you very much. >> >> >> >> >> >> >> >> >> 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 ranjankrchaubey at gmail.com Mon Dec 3 13:06:06 2018 From: ranjankrchaubey at gmail.com (Ranjan Krchaubey) Date: Mon, 3 Dec 2018 18:36:06 +0530 Subject: [openstack-dev] Stepping down from Neutron core team In-Reply-To: <1588BF61-D40E-4CD4-BB2E-BBDEEC8B5C75@redhat.com> References: <1588BF61-D40E-4CD4-BB2E-BBDEEC8B5C75@redhat.com> Message-ID: Hi all, Can any one help me to resvolve error 111 on keystone Thanks & Regards Ranjan Kumar Mob: 9284158762 > On 03-Dec-2018, at 1:39 PM, Slawomir Kaplonski wrote: > > Hi, > > Thanks for all Your work in Neutron and good luck in Your new role. > > — > Slawek Kaplonski > Senior software engineer > Red Hat > >> Wiadomość napisana przez Hirofumi Ichihara w dniu 02.12.2018, o godz. 15:08: >> >> Hi all, >> >> I’m stepping down from the core team because my role changed and I cannot have responsibilities of neutron core. >> >> My start of neutron was 5 years ago. I had many good experiences from neutron team. >> Today neutron is great project. Neutron gets new reviewers, contributors and, users. >> Keep on being a great community. >> >> Thanks, >> Hirofumi >> __________________________________________________________________________ >> 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 jim at jimrollenhagen.com Mon Dec 3 13:19:38 2018 From: jim at jimrollenhagen.com (Jim Rollenhagen) Date: Mon, 3 Dec 2018 08:19:38 -0500 Subject: Proposing KaiFeng Wang for ironic-core In-Reply-To: References: Message-ID: On Sun, Dec 2, 2018 at 9:46 AM Julia Kreger wrote: > I'd like to propose adding KaiFeng to the ironic-core reviewer group. > Previously, we had granted KaiFeng rights on ironic-inspector-core and I > personally think they have done a great job there. > > Kaifeng has also been reviewing other repositories in ironic's scope[1]. > Their reviews and feedback have been insightful and meaningful. They have > also been very active[2] at reviewing which is an asset for any project. > > I believe they will be an awesome addition to the team. > +2! // jim > > -Julia > > [1]: http://stackalytics.com/?module=ironic-group&user_id=kaifeng > [2]: http://stackalytics.com/report/contribution/ironic-group/90 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangtrinhnt at gmail.com Mon Dec 3 13:24:28 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Mon, 3 Dec 2018 22:24:28 +0900 Subject: [Searchlight] Cancel meeting today Message-ID: Hi team, Everybody is busy today so we will cancel the meeting today. Please ping me on the channel #openstack-searchlight. Bests, -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Mon Dec 3 13:25:51 2018 From: mnaser at vexxhost.com (Mohammed Naser) Date: Mon, 3 Dec 2018 08:25:51 -0500 Subject: [openstack-ansible] Evaluating meeting schedule + method In-Reply-To: References: <1913981.aYPTVNe1F8@whitebase.usersys.redhat.com> <8c59e2dbcd07bda4d4e12952e5d5af0bf8c839f2.camel@evrard.me> Message-ID: On Wed, Nov 28, 2018 at 10:55 AM Michael McCune wrote: > 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/ > > Unfortunately, I haven't heard a lot of the OpenStack Ansible side of things however I'm very happy to hear about what's going on with other projects and how to pick ways to manage our meetings. The first step that I'd like to maybe suggest is going to an office hours model? I'm still not sure how that will increase our engagement in meetings. -- 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 jaypipes at gmail.com Mon Dec 3 13:59:13 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Mon, 3 Dec 2018 08:59:13 -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 05:52 PM, Mike Carden wrote: > > 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. :) Presuming you are deploying Rocky or Queens, It goes in the nova.conf file under the [placement] section: randomize_allocation_candidates = true The nova.conf file should be the one used by nova-scheduler. Best, -jay From gryf73 at gmail.com Mon Dec 3 14:08:19 2018 From: gryf73 at gmail.com (Roman Dobosz) Date: Mon, 3 Dec 2018 15:08:19 +0100 Subject: [nova][ops] Migrating instances with old extra specs info. Message-ID: Hi, We have an issue regarding live migrate old instances. On our infrastructure based on Newton, we had not well named our aggregation groups and we decided to completely change the naming conventions. We are using extra specs/metadata in flavors/aggregates and AggregateInstanceExtraSpecsFilter to select the set of hosts. After changing one of the key (lets call it 'kind') of extra spec/metadata to the new value, we are able to create new instances, but unable to live-migrate old one. This is because of stored flavor extra specs in instance_extra, which still holds the old value for the 'kind' key, and make the aggregate filter fail to match the hosts. In our opinion, it should be able to live-migrate such instance, since only the flavor metadata has changed, while other fields doesn't (vcpus, memory, disk). Is it a bug? Or maybe it is possible to change the instance flavor extra spec? -- Cheers, Roman Dobosz From nate.johnston at redhat.com Mon Dec 3 14:15:06 2018 From: nate.johnston at redhat.com (Nate Johnston) Date: Mon, 3 Dec 2018 09:15:06 -0500 Subject: [openstack-dev] Stepping down from Neutron core team In-Reply-To: References: Message-ID: <20181203141506.usaxv36gz56f4vic@bishop> On Sun, Dec 02, 2018 at 11:08:25PM +0900, Hirofumi Ichihara wrote: > I’m stepping down from the core team because my role changed and I cannot > have responsibilities of neutron core. Thank you very much for all of the insightful reviews over the years. Good luck on your next adventure! Nate Johnston (njohnston) __________________________________________________________________________ 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 Dec 3 14:53:59 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 03 Dec 2018 09:53:59 -0500 Subject: [goal][python3] week R-18 update Message-ID: This is the weekly update for the "Run under Python 3 by default" goal (https://governance.openstack.org/tc/goals/stein/python3-first.html). I've missed sending this email for a few weeks again, due to the Summit, holiday, and then illness. == Ongoing and Completed Work == We're still making good progress, but several teams have a ways to go on the tox defaults patches and 3.6 unit tests. Please prioritize these reviews so we can move on to the more complicated parts of the goal! +---------------------+--------------+---------+----------+---------+------------+-------+--------------------+ | Team | tox defaults | Docs | 3.6 unit | Failing | Unreviewed | Total | Champion | +---------------------+--------------+---------+----------+---------+------------+-------+--------------------+ | adjutant | 1/ 1 | - | + | 0 | 1 | 2 | Doug Hellmann | | barbican | + | 1/ 3 | + | 1 | 1 | 7 | Doug Hellmann | | blazar | + | + | + | 0 | 0 | 9 | Nguyen Hai | | Chef OpenStack | + | - | - | 0 | 0 | 2 | Doug Hellmann | | cinder | + | + | + | 0 | 0 | 11 | Doug Hellmann | | cloudkitty | + | + | + | 0 | 0 | 9 | Doug Hellmann | | congress | + | + | + | 0 | 0 | 9 | Nguyen Hai | | cyborg | + | + | + | 0 | 0 | 7 | Nguyen Hai | | designate | + | + | + | 0 | 0 | 9 | Nguyen Hai | | Documentation | + | + | + | 0 | 0 | 10 | Doug Hellmann | | ec2-api | + | + | + | 0 | 0 | 7 | | | freezer | + | + | + | 0 | 0 | 11 | | | glance | + | + | + | 0 | 0 | 10 | Nguyen Hai | | heat | 2/ 8 | + | 1/ 7 | 1 | 0 | 21 | Doug Hellmann | | horizon | + | + | + | 0 | 0 | 34 | Nguyen Hai | | I18n | + | - | - | 0 | 0 | 1 | Doug Hellmann | | InteropWG | 2/ 3 | + | 1/ 3 | 1 | 1 | 9 | Doug Hellmann | | ironic | 1/ 10 | + | + | 0 | 0 | 35 | Doug Hellmann | | karbor | + | + | + | 0 | 0 | 7 | Nguyen Hai | | keystone | + | + | + | 0 | 0 | 18 | Doug Hellmann | | kolla | + | + | + | 0 | 0 | 5 | | | kuryr | + | + | + | 0 | 0 | 9 | Doug Hellmann | | magnum | 2/ 5 | + | + | 0 | 1 | 10 | | | manila | + | + | + | 0 | 0 | 13 | Goutham Pacha Ravi | | masakari | 2/ 5 | + | - | 0 | 2 | 6 | Nguyen Hai | | mistral | + | + | + | 0 | 0 | 13 | Nguyen Hai | | monasca | 1/ 17 | + | + | 0 | 1 | 34 | Doug Hellmann | | murano | + | + | + | 0 | 0 | 14 | | | neutron | 5/ 19 | 1/ 14 | 1/ 13 | 4 | 3 | 46 | Doug Hellmann | | nova | + | + | + | 0 | 0 | 14 | | | octavia | + | + | + | 0 | 0 | 12 | Nguyen Hai | | OpenStack Charms | 8/ 73 | - | - | 8 | 3 | 73 | Doug Hellmann | | OpenStack-Helm | + | + | - | 0 | 0 | 4 | | | OpenStackAnsible | + | + | - | 0 | 0 | 152 | | | OpenStackClient | + | + | + | 0 | 0 | 11 | | | OpenStackSDK | + | + | + | 0 | 0 | 10 | | | oslo | + | + | + | 0 | 0 | 63 | Doug Hellmann | | Packaging-rpm | + | + | + | 0 | 0 | 6 | Doug Hellmann | | PowerVMStackers | - | - | + | 0 | 0 | 3 | Doug Hellmann | | Puppet OpenStack | + | + | - | 0 | 0 | 44 | Doug Hellmann | | qinling | + | + | + | 0 | 0 | 6 | | | Quality Assurance | 3/ 11 | + | + | 0 | 2 | 32 | Doug Hellmann | | rally | 1/ 3 | + | - | 1 | 1 | 5 | Nguyen Hai | | Release Management | - | - | + | 0 | 0 | 1 | Doug Hellmann | | requirements | - | + | + | 0 | 0 | 2 | Doug Hellmann | | sahara | 1/ 6 | + | + | 0 | 0 | 13 | Doug Hellmann | | searchlight | + | + | + | 0 | 0 | 9 | Nguyen Hai | | senlin | + | + | + | 0 | 0 | 9 | Nguyen Hai | | SIGs | + | + | + | 0 | 0 | 13 | Doug Hellmann | | solum | + | + | + | 0 | 0 | 7 | Nguyen Hai | | storlets | + | + | + | 0 | 0 | 4 | | | swift | 2/ 3 | + | + | 1 | 1 | 6 | Nguyen Hai | | tacker | 1/ 3 | + | + | 0 | 1 | 8 | Nguyen Hai | | Technical Committee | + | - | + | 0 | 0 | 4 | Doug Hellmann | | Telemetry | 1/ 7 | + | + | 0 | 1 | 19 | Doug Hellmann | | tricircle | + | + | + | 0 | 0 | 5 | Nguyen Hai | | tripleo | 5/ 55 | + | + | 3 | 1 | 93 | Doug Hellmann | | trove | 1/ 5 | + | + | 0 | 0 | 11 | Doug Hellmann | | User Committee | 3/ 3 | + | - | 0 | 2 | 5 | Doug Hellmann | | vitrage | + | + | + | 0 | 0 | 9 | Nguyen Hai | | watcher | + | + | + | 0 | 0 | 10 | Nguyen Hai | | winstackers | + | + | + | 0 | 0 | 6 | | | zaqar | + | + | + | 0 | 0 | 8 | | | zun | + | + | + | 0 | 0 | 8 | Nguyen Hai | | | 43/ 61 | 55/ 57 | 52/ 55 | 20 | 22 | 1075 | | +---------------------+--------------+---------+----------+---------+------------+-------+--------------------+ == Next Steps == We need to to approve the patches proposed by the goal champions, and then to expand functional test coverage for python 3. PTLs, please document your team's status in the wiki as well: https://wiki.openstack.org/wiki/Python3 == How can you help? == 1. Choose a patch that has failing tests and help fix it. https://review.openstack.org/#/q/topic:python3-first+status:open+(+label:Verified-1+OR+label:Verified-2+) 2. Review the patches for the zuul changes. Keep in mind that some of those patches will be on the stable branches for projects. 3. Work on adding functional test jobs that run under Python 3. == How can you ask for help? == If you have any questions, please post them here to the openstack-dev list with the topic tag [python3] in the subject line. Posting questions to the mailing list will give the widest audience the chance to see the answers. We are using the #openstack-dev IRC channel for discussion as well, but I'm not sure how good our timezone coverage is so it's probably better to use the mailing list. == Reference Material == Goal description: https://governance.openstack.org/tc/goals/stein/python3-first.html Open patches needing reviews: https://review.openstack.org/#/q/topic:python3-first+is:open Storyboard: https://storyboard.openstack.org/#!/board/104 Zuul migration notes: https://etherpad.openstack.org/p/python3-first Zuul migration tracking: https://storyboard.openstack.org/#!/story/2002586 Python 3 Wiki page: https://wiki.openstack.org/wiki/Python3 -- Doug From jaypipes at gmail.com Mon Dec 3 15:07:18 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Mon, 3 Dec 2018 10:07:18 -0500 Subject: [nova][ops] Migrating instances with old extra specs info. In-Reply-To: References: Message-ID: On 12/03/2018 09:08 AM, Roman Dobosz wrote: > Hi, > > We have an issue regarding live migrate old instances. > > On our infrastructure based on Newton, we had not well named our > aggregation groups and we decided to completely change the naming > conventions. We are using extra specs/metadata in flavors/aggregates and > AggregateInstanceExtraSpecsFilter to select the set of hosts. > > After changing one of the key (lets call it 'kind') of extra > spec/metadata to the new value, we are able to create new instances, but > unable to live-migrate old one. This is because of stored flavor extra > specs in instance_extra, which still holds the old value for the 'kind' > key, and make the aggregate filter fail to match the hosts. > > In our opinion, it should be able to live-migrate such instance, since > only the flavor metadata has changed, while other fields doesn't (vcpus, > memory, disk). > > Is it a bug? Or maybe it is possible to change the instance flavor > extra spec? Not sure it's a bug, per-se... might just be something you need to manually change database records for, though. Sucks, since it's hacky, but not sure if it's something we should change in the API contract. Best, -jay From dangtrinhnt at gmail.com Mon Dec 3 15:28:30 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Tue, 4 Dec 2018 00:28:30 +0900 Subject: [Searchlight][Zuul] tox failed tests at zuul check only Message-ID: Hello, Currently, [1] fails tox py27 tests on Zuul check for just updating the log text. The tests are successful at local dev env. Just wondering there is any new change at Zuul CI? [1] https://review.openstack.org/#/c/619162/ Thanks, -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahm.jawad118 at gmail.com Mon Dec 3 14:42:37 2018 From: ahm.jawad118 at gmail.com (Jawad Ahmed) Date: Mon, 3 Dec 2018 15:42:37 +0100 Subject: [Openstack-operators] Spice screen in horizon Message-ID: Hi all, How can I fit spice screen*(vm console| black screen)* to horizon console. Please see the attachment.Also below messages ,keyboard input is insecure etc.If someone can suggest workaround to remove those messages. I ll appreciate any kind of suggestions.Thank you. -- Greetings, Jawad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2018-12-03 at 15.37.17.png Type: image/png Size: 145854 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 smooney at redhat.com Mon Dec 3 15:34:25 2018 From: smooney at redhat.com (Sean Mooney) Date: Mon, 03 Dec 2018 15:34:25 +0000 Subject: [nova][ops] Migrating instances with old extra specs info. In-Reply-To: References: Message-ID: On Mon, 2018-12-03 at 10:07 -0500, Jay Pipes wrote: > On 12/03/2018 09:08 AM, Roman Dobosz wrote: > > Hi, > > > > We have an issue regarding live migrate old instances. > > > > On our infrastructure based on Newton, we had not well named our > > aggregation groups and we decided to completely change the naming > > conventions. We are using extra specs/metadata in flavors/aggregates and > > AggregateInstanceExtraSpecsFilter to select the set of hosts. > > > > After changing one of the key (lets call it 'kind') of extra > > spec/metadata to the new value, we are able to create new instances, but > > unable to live-migrate old one. This is because of stored flavor extra > > specs in instance_extra, which still holds the old value for the 'kind' > > key, and make the aggregate filter fail to match the hosts. > > > > In our opinion, it should be able to live-migrate such instance, since > > only the flavor metadata has changed, while other fields doesn't (vcpus, > > memory, disk). > > > > Is it a bug? Or maybe it is possible to change the instance flavor > > extra spec? > > Not sure it's a bug, per-se... might just be something you need to > manually change database records for, though. Sucks, since it's hacky, > but not sure if it's something we should change in the API contract. depending on what that extra spec was nova could not assume that changing it would not impact that vms runtime or how its scheduled. As an RFE however i might be worth considering if we could/show allow a resize to the same flavor so that we can update the embeded flavor to pickup extra specs changes. if we allowed such a resize and the live resize spec makes progess then perhaps that woudl be a clean resolution to this usecase? > > Best, > -jay > From gryf73 at gmail.com Mon Dec 3 16:32:40 2018 From: gryf73 at gmail.com (Roman Dobosz) Date: Mon, 3 Dec 2018 17:32:40 +0100 Subject: [nova][ops] Migrating instances with old extra specs info. In-Reply-To: References: Message-ID: <20181203173240.8de68c03dfc8527fe2cefb56@gmail.com> On Mon, 3 Dec 2018 10:07:18 -0500 Jay Pipes wrote: > > Is it a bug? Or maybe it is possible to change the instance flavor > > extra spec? > > Not sure it's a bug, per-se... might just be something you need to At least unexpected behavior :) > manually change database records for, though. Sucks, since it's hacky, > but not sure if it's something we should change in the API contract. I'd be happy with nova-manage command for update extra specs in instance info, it doesn't need to be an API change :) -- Cheers, Roman Dobosz From gryf73 at gmail.com Mon Dec 3 16:35:27 2018 From: gryf73 at gmail.com (Roman Dobosz) Date: Mon, 3 Dec 2018 17:35:27 +0100 Subject: [nova][ops] Migrating instances with old extra specs info. In-Reply-To: References: Message-ID: <20181203173527.6ad5aa3f6d749ad9f8008be2@gmail.com> On Mon, 03 Dec 2018 15:34:25 +0000 Sean Mooney wrote: > if we allowed such a resize and the live resize spec makes progess > then perhaps that woudl be a clean resolution to this usecase? Unlike changing values during resize, overriding certain keys in extra specs could be tricky, and slippery a bit. I'd opt for nova-manage command for manipulating existing instances data instead. -- Cheers, Roman Dobosz From mriedemos at gmail.com Mon Dec 3 16:38:01 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Mon, 3 Dec 2018 10:38:01 -0600 Subject: [nova] When can/should we remove old nova-status upgrade checks? Message-ID: <41dda844-4466-84b6-6f47-3996d2b955cc@gmail.com> Questions came up in review [1] about dropping an old "nova-status upgrade check" which relies on using the in-tree placement database models for testing the check. The check in question, "Resource Providers", compares the number of compute node resource providers in the nova_api DB against the number of compute nodes in all cells. When the check was originally written in Ocata [2] it was meant to help ease the upgrade where nova-compute needed to be configured to report compute node resource provider inventory to placement so the scheduler could use placement. It looks for things like >0 compute nodes but 0 resource providers indicating the computes aren't reporting into placement like they should be. In Ocata, if that happened, and there were older compute nodes (from Newton), then the scheduler would fallback to not use placement. That fallback code has been removed. Also in Ocata, nova-compute would fail to start if nova.conf wasn't configured for placement [3] but that has also been removed. Now if nova.conf isn't configured for placement, I think we'll just log an exception traceback but not actually fail the service startup, and the node's resources wouldn't be available to the scheduler, so you could get NoValidHost failures during scheduling and need to dig into why a given compute node isn't being used during scheduling. The question is, given this was added in Ocata to ease with the upgrade to require placement, and we're long past that now, is the check still useful? The check still has lots of newton/ocata/pike comments in it, so it's showing its age. However, one could argue it is still useful for base install verification, or for someone doing FFU. If we keep this check, the related tests will need to be re-written to use the placement REST API fixture since the in-tree nova_api db tables will eventually go away because of extracted placement. The bigger question is, what sort of criteria do we have for dropping old checks like this besides when the related code, for which the check was added, is removed? FFU kind of throws a wrench in everything, but at the same time, I believe the prescribed FFU steps are that online data migrations (and upgrade checks) are meant to be run per-release you're fast-forward upgrading through. [1] https://review.openstack.org/#/c/617941/26/nova/tests/unit/cmd/test_status.py [2] https://review.openstack.org/#/c/413250/ [3] https://github.com/openstack/nova/blob/stable/ocata/nova/compute/manager.py#L1139 -- Thanks, Matt From cboylan at sapwetik.org Mon Dec 3 16:38:07 2018 From: cboylan at sapwetik.org (Clark Boylan) Date: Mon, 03 Dec 2018 08:38:07 -0800 Subject: [Searchlight][Zuul] tox failed tests at zuul check only In-Reply-To: References: Message-ID: <1543855087.1459125.1597252016.5DBF506E@webmail.messagingengine.com> On Mon, Dec 3, 2018, at 7:28 AM, Trinh Nguyen wrote: > Hello, > > Currently, [1] fails tox py27 tests on Zuul check for just updating the log > text. The tests are successful at local dev env. Just wondering there is > any new change at Zuul CI? > > [1] https://review.openstack.org/#/c/619162/ > Reading the exceptions [2] and the test setup code [3] it appears that elasticsearch isn't responding on its http port and is thus treated as having not started. With the info we currently have it is hard to say why. Instead of redirecting exec logs to /dev/null [4] maybe we can capture that data? Also probably worth grabbing the elasticsearch daemon log as well. Without that information it is hard to say why this happened. I am not aware of any changes in the CI system that would cause this, but we do rebuild our test node images daily. [2] http://logs.openstack.org/62/619162/5/check/openstack-tox-py27/9ce318d/job-output.txt.gz#_2018-11-27_05_32_48_854289 [3] https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/functional/__init__.py#n868 [4] https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/functional/__init__.py#n851 Clark From dangtrinhnt at gmail.com Mon Dec 3 16:41:57 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Tue, 4 Dec 2018 01:41:57 +0900 Subject: [Searchlight][Zuul] tox failed tests at zuul check only In-Reply-To: <1543855087.1459125.1597252016.5DBF506E@webmail.messagingengine.com> References: <1543855087.1459125.1597252016.5DBF506E@webmail.messagingengine.com> Message-ID: Hi Clark, Thanks for the update. I will try doing what you suggested. Bests, On Tue, Dec 4, 2018 at 1:39 AM Clark Boylan wrote: > On Mon, Dec 3, 2018, at 7:28 AM, Trinh Nguyen wrote: > > Hello, > > > > Currently, [1] fails tox py27 tests on Zuul check for just updating the > log > > text. The tests are successful at local dev env. Just wondering there is > > any new change at Zuul CI? > > > > [1] https://review.openstack.org/#/c/619162/ > > > > Reading the exceptions [2] and the test setup code [3] it appears that > elasticsearch isn't responding on its http port and is thus treated as > having not started. With the info we currently have it is hard to say why. > Instead of redirecting exec logs to /dev/null [4] maybe we can capture that > data? Also probably worth grabbing the elasticsearch daemon log as well. > > Without that information it is hard to say why this happened. I am not > aware of any changes in the CI system that would cause this, but we do > rebuild our test node images daily. > > [2] > http://logs.openstack.org/62/619162/5/check/openstack-tox-py27/9ce318d/job-output.txt.gz#_2018-11-27_05_32_48_854289 > [3] > https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/functional/__init__.py#n868 > [4] > https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/functional/__init__.py#n851 > > Clark > > -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaypipes at gmail.com Mon Dec 3 16:48:34 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Mon, 3 Dec 2018 11:48:34 -0500 Subject: [nova] When can/should we remove old nova-status upgrade checks? In-Reply-To: <41dda844-4466-84b6-6f47-3996d2b955cc@gmail.com> References: <41dda844-4466-84b6-6f47-3996d2b955cc@gmail.com> Message-ID: <57d607fb-ae4a-0bb7-ad4f-a70f8217735e@gmail.com> On 12/03/2018 11:38 AM, Matt Riedemann wrote: > Questions came up in review [1] about dropping an old "nova-status > upgrade check" which relies on using the in-tree placement database > models for testing the check. The check in question, "Resource > Providers", compares the number of compute node resource providers in > the nova_api DB against the number of compute nodes in all cells. When > the check was originally written in Ocata [2] it was meant to help ease > the upgrade where nova-compute needed to be configured to report compute > node resource provider inventory to placement so the scheduler could use > placement. It looks for things like >0 compute nodes but 0 resource > providers indicating the computes aren't reporting into placement like > they should be. In Ocata, if that happened, and there were older compute > nodes (from Newton), then the scheduler would fallback to not use > placement. That fallback code has been removed. Also in Ocata, > nova-compute would fail to start if nova.conf wasn't configured for > placement [3] but that has also been removed. Now if nova.conf isn't > configured for placement, I think we'll just log an exception traceback > but not actually fail the service startup, and the node's resources > wouldn't be available to the scheduler, so you could get NoValidHost > failures during scheduling and need to dig into why a given compute node > isn't being used during scheduling. > > The question is, given this was added in Ocata to ease with the upgrade > to require placement, and we're long past that now, is the check still > useful? The check still has lots of newton/ocata/pike comments in it, so > it's showing its age. However, one could argue it is still useful for > base install verification, or for someone doing FFU. If we keep this > check, the related tests will need to be re-written to use the placement > REST API fixture since the in-tree nova_api db tables will eventually go > away because of extracted placement. > > The bigger question is, what sort of criteria do we have for dropping > old checks like this besides when the related code, for which the check > was added, is removed? I'm not sure there is any "standard" criteria other than evaluating each migration in the way you've done above and then removing the code that is past its useful life (due to the code touching now-irrelevant parts of code as you describe above for the placement-related checks). Best, -jay From jaypipes at gmail.com Mon Dec 3 16:56:17 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Mon, 3 Dec 2018 11:56:17 -0500 Subject: [nova][ops] Migrating instances with old extra specs info. In-Reply-To: <20181203173240.8de68c03dfc8527fe2cefb56@gmail.com> References: <20181203173240.8de68c03dfc8527fe2cefb56@gmail.com> Message-ID: On 12/03/2018 11:32 AM, Roman Dobosz wrote: > On Mon, 3 Dec 2018 10:07:18 -0500 > Jay Pipes wrote: > >>> Is it a bug? Or maybe it is possible to change the instance flavor >>> extra spec? >> >> Not sure it's a bug, per-se... might just be something you need to > > At least unexpected behavior :) It's not unexpected behaviour at all. The behaviour of Nova when changing a flavor's details has been (for many releases) that the flavor's details are changed but flavor data for already-launched instances does not change. Just like you can delete a flavor but it doesn't affect already-launched instances because we store the details of the original instance. The root of the problem you are experiencing is that flavor extra-specs is a pile of half-standardized random key-value information instead of structured, standardized quantitative and qualitative information (*gasp* that's what resource classes and traits are in placement...) Which is why I say this isn't actually unexpected behaviour or really a bug. >> manually change database records for, though. Sucks, since it's hacky, >> but not sure if it's something we should change in the API contract. > > I'd be happy with nova-manage command for update extra specs in > instance info, it doesn't need to be an API change :) mysql -u$USER -p$PASSWORD -Dnova -e"UPDATE instance_extra SET flavor = REPLACE(flavor, 'old string', 'new string')" There, no need for a nova-manage command. Best, -jay p.s. test the above on a copy of your production DB before you trust it... :) From openstack at fried.cc Mon Dec 3 16:59:46 2018 From: openstack at fried.cc (Eric Fried) Date: Mon, 3 Dec 2018 10:59:46 -0600 Subject: [nova] When can/should we remove old nova-status upgrade checks? In-Reply-To: <57d607fb-ae4a-0bb7-ad4f-a70f8217735e@gmail.com> References: <41dda844-4466-84b6-6f47-3996d2b955cc@gmail.com> <57d607fb-ae4a-0bb7-ad4f-a70f8217735e@gmail.com> Message-ID: <9d50c6bd-7e9f-6ef9-7b4b-826c770b2c91@fried.cc> On 12/3/18 10:48, Jay Pipes wrote: > On 12/03/2018 11:38 AM, Matt Riedemann wrote: >> Questions came up in review [1] about dropping an old "nova-status >> upgrade check" which relies on using the in-tree placement database >> models for testing the check. The check in question, "Resource >> Providers", compares the number of compute node resource providers in >> the nova_api DB against the number of compute nodes in all cells. When >> the check was originally written in Ocata [2] it was meant to help >> ease the upgrade where nova-compute needed to be configured to report >> compute node resource provider inventory to placement so the scheduler >> could use placement. It looks for things like >0 compute nodes but 0 >> resource providers indicating the computes aren't reporting into >> placement like they should be. In Ocata, if that happened, and there >> were older compute nodes (from Newton), then the scheduler would >> fallback to not use placement. That fallback code has been removed. >> Also in Ocata, nova-compute would fail to start if nova.conf wasn't >> configured for placement [3] but that has also been removed. Now if >> nova.conf isn't configured for placement, I think we'll just log an >> exception traceback but not actually fail the service startup, and the >> node's resources wouldn't be available to the scheduler, so you could >> get NoValidHost failures during scheduling and need to dig into why a >> given compute node isn't being used during scheduling. I say remove the check. Its usefulness is negligible compared to the effort that would be required to maintain it. It certainly isn't worth writing a whole new placement feature to replace the db access. And using existing interfaces would be very heavy in large deployments. (Not that that's a show-stopper for running an upgrade check, but still.) -efried >> The question is, given this was added in Ocata to ease with the >> upgrade to require placement, and we're long past that now, is the >> check still useful? The check still has lots of newton/ocata/pike >> comments in it, so it's showing its age. However, one could argue it >> is still useful for base install verification, or for someone doing >> FFU. If we keep this check, the related tests will need to be >> re-written to use the placement REST API fixture since the in-tree >> nova_api db tables will eventually go away because of extracted >> placement. >> >> The bigger question is, what sort of criteria do we have for dropping >> old checks like this besides when the related code, for which the >> check was added, is removed? > > I'm not sure there is any "standard" criteria other than evaluating each > migration in the way you've done above and then removing the code that > is past its useful life (due to the code touching now-irrelevant parts > of code as you describe above for the placement-related checks). > > Best, > -jay > > From fungi at yuggoth.org Mon Dec 3 17:03:40 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 3 Dec 2018 17:03:40 +0000 Subject: [Searchlight][infra] tox failed tests at zuul check only In-Reply-To: References: Message-ID: <20181203170339.psadnws63wfywtrs@yuggoth.org> On 2018-12-04 00:28:30 +0900 (+0900), Trinh Nguyen wrote: > Currently, [1] fails tox py27 tests on Zuul check for just updating the log > text. The tests are successful at local dev env. Just wondering there is > any new change at Zuul CI? > > [1] https://review.openstack.org/#/c/619162/ I don't know of any recent changes which would result in the indicated test failures. According to the log it looks like it's a functional testsuite and the tests are failing to connect to the search API. I don't see your job collecting any service logs however, so it's unclear whether the API service is failing to start, or spontaneously crashes, or something else is going on. My first guess would be that one of your dependencies has released and brought some sort of regression. According to http://zuul.openstack.org/builds?job_name=openstack-tox-py27&project=openstack%2Fsearchlight&branch=master the last time that job passed for your repo was 2018-11-07 with the installed package versions listed in the http://logs.openstack.org/56/616056/1/gate/openstack-tox-py27/e413441/tox/py27-5.log file, and the first failure I see matching the errors in yours ran with the versions in http://logs.openstack.org/62/619162/1/check/openstack-tox-py27/809a281/tox/py27-5.log on 2018-11-21 (it wasn't run for the intervening 2 weeks so we have a fairly large window of potential external breakage there). A diff of those suggests the following dependencies updated between them: coverage: 4.5.1 -> 4.5.2 cryptography: 2.3.1 -> 2.4.1 httplib2: 0.11.3 -> 0.12.0 oslo.cache: 1.31.1 -> 1.31.0 (downgraded) oslo.service: 1.32.0 -> 1.33.0 python-neutronclient: 6.10.0 -> 6.11.0 requests: 2.20.0 -> 2.20.1 WebOb: 1.8.3 -> 1.8.4 Make sure with your local attempts at reproduction you're running with these newer versions of dependencies, for example by clearing any existing tox envs with the -r flag or `git clean -dfx` so that stale versions aren't used 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 eibm at fried.cc Mon Dec 3 16:58:10 2018 From: eibm at fried.cc (Eric Fried) Date: Mon, 3 Dec 2018 10:58:10 -0600 Subject: [nova] When can/should we remove old nova-status upgrade checks? In-Reply-To: <57d607fb-ae4a-0bb7-ad4f-a70f8217735e@gmail.com> References: <41dda844-4466-84b6-6f47-3996d2b955cc@gmail.com> <57d607fb-ae4a-0bb7-ad4f-a70f8217735e@gmail.com> Message-ID: <856e56e5-a66c-6c52-0900-01818a825f87@fried.cc> On 12/3/18 10:48, Jay Pipes wrote: > On 12/03/2018 11:38 AM, Matt Riedemann wrote: >> Questions came up in review [1] about dropping an old "nova-status >> upgrade check" which relies on using the in-tree placement database >> models for testing the check. The check in question, "Resource >> Providers", compares the number of compute node resource providers in >> the nova_api DB against the number of compute nodes in all cells. When >> the check was originally written in Ocata [2] it was meant to help >> ease the upgrade where nova-compute needed to be configured to report >> compute node resource provider inventory to placement so the scheduler >> could use placement. It looks for things like >0 compute nodes but 0 >> resource providers indicating the computes aren't reporting into >> placement like they should be. In Ocata, if that happened, and there >> were older compute nodes (from Newton), then the scheduler would >> fallback to not use placement. That fallback code has been removed. >> Also in Ocata, nova-compute would fail to start if nova.conf wasn't >> configured for placement [3] but that has also been removed. Now if >> nova.conf isn't configured for placement, I think we'll just log an >> exception traceback but not actually fail the service startup, and the >> node's resources wouldn't be available to the scheduler, so you could >> get NoValidHost failures during scheduling and need to dig into why a >> given compute node isn't being used during scheduling. I say remove the check. Its usefulness is negligible compared to the effort that would be required to maintain it. It certainly isn't worth writing a whole new placement feature to replace the db access. And using existing interfaces would be very heavy in large deployments. (Not that that's a show-stopper for running an upgrade check, but still.) -efried >> The question is, given this was added in Ocata to ease with the >> upgrade to require placement, and we're long past that now, is the >> check still useful? The check still has lots of newton/ocata/pike >> comments in it, so it's showing its age. However, one could argue it >> is still useful for base install verification, or for someone doing >> FFU. If we keep this check, the related tests will need to be >> re-written to use the placement REST API fixture since the in-tree >> nova_api db tables will eventually go away because of extracted >> placement. >> >> The bigger question is, what sort of criteria do we have for dropping >> old checks like this besides when the related code, for which the >> check was added, is removed? > > I'm not sure there is any "standard" criteria other than evaluating each > migration in the way you've done above and then removing the code that > is past its useful life (due to the code touching now-irrelevant parts > of code as you describe above for the placement-related checks). > > Best, > -jay > > From mrhillsman at gmail.com Mon Dec 3 17:22:26 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Mon, 3 Dec 2018 11:22:26 -0600 Subject: [all][uc] OpenStack UC Meeting @ 1900 UTC Message-ID: Hi everyone, Just a reminder that the UC meeting will be in #openstack-uc in a little more than an hour and a half from now. Please feel empowered to add to the agenda here - https://etherpad.openstack.org/p/uc - and we hope to see you there! -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrhillsman at gmail.com Mon Dec 3 17:40:25 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Mon, 3 Dec 2018 11:40:25 -0600 Subject: Fwd: [Action Needed] Update your Zoom clients In-Reply-To: References: Message-ID: Hi everyone, It was mentioned to me last week an issue with Zoom by some community members who know I use it and I keep my client updated but maybe you do not. Got another email this morning so, that being said, if you did not already know: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15715 Upgrade your client: https://support.zoom.us/hc/en-us/articles/201362233-Where-Do-I-Download-The-Latest-Version- -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rico.lin.guanyu at gmail.com Mon Dec 3 17:42:46 2018 From: rico.lin.guanyu at gmail.com (Rico Lin) Date: Tue, 4 Dec 2018 01:42:46 +0800 Subject: [all]Forum summary: Expose SIGs and WGs Message-ID: Dear all Here is the summary for forum `Expose SIGs and WGs` (etherpad [1] ). This concept still under development, so this is an open discussion and we need more feedbacks. Here are some general agreements on actions or ideas that we think it's worth to find the answer. *Set up guidelines for SIGs/WGs/Teams for interaction specific to this around tracking cross-project work* We tend to agree that we kind of lack for a guideline or a sample for SIGs/WGs, since all SIGs/WGs formed for different interest, we won't try to unify tools (unless that's what everyone agrees on) or rules for all groups. What we can do is to give more help to groups and provide a clear way for how they can set up cross-project works if they want to. Also, we can provide information on how to reach to users, ops, and developers and bridge them up. And we can even do a more general guideline or sample on how other SIGs/WGs are doing with their own workflow. Like self-healing SIG working on getting user story and feedback and use them to general better document/guideline for other users. Also, public cloud WG working on collect issues from public cloud providers and bring those issues to projects. Those IMO are great examples that we should put them down somewhere for cross SIGs/WGs consideration. As a further idea, we can even discuss if it's a common interest to have a SIG to help on SIGs. *A workflow for tracking:* This kind of follow above item. If we're going to set up a workflow, what we can add in to help people live an easier life? This is also an idea that no one in the room thinks it's a bad one, so it means in long term, it might worth our time to provide more clear information on what exactly workflow that we suggest everyone use. *Discuss SIG spec repo*: The discussion here is how can we monitoring SIGs/WGs health and track tasks. When talking about tasks we not just talking about bugs, but also features that's been considered as essential tasks for SIGs/WGs. We need a place to put them down in a trackable way (from a user story to a patch for implementation). *Ask foundation about have project update for SIGs/WGs*: One action we can start right now is to let SIGs/WGs present a project update (or even like a session but give each group 5 mins to present). This should help group getting more attention. And even capable to send out messages like what's the most important features or bug fixes they need from project teams, or what's the most important tasks that are under planning or working on. Fortunately, we got Melvin Hillsman (UC) volunteer on this task. We also have some real story (Luzi's story) for people to get a better understanding of why current workflow can look like for someone who tries to help. The thing that we also wish to do is to clear the message here. We think most of the tools are already there, so we shouldn't need to ask project teams to do any huge change. But still, we found there are definitely some improvements that we can do to better bridge users, ops, and developers. You might find some information here didn't give you a clear answer. And that's because of we still under open discussion for this. And I assume we gonna keep finding actions from discussions that we can do right away. We will try to avoid that we have to do the exact same session with the same argument over and over again. So please give your feedback, any idea, or give us your help if you also care about this. [1] https://etherpad.openstack.org/p/expose-sigs-and-wgs -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mcginnis at gmx.com Mon Dec 3 17:54:41 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Mon, 3 Dec 2018 11:54:41 -0600 Subject: [ptl][release] Proposed changes for cycle-with-intermediary services releases Message-ID: <20181203175441.GA19885@sm-workstation> This is a continuation of the effort the release team had started after the Denver PTG with simplifying and better aligning the release models in use. We noticed a handful of projects that had, intentionally or unintentionally, only made one release during the Rocky cycle. This result wasn't quite was intended, so we had discussed how we might encourage things so consumers of the community output get what they are expecting during the cycle. The intermediary model should be used to be able to deliver multiple releases at any point throughout the cycle. It should not be used as a way to avoid doing any releases until the very end of the cycle. To encourage (force?) this, we would require at least two releases of a non-library cycle-with-intermediary project during the cycle. If a release is not done by milestone 2, these projects would be switched to the new cycle-with-rc. This may actually be preferable for some with the reduced administrative overhead that should provide. Of course, teams are encouraged to decide and follow their preferred release model for whatever makes the most sense for their project. If you are the PTL or release liaison for one of these projects, please take some time to consider if the current cycle-with-intermediary release model is right for you, or if you should switch over to the newer cycle-with-rc model. The release team will review the current state of things after the second milestone at the beginning of January to try to help any projects that may benefit from choosing a different declared release model. Thanks! Sean McGinnis and the Release Team From jimmy at openstack.org Mon Dec 3 18:22:40 2018 From: jimmy at openstack.org (Jimmy McArthur) Date: Mon, 03 Dec 2018 12:22:40 -0600 Subject: OpenStack Summit Berlin Videos Now Available Message-ID: <5C057470.8050405@openstack.org> Thank you again for a wonderful Summit in Berlin. I'm pleased to announce the Summit Videos are now up on the openstack.org website: https://www.openstack.org/videos/summits/berlin-2018 If there was a session you missed, now is your chance to catch up! These videos will also be available in the Summit App as well as on the web under the Berlin Summit Schedule (https://www.openstack.org/summit/berlin-2018/summit-schedule/). If you have any questions or concerns about the videos, please write speakersupport at openstack.org. Cheers, Jimmy From doug at doughellmann.com Mon Dec 3 18:34:20 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 03 Dec 2018 13:34:20 -0500 Subject: [tc] agenda for Technical Committee Meeting 6 Dec 2018 @ 1400 UTC Message-ID: TC Members, Our next meeting will be this Thursday, 6 Dec at 1400 UTC in #openstack-tc. This email contains the agenda for the meeting, based on the content of the wiki [0]. If you will not be able to attend, please include your name in the "Apologies for Absence" section of the wiki page [0]. [0] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee * Follow up on past action items ** dhellmann complete liaison assignments using the random generator I have updated the team liaisons in the wiki [1]. Please review the list of projects to which you are assigned. [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker#Project_Teams ** tc-members review the chair duties document The draft document from [2] has been merged and is now available in the governance repo as CHAIR.rst [3]. Please come prepared to discuss any remaining questions about the list of chair duties. [2] https://etherpad.openstack.org/p/tc-chair-responsibilities [3] http://git.openstack.org/cgit/openstack/governance/tree/CHAIR.rst * active initiatives ** keeping up with python 3 releases We are ready to approve Zane's resolution for a process for tracking python 3 versions [4]. There is one wording update [5] that we should prepare for approval as well. The next step will be to approve Sean's patch describing the runtimes supported for Stein [6]. Please come prepared to discuss any issues with those patches so we can resolve them and move forward. [4] https://review.openstack.org/613145 [5] https://review.openstack.org/#/c/621461/1 [6] https://review.openstack.org/#/c/611080/ * follow-up from Berlin Forum ** Vision for OpenStack clouds Zane has summarized the forum session on the mailing list [7], including listing several potential updates to the vision based on our discussion there. Please come prepared to discuss next steps for making those changes. [7] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000431.html ** Train cycle goals I posted my summary of the forum session [8]. Each of the candidate goals have work to be done before they could be selected, so we will need to work with the sponsors and champions to see where enough progress is made to let us choose from among the proposals. Lance has agreed to lead the selection process for the Train goals, and will be looking for someone to pair up with on that. [8] http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000055.html ** Other TC outcomes from Forum We had several other forum sessions, and should make sure we have a good list of any promised actions that came from those discussions. Please come prepared to discuss any sessions you moderated -- having summaries on the mailing list before the meeting would be very helpful. -- Doug From mdulko at redhat.com Mon Dec 3 18:49:53 2018 From: mdulko at redhat.com (=?UTF-8?Q?Micha=C5=82?= Dulko) Date: Mon, 03 Dec 2018 19:49:53 +0100 Subject: [openstack-dev] [kuryr] can we start kuryr libnetwork in container inside the nova VM. In-Reply-To: References: <7b585278013291fda1d55b5d74965b26d317e637.camel@redhat.com> Message-ID: <67b4d15b3c5b08d364610112e0b2c709f86febbf.camel@redhat.com> On Sun, 2018-12-02 at 09:33 +0530, Vikrant Aggarwal wrote: > Thanks Michal. Yes, my scenario is same which you mentioned. But I > don't want to use COE atm. So. the OVS and neutron-agent running > inside the VM will be communicating with compute node neutron agent? I've did some more research and seems like nested deployments actually got implemented in kuryr-libnetwork around 3 years ago. I don't know if that still works though. Also there seem to be no documentation, so unfortunately you'll need to figure it out by reading the code. See blueprint [1] for a list of related patches. Remember that this requires the cloud to support subports and trunk ports in Neutron. VMs get the trunk ports attached and the containers get the subports. This doesn't require neutron-agent running on the VMs. [1] https://blueprints.launchpad.net/kuryr/+spec/containers-in-instances > Thanks & Regards, > Vikrant Aggarwal > > > On Fri, Nov 30, 2018 at 9:31 PM Michał Dulko wrote: > > 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 jude at judecross.com Mon Dec 3 19:15:46 2018 From: jude at judecross.com (Jude Cross) Date: Mon, 3 Dec 2018 11:15:46 -0800 Subject: [senlin] New meeting time for odd weeks Message-ID: +1 -------------------------------------------------------------------------------------------------------------------- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Arkady.Kanevsky at dell.com Mon Dec 3 19:40:01 2018 From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com) Date: Mon, 3 Dec 2018 19:40:01 +0000 Subject: OpenStack Summit Berlin Videos Now Available In-Reply-To: <5C057470.8050405@openstack.org> References: <5C057470.8050405@openstack.org> Message-ID: <1d4f5bec8f9143ba880d78df8566a757@AUSX13MPS308.AMER.DELL.COM> Thank you very much Jimmy for making it happen. -----Original Message----- From: Jimmy McArthur [mailto:jimmy at openstack.org] Sent: Monday, December 3, 2018 12:23 PM To: openstack-discuss at lists.openstack.org; community at lists.openstack.org Subject: OpenStack Summit Berlin Videos Now Available [EXTERNAL EMAIL] Thank you again for a wonderful Summit in Berlin. I'm pleased to announce the Summit Videos are now up on the openstack.org website: https://www.openstack.org/videos/summits/berlin-2018 If there was a session you missed, now is your chance to catch up! These videos will also be available in the Summit App as well as on the web under the Berlin Summit Schedule (https://www.openstack.org/summit/berlin-2018/summit-schedule/). If you have any questions or concerns about the videos, please write speakersupport at openstack.org. Cheers, Jimmy From openstack at nemebean.com Mon Dec 3 19:40:04 2018 From: openstack at nemebean.com (Ben Nemec) Date: Mon, 3 Dec 2018 13:40:04 -0600 Subject: [oslo] Berlin Summit Recap Message-ID: A bit late because I was on PTO the week after and it turns out I had a lot more to say than I realized. :-) There wasn't a ton of Oslo stuff going on, but there were a few interesting things that I discuss in [1]. I also ended up writing my thoughts about some non-Oslo-specific sessions I attended, including one that I split off in its own post because it got a bit long and deserved standalone attention[2]. 1: http://blog.nemebean.com/content/berlin-summit-recap 2: http://blog.nemebean.com/content/upstream-openstack-performance-and-release-shaming -Ben From doug at doughellmann.com Mon Dec 3 20:00:22 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 03 Dec 2018 15:00:22 -0500 Subject: [ops][docs] The Contributor Guide: Ops Feedback Session Summary In-Reply-To: References: <5938a4e0-3eb1-5448-3af5-f56bf3452e9c@suse.com> Message-ID: Doug Hellmann writes: > 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 > The patch to add this to the theme is in https://review.openstack.org/#/c/621690/ -- Doug From mrhillsman at gmail.com Mon Dec 3 20:18:11 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Mon, 3 Dec 2018 14:18:11 -0600 Subject: OpenStack Summit Berlin Videos Now Available In-Reply-To: <5C057470.8050405@openstack.org> References: <5C057470.8050405@openstack.org> Message-ID: Thanks for the update Jimmy! On Mon, Dec 3, 2018 at 12:23 PM Jimmy McArthur wrote: > Thank you again for a wonderful Summit in Berlin. I'm pleased to > announce the Summit Videos are now up on the openstack.org website: > https://www.openstack.org/videos/summits/berlin-2018 If there was a > session you missed, now is your chance to catch up! These videos will > also be available in the Summit App as well as on the web under the > Berlin Summit Schedule > (https://www.openstack.org/summit/berlin-2018/summit-schedule/). > > If you have any questions or concerns about the videos, please write > speakersupport at openstack.org. > > Cheers, > Jimmy > > -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Mon Dec 3 20:32:15 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Mon, 3 Dec 2018 14:32:15 -0600 Subject: OpenStack Summit Berlin Videos Now Available In-Reply-To: <5C057470.8050405@openstack.org> References: <5C057470.8050405@openstack.org> Message-ID: <636ad729-570e-c673-c33d-9b6a2382ece0@gmail.com> On 12/3/2018 12:22 PM, Jimmy McArthur wrote: > > If you have any questions or concerns about the videos, please write > speakersupport at openstack.org. So uh, I don't really want to be that guy, but I'm sure others have noticed the deal with the slides being different in the recordings from years past, in that you can't view them (hopefully people are uploading their slides). I'm mostly curious if there was a reason for that? Budget cuts? Technical issues? -- Thanks, Matt From mike.carden at gmail.com Mon Dec 3 20:43:04 2018 From: mike.carden at gmail.com (Mike Carden) Date: Tue, 4 Dec 2018 07:43:04 +1100 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> Message-ID: > > > Presuming you are deploying Rocky or Queens, > Yep, it's Queens. > > It goes in the nova.conf file under the [placement] section: > > randomize_allocation_candidates = true > In triple-o land it seems like the config may need to be somewhere like nova-scheduler.yaml and laid down via a re-deploy. Or something. The nova_scheduler runs in a container on a 'controller' host. -- MC -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimmy at openstack.org Mon Dec 3 20:46:31 2018 From: jimmy at openstack.org (Jimmy McArthur) Date: Mon, 03 Dec 2018 14:46:31 -0600 Subject: OpenStack Summit Berlin Videos Now Available In-Reply-To: <636ad729-570e-c673-c33d-9b6a2382ece0@gmail.com> References: <5C057470.8050405@openstack.org> <636ad729-570e-c673-c33d-9b6a2382ece0@gmail.com> Message-ID: <5C059627.9040304@openstack.org> In Berlin, in rooms where we had a full view of the screen, we didn't do a second screen for slides only. As mentioned, presenters can upload their slides to help with that. For places like the Marketplace demo theater where we had a smaller screen format, we added the view of both presenter and slide: https://www.openstack.org/videos/berlin-2018/how-to-avoid-vendor-lock-in-in-a-multi-cloud-world-with-zenko We're looking at ways to improve both formats in Denver, so I'd say stand by. If there is a presentation that you feel is too difficult to follow, we can reach out to those presenters and encourage them again to upload their slides. > Matt Riedemann > December 3, 2018 at 2:32 PM > > > So uh, I don't really want to be that guy, but I'm sure others have > noticed the deal with the slides being different in the recordings > from years past, in that you can't view them (hopefully people are > uploading their slides). I'm mostly curious if there was a reason for > that? Budget cuts? Technical issues? > > Jimmy McArthur > December 3, 2018 at 12:22 PM > Thank you again for a wonderful Summit in Berlin. I'm pleased to > announce the Summit Videos are now up on the openstack.org website: > https://www.openstack.org/videos/summits/berlin-2018 If there was a > session you missed, now is your chance to catch up! These videos will > also be available in the Summit App as well as on the web under the > Berlin Summit Schedule > (https://www.openstack.org/summit/berlin-2018/summit-schedule/). > > If you have any questions or concerns about the videos, please write > speakersupport at openstack.org. > > Cheers, > Jimmy > > _______________________________________________ > Staff mailing list > Staff at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/staff -------------- next part -------------- An HTML attachment was scrubbed... URL: From gryf73 at gmail.com Mon Dec 3 20:58:23 2018 From: gryf73 at gmail.com (Roman Dobosz) Date: Mon, 3 Dec 2018 21:58:23 +0100 Subject: [nova][ops] Migrating instances with old extra specs info. In-Reply-To: References: <20181203173240.8de68c03dfc8527fe2cefb56@gmail.com> Message-ID: <20181203215823.e41d1d0b0e33f878794a8beb@gmail.com> On Mon, 3 Dec 2018 11:56:17 -0500 Jay Pipes wrote: > >>> Is it a bug? Or maybe it is possible to change the instance flavor > >>> extra spec? > >> Not sure it's a bug, per-se... might just be something you need to > > At least unexpected behavior :) > It's not unexpected behaviour at all. The behaviour of Nova when > changing a flavor's details has been (for many releases) that the > flavor's details are changed but flavor data for already-launched > instances does not change. Just like you can delete a flavor but it > doesn't affect already-launched instances because we store the details > of the original instance. For resource related things - sure. As for more ephemeral things like metadata - its arguable. Although, I tend to agree, that sometimes metadata could potentially hold sensitive information, which shouldn't be changed in that case. > The root of the problem you are experiencing is that flavor extra-specs > is a pile of half-standardized random key-value information instead of > structured, standardized quantitative and qualitative information > (*gasp* that's what resource classes and traits are in placement...) Yeah, I know. But we have that issue in Newton, where traits are nonexistent yet :) > Which is why I say this isn't actually unexpected behaviour or really a bug. > > >> manually change database records for, though. Sucks, since it's hacky, > >> but not sure if it's something we should change in the API contract. > > I'd be happy with nova-manage command for update extra specs in > > instance info, it doesn't need to be an API change :) > mysql -u$USER -p$PASSWORD -Dnova -e"UPDATE instance_extra SET flavor = > REPLACE(flavor, 'old string', 'new string')" > > There, no need for a nova-manage command. Well, thank you, kind sir! > p.s. test the above on a copy of your production DB before you trust > it... :) You bet :) -- Cheers, Roman Dobosz From mriedemos at gmail.com Mon Dec 3 21:01:58 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Mon, 3 Dec 2018 15:01:58 -0600 Subject: OpenStack Summit Berlin Videos Now Available In-Reply-To: <5C059627.9040304@openstack.org> References: <5C057470.8050405@openstack.org> <636ad729-570e-c673-c33d-9b6a2382ece0@gmail.com> <5C059627.9040304@openstack.org> Message-ID: On 12/3/2018 2:46 PM, Jimmy McArthur wrote: > We're looking at ways to improve both formats in Denver, so I'd say > stand by.  If there is a presentation that you feel is too difficult to > follow, we can reach out to those presenters and encourage them again to > upload their slides. Here is a good example of what I'm talking about: https://youtu.be/J9K-x0yVZ4U?t=425 There is full view of the slides, but my eyes can't read most of that text. Compare that to YVR: https://youtu.be/U5V_2CUj-6A?t=576 And it's night and day. -- Thanks, Matt From jimmy at openstack.org Mon Dec 3 21:05:26 2018 From: jimmy at openstack.org (Jimmy McArthur) Date: Mon, 03 Dec 2018 15:05:26 -0600 Subject: OpenStack Summit Berlin Videos Now Available In-Reply-To: References: <5C057470.8050405@openstack.org> <636ad729-570e-c673-c33d-9b6a2382ece0@gmail.com> <5C059627.9040304@openstack.org> Message-ID: <5C059A96.8030504@openstack.org> Yeah, that makes sense. We had multiple complaints coming out of YVR that the size of the speaker was too small. So we're trying to work out a happy medium that can still work within our budget. Appreciate the feedback :) > Matt Riedemann > December 3, 2018 at 3:01 PM > > > Here is a good example of what I'm talking about: > > https://youtu.be/J9K-x0yVZ4U?t=425 > > There is full view of the slides, but my eyes can't read most of that > text. Compare that to YVR: > > https://youtu.be/U5V_2CUj-6A?t=576 > > And it's night and day. > > Jimmy McArthur > December 3, 2018 at 2:46 PM > In Berlin, in rooms where we had a full view of the screen, we didn't > do a second screen for slides only. As mentioned, presenters can > upload their slides to help with that. > > For places like the Marketplace demo theater where we had a smaller > screen format, we added the view of both presenter and slide: > https://www.openstack.org/videos/berlin-2018/how-to-avoid-vendor-lock-in-in-a-multi-cloud-world-with-zenko > > We're looking at ways to improve both formats in Denver, so I'd say > stand by. If there is a presentation that you feel is too difficult > to follow, we can reach out to those presenters and encourage them > again to upload their slides. > > > > Matt Riedemann > December 3, 2018 at 2:32 PM > > > So uh, I don't really want to be that guy, but I'm sure others have > noticed the deal with the slides being different in the recordings > from years past, in that you can't view them (hopefully people are > uploading their slides). I'm mostly curious if there was a reason for > that? Budget cuts? Technical issues? > > Jimmy McArthur > December 3, 2018 at 12:22 PM > Thank you again for a wonderful Summit in Berlin. I'm pleased to > announce the Summit Videos are now up on the openstack.org website: > https://www.openstack.org/videos/summits/berlin-2018 If there was a > session you missed, now is your chance to catch up! These videos will > also be available in the Summit App as well as on the web under the > Berlin Summit Schedule > (https://www.openstack.org/summit/berlin-2018/summit-schedule/). > > If you have any questions or concerns about the videos, please write > speakersupport at openstack.org. > > Cheers, > Jimmy > > _______________________________________________ > Staff mailing list > Staff at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/staff -------------- next part -------------- An HTML attachment was scrubbed... URL: From openstack at medberry.net Mon Dec 3 21:16:11 2018 From: openstack at medberry.net (David Medberry) Date: Mon, 3 Dec 2018 14:16:11 -0700 Subject: OpenStack Summit Berlin Videos Now Available In-Reply-To: <5C059A96.8030504@openstack.org> References: <5C057470.8050405@openstack.org> <636ad729-570e-c673-c33d-9b6a2382ece0@gmail.com> <5C059627.9040304@openstack.org> <5C059A96.8030504@openstack.org> Message-ID: Hmmm, if you can HEAR the speaker and SEE the slides (as in YVR), seems like that should be sufficient. There's usually a photo of the speaker on their bio page if you need more "presence". -dave On Mon, Dec 3, 2018 at 2:05 PM Jimmy McArthur wrote: > Yeah, that makes sense. We had multiple complaints coming out of YVR that > the size of the speaker was too small. So we're trying to work out a happy > medium that can still work within our budget. > > Appreciate the feedback :) > > Matt Riedemann > December 3, 2018 at 3:01 PM > > > Here is a good example of what I'm talking about: > > https://youtu.be/J9K-x0yVZ4U?t=425 > > There is full view of the slides, but my eyes can't read most of that > text. Compare that to YVR: > > https://youtu.be/U5V_2CUj-6A?t=576 > > And it's night and day. > > Jimmy McArthur > December 3, 2018 at 2:46 PM > In Berlin, in rooms where we had a full view of the screen, we didn't do a > second screen for slides only. As mentioned, presenters can upload their > slides to help with that. > > For places like the Marketplace demo theater where we had a smaller screen > format, we added the view of both presenter and slide: > https://www.openstack.org/videos/berlin-2018/how-to-avoid-vendor-lock-in-in-a-multi-cloud-world-with-zenko > > We're looking at ways to improve both formats in Denver, so I'd say stand > by. If there is a presentation that you feel is too difficult to follow, > we can reach out to those presenters and encourage them again to upload > their slides. > > > > Matt Riedemann > December 3, 2018 at 2:32 PM > > > So uh, I don't really want to be that guy, but I'm sure others have > noticed the deal with the slides being different in the recordings from > years past, in that you can't view them (hopefully people are uploading > their slides). I'm mostly curious if there was a reason for that? Budget > cuts? Technical issues? > > Jimmy McArthur > December 3, 2018 at 12:22 PM > Thank you again for a wonderful Summit in Berlin. I'm pleased to announce > the Summit Videos are now up on the openstack.org website: > https://www.openstack.org/videos/summits/berlin-2018 If there was a > session you missed, now is your chance to catch up! These videos will also > be available in the Summit App as well as on the web under the Berlin > Summit Schedule ( > https://www.openstack.org/summit/berlin-2018/summit-schedule/). > > If you have any questions or concerns about the videos, please write > speakersupport at openstack.org. > > Cheers, > Jimmy > > _______________________________________________ > Staff mailing list > Staff at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/staff > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openstack at medberry.net Mon Dec 3 21:18:00 2018 From: openstack at medberry.net (David Medberry) Date: Mon, 3 Dec 2018 14:18:00 -0700 Subject: OpenStack Summit Berlin Videos Now Available In-Reply-To: References: <5C057470.8050405@openstack.org> <636ad729-570e-c673-c33d-9b6a2382ece0@gmail.com> <5C059627.9040304@openstack.org> <5C059A96.8030504@openstack.org> Message-ID: and so sorry for the TOFU reply all. I'm beating myself up over it. From corvus at inaugust.com Mon Dec 3 21:30:32 2018 From: corvus at inaugust.com (James E. Blair) Date: Mon, 03 Dec 2018 13:30:32 -0800 Subject: [infra] A change to Zuul's queuing behavior Message-ID: <87bm62z4av.fsf@meyer.lemoncheese.net> Hi, We recently made a change to how Zuul and Nodepool prioritize node requests. Cloud resources are the major constraint in how long it takes Zuul to run test jobs on proposed changes. Because we're using more resources than ever before (but not necessarily because we're doing more work -- Clark has been helping to identify inefficiencies in other mailing list threads), the amount of time it takes to receive results on a change has been increasing. Since some larger projects consume the bulk of cloud resources in our system, this can be especially frustrating for smaller projects. To be sure, it impacts everyone, but while larger projects receive a continuous stream of results (even if delayed) smaller projects may wait hours before seeing results on a single change. In order to help all projects maintain a minimal velocity, we've begun dynamically prioritizing node requests based on the number of changes a project has in a given pipeline. This means that the first change for every project in the check pipeline has the same priority. The same is true for the second change of each project in the pipeline. The result is that if a project has 50 changes in check, and another project has a single change in check, the second project won't have to wait for all 50 changes ahead before it gets nodes allocated. As conditions change (requests are fulfilled, changes are added and removed) the priorities of any unfulfilled requests are adjusted accordingly. In the gate pipeline, the grouping is by shared change queue. But the gate pipeline still has a higher overall precedence than check. We hope that this will make for a significant improvement in the experience for smaller projects without causing undue hardship for larger ones. We will be closely observing the new behavior and make any necessary tuning adjustments over the next few weeks. Please let us know if you see any adverse impacts, but don't be surprised if you notice node requests being filled "out of order". -Jim From chris.friesen at windriver.com Mon Dec 3 21:33:08 2018 From: chris.friesen at windriver.com (Chris Friesen) Date: Mon, 3 Dec 2018 15:33:08 -0600 Subject: [infra] A change to Zuul's queuing behavior In-Reply-To: <87bm62z4av.fsf@meyer.lemoncheese.net> References: <87bm62z4av.fsf@meyer.lemoncheese.net> Message-ID: On 12/3/2018 3:30 PM, James E. Blair wrote: > In order to help all projects maintain a minimal velocity, we've begun > dynamically prioritizing node requests based on the number of changes a > project has in a given pipeline. This sounds great, thanks. Chris From miguel at mlavalle.com Mon Dec 3 21:38:21 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Mon, 3 Dec 2018 15:38:21 -0600 Subject: [openstack-dev] [Neutron] Propose Nate Johnston for Neutron core Message-ID: Hi Stackers, I want to nominate Nate Johnston (irc:njohnston) as a member of the Neutron core team. Nate started contributing to Neutron back in the Liberty cycle. One of the highlight contributions of that early period is his collaboration with others to implement DSCP QoS rules ( https://review.openstack.org/#/c/251738/). After a hiatus of a few cycles, we were lucky to have Nate come back to the community during the Rocky cycle. Since then, he has been a driving force in the adoption in Neutron of Oslo Versioned Objects, the "Run under Python 3 by default" community wide initiative and the optimization of ports creation in bulk to better support containerized workloads. He is a man with a wide range of interests, who is not afraid of expressing his opinions in any of them. The quality and number of his code reviews during the Stein cycle is on par with the leading members of the core team: http://stackalytics.com/?module=neutron-group. I especially admire his ability to forcefully handle disagreement in a friendly and easy going manner. On top of all that, he graciously endured me as his mentor over the past few months. For all these reasons, I think he is ready to join the team and we will be very lucky to have him as a fully voting core. I will keep this nomination open for a week as customary. Thank you Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: From duc.openstack at gmail.com Mon Dec 3 21:53:45 2018 From: duc.openstack at gmail.com (Duc Truong) Date: Mon, 3 Dec 2018 13:53:45 -0800 Subject: OpenStack Summit Berlin Videos Now Available In-Reply-To: References: <5C057470.8050405@openstack.org> <636ad729-570e-c673-c33d-9b6a2382ece0@gmail.com> <5C059627.9040304@openstack.org> <5C059A96.8030504@openstack.org> Message-ID: Quick question, how do we upload the slides for our presentation? From miguel at mlavalle.com Mon Dec 3 22:14:02 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Mon, 3 Dec 2018 16:14:02 -0600 Subject: [openstack-dev] [Neutron] Propose Hongbin Lu for Neutron core Message-ID: Hi Stackers, I want to nominate Hongbin Lu (irc: hongbin) as a member of the Neutron core team. Hongbin started contributing to the OpenStack community in the Liberty cycle. Over time, he made great contributions in helping the community to better support containers by being core team member and / or PTL in projects such as Zun and Magnum. An then, fortune played in our favor and Hongbin joined the Neutron team in the Queens cycle. Since then, he has made great contributions such as filters validation in the ReST API, PF status propagation to to VFs (ports) in SR-IOV environments and leading the forking of RYU into the os-ken OpenStack project, which provides key foundational functionality for openflow. He is not a man who wastes words, but when he speaks up, his opinions are full of insight. This is reflected in the quality of his code reviews, which in number are on par with the leading members of the core team: http://stackalytics.com/?module=neutron-group. Even though Hongbin leaves in Toronto, he speaks Mandarin Chinese and was born and raised in China. This is a big asset in helping the Neutron team to incorporate use cases from that part of the world. Hongbin spent the past few months being mentored by Slawek Kaplonski, who has reported that Hongbin is ready for the challenge of being a core team member. I (and other core team members) concur. I will keep this nomination open for a week as customary. Thank you Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimmy at openstack.org Mon Dec 3 22:16:29 2018 From: jimmy at openstack.org (Jimmy McArthur) Date: Mon, 03 Dec 2018 16:16:29 -0600 Subject: OpenStack Summit Berlin Videos Now Available In-Reply-To: References: <5C057470.8050405@openstack.org> <636ad729-570e-c673-c33d-9b6a2382ece0@gmail.com> <5C059627.9040304@openstack.org> <5C059A96.8030504@openstack.org> Message-ID: <5C05AB3D.8080908@openstack.org> Hi Duc, Please send a link to your slide deck (or the deck itself) to speakersupport at openstack.org, and I'll be happy to get it up for you. Thank you, Jimmy > Duc Truong > December 3, 2018 at 3:53 PM > Quick question, how do we upload the slides for our presentation? > David Medberry > December 3, 2018 at 3:18 PM > and so sorry for the TOFU reply all. I'm beating myself up over it. > David Medberry > December 3, 2018 at 3:16 PM > Hmmm, if you can HEAR the speaker and SEE the slides (as in YVR), > seems like that should be sufficient. There's usually a photo of the > speaker on their bio page if you need more "presence". > > -dave > > Jimmy McArthur > December 3, 2018 at 3:05 PM > Yeah, that makes sense. We had multiple complaints coming out of YVR > that the size of the speaker was too small. So we're trying to work > out a happy medium that can still work within our budget. > > Appreciate the feedback :) > > > Matt Riedemann > December 3, 2018 at 3:01 PM > > > Here is a good example of what I'm talking about: > > https://youtu.be/J9K-x0yVZ4U?t=425 > > There is full view of the slides, but my eyes can't read most of that > text. Compare that to YVR: > > https://youtu.be/U5V_2CUj-6A?t=576 > > And it's night and day. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From strigazi at gmail.com Mon Dec 3 22:24:48 2018 From: strigazi at gmail.com (Spyros Trigazis) Date: Mon, 3 Dec 2018 23:24:48 +0100 Subject: [openstack-dev] [magnum] kubernetes images for magnum rocky Message-ID: Hello all, Following the vulnerability [0], with magnum rocky and the kubernetes driver on fedora atomic you can use this tag "v1.11.5-1" [1] for new clusters. To upgrade the apiserver in existing clusters, on the master node(s) you can run: sudo atomic pull --storage ostree docker.io/openstackmagnum/kubernetes-apiserver:v1.11.5-1 sudo atomic containers update --rebase docker.io/openstackmagnum/kubernetes-apiserver:v1.11.5-1 kube-apiserver You can upgrade the other k8s components with similar commands. I'll share instructions for magnum queens tomorrow morning CET time. Cheers, Spyros [0] https://github.com/kubernetes/kubernetes/issues/71411 [1] https://hub.docker.com/r/openstackmagnum/kubernetes-apiserver/tags/ -------------- 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 strigazi at gmail.com Mon Dec 3 22:24:48 2018 From: strigazi at gmail.com (Spyros Trigazis) Date: Mon, 3 Dec 2018 23:24:48 +0100 Subject: [Openstack-operators] [openstack-dev][magnum] kubernetes images for magnum rocky Message-ID: Hello all, Following the vulnerability [0], with magnum rocky and the kubernetes driver on fedora atomic you can use this tag "v1.11.5-1" [1] for new clusters. To upgrade the apiserver in existing clusters, on the master node(s) you can run: sudo atomic pull --storage ostree docker.io/openstackmagnum/kubernetes-apiserver:v1.11.5-1 sudo atomic containers update --rebase docker.io/openstackmagnum/kubernetes-apiserver:v1.11.5-1 kube-apiserver You can upgrade the other k8s components with similar commands. I'll share instructions for magnum queens tomorrow morning CET time. Cheers, Spyros [0] https://github.com/kubernetes/kubernetes/issues/71411 [1] https://hub.docker.com/r/openstackmagnum/kubernetes-apiserver/tags/ -------------- 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 skaplons at redhat.com Mon Dec 3 22:41:33 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Mon, 3 Dec 2018 23:41:33 +0100 Subject: [openstack-dev] [Neutron] Propose Hongbin Lu for Neutron core In-Reply-To: References: Message-ID: <493CB94D-19C3-4B61-8577-6BD98006B7F5@redhat.com> Definitely big +1 from me! — Slawek Kaplonski Senior software engineer Red Hat > Wiadomość napisana przez Miguel Lavalle w dniu 03.12.2018, o godz. 23:14: > > Hi Stackers, > > I want to nominate Hongbin Lu (irc: hongbin) as a member of the Neutron core team. Hongbin started contributing to the OpenStack community in the Liberty cycle. Over time, he made great contributions in helping the community to better support containers by being core team member and / or PTL in projects such as Zun and Magnum. An then, fortune played in our favor and Hongbin joined the Neutron team in the Queens cycle. Since then, he has made great contributions such as filters validation in the ReST API, PF status propagation to to VFs (ports) in SR-IOV environments and leading the forking of RYU into the os-ken OpenStack project, which provides key foundational functionality for openflow. He is not a man who wastes words, but when he speaks up, his opinions are full of insight. This is reflected in the quality of his code reviews, which in number are on par with the leading members of the core team: http://stackalytics.com/?module=neutron-group. Even though Hongbin leaves in Toronto, he speaks Mandarin Chinese and was born and raised in China. This is a big asset in helping the Neutron team to incorporate use cases from that part of the world. > > Hongbin spent the past few months being mentored by Slawek Kaplonski, who has reported that Hongbin is ready for the challenge of being a core team member. I (and other core team members) concur. > > I will keep this nomination open for a week as customary. > > Thank you > > Miguel From skaplons at redhat.com Mon Dec 3 22:43:24 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Mon, 3 Dec 2018 23:43:24 +0100 Subject: [openstack-dev] [Neutron] Propose Nate Johnston for Neutron core In-Reply-To: References: Message-ID: Big +1 from me for Nate also :) — Slawek Kaplonski Senior software engineer Red Hat > Wiadomość napisana przez Miguel Lavalle w dniu 03.12.2018, o godz. 22:38: > > Hi Stackers, > > I want to nominate Nate Johnston (irc:njohnston) as a member of the Neutron core team. Nate started contributing to Neutron back in the Liberty cycle. One of the highlight contributions of that early period is his collaboration with others to implement DSCP QoS rules (https://review.openstack.org/#/c/251738/). After a hiatus of a few cycles, we were lucky to have Nate come back to the community during the Rocky cycle. Since then, he has been a driving force in the adoption in Neutron of Oslo Versioned Objects, the "Run under Python 3 by default" community wide initiative and the optimization of ports creation in bulk to better support containerized workloads. He is a man with a wide range of interests, who is not afraid of expressing his opinions in any of them. The quality and number of his code reviews during the Stein cycle is on par with the leading members of the core team: http://stackalytics.com/?module=neutron-group. I especially admire his ability to forcefully handle disagreement in a friendly and easy going manner. > > On top of all that, he graciously endured me as his mentor over the past few months. For all these reasons, I think he is ready to join the team and we will be very lucky to have him as a fully voting core. > > I will keep this nomination open for a week as customary. > > Thank you > > Miguel > > From openstack at nemebean.com Mon Dec 3 22:48:28 2018 From: openstack at nemebean.com (Ben Nemec) Date: Mon, 3 Dec 2018 16:48:28 -0600 Subject: [all] Etcd as DLM Message-ID: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> Hi, I wanted to revisit this topic because it has come up in some downstream discussions around Cinder A/A HA and the last time we talked about it upstream was a year and a half ago[1]. There have certainly been changes since then so I think it's worth another look. For context, the conclusion of that session was: "Let's use etcd 3.x in the devstack CI, projects that are eventlet based an use the etcd v3 http experimental API and those that don't can use the etcd v3 gRPC API. Dims will submit a patch to tooz for the new driver with v3 http experimental API. Projects should feel free to use the DLM based on tooz+etcd3 from now on. Others projects can figure out other use cases for etcd3." The main question that has come up is whether this is still the best practice or if we should revisit the preferred drivers for etcd. Gorka has gotten the grpc-based driver working in a Cinder driver that needs etcd[2], so there's a question as to whether we still need the HTTP etcd-gateway or if everything should use grpc. I will admit I'm nervous about trying to juggle eventlet and grpc, but if it works then my only argument is general misgivings about doing anything clever that involves eventlet. :-) It looks like the HTTP API for etcd has moved out of experimental status[3] at this point, so that's no longer an issue. There was some vague concern from a downstream packaging perspective that the grpc library might use a funky build system, whereas the etcd3-gateway library only depends on existing OpenStack requirements. On the other hand, I don't know how much of a hassle it is to deploy and manage a grpc-gateway. I'm kind of hoping someone has already been down this road and can advise about what they found. Thanks. -Ben 1: https://etherpad.openstack.org/p/BOS-etcd-base-service 2: https://github.com/embercsi/ember-csi/blob/5bd4dffe9107bc906d14a45cd819d9a659c19047/ember_csi/ember_csi.py#L1106-L1111 3: https://github.com/grpc-ecosystem/grpc-gateway From mrhillsman at gmail.com Mon Dec 3 23:13:42 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Mon, 3 Dec 2018 17:13:42 -0600 Subject: [sigs] Monthly Update Message-ID: Hi everyone, During the Forum we discussed one simple way we could move forward to hopefully get more visibility and activity within SIGs. Here is a proposal for such a step. Send out a monthly email to openstack-discuss with the following information from each SIG captured via etherpad [0] 1. What success(es) have you had this month as a SIG? 2. What should we know about the SIG for the next month? 3. What would you like help (hands) or feedback (eyes) on? Besides the ML, other places this could be re-used in whole or part is on social media, SU Blog, etc. Thoughts? [0] https://etherpad.openstack.org/p/sig-updates -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Mon Dec 3 23:30:22 2018 From: smooney at redhat.com (Sean Mooney) Date: Mon, 03 Dec 2018 23:30:22 +0000 Subject: OpenStack Summit Berlin Videos Now Available In-Reply-To: References: <5C057470.8050405@openstack.org> <636ad729-570e-c673-c33d-9b6a2382ece0@gmail.com> <5C059627.9040304@openstack.org> <5C059A96.8030504@openstack.org> Message-ID: On Mon, 2018-12-03 at 14:16 -0700, David Medberry wrote: > Hmmm, if you can HEAR the speaker and SEE the slides (as in YVR), seems like that should be sufficient. that would be my peference also. it is nice to be able to see presenteres but their slides/laptop screen are the more important content that said im glad that they are available. > There's usually a photo of the speaker on their bio page if you need more "presence". > > -dave > > On Mon, Dec 3, 2018 at 2:05 PM Jimmy McArthur wrote: > > Yeah, that makes sense. We had multiple complaints coming out of YVR that the size of the speaker was too small. So > > we're trying to work out a happy medium that can still work within our budget. > > > > Appreciate the feedback :) > > > > > Matt Riedemann December 3, 2018 at 3:01 PM > > > > > > > > > Here is a good example of what I'm talking about: > > > > > > https://youtu.be/J9K-x0yVZ4U?t=425 > > > > > > There is full view of the slides, but my eyes can't read most of that text. Compare that to YVR: > > > > > > https://youtu.be/U5V_2CUj-6A?t=576 > > > > > > And it's night and day. one factor in that may be that the videos are uploaded in 720p at 50 rather then 1080p at 60 as they had been in vancouver. so far i have been able to view most of videos ok. the room where the project updates were is proably the one with the worst lighting. the room were the lights at the front were dimmed are quite good. the shorter videos/ market place demos like https://www.youtube.com/watch?v=hzcrjk-tgLk are certenly eaiser to view the presented content but most of the larger rooms are visable. > > > > > > Jimmy McArthur December 3, 2018 at 2:46 PM > > > In Berlin, in rooms where we had a full view of the screen, we didn't do a second screen for slides only. As > > > mentioned, presenters can upload their slides to help with that. > > > > > > For places like the Marketplace demo theater where we had a smaller screen format, we added the view of both > > > presenter and slide: https://www.openstack.org/videos/berlin-2018/how-to-avoid-vendor-lock-in-in-a-multi-cloud-wor > > > ld-with-zenko > > > > > > We're looking at ways to improve both formats in Denver, so I'd say stand by. If there is a presentation that you > > > feel is too difficult to follow, we can reach out to those presenters and encourage them again to upload their > > > slides. > > > > > > > > > > > > Matt Riedemann December 3, 2018 at 2:32 PM > > > > > > > > > So uh, I don't really want to be that guy, but I'm sure others have noticed the deal with the slides being > > > different in the recordings from years past, in that you can't view them (hopefully people are uploading their > > > slides). I'm mostly curious if there was a reason for that? Budget cuts? Technical issues? > > > > > > Jimmy McArthur December 3, 2018 at 12:22 PM > > > Thank you again for a wonderful Summit in Berlin. I'm pleased to announce the Summit Videos are now up on the > > > openstack.org website: https://www.openstack.org/videos/summits/berlin-2018 If there was a session you missed, > > > now is your chance to catch up! These videos will also be available in the Summit App as well as on the web under > > > the Berlin Summit Schedule (https://www.openstack.org/summit/berlin-2018/summit-schedule/). > > > > > > If you have any questions or concerns about the videos, please write speakersupport at openstack.org. > > > > > > Cheers, > > > Jimmy > > > > > > _______________________________________________ > > > Staff mailing list > > > Staff at lists.openstack.org > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/staff > > From smooney at redhat.com Mon Dec 3 23:42:19 2018 From: smooney at redhat.com (Sean Mooney) Date: Mon, 03 Dec 2018 23:42:19 +0000 Subject: [infra] A change to Zuul's queuing behavior In-Reply-To: <87bm62z4av.fsf@meyer.lemoncheese.net> References: <87bm62z4av.fsf@meyer.lemoncheese.net> Message-ID: On Mon, 2018-12-03 at 13:30 -0800, James E. Blair wrote: > Hi, > > We recently made a change to how Zuul and Nodepool prioritize node > requests. Cloud resources are the major constraint in how long it takes > Zuul to run test jobs on proposed changes. Because we're using more > resources than ever before (but not necessarily because we're doing more > work -- Clark has been helping to identify inefficiencies in other > mailing list threads), the amount of time it takes to receive results on > a change has been increasing. > > Since some larger projects consume the bulk of cloud resources in our > system, this can be especially frustrating for smaller projects. To be > sure, it impacts everyone, but while larger projects receive a > continuous stream of results (even if delayed) smaller projects may wait > hours before seeing results on a single change. > > In order to help all projects maintain a minimal velocity, we've begun > dynamically prioritizing node requests based on the number of changes a > project has in a given pipeline. > > This means that the first change for every project in the check pipeline > has the same priority. The same is true for the second change of each > project in the pipeline. The result is that if a project has 50 changes > in check, and another project has a single change in check, the second > project won't have to wait for all 50 changes ahead before it gets nodes > allocated. i could be imagineing this but is this not how zuul v2 used to work or rather how the gate was configured a few cycles ago. i remember in the past when i was working on smaller projects it was often quicker to submit patches to those instead fo nova for example. in partacal i remember working on both os-vif and nova in the past and finding my os-vif jobs would often get started much quicker then nova. anyway i think this is hopefully a good change for the majority of projects but it triggered of feeling of deja vu, was this how the gates used to run? > As conditions change (requests are fulfilled, changes are > added and removed) the priorities of any unfulfilled requests are > adjusted accordingly. > > In the gate pipeline, the grouping is by shared change queue. But the > gate pipeline still has a higher overall precedence than check. > > We hope that this will make for a significant improvement in the > experience for smaller projects without causing undue hardship for > larger ones. > We will be closely observing the new behavior and make any > necessary tuning adjustments over the next few weeks. Please let us > know if you see any adverse impacts, but don't be surprised if you > notice node requests being filled "out of order". > > -Jim > From strigazi at gmail.com Mon Dec 3 23:13:52 2018 From: strigazi at gmail.com (Spyros Trigazis) Date: Tue, 4 Dec 2018 00:13:52 +0100 Subject: [openstack-dev] [magnum] kubernetes images for magnum rocky In-Reply-To: References: Message-ID: Magnum queens, uses kubernetes 1.9.3 by default. You can upgrade to v1.10.11-1. From a quick test v1.11.5-1 is also compatible with 1.9.x. We are working to make this painless, sorry you have to ssh to the nodes for now. Cheers, Spyros On Mon, 3 Dec 2018 at 23:24, Spyros Trigazis wrote: > Hello all, > > Following the vulnerability [0], with magnum rocky and the kubernetes > driver > on fedora atomic you can use this tag "v1.11.5-1" [1] for new clusters. To > upgrade > the apiserver in existing clusters, on the master node(s) you can run: > sudo atomic pull --storage ostree > docker.io/openstackmagnum/kubernetes-apiserver:v1.11.5-1 > sudo atomic containers update --rebase > docker.io/openstackmagnum/kubernetes-apiserver:v1.11.5-1 kube-apiserver > > You can upgrade the other k8s components with similar commands. > > I'll share instructions for magnum queens tomorrow morning CET time. > > Cheers, > Spyros > > [0] https://github.com/kubernetes/kubernetes/issues/71411 > [1] https://hub.docker.com/r/openstackmagnum/kubernetes-apiserver/tags/ > -------------- 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 strigazi at gmail.com Mon Dec 3 23:13:52 2018 From: strigazi at gmail.com (Spyros Trigazis) Date: Tue, 4 Dec 2018 00:13:52 +0100 Subject: [Openstack-operators] [openstack-dev][magnum] kubernetes images for magnum rocky In-Reply-To: References: Message-ID: Magnum queens, uses kubernetes 1.9.3 by default. You can upgrade to v1.10.11-1. From a quick test v1.11.5-1 is also compatible with 1.9.x. We are working to make this painless, sorry you have to ssh to the nodes for now. Cheers, Spyros On Mon, 3 Dec 2018 at 23:24, Spyros Trigazis wrote: > Hello all, > > Following the vulnerability [0], with magnum rocky and the kubernetes > driver > on fedora atomic you can use this tag "v1.11.5-1" [1] for new clusters. To > upgrade > the apiserver in existing clusters, on the master node(s) you can run: > sudo atomic pull --storage ostree > docker.io/openstackmagnum/kubernetes-apiserver:v1.11.5-1 > sudo atomic containers update --rebase > docker.io/openstackmagnum/kubernetes-apiserver:v1.11.5-1 kube-apiserver > > You can upgrade the other k8s components with similar commands. > > I'll share instructions for magnum queens tomorrow morning CET time. > > Cheers, > Spyros > > [0] https://github.com/kubernetes/kubernetes/issues/71411 > [1] https://hub.docker.com/r/openstackmagnum/kubernetes-apiserver/tags/ > -------------- 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 juliaashleykreger at gmail.com Mon Dec 3 23:53:45 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Mon, 3 Dec 2018 15:53:45 -0800 Subject: [all] Etcd as DLM In-Reply-To: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> Message-ID: I would like to slightly interrupt this train of thought for an unscheduled vision of the future! What if we could allow a component to store data in etcd3's key value store like how we presently use oslo_db/sqlalchemy? While I personally hope to have etcd3 as a DLM for ironic one day, review bandwidth permitting, it occurs to me that etcd3 could be leveraged for more than just DLM. If we have a common vision to enable data storage, I suspect it might help provide overall guidance as to how we want to interact with the service moving forward. -Julia On Mon, Dec 3, 2018 at 2:52 PM Ben Nemec wrote: > Hi, > > I wanted to revisit this topic because it has come up in some downstream > discussions around Cinder A/A HA and the last time we talked about it > upstream was a year and a half ago[1]. There have certainly been changes > since then so I think it's worth another look. For context, the > conclusion of that session was: > > "Let's use etcd 3.x in the devstack CI, projects that are eventlet based > an use the etcd v3 http experimental API and those that don't can use > the etcd v3 gRPC API. Dims will submit a patch to tooz for the new > driver with v3 http experimental API. Projects should feel free to use > the DLM based on tooz+etcd3 from now on. Others projects can figure out > other use cases for etcd3." > > The main question that has come up is whether this is still the best > practice or if we should revisit the preferred drivers for etcd. Gorka > has gotten the grpc-based driver working in a Cinder driver that needs > etcd[2], so there's a question as to whether we still need the HTTP > etcd-gateway or if everything should use grpc. I will admit I'm nervous > about trying to juggle eventlet and grpc, but if it works then my only > argument is general misgivings about doing anything clever that involves > eventlet. :-) > > It looks like the HTTP API for etcd has moved out of experimental > status[3] at this point, so that's no longer an issue. There was some > vague concern from a downstream packaging perspective that the grpc > library might use a funky build system, whereas the etcd3-gateway > library only depends on existing OpenStack requirements. > > On the other hand, I don't know how much of a hassle it is to deploy and > manage a grpc-gateway. I'm kind of hoping someone has already been down > this road and can advise about what they found. > > Thanks. > > -Ben > > 1: https://etherpad.openstack.org/p/BOS-etcd-base-service > 2: > > https://github.com/embercsi/ember-csi/blob/5bd4dffe9107bc906d14a45cd819d9a659c19047/ember_csi/ember_csi.py#L1106-L1111 > 3: https://github.com/grpc-ecosystem/grpc-gateway > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangtrinhnt at gmail.com Tue Dec 4 00:09:32 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Tue, 4 Dec 2018 09:09:32 +0900 Subject: [Searchlight][infra] tox failed tests at zuul check only In-Reply-To: <20181203170339.psadnws63wfywtrs@yuggoth.org> References: <20181203170339.psadnws63wfywtrs@yuggoth.org> Message-ID: Thank Jeremy for the clear instructions. On Tue, Dec 4, 2018 at 2:05 AM Jeremy Stanley wrote: > On 2018-12-04 00:28:30 +0900 (+0900), Trinh Nguyen wrote: > > Currently, [1] fails tox py27 tests on Zuul check for just updating the > log > > text. The tests are successful at local dev env. Just wondering there is > > any new change at Zuul CI? > > > > [1] https://review.openstack.org/#/c/619162/ > > I don't know of any recent changes which would result in the > indicated test failures. According to the log it looks like it's a > functional testsuite and the tests are failing to connect to the > search API. I don't see your job collecting any service logs > however, so it's unclear whether the API service is failing to > start, or spontaneously crashes, or something else is going on. My > first guess would be that one of your dependencies has released and > brought some sort of regression. > > According to > > http://zuul.openstack.org/builds?job_name=openstack-tox-py27&project=openstack%2Fsearchlight&branch=master > the last time that job passed for your repo was 2018-11-07 with the > installed package versions listed in the > > http://logs.openstack.org/56/616056/1/gate/openstack-tox-py27/e413441/tox/py27-5.log > file, and the first failure I see matching the errors in yours ran > with the versions in > > http://logs.openstack.org/62/619162/1/check/openstack-tox-py27/809a281/tox/py27-5.log > on 2018-11-21 (it wasn't run for the intervening 2 weeks so we have > a fairly large window of potential external breakage there). A diff > of those suggests the following dependencies updated between them: > > coverage: 4.5.1 -> 4.5.2 > cryptography: 2.3.1 -> 2.4.1 > httplib2: 0.11.3 -> 0.12.0 > oslo.cache: 1.31.1 -> 1.31.0 (downgraded) > oslo.service: 1.32.0 -> 1.33.0 > python-neutronclient: 6.10.0 -> 6.11.0 > requests: 2.20.0 -> 2.20.1 > WebOb: 1.8.3 -> 1.8.4 > > Make sure with your local attempts at reproduction you're running > with these newer versions of dependencies, for example by clearing > any existing tox envs with the -r flag or `git clean -dfx` so that > stale versions aren't used instead. > -- > Jeremy Stanley > -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Tue Dec 4 00:05:28 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 4 Dec 2018 00:05:28 +0000 Subject: [all] The old mailing lists are now retired In-Reply-To: <20181119000426.hpgshg6ln5652pvt@yuggoth.org> References: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> <20181119000426.hpgshg6ln5652pvt@yuggoth.org> Message-ID: <20181204000527.mdeesmrtlloej3ye@yuggoth.org> The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists were replaced by openstack-discuss. Starting now the old lists are no longer receiving new posts, but their addresses are aliased to the new list for the convenience of anyone replying to an earlier message. If you happen to notice one of the old list addresses in a reply you're writing, please take a moment to update it to the correct one. Here follow some brief notes on the nature of this new list: 1. We have documented[*] subject tags we want to use. Most of our current needs are probably already covered there, but if you notice something missing you can correct it by posting a change for code review to the doc/source/open-community.rst file in the openstack/project-team-guide Git repository. 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. 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. Further, the From and Reply-To headers from the original message are unaltered by the listserv. These changes in behavior from our previous lists are part of an effort to avoid creating unnecessary DMARC/DKIM violations. A mailreader with reply-to-list functionality is strongly recommended. If you're unfortunate enough not to be using such a client, you may be able to get away with using reply-to-all and then removing any irrelevant addresses (making sure to still include the mailing list's posting address). 3. Please take a moment to review our netiquette guide[**] for participating in OpenStack mailing lists. [*] https://docs.openstack.org/project-team-guide/open-community.html#mailing-lists [**] https://wiki.openstack.org/wiki/MailingListEtiquette -- 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 strigazi at gmail.com Tue Dec 4 00:24:21 2018 From: strigazi at gmail.com (Spyros Trigazis) Date: Tue, 4 Dec 2018 01:24:21 +0100 Subject: [openstack-dev][magnum] kubernetes images for magnum rocky In-Reply-To: References: Message-ID: Hello again, address space issues: # uninstall the running container sudo atomic uninstall kube-apiserver # delete the old image, check which one you use sudo atomic images delete --storage ostree docker.io/openstackmagnum/kubernetes-apiserver:v1.9.3 # prune to actually claim the space back sudo atomic images prune # install the new image sudo atomic install --system --storage ostree --name kube-apiserver docker.io/openstackmagnum/kubernetes-apiserver:v1.10.11-1 # start the service sudo systemctl start kube-apiserver I haven't used it, but there is an ansible module [0]. Cheers, Spyros [0] https://docs.ansible.com/ansible/2.5/modules/atomic_container_module.html On Tue, 4 Dec 2018 at 00:13, Spyros Trigazis wrote: > Magnum queens, uses kubernetes 1.9.3 by default. > You can upgrade to v1.10.11-1. From a quick test > v1.11.5-1 is also compatible with 1.9.x. > > We are working to make this painless, sorry you > have to ssh to the nodes for now. > > Cheers, > Spyros > > On Mon, 3 Dec 2018 at 23:24, Spyros Trigazis wrote: > >> Hello all, >> >> Following the vulnerability [0], with magnum rocky and the kubernetes >> driver >> on fedora atomic you can use this tag "v1.11.5-1" [1] for new clusters. >> To upgrade >> the apiserver in existing clusters, on the master node(s) you can run: >> sudo atomic pull --storage ostree >> docker.io/openstackmagnum/kubernetes-apiserver:v1.11.5-1 >> sudo atomic containers update --rebase >> docker.io/openstackmagnum/kubernetes-apiserver:v1.11.5-1 kube-apiserver >> >> You can upgrade the other k8s components with similar commands. >> >> I'll share instructions for magnum queens tomorrow morning CET time. >> >> Cheers, >> Spyros >> >> [0] https://github.com/kubernetes/kubernetes/issues/71411 >> [1] https://hub.docker.com/r/openstackmagnum/kubernetes-apiserver/tags/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kevin.Fox at pnnl.gov Tue Dec 4 00:55:31 2018 From: Kevin.Fox at pnnl.gov (Fox, Kevin M) Date: Tue, 4 Dec 2018 00:55:31 +0000 Subject: [all] Etcd as DLM In-Reply-To: References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com>, Message-ID: <1A3C52DFCD06494D8528644858247BF01C24C6BD@EX10MBOX03.pnnl.gov> It is a full base service already: https://governance.openstack.org/tc/reference/base-services.html Projects have been free to use it for quite some time. I'm not sure if any actually are yet though. It was decided not to put an abstraction layer on top as its pretty simple and commonly deployed. Thanks, Kevin ________________________________ From: Julia Kreger [juliaashleykreger at gmail.com] Sent: Monday, December 03, 2018 3:53 PM To: Ben Nemec Cc: Davanum Srinivas; geguileo at redhat.com; openstack-discuss at lists.openstack.org Subject: Re: [all] Etcd as DLM I would like to slightly interrupt this train of thought for an unscheduled vision of the future! What if we could allow a component to store data in etcd3's key value store like how we presently use oslo_db/sqlalchemy? While I personally hope to have etcd3 as a DLM for ironic one day, review bandwidth permitting, it occurs to me that etcd3 could be leveraged for more than just DLM. If we have a common vision to enable data storage, I suspect it might help provide overall guidance as to how we want to interact with the service moving forward. -Julia On Mon, Dec 3, 2018 at 2:52 PM Ben Nemec > wrote: Hi, I wanted to revisit this topic because it has come up in some downstream discussions around Cinder A/A HA and the last time we talked about it upstream was a year and a half ago[1]. There have certainly been changes since then so I think it's worth another look. For context, the conclusion of that session was: "Let's use etcd 3.x in the devstack CI, projects that are eventlet based an use the etcd v3 http experimental API and those that don't can use the etcd v3 gRPC API. Dims will submit a patch to tooz for the new driver with v3 http experimental API. Projects should feel free to use the DLM based on tooz+etcd3 from now on. Others projects can figure out other use cases for etcd3." The main question that has come up is whether this is still the best practice or if we should revisit the preferred drivers for etcd. Gorka has gotten the grpc-based driver working in a Cinder driver that needs etcd[2], so there's a question as to whether we still need the HTTP etcd-gateway or if everything should use grpc. I will admit I'm nervous about trying to juggle eventlet and grpc, but if it works then my only argument is general misgivings about doing anything clever that involves eventlet. :-) It looks like the HTTP API for etcd has moved out of experimental status[3] at this point, so that's no longer an issue. There was some vague concern from a downstream packaging perspective that the grpc library might use a funky build system, whereas the etcd3-gateway library only depends on existing OpenStack requirements. On the other hand, I don't know how much of a hassle it is to deploy and manage a grpc-gateway. I'm kind of hoping someone has already been down this road and can advise about what they found. Thanks. -Ben 1: https://etherpad.openstack.org/p/BOS-etcd-base-service 2: https://github.com/embercsi/ember-csi/blob/5bd4dffe9107bc906d14a45cd819d9a659c19047/ember_csi/ember_csi.py#L1106-L1111 3: https://github.com/grpc-ecosystem/grpc-gateway -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.carden at gmail.com Tue Dec 4 02:04:02 2018 From: mike.carden at gmail.com (Mike Carden) Date: Tue, 4 Dec 2018 13:04:02 +1100 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> Message-ID: Having found the nice docs at: https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/tips_tricks.html I have divined that I can ssh to each controller node and: sudo docker exec -u root nova_scheduler crudini --set /etc/nova/nova.conf placement randomize_allocation_candidates true sudo docker kill -s SIGHUP nova_scheduler ...and indeed the /etc/nova/nova.conf in each nova_scheduler container is updated accordingly. Unfortunately, instances are all still launched on compute-0. -- MC -------------- next part -------------- An HTML attachment was scrubbed... URL: From liuyulong.xa at gmail.com Tue Dec 4 02:04:35 2018 From: liuyulong.xa at gmail.com (LIU Yulong) Date: Tue, 4 Dec 2018 10:04:35 +0800 Subject: [openstack-dev] [Neutron] Propose Hongbin Lu for Neutron core In-Reply-To: <493CB94D-19C3-4B61-8577-6BD98006B7F5@redhat.com> References: <493CB94D-19C3-4B61-8577-6BD98006B7F5@redhat.com> Message-ID: +1 On Tue, Dec 4, 2018 at 6:43 AM Slawomir Kaplonski wrote: > Definitely big +1 from me! > > — > Slawek Kaplonski > Senior software engineer > Red Hat > > > Wiadomość napisana przez Miguel Lavalle w dniu > 03.12.2018, o godz. 23:14: > > > > Hi Stackers, > > > > I want to nominate Hongbin Lu (irc: hongbin) as a member of the Neutron > core team. Hongbin started contributing to the OpenStack community in the > Liberty cycle. Over time, he made great contributions in helping the > community to better support containers by being core team member and / or > PTL in projects such as Zun and Magnum. An then, fortune played in our > favor and Hongbin joined the Neutron team in the Queens cycle. Since then, > he has made great contributions such as filters validation in the ReST API, > PF status propagation to to VFs (ports) in SR-IOV environments and leading > the forking of RYU into the os-ken OpenStack project, which provides key > foundational functionality for openflow. He is not a man who wastes words, > but when he speaks up, his opinions are full of insight. This is reflected > in the quality of his code reviews, which in number are on par with the > leading members of the core team: > http://stackalytics.com/?module=neutron-group. Even though Hongbin leaves > in Toronto, he speaks Mandarin Chinese and was born and raised in China. > This is a big asset in helping the Neutron team to incorporate use cases > from that part of the world. > > > > Hongbin spent the past few months being mentored by Slawek Kaplonski, > who has reported that Hongbin is ready for the challenge of being a core > team member. I (and other core team members) concur. > > > > I will keep this nomination open for a week as customary. > > > > Thank you > > > > Miguel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liuyulong.xa at gmail.com Tue Dec 4 02:04:51 2018 From: liuyulong.xa at gmail.com (LIU Yulong) Date: Tue, 4 Dec 2018 10:04:51 +0800 Subject: [openstack-dev] [Neutron] Propose Nate Johnston for Neutron core In-Reply-To: References: Message-ID: +1 On Tue, Dec 4, 2018 at 6:44 AM Slawomir Kaplonski wrote: > Big +1 from me for Nate also :) > > — > Slawek Kaplonski > Senior software engineer > Red Hat > > > Wiadomość napisana przez Miguel Lavalle w dniu > 03.12.2018, o godz. 22:38: > > > > Hi Stackers, > > > > I want to nominate Nate Johnston (irc:njohnston) as a member of the > Neutron core team. Nate started contributing to Neutron back in the Liberty > cycle. One of the highlight contributions of that early period is his > collaboration with others to implement DSCP QoS rules ( > https://review.openstack.org/#/c/251738/). After a hiatus of a few > cycles, we were lucky to have Nate come back to the community during the > Rocky cycle. Since then, he has been a driving force in the adoption in > Neutron of Oslo Versioned Objects, the "Run under Python 3 by default" > community wide initiative and the optimization of ports creation in bulk to > better support containerized workloads. He is a man with a wide range of > interests, who is not afraid of expressing his opinions in any of them. > The quality and number of his code reviews during the Stein cycle is on par > with the leading members of the core team: > http://stackalytics.com/?module=neutron-group. I especially admire his > ability to forcefully handle disagreement in a friendly and easy going > manner. > > > > On top of all that, he graciously endured me as his mentor over the past > few months. For all these reasons, I think he is ready to join the team and > we will be very lucky to have him as a fully voting core. > > > > I will keep this nomination open for a week as customary. > > > > Thank you > > > > Miguel > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juliaashleykreger at gmail.com Tue Dec 4 02:47:25 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Mon, 3 Dec 2018 18:47:25 -0800 Subject: [all] Etcd as DLM In-Reply-To: <1A3C52DFCD06494D8528644858247BF01C24C6BD@EX10MBOX03.pnnl.gov> References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> <1A3C52DFCD06494D8528644858247BF01C24C6BD@EX10MBOX03.pnnl.gov> Message-ID: Indeed it is a considered a base service, but I'm unaware of why it was decided to not have any abstraction layer on top. That sort of defeats the adoption of tooz as a standard in the community. Plus with the rest of our code bases, we have a number of similar or identical patterns and it would be ideal to have a single library providing the overall interface for the purposes of consistency. Could you provide some more background on that decision? I guess what I'd really like to see is an oslo.db interface into etcd3. -Julia On Mon, Dec 3, 2018 at 4:55 PM Fox, Kevin M wrote: > It is a full base service already: > https://governance.openstack.org/tc/reference/base-services.html > > Projects have been free to use it for quite some time. I'm not sure if any > actually are yet though. > > It was decided not to put an abstraction layer on top as its pretty simple > and commonly deployed. > > Thanks, > Kevin > ------------------------------ > *From:* Julia Kreger [juliaashleykreger at gmail.com] > *Sent:* Monday, December 03, 2018 3:53 PM > *To:* Ben Nemec > *Cc:* Davanum Srinivas; geguileo at redhat.com; > openstack-discuss at lists.openstack.org > *Subject:* Re: [all] Etcd as DLM > > I would like to slightly interrupt this train of thought for an > unscheduled vision of the future! > > What if we could allow a component to store data in etcd3's key value > store like how we presently use oslo_db/sqlalchemy? > > While I personally hope to have etcd3 as a DLM for ironic one day, review > bandwidth permitting, it occurs to me that etcd3 could be leveraged for > more than just DLM. If we have a common vision to enable data storage, I > suspect it might help provide overall guidance as to how we want to > interact with the service moving forward. > > -Julia > > On Mon, Dec 3, 2018 at 2:52 PM Ben Nemec wrote: > >> Hi, >> >> I wanted to revisit this topic because it has come up in some downstream >> discussions around Cinder A/A HA and the last time we talked about it >> upstream was a year and a half ago[1]. There have certainly been changes >> since then so I think it's worth another look. For context, the >> conclusion of that session was: >> >> "Let's use etcd 3.x in the devstack CI, projects that are eventlet based >> an use the etcd v3 http experimental API and those that don't can use >> the etcd v3 gRPC API. Dims will submit a patch to tooz for the new >> driver with v3 http experimental API. Projects should feel free to use >> the DLM based on tooz+etcd3 from now on. Others projects can figure out >> other use cases for etcd3." >> >> The main question that has come up is whether this is still the best >> practice or if we should revisit the preferred drivers for etcd. Gorka >> has gotten the grpc-based driver working in a Cinder driver that needs >> etcd[2], so there's a question as to whether we still need the HTTP >> etcd-gateway or if everything should use grpc. I will admit I'm nervous >> about trying to juggle eventlet and grpc, but if it works then my only >> argument is general misgivings about doing anything clever that involves >> eventlet. :-) >> >> It looks like the HTTP API for etcd has moved out of experimental >> status[3] at this point, so that's no longer an issue. There was some >> vague concern from a downstream packaging perspective that the grpc >> library might use a funky build system, whereas the etcd3-gateway >> library only depends on existing OpenStack requirements. >> >> On the other hand, I don't know how much of a hassle it is to deploy and >> manage a grpc-gateway. I'm kind of hoping someone has already been down >> this road and can advise about what they found. >> >> Thanks. >> >> -Ben >> >> 1: https://etherpad.openstack.org/p/BOS-etcd-base-service >> 2: >> >> https://github.com/embercsi/ember-csi/blob/5bd4dffe9107bc906d14a45cd819d9a659c19047/ember_csi/ember_csi.py#L1106-L1111 >> 3: https://github.com/grpc-ecosystem/grpc-gateway >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz at redhat.com Tue Dec 4 03:46:05 2018 From: aschultz at redhat.com (Alex Schultz) Date: Mon, 3 Dec 2018 20:46:05 -0700 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> Message-ID: On Mon, Dec 3, 2018 at 7:06 PM Mike Carden wrote: > > > Having found the nice docs at: > https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/tips_tricks.html > > I have divined that I can ssh to each controller node and: > sudo docker exec -u root nova_scheduler crudini --set /etc/nova/nova.conf placement randomize_allocation_candidates true > sudo docker kill -s SIGHUP nova_scheduler > FYI protip, you can add the following to a custom environment file to configure this value (as we don't expose the config by default) parameters_defaults: ControllerExtraConfig: nova::config::nova_config: placement/randomize_allocation_candidates: value: true And then do a deployment. This will persist it and ensure future scaling/management updates won't remove this configuration. > ...and indeed the /etc/nova/nova.conf in each nova_scheduler container is updated accordingly. > > Unfortunately, instances are all still launched on compute-0. > > -- > MC > > From aschultz at redhat.com Tue Dec 4 03:46:05 2018 From: aschultz at redhat.com (Alex Schultz) Date: Mon, 3 Dec 2018 20:46:05 -0700 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> Message-ID: On Mon, Dec 3, 2018 at 7:06 PM Mike Carden wrote: > > > Having found the nice docs at: > https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/tips_tricks.html > > I have divined that I can ssh to each controller node and: > sudo docker exec -u root nova_scheduler crudini --set /etc/nova/nova.conf placement randomize_allocation_candidates true > sudo docker kill -s SIGHUP nova_scheduler > FYI protip, you can add the following to a custom environment file to configure this value (as we don't expose the config by default) parameters_defaults: ControllerExtraConfig: nova::config::nova_config: placement/randomize_allocation_candidates: value: true And then do a deployment. This will persist it and ensure future scaling/management updates won't remove this configuration. > ...and indeed the /etc/nova/nova.conf in each nova_scheduler container is updated accordingly. > > Unfortunately, instances are all still launched on compute-0. > > -- > MC > > From miguel at mlavalle.com Tue Dec 4 04:00:18 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Mon, 3 Dec 2018 22:00:18 -0600 Subject: [openstack-dev] [Neutron] Bugs deputy report week of November 26th Message-ID: Hi Neutron team, I was the bugs deputy the week of November 26th. It was a relatively quite week. These are the bugs reported during the period: *Medium priority* - https://bugs.launchpad.net/neutron/+bug/1805824, The dhcp port's address may be messed when the port's network has multiple subnets. Fix proposed here: https://review.openstack.org/#/c/620900/. It undoes a previous fix, https://bugs.launchpad.net/neutron/+bug/1581918, so another alternative has to be found - https://bugs.launchpad.net/neutron/+bug/1805808, Openvswitch firewall driver don't reinitialize after ovs-vswitchd restart. Fix proposed here: https://review.openstack.org/620886 - https://bugs.launchpad.net/neutron/+bug/1805456, [DVR] Neutron doesn't configure multiple external subnets for one network properly. Owner assigned *Low priority* - https://bugs.launchpad.net/neutron/+bug/1805844*, *When debugging fullstack tests, "cmd" module is incorrectly imported*. *Fix already in progress: https://review.openstack.org/620916 - https://bugs.launchpad.net/neutron/+bug/1805126, confusing wording in config-dns-int.rst. Fixed proposed: https://review.openstack.org/620017 *Incomplete* - https://bugs.launchpad.net/neutron/+bug/1805769, maximum RPC response timeout is not reasonable. Requested clarification from submitter - https://bugs.launchpad.net/neutron/+bug/1805356, Convert instance method to staticmethod in linux bridge agent. Requested clarification from submitter *Needs further investigation* - https://bugs.launchpad.net/neutron/+bug/1805132, bulk creation of security group rules fails StaleDataError. Couldn't reproduce -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.carden at gmail.com Tue Dec 4 04:10:36 2018 From: mike.carden at gmail.com (Mike Carden) Date: Tue, 4 Dec 2018 15:10:36 +1100 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> Message-ID: On Tue, Dec 4, 2018 at 2:46 PM Alex Schultz wrote: > > > parameters_defaults: > ControllerExtraConfig: > nova::config::nova_config: > placement/randomize_allocation_candidates: > value: true Thanks for that Alex. I'll roll that into our next over-the-top deploy update. I won't hold my breath for it actually getting our scheduling sorted out though, since it made no difference when I manually updated all three controllers with that config. -- MC -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrhillsman at gmail.com Tue Dec 4 04:12:19 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Mon, 3 Dec 2018 22:12:19 -0600 Subject: [openlab] Weekly Meeting Message-ID: Hi everyone, Please see the following links for full log of today’s meeting and a more concise summary: Full Log: https://meetings.openlabtesting.org/devops/2018/devops.2018-12-04-02.00.log.html Summary (Minutes): https://meetings.openlabtesting.org/devops/2018/devops.2018-12-04-02.00.html Help Wanted: Setup os_loganalyze – https://github.com/theopenlab/openlab/issues/137 There is always an opportunity to grab items off the project board – https://github.com/orgs/theopenlab/projects/1 If you have any questions regarding the meeting please send email response to this email for follow-up. -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.urdin at binero.se Tue Dec 4 08:38:08 2018 From: tobias.urdin at binero.se (Tobias Urdin) Date: Tue, 4 Dec 2018 09:38:08 +0100 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> Message-ID: <0331f7bb-9e6d-5f75-5649-5bc5285585c8@binero.se> Started a patch to include that option in puppet-nova as well based on this thread which perhaps can help the TripleO based world as well. https://review.openstack.org/#/c/621593/ Best regards On 12/04/2018 04:56 AM, Alex Schultz wrote: > On Mon, Dec 3, 2018 at 7:06 PM Mike Carden wrote: >> >> Having found the nice docs at: >> https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/tips_tricks.html >> >> I have divined that I can ssh to each controller node and: >> sudo docker exec -u root nova_scheduler crudini --set /etc/nova/nova.conf placement randomize_allocation_candidates true >> sudo docker kill -s SIGHUP nova_scheduler >> > FYI protip, you can add the following to a custom environment file to > configure this value (as we don't expose the config by default) > > parameters_defaults: > ControllerExtraConfig: > nova::config::nova_config: > placement/randomize_allocation_candidates: > value: true > > > And then do a deployment. This will persist it and ensure future > scaling/management updates won't remove this configuration. > > > >> ...and indeed the /etc/nova/nova.conf in each nova_scheduler container is updated accordingly. >> >> Unfortunately, instances are all still launched on compute-0. >> >> -- >> MC >> >> > From balazs.gibizer at ericsson.com Tue Dec 4 09:00:43 2018 From: balazs.gibizer at ericsson.com (=?iso-8859-1?Q?Bal=E1zs_Gibizer?=) Date: Tue, 4 Dec 2018 09:00:43 +0000 Subject: [nova] When can/should we remove old nova-status upgrade checks? In-Reply-To: <41dda844-4466-84b6-6f47-3996d2b955cc@gmail.com> References: <41dda844-4466-84b6-6f47-3996d2b955cc@gmail.com> Message-ID: <1543914038.32372.1@smtp.office365.com> On Mon, Dec 3, 2018 at 5:38 PM, Matt Riedemann wrote: > Questions came up in review [1] about dropping an old "nova-status > upgrade check" which relies on using the in-tree placement database > models for testing the check. The check in question, "Resource > Providers", compares the number of compute node resource providers in > the nova_api DB against the number of compute nodes in all cells. > When the check was originally written in Ocata [2] it was meant to > help ease the upgrade where nova-compute needed to be configured to > report compute node resource provider inventory to placement so the > scheduler could use placement. It looks for things like >0 compute > nodes but 0 resource providers indicating the computes aren't > reporting into placement like they should be. In Ocata, if that > happened, and there were older compute nodes (from Newton), then the > scheduler would fallback to not use placement. That fallback code has > been removed. Also in Ocata, nova-compute would fail to start if > nova.conf wasn't configured for placement [3] but that has also been > removed. Now if nova.conf isn't configured for placement, I think > we'll just log an exception traceback but not actually fail the > service startup, and the node's resources wouldn't be available to > the scheduler, so you could get NoValidHost failures during > scheduling and need to dig into why a given compute node isn't being > used during scheduling. > > The question is, given this was added in Ocata to ease with the > upgrade to require placement, and we're long past that now, is the > check still useful? The check still has lots of newton/ocata/pike > comments in it, so it's showing its age. However, one could argue it > is still useful for base install verification, or for someone doing > FFU. If we keep this check, the related tests will need to be > re-written to use the placement REST API fixture since the in-tree > nova_api db tables will eventually go away because of extracted > placement. I'm OK to remove the check as during FFU one can install Rocky version of nova to run the check if needed. Anyhow if there is a need to keep the check, then I think we can change the implementation to read the hostname of each compute from the HostMapping and query the placement API with that hostname as a RP name then check that there is VCPU inventory at least on that RP. Cheers, gibi > > The bigger question is, what sort of criteria do we have for dropping > old checks like this besides when the related code, for which the > check was added, is removed? FFU kind of throws a wrench in > everything, but at the same time, I believe the prescribed FFU steps > are that online data migrations (and upgrade checks) are meant to be > run per-release you're fast-forward upgrading through. > > [1] > https://review.openstack.org/#/c/617941/26/nova/tests/unit/cmd/test_status.py > [2] https://review.openstack.org/#/c/413250/ > [3] > https://github.com/openstack/nova/blob/stable/ocata/nova/compute/manager.py#L1139 > > -- > > Thanks, > > Matt > From gmann at ghanshyammann.com Tue Dec 4 09:01:04 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 04 Dec 2018 18:01:04 +0900 Subject: [dev] [tc][all] TC office hours is started now on #openstack-tc Message-ID: <1677873098d.e1e2934268954.3300616982788651524@ghanshyammann.com> Hello everyone, 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. - gmann & TC From gmann at ghanshyammann.com Tue Dec 4 10:16:49 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 04 Dec 2018 19:16:49 +0900 Subject: [dev][nova][placement][qa] opinion on adding placement tests support in Tempest Message-ID: <16778b864ea.ed28ea0d72714.6704537180908793759@ghanshyammann.com> Hi All, As you all know, placement tests (in nova repo or in new placement repo) are implemented using gabbi functional test[1]. There is a patch from amodi about adding placement test in Tempest [2]. Currently, Tempest does not support the placement endpoints. To support placement API in Tempest, it does not need much work (i have listed the todo items in gerrit patch.). Before we start or proceed with the discussion in QA, i would like to get the nova(placement) team opinion on adding the placement support in Tempest. Obviously, we should not duplicate the testing effort between what existing gabbi tests cover or what going to be added in Tempest which we can take care while adding the new tests. [1] https://github.com/openstack/nova/tree/5f648dda49a6d5fe5ecfd7dddcb5f7dc3d6b51a6/nova/tests/functional/api/openstack/placement https://github.com/openstack/placement/tree/34f03c297e28ae2c46ab11debdb4bbe64df1acdc/placement/tests/functional [2] https://review.openstack.org/#/c/621645/2 -gmann From cdent+os at anticdent.org Tue Dec 4 10:55:08 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Tue, 4 Dec 2018 10:55:08 +0000 (GMT) Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> Message-ID: On Tue, 4 Dec 2018, Mike Carden wrote: > Having found the nice docs at: > https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/tips_tricks.html > > I have divined that I can ssh to each controller node and: > sudo docker exec -u root nova_scheduler crudini --set /etc/nova/nova.conf > placement randomize_allocation_candidates true > sudo docker kill -s SIGHUP nova_scheduler > > ...and indeed the /etc/nova/nova.conf in each nova_scheduler container is > updated accordingly. > > Unfortunately, instances are all still launched on compute-0. Sorry this has been such a pain for you. There are a couple of issues/other things to try: * The 'randomize_allocation_candidates' config setting is used by the placement-api process (probably called nova-placement-api in queens), not the nova-scheduler process, so you need to update the config (in the placement section) for the former and restart it. * If that still doesn't fix it then it would be helpful to see the logs from both the placement-api and nova-scheduler process from around the time you try to launch some instances, as that will help show if there's some other factor at play that is changing the number of available target hosts, causing attempts on the other two hosts to not land. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From flavio at redhat.com Tue Dec 4 11:08:08 2018 From: flavio at redhat.com (Flavio Percoco) Date: Tue, 4 Dec 2018 12:08:08 +0100 Subject: [Nova] Increase size limits for user data Message-ID: Greetings, I've been working on a tool that requires creating CoreOS nodes on OpenStack. Sadly, I've hit the user data limit, which has blocked the work I'm doing. One big difference between CoreOS images and other cloud images out there is that CoreOS images don't use cloud-init but a different tool called Ignition[0], which uses JSON as its serialization format. The size of the configs that I need to pass to the instance is bigger than the limit imposed by Nova. I've worked on reducing the size as much as possible and even generating a compressed version of it but the data is still bigger than the limit (144 kb vs 65kb). I'd like to understand better what the nature of the limit is (is it because of the field size in the database? Is it purely an API limit? Is it because it causes problems depending on the vendor? As far as I can tell the limit is just being enforced by the API schema[1] and not the DB as it uses a MEDIUMTEXT field. I realize this has been asked before but I wanted to get a feeling of the current opinion about this. Would the Nova team consider increasing the limit of the API considering that more use cases like this may be more common these days? [0] https://coreos.com/ignition/docs/latest/ [1] https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/servers.py#L212-L215 Thanks, Flavio -- @flaper87 Flavio Percoco From cdent+os at anticdent.org Tue Dec 4 11:13:44 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Tue, 4 Dec 2018 11:13:44 +0000 (GMT) Subject: [dev][nova][placement][qa] opinion on adding placement tests support in Tempest In-Reply-To: <16778b864ea.ed28ea0d72714.6704537180908793759@ghanshyammann.com> References: <16778b864ea.ed28ea0d72714.6704537180908793759@ghanshyammann.com> Message-ID: On Tue, 4 Dec 2018, Ghanshyam Mann wrote: > Before we start or proceed with the discussion in QA, i would like to get the nova(placement) team opinion on adding the placement support in Tempest. Obviously, we should not duplicate the testing effort between what existing gabbi tests cover or what going to be added in Tempest which we can take care while adding the new tests. My feeling on this is that what should be showing up in tempest with regard to placement tests are things that demonstrate and prove end to end scenarios in which placement is involved as a critical part, but is in the background. For example, things like the emerging minimal bandwidth functionality that involves all three of nova, placement and neutron. I don't think we need extensive testing in Tempest of the placement API itself, as that's already well covered by the existing functional tests, nor do I think it makes much sense to cover the common scheduling scenarios between nova and placement as those are also well covered and will continue to be covered even with placement extracted [1]. Existing Tempests tests that do things like launching, resizing, migrating servers already touch placement so may be sufficient. If we wanted to make these more complete adding verification of resource providers and their inventories before and after the tests might be useful. [1] https://review.openstack.org/#/c/617941/ -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From lajos.katona at ericsson.com Tue Dec 4 11:49:53 2018 From: lajos.katona at ericsson.com (Lajos Katona) Date: Tue, 4 Dec 2018 11:49:53 +0000 Subject: [dev][nova][placement][qa] opinion on adding placement tests support in Tempest In-Reply-To: References: <16778b864ea.ed28ea0d72714.6704537180908793759@ghanshyammann.com> Message-ID: <231b7347-1165-3917-80a1-88cf33c96de1@ericsson.com> Hi, I started to add a scenario test to neutron-tempest-plugin for bandwidth and for that some placement client to tempest. I plan to upload (possibly as WIP) first the client part and after that the scenario for bandwidth and for routed networks as that one uses placement as well. Regards Lajos On 2018. 12. 04. 12:13, Chris Dent wrote: > On Tue, 4 Dec 2018, Ghanshyam Mann wrote: > >> Before we start or proceed with the discussion in QA, i would like to >> get the nova(placement) team opinion on adding the placement support >> in Tempest. Obviously, we should not duplicate the testing effort >> between what existing gabbi tests cover or what going to be added in >> Tempest which we can take care while adding the new tests. > > My feeling on this is that what should be showing up in tempest with > regard to placement tests are things that demonstrate and prove end > to end scenarios in which placement is involved as a critical part, > but is in the background. For example, things like the emerging minimal > bandwidth functionality that involves all three of nova, placement > and neutron. > > I don't think we need extensive testing in Tempest of the placement > API itself, as that's already well covered by the existing > functional tests, nor do I think it makes much sense to cover the > common scheduling scenarios between nova and placement as those are > also well covered and will continue to be covered even with > placement extracted [1]. > > Existing Tempests tests that do things like launching, resizing, > migrating servers already touch placement so may be sufficient. If > we wanted to make these more complete adding verification of > resource providers and their inventories before and after the tests > might be useful. > > > [1] https://review.openstack.org/#/c/617941/ > From zufar at onf-ambassador.org Tue Dec 4 08:59:13 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Tue, 4 Dec 2018 15:59:13 +0700 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> Message-ID: Hi all, I am facing this issue again, I try to add this configuration but still, the node is going to compute1. [scheduler] driver = filter_scheduler host_manager = host_manager [filter_scheduler] available_filters=nova.scheduler.filters.all_filters enabled_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,CoreFilter use_baremetal_filters=False weight_classes=nova.scheduler.weights.all_weighers [placement] randomize_allocation_candidates = true thank you. Best Regards, Zufar Dhiyaulhaq On Tue, Dec 4, 2018 at 3:55 AM Mike Carden wrote: > >> Presuming you are deploying Rocky or Queens, >> > > Yep, it's Queens. > > >> >> It goes in the nova.conf file under the [placement] section: >> >> randomize_allocation_candidates = true >> > > In triple-o land it seems like the config may need to be somewhere like > nova-scheduler.yaml and laid down via a re-deploy. > > Or something. > > The nova_scheduler runs in a container on a 'controller' host. > > -- > MC > > _______________________________________________ > 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 geguileo at redhat.com Tue Dec 4 10:08:12 2018 From: geguileo at redhat.com (Gorka Eguileor) Date: Tue, 4 Dec 2018 11:08:12 +0100 Subject: [all] Etcd as DLM In-Reply-To: References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> <1A3C52DFCD06494D8528644858247BF01C24C6BD@EX10MBOX03.pnnl.gov> Message-ID: <20181204100812.og33xegl2fxmoo6g@localhost> On 03/12, Julia Kreger wrote: > Indeed it is a considered a base service, but I'm unaware of why it was > decided to not have any abstraction layer on top. That sort of defeats the > adoption of tooz as a standard in the community. Plus with the rest of our > code bases, we have a number of similar or identical patterns and it would > be ideal to have a single library providing the overall interface for the > purposes of consistency. Could you provide some more background on that > decision? > > I guess what I'd really like to see is an oslo.db interface into etcd3. > > -Julia Hi, I think that some projects won't bother with the etcd interface since it would require some major rework of the whole service to get it working. Take Cinder for example. We do complex conditional updates that, as far as I know, cannot be satisfied with etcd's Compare-and-Swap functionality. We could modify all our code to make it support both relational databases and key-value stores, but I'm not convinced it would be worthwhile considering the huge effort it would require. I believe there are other OpenStack projects that have procedural code stored on the database, which would probably be hard to make compatible with key-value stores. Cheers, Gorka. > > On Mon, Dec 3, 2018 at 4:55 PM Fox, Kevin M wrote: > > > It is a full base service already: > > https://governance.openstack.org/tc/reference/base-services.html > > > > Projects have been free to use it for quite some time. I'm not sure if any > > actually are yet though. > > > > It was decided not to put an abstraction layer on top as its pretty simple > > and commonly deployed. > > > > Thanks, > > Kevin > > ------------------------------ > > *From:* Julia Kreger [juliaashleykreger at gmail.com] > > *Sent:* Monday, December 03, 2018 3:53 PM > > *To:* Ben Nemec > > *Cc:* Davanum Srinivas; geguileo at redhat.com; > > openstack-discuss at lists.openstack.org > > *Subject:* Re: [all] Etcd as DLM > > > > I would like to slightly interrupt this train of thought for an > > unscheduled vision of the future! > > > > What if we could allow a component to store data in etcd3's key value > > store like how we presently use oslo_db/sqlalchemy? > > > > While I personally hope to have etcd3 as a DLM for ironic one day, review > > bandwidth permitting, it occurs to me that etcd3 could be leveraged for > > more than just DLM. If we have a common vision to enable data storage, I > > suspect it might help provide overall guidance as to how we want to > > interact with the service moving forward. > > > > -Julia > > > > On Mon, Dec 3, 2018 at 2:52 PM Ben Nemec wrote: > > > >> Hi, > >> > >> I wanted to revisit this topic because it has come up in some downstream > >> discussions around Cinder A/A HA and the last time we talked about it > >> upstream was a year and a half ago[1]. There have certainly been changes > >> since then so I think it's worth another look. For context, the > >> conclusion of that session was: > >> > >> "Let's use etcd 3.x in the devstack CI, projects that are eventlet based > >> an use the etcd v3 http experimental API and those that don't can use > >> the etcd v3 gRPC API. Dims will submit a patch to tooz for the new > >> driver with v3 http experimental API. Projects should feel free to use > >> the DLM based on tooz+etcd3 from now on. Others projects can figure out > >> other use cases for etcd3." > >> > >> The main question that has come up is whether this is still the best > >> practice or if we should revisit the preferred drivers for etcd. Gorka > >> has gotten the grpc-based driver working in a Cinder driver that needs > >> etcd[2], so there's a question as to whether we still need the HTTP > >> etcd-gateway or if everything should use grpc. I will admit I'm nervous > >> about trying to juggle eventlet and grpc, but if it works then my only > >> argument is general misgivings about doing anything clever that involves > >> eventlet. :-) > >> > >> It looks like the HTTP API for etcd has moved out of experimental > >> status[3] at this point, so that's no longer an issue. There was some > >> vague concern from a downstream packaging perspective that the grpc > >> library might use a funky build system, whereas the etcd3-gateway > >> library only depends on existing OpenStack requirements. > >> > >> On the other hand, I don't know how much of a hassle it is to deploy and > >> manage a grpc-gateway. I'm kind of hoping someone has already been down > >> this road and can advise about what they found. > >> > >> Thanks. > >> > >> -Ben > >> > >> 1: https://etherpad.openstack.org/p/BOS-etcd-base-service > >> 2: > >> > >> https://github.com/embercsi/ember-csi/blob/5bd4dffe9107bc906d14a45cd819d9a659c19047/ember_csi/ember_csi.py#L1106-L1111 > >> 3: https://github.com/grpc-ecosystem/grpc-gateway > >> > >> From ervikrant06 at gmail.com Tue Dec 4 11:28:50 2018 From: ervikrant06 at gmail.com (Vikrant Aggarwal) Date: Tue, 4 Dec 2018 16:58:50 +0530 Subject: [neutron] [octavia] Manual deployment step for octavia on packstack Message-ID: Hello Team, Do we have the steps documented somewhere to install octavia manually like we have for zun [1]? I have done the openstack deployment using packstack and now I want to install the octavia manually on it. I have done the following steps: # groupadd --system octavia # useradd --home-dir "/var/lib/octavia" --create-home --system --shell /bin/false -g octavia octavia # cd /var/lib/octavia/ # git clone https://github.com/openstack/octavia.git # chown -R octavia:octavia * # pip install -r requirements.txt # python setup.py install # openstack user create --domain default --password-prompt octavia # openstack role add --project service --user octavia admin # openstack service create --name octavia --description "Octavia Service" "Octavia Load Balancing Servic" # openstack endpoint create --region RegionOne "Octavia Load Balancing Servic" public http://10.121.19.50:9876/v1 # openstack endpoint create --region RegionOne "Octavia Load Balancing Servic" admin http://10.121.19.50:9876/v1 # openstack endpoint create --region RegionOne "Octavia Load Balancing Servic" internal http://10.121.19.50:9876/v1 Made the following changes in the configuration file. [root at packstack1 octavia(keystone_admin)]# diff etc/octavia.conf /etc/octavia/octavia.conf 20,21c20,21 < # bind_host = 127.0.0.1 < # bind_port = 9876 --- > bind_host = 10.121.19.50 > bind_port = 9876 38c38 < # api_v2_enabled = True --- > # api_v2_enabled = False 64c64 < # connection = mysql+pymysql:// --- > connection = mysql+pymysql://octavia:octavia at 10.121.19.50/octavia 109c109 < # www_authenticate_uri = https://localhost:5000/v3 --- > www_authenticate_uri = https://10.121.19.50:5000/v3 111,114c111,114 < # auth_url = https://localhost:5000/v3 < # username = octavia < # password = password < # project_name = service --- > auth_url = https://10.121.19.50:35357/v3 > username = octavia > password = octavia > project_name = service 117,118c117,118 < # project_domain_name = Default < # user_domain_name = Default --- > project_domain_name = default > user_domain_name = default Generated the certificates using the script and copy the following certificates in octavia: [root at packstack1 octavia(keystone_admin)]# cd /etc/octavia/ [root at packstack1 octavia(keystone_admin)]# ls -lhrt total 28K -rw-r--r--. 1 octavia octavia 14K Dec 4 05:50 octavia.conf -rw-r--r--. 1 octavia octavia 1.7K Dec 4 05:55 client.key -rw-r--r--. 1 octavia octavia 989 Dec 4 05:55 client.csr -rw-r--r--. 1 octavia octavia 1.7K Dec 4 05:55 client.pem Can anyone please guide me about the further configuration? [1] https://docs.openstack.org/zun/latest/install/controller-install.html Thanks & Regards, Vikrant Aggarwal -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaypipes at gmail.com Tue Dec 4 12:52:10 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Tue, 4 Dec 2018 07:52:10 -0500 Subject: [all] Etcd as DLM In-Reply-To: References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> Message-ID: <208e0023-cb4d-1b7f-9f31-b186a9c45f4c@gmail.com> On 12/03/2018 06:53 PM, Julia Kreger wrote: > I would like to slightly interrupt this train of thought for an > unscheduled vision of the future! > > What if we could allow a component to store data in etcd3's key value > store like how we presently use oslo_db/sqlalchemy? > > While I personally hope to have etcd3 as a DLM for ironic one day, > review bandwidth permitting, it occurs to me that etcd3 could be > leveraged for more than just DLM. If we have a common vision to enable > data storage, I suspect it might help provide overall guidance as to how > we want to interact with the service moving forward. Considering Ironic doesn't have a database schema that really uses the relational database properly, I think this is an excellent idea. [1] Ironic's database schema is mostly a bunch of giant JSON BLOB fields that are (ab)used by callers to add unstructured data pointing at a node's UUID. Which is pretty much what a KVS like etcd was made for, so I say, go for it. Best, -jay [1] The same can be said for quite a few tables in Nova's cell DB, namely compute_nodes, instance_info_caches, instance_metadata, instance_system_metadata, instance_extra, instance_actions, instance_action_events and pci_devices. And Nova's API DB has the aggregate_metadata, flavor_extra_specs, request_specs, build_requests and key_pairs tables, all of which are good candidates for non-relational storage. From jaypipes at gmail.com Tue Dec 4 13:00:53 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Tue, 4 Dec 2018 08:00:53 -0500 Subject: [dev][nova][placement][qa] opinion on adding placement tests support in Tempest In-Reply-To: References: <16778b864ea.ed28ea0d72714.6704537180908793759@ghanshyammann.com> Message-ID: <52060b98-74f5-3a3a-1b51-8cba8aa7b00c@gmail.com> On 12/04/2018 06:13 AM, Chris Dent wrote: > On Tue, 4 Dec 2018, Ghanshyam Mann wrote: > >> Before we start or proceed with the discussion in QA, i would like to >> get the nova(placement) team opinion on adding the placement support >> in Tempest. Obviously, we should not duplicate the testing effort >> between what existing gabbi tests cover or what going to be added in >> Tempest which we can take care while adding the new tests. > > My feeling on this is that what should be showing up in tempest with > regard to placement tests are things that demonstrate and prove end > to end scenarios in which placement is involved as a critical part, > but is in the background. For example, things like the emerging minimal > bandwidth functionality that involves all three of nova, placement > and neutron. > > I don't think we need extensive testing in Tempest of the placement > API itself, as that's already well covered by the existing > functional tests, nor do I think it makes much sense to cover the > common scheduling scenarios between nova and placement as those are > also well covered and will continue to be covered even with > placement extracted [1]. > > Existing Tempests tests that do things like launching, resizing, > migrating servers already touch placement so may be sufficient. If > we wanted to make these more complete adding verification of > resource providers and their inventories before and after the tests > might be useful. Fully agree with Chris' assessment on this. Best, -jay From thierry at openstack.org Tue Dec 4 13:15:30 2018 From: thierry at openstack.org (Thierry Carrez) Date: Tue, 4 Dec 2018 14:15:30 +0100 Subject: [all] Etcd as DLM In-Reply-To: References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> <1A3C52DFCD06494D8528644858247BF01C24C6BD@EX10MBOX03.pnnl.gov> Message-ID: <3ebe82c8-ea86-566b-faff-b9f2fd22009a@openstack.org> Julia Kreger wrote: > Indeed it is a considered a base service, but I'm unaware of why it was > decided to not have any abstraction layer on top. That sort of defeats > the adoption of tooz as a standard in the community. Plus with the rest > of our code bases, we have a number of similar or identical patterns and > it would be ideal to have a single library providing the overall > interface for the purposes of consistency. Could you provide some more > background on that decision? Dims can probably summarize it better than I can do. When we were discussing adding a DLM as a base service, we had a lot of discussion at several events and on several threads weighing that option (a "tooz-compatible DLM" vs. "etcd"). IIRC the final decision had to do with leveraging specific etcd features vs. using the smallest common denominator, while we expect everyone to be deploying etcd. > I guess what I'd really like to see is an oslo.db interface into etcd3. Not sure that is what you're looking for, but the concept of an oslo.db interface to a key-value store was explored by a research team and the FEMDC WG (Fog/Edge/Massively-distributed Clouds), in the context of distributing Nova data around. Their ROME oslo.db driver PoC was using Redis, but I think it could be adapted to use etcd quite easily. Some pointers: https://github.com/beyondtheclouds/rome https://www.openstack.org/videos/austin-2016/a-ring-to-rule-them-all-revising-openstack-internals-to-operate-massively-distributed-clouds -- Thierry Carrez (ttx) From dprince at redhat.com Tue Dec 4 13:16:30 2018 From: dprince at redhat.com (Dan Prince) Date: Tue, 04 Dec 2018 08:16:30 -0500 Subject: [Nova] Increase size limits for user data In-Reply-To: References: Message-ID: <7a06df3739d66083a5042ad6346f77e1b8081f65.camel@redhat.com> On Tue, 2018-12-04 at 12:08 +0100, Flavio Percoco wrote: > Greetings, > > I've been working on a tool that requires creating CoreOS nodes on > OpenStack. Sadly, I've hit the user data limit, which has blocked the > work I'm doing. > > One big difference between CoreOS images and other cloud images out > there is that CoreOS images don't use cloud-init but a different tool > called Ignition[0], which uses JSON as its serialization format. > > The size of the configs that I need to pass to the instance is bigger > than the limit imposed by Nova. I've worked on reducing the size as > much as possible and even generating a compressed version of it but > the data is still bigger than the limit (144 kb vs 65kb). > > I'd like to understand better what the nature of the limit is (is it > because of the field size in the database? Is it purely an API limit? > Is it because it causes problems depending on the vendor? As far as I > can tell the limit is just being enforced by the API schema[1] and > not > the DB as it uses a MEDIUMTEXT field. > > I realize this has been asked before but I wanted to get a feeling of > the current opinion about this. Would the Nova team consider > increasing the limit of the API considering that more use cases like > this may be more common these days? I think EC2 only gives you 1/4 of what Nova does (16KB or so). So it would seem Nova is already being somewhat generous here. I don't see any harm in increasing it so long as the DB supports it (no DB schema change would be required). I wonder if pairing userdata with a token that allowed you to download the information from another (much larger) data source would be a better pattern here though. Then you could make it as large as you needed. Dan > > [0] https://coreos.com/ignition/docs/latest/ > [1] > https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/servers.py#L212-L215 > > Thanks, > Flavio > From ervikrant06 at gmail.com Tue Dec 4 13:19:41 2018 From: ervikrant06 at gmail.com (Vikrant Aggarwal) Date: Tue, 4 Dec 2018 18:49:41 +0530 Subject: [openstack-dev] [magnum] [Rocky] K8 deployment on fedora-atomic is failed In-Reply-To: References: Message-ID: Hello Team, Any help on this issue? Thanks & Regards, Vikrant Aggarwal On Fri, Nov 30, 2018 at 9:13 AM Vikrant Aggarwal wrote: > 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: From jaypipes at gmail.com Tue Dec 4 13:47:37 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Tue, 4 Dec 2018 08:47:37 -0500 Subject: [all] Etcd as DLM In-Reply-To: <3ebe82c8-ea86-566b-faff-b9f2fd22009a@openstack.org> References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> <1A3C52DFCD06494D8528644858247BF01C24C6BD@EX10MBOX03.pnnl.gov> <3ebe82c8-ea86-566b-faff-b9f2fd22009a@openstack.org> Message-ID: <0c5a4a87-2ee8-f6d4-8de0-f693d70df7ee@gmail.com> On 12/04/2018 08:15 AM, Thierry Carrez wrote: > Julia Kreger wrote: >> Indeed it is a considered a base service, but I'm unaware of why it >> was decided to not have any abstraction layer on top. That sort of >> defeats the adoption of tooz as a standard in the community. Plus with >> the rest of our code bases, we have a number of similar or identical >> patterns and it would be ideal to have a single library providing the >> overall interface for the purposes of consistency. Could you provide >> some more background on that decision? > > Dims can probably summarize it better than I can do. > > When we were discussing adding a DLM as a base service, we had a lot of > discussion at several events and on several threads weighing that option > (a "tooz-compatible DLM" vs. "etcd"). IIRC the final decision had to do > with leveraging specific etcd features vs. using the smallest common > denominator, while we expect everyone to be deploying etcd. > >> I guess what I'd really like to see is an oslo.db interface into etcd3. > > Not sure that is what you're looking for, but the concept of an oslo.db > interface to a key-value store was explored by a research team and the > FEMDC WG (Fog/Edge/Massively-distributed Clouds), in the context of > distributing Nova data around. Their ROME oslo.db driver PoC was using > Redis, but I think it could be adapted to use etcd quite easily. Note that it's not appropriate to replace *all* use of an RDBMS in OpenStack-land with etcd. I hope I wasn't misunderstood in my statement earlier. Just *some* use cases are better served by a key/value store, and etcd3's transactions and watches are a great tool for solving *some* use cases -- but definitely not all :) Anyway, just making sure nobody's going to accuse me of saying OpenStack should abandon all RDBMS use for a KVS. :) Best, -jay > Some pointers: > > https://github.com/beyondtheclouds/rome > > https://www.openstack.org/videos/austin-2016/a-ring-to-rule-them-all-revising-openstack-internals-to-operate-massively-distributed-clouds > > From bcafarel at redhat.com Tue Dec 4 14:01:17 2018 From: bcafarel at redhat.com (Bernard Cafarelli) Date: Tue, 4 Dec 2018 15:01:17 +0100 Subject: [openstack-dev] [Neutron] Propose Hongbin Lu for Neutron core In-Reply-To: References: <493CB94D-19C3-4B61-8577-6BD98006B7F5@redhat.com> Message-ID: Not a core, but definitely +1 from me, I think most Neutron reviews I went through had comments or feedback from Hongbin Lu! On Tue, 4 Dec 2018 at 03:05, LIU Yulong wrote: > +1 > > On Tue, Dec 4, 2018 at 6:43 AM Slawomir Kaplonski > wrote: > >> Definitely big +1 from me! >> >> — >> Slawek Kaplonski >> Senior software engineer >> Red Hat >> >> > Wiadomość napisana przez Miguel Lavalle w dniu >> 03.12.2018, o godz. 23:14: >> > >> > Hi Stackers, >> > >> > I want to nominate Hongbin Lu (irc: hongbin) as a member of the Neutron >> core team. Hongbin started contributing to the OpenStack community in the >> Liberty cycle. Over time, he made great contributions in helping the >> community to better support containers by being core team member and / or >> PTL in projects such as Zun and Magnum. An then, fortune played in our >> favor and Hongbin joined the Neutron team in the Queens cycle. Since then, >> he has made great contributions such as filters validation in the ReST API, >> PF status propagation to to VFs (ports) in SR-IOV environments and leading >> the forking of RYU into the os-ken OpenStack project, which provides key >> foundational functionality for openflow. He is not a man who wastes words, >> but when he speaks up, his opinions are full of insight. This is reflected >> in the quality of his code reviews, which in number are on par with the >> leading members of the core team: >> http://stackalytics.com/?module=neutron-group. Even though Hongbin >> leaves in Toronto, he speaks Mandarin Chinese and was born and raised in >> China. This is a big asset in helping the Neutron team to incorporate use >> cases from that part of the world. >> > >> > Hongbin spent the past few months being mentored by Slawek Kaplonski, >> who has reported that Hongbin is ready for the challenge of being a core >> team member. I (and other core team members) concur. >> > >> > I will keep this nomination open for a week as customary. >> > >> > Thank you >> > >> > Miguel >> >> >> -- Bernard Cafarelli -------------- next part -------------- An HTML attachment was scrubbed... URL: From mihalis68 at gmail.com Tue Dec 4 14:12:24 2018 From: mihalis68 at gmail.com (Chris Morgan) Date: Tue, 4 Dec 2018 09:12:24 -0500 Subject: [ops] last week's Ops Meetups team minutes Message-ID: Meeting ended Tue Nov 27 15:56:56 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 10:57 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_team.2018-11-27-15.00.html 10:57 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_team.2018-11-27-15.00.txt 10:57 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_team.2018-11-27-15.00.log.html Next meeting in just under an hour from now on #openstack-operators Chris -- Chris Morgan -------------- next part -------------- An HTML attachment was scrubbed... URL: From flavio at redhat.com Tue Dec 4 14:14:20 2018 From: flavio at redhat.com (Flavio Percoco) Date: Tue, 4 Dec 2018 15:14:20 +0100 Subject: [Nova] Increase size limits for user data In-Reply-To: <7a06df3739d66083a5042ad6346f77e1b8081f65.camel@redhat.com> References: <7a06df3739d66083a5042ad6346f77e1b8081f65.camel@redhat.com> Message-ID: On Tue, Dec 4, 2018 at 2:16 PM Dan Prince wrote: > > On Tue, 2018-12-04 at 12:08 +0100, Flavio Percoco wrote: > > Greetings, > > > > I've been working on a tool that requires creating CoreOS nodes on > > OpenStack. Sadly, I've hit the user data limit, which has blocked the > > work I'm doing. > > > > One big difference between CoreOS images and other cloud images out > > there is that CoreOS images don't use cloud-init but a different tool > > called Ignition[0], which uses JSON as its serialization format. > > > > The size of the configs that I need to pass to the instance is bigger > > than the limit imposed by Nova. I've worked on reducing the size as > > much as possible and even generating a compressed version of it but > > the data is still bigger than the limit (144 kb vs 65kb). > > > > I'd like to understand better what the nature of the limit is (is it > > because of the field size in the database? Is it purely an API limit? > > Is it because it causes problems depending on the vendor? As far as I > > can tell the limit is just being enforced by the API schema[1] and > > not > > the DB as it uses a MEDIUMTEXT field. > > > > I realize this has been asked before but I wanted to get a feeling of > > the current opinion about this. Would the Nova team consider > > increasing the limit of the API considering that more use cases like > > this may be more common these days? > > I think EC2 only gives you 1/4 of what Nova does (16KB or so). So it > would seem Nova is already being somewhat generous here. > Yeah, I checked before sending this and I thought that regardless of what EC2 is doing, I think it'd be nice for us to consider the use case. > I don't see any harm in increasing it so long as the DB supports it (no > DB schema change would be required). > > I wonder if pairing userdata with a token that allowed you to download > the information from another (much larger) data source would be a > better pattern here though. Then you could make it as large as you > needed. This is the current solution, which has allowed me to move forward with the work I'm doing. Regardless, I would like us to discuss this. I'd rather have the limit in Nova increased than adding a dependency on another service that would, very likely, only be used for this specific use case. Flavio From mihalis68 at gmail.com Tue Dec 4 14:17:07 2018 From: mihalis68 at gmail.com (Chris Morgan) Date: Tue, 4 Dec 2018 09:17:07 -0500 Subject: [ops] Ops Meetup proposal, Berlin, early 2019 Message-ID: Hello Everyone, Deutsche Telekom has kindly offered to host an OpenStack Operators Meetup early next year see https://etherpad.openstack.org/p/ops-meetup-venue-discuss-1st-2019-berlin This is the only current offer so far for the first Ops Meetup of 2019 so is very likely to be approved. If you have feedback on this please join us at our weekly IRC meeting or forward your feedback to an Ops Meetups Team member (see https://wiki.openstack.org/wiki/Ops_Meetups_Team for details of the current team). This proposal meets the consensus goal of Europe as the region for the 1st meetup, making it likely that the following one later in 2019 would be in North America. Chris -- Chris Morgan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdobreli at redhat.com Tue Dec 4 14:29:14 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Tue, 4 Dec 2018 15:29:14 +0100 Subject: [all][FEMDC] Etcd as DLM In-Reply-To: <3ebe82c8-ea86-566b-faff-b9f2fd22009a@openstack.org> References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> <1A3C52DFCD06494D8528644858247BF01C24C6BD@EX10MBOX03.pnnl.gov> <3ebe82c8-ea86-566b-faff-b9f2fd22009a@openstack.org> Message-ID: On 12/4/18 2:15 PM, Thierry Carrez wrote: > Not sure that is what you're looking for, but the concept of an oslo.db > interface to a key-value store was explored by a research team and the > FEMDC WG (Fog/Edge/Massively-distributed Clouds), in the context of > distributing Nova data around. Their ROME oslo.db driver PoC was using > Redis, but I think it could be adapted to use etcd quite easily. > > Some pointers: > > https://github.com/beyondtheclouds/rome > > https://www.openstack.org/videos/austin-2016/a-ring-to-rule-them-all-revising-openstack-internals-to-operate-massively-distributed-clouds That's interesting, thank you! I'd like to remind though that Edge/Fog cases assume high latency, which is not the best fit for strongly consistent oslo.db data backends, like Etcd or Galera. Technically, it had been proved in the past a few years that only causal consistency, which is like eventual consistency but works much better for end users [0], is a way to go for Edge clouds. Except that there is *yet* a decent implementation exists of a causal consistent KVS! So my take is, if we'd ever want to redesign ORM transactions et al to CAS operations and KVS, it should be done not for Etcd in mind, but a future causal consistent solution. [0] https://www.usenix.org/system/files/login/articles/08_lloyd_41-43_online.pdf -- Best regards, Bogdan Dobrelya, Irc #bogdando From haleyb.dev at gmail.com Tue Dec 4 14:57:43 2018 From: haleyb.dev at gmail.com (Brian Haley) Date: Tue, 4 Dec 2018 09:57:43 -0500 Subject: [openstack-dev] [Neutron] Propose Nate Johnston for Neutron core In-Reply-To: References: Message-ID: Big +1 from me, keep up the great work Nate! -Brian On 12/3/18 4:38 PM, Miguel Lavalle wrote: > Hi Stackers, > > I want to nominate Nate Johnston (irc:njohnston) as a member of the > Neutron core team. Nate started contributing to Neutron back in the > Liberty cycle. One of the highlight contributions of that early period > is his collaboration with others to implement DSCP QoS rules > (https://review.openstack.org/#/c/251738/). After a hiatus of a few > cycles, we were lucky to have Nate come back to the community during the > Rocky cycle. Since then, he has been a driving force in the adoption in > Neutron of Oslo Versioned Objects, the "Run under Python 3 by default" > community wide initiative and the optimization of ports creation in bulk > to better support containerized workloads. He is a man with a wide range > of interests, who is not afraid of expressing his opinions in any of > them.  The quality and number of his code reviews during the Stein cycle > is on par with the leading members of the core team: > http://stackalytics.com/?module=neutron-group.  I especially admire his > ability to forcefully handle disagreement in a friendly and easy going > manner. > > On top of all that, he graciously endured me as his mentor over the past > few months. For all these reasons, I think he is ready to join the team > and we will be very lucky to have him as a fully voting core. > > I will keep this nomination open for a week as customary. > > Thank you > > Miguel > > From haleyb.dev at gmail.com Tue Dec 4 14:57:55 2018 From: haleyb.dev at gmail.com (Brian Haley) Date: Tue, 4 Dec 2018 09:57:55 -0500 Subject: [openstack-dev] [Neutron] Propose Hongbin Lu for Neutron core In-Reply-To: References: Message-ID: <726003a1-da0b-f542-00b2-a7900cc308d9@gmail.com> Big +1 from me as well! -Brian On 12/3/18 5:14 PM, Miguel Lavalle wrote: > Hi Stackers, > > I want to nominate Hongbin Lu (irc: hongbin) as a member of the Neutron > core team. Hongbin started contributing to the OpenStack community in > the Liberty cycle. Over time, he made great contributions in helping the > community to better support containers by being core team member and / > or PTL in projects such as Zun and Magnum. An then, fortune played in > our favor and Hongbin joined the Neutron team in the Queens cycle. Since > then, he has made great contributions such as filters validation in the > ReST API, PF status propagation to to VFs (ports) in SR-IOV environments > and leading the forking of RYU into the os-ken OpenStack project, which > provides key foundational functionality for openflow. He is not a man > who wastes words, but when he speaks up, his opinions are full of > insight. This is reflected in the quality of his code reviews, which in > number are on par with the leading members of the core team: > http://stackalytics.com/?module=neutron-group. Even though Hongbin > leaves in Toronto, he speaks Mandarin Chinese and was born and raised in > China. This is a big asset in helping the Neutron team to incorporate > use cases from that part of the world. > > Hongbin spent the past few months being mentored by Slawek Kaplonski, > who has reported that Hongbin is ready for the challenge of being a core > team member. I (and other core team members) concur. > > I will keep this nomination open for a week as customary. > > Thank you > > Miguel From mriedemos at gmail.com Tue Dec 4 15:09:30 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Tue, 4 Dec 2018 09:09:30 -0600 Subject: [Nova] Increase size limits for user data In-Reply-To: References: <7a06df3739d66083a5042ad6346f77e1b8081f65.camel@redhat.com> Message-ID: On 12/4/2018 8:14 AM, Flavio Percoco wrote: > This is the current solution, which has allowed me to move forward > with the work I'm doing. Regardless, I would like us to discuss this. > I'd rather have the limit in Nova increased than adding a dependency > on another service that would, very likely, only be used for this > specific use case. As far as the DB limit, it's not just the actual instances.user_data table that matters [1] it's also the build_requests.instance column [2] and the latter is the bigger issue since it's an entire Instance object, including the user_data plus whatever else (like the flavor, metadata and system_metadata) serialized into that single MEDIUMTEXT field. That's what worries me about blowing up that field if we increase the API limit on user_data. As for passing a handle to a thing in another service, we have talked a few times about integrating with a service like Glare to allow users to pass a baremetal node RAID config handle when creating a server and then nova would pull the spec down from Glare and pass it on to the virt driver. We could do the same thing here I would think. Glare is just a generic artifact repository right? I think that would be a better long-term solution for these problems rather than trying to make nova a blob store. [1] https://github.com/openstack/nova/blob/5f648dda49a6d5fe5ecfd7dddcb5f7dc3d6b51a6/nova/db/sqlalchemy/models.py#L288 [2] https://github.com/openstack/nova/blob/5f648dda49a6d5fe5ecfd7dddcb5f7dc3d6b51a6/nova/db/sqlalchemy/api_models.py#L250 -- Thanks, Matt From chkumar246 at gmail.com Tue Dec 4 15:10:42 2018 From: chkumar246 at gmail.com (Chandan kumar) Date: Tue, 4 Dec 2018 20:40:42 +0530 Subject: [tripleo][openstack-ansible] collaboration on os_tempest role update II Message-ID: Hello, It's more than 2 weeks, here is the another updates on what we have done till today i.e. on Dec 4th, 2018 on collaborating on os_tempest role [1]. * Add centos-7 job with support to python-tempestconf - https://review.openstack.org/#/c/619021/ * Enable support to pass override option to tempestconf - https://review.openstack.org/#/c/619986/ * Added task to list tempest tests - https://review.openstack.org/619024 Work still going on: * Use tempest run for generating subunit results - https://review.openstack.org/621584 * python-tempestconf extra cli support in os_tempest - https://review.openstack.org/620800 * Better blacklist and whitelist tests management - https://review.openstack.org/621605 In upcoming two weeks, we are planning to finish * complete python-tempestconf named_arguments support in os_tempest * Better blacklist and whitelist tests management. Here is the first update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136452.html Thanks, Chandan Kumar From jaypipes at gmail.com Tue Dec 4 15:27:23 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Tue, 4 Dec 2018 10:27:23 -0500 Subject: [Nova] Increase size limits for user data In-Reply-To: References: <7a06df3739d66083a5042ad6346f77e1b8081f65.camel@redhat.com> Message-ID: On 12/04/2018 10:09 AM, Matt Riedemann wrote: > On 12/4/2018 8:14 AM, Flavio Percoco wrote: >> This is the current solution, which has allowed me to move forward >> with the work I'm doing. Regardless, I would like us to discuss this. >> I'd rather have the limit in Nova increased than adding a dependency >> on another service that would, very likely, only be used for this >> specific use case. > > As far as the DB limit, it's not just the actual instances.user_data > table that matters [1] it's also the build_requests.instance column [2] > and the latter is the bigger issue since it's an entire Instance object, > including the user_data plus whatever else (like the flavor, metadata > and system_metadata) serialized into that single MEDIUMTEXT field. > That's what worries me about blowing up that field if we increase the > API limit on user_data. How prescient. :) http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000523.html Best, -jay From dmellado at redhat.com Tue Dec 4 15:27:26 2018 From: dmellado at redhat.com (Daniel Mellado) Date: Tue, 4 Dec 2018 16:27:26 +0100 Subject: [openstack-dev] [kuryr] kuryr libnetwork installation inside the vm is failing In-Reply-To: References: Message-ID: <70b7da13-282c-9b48-68b2-24a59b718ae3@redhat.com> If you check here our issue lies on subprocess32 dependencies, not really on anything kuryr related. Please make sure you're able to install this package and that you match all deps here before retrying! Thanks! On 30/11/18 5:04, Vikrant Aggarwal wrote: >   Running setup.py install for subprocess32 ... error -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x13DDF774E05F5B85.asc Type: application/pgp-keys Size: 2208 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From msm at redhat.com Tue Dec 4 15:34:08 2018 From: msm at redhat.com (Michael McCune) Date: Tue, 4 Dec 2018 10:34:08 -0500 Subject: [sigs] Monthly Update In-Reply-To: References: Message-ID: hi Melvin, i think this is a nice idea to help increase communications but i would like to share a few things i observed over the time we published the API-SIG newsletter. 1. sometimes not much changes. we noticed this trend as the SIG become more and more mature, basically there were fewer and fewer weekly items to report. perhaps a monthly cadence will be better for collecting input from the various SIGs, but just a heads up that it is possible for some groups to have slow movement between updates. 2. tough to gauge readership. this was always something i was curious about, we never had many (or really any) responses to our newsletters. i did receive a few personal notes of appreciation, which were tremendous boosts, but aside from that it was difficult to know if our message was getting across. 3. are we talking to ourselves? this kinda follows point 2, depending on how the newsletter is received it is entirely possible that we were just publishing our newsletter for ourselves. i like to think this wasn't the case, but i think it's something to be aware of as we start to ask SIGs to take time to contribute. mind you, i don't think any of these points should dissuade the community from publishing a SIG newsletter. i wanted to share my experiences just to help build awareness as we launch this new effort. peace o/ On Mon, Dec 3, 2018 at 6:16 PM Melvin Hillsman wrote: > > Hi everyone, > > During the Forum we discussed one simple way we could move forward to hopefully get more visibility and activity within SIGs. Here is a proposal for such a step. Send out a monthly email to openstack-discuss with the following information from each SIG captured via etherpad [0] > > 1. What success(es) have you had this month as a SIG? > 2. What should we know about the SIG for the next month? > 3. What would you like help (hands) or feedback (eyes) on? > > Besides the ML, other places this could be re-used in whole or part is on social media, SU Blog, etc. Thoughts? > > [0] https://etherpad.openstack.org/p/sig-updates > -- > Kind regards, > > Melvin Hillsman > mrhillsman at gmail.com > mobile: (832) 264-2646 From bodenvmw at gmail.com Tue Dec 4 15:38:29 2018 From: bodenvmw at gmail.com (Boden Russell) Date: Tue, 4 Dec 2018 08:38:29 -0700 Subject: [dev][neutron] neutron-lib work items Message-ID: Awhile back we asked for volunteers willing to help with the neutron-lib effort [1]. Now that we have some volunteers [2], I've gone ahead and added some high-level work items to that list [2]. For those who choose to drive one of the items, please put your name next to it so that we don't step on each others toes during the effort. Feel free to reach out to me for questions/details. Also a friendly reminder to all; please help out this effort by reviewing neutron-lib patches as they arrive in your project's review queue. Thanks [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/135279.html [2] https://etherpad.openstack.org/p/neutron-lib-volunteers-and-punch-list From thierry at openstack.org Tue Dec 4 15:45:20 2018 From: thierry at openstack.org (Thierry Carrez) Date: Tue, 4 Dec 2018 16:45:20 +0100 Subject: [tc] Adapting office hours schedule to demand Message-ID: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> Hi, A while ago, the Technical Committee designated specific hours in the week where members would make extra effort to be around on #openstack-tc on IRC, so that community members looking for answers to their questions or wanting to engage can find a time convenient for them and a critical mass of TC members around. We currently have 3 weekly spots: - 09:00 UTC on Tuesdays - 01:00 UTC on Wednesdays - 15:00 UTC on Thursdays But after a few months it appears that: 1/ nobody really comes on channel at office hour time to ask questions. We had a questions on the #openstack-tc IRC channel, but I wouldn't say people take benefit of the synced time 2/ some office hours (most notably the 01:00 UTC on Wednesdays, but also to a lesser extent the 09:00 UTC on Tuesdays) end up just being a couple of TC members present So the schedule is definitely not reaching its objectives, and as such may be a bit overkill. I was also wondering if this is not a case where the offer is hurting the demand -- by having so many office hour spots around, nobody considers them special. Should we: - Reduce office hours to one or two per week, possibly rotating times - Dump the whole idea and just encourage people to ask questions at any time on #openstack-tc, and get asynchronous answers - Keep it as-is, it still has the side benefit of triggering spikes of TC member activity Thoughts ? -- Thierry Carrez (ttx) From doug at doughellmann.com Tue Dec 4 16:04:13 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Tue, 4 Dec 2018 11:04:13 -0500 Subject: [Release-job-failures][release][tripleo] Tag of openstack/tripleo-heat-templates failed In-Reply-To: References: Message-ID: > On Dec 4, 2018, at 11:00 AM, zuul at openstack.org wrote: > > Build failed. > > - publish-openstack-releasenotes-python3 http://logs.openstack.org/7b/7baea84f1168d72b0eb8901da47d5f4efbaccff8/tag/publish-openstack-releasenotes-python3/2d5a462/ : POST_FAILURE in 5m 02s > - publish-openstack-releasenotes http://logs.openstack.org/7b/7baea84f1168d72b0eb8901da47d5f4efbaccff8/tag/publish-openstack-releasenotes/6088133/ : SUCCESS in 5m 04s > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures It looks like tripleo-heat-templates still has both release notes jobs configured, so there was a race condition in publishing. Doug From zufar at onf-ambassador.org Tue Dec 4 16:10:58 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Tue, 4 Dec 2018 23:10:58 +0700 Subject: Octavia Production Deployment Confused Message-ID: Hi, I want to implement Octavia service in OpenStack Queens. I am stuck on two-step : 1. Create Octavia User I am trying to create Octavia user with this command, is this the right way? openstack user create octavia --domain default --password octavia openstack role add --user octavia --project services admin openstack service create --name octavia --description "OpenStack Octavia" load-balancer openstack endpoint create --region RegionOne octavia public http://10.60.60.10:9876 openstack endpoint create --region RegionOne octavia internal http://10.60.60.10:9876 openstack endpoint create --region RegionOne octavia admin http://10.60.60.10:9876 2. Load Balancer Network Configuration "Add appropriate routing to/from the ‘lb-mgmt-net’ such that egress is allowed, and the controller (to be created later) can talk to hosts on this network." I don't know how to route from controller host into a private network, is any specific command for doing that? following tutorial from https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html#running-octavia-in-production . Thank You Best Regards, Zufar Dhiyaulhaq -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufardhiyaulhaq at gmail.com Tue Dec 4 16:15:46 2018 From: zufardhiyaulhaq at gmail.com (Zufar Dhiyaulhaq) Date: Tue, 4 Dec 2018 23:15:46 +0700 Subject: Octavia Production Deployment Confused Message-ID: Hi, I want to implement Octavia service in OpenStack Queens. I am stuck on two-step : 1. Create Octavia User I am trying to create Octavia user with this command, is this the right way? openstack user create octavia --domain default --password octavia openstack role add --user octavia --project services admin openstack service create --name octavia --description "OpenStack Octavia" load-balancer openstack endpoint create --region RegionOne octavia public http://10.60.60.10:9876 openstack endpoint create --region RegionOne octavia internal http://10.60.60.10:9876 openstack endpoint create --region RegionOne octavia admin http://10.60.60.10:9876 2. Load Balancer Network Configuration "Add appropriate routing to/from the ‘lb-mgmt-net’ such that egress is allowed, and the controller (to be created later) can talk to hosts on this network." I don't know how to route from controller host into a private network, is any specific command for doing that? following tutorial from https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html#running-octavia-in-production . Thank You Best Regards, Zufar Dhiyaulhaq -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilien at redhat.com Tue Dec 4 16:23:44 2018 From: emilien at redhat.com (Emilien Macchi) Date: Tue, 4 Dec 2018 11:23:44 -0500 Subject: [Release-job-failures][release][tripleo] Tag of openstack/tripleo-heat-templates failed In-Reply-To: References: Message-ID: I'm looking into it now. On Tue, Dec 4, 2018 at 11:11 AM Doug Hellmann wrote: > > > > On Dec 4, 2018, at 11:00 AM, zuul at openstack.org wrote: > > > > Build failed. > > > > - publish-openstack-releasenotes-python3 > http://logs.openstack.org/7b/7baea84f1168d72b0eb8901da47d5f4efbaccff8/tag/publish-openstack-releasenotes-python3/2d5a462/ > : POST_FAILURE in 5m 02s > > - publish-openstack-releasenotes > http://logs.openstack.org/7b/7baea84f1168d72b0eb8901da47d5f4efbaccff8/tag/publish-openstack-releasenotes/6088133/ > : SUCCESS in 5m 04s > > > > _______________________________________________ > > Release-job-failures mailing list > > Release-job-failures at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > > It looks like tripleo-heat-templates still has both release notes jobs > configured, so there was a race condition in publishing. > > Doug > > > -- Emilien Macchi -------------- next part -------------- An HTML attachment was scrubbed... URL: From openstack at nemebean.com Tue Dec 4 16:42:05 2018 From: openstack at nemebean.com (Ben Nemec) Date: Tue, 4 Dec 2018 10:42:05 -0600 Subject: [all] Etcd as DLM In-Reply-To: <20181204100812.og33xegl2fxmoo6g@localhost> References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> <1A3C52DFCD06494D8528644858247BF01C24C6BD@EX10MBOX03.pnnl.gov> <20181204100812.og33xegl2fxmoo6g@localhost> Message-ID: Copying Mike Bayer since he's our resident DB expert. One more comment inline. On 12/4/18 4:08 AM, Gorka Eguileor wrote: > On 03/12, Julia Kreger wrote: >> Indeed it is a considered a base service, but I'm unaware of why it was >> decided to not have any abstraction layer on top. That sort of defeats the >> adoption of tooz as a standard in the community. Plus with the rest of our >> code bases, we have a number of similar or identical patterns and it would >> be ideal to have a single library providing the overall interface for the >> purposes of consistency. Could you provide some more background on that >> decision? >> >> I guess what I'd really like to see is an oslo.db interface into etcd3. >> >> -Julia > > Hi, > > I think that some projects won't bother with the etcd interface since it > would require some major rework of the whole service to get it working. I don't think Julia was suggesting that every project move to etcd, just that we make it available for projects that want to use it this way. > > Take Cinder for example. We do complex conditional updates that, as far > as I know, cannot be satisfied with etcd's Compare-and-Swap > functionality. We could modify all our code to make it support both > relational databases and key-value stores, but I'm not convinced it > would be worthwhile considering the huge effort it would require. > > I believe there are other OpenStack projects that have procedural code > stored on the database, which would probably be hard to make compatible > with key-value stores. > > Cheers, > Gorka. > >> >> On Mon, Dec 3, 2018 at 4:55 PM Fox, Kevin M wrote: >> >>> It is a full base service already: >>> https://governance.openstack.org/tc/reference/base-services.html >>> >>> Projects have been free to use it for quite some time. I'm not sure if any >>> actually are yet though. >>> >>> It was decided not to put an abstraction layer on top as its pretty simple >>> and commonly deployed. >>> >>> Thanks, >>> Kevin >>> ------------------------------ >>> *From:* Julia Kreger [juliaashleykreger at gmail.com] >>> *Sent:* Monday, December 03, 2018 3:53 PM >>> *To:* Ben Nemec >>> *Cc:* Davanum Srinivas; geguileo at redhat.com; >>> openstack-discuss at lists.openstack.org >>> *Subject:* Re: [all] Etcd as DLM >>> >>> I would like to slightly interrupt this train of thought for an >>> unscheduled vision of the future! >>> >>> What if we could allow a component to store data in etcd3's key value >>> store like how we presently use oslo_db/sqlalchemy? >>> >>> While I personally hope to have etcd3 as a DLM for ironic one day, review >>> bandwidth permitting, it occurs to me that etcd3 could be leveraged for >>> more than just DLM. If we have a common vision to enable data storage, I >>> suspect it might help provide overall guidance as to how we want to >>> interact with the service moving forward. >>> >>> -Julia >>> >>> On Mon, Dec 3, 2018 at 2:52 PM Ben Nemec wrote: >>> >>>> Hi, >>>> >>>> I wanted to revisit this topic because it has come up in some downstream >>>> discussions around Cinder A/A HA and the last time we talked about it >>>> upstream was a year and a half ago[1]. There have certainly been changes >>>> since then so I think it's worth another look. For context, the >>>> conclusion of that session was: >>>> >>>> "Let's use etcd 3.x in the devstack CI, projects that are eventlet based >>>> an use the etcd v3 http experimental API and those that don't can use >>>> the etcd v3 gRPC API. Dims will submit a patch to tooz for the new >>>> driver with v3 http experimental API. Projects should feel free to use >>>> the DLM based on tooz+etcd3 from now on. Others projects can figure out >>>> other use cases for etcd3." >>>> >>>> The main question that has come up is whether this is still the best >>>> practice or if we should revisit the preferred drivers for etcd. Gorka >>>> has gotten the grpc-based driver working in a Cinder driver that needs >>>> etcd[2], so there's a question as to whether we still need the HTTP >>>> etcd-gateway or if everything should use grpc. I will admit I'm nervous >>>> about trying to juggle eventlet and grpc, but if it works then my only >>>> argument is general misgivings about doing anything clever that involves >>>> eventlet. :-) >>>> >>>> It looks like the HTTP API for etcd has moved out of experimental >>>> status[3] at this point, so that's no longer an issue. There was some >>>> vague concern from a downstream packaging perspective that the grpc >>>> library might use a funky build system, whereas the etcd3-gateway >>>> library only depends on existing OpenStack requirements. >>>> >>>> On the other hand, I don't know how much of a hassle it is to deploy and >>>> manage a grpc-gateway. I'm kind of hoping someone has already been down >>>> this road and can advise about what they found. >>>> >>>> Thanks. >>>> >>>> -Ben >>>> >>>> 1: https://etherpad.openstack.org/p/BOS-etcd-base-service >>>> 2: >>>> >>>> https://github.com/embercsi/ember-csi/blob/5bd4dffe9107bc906d14a45cd819d9a659c19047/ember_csi/ember_csi.py#L1106-L1111 >>>> 3: https://github.com/grpc-ecosystem/grpc-gateway >>>> >>>> From Kevin.Fox at pnnl.gov Tue Dec 4 16:49:27 2018 From: Kevin.Fox at pnnl.gov (Fox, Kevin M) Date: Tue, 4 Dec 2018 16:49:27 +0000 Subject: [all][FEMDC] Etcd as DLM In-Reply-To: References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> <1A3C52DFCD06494D8528644858247BF01C24C6BD@EX10MBOX03.pnnl.gov> <3ebe82c8-ea86-566b-faff-b9f2fd22009a@openstack.org>, Message-ID: <1A3C52DFCD06494D8528644858247BF01C24CFD6@EX10MBOX03.pnnl.gov> This thread is shifting a bit... I'd like to throw in another related idea we're talking about it... There is storing data in key/value stores and there is also storing data in document stores. Kubernetes uses a key/value store and builds a document store out of it. All its api then runs through a document store, not a key/value store. This model has proven to be quite powerful. I wonder if an abstraction over document stores would be useful? wrapping around k8s crds would be interesting. A lightweight openstack without mysql would have some interesting benifits. Thanks, Kevin ________________________________________ From: Bogdan Dobrelya [bdobreli at redhat.com] Sent: Tuesday, December 04, 2018 6:29 AM To: openstack-discuss at lists.openstack.org Subject: Re: [all][FEMDC] Etcd as DLM On 12/4/18 2:15 PM, Thierry Carrez wrote: > Not sure that is what you're looking for, but the concept of an oslo.db > interface to a key-value store was explored by a research team and the > FEMDC WG (Fog/Edge/Massively-distributed Clouds), in the context of > distributing Nova data around. Their ROME oslo.db driver PoC was using > Redis, but I think it could be adapted to use etcd quite easily. > > Some pointers: > > https://github.com/beyondtheclouds/rome > > https://www.openstack.org/videos/austin-2016/a-ring-to-rule-them-all-revising-openstack-internals-to-operate-massively-distributed-clouds That's interesting, thank you! I'd like to remind though that Edge/Fog cases assume high latency, which is not the best fit for strongly consistent oslo.db data backends, like Etcd or Galera. Technically, it had been proved in the past a few years that only causal consistency, which is like eventual consistency but works much better for end users [0], is a way to go for Edge clouds. Except that there is *yet* a decent implementation exists of a causal consistent KVS! So my take is, if we'd ever want to redesign ORM transactions et al to CAS operations and KVS, it should be done not for Etcd in mind, but a future causal consistent solution. [0] https://www.usenix.org/system/files/login/articles/08_lloyd_41-43_online.pdf -- Best regards, Bogdan Dobrelya, Irc #bogdando From zufardhiyaulhaq at gmail.com Tue Dec 4 16:00:23 2018 From: zufardhiyaulhaq at gmail.com (Zufar Dhiyaulhaq) Date: Tue, 4 Dec 2018 23:00:23 +0700 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> Message-ID: Hi all, I am facing this issue again, I try to add this configuration but still, the node is going to compute1. [scheduler] driver = filter_scheduler host_manager = host_manager [filter_scheduler] available_filters=nova.scheduler.filters.all_filters enabled_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,CoreFilter use_baremetal_filters=False weight_classes=nova.scheduler.weights.all_weighers [placement] randomize_allocation_candidates = true thank you. Best Regards, Zufar Dhiyaulhaq On Tue, Dec 4, 2018 at 3:59 PM Zufar Dhiyaulhaq wrote: > Hi all, I am facing this issue again, > > I try to add this configuration but still, the node is going to compute1. > > [scheduler] > driver = filter_scheduler > host_manager = host_manager > > [filter_scheduler] > available_filters=nova.scheduler.filters.all_filters > > enabled_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,CoreFilter > use_baremetal_filters=False > weight_classes=nova.scheduler.weights.all_weighers > > [placement] > randomize_allocation_candidates = true > > thank you. > > > Best Regards, > Zufar Dhiyaulhaq > > > On Tue, Dec 4, 2018 at 3:55 AM Mike Carden wrote: > >> >>> Presuming you are deploying Rocky or Queens, >>> >> >> Yep, it's Queens. >> >> >>> >>> It goes in the nova.conf file under the [placement] section: >>> >>> randomize_allocation_candidates = true >>> >> >> In triple-o land it seems like the config may need to be somewhere like >> nova-scheduler.yaml and laid down via a re-deploy. >> >> Or something. >> >> The nova_scheduler runs in a container on a 'controller' host. >> >> -- >> MC >> >> _______________________________________________ >> 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 zufardhiyaulhaq at gmail.com Tue Dec 4 16:07:21 2018 From: zufardhiyaulhaq at gmail.com (Zufar Dhiyaulhaq) Date: Tue, 4 Dec 2018 23:07:21 +0700 Subject: Octavia Production Deployment Confused Message-ID: Hi, I want to implement Octavia service in OpenStack Queens. I am stuck on two-step : 1. Create Octavia User I am trying to create Octavia user with this command, is this the right way? openstack user create octavia --domain default --password octavia openstack role add --user octavia --project services admin openstack service create --name octavia --description "OpenStack Octavia" load-balancer openstack endpoint create --region RegionOne octavia public http://10.60.60.10:9876 openstack endpoint create --region RegionOne octavia internal http://10.60.60.10:9876 openstack endpoint create --region RegionOne octavia admin http://10.60.60.10:9876 2. Load Balancer Network Configuration "Add appropriate routing to/from the ‘lb-mgmt-net’ such that egress is allowed, and the controller (to be created later) can talk to hosts on this network." I don't know how to route from controller host into a private network, is any specific command for doing that? following tutorial from https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html#running-octavia-in-production . Thank You Best Regards, Zufar Dhiyaulhaq -------------- next part -------------- An HTML attachment was scrubbed... URL: From dms at danplanet.com Tue Dec 4 16:55:34 2018 From: dms at danplanet.com (Dan Smith) Date: Tue, 04 Dec 2018 08:55:34 -0800 Subject: [dev][nova][placement][qa] opinion on adding placement tests support in Tempest In-Reply-To: <52060b98-74f5-3a3a-1b51-8cba8aa7b00c@gmail.com> (Jay Pipes's message of "Tue, 4 Dec 2018 08:00:53 -0500") References: <16778b864ea.ed28ea0d72714.6704537180908793759@ghanshyammann.com> <52060b98-74f5-3a3a-1b51-8cba8aa7b00c@gmail.com> Message-ID: > On 12/04/2018 06:13 AM, Chris Dent wrote: >> On Tue, 4 Dec 2018, Ghanshyam Mann wrote: >> >>> Before we start or proceed with the discussion in QA, i would like >>> to get the nova(placement) team opinion on adding the placement >>> support in Tempest. Obviously, we should not duplicate the testing >>> effort between what existing gabbi tests cover or what going to be >>> added in Tempest which we can take care while adding the new tests. >> >> My feeling on this is that what should be showing up in tempest with >> regard to placement tests are things that demonstrate and prove end >> to end scenarios in which placement is involved as a critical part, >> but is in the background. For example, things like the emerging minimal >> bandwidth functionality that involves all three of nova, placement >> and neutron. >> >> I don't think we need extensive testing in Tempest of the placement >> API itself, as that's already well covered by the existing >> functional tests, nor do I think it makes much sense to cover the >> common scheduling scenarios between nova and placement as those are >> also well covered and will continue to be covered even with >> placement extracted [1]. >> >> Existing Tempests tests that do things like launching, resizing, >> migrating servers already touch placement so may be sufficient. If >> we wanted to make these more complete adding verification of >> resource providers and their inventories before and after the tests >> might be useful. > > Fully agree with Chris' assessment on this. I don't disagree either. However, I do think that there are cases where it may make sense to be _able_ to hit the placement endpoint from tempest in order to verify that certain things are happening, even in a scenario that involves other services. For example, if we're testing nova's request filter stuff, we may very well need to hit the placement endpoint to validate that aggregate information is being mirrored, and/or that adding a trait to a provider properly results in some scheduling behavior. So, if the question is "should a tempest test be able to hit the placement endpoint?" I would say "yes". If the question is "should tempest have tests that only hit placement to validate proper behavior", I'd agree that functional tests in placement probably cover that sufficiently. I *think* that gmann's question in the email was actually about placement endpoint support, which is the former, and I think is probably legit. --Dan From doug at doughellmann.com Tue Dec 4 16:56:37 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Tue, 04 Dec 2018 11:56:37 -0500 Subject: [Release-job-failures] Release of openstack/networking-ansible failed In-Reply-To: References: Message-ID: zuul at openstack.org writes: > Build failed. > > - release-openstack-python http://logs.openstack.org/62/62d263ef737957dce0e83526268f20ae4bdd3b21/release/release-openstack-python/dd28025/ : SUCCESS in 4m 09s > - announce-release http://logs.openstack.org/62/62d263ef737957dce0e83526268f20ae4bdd3b21/release/announce-release/44a3623/ : SUCCESS in 4m 16s > - propose-update-constraints http://logs.openstack.org/62/62d263ef737957dce0e83526268f20ae4bdd3b21/release/propose-update-constraints/3b72b02/ : SUCCESS in 3m 49s > - trigger-readthedocs-webhook http://logs.openstack.org/62/62d263ef737957dce0e83526268f20ae4bdd3b21/release/trigger-readthedocs-webhook/c912b3a/ : FAILURE in 1m 57s > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures It looks like the networking-ansible project needs to do some work on the readthedocs integration. -- Doug From Kevin.Fox at pnnl.gov Tue Dec 4 16:57:36 2018 From: Kevin.Fox at pnnl.gov (Fox, Kevin M) Date: Tue, 4 Dec 2018 16:57:36 +0000 Subject: [all] Etcd as DLM In-Reply-To: <208e0023-cb4d-1b7f-9f31-b186a9c45f4c@gmail.com> References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> , <208e0023-cb4d-1b7f-9f31-b186a9c45f4c@gmail.com> Message-ID: <1A3C52DFCD06494D8528644858247BF01C24D014@EX10MBOX03.pnnl.gov> I've asked for it a while ago, but will ask again since the subject came back up. :) If ironic could target k8s crds for storage, it would be significantly easier to deploy an under cloud. Between k8s api, the k8s cluster api and ironic's api, a truly self hosting k8s could be possible. Thanks, Kevin ________________________________________ From: Jay Pipes [jaypipes at gmail.com] Sent: Tuesday, December 04, 2018 4:52 AM To: openstack-discuss at lists.openstack.org Subject: Re: [all] Etcd as DLM On 12/03/2018 06:53 PM, Julia Kreger wrote: > I would like to slightly interrupt this train of thought for an > unscheduled vision of the future! > > What if we could allow a component to store data in etcd3's key value > store like how we presently use oslo_db/sqlalchemy? > > While I personally hope to have etcd3 as a DLM for ironic one day, > review bandwidth permitting, it occurs to me that etcd3 could be > leveraged for more than just DLM. If we have a common vision to enable > data storage, I suspect it might help provide overall guidance as to how > we want to interact with the service moving forward. Considering Ironic doesn't have a database schema that really uses the relational database properly, I think this is an excellent idea. [1] Ironic's database schema is mostly a bunch of giant JSON BLOB fields that are (ab)used by callers to add unstructured data pointing at a node's UUID. Which is pretty much what a KVS like etcd was made for, so I say, go for it. Best, -jay [1] The same can be said for quite a few tables in Nova's cell DB, namely compute_nodes, instance_info_caches, instance_metadata, instance_system_metadata, instance_extra, instance_actions, instance_action_events and pci_devices. And Nova's API DB has the aggregate_metadata, flavor_extra_specs, request_specs, build_requests and key_pairs tables, all of which are good candidates for non-relational storage. From doug at doughellmann.com Tue Dec 4 17:06:58 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Tue, 04 Dec 2018 12:06:58 -0500 Subject: [Release-job-failures][release][tripleo] Tag of openstack/tripleo-heat-templates failed In-Reply-To: References: Message-ID: Emilien Macchi writes: > I'm looking into it now. > > On Tue, Dec 4, 2018 at 11:11 AM Doug Hellmann wrote: > >> >> >> > On Dec 4, 2018, at 11:00 AM, zuul at openstack.org wrote: >> > >> > Build failed. >> > >> > - publish-openstack-releasenotes-python3 >> http://logs.openstack.org/7b/7baea84f1168d72b0eb8901da47d5f4efbaccff8/tag/publish-openstack-releasenotes-python3/2d5a462/ >> : POST_FAILURE in 5m 02s >> > - publish-openstack-releasenotes >> http://logs.openstack.org/7b/7baea84f1168d72b0eb8901da47d5f4efbaccff8/tag/publish-openstack-releasenotes/6088133/ >> : SUCCESS in 5m 04s >> > >> > _______________________________________________ >> > Release-job-failures mailing list >> > Release-job-failures at lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures >> >> It looks like tripleo-heat-templates still has both release notes jobs >> configured, so there was a race condition in publishing. >> >> Doug >> >> >> > > -- > Emilien Macchi The fix for this is to stop running the python2 version of the publish job on the tag event by removing that job from the project-template. See https://review.openstack.org/622430 -- Doug From emilien at redhat.com Tue Dec 4 17:09:05 2018 From: emilien at redhat.com (Emilien Macchi) Date: Tue, 4 Dec 2018 12:09:05 -0500 Subject: [Release-job-failures][release][tripleo] Tag of openstack/tripleo-heat-templates failed In-Reply-To: References: Message-ID: On Tue, Dec 4, 2018 at 12:07 PM Doug Hellmann wrote: > The fix for this is to stop running the python2 version of the publish > job on the tag event by removing that job from the project-template. See > https://review.openstack.org/622430 > Thanks for your help Doug! -- Emilien Macchi -------------- next part -------------- An HTML attachment was scrubbed... URL: From mranga at gmail.com Tue Dec 4 17:18:17 2018 From: mranga at gmail.com (M. Ranganathan) Date: Tue, 4 Dec 2018 12:18:17 -0500 Subject: Octavia Production Deployment Confused In-Reply-To: References: Message-ID: I did this manually. -- Create an ovs port on br-int -- Create a neutron port using the ovs port that you just created. -- Assign the ip address of the neutron port to the ovs port -- Use ip netns exec to assign a route in the router namespace of the LoadBalancer network. If there's somebody who has a better way to do this, please share. Ranga On Tue, Dec 4, 2018 at 11:16 AM Zufar Dhiyaulhaq wrote: > Hi, I want to implement Octavia service in OpenStack Queens. > > I am stuck on two-step : > 1. Create Octavia User > > I am trying to create Octavia user with this command, is this the right > way? > > openstack user create octavia --domain default --password octavia > openstack role add --user octavia --project services admin > > openstack service create --name octavia --description "OpenStack Octavia" > load-balancer > openstack endpoint create --region RegionOne octavia public > http://10.60.60.10:9876 > openstack endpoint create --region RegionOne octavia internal > http://10.60.60.10:9876 > openstack endpoint create --region RegionOne octavia admin > http://10.60.60.10:9876 > > 2. Load Balancer Network Configuration > "Add appropriate routing to/from the ‘lb-mgmt-net’ such that egress is > allowed, and the controller (to be created later) can talk to hosts on this > network." > > I don't know how to route from controller host into a private network, is > any specific command for doing that? > > following tutorial from > https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html#running-octavia-in-production > . > > Thank You > > Best Regards, > Zufar Dhiyaulhaq > -- M. Ranganathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.therond at gmail.com Tue Dec 4 17:25:21 2018 From: gael.therond at gmail.com (=?UTF-8?Q?Ga=C3=ABl_THEROND?=) Date: Tue, 4 Dec 2018 18:25:21 +0100 Subject: Octavia Production Deployment Confused In-Reply-To: References: Message-ID: You can do it with any routed network that you’ll load as a provider network too. Way more simpler, no need for ovs manipulation, just get your network team to give you a vlan both available from computer node and controller plan. It can be a network subnet and vlan completely unknown from you controller as long as you get an intermediary equipment that route your traffic or that you add the proper route on your controllers. Le mar. 4 déc. 2018 à 18:21, M. Ranganathan a écrit : > I did this manually. > > -- Create an ovs port on br-int > -- Create a neutron port using the ovs port that you just created. > -- Assign the ip address of the neutron port to the ovs port > -- Use ip netns exec to assign a route in the router namespace of the > LoadBalancer network. > > If there's somebody who has a better way to do this, please share. > > Ranga > > On Tue, Dec 4, 2018 at 11:16 AM Zufar Dhiyaulhaq > wrote: > >> Hi, I want to implement Octavia service in OpenStack Queens. >> >> I am stuck on two-step : >> 1. Create Octavia User >> >> I am trying to create Octavia user with this command, is this the right >> way? >> >> openstack user create octavia --domain default --password octavia >> openstack role add --user octavia --project services admin >> >> openstack service create --name octavia --description "OpenStack Octavia" >> load-balancer >> openstack endpoint create --region RegionOne octavia public >> http://10.60.60.10:9876 >> openstack endpoint create --region RegionOne octavia internal >> http://10.60.60.10:9876 >> openstack endpoint create --region RegionOne octavia admin >> http://10.60.60.10:9876 >> >> 2. Load Balancer Network Configuration >> "Add appropriate routing to/from the ‘lb-mgmt-net’ such that egress is >> allowed, and the controller (to be created later) can talk to hosts on this >> network." >> >> I don't know how to route from controller host into a private network, is >> any specific command for doing that? >> >> following tutorial from >> https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html#running-octavia-in-production >> . >> >> Thank You >> >> Best Regards, >> Zufar Dhiyaulhaq >> > > > -- > M. Ranganathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbragstad at gmail.com Tue Dec 4 17:38:27 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Tue, 4 Dec 2018 11:38:27 -0600 Subject: [tc][all] Train Community Goals Message-ID: Hi all, The purpose of this thread is to have a more focused discussion about what we'd like to target for Train community goals, bootstrapped with the outcomes from the session in Berlin [0]. During the session, we went through each item as a group and let the person who added it share why they thought it would be a good community goal candidate for the next release. Most goals have feedback captured in etherpad describing next steps, but the following stuck out as top contenders from the session (rated by upvotes): 1. Moving legacy clients to python-openstackclient 2. Cleaning up resources when deleting a project 3. Service-side health checks I don't think I missed any goals from the session, but if I did, please let me know and I'll add it to the list so that we can discuss it here. Does anyone have strong opinions either way about the goals listed above? [0] https://etherpad.openstack.org/p/BER-t-series-goals -------------- next part -------------- An HTML attachment was scrubbed... URL: From juliaashleykreger at gmail.com Tue Dec 4 17:43:28 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Tue, 4 Dec 2018 09:43:28 -0800 Subject: [all] Etcd as DLM In-Reply-To: <0c5a4a87-2ee8-f6d4-8de0-f693d70df7ee@gmail.com> References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> <1A3C52DFCD06494D8528644858247BF01C24C6BD@EX10MBOX03.pnnl.gov> <3ebe82c8-ea86-566b-faff-b9f2fd22009a@openstack.org> <0c5a4a87-2ee8-f6d4-8de0-f693d70df7ee@gmail.com> Message-ID: On Tue, Dec 4, 2018 at 5:53 AM Jay Pipes wrote: > On 12/04/2018 08:15 AM, Thierry Carrez wrote: > > Julia Kreger wrote: > >> Indeed it is a considered a base service, but I'm unaware of why it > >> was decided to not have any abstraction layer on top. That sort of > >> defeats the adoption of tooz as a standard in the community. Plus with > >> the rest of our code bases, we have a number of similar or identical > >> patterns and it would be ideal to have a single library providing the > >> overall interface for the purposes of consistency. Could you provide > >> some more background on that decision? > > > > Dims can probably summarize it better than I can do. > > > > When we were discussing adding a DLM as a base service, we had a lot of > > discussion at several events and on several threads weighing that option > > (a "tooz-compatible DLM" vs. "etcd"). IIRC the final decision had to do > > with leveraging specific etcd features vs. using the smallest common > > denominator, while we expect everyone to be deploying etcd. > > > >> I guess what I'd really like to see is an oslo.db interface into etcd3. > > > > Not sure that is what you're looking for, but the concept of an oslo.db > > interface to a key-value store was explored by a research team and the > > FEMDC WG (Fog/Edge/Massively-distributed Clouds), in the context of > > distributing Nova data around. Their ROME oslo.db driver PoC was using > > Redis, but I think it could be adapted to use etcd quite easily. > > Note that it's not appropriate to replace *all* use of an RDBMS in > OpenStack-land with etcd. I hope I wasn't misunderstood in my statement > earlier. > > Just *some* use cases are better served by a key/value store, and > etcd3's transactions and watches are a great tool for solving *some* use > cases -- but definitely not all :) > > Anyway, just making sure nobody's going to accuse me of saying OpenStack > should abandon all RDBMS use for a KVS. :) > > Best, > -jay > Definitely not interpreted that way and not what I was thinking either. I definitely see there is value, and your thoughts do greatly confirm that at least I'm not the only crazy person thinking it could be a good idea^(TM). > > Some pointers: > > > > https://github.com/beyondtheclouds/rome > > > > > https://www.openstack.org/videos/austin-2016/a-ring-to-rule-them-all-revising-openstack-internals-to-operate-massively-distributed-clouds > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdent+os at anticdent.org Tue Dec 4 17:47:56 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Tue, 4 Dec 2018 17:47:56 +0000 (GMT) Subject: [tc] Adapting office hours schedule to demand In-Reply-To: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> Message-ID: On Tue, 4 Dec 2018, Thierry Carrez wrote: > Should we: > > - Reduce office hours to one or two per week, possibly rotating times > > - Dump the whole idea and just encourage people to ask questions at any time > on #openstack-tc, and get asynchronous answers > > - Keep it as-is, it still has the side benefit of triggering spikes of TC > member activity One more option, for completeness - Drop to one or two per week, at fixed and well-known times, and encourage more use of email for engaging with and within the TC. We keep saying that email is the only reliable medium we have and then keep talking about ways to use IRC more. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From juliaashleykreger at gmail.com Tue Dec 4 17:50:13 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Tue, 4 Dec 2018 09:50:13 -0800 Subject: [all][FEMDC] Etcd as DLM In-Reply-To: <1A3C52DFCD06494D8528644858247BF01C24CFD6@EX10MBOX03.pnnl.gov> References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> <1A3C52DFCD06494D8528644858247BF01C24C6BD@EX10MBOX03.pnnl.gov> <3ebe82c8-ea86-566b-faff-b9f2fd22009a@openstack.org> <1A3C52DFCD06494D8528644858247BF01C24CFD6@EX10MBOX03.pnnl.gov> Message-ID: I like where this is going! Comment in-line. On Tue, Dec 4, 2018 at 8:53 AM Fox, Kevin M wrote: > This thread is shifting a bit... > > I'd like to throw in another related idea we're talking about it... > > There is storing data in key/value stores and there is also storing data > in document stores. > > Kubernetes uses a key/value store and builds a document store out of it. > All its api then runs through a document store, not a key/value store. > > This model has proven to be quite powerful. I wonder if an abstraction > over document stores would be useful? wrapping around k8s crds would be > interesting. A lightweight openstack without mysql would have some > interesting benifits. > I suspect the code would largely be the same, if we support key/value then I would hope that then we could leverage all of that with just opening/connecting of the document store. Perhaps this is worth some further investigation, but ultimately what I've been thinking is if we _could_ allow some, not all, services to operate in completely decoupled fashion we better enable them to support OpenStack and neighboring technologies. Ironic is kind of the obvious starting point of sorts since everyone needs to start with some baremetal somewhere if they are are building their own infrastructure up. > > Thanks, > Kevin > ________________________________________ > From: Bogdan Dobrelya [bdobreli at redhat.com] > Sent: Tuesday, December 04, 2018 6:29 AM > To: openstack-discuss at lists.openstack.org > Subject: Re: [all][FEMDC] Etcd as DLM > > On 12/4/18 2:15 PM, Thierry Carrez wrote: > > Not sure that is what you're looking for, but the concept of an oslo.db > > interface to a key-value store was explored by a research team and the > > FEMDC WG (Fog/Edge/Massively-distributed Clouds), in the context of > > distributing Nova data around. Their ROME oslo.db driver PoC was using > > Redis, but I think it could be adapted to use etcd quite easily. > > > > Some pointers: > > > > https://github.com/beyondtheclouds/rome > > > > > https://www.openstack.org/videos/austin-2016/a-ring-to-rule-them-all-revising-openstack-internals-to-operate-massively-distributed-clouds > > That's interesting, thank you! I'd like to remind though that Edge/Fog > cases assume high latency, which is not the best fit for strongly > consistent oslo.db data backends, like Etcd or Galera. Technically, it > had been proved in the past a few years that only causal consistency, > which is like eventual consistency but works much better for end users > [0], is a way to go for Edge clouds. Except that there is *yet* a decent > implementation exists of a causal consistent KVS! > > So my take is, if we'd ever want to redesign ORM transactions et al to > CAS operations and KVS, it should be done not for Etcd in mind, but a > future causal consistent solution. > > [0] > > https://www.usenix.org/system/files/login/articles/08_lloyd_41-43_online.pdf > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbragstad at gmail.com Tue Dec 4 17:53:30 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Tue, 4 Dec 2018 11:53:30 -0600 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> Message-ID: On Tue, Dec 4, 2018 at 9:47 AM Thierry Carrez wrote: > Hi, > > A while ago, the Technical Committee designated specific hours in the > week where members would make extra effort to be around on #openstack-tc > on IRC, so that community members looking for answers to their questions > or wanting to engage can find a time convenient for them and a critical > mass of TC members around. We currently have 3 weekly spots: > > - 09:00 UTC on Tuesdays > - 01:00 UTC on Wednesdays > - 15:00 UTC on Thursdays > > But after a few months it appears that: > > 1/ nobody really comes on channel at office hour time to ask questions. > We had a questions on the #openstack-tc IRC channel, but I wouldn't say > people take benefit of the synced time > > 2/ some office hours (most notably the 01:00 UTC on Wednesdays, but also > to a lesser extent the 09:00 UTC on Tuesdays) end up just being a couple > of TC members present > Conversely, office hours are relatively low bandwidth, IMO. Unless there is an active discussion, I'm usually working on something else and checking the channel intermittently. That said, I don't think it's a huge inconveince to monitor the channel for an hour in the event someone does swing by. > > So the schedule is definitely not reaching its objectives, and as such > may be a bit overkill. I was also wondering if this is not a case where > the offer is hurting the demand -- by having so many office hour spots > around, nobody considers them special. > > Should we: > > - Reduce office hours to one or two per week, possibly rotating times > > - Dump the whole idea and just encourage people to ask questions at any > time on #openstack-tc, and get asynchronous answers > I completely agree that we should encourage people to come talk to us at any time, but I think office hours hold us accountable for being present. We're doing our part by making sure we're available. > > - Keep it as-is, it still has the side benefit of triggering spikes of > TC member activity > Thoughts ? > > -- > Thierry Carrez (ttx) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilien at redhat.com Tue Dec 4 17:54:59 2018 From: emilien at redhat.com (Emilien Macchi) Date: Tue, 4 Dec 2018 12:54:59 -0500 Subject: [tripleo] [validations] Replacement of undercloud_conf module Message-ID: Hi folks, Context: https://bugs.launchpad.net/tripleo/+bug/1805825 Today I randomly found this module: https://github.com/openstack/tripleo-validations/blob/d21e7fa30f9be15bb980279197dc6c5206f38a38/validations/library/undercloud_conf.py And it gave me 2 ideas, as I think we don't need this module and would consider it as technical debt at this point: - it's relying on a file, which isn't super safe and flexible IMHO. - a lot of validations rely on Hieradata which isn't safe either, we saw it with the Containerized Undercloud. So I propose that: - we export require parameters via the Heat templates into Ansible variables - we consume these variables from tripleo-validations (can be in the inventory or a dedicated var file for validations). So that way we remove the dependency on having the undercloud.conf access from Mistral Executor and also stop depending on Puppet (hieradata) which we don't guarantee to be here in the future. Can someone from TripleO validations team ack this email and put this work in your backlog? If you need assistance we're happy to help but I believe this is an important effort to avoid technical debt here. Thanks, -- Emilien Macchi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko.vancsa at gmail.com Tue Dec 4 18:06:27 2018 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Tue, 4 Dec 2018 10:06:27 -0800 Subject: Berlin Summit recap on Edge Message-ID: <5BCA051D-9368-4C1E-B993-FB83525F5296@gmail.com> Hi, I hope those of you who came to the Berlin Summit had a great event, a good trip home and got some rest, caught up with work and those who went on vacation had a great time. Hereby I would like to give a short summary to everyone either as a reminder or as a package to help you catch up briefly with what happened around edge in Berlin. As you most probably know we had a dedicated track for Edge Computing with numerous presentations and panel discussions at the conference which were recorded. If you would like to catch up or see some sessions again please visit the OpenStack website[1] for the videos. In parallel to the conference we were having the Forum taking place with 40-minute-long working sessions for developers, operators and users to meet and discuss new requirements, challenges and pain points to address. We had quite a few sessions around edge which you’ll find a brief recap of here. I would like to start with the OSF Edge Computing Group also Edge WG’s sessions, if you are new to the activities of this group you may want to read my notes[2] on the Denver PTG to catch up on the community’s and the group's work on defining reference architectures for edge use cases. During the Forum we continued to discuss the Minimum Viable Product (MVP) architecture topic[3] that we’ve started at the last PTG. As the group and attendees had limited amount of time available for the topic we concluded on some basics and agreed on action items to follow up on. The session attendees agreed that the MVP architecture is an important first step and we will keep its scope limited to the current OpenStack services listed on the wiki capturing the details[4]. While there is interest in adding further services such as Ironic or Qinling we will discuss those in this context in upcoming phases. The Edge WG is actively working on capturing edge computing use cases in order to understand better the requirements and to work together with OpenStack and StarlingX projects on design and implementation work based the input the groups has been collecting[5]. We had a session about use cases[6] to identify which are the ones the group should focus on with immediate actions where we got vRAN and edge cloud, uCPE and industrial control with most interest in the room to work on. The group is actively working on the map the MVP architecture options to the use cases identified by the group and to get more details on the ones we identified during the Forum session. If you are interested in participating in these activities please see the details[7] of the group’s weekly meetings. While the MVP architecture work is focusing on a minimalistic view to provide a reference architecture with the covered services prepared for edge use cases there is work ongoing in parallel in several OpenStack projects. You can find notes on the Forum etherpads[8][9][10] on the progress of projects such as Cinder, Ironic, Kolla-Ansible and TripleO. The general consensus of the project discussions were that the services are in a good shape when edge requirements are concerned and there is a good view on the way forward like improving availability zone functionality or remote management of bare metal nodes. With all the work ongoing in the projects as well as in the Edge WG the expectation is that we will be able to easily move to the next phases with the MVP architectures work when the working group is ready. Both the group and the projects are looking for contributors for both identifying further requirements, use cases or do the implementation and testing work. Testing is an area that will be crucial for edge and we are looking into both cross-project and cross-community collaborations for that for instance with OPNFV and Akraino. While we didn’t have a Keystone specific Forum session for edge this time a small group of people came together to discuss next steps with federation. We are converging towards some generic feature additions to Keystone based on the Athenz plugin from Oath. You can read a Keystone summary[11] for the week in Berlin from Lance Bragsad including plans related to edge. We had a couple of sessions at the Summit about StarlingX both in the conference part as well as the Forum. You can check out videos such as the project update[12] and other relevant sessions[13] among the Summit videos. As the StarlingX community is working closely with the Edge WG as well as the relevant OpenStack project teams at the Forum we had sessions that were focusing on some specific items for planning future work and understanding requirements better for the project. The team had a session on IoT[14] to talk about the list of devices to consider and the requirements systems need to address in this space. The session also identified a collaboration option between StarlingX, IoTronic[15] and Ironic when it comes to realizing and testing use cases. With putting more emphasis on containers at the edge the team also had a session on containerized application requirements[16] with a focus on Kubernetes clusters. During the session we talked about areas like container networking, multi-tenancy, persistent storage and a few more to see what options we have for them and what is missing today to have the particular area covered. The StarlingX community is focusing more on containerization in the upcoming releases for which the feedback and ideas during the session are very important to have. One more session to mention is the ‘Ask me anything about StarlingX’ one at the Forum where experts from the community offered help in general to people who are new and/or have questions about the project. The session was well attended and questions were focusing more on the practical angles like footprint or memory consumption and a few more specific questions that were beyond generic interest and overview of the project. These were the activities in high level around edge without going into too much detail on either of the topics as that would be a way longer e-mail. :) I hope you found interesting topics and useful pointers for more information to catch up on. If you would like to participate in these activities you can dial-in to the Edge WG weekly calls[17] or weekly Use cases calls[18] or check the StarlingX sub-project team calls[19] and further material on the website[20] about how to contribute or jump on IRC for OpenStack project team meetings[21] in the area of your interest. Please let me know if you have any questions to either of the above items. :) Thanks and Best Regards, Ildikó (IRC: ildikov) [1] https://www.openstack.org/videos/ [2] http://lists.openstack.org/pipermail/edge-computing/2018-September/000432.html [3] https://etherpad.openstack.org/p/BER-MVP-architecture-for-edge [4] https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures [5] https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases [6] https://etherpad.openstack.org/p/BER-edge-use-cases-and-requirements [7] https://wiki.openstack.org/wiki/Edge_Computing_Group [8] https://etherpad.openstack.org/p/BER-Cinder_at_the_Edge [9] https://etherpad.openstack.org/p/BER-ironic-edge [10] https://etherpad.openstack.org/p/BER-tripleo-undercloud-edge [11] https://www.lbragstad.com/blog/openstack-summit-berlin-recap [12] https://www.openstack.org/videos/berlin-2018/starlingx-project-update-6-months-in-the-life-of-a-new-open-source-project [13] https://www.openstack.org/videos/search?search=starlingx [14] https://etherpad.openstack.org/p/BER-integrating-iot-device-mgmt-with-edge-cloud [15] https://github.com/openstack/iotronic [16] https://etherpad.openstack.org/p/BER-containerized-app-reqmts-on-kubernetes-at-edge [17] https://www.openstack.org/assets/edge/OSF-Edge-Computing-Group-Weekly-Calls.ics [18] https://www.openstack.org/assets/edge/OSF-Edge-WG-Use-Cases-Weekly-Calls.ics [19] https://wiki.openstack.org/wiki/Starlingx/Meetings [20] https://www.starlingx.io [21] http://eavesdrop.openstack.org From juliaashleykreger at gmail.com Tue Dec 4 18:08:34 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Tue, 4 Dec 2018 10:08:34 -0800 Subject: [tc][all] Train Community Goals In-Reply-To: References: Message-ID: Off-hand, I think there needs to be a few more words agreed upon for each in terms of what each item practically means. In other words, does #1 mean each python-clientlibrary's OSC plugin is ready to rock and roll, or we talking about everyone rewriting all client interactions in to openstacksdk, and porting existing OSC plugins use that different python sdk. In other words, some projects could find it very easy or that they are already done, where as others could find themselves with a huge lift that is also dependent upon review bandwidth that is outside of their control or influence which puts such a goal at risk if we try and push too hard. -Julia On Tue, Dec 4, 2018 at 9:43 AM Lance Bragstad wrote: > Hi all, > > The purpose of this thread is to have a more focused discussion about what > we'd like to target for Train community goals, bootstrapped with the > outcomes from the session in Berlin [0]. > > During the session, we went through each item as a group and let the > person who added it share why they thought it would be a good community > goal candidate for the next release. Most goals have feedback captured in > etherpad describing next steps, but the following stuck out as top > contenders from the session (rated by upvotes): > > 1. Moving legacy clients to python-openstackclient > 2. Cleaning up resources when deleting a project > 3. Service-side health checks > > I don't think I missed any goals from the session, but if I did, please > let me know and I'll add it to the list so that we can discuss it here. > > Does anyone have strong opinions either way about the goals listed above? > > [0] https://etherpad.openstack.org/p/BER-t-series-goals > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juliaashleykreger at gmail.com Tue Dec 4 18:14:45 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Tue, 4 Dec 2018 10:14:45 -0800 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> Message-ID: I am +1 to cdent's option below. The bottom line for every TC member is that most of our work days can only hit one or maybe two office hours per week. I think we should re-poll, possibly adjust times if necessary but trying to keep those times with-in the window that works. Every TC election we can re-poll for best times, and change accordingly. Three times a week just seems like it may not be useful or beneficial. Twice is much easier to schedule. One will likely conflict for some of us regardless of what we try to do. -Julia On Tue, Dec 4, 2018 at 9:51 AM Chris Dent wrote: > On Tue, 4 Dec 2018, Thierry Carrez wrote: > > > Should we: > > > > - Reduce office hours to one or two per week, possibly rotating times > > > > - Dump the whole idea and just encourage people to ask questions at any > time > > on #openstack-tc, and get asynchronous answers > > > > - Keep it as-is, it still has the side benefit of triggering spikes of > TC > > member activity > > One more option, for completeness > > - Drop to one or two per week, at fixed and well-known times, and > encourage more use of email for engaging with and within the TC. > > We keep saying that email is the only reliable medium we have and > then keep talking about ways to use IRC more. > > -- > Chris Dent ٩◔̯◔۶ https://anticdent.org/ > freenode: cdent tw: @anticdent -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdent+os at anticdent.org Tue Dec 4 18:30:56 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Tue, 4 Dec 2018 18:30:56 +0000 (GMT) Subject: [dev][nova][placement][qa] opinion on adding placement tests support in Tempest In-Reply-To: References: <16778b864ea.ed28ea0d72714.6704537180908793759@ghanshyammann.com> <52060b98-74f5-3a3a-1b51-8cba8aa7b00c@gmail.com> Message-ID: On Tue, 4 Dec 2018, Dan Smith wrote: >> On 12/04/2018 06:13 AM, Chris Dent wrote: >>> Existing Tempests tests that do things like launching, resizing, >>> migrating servers already touch placement so may be sufficient. If >>> we wanted to make these more complete adding verification of >>> resource providers and their inventories before and after the tests >>> might be useful. [snip] > I don't disagree either. However, I do think that there are cases where > it may make sense to be _able_ to hit the placement endpoint from > tempest in order to verify that certain things are happening, even in a > scenario that involves other services. [snip] Based on conversation with Dan in IRC, we decided it might be useful to clarify that Dan and I are in agreement. It had seemed to me that he was saying something different from me, but we're both basically saying "yes, tempest needs to be able to talk to placement to confirm what it's holding because that's useful sometimes" and "no, tempest doesn't need to verify the workings of placement api itself". Which boils out to this: > I *think* that gmann's > question in the email was actually about placement endpoint support, > which is the former, and I think is probably legit. Yes. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From jimmy at openstack.org Tue Dec 4 18:33:48 2018 From: jimmy at openstack.org (Jimmy McArthur) Date: Tue, 04 Dec 2018 12:33:48 -0600 Subject: [ptl] [openstack-map] New tags for OpenStack Project Map Message-ID: <5C06C88C.1010303@openstack.org> Following up on this thread from ttx [1], we are continuing to enhance the content on the OpenStack Project Map [2],[3] through new tags that are managed through the openstack-map repo [4]. * video (id, title, description) - This controls the Project Update video you see on the project page. I've just pushed a review adding all of the Project Updates for Berlin [5] * depends-on - Things that are a strong dependency. This should be used ONLY if your component requires another one to work (e.g. nova -> glance) * see-also - Should list things that are a week dependency or an adjacent relevant thing * support-teams (name: link) - This is meant to give credit to adjacent projects that aren't necessary to run the software (e.g. Oslo, i18n, Docs). We are still determining how best to implement this tag, but we feel it's important to give some credit to these other teams that are so critical in helping to maintain, support, and build OpenStack If you have some time, please go to the git repo [4] and review your project and help flesh out these new tags (or update old ones) so we can display them in the Project Map [2]. Cheers, Jimmy [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000178.html [2] https://www.openstack.org/software/project-navigator/openstack-components [3] https://www.openstack.org/assets/software/projectmap/openstack-map.pdf [4] https://git.openstack.org/cgit/openstack/openstack-map/ [5] https://review.openstack.org/622485 From mdulko at redhat.com Tue Dec 4 18:39:14 2018 From: mdulko at redhat.com (=?UTF-8?Q?Micha=C5=82?= Dulko) Date: Tue, 04 Dec 2018 19:39:14 +0100 Subject: [dev] [os-vif][nova][neutron][kuryr] os-vif serialisation, persistence and version compatiablity moving to v2.0 In-Reply-To: References: Message-ID: On Fri, 2018-11-30 at 20:57 +0000, Sean Mooney wrote: > 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 think we can handle that through port profiles. Anyway it's definitely a smaller issue that we can figure out. Moreover the change you mention actually allows us to do modifications in the data structure we save with keeping the backward compatibility, so definitely we have some options. > 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 We save it in K8s objects annotations, through K8s API, which saves it into the etcd. We assume no access to the etcd itself, so communication happens only through K8s mechanisms. > - are they bining sent to other services No, but we read the VIF's from both kuryr-kubernetes and kuryr-daemon services. > - are how are you serialising them. > - obj_to_primitive > - other It's obj_to_primitive(), see [1]. > - are you depending on obj_make_compatible There's no code for that yet, but we definitely planned that to happen to enable us to do changes in o.vo's we save in a backwards-compatible manner. > - how can we help you not use them until we actually support this use case. Well, we need to use them. :( Either we use os-vif's o.vo's or we transition to anything else we can own now. > 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. I believe we need to list the changes you want to make and work out how to keep compatibility. Kuryr itself doesn't use a lot of the fields, but we need to keep compatibility with objects saved on K8s resources by older versions of Kuryr-Kubernetes. This means that we still need a way to deserialize old o.vo's with the newer version of os-vif. > regards > sean. [1] https://github.com/openstack/kuryr-kubernetes/blob/38f541604ff490fbc381f78a23655e30e6aa0bcc/kuryr_kubernetes/controller/handlers/vif.py#L176-L178 From amodi at redhat.com Tue Dec 4 18:50:09 2018 From: amodi at redhat.com (Archit Modi) Date: Tue, 4 Dec 2018 13:50:09 -0500 Subject: [dev][nova][placement][qa] opinion on adding placement tests support in Tempest In-Reply-To: References: <16778b864ea.ed28ea0d72714.6704537180908793759@ghanshyammann.com> <52060b98-74f5-3a3a-1b51-8cba8aa7b00c@gmail.com> Message-ID: Great! There is already a patch from Lajos [1]. I'd like resource_provider_aggregates_client to be added too. (/resource_providers/{uuid}/aggregates) [1] https://review.openstack.org/#/c/622316/ On Tue, Dec 4, 2018 at 1:32 PM Chris Dent wrote: > On Tue, 4 Dec 2018, Dan Smith wrote: > > >> On 12/04/2018 06:13 AM, Chris Dent wrote: > >>> Existing Tempests tests that do things like launching, resizing, > >>> migrating servers already touch placement so may be sufficient. If > >>> we wanted to make these more complete adding verification of > >>> resource providers and their inventories before and after the tests > >>> might be useful. > > [snip] > > > I don't disagree either. However, I do think that there are cases where > > it may make sense to be _able_ to hit the placement endpoint from > > tempest in order to verify that certain things are happening, even in a > > scenario that involves other services. > > [snip] > > Based on conversation with Dan in IRC, we decided it might be useful > to clarify that Dan and I are in agreement. It had seemed to me that > he was saying something different from me, but we're both basically > saying "yes, tempest needs to be able to talk to placement to > confirm what it's holding because that's useful sometimes" and "no, > tempest doesn't need to verify the workings of placement api itself". > > Which boils out to this: > > > I *think* that gmann's > > question in the email was actually about placement endpoint support, > > which is the former, and I think is probably legit. > > Yes. > > -- > Chris Dent ٩◔̯◔۶ https://anticdent.org/ > freenode: cdent tw: @anticdent -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtantsur at redhat.com Tue Dec 4 18:51:32 2018 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Tue, 4 Dec 2018 19:51:32 +0100 Subject: [tc][all] Train Community Goals In-Reply-To: References: Message-ID: <496e2f28-5523-229e-04fb-9494690f1da7@redhat.com> On 12/4/18 7:08 PM, Julia Kreger wrote: > Off-hand, I think there needs to be a few more words agreed upon for each in > terms of what each item practically means. > > In other words, does #1 mean each python-clientlibrary's OSC plugin is ready to > rock and roll, or we talking about everyone rewriting all client interactions in > to openstacksdk, and porting existing OSC plugins use that different python sdk. > > In other words, some projects could find it very easy or that they are already > done, where as others could find themselves with a huge lift that is also > dependent upon review bandwidth that is outside of their control or influence > which puts such a goal at risk if we try and push too hard. If the goal is to make all client interactions use openstacksdk, we may indeed lack review throughput. It looks like we have 4 active reviewers this cycle: http://stackalytics.com/?module=openstacksdk > -Julia > > > On Tue, Dec 4, 2018 at 9:43 AM Lance Bragstad > wrote: > > Hi all, > > The purpose of this thread is to have a more focused discussion about what > we'd like to target for Train community goals, bootstrapped with the > outcomes from the session in Berlin [0]. > > During the session, we went through each item as a group and let the person > who added it share why they thought it would be a good community goal > candidate for the next release. Most goals have feedback captured in > etherpad describing next steps, but the following stuck out as top > contenders from the session (rated by upvotes): > > 1. Moving legacy clients to python-openstackclient > 2. Cleaning up resources when deleting a project > 3. Service-side health checks > > I don't think I missed any goals from the session, but if I did, please let > me know and I'll add it to the list so that we can discuss it here. > > Does anyone have strong opinions either way about the goals listed above? > > [0] https://etherpad.openstack.org/p/BER-t-series-goals > From emilien at redhat.com Tue Dec 4 19:41:38 2018 From: emilien at redhat.com (Emilien Macchi) Date: Tue, 4 Dec 2018 14:41:38 -0500 Subject: [tripleo] cleanup upgrade_tasks Message-ID: Upgrade folks, Please take a look at https://review.openstack.org/622578. We don't run the upgrade_tasks Ansible tasks that stop systemd services and remove the packages since all services are containerized. These tasks were useful in Rocky when we converted the Undercloud from baremetal to containers but in Stein this is not useful anymore. It's actually breaking upgrades for Podman, as containers are now seen by systemd, and these tasks conflicts with the way containers are managed in Paunch. Thanks, -- Emilien Macchi -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike_mp at zzzcomputing.com Tue Dec 4 19:30:02 2018 From: mike_mp at zzzcomputing.com (Mike Bayer) Date: Tue, 4 Dec 2018 14:30:02 -0500 Subject: [all] Etcd as DLM In-Reply-To: References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> <1A3C52DFCD06494D8528644858247BF01C24C6BD@EX10MBOX03.pnnl.gov> <20181204100812.og33xegl2fxmoo6g@localhost> Message-ID: On Tue, Dec 4, 2018 at 11:42 AM Ben Nemec wrote: > > Copying Mike Bayer since he's our resident DB expert. One more comment > inline. so the level of abstraction oslo.db itself provides is fairly light - it steps in for the initial configuration of the database engine, for the job of reworking exceptions into something more locallized, and then for supplying a basic transactional begin/commit pattern that includes concepts that openstack uses a lot. it also has some helpers for things like special datatypes, test frameworks, and stuff like that. That is, oslo.db is not a full blown "abstraction" layer, it exposes the SQLAlchemy API which is then where you have the major level of abstraction. Given that, making oslo.db do for etcd3 what it does for SQLAlchemy would be an appropriate place for such a thing. It would be all new code and not really have much overlap with anything that's there right now, but still would be feasible at least at the level of, "get a handle to etcd3, here's the basic persistence / query pattern we use with it, here's a test framework that will allow test suites to use it". At the level of actually reading and writing data to etcd3 as well as querying, that's a bigger task, and certainly that is not a SQLAlchemy thing either. If etcd3's interface is a simple enough "get" / "put" / "query" and then some occasional special operations, those kinds of abstraction APIs are often not too terrible to write. Also note that we have a key/value database interface right now in oslo.cache which uses dogpile.cache against both memcached and redis right now. If you really only needed put/get with etcd3, it could do that also, but I would assume we have the need for more of a fine grained interface than that. Haven't studied etcd3 as of yet. But I'd be interested in supporting it in oslo somewhere. > > On 12/4/18 4:08 AM, Gorka Eguileor wrote: > > On 03/12, Julia Kreger wrote: > >> Indeed it is a considered a base service, but I'm unaware of why it was > >> decided to not have any abstraction layer on top. That sort of defeats the > >> adoption of tooz as a standard in the community. Plus with the rest of our > >> code bases, we have a number of similar or identical patterns and it would > >> be ideal to have a single library providing the overall interface for the > >> purposes of consistency. Could you provide some more background on that > >> decision? > >> > >> I guess what I'd really like to see is an oslo.db interface into etcd3. > >> > >> -Julia > > > > Hi, > > > > I think that some projects won't bother with the etcd interface since it > > would require some major rework of the whole service to get it working. > > I don't think Julia was suggesting that every project move to etcd, just > that we make it available for projects that want to use it this way. > > > > > Take Cinder for example. We do complex conditional updates that, as far > > as I know, cannot be satisfied with etcd's Compare-and-Swap > > functionality. We could modify all our code to make it support both > > relational databases and key-value stores, but I'm not convinced it > > would be worthwhile considering the huge effort it would require. > > > > I believe there are other OpenStack projects that have procedural code > > stored on the database, which would probably be hard to make compatible > > with key-value stores. > > > > Cheers, > > Gorka. > > > >> > >> On Mon, Dec 3, 2018 at 4:55 PM Fox, Kevin M wrote: > >> > >>> It is a full base service already: > >>> https://governance.openstack.org/tc/reference/base-services.html > >>> > >>> Projects have been free to use it for quite some time. I'm not sure if any > >>> actually are yet though. > >>> > >>> It was decided not to put an abstraction layer on top as its pretty simple > >>> and commonly deployed. > >>> > >>> Thanks, > >>> Kevin > >>> ------------------------------ > >>> *From:* Julia Kreger [juliaashleykreger at gmail.com] > >>> *Sent:* Monday, December 03, 2018 3:53 PM > >>> *To:* Ben Nemec > >>> *Cc:* Davanum Srinivas; geguileo at redhat.com; > >>> openstack-discuss at lists.openstack.org > >>> *Subject:* Re: [all] Etcd as DLM > >>> > >>> I would like to slightly interrupt this train of thought for an > >>> unscheduled vision of the future! > >>> > >>> What if we could allow a component to store data in etcd3's key value > >>> store like how we presently use oslo_db/sqlalchemy? > >>> > >>> While I personally hope to have etcd3 as a DLM for ironic one day, review > >>> bandwidth permitting, it occurs to me that etcd3 could be leveraged for > >>> more than just DLM. If we have a common vision to enable data storage, I > >>> suspect it might help provide overall guidance as to how we want to > >>> interact with the service moving forward. > >>> > >>> -Julia > >>> > >>> On Mon, Dec 3, 2018 at 2:52 PM Ben Nemec wrote: > >>> > >>>> Hi, > >>>> > >>>> I wanted to revisit this topic because it has come up in some downstream > >>>> discussions around Cinder A/A HA and the last time we talked about it > >>>> upstream was a year and a half ago[1]. There have certainly been changes > >>>> since then so I think it's worth another look. For context, the > >>>> conclusion of that session was: > >>>> > >>>> "Let's use etcd 3.x in the devstack CI, projects that are eventlet based > >>>> an use the etcd v3 http experimental API and those that don't can use > >>>> the etcd v3 gRPC API. Dims will submit a patch to tooz for the new > >>>> driver with v3 http experimental API. Projects should feel free to use > >>>> the DLM based on tooz+etcd3 from now on. Others projects can figure out > >>>> other use cases for etcd3." > >>>> > >>>> The main question that has come up is whether this is still the best > >>>> practice or if we should revisit the preferred drivers for etcd. Gorka > >>>> has gotten the grpc-based driver working in a Cinder driver that needs > >>>> etcd[2], so there's a question as to whether we still need the HTTP > >>>> etcd-gateway or if everything should use grpc. I will admit I'm nervous > >>>> about trying to juggle eventlet and grpc, but if it works then my only > >>>> argument is general misgivings about doing anything clever that involves > >>>> eventlet. :-) > >>>> > >>>> It looks like the HTTP API for etcd has moved out of experimental > >>>> status[3] at this point, so that's no longer an issue. There was some > >>>> vague concern from a downstream packaging perspective that the grpc > >>>> library might use a funky build system, whereas the etcd3-gateway > >>>> library only depends on existing OpenStack requirements. > >>>> > >>>> On the other hand, I don't know how much of a hassle it is to deploy and > >>>> manage a grpc-gateway. I'm kind of hoping someone has already been down > >>>> this road and can advise about what they found. > >>>> > >>>> Thanks. > >>>> > >>>> -Ben > >>>> > >>>> 1: https://etherpad.openstack.org/p/BOS-etcd-base-service > >>>> 2: > >>>> > >>>> https://github.com/embercsi/ember-csi/blob/5bd4dffe9107bc906d14a45cd819d9a659c19047/ember_csi/ember_csi.py#L1106-L1111 > >>>> 3: https://github.com/grpc-ecosystem/grpc-gateway > >>>> > >>>> From mike.carden at gmail.com Tue Dec 4 21:04:11 2018 From: mike.carden at gmail.com (Mike Carden) Date: Wed, 5 Dec 2018 08:04:11 +1100 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> Message-ID: On Tue, Dec 4, 2018 at 9:58 PM Chris Dent wrote: > > * The 'randomize_allocation_candidates' config setting is used by > the placement-api process (probably called nova-placement-api in > queens), not the nova-scheduler process, so you need to update the > config (in the placement section) for the former and restart it. > > Thanks Chris. I tried the same thing in the nova.conf of the nova_placement containers and still no joy. A check on a fresh deploy of Queens with just a couple of x86 compute nodes proves that it can work without randomize_allocation_candidates being set to True. Out of the box we get an even distribution of VMs across compute nodes. It seems that somewhere along the path of adding Ironic and some baremetal nodes and host aggregates and a PPC64LE node, the scheduling goes awry. Back to the drawing board, and the logs. -- MC -------------- next part -------------- An HTML attachment was scrubbed... URL: From dprince at redhat.com Tue Dec 4 21:18:52 2018 From: dprince at redhat.com (Dan Prince) Date: Tue, 04 Dec 2018 16:18:52 -0500 Subject: [tripleo] [validations] Replacement of undercloud_conf module In-Reply-To: References: Message-ID: On Tue, 2018-12-04 at 12:54 -0500, Emilien Macchi wrote: > Hi folks, > > Context: https://bugs.launchpad.net/tripleo/+bug/1805825 > > Today I randomly found this module: > https://github.com/openstack/tripleo-validations/blob/d21e7fa30f9be15bb980279197dc6c5206f38a38/validations/library/undercloud_conf.py > > And it gave me 2 ideas, as I think we don't need this module and > would consider it as technical debt at this point: > - it's relying on a file, which isn't super safe and flexible IMHO. We still use undercloud.conf though right? Why is it not safe (the data has to be stored somewhere right)? > - a lot of validations rely on Hieradata which isn't safe either, we > saw it with the Containerized Undercloud. Why is this not safe? I commented on the LP you linked but it seems to me that a simple fix would be to set the same hiera setting we used before so that the location of the undercloud.conf is known. We still use and support hiera for the Undercloud. It would be a simple matter to set this in an undercloud service via t-h-t. If you wanted to you could even cache a copy of the used version somewhere and then consume it that way right? Dan > > So I propose that: > - we export require parameters via the Heat templates into Ansible > variables > - we consume these variables from tripleo-validations (can be in the > inventory or a dedicated var file for validations). > > So that way we remove the dependency on having the undercloud.conf > access from Mistral Executor and also stop depending on Puppet > (hieradata) which we don't guarantee to be here in the future. > > Can someone from TripleO validations team ack this email and put this > work in your backlog? If you need assistance we're happy to help but > I believe this is an important effort to avoid technical debt here. > > Thanks, > -- > Emilien Macchi From dprince at redhat.com Tue Dec 4 21:32:31 2018 From: dprince at redhat.com (Dan Prince) Date: Tue, 04 Dec 2018 16:32:31 -0500 Subject: [tripleo] cleanup upgrade_tasks In-Reply-To: References: Message-ID: <3d8f8b993d23b2b3391a9b3abd508c0c724465cb.camel@redhat.com> On Tue, 2018-12-04 at 14:41 -0500, Emilien Macchi wrote: > Upgrade folks, > > Please take a look at https://review.openstack.org/622578. > We don't run the upgrade_tasks Ansible tasks that stop systemd > services and remove the packages since all services are > containerized. > These tasks were useful in Rocky when we converted the Undercloud > from baremetal to containers but in Stein this is not useful anymore. Would some of them be useful for fast forward upgrades in the future though? I suppose it all depends on where you draw your "upgrade lines" from major version to major version. > It's actually breaking upgrades for Podman, as containers are now > seen by systemd, and these tasks conflicts with the way containers > are managed in Paunch. Many of these steps are very similar. It seems like it would be possible to detect podman in the systemd unit file (systemctl show | grep podman) or something and then set your Ansible variables accordingly to disable the block if podman is being used. And improvement might be to put this logic into a playbook and consume it from each module. That is, if we even want to keep this upgrade code for the future. > > Thanks, > -- > Emilien Macchi From anlin.kong at gmail.com Tue Dec 4 21:35:04 2018 From: anlin.kong at gmail.com (Lingxian Kong) Date: Wed, 5 Dec 2018 10:35:04 +1300 Subject: Octavia Production Deployment Confused In-Reply-To: References: Message-ID: On Wed, Dec 5, 2018 at 6:27 AM Gaël THEROND wrote: > You can do it with any routed network that you’ll load as a provider > network too. > > Way more simpler, no need for ovs manipulation, just get your network team > to give you a vlan both available from computer node and controller plan. > It can be a network subnet and vlan completely unknown from you controller > as long as you get an intermediary equipment that route your traffic or > that you add the proper route on your controllers. > Yeah, that's also how we did for our Octavia service in production thanks to our ops team. Cheers, Lingxian Kong -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdent+os at anticdent.org Tue Dec 4 21:35:38 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Tue, 4 Dec 2018 21:35:38 +0000 (GMT) Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> Message-ID: On Wed, 5 Dec 2018, Mike Carden wrote: > On Tue, Dec 4, 2018 at 9:58 PM Chris Dent wrote: > >> >> * The 'randomize_allocation_candidates' config setting is used by >> the placement-api process (probably called nova-placement-api in >> queens), not the nova-scheduler process, so you need to update the >> config (in the placement section) for the former and restart it. > > I tried the same thing in the nova.conf of the nova_placement containers > and still no joy. Darn. > A check on a fresh deploy of Queens with just a couple of x86 compute nodes > proves that it can work without randomize_allocation_candidates being set > to True. Out of the box we get an even distribution of VMs across compute > nodes. It seems that somewhere along the path of adding Ironic and some > baremetal nodes and host aggregates and a PPC64LE node, the scheduling goes > awry. Yeah, this sort of stuff is why I was hoping we could see some of your logs, to figure out which of those things was the haymaker. If you figure it out, please post about it. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From juliaashleykreger at gmail.com Tue Dec 4 21:37:11 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Tue, 4 Dec 2018 13:37:11 -0800 Subject: [ironic] Time to discuss clean/deploy steps Message-ID: All, I've looked at the doodle poll results and it looks like the best available time is 3:00 PM UTC on Friday December 7th. I suggest we use bluejeans[2] as that has worked fairly well for us thus far. The specification documented related to the discussion can be found in review[3]. Thanks, -Julia [1] https://doodle.com/poll/yan4wyvztf7mpq46 [2] https://bluejeans.com/u/jkreger/ [3] https://review.openstack.org/#/c/606199/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Tue Dec 4 21:41:02 2018 From: smooney at redhat.com (Sean Mooney) Date: Tue, 04 Dec 2018 21:41:02 +0000 Subject: [ptl] [openstack-map] New tags for OpenStack Project Map In-Reply-To: <5C06C88C.1010303@openstack.org> References: <5C06C88C.1010303@openstack.org> Message-ID: <9fb1b60096c4cebe093a52b7ab933b01974fdf13.camel@redhat.com> On Tue, 2018-12-04 at 12:33 -0600, Jimmy McArthur wrote: > Following up on this thread from ttx [1], we are continuing to enhance > the content on the OpenStack Project Map [2],[3] through new tags that > are managed through the openstack-map repo [4]. > > * video (id, title, description) - This controls the Project Update > video you see on the project page. I've just pushed a review adding all > of the Project Updates for Berlin [5] > > * depends-on - Things that are a strong dependency. This should be used > ONLY if your component requires another one to work (e.g. nova -> glance) > > * see-also - Should list things that are a week dependency or an > adjacent relevant thing out of interest why see-also and not relates-to see-also is an imperative instruction to look at something where as relates-to is a declaritive satement about the relationship between two entities just as depends-on is for hard dependencies. > > * support-teams (name: link) - This is meant to give credit to adjacent > projects that aren't necessary to run the software (e.g. Oslo, i18n, > Docs). We are still determining how best to implement this tag, but we > feel it's important to give some credit to these other teams that are so > critical in helping to maintain, support, and build OpenStack > > If you have some time, please go to the git repo [4] and review your > project and help flesh out these new tags (or update old ones) so we can > display them in the Project Map [2]. > > Cheers, > Jimmy > > [1] > http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000178.html > > [2] > https://www.openstack.org/software/project-navigator/openstack-components > [3] https://www.openstack.org/assets/software/projectmap/openstack-map.pdf > [4] https://git.openstack.org/cgit/openstack/openstack-map/ > [5] https://review.openstack.org/622485 > From smooney at redhat.com Tue Dec 4 21:50:35 2018 From: smooney at redhat.com (Sean Mooney) Date: Tue, 04 Dec 2018 21:50:35 +0000 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> Message-ID: <4273f2ee3117b06cb52f553e2bdbb2b20a816039.camel@redhat.com> On Tue, 2018-12-04 at 21:35 +0000, Chris Dent wrote: > On Wed, 5 Dec 2018, Mike Carden wrote: > > > On Tue, Dec 4, 2018 at 9:58 PM Chris Dent wrote: > > > > > > > > * The 'randomize_allocation_candidates' config setting is used by > > > the placement-api process (probably called nova-placement-api in > > > queens), not the nova-scheduler process, so you need to update the > > > config (in the placement section) for the former and restart it. > > > > I tried the same thing in the nova.conf of the nova_placement containers > > and still no joy. > > Darn. > > > A check on a fresh deploy of Queens with just a couple of x86 compute nodes > > proves that it can work without randomize_allocation_candidates being set > > to True. Out of the box we get an even distribution of VMs across compute > > nodes. It seems that somewhere along the path of adding Ironic and some > > baremetal nodes and host aggregates and a PPC64LE node, the scheduling goes > > awry. > > Yeah, this sort of stuff is why I was hoping we could see some of > your logs, to figure out which of those things was the haymaker. so one thing that came up recently downstream was a discusion around the BuildFailureWeigher https://docs.openstack.org/nova/rocky/user/filter-scheduler.html#weights and the build_failure_weight_multiplier https://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.build_failure_weight_multiplier i wonder if failed build shoudl be leading to packing behavior. it would explain why intially it is fine but over time as host get a significant build failure weight applied that the cluster transiation form even spread to packing behaivior. > > If you figure it out, please post about it. > From johnsomor at gmail.com Tue Dec 4 22:04:00 2018 From: johnsomor at gmail.com (Michael Johnson) Date: Tue, 4 Dec 2018 14:04:00 -0800 Subject: [Nova] Increase size limits for user data In-Reply-To: References: <7a06df3739d66083a5042ad6346f77e1b8081f65.camel@redhat.com> Message-ID: The limited size of user_data (not even a floppy disk worth of space) is why Octavia has not used it either. We have used a, now deprecated, feature of config drive and nova. So, I am in full support of solving this problem. I would also like to request that we implement this in a way that we can secure the content. We use the config drive mechanism to load per-instance certificates and keys into the instance at boot time and would like to continue to use this mechanism to "seed" the instance. Our current mechanism stores the data along with the instance image, which means it is as protected as the OS image we boot. As we design the future, it would be awesome if we can provide the same or better level of protection for that content. Michael On Tue, Dec 4, 2018 at 7:34 AM Jay Pipes wrote: > > On 12/04/2018 10:09 AM, Matt Riedemann wrote: > > On 12/4/2018 8:14 AM, Flavio Percoco wrote: > >> This is the current solution, which has allowed me to move forward > >> with the work I'm doing. Regardless, I would like us to discuss this. > >> I'd rather have the limit in Nova increased than adding a dependency > >> on another service that would, very likely, only be used for this > >> specific use case. > > > > As far as the DB limit, it's not just the actual instances.user_data > > table that matters [1] it's also the build_requests.instance column [2] > > and the latter is the bigger issue since it's an entire Instance object, > > including the user_data plus whatever else (like the flavor, metadata > > and system_metadata) serialized into that single MEDIUMTEXT field. > > That's what worries me about blowing up that field if we increase the > > API limit on user_data. > > How prescient. :) > > http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000523.html > > Best, > -jay > From mike.carden at gmail.com Tue Dec 4 22:08:36 2018 From: mike.carden at gmail.com (Mike Carden) Date: Wed, 5 Dec 2018 09:08:36 +1100 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: <4273f2ee3117b06cb52f553e2bdbb2b20a816039.camel@redhat.com> References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> <4273f2ee3117b06cb52f553e2bdbb2b20a816039.camel@redhat.com> Message-ID: On Wed, Dec 5, 2018 at 8:54 AM Sean Mooney wrote: > > so one thing that came up recently downstream was a discusion around the > BuildFailureWeigher > Now there's an interesting idea. The compute node that's not being scheduled *hasn't* had build failures, but we had a lot of build failures in Ironic for a while due to the published RHEL7.6 qcow2 image having a wee typo in its grub conf. Those failures *shouldn't* influence non-ironic scheduling I'd have thought. Hmmm. -- MC -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnsomor at gmail.com Tue Dec 4 22:12:19 2018 From: johnsomor at gmail.com (Michael Johnson) Date: Tue, 4 Dec 2018 14:12:19 -0800 Subject: Octavia Production Deployment Confused In-Reply-To: References: Message-ID: Zufar, Hi. Before I start with your questions I want to let you know that the Octavia team will see your message sooner if you add the [octavia] prefix to your e-mail subject line. As for the questions: 1. Yes, that should work, but the services project is usually named "service". It gives the Octavia service more permissions that it really needs, but will work as a starting point. 2. This can be accomplished in many ways. The traffic on the "lb-mgmt-net" is IP based, so can be routed if you need in your deployment. Others will use a provider network. Devstack pops a port off the neutron OVS. It might be helpful for you to look at our devstack setup script: https://github.com/openstack/octavia/blob/master/devstack/plugin.sh and/or the OpenStack Ansible role for Octavia: https://github.com/openstack/openstack-ansible-os_octavia for examples. As always, we hang out in the #openstack-lbaas IRC channel if you would like to chat about your deployment. Michael On Tue, Dec 4, 2018 at 8:21 AM Zufar Dhiyaulhaq wrote: > > Hi, I want to implement Octavia service in OpenStack Queens. > > I am stuck on two-step : > 1. Create Octavia User > > I am trying to create Octavia user with this command, is this the right way? > > openstack user create octavia --domain default --password octavia > openstack role add --user octavia --project services admin > > openstack service create --name octavia --description "OpenStack Octavia" load-balancer > openstack endpoint create --region RegionOne octavia public http://10.60.60.10:9876 > openstack endpoint create --region RegionOne octavia internal http://10.60.60.10:9876 > openstack endpoint create --region RegionOne octavia admin http://10.60.60.10:9876 > > 2. Load Balancer Network Configuration > "Add appropriate routing to/from the ‘lb-mgmt-net’ such that egress is allowed, and the controller (to be created later) can talk to hosts on this network." > > I don't know how to route from controller host into a private network, is any specific command for doing that? > > following tutorial from https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html#running-octavia-in-production. > > Thank You > Best Regards, > Zufar Dhiyaulhaq From mikal at stillhq.com Tue Dec 4 22:25:27 2018 From: mikal at stillhq.com (Michael Still) Date: Wed, 5 Dec 2018 09:25:27 +1100 Subject: [Nova] Increase size limits for user data In-Reply-To: References: <7a06df3739d66083a5042ad6346f77e1b8081f65.camel@redhat.com> Message-ID: Have you looked at vendor data? It gives you a trusted way to inject arbitrary data into a config drive (or metadata server call), where that additional data isn't stored by nova and can be of an arbitrary size. Michael On Wed, Dec 5, 2018 at 9:07 AM Michael Johnson wrote: > The limited size of user_data (not even a floppy disk worth of space) > is why Octavia has not used it either. We have used a, now deprecated, > feature of config drive and nova. > > So, I am in full support of solving this problem. > > I would also like to request that we implement this in a way that we > can secure the content. We use the config drive mechanism to load > per-instance certificates and keys into the instance at boot time and > would like to continue to use this mechanism to "seed" the instance. > Our current mechanism stores the data along with the instance image, > which means it is as protected as the OS image we boot. > > As we design the future, it would be awesome if we can provide the > same or better level of protection for that content. > > Michael > On Tue, Dec 4, 2018 at 7:34 AM Jay Pipes wrote: > > > > On 12/04/2018 10:09 AM, Matt Riedemann wrote: > > > On 12/4/2018 8:14 AM, Flavio Percoco wrote: > > >> This is the current solution, which has allowed me to move forward > > >> with the work I'm doing. Regardless, I would like us to discuss this. > > >> I'd rather have the limit in Nova increased than adding a dependency > > >> on another service that would, very likely, only be used for this > > >> specific use case. > > > > > > As far as the DB limit, it's not just the actual instances.user_data > > > table that matters [1] it's also the build_requests.instance column [2] > > > and the latter is the bigger issue since it's an entire Instance > object, > > > including the user_data plus whatever else (like the flavor, metadata > > > and system_metadata) serialized into that single MEDIUMTEXT field. > > > That's what worries me about blowing up that field if we increase the > > > API limit on user_data. > > > > How prescient. :) > > > > > http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000523.html > > > > Best, > > -jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juliaashleykreger at gmail.com Tue Dec 4 22:45:45 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Tue, 4 Dec 2018 14:45:45 -0800 Subject: [TC] Forum TC Vision Retrospective summary Message-ID: During the Forum in Berlin, the Technical Committee along with interested community members took some time to look back at the vision that written in early 2017. We had three simple questions: * What went well? * What needs improvement? * What should the next steps be? To summarize, the group thought the vision helped guide some thoughts and decisions. Helped provide validation on what was thought to be important. We have seen adjacent communities fostered. We didn't solely focus on the vision which was viewed as a positive as things do change over time. It helped us contrast, and in the process of writing the vision we reached the use of the same words. Most importantly, we learned that we took on too much work. As with most retrospectives, the list of things that needed improvement was a bit longer. There was some perception that it fell off the map, and that not every item received work. Possibly that we even took the vision too literally and too detailed as opposed to use it as more a guiding document to help us evolve as time goes on. There was consensus that there was still room to improve and that we could have done a better at conveying context to express how, what, and why. For next steps, we feel that it is time to revise the vision, albeit in a shorter form. We also felt that there could be a vision for the TC itself, which led to the discussion of providing clarity to the role of the Technical Committee. As for action items and next steps that we reached consensus on: * To refine the technical vision document. * That it was time to compose a new vision for the community. * Consensus was reached that there should be a vision of the TC itself, and as part of this have a living document that describes the "Role of the TC". ** ttx, cdent, and TheJulia have volunteered to continue those discussions. ** mnaser would start a discussion with the community as to what the TC should and shouldn't do. For those reading this, please remember that the TC's role is defined in the foundation bylaws, so this would be more of a collection of perceptions. * TheJulia to propose a governance update to suggest that people proposing TC candidacy go ahead and preemptively seek to answer the question of what the candidate perceives as the role of the TC. The etherpad that followed the discussion can be found at: https://etherpad.openstack.org/p/BER-tc-vision-retrospective -Julia -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufar at onf-ambassador.org Tue Dec 4 23:54:09 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Wed, 5 Dec 2018 06:54:09 +0700 Subject: Octavia Production Deployment Confused In-Reply-To: References: Message-ID: Hi all, Thank you, So the amphora will use a provider network. but how we can access this load balancer externally? via IP assign into amphora (provider network IP)? Another question, I am facing a problem with a keypair. I am generating a keypair with `create_certificates.sh` source /tmp/octavia/bin/create_certificates.sh /etc/octavia/certs /tmp/octavia/etc/certificates/openssl.cnf but when creating the load balancer service, I got this error from /var/log/octavia/worker.log ERROR oslo_messaging.rpc.server CertificateGenerationException: Could not sign the certificate request: Failed to load CA Private Key /etc/octavia/certs/private/cakey.pem. I am using this configuration under octavia.conf [certificates] ca_certificate = /etc/octavia/certs/ca_01.pem ca_private_key = /etc/octavia/certs/private/cakey.pem ca_private_key_passphrase = foobar Anyone know this issue? I am following Mr. Lingxian Kong blog in https://lingxiankong.github.io/2016-06-07-octavia-deployment-prerequisites.html Best Regards, Zufar Dhiyaulhaq On Wed, Dec 5, 2018 at 4:35 AM Lingxian Kong wrote: > On Wed, Dec 5, 2018 at 6:27 AM Gaël THEROND > wrote: > >> You can do it with any routed network that you’ll load as a provider >> network too. >> >> Way more simpler, no need for ovs manipulation, just get your network >> team to give you a vlan both available from computer node and controller >> plan. It can be a network subnet and vlan completely unknown from you >> controller as long as you get an intermediary equipment that route your >> traffic or that you add the proper route on your controllers. >> > > Yeah, that's also how we did for our Octavia service in production thanks > to our ops team. > > Cheers, > Lingxian Kong > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufardhiyaulhaq at gmail.com Tue Dec 4 23:57:41 2018 From: zufardhiyaulhaq at gmail.com (Zufar Dhiyaulhaq) Date: Wed, 5 Dec 2018 06:57:41 +0700 Subject: Octavia Production Deployment Confused In-Reply-To: References: Message-ID: Hi Michael, Thank you, I create with `services` because when I am trying to list the project, its give me `services` [root at zu-controller0 ~(keystone_admin)]# openstack project list | 27439cc0ba52421cad2426c980a0d0fa | admin | | 4020d4a5e7ad4d279fc3d1916d18ced1 | services | Best Regards, Zufar Dhiyaulhaq On Wed, Dec 5, 2018 at 5:12 AM Michael Johnson wrote: > Zufar, > > Hi. Before I start with your questions I want to let you know that the > Octavia team will see your message sooner if you add the [octavia] > prefix to your e-mail subject line. > > As for the questions: > 1. Yes, that should work, but the services project is usually named > "service". It gives the Octavia service more permissions that it > really needs, but will work as a starting point. > 2. This can be accomplished in many ways. The traffic on the > "lb-mgmt-net" is IP based, so can be routed if you need in your > deployment. Others will use a provider network. Devstack pops a port > off the neutron OVS. > > It might be helpful for you to look at our devstack setup script: > https://github.com/openstack/octavia/blob/master/devstack/plugin.sh > and/or > > the OpenStack Ansible role for Octavia: > https://github.com/openstack/openstack-ansible-os_octavia for > examples. > > As always, we hang out in the #openstack-lbaas IRC channel if you > would like to chat about your deployment. > > Michael > > On Tue, Dec 4, 2018 at 8:21 AM Zufar Dhiyaulhaq > wrote: > > > > Hi, I want to implement Octavia service in OpenStack Queens. > > > > I am stuck on two-step : > > 1. Create Octavia User > > > > I am trying to create Octavia user with this command, is this the right > way? > > > > openstack user create octavia --domain default --password octavia > > openstack role add --user octavia --project services admin > > > > openstack service create --name octavia --description "OpenStack > Octavia" load-balancer > > openstack endpoint create --region RegionOne octavia public > http://10.60.60.10:9876 > > openstack endpoint create --region RegionOne octavia internal > http://10.60.60.10:9876 > > openstack endpoint create --region RegionOne octavia admin > http://10.60.60.10:9876 > > > > 2. Load Balancer Network Configuration > > "Add appropriate routing to/from the ‘lb-mgmt-net’ such that egress is > allowed, and the controller (to be created later) can talk to hosts on this > network." > > > > I don't know how to route from controller host into a private network, > is any specific command for doing that? > > > > following tutorial from > https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html#running-octavia-in-production > . > > > > Thank You > > Best Regards, > > Zufar Dhiyaulhaq > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Wed Dec 5 00:35:32 2018 From: mnaser at vexxhost.com (Mohammed Naser) Date: Tue, 4 Dec 2018 19:35:32 -0500 Subject: [openstack-ansible] avoid approving changes hitting centos-7 jobs Message-ID: <82905CC8-29BF-4A81-ACEA-F3A3DE917401@vexxhost.com> Hi everyone: With the release of CentOS 7.6, we are unable to merge any code which runs on CentOS 7 because of the fact that our containers are still 7.5 however the host is 7.6 There is an issue open to get CentOS 7.6 images in: https://github.com/CentOS/sig-cloud-instance-images/issues/133 We’re hoping that upstream can provide this CentOS image soon to unbreak us but until then we’ll be blocked. I’ll try to reach out to anyone on the CentOS 7 team who can help us, but for the meantime, let’s avoid approving anything with voting CentOS 7 jobs. Thanks! Mohammed From emilien at redhat.com Wed Dec 5 00:37:14 2018 From: emilien at redhat.com (Emilien Macchi) Date: Tue, 4 Dec 2018 19:37:14 -0500 Subject: [tripleo] [validations] Replacement of undercloud_conf module In-Reply-To: References: Message-ID: On Tue, Dec 4, 2018 at 4:18 PM Dan Prince wrote: > Why is this not safe? > > I commented on the LP you linked but it seems to me that a simple fix > would be to set the same hiera setting we used before so that the > location of the undercloud.conf is known. We still use and support > hiera for the Undercloud. It would be a simple matter to set this in an > undercloud service via t-h-t. If you wanted to you could even cache a > copy of the used version somewhere and then consume it that way right? > I guess I wanted to use proper Ansible variables instead of Hiera, since we are moving toward more Ansible. That's all. I found it cleaner and simpler than relying on undercloud.conf file. -- Emilien Macchi -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Wed Dec 5 01:02:02 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 05 Dec 2018 10:02:02 +0900 Subject: [dev] [tc][all] TC office hours is started now on #openstack-tc Message-ID: <1677be2d414.b86749a695953.736336492767392639@ghanshyammann.com> Hello everyone, 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. - gmann & TC From emilien at redhat.com Wed Dec 5 01:53:15 2018 From: emilien at redhat.com (Emilien Macchi) Date: Tue, 4 Dec 2018 20:53:15 -0500 Subject: [tripleo] cleanup upgrade_tasks In-Reply-To: <3d8f8b993d23b2b3391a9b3abd508c0c724465cb.camel@redhat.com> References: <3d8f8b993d23b2b3391a9b3abd508c0c724465cb.camel@redhat.com> Message-ID: On Tue, Dec 4, 2018 at 4:32 PM Dan Prince wrote: > Would some of them be useful for fast forward upgrades in the future > though? I suppose it all depends on where you draw your "upgrade lines" > from major version to major version. > AFIK these tasks aren't useful in master (Stein) for FFU, as they were used between Newton and Queens. Since Queens only have containerized undercloud, and Undercloud isn't upgraded via FFU, I think these tasks could be removed. Many of these steps are very similar. It seems like it would be > possible to detect podman in the systemd unit file (systemctl show > | grep podman) or something and then set your Ansible > variables accordingly to disable the block if podman is being used. > > And improvement might be to put this logic into a playbook and consume > it from each module. That is, if we even want to keep this upgrade code > for the future. > Indeed, if upgrade team wants to keep or refactor them [0], it's fine. [0] https://review.openstack.org/#/c/582502 -- Emilien Macchi -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at bakeyournoodle.com Wed Dec 5 05:02:10 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Wed, 5 Dec 2018 16:02:10 +1100 Subject: [openstack-dev] [puppet] [stable] Deprecation of newton branches In-Reply-To: References: <2ae10ca2-8c77-ccbc-c009-a22c1d3cfd69@binero.se> Message-ID: <20181205050207.GA19462@thor.bakeyournoodle.com> On Thu, Nov 29, 2018 at 11:38:45AM +0100, Tobias Urdin wrote: > 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? Just to be clear You're asking for the following repos to be marked EOL (current origin/stable/newton tagged as newton-eol and deleted, any open reviews abandoned) : # EOL repos belonging to Puppet OpenStack eol_branch.sh -- stable/newton newton-eol \ openstack/puppet-aodh openstack/puppet-barbican \ openstack/puppet-ceilometer openstack/puppet-cinder \ openstack/puppet-designate openstack/puppet-glance \ openstack/puppet-gnocchi openstack/puppet-heat \ openstack/puppet-horizon openstack/puppet-ironic \ openstack/puppet-keystone openstack/puppet-magnum \ openstack/puppet-manila openstack/puppet-mistral \ openstack/puppet-murano openstack/puppet-neutron \ openstack/puppet-nova \ openstack/puppet-openstack-integration \ openstack/puppet-openstack_extras \ openstack/puppet-openstack_spec_helper \ openstack/puppet-openstacklib openstack/puppet-oslo \ openstack/puppet-ovn openstack/puppet-sahara \ openstack/puppet-swift openstack/puppet-tempest \ openstack/puppet-trove openstack/puppet-vswitch \ openstack/puppet-zaqar 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 anlin.kong at gmail.com Wed Dec 5 08:07:53 2018 From: anlin.kong at gmail.com (Lingxian Kong) Date: Wed, 5 Dec 2018 21:07:53 +1300 Subject: [ptl] [openstack-map] New tags for OpenStack Project Map In-Reply-To: <5C06C88C.1010303@openstack.org> References: <5C06C88C.1010303@openstack.org> Message-ID: On Wed, Dec 5, 2018 at 7:35 AM Jimmy McArthur wrote: > Following up on this thread from ttx [1], we are continuing to enhance > the content on the OpenStack Project Map [2],[3] through new tags that > are managed through the openstack-map repo [4]. > > * video (id, title, description) - This controls the Project Update > video you see on the project page. I've just pushed a review adding all > of the Project Updates for Berlin [5] > I'm wondering where does the id come from? Youtube URL suffix? Cheers, Lingxian Kong -------------- next part -------------- An HTML attachment was scrubbed... URL: From stig.openstack at telfer.org Wed Dec 5 08:14:27 2018 From: stig.openstack at telfer.org (Stig Telfer) Date: Wed, 5 Dec 2018 08:14:27 +0000 Subject: [scientific-sig] No IRC Meeting today Message-ID: <2CA0C7F5-8D50-4A27-A7E2-B9E5E9ABCDB8@telfer.org> Hi all - Apologies, there will be no Scientific SIG IRC meeting today. It’s too busy a week on other fronts. We’ll carry over agenda items to the next session and hopefully make up for lost time there. Best wishes, Stig From bdobreli at redhat.com Wed Dec 5 08:39:54 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Wed, 5 Dec 2018 09:39:54 +0100 Subject: [tripleo] [validations] Replacement of undercloud_conf module In-Reply-To: References: Message-ID: <093221e3-33f0-6258-5f4f-e7a139f8f083@redhat.com> On 12/5/18 1:37 AM, Emilien Macchi wrote: > > > On Tue, Dec 4, 2018 at 4:18 PM Dan Prince > wrote: > > Why is this not safe? > > I commented on the LP you linked but it seems to me that a simple fix > would be to set the same hiera setting we used before so that the > location of the undercloud.conf is known. We still use and support > hiera for the Undercloud. It would be a simple matter to set this in an > undercloud service via t-h-t. If you wanted to you could even cache a > copy of the used version somewhere and then consume it that way right? > > > I guess I wanted to use proper Ansible variables instead of Hiera, since > we are moving toward more Ansible. That's all. > I found it cleaner and simpler than relying on undercloud.conf file. +1 > -- > Emilien Macchi -- Best regards, Bogdan Dobrelya, Irc #bogdando From thierry at openstack.org Wed Dec 5 08:57:54 2018 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 5 Dec 2018 09:57:54 +0100 Subject: [TC] Forum TC Vision Retrospective summary In-Reply-To: References: Message-ID: Julia Kreger wrote: > * Consensus was reached that there should be a vision of the TC itself, > and as part of this have a living document that describes the "Role of > the TC". > ** ttx, cdent, and TheJulia have volunteered to continue those discussions. > ** mnaser would start a discussion with the community as to what the TC > should and shouldn't do. For those reading this, please remember that > the TC's role is defined in the foundation bylaws, so this would be more > of a collection of perceptions. A first draft of that document was posted for early comments at: https://review.openstack.org/#/c/622400/ -- Thierry Carrez (ttx) From lajos.katona at ericsson.com Wed Dec 5 08:58:03 2018 From: lajos.katona at ericsson.com (Lajos Katona) Date: Wed, 5 Dec 2018 08:58:03 +0000 Subject: [dev][nova][placement][qa] opinion on adding placement tests support in Tempest In-Reply-To: References: <16778b864ea.ed28ea0d72714.6704537180908793759@ghanshyammann.com> <52060b98-74f5-3a3a-1b51-8cba8aa7b00c@gmail.com> Message-ID: <3d5fea81-f2f9-8522-ce88-18d393be652d@ericsson.com> Thanks, I uploaded the patch only to start the conversation early, I plan to add all the necessary methods to cover the needs now for bandwidth, and have a basic framework for adding more things later. Regards Lajos On 2018. 12. 04. 19:50, Archit Modi wrote: Great! There is already a patch from Lajos [1]. I'd like resource_provider_aggregates_client to be added too. (/resource_providers/{uuid}/aggregates) [1] https://review.openstack.org/#/c/622316/ On Tue, Dec 4, 2018 at 1:32 PM Chris Dent > wrote: On Tue, 4 Dec 2018, Dan Smith wrote: >> On 12/04/2018 06:13 AM, Chris Dent wrote: >>> Existing Tempests tests that do things like launching, resizing, >>> migrating servers already touch placement so may be sufficient. If >>> we wanted to make these more complete adding verification of >>> resource providers and their inventories before and after the tests >>> might be useful. [snip] > I don't disagree either. However, I do think that there are cases where > it may make sense to be _able_ to hit the placement endpoint from > tempest in order to verify that certain things are happening, even in a > scenario that involves other services. [snip] Based on conversation with Dan in IRC, we decided it might be useful to clarify that Dan and I are in agreement. It had seemed to me that he was saying something different from me, but we're both basically saying "yes, tempest needs to be able to talk to placement to confirm what it's holding because that's useful sometimes" and "no, tempest doesn't need to verify the workings of placement api itself". Which boils out to this: > I *think* that gmann's > question in the email was actually about placement endpoint support, > which is the former, and I think is probably legit. Yes. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent -------------- next part -------------- An HTML attachment was scrubbed... URL: From aspiers at suse.com Tue Dec 4 23:54:20 2018 From: aspiers at suse.com (Adam Spiers) Date: Tue, 4 Dec 2018 23:54:20 +0000 Subject: [tc][all][self-healing-sig] Train Community Goals In-Reply-To: References: Message-ID: <20181204235419.bi7txdhnz45bsasf@pacific.linksys.moosehall> Lance Bragstad wrote: >Hi all, > >The purpose of this thread is to have a more focused discussion about what >we'd like to target for Train community goals, bootstrapped with the >outcomes from the session in Berlin [0]. > >During the session, we went through each item as a group and let the person >who added it share why they thought it would be a good community goal >candidate for the next release. Most goals have feedback captured in >etherpad describing next steps, but the following stuck out as top >contenders from the session (rated by upvotes): > > 1. Moving legacy clients to python-openstackclient > 2. Cleaning up resources when deleting a project > 3. Service-side health checks > >I don't think I missed any goals from the session, but if I did, please let >me know and I'll add it to the list so that we can discuss it here. > >Does anyone have strong opinions either way about the goals listed above? > >[0] https://etherpad.openstack.org/p/BER-t-series-goals I'm a fan of 3. service-side health checks, since I've been having discussions about this with various parties at the last 3--6 (I lost count) Forum / PTG events, and every time there seems to have been a decent amount of interest, e.g. - Deployment solutions have a clear motive for being able to programmatically determine a more accurate picture of the health of services, e.g. k8s-based deployments like Airship where containers would benefit from more accurate liveness probes. - The Self-healing SIG is obviously a natural customer for this functionality, since before you can heal you need to know what exactly needs healing. - It could benefit specific projects such as Vitrage, Horizon, and Monasca, and also automated tests / CI. Other factors it has in its favour as a community goal is that it's not too ambitious as to prevent a significant amount of progress in one cycle, and also progress should be easily measurable. FWIW here's some history ... For a good while we got stuck bike-shedding the spec: https://review.openstack.org/#/c/531456/ but in the API SIG session in Denver, we managed to break the deadlock and agreed to do the simplest thing which could possibly work in order to move forwards: https://etherpad.openstack.org/p/api-sig-stein-ptg Yes, there are many unresolved questions about the long-term design, but we decided to avoid any further paralysis and instead forge ahead based on the following principles: - The existing oslo.middleware mechanism is a good start, so just add a /v2 endpoint to avoid breaking existing consumers. - Only worry about API services for now. - Don't worry about authentication yet. - Endpoints should only report on their own health, not on the health of dependencies / related services. In Berlin Graham (@mugsie) pushed a very rough prototype to Gerrit: https://review.openstack.org/#/c/617924/ There's a story in StoryBoard tracking all of this. I've just updated it in an attempt to capture all the relevant history: https://storyboard.openstack.org/#!/story/2001439 From aspiers at suse.com Wed Dec 5 00:07:30 2018 From: aspiers at suse.com (Adam Spiers) Date: Wed, 5 Dec 2018 00:07:30 +0000 Subject: [self-healing-sig] reminder: self-healing SIG IRC meetings tomorrow (Wed) Message-ID: <20181205000730.rgutstasf4xkhato@pacific.linksys.moosehall> Just a reminder that the second batch of the new series of IRC meetings for the self-healing SIG are happening tomorrow (well, today depending on where you live), i.e. Wednesday at 0900 UTC and 1700 UTC, in the #openstack-self-healing channel on Freenode: http://eavesdrop.openstack.org/#Self-healing_SIG_Meeting All are welcome! From geguileo at redhat.com Wed Dec 5 09:30:39 2018 From: geguileo at redhat.com (Gorka Eguileor) Date: Wed, 5 Dec 2018 10:30:39 +0100 Subject: [all] Etcd as DLM In-Reply-To: References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> <1A3C52DFCD06494D8528644858247BF01C24C6BD@EX10MBOX03.pnnl.gov> <20181204100812.og33xegl2fxmoo6g@localhost> Message-ID: <20181205093039.a7hv4lgo55aywhd7@localhost> On 04/12, Ben Nemec wrote: > Copying Mike Bayer since he's our resident DB expert. One more comment > inline. > > On 12/4/18 4:08 AM, Gorka Eguileor wrote: > > On 03/12, Julia Kreger wrote: > > > Indeed it is a considered a base service, but I'm unaware of why it was > > > decided to not have any abstraction layer on top. That sort of defeats the > > > adoption of tooz as a standard in the community. Plus with the rest of our > > > code bases, we have a number of similar or identical patterns and it would > > > be ideal to have a single library providing the overall interface for the > > > purposes of consistency. Could you provide some more background on that > > > decision? > > > > > > I guess what I'd really like to see is an oslo.db interface into etcd3. > > > > > > -Julia > > > > Hi, > > > > I think that some projects won't bother with the etcd interface since it > > would require some major rework of the whole service to get it working. > > I don't think Julia was suggesting that every project move to etcd, just > that we make it available for projects that want to use it this way. > Hi, My bad, I assumed that was the intention, otherwise, shouldn't we first ask how many projects would start using this key-value interface if it did exist? I mean, if there's only going to be 1 project using it, then it may be better to go with the standard pattern of implementing it in that project, and only extract it once there is a need for such a common library. Cheers, Gorka. > > > > Take Cinder for example. We do complex conditional updates that, as far > > as I know, cannot be satisfied with etcd's Compare-and-Swap > > functionality. We could modify all our code to make it support both > > relational databases and key-value stores, but I'm not convinced it > > would be worthwhile considering the huge effort it would require. > > > > I believe there are other OpenStack projects that have procedural code > > stored on the database, which would probably be hard to make compatible > > with key-value stores. > > > > Cheers, > > Gorka. > > > > > > > > On Mon, Dec 3, 2018 at 4:55 PM Fox, Kevin M wrote: > > > > > > > It is a full base service already: > > > > https://governance.openstack.org/tc/reference/base-services.html > > > > > > > > Projects have been free to use it for quite some time. I'm not sure if any > > > > actually are yet though. > > > > > > > > It was decided not to put an abstraction layer on top as its pretty simple > > > > and commonly deployed. > > > > > > > > Thanks, > > > > Kevin > > > > ------------------------------ > > > > *From:* Julia Kreger [juliaashleykreger at gmail.com] > > > > *Sent:* Monday, December 03, 2018 3:53 PM > > > > *To:* Ben Nemec > > > > *Cc:* Davanum Srinivas; geguileo at redhat.com; > > > > openstack-discuss at lists.openstack.org > > > > *Subject:* Re: [all] Etcd as DLM > > > > > > > > I would like to slightly interrupt this train of thought for an > > > > unscheduled vision of the future! > > > > > > > > What if we could allow a component to store data in etcd3's key value > > > > store like how we presently use oslo_db/sqlalchemy? > > > > > > > > While I personally hope to have etcd3 as a DLM for ironic one day, review > > > > bandwidth permitting, it occurs to me that etcd3 could be leveraged for > > > > more than just DLM. If we have a common vision to enable data storage, I > > > > suspect it might help provide overall guidance as to how we want to > > > > interact with the service moving forward. > > > > > > > > -Julia > > > > > > > > On Mon, Dec 3, 2018 at 2:52 PM Ben Nemec wrote: > > > > > > > > > Hi, > > > > > > > > > > I wanted to revisit this topic because it has come up in some downstream > > > > > discussions around Cinder A/A HA and the last time we talked about it > > > > > upstream was a year and a half ago[1]. There have certainly been changes > > > > > since then so I think it's worth another look. For context, the > > > > > conclusion of that session was: > > > > > > > > > > "Let's use etcd 3.x in the devstack CI, projects that are eventlet based > > > > > an use the etcd v3 http experimental API and those that don't can use > > > > > the etcd v3 gRPC API. Dims will submit a patch to tooz for the new > > > > > driver with v3 http experimental API. Projects should feel free to use > > > > > the DLM based on tooz+etcd3 from now on. Others projects can figure out > > > > > other use cases for etcd3." > > > > > > > > > > The main question that has come up is whether this is still the best > > > > > practice or if we should revisit the preferred drivers for etcd. Gorka > > > > > has gotten the grpc-based driver working in a Cinder driver that needs > > > > > etcd[2], so there's a question as to whether we still need the HTTP > > > > > etcd-gateway or if everything should use grpc. I will admit I'm nervous > > > > > about trying to juggle eventlet and grpc, but if it works then my only > > > > > argument is general misgivings about doing anything clever that involves > > > > > eventlet. :-) > > > > > > > > > > It looks like the HTTP API for etcd has moved out of experimental > > > > > status[3] at this point, so that's no longer an issue. There was some > > > > > vague concern from a downstream packaging perspective that the grpc > > > > > library might use a funky build system, whereas the etcd3-gateway > > > > > library only depends on existing OpenStack requirements. > > > > > > > > > > On the other hand, I don't know how much of a hassle it is to deploy and > > > > > manage a grpc-gateway. I'm kind of hoping someone has already been down > > > > > this road and can advise about what they found. > > > > > > > > > > Thanks. > > > > > > > > > > -Ben > > > > > > > > > > 1: https://etherpad.openstack.org/p/BOS-etcd-base-service > > > > > 2: > > > > > > > > > > https://github.com/embercsi/ember-csi/blob/5bd4dffe9107bc906d14a45cd819d9a659c19047/ember_csi/ember_csi.py#L1106-L1111 > > > > > 3: https://github.com/grpc-ecosystem/grpc-gateway > > > > > > > > > > From flfuchs at redhat.com Wed Dec 5 09:36:44 2018 From: flfuchs at redhat.com (Florian Fuchs) Date: Wed, 5 Dec 2018 10:36:44 +0100 Subject: [tripleo] [validations] Replacement of undercloud_conf module In-Reply-To: References: Message-ID: On Tue, Dec 4, 2018 at 10:20 PM Dan Prince wrote: > > On Tue, 2018-12-04 at 12:54 -0500, Emilien Macchi wrote: > > Hi folks, > > > > Context: https://bugs.launchpad.net/tripleo/+bug/1805825 > > > > Today I randomly found this module: > > https://github.com/openstack/tripleo-validations/blob/d21e7fa30f9be15bb980279197dc6c5206f38a38/validations/library/undercloud_conf.py > > > > And it gave me 2 ideas, as I think we don't need this module and > > would consider it as technical debt at this point: > > - it's relying on a file, which isn't super safe and flexible IMHO. > > We still use undercloud.conf though right? Why is it not safe (the data > has to be stored somewhere right)? > > > - a lot of validations rely on Hieradata which isn't safe either, we > > saw it with the Containerized Undercloud. > > Why is this not safe? > > I commented on the LP you linked but it seems to me that a simple fix > would be to set the same hiera setting we used before so that the > location of the undercloud.conf is known. We still use and support > hiera for the Undercloud. It would be a simple matter to set this in an > undercloud service via t-h-t. If you wanted to you could even cache a > copy of the used version somewhere and then consume it that way right? I guess this is pretty much what's happening in this patch (at least partly): https://review.openstack.org/#/c/614470/ However, I agree with Emilien that it's a good idea to remove the dependency on puppet/hieradata in favor of ansibles vars. > > Dan > > > > > So I propose that: > > - we export require parameters via the Heat templates into Ansible > > variables > > - we consume these variables from tripleo-validations (can be in the > > inventory or a dedicated var file for validations). Since tripleo-validations consume the inventory with every validation run anyway, I'm slightly in favor of storing the variables there instead of an extra validations file. Florian > > > > So that way we remove the dependency on having the undercloud.conf > > access from Mistral Executor and also stop depending on Puppet > > (hieradata) which we don't guarantee to be here in the future. > > > > Can someone from TripleO validations team ack this email and put this > > work in your backlog? If you need assistance we're happy to help but > > I believe this is an important effort to avoid technical debt here. > > > > Thanks, > > -- > > Emilien Macchi > > From thierry at openstack.org Wed Dec 5 10:31:10 2018 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 5 Dec 2018 11:31:10 +0100 Subject: [loci] Release management for LOCI In-Reply-To: <3855B170-6E38-4DB9-A91C-9389D16D387F@openstack.org> References: <3855B170-6E38-4DB9-A91C-9389D16D387F@openstack.org> Message-ID: <64a34fd9-d31b-5d7d-ae94-053d9bdebbad@openstack.org> Chris Hoge wrote: > [...] > 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. Looking at the meeting logs it appears the position has not changed. I proposed as a result: https://review.openstack.org/622902 Cheers, -- Thierry Carrez (ttx) From thierry at openstack.org Wed Dec 5 10:32:51 2018 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 5 Dec 2018 11:32:51 +0100 Subject: [dev][qa][devstack] Release management for QA toold and plugins In-Reply-To: <16771aa6641.f7035e7c28699.479407897586326349@ghanshyammann.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> <16771aa6641.f7035e7c28699.479407897586326349@ghanshyammann.com> Message-ID: Ghanshyam Mann wrote: > ---- On Fri, 30 Nov 2018 19:05:36 +0900 Thierry Carrez wrote ---- > > [...] > > 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 ! > > +1. Those looks good. Thanks. See: https://review.openstack.org/622903 https://review.openstack.org/622904 https://review.openstack.org/#/c/622919/ Cheers, -- Thierry Carrez (ttx) From gmann at ghanshyammann.com Wed Dec 5 10:53:43 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 05 Dec 2018 19:53:43 +0900 Subject: [dev][nova][placement][qa] opinion on adding placement tests support in Tempest In-Reply-To: References: <16778b864ea.ed28ea0d72714.6704537180908793759@ghanshyammann.com> <52060b98-74f5-3a3a-1b51-8cba8aa7b00c@gmail.com> Message-ID: <1677e0088f3.c1fe7968101627.2677144604314914637@ghanshyammann.com> ---- On Wed, 05 Dec 2018 03:30:56 +0900 Chris Dent wrote ---- > On Tue, 4 Dec 2018, Dan Smith wrote: > > >> On 12/04/2018 06:13 AM, Chris Dent wrote: > >>> Existing Tempests tests that do things like launching, resizing, > >>> migrating servers already touch placement so may be sufficient. If > >>> we wanted to make these more complete adding verification of > >>> resource providers and their inventories before and after the tests > >>> might be useful. > > [snip] > > > I don't disagree either. However, I do think that there are cases where > > it may make sense to be _able_ to hit the placement endpoint from > > tempest in order to verify that certain things are happening, even in a > > scenario that involves other services. > > [snip] > > Based on conversation with Dan in IRC, we decided it might be useful > to clarify that Dan and I are in agreement. It had seemed to me that > he was saying something different from me, but we're both basically > saying "yes, tempest needs to be able to talk to placement to > confirm what it's holding because that's useful sometimes" and "no, > tempest doesn't need to verify the workings of placement api itself". Yeah, that is what we wanted. I think I mentioned that in my original mail but that sentence was not so clear. There will not be any overlap/duplicate tests between what existing functional test cover and what Tempest is going to cover. Tempest will need to talk to placement for extra verification in Tempest tests. Verify only placement API working is not in scope of Tempest. Which is nothing but : - Adding placement service clients with unit test coverage only - Those service client will be added on need basis. We do not want to maintain the unused service clients. - Use those service clients to talk to placement for extra verification in tests. > > Which boils out to this: > > > I *think* that gmann's > > question in the email was actually about placement endpoint support, > > which is the former, and I think is probably legit. > > Yes. Great, we all are on same page now. -gmann > > -- > Chris Dent ٩◔̯◔۶ https://anticdent.org/ > freenode: cdent tw: @anticdent From bdobreli at redhat.com Wed Dec 5 11:08:56 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Wed, 5 Dec 2018 12:08:56 +0100 Subject: [all][tc][Edge][FEMDC][tripleo][akraino][starlingx] Chronicles Of A Causal Consistency Message-ID: Background. Fact 0. Edge MVP reference architectures are limited to a single control plane that uses a central/global data backend by usual for boring Cloud computing meanings. Fact 1. Edge clouds in Fog computing world are WAN-distributed. Far and middle-level tiers may be communicating to their control planes over high-latency (~50/100ms or more) connections. Fact 2. Post-MVP phases [0] of future reference architectures for Edge imply high autonomity of edge sites (aka cloudlets [1][2]), which is having multiple control planes always maintaining CRUD operations locally and replicating shared state asynchronously, only when "uplinks" are available, if available at all. Fact 3. Distributed Compute Node in the post-MVP phases represents a multi-tiered star topology with middle-layer control planes aggregating thousands of computes at far edge sites and serving CRUD operations for those locally and fully autonomous to upper aggregation edge layers [3]. Those in turn might be aggregating tens of thousands of computes via tens/hundreds of such middle layers. And finally, there may be a central site or a few that want some data and metrics from all of the aggregation edge layers under its control, or pushing deployment configuration down hill through all of the layers. Reality check. That said, the given facts 1-3 contradict to strongly consistent data backends supported in today OpenStack (oslo.db), or Kubernetes as well. That means that neither of two IaaS/PaaS solutions is ready for future post-MVP phases of Edge as of yet. That also means that both will need a new, weaker consistent, data backend to pass the future reality check. If you're interested in formal proves of that claim, please see for sources [4][5][6][7][8]. A [tl;dr] of those: a) It is known that causal consistency is the best suitable for high-latency, high-scale and highly dynamic nature of membership in clusters b) "it it is significantly harder to implement causal consistency than eventual consistency. This explains the fact why there is not even a single commercial database system that uses causal consistency" [6] Challenge accepted! What can we as OpenStack community, joined the Kubernetes/OSF/CNCF communities perhaps, for the bright Edge future can do to make things passing that reality check? It's time to start thinking off it early, before we are to face the post-MVP phases for Edge, IMO. That is also something being discussed in the neighbour topic [9] and that I'm also trying to position as a challenge in that very high-level draft paper [10]. As of potential steps on the way of implementing/adopting such a causal data backend in OpenStack at least, we should start looking into the papers, like [4][5][6][7][8] (or even [11], why not having a FS for that?), and probably more of it as a "theoretical background". [0] https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#Features_2 [1] https://github.com/State-of-the-Edge/glossary/blob/master/edge-glossary.md#cloudlet [2] https://en.wikipedia.org/wiki/Cloudlet [3] https://github.com/State-of-the-Edge/glossary/blob/master/edge-glossary.md#aggregation-edge-layer [4] http://www.bailis.org/papers/bolton-sigmod2013.pdf [5] http://www.cs.princeton.edu/~wlloyd/papers/eiger-nsdi13.pdf [6] https://www.ronpub.com/OJDB_2015v2i1n02_Elbushra.pdf [7] http://www.cs.cornell.edu/lorenzo/papers/cac-tr.pdf [8] https://www.cs.cmu.edu/~dga/papers/cops-sosp2011.pdf [9] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000492.html [10] https://github.com/bogdando/papers-ieee/blob/master/ICFC-2019/LaTeX/position_paper_1570506394.pdf [11] http://rainbowfs.lip6.fr/data/RainbowFS-2016-04-12.pdf -- Best regards, Bogdan Dobrelya, Irc #bogdando From gmann at ghanshyammann.com Wed Dec 5 11:39:57 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 05 Dec 2018 20:39:57 +0900 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> Message-ID: <1677e2adcd5.b59b7cfb103641.8644361703617614132@ghanshyammann.com> ---- On Wed, 05 Dec 2018 00:45:20 +0900 Thierry Carrez wrote ---- > Hi, > > A while ago, the Technical Committee designated specific hours in the > week where members would make extra effort to be around on #openstack-tc > on IRC, so that community members looking for answers to their questions > or wanting to engage can find a time convenient for them and a critical > mass of TC members around. We currently have 3 weekly spots: > > - 09:00 UTC on Tuesdays > - 01:00 UTC on Wednesdays > - 15:00 UTC on Thursdays > > But after a few months it appears that: > > 1/ nobody really comes on channel at office hour time to ask questions. > We had a questions on the #openstack-tc IRC channel, but I wouldn't say > people take benefit of the synced time > > 2/ some office hours (most notably the 01:00 UTC on Wednesdays, but also > to a lesser extent the 09:00 UTC on Tuesdays) end up just being a couple > of TC members present > > So the schedule is definitely not reaching its objectives, and as such > may be a bit overkill. I was also wondering if this is not a case where > the offer is hurting the demand -- by having so many office hour spots > around, nobody considers them special. > > Should we: > > - Reduce office hours to one or two per week, possibly rotating times > > - Dump the whole idea and just encourage people to ask questions at any > time on #openstack-tc, and get asynchronous answers > > - Keep it as-is, it still has the side benefit of triggering spikes of > TC member activity I vote for keeping it to two in a week which can cover both Asia and USA/EU TZ which mean either dropping either Tuesday or Wednesday. If traffic is same in office hours then also it is ok as it does not take any extra effort from us. we keep doing our day activity and keep eyes on channel during that time. Obviously it does not mean we will not active in other time but it is good to save a particular slot where people can find more than one TC. -gmann > > Thoughts ? > > -- > Thierry Carrez (ttx) > > From zhaolihuisky at aliyun.com Wed Dec 5 05:50:26 2018 From: zhaolihuisky at aliyun.com (zhaolihuisky) Date: Wed, 05 Dec 2018 13:50:26 +0800 Subject: =?UTF-8?B?W29wZW5zdGFja11bZGlza2ltYWdlLWJ1aWxkZXJdIEhvdyB0byBpbnN0YWxsIHNvZnR3YXJl?= =?UTF-8?B?IHBhY2thZ2VzIGF0IGJ1aWxkaW5nIG11cmFuby1hZ2VudCBpbWFnZQ==?= Message-ID: hi, guys How to install software packages at building murano-agent image. I have download telegraf-x.x.x-x86_64.rpm file and how to install this package into murano-agent image. Is there any suggestion? Best Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From liliueecg at gmail.com Wed Dec 5 05:55:06 2018 From: liliueecg at gmail.com (Li Liu) Date: Wed, 5 Dec 2018 00:55:06 -0500 Subject: [cyborg] IRC meeting for Dec 5th Message-ID: Hi team, The IRC meeting will be held at the normal time again this week. *Starting next week*, we will move it to 0300 UTC, which 10:00 pm est(Tuesday) / 7:00 pm pst(Tuesday) / 11am beijing time (Wednesday) For this week's meeting, we will try to 1. finalize the new DB scheme design 2. finalize the question from Xinran's email on whether we should use conductor or agent to do the diff/update in DB 3. Track status on miscs -- Thank you Regards Li -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Wed Dec 5 12:02:08 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 05 Dec 2018 21:02:08 +0900 Subject: [openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04) In-Reply-To: <1673a198ed5.ffd33ea931022.2184156112862411416@ghanshyammann.com> References: <20181106210549.4nv6co64qbqk5l7f@skaplons-mac> <20181106212533.v6eapwxd2ksggrlo@yuggoth.org> <4C6DAE05-6FFB-4671-89DA-5EB07229DB26@redhat.com> <166eb10f8fb.117c25ba675341.116732651371514382@ghanshyammann.com> <1673a198ed5.ffd33ea931022.2184156112862411416@ghanshyammann.com> Message-ID: <1677e3f2b18.e6941ff4108960.3659294646236910868@ghanshyammann.com> Reminder to test your project specific jobs if those are dependent on Devstack or Tempest base jobs and keep adding the results on etherpad- https://etherpad.openstack.org/p/devstack-bionic We will merge the Devstack and Tempest base job on Bionic on 10th Dec 2018. -gmann ---- On Thu, 22 Nov 2018 15:26:52 +0900 Ghanshyam Mann wrote ---- > 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 dprince at redhat.com Wed Dec 5 12:31:40 2018 From: dprince at redhat.com (Dan Prince) Date: Wed, 05 Dec 2018 07:31:40 -0500 Subject: [tripleo] [validations] Replacement of undercloud_conf module In-Reply-To: References: Message-ID: <006550d1fdab4a4c6ab94c72c791687cd4e654fb.camel@redhat.com> On Tue, 2018-12-04 at 19:37 -0500, Emilien Macchi wrote: > On Tue, Dec 4, 2018 at 4:18 PM Dan Prince wrote: > > Why is this not safe? > > > > > > > > I commented on the LP you linked but it seems to me that a simple > > fix > > > > would be to set the same hiera setting we used before so that the > > > > location of the undercloud.conf is known. We still use and support > > > > hiera for the Undercloud. It would be a simple matter to set this > > in an > > > > undercloud service via t-h-t. If you wanted to you could even cache > > a > > > > copy of the used version somewhere and then consume it that way > > right? > > I guess I wanted to use proper Ansible variables instead of Hiera, > since we are moving toward more Ansible. That's all. > I found it cleaner and simpler than relying on undercloud.conf file. Agreed. After reviewing your patches it all looked fine. Dan > -- > Emilien Macchi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at jimrollenhagen.com Wed Dec 5 12:59:44 2018 From: jim at jimrollenhagen.com (Jim Rollenhagen) Date: Wed, 5 Dec 2018 07:59:44 -0500 Subject: [ironic] Time to discuss clean/deploy steps In-Reply-To: References: Message-ID: On Tue, Dec 4, 2018 at 4:39 PM Julia Kreger wrote: > All, > > I've looked at the doodle poll results and it looks like the best > available time is 3:00 PM UTC on Friday December 7th. > Turns out I won't be able to make that after all. :( Will drop my thoughts in the spec. > > I suggest we use bluejeans[2] as that has worked fairly well for us thus > far. The specification documented related to the discussion can be found in > review[3]. > > Thanks, > > -Julia > > [1] https://doodle.com/poll/yan4wyvztf7mpq46 > [2] https://bluejeans.com/u/jkreger/ > [3] https://review.openstack.org/#/c/606199/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jistr at redhat.com Wed Dec 5 12:06:34 2018 From: jistr at redhat.com (=?UTF-8?B?SmnFmcOtIFN0csOhbnNrw70=?=) Date: Wed, 5 Dec 2018 13:06:34 +0100 Subject: [tripleo] Spec for upgrades including operating system upgrade Message-ID: Hi folks, there's work ongoing to figure out how we can include operating system upgrade into the TripleO upgrade procedure. As we explore the options, it becomes apparent that we need to change the operator workflow, and the OpenStack upgrade including an operating system upgrade will likely end up being our most daring, complex, risky upgrade procedure yet. There's a spec [1] which outlines the expected operator workflow and its implementation, alternatives, current gaps, risks etc. If you maintain any of our composable services, please take some time to review the spec, consider if the upgrade of the service fits the proposed upgrade workflow, and provide feedback or suggestions. The spec is fairly long (the topic is complex), but it's been structured to make the read as comfortable as possible. Thank you, Jirka [1] patch: https://review.openstack.org/#/c/622324 rendered: http://logs.openstack.org/24/622324/1/check/openstack-tox-docs/b047271/html/specs/stein/upgrades-with-operating-system.html From ltoscano at redhat.com Wed Dec 5 13:19:52 2018 From: ltoscano at redhat.com (Luigi Toscano) Date: Wed, 05 Dec 2018 14:19:52 +0100 Subject: [openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04) In-Reply-To: <1677e3f2b18.e6941ff4108960.3659294646236910868@ghanshyammann.com> References: <1673a198ed5.ffd33ea931022.2184156112862411416@ghanshyammann.com> <1677e3f2b18.e6941ff4108960.3659294646236910868@ghanshyammann.com> Message-ID: <4795573.S6joe1DXvj@whitebase.usersys.redhat.com> On Wednesday, 5 December 2018 13:02:08 CET Ghanshyam Mann wrote: > Reminder to test your project specific jobs if those are dependent on > Devstack or Tempest base jobs and keep adding the results on etherpad- > https://etherpad.openstack.org/p/devstack-bionic > > We will merge the Devstack and Tempest base job on Bionic on 10th Dec 2018. > I can't test it right now using the gates (so I can't really report this on the etherpad), but a quick local test shows that devstack-plugin-ceph shows does not seem to support bionic. I may try to prepare a test job later if no one beats me at it. Ciao -- Luigi From ltoscano at redhat.com Wed Dec 5 13:29:10 2018 From: ltoscano at redhat.com (Luigi Toscano) Date: Wed, 05 Dec 2018 14:29:10 +0100 Subject: [openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04) In-Reply-To: <4795573.S6joe1DXvj@whitebase.usersys.redhat.com> References: <1677e3f2b18.e6941ff4108960.3659294646236910868@ghanshyammann.com> <4795573.S6joe1DXvj@whitebase.usersys.redhat.com> Message-ID: <4000535.P2t9rJb4HH@whitebase.usersys.redhat.com> On Wednesday, 5 December 2018 14:19:52 CET Luigi Toscano wrote: > On Wednesday, 5 December 2018 13:02:08 CET Ghanshyam Mann wrote: > > Reminder to test your project specific jobs if those are dependent on > > Devstack or Tempest base jobs and keep adding the results on etherpad- > > https://etherpad.openstack.org/p/devstack-bionic > > > > We will merge the Devstack and Tempest base job on Bionic on 10th Dec > > 2018. > > I can't test it right now using the gates (so I can't really report this on > the etherpad), but a quick local test shows that devstack-plugin-ceph shows > does not seem to support bionic. I may try to prepare a test job later if no > one beats me at it. > Erp, sorry, I didn't notice https://review.openstack.org/#/c/611594/ - I confirm that it makes devstack-plugin-ceph compatible with bionic, so please merge it :) Ciao -- Luigi From jimmy at openstack.org Wed Dec 5 14:10:30 2018 From: jimmy at openstack.org (Jimmy McArthur) Date: Wed, 05 Dec 2018 08:10:30 -0600 Subject: [ptl] [openstack-map] New tags for OpenStack Project Map In-Reply-To: References: <5C06C88C.1010303@openstack.org> Message-ID: <5C07DC56.8050000@openstack.org> Apologies for not clarifying. Yes. The video ID is the YoutTubeID. > Lingxian Kong > December 5, 2018 at 2:07 AM > On Wed, Dec 5, 2018 at 7:35 AM Jimmy McArthur > wrote: > > Following up on this thread from ttx [1], we are continuing to > enhance > the content on the OpenStack Project Map [2],[3] through new tags > that > are managed through the openstack-map repo [4]. > > * video (id, title, description) - This controls the Project Update > video you see on the project page. I've just pushed a review > adding all > of the Project Updates for Berlin [5] > > > I'm wondering where does the id come from? Youtube URL suffix? > Cheers, > Lingxian Kong > Jimmy McArthur > December 4, 2018 at 12:33 PM > Following up on this thread from ttx [1], we are continuing to enhance > the content on the OpenStack Project Map [2],[3] through new tags that > are managed through the openstack-map repo [4]. > > * video (id, title, description) - This controls the Project Update > video you see on the project page. I've just pushed a review adding > all of the Project Updates for Berlin [5] > > * depends-on - Things that are a strong dependency. This should be > used ONLY if your component requires another one to work (e.g. nova -> > glance) > > * see-also - Should list things that are a week dependency or an > adjacent relevant thing > > * support-teams (name: link) - This is meant to give credit to > adjacent projects that aren't necessary to run the software (e.g. > Oslo, i18n, Docs). We are still determining how best to implement > this tag, but we feel it's important to give some credit to these > other teams that are so critical in helping to maintain, support, and > build OpenStack > > If you have some time, please go to the git repo [4] and review your > project and help flesh out these new tags (or update old ones) so we > can display them in the Project Map [2]. > > Cheers, > Jimmy > > [1] > http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000178.html > > [2] > https://www.openstack.org/software/project-navigator/openstack-components > [3] > https://www.openstack.org/assets/software/projectmap/openstack-map.pdf > [4] https://git.openstack.org/cgit/openstack/openstack-map/ > [5] https://review.openstack.org/622485 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luka.peschke at objectif-libre.com Wed Dec 5 14:16:01 2018 From: luka.peschke at objectif-libre.com (Luka Peschke) Date: Wed, 05 Dec 2018 15:16:01 +0100 Subject: [cloudkitty] IRC Meeting of the 7/12 will exceptionally happen at 9h AM UTC Message-ID: Hello, After discussion on IRC, it has been decided that the next CloudKitty IRC meeting (which was supposed to happen at 15h UTC on the 7/12) will exceptionally be held at 9h UTC (10h CET) on the same day. The schedule for other meetings remains unchanged (First friday of each month at 15h UTC). Cheers, -- Luka Peschke Développeur +33 (0) 5 82 95 65 36 5 rue du Moulin Bayard - 31000 Toulouse www.objectif-libre.com From doug at doughellmann.com Wed Dec 5 14:18:49 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 05 Dec 2018 09:18:49 -0500 Subject: [all] Etcd as DLM In-Reply-To: References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> <1A3C52DFCD06494D8528644858247BF01C24C6BD@EX10MBOX03.pnnl.gov> <20181204100812.og33xegl2fxmoo6g@localhost> Message-ID: Mike Bayer writes: > On Tue, Dec 4, 2018 at 11:42 AM Ben Nemec wrote: >> >> Copying Mike Bayer since he's our resident DB expert. One more comment >> inline. > > so the level of abstraction oslo.db itself provides is fairly light - > it steps in for the initial configuration of the database engine, for > the job of reworking exceptions into something more locallized, and > then for supplying a basic transactional begin/commit pattern that > includes concepts that openstack uses a lot. it also has some > helpers for things like special datatypes, test frameworks, and stuff > like that. > > That is, oslo.db is not a full blown "abstraction" layer, it exposes > the SQLAlchemy API which is then where you have the major level of > abstraction. > > Given that, making oslo.db do for etcd3 what it does for SQLAlchemy > would be an appropriate place for such a thing. It would be all new > code and not really have much overlap with anything that's there right > now, but still would be feasible at least at the level of, "get a > handle to etcd3, here's the basic persistence / query pattern we use > with it, here's a test framework that will allow test suites to use > it". If there's no real overlap, it sounds like maybe a new (or at least different, see below) library would be more appropriate. That would let the authors/reviewers focus on whatever configuration abstraction we need for etcd3, and not worry about the relational database stuff in oslo.db now. > At the level of actually reading and writing data to etcd3 as well as > querying, that's a bigger task, and certainly that is not a SQLAlchemy > thing either. If etcd3's interface is a simple enough "get" / "put" > / "query" and then some occasional special operations, those kinds of > abstraction APIs are often not too terrible to write. There are a zillion client libraries for etcd already. Let's see which one has the most momentum, and use that. > Also note that we have a key/value database interface right now in > oslo.cache which uses dogpile.cache against both memcached and redis > right now. If you really only needed put/get with etcd3, it could > do that also, but I would assume we have the need for more of a fine > grained interface than that. Haven't studied etcd3 as of yet. But > I'd be interested in supporting it in oslo somewhere. Using oslo.cache might make sense, too. Doug From doug at doughellmann.com Wed Dec 5 14:40:30 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 05 Dec 2018 09:40:30 -0500 Subject: [TC] Forum TC Vision Retrospective summary In-Reply-To: References: Message-ID: Julia Kreger writes: > During the Forum in Berlin, the Technical Committee along with interested > community members took some time to look back at the vision that written in > early 2017. > > We had three simple questions: > * What went well? > * What needs improvement? > * What should the next steps be? > > To summarize, the group thought the vision helped guide some thoughts and > decisions. Helped provide validation on what was thought to be important. > We have seen adjacent communities fostered. We didn't solely focus on the > vision which was viewed as a positive as things do change over time. It > helped us contrast, and in the process of writing the vision we reached the > use of the same words. > > Most importantly, we learned that we took on too much work. > > As with most retrospectives, the list of things that needed improvement was > a bit longer. There was some perception that it fell off the map, and that > not every item received work. Possibly that we even took the vision too > literally and too detailed as opposed to use it as more a guiding document > to help us evolve as time goes on. There was consensus that there was still > room to improve and that we could have done a better at conveying context > to express how, what, and why. > > For next steps, we feel that it is time to revise the vision, albeit in a > shorter form. We also felt that there could be a vision for the TC itself, > which led to the discussion of providing clarity to the role of the > Technical Committee. > > As for action items and next steps that we reached consensus on: > > * To refine the technical vision document. > * That it was time to compose a new vision for the community. > * Consensus was reached that there should be a vision of the TC itself, and > as part of this have a living document that describes the "Role of the TC". > ** ttx, cdent, and TheJulia have volunteered to continue those discussions. > ** mnaser would start a discussion with the community as to what the TC > should and shouldn't do. For those reading this, please remember that the > TC's role is defined in the foundation bylaws, so this would be more of a > collection of perceptions. > * TheJulia to propose a governance update to suggest that people proposing > TC candidacy go ahead and preemptively seek to answer the question of what > the candidate perceives as the role of the TC. Do we need a resolution for this? Or just for someone to remember to ask the question when the time comes? > > The etherpad that followed the discussion can be found at: > https://etherpad.openstack.org/p/BER-tc-vision-retrospective > > -Julia -- Doug From opensrloo at gmail.com Wed Dec 5 14:57:05 2018 From: opensrloo at gmail.com (Ruby Loo) Date: Wed, 5 Dec 2018 09:57:05 -0500 Subject: Proposing KaiFeng Wang for ironic-core In-Reply-To: References: Message-ID: On Sun, Dec 2, 2018 at 9:45 AM Julia Kreger wrote: > I'd like to propose adding KaiFeng to the ironic-core reviewer group. > Previously, we had granted KaiFeng rights on ironic-inspector-core and I > personally think they have done a great job there. > > Kaifeng has also been reviewing other repositories in ironic's scope[1]. > Their reviews and feedback have been insightful and meaningful. They have > also been very active[2] at reviewing which is an asset for any project. > > I believe they will be an awesome addition to the team. > > -Julia > > [1]: http://stackalytics.com/?module=ironic-group&user_id=kaifeng > [2]: http://stackalytics.com/report/contribution/ironic-group/90 > Totally agree ++, thanks for proposing Kaifeng and thank you Kaifeng for all the great work so far! --ruby -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike_mp at zzzcomputing.com Wed Dec 5 14:58:33 2018 From: mike_mp at zzzcomputing.com (Mike Bayer) Date: Wed, 5 Dec 2018 09:58:33 -0500 Subject: [all] Etcd as DLM In-Reply-To: References: <3147d433-13b4-3582-c831-25c29a5799ca@nemebean.com> <1A3C52DFCD06494D8528644858247BF01C24C6BD@EX10MBOX03.pnnl.gov> <20181204100812.og33xegl2fxmoo6g@localhost> Message-ID: On Wed, Dec 5, 2018 at 9:18 AM Doug Hellmann wrote: > > Mike Bayer writes: > > > On Tue, Dec 4, 2018 at 11:42 AM Ben Nemec wrote: > >> > >> Copying Mike Bayer since he's our resident DB expert. One more comment > >> inline. > > > > so the level of abstraction oslo.db itself provides is fairly light - > > it steps in for the initial configuration of the database engine, for > > the job of reworking exceptions into something more locallized, and > > then for supplying a basic transactional begin/commit pattern that > > includes concepts that openstack uses a lot. it also has some > > helpers for things like special datatypes, test frameworks, and stuff > > like that. > > > > That is, oslo.db is not a full blown "abstraction" layer, it exposes > > the SQLAlchemy API which is then where you have the major level of > > abstraction. > > > > Given that, making oslo.db do for etcd3 what it does for SQLAlchemy > > would be an appropriate place for such a thing. It would be all new > > code and not really have much overlap with anything that's there right > > now, but still would be feasible at least at the level of, "get a > > handle to etcd3, here's the basic persistence / query pattern we use > > with it, here's a test framework that will allow test suites to use > > it". > > If there's no real overlap, it sounds like maybe a new (or at least > different, see below) library would be more appropriate. That would let > the authors/reviewers focus on whatever configuration abstraction we > need for etcd3, and not worry about the relational database stuff in > oslo.db now. OK, my opinion on that is informed by how oslo.db is organized; in that it has no relational database concepts in the base, which are instead local to oslo_db.sqlalchemy. It originally intended to be abstraction for "databases" in general. There may be some value sharing some concepts across relational and key/value databases, to the extent they are used as the primary data storage service for an application and not just a cache, although this may not be practical right now and we might consider oslo_db to just be slightly mis-named. > > > At the level of actually reading and writing data to etcd3 as well as > > querying, that's a bigger task, and certainly that is not a SQLAlchemy > > thing either. If etcd3's interface is a simple enough "get" / "put" > > / "query" and then some occasional special operations, those kinds of > > abstraction APIs are often not too terrible to write. > > There are a zillion client libraries for etcd already. Let's see which > one has the most momentum, and use that. Right, but I'm not talking about client libraries I'm talking about an abstraction layer. So that the openstack app that talks to etcd3 and tomorrow might want to talk to FoundationDB wouldn't have to rip all the code out entirely. or more immediately, when the library that has the "most momentum" no longer does, and we need to switch. Openstack's switch from MySQL-python to pymysql is a great example of this, as well as the switch of memcached drivers from python-memcached to pymemcached. consumers of oslo libraries should only have to change a configuration string for changes like this, not any imports or calling conventions. Googling around I'm not seeing much that does this other than dogpile.cache and a few small projects that don't look very polished. This is probably because it's sort of trivial to make a basic one and then sort of hard to expose vendor-specific features once you've done so. but still IMO worthwhile. > > > Also note that we have a key/value database interface right now in > > oslo.cache which uses dogpile.cache against both memcached and redis > > right now. If you really only needed put/get with etcd3, it could > > do that also, but I would assume we have the need for more of a fine > > grained interface than that. Haven't studied etcd3 as of yet. But > > I'd be interested in supporting it in oslo somewhere. > > Using oslo.cache might make sense, too. I think the problems of caching are different than those of primary data store. Caching assumes data is impermanent, that it expires with a given length of time, and that the thing being stored is opaque and can't be queried directly or in the aggregate at least as far as the caching API is concerned (e.g. no "fetch by 'field'", for starters). Whereas a database abstraction API would include support for querying, as well as that it would treat the data as permanent and critical rather than a transitory, stale copy of something. so while I'm 0 on not using oslo.db I'm -1 on using oslo.cache. > > Doug From sjamgade at suse.com Wed Dec 5 15:30:06 2018 From: sjamgade at suse.com (Sumit Jamgade) Date: Wed, 5 Dec 2018 16:30:06 +0100 Subject: [glance] is glance-cache deprecated Message-ID: Hello, $subject or are there any plans to migrate it to v2 ? I see Ia086230cc8c92f7b7dfd5b001923110d5bc55d4d removed the underlying entrypoint for glanace-cache-manage entrypoint -- thanks Sumit From doug at doughellmann.com Wed Dec 5 15:41:01 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 05 Dec 2018 10:41:01 -0500 Subject: [tc][all] Train Community Goals In-Reply-To: References: Message-ID: Julia Kreger writes: > Off-hand, I think there needs to be a few more words agreed upon for each > in terms of what each item practically means. > > In other words, does #1 mean each python-clientlibrary's OSC plugin is > ready to rock and roll, or we talking about everyone rewriting all client > interactions in to openstacksdk, and porting existing OSC plugins use that > different python sdk. We talked about those things as separate phases. IIRC, the first phase was to include ensuring that python-openstackclient has full feature coverage for non-admin operations for all microversions, using the existing python-${service}client library or SDK as is appropriate. The next phase was to ensure that the SDK has full feature coverage for all microversions. After that point we could update OSC to use the SDK and start deprecating the service-specific client libraries. > In other words, some projects could find it very easy or that they are > already done, where as others could find themselves with a huge lift that > is also dependent upon review bandwidth that is outside of their control or > influence which puts such a goal at risk if we try and push too hard. > > -Julia > > > On Tue, Dec 4, 2018 at 9:43 AM Lance Bragstad wrote: > >> Hi all, >> >> The purpose of this thread is to have a more focused discussion about what >> we'd like to target for Train community goals, bootstrapped with the >> outcomes from the session in Berlin [0]. >> >> During the session, we went through each item as a group and let the >> person who added it share why they thought it would be a good community >> goal candidate for the next release. Most goals have feedback captured in >> etherpad describing next steps, but the following stuck out as top >> contenders from the session (rated by upvotes): >> >> 1. Moving legacy clients to python-openstackclient >> 2. Cleaning up resources when deleting a project >> 3. Service-side health checks >> >> I don't think I missed any goals from the session, but if I did, please >> let me know and I'll add it to the list so that we can discuss it here. >> >> Does anyone have strong opinions either way about the goals listed above? >> >> [0] https://etherpad.openstack.org/p/BER-t-series-goals >> -- Doug From rosmaita.fossdev at gmail.com Wed Dec 5 16:36:49 2018 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Wed, 5 Dec 2018 11:36:49 -0500 Subject: [glance] is glance-cache deprecated In-Reply-To: References: Message-ID: <56432dc9-d61a-f1e0-16bd-a51bf29b2fb6@gmail.com> On 12/5/18 10:30 AM, Sumit Jamgade wrote: > Hello, > > $subject No. It's just not easily manageable ATM. > or are there any plans to migrate it to v2 ? Yes, see this spec for Stein: https://git.openstack.org/cgit/openstack/glance-specs/commit/?id=862f2212c7a382a832456829be8bd6f2f9ee2561 > > I see Ia086230cc8c92f7b7dfd5b001923110d5bc55d4d removed the underlying > entrypoint > for glanace-cache-manage entrypoint > > -- > thanks > Sumit > From dangtrinhnt at gmail.com Wed Dec 5 16:50:14 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Thu, 6 Dec 2018 01:50:14 +0900 Subject: [Searchlight][infra] tox failed tests at zuul check only In-Reply-To: References: <20181203170339.psadnws63wfywtrs@yuggoth.org> Message-ID: Hi all, I just wonder why the CI uses "searchlight==6.0.0.0b2.dev11" [1] when the latest release I made is "6.0.0.0b1"? [1] http://logs.openstack.org/71/622871/1/check/openstack-tox-py27/aca5881/job-output.txt.gz On Tue, Dec 4, 2018 at 9:09 AM Trinh Nguyen wrote: > Thank Jeremy for the clear instructions. > > On Tue, Dec 4, 2018 at 2:05 AM Jeremy Stanley wrote: > >> On 2018-12-04 00:28:30 +0900 (+0900), Trinh Nguyen wrote: >> > Currently, [1] fails tox py27 tests on Zuul check for just updating the >> log >> > text. The tests are successful at local dev env. Just wondering there is >> > any new change at Zuul CI? >> > >> > [1] https://review.openstack.org/#/c/619162/ >> >> I don't know of any recent changes which would result in the >> indicated test failures. According to the log it looks like it's a >> functional testsuite and the tests are failing to connect to the >> search API. I don't see your job collecting any service logs >> however, so it's unclear whether the API service is failing to >> start, or spontaneously crashes, or something else is going on. My >> first guess would be that one of your dependencies has released and >> brought some sort of regression. >> >> According to >> >> http://zuul.openstack.org/builds?job_name=openstack-tox-py27&project=openstack%2Fsearchlight&branch=master >> the last time that job passed for your repo was 2018-11-07 with the >> installed package versions listed in the >> >> http://logs.openstack.org/56/616056/1/gate/openstack-tox-py27/e413441/tox/py27-5.log >> file, and the first failure I see matching the errors in yours ran >> with the versions in >> >> http://logs.openstack.org/62/619162/1/check/openstack-tox-py27/809a281/tox/py27-5.log >> on 2018-11-21 (it wasn't run for the intervening 2 weeks so we have >> a fairly large window of potential external breakage there). A diff >> of those suggests the following dependencies updated between them: >> >> coverage: 4.5.1 -> 4.5.2 >> cryptography: 2.3.1 -> 2.4.1 >> httplib2: 0.11.3 -> 0.12.0 >> oslo.cache: 1.31.1 -> 1.31.0 (downgraded) >> oslo.service: 1.32.0 -> 1.33.0 >> python-neutronclient: 6.10.0 -> 6.11.0 >> requests: 2.20.0 -> 2.20.1 >> WebOb: 1.8.3 -> 1.8.4 >> >> Make sure with your local attempts at reproduction you're running >> with these newer versions of dependencies, for example by clearing >> any existing tox envs with the -r flag or `git clean -dfx` so that >> stale versions aren't used instead. >> -- >> Jeremy Stanley >> > > > -- > *Trinh Nguyen* > *www.edlab.xyz * > > -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Wed Dec 5 17:10:23 2018 From: cboylan at sapwetik.org (Clark Boylan) Date: Wed, 05 Dec 2018 09:10:23 -0800 Subject: [Searchlight][infra] tox failed tests at zuul check only In-Reply-To: References: <20181203170339.psadnws63wfywtrs@yuggoth.org> Message-ID: <1544029823.1906308.1599921208.06E91026@webmail.messagingengine.com> On Wed, Dec 5, 2018, at 8:50 AM, Trinh Nguyen wrote: > Hi all, > > I just wonder why the CI uses "searchlight==6.0.0.0b2.dev11" [1] when the > latest release I made is "6.0.0.0b1"? > > [1] > http://logs.openstack.org/71/622871/1/check/openstack-tox-py27/aca5881/job-output.txt.gz > It is testing the change you pushed which is 11 commits ahead of 6.0.0.0b1. PBR knows that if the most recent release was 6.0.0.0b1 then the next possible release must be at least 6.0.0.0b2. The 11 comments since 6.0.0.0b1 form the .dev11 suffix. Basically this is PBR being smart to attempt to give you monotonically increasing version numbers that are also valid should you tag a release. More details at https://docs.openstack.org/pbr/latest/user/features.html#version. Clark From fungi at yuggoth.org Wed Dec 5 17:10:53 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 5 Dec 2018 17:10:53 +0000 Subject: [Searchlight][infra] tox failed tests at zuul check only In-Reply-To: References: <20181203170339.psadnws63wfywtrs@yuggoth.org> Message-ID: <20181205171053.lnifnu5pqxthz3eh@yuggoth.org> On 2018-12-06 01:50:14 +0900 (+0900), Trinh Nguyen wrote: > I just wonder why the CI uses "searchlight==6.0.0.0b2.dev11" [1] when the > latest release I made is "6.0.0.0b1"? > > [1] http://logs.openstack.org/71/622871/1/check/openstack-tox-py27/aca5881/job-output.txt.gz [...] Python PEP 440 sorts .dev versions earlier than the equivalent string prior to the .dev portion, so PBR is generating a version for you which sorts after 6.0.0.0b1 (the most recent tag on that branch) but before 6.0.0.0b2 (the next possible beta tag you might use in the future). The "11" there indicates it sees you have 11 additional commits on that branch since the 6.0.0.0b1 tag was applied. -- 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 dangtrinhnt at gmail.com Wed Dec 5 17:17:32 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Thu, 6 Dec 2018 02:17:32 +0900 Subject: [Searchlight][infra] tox failed tests at zuul check only In-Reply-To: <1544029823.1906308.1599921208.06E91026@webmail.messagingengine.com> References: <20181203170339.psadnws63wfywtrs@yuggoth.org> <1544029823.1906308.1599921208.06E91026@webmail.messagingengine.com> Message-ID: Oh Jeremy, Clark, Thank for the info. Pretty helpful. Bests, On Thu, Dec 6, 2018 at 2:12 AM Clark Boylan wrote: > On Wed, Dec 5, 2018, at 8:50 AM, Trinh Nguyen wrote: > > Hi all, > > > > I just wonder why the CI uses "searchlight==6.0.0.0b2.dev11" [1] when the > > latest release I made is "6.0.0.0b1"? > > > > [1] > > > http://logs.openstack.org/71/622871/1/check/openstack-tox-py27/aca5881/job-output.txt.gz > > > > It is testing the change you pushed which is 11 commits ahead of > 6.0.0.0b1. PBR knows that if the most recent release was 6.0.0.0b1 then the > next possible release must be at least 6.0.0.0b2. The 11 comments since > 6.0.0.0b1 form the .dev11 suffix. > > Basically this is PBR being smart to attempt to give you monotonically > increasing version numbers that are also valid should you tag a release. > More details at > https://docs.openstack.org/pbr/latest/user/features.html#version. > > Clark > > -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From openstack at fried.cc Wed Dec 5 17:18:37 2018 From: openstack at fried.cc (Eric Fried) Date: Wed, 5 Dec 2018 11:18:37 -0600 Subject: [dev] How to develop changes in a series In-Reply-To: <1CC272501B5BC543A05DB90AA509DED527475067@ORSMSX162.amr.corp.intel.com> References: <1CC272501B5BC543A05DB90AA509DED527475067@ORSMSX162.amr.corp.intel.com> Message-ID: This started off as a response to some questions Sundar asked, but I thought it might be interesting/useful for new[er] OpenStack developers at large, so broadcasting. I'm sure there's a document somewhere that covers this, but here's a quick run-down on how to develop multiple changes in a series. (Or at least, how I do it.) Start on a freshly-pull'd master branch: efried at efried-ThinkPad-W520:~/Neo/nova$ git checkout master Switched to branch 'master' Your branch is up-to-date with 'origin/master'. efried at efried-ThinkPad-W520:~/Neo/nova$ git pull --all When you're working on a blueprint, you want to name your local branch after the blueprint. So in this case, bp/nova-cyborg-interaction. efried at efried-ThinkPad-W520:~/Neo/nova$ git checkout -b bp/nova-cyborg-interaction Switched to a new branch 'bp/nova-cyborg-interaction' efried at efried-ThinkPad-W520:~/Neo/nova$ git log --oneline -1 --decorate 5bf6f63 (HEAD, origin/master, origin/HEAD, gerrit/master, master, bp/nova-cyborg-interaction) Merge "Deprecate the nova-xvpvncproxy service" When you `git commit` (without `--amend`), you're creating a new commit on top of whatever commit you started at. If you started with a clean, freshly pull'd master branch, that'll be whatever the most recently merged commit in the master branch was. In this example, that's commit 5bf6f63. So let's say I make an edit for my first patch and commit it: efried at efried-ThinkPad-W520:~/Neo/nova$ echo 'python-cyborgclient>=1.0' >> requirements.txt efried at efried-ThinkPad-W520:~/Neo/nova$ echo 'python-cyborgclient==1.1' >> lower-constraints.txt efried at efried-ThinkPad-W520:~/Neo/nova$ git commit -a -m "Add cyborg client to requirements" [bp/nova-cyborg-interaction 1b2c453] Add cyborg client to requirements  2 files changed, 2 insertions(+) efried at efried-ThinkPad-W520:~/Neo/nova$ git log --oneline -2 --decorate 1b2c453 (HEAD, bp/nova-cyborg-interaction) Add cyborg client to requirements 5bf6f63 (origin/master, origin/HEAD, gerrit/master, master) Merge "Deprecate the nova-xvpvncproxy service" I just made commit 1b2c453 on top of 5bf6f63. You'll notice my branch name (bp/nova-cyborg-interaction) came along with me. Now I'm going to make another change, but just part of it, a work-in-progress commit: efried at efried-ThinkPad-W520:~/Neo/nova$ mkdir nova/pci/cyborg efried at efried-ThinkPad-W520:~/Neo/nova$ touch nova/pci/cyborg/__init__.py efried at efried-ThinkPad-W520:~/Neo/nova$ git add nova/pci/cyborg/__init__.py efried at efried-ThinkPad-W520:~/Neo/nova$ git commit -m "WIP: Cyborg PCI handling" [bp/nova-cyborg-interaction ebb3505] WIP: Cyborg PCI handling  1 file changed, 0 insertions(+), 0 deletions(-)  create mode 100644 nova/pci/cyborg/__init__.py efried at efried-ThinkPad-W520:~/Neo/nova$ git log --oneline -3 --decorate ebb3505 (HEAD, bp/nova-cyborg-interaction) WIP: Cyborg PCI handling 1b2c453 Add cyborg client to requirements 5bf6f63 (origin/master, origin/HEAD, gerrit/master, master) Merge "Deprecate the nova-xvpvncproxy service" Now commit ebb3505 is on top of 1b2c453, which is still on top of 5bf6f63 (the master). Note that my branch name came with me again. At this point, I push my series up to gerrit. Note that it makes me confirm that I really want to push two commits at once. efried at efried-ThinkPad-W520:~/Neo/nova$ git review You are about to submit multiple commits. This is expected if you are submitting a commit that is dependent on one or more in-review commits, or if you are submitting multiple self-contained but dependent changes. Otherwise you should consider squashing your changes into one commit before submitting (for indivisible changes) or submitting from separate branches (for independent changes). The outstanding commits are: ebb3505 (HEAD, bp/nova-cyborg-interaction) WIP: Cyborg PCI handling 1b2c453 Add cyborg client to requirements Do you really want to submit the above commits? Type 'yes' to confirm, other to cancel: yes remote: remote: Processing changes: new: 2, refs: 2 (\)        remote: Processing changes: new: 2, refs: 2 (\)        remote: Processing changes: new: 2, refs: 2 (\)        remote: Processing changes: new: 2, refs: 2, done            remote: remote: New Changes:        remote:   https://review.openstack.org/623026 Add cyborg client to requirements        remote:   https://review.openstack.org/623027 WIP: Cyborg PCI handling        remote: To ssh://efried at review.openstack.org:29418/openstack/nova.git  * [new branch]      HEAD -> refs/publish/master/bp/nova-cyborg-interaction Now if you go to either of those links - e.g. https://review.openstack.org/#/c/623026/ - you'll see that the patches are stacked up in series on the top right. But oops, I made a mistake in my first commit. My lower constraint can't be higher than my minimum in requirements.txt. If I still had my branch locally, I could skip this next step, but as a matter of rigor to avoid some common pratfalls, I will pull the whole series afresh from gerrit by asking git review to grab the *top* change: efried at efried-ThinkPad-W520:~/Neo/nova$ git review -d 623027 Downloading refs/changes/27/623027/1 from gerrit Switched to branch "review/eric_fried/bp/nova-cyborg-interaction" Now I'm sitting on the top change (which you'll notice happens to be exactly the same as before I pushed it - again, meaning I could technically have just worked from where I was, but see above): efried at efried-ThinkPad-W520:~/Neo/nova$ git log --oneline -3 --decorate ebb3505 (HEAD, review/eric_fried/bp/nova-cyborg-interaction, bp/nova-cyborg-interaction) WIP: Cyborg PCI handling 1b2c453 Add cyborg client to requirements 5bf6f63 (origin/master, origin/HEAD, gerrit/master, master) Merge "Deprecate the nova-xvpvncproxy service" But I want to edit 1b2c453, while leaving ebb3505 properly stacked on top of it. Here I use a tool called `git restack` (run `pip install git-restack` to install it). efried at efried-ThinkPad-W520:~/Neo/nova$ git restack This pops me into an editor showing me all the commits between wherever I am and the main branch (now they're in top-first order): pick 1b2c453 Add cyborg client to requirements pick ebb3505 WIP: Cyborg PCI handling I want to fix the first one, so I change to: edit 1b2c453 Add cyborg client to requirements pick ebb3505 WIP: Cyborg PCI handling Save and quit the editor, and I see: Stopped at 1b2c453453242a3fa57f2d4fdc80c837b02b804f... Add cyborg client to requirements You can amend the commit now, with         git commit --amend Once you are satisfied with your changes, run         git rebase --continue I fix lower-constraints: efried at efried-ThinkPad-W520:~/Neo/nova$ sed -i 's/cyborgclient==1.1/cyborgclient==1.0/' lower-constraints.txt ...and *amend* the current commit efried at efried-ThinkPad-W520:~/Neo/nova$ git commit -a --amend --no-edit [detached HEAD 6b3455f] Add cyborg client to requirements  Date: Wed Dec 5 09:43:15 2018 -0600  2 files changed, 2 insertions(+) ...and tell `git restack` to proceed efried at efried-ThinkPad-W520:~/Neo/nova$ git rebase --continue Successfully rebased and updated refs/heads/review/eric_fried/bp/nova-cyborg-interaction. If I had a taller series, and I had changed 'pick' to 'edit' for more than one commit, I would now be sitting on the next one I needed to edit. As it is, that was the only thing I needed to do, so I'm done and sitting on the top of my series again. 124b612 (HEAD, review/eric_fried/bp/nova-cyborg-interaction) WIP: Cyborg PCI handling 6b3455f Add cyborg client to requirements 5bf6f63 (origin/master, origin/HEAD, gerrit/master, master) Merge "Deprecate the nova-xvpvncproxy service" Notice that the commit hashes have changed for *both* commits (but not the master). The top one changed because it got rebased onto the new version of the middle one. Now if I push the series back up to gerrit, I get the same confirmation prompt, and both changes get a new patch set. If you look at the top patch in gerrit, you'll see that PS2 shows up as just a rebase. ==================== That ought to be enough for now. There's a couple of gotchas when restacking and the automatic rebase results in merge conflicts, but we can save that for another time. To answer your specific question: > * If you have a patch sequence A followed by B, where patch B depends on patch A, >   how do you communicate that in the submission? If they're in the same commit series, like the example above, It Just Happens. Zuul and the CIs know to pull the whole series when they run; gerrit won't merge N+1 until N is merged; etc. If they're *not* in the same commit series, or if they're not in the same repository, you can use Depends-On in the commit message, to the same effect.  (But I'm not sure if/how Depends-On works for feature branches.) HTH, efried . From dangtrinhnt at gmail.com Wed Dec 5 17:24:45 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Thu, 6 Dec 2018 02:24:45 +0900 Subject: [Searchlight][infra] tox failed tests at zuul check only In-Reply-To: References: <20181203170339.psadnws63wfywtrs@yuggoth.org> <1544029823.1906308.1599921208.06E91026@webmail.messagingengine.com> Message-ID: I'm not sure if this matters: "failed with error code 1 in /home/zuul/src/ git.openstack.org/openstack/searchlight, falling back to uneditable format, Could not determine repository location of /home/zuul/src/ git.openstack.org/openstack/searchlight...Could not determine repository location,searchlight==6.0.0.0b2.dev11" On Thu, Dec 6, 2018 at 2:17 AM Trinh Nguyen wrote: > Oh Jeremy, Clark, > > Thank for the info. Pretty helpful. > > Bests, > > On Thu, Dec 6, 2018 at 2:12 AM Clark Boylan wrote: > >> On Wed, Dec 5, 2018, at 8:50 AM, Trinh Nguyen wrote: >> > Hi all, >> > >> > I just wonder why the CI uses "searchlight==6.0.0.0b2.dev11" [1] when >> the >> > latest release I made is "6.0.0.0b1"? >> > >> > [1] >> > >> http://logs.openstack.org/71/622871/1/check/openstack-tox-py27/aca5881/job-output.txt.gz >> > >> >> It is testing the change you pushed which is 11 commits ahead of >> 6.0.0.0b1. PBR knows that if the most recent release was 6.0.0.0b1 then the >> next possible release must be at least 6.0.0.0b2. The 11 comments since >> 6.0.0.0b1 form the .dev11 suffix. >> >> Basically this is PBR being smart to attempt to give you monotonically >> increasing version numbers that are also valid should you tag a release. >> More details at >> https://docs.openstack.org/pbr/latest/user/features.html#version. >> >> Clark >> >> > > -- > *Trinh Nguyen* > *www.edlab.xyz * > > -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Wed Dec 5 17:28:22 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 5 Dec 2018 17:28:22 +0000 Subject: [Searchlight][infra] tox failed tests at zuul check only In-Reply-To: References: <20181203170339.psadnws63wfywtrs@yuggoth.org> <1544029823.1906308.1599921208.06E91026@webmail.messagingengine.com> Message-ID: <20181205172821.crmaj3y5lzxcjxof@yuggoth.org> On 2018-12-06 02:24:45 +0900 (+0900), Trinh Nguyen wrote: > I'm not sure if this matters: > > "failed with error code 1 in /home/zuul/src/ > git.openstack.org/openstack/searchlight, falling back to uneditable format, > Could not determine repository location of /home/zuul/src/ > git.openstack.org/openstack/searchlight...Could not determine repository > location,searchlight==6.0.0.0b2.dev11" [...] It's benign. Because Zuul pushes the repository onto the test node, it has no Git remote. Clark has proposed https://github.com/pypa/pip/pull/4760 to substitute a file:// URL. -- 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 cboylan at sapwetik.org Wed Dec 5 17:35:59 2018 From: cboylan at sapwetik.org (Clark Boylan) Date: Wed, 05 Dec 2018 09:35:59 -0800 Subject: [dev] How to develop changes in a series In-Reply-To: References: <1CC272501B5BC543A05DB90AA509DED527475067@ORSMSX162.amr.corp.intel.com> Message-ID: <1544031359.1912751.1599945120.4758C77C@webmail.messagingengine.com> On Wed, Dec 5, 2018, at 9:18 AM, Eric Fried wrote: > This started off as a response to some questions Sundar asked, but I > thought it might be interesting/useful for new[er] OpenStack developers > at large, so broadcasting. Snip. Note the content I've removed was really good and worth a read if you work with stacks of commits and Gerrit. > > * If you have a patch sequence A followed by B, where patch B depends > on patch A, > >   how do you communicate that in the submission? > > If they're in the same commit series, like the example above, It Just > Happens. Zuul and the CIs know to pull the whole series when they run; > gerrit won't merge N+1 until N is merged; etc. > > If they're *not* in the same commit series, or if they're not in the > same repository, you can use Depends-On in the commit message, to the > same effect.  (But I'm not sure if/how Depends-On works for feature > branches.) This does work with feature branches as long as the assumption that a feature branch is roughly equivalent to master holds (typically this is the case as new features go into master). On the Zuul side of things Zuul ensures that every branch for each project under test (as specified by depends on and required-projects in the job config) is up to date. This includes applying any speculative state from gating or dependencies. It is then up to tools like devstack (and in the past devstack-gate) to consume those branches as necessary. For example grenade will start with stable/old and upgrade to stable/new|master. Typically in the case of feature branches the assumption in the tooling is use the feature branch in all the projects and if they don't have that feature branch fall back to master. This is where the feature branch implies something like master assumption comes from. You can always refer back to the logs to see what exactly was installed for each project under test to confirm it was testing what you expected it to. Clark From melwittt at gmail.com Wed Dec 5 17:39:31 2018 From: melwittt at gmail.com (melanie witt) Date: Wed, 5 Dec 2018 09:39:31 -0800 Subject: OpenStack Summit Berlin Videos Now Available In-Reply-To: References: <5C057470.8050405@openstack.org> <636ad729-570e-c673-c33d-9b6a2382ece0@gmail.com> <5C059627.9040304@openstack.org> Message-ID: On Mon, 3 Dec 2018 15:01:58 -0600, Matt Riedemann wrote: > On 12/3/2018 2:46 PM, Jimmy McArthur wrote: >> We're looking at ways to improve both formats in Denver, so I'd say >> stand by.  If there is a presentation that you feel is too difficult to >> follow, we can reach out to those presenters and encourage them again to >> upload their slides. > > Here is a good example of what I'm talking about: > > https://youtu.be/J9K-x0yVZ4U?t=425 > > There is full view of the slides, but my eyes can't read most of that > text. Compare that to YVR: > > https://youtu.be/U5V_2CUj-6A?t=576 > > And it's night and day. Thanks for mentioning this. I've just sent the slides to speakersupport@, so hopefully they'll be linked soon to the session page. General feedback regarding slide upload: last summit, we received an email from speakersupport@ letting us know the self-service slide upload system was ready and we were able to upload slides ourselves through openstack.org. I thought that was a nice system, FWIW. This time, I was expecting a similar message process for uploading slides and didn't realize we could have added slides already by now. Cheers, -melanie From cboylan at sapwetik.org Wed Dec 5 17:43:35 2018 From: cboylan at sapwetik.org (Clark Boylan) Date: Wed, 05 Dec 2018 09:43:35 -0800 Subject: [openstack][diskimage-builder] How to install software packages at building murano-agent image In-Reply-To: References: Message-ID: <1544031815.1914972.1599954544.6EFB578F@webmail.messagingengine.com> On Tue, Dec 4, 2018, at 9:50 PM, zhaolihuisky wrote: > hi, guys > > How to install software packages at building murano-agent image. > > I have download telegraf-x.x.x-x86_64.rpm file and how to install this > package into murano-agent image. > > Is there any suggestion? > > Best Regards. For packages in default distro repos you can pass -p $packagename to disk-image-create to specify packages to install. In this case the software is coming from an rpm you are downloading from outside the package repos so the process is a little more involved. In this case I would create an element with an install.d/89-install-telegraf.sh script. In that script you can download the rpm then install it with rpm -i. Then add the new element to your disk-image-create elements list. Clark From jimmy at openstack.org Wed Dec 5 17:53:26 2018 From: jimmy at openstack.org (Jimmy McArthur) Date: Wed, 05 Dec 2018 11:53:26 -0600 Subject: OpenStack Summit Berlin Videos Now Available In-Reply-To: References: <5C057470.8050405@openstack.org> <636ad729-570e-c673-c33d-9b6a2382ece0@gmail.com> <5C059627.9040304@openstack.org> Message-ID: <5C081096.5080003@openstack.org> Thanks for the feedback, Melanie. We did send that email out this go round, but I think there were two tracks that were excluded that weren't meant to be. We're expanding the functionality so that you can upload from the CFP/Speaker Profile w/o having to be prompted by us, so stand by for more features :) Cheers, Jimmy > melanie witt > December 5, 2018 at 11:39 AM > > > Thanks for mentioning this. I've just sent the slides to > speakersupport@, so hopefully they'll be linked soon to the session page. > > General feedback regarding slide upload: last summit, we received an > email from speakersupport@ letting us know the self-service slide > upload system was ready and we were able to upload slides ourselves > through openstack.org. I thought that was a nice system, FWIW. This > time, I was expecting a similar message process for uploading slides > and didn't realize we could have added slides already by now. > > Cheers, > -melanie > > > > > > > Matt Riedemann > December 3, 2018 at 3:01 PM > > > Here is a good example of what I'm talking about: > > https://youtu.be/J9K-x0yVZ4U?t=425 > > There is full view of the slides, but my eyes can't read most of that > text. Compare that to YVR: > > https://youtu.be/U5V_2CUj-6A?t=576 > > And it's night and day. > > Jimmy McArthur > December 3, 2018 at 2:46 PM > In Berlin, in rooms where we had a full view of the screen, we didn't > do a second screen for slides only. As mentioned, presenters can > upload their slides to help with that. > > For places like the Marketplace demo theater where we had a smaller > screen format, we added the view of both presenter and slide: > https://www.openstack.org/videos/berlin-2018/how-to-avoid-vendor-lock-in-in-a-multi-cloud-world-with-zenko > > We're looking at ways to improve both formats in Denver, so I'd say > stand by. If there is a presentation that you feel is too difficult > to follow, we can reach out to those presenters and encourage them > again to upload their slides. > > > > Matt Riedemann > December 3, 2018 at 2:32 PM > > > So uh, I don't really want to be that guy, but I'm sure others have > noticed the deal with the slides being different in the recordings > from years past, in that you can't view them (hopefully people are > uploading their slides). I'm mostly curious if there was a reason for > that? Budget cuts? Technical issues? > > Jimmy McArthur > December 3, 2018 at 12:22 PM > Thank you again for a wonderful Summit in Berlin. I'm pleased to > announce the Summit Videos are now up on the openstack.org website: > https://www.openstack.org/videos/summits/berlin-2018 If there was a > session you missed, now is your chance to catch up! These videos will > also be available in the Summit App as well as on the web under the > Berlin Summit Schedule > (https://www.openstack.org/summit/berlin-2018/summit-schedule/). > > If you have any questions or concerns about the videos, please write > speakersupport at openstack.org. > > Cheers, > Jimmy > > _______________________________________________ > Staff mailing list > Staff at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/staff -------------- next part -------------- An HTML attachment was scrubbed... URL: From melwittt at gmail.com Wed Dec 5 17:54:36 2018 From: melwittt at gmail.com (melanie witt) Date: Wed, 5 Dec 2018 09:54:36 -0800 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: <05bf0894-033c-c921-feb3-d59280dedecc@gmail.com> On Tue, 27 Nov 2018 08:32:40 -0800, Dan Smith 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. > > 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? No, you didn't miss additional discussion after the session. I realize now from your and Tobias replies that I must have misunderstood the access grant part of the discussion. What I had interpreted when I brought up the idea of a keystone-based access grant was that Adrian thought it could solve their ownership transfer use case (and it's possible I misunderstood his response as well). And I don't recall Tobias saying something in objection to the idea, so I wrongly thought it could work for his use case too. I apologize for my misunderstanding and muddying the waters for everyone on this. Correcting myself: really what is wanted is to literally change project_id and user_id for resources, and that allowing the addition of another owner for a project's resources is not sufficient. Best, -melanie From openstack at nemebean.com Wed Dec 5 17:56:19 2018 From: openstack at nemebean.com (Ben Nemec) Date: Wed, 5 Dec 2018 11:56:19 -0600 Subject: [dev] How to develop changes in a series In-Reply-To: References: <1CC272501B5BC543A05DB90AA509DED527475067@ORSMSX162.amr.corp.intel.com> Message-ID: I will take this opportunity to pimp the video series I did on this exact topic: https://www.youtube.com/watch?v=mHyvP7zp4Ko&list=PLR97FKPZ-mD9XJCfwDE5c-td9lZGIPfS5&index=4 On 12/5/18 11:18 AM, Eric Fried wrote: > This started off as a response to some questions Sundar asked, but I > thought it might be interesting/useful for new[er] OpenStack developers > at large, so broadcasting. > > I'm sure there's a document somewhere that covers this, but here's a > quick run-down on how to develop multiple changes in a series. (Or at > least, how I do it.) > > Start on a freshly-pull'd master branch: > > efried at efried-ThinkPad-W520:~/Neo/nova$ git checkout master > Switched to branch 'master' > Your branch is up-to-date with 'origin/master'. > efried at efried-ThinkPad-W520:~/Neo/nova$ git pull --all > > > When you're working on a blueprint, you want to name your local branch > after the blueprint. So in this case, bp/nova-cyborg-interaction. > > efried at efried-ThinkPad-W520:~/Neo/nova$ git checkout -b > bp/nova-cyborg-interaction > Switched to a new branch 'bp/nova-cyborg-interaction' > efried at efried-ThinkPad-W520:~/Neo/nova$ git log --oneline -1 --decorate > 5bf6f63 (HEAD, origin/master, origin/HEAD, gerrit/master, master, > bp/nova-cyborg-interaction) Merge "Deprecate the nova-xvpvncproxy service" > > When you `git commit` (without `--amend`), you're creating a new commit > on top of whatever commit you started at. If you started with a clean, > freshly pull'd master branch, that'll be whatever the most recently > merged commit in the master branch was. In this example, that's commit > 5bf6f63. > > So let's say I make an edit for my first patch and commit it: > > efried at efried-ThinkPad-W520:~/Neo/nova$ echo 'python-cyborgclient>=1.0' >>> requirements.txt > efried at efried-ThinkPad-W520:~/Neo/nova$ echo 'python-cyborgclient==1.1' >>> lower-constraints.txt > efried at efried-ThinkPad-W520:~/Neo/nova$ git commit -a -m "Add cyborg > client to requirements" > [bp/nova-cyborg-interaction 1b2c453] Add cyborg client to requirements >  2 files changed, 2 insertions(+) > efried at efried-ThinkPad-W520:~/Neo/nova$ git log --oneline -2 --decorate > 1b2c453 (HEAD, bp/nova-cyborg-interaction) Add cyborg client to requirements > 5bf6f63 (origin/master, origin/HEAD, gerrit/master, master) Merge > "Deprecate the nova-xvpvncproxy service" > > I just made commit 1b2c453 on top of 5bf6f63. You'll notice my branch > name (bp/nova-cyborg-interaction) came along with me. > > Now I'm going to make another change, but just part of it, a > work-in-progress commit: > > efried at efried-ThinkPad-W520:~/Neo/nova$ mkdir nova/pci/cyborg > efried at efried-ThinkPad-W520:~/Neo/nova$ touch nova/pci/cyborg/__init__.py > efried at efried-ThinkPad-W520:~/Neo/nova$ git add nova/pci/cyborg/__init__.py > efried at efried-ThinkPad-W520:~/Neo/nova$ git commit -m "WIP: Cyborg PCI > handling" > [bp/nova-cyborg-interaction ebb3505] WIP: Cyborg PCI handling >  1 file changed, 0 insertions(+), 0 deletions(-) >  create mode 100644 nova/pci/cyborg/__init__.py > efried at efried-ThinkPad-W520:~/Neo/nova$ git log --oneline -3 --decorate > ebb3505 (HEAD, bp/nova-cyborg-interaction) WIP: Cyborg PCI handling > 1b2c453 Add cyborg client to requirements > 5bf6f63 (origin/master, origin/HEAD, gerrit/master, master) Merge > "Deprecate the nova-xvpvncproxy service" > > Now commit ebb3505 is on top of 1b2c453, which is still on top of > 5bf6f63 (the master). Note that my branch name came with me again. > > At this point, I push my series up to gerrit. Note that it makes me > confirm that I really want to push two commits at once. > > efried at efried-ThinkPad-W520:~/Neo/nova$ git review > You are about to submit multiple commits. This is expected if you are > submitting a commit that is dependent on one or more in-review > commits, or if you are submitting multiple self-contained but > dependent changes. Otherwise you should consider squashing your > changes into one commit before submitting (for indivisible changes) or > submitting from separate branches (for independent changes). > > The outstanding commits are: > > ebb3505 (HEAD, bp/nova-cyborg-interaction) WIP: Cyborg PCI handling > 1b2c453 Add cyborg client to requirements > > Do you really want to submit the above commits? > Type 'yes' to confirm, other to cancel: yes > remote: > remote: Processing changes: new: 2, refs: 2 (\) > remote: Processing changes: new: 2, refs: 2 (\) > remote: Processing changes: new: 2, refs: 2 (\) > remote: Processing changes: new: 2, refs: 2, done > remote: > remote: New Changes: > remote:   https://review.openstack.org/623026 Add cyborg client to > requirements > remote:   https://review.openstack.org/623027 WIP: Cyborg PCI > handling > remote: > To ssh://efried at review.openstack.org:29418/openstack/nova.git >  * [new branch]      HEAD -> refs/publish/master/bp/nova-cyborg-interaction > > Now if you go to either of those links - e.g. > https://review.openstack.org/#/c/623026/ - you'll see that the patches > are stacked up in series on the top right. > > But oops, I made a mistake in my first commit. My lower constraint can't > be higher than my minimum in requirements.txt. If I still had my branch > locally, I could skip this next step, but as a matter of rigor to avoid > some common pratfalls, I will pull the whole series afresh from gerrit > by asking git review to grab the *top* change: > > efried at efried-ThinkPad-W520:~/Neo/nova$ git review -d 623027 > Downloading refs/changes/27/623027/1 from gerrit > Switched to branch "review/eric_fried/bp/nova-cyborg-interaction" > > Now I'm sitting on the top change (which you'll notice happens to be > exactly the same as before I pushed it - again, meaning I could > technically have just worked from where I was, but see above): > > efried at efried-ThinkPad-W520:~/Neo/nova$ git log --oneline -3 --decorate > ebb3505 (HEAD, review/eric_fried/bp/nova-cyborg-interaction, > bp/nova-cyborg-interaction) WIP: Cyborg PCI handling > 1b2c453 Add cyborg client to requirements > 5bf6f63 (origin/master, origin/HEAD, gerrit/master, master) Merge > "Deprecate the nova-xvpvncproxy service" > > But I want to edit 1b2c453, while leaving ebb3505 properly stacked on > top of it. Here I use a tool called `git restack` (run `pip install > git-restack` to install it). > > efried at efried-ThinkPad-W520:~/Neo/nova$ git restack > > This pops me into an editor showing me all the commits between wherever > I am and the main branch (now they're in top-first order): > > pick 1b2c453 Add cyborg client to requirements > pick ebb3505 WIP: Cyborg PCI handling > > > I want to fix the first one, so I change to: > > edit 1b2c453 Add cyborg client to requirements > pick ebb3505 WIP: Cyborg PCI handling > > > Save and quit the editor, and I see: > > Stopped at 1b2c453453242a3fa57f2d4fdc80c837b02b804f... Add cyborg client > to requirements > You can amend the commit now, with > >         git commit --amend > > Once you are satisfied with your changes, run > >         git rebase --continue > > I fix lower-constraints: > > efried at efried-ThinkPad-W520:~/Neo/nova$ sed -i > 's/cyborgclient==1.1/cyborgclient==1.0/' lower-constraints.txt > > ...and *amend* the current commit > > efried at efried-ThinkPad-W520:~/Neo/nova$ git commit -a --amend --no-edit > [detached HEAD 6b3455f] Add cyborg client to requirements >  Date: Wed Dec 5 09:43:15 2018 -0600 >  2 files changed, 2 insertions(+) > > ...and tell `git restack` to proceed > > efried at efried-ThinkPad-W520:~/Neo/nova$ git rebase --continue > Successfully rebased and updated > refs/heads/review/eric_fried/bp/nova-cyborg-interaction. > > If I had a taller series, and I had changed 'pick' to 'edit' for more > than one commit, I would now be sitting on the next one I needed to > edit. As it is, that was the only thing I needed to do, so I'm done and > sitting on the top of my series again. > > 124b612 (HEAD, review/eric_fried/bp/nova-cyborg-interaction) WIP: Cyborg > PCI handling > 6b3455f Add cyborg client to requirements > 5bf6f63 (origin/master, origin/HEAD, gerrit/master, master) Merge > "Deprecate the nova-xvpvncproxy service" > > Notice that the commit hashes have changed for *both* commits (but not > the master). The top one changed because it got rebased onto the new > version of the middle one. > > Now if I push the series back up to gerrit, I get the same confirmation > prompt, and both changes get a new patch set. If you look at the top > patch in gerrit, you'll see that PS2 shows up as just a rebase. > > > ==================== > > That ought to be enough for now. There's a couple of gotchas when > restacking and the automatic rebase results in merge conflicts, but we > can save that for another time. > > To answer your specific question: > >> * If you have a patch sequence A followed by B, where patch B depends > on patch A, >>   how do you communicate that in the submission? > > If they're in the same commit series, like the example above, It Just > Happens. Zuul and the CIs know to pull the whole series when they run; > gerrit won't merge N+1 until N is merged; etc. > > If they're *not* in the same commit series, or if they're not in the > same repository, you can use Depends-On in the commit message, to the > same effect.  (But I'm not sure if/how Depends-On works for feature > branches.) > > HTH, > efried > . > > From doug at doughellmann.com Wed Dec 5 18:03:04 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 05 Dec 2018 13:03:04 -0500 Subject: [dev] How to develop changes in a series In-Reply-To: References: <1CC272501B5BC543A05DB90AA509DED527475067@ORSMSX162.amr.corp.intel.com> Message-ID: Eric Fried writes: > This started off as a response to some questions Sundar asked, but I > thought it might be interesting/useful for new[er] OpenStack developers > at large, so broadcasting. > > I'm sure there's a document somewhere that covers this, but here's a > quick run-down on how to develop multiple changes in a series. (Or at > least, how I do it.) This information would be a great addition to the contributor's guide at https://docs.openstack.org/contributors/code-and-documentation/index.html (that's the openstack/contributor-guide repo). -- Doug From melwittt at gmail.com Wed Dec 5 18:38:06 2018 From: melwittt at gmail.com (melanie witt) Date: Wed, 5 Dec 2018 10:38:06 -0800 Subject: [dev][nova] time for another spec review day? Message-ID: Hi All, Our spec freeze is milestone 2 January 10 and I was thinking, because of holiday time coming up, it might be a good idea to have another spec review day ahead of the freeze early next year. I was thinking maybe Tuesday next week December 11, to allow the most amount of time before holiday PTO starts. Please let me know what you think. Cheers, -melanie From juliaashleykreger at gmail.com Wed Dec 5 19:16:50 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Wed, 5 Dec 2018 11:16:50 -0800 Subject: [TC] Forum TC Vision Retrospective summary In-Reply-To: References: Message-ID: I wasn't thinking a resolution, more a suggestion in the TC election details, but I've not had a chance to really get to this. We could just try to make a commitment to explicitly asking, but I'm afraid that reminder may get lost in everything else that any given community is already having to context switch between. On Wed, Dec 5, 2018 at 6:40 AM Doug Hellmann wrote: > Julia Kreger writes: > > > During the Forum in Berlin, the Technical Committee along with interested > > community members took some time to look back at the vision that written > in > > early 2017. > > > > We had three simple questions: > > * What went well? > > * What needs improvement? > > * What should the next steps be? > > > > To summarize, the group thought the vision helped guide some thoughts and > > decisions. Helped provide validation on what was thought to be important. > > We have seen adjacent communities fostered. We didn't solely focus on the > > vision which was viewed as a positive as things do change over time. It > > helped us contrast, and in the process of writing the vision we reached > the > > use of the same words. > > > > Most importantly, we learned that we took on too much work. > > > > As with most retrospectives, the list of things that needed improvement > was > > a bit longer. There was some perception that it fell off the map, and > that > > not every item received work. Possibly that we even took the vision too > > literally and too detailed as opposed to use it as more a guiding > document > > to help us evolve as time goes on. There was consensus that there was > still > > room to improve and that we could have done a better at conveying context > > to express how, what, and why. > > > > For next steps, we feel that it is time to revise the vision, albeit in a > > shorter form. We also felt that there could be a vision for the TC > itself, > > which led to the discussion of providing clarity to the role of the > > Technical Committee. > > > > As for action items and next steps that we reached consensus on: > > > > * To refine the technical vision document. > > * That it was time to compose a new vision for the community. > > * Consensus was reached that there should be a vision of the TC itself, > and > > as part of this have a living document that describes the "Role of the > TC". > > ** ttx, cdent, and TheJulia have volunteered to continue those > discussions. > > ** mnaser would start a discussion with the community as to what the TC > > should and shouldn't do. For those reading this, please remember that the > > TC's role is defined in the foundation bylaws, so this would be more of a > > collection of perceptions. > > * TheJulia to propose a governance update to suggest that people > proposing > > TC candidacy go ahead and preemptively seek to answer the question of > what > > the candidate perceives as the role of the TC. > > Do we need a resolution for this? Or just for someone to remember to ask > the question when the time comes? > > > > > The etherpad that followed the discussion can be found at: > > https://etherpad.openstack.org/p/BER-tc-vision-retrospective > > > > -Julia > > -- > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vdrok at mirantis.com Wed Dec 5 19:18:59 2018 From: vdrok at mirantis.com (Vladyslav Drok) Date: Wed, 5 Dec 2018 11:18:59 -0800 Subject: Proposing KaiFeng Wang for ironic-core In-Reply-To: References: Message-ID: +1 -vlad On Wed, Dec 5, 2018 at 6:59 AM Ruby Loo wrote: > > On Sun, Dec 2, 2018 at 9:45 AM Julia Kreger > wrote: > >> I'd like to propose adding KaiFeng to the ironic-core reviewer group. >> Previously, we had granted KaiFeng rights on ironic-inspector-core and I >> personally think they have done a great job there. >> >> Kaifeng has also been reviewing other repositories in ironic's scope[1]. >> Their reviews and feedback have been insightful and meaningful. They have >> also been very active[2] at reviewing which is an asset for any project. >> >> I believe they will be an awesome addition to the team. >> >> -Julia >> >> [1]: http://stackalytics.com/?module=ironic-group&user_id=kaifeng >> [2]: http://stackalytics.com/report/contribution/ironic-group/90 >> > > Totally agree ++, thanks for proposing Kaifeng and thank you Kaifeng for > all the great work so far! > > --ruby > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Wed Dec 5 19:27:08 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 05 Dec 2018 14:27:08 -0500 Subject: [dev][goal][python3][qa][devstack][ptl] changing devstack's python 3 behavior Message-ID: Today devstack requires each project to explicitly indicate that it can be installed under python 3, even when devstack itself is running with python 3 enabled. As part of the python3-first goal, I have proposed a change to devstack to modify that behavior [1]. With the change in place, when devstack runs with python3 enabled all services are installed under python 3, unless explicitly listed as not supporting python 3. If your project has a devstack plugin or runs integration or functional test jobs that use devstack, please test your project with the patch (you can submit a trivial change to your project and use Depends-On to pull in the devstack change). [1] https://review.openstack.org/#/c/622415/ -- Doug From edmondsw at us.ibm.com Wed Dec 5 19:48:37 2018 From: edmondsw at us.ibm.com (William M Edmonds) Date: Wed, 5 Dec 2018 14:48:37 -0500 Subject: [dev] How to develop changes in a series In-Reply-To: References: <1CC272501B5BC543A05DB90AA509DED527475067@ORSMSX162.amr.corp.intel.com> Message-ID: Eric Fried wrote on 12/05/2018 12:18:37 PM: > But I want to edit 1b2c453, while leaving ebb3505 properly stacked on > top of it. Here I use a tool called `git restack` (run `pip install > git-restack` to install it). It's worth noting that you can just use `git rebase` [1], you don't have to use git-restack. This is why later you're using `git rebase --continue`, because git-restack is actually using rebase under the covers. [1] https://stackoverflow.com/questions/1186535/how-to-modify-a-specified-commit -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Wed Dec 5 19:52:28 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 5 Dec 2018 19:52:28 +0000 Subject: [dev] How to develop changes in a series In-Reply-To: References: <1CC272501B5BC543A05DB90AA509DED527475067@ORSMSX162.amr.corp.intel.com> Message-ID: <20181205195227.4j3rkpinlgts3ujv@yuggoth.org> On 2018-12-05 14:48:37 -0500 (-0500), William M Edmonds wrote: > Eric Fried wrote on 12/05/2018 12:18:37 PM: > > > > > But I want to edit 1b2c453, while leaving ebb3505 properly stacked on > > top of it. Here I use a tool called `git restack` (run `pip install > > git-restack` to install it). > > It's worth noting that you can just use `git rebase` [1], you don't have to > use git-restack. This is why later you're using `git rebase --continue`, > because git-restack is actually using rebase under the covers. > > [1] https://stackoverflow.com/questions/1186535/how-to-modify-a-specified-commit You can, however what git-restack does for you is figure out which commit to rebase on top of so that you don't inadvertently rebase your stack of changes onto a newer branch state and then make things harder on reviewers. -- 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 edmondsw at us.ibm.com Wed Dec 5 20:40:25 2018 From: edmondsw at us.ibm.com (William M Edmonds) Date: Wed, 5 Dec 2018 15:40:25 -0500 Subject: [dev] How to develop changes in a series In-Reply-To: <20181205195227.4j3rkpinlgts3ujv@yuggoth.org> References: <1CC272501B5BC543A05DB90AA509DED527475067@ORSMSX162.amr.corp.intel.com> <20181205195227.4j3rkpinlgts3ujv@yuggoth.org> Message-ID: Jeremy Stanley wrote on 12/05/2018 02:52:28 PM: > On 2018-12-05 14:48:37 -0500 (-0500), William M Edmonds wrote: > > Eric Fried wrote on 12/05/2018 12:18:37 PM: > > > > > > > > > But I want to edit 1b2c453, while leaving ebb3505 properly stacked on > > > top of it. Here I use a tool called `git restack` (run `pip install > > > git-restack` to install it). > > > > It's worth noting that you can just use `git rebase` [1], you don't have to > > use git-restack. This is why later you're using `git rebase --continue`, > > because git-restack is actually using rebase under the covers. > > > > [1] https://stackoverflow.com/questions/1186535/how-to-modify-a- > specified-commit > > You can, however what git-restack does for you is figure out which > commit to rebase on top of so that you don't inadvertently rebase > your stack of changes onto a newer branch state and then make things > harder on reviewers. > -- > Jeremy Stanley Ah, that's good to know. Also, found this existing documentation [2] if someone wants to propose an update or link from another location. Note that it doesn't currently mention git-restack, just rebase. [2] https://docs.openstack.org/contributors/code-and-documentation/patch-best-practices.html#how-to-handle-chains -------------- next part -------------- An HTML attachment was scrubbed... URL: From allison at openstack.org Wed Dec 5 21:06:24 2018 From: allison at openstack.org (Allison Price) Date: Wed, 5 Dec 2018 15:06:24 -0600 Subject: What's Happening in the Open Infrastructure Community Message-ID: <5B66F0D8-B789-42F7-8864-E1A68685A306@openstack.org> Hi everyone, This week, we distributed the first Open Infrastructure Community Newsletter. Our goal with the bi-weekly newsletter is to provide a digest of the latest developments and activities across open infrastructure projects, events and users. This week, we highlighted the Berlin Summit as well as brief updates from OpenStack as well as the OSF's four pilot projects: Airship, Kata Containers, StarlingX and Zuul. You can checkout the full newsletter on Superuser [1], and if you are interested in receiving the upcoming newsletters, you can subscribe here [2]. If you would like to contribute or have feedback, please reach out to community at openstack.org. Thanks! Allison Allison Price OpenStack Foundation allison at openstack.org [1] http://superuser.openstack.org/articles/inside-open-infrastructure-newsletter1 [2] https://www.openstack.org/community/email-signup -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Wed Dec 5 21:27:16 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 5 Dec 2018 15:27:16 -0600 Subject: [nova][dev] Bug about disabled compute during scheduling Message-ID: Belmiro/Surya, I'm trying to follow up on something Belmiro mentioned at the summit before I forget about it. CERN sets this value low: https://docs.openstack.org/nova/latest/configuration/config.html#scheduler.max_placement_results And as a result, when disabling nova-computes during maintenance, you can fail during scheduling because placement only returns resource providers for disabled computes. I believe Dan and I kicked around some ideas on how we could deal with this, like either via a periodic in the compute service or when the compute service is disabled in the API, we would set the 'reserved' inventory value equal to the total to take those computes out of scheduling. I think Belmiro said this is what CERN is doing today as a workaround? For the latter solution, I don't know if we'd proxy that change directly from nova-api to placement, or make an RPC cast/call to nova-compute to do it, but that's an implementation detail. I mostly just want to make sure we get a bug reported for this so we don't lose track of it. Can one of you open a bug with your scenario and current workaround? -- Thanks, Matt From conrad.kimball at boeing.com Wed Dec 5 21:57:06 2018 From: conrad.kimball at boeing.com (Kimball (US), Conrad) Date: Wed, 5 Dec 2018 21:57:06 +0000 Subject: Anyone using ScaleIO block storage? Message-ID: <4c69e844a1a14e9388b59a8b7646bc37@boeing.com> Is anyone using ScaleIO (from Dell EMC) as a Cinder storage provider? What has been your experience with it, and at what scale? Our enterprise storage team is moving to ScaleIO and wants our OpenStack deployments to use it, so I'm looking for real life experiences to calibrate vendor stories of wonderfulness. One concern I do have is that it uses a proprietary protocol that in turn requires a proprietary "data client". For VM hosting this data client can be installed in the compute node host OS, but seems like we wouldn't be able to boot a bare-metal instance from a ScaleIO-backed Cinder volume. Conrad Kimball Associate Technical Fellow Enterprise Architecture Chief Architect, Enterprise Cloud Services conrad.kimball at boeing.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Wed Dec 5 23:24:41 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 5 Dec 2018 17:24:41 -0600 Subject: [goals][upgrade-checkers] Week R-18 Update Message-ID: First, I'm sorry about the big gap in updates, the last one being before the summit. Things have been busy elsewhere. Second, I'm happy to report the majority of projects have merged the initial framework patch for the "$project-status upgrade check" command. There are a few outstanding patches for projects which need core review (I went through this list today and +1 on them): https://review.openstack.org/#/q/topic:upgrade-checkers+status:open There are a few projects adding real upgrade checks as well, like designate and cloudkitty, which is good to see. For projects that have already merged the framework check, please talk in your meetings about what "real" upgrade check you could add in stein to replace the placeholder/sample check that came with the framework patch. Note that checks added in stein don't necessarily need to be for stein upgrade issues, they could be for something that was an upgrade impact in rocky, queens, etc, because with fast-forward upgrades people will be rolling through and might have missed something in the release notes. If you have questions, feel free to reach out to me in #openstack-dev (mriedem) or reply to this thread. -- Thanks, Matt From juliaashleykreger at gmail.com Wed Dec 5 23:29:07 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Wed, 5 Dec 2018 15:29:07 -0800 Subject: Anyone using ScaleIO block storage? In-Reply-To: <4c69e844a1a14e9388b59a8b7646bc37@boeing.com> References: <4c69e844a1a14e9388b59a8b7646bc37@boeing.com> Message-ID: On Wed, Dec 5, 2018 at 2:02 PM Kimball (US), Conrad < conrad.kimball at boeing.com> wrote: [trim] > One concern I do have is that it uses a proprietary protocol that in turn > requires a proprietary “data client”. For VM hosting this data client can > be installed in the compute node host OS, but seems like we wouldn’t be > able to boot a bare-metal instance from a ScaleIO-backed Cinder volume. > Not supporting iSCSI would indeed be an issue for bare-metal instances. The same basic issue exists for Ceph backed storage, although I've been encouraging the cinder team to provide a capability of returning an iscsi volume mapping for Ceph. If there is a similar possibility, please let me know as it might change the overall discussion regarding providing storage for bare metal instances. -Julia > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnsomor at gmail.com Thu Dec 6 00:13:02 2018 From: johnsomor at gmail.com (Michael Johnson) Date: Wed, 5 Dec 2018 16:13:02 -0800 Subject: Octavia Production Deployment Confused In-Reply-To: References: Message-ID: Hi Zufar, Tenant traffic into the VIP and out to member servers is isolated from the lb-mgmt-net. The VIP network is hot-plugged into the amphora network namespace for tenant traffic when a user creates a load balancer and specifies the VIP subnet or network. As for the certificate creation, please see this document awaiting patch review: https://review.openstack.org/613454 I wrote up a detailed certificate configuration guide that should help you resolve your certificate configuration issue. Michael On Tue, Dec 4, 2018 at 3:59 PM Zufar Dhiyaulhaq wrote: > > Hi all, > > Thank you, > So the amphora will use a provider network. but how we can access this load balancer externally? via IP assign into amphora (provider network IP)? > > Another question, I am facing a problem with a keypair. I am generating a keypair with `create_certificates.sh` > source /tmp/octavia/bin/create_certificates.sh /etc/octavia/certs /tmp/octavia/etc/certificates/openssl.cnf > > but when creating the load balancer service, I got this error from /var/log/octavia/worker.log > ERROR oslo_messaging.rpc.server CertificateGenerationException: Could not sign the certificate request: Failed to load CA Private Key /etc/octavia/certs/private/cakey.pem. > > I am using this configuration under octavia.conf > [certificates] > > ca_certificate = /etc/octavia/certs/ca_01.pem > > ca_private_key = /etc/octavia/certs/private/cakey.pem > > ca_private_key_passphrase = foobar > > Anyone know this issue? > I am following Mr. Lingxian Kong blog in https://lingxiankong.github.io/2016-06-07-octavia-deployment-prerequisites.html > > Best Regards, > Zufar Dhiyaulhaq > > > On Wed, Dec 5, 2018 at 4:35 AM Lingxian Kong wrote: >> >> On Wed, Dec 5, 2018 at 6:27 AM Gaël THEROND wrote: >>> >>> You can do it with any routed network that you’ll load as a provider network too. >>> >>> Way more simpler, no need for ovs manipulation, just get your network team to give you a vlan both available from computer node and controller plan. It can be a network subnet and vlan completely unknown from you controller as long as you get an intermediary equipment that route your traffic or that you add the proper route on your controllers. >> >> >> Yeah, that's also how we did for our Octavia service in production thanks to our ops team. >> >> Cheers, >> Lingxian Kong From jaosorior at redhat.com Thu Dec 6 00:17:03 2018 From: jaosorior at redhat.com (Juan Antonio Osorio Robles) Date: Wed, 5 Dec 2018 19:17:03 -0500 Subject: [tripleo] PTL on vacations Message-ID: <2e53ebf1-ca96-56c8-5491-c659c88d9ce8@redhat.com> Hello folks! I'll be on vacations from December 10th to January 2nd. For this reason, I won't be hosting the weekly meetings until I'm back. Best regards From jaosorior at redhat.com Thu Dec 6 00:17:54 2018 From: jaosorior at redhat.com (Juan Antonio Osorio Robles) Date: Wed, 5 Dec 2018 19:17:54 -0500 Subject: [tripleo] No weekly meeting on December 25 Message-ID: <248391bd-6c2c-2f6d-8fdc-6dee83a8490b@redhat.com> Enjoy the holidays! From Burak.Hoban at iag.com.au Thu Dec 6 00:46:31 2018 From: Burak.Hoban at iag.com.au (Burak Hoban) Date: Thu, 6 Dec 2018 00:46:31 +0000 Subject: Anyone using ScaleIO block storage? Message-ID: We've been using ScaleIO alongside OpenStack for about 2 years now. From a stability point of view, no issues... we're still running on Mitaka so some of the integration isn't great but with the upgrade cycle coming up for us all of that should be solved. We only utilise (VM) instances on OpenStack though, not bare metal. _____________________________________________________________________ The information transmitted in this message and its attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of the sender. This message has been scanned for viruses. _____________________________________________________________________ From shiriul.lol at gmail.com Thu Dec 6 01:30:28 2018 From: shiriul.lol at gmail.com (SIRI KIM) Date: Thu, 6 Dec 2018 10:30:28 +0900 Subject: [loci] How to add some agent to loci images Message-ID: Hello, Jean. I tried to add lbaas-agent and fwaas-agent to official loci neutron image. To pass openstack-helm gate test, I need lbaas-agent and fwaas-agent. I found your openstack source repository is repository: 172.17.0.1:5000/loci/requirements Please let me know I can I add lbaas-agent and fwaas-agent to official loci neutron image. Thanks, Siri -------------- next part -------------- An HTML attachment was scrubbed... URL: From saphi070 at gmail.com Thu Dec 6 01:47:47 2018 From: saphi070 at gmail.com (Sa Pham) Date: Thu, 6 Dec 2018 08:47:47 +0700 Subject: Anyone using ScaleIO block storage? In-Reply-To: References: Message-ID: Do you have a problems such as block request from compute to storage? So It makes VM is switched to read-only mode. On Thu, Dec 6, 2018 at 7:51 AM Burak Hoban wrote: > We've been using ScaleIO alongside OpenStack for about 2 years now. > > From a stability point of view, no issues... we're still running on Mitaka > so some of the integration isn't great but with the upgrade cycle coming up > for us all of that should be solved. > > We only utilise (VM) instances on OpenStack though, not bare metal. > > _____________________________________________________________________ > > The information transmitted in this message and its attachments (if any) > is intended > only for the person or entity to which it is addressed. > The message may contain confidential and/or privileged material. Any > review, > retransmission, dissemination or other use of, or taking of any action in > reliance > upon this information, by persons or entities other than the intended > recipient is > prohibited. > > If you have received this in error, please contact the sender and delete > this e-mail > and associated material from any computer. > > The intended recipient of this e-mail may only use, reproduce, disclose or > distribute > the information contained in this e-mail and any attached files, with the > permission > of the sender. > > This message has been scanned for viruses. > _____________________________________________________________________ > -- Sa Pham Dang Cloud RnD Team - VCCloud Phone/Telegram: 0986.849.582 Skype: great_bn -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Thu Dec 6 02:59:48 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 06 Dec 2018 11:59:48 +0900 Subject: [openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04) In-Reply-To: <4000535.P2t9rJb4HH@whitebase.usersys.redhat.com> References: <1677e3f2b18.e6941ff4108960.3659294646236910868@ghanshyammann.com> <4795573.S6joe1DXvj@whitebase.usersys.redhat.com> <4000535.P2t9rJb4HH@whitebase.usersys.redhat.com> Message-ID: <167817503c2.af0c3727123070.8090564432642728571@ghanshyammann.com> ---- On Wed, 05 Dec 2018 22:29:10 +0900 Luigi Toscano wrote ---- > On Wednesday, 5 December 2018 14:19:52 CET Luigi Toscano wrote: > > On Wednesday, 5 December 2018 13:02:08 CET Ghanshyam Mann wrote: > > > Reminder to test your project specific jobs if those are dependent on > > > Devstack or Tempest base jobs and keep adding the results on etherpad- > > > https://etherpad.openstack.org/p/devstack-bionic > > > > > > We will merge the Devstack and Tempest base job on Bionic on 10th Dec > > > 2018. > > > > I can't test it right now using the gates (so I can't really report this on > > the etherpad), but a quick local test shows that devstack-plugin-ceph shows > > does not seem to support bionic. I may try to prepare a test job later if no > > one beats me at it. > > > > Erp, sorry, I didn't notice https://review.openstack.org/#/c/611594/ - I > confirm that it makes devstack-plugin-ceph compatible with bionic, so please > merge it :) Yeah, frickler had the fix up and now it is merged. Thanks. -gmann > > Ciao > -- > Luigi > > > From sean.mcginnis at gmx.com Thu Dec 6 06:16:50 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Thu, 6 Dec 2018 00:16:50 -0600 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: <1677e2adcd5.b59b7cfb103641.8644361703617614132@ghanshyammann.com> References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> <1677e2adcd5.b59b7cfb103641.8644361703617614132@ghanshyammann.com> Message-ID: <20181206061649.GA28275@sm-workstation> > > > > Should we: > > > > - Reduce office hours to one or two per week, possibly rotating times > > > > - Dump the whole idea and just encourage people to ask questions at any > > time on #openstack-tc, and get asynchronous answers > > > > - Keep it as-is, it still has the side benefit of triggering spikes of > > TC member activity > > I vote for keeping it to two in a week which can cover both Asia and USA/EU TZ which mean either dropping either Tuesday or Wednesday. If traffic is same in office hours then also it is ok as it does not take any extra effort from us. we keep doing our day activity and keep eyes on channel during that time. Obviously it does not mean we will not active in other time but it is good to save a particular slot where people can find more than one TC. > > -gmann > This seems reasonable. The 01:00 UTC office hour on Wednesday has never had much activity. I think there are usually a few folks around in case someone does show up with some questions, but I have yet to see that actually happen. I think we could drop Wednesday with little noticeable impact, while still staying accessible via IRC or the mailing list. Sean From sean.mcginnis at gmx.com Thu Dec 6 06:20:36 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Thu, 6 Dec 2018 00:20:36 -0600 Subject: [tc][all] Train Community Goals In-Reply-To: References: Message-ID: <20181206062035.GB28275@sm-workstation> > > > > In other words, does #1 mean each python-clientlibrary's OSC plugin is > > ready to rock and roll, or we talking about everyone rewriting all client > > interactions in to openstacksdk, and porting existing OSC plugins use that > > different python sdk. > > We talked about those things as separate phases. IIRC, the first phase > was to include ensuring that python-openstackclient has full feature > coverage for non-admin operations for all microversions, using the > existing python-${service}client library or SDK as is appropriate. The > next phase was to ensure that the SDK has full feature coverage for all > microversions. After that point we could update OSC to use the SDK and > start deprecating the service-specific client libraries. > That was my recollection as well. > > In other words, some projects could find it very easy or that they are > > already done, where as others could find themselves with a huge lift that > > is also dependent upon review bandwidth that is outside of their control or > > influence which puts such a goal at risk if we try and push too hard. > > > > -Julia > > I do think there is still a lot of foundation work that needs to be done before we can make it a cycle goal to move more completely to osc. Before we get there, I think we need to see more folks involved on the project to be ready for the increased attention. Right now, I would classify this goal as a "huge lift". Sean From sean.mcginnis at gmx.com Thu Dec 6 06:41:31 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Thu, 6 Dec 2018 00:41:31 -0600 Subject: [release] Release countdown for week R-17, Dec 10-14 Message-ID: <20181206064131.GA28816@sm-workstation> Development Focus ----------------- We are coming up on end of year holiday's, so the next few weeks will probably go by fast. Teams should be focused on development plans, but please be aware if there are any project specific milestone 2 deadlines you need to be aware of. General Information ------------------- Just a reminder about the changes this cycle with library deliverables that follow the cycle-with-milestones release model. As announced, we will be automatically proposing releases for these libraries at milestone 2 if there have been any functional changes since the last release to help ensure those changes are picked up by consumers with plenty of time to identify and correct issues. More detail can be found in the original mailing list post describing the changes: http://lists.openstack.org/pipermail/openstack-dev/2018-October/135689.html There are also a set of deliverables following the cycle-with-intermediary model that are not considered libraries. These are services and other somewhat different deliverables. We want to make sure the cycle-with-intermediary release model is not being used as a way to just perform one final release. The intent of this release model is to have multiple releases throughout a development cycle. If you own one of these deliverables, please think about performing a release if one has not already been done for Stein, or decide if the updated cycle-with-rc release model is more appropriate for your needs. More information can be found here: http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000465.html Upcoming Deadlines & Dates -------------------------- Stein-2 Milestone: January 10 -- Sean McGinnis (smcginnis) From Burak.Hoban at iag.com.au Thu Dec 6 07:08:33 2018 From: Burak.Hoban at iag.com.au (Burak Hoban) Date: Thu, 6 Dec 2018 07:08:33 +0000 Subject: Anyone using ScaleIO block storage? In-Reply-To: References: Message-ID: The only time you should realistically see disks going into read-only mode from ScaleIO is if you’re having _major_ underlying issues, e.g. something like major networking issues, which may cause mass drops of MDMs or bad oscillating network failures. ScaleIO (VxFlex OS) can handle MDMs disconnecting fairly well, but the only time you’d really see issues if there’s something seriously wrong with the environment; this would be similar in a Ceph or any other software defined storage platform. We actually run ScaleIO environments (MDM, SDC and SDS) on top our Compute Nodes to offer instances block storage, but there’s also no issue in connecting external SDC’s to a ScaleIO cluster (e.g. if SDS is on storage only nodes) as it’s fully supported. _____________________________________________________________________ The information transmitted in this message and its attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of the sender. This message has been scanned for viruses. _____________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From saphi070 at gmail.com Thu Dec 6 07:17:40 2018 From: saphi070 at gmail.com (Sa Pham) Date: Thu, 6 Dec 2018 14:17:40 +0700 Subject: Anyone using ScaleIO block storage? In-Reply-To: References: Message-ID: So you are running SDS Service on Compute node. On Thu, Dec 6, 2018 at 2:08 PM Burak Hoban wrote: > The only time you should realistically see disks going into read-only mode > from ScaleIO is if you’re having _*major*_ underlying issues, e.g. > something like major networking issues, which may cause mass drops of MDMs > or bad oscillating network failures. ScaleIO (VxFlex OS) can handle MDMs > disconnecting fairly well, but the only time you’d really see issues if > there’s something seriously wrong with the environment; this would be > similar in a Ceph or any other software defined storage platform. > > > > We actually run ScaleIO environments (MDM, SDC and SDS) on top our Compute > Nodes to offer instances block storage, but there’s also no issue in > connecting external SDC’s to a ScaleIO cluster (e.g. if SDS is on storage > only nodes) as it’s fully supported. > > > > > > _____________________________________________________________________ > > The information transmitted in this message and its attachments (if any) > is intended > only for the person or entity to which it is addressed. > The message may contain confidential and/or privileged material. Any > review, > retransmission, dissemination or other use of, or taking of any action in > reliance > upon this information, by persons or entities other than the intended > recipient is > prohibited. > > If you have received this in error, please contact the sender and delete > this e-mail > and associated material from any computer. > > The intended recipient of this e-mail may only use, reproduce, disclose or > distribute > the information contained in this e-mail and any attached files, with the > permission > of the sender. > > This message has been scanned for viruses. > _____________________________________________________________________ > -- Sa Pham Dang Cloud RnD Team - VCCloud Phone/Telegram: 0986.849.582 Skype: great_bn -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.urdin at binero.se Thu Dec 6 08:40:57 2018 From: tobias.urdin at binero.se (Tobias Urdin) Date: Thu, 6 Dec 2018 09:40:57 +0100 Subject: [openstack-dev] [puppet] [stable] Deprecation of newton branches In-Reply-To: <20181205050207.GA19462@thor.bakeyournoodle.com> References: <2ae10ca2-8c77-ccbc-c009-a22c1d3cfd69@binero.se> <20181205050207.GA19462@thor.bakeyournoodle.com> Message-ID: <3e084433-c965-3881-53ac-761606b5604b@binero.se> Hello Tony, Yes that list is correct and complete, please go ahead. Thanks! On 12/05/2018 06:06 AM, Tony Breeds wrote: > On Thu, Nov 29, 2018 at 11:38:45AM +0100, Tobias Urdin wrote: >> 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? > Just to be clear You're asking for the following repos to be marked > EOL (current origin/stable/newton tagged as newton-eol and deleted, any > open reviews abandoned) > : > # EOL repos belonging to Puppet OpenStack > eol_branch.sh -- stable/newton newton-eol \ > openstack/puppet-aodh openstack/puppet-barbican \ > openstack/puppet-ceilometer openstack/puppet-cinder \ > openstack/puppet-designate openstack/puppet-glance \ > openstack/puppet-gnocchi openstack/puppet-heat \ > openstack/puppet-horizon openstack/puppet-ironic \ > openstack/puppet-keystone openstack/puppet-magnum \ > openstack/puppet-manila openstack/puppet-mistral \ > openstack/puppet-murano openstack/puppet-neutron \ > openstack/puppet-nova \ > openstack/puppet-openstack-integration \ > openstack/puppet-openstack_extras \ > openstack/puppet-openstack_spec_helper \ > openstack/puppet-openstacklib openstack/puppet-oslo \ > openstack/puppet-ovn openstack/puppet-sahara \ > openstack/puppet-swift openstack/puppet-tempest \ > openstack/puppet-trove openstack/puppet-vswitch \ > openstack/puppet-zaqar > > Yours Tony. From ifatafekn at gmail.com Thu Dec 6 09:32:13 2018 From: ifatafekn at gmail.com (Ifat Afek) Date: Thu, 6 Dec 2018 11:32:13 +0200 Subject: [all][ptl][heat][senlin][magnum][vitrage] New SIG for Autoscaling? plus, Session Summary: Autoscaling Integration, improvement, and feedback In-Reply-To: References: Message-ID: +1 for that. I see a lot of similarities between this SIG and the self-healing SIG, although their scopes are slightly different. In both cases, there is a need to decide when an action should be taken (based on Ceilometer, Monasca, Vitrage etc.) what action to take (healing/scaling) and how to execute it (using Heat, Senlin, Mistral, …). The main differences are the specific triggers and the actions to perform. I think that as a first step we should document the use cases. Ifat On Thu, Nov 29, 2018 at 9:34 PM Joseph Davis wrote: > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjamgade at suse.com Thu Dec 6 09:50:19 2018 From: sjamgade at suse.com (Sumit Jamgade) Date: Thu, 6 Dec 2018 10:50:19 +0100 Subject: [glance] is glance-cache deprecated In-Reply-To: <56432dc9-d61a-f1e0-16bd-a51bf29b2fb6@gmail.com> References: <56432dc9-d61a-f1e0-16bd-a51bf29b2fb6@gmail.com> Message-ID: On 12/05/2018 05:36 PM, Brian Rosmaita wrote: > On 12/5/18 10:30 AM, Sumit Jamgade wrote: >> Hello, >> >> $subject > > No. It's just not easily manageable ATM. so is there an alternative to the glance-cache-manage cmd for Rocky to queue/list/delete/... images > >> or are there any plans to migrate it to v2 ? > > Yes, see this spec for Stein: > https://git.openstack.org/cgit/openstack/glance-specs/commit/?id=862f2212c7a382a832456829be8bd6f2f9ee2561 thanks for this, I did not know about lite-specs. From Burak.Hoban at iag.com.au Thu Dec 6 11:26:17 2018 From: Burak.Hoban at iag.com.au (Burak Hoban) Date: Thu, 6 Dec 2018 11:26:17 +0000 Subject: Anyone using ScaleIO block storage? In-Reply-To: References: Message-ID: In our environment, the Compute Nodes run the MDM, SDC and SDS components of ScaleIO (VxFlex OS). However external SDC’s and SDC’s connecting to multiple environments are fully supported. As long as the SDC-SDS network is available, and at least one MDM network is also available then there shouldn’t be any issues. Have you had issues before? _____________________________________________________________________ The information transmitted in this message and its attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of the sender. This message has been scanned for viruses. _____________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From surya.seetharaman9 at gmail.com Thu Dec 6 00:26:00 2018 From: surya.seetharaman9 at gmail.com (Surya Seetharaman) Date: Thu, 6 Dec 2018 01:26:00 +0100 Subject: [nova][dev] Bug about disabled compute during scheduling In-Reply-To: References: Message-ID: Hi Matt, Thanks for looking into this, On Wed, Dec 5, 2018 at 10:27 PM Matt Riedemann wrote: > Belmiro/Surya, > > I'm trying to follow up on something Belmiro mentioned at the summit > before I forget about it. > > CERN sets this value low: > > > https://docs.openstack.org/nova/latest/configuration/config.html#scheduler.max_placement_results > > And as a result, when disabling nova-computes during maintenance, you > can fail during scheduling because placement only returns resource > providers for disabled computes. > > I believe Dan and I kicked around some ideas on how we could deal with > this, like either via a periodic in the compute service or when the > compute service is disabled in the API, we would set the 'reserved' > inventory value equal to the total to take those computes out of > scheduling. Just read the discussion on the channel and saw there were a couple of approaches proposed like traits and neg-aggregates in addition to the above two. > I think Belmiro said this is what CERN is doing today as a > workaround? > > As far as I know we don't have it in PROD, I will let Belmiro confirm this anyways > For the latter solution, I don't know if we'd proxy that change directly > from nova-api to placement, or make an RPC cast/call to nova-compute to > do it, but that's an implementation detail. > > I mostly just want to make sure we get a bug reported for this so we > don't lose track of it. Can one of you open a bug with your scenario and > current workaround? > > We have already filed a bug for this: https://bugs.launchpad.net/nova/+bug/1805984. Will add the workaround we have into the description. ------------ Regards, Surya. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sairamb at taashee.com Thu Dec 6 07:33:27 2018 From: sairamb at taashee.com (sairam) Date: Thu, 6 Dec 2018 00:33:27 -0700 (MST) Subject: [TripleO] Configure SR-IOV VFs in tripleo In-Reply-To: References: Message-ID: <1544081607797-0.post@n7.nabble.com> we deployed overcloud rhosp10 through sriov but i am not able to create instance through please help me -- Sent from: http://openstack.10931.n7.nabble.com/Developer-f2.html From dougal at redhat.com Thu Dec 6 09:52:40 2018 From: dougal at redhat.com (Dougal Matthews) Date: Thu, 6 Dec 2018 09:52:40 +0000 Subject: [openstack-dev] [tripleo] Workflows Squad changes In-Reply-To: References: Message-ID: On Wed, 28 Nov 2018 at 10:15, 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. > +2, I support this idea. Adriano has been a valuable member of the Mistral core team for almost a year (and active in Mistral for some time before that). So he has lots of experience directly relevant to the workflow and action development in tripleo-common. Recently he has started contributing and reviewing regularly so I am confident he would make a positive impact to the tripleo core team. 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 > __________________________________________________________________________ > 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: From mriedemos at gmail.com Thu Dec 6 12:45:55 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 6 Dec 2018 06:45:55 -0600 Subject: [dev][nova][glance] Interesting bug about deleting shelved server snapshot Message-ID: I came across this bug during triage today: https://bugs.launchpad.net/nova/+bug/1807110 They are advocating that nova/glance somehow keep a shelved server snapshot image from being inadvertently deleted by the user since it could result in data loss as they can't unshelve the server later (there is metadata in nova that links the shelved server to the snapshot image in glance which is used during unshelve). I don't see a base description field on images but I suppose nova could write a description property that explains what the snapshot is and warn against deleting it. Going a step further, nova could potentially set the protected flag to true so the image cannot be deleted, but I have two concerns about that: 1. I don't see any way to force delete a protected image in glance - does that exist or has it been discussed before? 2. Would the user be able to PATCH the image to change the protected value to false and then delete the image if they really wanted to? The other problem with nova marking the image as protected is that if the user deletes the server, the compute API tries to delete the snapshot image [1] which would fail if it's still protected, and then we could see snapshot images getting orphaned in glance. Arguably nova could detect this situation, update the protected field to false, and then delete the image. Other thoughts? Has this come up before? [1] https://github.com/openstack/nova/blob/c9dca64fa64005e5bea327f06a7a3f4821ab72b1/nova/compute/api.py#L1950 -- Thanks, Matt From navdeep.uniyal at bristol.ac.uk Thu Dec 6 14:10:10 2018 From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal) Date: Thu, 6 Dec 2018 14:10:10 +0000 Subject: Networking-sfc Installation on Openstack Queens Message-ID: Dear all, I would like to use the networking-sfc in my multi-node openstack (Queens) vanilla installation. All the guides I found focussed on devstack. Please let me know if there is a proper documentation/guide to install the sfc service on my controller and compute nodes including the prerequisites. Please note: as of now I am using linuxbridge agent only. Please state if openVSwitch agent is required and how to install it. Kind Regards, Navdeep -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Thu Dec 6 14:14:16 2018 From: smooney at redhat.com (Sean Mooney) Date: Thu, 6 Dec 2018 14:14:16 +0000 Subject: [dev][nova][glance] Interesting bug about deleting shelved server snapshot In-Reply-To: References: Message-ID: On Thu, Dec 6, 2018 at 12:52 PM Matt Riedemann wrote: > > I came across this bug during triage today: > > https://bugs.launchpad.net/nova/+bug/1807110 > > They are advocating that nova/glance somehow keep a shelved server > snapshot image from being inadvertently deleted by the user since it > could result in data loss as they can't unshelve the server later (there > is metadata in nova that links the shelved server to the snapshot image > in glance which is used during unshelve). > > I don't see a base description field on images but I suppose nova could > write a description property that explains what the snapshot is and warn > against deleting it. > > Going a step further, nova could potentially set the protected flag to > true so the image cannot be deleted, but I have two concerns about that: > > 1. I don't see any way to force delete a protected image in glance - > does that exist or has it been discussed before? > > 2. Would the user be able to PATCH the image to change the protected > value to false and then delete the image if they really wanted to? would they need too? if they wanted to delete the snapshot could thye not just delete the shelved instnace. if the snapshot is goin i assume we will not be able to unshvel it anyway by falling back to the base image or something like that so is there a usecase where deleteing the snap shot leave the shelved instance in a valid unshelvable state? if not i think setting the protected flag is ok to do. > > The other problem with nova marking the image as protected is that if > the user deletes the server, the compute API tries to delete the > snapshot image [1] which would fail if it's still protected, and then we > could see snapshot images getting orphaned in glance. Arguably nova > could detect this situation, update the protected field to false, and > then delete the image. that seams sane to me. if nova set teh protected field when shelving the instance it shold be able to unprotect the snapshot when unshelving. > > Other thoughts? Has this come up before? > > [1] > https://github.com/openstack/nova/blob/c9dca64fa64005e5bea327f06a7a3f4821ab72b1/nova/compute/api.py#L1950 > > -- > > Thanks, > > Matt > From smooney at redhat.com Thu Dec 6 14:29:21 2018 From: smooney at redhat.com (Sean Mooney) Date: Thu, 6 Dec 2018 14:29:21 +0000 Subject: Networking-sfc Installation on Openstack Queens In-Reply-To: References: Message-ID: On Thu, Dec 6, 2018 at 2:15 PM Navdeep Uniyal wrote: > > Dear all, > > > > I would like to use the networking-sfc in my multi-node openstack (Queens) vanilla installation. > > All the guides I found focussed on devstack. Please let me know if there is a proper documentation/guide to install the sfc service on my controller and compute nodes including the prerequisites. > > > > Please note: as of now I am using linuxbridge agent only. Please state if openVSwitch agent is required and how to install it. as far as i am aware, networking-sfc does not supprot linux bridge. the default backend is ovs but it has support for odl and onos also the last time i checked. few openstack installers have native supprot for networking-sfc in production. looking at the offical install guide https://docs.openstack.org/networking-sfc/latest/install/index.html it does seam to assume devstack in places and is generally quite light on content. that said networking sfc runs as an extention to neutron so the basic steps descibed in the guide can be adapted to any deployment. i do not work on networking-sfc so i cant really help but just so you are aware the openstack at lists.openstack.org list is nolonger used and we have moved all openstack lists to openstack-discuss at list.openstack.org. i have updated the list address but if you are not already on the new list i would suggest joining to recive the responce. > > > > Kind Regards, > > Navdeep > > > > From navdeep.uniyal at bristol.ac.uk Thu Dec 6 13:08:33 2018 From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal) Date: Thu, 6 Dec 2018 13:08:33 +0000 Subject: Networking-sfc Installation on Openstack Queens Message-ID: Dear all, I would like to use the networking-sfc in my multi-node openstack (Queens) vanilla installation. All the guides I found focussed on devstack. Please let me know if there is a proper documentation/guide to install the sfc service on my controller and compute nodes including the prerequisites. Please note: as of now I am using linuxbridge agent only. Please state if openVSwitch agent is required and how to install it. Kind Regards, Navdeep -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Thu Dec 6 14:50:20 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 6 Dec 2018 08:50:20 -0600 Subject: [dev][nova][glance] Interesting bug about deleting shelved server snapshot In-Reply-To: References: Message-ID: On 12/6/2018 8:14 AM, Sean Mooney wrote: >> 2. Would the user be able to PATCH the image to change the protected >> value to false and then delete the image if they really wanted to? > would they need too? > if they wanted to delete the snapshot could thye not just delete the > shelved instnace. if the snapshot is goin i assume we will not be able > to unshvel > it anyway by falling back to the base image or something like that so is > there a usecase where deleteing the snap shot leave the shelved instance in a > valid unshelvable state? if not i think setting the protected flag is ok to do. I'm having a hard time understanding what you're saying. Are you saying, the user should delete the protected snapshot via deleting the shelved server? I don't think that's very clear. But yes you can't unshelve the instance if the image is deleted (or if the user does not have access to it, which is a separate bug [1675791]). I think you're just saying, the user shouldn't need to delete the protected shelve snapshot image and if they do, the server should be deleted as well. >> The other problem with nova marking the image as protected is that if >> the user deletes the server, the compute API tries to delete the >> snapshot image [1] which would fail if it's still protected, and then we >> could see snapshot images getting orphaned in glance. Arguably nova >> could detect this situation, update the protected field to false, and >> then delete the image. > that seams sane to me. if nova set teh protected field when shelving the > instance it shold be able to unprotect the snapshot when unshelving. It's not unshelve, it's delete. -- Thanks, Matt From lbragstad at gmail.com Thu Dec 6 15:15:04 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Thu, 6 Dec 2018 09:15:04 -0600 Subject: [tc][all] Train Community Goals In-Reply-To: <20181206062035.GB28275@sm-workstation> References: <20181206062035.GB28275@sm-workstation> Message-ID: Today in the TC meeting, we discussed the status of the three candidate goals [0]. Ultimately, we as the TC, are wondering who would be willing to drive the goal work. Having a champion step up early on will help us get answers to questions about the feasibility of the goal, it's impact across OpenStack, among other things that will help us, as a community, make an informed decision. Remember, championing a goal doesn't need to fall on a single individual. With proper communication, work can be spread out to lighten the load. What I'd like is to open this up to the community and see who would be willing to drive the proposed goals. If you have any questions about championing a goal, please don't hesitate to swing by #openstack-tc, or you can ping me privately. [0] http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-12-06-14.00.log.html#l-104 On Thu, Dec 6, 2018 at 12:20 AM Sean McGinnis wrote: > > > > > > In other words, does #1 mean each python-clientlibrary's OSC plugin is > > > ready to rock and roll, or we talking about everyone rewriting all > client > > > interactions in to openstacksdk, and porting existing OSC plugins use > that > > > different python sdk. > > > > We talked about those things as separate phases. IIRC, the first phase > > was to include ensuring that python-openstackclient has full feature > > coverage for non-admin operations for all microversions, using the > > existing python-${service}client library or SDK as is appropriate. The > > next phase was to ensure that the SDK has full feature coverage for all > > microversions. After that point we could update OSC to use the SDK and > > start deprecating the service-specific client libraries. > > > > That was my recollection as well. > > > > In other words, some projects could find it very easy or that they are > > > already done, where as others could find themselves with a huge lift > that > > > is also dependent upon review bandwidth that is outside of their > control or > > > influence which puts such a goal at risk if we try and push too hard. > > > > > > -Julia > > > > > I do think there is still a lot of foundation work that needs to be done > before > we can make it a cycle goal to move more completely to osc. Before we get > there, I think we need to see more folks involved on the project to be > ready > for the increased attention. > > Right now, I would classify this goal as a "huge lift". > > Sean > -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at ericsson.com Thu Dec 6 15:24:37 2018 From: balazs.gibizer at ericsson.com (=?Windows-1252?Q?Bal=E1zs_Gibizer?=) Date: Thu, 6 Dec 2018 15:24:37 +0000 Subject: Anyone using ScaleIO block storage? In-Reply-To: <4c69e844a1a14e9388b59a8b7646bc37@boeing.com> References: <4c69e844a1a14e9388b59a8b7646bc37@boeing.com> Message-ID: <1544109874.26914.3@smtp.office365.com> On Wed, Dec 5, 2018 at 10:57 PM, Kimball (US), Conrad wrote: > Is anyone using ScaleIO (from Dell EMC) as a Cinder storage provider? > What has been your experience with it, and at what scale? My employer has multiple customers using our OpenStack based cloud solution with ScaleIO as volume backend. These customers are mostly telco operators running virtual network functions in their cloud, but there are customers using the cloud for other non telco IT purpose too. There are various types and flavors of the ScaleIO deployments at these customers, including low footprint deployment providing nx100 GiB raw capacity with small number of servers, medium capacity ultra HA systems with nx10 servers using multiple protection domains and fault sets, high capacity systems with petabyte range raw capacity, hyperconverged systems running storage and compute services on the same servers. The general feedback from the customers are positive, we did not hear about performance or stability issues. However, one common property of these customers and deployments that none of them handle bare metal instances, therefore, we do not have experience with that. In order to boot bare metal instance from ScaleIO volume, the BIOS should be able to act as ScaleIO client, which will likely never happen. ScaleIO used to have a capability to expose the volumes over standard iSCSI, but this capability has been removed long time ago. As this was a feature in the past, making Dell/EMC to re-introduce it may not be completely impossible if there is high enough interest for that. However, this would vanish the power of the proprietary protocol which let the client to balance the load towards multiple servers. Cheers, gibi > > Our enterprise storage team is moving to ScaleIO and wants our > OpenStack deployments to use it, so I’m looking for real life > experiences to calibrate vendor stories of wonderfulness. > > One concern I do have is that it uses a proprietary protocol that in > turn requires a proprietary “data client”. For VM hosting this > data client can be installed in the compute node host OS, but seems > like we wouldn’t be able to boot a bare-metal instance from a > ScaleIO-backed Cinder volume. > > Conrad Kimball > Associate Technical Fellow > Enterprise Architecture > Chief Architect, Enterprise Cloud Services > conrad.kimball at boeing.com From smooney at redhat.com Thu Dec 6 15:26:18 2018 From: smooney at redhat.com (Sean Mooney) Date: Thu, 6 Dec 2018 15:26:18 +0000 Subject: [dev][nova][glance] Interesting bug about deleting shelved server snapshot In-Reply-To: References: Message-ID: On Thu, Dec 6, 2018 at 2:50 PM Matt Riedemann wrote: > > On 12/6/2018 8:14 AM, Sean Mooney wrote: > >> 2. Would the user be able to PATCH the image to change the protected > >> value to false and then delete the image if they really wanted to? > > would they need too? > > if they wanted to delete the snapshot could thye not just delete the > > shelved instnace. if the snapshot is goin i assume we will not be able > > to unshvel > > it anyway by falling back to the base image or something like that so is > > there a usecase where deleteing the snap shot leave the shelved instance in a > > valid unshelvable state? if not i think setting the protected flag is ok to do. > > I'm having a hard time understanding what you're saying. Are you saying, > the user should delete the protected snapshot via deleting the shelved > server? I don't think that's very clear. But yes you can't unshelve the > instance if the image is deleted (or if the user does not have access to > it, which is a separate bug [1675791]). I think you're just saying, the > user shouldn't need to delete the protected shelve snapshot image and if > they do, the server should be deleted as well. yes sorry i did not say that clearly. basically i wanted to say that since the user would break the unshelving of an instance by deleting the snapshot nova created we should prevent them from doing that by setting the protected flag. if they really wanted to still delete the snappshot they should therefor delete the shelved instance which should cause nova to delete the snapshot. > > >> The other problem with nova marking the image as protected is that if > >> the user deletes the server, the compute API tries to delete the > >> snapshot image [1] which would fail if it's still protected, and then we > >> could see snapshot images getting orphaned in glance. Arguably nova > >> could detect this situation, update the protected field to false, and > >> then delete the image. > > that seams sane to me. if nova set teh protected field when shelving the > > instance it shold be able to unprotect the snapshot when unshelving. > > It's not unshelve, it's delete. sorry you are correct on deleting the instance i think nova should be able to unprotect the snapshot if the instnace is still shelved. that said there could be issues with this if someone manually booted another instance form the snapshot but im not sure if that would have other issues. > > -- > > Thanks, > > Matt From jsbryant at electronicjungle.net Thu Dec 6 15:30:53 2018 From: jsbryant at electronicjungle.net (Jay Bryant) Date: Thu, 6 Dec 2018 09:30:53 -0600 Subject: [tc][all] Train Community Goals In-Reply-To: <20181206062035.GB28275@sm-workstation> References: <20181206062035.GB28275@sm-workstation> Message-ID: >> We talked about those things as separate phases. IIRC, the first phase >> was to include ensuring that python-openstackclient has full feature >> coverage for non-admin operations for all microversions, using the >> existing python-${service}client library or SDK as is appropriate. The >> next phase was to ensure that the SDK has full feature coverage for all >> microversions. After that point we could update OSC to use the SDK and >> start deprecating the service-specific client libraries. > >That was my recollection as well. This was my understanding as well and I think the phased approach is important to take given that I don't know that we have as many people with SDK experience. At least that is the case in Cinder. > I do think there is still a lot of foundation work that needs to be done before > we can make it a cycle goal to move more completely to osc. Before we get > there, I think we need to see more folks involved on the project to be ready > for the increased attention. > Right now, I would classify this goal as a "huge lift". I think that moving to OSC and away from the other client interfaces is a good goal. It will make for a better user experience and would hopefully help make documentation easier to understand. With that said, I know that there is a sizable gap between what OSC has for Cinder and what is available for python-cinderclient. If we make this a goal we are doing to need good organization and documentation of those gaps and volunteers to help make this change happen. On Thu, Dec 6, 2018 at 12:21 AM Sean McGinnis wrote: > > > > > > In other words, does #1 mean each python-clientlibrary's OSC plugin is > > > ready to rock and roll, or we talking about everyone rewriting all > client > > > interactions in to openstacksdk, and porting existing OSC plugins use > that > > > different python sdk. > > > > We talked about those things as separate phases. IIRC, the first phase > > was to include ensuring that python-openstackclient has full feature > > coverage for non-admin operations for all microversions, using the > > existing python-${service}client library or SDK as is appropriate. The > > next phase was to ensure that the SDK has full feature coverage for all > > microversions. After that point we could update OSC to use the SDK and > > start deprecating the service-specific client libraries. > > > > That was my recollection as well. > > > > In other words, some projects could find it very easy or that they are > > > already done, where as others could find themselves with a huge lift > that > > > is also dependent upon review bandwidth that is outside of their > control or > > > influence which puts such a goal at risk if we try and push too hard. > > > > > > -Julia > > > > > I do think there is still a lot of foundation work that needs to be done > before > we can make it a cycle goal to move more completely to osc. Before we get > there, I think we need to see more folks involved on the project to be > ready > for the increased attention. > > Right now, I would classify this goal as a "huge lift". > > Sean > > -- jsbryant at electronicjungle.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsbryant at electronicjungle.net Thu Dec 6 15:36:48 2018 From: jsbryant at electronicjungle.net (Jay Bryant) Date: Thu, 6 Dec 2018 09:36:48 -0600 Subject: Anyone using ScaleIO block storage? In-Reply-To: References: <4c69e844a1a14e9388b59a8b7646bc37@boeing.com> Message-ID: > Not supporting iSCSI would indeed be an issue for bare-metal instances. The same basic issue exists for Ceph backed storage, although I've been encouraging the cinder team to provide a capability of returning an iscsi volume mapping for Ceph. If there > is a similar possibility, please let me know as it might change the overall discussion regarding providing storage for bare metal instances. Julia, This is an interesting idea. Depending on how things go with the Ceph iSCSI implementation goes I wonder if we can look at doing something more general where the volume node can act as an iSCSI gateway for any user that wants iSCSI support. I am not sure how hard creating a general solution would be or what the performance impact would be. It puts the volume node in the data path which may cause people to hesitate on this. Something to think about though. Jay On Wed, Dec 5, 2018 at 5:30 PM Julia Kreger wrote: > > > On Wed, Dec 5, 2018 at 2:02 PM Kimball (US), Conrad < > conrad.kimball at boeing.com> wrote: > [trim] > >> One concern I do have is that it uses a proprietary protocol that in turn >> requires a proprietary “data client”. For VM hosting this data client can >> be installed in the compute node host OS, but seems like we wouldn’t be >> able to boot a bare-metal instance from a ScaleIO-backed Cinder volume. >> > > Not supporting iSCSI would indeed be an issue for bare-metal instances. > The same basic issue exists for Ceph backed storage, although I've been > encouraging the cinder team to provide a capability of returning an iscsi > volume mapping for Ceph. If there is a similar possibility, please let me > know as it might change the overall discussion regarding providing storage > for bare metal instances. > > -Julia > >> -- jsbryant at electronicjungle.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From Arkady.Kanevsky at dell.com Thu Dec 6 15:53:06 2018 From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com) Date: Thu, 6 Dec 2018 15:53:06 +0000 Subject: [tc][all] Train Community Goals In-Reply-To: References: <20181206062035.GB28275@sm-workstation> Message-ID: <670372467d5245ebb7e314867c2aca0f@AUSX13MPS308.AMER.DELL.COM> Suggest we get User community involved. If a user have tools written to current client libraries it will be impacted. So getting their feedback on impact and, for sure, continues reminder that this is coming and when will be good. From: Jay Bryant [mailto:jsbryant at electronicjungle.net] Sent: Thursday, December 6, 2018 9:31 AM To: Sean McGinnis Cc: openstack-discuss at lists.openstack.org Subject: Re: [tc][all] Train Community Goals [EXTERNAL EMAIL] >> We talked about those things as separate phases. IIRC, the first phase >> was to include ensuring that python-openstackclient has full feature >> coverage for non-admin operations for all microversions, using the >> existing python-${service}client library or SDK as is appropriate. The >> next phase was to ensure that the SDK has full feature coverage for all >> microversions. After that point we could update OSC to use the SDK and >> start deprecating the service-specific client libraries. > >That was my recollection as well. This was my understanding as well and I think the phased approach is important to take given that I don't know that we have as many people with SDK experience. At least that is the case in Cinder. > I do think there is still a lot of foundation work that needs to be done before > we can make it a cycle goal to move more completely to osc. Before we get > there, I think we need to see more folks involved on the project to be ready > for the increased attention. > Right now, I would classify this goal as a "huge lift". I think that moving to OSC and away from the other client interfaces is a good goal. It will make for a better user experience and would hopefully help make documentation easier to understand. With that said, I know that there is a sizable gap between what OSC has for Cinder and what is available for python-cinderclient. If we make this a goal we are doing to need good organization and documentation of those gaps and volunteers to help make this change happen. On Thu, Dec 6, 2018 at 12:21 AM Sean McGinnis > wrote: > > > > In other words, does #1 mean each python-clientlibrary's OSC plugin is > > ready to rock and roll, or we talking about everyone rewriting all client > > interactions in to openstacksdk, and porting existing OSC plugins use that > > different python sdk. > > We talked about those things as separate phases. IIRC, the first phase > was to include ensuring that python-openstackclient has full feature > coverage for non-admin operations for all microversions, using the > existing python-${service}client library or SDK as is appropriate. The > next phase was to ensure that the SDK has full feature coverage for all > microversions. After that point we could update OSC to use the SDK and > start deprecating the service-specific client libraries. > That was my recollection as well. > > In other words, some projects could find it very easy or that they are > > already done, where as others could find themselves with a huge lift that > > is also dependent upon review bandwidth that is outside of their control or > > influence which puts such a goal at risk if we try and push too hard. > > > > -Julia > > I do think there is still a lot of foundation work that needs to be done before we can make it a cycle goal to move more completely to osc. Before we get there, I think we need to see more folks involved on the project to be ready for the increased attention. Right now, I would classify this goal as a "huge lift". Sean -- jsbryant at electronicjungle.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Thu Dec 6 15:58:13 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 6 Dec 2018 15:58:13 +0000 Subject: [ops] Anyone using ScaleIO block storage? In-Reply-To: <1544109874.26914.3@smtp.office365.com> References: <4c69e844a1a14e9388b59a8b7646bc37@boeing.com> <1544109874.26914.3@smtp.office365.com> Message-ID: <20181206155812.5bmixglpv65tjp4w@yuggoth.org> On 2018-12-06 15:24:37 +0000 (+0000), Balázs Gibizer wrote: [...] > In order to boot bare metal instance from ScaleIO volume, the BIOS > should be able to act as ScaleIO client, which will likely never > happen. ScaleIO used to have a capability to expose the volumes > over standard iSCSI, but this capability has been removed long > time ago. As this was a feature in the past, making Dell/EMC to > re-introduce it may not be completely impossible if there is high > enough interest for that. However, this would vanish the power of > the proprietary protocol which let the client to balance the load > towards multiple servers. [...] You'd only need iSCSI support for bootstrapping though, right? Once you're able to boot a ramdisk with the ScaleIO (my friends at EMC would want me to remind everyone it's called "VFlexOS" now) driver it should be able to pivot to their proprietary protocol. In theory some running service on the network could simply act as an iSCSI proxy for that limited purpose. -- 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 jungleboyj at gmail.com Thu Dec 6 16:04:04 2018 From: jungleboyj at gmail.com (Jay Bryant) Date: Thu, 6 Dec 2018 10:04:04 -0600 Subject: [ops] Anyone using ScaleIO block storage? In-Reply-To: <20181206155812.5bmixglpv65tjp4w@yuggoth.org> References: <4c69e844a1a14e9388b59a8b7646bc37@boeing.com> <1544109874.26914.3@smtp.office365.com> <20181206155812.5bmixglpv65tjp4w@yuggoth.org> Message-ID: On 12/6/2018 9:58 AM, Jeremy Stanley wrote: > On 2018-12-06 15:24:37 +0000 (+0000), Balázs Gibizer wrote: > [...] >> In order to boot bare metal instance from ScaleIO volume, the BIOS >> should be able to act as ScaleIO client, which will likely never >> happen. ScaleIO used to have a capability to expose the volumes >> over standard iSCSI, but this capability has been removed long >> time ago. As this was a feature in the past, making Dell/EMC to >> re-introduce it may not be completely impossible if there is high >> enough interest for that. However, this would vanish the power of >> the proprietary protocol which let the client to balance the load >> towards multiple servers. > [...] > > You'd only need iSCSI support for bootstrapping though, right? Once > you're able to boot a ramdisk with the ScaleIO (my friends at EMC > would want me to remind everyone it's called "VFlexOS" now) driver > it should be able to pivot to their proprietary protocol. In theory > some running service on the network could simply act as an iSCSI > proxy for that limited purpose. Good question.  Don't know the details there.  I am going to add Helen Walsh who works on the Dell/EMC drivers to see if she could help give some insight. Jay From rosmaita.fossdev at gmail.com Thu Dec 6 16:17:57 2018 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Thu, 6 Dec 2018 11:17:57 -0500 Subject: [dev][nova][glance] Interesting bug about deleting shelved server snapshot In-Reply-To: References: Message-ID: <66e2902d-8a43-c293-6243-b8ca908d4bf9@gmail.com> (Just addressing the specific Glance questions, not taking a position on the proposal.) On 12/6/18 7:45 AM, Matt Riedemann wrote: > I came across this bug during triage today: > > https://bugs.launchpad.net/nova/+bug/1807110 > > They are advocating that nova/glance somehow keep a shelved server > snapshot image from being inadvertently deleted by the user since it > could result in data loss as they can't unshelve the server later (there > is metadata in nova that links the shelved server to the snapshot image > in glance which is used during unshelve). > > I don't see a base description field on images but I suppose nova could > write a description property that explains what the snapshot is and warn > against deleting it. Yes, any user can add a 'description' property (unless prohibited by property protections). > Going a step further, nova could potentially set the protected flag to > true so the image cannot be deleted, but I have two concerns about that: > > 1. I don't see any way to force delete a protected image in glance - > does that exist or has it been discussed before? You cannot force delete a protected image in glance, but an admin can PATCH the image to update 'protected' to false, and then delete the image, which is functionally the same thing. > > 2. Would the user be able to PATCH the image to change the protected > value to false and then delete the image if they really wanted to? Yes, replacing the value of the 'protected' property on an image can be done by the image owner. (There is no specific policy for this other than the generic "modify_image" policy. I guess I should mention that there's also a "delete_image" policy. The default value for both policies is unrestricted ("").) > > The other problem with nova marking the image as protected is that if > the user deletes the server, the compute API tries to delete the > snapshot image [1] which would fail if it's still protected, and then we > could see snapshot images getting orphaned in glance. Arguably nova > could detect this situation, update the protected field to false, and > then delete the image. > > Other thoughts? Has this come up before? > > [1] > https://github.com/openstack/nova/blob/c9dca64fa64005e5bea327f06a7a3f4821ab72b1/nova/compute/api.py#L1950 > > From balazs.gibizer at ericsson.com Thu Dec 6 16:41:49 2018 From: balazs.gibizer at ericsson.com (=?iso-8859-1?Q?Bal=E1zs_Gibizer?=) Date: Thu, 6 Dec 2018 16:41:49 +0000 Subject: [nova] What to do with the legacy notification interface? Message-ID: <1544114506.15837.0@smtp.office365.com> Hi, Last decision from the Denver PTG [1] was to * finish the remaining transformations [2] * change the default value of notification_format conf option from 'both' to 'versioned' * communicate that the legacy notification interface has been deprecated, unsupported but the code will not be removed Since the PTG the last two transformation patches [2] has been approved and the deprecation patch has been prepared [3]. However recently we got a bug report [4] where the performance impact of emiting both legacy and versioned notification caused unnecessary load on the message bus. (Btw this performance impact was raised in the original spec [5]). The original reason we emited both type of notifications was to keep backward compatibility with consumers only understanding legacy notifications. It worked so well that most of the consumers still depend on the legacy notifications (detailed status is in [1]). I see three options to move forward: A) Do nothing. By default, emit both type of notifications. This means that deployers seeing the performance impact of [4] needs to reconfigure nova. Also this is agains our decision to move away from supporting legacy notifications. B) Follow the plan from the PTG and change the default value of the config to emit only versioned notifications. This solves the immediate effect of the bug [4]. This is following our original plan. BUT this is backward incompatible change which in the current situation means most of the deployments (e.g. those, deploying notification consumer modules like ceilometer) need to change this config to 'unversioned' or 'both'. There was discussion about helping out notification consumers to convert their code using the new versioned interface but I have no spare time at the moment and I failed to drum up resources internally for this work. Also I don't see others volunteering for such work. C) Change the default to 'legacy'. This solves the bug [4]. BUT sends a really mixed message. As our original goal was to stop supporting the legacy notification interface of nova. Matt stated on IRC recently, there is no real bug inflow for the legacy code. Also looking at changes in the code I see that last cycle we had couple of blueprints extending the new versioned notifications with extra fields but that inflow stopped in this cycle too. So we most probably can keep the legacy code in place and supported forever without too much pain and too much divergence from the versioned interface. -- Personally, I spent enough time implementing and reviewing the versioned interface that I'm biased towards option B). But I do understand that our original goals setting in 2015 was made in such environment that changed significantly in the past cycles. So I can accept option C) as well if we can agree. Cheers, gibi [1] https://etherpad.openstack.org/p/nova-ptg-stein L765 [2] https://review.openstack.org/#/q/topic:bp/versioned-notification-transformation-stein+status:open [3] https://review.openstack.org/#/c/603079/ [4] https://bugs.launchpad.net/nova/+bug/1805659 [5] https://review.openstack.org/#/c/224755/11/specs/mitaka/approved/versioned-notification-api.rst at 687 From juliaashleykreger at gmail.com Thu Dec 6 17:09:23 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Thu, 6 Dec 2018 09:09:23 -0800 Subject: Anyone using ScaleIO block storage? In-Reply-To: <1544109874.26914.3@smtp.office365.com> References: <4c69e844a1a14e9388b59a8b7646bc37@boeing.com> <1544109874.26914.3@smtp.office365.com> Message-ID: On Thu, Dec 6, 2018 at 7:31 AM Balázs Gibizer wrote: > [trim] > ScaleIO used to have a capability to expose the volumes over standard > iSCSI, but this capability has been removed long time ago. As this was > a feature > in the past, making Dell/EMC to re-introduce it may not be completely > impossible if there is high enough interest for that. However, this > would vanish > the power of the proprietary protocol which let the client to balance > the load towards multiple servers. > [trim] iSCSI does have the ability to communicate additional paths that a client may choose to invoke, the issue then largely becomes locking across paths, which becomes a huge issue if lun locking is being used as part of something like a clustered file system. Of course, most initial initiators may not be able to support this, and as far as I'm aware what iscsi initiators that we can control in hardware don't have or have limited iscsi multipath support. Of course, if they iBFT load that.... Well, I'll stop now because of limitations with iBFT. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From juliaashleykreger at gmail.com Thu Dec 6 17:17:23 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Thu, 6 Dec 2018 09:17:23 -0800 Subject: [ops] Anyone using ScaleIO block storage? In-Reply-To: <20181206155812.5bmixglpv65tjp4w@yuggoth.org> References: <4c69e844a1a14e9388b59a8b7646bc37@boeing.com> <1544109874.26914.3@smtp.office365.com> <20181206155812.5bmixglpv65tjp4w@yuggoth.org> Message-ID: On Thu, Dec 6, 2018 at 8:04 AM Jeremy Stanley wrote: > On 2018-12-06 15:24:37 +0000 (+0000), Balázs Gibizer wrote: > [...] > > In order to boot bare metal instance from ScaleIO volume, the BIOS > > should be able to act as ScaleIO client, which will likely never > > happen. ScaleIO used to have a capability to expose the volumes > > over standard iSCSI, but this capability has been removed long > > time ago. As this was a feature in the past, making Dell/EMC to > > re-introduce it may not be completely impossible if there is high > > enough interest for that. However, this would vanish the power of > > the proprietary protocol which let the client to balance the load > > towards multiple servers. [...] > > You'd only need iSCSI support for bootstrapping though, right? Once > you're able to boot a ramdisk with the ScaleIO (my friends at EMC > would want me to remind everyone it's called "VFlexOS" now) driver > it should be able to pivot to their proprietary protocol. In theory > some running service on the network could simply act as an iSCSI > proxy for that limited purpose. > -- > Jeremy Stanley > This is a great point. I fear the issue would be how to inform the guest of what and how to pivot. At some point it might just be easier to boot the known kernel/ramdisk and have a command line argument. That being said things like this is why ironic implemented the network booting ramdisk interface so an operator could choose something along similar lines. If some abstraction pattern could be identified, and be well unit tested at least, I feel like we might be able to pass along the necessary information if needed. Naturally the existing ironic community does not have access to this sort of hardware, and it would be a bespoke sort of integration. We investigated doing something similar for Ceph integration but largely pulled back due to a lack of initial ramdisk loader standardization and even support for the root filesystem on Ceph. -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.goncharov at gmail.com Thu Dec 6 17:29:01 2018 From: artem.goncharov at gmail.com (Artem Goncharov) Date: Thu, 6 Dec 2018 18:29:01 +0100 Subject: [tc][all] Train Community Goals In-Reply-To: References: <20181206062035.GB28275@sm-workstation> Message-ID: On Thu, Dec 6, 2018, 16:19 Lance Bragstad wrote: > Today in the TC meeting, we discussed the status of the three candidate > goals [0]. Ultimately, we as the TC, are wondering who would be willing to > drive the goal work. > > Having a champion step up early on will help us get answers to questions > about the feasibility of the goal, it's impact across OpenStack, among > other things that will help us, as a community, make an informed decision. > > Remember, championing a goal doesn't need to fall on a single individual. > With proper communication, work can be spread out to lighten the load. > > What I'd like is to open this up to the community and see who would be > willing to drive the proposed goals. If you have any questions about > championing a goal, please don't hesitate to swing by #openstack-tc, or you > can ping me privately. > I was waiting for the start of switching osc "services" to SDK for quite a while now. I am definitely interested and committed to support the real coding work here. I would also like to volunteer driving the goal if noone objects. > [0] > http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-12-06-14.00.log.html#l-104 > > On Thu, Dec 6, 2018 at 12:20 AM Sean McGinnis > wrote: > >> > > >> > > In other words, does #1 mean each python-clientlibrary's OSC plugin is >> > > ready to rock and roll, or we talking about everyone rewriting all >> client >> > > interactions in to openstacksdk, and porting existing OSC plugins use >> that >> > > different python sdk. >> > >> > We talked about those things as separate phases. IIRC, the first phase >> > was to include ensuring that python-openstackclient has full feature >> > coverage for non-admin operations for all microversions, using the >> > existing python-${service}client library or SDK as is appropriate. The >> > next phase was to ensure that the SDK has full feature coverage for all >> > microversions. After that point we could update OSC to use the SDK and >> > start deprecating the service-specific client libraries. >> > >> >> That was my recollection as well. >> >> > > In other words, some projects could find it very easy or that they are >> > > already done, where as others could find themselves with a huge lift >> that >> > > is also dependent upon review bandwidth that is outside of their >> control or >> > > influence which puts such a goal at risk if we try and push too hard. >> > > >> > > -Julia >> > > >> >> I do think there is still a lot of foundation work that needs to be done >> before >> we can make it a cycle goal to move more completely to osc. Before we get >> there, I think we need to see more folks involved on the project to be >> ready >> for the increased attention. >> >> Right now, I would classify this goal as a "huge lift". >> >> Sean >> > Artem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Thu Dec 6 17:35:03 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 6 Dec 2018 11:35:03 -0600 Subject: [nova] What to do with the legacy notification interface? In-Reply-To: <1544114506.15837.0@smtp.office365.com> References: <1544114506.15837.0@smtp.office365.com> Message-ID: <1466d5db-316f-34a3-9f08-a5931ab6ce86@gmail.com> On 12/6/2018 10:41 AM, Balázs Gibizer wrote: > Hi, > > Last decision from the Denver PTG [1] was to > * finish the remaining transformations [2] > * change the default value of notification_format conf option from > 'both' to 'versioned' > * communicate that the legacy notification interface has been > deprecated, unsupported but the code will not be removed > > Since the PTG the last two transformation patches [2] has been approved > and the deprecation patch has been prepared [3]. However recently we > got a bug report [4] where the performance impact of emiting both > legacy and versioned notification caused unnecessary load on the > message bus. (Btw this performance impact was raised in the original > spec [5]). The original reason we emited both type of notifications was > to keep backward compatibility with consumers only understanding legacy > notifications. It worked so well that most of the consumers still > depend on the legacy notifications (detailed status is in [1]). > > I see three options to move forward: > > A) Do nothing. By default, emit both type of notifications. This means > that deployers seeing the performance impact of [4] needs to > reconfigure nova. Also this is agains our decision to move away from > supporting legacy notifications. > > B) Follow the plan from the PTG and change the default value of the > config to emit only versioned notifications. This solves the immediate > effect of the bug [4]. This is following our original plan. BUT this is > backward incompatible change which in the current situation means most > of the deployments (e.g. those, deploying notification consumer modules > like ceilometer) need to change this config to 'unversioned' or 'both'. > > There was discussion about helping out notification consumers to > convert their code using the new versioned interface but I have no > spare time at the moment and I failed to drum up resources internally > for this work. Also I don't see others volunteering for such work. > > C) Change the default to 'legacy'. This solves the bug [4]. BUT sends a > really mixed message. As our original goal was to stop supporting the > legacy notification interface of nova. > Matt stated on IRC recently, there is no real bug inflow for the legacy > code. Also looking at changes in the code I see that last cycle we had > couple of blueprints extending the new versioned notifications with > extra fields but that inflow stopped in this cycle too. So we most > probably can keep the legacy code in place and supported forever > without too much pain and too much divergence from the versioned > interface. > > -- > > Personally, I spent enough time implementing and reviewing the > versioned interface that I'm biased towards option B). But I do > understand that our original goals setting in 2015 was made in such > environment that changed significantly in the past cycles. So I can > accept option C) as well if we can agree. > > Cheers, > gibi > > [1]https://etherpad.openstack.org/p/nova-ptg-stein L765 > [2] > https://review.openstack.org/#/q/topic:bp/versioned-notification-transformation-stein+status:open > [3]https://review.openstack.org/#/c/603079/ > [4]https://bugs.launchpad.net/nova/+bug/1805659 > [5] > https://review.openstack.org/#/c/224755/11/specs/mitaka/approved/versioned-notification-api.rst at 687 In skimming the spec again: https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/versioned-notification-transformation-newton.html I get that legacy unversioned notifications in nova were kind of a mess and changing them without a version was icky even though they are internal to a deployment. Moving to using versioned notifications with well-defined objects, docs samples, all of that is very nice for nova *developers*, but what I've been struggling with is what benefit do the versioned notifications bring to nova *consumers*, besides we say you can only add new notifications if they are versioned. In other words, what motivation does a project that is currently consuming unversioned legacy notifications have to put the work in to switch to versioned notifications? The spec doesn't really get into that in much detail. I do remember an older thread with gordc where he was asking about schema payloads and such so a consumer could say implement processing a notification at version 1.0, but then if it gets a version 1.4 payload it could figure out how to backlevel the payload to the 1.0 version it understands - sort of like what we've talked about doing with os-vif between nova and neutron (again, for years). But that thread kind of died out from what I remember. But that seems like a nice benefit for upgrades, but I also figure it's probably very low priority on everyone's wishlist. Another way I've thought about the deprecation lately is that if we (nova devs) did the work to migrate ceilometer, then we'd have one major consumer and we could then deprecate the legacy notifications and change the default to 'versioned'. But like you said, no one is coming out of the woodwork to do that work. Anyway, I'm just having a hard time with the fact so much work has been put into this over the last few years that now everything is transformed but no one is using it, and I don't see many compelling reasons why a project would migrate, especially since the projects that are consuming nova's notifications are mostly working with a skeleton crew of maintainers. I'd really like some input from other project developers and operators here. -- Thanks, Matt From pshchelokovskyy at mirantis.com Thu Dec 6 18:02:25 2018 From: pshchelokovskyy at mirantis.com (Pavlo Shchelokovskyy) Date: Thu, 6 Dec 2018 20:02:25 +0200 Subject: [barbican][nova] booting instance from snapshot or unshelve with image signature verification enabled Message-ID: Hi all, I am looking at how Nova is integrated with Barbican and am wondering how the user workflow when booting instance from snapshot should work (including unshelving a shelved instance) when Nova is set to strictly verify Glance images' signatures. Currently Nova strips by default all signature-related image metadata of original image when creating snapshot and for good reason - as the hash of the snapshot is definitely not the same as that of the image it was booted from, the signature of the original image is no longer valid for snapshot. Effectively that means that when strict image signature validation is enabled in Nova, the user can no longer simply boot from that snapshot, and even less obvious, can not unshelve instances the same way as without signature validation enabled. So is it expected that user manually signs her instance snapshots or is there some automagic way to do it? Or is it a known issue / limitation? Unfortunately I couldn't find any existing bugs or mentions in docs on that. Best regards, -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrhillsman at gmail.com Thu Dec 6 18:10:16 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Thu, 6 Dec 2018 12:10:16 -0600 Subject: [sdk] Establishing SDK Validation Baseline Message-ID: Hi everyone, We have spent some time working to get an idea of what official SDKs would look like. We had some sessions during the Berlin summit[0][1] and there was a lot of great feedback. Currently the following SDKs are generally considered usable for their respective language; there are others of course: openstacksdk (Python) gophercloud (Go) pkgcloud (JavaScript) openstack4j (Java) rust-openstack (Rust) fog-openstack (Ruby) php-opencloud (PHP) After many discussions it seems SDK validation essentially should be about confirming cloud state pre/post SDK interaction rather than API support. An example is that when I use pkgcloud and ask that a VM be created, does the VM exist, in the way I asked it exist, rather than are there specific API calls that are being hit along the way to creating my VM. I am putting this email out to keep the community informed of what has been discussed in this space but also and most importantly to get feedback and support for this work. It would be great to get a set of official and community SDKs, get them setup with CI testing for validation (not changing their current CI for unit/functional/acceptance testing; unless asked to help do this), and connect the results to the updated project navigator SDK section. A list of scenarios has been provided as a good starting point for cloud state checks.[2] Essentially the proposal is to deploy OpenStack from upstream (devstack or other), stand up a VM within the cloud, grab all the SDKs, run acceptance tests, report pass/fail results, update project navigator. Of course there are details to be worked out and I do have a few questions that I hope would help get everyone interested on the same page via this thread. 1. Does this make sense? 1. Would folks be interested in a SDK SIG or does it make more sense to request an item on the API SIG's agenda? 1. Bi-weekly discussions a good cadence? 1. Who is interested in tackling this together? [0] https://etherpad.openstack.org/p/BER-better-expose-what-we-produce [1] https://etherpad.openstack.org/p/BER-sdk-certification [2] https://docs.google.com/spreadsheets/d/1cdzFeV5I4Wk9FK57yqQmp5JJdGfKzEOdB3Vtt9vnVJM -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From msm at redhat.com Thu Dec 6 18:36:25 2018 From: msm at redhat.com (Michael McCune) Date: Thu, 6 Dec 2018 13:36:25 -0500 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: References: Message-ID: thanks for bringing this up Melvin. On Thu, Dec 6, 2018 at 1:13 PM Melvin Hillsman wrote: > Essentially the proposal is to deploy OpenStack from upstream (devstack or other), stand up a VM within the cloud, grab all the SDKs, run acceptance tests, report pass/fail results, update project navigator. Of course there are details to be worked out and I do have a few questions that I hope would help get everyone interested on the same page via this thread. > > Does this make sense? > makes sense to me, and sounds like a good idea provided we have the people ready to maintain the testing infra and patches for this (which i assume we do). > Would folks be interested in a SDK SIG or does it make more sense to request an item on the API SIG's agenda? > i don't have a strong opinion either way, but i will point out that the API-SIG has migrated to office hours instead of a weekly meeting. if you expect that the proposed SDK work will have a strong cadence then it might make more practical sense to create a new SIG, or really even a working group until the objective of the testing is reached. the only reason i bring up working groups here is that there seems like a clearly stated goal for the initial part of this work. namely creating the testing and validation infrastructure described. it might make sense to form a working group until the initial work is complete and then move continued discussion under the API-SIG for organization. > Bi-weekly discussions a good cadence? > that sounds reasonable for a start, but i don't have a strong opinion here. > Who is interested in tackling this together? > if you need any help from API-SIG, please reach out. i would be willing to help with administrative/governance type stuff. peace o/ From paul.bourke at oracle.com Thu Dec 6 18:41:43 2018 From: paul.bourke at oracle.com (Paul Bourke) Date: Thu, 6 Dec 2018 10:41:43 -0800 (PST) Subject: [octavia] Routing between lb-mgmt-net and amphora Message-ID: Hi, This is mostly a follow on to the thread at[0], though due to the mailing list transition it was easier to start a new thread. I've been attempting to get Octavia setup according to the dev-quick-start guide[1], but have been struggling with the following piece: "Add appropriate routing to / from the ‘lb-mgmt-net’ such that egress is allowed, and the controller (to be created later) can talk to hosts on this network." In mranga's reply, they say: > -- Create an ovs port on br-int > -- Create a neutron port using the ovs port that you just created. > -- Assign the ip address of the neutron port to the ovs port > -- Use ip netns exec to assign a route in the router namespace of the LoadBalancer network. I have enough of an understanding of Neutron/OVS for this to mostly make sense, but not enough to actually put it into practice it seems. My environment: 3 x control nodes 2 x network nodes 1 x compute All nodes have two interfaces, eth0 being the management network - 192.168.5.0/24, and eth1 being used for the provider network. I then create the Octavia lb-mgmt-net on 172.18.2.0/24. I've read the devstack script[2] and have the following questions: * Should I add the OVS port to br-int on the compute, network nodes, or both? * What is the purpose of creating a neutron port in this scenario If anyone is able to explain this a bit further or can even point to some good material to flesh out the underlying concepts it would be much appreciated, I feel the 'Neutron 101' videos I've done so far are not quite getting me there :) Cheers, -Paul [0] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000544.html [1] https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html [2] https://github.com/openstack/octavia/blob/master/devstack/plugin.sh From duc.openstack at gmail.com Thu Dec 6 18:53:53 2018 From: duc.openstack at gmail.com (Duc Truong) Date: Thu, 6 Dec 2018 10:53:53 -0800 Subject: [senlin] Cancelling this week's meeting Message-ID: Everyone, The new odd week meeting time has just been approved but due to the short notice and also since there are no important updates since last week, I will cancel the Senlin meeting for this week. Next week the meeting will be on Friday at 530 UTC. Regards, Duc From chris at openstack.org Thu Dec 6 19:52:35 2018 From: chris at openstack.org (Chris Hoge) Date: Thu, 6 Dec 2018 11:52:35 -0800 Subject: [loci] How to add some agent to loci images In-Reply-To: References: Message-ID: <2ED125CF-8AA3-4D81-8C0F-FDF8ED1EF2F0@openstack.org> Except in a few instances, Loci aims to generically build OpenStack service images and has pretty robust scripts that will allow you to build the containers without modification of the project. In the instance of neutron-fwaas, you can easily build the service following the instructions in README.md[1] in the Loci repository. Just set `PROJECT=neutron-fwaas` and tag appripriately. The major caveat is the build for that project is not gate tested (although I've managed to complete a build of it in my own environment). You could do the same thing similarly for neutron-lbaas, but please be aware that for a number of reasons neutron-lbaas project has been deprecated[2], and you should instead prefer to use Octavia as the official replacement for it. Thanks, Chris [1] http://git.openstack.org/cgit/openstack/loci/tree/README.md [2] https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation > On Dec 5, 2018, at 5:30 PM, SIRI KIM wrote: > > Hello, Jean. > > I tried to add lbaas-agent and fwaas-agent to official loci neutron image. > To pass openstack-helm gate test, I need lbaas-agent and fwaas-agent. > > I found your openstack source repository is > repository: 172.17.0.1:5000/loci/requirements > > Please let me know I can I add lbaas-agent and fwaas-agent to official loci neutron image. > > Thanks, > Siri From doug at doughellmann.com Thu Dec 6 20:43:09 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 06 Dec 2018 15:43:09 -0500 Subject: [tc] agenda for Technical Committee Meeting 6 Dec 2018 @ 1400 UTC In-Reply-To: References: Message-ID: Doug Hellmann writes: > TC Members, > > Our next meeting will be this Thursday, 6 Dec at 1400 UTC in > #openstack-tc. This email contains the agenda for the meeting, based on > the content of the wiki [0]. > > If you will not be able to attend, please include your name in the > "Apologies for Absence" section of the wiki page [0]. > > [0] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee > > > > * Follow up on past action items > > ** dhellmann complete liaison assignments using the random generator > > I have updated the team liaisons in the wiki [1]. Please review the > list of projects to which you are assigned. > > [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker#Project_Teams > > ** tc-members review the chair duties document > > The draft document from [2] has been merged and is now available in > the governance repo as CHAIR.rst [3]. Please come prepared to discuss > any remaining questions about the list of chair duties. > > [2] https://etherpad.openstack.org/p/tc-chair-responsibilities > [3] http://git.openstack.org/cgit/openstack/governance/tree/CHAIR.rst > > * active initiatives > > ** keeping up with python 3 releases > > We are ready to approve Zane's resolution for a process for tracking > python 3 versions [4]. There is one wording update [5] that we should > prepare for approval as well. The next step will be to approve Sean's > patch describing the runtimes supported for Stein [6]. > > Please come prepared to discuss any issues with those patches so we > can resolve them and move forward. > > [4] https://review.openstack.org/613145 > [5] https://review.openstack.org/#/c/621461/1 > [6] https://review.openstack.org/#/c/611080/ > > * follow-up from Berlin Forum > > ** Vision for OpenStack clouds > > Zane has summarized the forum session on the mailing list [7], > including listing several potential updates to the vision based on > our discussion there. Please come prepared to discuss next steps for > making those changes. > > [7] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000431.html > > ** Train cycle goals > > I posted my summary of the forum session [8]. Each of the candidate > goals have work to be done before they could be selected, so we will > need to work with the sponsors and champions to see where enough > progress is made to let us choose from among the proposals. Lance has > agreed to lead the selection process for the Train goals, and will be > looking for someone to pair up with on that. > > [8] http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000055.html > > ** Other TC outcomes from Forum > > We had several other forum sessions, and should make sure we have a > good list of any promised actions that came from those > discussions. Please come prepared to discuss any sessions you > moderated -- having summaries on the mailing list before the meeting > would be very helpful. > > -- > Doug > The log and summary of this meeting are available in the usual place: Minutes: http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-12-06-14.00.html Minutes (text): http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-12-06-14.00.txt Log: http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-12-06-14.00.log.html -- Doug From doug at doughellmann.com Thu Dec 6 21:00:19 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 06 Dec 2018 16:00:19 -0500 Subject: [tc] Technical Committee status update for 6 December Message-ID: This is the (alegedly) weekly summary of work being done by the Technical Committee members. The full list of active items is managed in the wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker We also track TC objectives for the cycle using StoryBoard at: https://storyboard.openstack.org/#!/project/923 == Recent Activity == It has been 4 weeks since the last update email, in part due to the Summit, then a holiday, then my absense due to illness. Project updates: * Add tenks under Ironic: https://review.openstack.org/#/c/600411/ * Add os_placement role to OpenStack Ansible: https://review.openstack.org/#/c/615187/ * Retired openstack-ansible-os_monasca-ui https://review.openstack.org/#/c/617322/ * Chris Hoge was made the new Loci team PTL https://review.openstack.org/#/c/620370/ Other updates: * Thierry has been working on a series of changes on behalf of the release management team to record the release management style used for each deliverable listed in the governance repository. https://review.openstack.org/#/c/613268/ * Zane updated our guidelines for new projects to clarify the scoping requirements: https://review.openstack.org/#/c/614799/ * Zane also added a Vision for OpenStack Clouds document, describing what we see as the scope of OpenStack overall: https://review.openstack.org/#/c/592205/ * I copied some code we had in a couple of other places into the governance repository to make it easier for the release, goal, and election tools to consume the governance data using the new openstack-governance library from PyPI. https://review.openstack.org/#/c/614599/ * I started a document describing the responsibilities of the TC chair. https://review.openstack.org/#/c/618810/ == TC Meetings == In order to fulfill our obligations under the OpenStack Foundation bylaws, the TC needs to hold meetings at least once each quarter. We agreed to meet monthly, and to emphasize agenda items that help us move initiatives forward while leaving most of the discussion of those topics to the mailing list. The agendas for all of our meetings will be sent to the openstack-dev mailing list in advance, and links to the logs and summary will be sent as a follow up after the meeting. Our most recent meeting was held on 6 Dec 2018. * http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000696.html The next meeting will be 3 December @ 1400 UTC in #openstack-tc == Ongoing Discussions == We have several governance changes up for review related to deciding how we will manage future Python 3 upgrades (including adding 3.7 and possibly dropping 3.5 during Stein). These are close to being approved, with some final wording adjustments being made now. * Explicitly declare stein supported runtimes: https://review.openstack.org/#/c/611080/ * Resolution on keeping up with Python 3 releases: https://review.openstack.org/#/c/613145/ I proposed an update to our house rules to allow faster approval of release management metadata maintained in the governance repository. * https://review.openstack.org/#/c/622989/ Thierry and Chris have been working on a description of the role of the TC. * https://review.openstack.org/#/c/622400/ Ghanshyam has proposed an enhancement to the Vision for OpenStack Clouds to cover feature discovery. * https://review.openstack.org/#/c/621516/ Lance has proposed an update to the charter to clarify how we will handle PTL transitions in the middle of a development cycle. * https://review.openstack.org/#/c/620928/ == TC member actions/focus/discussions for the coming week(s) == We have several significant changes up for review. Please take time to consider all of the open patches, then comment and vote on them. It's very difficult to tell if we have reached consensus if everyone waits for the conversation to settle before commenting. == Contacting the TC == The Technical Committee uses a series of weekly "office hour" time slots for synchronous communication. We hope that by having several such times scheduled, we will have more opportunities to engage with members of the community from different timezones. Office hour times in #openstack-tc: - 09:00 UTC on Tuesdays - 01:00 UTC on Wednesdays - 15:00 UTC on Thursdays If you have something you would like the TC to discuss, you can add it to our office hour conversation starter etherpad at: https://etherpad.openstack.org/p/tc-office-hour-conversation-starters Many of us also run IRC bouncers which stay in #openstack-tc most of the time, so please do not feel that you need to wait for an office hour time to pose a question or offer a suggestion. You can use the string "tc-members" to alert the members to your question. You will find channel logs with past conversations at http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ If you expect your topic to require significant discussion or to need input from members of the community other than the TC, please start a mailing list discussion on openstack-discuss at lists.openstack.org and use the subject tag "[tc]" to bring it to the attention of TC members. -- Doug From openstack at nemebean.com Thu Dec 6 21:06:25 2018 From: openstack at nemebean.com (Ben Nemec) Date: Thu, 6 Dec 2018 15:06:25 -0600 Subject: [tc] Technical Committee status update for 6 December In-Reply-To: References: Message-ID: On 12/6/18 3:00 PM, Doug Hellmann wrote: > > This is the (alegedly) weekly summary of work being done by the > Technical Committee members. The full list of active items is managed in > the wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker > > We also track TC objectives for the cycle using StoryBoard at: > https://storyboard.openstack.org/#!/project/923 > > == Recent Activity == > > It has been 4 weeks since the last update email, in part due to the > Summit, then a holiday, then my absense due to illness. > > Project updates: > > * Add tenks under Ironic: https://review.openstack.org/#/c/600411/ > * Add os_placement role to OpenStack Ansible: https://review.openstack.org/#/c/615187/ > * Retired openstack-ansible-os_monasca-ui https://review.openstack.org/#/c/617322/ > * Chris Hoge was made the new Loci team PTL https://review.openstack.org/#/c/620370/ > > Other updates: > > * Thierry has been working on a series of changes on behalf of the > release management team to record the release management style used > for each deliverable listed in the governance > repository. https://review.openstack.org/#/c/613268/ > * Zane updated our guidelines for new projects to clarify the scoping > requirements: https://review.openstack.org/#/c/614799/ > * Zane also added a Vision for OpenStack Clouds document, describing > what we see as the scope of OpenStack overall: > https://review.openstack.org/#/c/592205/ > * I copied some code we had in a couple of other places into the > governance repository to make it easier for the release, goal, and > election tools to consume the governance data using the new > openstack-governance library from > PyPI. https://review.openstack.org/#/c/614599/ > * I started a document describing the responsibilities of the TC > chair. https://review.openstack.org/#/c/618810/ > > == TC Meetings == > > In order to fulfill our obligations under the OpenStack Foundation > bylaws, the TC needs to hold meetings at least once each quarter. We > agreed to meet monthly, and to emphasize agenda items that help us move > initiatives forward while leaving most of the discussion of those topics > to the mailing list. The agendas for all of our meetings will be sent to > the openstack-dev mailing list in advance, and links to the logs and > summary will be sent as a follow up after the meeting. > > Our most recent meeting was held on 6 Dec 2018. > > * http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000696.html > > The next meeting will be 3 December @ 1400 UTC in #openstack-tc *January? > > == Ongoing Discussions == > > We have several governance changes up for review related to deciding how > we will manage future Python 3 upgrades (including adding 3.7 and > possibly dropping 3.5 during Stein). These are close to being approved, > with some final wording adjustments being made now. > > * Explicitly declare stein supported runtimes: > https://review.openstack.org/#/c/611080/ > * Resolution on keeping up with Python 3 releases: > https://review.openstack.org/#/c/613145/ > > I proposed an update to our house rules to allow faster approval of > release management metadata maintained in the governance repository. > > * https://review.openstack.org/#/c/622989/ > > Thierry and Chris have been working on a description of the role of the > TC. > > * https://review.openstack.org/#/c/622400/ > > Ghanshyam has proposed an enhancement to the Vision for OpenStack Clouds > to cover feature discovery. > > * https://review.openstack.org/#/c/621516/ > > Lance has proposed an update to the charter to clarify how we will > handle PTL transitions in the middle of a development cycle. > > * https://review.openstack.org/#/c/620928/ > > == TC member actions/focus/discussions for the coming week(s) == > > We have several significant changes up for review. Please take time to > consider all of the open patches, then comment and vote on them. It's > very difficult to tell if we have reached consensus if everyone waits > for the conversation to settle before commenting. > > == Contacting the TC == > > The Technical Committee uses a series of weekly "office hour" time > slots for synchronous communication. We hope that by having several > such times scheduled, we will have more opportunities to engage > with members of the community from different timezones. > > Office hour times in #openstack-tc: > > - 09:00 UTC on Tuesdays > - 01:00 UTC on Wednesdays > - 15:00 UTC on Thursdays > > If you have something you would like the TC to discuss, you can add > it to our office hour conversation starter etherpad at: > https://etherpad.openstack.org/p/tc-office-hour-conversation-starters > > Many of us also run IRC bouncers which stay in #openstack-tc most > of the time, so please do not feel that you need to wait for an > office hour time to pose a question or offer a suggestion. You can > use the string "tc-members" to alert the members to your question. > > You will find channel logs with past conversations at > http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ > > If you expect your topic to require significant discussion or to need > input from members of the community other than the TC, please start a > mailing list discussion on openstack-discuss at lists.openstack.org and > use the subject tag "[tc]" to bring it to the attention of TC members. > From mranga at gmail.com Thu Dec 6 21:12:09 2018 From: mranga at gmail.com (M. Ranganathan) Date: Thu, 6 Dec 2018 16:12:09 -0500 Subject: [octavia] Routing between lb-mgmt-net and amphora In-Reply-To: References: Message-ID: HACK ALERT Disclaimer: My suggestion could be clumsy. On Thu, Dec 6, 2018 at 1:46 PM Paul Bourke wrote: > Hi, > > This is mostly a follow on to the thread at[0], though due to the mailing > list transition it was easier to start a new thread. > > I've been attempting to get Octavia setup according to the dev-quick-start > guide[1], but have been struggling with the following piece: > > "Add appropriate routing to / from the ‘lb-mgmt-net’ such that egress is > allowed, and the controller (to be created later) can talk to hosts on this > network." > > In mranga's reply, they say: > > > -- Create an ovs port on br-int > > -- Create a neutron port using the ovs port that you just created. > > -- Assign the ip address of the neutron port to the ovs port > > -- Use ip netns exec to assign a route in the router namespace of the > LoadBalancer network. > > I have enough of an understanding of Neutron/OVS for this to mostly make > sense, but not enough to actually put it into practice it seems. My > environment: > > 3 x control nodes > 2 x network nodes > 1 x compute > > All nodes have two interfaces, eth0 being the management network - > 192.168.5.0/24, and eth1 being used for the provider network. I then > create the Octavia lb-mgmt-net on 172.18.2.0/24. > > I've read the devstack script[2] and have the following questions: > > * Should I add the OVS port to br-int on the compute, network nodes, or > both? > I have only one controller which also functions as my network node. I added the port on the controller/network node. br-int is the place where the integration happens. You will find each network has an internal vlan tag associated with it. Use the tag assigned to your lb network when you create the ovs port. ovs-vsctl show will tell you more. * What is the purpose of creating a neutron port in this scenario > Just want to be sure Neutron knows about it and has an entry in its database so the address won't be used for something else. If you are using static addresses, for example you should not need this (I think). BTW the created port is DOWN. I am not sure why and I am not sure it matters. > If anyone is able to explain this a bit further or can even point to some > good material to flesh out the underlying concepts it would be much > appreciated, I feel the 'Neutron 101' videos I've done so far are not quite > getting me there :) > > Cheers, > -Paul > > [0] > http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000544.html > [1] > https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html > [2] https://github.com/openstack/octavia/blob/master/devstack/plugin.sh > > -- M. Ranganathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Thu Dec 6 21:14:17 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 06 Dec 2018 16:14:17 -0500 Subject: [tc] Technical Committee status update for 6 December In-Reply-To: References: Message-ID: Ben Nemec writes: > On 12/6/18 3:00 PM, Doug Hellmann wrote: >> >> >> Our most recent meeting was held on 6 Dec 2018. >> >> * http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000696.html >> >> The next meeting will be 3 December @ 1400 UTC in #openstack-tc > > *January? Hey, look, someone reads these messages! Yes, January, 2019. Thanks for spotting that. Details and ICS file at http://eavesdrop.openstack.org/#Technical_Committee_Meeting -- Doug From jp.methot at planethoster.info Thu Dec 6 21:19:24 2018 From: jp.methot at planethoster.info (=?utf-8?Q?Jean-Philippe_M=C3=A9thot?=) Date: Thu, 6 Dec 2018 16:19:24 -0500 Subject: [ops] Disk QoS in Cinder and Nova flavour Message-ID: <1D2E0C27-525D-4262-A0D5-C56E0DEAC9AE@planethoster.info> Hi, This is something that’s not exactly clear in the documentation and so I thought I’d ask here. There are currently two ways to set disk IO limits, or QoS: through Cinder QoS values or through Nova flavours. My question is, what’s the difference exactly? I assume that Cinder QoS only applies on Cinder volume, but is the same true for flavour QoS? In other words, is QoS through flavour supposed to apply to both Cinder volumes and ephemeral storage or is it only for ephemeral storage? Additionally, I'm under the assumption that once you provision a block device of a certain type with QoS associated to it, it becomes impossible to modify the values afterwards. Is that correct? This is a strange behaviour, considering that technically, you should be able to change QoS when it’s set through flavour using a simple resize. Please correct me if I’m wrong. I feel that this could be better explained in the current documentation. Jean-Philippe Méthot Openstack system administrator Administrateur système Openstack PlanetHoster inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Thu Dec 6 21:19:44 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 6 Dec 2018 21:19:44 +0000 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> Message-ID: <20181206211943.y6w365nm746r7ula@yuggoth.org> On 2018-12-04 16:45:20 +0100 (+0100), Thierry Carrez wrote: [...] > Should we: > > - Reduce office hours to one or two per week, possibly rotating times > > - Dump the whole idea and just encourage people to ask questions at any time > on #openstack-tc, and get asynchronous answers > > - Keep it as-is, it still has the side benefit of triggering spikes of TC > member activity > > Thoughts ? I'm fine keeping the schedule as-is (it hasn't been any particular inconvenience for me personally), but if there are times we think might work better for the community then I'm all for rearranging it into a more effective lineup too. -- 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 Thu Dec 6 21:48:33 2018 From: melwittt at gmail.com (melanie witt) Date: Thu, 6 Dec 2018 13:48:33 -0800 Subject: [dev][nova] time for another spec review day? In-Reply-To: References: Message-ID: On Wed, 5 Dec 2018 10:38:06 -0800, Melanie Witt wrote: > Our spec freeze is milestone 2 January 10 and I was thinking, because of > holiday time coming up, it might be a good idea to have another spec > review day ahead of the freeze early next year. I was thinking maybe > Tuesday next week December 11, to allow the most amount of time before > holiday PTO starts. > > Please let me know what you think. We discussed this in the nova meeting today and the consensus was NOT to have another spec review day. We have a lot in-flight already and people are busy with other things, so based on the input from the meeting and lack of response on this email, we will pass on having another spec review day. Best, -melanie From mriedemos at gmail.com Thu Dec 6 22:12:04 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 6 Dec 2018 16:12:04 -0600 Subject: [tc][all] Train Community Goals In-Reply-To: References: <20181206062035.GB28275@sm-workstation> Message-ID: On 12/6/2018 9:15 AM, Lance Bragstad wrote: > Today in the TC meeting, we discussed the status of the three candidate > goals [0]. Ultimately, we as the TC, are wondering who would be willing > to drive the goal work. > > Having a champion step up early on will help us get answers to questions > about the feasibility of the goal, it's impact across OpenStack, among > other things that will help us, as a community, make an informed decision. > > Remember, championing a goal doesn't need to fall on a single > individual. With proper communication, work can be spread out to lighten > the load. > > What I'd like is to open this up to the community and see who would be > willing to drive the proposed goals. If you have any questions about > championing a goal, please don't hesitate to swing by #openstack-tc, or > you can ping me privately. Regarding the legacy/OSC one, there was a TODO from Berlin for Monty and I think dtantsur (volunteered by Monty) to do some documentation (or something) about what some of this would look like? If that isn't done, it might be good to get done first to help make an informed decision. Otherwise my recollection was the same as Doug's and that we need to be working on closing gaps in OSC regardless of what the underlying code is doing (using the SDK or e.g. python-novaclient). Once that is done we can start working on shifting the underlying stuff from legacy clients to SDK. To make that more digestible, I would also suggest that the goal could aim for some specific release of compatibility as a minimum, e.g. make sure OSC supports all compute API microversions up through Mitaka since lots of clouds are still running Mitaka*. Trying to scope this to "let's get parity up to what the server supported 2 years ago" rather than all of it and fail would be beneficial for projects with bigger gaps. *In fact, according to https://www.openstack.org/analytics Mitaka is the #1 release being used in deployments right now. -- Thanks, Matt From mriedemos at gmail.com Thu Dec 6 22:14:42 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 6 Dec 2018 16:14:42 -0600 Subject: [tc][all] Train Community Goals In-Reply-To: References: <20181206062035.GB28275@sm-workstation> Message-ID: <064cb28c-bf7c-2fe4-eec8-653ef5278979@gmail.com> On 12/6/2018 9:30 AM, Jay Bryant wrote: > With that said, I know that there is a sizable gap between what OSC has > for Cinder and what is available for > python-cinderclient.  If we make this a goal we are doing to need good > organization and documentation of those > gaps and volunteers to help make this change happen. Get someone to start doing this: https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc It's not hard, doesn't take (too) long, and would give you an idea of what your target goal should be. That's why I keep harping on Mitaka as a goal for parity with the compute API. -- Thanks, Matt From lbragstad at gmail.com Thu Dec 6 22:49:30 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Thu, 6 Dec 2018 16:49:30 -0600 Subject: [tc][all] Train Community Goals In-Reply-To: References: <20181206062035.GB28275@sm-workstation> Message-ID: On Thu, Dec 6, 2018 at 11:29 AM Artem Goncharov wrote: > > > On Thu, Dec 6, 2018, 16:19 Lance Bragstad wrote: > >> Today in the TC meeting, we discussed the status of the three candidate >> goals [0]. Ultimately, we as the TC, are wondering who would be willing to >> drive the goal work. >> >> Having a champion step up early on will help us get answers to questions >> about the feasibility of the goal, it's impact across OpenStack, among >> other things that will help us, as a community, make an informed decision. >> >> Remember, championing a goal doesn't need to fall on a single individual. >> With proper communication, work can be spread out to lighten the load. >> >> What I'd like is to open this up to the community and see who would be >> willing to drive the proposed goals. If you have any questions about >> championing a goal, please don't hesitate to swing by #openstack-tc, or you >> can ping me privately. >> > > I was waiting for the start of switching osc "services" to SDK for quite a > while now. I am definitely interested and committed to support the real > coding work here. I would also like to volunteer driving the goal if noone > objects. > Thanks chiming in, Artem! As others in the thread have eluded to, this could very well be a multi-step effort. A big part of that is going to be figuring out where the different projects are in relation to the desired end state. Would you be open to starting some preliminary work to help collect some of that information? Matt's etherpad for the compute API gap analysis with OSC is a good example. > > >> [0] >> http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-12-06-14.00.log.html#l-104 >> >> On Thu, Dec 6, 2018 at 12:20 AM Sean McGinnis >> wrote: >> >>> > > >>> > > In other words, does #1 mean each python-clientlibrary's OSC plugin >>> is >>> > > ready to rock and roll, or we talking about everyone rewriting all >>> client >>> > > interactions in to openstacksdk, and porting existing OSC plugins >>> use that >>> > > different python sdk. >>> > >>> > We talked about those things as separate phases. IIRC, the first phase >>> > was to include ensuring that python-openstackclient has full feature >>> > coverage for non-admin operations for all microversions, using the >>> > existing python-${service}client library or SDK as is appropriate. The >>> > next phase was to ensure that the SDK has full feature coverage for all >>> > microversions. After that point we could update OSC to use the SDK and >>> > start deprecating the service-specific client libraries. >>> > >>> >>> That was my recollection as well. >>> >>> > > In other words, some projects could find it very easy or that they >>> are >>> > > already done, where as others could find themselves with a huge lift >>> that >>> > > is also dependent upon review bandwidth that is outside of their >>> control or >>> > > influence which puts such a goal at risk if we try and push too hard. >>> > > >>> > > -Julia >>> > > >>> >>> I do think there is still a lot of foundation work that needs to be done >>> before >>> we can make it a cycle goal to move more completely to osc. Before we get >>> there, I think we need to see more folks involved on the project to be >>> ready >>> for the increased attention. >>> >>> Right now, I would classify this goal as a "huge lift". >>> >>> Sean >>> >> > Artem > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at bakeyournoodle.com Thu Dec 6 22:50:28 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Fri, 7 Dec 2018 09:50:28 +1100 Subject: [openstack-dev] [puppet] [stable] Deprecation of newton branches In-Reply-To: <3e084433-c965-3881-53ac-761606b5604b@binero.se> References: <2ae10ca2-8c77-ccbc-c009-a22c1d3cfd69@binero.se> <20181205050207.GA19462@thor.bakeyournoodle.com> <3e084433-c965-3881-53ac-761606b5604b@binero.se> Message-ID: <20181206225027.GA32339@thor.bakeyournoodle.com> On Thu, Dec 06, 2018 at 09:40:57AM +0100, Tobias Urdin wrote: > Hello Tony, > Yes that list is correct and complete, please go ahead. Done. I discovered I need to tweak this process which gives the PTLs more control so that's good :) 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 mriedemos at gmail.com Thu Dec 6 22:55:49 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 6 Dec 2018 16:55:49 -0600 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: References: Message-ID: On 12/6/2018 12:10 PM, Melvin Hillsman wrote: > After many discussions it seems SDK validation essentially should be > about confirming cloud state pre/post SDK interaction rather than API > support. An example is that when I use pkgcloud and ask that a VM be > created, does the VM exist, in the way I asked it exist, rather than are > there specific API calls that are being hit along the way to creating my VM. > > I am putting this email out to keep the community informed of what has > been discussed in this space but also and most importantly to get > feedback and support for this work. It would be great to get a set of > official and community SDKs, get them setup with CI testing for > validation (not changing their current CI for unit/functional/acceptance > testing; unless asked to help do this), and connect the results to the > updated project navigator SDK section. A list of scenarios has been > provided as a good starting point for cloud state checks.[2] > > Essentially the proposal is to deploy OpenStack from upstream (devstack > or other), stand up a VM within the cloud, grab all the SDKs, run > acceptance tests, report pass/fail results, update project navigator. Of > course there are details to be worked out and I do have a few questions > that I hope would help get everyone interested on the same page via this > thread. > > 1. Does this make sense? Makes sense to me. Validating the end result of some workflow makes sense to me. One thing I'm wondering about is what you'd start with for basic scenarios. It might make sense to start with some of the very basic kinds of things that openstack interoperability certification requires, like create a VM, attach a volume and port, and then delete it all. Then I guess you'd build from there? > > 2. Would folks be interested in a SDK SIG or does it make more sense to > request an item on the API SIG's agenda? No opinion. > > 3. Bi-weekly discussions a good cadence? Again no opinion but I wanted to say thanks for communicating this for others less involved in this space - it's good to know *something* is going on. > > 4. Who is interested in tackling this together? Again, no real opinion from me. :) Hopefully that other person that I just saw run away over there... -- Thanks, Matt From cboylan at sapwetik.org Thu Dec 6 23:16:01 2018 From: cboylan at sapwetik.org (Clark Boylan) Date: Thu, 06 Dec 2018 15:16:01 -0800 Subject: [infra] Update on test throughput and Zuul backlogs Message-ID: <1544138161.3416170.1601467632.09A4549E@webmail.messagingengine.com> Hello everyone, I was asked to write another one of these in the Nova meeting today so here goes. TripleO has done a good job of reducing resource consumption and now represents about 42% of the total resource usage for the last month down from over 50% when we first started tracking this info. Generating the report requires access to Zuul's scheduler logs so I've pasted a copy at http://paste.openstack.org/show/736797/. There is a change, https://review.openstack.org/#/c/616306/, to report this data via statsd which will allow anyone to generate it off of our graphite server once deployed. Another piece of exciting (good) news is that we've changed the way the Zuul resource allocation scheme prioritizes requests. In the check pipeline a change's relative priority is based on how many changes for that project are already in check and in the gate pipeline it is relative to the number of changes in the shared gate queue. What this means is that less active projects shouldn't need to wait as long for their changes to be tested, but more active projects like tripleo-heat-templates, nova, and neutron may see other changes being tested ahead of their changes. More details on this thread, http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000482.html. One side effect of this change is that our Zuul is now running more jobs per hour than in the past (because it can more quickly churn through changes for "cheap" projects). Unfortunately, this has increased the memory demands on the zuul-executors and we've found that we are using far more swap than we'd like. We'll be applying https://review.openstack.org/#/c/623245/ to reduce the amount of memory required by each job during the course of its run which we hope helps. We've also added one new executor with plans to add a second if this change doesn't help. All that said flaky tests are still an issue. One set of problems seems related to slower than expected/before test nodes in the BHS1 region. We've been debugging these with OVH (thank you amorin!) and think we've managed to make some improvements though so far the problems persist. Current theory is that we are acting as our own noisy neighbors starving the hypervisors of disk IO throughput. In order to test that we've halved the total number of resources we'll use there. More details at https://etherpad.openstack.org/p/bhs1-test-node-slowness including a list of e-r bugs that may be tied to this issue. One thing to keep in mind is that while the test nodes are slower than we'd like, they have also exposed some situations where our software is less efficient than we'd like. At least one bug, https://bugs.launchpad.net/nova/+bug/1807219, has been identified through this. I would encourage people debugging these slow tests to look to see if this exposes a deficiency in our software that can be fixed. CentOS 7.6 released this last Monday. Fallout from that has included needing to update ansible playbooks that ensure the latest version of a centos distro package without setting become: yes. Previously the package was installed at the latest version on our images which ansible could verify without root privileges. Additionally golang is no longer a valid package on the base OS as it was on 7.5 (side note, this doesn't feel incredibly stable for users if anyone from rhel is listening). If your jobs depend on golang on centos and were getting that from the distro packages on 7.5 you'll need to find somewhere else to get golang now. With the distro updates come broken nested virt. Unfortunately nested virt continues to be a back and forth of working today, not working tomorrow. It seem that our test node kernels play a big impact on that then a few days later the various clouds apply new hypervisor kernel updates and things work again. If your jobs attempt to use nested virt and you've seen odd behavior from them (like reboots) recently this may be the cause. These are the big issues that affect large numbers of projects (or even all of them), but there are still many project specific problems floating around as well. Unfortunately I haven't had much time to help dig into those recently (see broader issues above), but I think it would be helpful if projects can do some of that digging themselves. Also, a friendly reminder that we try to provide in cloud region mirrors and caches for commonly used resources like distro packages, pypi packages, dockerhub images, and so on. If your jobs aren't using these and you find they fail occasionally due to the Internet being flaky we'll be happy to help you update the jobs to use the in region resources instead. We'll keep pushing to fix the broader issues and are more than happy to help debug failures you hit within your projects as well. Hopefully this was helpful despite its length. Clark From mrhillsman at gmail.com Thu Dec 6 23:39:04 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Thu, 6 Dec 2018 17:39:04 -0600 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: References: Message-ID: On Thu, Dec 6, 2018 at 4:56 PM Matt Riedemann wrote: > On 12/6/2018 12:10 PM, Melvin Hillsman wrote: > > After many discussions it seems SDK validation essentially should be > > about confirming cloud state pre/post SDK interaction rather than API > > support. An example is that when I use pkgcloud and ask that a VM be > > created, does the VM exist, in the way I asked it exist, rather than are > > there specific API calls that are being hit along the way to creating my > VM. > > > > I am putting this email out to keep the community informed of what has > > been discussed in this space but also and most importantly to get > > feedback and support for this work. It would be great to get a set of > > official and community SDKs, get them setup with CI testing for > > validation (not changing their current CI for unit/functional/acceptance > > testing; unless asked to help do this), and connect the results to the > > updated project navigator SDK section. A list of scenarios has been > > provided as a good starting point for cloud state checks.[2] > > > > Essentially the proposal is to deploy OpenStack from upstream (devstack > > or other), stand up a VM within the cloud, grab all the SDKs, run > > acceptance tests, report pass/fail results, update project navigator. Of > > course there are details to be worked out and I do have a few questions > > that I hope would help get everyone interested on the same page via this > > thread. > > > > 1. Does this make sense? > > Makes sense to me. Validating the end result of some workflow makes > sense to me. One thing I'm wondering about is what you'd start with for > basic scenarios. It might make sense to start with some of the very > basic kinds of things that openstack interoperability certification > requires, like create a VM, attach a volume and port, and then delete it > all. Then I guess you'd build from there? > Yes sir the scenarios you mention are exactly what we have in the spreadsheet and want to add more. I did not think about it but maybe this ethercalc is better for everyone to collaborate on - https://ethercalc.org/q4nklltf21nz > > > > > 2. Would folks be interested in a SDK SIG or does it make more sense to > > request an item on the API SIG's agenda? > > No opinion. > > > > > 3. Bi-weekly discussions a good cadence? > > Again no opinion but I wanted to say thanks for communicating this for > others less involved in this space - it's good to know *something* is > going on. > > > > > 4. Who is interested in tackling this together? > > Again, no real opinion from me. :) Hopefully that other person that I > just saw run away over there... > > -- > > Thanks, > > Matt > > -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrhillsman at gmail.com Thu Dec 6 23:46:36 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Thu, 6 Dec 2018 17:46:36 -0600 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: References: Message-ID: On Thu, Dec 6, 2018 at 12:30 PM Artem Goncharov wrote: > > > On Thu, 6 Dec 2018, 19:12 Melvin Hillsman, wrote: > >> Hi everyone, >> >> We have spent some time working to get an idea of what official SDKs >> would look like. We had some sessions during the Berlin summit[0][1] and >> there was a lot of great feedback. >> >> Currently the following SDKs are generally considered usable for their >> respective language; there are others of course: >> >> openstacksdk (Python) >> gophercloud (Go) >> pkgcloud (JavaScript) >> openstack4j (Java) >> rust-openstack (Rust) >> fog-openstack (Ruby) >> php-opencloud (PHP) >> >> After many discussions it seems SDK validation essentially should be >> about confirming cloud state pre/post SDK interaction rather than API >> support. An example is that when I use pkgcloud and ask that a VM be >> created, does the VM exist, in the way I asked it exist, rather than are >> there specific API calls that are being hit along the way to creating my VM. >> >> I am putting this email out to keep the community informed of what has >> been discussed in this space but also and most importantly to get feedback >> and support for this work. It would be great to get a set of official and >> community SDKs, get them setup with CI testing for validation (not changing >> their current CI for unit/functional/acceptance testing; unless asked to >> help do this), and connect the results to the updated project navigator SDK >> section. A list of scenarios has been provided as a good starting point for >> cloud state checks.[2] >> >> Essentially the proposal is to deploy OpenStack from upstream (devstack >> or other), stand up a VM within the cloud, grab all the SDKs, run >> acceptance tests, report pass/fail results, update project navigator. Of >> course there are details to be worked out and I do have a few questions >> that I hope would help get everyone interested on the same page via this >> thread. >> >> >> 1. Does this make sense? >> >> > As a representative of a public cloud operator I say yes. It definitely > makes sense to let users know, which SDKs are certified to work to have > understanding what they can use. However then comes the question, that each > public operator has own "tricks" and possibly even extension services, > which make SDK behave not as expected. I do really see a need to provide a > regular way in each of those SDKs to add and (I really don't want this, but > need unfortunately) sometimes override services implementation if those are > changed in some way. > So the certification make sense, but the CI question probably goes in the > direction of OpenLab > Yes this is definitely something to consider; public cloud tricks and extensions. An idea that was floated is to have an upstream cloud to run against that passes all interop powered programs to run the SDKs against. Even though SDKs provide more coverage an SDK that works against a service that is certified should work in any cloud that is certified? > >> 1. Would folks be interested in a SDK SIG or does it make more sense >> to request an item on the API SIG's agenda? >> >> Both has pro and cons, but I am neutral here > > Same, just wanted to get it out there and hopefully get API SIG members feedback so as not to hijack any of their agendas or creep on their scope without consent. > > >> 1. Bi-weekly discussions a good cadence? >> >> Yes. The regular communication is a requirement. > > > >> 1. Who is interested in tackling this together? >> >> > I do, but not alone > Haha, agreed, but we definitely should work on it and be consistent even if the initial set of folks is small. We have a large community to lean on and should rather than simply going at it alone. > > >> >> >> [0] https://etherpad.openstack.org/p/BER-better-expose-what-we-produce >> [1] https://etherpad.openstack.org/p/BER-sdk-certification >> [2] >> https://docs.google.com/spreadsheets/d/1cdzFeV5I4Wk9FK57yqQmp5JJdGfKzEOdB3Vtt9vnVJM >> >> >> -- >> Kind regards, >> >> Melvin Hillsman >> mrhillsman at gmail.com >> mobile: (832) 264-2646 >> > > Regards, > Artem Goncharov > gtema > OpenTelekomCloud > >> -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Thu Dec 6 23:50:30 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 6 Dec 2018 17:50:30 -0600 Subject: [infra] Update on test throughput and Zuul backlogs In-Reply-To: <1544138161.3416170.1601467632.09A4549E@webmail.messagingengine.com> References: <1544138161.3416170.1601467632.09A4549E@webmail.messagingengine.com> Message-ID: On 12/6/2018 5:16 PM, Clark Boylan wrote: > I was asked to write another one of these in the Nova meeting today so here goes. Thanks Clark, this is really helpful. > > One thing to keep in mind is that while the test nodes are slower than we'd like, they have also exposed some situations where our software is less efficient than we'd like. At least one bug,https://bugs.launchpad.net/nova/+bug/1807219, has been identified through this. I would encourage people debugging these slow tests to look to see if this exposes a deficiency in our software that can be fixed. That was split off from this: https://bugs.launchpad.net/nova/+bug/1807044 But yeah a couple of issues Dan and I are digging into. Another thing I noticed in one of these nova-api start timeout failures in ovh-bhs1 was uwsgi seems to just stall for 26 seconds here: http://logs.openstack.org/01/619701/5/gate/tempest-slow/2bb461b/controller/logs/screen-n-api.txt.gz#_Dec_05_20_13_23_060958 I pushed a patch to enable uwsgi debug logging: https://review.openstack.org/#/c/623265/ But of course I didn't (1) get a recreate or (2) seem to see any additional debug logging from uwsgi. If someone else knows how to enable that please let me know. > > These are the big issues that affect large numbers of projects (or even all of them), but there are still many project specific problems floating around as well. Unfortunately I haven't had much time to help dig into those recently (see broader issues above), but I think it would be helpful if projects can do some of that digging themselves. Also, a friendly reminder that we try to provide in cloud region mirrors and caches for commonly used resources like distro packages, pypi packages, dockerhub images, and so on. If your jobs aren't using these and you find they fail occasionally due to the Internet being flaky we'll be happy to help you update the jobs to use the in region resources instead. I'm not sure if this query is valid anymore: http://status.openstack.org/elastic-recheck/#1783405 If it is, then we still have some tempest tests that aren't marked as slow but are contributing to job timeouts outside the tempest-slow job. I know the last time this came up, the QA team had a report of the slowest non-slow tests - can we get another one of those now? Another thing is, are there particular voting jobs that have a failure rate over 50% and are resetting the gate? If we do, we should consider making them non-voting while project teams work on fixing the issues. Because I've had approved patches for days now taking 13+ hours just to fail, which is pretty unsustainable. > > We'll keep pushing to fix the broader issues and are more than happy to help debug failures you hit within your projects as well. > > Hopefully this was helpful despite its length. Again, thank you Clark for taking the time to write up this summary - it's extremely useful. -- Thanks, Matt From melwittt at gmail.com Fri Dec 7 00:01:28 2018 From: melwittt at gmail.com (melanie witt) Date: Thu, 6 Dec 2018 16:01:28 -0800 Subject: [infra] Update on test throughput and Zuul backlogs In-Reply-To: <1544138161.3416170.1601467632.09A4549E@webmail.messagingengine.com> References: <1544138161.3416170.1601467632.09A4549E@webmail.messagingengine.com> Message-ID: On Thu, 06 Dec 2018 15:16:01 -0800, Clark Boylan wrote: [snip] > One thing to keep in mind is that while the test nodes are slower than we'd like, they have also exposed some situations where our software is less efficient than we'd like. At least one bug, https://bugs.launchpad.net/nova/+bug/1807219, has been identified through this. I would encourage people debugging these slow tests to look to see if this exposes a deficiency in our software that can be fixed. [snip] > These are the big issues that affect large numbers of projects (or even all of them), but there are still many project specific problems floating around as well. Unfortunately I haven't had much time to help dig into those recently (see broader issues above), but I think it would be helpful if projects can do some of that digging themselves. [snip] FYI for interested people, we are working on some nova-specific problems in the following patches/series: https://review.openstack.org/623282 https://review.openstack.org/623246 https://review.openstack.org/623265 > We'll keep pushing to fix the broader issues and are more than happy to help debug failures you hit within your projects as well. Thanks for the excellent write-up. It's a nice window into what's going on in the gate, the work the infra team is doing, and letting us know how we can help. Best, -melanie From melwittt at gmail.com Fri Dec 7 00:04:44 2018 From: melwittt at gmail.com (melanie witt) Date: Thu, 6 Dec 2018 16:04:44 -0800 Subject: [infra] Update on test throughput and Zuul backlogs In-Reply-To: References: <1544138161.3416170.1601467632.09A4549E@webmail.messagingengine.com> Message-ID: On Thu, 6 Dec 2018 16:01:28 -0800, Melanie Witt wrote: > On Thu, 06 Dec 2018 15:16:01 -0800, Clark Boylan wrote: > > [snip] > >> One thing to keep in mind is that while the test nodes are slower than we'd like, they have also exposed some situations where our software is less efficient than we'd like. At least one bug, https://bugs.launchpad.net/nova/+bug/1807219, has been identified through this. I would encourage people debugging these slow tests to look to see if this exposes a deficiency in our software that can be fixed. > > [snip] > >> These are the big issues that affect large numbers of projects (or even all of them), but there are still many project specific problems floating around as well. Unfortunately I haven't had much time to help dig into those recently (see broader issues above), but I think it would be helpful if projects can do some of that digging themselves. > > [snip] > > FYI for interested people, we are working on some nova-specific problems > in the following patches/series: > > https://review.openstack.org/623282 > https://review.openstack.org/623246 > https://review.openstack.org/623265 > >> We'll keep pushing to fix the broader issues and are more than happy to help debug failures you hit within your projects as well. > > Thanks for the excellent write-up. It's a nice window into what's going > on in the gate, the work the infra team is doing, and letting us know > how we can help. Bah, didn't see Matt's reply by the time I hit send. Apologies for the [less detailed] replication. -melanie From mrhillsman at gmail.com Fri Dec 7 00:09:47 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Thu, 6 Dec 2018 18:09:47 -0600 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: References: Message-ID: On Thu, Dec 6, 2018 at 12:36 PM Michael McCune wrote: > thanks for bringing this up Melvin. > > On Thu, Dec 6, 2018 at 1:13 PM Melvin Hillsman > wrote: > > Essentially the proposal is to deploy OpenStack from upstream (devstack > or other), stand up a VM within the cloud, grab all the SDKs, run > acceptance tests, report pass/fail results, update project navigator. Of > course there are details to be worked out and I do have a few questions > that I hope would help get everyone interested on the same page via this > thread. > > > > Does this make sense? > > > > makes sense to me, and sounds like a good idea provided we have the > people ready to maintain the testing infra and patches for this (which > i assume we do). > I think we have a good base to build on, should get started, keep everyone informed, and we can continue to work to recruit more interested folks. I think if we work especially hard to streamline the entire process so it is as automated as possible. > > > Would folks be interested in a SDK SIG or does it make more sense to > request an item on the API SIG's agenda? > > > > i don't have a strong opinion either way, but i will point out that > the API-SIG has migrated to office hours instead of a weekly meeting. > if you expect that the proposed SDK work will have a strong cadence > then it might make more practical sense to create a new SIG, or really > even a working group until the objective of the testing is reached. > > the only reason i bring up working groups here is that there seems > like a clearly stated goal for the initial part of this work. namely > creating the testing and validation infrastructure described. it might > make sense to form a working group until the initial work is complete > and then move continued discussion under the API-SIG for organization. > Working group actually makes a lot more sense, thanks for the suggestion, I agree with you; anyone else? > > > Bi-weekly discussions a good cadence? > > > > that sounds reasonable for a start, but i don't have a strong opinion here. > > > Who is interested in tackling this together? > > > > if you need any help from API-SIG, please reach out. i would be > willing to help with administrative/governance type stuff. > > peace o/ > -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From shiriul.lol at gmail.com Fri Dec 7 01:21:45 2018 From: shiriul.lol at gmail.com (SIRI KIM) Date: Fri, 7 Dec 2018 10:21:45 +0900 Subject: [loci][openstack-helm] How to add some agent to loci images In-Reply-To: <2ED125CF-8AA3-4D81-8C0F-FDF8ED1EF2F0@openstack.org> References: <2ED125CF-8AA3-4D81-8C0F-FDF8ED1EF2F0@openstack.org> Message-ID: I have added [openstack-helm] since this might be cross-project issue. our objetive: add neutron-lbaas & neutron-fwaas chart to openstack-helm upstream. problem: we need this loci image to push lbaas and fwaas chart into upstream repo. In order to pass osh gating, we need to have neutron-lbaas & neutron-fwaas agent image available for openstack-helm project. My question was not about how to build loci image locally, but what would be the best way to make these two images (lbaas and fwaas) available for openstack-helm project. Please kindly guide me here. :) thanks PS. This link is added openstack-helm neutron-lbaas. https://review.openstack.org/#/c/609299/ 2018년 12월 7일 (금) 오전 4:54, Chris Hoge 님이 작성: > Except in a few instances, Loci aims to generically build OpenStack > service images and has pretty robust scripts that will allow you > to build the containers without modification of the project. In the > instance of neutron-fwaas, you can easily build the service following the > instructions in README.md[1] in the Loci repository. Just set > `PROJECT=neutron-fwaas` and tag appripriately. The major caveat is the > build for that project is not gate tested (although I've managed to > complete a build of it in my own environment). > > You could do the same thing similarly for neutron-lbaas, but please be > aware that for a number of reasons neutron-lbaas project has been > deprecated[2], and you should instead prefer to use Octavia as the > official replacement for it. > > Thanks, > Chris > > [1] http://git.openstack.org/cgit/openstack/loci/tree/README.md > [2] https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation > > > On Dec 5, 2018, at 5:30 PM, SIRI KIM wrote: > > > > Hello, Jean. > > > > I tried to add lbaas-agent and fwaas-agent to official loci neutron > image. > > To pass openstack-helm gate test, I need lbaas-agent and fwaas-agent. > > > > I found your openstack source repository is > > repository: 172.17.0.1:5000/loci/requirements > > > > Please let me know I can I add lbaas-agent and fwaas-agent to official > loci neutron image. > > > > Thanks, > > Siri > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at bakeyournoodle.com Fri Dec 7 03:16:55 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Fri, 7 Dec 2018 14:16:55 +1100 Subject: [tc] Technical Committee status update for 6 December In-Reply-To: References: Message-ID: <20181207031655.GB32339@thor.bakeyournoodle.com> On Thu, Dec 06, 2018 at 04:00:19PM -0500, Doug Hellmann wrote: > > This is the (alegedly) weekly summary of work being done by the > Technical Committee members. The full list of active items is managed in > the wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker > > We also track TC objectives for the cycle using StoryBoard at: > https://storyboard.openstack.org/#!/project/923 > > == Recent Activity == > > It has been 4 weeks since the last update email, in part due to the > Summit, then a holiday, then my absense due to illness. > > Project updates: > > * Add tenks under Ironic: https://review.openstack.org/#/c/600411/ > * Add os_placement role to OpenStack Ansible: https://review.openstack.org/#/c/615187/ > * Retired openstack-ansible-os_monasca-ui https://review.openstack.org/#/c/617322/ > * Chris Hoge was made the new Loci team PTL https://review.openstack.org/#/c/620370/ > > Other updates: > > * Thierry has been working on a series of changes on behalf of the > release management team to record the release management style used > for each deliverable listed in the governance > repository. https://review.openstack.org/#/c/613268/ > * Zane updated our guidelines for new projects to clarify the scoping > requirements: https://review.openstack.org/#/c/614799/ > * Zane also added a Vision for OpenStack Clouds document, describing > what we see as the scope of OpenStack overall: > https://review.openstack.org/#/c/592205/ > * I copied some code we had in a couple of other places into the > governance repository to make it easier for the release, goal, and > election tools to consume the governance data using the new > openstack-governance library from > PyPI. https://review.openstack.org/#/c/614599/ I took a quick stab at this, and I think we'll need a feature in that library to be able to use it in the election repo. So I'll start with that. Patches incoming 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 dangtrinhnt at gmail.com Fri Dec 7 07:30:40 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Fri, 7 Dec 2018 16:30:40 +0900 Subject: [Searchlight][Zuul] tox failed tests at zuul check only In-Reply-To: <1543855087.1459125.1597252016.5DBF506E@webmail.messagingengine.com> References: <1543855087.1459125.1597252016.5DBF506E@webmail.messagingengine.com> Message-ID: Hi Clark, Outputting the exec logs does help. And, I found the problem for the functional tests to fail, it because ES cannot be started because of the way the functional sets up the new version of ES server (5.x). I'm working on updating it. Many thanks, On Tue, Dec 4, 2018 at 1:39 AM Clark Boylan wrote: > On Mon, Dec 3, 2018, at 7:28 AM, Trinh Nguyen wrote: > > Hello, > > > > Currently, [1] fails tox py27 tests on Zuul check for just updating the > log > > text. The tests are successful at local dev env. Just wondering there is > > any new change at Zuul CI? > > > > [1] https://review.openstack.org/#/c/619162/ > > > > Reading the exceptions [2] and the test setup code [3] it appears that > elasticsearch isn't responding on its http port and is thus treated as > having not started. With the info we currently have it is hard to say why. > Instead of redirecting exec logs to /dev/null [4] maybe we can capture that > data? Also probably worth grabbing the elasticsearch daemon log as well. > > Without that information it is hard to say why this happened. I am not > aware of any changes in the CI system that would cause this, but we do > rebuild our test node images daily. > > [2] > http://logs.openstack.org/62/619162/5/check/openstack-tox-py27/9ce318d/job-output.txt.gz#_2018-11-27_05_32_48_854289 > [3] > https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/functional/__init__.py#n868 > [4] > https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/functional/__init__.py#n851 > > Clark > > -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdecacqu at redhat.com Fri Dec 7 08:42:42 2018 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Fri, 07 Dec 2018 08:42:42 +0000 Subject: [infra] Update on test throughput and Zuul backlogs In-Reply-To: <1544138161.3416170.1601467632.09A4549E@webmail.messagingengine.com> References: <1544138161.3416170.1601467632.09A4549E@webmail.messagingengine.com> Message-ID: <1544171839.tqkuyzpbd8.tristanC@fedora> On December 6, 2018 11:16 pm, Clark Boylan wrote: > Additionally golang is no longer a valid package on the base OS as it was on 7.5. > According to the release note, golang is now shipped as part of the SCL. See this how-to for the install instructions: http://www.karan.org/blog/2018/12/06/using-go-toolset-on-centos-linux-7-x86_64/ Regards, -Tristan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From balazs.gibizer at ericsson.com Fri Dec 7 08:48:44 2018 From: balazs.gibizer at ericsson.com (=?iso-8859-1?Q?Bal=E1zs_Gibizer?=) Date: Fri, 7 Dec 2018 08:48:44 +0000 Subject: [nova] What to do with the legacy notification interface? In-Reply-To: <1466d5db-316f-34a3-9f08-a5931ab6ce86@gmail.com> References: <1544114506.15837.0@smtp.office365.com> <1466d5db-316f-34a3-9f08-a5931ab6ce86@gmail.com> Message-ID: <1544172519.19737.0@smtp.office365.com> On Thu, Dec 6, 2018 at 6:35 PM, Matt Riedemann wrote: > On 12/6/2018 10:41 AM, Balázs Gibizer wrote: >> Hi, >> >> Last decision from the Denver PTG [1] was to >> * finish the remaining transformations [2] >> * change the default value of notification_format conf option from >> 'both' to 'versioned' >> * communicate that the legacy notification interface has been >> deprecated, unsupported but the code will not be removed >> >> Since the PTG the last two transformation patches [2] has been >> approved >> and the deprecation patch has been prepared [3]. However recently we >> got a bug report [4] where the performance impact of emiting both >> legacy and versioned notification caused unnecessary load on the >> message bus. (Btw this performance impact was raised in the original >> spec [5]). The original reason we emited both type of notifications >> was >> to keep backward compatibility with consumers only understanding >> legacy >> notifications. It worked so well that most of the consumers still >> depend on the legacy notifications (detailed status is in [1]). >> >> I see three options to move forward: >> >> A) Do nothing. By default, emit both type of notifications. This >> means >> that deployers seeing the performance impact of [4] needs to >> reconfigure nova. Also this is agains our decision to move away from >> supporting legacy notifications. >> >> B) Follow the plan from the PTG and change the default value of the >> config to emit only versioned notifications. This solves the >> immediate >> effect of the bug [4]. This is following our original plan. BUT this >> is >> backward incompatible change which in the current situation means >> most >> of the deployments (e.g. those, deploying notification consumer >> modules >> like ceilometer) need to change this config to 'unversioned' or >> 'both'. >> >> There was discussion about helping out notification consumers to >> convert their code using the new versioned interface but I have no >> spare time at the moment and I failed to drum up resources internally >> for this work. Also I don't see others volunteering for such work. >> >> C) Change the default to 'legacy'. This solves the bug [4]. BUT >> sends a >> really mixed message. As our original goal was to stop supporting the >> legacy notification interface of nova. >> Matt stated on IRC recently, there is no real bug inflow for the >> legacy >> code. Also looking at changes in the code I see that last cycle we >> had >> couple of blueprints extending the new versioned notifications with >> extra fields but that inflow stopped in this cycle too. So we most >> probably can keep the legacy code in place and supported forever >> without too much pain and too much divergence from the versioned >> interface. >> >> -- >> >> Personally, I spent enough time implementing and reviewing the >> versioned interface that I'm biased towards option B). But I do >> understand that our original goals setting in 2015 was made in such >> environment that changed significantly in the past cycles. So I can >> accept option C) as well if we can agree. >> >> Cheers, >> gibi >> >> [1]https://etherpad.openstack.org/p/nova-ptg-stein L765 >> [2] >> https://review.openstack.org/#/q/topic:bp/versioned-notification-transformation-stein+status:open >> [3]https://review.openstack.org/#/c/603079/ >> [4]https://bugs.launchpad.net/nova/+bug/1805659 >> [5] >> https://review.openstack.org/#/c/224755/11/specs/mitaka/approved/versioned-notification-api.rst at 687 > > In skimming the spec again: > > https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/versioned-notification-transformation-newton.html > > I get that legacy unversioned notifications in nova were kind of a > mess and changing them without a version was icky even though they > are internal to a deployment. Moving to using versioned notifications > with well-defined objects, docs samples, all of that is very nice for > nova *developers*, but what I've been struggling with is what benefit > do the versioned notifications bring to nova *consumers*, besides we > say you can only add new notifications if they are versioned. Funnily, orignially I only wanted to add one new (legacy) notification (service.update) to nova back in 2015 and that requirement discussion led to the birth of the versioned interface. But besides that, I think, discovering what notifications exists and what data is provided in any given notifications are someting that is lot easier now with the versioned interface for (new) consumers that don't want to read nova code. They just open the docs and the samples. Sure this is not a good reason for a consumer that did the legwork already and built something top of the legacy interface. Are there new notification consumers apparing around nova? I don't think so. I guess we were naive enough three years ago to think that there will be new notification consumers to justify this work. > > In other words, what motivation does a project that is currently > consuming unversioned legacy notifications have to put the work in to > switch to versioned notifications? The spec doesn't really get into > that in much detail. > > I do remember an older thread with gordc where he was asking about > schema payloads and such so a consumer could say implement processing > a notification at version 1.0, but then if it gets a version 1.4 > payload it could figure out how to backlevel the payload to the 1.0 > version it understands - sort of like what we've talked about doing > with os-vif between nova and neutron (again, for years). But that > thread kind of died out from what I remember. But that seems like a > nice benefit for upgrades, but I also figure it's probably very low > priority on everyone's wishlist. I agree. I don't see any benefit for well establised legacy notification consumer besides the discoverability of change in the payload schema. But that schema also does not change too much. Cheers, gibi > > Another way I've thought about the deprecation lately is that if we > (nova devs) did the work to migrate ceilometer, then we'd have one > major consumer and we could then deprecate the legacy notifications > and change the default to 'versioned'. But like you said, no one is > coming out of the woodwork to do that work. > > Anyway, I'm just having a hard time with the fact so much work has > been put into this over the last few years that now everything is > transformed but no one is using it, and I don't see many compelling > reasons why a project would migrate, especially since the projects > that are consuming nova's notifications are mostly working with a > skeleton crew of maintainers. > > I'd really like some input from other project developers and > operators here. > > -- > > Thanks, > > Matt > From dtantsur at redhat.com Fri Dec 7 12:10:39 2018 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Fri, 7 Dec 2018 13:10:39 +0100 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: References: Message-ID: On 12/7/18 1:09 AM, Melvin Hillsman wrote: > > > On Thu, Dec 6, 2018 at 12:36 PM Michael McCune > wrote: > > thanks for bringing this up Melvin. > > On Thu, Dec 6, 2018 at 1:13 PM Melvin Hillsman > wrote: > > Essentially the proposal is to deploy OpenStack from upstream (devstack > or other), stand up a VM within the cloud, grab all the SDKs, run acceptance > tests, report pass/fail results, update project navigator. Of course there > are details to be worked out and I do have a few questions that I hope would > help get everyone interested on the same page via this thread. > > > > Does this make sense? > > > > makes sense to me, and sounds like a good idea provided we have the > people ready to maintain the testing infra and patches for this (which > i assume we do). > > > I think we have a good base to build on, should get started, keep everyone > informed, and we can continue to work to recruit more interested folks. I think > if we work especially hard to streamline the entire process so it is as > automated as possible. > > > > Would folks be interested in a SDK SIG or does it make more sense to > request an item on the API SIG's agenda? > > > > i don't have a strong opinion either way, but i will point out that > the API-SIG has migrated to office hours instead of a weekly meeting. > if you expect that the proposed SDK work will have a strong cadence > then it might make more practical sense to create a new SIG, or really > even a working group until the objective of the testing is reached. > > the only reason i bring up working groups here is that there seems > like a clearly stated goal for the initial part of this work. namely > creating the testing and validation infrastructure described. it might > make sense to form a working group until the initial work is complete > and then move continued discussion under the API-SIG for organization. > > > Working group actually makes a lot more sense, thanks for the suggestion, I > agree with you; anyone else? I disagree :) I think back around Dublin we agreed that SDKs are in scope of API SIG, since they help people consume our API. And given that the API SIG is barely alive, it may be give it a chance to become active again. > > > > Bi-weekly discussions a good cadence? > > > > that sounds reasonable for a start, but i don't have a strong opinion here. > > > Who is interested in tackling this together? > > > > if you need any help from API-SIG, please reach out. i would be > willing to help with administrative/governance type stuff. As an author of a young SDK, I'm certainly in, be it within or outside of the API SIG. Dmitry > > > peace o/ > > > > -- > Kind regards, > > Melvin Hillsman > mrhillsman at gmail.com > mobile: (832) 264-2646 From cdent+os at anticdent.org Fri Dec 7 12:58:46 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Fri, 7 Dec 2018 12:58:46 +0000 (GMT) Subject: [placement] update 18-49 Message-ID: HTML: https://anticdent.org/placement-update-18-49.html This will be the last placement update of the year. I'll be travelling next Friday and after that we'll be deep in the December lull. I'll catch us up next on January 4th. # Most Important As last week, 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 * The perfload jobs which used to run in the nova-next job now has its [own job](https://review.openstack.org/#/c/619248/), running on each change. This may be of general interest because it runs placement "live" but without devstack. Results in job runs that are less than 4 minutes. * We've decided to go ahead with the simple os-resource-classes idea, so a repo is [being created](https://review.openstack.org/#/c/621666/). # Slow Reviews (Reviews which need additional attention because they have unresolved questions.) * Set root_provider_id in the database This has some indecision because it does a data migration within schema migrations. For this particular case this is safe and quick, but there's concern that it softens a potentially useful boundary between schema and data migrations. # Bugs * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 17. -2. * [In progress placement bugs](https://goo.gl/vzGGDQ) 13. -1 ## Interesting Bugs (Bugs that are sneaky and interesting and need someone to pick them up.) * placement/objects/resource_provider.py missing test coverage for several methods This is likely the result of the extraction. Tests in nova's test_servers and friends probably covered some of this stuff, but now we need placement-specific tests. * maximum recursion possible while setting aggregates in placement This can only happen under very heavy load with a very low number of placement processes, but the code that fails should probably change anyway: it's a potentially infinite loop with no safety breakout. # Specs Spec freeze is milestone 2, the week of January 7th. There was going to be a spec review sprint next week but it was agreed that people are already sufficiently busy. This will certainly mean that some of these specs do not get accepted for this cycle. 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 continues 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 The [extraction etherpad](https://etherpad.openstack.org/p/placement-extract-stein-4) is starting to contain more strikethrough text than not. Progress is being made. The main tasks are the reshaper work mentioned above and the work to get deployment tools operating with an 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/) 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 that use [extracted placement](https://review.openstack.org/#/c/617941/) are working but not yet merged. A child of that patch [removes the placement code](https://review.openstack.org/#/c/618215/). Further work will be required to tune up the various pieces of documentation in nova that reference placement. # Other There are currently only 8 [open changes](https://review.openstack.org/#/q/project:openstack/placement+status:open) in placement itself. Most of the time critical work is happening elsewhere (notably the deployment tool changes listed above). Of those placement changes the [database-related](https://review.openstack.org/#/q/owner:nakamura.tetsuro%2540lab.ntt.co.jp+status:open+project:openstack/placement) ones from Tetsuro are the most important. Outside of placement: * 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) * WIP: add Placement aggregates tests (in tempest) # End In case it hasn't been clear: things being listed here is an explicit invitation (even plea) for _you_ to help out by reviewing or fixing. Thank you. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From thierry at openstack.org Fri Dec 7 13:35:56 2018 From: thierry at openstack.org (Thierry Carrez) Date: Fri, 7 Dec 2018 14:35:56 +0100 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: References: Message-ID: <380a044d-8185-a312-2f7e-40bd663cf49c@openstack.org> Melvin Hillsman wrote: > We have spent some time working to get an idea of what official SDKs > would look like. We had some sessions during the Berlin summit[0][1] and > there was a lot of great feedback. > > Currently the following SDKs are generally considered usable for their > respective language; there are others of course: > > openstacksdk (Python) > gophercloud (Go) > pkgcloud (JavaScript) > openstack4j (Java) > rust-openstack (Rust) > fog-openstack (Ruby) > php-opencloud (PHP) As a sidenote, we also want to show those SDKs on openstack.org/software alongside openstacksdk, so having validation that they actually do what they are supposed to do is really critical. > After many discussions it seems SDK validation essentially should be > about confirming cloud state pre/post SDK interaction rather than API > support. An example is that when I use pkgcloud and ask that a VM be > created, does the VM exist, in the way I asked it exist, rather than are > there specific API calls that are being hit along the way to creating my VM. > > I am putting this email out to keep the community informed of what has > been discussed in this space but also and most importantly to get > feedback and support for this work. It would be great to get a set of > official and community SDKs, get them setup with CI testing for > validation (not changing their current CI for unit/functional/acceptance > testing; unless asked to help do this), and connect the results to the > updated project navigator SDK section. A list of scenarios has been > provided as a good starting point for cloud state checks.[2] > > Essentially the proposal is to deploy OpenStack from upstream (devstack > or other), stand up a VM within the cloud, grab all the SDKs, run > acceptance tests, report pass/fail results, update project navigator. Of > course there are details to be worked out and I do have a few questions > that I hope would help get everyone interested on the same page via this > thread. > > 1. Does this make sense? Yes. > 2. Would folks be interested in a SDK SIG or does it make more sense to > request an item on the API SIG's agenda? As others mentioned, there is lots of overlap between API SIG and SDK work, but that would be a stretch of the API SIG mission, which they might or might not be interested in doing. If they'd rather have the groups separated, I still think the SIG group format applies better than a "workgroup" as caring about SDKs and their quality will be an ongoing effort, it's not just about setting up tests and then forgetting about them. So I'd encourage the formation of a SDK SIG if that work can't be included in the existing API SIG. > 3. Bi-weekly discussions a good cadence? No strong opinion, but bi-weekly sounds good. > 4. Who is interested in tackling this together? As mentioned above, I'll be involved in the promotion of the result of that effort, by making sure the openstack.org/software pages evolve a way to list "verified" SDKs alongside the one that is produced locally. -- Thierry Carrez (ttx) From msm at redhat.com Fri Dec 7 14:52:49 2018 From: msm at redhat.com (Michael McCune) Date: Fri, 7 Dec 2018 09:52:49 -0500 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: <380a044d-8185-a312-2f7e-40bd663cf49c@openstack.org> References: <380a044d-8185-a312-2f7e-40bd663cf49c@openstack.org> Message-ID: On Fri, Dec 7, 2018 at 8:40 AM Thierry Carrez wrote: > > Melvin Hillsman wrote: > > 2. Would folks be interested in a SDK SIG or does it make more sense to > > request an item on the API SIG's agenda? > > As others mentioned, there is lots of overlap between API SIG and SDK > work, but that would be a stretch of the API SIG mission, which they > might or might not be interested in doing. > i don't necessarily have an objection to modifying the API SIG mission to be more inclusive of the SDK work. i think this is something we had actually hoped for after discussions a few cycles ago about how we could be welcoming to the operators and users with SDK specific issues. i think for this expansion/inclusion to be optimally successful we will need to consider re-starting a regular meeting and also getting some new blood on the API SIG core team. we are currently at 3 cores (Ed Leafe, Dmitry Tantsur, and myself) and the reasoning for our meetings evolving into office hours was that it was just the three of us (and Chris Dent usually) coming to those meetings. ideally with new work being done around the SDKs these meetings would become more active again. peace o/ From paul.bourke at oracle.com Fri Dec 7 14:56:28 2018 From: paul.bourke at oracle.com (Paul Bourke) Date: Fri, 7 Dec 2018 14:56:28 +0000 Subject: [octavia] Routing between lb-mgmt-net and amphora In-Reply-To: References: Message-ID: <6a861285-b25b-87d6-15fe-a48cdf0f08da@oracle.com> Ok, so in my case, I've booted a test cirros VM on lb-mgmt-net, it gets assigned an IP of 172.18.2.126. The goal is to be able to ping this IP directly from the control plane. I create a port in neutron: http://paste.openstack.org/show/736821/ I log onto the network node that's hosting the dhcp namespace for this node: http://paste.openstack.org/show/736823/ I then run the following command lifted from devstack, with my port info subbed in: # ovs-vsctl -- --may-exist add-port ${OVS_BRIDGE:-br-int} o-hm0 -- set Interface o-hm0 type=internal -- set Interface o-hm0 external-ids:iface-status=active -- set Interface o-hm0 external-ids:attached-mac=$MGMT_PORT_MAC -- set Interface o-hm0 external-ids:iface-id=$MGMT_PORT_ID -- set Interface o-hm0 external-ids:skip_cleanup=true Here's the output of 'ovs-vsctl show' at this point: http://paste.openstack.org/show/736826/ Note that the tap device for the VM (tap6440048f-d2) has tag 3. However, if I try to add 'tag=3' to the above add-port command it just assigns the port the dead tag 4095. So at the point I have a new interface created, o-hm0, with a status of DOWN. It's on br-int, but I can't ping the instance at 172.18.2.126. I also assume I need to add a static route of some form on the node, though no attempts so far have resulted in being able to ping. Would be very grateful if you could revise these commands and let know if they deviate from what you're doing. -Paul On 06/12/2018 21:12, M. Ranganathan wrote: > HACK ALERT Disclaimer: My suggestion could be clumsy. > > On Thu, Dec 6, 2018 at 1:46 PM Paul Bourke > wrote: > > Hi, > > This is mostly a follow on to the thread at[0], though due to the > mailing list transition it was easier to start a new thread. > > I've been attempting to get Octavia setup according to the > dev-quick-start guide[1], but have been struggling with the > following piece: > > "Add appropriate routing to / from the ‘lb-mgmt-net’ such that > egress is allowed, and the controller (to be created later) can talk > to hosts on this network." > > In mranga's reply, they say: > > > -- Create an ovs port  on br-int > > -- Create a neutron port using the ovs port that you just created. > > -- Assign the ip address of the neutron port to the ovs port > > -- Use ip netns exec to assign a route in the router namespace of > the LoadBalancer network. > > I have enough of an understanding of Neutron/OVS for this to mostly > make sense, but not enough to actually put it into practice it > seems. My environment: > > 3 x control nodes > 2 x network nodes > 1 x compute > > All nodes have two interfaces, eth0 being the management network - > 192.168.5.0/24 , and eth1 being used for the > provider network. I then create the Octavia lb-mgmt-net on > 172.18.2.0/24 . > > I've read the devstack script[2] and have the following questions: > > * Should I add the OVS port to br-int on the compute, network nodes, > or both? > > > I have only one controller which also functions as my network node. I > added the port on the controller/network  node. br-int is the place > where the integration happens. You will find each network has an > internal vlan tag associated with it. Use the tag assigned to your lb > network when you create the ovs port. > > ovs-vsctl show will tell you more. > > > * What is the purpose of creating a neutron port in this scenario > > > Just want to be sure Neutron knows about it and has an entry in its > database so the address won't be used for something else. If you are > using static addresses, for example you should not need this (I think). > > BTW the created port is DOWN. I am not sure why and I am not sure it > matters. > > > If anyone is able to explain this a bit further or can even point to > some good material to flesh out the underlying concepts it would be > much appreciated, I feel the 'Neutron 101' videos I've done so far > are not quite getting me there :) > > Cheers, > -Paul > > [0] > http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000544.html > [1] > https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html > [2] https://github.com/openstack/octavia/blob/master/devstack/plugin.sh > > > > -- > M. Ranganathan > From juliaashleykreger at gmail.com Fri Dec 7 16:02:08 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Fri, 7 Dec 2018 08:02:08 -0800 Subject: [ironic] Time to discuss clean/deploy steps In-Reply-To: References: Message-ID: Following up from our discussion: Present: dtantsur rloo mgoddard jaypipes TheJulia stendukler iurygregoy Consensuses: * The "holding" state seems generally useful to operators and we should implement that, likely as an RFE since the needful actions and steps to be reached with a running ramdisk are fairly clear. * An API may make sense for some users, but the caveats and issues are fairly expansive. Largely because for good usability, we would need to cache, and that cache may no longer be valid or not valid for even the next run. * We need to revise our documentation to be a little more clear regarding cleaning steps so it is easier to find and understand, since we already document our default steps. Vendor hardware manager modules should do the same, provide documentation on the steps, and caveats to use. ** The same essentially applies to deploy steps, we will need to ensure that is properly documented to make everyone's lives easier. * We agreed that the team likely does not need to implement this API at this time. This is largely due to all of these possible caveats and exception handling that would be needed to provide a full picture of the available clean/deploy step universe for third party hardware managers. * We agreed it was useful to finally talk via a higher bandwidth medium since we've not been able to reach consensus on this functionality via irc or review. Action Items: * TheJulia to look at the documentation and revise it over the holidays to try and be a little more clear and concise about cleaning and steps. * TheJulia, or whomever beats her to it, to update the spec to basically represent the above consensuses and change the target folder to backlog instead of approved and not-implemented. Spec will be free for anyone who wishes to implement the feature, however the team On Tue, Dec 4, 2018 at 1:37 PM Julia Kreger wrote: > All, > > I've looked at the doodle poll results and it looks like the best > available time is 3:00 PM UTC on Friday December 7th. > > I suggest we use bluejeans[2] as that has worked fairly well for us thus > far. The specification documented related to the discussion can be found in > review[3]. > > Thanks, > > -Julia > > [1] https://doodle.com/poll/yan4wyvztf7mpq46 > [2] https://bluejeans.com/u/jkreger/ > [3] https://review.openstack.org/#/c/606199/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Fri Dec 7 16:07:49 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Fri, 7 Dec 2018 10:07:49 -0600 Subject: [nova] Moving nova-cells-v1 job to the experimental queue Message-ID: <2f4fad9f-38de-f966-8ef6-5184acf0ac7d@gmail.com> I have changes up which move the nova-cells-v1 CI job to the experimental queue: https://review.openstack.org/#/q/topic:bug/1807407 We continue to see intermittent failures in that job and given the deprecated nature of cells v1, CERN is using cells v2, the job no longer runs nova-network, and its flakiness (plus the general state of the gate lately), it is time to move this further out of our daily lives and down the road to its eventual removal. Keeping it as an option to run on-demand in the experimental queue at least allows us to leverage it if needed should some major cells v1 fix be needed, but that is doubtful (we haven't had a cells v1 specific bug fix in a long time). -- Thanks, Matt From colleen at gazlene.net Fri Dec 7 16:11:17 2018 From: colleen at gazlene.net (Colleen Murphy) Date: Fri, 07 Dec 2018 17:11:17 +0100 Subject: [dev][keystone] Keystone Team Update - Week of 3 December 2018 Message-ID: <1544199077.1398908.1602216128.4FBE9319@webmail.messagingengine.com> # Keystone Team Update - Week of 3 December 2018 ## News ### New Outreachy Interns The keystone team is lucky enough to have two Outreachy interns this round: welcome to Erus (erus) and Islam (imus)! Erus will be helping us with our federation implementation and Islam will be working on improving our API unit tests. We're happy to have you! ### Keystone as IdP Proxy (Broker) Morgan started working on a diagram to explain the proposed architecture for keystone as an identity provider proxy/broker[1][2]. It is a good starting point for understanding the general idea of what the proposed design is. Please have a look at it and bring your questions to Morgan. [1] https://usercontent.irccloud-cdn.com/file/Au4e3DXb/Keystone%20IDP%20(initial)%20Diagram.png [2] http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-12-04-16.00.log.html#l-247 ## Open Specs Stein specs: https://bit.ly/2Pi6dGj Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 25 changes this week. ## Changes that need Attention Search query: https://bit.ly/2RLApdA There are 91 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 5 new bugs and closed 4. Bugs opened (5) Bug #1806713 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1806713 Bug #1806762 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1806762 Bug #1806195 (keystone:Undecided) opened by nigel cook https://bugs.launchpad.net/keystone/+bug/1806195 Bug #1806377 (keystone:Undecided) opened by kirandevraaj https://bugs.launchpad.net/keystone/+bug/1806377 Bug #1807184 (oslo.policy:Medium) opened by Brian Rosmaita https://bugs.launchpad.net/oslo.policy/+bug/1807184 Bugs fixed (4) Bug #1806109 (keystoneauth:Medium) fixed by Monty Taylor https://bugs.launchpad.net/keystoneauth/+bug/1806109 Bug #1800259 (oslo.policy:Undecided) fixed by Lance Bragstad https://bugs.launchpad.net/oslo.policy/+bug/1800259 Bug #1803722 (oslo.policy:Undecided) fixed by Corey Bryant https://bugs.launchpad.net/oslo.policy/+bug/1803722 Bug #1804073 (oslo.policy:Undecided) fixed by John Dennis https://bugs.launchpad.net/oslo.policy/+bug/1804073 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html We have just a month left until our spec freeze. A month after that is our feature proposal freeze, so if you are planning significant feature work, best to get started on it soon. ## 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 dangtrinhnt at gmail.com Fri Dec 7 16:17:29 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Sat, 8 Dec 2018 01:17:29 +0900 Subject: [Searchlight][Zuul] tox failed tests at zuul check only In-Reply-To: References: <1543855087.1459125.1597252016.5DBF506E@webmail.messagingengine.com> Message-ID: Hi again, Just wonder how the image for searchlight test was set up? Which user is used for running ElasticSearch? Is there any way to indicate the user that will run the test? Can I do it with [1]? Based on the output of [2] I can see there are some permission issue of JDK if I run the functional tests with the stack user on my dev environment. [1] https://git.openstack.org/cgit/openstack/searchlight/tree/tools/test-setup.sh [2] https://review.openstack.org/#/c/622871/3/searchlight/tests/functional/__init__.py Thanks, On Fri, Dec 7, 2018 at 4:30 PM Trinh Nguyen wrote: > Hi Clark, > > Outputting the exec logs does help. And, I found the problem for the > functional tests to fail, it because ES cannot be started because of the > way the functional sets up the new version of ES server (5.x). I'm working > on updating it. > > Many thanks, > > On Tue, Dec 4, 2018 at 1:39 AM Clark Boylan wrote: > >> On Mon, Dec 3, 2018, at 7:28 AM, Trinh Nguyen wrote: >> > Hello, >> > >> > Currently, [1] fails tox py27 tests on Zuul check for just updating the >> log >> > text. The tests are successful at local dev env. Just wondering there is >> > any new change at Zuul CI? >> > >> > [1] https://review.openstack.org/#/c/619162/ >> > >> >> Reading the exceptions [2] and the test setup code [3] it appears that >> elasticsearch isn't responding on its http port and is thus treated as >> having not started. With the info we currently have it is hard to say why. >> Instead of redirecting exec logs to /dev/null [4] maybe we can capture that >> data? Also probably worth grabbing the elasticsearch daemon log as well. >> >> Without that information it is hard to say why this happened. I am not >> aware of any changes in the CI system that would cause this, but we do >> rebuild our test node images daily. >> >> [2] >> http://logs.openstack.org/62/619162/5/check/openstack-tox-py27/9ce318d/job-output.txt.gz#_2018-11-27_05_32_48_854289 >> [3] >> https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/functional/__init__.py#n868 >> [4] >> https://git.openstack.org/cgit/openstack/searchlight/tree/searchlight/tests/functional/__init__.py#n851 >> >> Clark >> >> > > -- > *Trinh Nguyen* > *www.edlab.xyz * > > -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Fri Dec 7 17:08:59 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Fri, 7 Dec 2018 11:08:59 -0600 Subject: [placement] update 18-49 - aggregate allocation ratios In-Reply-To: References: Message-ID: <6cce1dff-3c26-683a-3529-ab955076a024@gmail.com> On 12/7/2018 6:58 AM, Chris Dent wrote: > * >   Account for host agg allocation ratio in placement >   (Still in rocky/) Given https://bugs.launchpad.net/nova/+bug/1804125 and the discussion with the operator in there, I've been thinking about this again lately. We will soon [1] at least have the restriction documented but the comment from the operator in that bug is painful: """ What's more distressing is that this appears to have produced a schism between the intended, documented functions of Nova scheduler and the actual operation of those functions on several consecutive releases of OpenStack. If the Aggregate* filters are no longer functional, and are no longer intended to be so, then I would think they should reasonably have been removed from the documentation and from the project so that deployers wouldn't expect to rely on them. """ With https://review.openstack.org/#/q/topic:bp/initial-allocation-ratios we at least have some sanity in nova-compute and you can control the allocation ratios per-compute (resource provider) either via nova config (the CERN use case) or the placement API using RBAC (the mgagne scenario, with placement RBAC added in Rocky). What is missing is something user-friendly for those that want to control allocation ratios in aggregate from the API. In Dublin we said we'd write an osc-placement CLI to help with this: https://etherpad.openstack.org/p/nova-ptg-rocky-placement ~L37 But that didn't happen unfortunately. It doesn't mean we couldn't still easily add that. That solution does require tooling changes from deployers though. The other alternative is Jay's spec which is to have nova-api mirror/proxy allocation ratio information from the compute host aggregates API to the placement API. Since Rocky the compute API already mirrors aggregate information to placement, so this would be building on that to also set allocation ratio information on each resource provider within said aggregate in placement. Part of me doesn't like that proxy work given our stance on no more proxies [2] but on the other hand we definitely regressed our own compute API (and scheduler) in Ocata, so it seems on us to provide the most user-friendly (no upgrade impact) way to solve that. Either way we go, at this point, doesn't it mean we can deprecate the Aggregate* filters since they are essentially useless when using the FilterScheduler and placement (remember the CachingScheduler is gone now)? [1] https://review.openstack.org/#/q/Ifaf596a8572637f843f47daf5adce394b0365676 [2] https://docs.openstack.org/nova/latest/contributor/project-scope.html#api-scope -- Thanks, Matt From melwittt at gmail.com Fri Dec 7 17:17:04 2018 From: melwittt at gmail.com (melanie witt) Date: Fri, 7 Dec 2018 09:17:04 -0800 Subject: [nova] slides now available for project update and project onboarding sessions Message-ID: <26c5fcb5-1b11-b4b5-2727-22bd9daf7118@gmail.com> Howdy all, This is just a FYI that slides are now attached to the summit events for the Nova - Project Update and the Nova - Project Onboarding sessions: https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22861/nova-project-update https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22860/nova-project-onboarding Cheers, -melanie From senrique at redhat.com Fri Dec 7 17:55:10 2018 From: senrique at redhat.com (Sofia Enriquez) Date: Fri, 7 Dec 2018 14:55:10 -0300 Subject: [cinder] [tempest] Ideas for test cases Message-ID: Hello cinder guys, I'm working on increasing the coverage of Cinder Tempest [1]. Since I'm relatively new using cinder retype+migrate functionality, I'm looking for possible ideas of test cases. Thanks, Sofi [1]: https://review.openstack.org/#/c/614022/ -- Sofia Enriquez Associate Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Fri Dec 7 18:16:12 2018 From: cboylan at sapwetik.org (Clark Boylan) Date: Fri, 07 Dec 2018 10:16:12 -0800 Subject: [Searchlight][Zuul] tox failed tests at zuul check only In-Reply-To: References: <1543855087.1459125.1597252016.5DBF506E@webmail.messagingengine.com> Message-ID: <1544206572.507632.1602338888.7C5CDA48@webmail.messagingengine.com> On Fri, Dec 7, 2018, at 8:17 AM, Trinh Nguyen wrote: > Hi again, > Just wonder how the image for searchlight test was set up? Which user is > used for running ElasticSearch? Is there any way to indicate the user that > will run the test? Can I do it with [1]? Based on the output of [2] I can > see there are some permission issue of JDK if I run the functional tests > with the stack user on my dev environment. > > [1] > https://git.openstack.org/cgit/openstack/searchlight/tree/tools/test-setup.sh > [2] > https://review.openstack.org/#/c/622871/3/searchlight/tests/functional/__init__.py > The unittest jobs run as the Zuul user. This user has sudo access when test-setup.sh runs, but then we remove sudo access when tox is run. This is important as we are trying to help ensure that you can run tox locally without it making system level changes. When your test setup script runs `dpkg -i` this package install may start running an elasticsearch instance. It depends on how the package is set up. This daemon would run under the user the package has configured for that service. When you run an elasticsearch process from your test suite this will run as the zuul user. Hope this helps. I also left a couple of comments on change 622871. Clark From fungi at yuggoth.org Fri Dec 7 19:09:26 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 7 Dec 2018 19:09:26 +0000 Subject: On trust and risk, Australia's Assistance and Access Bill Message-ID: <20181207190926.z6fnjnevoh66yrqf@yuggoth.org> I've seen concern expressed in OpenStack and other free/libre open source software communities over the recent passage of the "Assistance and Access Bill 2018" by the Australian Parliament, and just want to say that I appreciate the trust relationships we've all built with our colleagues in many countries, including Australia. As someone who doesn't particularly agree with many of the laws passed in his own country, while I'm not going to encourage civil disobedience, I do respect that many have shown preference for it over compelled compromise of our community's established trust. I, for one, don't wish to return to the "bad old days" of the crypto wars, when major projects like OpenBSD refused contributions from citizens and residents of the USA. It's bad for project morale, excludes valuable input from people with a variety of perspectives, and it's just downright inefficient too. The unfortunate truth is that anyone can be pressured at any time to derail, backdoor or otherwise compromise software and systems. A new law in one country doesn't change that. There are frequent news stories about government agencies installing covert interfaces in enterprise and consumer electronic devices alike through compulsion of those involved in their programming, manufacture and distribution. There's evidence of major standards bodies being sidetracked and steered into unwittingly approving flawed specifications which influential actors already know ways to circumvent. Over the course of my career I've had to make personal choices regarding installation and maintenance of legally-mandated systems for spying on customers and users. All we can ever hope for is that the relationships, systems and workflows we create are as resistant as possible to these sorts of outside influences. Sure, ejecting people from important or sensitive positions within the project based on their nationality might be a way to send a message to a particular government, but the problem is bigger than just one country and we'd really all need to be removed from our posts for pretty much the same reasons. This robust community of trust and acceptance we've fostered is not a risk, it's another line of defense against erosion of our ideals and principles. Entrenched concepts like open design and public review help to shield us from these situations, and while there is no perfect protection it seems to me that secret compromise under our many watchful eyes is a much harder task than doing so behind the closed doors of proprietary systems development. I really appreciate all the Australians who toil tirelessly to make OpenStack better, and am proud to call them friends and colleagues. I certainly don't want them to feel any need to resign from their valuable work because they're worried the rest of us can no longer trust them. -- 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 msm at redhat.com Fri Dec 7 19:12:35 2018 From: msm at redhat.com (Michael McCune) Date: Fri, 7 Dec 2018 14:12:35 -0500 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: References: <380a044d-8185-a312-2f7e-40bd663cf49c@openstack.org> Message-ID: hey folks, i realized after some discussion with the other API SIG cores that i might not have been clear enough in my responses. for the record, i _do not_ have an objection to bringing the SDK work into the mission of the API SIG. further, i think it does make good sense to rally all these concerns in one place and will reduce the confusion that coalesces around new SIG formations. i do maintain that we will need to do some work and bring on fresh bodies into the SIG to ensure the best outcomes. for transparency sake, here is a link[0] to the chat we had in #openstack-sdk among the API SIG cores. peace o/ [0]: http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2018-12-07.log.html#t2018-12-07T16:06:43 From juliaashleykreger at gmail.com Fri Dec 7 19:20:29 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Fri, 7 Dec 2018 11:20:29 -0800 Subject: On trust and risk, Australia's Assistance and Access Bill In-Reply-To: <20181207190926.z6fnjnevoh66yrqf@yuggoth.org> References: <20181207190926.z6fnjnevoh66yrqf@yuggoth.org> Message-ID: Very well said! Thank you Jeremy! On Fri, Dec 7, 2018 at 11:14 AM Jeremy Stanley wrote: > I've seen concern expressed in OpenStack and other free/libre open > source software communities over the recent passage of the > "Assistance and Access Bill 2018" by the Australian Parliament, and > just want to say that I appreciate the trust relationships we've all > built with our colleagues in many countries, including Australia. As > someone who doesn't particularly agree with many of the laws passed > in his own country, while I'm not going to encourage civil > disobedience, I do respect that many have shown preference for it > over compelled compromise of our community's established trust. I, > for one, don't wish to return to the "bad old days" of the crypto > wars, when major projects like OpenBSD refused contributions from > citizens and residents of the USA. It's bad for project morale, > excludes valuable input from people with a variety of perspectives, > and it's just downright inefficient too. > > The unfortunate truth is that anyone can be pressured at any time to > derail, backdoor or otherwise compromise software and systems. A new > law in one country doesn't change that. There are frequent news > stories about government agencies installing covert interfaces in > enterprise and consumer electronic devices alike through compulsion > of those involved in their programming, manufacture and > distribution. There's evidence of major standards bodies being > sidetracked and steered into unwittingly approving flawed > specifications which influential actors already know ways to > circumvent. Over the course of my career I've had to make personal > choices regarding installation and maintenance of legally-mandated > systems for spying on customers and users. All we can ever hope for > is that the relationships, systems and workflows we create are as > resistant as possible to these sorts of outside influences. > > Sure, ejecting people from important or sensitive positions within > the project based on their nationality might be a way to send a > message to a particular government, but the problem is bigger than > just one country and we'd really all need to be removed from our > posts for pretty much the same reasons. This robust community of > trust and acceptance we've fostered is not a risk, it's another line > of defense against erosion of our ideals and principles. Entrenched > concepts like open design and public review help to shield us from > these situations, and while there is no perfect protection it seems > to me that secret compromise under our many watchful eyes is a much > harder task than doing so behind the closed doors of proprietary > systems development. > > I really appreciate all the Australians who toil tirelessly to make > OpenStack better, and am proud to call them friends and colleagues. > I certainly don't want them to feel any need to resign from their > valuable work because they're worried the rest of us can no longer > trust them. > -- > Jeremy Stanley > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msm at redhat.com Fri Dec 7 19:23:23 2018 From: msm at redhat.com (Michael McCune) Date: Fri, 7 Dec 2018 14:23:23 -0500 Subject: On trust and risk, Australia's Assistance and Access Bill In-Reply-To: <20181207190926.z6fnjnevoh66yrqf@yuggoth.org> References: <20181207190926.z6fnjnevoh66yrqf@yuggoth.org> Message-ID: On Fri, Dec 7, 2018 at 2:12 PM Jeremy Stanley wrote: > > I've seen concern expressed in OpenStack and other free/libre open > source software communities over the recent passage of the > "Assistance and Access Bill 2018" by the Australian Parliament, and > just want to say that I appreciate the trust relationships we've all > built with our colleagues in many countries, including Australia. As > someone who doesn't particularly agree with many of the laws passed > in his own country, while I'm not going to encourage civil > disobedience, I do respect that many have shown preference for it > over compelled compromise of our community's established trust. I, > for one, don't wish to return to the "bad old days" of the crypto > wars, when major projects like OpenBSD refused contributions from > citizens and residents of the USA. It's bad for project morale, > excludes valuable input from people with a variety of perspectives, > and it's just downright inefficient too. > > The unfortunate truth is that anyone can be pressured at any time to > derail, backdoor or otherwise compromise software and systems. A new > law in one country doesn't change that. There are frequent news > stories about government agencies installing covert interfaces in > enterprise and consumer electronic devices alike through compulsion > of those involved in their programming, manufacture and > distribution. There's evidence of major standards bodies being > sidetracked and steered into unwittingly approving flawed > specifications which influential actors already know ways to > circumvent. Over the course of my career I've had to make personal > choices regarding installation and maintenance of legally-mandated > systems for spying on customers and users. All we can ever hope for > is that the relationships, systems and workflows we create are as > resistant as possible to these sorts of outside influences. > > Sure, ejecting people from important or sensitive positions within > the project based on their nationality might be a way to send a > message to a particular government, but the problem is bigger than > just one country and we'd really all need to be removed from our > posts for pretty much the same reasons. This robust community of > trust and acceptance we've fostered is not a risk, it's another line > of defense against erosion of our ideals and principles. Entrenched > concepts like open design and public review help to shield us from > these situations, and while there is no perfect protection it seems > to me that secret compromise under our many watchful eyes is a much > harder task than doing so behind the closed doors of proprietary > systems development. > > I really appreciate all the Australians who toil tirelessly to make > OpenStack better, and am proud to call them friends and colleagues. > I certainly don't want them to feel any need to resign from their > valuable work because they're worried the rest of us can no longer > trust them. > -- > Jeremy Stanley ++ well said. thank you for stating this so eloquently. peace o/ From mranga at gmail.com Fri Dec 7 19:45:12 2018 From: mranga at gmail.com (M. Ranganathan) Date: Fri, 7 Dec 2018 14:45:12 -0500 Subject: [octavia] Routing between lb-mgmt-net and amphora In-Reply-To: <6a861285-b25b-87d6-15fe-a48cdf0f08da@oracle.com> References: <6a861285-b25b-87d6-15fe-a48cdf0f08da@oracle.com> Message-ID: Here is a gist of what I did (which again could be completely the wrong way to proceed). Basically, you create a port for your network and then run the script to emit the configuration commands you need to run *examine the output before running it please* Feel free to re-use or better yet, please come up with a way to do the equivalent thing using just openstack command line (without scripts) and share it. https://gist.github.com/ranganathanm/6fcd94ad0d568d00156cff08b055c4b0 Hope this helps On Fri, Dec 7, 2018 at 9:58 AM Paul Bourke wrote: > Ok, so in my case, I've booted a test cirros VM on lb-mgmt-net, it gets > assigned an IP of 172.18.2.126. The goal is to be able to ping this IP > directly from the control plane. > > I create a port in neutron: http://paste.openstack.org/show/736821/ > > I log onto the network node that's hosting the dhcp namespace for this > node: http://paste.openstack.org/show/736823/ > > I then run the following command lifted from devstack, with my port info > subbed in: > > # ovs-vsctl -- --may-exist add-port ${OVS_BRIDGE:-br-int} o-hm0 -- set > Interface o-hm0 type=internal -- set Interface o-hm0 > external-ids:iface-status=active -- set Interface o-hm0 > external-ids:attached-mac=$MGMT_PORT_MAC -- set Interface o-hm0 > external-ids:iface-id=$MGMT_PORT_ID -- set Interface o-hm0 > external-ids:skip_cleanup=true > > Here's the output of 'ovs-vsctl show' at this point: > http://paste.openstack.org/show/736826/ > > Note that the tap device for the VM (tap6440048f-d2) has tag 3. However, > if I try to add 'tag=3' to the above add-port command it just assigns > the port the dead tag 4095. > > So at the point I have a new interface created, o-hm0, with a status of > DOWN. It's on br-int, but I can't ping the instance at 172.18.2.126. I > also assume I need to add a static route of some form on the node, > though no attempts so far have resulted in being able to ping. > > Would be very grateful if you could revise these commands and let know > if they deviate from what you're doing. > > -Paul > > On 06/12/2018 21:12, M. Ranganathan wrote: > > HACK ALERT Disclaimer: My suggestion could be clumsy. > > > > On Thu, Dec 6, 2018 at 1:46 PM Paul Bourke > > wrote: > > > > Hi, > > > > This is mostly a follow on to the thread at[0], though due to the > > mailing list transition it was easier to start a new thread. > > > > I've been attempting to get Octavia setup according to the > > dev-quick-start guide[1], but have been struggling with the > > following piece: > > > > "Add appropriate routing to / from the ‘lb-mgmt-net’ such that > > egress is allowed, and the controller (to be created later) can talk > > to hosts on this network." > > > > In mranga's reply, they say: > > > > > -- Create an ovs port on br-int > > > -- Create a neutron port using the ovs port that you just created. > > > -- Assign the ip address of the neutron port to the ovs port > > > -- Use ip netns exec to assign a route in the router namespace of > > the LoadBalancer network. > > > > I have enough of an understanding of Neutron/OVS for this to mostly > > make sense, but not enough to actually put it into practice it > > seems. My environment: > > > > 3 x control nodes > > 2 x network nodes > > 1 x compute > > > > All nodes have two interfaces, eth0 being the management network - > > 192.168.5.0/24 , and eth1 being used for the > > provider network. I then create the Octavia lb-mgmt-net on > > 172.18.2.0/24 . > > > > I've read the devstack script[2] and have the following questions: > > > > * Should I add the OVS port to br-int on the compute, network nodes, > > or both? > > > > > > I have only one controller which also functions as my network node. I > > added the port on the controller/network node. br-int is the place > > where the integration happens. You will find each network has an > > internal vlan tag associated with it. Use the tag assigned to your lb > > network when you create the ovs port. > > > > ovs-vsctl show will tell you more. > > > > > > * What is the purpose of creating a neutron port in this scenario > > > > > > Just want to be sure Neutron knows about it and has an entry in its > > database so the address won't be used for something else. If you are > > using static addresses, for example you should not need this (I think). > > > > BTW the created port is DOWN. I am not sure why and I am not sure it > > matters. > > > > > > If anyone is able to explain this a bit further or can even point to > > some good material to flesh out the underlying concepts it would be > > much appreciated, I feel the 'Neutron 101' videos I've done so far > > are not quite getting me there :) > > > > Cheers, > > -Paul > > > > [0] > > > http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000544.html > > [1] > > > https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html > > [2] > https://github.com/openstack/octavia/blob/master/devstack/plugin.sh > > > > > > > > -- > > M. Ranganathan > > > -- M. Ranganathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Fri Dec 7 21:01:55 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Fri, 7 Dec 2018 15:01:55 -0600 Subject: [infra] A change to Zuul's queuing behavior In-Reply-To: <87bm62z4av.fsf@meyer.lemoncheese.net> References: <87bm62z4av.fsf@meyer.lemoncheese.net> Message-ID: <43a151f1-e690-96e7-05b5-7561e34033b2@gmail.com> On 12/3/2018 3:30 PM, James E. Blair wrote: > Since some larger projects consume the bulk of cloud resources in our > system, this can be especially frustrating for smaller projects. To be > sure, it impacts everyone, but while larger projects receive a > continuous stream of results (even if delayed) smaller projects may wait > hours before seeing results on a single change. > > In order to help all projects maintain a minimal velocity, we've begun > dynamically prioritizing node requests based on the number of changes a > project has in a given pipeline. FWIW, and maybe this is happening across the board right now, but it's taking probably ~16 hours to get results on nova changes right now, which becomes increasingly frustrating when they finally get a node, tests run and then the job times out or something because the node is slow (or some other known race test failure). Is there any way to determine or somehow track how long a change has been queued up before and take that into consideration when it's re-enqueued? Like take this change: https://review.openstack.org/#/c/620154/ That took about 3 days to merge with constant rechecks from the time it was approved. It would be cool if there was a way to say, from within 50 queued nova changes (using the example in the original email), let's say zuul knew that 10 of those 50 have already gone through one or more times and weigh those differently so when they do get queued up, they are higher in the queue than maybe something that is just going through it's first time. -- Thanks, Matt From kennelson11 at gmail.com Fri Dec 7 21:55:32 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Fri, 7 Dec 2018 13:55:32 -0800 Subject: [dev] How to develop changes in a series In-Reply-To: References: <1CC272501B5BC543A05DB90AA509DED527475067@ORSMSX162.amr.corp.intel.com> <20181205195227.4j3rkpinlgts3ujv@yuggoth.org> Message-ID: Thanks for mentioning the contributor guide! I'll happily review any patches you have for that section. I'm sure Ildiko would be happy to as well. -Kendall (diablo_rojo) On Wed, Dec 5, 2018 at 12:41 PM William M Edmonds wrote: > Jeremy Stanley wrote on 12/05/2018 02:52:28 PM: > > On 2018-12-05 14:48:37 -0500 (-0500), William M Edmonds wrote: > > > Eric Fried wrote on 12/05/2018 12:18:37 PM: > > > > > > > > > > > > > But I want to edit 1b2c453, while leaving ebb3505 properly stacked on > > > > top of it. Here I use a tool called `git restack` (run `pip install > > > > git-restack` to install it). > > > > > > It's worth noting that you can just use `git rebase` [1], you don't > have to > > > use git-restack. This is why later you're using `git rebase > --continue`, > > > because git-restack is actually using rebase under the covers. > > > > > > [1] https://stackoverflow.com/questions/1186535/how-to-modify-a- > > specified-commit > > > > You can, however what git-restack does for you is figure out which > > commit to rebase on top of so that you don't inadvertently rebase > > your stack of changes onto a newer branch state and then make things > > harder on reviewers. > > -- > > Jeremy Stanley > > Ah, that's good to know. > > Also, found this existing documentation [2] if someone wants to propose an > update or link from another location. Note that it doesn't currently > mention git-restack, just rebase. > > [2] > https://docs.openstack.org/contributors/code-and-documentation/patch-best-practices.html#how-to-handle-chains > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennelson11 at gmail.com Fri Dec 7 21:58:38 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Fri, 7 Dec 2018 13:58:38 -0800 Subject: [ops][docs] The Contributor Guide: Ops Feedback Session Summary In-Reply-To: References: <5938a4e0-3eb1-5448-3af5-f56bf3452e9c@suse.com> Message-ID: Thanks Doug! -Kendall (diablo_rojo) On Mon, Dec 3, 2018 at 12:01 PM Doug Hellmann wrote: > Doug Hellmann writes: > > > 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 > > > > The patch to add this to the theme is in > https://review.openstack.org/#/c/621690/ > > -- > Doug > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corvus at inaugust.com Fri Dec 7 22:53:27 2018 From: corvus at inaugust.com (James E. Blair) Date: Fri, 07 Dec 2018 14:53:27 -0800 Subject: [infra] A change to Zuul's queuing behavior In-Reply-To: <43a151f1-e690-96e7-05b5-7561e34033b2@gmail.com> (Matt Riedemann's message of "Fri, 7 Dec 2018 15:01:55 -0600") References: <87bm62z4av.fsf@meyer.lemoncheese.net> <43a151f1-e690-96e7-05b5-7561e34033b2@gmail.com> Message-ID: <87tvjpj6e0.fsf@meyer.lemoncheese.net> Matt Riedemann writes: > On 12/3/2018 3:30 PM, James E. Blair wrote: >> Since some larger projects consume the bulk of cloud resources in our >> system, this can be especially frustrating for smaller projects. To be >> sure, it impacts everyone, but while larger projects receive a >> continuous stream of results (even if delayed) smaller projects may wait >> hours before seeing results on a single change. >> >> In order to help all projects maintain a minimal velocity, we've begun >> dynamically prioritizing node requests based on the number of changes a >> project has in a given pipeline. > > FWIW, and maybe this is happening across the board right now, but it's > taking probably ~16 hours to get results on nova changes right now, > which becomes increasingly frustrating when they finally get a node, > tests run and then the job times out or something because the node is > slow (or some other known race test failure). > > Is there any way to determine or somehow track how long a change has > been queued up before and take that into consideration when it's > re-enqueued? Like take this change: > > https://review.openstack.org/#/c/620154/ > > That took about 3 days to merge with constant rechecks from the time > it was approved. It would be cool if there was a way to say, from > within 50 queued nova changes (using the example in the original > email), let's say zuul knew that 10 of those 50 have already gone > through one or more times and weigh those differently so when they do > get queued up, they are higher in the queue than maybe something that > is just going through it's first time. This suggestion would be difficult to implement, but also, I think it runs counter to some of the ideas that have been put into place in the past. In particular, the idea of clean-check was to make it harder to merge changes with gate failures (under the assumption that they are more likely to introduce racy tests). This might make it easier to recheck-bash bad changes in (along with good). Anyway, we chatted in IRC a bit and came up with another tweak, which is to group projects together in the check pipeline when setting this priority. We already to in gate, but currently, every project in the system gets equal footing in check for their first change. The change under discussion would group all tripleo projects together, and all the integrated projects together, so that the first change for a tripleo project had the same priority as the first change for an integrated project, and a puppet project, etc. The intent is to further reduce the priority "boost" that projects with lots of repos have. The idea is still to try to find a simple and automated way of more fairly distributing our resources. If this doesn't work, we can always return to the previous strict FIFO method. However, given the extreme delays we're seeing across the board, I'm trying to avoid the necessity of actually allocating quota to projects. If we can't make this work, and we aren't able to reduce utilization by improving the reliability of tests (which, by *far* would be the most effective thing to do -- please work with Clark on that), we may have to start talking about that. -Jim From pete.vandergiessen at canonical.com Fri Dec 7 23:05:29 2018 From: pete.vandergiessen at canonical.com (Pete Vander Giessen) Date: Fri, 7 Dec 2018 18:05:29 -0500 Subject: [dev] quick report on microstack Message-ID: Hi All, 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. > ... On Tue Nov 20 14:37:35 UTC 2018 Melvin Hillsman wrote: > 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. Thank you both for taking a look and raising bugs :-) We've spent our time after returning from the U.S. Thanksgiving Break hammering bits and pieces into shape. I just pushed a release to the candidate channel that should fix some of the hiccups on install and restart. (Instances you've spun up will still be stopped after a system reboot, but you should be able to start them up manually and continue using them without any issues.) You can install it with: sudo snap install microstack --classic --candidate And if you've already got microstack installed, you can do: sudo snap refresh microstack @Chris Morgan: I left a comment on the bug relating to theme switching that you raised (https://github.com/CanonicalLtd/microstack/issues/39). It looks like something is broken in the pathing for the scss around the roboto font face, but I'm not sure whether it's an issue with the way that the snap lays out the files (a missing symlink, maybe?), or if it's a more general issue when installing from a Rocky release tarball. We're troubleshooting, but if you'd weigh in with an opinion, I'd appreciate it. Thanks again! ~ PeteVG -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangtrinhnt at gmail.com Sat Dec 8 00:10:23 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Sat, 8 Dec 2018 09:10:23 +0900 Subject: [Searchlight][Zuul] tox failed tests at zuul check only In-Reply-To: <1544206572.507632.1602338888.7C5CDA48@webmail.messagingengine.com> References: <1543855087.1459125.1597252016.5DBF506E@webmail.messagingengine.com> <1544206572.507632.1602338888.7C5CDA48@webmail.messagingengine.com> Message-ID: Thanks, Clark. On Sat, Dec 8, 2018 at 3:16 AM Clark Boylan wrote: > On Fri, Dec 7, 2018, at 8:17 AM, Trinh Nguyen wrote: > > Hi again, > > Just wonder how the image for searchlight test was set up? Which user is > > used for running ElasticSearch? Is there any way to indicate the user > that > > will run the test? Can I do it with [1]? Based on the output of [2] I can > > see there are some permission issue of JDK if I run the functional tests > > with the stack user on my dev environment. > > > > [1] > > > https://git.openstack.org/cgit/openstack/searchlight/tree/tools/test-setup.sh > > [2] > > > https://review.openstack.org/#/c/622871/3/searchlight/tests/functional/__init__.py > > > > The unittest jobs run as the Zuul user. This user has sudo access when > test-setup.sh runs, but then we remove sudo access when tox is run. This is > important as we are trying to help ensure that you can run tox locally > without it making system level changes. > > When your test setup script runs `dpkg -i` this package install may start > running an elasticsearch instance. It depends on how the package is set up. > This daemon would run under the user the package has configured for that > service. When you run an elasticsearch process from your test suite this > will run as the zuul user. > > Hope this helps. I also left a couple of comments on change 622871. > > Clark > -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From bino at jogjacamp.co.id Sat Dec 8 01:42:48 2018 From: bino at jogjacamp.co.id (Bino Oetomo) Date: Sat, 8 Dec 2018 08:42:48 +0700 Subject: [Neutron] Message-ID: Dear All. I have no problem configuring network via Hosrizon-dasboard. I start playing with python for some task. I got succsess in creating network. I create a router, with one interface connected to existing 'ext-network' .. success. But I fail when I try to add a port to that router for connecting to existing internal network. Here is part of my python shell. -------------------- body_value = { 'port': { 'admin_state_up': True, 'device_owner': 'network:router_interface', 'device_id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-net-01-02', 'network_id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'binding:host_id': 'rocky-controller.mynet.net', 'binding:profile': {}, 'binding:vnic_type': 'normal', 'fixed_ips': [{ 'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', 'ip_address': '192.168.202.254' }], }} response = nt.create_port(body=body_value) response {'port': {'allowed_address_pairs': [], 'extra_dhcp_opts': [], 'updated_at': '2018-12-07T08:10:24Z', 'device_owner': 'network:router_interface', 'revision_number': 1, 'port_security_enabled': False, 'binding:profile': {}, 'fixed_ips': [{'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', 'ip_address': '192.168.202.254'}], 'id': 'd02eb0f0-663f-423f-af4e-c969ccb9dc25', 'security_groups': [], 'binding:vif_details': {'port_filter': True, 'datapath_type': 'system', 'ovs_hybrid_plug': True}, 'binding:vif_type': 'ovs', 'mac_address': 'fa:16:3e:e2:9d:8f', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'DOWN', 'binding:host_id': 'rocky-controller.mynet.net', 'description': '', 'tags': [], 'device_id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-net-01-02', 'admin_state_up': True, 'network_id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T08:10:24Z', 'binding:vnic_type': 'normal'}} -------------------- 'status' always 'DOWN'. Kindly please give me some clue to fix this problem Note : Actualy I post same question on stackexchange : https://stackoverflow.com/questions/53665795/openstack-python-neutronclient-creating-port-but-down Sincerely -bino- -------------- next part -------------- An HTML attachment was scrubbed... URL: From soheil.ir08 at gmail.com Sat Dec 8 08:07:51 2018 From: soheil.ir08 at gmail.com (Soheil Pourbafrani) Date: Sat, 8 Dec 2018 11:37:51 +0330 Subject: [OpenStack][Neutron] WARNING neutron.pecan_wsgi.controllers.root Message-ID: Hi, I defined an external flat network and the Instances' network functionality is OK but the neutron logs continusly on the file server.log: *2018-12-04 03:21:22.206 2218 WARNING neutron.pecan_wsgi.controllers.root [req-0ac40043-ec93-490d-8770-5f4c49a11ea6 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] No controller found for: floatingips - returning response code 404: PecanNotFound* 2018-12-04 03:21:22.208 2218 INFO neutron.pecan_wsgi.hooks.translation [req-0ac40043-ec93-490d-8770-5f4c49a11ea6 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] GET failed (client error): The resource could not be found. 2018-12-04 03:21:22.209 2218 INFO neutron.wsgi [req-0ac40043-ec93-490d-8770-5f4c49a11ea6 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] 192.168.0.31 "GET /v2.0/floatingips?fixed_ip_address=192.168.0.205&port_id=15251089-950a-4a4b-998b-e7412350b8bc HTTP/1.1" status: 404 len: 309 time: 0.0077560 2018-12-04 03:21:22.284 2218 INFO neutron.wsgi [req-1177939c-e304-439a-a6bf-1a3d216a2336 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] 192.168.0.31 "GET /v2.0/subnets?id=9771f7f2-12f8-46bd-aca3-f1d26e0b9768 HTTP/1.1" status: 200 len: 835 time: 0.0708778 2018-12-04 03:21:22.368 2218 INFO neutron.wsgi [req-12dce42d-f6a0-4deb-902d-c46d95621013 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] 192.168.0.31 "GET /v2.0/ports?network_id=a90d7d71-1ff4-4a98-b2b9-68adaea7d1c4&device_owner=network%3Adhcp HTTP/1.1" status: 200 len: 1085 time: 0.0782819 2018-12-04 03:21:22.569 2218 INFO neutron.wsgi [req-e73d9ad4-4e70-4fb6-91a5-9bd02c606284 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] 192.168.0.31 "GET /v2.0/networks/a90d7d71-1ff4-4a98-b2b9-68adaea7d1c4?fields=segments HTTP/1.1" status: 200 len: 212 time: 0.1933858 2018-12-04 03:21:22.751 2218 INFO neutron.wsgi [req-79921bc1-7f1a-4eee-aeca-3b660aab0522 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] 192.168.0.31 "GET /v2.0/networks/a90d7d71-1ff4-4a98-b2b9-68adaea7d1c4?fields=provider%3Aphysical_network&fields=provider%3Anetwork_type HTTP/1.1" status: 200 len: 281 time: 0.1775169 2018-12-04 03:21:34.957 2218 INFO neutron.wsgi [req-50877132-2c57-4220-9689-5c739d415aa8 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] 192.168.0.32 "GET /v2.0/ports?tenant_id=8cd6e51308894e119d2ad90ed15e71d2&device_id=882901a0-e518-4b4b-bf08-e998c4c0c875 HTTP/1.1" status: 200 len: 1094 time: 0.1096959 2018-12-04 03:21:35.116 2218 INFO neutron.wsgi [req-0305018f-b085-46c2-86cd-1769432cda91 539929ca1549436cb4c4171e037e8df7 0a26c316d0d143229f7420cf7fa35bdc - default default] 192.168.0.32 "GET /v2.0/networks?id=a90d7d71-1ff4-4a98-b2b9-68adaea7d1c4 HTTP/1.1" status: 200 len: 877 time: 0.1516771 I checked the neutron.conf and there was not any web_framework attribute under the [Default] section. >From OpenStack forum, someone suggest to set *web_framework = legacy *in neutron.conf. I did but it had no effect and neutron still is logging the so-called warning. Is this a bug or I miss something in configuration? I use the OpenStack Rocky. -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Sat Dec 8 14:42:35 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Sat, 8 Dec 2018 15:42:35 +0100 Subject: [Neutron] In-Reply-To: References: Message-ID: <05CDC301-26EF-4554-B595-9FB950BD8731@redhat.com> Hi, You shouldn’t create port with router as device owner. If You want to connect port or subnet to router, there is proper method for that: https://developer.openstack.org/api-ref/network/v2/?expanded=add-interface-to-router-detail#add-interface-to-router — Slawek Kaplonski Senior software engineer Red Hat > Wiadomość napisana przez Bino Oetomo w dniu 08.12.2018, o godz. 02:42: > > Dear All. > > I have no problem configuring network via Hosrizon-dasboard. > > I start playing with python for some task. > I got succsess in creating network. > I create a router, with one interface connected to existing 'ext-network' .. success. > > But I fail when I try to add a port to that router for connecting to existing internal network. > > Here is part of my python shell. > > -------------------- > body_value = { > > > 'port': { > > > 'admin_state_up': True, > > > 'device_owner': 'network:router_interface', > > > 'device_id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', > > > 'name': 'Bino-net-01-02', > > > 'network_id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', > > > 'binding:host_id': 'rocky-controller.mynet.net', > > > 'binding:profile': {}, > > > 'binding:vnic_type': 'normal', > > > 'fixed_ips': [{ > > > 'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', > > > 'ip_address': '192.168.202.254' > > > }], > > > } > } > > > response > = nt.create_port(body=body_value) > > response > > > {'port': {'allowed_address_pairs': [], 'extra_dhcp_opts': [], 'updated_at': '2018-12-07T08:10:24Z', 'device_owner': 'network:router_interface', 'revision_number': 1, 'port_security_enabled': False, 'binding:profile': {}, 'fixed_ips': [{'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', 'ip_address': '192.168.202.254'}], 'id': 'd02eb0f0-663f-423f-af4e-c969ccb9dc25', 'security_groups': [], 'binding:vif_details': {'port_filter': True, 'datapath_type': 'system', 'ovs_hybrid_plug': True}, 'binding:vif_type': 'ovs', 'mac_address': 'fa:16:3e:e2:9d:8f', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'DOWN', 'binding:host_id': 'rocky-controller.mynet.net', 'description': '', 'tags': [], 'device_id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-net-01-02', 'admin_state_up': True, 'network_id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T08:10:24Z', 'binding:vnic_type': 'normal'}} > > -------------------- > 'status' always 'DOWN'. > > Kindly please give me some clue to fix this problem > > Note : Actualy I post same question on stackexchange : https://stackoverflow.com/questions/53665795/openstack-python-neutronclient-creating-port-but-down > > Sincerely > -bino- From mriedemos at gmail.com Sat Dec 8 18:28:47 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Sat, 8 Dec 2018 12:28:47 -0600 Subject: [infra] Update on test throughput and Zuul backlogs In-Reply-To: <1544138161.3416170.1601467632.09A4549E@webmail.messagingengine.com> References: <1544138161.3416170.1601467632.09A4549E@webmail.messagingengine.com> Message-ID: <79ccf3b2-aded-966b-a7bd-ec98be79f177@gmail.com> On 12/6/2018 5:16 PM, Clark Boylan wrote: > All that said flaky tests are still an issue. One set of problems seems related to slower than expected/before test nodes in the BHS1 region. We've been debugging these with OVH (thank you amorin!) and think we've managed to make some improvements though so far the problems persist. Current theory is that we are acting as our own noisy neighbors starving the hypervisors of disk IO throughput. In order to test that we've halved the total number of resources we'll use there. More details athttps://etherpad.openstack.org/p/bhs1-test-node-slowness including a list of e-r bugs that may be tied to this issue. > > One thing to keep in mind is that while the test nodes are slower than we'd like, they have also exposed some situations where our software is less efficient than we'd like. At least one bug,https://bugs.launchpad.net/nova/+bug/1807219, has been identified through this. I would encourage people debugging these slow tests to look to see if this exposes a deficiency in our software that can be fixed. Here are a couple of fixes for recently fingerprinted gate bugs: https://review.openstack.org/#/c/623669/ https://review.openstack.org/#/c/623597/ Those are in grenade and devstack respectively so we'll need some QA cores. -- Thanks, Matt From gmann at ghanshyammann.com Sun Dec 9 11:22:36 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Sun, 09 Dec 2018 20:22:36 +0900 Subject: [cinder] [tempest] Ideas for test cases In-Reply-To: References: Message-ID: <16792b46bae.b1b7956b187049.263161708726828786@ghanshyammann.com> Thanks Sofia, There are few existing test cases in Tempest which cover retype and migration cases. Check if that cover your cases or you can extend those where you can reuse the code. - https://github.com/openstack/tempest/blob/e6c330892fbc8ae790384d554dd6d5c2668d8d24/tempest/api/volume/admin/test_volume_retype.py - https://github.com/openstack/tempest/blob/837726a9ede64e33d0def018da24e146dd6b5af3/tempest/scenario/test_volume_migrate_attached.py -gmann ---- On Sat, 08 Dec 2018 02:55:10 +0900 Sofia Enriquez wrote ---- > Hello cinder guys, > > I'm working on increasing the coverage of Cinder Tempest [1]. > > Since I'm relatively new using cinder retype+migrate functionality, I'm looking for possible ideas of test cases. > Thanks,Sofi > > [1]: https://review.openstack.org/#/c/614022/ > > -- > Sofia Enriquez > Associate Software Engineer > > From ervikrant06 at gmail.com Sat Dec 8 11:51:46 2018 From: ervikrant06 at gmail.com (Vikrant Aggarwal) Date: Sat, 8 Dec 2018 17:21:46 +0530 Subject: [openstack-dev] [magnum] [Rocky] K8 deployment on fedora-atomic is failed In-Reply-To: References: Message-ID: Hello Team, Any help on this issue? Thanks & Regards, Vikrant Aggarwal On Tue, Dec 4, 2018 at 6:49 PM Vikrant Aggarwal wrote: > Hello Team, > > Any help on this issue? > > Thanks & Regards, > Vikrant Aggarwal > > > On Fri, Nov 30, 2018 at 9:13 AM Vikrant Aggarwal > wrote: > >> 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: From bino at jogjacamp.co.id Sat Dec 8 23:49:07 2018 From: bino at jogjacamp.co.id (Bino Oetomo) Date: Sun, 9 Dec 2018 06:49:07 +0700 Subject: [Neutron] In-Reply-To: <05CDC301-26EF-4554-B595-9FB950BD8731@redhat.com> References: <05CDC301-26EF-4554-B595-9FB950BD8731@redhat.com> Message-ID: Dear Kaplonski sir. Thankyou for your help. Actualy, the one that I paste is not my first try. It's the result after I blindly trying add more and more parameters into body. Ok, I will try your sugestion and make a call using very minimal parameters per https://docs.openstack.org/ocata/user-guide/sdk-neutron-apis.html#create-router-and-add-port-to-subnet body_value = {'port': { 'admin_state_up': True, 'device_id': router_device_id, 'name': 'port1', 'network_id': network_id, }} I'll back to this list. Sincerely -bino- On Sat, Dec 8, 2018 at 9:42 PM Slawomir Kaplonski wrote: > Hi, > > You shouldn’t create port with router as device owner. If You want to > connect port or subnet to router, there is proper method for that: > https://developer.openstack.org/api-ref/network/v2/?expanded=add-interface-to-router-detail#add-interface-to-router > > — > Slawek Kaplonski > Senior software engineer > Red Hat > > > Wiadomość napisana przez Bino Oetomo w dniu > 08.12.2018, o godz. 02:42: > > > > Dear All. > > > > I have no problem configuring network via Hosrizon-dasboard. > > > > I start playing with python for some task. > > I got succsess in creating network. > > I create a router, with one interface connected to existing > 'ext-network' .. success. > > > > But I fail when I try to add a port to that router for connecting to > existing internal network. > > > > Here is part of my python shell. > > > > -------------------- > > body_value = { > > > > > > 'port': { > > > > > > 'admin_state_up': True, > > > > > > 'device_owner': 'network:router_interface', > > > > > > 'device_id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', > > > > > > 'name': 'Bino-net-01-02', > > > > > > 'network_id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', > > > > > > 'binding:host_id': 'rocky-controller.mynet.net', > > > > > > 'binding:profile': {}, > > > > > > 'binding:vnic_type': 'normal', > > > > > > 'fixed_ips': [{ > > > > > > 'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', > > > > > > 'ip_address': '192.168.202.254' > > > > > > }], > > > > > > } > > } > > > > > > response > > = nt.create_port(body=body_value) > > > > response > > > > > > {'port': {'allowed_address_pairs': [], 'extra_dhcp_opts': [], > 'updated_at': '2018-12-07T08:10:24Z', 'device_owner': > 'network:router_interface', 'revision_number': 1, 'port_security_enabled': > False, 'binding:profile': {}, 'fixed_ips': [{'subnet_id': > 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', 'ip_address': '192.168.202.254'}], > 'id': 'd02eb0f0-663f-423f-af4e-c969ccb9dc25', 'security_groups': [], > 'binding:vif_details': {'port_filter': True, 'datapath_type': 'system', > 'ovs_hybrid_plug': True}, 'binding:vif_type': 'ovs', 'mac_address': > 'fa:16:3e:e2:9d:8f', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', > 'status': 'DOWN', 'binding:host_id': 'rocky-controller.mynet.net', > 'description': '', 'tags': [], 'device_id': > 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-net-01-02', > 'admin_state_up': True, 'network_id': > 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'tenant_id': > 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T08:10:24Z', > 'binding:vnic_type': 'normal'}} > > > > -------------------- > > 'status' always 'DOWN'. > > > > Kindly please give me some clue to fix this problem > > > > Note : Actualy I post same question on stackexchange : > https://stackoverflow.com/questions/53665795/openstack-python-neutronclient-creating-port-but-down > > > > Sincerely > > -bino- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Sun Dec 9 13:57:54 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Sun, 09 Dec 2018 22:57:54 +0900 Subject: [infra] Update on test throughput and Zuul backlogs In-Reply-To: References: <1544138161.3416170.1601467632.09A4549E@webmail.messagingengine.com> Message-ID: <1679342979a.e9c69432187953.2468583431880373982@ghanshyammann.com> ---- On Fri, 07 Dec 2018 08:50:30 +0900 Matt Riedemann wrote ---- > On 12/6/2018 5:16 PM, Clark Boylan wrote: > > I was asked to write another one of these in the Nova meeting today so here goes. > > Thanks Clark, this is really helpful. > > > > > One thing to keep in mind is that while the test nodes are slower than we'd like, they have also exposed some situations where our software is less efficient than we'd like. At least one bug,https://bugs.launchpad.net/nova/+bug/1807219, has been identified through this. I would encourage people debugging these slow tests to look to see if this exposes a deficiency in our software that can be fixed. > > That was split off from this: > > https://bugs.launchpad.net/nova/+bug/1807044 > > But yeah a couple of issues Dan and I are digging into. > > Another thing I noticed in one of these nova-api start timeout failures > in ovh-bhs1 was uwsgi seems to just stall for 26 seconds here: > > http://logs.openstack.org/01/619701/5/gate/tempest-slow/2bb461b/controller/logs/screen-n-api.txt.gz#_Dec_05_20_13_23_060958 > > I pushed a patch to enable uwsgi debug logging: > > https://review.openstack.org/#/c/623265/ > > But of course I didn't (1) get a recreate or (2) seem to see any > additional debug logging from uwsgi. If someone else knows how to enable > that please let me know. > > > > > These are the big issues that affect large numbers of projects (or even all of them), but there are still many project specific problems floating around as well. Unfortunately I haven't had much time to help dig into those recently (see broader issues above), but I think it would be helpful if projects can do some of that digging themselves. Also, a friendly reminder that we try to provide in cloud region mirrors and caches for commonly used resources like distro packages, pypi packages, dockerhub images, and so on. If your jobs aren't using these and you find they fail occasionally due to the Internet being flaky we'll be happy to help you update the jobs to use the in region resources instead. > > I'm not sure if this query is valid anymore: > > http://status.openstack.org/elastic-recheck/#1783405 > > If it is, then we still have some tempest tests that aren't marked as > slow but are contributing to job timeouts outside the tempest-slow job. > I know the last time this came up, the QA team had a report of the > slowest non-slow tests - can we get another one of those now? This seems still valid query. 7 fails in 24 hrs / 302 fails in 10 days. I did some more catagorization for this query with build_name and found failure are- tempest-full or tempest-full-py3 - ~50% tempest-all - 2 % tempest-slow - 2% rest all is in all other jobs. I proposed to modify the query to exclude the tempest-all and tempest-slow job which runs all slow tests also. - https://review.openstack.org/#/c/623949/ On doing another round of marking slow tests, I will check if we can get more specific slow tests which are slow consistantly. -gmann > > Another thing is, are there particular voting jobs that have a failure > rate over 50% and are resetting the gate? If we do, we should consider > making them non-voting while project teams work on fixing the issues. > Because I've had approved patches for days now taking 13+ hours just to > fail, which is pretty unsustainable. > > > > > We'll keep pushing to fix the broader issues and are more than happy to help debug failures you hit within your projects as well. > > > > Hopefully this was helpful despite its length. > > Again, thank you Clark for taking the time to write up this summary - > it's extremely useful. > > -- > > Thanks, > > Matt > > From gmann at ghanshyammann.com Sun Dec 9 14:05:29 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Sun, 09 Dec 2018 23:05:29 +0900 Subject: [infra] Update on test throughput and Zuul backlogs In-Reply-To: <79ccf3b2-aded-966b-a7bd-ec98be79f177@gmail.com> References: <1544138161.3416170.1601467632.09A4549E@webmail.messagingengine.com> <79ccf3b2-aded-966b-a7bd-ec98be79f177@gmail.com> Message-ID: <16793498862.125d42988187984.1060993771189928648@ghanshyammann.com> ---- On Sun, 09 Dec 2018 03:28:47 +0900 Matt Riedemann wrote ---- > On 12/6/2018 5:16 PM, Clark Boylan wrote: > > All that said flaky tests are still an issue. One set of problems seems related to slower than expected/before test nodes in the BHS1 region. We've been debugging these with OVH (thank you amorin!) and think we've managed to make some improvements though so far the problems persist. Current theory is that we are acting as our own noisy neighbors starving the hypervisors of disk IO throughput. In order to test that we've halved the total number of resources we'll use there. More details athttps://etherpad.openstack.org/p/bhs1-test-node-slowness including a list of e-r bugs that may be tied to this issue. > > > > One thing to keep in mind is that while the test nodes are slower than we'd like, they have also exposed some situations where our software is less efficient than we'd like. At least one bug,https://bugs.launchpad.net/nova/+bug/1807219, has been identified through this. I would encourage people debugging these slow tests to look to see if this exposes a deficiency in our software that can be fixed. > > Here are a couple of fixes for recently fingerprinted gate bugs: > > https://review.openstack.org/#/c/623669/ > > https://review.openstack.org/#/c/623597/ > > Those are in grenade and devstack respectively so we'll need some QA cores. Done. grenade one is merged and devstack is in the queue. -gmann > > -- > > Thanks, > > Matt > > From gmann at ghanshyammann.com Sun Dec 9 14:14:37 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Sun, 09 Dec 2018 23:14:37 +0900 Subject: [infra] A change to Zuul's queuing behavior In-Reply-To: <87tvjpj6e0.fsf@meyer.lemoncheese.net> References: <87bm62z4av.fsf@meyer.lemoncheese.net> <43a151f1-e690-96e7-05b5-7561e34033b2@gmail.com> <87tvjpj6e0.fsf@meyer.lemoncheese.net> Message-ID: <1679351e6fd.cc0838f2188020.4216860630159968715@ghanshyammann.com> ---- On Sat, 08 Dec 2018 07:53:27 +0900 James E. Blair wrote ---- > Matt Riedemann writes: > > > On 12/3/2018 3:30 PM, James E. Blair wrote: > >> Since some larger projects consume the bulk of cloud resources in our > >> system, this can be especially frustrating for smaller projects. To be > >> sure, it impacts everyone, but while larger projects receive a > >> continuous stream of results (even if delayed) smaller projects may wait > >> hours before seeing results on a single change. > >> > >> In order to help all projects maintain a minimal velocity, we've begun > >> dynamically prioritizing node requests based on the number of changes a > >> project has in a given pipeline. > > > > FWIW, and maybe this is happening across the board right now, but it's > > taking probably ~16 hours to get results on nova changes right now, > > which becomes increasingly frustrating when they finally get a node, > > tests run and then the job times out or something because the node is > > slow (or some other known race test failure). > > > > Is there any way to determine or somehow track how long a change has > > been queued up before and take that into consideration when it's > > re-enqueued? Like take this change: > > > > https://review.openstack.org/#/c/620154/ > > > > That took about 3 days to merge with constant rechecks from the time > > it was approved. It would be cool if there was a way to say, from > > within 50 queued nova changes (using the example in the original > > email), let's say zuul knew that 10 of those 50 have already gone > > through one or more times and weigh those differently so when they do > > get queued up, they are higher in the queue than maybe something that > > is just going through it's first time. > > This suggestion would be difficult to implement, but also, I think it > runs counter to some of the ideas that have been put into place > in the past. In particular, the idea of clean-check was to make it > harder to merge changes with gate failures (under the assumption that > they are more likely to introduce racy tests). This might make it > easier to recheck-bash bad changes in (along with good). > > Anyway, we chatted in IRC a bit and came up with another tweak, which is > to group projects together in the check pipeline when setting this > priority. We already to in gate, but currently, every project in the > system gets equal footing in check for their first change. The change > under discussion would group all tripleo projects together, and all the > integrated projects together, so that the first change for a tripleo > project had the same priority as the first change for an integrated > project, and a puppet project, etc. > > The intent is to further reduce the priority "boost" that projects with > lots of repos have. > > The idea is still to try to find a simple and automated way of more > fairly distributing our resources. If this doesn't work, we can always > return to the previous strict FIFO method. However, given the extreme > delays we're seeing across the board, I'm trying to avoid the necessity > of actually allocating quota to projects. If we can't make this work, > and we aren't able to reduce utilization by improving the reliability of > tests (which, by *far* would be the most effective thing to do -- please > work with Clark on that), we may have to start talking about that. > > -Jim We can optimize the node by removing the job from running queue on the first failure hit instead of full run and then release the node. This is a trade-off with getting the all failure once and fix them all together but I am not sure if that is the case all time. For example- if any change has pep8 error then, no need to run integration tests jobs there. This at least can save nodes at some extent. -gmann > > From fungi at yuggoth.org Sun Dec 9 14:25:57 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Sun, 9 Dec 2018 14:25:57 +0000 Subject: [infra] A change to Zuul's queuing behavior In-Reply-To: <1679351e6fd.cc0838f2188020.4216860630159968715@ghanshyammann.com> References: <87bm62z4av.fsf@meyer.lemoncheese.net> <43a151f1-e690-96e7-05b5-7561e34033b2@gmail.com> <87tvjpj6e0.fsf@meyer.lemoncheese.net> <1679351e6fd.cc0838f2188020.4216860630159968715@ghanshyammann.com> Message-ID: <20181209142556.lg2wkpoj2xfvkdio@yuggoth.org> On 2018-12-09 23:14:37 +0900 (+0900), Ghanshyam Mann wrote: [...] > We can optimize the node by removing the job from running queue on > the first failure hit instead of full run and then release the > node. This is a trade-off with getting the all failure once and > fix them all together but I am not sure if that is the case all > time. For example- if any change has pep8 error then, no need to > run integration tests jobs there. This at least can save nodes at > some extent. I can recall plenty of times where I've pushed a change which failed pep8 on some non-semantic whitespace complaint and also had unit test or integration test failures. In those cases it's quite obvious that the pep8 failure reason couldn't have been the reason for the other failed jobs so seeing them all saved me wasting time on additional patches and waiting for more rounds of results. For that matter, a lot of my time as a developer (or even as a reviewer) is saved by seeing which clusters of jobs fail for a given change. For example, if I see all unit test jobs fail but integration test jobs pass I can quickly infer that there may be issues with a unit test that's being modified and spend less time fumbling around in the dark with various logs. It's possible we can save some CI resource consumption with such a trade-off, but doing so comes at the expense of developer and reviewer time so we have to make sure it's worthwhile. There was a point in the past where we did something similar (only run other jobs if a canary linter job passed), and there are good reasons why we didn't continue 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 zilhazur.rahman at brilliant.com.bd Sun Dec 9 16:15:37 2018 From: zilhazur.rahman at brilliant.com.bd (Zilhazur Rahman) Date: Sun, 9 Dec 2018 22:15:37 +0600 (BDT) Subject: [Neutron][ovs-dpdk] Message-ID: <889103638.17479349.1544372137196.JavaMail.zimbra@brilliant.com.bd> Hi I am writing for the first time to the mailing list of openstack, I am trying to deploy ovs-dpdk to have better traffic throughput for NFV. Could you please share any tutorial link for standard ovs-dpdk deployment. On the other hand, openstack site says this " Expect performance degradation of services using tap devices: these devices do not support DPDK. Example services include DVR, FWaaS, or LBaaS. " but I need to have LBaaS and DVR ( to have direct external connectivity on compute) , what could be done in this case? Regards Zilhaz From bino at jogjacamp.co.id Mon Dec 10 02:04:10 2018 From: bino at jogjacamp.co.id (Bino Oetomo) Date: Mon, 10 Dec 2018 09:04:10 +0700 Subject: [Neutron] In-Reply-To: <05CDC301-26EF-4554-B595-9FB950BD8731@redhat.com> References: <05CDC301-26EF-4554-B595-9FB950BD8731@redhat.com> Message-ID: Dear All, As suggested by Slawek Kaplonski, I tried this. ----------- >>> myrouter {'status': 'ACTIVE', 'external_gateway_info': {'network_id': 'd10dd06a-0425-49eb-a8ba-85abf55ac0f5', 'enable_snat': True, 'external_fixed_ips': [{'subnet_id': '4639e018-1cc1-49cc-89d4-4cad49bd4b89', 'ip_address': '10.10.10.2'}]}, 'availability_zone_hints': [], 'availability_zones': ['nova'], 'description': '', 'tags': [], 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T07:24:41Z', 'admin_state_up': True, 'distributed': False, 'updated_at': '2018-12-07T07:58:02Z', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'flavor_id': None, 'revision_number': 10, 'routes': [], 'ha': False, 'id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-rtr-01'} ```>>> mynetworks=[n for n in netlist['networks'] if n['name'].startswith('Bino')] >>> mynetworks [{'provider:physical_network': 'viavlan', 'ipv6_address_scope': None, 'revision_number': 7, 'port_security_enabled': True, 'mtu': 1500, 'id': '942675f6-fd5e-4bb2-ba43-487be992ff4e', 'router:external': False, 'availability_zone_hints': [], 'availability_zones': ['nova'], 'ipv4_address_scope': None, 'shared': False, 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'ACTIVE', 'subnets': ['5373bc35-a90f-4793-a912-801920e47769'], 'description': '', 'tags': [], 'updated_at': '2018-12-07T07:50:27Z', 'provider:segmentation_id': 2037, 'name': 'Bino-net-01', 'admin_state_up': True, 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T07:28:00Z', 'provider:network_type': 'vlan'}, {'provider:physical_network': 'viavlan', 'ipv6_address_scope': None, 'revision_number': 6, 'port_security_enabled': True, 'mtu': 1500, 'id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'router:external': False, 'availability_zone_hints': [], 'availability_zones': ['nova'], 'ipv4_address_scope': None, 'shared': False, 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'ACTIVE', 'subnets': ['c71a86a3-f9a8-4e60-828e-5d6f87e58ac9'], 'description': '', 'tags': [], 'updated_at': '2018-12-07T07:49:59Z', 'provider:segmentation_id': 2002, 'name': 'Bino-net-02', 'admin_state_up': True, 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T07:29:52Z', 'provider:network_type': 'vlan'}] >>> print([n['name'] for n in mynetworks]) ['Bino-net-01', 'Bino-net-02'] >>> mynetwork=mynetworks[1] >>> mynetwork['name'] 'Bino-net-02' >>> body_value = { ... 'port': { ... 'admin_state_up': True, ... 'device_id': myrouter['id'], ... 'name': 'Bino-rtr-01-02', ... 'network_id': mynetwork['id'], ... } ... } >>> response = nt.create_port(body=body_value) >>> response {'port': {'allowed_address_pairs': [], 'extra_dhcp_opts': [], 'updated_at': '2018-12-10T01:44:10Z', 'device_owner': '', 'revision_number': 1, 'binding:profile': {}, 'port_security_enabled': True, 'fixed_ips': [{'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', 'ip_address': '192.168.202.6'}], 'id': 'a2a337af-3a37-4a9a-a4f1-ffaacdf9f881', 'security_groups': ['4bed540c-266d-4cc2-8225-3e02ccd89ff1'], 'binding:vif_details': {}, 'binding:vif_type': 'unbound', 'mac_address': 'fa:16:3e:05:aa:b5', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'DOWN', 'binding:host_id': '', 'description': '', 'tags': [], 'device_id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-rtr-01-02', 'admin_state_up': True, 'network_id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-10T01:44:10Z', 'binding:vnic_type': 'normal'}} >>> response['port']['status'] 'DOWN' ------ Looks like the port status still 'DOWN'. Sincerely -bino- On Sat, Dec 8, 2018 at 9:42 PM Slawomir Kaplonski wrote: > Hi, > > You shouldn’t create port with router as device owner. If You want to > connect port or subnet to router, there is proper method for that: > https://developer.openstack.org/api-ref/network/v2/?expanded=add-interface-to-router-detail#add-interface-to-router > > — > Slawek Kaplonski > Senior software engineer > Red Hat > > > Wiadomość napisana przez Bino Oetomo w dniu > 08.12.2018, o godz. 02:42: > > > > Dear All. > > > > I have no problem configuring network via Hosrizon-dasboard. > > > > I start playing with python for some task. > > I got succsess in creating network. > > I create a router, with one interface connected to existing > 'ext-network' .. success. > > > > But I fail when I try to add a port to that router for connecting to > existing internal network. > > > > Here is part of my python shell. > > > > -------------------- > > body_value = { > > > > > > 'port': { > > > > > > 'admin_state_up': True, > > > > > > 'device_owner': 'network:router_interface', > > > > > > 'device_id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', > > > > > > 'name': 'Bino-net-01-02', > > > > > > 'network_id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', > > > > > > 'binding:host_id': 'rocky-controller.mynet.net', > > > > > > 'binding:profile': {}, > > > > > > 'binding:vnic_type': 'normal', > > > > > > 'fixed_ips': [{ > > > > > > 'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', > > > > > > 'ip_address': '192.168.202.254' > > > > > > }], > > > > > > } > > } > > > > > > response > > = nt.create_port(body=body_value) > > > > response > > > > > > {'port': {'allowed_address_pairs': [], 'extra_dhcp_opts': [], > 'updated_at': '2018-12-07T08:10:24Z', 'device_owner': > 'network:router_interface', 'revision_number': 1, 'port_security_enabled': > False, 'binding:profile': {}, 'fixed_ips': [{'subnet_id': > 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', 'ip_address': '192.168.202.254'}], > 'id': 'd02eb0f0-663f-423f-af4e-c969ccb9dc25', 'security_groups': [], > 'binding:vif_details': {'port_filter': True, 'datapath_type': 'system', > 'ovs_hybrid_plug': True}, 'binding:vif_type': 'ovs', 'mac_address': > 'fa:16:3e:e2:9d:8f', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', > 'status': 'DOWN', 'binding:host_id': 'rocky-controller.mynet.net', > 'description': '', 'tags': [], 'device_id': > 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-net-01-02', > 'admin_state_up': True, 'network_id': > 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'tenant_id': > 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T08:10:24Z', > 'binding:vnic_type': 'normal'}} > > > > -------------------- > > 'status' always 'DOWN'. > > > > Kindly please give me some clue to fix this problem > > > > Note : Actualy I post same question on stackexchange : > https://stackoverflow.com/questions/53665795/openstack-python-neutronclient-creating-port-but-down > > > > Sincerely > > -bino- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ervikrant06 at gmail.com Mon Dec 10 02:54:27 2018 From: ervikrant06 at gmail.com (Vikrant Aggarwal) Date: Mon, 10 Dec 2018 08:24:27 +0530 Subject: [neutron] [octavia] Manual deployment step for octavia on packstack Message-ID: Hello Team, Do we have the steps documented somewhere to install octavia manually like we have for zun [1]? I have done the openstack deployment using packstack and now I want to install the octavia manually on it. I have done the following steps: # groupadd --system octavia # useradd --home-dir "/var/lib/octavia" --create-home --system --shell /bin/false -g octavia octavia # cd /var/lib/octavia/ # git clone https://github.com/openstack/octavia.git # chown -R octavia:octavia * # pip install -r requirements.txt # python setup.py install # openstack user create --domain default --password-prompt octavia # openstack role add --project service --user octavia admin # openstack service create --name octavia --description "Octavia Service" " Octavia Load Balancing Servic" # openstack endpoint create --region RegionOne "Octavia Load Balancing Servic" public http://10.121.19.50:9876/v1 # openstack endpoint create --region RegionOne "Octavia Load Balancing Servic" admin http://10.121.19.50:9876/v1 # openstack endpoint create --region RegionOne "Octavia Load Balancing Servic" internal http://10.121.19.50:9876/v1 Made the following changes in the configuration file. [root at packstack1 octavia(keystone_admin)]# diff etc/octavia.conf /etc/ octavia/octavia.conf 20,21c20,21 < # bind_host = 127.0.0.1 < # bind_port = 9876 --- > bind_host = 10.121.19.50 > bind_port = 9876 38c38 < # api_v2_enabled = True --- > # api_v2_enabled = False 64c64 < # connection = mysql+pymysql:// --- > connection = mysql+pymysql://octavia:octavia at 10.121.19.50/octavia 109c109 < # www_authenticate_uri = https://localhost:5000/v3 --- > www_authenticate_uri = https://10.121.19.50:5000/v3 111,114c111,114 < # auth_url = https://localhost:5000/v3 < # username = octavia < # password = password < # project_name = service --- > auth_url = https://10.121.19.50:35357/v3 > username = octavia > password = octavia > project_name = service 117,118c117,118 < # project_domain_name = Default < # user_domain_name = Default --- > project_domain_name = default > user_domain_name = default Generated the certificates using the script and copy the following certificates in octavia: [root at packstack1 octavia(keystone_admin)]# cd /etc/octavia/ [root at packstack1 octavia(keystone_admin)]# ls -lhrt total 28K -rw-r--r--. 1 octavia octavia 14K Dec 4 05:50 octavia.conf -rw-r--r--. 1 octavia octavia 1.7K Dec 4 05:55 client.key -rw-r--r--. 1 octavia octavia 989 Dec 4 05:55 client.csr -rw-r--r--. 1 octavia octavia 1.7K Dec 4 05:55 client.pem Can anyone please guide me about the further configuration? [1] https://docs.openstack.org/zun/latest/install/controller-install.html Thanks & Regards, Vikrant Aggarwal -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at bakeyournoodle.com Mon Dec 10 05:09:22 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Mon, 10 Dec 2018 16:09:22 +1100 Subject: [Release-job-failures] Tag of openstack/freezer failed In-Reply-To: References: Message-ID: <20181210050922.GC32339@thor.bakeyournoodle.com> On Mon, Dec 10, 2018 at 04:49:47AM +0000, zuul at openstack.org wrote: > Build failed. > > - publish-openstack-releasenotes-python3 http://logs.openstack.org/31/31314e5e707bfe4933e1046dd0a18f1daa8cca6c/tag/publish-openstack-releasenotes-python3/bc14e14/ : POST_FAILURE in 2m 31s Looking at the logs I think this failed in create-afs-token[1]. If I Understand correctly this means the releasenotes weren't published but they will upon the next successful publish run. Yours Tony. [1] http://logs.openstack.org/31/31314e5e707bfe4933e1046dd0a18f1daa8cca6c/tag/publish-openstack-releasenotes-python3/bc14e14/job-output.txt.gz#_2018-12-10_04_49_23_454869 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From bino at jogjacamp.co.id Mon Dec 10 05:13:34 2018 From: bino at jogjacamp.co.id (Bino Oetomo) Date: Mon, 10 Dec 2018 12:13:34 +0700 Subject: Add port to router using python Message-ID: Dear All. My openstack installation version is 'rocky'. I tried to create a new port and add it to existing router. Got no error messages, but the port status always 'DOWN'. -------------------------------------- >>> myrouter {'status': 'ACTIVE', 'external_gateway_info': {'network_id': 'd10dd06a-0425-49eb-a8ba-85abf55ac0f5', 'enable_snat': True, 'external_fixed_ips': [{'subnet_id': '4639e018-1cc1-49cc-89d4-4cad49bd4b89', 'ip_address': '10.10.10.2'}]}, 'availability_zone_hints': [], 'availability_zones': ['nova'], 'description': '', 'tags': [], 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T07:24:41Z', 'admin_state_up': True, 'distributed': False, 'updated_at': '2018-12-07T07:58:02Z', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'flavor_id': None, 'revision_number': 10, 'routes': [], 'ha': False, 'id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-rtr-01'} ```>>> mynetworks=[n for n in netlist['networks'] if n['name'].startswith('Bino')] >>> mynetworks [{'provider:physical_network': 'viavlan', 'ipv6_address_scope': None, 'revision_number': 7, 'port_security_enabled': True, 'mtu': 1500, 'id': '942675f6-fd5e-4bb2-ba43-487be992ff4e', 'router:external': False, 'availability_zone_hints': [], 'availability_zones': ['nova'], 'ipv4_address_scope': None, 'shared': False, 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'ACTIVE', 'subnets': ['5373bc35-a90f-4793-a912-801920e47769'], 'description': '', 'tags': [], 'updated_at': '2018-12-07T07:50:27Z', 'provider:segmentation_id': 2037, 'name': 'Bino-net-01', 'admin_state_up': True, 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T07:28:00Z', 'provider:network_type': 'vlan'}, {'provider:physical_network': 'viavlan', 'ipv6_address_scope': None, 'revision_number': 6, 'port_security_enabled': True, 'mtu': 1500, 'id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'router:external': False, 'availability_zone_hints': [], 'availability_zones': ['nova'], 'ipv4_address_scope': None, 'shared': False, 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'ACTIVE', 'subnets': ['c71a86a3-f9a8-4e60-828e-5d6f87e58ac9'], 'description': '', 'tags': [], 'updated_at': '2018-12-07T07:49:59Z', 'provider:segmentation_id': 2002, 'name': 'Bino-net-02', 'admin_state_up': True, 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T07:29:52Z', 'provider:network_type': 'vlan'}] >>> print([n['name'] for n in mynetworks]) ['Bino-net-01', 'Bino-net-02'] >>> mynetwork=mynetworks[1] >>> mynetwork['name'] 'Bino-net-02' >>> body_value = { ... 'port': { ... 'admin_state_up': True, ... 'device_id': myrouter['id'], ... 'name': 'Bino-rtr-01-02', ... 'network_id': mynetwork['id'], ... } ... } >>> response = nt.create_port(body=body_value) >>> response {'port': {'allowed_address_pairs': [], 'extra_dhcp_opts': [], 'updated_at': '2018-12-10T01:44:10Z', 'device_owner': '', 'revision_number': 1, 'binding:profile': {}, 'port_security_enabled': True, 'fixed_ips': [{'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', 'ip_address': '192.168.202.6'}], 'id': 'a2a337af-3a37-4a9a-a4f1-ffaacdf9f881', 'security_groups': ['4bed540c-266d-4cc2-8225-3e02ccd89ff1'], 'binding:vif_details': {}, 'binding:vif_type': 'unbound', 'mac_address': 'fa:16:3e:05:aa:b5', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'DOWN', 'binding:host_id': '', 'description': '', 'tags': [], 'device_id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-rtr-01-02', 'admin_state_up': True, 'network_id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-10T01:44:10Z', 'binding:vnic_type': 'normal'}} >>> response['port']['status'] 'DOWN' -------------------------------------- Kindly please give me some clues to fic this problem Sincerely -bino- -------------- next part -------------- An HTML attachment was scrubbed... URL: From bino at jogjacamp.co.id Mon Dec 10 05:19:00 2018 From: bino at jogjacamp.co.id (Bino Oetomo) Date: Mon, 10 Dec 2018 12:19:00 +0700 Subject: apologize Message-ID: Dear All. I apologize for my double post. I just realize after I write the second one. The first one is posted before I joint the list, it's http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000745.html And the second one is : http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000760.html Sincerely -bino- -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Mon Dec 10 07:21:34 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 10 Dec 2018 16:21:34 +0900 Subject: [openstack-dev] [nova][cinder][qa] Should we enable multiattach in tempest-full? In-Reply-To: <81332221-db29-5525-6f3f-a000c93e4939@gmail.com> References: <4f1bf485-f663-69ae-309e-ab9286e588e1@gmail.com> <1538382375.30016.0@smtp.office365.com> <1662fd96896.121bfdb2733507.842876450808135416@ghanshyammann.com> <81332221-db29-5525-6f3f-a000c93e4939@gmail.com> Message-ID: <16796fe1b6c.c3e4e009192453.8132097322747769095@ghanshyammann.com> ---- On Tue, 02 Oct 2018 00:28:51 +0900 Matt Riedemann wrote ---- > On 10/1/2018 8:37 AM, Ghanshyam Mann wrote: > > +1 on adding multiattach on integrated job. It is always good to cover more features in integrate-gate instead of separate jobs. These tests does not take much time, it should be ok to add in tempest-full [1]. We should make only really slow test as 'slow' otherwise it should be fine to run in tempest-full. > > > > I thought adding tempest-slow on cinder was merged but it is not[2] > > > > [1]http://logs.openstack.org/80/606880/2/check/nova-multiattach/7f8681e/job-output.txt.gz#_2018-10-01_10_12_55_482653 > > [2]https://review.openstack.org/#/c/591354/2 > > Actually it will be enabled in both tempest-full and tempest-slow, > because there is also a multiattach test marked as 'slow': > TestMultiAttachVolumeSwap. > > I'll push patches today. While reviewing your patch and checking multiattach slow test on stable branch as part of tempest-slow job, I found that tempest-slow (tempest-multinode-full) job does not run on nova stable branches (even nova .zuul.yaml has that job to run for stable branch) which we can say bug on Tempest side because tempest-slow job definition is to run only on master [1]. I am trying to enable that for all stable branches[2]. I am getting few failure on tempest-slow (tempest-multinode-full) for stable branches which might take time to fix and till then let's keep nova-multiattach on stable branches and remove only for master. [1] https://github.com/openstack/tempest/blob/a32467c4c515dff325e6b4b5ce7af24a0b7a9961/.zuul.yaml#L270 [2] https://review.openstack.org/#/q/topic:tempest-multinode-slow-stable+(status:open+OR+status:merged) -gmann > > -- > > 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 skaplons at redhat.com Mon Dec 10 08:01:10 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Mon, 10 Dec 2018 09:01:10 +0100 Subject: [Neutron] In-Reply-To: References: <05CDC301-26EF-4554-B595-9FB950BD8731@redhat.com> Message-ID: <67369879-1E4B-4B84-9744-ED094F499F21@redhat.com> Hi, If You want to attach port/subnet to router, please don’t do this with „create_port()” method only - it’s not enough. You should use add_interface_to_router() method if You are using Openstack SDK: https://github.com/openstack/openstacksdk/blob/master/openstack/network/v2/_proxy.py#L2441 or add_interface_router() method from neutron client: https://github.com/openstack/python-neutronclient/blob/d8cb1472c867d2a308e26abea0b0a01f1d6629a1/neutronclient/v2_0/client.py#L918 — Slawek Kaplonski Senior software engineer Red Hat > Wiadomość napisana przez Bino Oetomo w dniu 10.12.2018, o godz. 03:04: > > Dear All, > > As suggested by Slawek Kaplonski, I tried this. > > ----------- > > >>> myrouter > {'status': 'ACTIVE', 'external_gateway_info': {'network_id': 'd10dd06a-0425-49eb-a8ba-85abf55ac0f5', 'enable_snat': True, 'external_fixed_ips': [{'subnet_id': '4639e018-1cc1-49cc-89d4-4cad49bd4b89', 'ip_address': '10.10.10.2'}]}, 'availability_zone_hints': [], 'availability_zones': ['nova'], 'description': '', 'tags': [], 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T07:24:41Z', 'admin_state_up': True, 'distributed': False, 'updated_at': '2018-12-07T07:58:02Z', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'flavor_id': None, 'revision_number': 10, 'routes': [], 'ha': False, 'id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-rtr-01'} > > ```>>> mynetworks=[n for n in netlist['networks'] if n['name'].startswith('Bino')] > >>> mynetworks > [{'provider:physical_network': 'viavlan', 'ipv6_address_scope': None, 'revision_number': 7, 'port_security_enabled': True, 'mtu': 1500, 'id': '942675f6-fd5e-4bb2-ba43-487be992ff4e', 'router:external': False, 'availability_zone_hints': [], 'availability_zones': ['nova'], 'ipv4_address_scope': None, 'shared': False, 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'ACTIVE', 'subnets': ['5373bc35-a90f-4793-a912-801920e47769'], 'description': '', 'tags': [], 'updated_at': '2018-12-07T07:50:27Z', 'provider:segmentation_id': 2037, 'name': 'Bino-net-01', 'admin_state_up': True, 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T07:28:00Z', 'provider:network_type': 'vlan'}, {'provider:physical_network': 'viavlan', 'ipv6_address_scope': None, 'revision_number': 6, 'port_security_enabled': True, 'mtu': 1500, 'id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'router:external': False, 'availability_zone_hints': [], 'availability_zones': ['nova'], 'ipv4_address_scope': None, 'shared': False, 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'ACTIVE', 'subnets': ['c71a86a3-f9a8-4e60-828e-5d6f87e58ac9'], 'description': '', 'tags': [], 'updated_at': '2018-12-07T07:49:59Z', 'provider:segmentation_id': 2002, 'name': 'Bino-net-02', 'admin_state_up': True, 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T07:29:52Z', 'provider:network_type': 'vlan'}] > >>> print([n['name'] for n in mynetworks]) > ['Bino-net-01', 'Bino-net-02'] > >>> mynetwork=mynetworks[1] > >>> mynetwork['name'] > 'Bino-net-02' > >>> body_value = { > ... 'port': { > ... 'admin_state_up': True, > ... 'device_id': myrouter['id'], > ... 'name': 'Bino-rtr-01-02', > ... 'network_id': mynetwork['id'], > ... } > ... } > >>> response = nt.create_port(body=body_value) > >>> response > {'port': {'allowed_address_pairs': [], 'extra_dhcp_opts': [], 'updated_at': '2018-12-10T01:44:10Z', 'device_owner': '', 'revision_number': 1, 'binding:profile': {}, 'port_security_enabled': True, 'fixed_ips': [{'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', 'ip_address': '192.168.202.6'}], 'id': 'a2a337af-3a37-4a9a-a4f1-ffaacdf9f881', 'security_groups': ['4bed540c-266d-4cc2-8225-3e02ccd89ff1'], 'binding:vif_details': {}, 'binding:vif_type': 'unbound', 'mac_address': 'fa:16:3e:05:aa:b5', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'DOWN', 'binding:host_id': '', 'description': '', 'tags': [], 'device_id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-rtr-01-02', 'admin_state_up': True, 'network_id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-10T01:44:10Z', 'binding:vnic_type': 'normal'}} > >>> response['port']['status'] > 'DOWN' > ------ > > Looks like the port status still 'DOWN'. > > Sincerely > -bino- > > > On Sat, Dec 8, 2018 at 9:42 PM Slawomir Kaplonski wrote: > Hi, > > You shouldn’t create port with router as device owner. If You want to connect port or subnet to router, there is proper method for that: https://developer.openstack.org/api-ref/network/v2/?expanded=add-interface-to-router-detail#add-interface-to-router > > — > Slawek Kaplonski > Senior software engineer > Red Hat > > > Wiadomość napisana przez Bino Oetomo w dniu 08.12.2018, o godz. 02:42: > > > > Dear All. > > > > I have no problem configuring network via Hosrizon-dasboard. > > > > I start playing with python for some task. > > I got succsess in creating network. > > I create a router, with one interface connected to existing 'ext-network' .. success. > > > > But I fail when I try to add a port to that router for connecting to existing internal network. > > > > Here is part of my python shell. > > > > -------------------- > > body_value = { > > > > > > 'port': { > > > > > > 'admin_state_up': True, > > > > > > 'device_owner': 'network:router_interface', > > > > > > 'device_id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', > > > > > > 'name': 'Bino-net-01-02', > > > > > > 'network_id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', > > > > > > 'binding:host_id': 'rocky-controller.mynet.net', > > > > > > 'binding:profile': {}, > > > > > > 'binding:vnic_type': 'normal', > > > > > > 'fixed_ips': [{ > > > > > > 'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', > > > > > > 'ip_address': '192.168.202.254' > > > > > > }], > > > > > > } > > } > > > > > > response > > = nt.create_port(body=body_value) > > > > response > > > > > > {'port': {'allowed_address_pairs': [], 'extra_dhcp_opts': [], 'updated_at': '2018-12-07T08:10:24Z', 'device_owner': 'network:router_interface', 'revision_number': 1, 'port_security_enabled': False, 'binding:profile': {}, 'fixed_ips': [{'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', 'ip_address': '192.168.202.254'}], 'id': 'd02eb0f0-663f-423f-af4e-c969ccb9dc25', 'security_groups': [], 'binding:vif_details': {'port_filter': True, 'datapath_type': 'system', 'ovs_hybrid_plug': True}, 'binding:vif_type': 'ovs', 'mac_address': 'fa:16:3e:e2:9d:8f', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'DOWN', 'binding:host_id': 'rocky-controller.mynet.net', 'description': '', 'tags': [], 'device_id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-net-01-02', 'admin_state_up': True, 'network_id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T08:10:24Z', 'binding:vnic_type': 'normal'}} > > > > -------------------- > > 'status' always 'DOWN'. > > > > Kindly please give me some clue to fix this problem > > > > Note : Actualy I post same question on stackexchange : https://stackoverflow.com/questions/53665795/openstack-python-neutronclient-creating-port-but-down > > > > Sincerely > > -bino- > From bino at jogjacamp.co.id Mon Dec 10 08:57:44 2018 From: bino at jogjacamp.co.id (Bino Oetomo) Date: Mon, 10 Dec 2018 15:57:44 +0700 Subject: [Neutron] In-Reply-To: <67369879-1E4B-4B84-9744-ED094F499F21@redhat.com> References: <05CDC301-26EF-4554-B595-9FB950BD8731@redhat.com> <67369879-1E4B-4B84-9744-ED094F499F21@redhat.com> Message-ID: Dear Sir. You are right. It works like a charm I realy appreciate your help Sincerely -bino- On Mon, Dec 10, 2018 at 3:02 PM Slawomir Kaplonski wrote: > Hi, > > If You want to attach port/subnet to router, please don’t do this with > „create_port()” method only - it’s not enough. > You should use add_interface_to_router() method if You are using Openstack > SDK: > https://github.com/openstack/openstacksdk/blob/master/openstack/network/v2/_proxy.py#L2441 > or add_interface_router() method from neutron client: > https://github.com/openstack/python-neutronclient/blob/d8cb1472c867d2a308e26abea0b0a01f1d6629a1/neutronclient/v2_0/client.py#L918 > > — > Slawek Kaplonski > Senior software engineer > Red Hat > > > Wiadomość napisana przez Bino Oetomo w dniu > 10.12.2018, o godz. 03:04: > > > > Dear All, > > > > As suggested by Slawek Kaplonski, I tried this. > > > > ----------- > > > > >>> myrouter > > {'status': 'ACTIVE', 'external_gateway_info': {'network_id': > 'd10dd06a-0425-49eb-a8ba-85abf55ac0f5', 'enable_snat': True, > 'external_fixed_ips': [{'subnet_id': > '4639e018-1cc1-49cc-89d4-4cad49bd4b89', 'ip_address': '10.10.10.2'}]}, > 'availability_zone_hints': [], 'availability_zones': ['nova'], > 'description': '', 'tags': [], 'tenant_id': > 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T07:24:41Z', > 'admin_state_up': True, 'distributed': False, 'updated_at': > '2018-12-07T07:58:02Z', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', > 'flavor_id': None, 'revision_number': 10, 'routes': [], 'ha': False, 'id': > 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-rtr-01'} > > > > ```>>> mynetworks=[n for n in netlist['networks'] if > n['name'].startswith('Bino')] > > >>> mynetworks > > [{'provider:physical_network': 'viavlan', 'ipv6_address_scope': None, > 'revision_number': 7, 'port_security_enabled': True, 'mtu': 1500, 'id': > '942675f6-fd5e-4bb2-ba43-487be992ff4e', 'router:external': False, > 'availability_zone_hints': [], 'availability_zones': ['nova'], > 'ipv4_address_scope': None, 'shared': False, 'project_id': > 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'ACTIVE', 'subnets': > ['5373bc35-a90f-4793-a912-801920e47769'], 'description': '', 'tags': [], > 'updated_at': '2018-12-07T07:50:27Z', 'provider:segmentation_id': 2037, > 'name': 'Bino-net-01', 'admin_state_up': True, 'tenant_id': > 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T07:28:00Z', > 'provider:network_type': 'vlan'}, {'provider:physical_network': 'viavlan', > 'ipv6_address_scope': None, 'revision_number': 6, 'port_security_enabled': > True, 'mtu': 1500, 'id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', > 'router:external': False, 'availability_zone_hints': [], > 'availability_zones': ['nova'], 'ipv4_address_scope': None, 'shared': > False, 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': > 'ACTIVE', 'subnets': ['c71a86a3-f9a8-4e60-828e-5d6f87e58ac9'], > 'description': '', 'tags': [], 'updated_at': '2018-12-07T07:49:59Z', > 'provider:segmentation_id': 2002, 'name': 'Bino-net-02', 'admin_state_up': > True, 'tenant_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': > '2018-12-07T07:29:52Z', 'provider:network_type': 'vlan'}] > > >>> print([n['name'] for n in mynetworks]) > > ['Bino-net-01', 'Bino-net-02'] > > >>> mynetwork=mynetworks[1] > > >>> mynetwork['name'] > > 'Bino-net-02' > > >>> body_value = { > > ... 'port': { > > ... 'admin_state_up': True, > > ... 'device_id': myrouter['id'], > > ... 'name': 'Bino-rtr-01-02', > > ... 'network_id': mynetwork['id'], > > ... } > > ... } > > >>> response = nt.create_port(body=body_value) > > >>> response > > {'port': {'allowed_address_pairs': [], 'extra_dhcp_opts': [], > 'updated_at': '2018-12-10T01:44:10Z', 'device_owner': '', > 'revision_number': 1, 'binding:profile': {}, 'port_security_enabled': True, > 'fixed_ips': [{'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', > 'ip_address': '192.168.202.6'}], 'id': > 'a2a337af-3a37-4a9a-a4f1-ffaacdf9f881', 'security_groups': > ['4bed540c-266d-4cc2-8225-3e02ccd89ff1'], 'binding:vif_details': {}, > 'binding:vif_type': 'unbound', 'mac_address': 'fa:16:3e:05:aa:b5', > 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', 'status': 'DOWN', > 'binding:host_id': '', 'description': '', 'tags': [], 'device_id': > 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-rtr-01-02', > 'admin_state_up': True, 'network_id': > 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'tenant_id': > 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-10T01:44:10Z', > 'binding:vnic_type': 'normal'}} > > >>> response['port']['status'] > > 'DOWN' > > ------ > > > > Looks like the port status still 'DOWN'. > > > > Sincerely > > -bino- > > > > > > On Sat, Dec 8, 2018 at 9:42 PM Slawomir Kaplonski > wrote: > > Hi, > > > > You shouldn’t create port with router as device owner. If You want to > connect port or subnet to router, there is proper method for that: > https://developer.openstack.org/api-ref/network/v2/?expanded=add-interface-to-router-detail#add-interface-to-router > > > > — > > Slawek Kaplonski > > Senior software engineer > > Red Hat > > > > > Wiadomość napisana przez Bino Oetomo w dniu > 08.12.2018, o godz. 02:42: > > > > > > Dear All. > > > > > > I have no problem configuring network via Hosrizon-dasboard. > > > > > > I start playing with python for some task. > > > I got succsess in creating network. > > > I create a router, with one interface connected to existing > 'ext-network' .. success. > > > > > > But I fail when I try to add a port to that router for connecting to > existing internal network. > > > > > > Here is part of my python shell. > > > > > > -------------------- > > > body_value = { > > > > > > > > > 'port': { > > > > > > > > > 'admin_state_up': True, > > > > > > > > > 'device_owner': 'network:router_interface', > > > > > > > > > 'device_id': 'a616dcc0-1f72-4424-9494-4d13b42445ee', > > > > > > > > > 'name': 'Bino-net-01-02', > > > > > > > > > 'network_id': 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', > > > > > > > > > 'binding:host_id': 'rocky-controller.mynet.net', > > > > > > > > > 'binding:profile': {}, > > > > > > > > > 'binding:vnic_type': 'normal', > > > > > > > > > 'fixed_ips': [{ > > > > > > > > > 'subnet_id': 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', > > > > > > > > > 'ip_address': '192.168.202.254' > > > > > > > > > }], > > > > > > > > > } > > > } > > > > > > > > > response > > > = nt.create_port(body=body_value) > > > > > > response > > > > > > > > > {'port': {'allowed_address_pairs': [], 'extra_dhcp_opts': [], > 'updated_at': '2018-12-07T08:10:24Z', 'device_owner': > 'network:router_interface', 'revision_number': 1, 'port_security_enabled': > False, 'binding:profile': {}, 'fixed_ips': [{'subnet_id': > 'c71a86a3-f9a8-4e60-828e-5d6f87e58ac9', 'ip_address': '192.168.202.254'}], > 'id': 'd02eb0f0-663f-423f-af4e-c969ccb9dc25', 'security_groups': [], > 'binding:vif_details': {'port_filter': True, 'datapath_type': 'system', > 'ovs_hybrid_plug': True}, 'binding:vif_type': 'ovs', 'mac_address': > 'fa:16:3e:e2:9d:8f', 'project_id': 'c0b89f614b5a457cb5acef8fe8c2b320', > 'status': 'DOWN', 'binding:host_id': 'rocky-controller.mynet.net', > 'description': '', 'tags': [], 'device_id': > 'a616dcc0-1f72-4424-9494-4d13b42445ee', 'name': 'Bino-net-01-02', > 'admin_state_up': True, 'network_id': > 'dfc8ed54-106d-48d0-8b45-cbd3cf0fbb79', 'tenant_id': > 'c0b89f614b5a457cb5acef8fe8c2b320', 'created_at': '2018-12-07T08:10:24Z', > 'binding:vnic_type': 'normal'}} > > > > > > -------------------- > > > 'status' always 'DOWN'. > > > > > > Kindly please give me some clue to fix this problem > > > > > > Note : Actualy I post same question on stackexchange : > https://stackoverflow.com/questions/53665795/openstack-python-neutronclient-creating-port-but-down > > > > > > Sincerely > > > -bino- > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From honjo.rikimaru at po.ntt-tx.co.jp Mon Dec 10 09:23:26 2018 From: honjo.rikimaru at po.ntt-tx.co.jp (Rikimaru Honjo) Date: Mon, 10 Dec 2018 18:23:26 +0900 Subject: [horizon]Javascript files contains "conf" in their file name Message-ID: Hello, I have a question about configuration of horizon. There are some javascript files contains "conf" in their file name in horizon repository.[1] Are they configuration files like local_settings.py for panels implemented in Angular? Sometimes, should I edit these files if I'd like to customize my horizon? [1] e.g. horizon/static/framework/conf/conf.js, openstack_dashboard/static/app/core/conf/conf.module.js Best Regards, -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Rikimaru Honjo E-mail:honjo.rikimaru at po.ntt-tx.co.jp From ifatafekn at gmail.com Mon Dec 10 10:28:01 2018 From: ifatafekn at gmail.com (Ifat Afek) Date: Mon, 10 Dec 2018 12:28:01 +0200 Subject: [vitrage] Removing the static-physical datasource Message-ID: Hi, Just wanted to give you a heads-up that we are about to remove the static-physical datasource [1][2] that was deprecated in Queens [3]. Please use the static datasource [4] instead. Thanks, Ifat [1] https://review.openstack.org/#/c/624033/ [2] https://review.openstack.org/#/c/624031/ [3] https://docs.openstack.org/releasenotes/vitrage/queens.html [4] https://docs.openstack.org/vitrage/latest/contributor/static-config.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-philippe at evrard.me Mon Dec 10 11:05:17 2018 From: jean-philippe at evrard.me (Jean-Philippe Evrard) Date: Mon, 10 Dec 2018 12:05:17 +0100 Subject: [loci][openstack-helm] How to add some agent to loci images In-Reply-To: References: <2ED125CF-8AA3-4D81-8C0F-FDF8ED1EF2F0@openstack.org> Message-ID: <824f452a87980106abca82287074083c8bb69201.camel@evrard.me> > > > On Fri, 2018-12-07 at 10:21 +0900, SIRI KIM wrote: > > our objetive: add neutron-lbaas & neutron-fwaas chart to openstack- > helm > upstream. > problem: we need this loci image to push lbaas and fwaas chart into > upstream repo. In order to pass osh gating, we need to have neutron- > lbaas & > > > neutron-fwaas agent image available for openstack-helm project. Yeah this seems more an OSH issue on how to properly leverage's LOCI feature (and publishing a series of images) than a request to LOCI directly I'd say :) I am currently refactoring how OSH is building LOCI images, but the idea of it would be pretty generic. It would be extensible by having a few extra environment variables before calling the build script (which basically do a series of docker builds). In those environment variables you could pass which projects to build, which variables to pass to LOCI (for example, "build me an octavia image with x"), what would be the registry of your choice. The result would be an updated/published image of your choice (on your dockerhub's user for example), which could then be used in your chart. Note: I don't think it's a good idea to build lbaas nowadays, as it's kinda the past :) Regards, Jean-Philippe Evrard (evrardjp) From smooney at redhat.com Mon Dec 10 12:20:03 2018 From: smooney at redhat.com (Sean Mooney) Date: Mon, 10 Dec 2018 12:20:03 +0000 Subject: [Neutron][ovs-dpdk] In-Reply-To: <889103638.17479349.1544372137196.JavaMail.zimbra@brilliant.com.bd> References: <889103638.17479349.1544372137196.JavaMail.zimbra@brilliant.com.bd> Message-ID: <4cd66cc1f4352baceb7516e432c9d872a5d40d72.camel@redhat.com> On Sun, 2018-12-09 at 22:15 +0600, Zilhazur Rahman wrote: > Hi > > I am writing for the first time to the mailing list of openstack, I am trying to deploy ovs-dpdk to have better > traffic throughput for NFV. Could you please share any tutorial link for standard ovs-dpdk deployment. On the other > hand, openstack site says this " Expect performance degradation of services using tap devices: these devices do not > support DPDK. Example services include DVR, FWaaS, or LBaaS. " but I need to have LBaaS and DVR ( to have direct > external connectivity on compute) , what could be done in this case? LBaaS perfromance will only be impacted in the legacy model where the loadblancer was network nodes using the linux kernel. if you are usign LBaas in the default mode where it creates a nova vm and run haproxy or another loadblancer on it then it will preform well provided the vm uses a hugepage backed flavor. if you do not use hugepages you will have no network connectivity. DVR is tricker as ther is really no way to avoid the fact it does routing in the kernel which not only disables all dpdk accleration but causes all dpdk acllerated port to experice a performance degrdation as it is more costly to service non dpdk interface therefor consuming more cpu resouces that would have been used to service the dpdk cores. using an sdn conttoler like ovn is one way to avoid this over head as it will route using openflow. i know that some people in neutron were looking at enableing openflow routing in ml2 ovs but i dont know what the state of that is. in terms of installation juju and triplo both have support for ovs-dpdk. kolla-ansible also has some support but i have not been maintaining it for the last 14 months or so as such i dont know how stable it is. from a netron perspective the only thing you need to change in the neutron configs is the ovs datapath to netdev in the ovs section of /etc/neutron/plugins/ml2/ml2_conf.ini on the nova side you shoule create a seperate host aggreage and new flavor with hugepages. from an ovs perspecitve if you are doing this by hand there are some docs directly form ovs to compile and install it from source https://github.com/openvswitch/ovs/blob/master/Documentation/intro/install/dpdk.rst but i would generally recommend installing it from your distro it will reduce teh performace a little but it will be better tested and easier to maintian. the main things to know is that ovs-dpdk will also require hugepages, you will have to configure a pmd core mask for the dpdk threads to use and all bridge must be of datapath type netdev with patch ports interconnecting them. finally if you want to use vxlan or other tunnels you must assign the tunnel endpoint ip to the ovs bridge with the dpdk phyical interface, otherwise your tunneled traffic will not be acclerated. > > > Regards > Zilhaz > From joshua.hesketh at gmail.com Mon Dec 10 12:32:27 2018 From: joshua.hesketh at gmail.com (Joshua Hesketh) Date: Mon, 10 Dec 2018 23:32:27 +1100 Subject: On trust and risk, Australia's Assistance and Access Bill In-Reply-To: References: <20181207190926.z6fnjnevoh66yrqf@yuggoth.org> Message-ID: Thank you all for your support. It is a difficult and unfortunate state of affairs for Australia. To me this highlights the need and strength of open source and I am proud to be a part of this community. Cheers, Josh On Sat, Dec 8, 2018 at 6:26 AM Michael McCune wrote: > On Fri, Dec 7, 2018 at 2:12 PM Jeremy Stanley wrote: > > > > I've seen concern expressed in OpenStack and other free/libre open > > source software communities over the recent passage of the > > "Assistance and Access Bill 2018" by the Australian Parliament, and > > just want to say that I appreciate the trust relationships we've all > > built with our colleagues in many countries, including Australia. As > > someone who doesn't particularly agree with many of the laws passed > > in his own country, while I'm not going to encourage civil > > disobedience, I do respect that many have shown preference for it > > over compelled compromise of our community's established trust. I, > > for one, don't wish to return to the "bad old days" of the crypto > > wars, when major projects like OpenBSD refused contributions from > > citizens and residents of the USA. It's bad for project morale, > > excludes valuable input from people with a variety of perspectives, > > and it's just downright inefficient too. > > > > The unfortunate truth is that anyone can be pressured at any time to > > derail, backdoor or otherwise compromise software and systems. A new > > law in one country doesn't change that. There are frequent news > > stories about government agencies installing covert interfaces in > > enterprise and consumer electronic devices alike through compulsion > > of those involved in their programming, manufacture and > > distribution. There's evidence of major standards bodies being > > sidetracked and steered into unwittingly approving flawed > > specifications which influential actors already know ways to > > circumvent. Over the course of my career I've had to make personal > > choices regarding installation and maintenance of legally-mandated > > systems for spying on customers and users. All we can ever hope for > > is that the relationships, systems and workflows we create are as > > resistant as possible to these sorts of outside influences. > > > > Sure, ejecting people from important or sensitive positions within > > the project based on their nationality might be a way to send a > > message to a particular government, but the problem is bigger than > > just one country and we'd really all need to be removed from our > > posts for pretty much the same reasons. This robust community of > > trust and acceptance we've fostered is not a risk, it's another line > > of defense against erosion of our ideals and principles. Entrenched > > concepts like open design and public review help to shield us from > > these situations, and while there is no perfect protection it seems > > to me that secret compromise under our many watchful eyes is a much > > harder task than doing so behind the closed doors of proprietary > > systems development. > > > > I really appreciate all the Australians who toil tirelessly to make > > OpenStack better, and am proud to call them friends and colleagues. > > I certainly don't want them to feel any need to resign from their > > valuable work because they're worried the rest of us can no longer > > trust them. > > -- > > Jeremy Stanley > > ++ > > well said. thank you for stating this so eloquently. > > peace o/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bence.romsics at gmail.com Mon Dec 10 13:49:47 2018 From: bence.romsics at gmail.com (Bence Romsics) Date: Mon, 10 Dec 2018 14:49:47 +0100 Subject: [neutron] bug deputy report for week of December 3 Message-ID: Hi Neutrinos, As I was the bug deputy, here comes the report for last week. (undecided) https://bugs.launchpad.net/neutron/+bug/1807153 Race condition in metering agent when creating iptable managers for router namespaces. In need of attention from experts of metering and dvr. haleyb volunteered in irc. https://bugs.launchpad.net/neutron/+bug/1807157 Metering doesn't work for DVR routers on compute nodes. In need of attention from experts of metering and dvr. haleyb volunteered in irc. (critical) https://bugs.launchpad.net/neutron/+bug/1807239 Race condition with DPDK + trunk ports when instance port is deleted then quickly recreated. Fix proposed: https://review.openstack.org/623275 (high) none (medium) https://bugs.launchpad.net/neutron/+bug/1806770 DHCP Agent should not release DHCP lease when client ID is not set on port. Fix proposed: https://review.openstack.org/623066 https://bugs.launchpad.net/neutron/+bug/1807396 With many VMs on the same tenant, the L3 ip neigh add is too slow. Fix proposed: https://review.openstack.org/581360. Change owner is asking for help with (ie. takeover of) the change. (low) https://bugs.launchpad.net/neutron/+bug/1805991 IP Route: subnet's host_houtes attribute and router's routes accept the invalidate subnets. Fix proposed: https://review.openstack.org/623420 https://bugs.launchpad.net/neutron/+bug/1806032 neutron doesn't prevent the network update from external to internal when floatingIPs present. First fix proposal was abandoned. Bence Romsics will propose another fix. https://bugs.launchpad.net/neutron/+bug/1807128 Table name in "add_ip_rule" can be a string. Fix proposed: https://review.openstack.org/623182 https://bugs.launchpad.net/neutron/+bug/1807421 Open vSwitch hardware offloading in neutron updates. Fishing for a new contributor over doc improvement. :-) https://bugs.launchpad.net/neutron/+bug/1805132 bulk creation of security group rules fails StaleDataError. Confirmed, but not yet analyzed. (incomplete) https://bugs.launchpad.net/neutron/+bug/1807382 DNSMASQ wrong addresses allocated after changing DHCP Clients between Neutron vRouters NET https://bugs.launchpad.net/neutron/+bug/1807483 networksegments table in neutron can not be cleared automatically https://bugs.launchpad.net/neutron/+bug/1807673 Networking (neutron) concepts in neutron (rfe) https://bugs.launchpad.net/neutron/+bug/1806052 Changing segmentation_id of existing network should be allowed https://bugs.launchpad.net/neutron/+bug/1806316 Add RPC query API to l2pop for FDB resync https://bugs.launchpad.net/neutron/+bug/1806390 Distributed DHCP agent Cheers, Bence Romsics irc: rubasov From fungi at yuggoth.org Mon Dec 10 14:01:56 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 10 Dec 2018 14:01:56 +0000 Subject: [Release-job-failures] Tag of openstack/freezer failed In-Reply-To: <20181210050922.GC32339@thor.bakeyournoodle.com> References: <20181210050922.GC32339@thor.bakeyournoodle.com> Message-ID: <20181210140155.3np3gfjzgbwlxpwm@yuggoth.org> On 2018-12-10 16:09:22 +1100 (+1100), Tony Breeds wrote: [...] > I think this failed in create-afs-token [...] I concur, and the most common cause for that particular error is if the afsd daemon for OpenAFS isn't running (failed to start, crashed, et cetera). Indeed, this job ran from the ze12 Zuul executor we just brought on line at the end of last week, and it looks like we missed a bootstrapping step. I've brought it back down for the time being while I make sure it's got the right kernel booted and the corresponding openafs.ko LKM built/loaded. Thanks for spotting this!!! -- 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 bathanhtlu at gmail.com Mon Dec 10 14:20:21 2018 From: bathanhtlu at gmail.com (=?UTF-8?B?VGjDoG5oIE5ndXnhu4VuIELDoQ==?=) Date: Mon, 10 Dec 2018 21:20:21 +0700 Subject: [oslo] How to use library "oslo.messaging" Message-ID: Dear all, I have a question about "library oslo.messaging". How can i use this librabry to write simple program listen event on Openstack (like Nova, Cinder)? I had read on docs, nova support "oslo_messaging_notifications" to send message via RabbitMQ, so I’m try to use this library but it seem very hard for me. *Nguyễn Bá Thành* *Mobile*: 0128 748 0391 *Email*: bathanhtlu at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From luisa.arches at nokia.com Mon Dec 10 14:35:03 2018 From: luisa.arches at nokia.com (Arches, Maria (Nokia - HU/Budapest)) Date: Mon, 10 Dec 2018 14:35:03 +0000 Subject: [nova] Fail to detach vhostuser vif type from VM Message-ID: Hello all, I tried to detach a vhostuser vif from VM. My network setup is neutron+ ovs dpdk and using Libvirt/KVM. I'm using Openstack Queens. Network interface was unplugged but was not removed from libvirt/VM. I also created a bug for this in Launchpad. Wrote here to find/discuss possible solutions. https://bugs.launchpad.net/nova/+bug/1807340 I got the following logs from nova-compute: 2018-12-10 12:29:49.008 3223 INFO os_vif [req-ffd43a33-b0b9-4b4d-a7ce-700b7aee2822 7f6d35b7b85042daa470658debca14c3 b8668325f4fa4b9085fd2ac43170dd42 - default default] Successfully unplugged vif VIFVHostUser(active=True,address=fa:16:3e:ca:4e:16,has_traffic_filtering=False,id=90ca01ab-9a43-4d5f-b0bd-cb334d07e22b,mode='server',network=Network(e108697b-f031-45cb-bf47-6031c69afd4b),path='/var/run/openvswitch/vhu90ca01ab-9a',plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_delete=False,vif_name='vhu90ca01ab-9a') 2018-12-10 12:29:49.011 3223 WARNING nova.virt.libvirt.driver [req-ffd43a33-b0b9-4b4d-a7ce-700b7aee2822 7f6d35b7b85042daa470658debca14c3 b8668325f4fa4b9085fd2ac43170dd42 - default default] [instance: a4dd7fb5-d234-4b2a-9ebd-b1e3f657ac3e] Detaching interface fa:16:3e:ca:4e:16 failed because the device is no longer found on the guest. Tried to investigate further the code and it seems that get_interface_cfg() does not find any interface that matches because target_dev is not the same. https://github.com/openstack/nova/blob/0f4cecb70c2d11593f18818523a61059c0196d88/nova/virt/libvirt/guest.py#L247 vhostuser backend does not set any value for target_dev, while LibvirtGuestInterface does. https://github.com/openstack/nova/blob/0f4cecb70c2d11593f18818523a61059c0196d88/nova/virt/libvirt/designer.py#L151 https://github.com/openstack/nova/blob/0f4cecb70c2d11593f18818523a61059c0196d88/nova/virt/libvirt/config.py#L1467 First question is, is it on purpose that vhostuser vif does not set any target_dev? Possible solution that I can think of: 1. Add setting of target_dev in set_vif_host_backend_vhostuser_config() 2. Skipping target_dev check when vif type is vhostuser. I also noticed, that when a vhostuser interface type is attached to VM during run-time there was no target dev present in the virsh dumpxml. First interface is created during creation. Second one, was attached run-time.
From doug at doughellmann.com Mon Dec 10 15:02:09 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 10 Dec 2018 10:02:09 -0500 Subject: [Release-job-failures] Tag of openstack/freezer failed In-Reply-To: <20181210050922.GC32339@thor.bakeyournoodle.com> References: <20181210050922.GC32339@thor.bakeyournoodle.com> Message-ID: Tony Breeds writes: > On Mon, Dec 10, 2018 at 04:49:47AM +0000, zuul at openstack.org wrote: >> Build failed. >> >> - publish-openstack-releasenotes-python3 http://logs.openstack.org/31/31314e5e707bfe4933e1046dd0a18f1daa8cca6c/tag/publish-openstack-releasenotes-python3/bc14e14/ : POST_FAILURE in 2m 31s > > Looking at the logs I think this failed in create-afs-token[1]. If I > Understand correctly this means the releasenotes weren't published but > they will upon the next successful publish run. > > Yours Tony. > > [1] http://logs.openstack.org/31/31314e5e707bfe4933e1046dd0a18f1daa8cca6c/tag/publish-openstack-releasenotes-python3/bc14e14/job-output.txt.gz#_2018-12-10_04_49_23_454869 > _______________________________________________ > Release-job-failures mailing list > Release-job-failures at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures Yes, that job should run again as part of the post pipeline when another patch is merged in the openstack/freezer repository. The published docs should reflect the newly tagged version. -- Doug From doug at doughellmann.com Mon Dec 10 15:08:23 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 10 Dec 2018 10:08:23 -0500 Subject: [oslo] How to use library "oslo.messaging" In-Reply-To: References: Message-ID: Thành Nguyễn Bá writes: > Dear all, > I have a question about "library oslo.messaging". How can i use this > librabry to write simple program listen event on Openstack (like Nova, > Cinder)? I had read on docs, nova support "oslo_messaging_notifications" to > send message via RabbitMQ, so I’m try to use this library but it seem very > hard for me. > > *Nguyễn Bá Thành* > > *Mobile*: 0128 748 0391 > > *Email*: bathanhtlu at gmail.com There is a notification "listener" built into the library in the oslo_messaging.notify.listener module. The source file [1] includes a basic example of using it. You may also find the ceilometer source code interesting, since it consumes notifications using the "batch" listener [2]. [1] http://git.openstack.org/cgit/openstack/oslo.messaging/tree/oslo_messaging/notify/listener.py [2] http://git.openstack.org/cgit/openstack/ceilometer/tree/ceilometer/messaging.py -- Doug From juliaashleykreger at gmail.com Mon Dec 10 16:21:18 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Mon, 10 Dec 2018 08:21:18 -0800 Subject: [ironic] Meetings cancelled for the holdiays, Resuming January 7th Message-ID: Greetings ironic folks and all of those interested in ironic! As discussed in this week's meeting[1], we are cancelling our next three meetings and resuming our weekly meeting on January 7th. This time of year, the ironic community tends to enter a bit of a quiet period. Starting next week, contributor availability will begin to wind down for the holidays. Those of us that will be hanging around tend to shift gears to focused feature work and often pay a little less attention to IRC and the mailing list. If core reviewers are needed, the `ironic-cores` tag can be used in the #openstack-ironic channel, and we will do our best to marshal reviewers in the event of an emergency. During this time, our weekly priority review list[1] will go into autopilot. Contributors are welcome to add items they feel need review visibility and we will prune merged items out as needed. If there are any questions, please feel free to reach out to me or post to the mailing list. Thanks, -Julia [1] http://eavesdrop.openstack.org/meetings/ironic/2018/ironic.2018-12-10-15.00.log.html [2] https://etherpad.openstack.org/p/IronicWhiteBoard starting at line 112. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Mon Dec 10 16:59:46 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Mon, 10 Dec 2018 10:59:46 -0600 Subject: [openstack-dev] [nova][cinder][qa] Should we enable multiattach in tempest-full? In-Reply-To: <16796fe1b6c.c3e4e009192453.8132097322747769095@ghanshyammann.com> References: <4f1bf485-f663-69ae-309e-ab9286e588e1@gmail.com> <1538382375.30016.0@smtp.office365.com> <1662fd96896.121bfdb2733507.842876450808135416@ghanshyammann.com> <81332221-db29-5525-6f3f-a000c93e4939@gmail.com> <16796fe1b6c.c3e4e009192453.8132097322747769095@ghanshyammann.com> Message-ID: <408eff57-be20-5a58-ef2d-f1f3d4b17bfc@gmail.com> On 12/10/2018 1:21 AM, Ghanshyam Mann wrote: > I am getting few failure on tempest-slow (tempest-multinode-full) for stable branches which might take time to fix and till > then let's keep nova-multiattach on stable branches and remove only for master. Bug https://bugs.launchpad.net/cinder/+bug/1807723/ is blocking removing the nova-multiattach job from master. Something is going on with TestMultiAttachVolumeSwap when there are two hosts. That test is marked slow but runs in nova-multiattach which also runs slow tests, and nova-multiattach is a single node job. With tempest change: https://review.openstack.org/#/c/606978/ TestMultiAttachVolumeSwap gets run in the tempest-slow job which is multi-node, and as a result I'm seeing race failures in that test. I've put my notes into the bug, but I need some help from Cinder at this point. I thought I had initially identified a very obvious problem in nova, but now I think nova is working as designed (although very confusing) and we're hitting a race during the swap where deleting the attachment record for the volume/server we swapped *from* is failing saying the target is still active. The fact we used to run this on a single-node job likely masked some race issue. As far as next steps, we could: 1. Move forward with removing nova-multiattach but skip TestMultiAttachVolumeSwap until bug 1807723 is fixed. 2. Try to workaround bug 1807723 in Tempest by creating the multiattach volume and servers on the same host (by pinning them to an AZ). 3. Add some retry logic to Cinder and hope it is just a race failure when the volume is connected to servers across different hosts. Ultimately this is the best scenario but I'm just not yet sure if that is really the issue or if something is really messed up in the volume backend when this fails where retries wouldn't help. -- Thanks, Matt From kgiusti at gmail.com Mon Dec 10 17:00:07 2018 From: kgiusti at gmail.com (Ken Giusti) Date: Mon, 10 Dec 2018 12:00:07 -0500 Subject: [oslo] How to use library "oslo.messaging" In-Reply-To: References: Message-ID: On Mon, Dec 10, 2018 at 9:24 AM Thành Nguyễn Bá wrote: > Dear all, > I have a question about "library oslo.messaging". How can i use this > librabry to write simple program listen event on Openstack (like Nova, > Cinder)? I had read on docs, nova support "oslo_messaging_notifications" to > send message via RabbitMQ, so I’m try to use this library but it seem very > hard for me. > > *Nguyễn Bá Thành* > > *Mobile*: 0128 748 0391 > > *Email*: bathanhtlu at gmail.com > Nguyen - just following up to the wider group: I've got a few simple example clients/servers that do RPC and Notifications. Check them out on my git repo: https://github.com/kgiusti/oslo-messaging-clients If folks find them useful I'll be more than glad to move them to the oslo.messaging repo (an examples directory, perhaps?) -- Ken Giusti (kgiusti at gmail.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Mon Dec 10 17:16:00 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 10 Dec 2018 12:16:00 -0500 Subject: [oslo] How to use library "oslo.messaging" In-Reply-To: References: Message-ID: Ken Giusti writes: > On Mon, Dec 10, 2018 at 9:24 AM Thành Nguyễn Bá > wrote: > >> Dear all, >> I have a question about "library oslo.messaging". How can i use this >> librabry to write simple program listen event on Openstack (like Nova, >> Cinder)? I had read on docs, nova support "oslo_messaging_notifications" to >> send message via RabbitMQ, so I’m try to use this library but it seem very >> hard for me. >> >> *Nguyễn Bá Thành* >> >> *Mobile*: 0128 748 0391 >> >> *Email*: bathanhtlu at gmail.com >> > > Nguyen - just following up to the wider group: > > I've got a few simple example clients/servers that do RPC and Notifications. > Check them out on my git repo: > > https://github.com/kgiusti/oslo-messaging-clients > > If folks find them useful I'll be more than glad to move them to the > oslo.messaging repo (an examples directory, perhaps?) +1 -- maybe we can even include them in the published docs, if the code samples aren't too long > > -- > Ken Giusti (kgiusti at gmail.com) -- Doug From miguel at mlavalle.com Mon Dec 10 17:31:13 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Mon, 10 Dec 2018 11:31:13 -0600 Subject: [openstack-dev] [Neutron] Propose Nate Johnston for Neutron core In-Reply-To: References: Message-ID: Hi Stackers, It has been a week since I posted Nate's nomination to the Neutron core team and I have only received positive feedback. As a consequence, let's welcome Nate to the team. Congratulations and keep up the good work! Best regards Miguel On Tue, Dec 4, 2018 at 8:57 AM Brian Haley wrote: > Big +1 from me, keep up the great work Nate! > > -Brian > > On 12/3/18 4:38 PM, Miguel Lavalle wrote: > > Hi Stackers, > > > > I want to nominate Nate Johnston (irc:njohnston) as a member of the > > Neutron core team. Nate started contributing to Neutron back in the > > Liberty cycle. One of the highlight contributions of that early period > > is his collaboration with others to implement DSCP QoS rules > > (https://review.openstack.org/#/c/251738/). After a hiatus of a few > > cycles, we were lucky to have Nate come back to the community during the > > Rocky cycle. Since then, he has been a driving force in the adoption in > > Neutron of Oslo Versioned Objects, the "Run under Python 3 by default" > > community wide initiative and the optimization of ports creation in bulk > > to better support containerized workloads. He is a man with a wide range > > of interests, who is not afraid of expressing his opinions in any of > > them. The quality and number of his code reviews during the Stein cycle > > is on par with the leading members of the core team: > > http://stackalytics.com/?module=neutron-group. I especially admire his > > ability to forcefully handle disagreement in a friendly and easy going > > manner. > > > > On top of all that, he graciously endured me as his mentor over the past > > few months. For all these reasons, I think he is ready to join the team > > and we will be very lucky to have him as a fully voting core. > > > > I will keep this nomination open for a week as customary. > > > > Thank you > > > > Miguel > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguel at mlavalle.com Mon Dec 10 17:32:38 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Mon, 10 Dec 2018 11:32:38 -0600 Subject: [openstack-dev] [Neutron] Propose Hongbin Lu for Neutron core In-Reply-To: <726003a1-da0b-f542-00b2-a7900cc308d9@gmail.com> References: <726003a1-da0b-f542-00b2-a7900cc308d9@gmail.com> Message-ID: Hi Stackers, It has been a week since I posted Hongbin's nomination to the Neutron core team and I have only received positive feedback. As a consequence, let's welcome Nate to the team. Congratulations and keep up the good work! Best regards Miguel On Tue, Dec 4, 2018 at 8:57 AM Brian Haley wrote: > Big +1 from me as well! > > -Brian > > On 12/3/18 5:14 PM, Miguel Lavalle wrote: > > Hi Stackers, > > > > I want to nominate Hongbin Lu (irc: hongbin) as a member of the Neutron > > core team. Hongbin started contributing to the OpenStack community in > > the Liberty cycle. Over time, he made great contributions in helping the > > community to better support containers by being core team member and / > > or PTL in projects such as Zun and Magnum. An then, fortune played in > > our favor and Hongbin joined the Neutron team in the Queens cycle. Since > > then, he has made great contributions such as filters validation in the > > ReST API, PF status propagation to to VFs (ports) in SR-IOV environments > > and leading the forking of RYU into the os-ken OpenStack project, which > > provides key foundational functionality for openflow. He is not a man > > who wastes words, but when he speaks up, his opinions are full of > > insight. This is reflected in the quality of his code reviews, which in > > number are on par with the leading members of the core team: > > http://stackalytics.com/?module=neutron-group. Even though Hongbin > > leaves in Toronto, he speaks Mandarin Chinese and was born and raised in > > China. This is a big asset in helping the Neutron team to incorporate > > use cases from that part of the world. > > > > Hongbin spent the past few months being mentored by Slawek Kaplonski, > > who has reported that Hongbin is ready for the challenge of being a core > > team member. I (and other core team members) concur. > > > > I will keep this nomination open for a week as customary. > > > > Thank you > > > > Miguel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Mon Dec 10 17:33:19 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 10 Dec 2018 17:33:19 +0000 Subject: [infra] OpenDev feedback forum session summary Message-ID: <20181210173319.lnqn2ydshtmpwkjj@yuggoth.org> Wednesday afternoon at the OpenStack Summit we met to discuss the plan for the upcoming transition of the OpenStack Infrastructure team to an independent effort named OpenDev. Notes were recorded at https://etherpad.openstack.org/p/BER-opendev-feedback-and-missing-features and form the basis of the summary with follows. For those unfamiliar with this topic, the announcement at http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html provides some background and context. Much of what follows may be a reiteration of things also covered there, so please excuse any redundancy on my part. To start out, we (re)announced that we have chosen a name (OpenDev) and a domain (opendev.org), so can more effectively plan for DNS changes for most of the services we currently host under the "legacy" (for us) openstack.org domain. It was also pointed out that while we expect to maintain convenience redirects and aliases from old hostnames for all services we reasonably can so as to minimize disruption, there will still be some unavoidable discontinuities for users from time to time as we work through this. We talked for a bit about options for decentralizing GitHub repository mirroring so that the current team no longer needs to maintain it, and how to put it in control of people who want to manage those organizations there for themselves instead. Doing this with a job in Zuul's post pipeline (using encrypted secrets for authentication) was suggested as one possible means to avoid users all maintaining their own separate automation to accomplish the same thing. Interest in bare metal CI nodes in nodepool was brought up again. To reiterate, there's not really any technical reason we can't use them, more that prior offers to donate access to Nova/Ironic-managed nodes for this purpose never panned out. If you work for an organization which maintains a "bare metal cloud" we could reach over the open Internet and you'd consider carving out some of your capacity for our CI system, please do get in touch with us! We spent a bit of time covering user concerns about the transition to OpenDev and what reassurances we ought to provide. For starters, our regular contributors and root systems administrators will continue to be just as reachable and responsive as ever via IRC and mailing lists, even if the names of the channels and MLs may change as part of this transition. Similarly, our operations will remain as open and transparent as they are today... really nothing about how we maintain our systems is changing substantively as a part of the OpenDev effort, though certainly the ways in which we maintain our systems do still change and evolve over time as we seek to improve them so that will of course continue to be the case. Paul Belanger raised concerns that announcing OpenDev could result in a flood of new requests to host more projects. Well, really, I think that's what we hope for. I (apparently) pointed out that even when StackForge was first created back at the beginning of 2012, there wasn't much restriction as to what we would be willing to host. As interest in OpenDev spreads to new audiences, interest in participating in its maintenance and development should too grow. That said, we acknowledge that there are some scalability bottlenecks and manual/human steps in certain aspects of new project onboarding for now, so should be very up-front with any new projects about that fact. We're also not planning for any big marketing push to seek out additional projects at this point, but are happy to talk to any who discover us and are interested in the services we offer. Next, Paul Belanger brought up the possibility of "bring your own cloud" options for projects providing CI resources themselves. While we expect nodepool to have support for tenant-specific resources in the not-too-distant future, Jim Blair and Clark Boylan agreed the large pool of generic resources we operate with now is really where we see a lot of benefit and ability to drive efficiencies of scale. Then Monty Taylor talked for a while, according to the notes in the pad, and said things about earmarked resources potentially requiring a sort of "commons tax" or... something. Jim Rollenhagen asked whether we would potentially start to test and gate projects on GitHub too rather than just our Gerrit. Clark Boylan and Jim Blair noted that the current situation where we're testing pull requests for Kata's repositories is a bit of an experiment in that direction today and the challenges we've faced suggest that, while we'll likely continue to act as a third-party CI system for some projects hosted on GitHub (we're doing that with Ansible for example), we've discovered that trying to enforce gating in code review platforms we don't also control is not likely something we'll want to continue in the long term. It came up that our earlier ideas for flattening our Git namespace to reduce confusion and minimize future repository renames is now not looking as attractive. Instead we're probably going to need to embrace an explosion of new namespaces and find better ways to cope with the pain of renames in Gerrit as projects want to move between them over time. We're planning to only run one Gerrit for simplicity, so artificially creating "tenants" in it through prefixes in repository names is really the simplest solution we have to avoid different projects stepping on one another's toes with their name choices. Then we got into some policy discussions about namespace creation. Jim Blair talked about the potential to map Git/Gerrit repository namespaces to distinct Zuul tenants, and someone (might have been me? I was fairly jet-lagged and so don't really remember) asked about who decides what the requirements are for projects to create repositories in a particular namespace. In the case of OpenStack, the answer is almost certainly the OpenStack Technical Committee or at least some group to whom they delegate that responsibility. The OpenStack TC needs to discuss fairly early what its policies are for the "openstack" namespace (whether existing unofficial projects will be allowed to remain, whether addition of new unofficial projects will be allowed there) as well as whether it wants to allow creation of multiple separate namespaces for official OpenStack projects. The suggestion of nested "deep" namespaces like openstack/nova/nova came up at this point too. We also resolved that we need to look back into the project rename plugin for Gerrit. The last time we evaluated it, there wasn't much there. We've heard it's improved with newer Gerrit releases, but if it's still lacking we might want to contribute to making it more effective so we can handle the inevitable renames more easily in the future. And finally, as happens with most forum sessions, we stopped abruptly because we ran over and it was Kendall Nelson's turn to start getting ops feedback for the Contributor Guide. ;) -- 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 Mon Dec 10 17:36:59 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Mon, 10 Dec 2018 11:36:59 -0600 Subject: [openstack-dev] [Neutron] Propose Hongbin Lu for Neutron core In-Reply-To: References: <726003a1-da0b-f542-00b2-a7900cc308d9@gmail.com> Message-ID: Hi Stackers, It has been a week since I posted Hongbin's nomination to the Neutron core team and I have only received positive feedback. As a consequence, let's welcome Hongbin to the team. Congratulations and keep up the good work! Best regards On Mon, Dec 10, 2018 at 11:32 AM Miguel Lavalle wrote: > Hi Stackers, > > It has been a week since I posted Hongbin's nomination to the Neutron core > team and I have only received positive feedback. As a consequence, let's > welcome Nate to the team. Congratulations and keep up the good work! > > Best regards > > Miguel > > On Tue, Dec 4, 2018 at 8:57 AM Brian Haley wrote: > >> Big +1 from me as well! >> >> -Brian >> >> On 12/3/18 5:14 PM, Miguel Lavalle wrote: >> > Hi Stackers, >> > >> > I want to nominate Hongbin Lu (irc: hongbin) as a member of the Neutron >> > core team. Hongbin started contributing to the OpenStack community in >> > the Liberty cycle. Over time, he made great contributions in helping >> the >> > community to better support containers by being core team member and / >> > or PTL in projects such as Zun and Magnum. An then, fortune played in >> > our favor and Hongbin joined the Neutron team in the Queens cycle. >> Since >> > then, he has made great contributions such as filters validation in the >> > ReST API, PF status propagation to to VFs (ports) in SR-IOV >> environments >> > and leading the forking of RYU into the os-ken OpenStack project, which >> > provides key foundational functionality for openflow. He is not a man >> > who wastes words, but when he speaks up, his opinions are full of >> > insight. This is reflected in the quality of his code reviews, which in >> > number are on par with the leading members of the core team: >> > http://stackalytics.com/?module=neutron-group. Even though Hongbin >> > leaves in Toronto, he speaks Mandarin Chinese and was born and raised >> in >> > China. This is a big asset in helping the Neutron team to incorporate >> > use cases from that part of the world. >> > >> > Hongbin spent the past few months being mentored by Slawek Kaplonski, >> > who has reported that Hongbin is ready for the challenge of being a >> core >> > team member. I (and other core team members) concur. >> > >> > I will keep this nomination open for a week as customary. >> > >> > Thank you >> > >> > Miguel >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From frode.nordahl at canonical.com Mon Dec 10 17:56:23 2018 From: frode.nordahl at canonical.com (Frode Nordahl) Date: Mon, 10 Dec 2018 18:56:23 +0100 Subject: [charms] No meetings until January 7th Message-ID: Dear charmers and community at large, We will be taking a break from our weekly meetings and will reconvene after the holidays. First weekly meeting will be Monday January 7th. In the meantime, do not hesitate to contact us in #openstack-charmers on Freenode or by sending e-mail to the OpenStack Discuss mailinglist using the [charms] tag in the subject line. Cheers all! -- Frode Nordahl -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.beisner at canonical.com Mon Dec 10 17:59:53 2018 From: ryan.beisner at canonical.com (Ryan Beisner) Date: Mon, 10 Dec 2018 11:59:53 -0600 Subject: [charms] No meetings until January 7th In-Reply-To: References: Message-ID: Thanks, Frode. Happy festive season to everyone! :-) On Mon, Dec 10, 2018 at 11:58 AM Frode Nordahl wrote: > Dear charmers and community at large, > > We will be taking a break from our weekly meetings and will reconvene > after the holidays. > > First weekly meeting will be Monday January 7th. > > In the meantime, do not hesitate to contact us in #openstack-charmers on > Freenode or by sending e-mail to the OpenStack Discuss mailinglist using > the [charms] tag in the subject line. > > Cheers all! > > -- > Frode Nordahl > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Mon Dec 10 17:23:56 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 10 Dec 2018 18:23:56 +0100 Subject: Openstacl magnum Queens api error Message-ID: Hi All, I installed magnum in queens with Centos 7 and I am facing with the same issue descrive here: https://bugs.launchpad.net/magnum/+bug/1701381 Please, anyone solved it? Regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From openstack at nemebean.com Mon Dec 10 18:33:03 2018 From: openstack at nemebean.com (Ben Nemec) Date: Mon, 10 Dec 2018 12:33:03 -0600 Subject: [dev][goal][python3][qa][devstack][ptl] changing devstack's python 3 behavior In-Reply-To: References: Message-ID: On 12/5/18 1:27 PM, Doug Hellmann wrote: > Today devstack requires each project to explicitly indicate that it can > be installed under python 3, even when devstack itself is running with > python 3 enabled. > > As part of the python3-first goal, I have proposed a change to devstack > to modify that behavior [1]. With the change in place, when devstack > runs with python3 enabled all services are installed under python 3, > unless explicitly listed as not supporting python 3. > > If your project has a devstack plugin or runs integration or functional > test jobs that use devstack, please test your project with the patch > (you can submit a trivial change to your project and use Depends-On to > pull in the devstack change). > > [1] https://review.openstack.org/#/c/622415/ > For Oslo, do we need to test every project or can we just do the devstack plugins and maybe one other as a sanity check? Since we don't own any devstack services this doesn't directly affect us, right? From doug at doughellmann.com Mon Dec 10 18:43:42 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 10 Dec 2018 13:43:42 -0500 Subject: [dev][goal][python3][qa][devstack][ptl] changing devstack's python 3 behavior In-Reply-To: References: Message-ID: Ben Nemec writes: > On 12/5/18 1:27 PM, Doug Hellmann wrote: >> Today devstack requires each project to explicitly indicate that it can >> be installed under python 3, even when devstack itself is running with >> python 3 enabled. >> >> As part of the python3-first goal, I have proposed a change to devstack >> to modify that behavior [1]. With the change in place, when devstack >> runs with python3 enabled all services are installed under python 3, >> unless explicitly listed as not supporting python 3. >> >> If your project has a devstack plugin or runs integration or functional >> test jobs that use devstack, please test your project with the patch >> (you can submit a trivial change to your project and use Depends-On to >> pull in the devstack change). >> >> [1] https://review.openstack.org/#/c/622415/ >> > > For Oslo, do we need to test every project or can we just do the > devstack plugins and maybe one other as a sanity check? Since we don't > own any devstack services this doesn't directly affect us, right? Given that we've been testing nova and cinder under python 3 for a while now I think it's probably safe to assume Oslo is working OK. This change is mostly about the fact that we were failing to install *all* of the services under python 3 by default. The existing library forward-testing jobs should handle future testing because they will install all of the services as well as the library under test using python 3. If you want to be extra careful, you could propose a patch to some of the more complicated libs (oslo.messaging and oslo.service come to mind) that depends on the patch above to ensure that those libraries don't trigger failures in the jobs. -- Doug From mriedemos at gmail.com Mon Dec 10 19:04:43 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Mon, 10 Dec 2018 13:04:43 -0600 Subject: [openstack-dev] [nova][cinder][qa] Should we enable multiattach in tempest-full? In-Reply-To: <408eff57-be20-5a58-ef2d-f1f3d4b17bfc@gmail.com> References: <4f1bf485-f663-69ae-309e-ab9286e588e1@gmail.com> <1538382375.30016.0@smtp.office365.com> <1662fd96896.121bfdb2733507.842876450808135416@ghanshyammann.com> <81332221-db29-5525-6f3f-a000c93e4939@gmail.com> <16796fe1b6c.c3e4e009192453.8132097322747769095@ghanshyammann.com> <408eff57-be20-5a58-ef2d-f1f3d4b17bfc@gmail.com> Message-ID: <422e5f8f-39e2-5ac5-95c4-c40a4184d0af@gmail.com> On 12/10/2018 10:59 AM, Matt Riedemann wrote: > TestMultiAttachVolumeSwap gets run in the tempest-slow job which is > multi-node, and as a result I'm seeing race failures in that test. I've > put my notes into the bug, but I need some help from Cinder at this > point. I thought I had initially identified a very obvious problem in > nova, but now I think nova is working as designed (although very > confusing) and we're hitting a race during the swap where deleting the > attachment record for the volume/server we swapped *from* is failing > saying the target is still active. After more debugging, it looks like when deleting the servers, the volume in question that fails to delete isn't being properly detached by nova-compute, so the connection still exists when tempest tries to delete the volume and then it fails. I'm not sure what is going on here, it's almost as if something is wrong in the DB and we're not finding the appropriate BDM in the DB during the server delete so we never detach. -- Thanks, Matt From chris at openstack.org Mon Dec 10 19:33:29 2018 From: chris at openstack.org (Chris Hoge) Date: Mon, 10 Dec 2018 11:33:29 -0800 Subject: [k8s] K8s-SIG-OpenStack Update Message-ID: Hi everyone, a quick update on SIG-OpenStack/K8s as we head into KubeCon. To start with, today David and I are at the contributors summit and will be available to catch up on any topics you're interested in personally. The only other event we have scheduled for KubeCon is the SIG Intro session[1], Tuesday at 2:35 PM in room 3A/B. Given the smaller turnout for the deep-dive session in Copenhagen, we opted to skip the deep dive session this time around. As such, the first half of the intro will serve as the official SIG-Update, then we will reserve the end of the time for collaboration and planning. If you're involved or interested in SIG-OpenStack at all, please be sure to make this session. Following up from the OpenStack Summit, we had a productive planning session and set a number of goals and tasks[2]. Top at the list is the rotation of the SIG leadership. We're currently accepting nominations to replace David Lyle and Robert Morse. Many thanks to both for serving this last year. Currently we have nominations for * Flavio Percoco * Melvin Hillsman If you would like to be considered for SIG leadership, or would like to nominate someone, please do so in this thread or personally to me. Another item on the agenda is the rebooting of the SIG-OpenStack/K8s meetings. We will return the previously scheduled time of Wednesdays at 4 PM PT, starting January 9. I'll be sending out agendas and reminders as we get closer to the date, and will be asking some sub-project owners to attend and contribute updates. Work on the cloud provider and associated code has been moving well, and the external provider has moved well beyond the capabilities of the now-deprecated in-tree provider. If you haven't started your migration plan off of the in-tree code, please start doing so now. We're targeting full removal in 2019. The OpenStack provider for the new Cluster API has started, and we are looking for more developers to get involved. This, and a possible Ironic provider, are important for the SIG to be involved with in the coming year. If SIG-Cluster-Lifecycle reaches its goals, the Cluster API will be one of the most valuable developments for operators and users in 2019. Finally, I continue to engage with SIG-Cloud-Provider as a co-lead to advocate for consistent provider development. One of the original goals was to wind down all provider SIGS. However, as the SIGs move beyond just provider code to larger support of a user and developer community, this plan is being reconsidered. I'll keep you updated on the developments. Thanks to everyone for your ongoing contributions, and I'm looking forward to seeing the folks who are attending KubeCon in Seattle. -Chris [1] Intro OpenStack SIG: https://sched.co/Grbk [2] SIG-K8s Berlin Summit Session: https://etherpad.openstack.org/p/sig-k8s-2018-berlin-summit From ignaziocassano at gmail.com Mon Dec 10 18:51:17 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 10 Dec 2018 19:51:17 +0100 Subject: Fwd: Openstacl magnum Queens api error In-Reply-To: References: Message-ID: ---------- Forwarded message --------- From: Ignazio Cassano Date: Lun 10 Dic 2018 18:23 Subject: Openstacl magnum Queens api error To: OpenStack Operators Hi All, I installed magnum in queens with Centos 7 and I am facing with the same issue descrive here: https://bugs.launchpad.net/magnum/+bug/1701381 Please, anyone solved it? Regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From anteaya at anteaya.info Mon Dec 10 20:11:07 2018 From: anteaya at anteaya.info (Anita Kuno) Date: Mon, 10 Dec 2018 15:11:07 -0500 Subject: On trust and risk, Australia's Assistance and Access Bill In-Reply-To: <20181207190926.z6fnjnevoh66yrqf@yuggoth.org> References: <20181207190926.z6fnjnevoh66yrqf@yuggoth.org> Message-ID: On 2018-12-07 2:09 p.m., Jeremy Stanley wrote: > Over the course of my career I've had to make personal > choices regarding installation and maintenance of legally-mandated > systems for spying on customers and users. All we can ever hope for > is that the relationships, systems and workflows we create are as > resistant as possible to these sorts of outside influences. To that end, I'd like to ensure that the people I know and trust are aware that they can talk to me for any reason or no reason at all. I'm not on irc as much as I used to be but my email still works. I care about you and having to face this kind of decision is really really difficult. Doing the right thing is frequently the least popular choice and requires a lot of internal fortitude to stand up for what you know is right and accept the consequences of doing so. Anyone I already know who might be facing this situation is welcome to contact me and I'll listen with all the support I can muster. Sometimes it helps if you remember you aren't alone. Thanks Jeremy, Anita From moshele at mellanox.com Mon Dec 10 20:22:58 2018 From: moshele at mellanox.com (Moshe Levi) Date: Mon, 10 Dec 2018 20:22:58 +0000 Subject: [neutron][ironic] Add Support for Smart NIC with baremetal Message-ID: Hi all, We started working on specs to support baremetal with smart-nic see [1] and [2]. There are some open issue and different approaches that require further discussion see [3]. To resolve them I would like to propose a meeting tomorrow , December 11th, at 15:00 UTC. For those of you interested in joining please use [4] to connect. [1] - https://review.openstack.org/#/c/582767/ [2] - https://review.openstack.org/#/c/619920/ [3] - https://etherpad.openstack.org/p/BER-ironic-smartnics [4] - https://bluejeans.com/u/jkreger Thanks, Moshe (moshele) -------------- next part -------------- An HTML attachment was scrubbed... URL: From moshele at mellanox.com Mon Dec 10 20:19:54 2018 From: moshele at mellanox.com (Moshe Levi) Date: Mon, 10 Dec 2018 20:19:54 +0000 Subject: [neutron][ironic] Add Support for Smart NIC with baremetal Message-ID: Hi all, We started working on specs to support baremetal with smart-nic see [1] and [2]. There are some open issue and different approaches that require further discussion see [3]. To resolve them I would like to propose a meeting tomorrow , December 11th, at 15:00 UTC. For those of you interested in joining please use [4] to connect. [1] - https://review.openstack.org/#/c/582767/ [2] - https://review.openstack.org/#/c/619920/ [3] - https://etherpad.openstack.org/p/BER-ironic-smartnics [4] - https://bluejeans.com/u/jkreger Thanks, Moshe (moshele) -------------- next part -------------- An HTML attachment was scrubbed... URL: From openstack at nemebean.com Mon Dec 10 20:49:33 2018 From: openstack at nemebean.com (Ben Nemec) Date: Mon, 10 Dec 2018 14:49:33 -0600 Subject: [dev][goal][python3][qa][devstack][ptl] changing devstack's python 3 behavior In-Reply-To: References: Message-ID: On 12/10/18 12:43 PM, Doug Hellmann wrote: > Ben Nemec writes: > >> On 12/5/18 1:27 PM, Doug Hellmann wrote: >>> Today devstack requires each project to explicitly indicate that it can >>> be installed under python 3, even when devstack itself is running with >>> python 3 enabled. >>> >>> As part of the python3-first goal, I have proposed a change to devstack >>> to modify that behavior [1]. With the change in place, when devstack >>> runs with python3 enabled all services are installed under python 3, >>> unless explicitly listed as not supporting python 3. >>> >>> If your project has a devstack plugin or runs integration or functional >>> test jobs that use devstack, please test your project with the patch >>> (you can submit a trivial change to your project and use Depends-On to >>> pull in the devstack change). >>> >>> [1] https://review.openstack.org/#/c/622415/ >>> >> >> For Oslo, do we need to test every project or can we just do the >> devstack plugins and maybe one other as a sanity check? Since we don't >> own any devstack services this doesn't directly affect us, right? > > Given that we've been testing nova and cinder under python 3 for a while > now I think it's probably safe to assume Oslo is working OK. This change > is mostly about the fact that we were failing to install *all* of the > services under python 3 by default. The existing library forward-testing > jobs should handle future testing because they will install all of the > services as well as the library under test using python 3. > > If you want to be extra careful, you could propose a patch to some of > the more complicated libs (oslo.messaging and oslo.service come to mind) > that depends on the patch above to ensure that those libraries don't > trigger failures in the jobs. > Okay, sounds good. I have test patches proposed under https://review.openstack.org/#/q/topic:test-devstack-py3+(status:open+OR+status:merged) Some have already passed so I think we're in good shape, but we'll see what happens with the others. From rtidwell at suse.com Mon Dec 10 22:44:44 2018 From: rtidwell at suse.com (Ryan Tidwell) Date: Mon, 10 Dec 2018 16:44:44 -0600 Subject: [neutron] Subnet onboard and changing API definitions in neutron-lib Message-ID: <6043f799-3413-62f8-1f21-6e5f3dd5988a@suse.com> All, I alluded to some concerns about the current state of subnet onboard at the end of today's neutron team meeting. I felt the mailing list was probably the best starting point for a discussion, so here it goes :) As I'm dealing with the last loose ends, I'm starting to deal with the 'subnets' extension to the subnetpool resource on the API [1]. This has me scratching my head at what the intent of this is since there isn't much history to work with. When I look at the definition of the subnet onboard extension in neutron-lib, I can see two possible "meanings" of POST/PUT here: 1. Create a subnet from this subnetpool using the default prefix length of the subnet pool. 2. Onboard the given subnet into the subnet pool. In addition to this ambiguity around the usage of the API, I also have concerns that ONBOARD_SUBNET_SPECS as currently defined makes no sense for either case.  ONBOARD_SUBNET_SPECS requires that an id, network_id, and ip_version be sent on any request made. This seems unnecessary for both cases. Case 1 where we assume that we are using an alternate API to create a subnet is problematic in the following ways: - Specifying an ip_version is unnecessary because it can be inferred from the subnet pool - The definition as written doesn't seem to allow us to respond to the user with anything other than a UUID. The user then has to make a second call to actually go read the details like CIDR that are going to be useful for them going forward. - More importantly, we already have an API (and corresponding CLI) for creating subnets that works well and has much more flexibility than this provides. Why duplicate functionality here? Case 2 where we assume that we are onboarding a subnet is problematic in the following ways: - Specifying network_id and ip_version are unnecessary. These values can be read right off the subnet (which we would need to read for onboarding anyway), all that needs to be passed is the subnet UUID. - Again, we would be duplicating functionality here because we have already defined an API for onboarding a subnet in the ACTION_MAP [2] My intent is to figure out where to go from here to make this better and/or alleviate the confusion on my part so this feature can be wrapped up. Here is what I propose: Because subnet onboard is still incomplete and we are not claiming support for it yet, I am proposing we simply remove the 'subnets' extension to the subnetpools resource [3]. This simplifies the API and resolves the concerns I expressed above. It also allows us to quickly finish up subnet onboard without losing any of the desired functionality, namely the ability to move ("onboard") an existing subnet into a subnet pool (and by extension and address scope). The reason I am looking for input here is that it isn't clear to me whether the approach I'm suggesting is acceptable to the team given our policies around changing API definitions in neutron-lib. I'm not aware of a situation where we have had an unreleased feature and have discovered we don't like the API definition in neutron-lib (which has sat for quite a while unimplemented) and want to change it. I'm just not aware of any precedent for this situation, so I'm hoping the team has some thoughts on how best to move forward. For reference, the current review for subnet onboard is https://review.openstack.org/#/c/348080/. Any thoughts on this topic would be greatly appreciated by me, and hopefully this discussion can be useful to a broad audience going forward. -Ryan [1] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/subnet_onboard.py#L32 [2] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/subnet_onboard.py#L58 [3] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/subnet_onboard.py#L41 From juliaashleykreger at gmail.com Mon Dec 10 23:57:26 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Mon, 10 Dec 2018 15:57:26 -0800 Subject: [tc][forum] Summary for "community outreach when cultures, time zones, and languages differ" session Message-ID: Leading up to the Summit a number of us in the TC discussed how to improve outreach and thus communications outside of what we would consider our normal circles. The focus was how to better enable asynchronous communication. How do we share context? Ultimately we are talking about bridge building. The discussion went in many directions and we kind of started out discussing items that make our preferred communication methods a bit difficult. Thierry really focused us back to reality pointing out that "the earth is round". As the community has recognized before, time zones are absolutely a thing and that we shouldn't try and force people to be up at 3 AM to attend a meeting every week. As this discussion went on, a number of note worthy ideas began to surface. * Teams should likely reconsider meeting times periodically. Some teams have found success with alternating, but other teams have found that few attend the second time slot. * That it is easier to form a group of people in a specific time zone as they bring their established culture and don't have to integrate into another culture which is easier for them. The down side of this is that this leads to those people focusing on that specific project. * IRC is "super-addictive". ** The real time value of IRC is recognized, however on-boarding people into it can sometimes be a time consuming effort for some projects. ** Many, the TC included, have been trying to push more deep discussions to the mailing list or having someone summarize the outcome of conversations to the mailing list. ** IRC communication is often viewed as "too fast" of a discussion if your not a native speaker of the language being used in IRC. By the time you or software translates a statement, the discussion has moved on. * No matter what we do, there are two styles of communication that we need to be mindful of both asynchronous and synchronous communication. ** Some communities, such as the Linux kernel, have adopted fully asynchronous communication to handle the fact that the world is round. ** Projects have a tendency to use any communication method available. *** Some projects use etherpads for short term status on items, where others focus on its use for thought process preservation. *** Some projects try to drive such thought processes to an IRC discussion and then that often ends up as a discussion in gerrit. A point was eventually raised that meetings can still be useful, standing issues aside, as long as context is known in advance. The advance context does allow a team to determine in advance if a meeting is even required. Todo's and what can be done! * Simple reminders have apparently helped some meeting moderators keep people in attendance. * We reached consensus to encourage moderators to provide context in advance of meetings. This is in order to assist everyone to be more informed and hopefully shorten the exercise of trying to understand the issue as opposed to understand others impressions and reaching consensus. ** We also reached consensus that moderators should cancel a meeting if there is nothing on the agenda. * We want to encourage outreach messaging. This is not just the sub-communities making themselves known to the larger community, but raising awareness of "what is going on" or "what is new?" either in a project or portion of the community. Ultimately this falls into the category of "we do not know, what we do not know" and as such it is upon all of us to attempt to better communicate where we see gaps. As for specific action items, after re-reading the notes, I think that is up to us as a community to determine our next steps. We recorded no action items so I think further discussion may be needed. Perhaps all The etherpad can be found at https://etherpad.openstack.org/p/BER-tc-community-outreach. -Julia -------------- next part -------------- An HTML attachment was scrubbed... URL: From melwittt at gmail.com Tue Dec 11 00:01:28 2018 From: melwittt at gmail.com (melanie witt) Date: Mon, 10 Dec 2018 16:01:28 -0800 Subject: [nova][dev] Stein blueprint tracking status Message-ID: <75e08d07-f32f-7e49-b506-258bf1f619f8@gmail.com> Hey all, Similar to previous cycles, I've created an etherpad for tracking status of Approved blueprints for Stein: https://etherpad.openstack.org/p/nova-stein-blueprint-status Please feel free to use it to help with code reviews and make notes on the pad if there's info to add. I'll keep the pad updated as we progress through the rest of the cycle. Cheers, -melanie From hongbin.lu at huawei.com Tue Dec 11 00:14:13 2018 From: hongbin.lu at huawei.com (Hongbin Lu) Date: Tue, 11 Dec 2018 00:14:13 +0000 Subject: [neutron][stadium] Switch from ryu to os-ken Message-ID: <0957CD8F4B55C0418161614FEC580D6B308A805A@yyzeml704-chm.china.huawei.com> Hi all, Due to the advice that Ryu library won't be maintained at the end of 2018, the neutron team decided to fork the Ryu library and maintain the fork, which is called os-ken [1], from now on. Right now, both neutron [2] and neutron-dynamic-routing [3] is switching over to os-ken. If other projects want to do the same, please feel free to handout to the openstack-neutron channel for helps or information. You can also find more in here: https://blueprints.launchpad.net/neutron/+spec/ryu-framework-maintenace-transition . [1] https://github.com/openstack/os-ken [2] https://review.openstack.org/#/c/607008/ [3] https://review.openstack.org/#/c/608357/ Best regards, Hongbin -------------- next part -------------- An HTML attachment was scrubbed... URL: From bluejay.ahn at gmail.com Tue Dec 11 01:22:57 2018 From: bluejay.ahn at gmail.com (Jaesuk Ahn) Date: Tue, 11 Dec 2018 10:22:57 +0900 Subject: [loci][openstack-helm] How to add some agent to loci images In-Reply-To: <824f452a87980106abca82287074083c8bb69201.camel@evrard.me> References: <2ED125CF-8AA3-4D81-8C0F-FDF8ED1EF2F0@openstack.org> <824f452a87980106abca82287074083c8bb69201.camel@evrard.me> Message-ID: On Mon, Dec 10, 2018 at 8:11 PM Jean-Philippe Evrard < jean-philippe at evrard.me> wrote: > > > > On Fri, 2018-12-07 at 10:21 +0900, SIRI KIM wrote: > > > > our objetive: add neutron-lbaas & neutron-fwaas chart to openstack- > > helm > > upstream. > > problem: we need this loci image to push lbaas and fwaas chart into > > upstream repo. In order to pass osh gating, we need to have neutron- > > lbaas & > > > > neutron-fwaas agent image available for openstack-helm project. > > Yeah this seems more an OSH issue on how to properly leverage's LOCI > feature (and publishing a series of images) than a request to LOCI > directly I'd say :) > > > Hi, I do agree that this seems OSH issue, I will bring this up on osh weekly meeting. :) Thanks. -- *Jaesuk Ahn*, Ph.D. Software R&D Center, SK Telecom -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshua.hesketh at gmail.com Tue Dec 11 01:54:45 2018 From: joshua.hesketh at gmail.com (Joshua Hesketh) Date: Tue, 11 Dec 2018 12:54:45 +1100 Subject: [OpenStack-Infra] [infra] OpenDev feedback forum session summary In-Reply-To: <20181210173319.lnqn2ydshtmpwkjj@yuggoth.org> References: <20181210173319.lnqn2ydshtmpwkjj@yuggoth.org> Message-ID: Thank you for the update, it's much appreciated for those who couldn't make it :-) On Tue, Dec 11, 2018 at 4:34 AM Jeremy Stanley wrote: > Wednesday afternoon at the OpenStack Summit we met to discuss the > plan for the upcoming transition of the OpenStack Infrastructure > team to an independent effort named OpenDev. Notes were recorded at > https://etherpad.openstack.org/p/BER-opendev-feedback-and-missing-features > and form the basis of the summary with follows. > > For those unfamiliar with this topic, the announcement at > > http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html > provides some background and context. Much of what follows may be a > reiteration of things also covered there, so please excuse any > redundancy on my part. > > To start out, we (re)announced that we have chosen a name (OpenDev) > and a domain (opendev.org), so can more effectively plan for DNS > changes for most of the services we currently host under the > "legacy" (for us) openstack.org domain. It was also pointed out that > while we expect to maintain convenience redirects and aliases from > old hostnames for all services we reasonably can so as to minimize > disruption, there will still be some unavoidable discontinuities for > users from time to time as we work through this. > > We talked for a bit about options for decentralizing GitHub > repository mirroring so that the current team no longer needs to > maintain it, and how to put it in control of people who want to > manage those organizations there for themselves instead. Doing this > with a job in Zuul's post pipeline (using encrypted secrets for > authentication) was suggested as one possible means to avoid users > all maintaining their own separate automation to accomplish the same > thing. > > Interest in bare metal CI nodes in nodepool was brought up again. To > reiterate, there's not really any technical reason we can't use > them, more that prior offers to donate access to Nova/Ironic-managed > nodes for this purpose never panned out. If you work for an > organization which maintains a "bare metal cloud" we could reach > over the open Internet and you'd consider carving out some of your > capacity for our CI system, please do get in touch with us! > > We spent a bit of time covering user concerns about the transition > to OpenDev and what reassurances we ought to provide. For starters, > our regular contributors and root systems administrators will > continue to be just as reachable and responsive as ever via IRC and > mailing lists, even if the names of the channels and MLs may change > as part of this transition. Similarly, our operations will remain as > open and transparent as they are today... really nothing about how > we maintain our systems is changing substantively as a part of the > OpenDev effort, though certainly the ways in which we maintain our > systems do still change and evolve over time as we seek to improve > them so that will of course continue to be the case. > > Paul Belanger raised concerns that announcing OpenDev could result > in a flood of new requests to host more projects. Well, really, I > think that's what we hope for. I (apparently) pointed out that even > when StackForge was first created back at the beginning of 2012, > there wasn't much restriction as to what we would be willing to > host. As interest in OpenDev spreads to new audiences, interest in > participating in its maintenance and development should too grow. > That said, we acknowledge that there are some scalability > bottlenecks and manual/human steps in certain aspects of new project > onboarding for now, so should be very up-front with any new projects > about that fact. We're also not planning for any big marketing push > to seek out additional projects at this point, but are happy to talk > to any who discover us and are interested in the services we offer. > > Next, Paul Belanger brought up the possibility of "bring your own > cloud" options for projects providing CI resources themselves. While > we expect nodepool to have support for tenant-specific resources in > the not-too-distant future, Jim Blair and Clark Boylan agreed the > large pool of generic resources we operate with now is really where > we see a lot of benefit and ability to drive efficiencies of scale. > Then Monty Taylor talked for a while, according to the notes in the > pad, and said things about earmarked resources potentially requiring > a sort of "commons tax" or... something. > > Jim Rollenhagen asked whether we would potentially start to test and > gate projects on GitHub too rather than just our Gerrit. Clark > Boylan and Jim Blair noted that the current situation where we're > testing pull requests for Kata's repositories is a bit of an > experiment in that direction today and the challenges we've faced > suggest that, while we'll likely continue to act as a third-party CI > system for some projects hosted on GitHub (we're doing that with > Ansible for example), we've discovered that trying to enforce gating > in code review platforms we don't also control is not likely > something we'll want to continue in the long term. > > It came up that our earlier ideas for flattening our Git namespace > to reduce confusion and minimize future repository renames is now > not looking as attractive. Instead we're probably going to need to > embrace an explosion of new namespaces and find better ways to cope > with the pain of renames in Gerrit as projects want to move between > them over time. We're planning to only run one Gerrit for > simplicity, so artificially creating "tenants" in it through > prefixes in repository names is really the simplest solution we have > to avoid different projects stepping on one another's toes with > their name choices. > > Then we got into some policy discussions about namespace creation. > Jim Blair talked about the potential to map Git/Gerrit repository > namespaces to distinct Zuul tenants, and someone (might have been > me? I was fairly jet-lagged and so don't really remember) asked > about who decides what the requirements are for projects to create > repositories in a particular namespace. In the case of OpenStack, > the answer is almost certainly the OpenStack Technical Committee or > at least some group to whom they delegate that responsibility. The > OpenStack TC needs to discuss fairly early what its policies are for > the "openstack" namespace (whether existing unofficial projects will > be allowed to remain, whether addition of new unofficial projects > will be allowed there) as well as whether it wants to allow creation > of multiple separate namespaces for official OpenStack projects. The > suggestion of nested "deep" namespaces like openstack/nova/nova came > up at this point too. > > We also resolved that we need to look back into the project rename > plugin for Gerrit. The last time we evaluated it, there wasn't much > there. We've heard it's improved with newer Gerrit releases, but if > it's still lacking we might want to contribute to making it more > effective so we can handle the inevitable renames more easily in the > future. > > And finally, as happens with most forum sessions, we stopped > abruptly because we ran over and it was Kendall Nelson's turn to > start getting ops feedback for the Contributor Guide. ;) > -- > Jeremy Stanley > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangtrinhnt at gmail.com Tue Dec 11 02:51:48 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Tue, 11 Dec 2018 11:51:48 +0900 Subject: The 2nd Vietnam OSUG upstream contribution mentoring webinar Message-ID: Hello, Yes, we did it, the 2nd time [1] :). In this session, the OpenStack Upstream Contribution Mentoring program of the Vietnam OSUG focus on how to debug the OpenStack projects. We discussed and shared some experiences of using testing and debugging tools (tox, logs, zuul ci, ara, etc.). It was awesome! I also would love to mention Jitsi [2], the free and open source video conferencing tool. We make it through more than 1 hour of video chatting without any limitations or interruptions. The experience was great! I recommend you guys check this tool out if you want to organize video conferences. [1] https://www.dangtrinh.com/2018/12/viet-openstack-now-renamed-viet.html [2] https://jitsi.org/ Bests, -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangtrinhnt at gmail.com Tue Dec 11 06:14:18 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Tue, 11 Dec 2018 15:14:18 +0900 Subject: [Searchlight] Weekly report for the week of Stein R-19 & R-18 Message-ID: Hello team, Just so you know that we're having an issue with our functional tests [1]. Hopefully, I can fix it at the end of the week. [1] https://www.dangtrinh.com/2018/12/searchlight-weekly-report-stein-r-19-r.html Bests, -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangtrinhnt at gmail.com Tue Dec 11 06:21:47 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Tue, 11 Dec 2018 15:21:47 +0900 Subject: [Searchlight][Zuul] tox failed tests at zuul check only In-Reply-To: References: <1543855087.1459125.1597252016.5DBF506E@webmail.messagingengine.com> <1544206572.507632.1602338888.7C5CDA48@webmail.messagingengine.com> Message-ID: Hi Clark, I'm trying to figure out how Zuul processes the test-setup.sh [1] file to adopt new dependencies. [1] https://github.com/openstack/searchlight/blob/master/tools/test-setup.sh Thanks, On Sat, Dec 8, 2018 at 9:10 AM Trinh Nguyen wrote: > Thanks, Clark. > > On Sat, Dec 8, 2018 at 3:16 AM Clark Boylan wrote: > >> On Fri, Dec 7, 2018, at 8:17 AM, Trinh Nguyen wrote: >> > Hi again, >> > Just wonder how the image for searchlight test was set up? Which user is >> > used for running ElasticSearch? Is there any way to indicate the user >> that >> > will run the test? Can I do it with [1]? Based on the output of [2] I >> can >> > see there are some permission issue of JDK if I run the functional tests >> > with the stack user on my dev environment. >> > >> > [1] >> > >> https://git.openstack.org/cgit/openstack/searchlight/tree/tools/test-setup.sh >> > [2] >> > >> https://review.openstack.org/#/c/622871/3/searchlight/tests/functional/__init__.py >> > >> >> The unittest jobs run as the Zuul user. This user has sudo access when >> test-setup.sh runs, but then we remove sudo access when tox is run. This is >> important as we are trying to help ensure that you can run tox locally >> without it making system level changes. >> >> When your test setup script runs `dpkg -i` this package install may start >> running an elasticsearch instance. It depends on how the package is set up. >> This daemon would run under the user the package has configured for that >> service. When you run an elasticsearch process from your test suite this >> will run as the zuul user. >> >> Hope this helps. I also left a couple of comments on change 622871. >> >> Clark >> > > > -- > *Trinh Nguyen* > *www.edlab.xyz * > > -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Tue Dec 11 09:00:17 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 11 Dec 2018 18:00:17 +0900 Subject: [dev] [tc][all] TC office hours is started now on #openstack-tc Message-ID: <1679c7ed819.ca179a2294220.1691595509360129661@ghanshyammann.com> Hello everyone, 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. - gmann & TC From ifatafekn at gmail.com Tue Dec 11 09:45:49 2018 From: ifatafekn at gmail.com (Ifat Afek) Date: Tue, 11 Dec 2018 11:45:49 +0200 Subject: [vitrage][monasca] Monasca datasource for Vitrage Message-ID: Hi, In case you missed it, we have a POC of a Monasca datasource for Vitrage [1] J Thanks Bartosz Zurkowski for the effort! There is one issue that we need to close though – how to connect the Monasca alarms to the resources in Vitrage. In order to connect an alarm to a resource, Vitrage should be able to identify that resource in its entity graph using the dimensions coming from Monasca. I understood that these dimensions are configurable and not pre-defined. Basically, there are two cases. 1. For OpenStack resources, all Vitrage needs to know is the UUID of the resource. I assume that there is always a dimension for that resource, right? Is the dimension always called the same? If not, how can Vitrage identify that this is the interesting dimension (if there are other dimensions for this alarm)? 2. For other resources it is more complicated, as they might not have a natural unique id. For example, a NIC id in Vitrage may be generated out of the host name + NIC name. Monasca alarm may have two separate dimensions for the host and nic. How can Vitrage understand that those two dimensions identify the resource? In other cases, Vitrage may need a resource_type dimension to uniquely identify the resource. Another question: I understood that Monasca can send alarms that originate from other monitors like Ceilometer, Prometheus etc. What are the dimensions in these cases? Monasca team, I’ll be happy to hear your opinion about these questions. If you can provide several different examples it will be very helpful. Thanks, Ifat [1] https://review.openstack.org/#/c/622899 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Tue Dec 11 15:01:47 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 11 Dec 2018 15:01:47 +0000 Subject: [Searchlight][Zuul] tox failed tests at zuul check only In-Reply-To: References: <1543855087.1459125.1597252016.5DBF506E@webmail.messagingengine.com> <1544206572.507632.1602338888.7C5CDA48@webmail.messagingengine.com> Message-ID: <20181211150147.f3oj4gzkufpbp2fc@yuggoth.org> On 2018-12-11 15:21:47 +0900 (+0900), Trinh Nguyen wrote: > I'm trying to figure out how Zuul processes the test-setup.sh [1] > file to adopt new dependencies. [...] Looking at what you've put in there for your JRE packages, those would be better handled in a bindep.txt file in your repository. Running tools/test-setup.sh in jobs is really to catch other sorts of setup steps like precreating a database or formatting and mounting a particular filesystem your tests are going to rely on. For system package dependencies of your jobs, we have a declarative mechanism already which doesn't require complex conditional handling: we install whatever bindep says is missing. I see you're also leveraging tools/test-setup.sh to obtain packages of elasticsearch which are not available in the distributions on which your jobs run, which I guess is a suitable workaround though it seems odd to test on platforms which don't package the software on which your project relies. -- 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 sfinucan at redhat.com Tue Dec 11 14:48:29 2018 From: sfinucan at redhat.com (Stephen Finucane) Date: Tue, 11 Dec 2018 14:48:29 +0000 Subject: [os-api-ref][doc] Removing inactive cores Message-ID: <38ad42a1ef5ca6cf8f6b599811d577e8d7e8716a.camel@redhat.com> We moved the os-api-ref project under the governance of the docs team at the beginning of the year. We've just done some housecleaning of the os-api-ref core list and have removed the following individuals owing to inactivity over the past 180 days. * Anne Gentle * Sean Dague * Karen Bradshaw We would like to thank them for their contributions and welcome them to rejoin the team if their priorities change. Stephen From thierry at openstack.org Tue Dec 11 15:12:51 2018 From: thierry at openstack.org (Thierry Carrez) Date: Tue, 11 Dec 2018 16:12:51 +0100 Subject: [tc][all] Documenting the role of the TC Message-ID: Hi everyone, At the Berlin Summit there was a Forum session to do a retrospective on the "TC vision for 2019" (written in April 2017). As Julia mentions in her summary[1] of that session, one action out of that session was to start working on a vision for the TC itself (rather than a vision by the TC for OpenStack), as a living document that would describe the role of the TC. Content was collaboratively drafted through an etherpad, then proposed as a governance review a few weeks ago. I just incorporated the latest early feedback in a revision. Please have a look at the current strawman and comment if you feel like something we are doing is missing, or something is there that should not be: https://review.openstack.org/622400 Like the "Technical vision for OpenStack clouds" document[2], this one is expected to be a living document describing the current situation, against which changes can be proposed. Once the initial version is approved, it will let us propose and discuss changes in the role of the TC. Thanks in advance for your comments ! [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000586.html [2] https://governance.openstack.org/tc/reference/technical-vision.html -- Thierry Carrez (ttx) From juliaashleykreger at gmail.com Tue Dec 11 15:52:11 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Tue, 11 Dec 2018 07:52:11 -0800 Subject: [neutron][ironic] Add Support for Smart NIC with baremetal In-Reply-To: References: Message-ID: Following up on the discussion: Attendees: - Moshe Levi - Nate Johnston - Davidsha - Miguel - Adrian Chirls - Julia Kreger Notes from meeting: - NOTE: The discussions largely focused on the "local" execution on the smartnic case. The remote case is still under discussion but is not blocking to the overall effort. - We will create a new vnic binding type, as to not break baremetal port binding logic that already exists. Smartnics are viewed a separate path of logic that needs to be taken. If hierarchical port binding is needed, the logic will need to be updated at a later point in time. - The binding profile information to be transmitted from ironic to neutron to contain information about the smartnic. No manual port/smartnic mapping file will be added. - There will be no implicit mapping of ironic port.uuid to hostname on the operating smartnic. - Consensus was that the operators should supply the sufficient information to ironic for neutron to relate the smartnic (with the data sent in binding_profile) to the vif and the baremetal port. - Neutron OVS agent will perform the actual final port-plug using os-vif as compared to the current virtualization use case or the existing baremetal vnic use case. On Mon, Dec 10, 2018 at 12:34 PM Moshe Levi wrote: > Hi all, > > > > We started working on specs to support baremetal with smart-nic see [1] > and [2]. > > There are some open issue and different approaches that require further > discussion see [3]. > > To resolve them I would like to propose a meeting tomorrow , December > 11th, at 15:00 UTC. For those of you interested in joining please use [4] > to connect. > > > > [1] - https://review.openstack.org/#/c/582767/ > > [2] - https://review.openstack.org/#/c/619920/ > > [3] - https://etherpad.openstack.org/p/BER-ironic-smartnics > > [4] - https://bluejeans.com/u/jkreger > > > > Thanks, > > Moshe (moshele) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blair.bethwaite at gmail.com Tue Dec 11 19:56:44 2018 From: blair.bethwaite at gmail.com (Blair Bethwaite) Date: Wed, 12 Dec 2018 08:56:44 +1300 Subject: [scientific] No Scientific SIG meeting this week Message-ID: Hi all, Apologies for the late notice but we have 2 of 3 chairs travelling and one out of timezone this week. Cheers, b1airo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltoscano at redhat.com Tue Dec 11 20:54:35 2018 From: ltoscano at redhat.com (Luigi Toscano) Date: Tue, 11 Dec 2018 21:54:35 +0100 Subject: [sahara][ops][tripleo][openstack-ansible][puppet-openstack][kolla][i18n] Upcoming split of the sahara repository[sahara][ops][tripleo][openstack-ansible][puppet-openstack][kolla][i18n] Upcoming split of the sahara repository Message-ID: <17553662.qPKBozYCZC@whitebase.usersys.redhat.com> Hi all, we (sahara developers) are working on splitting the content of sahara.git, moving the code of each plugin to its own respository. Each plugin is used for a different Hadoop/Big Data provider. The change is better described in the following spec, which didn't happen in Rocky: http://specs.openstack.org/openstack/sahara-specs/specs/rocky/plugins-outside-sahara-core.html The change is going to impact other projects, but hopefully not the users. I will try to summarize the impact on the various consumers of sahara. == Deployment tools - the devstack plugin in the test repository (see below) was modified to support the installation of all the available plugins previously available in- tree, so devstack users should not notice any change. - puppet-sahara will require changes to install the additional repositories, and we would require and welcome any help; - I hope that the puppet-sahara changes would be enough to make TripleO work, but we would need some help on this. - openstack-ansibe-os_sahara will require changes as well, but we have a bit more expertise on Ansible and we can help with the changes. - kolla will require some changes too, depending on te (apologize if I forgot some project) == Packaging It would be nice if users could get all the plugins packages by installing the same packages as before the split, but I understand that it may be tricky, because each plugin depends on the core of sahara. This means that a binary subpackage like openstack-sahara (RDO) or sahara (Debian) can't depend on the binary packages of the plugins, or that would introduce a circular dependency. I raised the issue on the RDO list to get some initial feedback and the solution that we are going to implement in RDO requires flipping the value of a variable to handle the bootstrap case and the normal case, please check: https://lists.rdoproject.org/pipermail/dev/2018-November/008972.html and the rest of the thread, like: https://lists.rdoproject.org/pipermail/dev/2018-December/008977.html Any additional idea from other packagers would be really appreciated, also because it has a direct impact on at least the puppet modules. == Preview The work-in-progress repositories are available here: Sahara: https://github.com/tellesnobrega/sahara/tree/split-plugins Plugins: * Ambari: https://github.com/tellesnobrega/sahara-plugin-ambari * CDH: https://github.com/tellesnobrega/sahara-plugin-cdh * MapR: https://github.com/tellesnobrega/sahara-plugin-mapr * Spark: https://github.com/tellesnobrega/sahara-plugin-spark * Storm: https://github.com/tellesnobrega/sahara-plugin-storm * Vanilla: https://github.com/tellesnobrega/sahara-plugin-vanilla Any comment is more than welcome! Ciao -- Luigi From aspiers at suse.com Tue Dec 11 21:42:06 2018 From: aspiers at suse.com (Adam Spiers) Date: Tue, 11 Dec 2018 21:42:06 +0000 Subject: [all][ptl][heat][senlin][magnum][vitrage][watcher] New SIG for Autoscaling? In-Reply-To: References: Message-ID: <20181211214205.v73ki5mgidiqx42j@pacific.linksys.moosehall> Agreed. I also see the similarities, but I don't think there is enough overlap to cause problems, so +1 from me. My only suggestion would be to consider whether it makes sense to slightly widen the scope, since I believe Watcher operates in the very similar area of optimisation, and to me auto-scaling just sounds like one particular use case out of many different approaches to optimisation, of which Watcher covers several. So for example you could call it the "self-optimising SIG" ;-) Feel free to copy any of the self-healing SIG's structure if it helps! Ifat Afek wrote: >+1 for that. > >I see a lot of similarities between this SIG and the self-healing SIG, >although their scopes are slightly different. > >In both cases, there is a need to decide when an action should be taken >(based on Ceilometer, Monasca, Vitrage etc.) what action to take >(healing/scaling) and how to execute it (using Heat, Senlin, Mistral, …). >The main differences are the specific triggers and the actions to perform. > >I think that as a first step we should document the use cases. > >Ifat > >On Thu, Nov 29, 2018 at 9:34 PM Joseph Davis wrote: > >>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 From msm at redhat.com Tue Dec 11 21:56:03 2018 From: msm at redhat.com (Michael McCune) Date: Tue, 11 Dec 2018 16:56:03 -0500 Subject: [sahara][ops][tripleo][openstack-ansible][puppet-openstack][kolla][i18n] Upcoming split of the sahara repository[sahara][ops][tripleo][openstack-ansible][puppet-openstack][kolla][i18n] Upcoming split of the sahara repository In-Reply-To: <17553662.qPKBozYCZC@whitebase.usersys.redhat.com> References: <17553662.qPKBozYCZC@whitebase.usersys.redhat.com> Message-ID: On Tue, Dec 11, 2018 at 3:57 PM Luigi Toscano wrote: > > Hi all, > > we (sahara developers) are working on splitting the content of sahara.git, > moving the code of each plugin to its own respository. Each plugin is used for > a different Hadoop/Big Data provider. The change is better described in the > following spec, which didn't happen in Rocky: > > http://specs.openstack.org/openstack/sahara-specs/specs/rocky/plugins-outside-sahara-core.html this sounds really cool, thanks for the update Luigi. peace o/ From mriedemos at gmail.com Tue Dec 11 22:41:00 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Tue, 11 Dec 2018 16:41:00 -0600 Subject: [all]Forum summary: Expose SIGs and WGs In-Reply-To: References: Message-ID: On 12/3/2018 11:42 AM, Rico Lin wrote: > We also have some real story (Luzi's story) for people to get a better > understanding of why current workflow can look like for someone who > tries to help. I looked over the note on this in the etherpad. They did what they were asked and things have stalled. At this point, I think it comes down to priorities, and in order to prioritize something big like this that requires coordinated work across several projects, we are going to need more stakeholders coming forward and saying they also want this feature so the vendors who are paying the people to work upstream can be given specific time to give this the attention it needs. And that ties back into getting the top 1 or 2 wishlist items from each SIG and trying to sort those based on what is the highest rated most common need for the greatest number of people - sort of like what we see happening with the resource delete API community wide goal proposal. -- Thanks, Matt From zigo at debian.org Tue Dec 11 22:42:40 2018 From: zigo at debian.org (Thomas Goirand) Date: Tue, 11 Dec 2018 23:42:40 +0100 Subject: [sahara][ops][tripleo][openstack-ansible][puppet-openstack][kolla][i18n] Upcoming split of the sahara repository[sahara][ops][tripleo][openstack-ansible][puppet-openstack][kolla][i18n] Upcoming split of the sahara repository In-Reply-To: <17553662.qPKBozYCZC@whitebase.usersys.redhat.com> References: <17553662.qPKBozYCZC@whitebase.usersys.redhat.com> Message-ID: Hi Luigi, First thanks for communicating about this. I'm afraid you probably will not like much what I'm going to have to write here. Sorry in advance if I'm not enthusiastic about this. On 12/11/18 9:54 PM, Luigi Toscano wrote: > == Packaging > > It would be nice if users could get all the plugins packages by installing the > same packages as before the split, but I understand that it may be tricky, > because each plugin depends on the core of sahara. This means that a binary > subpackage like openstack-sahara (RDO) or sahara (Debian) can't depend on the > binary packages of the plugins, or that would introduce a circular dependency. > > I raised the issue on the RDO list to get some initial feedback and the > solution that we are going to implement in RDO requires flipping the value of > a variable to handle the bootstrap case and the normal case, please check: > https://lists.rdoproject.org/pipermail/dev/2018-November/008972.html > and the rest of the thread, like: > https://lists.rdoproject.org/pipermail/dev/2018-December/008977.html > > Any additional idea from other packagers would be really appreciated, also > because it has a direct impact on at least the puppet modules. We aren't "packagers", we *maintain* packages, and therefore are package maintainers. And from that perspective, such decision from upstream is always disruptive, both from the package maintainer view, and for our users. While a plugin architecture looks sexy from the outside, it can bite hard in many ways. In argumentation in the spec, the one and only thing which is annoying your users (according to the argumentation) is that plugins are tight to a milestone, and that it's not possible to upgrade a plug-in separately. I seriously doubt that Sahara users are going to do that, for many reasons. Here's 2 of them. First, because if they consume packages, I don't see downstream distribution making update to packages so often. Especially if there's so many to update, and so many combination to test, it's going to be very difficult for downstream distribution to know what to do, and do regular plugin updates. Second, because I very much doubt that users will want to update their plugins that often. Most OpenStack users are struggling with updates of the OpenStack core already. Another thing is experience we had with Cinder and Neutron. As you know, Cinder carries the drivers in the main repository, while Neutron decided to move to a plugin system. So we do trust the Cinder team to do a good job to maintain the plugins, and have them in sync with the release, for some Neutron plugins, it has been a complete disaster, with some plugins always lagging behind the needed API changes and so on. As for downstream distribution, it is very hard to know which plugins are worth packaging or not, and even harder to know which are well maintained upstream or not. What's your plan for addressing this issue? As for myself, I'm really not sure I'm going to invest so much time on Sahara packaging plugin. Maybe I'll decide to package a few, but probably not all plugins, as it's very time consuming. Maybe I'll find spare cycles. It wont be important anyway, because Debian Buster will be frozen, so I may just skip that work for the Stein release, as I'll probably be busy on other stuff. So, not best timing for me as a Debian package maintainer. :/ So, maybe you could reconsider? Or is it already too late? > == Preview > > The work-in-progress repositories are available here: > > Sahara: https://github.com/tellesnobrega/sahara/tree/split-plugins > > Plugins: > * Ambari: https://github.com/tellesnobrega/sahara-plugin-ambari > * CDH: https://github.com/tellesnobrega/sahara-plugin-cdh > * MapR: https://github.com/tellesnobrega/sahara-plugin-mapr > * Spark: https://github.com/tellesnobrega/sahara-plugin-spark > * Storm: https://github.com/tellesnobrega/sahara-plugin-storm > * Vanilla: https://github.com/tellesnobrega/sahara-plugin-vanilla Oh gosh... This becomes very embarrassing. I have absolutely no clue what these plugins are for, and there's absolutely no clue in the repositories. Appart from "Spark", which I vaguely heard about, the above names give zero clue on what they do. There's no hyperlink to the projects these plugins are supporting. I have no clue which of the above plugins is for Hadoop, which was historically the first target of Sahara. Please, please please please, for each plugin, provide: - A sort description of 80 chars, in one line - A long description of *AT LEAST* 3 lines of 80 chars That's IMO the minimum you own to the downstream package maintainers that are doing the work for your project for free (that's really my case, I never used Sahara, and I have zero professional insentive to package it, I really do it as a courtesy for Debian and OpenStack users). Thanks for working on Sahara, Cheers, Thomas Goirand (zigo) P.S: I've disregarded the added amount of work that all of this change imposes to all of us, as I thought you knew already about it, but this is not a good news to know 6 new packages will be needed... :( From openstack at nemebean.com Tue Dec 11 23:03:12 2018 From: openstack at nemebean.com (Ben Nemec) Date: Tue, 11 Dec 2018 17:03:12 -0600 Subject: [oslo][tooz][requirements] Tooz etcd3 tests blocked on grpcio>=1.16.0 Message-ID: <23246b05-d96f-f981-5ab9-a9d102fcb480@nemebean.com> The tooz gate is currently blocked on https://bugs.launchpad.net/python-tooz/+bug/1808046 which seems to have been introduced with grpcio 1.16.0. I need to raise that issue with the grpc folks, but in the meantime should we block the problematic versions? grpcio isn't currently in g-r and I can't remember what our policy on transitive dependencies is, so I thought I'd solicit opinions. Thanks. -Ben From ltoscano at redhat.com Tue Dec 11 23:10:39 2018 From: ltoscano at redhat.com (Luigi Toscano) Date: Wed, 12 Dec 2018 00:10:39 +0100 Subject: [sahara][ops][tripleo][openstack-ansible][puppet-openstack][kolla][i18n] Upcoming split of the sahara repository[sahara][ops][tripleo][openstack-ansible][puppet-openstack][kolla][i18n] Upcoming split of the sahara repository In-Reply-To: References: <17553662.qPKBozYCZC@whitebase.usersys.redhat.com> Message-ID: <4598759.uZ9kGMok9I@whitebase.usersys.redhat.com> On Tuesday, 11 December 2018 23:42:40 CET Thomas Goirand wrote: > Hi Luigi, > > First thanks for communicating about this. > > I'm afraid you probably will not like much what I'm going to have to > write here. Sorry in advance if I'm not enthusiastic about this. > > On 12/11/18 9:54 PM, Luigi Toscano wrote: > > == Packaging > > > > It would be nice if users could get all the plugins packages by installing > > the same packages as before the split, but I understand that it may be > > tricky, because each plugin depends on the core of sahara. This means > > that a binary subpackage like openstack-sahara (RDO) or sahara (Debian) > > can't depend on the binary packages of the plugins, or that would > > introduce a circular dependency. > > > > I raised the issue on the RDO list to get some initial feedback and the > > solution that we are going to implement in RDO requires flipping the value > > of a variable to handle the bootstrap case and the normal case, please > > check: > > https://lists.rdoproject.org/pipermail/dev/2018-November/008972.html> > > and the rest of the thread, like: > > https://lists.rdoproject.org/pipermail/dev/2018-December/008977.html > > > > Any additional idea from other packagers would be really appreciated, also > > because it has a direct impact on at least the puppet modules. > > We aren't "packagers", we *maintain* packages, and therefore are package > maintainers. And from that perspective, such decision from upstream is > always disruptive, both from the package maintainer view, and for our users. About the terminology, I'd like to point out that I've seen "packagers" used without any particular weird meaning attached in all the development communities I followed or I contributed to, even used by the people in charge of the packages, and I knew quite a lot of them. Going to the proper point: > While a plugin architecture looks sexy from the outside, it can bite > hard in many ways. > > In argumentation in the spec, the one and only thing which is annoying > your users (according to the argumentation) is that plugins are tight to > a milestone, and that it's not possible to upgrade a plug-in separately. > I seriously doubt that Sahara users are going to do that, for many > reasons. Here's 2 of them. > > First, because if they consume packages, I don't see downstream > distribution making update to packages so often. Especially if there's > so many to update, and so many combination to test, it's going to be > very difficult for downstream distribution to know what to do, and do > regular plugin updates. That's about people in charge of the packages, so me (partially for RDO), you, and other people. > > Second, because I very much doubt that users will want to update their > plugins that often. Most OpenStack users are struggling with updates of > the OpenStack core already. We didn't come out with this requirement outselves. We had various operators over the year who could not provide newer plugins to their users because they could not upgrade the whole of OpenStack and asked for this. This feature is there exactly to not upgrade the core of OpenStack. Upgrading leaves components like the plugin is a totally different story. > Another thing is experience we had with Cinder and Neutron. As you know, > Cinder carries the drivers in the main repository, while Neutron decided > to move to a plugin system. So we do trust the Cinder team to do a good > job to maintain the plugins, and have them in sync with the release, for > some Neutron plugins, it has been a complete disaster, with some plugins > always lagging behind the needed API changes and so on. As for > downstream distribution, it is very hard to know which plugins are worth > packaging or not, and even harder to know which are well maintained > upstream or not. What's your plan for addressing this issue? By keeping a proper set of constraints in the plugins. As I mentioned, the core of Sahara is more than stable and most of the changes are in the plugins. tl;dr we don't plan API changes in the interface between the core and the plugins. And we probably don't want them. At most we may add some of them, but not remove. > As for myself, I'm really not sure I'm going to invest so much time on > Sahara packaging plugin. Maybe I'll decide to package a few, but > probably not all plugins, as it's very time consuming. Maybe I'll find > spare cycles. It wont be important anyway, because Debian Buster will be > frozen, so I may just skip that work for the Stein release, as I'll > probably be busy on other stuff. So, not best timing for me as a Debian > package maintainer. :/ > > So, maybe you could reconsider? Or is it already too late? There is no going back. > > > == Preview > > > > The work-in-progress repositories are available here: > > > > Sahara: https://github.com/tellesnobrega/sahara/tree/split-plugins > > > > Plugins: > > * Ambari: https://github.com/tellesnobrega/sahara-plugin-ambari > > * CDH: https://github.com/tellesnobrega/sahara-plugin-cdh > > * MapR: https://github.com/tellesnobrega/sahara-plugin-mapr > > * Spark: https://github.com/tellesnobrega/sahara-plugin-spark > > * Storm: https://github.com/tellesnobrega/sahara-plugin-storm > > * Vanilla: https://github.com/tellesnobrega/sahara-plugin-vanilla > > Oh gosh... This becomes very embarrassing. I have absolutely no clue > what these plugins are for, and there's absolutely no clue in the > repositories. Appart from "Spark", which I vaguely heard about, the > above names give zero clue on what they do. There's no hyperlink to the > projects these plugins are supporting. I have no clue which of the above > plugins is for Hadoop, which was historically the first target of Sahara. That's the meaning of "testing repository"; they are not final (they will need at least one or two more rebases from the current master). The description in setup.cfg can certainly be extended, and the related content of README.rst too. This is a valuable suggestion. Ciao -- Luigi From mthode at mthode.org Tue Dec 11 23:51:47 2018 From: mthode at mthode.org (Matthew Thode) Date: Tue, 11 Dec 2018 17:51:47 -0600 Subject: [oslo][tooz][requirements] Tooz etcd3 tests blocked on grpcio>=1.16.0 In-Reply-To: <23246b05-d96f-f981-5ab9-a9d102fcb480@nemebean.com> References: <23246b05-d96f-f981-5ab9-a9d102fcb480@nemebean.com> Message-ID: <20181211235147.76ad2uwamon2dsvq@mthode.org> On 18-12-11 17:03:12, Ben Nemec wrote: > The tooz gate is currently blocked on > https://bugs.launchpad.net/python-tooz/+bug/1808046 which seems to have been > introduced with grpcio 1.16.0. I need to raise that issue with the grpc > folks, but in the meantime should we block the problematic versions? grpcio > isn't currently in g-r and I can't remember what our policy on transitive > dependencies is, so I thought I'd solicit opinions. > > Thanks. > I'm not aware of any policy on how we block dependencies like this. At the moment I'd suggest opening a bug with us so we don't forget and add it to global-requirements (preferably with a comment). Answering all the questions as normal. https://storyboard.openstack.org/#!/project/openstack/requirements -- Matthew Thode (prometheanfire) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From dangtrinhnt at gmail.com Wed Dec 12 00:47:35 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Wed, 12 Dec 2018 09:47:35 +0900 Subject: [Searchlight][Zuul] tox failed tests at zuul check only In-Reply-To: <20181211150147.f3oj4gzkufpbp2fc@yuggoth.org> References: <1543855087.1459125.1597252016.5DBF506E@webmail.messagingengine.com> <1544206572.507632.1602338888.7C5CDA48@webmail.messagingengine.com> <20181211150147.f3oj4gzkufpbp2fc@yuggoth.org> Message-ID: Thank Jeremy. I will look into bindep. On Wed, Dec 12, 2018 at 12:04 AM Jeremy Stanley wrote: > On 2018-12-11 15:21:47 +0900 (+0900), Trinh Nguyen wrote: > > I'm trying to figure out how Zuul processes the test-setup.sh [1] > > file to adopt new dependencies. > [...] > > Looking at what you've put in there for your JRE packages, those > would be better handled in a bindep.txt file in your repository. > Running tools/test-setup.sh in jobs is really to catch other sorts > of setup steps like precreating a database or formatting and > mounting a particular filesystem your tests are going to rely on. > For system package dependencies of your jobs, we have a declarative > mechanism already which doesn't require complex conditional > handling: we install whatever bindep says is missing. > > I see you're also leveraging tools/test-setup.sh to obtain packages > of elasticsearch which are not available in the distributions on > which your jobs run, which I guess is a suitable workaround though > it seems odd to test on platforms which don't package the software > on which your project relies. > -- > Jeremy Stanley > -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Wed Dec 12 01:03:28 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 12 Dec 2018 10:03:28 +0900 Subject: [dev] [tc][all] TC office hours is started now on #openstack-tc Message-ID: <1679ff0a97d.cfc3717a14880.8241100762744862054@ghanshyammann.com> Hello everyone, 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. - gmann & TC From niraj.singh at nttdata.com Wed Dec 12 02:30:46 2018 From: niraj.singh at nttdata.com (Singh, Niraj) Date: Wed, 12 Dec 2018 02:30:46 +0000 Subject: [tosca-parser] Need new release of tosca-parser library Message-ID: Hi Team, Heat-translator patch [1] is dependent on tosca-parser changes that is already merged in patch [2]. We need new tosco-parser release so that we can add the new release version in heat-translator and proceed further with the review. And tacker patch [3] is dependent on heat-translator [1]. So we also need new release of heat-translator after merging the new changes so that it can be used by tacker changes to successfully work with new functionality. Please let me know the plan when you will release tosco-parse library. [1] https://review.openstack.org/#/c/619154/ heat-translator [2] https://review.openstack.org/#/c/612973/ tosco-parser [3] https://review.openstack.org/#/c/622888/ tacker Best Regards, Niraj Singh | System Analyst| NTT DATA Global Delivery Services Ltd.| w. +91.20.6604.1500 x 403|m.8055861633| Niraj.Singh at nttdata.com Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at bakeyournoodle.com Wed Dec 12 02:35:15 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Wed, 12 Dec 2018 13:35:15 +1100 Subject: [oslo][tooz][requirements] Tooz etcd3 tests blocked on grpcio>=1.16.0 In-Reply-To: <23246b05-d96f-f981-5ab9-a9d102fcb480@nemebean.com> References: <23246b05-d96f-f981-5ab9-a9d102fcb480@nemebean.com> Message-ID: <20181212023515.GB6373@thor.bakeyournoodle.com> On Tue, Dec 11, 2018 at 05:03:12PM -0600, Ben Nemec wrote: > The tooz gate is currently blocked on > https://bugs.launchpad.net/python-tooz/+bug/1808046 which seems to have been > introduced with grpcio 1.16.0. I need to raise that issue with the grpc > folks, but in the meantime should we block the problematic versions? grpcio > isn't currently in g-r and I can't remember what our policy on transitive > dependencies is, so I thought I'd solicit opinions. Yup just add it in this section: http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n479 Bonus points if you have a second patch that removes daiquiri from that section as we're clearly not blocking version any more. 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 dangtrinhnt at gmail.com Wed Dec 12 02:37:10 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Wed, 12 Dec 2018 11:37:10 +0900 Subject: [Searchlight][Zuul] tox failed tests at zuul check only In-Reply-To: References: <1543855087.1459125.1597252016.5DBF506E@webmail.messagingengine.com> <1544206572.507632.1602338888.7C5CDA48@webmail.messagingengine.com> <20181211150147.f3oj4gzkufpbp2fc@yuggoth.org> Message-ID: Trying to look through the logs of the last merged patch set [1] but nothing there. Is there any other places that I can look into? [1] https://review.openstack.org/#/c/616056/ Thanks, On Wed, Dec 12, 2018 at 9:47 AM Trinh Nguyen wrote: > Thank Jeremy. I will look into bindep. > > On Wed, Dec 12, 2018 at 12:04 AM Jeremy Stanley wrote: > >> On 2018-12-11 15:21:47 +0900 (+0900), Trinh Nguyen wrote: >> > I'm trying to figure out how Zuul processes the test-setup.sh [1] >> > file to adopt new dependencies. >> [...] >> >> Looking at what you've put in there for your JRE packages, those >> would be better handled in a bindep.txt file in your repository. >> Running tools/test-setup.sh in jobs is really to catch other sorts >> of setup steps like precreating a database or formatting and >> mounting a particular filesystem your tests are going to rely on. >> For system package dependencies of your jobs, we have a declarative >> mechanism already which doesn't require complex conditional >> handling: we install whatever bindep says is missing. >> >> I see you're also leveraging tools/test-setup.sh to obtain packages >> of elasticsearch which are not available in the distributions on >> which your jobs run, which I guess is a suitable workaround though >> it seems odd to test on platforms which don't package the software >> on which your project relies. >> -- >> Jeremy Stanley >> > > > -- > *Trinh Nguyen* > *www.edlab.xyz * > > -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Wed Dec 12 02:37:45 2018 From: cboylan at sapwetik.org (Clark Boylan) Date: Tue, 11 Dec 2018 18:37:45 -0800 Subject: [oslo][tooz][requirements] Tooz etcd3 tests blocked on grpcio>=1.16.0 In-Reply-To: <20181212023515.GB6373@thor.bakeyournoodle.com> References: <23246b05-d96f-f981-5ab9-a9d102fcb480@nemebean.com> <20181212023515.GB6373@thor.bakeyournoodle.com> Message-ID: <1544582265.3129550.1606583752.09D0F005@webmail.messagingengine.com> On Tue, Dec 11, 2018, at 6:35 PM, Tony Breeds wrote: > On Tue, Dec 11, 2018 at 05:03:12PM -0600, Ben Nemec wrote: > > The tooz gate is currently blocked on > > https://bugs.launchpad.net/python-tooz/+bug/1808046 which seems to have been > > introduced with grpcio 1.16.0. I need to raise that issue with the grpc > > folks, but in the meantime should we block the problematic versions? grpcio > > isn't currently in g-r and I can't remember what our policy on transitive > > dependencies is, so I thought I'd solicit opinions. > > Yup just add it in this section: > http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n479 Do we need to have the constraints generation tooling install tooz[etcd3] so that the transitive dep for grpcio is installed too? Or will that get pulled in because it is in global-requirements? Enough has changed in how this all works I'm not totally sure what is necessary anymore but tooz lists etcd3 as an extra requires so you have to ask for it to get those deps. Clark From tony at bakeyournoodle.com Wed Dec 12 02:39:51 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Wed, 12 Dec 2018 13:39:51 +1100 Subject: [tosca-parser] Need new release of tosca-parser library In-Reply-To: References: Message-ID: <20181212023950.GC6373@thor.bakeyournoodle.com> On Wed, Dec 12, 2018 at 02:30:46AM +0000, Singh, Niraj wrote: > Hi Team, > > > Heat-translator patch [1] is dependent on tosca-parser changes that is already merged in patch [2]. > > > We need new tosco-parser release so that we can add the new release version in heat-translator and proceed further with the review. This can be done via the openstack/releases repo. We'll need either the heat PTL or release team liaison to approve the patch if neither of them can propose the change. 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 tony at bakeyournoodle.com Wed Dec 12 02:47:21 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Wed, 12 Dec 2018 13:47:21 +1100 Subject: [oslo][tooz][requirements] Tooz etcd3 tests blocked on grpcio>=1.16.0 In-Reply-To: <1544582265.3129550.1606583752.09D0F005@webmail.messagingengine.com> References: <23246b05-d96f-f981-5ab9-a9d102fcb480@nemebean.com> <20181212023515.GB6373@thor.bakeyournoodle.com> <1544582265.3129550.1606583752.09D0F005@webmail.messagingengine.com> Message-ID: <20181212024720.GD6373@thor.bakeyournoodle.com> On Tue, Dec 11, 2018 at 06:37:45PM -0800, Clark Boylan wrote: > Do we need to have the constraints generation tooling install > tooz[etcd3] so that the transitive dep for grpcio is installed too? We do not. > Or > will that get pulled in because it is in global-requirements? Yes that one :D 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 mthode at mthode.org Wed Dec 12 02:54:03 2018 From: mthode at mthode.org (Matthew Thode) Date: Tue, 11 Dec 2018 20:54:03 -0600 Subject: [oslo][tooz][requirements] Tooz etcd3 tests blocked on grpcio>=1.16.0 In-Reply-To: <1544582265.3129550.1606583752.09D0F005@webmail.messagingengine.com> References: <23246b05-d96f-f981-5ab9-a9d102fcb480@nemebean.com> <20181212023515.GB6373@thor.bakeyournoodle.com> <1544582265.3129550.1606583752.09D0F005@webmail.messagingengine.com> Message-ID: <20181212025403.nnj2txxbot2dha66@mthode.org> On 18-12-11 18:37:45, Clark Boylan wrote: > On Tue, Dec 11, 2018, at 6:35 PM, Tony Breeds wrote: > > On Tue, Dec 11, 2018 at 05:03:12PM -0600, Ben Nemec wrote: > > > The tooz gate is currently blocked on > > > https://bugs.launchpad.net/python-tooz/+bug/1808046 which seems to have been > > > introduced with grpcio 1.16.0. I need to raise that issue with the grpc > > > folks, but in the meantime should we block the problematic versions? grpcio > > > isn't currently in g-r and I can't remember what our policy on transitive > > > dependencies is, so I thought I'd solicit opinions. > > > > Yup just add it in this section: > > http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n479 > > Do we need to have the constraints generation tooling install tooz[etcd3] so that the transitive dep for grpcio is installed too? Or will that get pulled in because it is in global-requirements? > > Enough has changed in how this all works I'm not totally sure what is necessary anymore but tooz lists etcd3 as an extra requires so you have to ask for it to get those deps. > ya, it should be in global-requirements if it's an extra dep, the reason why gating didn't catch it is because it's not checking. see http://logs.openstack.org/47/624247/3/check/requirements-check/f8b35d2/job-output.txt.gz#_2018-12-11_22_58_07_751203 for example. going to see if I can add that... -- Matthew Thode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mthode at mthode.org Wed Dec 12 03:07:26 2018 From: mthode at mthode.org (Matthew Thode) Date: Tue, 11 Dec 2018 21:07:26 -0600 Subject: [oslo][tooz][requirements] Tooz etcd3 tests blocked on grpcio>=1.16.0 In-Reply-To: <20181212025403.nnj2txxbot2dha66@mthode.org> References: <23246b05-d96f-f981-5ab9-a9d102fcb480@nemebean.com> <20181212023515.GB6373@thor.bakeyournoodle.com> <1544582265.3129550.1606583752.09D0F005@webmail.messagingengine.com> <20181212025403.nnj2txxbot2dha66@mthode.org> Message-ID: <20181212030726.gifmmnkwc5mskyyx@mthode.org> On 18-12-11 20:54:03, Matthew Thode wrote: > On 18-12-11 18:37:45, Clark Boylan wrote: > > On Tue, Dec 11, 2018, at 6:35 PM, Tony Breeds wrote: > > > On Tue, Dec 11, 2018 at 05:03:12PM -0600, Ben Nemec wrote: > > > > The tooz gate is currently blocked on > > > > https://bugs.launchpad.net/python-tooz/+bug/1808046 which seems to have been > > > > introduced with grpcio 1.16.0. I need to raise that issue with the grpc > > > > folks, but in the meantime should we block the problematic versions? grpcio > > > > isn't currently in g-r and I can't remember what our policy on transitive > > > > dependencies is, so I thought I'd solicit opinions. > > > > > > Yup just add it in this section: > > > http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n479 > > > > Do we need to have the constraints generation tooling install tooz[etcd3] so that the transitive dep for grpcio is installed too? Or will that get pulled in because it is in global-requirements? > > > > Enough has changed in how this all works I'm not totally sure what is necessary anymore but tooz lists etcd3 as an extra requires so you have to ask for it to get those deps. > > > > ya, it should be in global-requirements if it's an extra dep, the reason > why gating didn't catch it is because it's not checking. > > see > http://logs.openstack.org/47/624247/3/check/requirements-check/f8b35d2/job-output.txt.gz#_2018-12-11_22_58_07_751203 > for example. > > going to see if I can add that... > Ignore this, I thought we were talking about grpcio being in listed as a direct (optional) dependency. Time to go to sleep. -- Matthew Thode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From bobh at haddleton.net Wed Dec 12 03:41:34 2018 From: bobh at haddleton.net (Bob Haddleton) Date: Tue, 11 Dec 2018 21:41:34 -0600 Subject: [tosca-parser] Need new release of tosca-parser library In-Reply-To: <20181212023950.GC6373@thor.bakeyournoodle.com> References: <20181212023950.GC6373@thor.bakeyournoodle.com> Message-ID: <6F5CE673-171B-436B-8D08-414494A9A60C@haddleton.net> I will submit this patch tomorrow morning (US/Central) Bob > On Dec 11, 2018, at 20:39, Tony Breeds wrote: > >> On Wed, Dec 12, 2018 at 02:30:46AM +0000, Singh, Niraj wrote: >> Hi Team, >> >> >> Heat-translator patch [1] is dependent on tosca-parser changes that is already merged in patch [2]. >> >> >> We need new tosco-parser release so that we can add the new release version in heat-translator and proceed further with the review. > > This can be done via the openstack/releases repo. We'll need either the > heat PTL or release team liaison to approve the patch if neither of them > can propose the change. > > Yours Tony. From chkumar246 at gmail.com Wed Dec 12 04:06:45 2018 From: chkumar246 at gmail.com (Chandan kumar) Date: Wed, 12 Dec 2018 09:36:45 +0530 Subject: [tripleo][openstack-ansible] collaboration on os_tempest role update II - Dec 12, 2018 Message-ID: Hello, Below is the another Iteration of updates on what happened in os_tempest[1.] side. Things got improved till Dec 4 - 12, 2018: * Use tempest run for generating subunit results - https://review.openstack.org/621584 Things still in progress: * Better blacklist and whitelist tests management - https://review.openstack.org/621605 * Use --profile feature for generating tempest.conf by passing all tempestconf named arguments in yaml file: - https://review.openstack.org/623187 - https://review.openstack.org/623413 * Use tempestconf rpm for generating tempest.conf in CentOS/SUSE distro Jobs: https://review.openstack.org/622999 Improvements in python-tempestconf: * Introducing profile feature to generate sample profile in tempestconf as well as user can create the same profile of named arguments and pass it to discover-tempest-config binary. It will help to improve automation across tooling. Next Week: * We will continue working on above in progress tasks. Here is the first update [2] and second update [3] Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136452.html [3.] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000537.html Thanks, Chandan Kumar From rico.lin.guanyu at gmail.com Wed Dec 12 05:31:41 2018 From: rico.lin.guanyu at gmail.com (Rico Lin) Date: Wed, 12 Dec 2018 13:31:41 +0800 Subject: [tosca-parser] Need new release of tosca-parser library In-Reply-To: <6F5CE673-171B-436B-8D08-414494A9A60C@haddleton.net> References: <20181212023950.GC6373@thor.bakeyournoodle.com> <6F5CE673-171B-436B-8D08-414494A9A60C@haddleton.net> Message-ID: On Wed, Dec 12, 2018 at 11:47 AM Bob Haddleton wrote: > I will submit this patch tomorrow morning (US/Central) > I will help to give my aproval just to honor the project release workflow > > Bob > > > On Dec 11, 2018, at 20:39, Tony Breeds wrote: > > > >> On Wed, Dec 12, 2018 at 02:30:46AM +0000, Singh, Niraj wrote: > >> Hi Team, > >> > >> > >> Heat-translator patch [1] is dependent on tosca-parser changes that is > already merged in patch [2]. > >> > >> > >> We need new tosco-parser release so that we can add the new release > version in heat-translator and proceed further with the review. > > > > This can be done via the openstack/releases repo. We'll need either the > > heat PTL or release team liaison to approve the patch if neither of them > > can propose the change. > > > > Yours Tony. > > > -- 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 Dec 12 07:54:36 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Wed, 12 Dec 2018 08:54:36 +0100 Subject: [neutron] gate issue Message-ID: Hi all, Recently we have issue with neutron-tempest-iptables_hybrid job which is failing 100% times. It is related to [1] and there is no need to recheck Your patches if CI failed on this job. To unblock our gate we proposed patch to make this job non-voting for some time [2]. When it will be merged, please rebase Your patches and it should be good then. [1] https://bugs.launchpad.net/os-vif/+bug/1807949 [2] https://review.openstack.org/#/c/624489/ — Slawek Kaplonski Senior software engineer Red Hat From rico.lin.guanyu at gmail.com Wed Dec 12 08:10:44 2018 From: rico.lin.guanyu at gmail.com (Rico Lin) Date: Wed, 12 Dec 2018 16:10:44 +0800 Subject: [heat] changing our meeting time, and no meeting this week Message-ID: Dear team As we have some change recently, I will move Heat team meeting time to Wednesday 08:00 UTC, I will send the patch later. We will not hold a meeting today, but we definitely needs a meeting next week so we can spend some time to clear our debt. -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangtrinhnt at gmail.com Wed Dec 12 08:35:05 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Wed, 12 Dec 2018 17:35:05 +0900 Subject: [Searchlight][Zuul] tox failed tests at zuul check only In-Reply-To: References: <1543855087.1459125.1597252016.5DBF506E@webmail.messagingengine.com> <1544206572.507632.1602338888.7C5CDA48@webmail.messagingengine.com> <20181211150147.f3oj4gzkufpbp2fc@yuggoth.org> Message-ID: Hi all, Finally, found the problem. For some reason, py27 has to wait a little bit longer for the elasticsearch instance to be up. I just let the functional setup code wait a little while. Problem solved. Amazing! :) Many thanks :) On Wed, Dec 12, 2018 at 11:37 AM Trinh Nguyen wrote: > Trying to look through the logs of the last merged patch set [1] but > nothing there. Is there any other places that I can look into? > > [1] https://review.openstack.org/#/c/616056/ > > Thanks, > > On Wed, Dec 12, 2018 at 9:47 AM Trinh Nguyen > wrote: > >> Thank Jeremy. I will look into bindep. >> >> On Wed, Dec 12, 2018 at 12:04 AM Jeremy Stanley >> wrote: >> >>> On 2018-12-11 15:21:47 +0900 (+0900), Trinh Nguyen wrote: >>> > I'm trying to figure out how Zuul processes the test-setup.sh [1] >>> > file to adopt new dependencies. >>> [...] >>> >>> Looking at what you've put in there for your JRE packages, those >>> would be better handled in a bindep.txt file in your repository. >>> Running tools/test-setup.sh in jobs is really to catch other sorts >>> of setup steps like precreating a database or formatting and >>> mounting a particular filesystem your tests are going to rely on. >>> For system package dependencies of your jobs, we have a declarative >>> mechanism already which doesn't require complex conditional >>> handling: we install whatever bindep says is missing. >>> >>> I see you're also leveraging tools/test-setup.sh to obtain packages >>> of elasticsearch which are not available in the distributions on >>> which your jobs run, which I guess is a suitable workaround though >>> it seems odd to test on platforms which don't package the software >>> on which your project relies. >>> -- >>> Jeremy Stanley >>> >> >> >> -- >> *Trinh Nguyen* >> *www.edlab.xyz * >> >> > > -- > *Trinh Nguyen* > *www.edlab.xyz * > > -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Wed Dec 12 09:25:45 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Wed, 12 Dec 2018 10:25:45 +0100 Subject: openstack magnum queens swarm error Message-ID: ello Everyone, I installed queens on centos with magnum and I am trying to create a swarm cluster with one muster and one node. The image I used is fedora-atomic 27 update 04 The stack generated end with an error and magnum conductor reports: ec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.304 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key api_address Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.305 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key swarm_masters Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key swarm_nodes Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key discovery_url Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.317 17964 ERROR magnum.drivers.heat.driver [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] Cluster error, stack status: CREATE_FAILED, stack_id: 306bd83a-7878-4d94-8ed0-1d297eec9768, reason: Resource CREATE failed: WaitConditionFailure: resources.swarm_nodes.resources[0].resources.node_wait_condition: swarm-agent service failed to start. I connected to the master node for verifyng if swarm agent is running. In the cloud init log I found: requests.exceptions.ConnectionError: HTTPConnectionPool(host='10.102.184.190', port=5000): Max retries exceeded with url: /v3//auth/tokens (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 110] Connection timed out',)) Cloud-init v. 0.7.9 running 'modules:final' at Wed, 12 Dec 2018 08:45:31 +0000. Up 55.54 seconds. 2018-12-12 08:47:45,858 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-005 [1] /var/lib/cloud/instance/scripts/part-006: line 13: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-006: line 26: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-006: line 38: /etc/etcd/etcd.conf: No such file or directory 2018-12-12 08:47:45,870 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-006 [1] Configuring docker network ... Configuring docker network service ... Removed /etc/systemd/system/multi-user.target.wants/docker-storage-setup.service. New size given (1280 extents) not larger than existing size (4863 extents) ERROR: There is not enough free space in volume group atomicos to create data volume of size MIN_DATA_SIZE=2G. 2018-12-12 08:47:46,206 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-010 [1] + systemctl stop docker + echo 'starting services' starting services + systemctl daemon-reload + for service in etcd docker.socket docker swarm-manager + echo 'activating service etcd' activating service etcd + systemctl enable etcd Failed to enable unit: Unit file etcd.service does not exist. + systemctl --no-block start etcd Failed to start etcd.service: Unit etcd.service not found. + for service in etcd docker.socket docker swarm-manager + echo 'activating service docker.socket' activating service docker.socket + systemctl enable docker.socket 1) Seems etcd service is not installed , 2) the instance required to contact controller on port 5000 (is it correct ?) Please help me. Regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Wed Dec 12 12:21:15 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 12 Dec 2018 21:21:15 +0900 Subject: [openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04) In-Reply-To: <1677e3f2b18.e6941ff4108960.3659294646236910868@ghanshyammann.com> References: <20181106210549.4nv6co64qbqk5l7f@skaplons-mac> <20181106212533.v6eapwxd2ksggrlo@yuggoth.org> <4C6DAE05-6FFB-4671-89DA-5EB07229DB26@redhat.com> <166eb10f8fb.117c25ba675341.116732651371514382@ghanshyammann.com> <1673a198ed5.ffd33ea931022.2184156112862411416@ghanshyammann.com> <1677e3f2b18.e6941ff4108960.3659294646236910868@ghanshyammann.com> Message-ID: <167a25d310b.e84195b728207.4908393628290283653@ghanshyammann.com> ---- On Wed, 05 Dec 2018 21:02:08 +0900 Ghanshyam Mann wrote ---- Devstack and Tempest patch to move base job to Bionic are merged now. tempest-full, tempest-slow, etc + all jobs derived from tempest or devstack base jobs are running on bionic now. devstack provide bionic nodeset now, any zuulv3 native job running on xenail (zuulv3 jobs not derived from devstack/tempest base jobs) can be moved to bionic using those nodeset. Note- all the legacy jobs are still on xenial and they will be move to Bionic during migrating them to zullv3 native. -gmann > Reminder to test your project specific jobs if those are dependent on Devstack or Tempest base jobs and keep adding the results on etherpad- https://etherpad.openstack.org/p/devstack-bionic > > We will merge the Devstack and Tempest base job on Bionic on 10th Dec 2018. > > -gmann > > > ---- On Thu, 22 Nov 2018 15:26:52 +0900 Ghanshyam Mann wrote ---- > > 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 aspiers at suse.com Wed Dec 12 12:28:06 2018 From: aspiers at suse.com (Adam Spiers) Date: Wed, 12 Dec 2018 12:28:06 +0000 Subject: [all]Forum summary: Expose SIGs and WGs In-Reply-To: References: Message-ID: <20181212122806.kll3gw6w65wz3js3@pacific.linksys.moosehall> Rico Lin wrote: >Dear all > >Here is the summary for forum `Expose SIGs and WGs` (etherpad [1] ). >This concept still under development, so this is an open discussion and >we need more feedbacks. >Here are some general agreements on actions or ideas that we think it's >worth to find the answer. Thanks for driving this, Rico! And sorry for the slow reply. >*Set up guidelines for SIGs/WGs/Teams for interaction specific to this >around tracking cross-project work* >We tend to agree that we kind of lack for a guideline or a sample for >SIGs/WGs, since all SIGs/WGs formed for different interest, we won't try to >unify tools (unless that's what everyone agrees on) or rules for all >groups. What we can do is to give more help to groups and provide a clear >way for how they can set up cross-project works if they want to. Also, we >can provide information on how to reach to users, ops, and developers and >bridge them up. And we can even do a more general guideline or sample on >how other SIGs/WGs are doing with their own workflow. Like self-healing SIG >working on getting user story and feedback and use them to general better >document/guideline for other users. Also, public cloud WG working on >collect issues from public cloud providers and bring those issues to >projects. Those IMO are great examples that we should put them down >somewhere for cross SIGs/WGs consideration. We already have some basic guidelines for communication here: https://governance.openstack.org/sigs/ Maybe we should just extend that with some suggested best practices? For example: - Set up an openstack/$signame-sig git repository (we could even create a cookiecutter repo, or is that overkill?) - Set up a StoryBoard project linked with that git repository - For cross-project collaboration, recommend the following: - submit cross-project stories to StoryBoard - submit cross-project specs to the SIG's git repo (and the SIG lead could set up a template for these, e.g. http://git.openstack.org/cgit/openstack/self-healing-sig/tree/specs/template.rst ) - post cross-project discussion to openstack-discuss@ with [$signame-sig] and all the appropriate [$project] tags in the Subject header >As a further idea, we can even >discuss if it's a common interest to have a SIG to help on SIGs. We already have that ;-) It's the "meta" SIG, mentioned here: https://governance.openstack.org/sigs/ >*A workflow for tracking:* >This kind of follow above item. If we're going to set up a workflow, what >we can add in to help people live an easier life? This is also an idea that >no one in the room thinks it's a bad one, so it means in long term, it >might worth our time to provide more clear information on what exactly >workflow that we suggest everyone use. Doesn't StoryBoard handle tracking nicely? >*Discuss SIG spec repo*: >The discussion here is how can we monitoring SIGs/WGs health and track >tasks. When talking about tasks we not just talking about bugs, but also >features that's been considered as essential tasks for SIGs/WGs. We need a >place to put them down in a trackable way (from a user story to a patch for >implementation). Again I think StoryBoard works nicely for this. >*Ask foundation about have project update for SIGs/WGs*: >One action we can start right now is to let SIGs/WGs present a project >update (or even like a session but give each group 5 mins to present). >This should help group getting more attention. And even capable to send >out messages like what's the most important features or bug fixes they >need from project teams, or what's the most important tasks that are under >planning or working on. >Fortunately, we got Melvin Hillsman (UC) volunteer on this task. Yes, I think this is really important. And from personal experience as a SIG chair, I know it would help me to have someone pestering me to provide project updates ;-) >The thing that we also wish to do is to clear the message here. We think >most of the tools are already there, so we shouldn't need to ask project >teams to do any huge change. But still, we found there are definitely some >improvements that we can do to better bridge users, ops, and developers. >You might find some information here didn't give you a clear answer. And >that's because of we still under open discussion for this. And I assume we >gonna keep finding actions from discussions that we can do right away. We >will try to avoid that we have to do the exact same session with the same >argument over and over again. >So please give your feedback, any idea, or give us your help if you also >care about this. Yes, I think you are right. My simple suggestion is above: just add some best practices to the governance-sigs page. From dangtrinhnt at gmail.com Wed Dec 12 12:32:23 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Wed, 12 Dec 2018 21:32:23 +0900 Subject: [Searchlight][Zuul] tox failed tests at zuul check only In-Reply-To: References: <1543855087.1459125.1597252016.5DBF506E@webmail.messagingengine.com> <1544206572.507632.1602338888.7C5CDA48@webmail.messagingengine.com> <20181211150147.f3oj4gzkufpbp2fc@yuggoth.org> Message-ID: BTW, I switched to use the bindep.txt and make the test script much simpler. Thanks :) On Wed, Dec 12, 2018 at 5:35 PM Trinh Nguyen wrote: > Hi all, > > Finally, found the problem. For some reason, py27 has to wait a little bit > longer for the elasticsearch instance to be up. I just let the functional > setup code wait a little while. > > Problem solved. Amazing! :) > > Many thanks :) > > On Wed, Dec 12, 2018 at 11:37 AM Trinh Nguyen > wrote: > >> Trying to look through the logs of the last merged patch set [1] but >> nothing there. Is there any other places that I can look into? >> >> [1] https://review.openstack.org/#/c/616056/ >> >> Thanks, >> >> On Wed, Dec 12, 2018 at 9:47 AM Trinh Nguyen >> wrote: >> >>> Thank Jeremy. I will look into bindep. >>> >>> On Wed, Dec 12, 2018 at 12:04 AM Jeremy Stanley >>> wrote: >>> >>>> On 2018-12-11 15:21:47 +0900 (+0900), Trinh Nguyen wrote: >>>> > I'm trying to figure out how Zuul processes the test-setup.sh [1] >>>> > file to adopt new dependencies. >>>> [...] >>>> >>>> Looking at what you've put in there for your JRE packages, those >>>> would be better handled in a bindep.txt file in your repository. >>>> Running tools/test-setup.sh in jobs is really to catch other sorts >>>> of setup steps like precreating a database or formatting and >>>> mounting a particular filesystem your tests are going to rely on. >>>> For system package dependencies of your jobs, we have a declarative >>>> mechanism already which doesn't require complex conditional >>>> handling: we install whatever bindep says is missing. >>>> >>>> I see you're also leveraging tools/test-setup.sh to obtain packages >>>> of elasticsearch which are not available in the distributions on >>>> which your jobs run, which I guess is a suitable workaround though >>>> it seems odd to test on platforms which don't package the software >>>> on which your project relies. >>>> -- >>>> Jeremy Stanley >>>> >>> >>> >>> -- >>> *Trinh Nguyen* >>> *www.edlab.xyz * >>> >>> >> >> -- >> *Trinh Nguyen* >> *www.edlab.xyz * >> >> > > -- > *Trinh Nguyen* > *www.edlab.xyz * > > -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From aspiers at suse.com Wed Dec 12 13:20:44 2018 From: aspiers at suse.com (Adam Spiers) Date: Wed, 12 Dec 2018 13:20:44 +0000 Subject: [all][security-sig][meta-sig] Forum summary: Expose SIGs and WGs In-Reply-To: References: Message-ID: <20181212132044.ibvr6dd54zrbqkj3@pacific.linksys.moosehall> Matt Riedemann wrote: >On 12/3/2018 11:42 AM, Rico Lin wrote: >>We also have some real story (Luzi's story) for people to get a >>better understanding of why current workflow can look like for >>someone who tries to help. > >I looked over the note on this in the etherpad. Me too - in case anyone missed the link to this initiative around image encryption, it's near the bottom of: https://etherpad.openstack.org/p/expose-sigs-and-wgs And BTW it sounds like a really cool initiative to me! In fact I think it could nicely complement the work I am doing on adding AMD SEV support to nova: https://review.openstack.org/#/c/609779/ >They did what they >were asked and things have stalled. At this point, I think it comes >down to priorities, and in order to prioritize something big like this >that requires coordinated work across several projects, we are going >to need more stakeholders coming forward and saying they also want >this feature so the vendors who are paying the people to work upstream >can be given specific time to give this the attention it needs. And >that ties back into getting the top 1 or 2 wishlist items from each >SIG and trying to sort those based on what is the highest rated most >common need for the greatest number of people - sort of like what we >see happening with the resource delete API community wide goal >proposal. Agreed. The Security SIG sounds like a natural home for it. I'm going to wildly speculate that maybe part of the reason it stalled is that it was perceived as coming from a couple of individuals rather than a SIG. If the initiative had been backed by the Security SIG as something worth prioritising, then maybe it could have received wider attention. Also maybe copying a couple of tricks from the Self-healing SIG might (or might not) help. Firstly, try to find one or two security-minded people from each involved project who are willing to act as liasons with the Security SIG: https://wiki.openstack.org/wiki/Self-healing_SIG#Project_liasons Those people won't necessarily need to commit any time to development themselves, but hopefully they could volunteer to review specs specific to their project, and later patches too. Secondly, track all work on StoryBoard so that the current status is always clearly visible. A couple of other things struck me about this initiative: - They were requested to propose separate specs for each involved project (Nova, Cinder and Glance in this case). This resulted in quite a bit of duplication between the specs, but maybe that was unavoidable. - The question where to put the shared encryption and decryption code remained unresolved, even though of the three options proposed, only the oslo option had no cons listed: https://etherpad.openstack.org/p/library-for-image-encryption-and-decryption oslo seems like a natural place to put it, so maybe the solution is to submit this spec to oslo? Although if the initiative was hosted by the Security SIG, then as a last resort the SIG could set up a git repository to host the code, at least as a temporary measure. From josephine.seifert at secustack.com Wed Dec 12 13:57:31 2018 From: josephine.seifert at secustack.com (Josephine Seifert) Date: Wed, 12 Dec 2018 14:57:31 +0100 Subject: [all][security-sig][meta-sig] Forum summary: Expose SIGs and WGs In-Reply-To: <20181212132044.ibvr6dd54zrbqkj3@pacific.linksys.moosehall> References: <20181212132044.ibvr6dd54zrbqkj3@pacific.linksys.moosehall> Message-ID: <1b668052-b1f3-a404-2811-0acc8d76fb5c@secustack.com> Am 12.12.18 um 14:20 schrieb Adam Spiers: > Matt Riedemann wrote: >> On 12/3/2018 11:42 AM, Rico Lin wrote: >>> We also have some real story (Luzi's story) for people to get a >>> better understanding of why current workflow can look like for >>> someone who tries to help. >> >> I looked over the note on this in the etherpad. > > Me too - in case anyone missed the link to this initiative around > image encryption, it's near the bottom of: >    https://etherpad.openstack.org/p/expose-sigs-and-wgs > > And BTW it sounds like a really cool initiative to me!  In fact I > think it could nicely complement the work I am doing on adding AMD SEV > support to nova: >    https://review.openstack.org/#/c/609779/ > Thank you, it's nice to hear that there are people who would like to have image encryption in OpenStack. > > A couple of other things struck me about this initiative: >  - They were requested to propose separate specs for each involved >    project (Nova, Cinder and Glance in this case).  This resulted in >    quite a bit of duplication between the specs, but maybe that was >    unavoidable. > We were told, they need those specs for documentation purposes. So I can understand why we have to do this. The downside is of course, that it not only takes longer to write / update the specs (as we really like to update all at the same time - so they are consistent), but mainly the project teams would only review the spec within their project (with a few exceptions).  >  - The question where to put the shared encryption and decryption code >    remained unresolved, even though of the three options proposed, only >    the oslo option had no cons listed: > >       > https://etherpad.openstack.org/p/library-for-image-encryption-and-decryption > >    oslo seems like a natural place to put it, so maybe the solution is >    to submit this spec to oslo? > Actually we already talked to the Security SIG, which are basically the same people as in Barbican, at the Summit. And we agreed that a new library in oslo would be a good option. So we proposed a spec for a new oslo-library:  https://review.openstack.org/#/c/618754/ Sadly there aren't many people in the Security SIG / Barbican right now and they also have their own features and projects (Barbican) to maintain. A few people from the other involved project would maybe help. I am currently talking to Ildiko about pop-up teams, which would be an option to organize things. regards, Josephine (Luzi) From fungi at yuggoth.org Wed Dec 12 14:23:16 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 12 Dec 2018 14:23:16 +0000 Subject: [all][security-sig][meta-sig] Forum summary: Expose SIGs and WGs In-Reply-To: <20181212132044.ibvr6dd54zrbqkj3@pacific.linksys.moosehall> References: <20181212132044.ibvr6dd54zrbqkj3@pacific.linksys.moosehall> Message-ID: <20181212142315.j3wccez5monwl4ma@yuggoth.org> On 2018-12-12 13:20:44 +0000 (+0000), Adam Spiers wrote: > Matt Riedemann wrote: [...] > > They did what they were asked and things have stalled. At this point, I > > think it comes down to priorities, and in order to prioritize something > > big like this that requires coordinated work across several projects, we > > are going to need more stakeholders coming forward and saying they also > > want this feature so the vendors who are paying the people to work > > upstream can be given specific time to give this the attention it needs. > > And that ties back into getting the top 1 or 2 wishlist items from each > > SIG and trying to sort those based on what is the highest rated most > > common need for the greatest number of people - sort of like what we see > > happening with the resource delete API community wide goal proposal. > > Agreed. The Security SIG sounds like a natural home for it. I'm going to > wildly speculate that maybe part of the reason it stalled is that it was > perceived as coming from a couple of individuals rather than a SIG. If the > initiative had been backed by the Security SIG as something worth > prioritising, then maybe it could have received wider attention. [...] We've seen Luzi and mhen in recent Security SIG weekly IRC meetings talking about the proposed specs for Cinder, Glance and Nova. However most of the representation in the Security SIG is from people involved in VMT work as well as some contributors from the Keystone and Barbican teams. As much as I'd like to say the Security SIG is a sensible place to drive an effort like this, most teams in OpenStack aren't really engaged in that SIG and the people who are regulars to our meetings lack the capacity to act as project managers in that regard. I'm happy to state, as a participant in the Security SIG, that I think having image encryption in OpenStack would be a great feature. I don't expect that alone helps an awful lot though. -- 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 Wed Dec 12 14:31:14 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 12 Dec 2018 09:31:14 -0500 Subject: [barbican][castellan] failures in barbican/castellan cross test job In-Reply-To: References: Message-ID: The patch https://review.openstack.org/622710 is trying to update the author address in the packaging metadata for castellan. The barbican-simple-crypto-devstack-tempest-castellan-from-git job is failing 5 tests, at least one of which gives the error message "Build of instance f211971d-0214-4b28-9b8c-c9ff92deabce aborted: cannot import name api", which appears to be a real error. Do barbican master and castellan master work together? Is there anyone with time to look into why that job is failing? -- Doug From doug at doughellmann.com Wed Dec 12 14:33:13 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 12 Dec 2018 09:33:13 -0500 Subject: [openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04) In-Reply-To: <167a25d310b.e84195b728207.4908393628290283653@ghanshyammann.com> References: <20181106210549.4nv6co64qbqk5l7f@skaplons-mac> <20181106212533.v6eapwxd2ksggrlo@yuggoth.org> <4C6DAE05-6FFB-4671-89DA-5EB07229DB26@redhat.com> <166eb10f8fb.117c25ba675341.116732651371514382@ghanshyammann.com> <1673a198ed5.ffd33ea931022.2184156112862411416@ghanshyammann.com> <1677e3f2b18.e6941ff4108960.3659294646236910868@ghanshyammann.com> <167a25d310b.e84195b728207.4908393628290283653@ghanshyammann.com> Message-ID: Ghanshyam Mann writes: > ---- On Wed, 05 Dec 2018 21:02:08 +0900 Ghanshyam Mann wrote ---- > > Devstack and Tempest patch to move base job to Bionic are merged now. tempest-full, tempest-slow, etc + all jobs derived from tempest or devstack base jobs are running on bionic now. > > devstack provide bionic nodeset now, any zuulv3 native job running on xenail (zuulv3 jobs not derived from devstack/tempest base jobs) can be moved to bionic using those nodeset. > > Note- all the legacy jobs are still on xenial and they will be move to Bionic during migrating them to zullv3 native. > > -gmann Excellent! Thanks to you and the QA team for continuing to drive this migration. -- Doug From fungi at yuggoth.org Wed Dec 12 14:46:06 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 12 Dec 2018 14:46:06 +0000 Subject: [all][security-sig][meta-sig] Forum summary: Expose SIGs and WGs In-Reply-To: <1b668052-b1f3-a404-2811-0acc8d76fb5c@secustack.com> References: <20181212132044.ibvr6dd54zrbqkj3@pacific.linksys.moosehall> <1b668052-b1f3-a404-2811-0acc8d76fb5c@secustack.com> Message-ID: <20181212144606.wswpl7xgnlqu2nzs@yuggoth.org> On 2018-12-12 14:57:31 +0100 (+0100), Josephine Seifert wrote: [...] > Actually we already talked to the Security SIG, which are > basically the same people as in Barbican, at the Summit. [...] I really appreciate the way you've engaged with other regulars in the Security SIG. It's a bit of a mischaracterization to suggest that they're mostly Barbican folks though. We do see redrobot (Douglas Mendizábal) semi-frequently in our IRC meetings, but most of our regulars at those meetings are vulnerability managers, core reviewers for Keystone, authors on the OpenStack Security Guide, maintainers of the Bandit static analyzer... We've shared a room with the Barbican team at some recent OpenStack Project Team Gatherings to help conserve available space at the conference venues since we definitely have some overlapping interests, so that could be part of the confusion. -- 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 witold.bedyk at est.fujitsu.com Wed Dec 12 14:57:48 2018 From: witold.bedyk at est.fujitsu.com (Bedyk, Witold) Date: Wed, 12 Dec 2018 14:57:48 +0000 Subject: [vitrage][monasca] Monasca datasource for Vitrage In-Reply-To: References: Message-ID: Hi, thanks Bartosz for the POC and great presentation in Berlin. Thanks Ifat for championing the effort and starting the thread. > There is one issue that we need to close though – how to connect the Monasca alarms to the resources in Vitrage. > > In order to connect an alarm to a resource, Vitrage should be able to identify that resource in its entity graph using the dimensions coming from Monasca. I > understood that these dimensions are configurable and not pre-defined. Correct. To make the picture complete: every alarm contains an associated `metric name` and a set of dimensions which identify the monitored resource. Both metric name and dimensions could potentially be used in Vitrage. 1. For OpenStack services we typically use dimension keys `hostname` and `service`. Examples would be: `name`: `http_status`, `dimensions`: {`hostname`: `node1`, `service`: `keystone`, `url`: `http://node1/identity`} Libvirt metrics all have the dimension keys `hostname`, `service`=`compute`, `resource_id`=instance_id 2. For other resources I’m not sure if we can define a general rule for assignments. As you have said, the unique information may be included in more the one dimension. For Prometheus, we use labels on each metric as dimensions. Additional dimensions can be configured in agent per Prometheus endpoint. How do you assign resources for alarms from Zabbix or Prometheus datasources? Best greetings Witek From: Ifat Afek Sent: Dienstag, 11. Dezember 2018 10:46 To: openstack-discuss at lists.openstack.org Cc: b.zurkowski at samsung.com; Bedyk, Witold Subject: [vitrage][monasca] Monasca datasource for Vitrage Hi, In case you missed it, we have a POC of a Monasca datasource for Vitrage [1] ☺ Thanks Bartosz Zurkowski for the effort! There is one issue that we need to close though – how to connect the Monasca alarms to the resources in Vitrage. In order to connect an alarm to a resource, Vitrage should be able to identify that resource in its entity graph using the dimensions coming from Monasca. I understood that these dimensions are configurable and not pre-defined. Basically, there are two cases. 1. For OpenStack resources, all Vitrage needs to know is the UUID of the resource. I assume that there is always a dimension for that resource, right? Is the dimension always called the same? If not, how can Vitrage identify that this is the interesting dimension (if there are other dimensions for this alarm)? 2. For other resources it is more complicated, as they might not have a natural unique id. For example, a NIC id in Vitrage may be generated out of the host name + NIC name. Monasca alarm may have two separate dimensions for the host and nic. How can Vitrage understand that those two dimensions identify the resource? In other cases, Vitrage may need a resource_type dimension to uniquely identify the resource. Another question: I understood that Monasca can send alarms that originate from other monitors like Ceilometer, Prometheus etc. What are the dimensions in these cases? Monasca team, I’ll be happy to hear your opinion about these questions. If you can provide several different examples it will be very helpful. Thanks, Ifat [1] https://review.openstack.org/#/c/622899 -------------- next part -------------- An HTML attachment was scrubbed... URL: From prometheanfire at gentoo.org Tue Dec 11 23:49:17 2018 From: prometheanfire at gentoo.org (Matthew Thode) Date: Tue, 11 Dec 2018 17:49:17 -0600 Subject: [oslo][tooz][requirements] Tooz etcd3 tests blocked on grpcio>=1.16.0 In-Reply-To: <23246b05-d96f-f981-5ab9-a9d102fcb480@nemebean.com> References: <23246b05-d96f-f981-5ab9-a9d102fcb480@nemebean.com> Message-ID: <20181211234917.irayx33fwz624hgn@gentoo.org> On 18-12-11 17:03:12, Ben Nemec wrote: > The tooz gate is currently blocked on > https://bugs.launchpad.net/python-tooz/+bug/1808046 which seems to have been > introduced with grpcio 1.16.0. I need to raise that issue with the grpc > folks, but in the meantime should we block the problematic versions? grpcio > isn't currently in g-r and I can't remember what our policy on transitive > dependencies is, so I thought I'd solicit opinions. > I'm not aware of any policy on how we block dependencies like this. At the moment I'd suggest opening a bug with us so we don't forget and add it to global-requirements (preferably with a comment). Answering all the questions as normal. https://storyboard.openstack.org/#!/project/openstack/requirements -- Matthew Thode (prometheanfire) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From liliueecg at gmail.com Wed Dec 12 02:35:46 2018 From: liliueecg at gmail.com (Li Liu) Date: Tue, 11 Dec 2018 21:35:46 -0500 Subject: [cyborg] IRC meeting for Dec 11th Message-ID: Hi Team, Just a last minute reminder that the IRC is happening in a new time slot this week at 0300 UTC Tuesday (10:00 pm est(Tuesday) / 7:00 pm pst(Tuesday) / 11am beijing time (Wednesday)) Agenda for this week's meeting: 1. Finalize https://review.openstack.org/#/c/615462/ 2. Status update on various outstanding work items -- Thank you Regards Li -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Wed Dec 12 09:03:16 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Wed, 12 Dec 2018 10:03:16 +0100 Subject: openstack queens magnum swarm error Message-ID: Hello Everyone, I installed queens on centos with magnum and I am trying to create a swarm cluster with one muster and one node. The image I used is fedora-atomic 27 update 04 The stack generated end with an error and magnum conductor reports: ec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.304 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key api_address Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.305 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key swarm_masters Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key swarm_nodes Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key discovery_url Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.317 17964 ERROR magnum.drivers.heat.driver [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] Cluster error, stack status: CREATE_FAILED, stack_id: 306bd83a-7878-4d94-8ed0-1d297eec9768, reason: Resource CREATE failed: WaitConditionFailure: resources.swarm_nodes.resources[0].resources.node_wait_condition: swarm-agent service failed to start. I connected to the master node for verifyng if swarm agent is running. In the cloud init log I found: requests.exceptions.ConnectionError: HTTPConnectionPool(host='10.102.184.190', port=5000): Max retries exceeded with url: /v3//auth/tokens (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 110] Connection timed out',)) Cloud-init v. 0.7.9 running 'modules:final' at Wed, 12 Dec 2018 08:45:31 +0000. Up 55.54 seconds. 2018-12-12 08:47:45,858 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-005 [1] /var/lib/cloud/instance/scripts/part-006: line 13: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-006: line 26: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-006: line 38: /etc/etcd/etcd.conf: No such file or directory 2018-12-12 08:47:45,870 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-006 [1] Configuring docker network ... Configuring docker network service ... Removed /etc/systemd/system/multi-user.target.wants/docker-storage-setup.service. New size given (1280 extents) not larger than existing size (4863 extents) ERROR: There is not enough free space in volume group atomicos to create data volume of size MIN_DATA_SIZE=2G. 2018-12-12 08:47:46,206 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-010 [1] + systemctl stop docker + echo 'starting services' starting services + systemctl daemon-reload + for service in etcd docker.socket docker swarm-manager + echo 'activating service etcd' activating service etcd + systemctl enable etcd Failed to enable unit: Unit file etcd.service does not exist. + systemctl --no-block start etcd Failed to start etcd.service: Unit etcd.service not found. + for service in etcd docker.socket docker swarm-manager + echo 'activating service docker.socket' activating service docker.socket + systemctl enable docker.socket 1) Seems etcd service is not installed , 2) the instance required to contact controller on port 5000 (is it correct ?) Please help me. Regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Wed Dec 12 09:06:45 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Wed, 12 Dec 2018 10:06:45 +0100 Subject: openstack queens magnum error Message-ID: Hello Everyone, I installed queens on centos with magnum and I am trying to create a swarm cluster with one muster and one node. The image I used is fedora-atomic 27 update 04 The stack generated end with an error and magnum conductor reports: ec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.304 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key api_address Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.305 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key swarm_masters Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key swarm_nodes Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key discovery_url Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.317 17964 ERROR magnum.drivers.heat.driver [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] Cluster error, stack status: CREATE_FAILED, stack_id: 306bd83a-7878-4d94-8ed0-1d297eec9768, reason: Resource CREATE failed: WaitConditionFailure: resources.swarm_nodes.resources[0].resources.node_wait_condition: swarm-agent service failed to start. I connected to the master node for verifyng if swarm agent is running. In the cloud init log I found: requests.exceptions.ConnectionError: HTTPConnectionPool(host='10.102.184.190', port=5000): Max retries exceeded with url: /v3//auth/tokens (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 110] Connection timed out',)) Cloud-init v. 0.7.9 running 'modules:final' at Wed, 12 Dec 2018 08:45:31 +0000. Up 55.54 seconds. 2018-12-12 08:47:45,858 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-005 [1] /var/lib/cloud/instance/scripts/part-006: line 13: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-006: line 26: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-006: line 38: /etc/etcd/etcd.conf: No such file or directory 2018-12-12 08:47:45,870 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-006 [1] Configuring docker network ... Configuring docker network service ... Removed /etc/systemd/system/multi-user.target.wants/docker-storage-setup.service. New size given (1280 extents) not larger than existing size (4863 extents) ERROR: There is not enough free space in volume group atomicos to create data volume of size MIN_DATA_SIZE=2G. 2018-12-12 08:47:46,206 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-010 [1] + systemctl stop docker + echo 'starting services' starting services + systemctl daemon-reload + for service in etcd docker.socket docker swarm-manager + echo 'activating service etcd' activating service etcd + systemctl enable etcd Failed to enable unit: Unit file etcd.service does not exist. + systemctl --no-block start etcd Failed to start etcd.service: Unit etcd.service not found. + for service in etcd docker.socket docker swarm-manager + echo 'activating service docker.socket' activating service docker.socket + systemctl enable docker.socket 1) Seems etcd service is not installed , 2) the instance required to contact controller on port 5000 (is it correct ?) Please help me. Regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From aspiers at suse.com Wed Dec 12 15:10:21 2018 From: aspiers at suse.com (Adam Spiers) Date: Wed, 12 Dec 2018 15:10:21 +0000 Subject: [all][security-sig][meta-sig] Forum summary: Expose SIGs and WGs In-Reply-To: <1b668052-b1f3-a404-2811-0acc8d76fb5c@secustack.com> References: <20181212132044.ibvr6dd54zrbqkj3@pacific.linksys.moosehall> <1b668052-b1f3-a404-2811-0acc8d76fb5c@secustack.com> Message-ID: <20181212151021.c3avsxxjwaytj5d7@pacific.linksys.moosehall> Josephine Seifert wrote: >Am 12.12.18 um 14:20 schrieb Adam Spiers: > >> Matt Riedemann wrote: >>> On 12/3/2018 11:42 AM, Rico Lin wrote: >>>> We also have some real story (Luzi's story) for people to get a >>>> better understanding of why current workflow can look like for >>>> someone who tries to help. >>> >>> I looked over the note on this in the etherpad. >> >> Me too - in case anyone missed the link to this initiative around >> image encryption, it's near the bottom of: >>    https://etherpad.openstack.org/p/expose-sigs-and-wgs >> >> And BTW it sounds like a really cool initiative to me!  In fact I >> think it could nicely complement the work I am doing on adding AMD SEV >> support to nova: >>    https://review.openstack.org/#/c/609779/ >> >Thank you, it's nice to hear that there are people who would like to >have image encryption in OpenStack. :-) >> A couple of other things struck me about this initiative: >>  - They were requested to propose separate specs for each involved >>    project (Nova, Cinder and Glance in this case).  This resulted in >>    quite a bit of duplication between the specs, but maybe that was >>    unavoidable. >> >We were told, they need those specs for documentation purposes. So I can >understand why we have to do this. The downside is of course, that it >not only takes longer to write / update the specs (as we really like to >update all at the same time - so they are consistent), but mainly the >project teams would only review the spec within their project (with a >few exceptions).  > >>  - The question where to put the shared encryption and decryption code >>    remained unresolved, even though of the three options proposed, only >>    the oslo option had no cons listed: >> >>       >> https://etherpad.openstack.org/p/library-for-image-encryption-and-decryption >> >>    oslo seems like a natural place to put it, so maybe the solution is >>    to submit this spec to oslo? >> >Actually we already talked to the Security SIG, which are basically the >same people as in Barbican, at the Summit. And we agreed that a new >library in oslo would be a good option. Got it - thanks to you and Jeremy for the extra context here. >So we proposed a spec for a new oslo-library:  >https://review.openstack.org/#/c/618754/ Ah, nice - thanks! What do you think about my suggestion of tracking this whole initiative as a story in StoryBoard? IMHO that would be a convenient way of tracking all the specs and any other related activity together from one place. From gagehugo at gmail.com Wed Dec 12 15:11:04 2018 From: gagehugo at gmail.com (Gage Hugo) Date: Wed, 12 Dec 2018 09:11:04 -0600 Subject: [all][security-sig][meta-sig] Forum summary: Expose SIGs and WGs In-Reply-To: <20181212144606.wswpl7xgnlqu2nzs@yuggoth.org> References: <20181212132044.ibvr6dd54zrbqkj3@pacific.linksys.moosehall> <1b668052-b1f3-a404-2811-0acc8d76fb5c@secustack.com> <20181212144606.wswpl7xgnlqu2nzs@yuggoth.org> Message-ID: ++ on engaging with us in the Security SIG, it's great to get more activity that is aligned with security and image encryption definitely seems like it fits in OpenStack. Unfortunately, as fungi mentioned, the Security SIG is currently not very active at the moment with the current members' responsibilities stretched over multiple other groups. On Wed, Dec 12, 2018 at 8:46 AM Jeremy Stanley wrote: > On 2018-12-12 14:57:31 +0100 (+0100), Josephine Seifert wrote: > [...] > > Actually we already talked to the Security SIG, which are > > basically the same people as in Barbican, at the Summit. > [...] > > I really appreciate the way you've engaged with other regulars in > the Security SIG. It's a bit of a mischaracterization to suggest > that they're mostly Barbican folks though. We do see redrobot > (Douglas Mendizábal) semi-frequently in our IRC meetings, but most > of our regulars at those meetings are vulnerability managers, core > reviewers for Keystone, authors on the OpenStack Security Guide, > maintainers of the Bandit static analyzer... We've shared a room > with the Barbican team at some recent OpenStack Project Team > Gatherings to help conserve available space at the conference venues > since we definitely have some overlapping interests, so that could > be part of the confusion. > -- > Jeremy Stanley > -------------- next part -------------- An HTML attachment was scrubbed... URL: From massimo.sgaravatto at gmail.com Wed Dec 12 15:32:53 2018 From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto) Date: Wed, 12 Dec 2018 16:32:53 +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: If I am not wrong another problem with the "openstack usage show" command is that it doesn't take into accounts instances that are in the shadow tables (i.e. deleted instances moved to the shadow tables using the 'nova-manage db archive_deleted_rows' command). Or the problem is with the 'nova-manage db archive_deleted_rows' which doesn't allow to specify a time range (i.e. to archive only instances deleted > x days ago) :-) I had a quick look to the collectd+virt plugin. It would be great if it would allow to also use the OpenStack project id when reporting stats (since I am interesting in producing per project accounting reports) ... Thanks again Cheers, Massimo On Thu, Nov 29, 2018 at 11:57 AM Massimo Sgaravatto < massimo.sgaravatto at gmail.com> wrote: > 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 josephine.seifert at secustack.com Wed Dec 12 15:46:59 2018 From: josephine.seifert at secustack.com (Josephine Seifert) Date: Wed, 12 Dec 2018 16:46:59 +0100 Subject: [all][security-sig][meta-sig] Forum summary: Expose SIGs and WGs In-Reply-To: <20181212151021.c3avsxxjwaytj5d7@pacific.linksys.moosehall> References: <20181212132044.ibvr6dd54zrbqkj3@pacific.linksys.moosehall> <1b668052-b1f3-a404-2811-0acc8d76fb5c@secustack.com> <20181212151021.c3avsxxjwaytj5d7@pacific.linksys.moosehall> Message-ID: > What do you think about my suggestion of tracking this whole > initiative as a story in StoryBoard?  IMHO that would be a convenient > way of tracking all the specs and any other related activity together > from one place. I will have to look into this, but it seems like a reasonable idea indeed. Thank you. I might try to combine it with the pop-up team idea :) From eumel at arcor.de Wed Dec 12 16:16:14 2018 From: eumel at arcor.de (Frank Kloeker) Date: Wed, 12 Dec 2018 17:16:14 +0100 Subject: [i18n] Team meeting Thursday 07:00 UTC #openstack-meeting Message-ID: <6b75f796d552ff0c2e8310d721788de0@arcor.de> Hello, just a reminder, we want to start this week with our new meeting format with combined meeting between I18n and Docs team. Next meeting would be start Thursday 07:00 UTC in #openstack-meeting. Logistic to see on [1]. Agenda is posted on [2]. Please add your topics if you want to discuss I18n things. kind regards Frank [1] http://eavesdrop.openstack.org/#I18N_Team_Meeting [2] https://wiki.openstack.org/wiki/Meetings/I18nTeamMeeting From hberaud at redhat.com Wed Dec 12 16:46:22 2018 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 12 Dec 2018 17:46:22 +0100 Subject: [oslo][meeting] agenda topics - RFE Configuration mapping tool for upgrade priority tracking Message-ID: Hey folks, I've added a topics to the next oslo meeting agenda. I want to discuss about the migration and especially about RFE configuration mapping tool. The main goal is to discuss about it to raise the priority. FYI I summarize some useful elements in this email. Specs: * https://review.openstack.org/#/c/520043/ * https://review.openstack.org/#/c/526314/ * https://review.openstack.org/#/c/526261/ Code reviews: https://review.openstack.org/#/q/status:open+project:openstack/oslo.config+branch:master+topic:migrator Some reviews was validated but some others need to be recovered due to the lack of response about the original authors. Do not hesitate to debate about this topics by responding at this thread to help us to have a better big picture before starting the meeting. Thanks folks. -- 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 openstack at nemebean.com Wed Dec 12 16:47:58 2018 From: openstack at nemebean.com (Ben Nemec) Date: Wed, 12 Dec 2018 10:47:58 -0600 Subject: [oslo][tooz][requirements] Tooz etcd3 tests blocked on grpcio>=1.16.0 In-Reply-To: <20181212023515.GB6373@thor.bakeyournoodle.com> References: <23246b05-d96f-f981-5ab9-a9d102fcb480@nemebean.com> <20181212023515.GB6373@thor.bakeyournoodle.com> Message-ID: <98b2ab47-9197-0f16-2cb1-0bd536c1ad4c@nemebean.com> On 12/11/18 8:35 PM, Tony Breeds wrote: > On Tue, Dec 11, 2018 at 05:03:12PM -0600, Ben Nemec wrote: >> The tooz gate is currently blocked on >> https://bugs.launchpad.net/python-tooz/+bug/1808046 which seems to have been >> introduced with grpcio 1.16.0. I need to raise that issue with the grpc >> folks, but in the meantime should we block the problematic versions? grpcio >> isn't currently in g-r and I can't remember what our policy on transitive >> dependencies is, so I thought I'd solicit opinions. > > Yup just add it in this section: > http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n479 Done: https://review.openstack.org/624759 > > Bonus points if you have a second patch that removes daiquiri from that > section as we're clearly not blocking version any more. And done: https://review.openstack.org/624760 > > Yours Tony. > From mriedemos at gmail.com Wed Dec 12 16:51:01 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 12 Dec 2018 10:51:01 -0600 Subject: [openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04) In-Reply-To: <167a25d310b.e84195b728207.4908393628290283653@ghanshyammann.com> References: <20181106210549.4nv6co64qbqk5l7f@skaplons-mac> <20181106212533.v6eapwxd2ksggrlo@yuggoth.org> <4C6DAE05-6FFB-4671-89DA-5EB07229DB26@redhat.com> <166eb10f8fb.117c25ba675341.116732651371514382@ghanshyammann.com> <1673a198ed5.ffd33ea931022.2184156112862411416@ghanshyammann.com> <1677e3f2b18.e6941ff4108960.3659294646236910868@ghanshyammann.com> <167a25d310b.e84195b728207.4908393628290283653@ghanshyammann.com> Message-ID: On 12/12/2018 6:21 AM, Ghanshyam Mann wrote: > Devstack and Tempest patch to move base job to Bionic are merged now. tempest-full, tempest-slow, etc + all jobs derived from tempest or devstack base jobs are running on bionic now. Really? That's not what I'm seeing here: http://logs.openstack.org/77/610977/5/check/tempest-full-py3/e6c244a/zuul-info/inventory.yaml Which is a job from that devstack patch to move to bionic. -- Thanks, Matt From mriedemos at gmail.com Wed Dec 12 16:56:52 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 12 Dec 2018 10:56:52 -0600 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> <1673a198ed5.ffd33ea931022.2184156112862411416@ghanshyammann.com> <1677e3f2b18.e6941ff4108960.3659294646236910868@ghanshyammann.com> <167a25d310b.e84195b728207.4908393628290283653@ghanshyammann.com> Message-ID: On 12/12/2018 10:51 AM, Matt Riedemann wrote: > On 12/12/2018 6:21 AM, Ghanshyam Mann wrote: >> Devstack and Tempest patch to move base job to Bionic are merged now. >> tempest-full, tempest-slow, etc + all jobs derived from tempest or >> devstack base jobs are running on bionic now. > > Really? That's not what I'm seeing here: > > http://logs.openstack.org/77/610977/5/check/tempest-full-py3/e6c244a/zuul-info/inventory.yaml > > > Which is a job from that devstack patch to move to bionic. Sorry for the noise, Clark pointed out the magic is turned on in the tempest change: https://review.openstack.org/#/c/618169/ -- Thanks, Matt From ignaziocassano at gmail.com Wed Dec 12 17:49:37 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Wed, 12 Dec 2018 18:49:37 +0100 Subject: Magnum Fedora atomic 27 Message-ID: Hello All, Deploying swarm cluster based on Fedora atomic cloud images, does not work fine in queens. On master node cloud init reports etcd package missing. Does anyone find this issue? Regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From ociuhandu at cloudbasesolutions.com Wed Dec 12 17:57:47 2018 From: ociuhandu at cloudbasesolutions.com (Octavian Ciuhandu) Date: Wed, 12 Dec 2018 17:57:47 +0000 Subject: Magnum Fedora atomic 27 In-Reply-To: References: Message-ID: <97CD74D6187F9A4C8737FD2BD35403555A5387D4@CBSEX1.cloudbase.local> Hello, We never managed to get any version except the master work ok with Fedora atomic. We ended up deloying magnum from master with a queens openstack and this worked ok for us. We tried queens/pike/rocky and all of them seemed to have missing things in the templates and doing a simple diff on the template files shows huge changes. Regards, Octavian. From: Ignazio Cassano Sent: miercuri, 12 decembrie 2018 09:50 To: OpenStack Operators Subject: Magnum Fedora atomic 27 Hello All, Deploying swarm cluster based on Fedora atomic cloud images, does not work fine in queens. On master node cloud init reports etcd package missing. Does anyone find this issue? Regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From pkovar at redhat.com Wed Dec 12 18:09:38 2018 From: pkovar at redhat.com (Petr Kovar) Date: Wed, 12 Dec 2018 19:09:38 +0100 Subject: [docs] New meeting time and format (was: [i18n] Team meeting Thursday 07:00 UTC #openstack-meeting) In-Reply-To: <6b75f796d552ff0c2e8310d721788de0@arcor.de> References: <6b75f796d552ff0c2e8310d721788de0@arcor.de> Message-ID: <20181212190938.ce968f8016315789a01742ab@redhat.com> All, As a follow-up to Frank's announcement, I'm also adding the [docs] tag so people interested in discussing OpenStack documentation don't miss this. You can use https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting to add topics to our meeting agenda. As always, you can find the current schedule here: http://eavesdrop.openstack.org/#Documentation_Team_Meeting Note that the meeting channel has changed from #openstack-doc to #openstack-meeting. Thanks to Frank for updating the schedules! Thank you, pk On Wed, 12 Dec 2018 17:16:14 +0100 Frank Kloeker wrote: > Hello, > > just a reminder, we want to start this week with our new meeting format > with combined meeting between I18n and Docs team. > Next meeting would be start Thursday 07:00 UTC in #openstack-meeting. > Logistic to see on [1]. Agenda is posted on [2]. > Please add your topics if you want to discuss I18n things. > > kind regards > > Frank > > [1] http://eavesdrop.openstack.org/#I18N_Team_Meeting > [2] https://wiki.openstack.org/wiki/Meetings/I18nTeamMeeting > From ignaziocassano at gmail.com Wed Dec 12 18:32:03 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Wed, 12 Dec 2018 19:32:03 +0100 Subject: Magnum Fedora atomic 27 In-Reply-To: <97CD74D6187F9A4C8737FD2BD35403555A5387D4@CBSEX1.cloudbase.local> References: <97CD74D6187F9A4C8737FD2BD35403555A5387D4@CBSEX1.cloudbase.local> Message-ID: Hello Octavian, I did not understand what you used for working fine. Did you create an image with diskimage builder ? Did you create your own templates? Seems you are not using templates generated by Magnum. ...is it correct? Thanks Ignazio Il giorno Mer 12 Dic 2018 18:57 Octavian Ciuhandu < ociuhandu at cloudbasesolutions.com> ha scritto: > Hello, > > > > We never managed to get any version except the master work ok with Fedora > atomic. We ended up deloying magnum from master with a queens openstack > and this worked ok for us. > > We tried queens/pike/rocky and all of them seemed to have missing things > in the templates and doing a simple diff on the template files shows huge > changes. > > > > Regards, > > > > Octavian. > > > > *From:* Ignazio Cassano > *Sent:* miercuri, 12 decembrie 2018 09:50 > *To:* OpenStack Operators > *Subject:* Magnum Fedora atomic 27 > > > > Hello All, > > Deploying swarm cluster based on Fedora atomic cloud images, does not work > fine in queens. On master node cloud init reports etcd package missing. > > Does anyone find this issue? > > Regards > > Ignazio > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ociuhandu at cloudbasesolutions.com Wed Dec 12 18:34:52 2018 From: ociuhandu at cloudbasesolutions.com (Octavian Ciuhandu) Date: Wed, 12 Dec 2018 18:34:52 +0000 Subject: Magnum Fedora atomic 27 In-Reply-To: References: <97CD74D6187F9A4C8737FD2BD35403555A5387D4@CBSEX1.cloudbase.local> Message-ID: <97CD74D6187F9A4C8737FD2BD35403555A539A0B@CBSEX1.cloudbase.local> Hi Ignazio, Using the magnum master branch we took the publicly-available fedora atomic image and used that one with the standard templates from Magnum. I will be able to check with the team again in a while but from what I know it worked fine like this (while it did not work with any of the stable branches of magnum). Octavian. From: Ignazio Cassano Sent: miercuri, 12 decembrie 2018 10:32 To: Octavian Ciuhandu Cc: OpenStack Operators Subject: Re: Magnum Fedora atomic 27 Hello Octavian, I did not understand what you used for working fine. Did you create an image with diskimage builder ? Did you create your own templates? Seems you are not using templates generated by Magnum. ...is it correct? Thanks Ignazio Il giorno Mer 12 Dic 2018 18:57 Octavian Ciuhandu > ha scritto: Hello, We never managed to get any version except the master work ok with Fedora atomic. We ended up deloying magnum from master with a queens openstack and this worked ok for us. We tried queens/pike/rocky and all of them seemed to have missing things in the templates and doing a simple diff on the template files shows huge changes. Regards, Octavian. From: Ignazio Cassano > Sent: miercuri, 12 decembrie 2018 09:50 To: OpenStack Operators > Subject: Magnum Fedora atomic 27 Hello All, Deploying swarm cluster based on Fedora atomic cloud images, does not work fine in queens. On master node cloud init reports etcd package missing. Does anyone find this issue? Regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Wed Dec 12 19:11:48 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Wed, 12 Dec 2018 20:11:48 +0100 Subject: Magnum Fedora atomic 27 In-Reply-To: <97CD74D6187F9A4C8737FD2BD35403555A539A0B@CBSEX1.cloudbase.local> References: <97CD74D6187F9A4C8737FD2BD35403555A5387D4@CBSEX1.cloudbase.local> <97CD74D6187F9A4C8737FD2BD35403555A539A0B@CBSEX1.cloudbase.local> Message-ID: Many thanks, Octavian. I will check the master branch Regards Ignazio Il giorno Mer 12 Dic 2018 19:34 Octavian Ciuhandu < ociuhandu at cloudbasesolutions.com> ha scritto: > Hi Ignazio, > > > > Using the magnum master branch we took the publicly-available fedora > atomic image and used that one with the standard templates from Magnum. I > will be able to check with the team again in a while but from what I know > it worked fine like this (while it did not work with any of the stable > branches of magnum). > > > > Octavian. > > > > *From:* Ignazio Cassano > *Sent:* miercuri, 12 decembrie 2018 10:32 > *To:* Octavian Ciuhandu > *Cc:* OpenStack Operators > *Subject:* Re: Magnum Fedora atomic 27 > > > > Hello Octavian, I did not understand what you used for working fine. > > Did you create an image with diskimage builder ? > > Did you create your own templates? > > Seems you are not using templates generated by Magnum. ...is it correct? > > Thanks > > Ignazio > > > > Il giorno Mer 12 Dic 2018 18:57 Octavian Ciuhandu < > ociuhandu at cloudbasesolutions.com> ha scritto: > > Hello, > > > > We never managed to get any version except the master work ok with Fedora > atomic. We ended up deloying magnum from master with a queens openstack > and this worked ok for us. > > We tried queens/pike/rocky and all of them seemed to have missing things > in the templates and doing a simple diff on the template files shows huge > changes. > > > > Regards, > > > > Octavian. > > > > *From:* Ignazio Cassano > *Sent:* miercuri, 12 decembrie 2018 09:50 > *To:* OpenStack Operators > *Subject:* Magnum Fedora atomic 27 > > > > Hello All, > > Deploying swarm cluster based on Fedora atomic cloud images, does not work > fine in queens. On master node cloud init reports etcd package missing. > > Does anyone find this issue? > > Regards > > Ignazio > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Wed Dec 12 19:18:26 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 12 Dec 2018 13:18:26 -0600 Subject: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata" In-Reply-To: References: Message-ID: <8557b741-d4f5-cdfd-a244-65b47a1c3445@gmail.com> On 10/22/2018 11:25 AM, Sergio A. de Carvalho Jr. wrote: > While troubleshooting a production issue we identified that the Nova > metadata API is fetching a lot more raw data from the database than > seems necessary. The problem appears to be caused by the SQL query used > to fetch instance data that joins the "instance" table with, among > others, two metadata tables: "instance_metadata" and > "instance_system_metadata". Below is a simplified version of this query > (I've added the full query at the end of this message for reference): Coming back on this thread [1], I've got a partial fix up which I'm hoping will help: https://review.openstack.org/#/c/624778/ That will avoid joining on some other tables depending on your configuration. It would be great if you could see if that helps resolve your issue. I think you just reverted https://review.openstack.org/#/c/276861/ as a workaround but it would be good to know if a more permanent fix (mine) gets you similar, or at least satisfactory, results. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-October/thread.html#135941 -- Thanks, Matt From mriedemos at gmail.com Wed Dec 12 19:50:53 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 12 Dec 2018 13:50:53 -0600 Subject: Gate fracas (status) update Message-ID: I wanted to follow up from Clark's last gate status update [1]. Lots of work has been going on the last few weeks to try and get the gate under control since it's hard to merge code when you can't merge code. Most of my update is specific to nova, but some of it might be interesting to others as well for general QA/infra FYI. I'll group this into a few categories of issue. Optimize node usage / reduce blast radius ----------------------------------------- * The nova-cells-1 job has been moved to the experimental queue [2] so that we can still test that environment but do it on-demand. This helps us avoid latent cellsv1-specific race failures which might reset the gate. * I'm trying to drop the nova-multiattach job which is partially redundant with tempest-full except it only runs tempest.compute.api tests and it also runs slow tests [3]. What is blocking this is test_volume_swap_with_multiattach in the tempest-slow job intermittently failing during volume cleanup [4]. I have put a lot of debug details into that bug and have a debug logging patch up as well to see if I can recreate the failure and sort out what is going wrong. The main difference between this test in the tempest-slow job and the nova-multiattach job is simply that the tempest-slow job is multinode and nova-multiattach is single node, and the single node aspect might have been hiding some weird race bugs when it came to disconnecting the volume to cleanup if the servers are all on the same host. Help debugging that would be appreciated. Zuul queuing changes -------------------- An infra thread [5] prompted some discussion in IRC which led to changes in how tripleo changes will be queued by zuul [6][7]. The idea here is to isolate tripleo changes into their own queue so failures in tripleo changes don't disrupt (or starve) changes in openstack projects (in general) from getting queued up for test nodes. tl;dr: nova changes should enqueue more like they used to before [5]. Gate bugs --------- * http://status.openstack.org/elastic-recheck/#1807518 A fix for devstack was merged on both master and stable/rocky but we're still seeing this, so it probably needs more investigation. * http://status.openstack.org/elastic-recheck/#1783405 We need another deep dive on tempest tests which aren't marked as slow but which might be slow and contributing to overall job timeouts. * http://status.openstack.org/elastic-recheck/#1808171 This is relatively new. Debug notes are in the launchpad bug. In this test, a server is being created with 7 ports and times out waiting to get the network-vif-plugged event from neutron on the first port only, the other 6 events are received. Regarding the port that doesn't get the event, there are some weird messages in the neutron agent logs so there could be a race there but we likely need help from the neutron team to investigate. I'm not sure what might have prompted this, but maybe the recent change to use Ubuntu Bionic nodes and a new version of OVS is buggy? * http://status.openstack.org/elastic-recheck/#1800472 The fix for this [8] merged a couple of hours ago and we're seeing it drop off the e-r graph. * http://status.openstack.org/elastic-recheck/#1806912 There are a couple of separate nova bugs for this [9][10]. The fixes for both changes are approved and should reduce the amount of time it takes to start nova-api which will help avoid timeouts on slower test nodes. The fix for [10] also fixes a long-standing rolling upgrade issue so we'll be backporting that one. * http://status.openstack.org/elastic-recheck/#1798688 There is a nova fix up for this [11] and has a +2, it's very simple and just needs another nova core (efried would get it but he's out until January). * http://status.openstack.org/elastic-recheck/#1807520 This has been fixed on all grenade branches [12] and was very latent (goes back to pike) but only showed up on slower test nodes. * http://status.openstack.org/elastic-recheck/#1808010 This is a real snowball issue where the cirros filesystem fills up so config drive fails, falling back to use the metadata API to get networking information but the metadata API response is too slow and cloud-init times out. I've got a related fix [13] but we likely need someone to help profile where our other inefficiencies are in responding the metadata API requests. * http://status.openstack.org/elastic-recheck/#1808063 This one is also relatively new and I'm not sure what might be causing it. ---- There are other bugs in the e-r page but the hits are low enough, or they are latent enough, that I won't bother trying to detail them here. [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/thread.html#709 [2] https://review.openstack.org/#/c/623538/ [3] https://review.openstack.org/#/q/topic:drop-multiattach-job [4] https://bugs.launchpad.net/tempest/+bug/1807723 [5] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/thread.html#482 [6] https://review.openstack.org/#/c/623595/ - this is the zuul feature [7] https://review.openstack.org/#/c/624246/ - the tripleo-ci change [8] https://review.openstack.org/#/c/615347/ [9] https://bugs.launchpad.net/nova/+bug/1807219 [10] https://bugs.launchpad.net/nova/+bug/1807044 [11] https://review.openstack.org/#/c/623596 [12] https://review.openstack.org/#/q/I833d79ecc97ddc844bf156ab64477c7c77424f20 [13] https://review.openstack.org/#/c/624778 -- Thanks, Matt From mriedemos at gmail.com Wed Dec 12 20:00:25 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 12 Dec 2018 14:00:25 -0600 Subject: Proposal to move cinder backup tests out of the integrated gate Message-ID: I wanted to send this separate from the latest gate status update [1] since it's primarily about latent cinder bugs causing failures in the gate for which no one is really investigating. Running down our tracked gate bugs [2] there are several related to cinder-backup testing: * http://status.openstack.org/elastic-recheck/#1483434 * http://status.openstack.org/elastic-recheck/#1745168 * http://status.openstack.org/elastic-recheck/#1739482 * http://status.openstack.org/elastic-recheck/#1635643 All of those bugs were reported a long time ago. I've done some investigation into them (at least at the time of reporting) and some are simply due to cinder-api using synchronous RPC calls to cinder-volume (or cinder-backup) and that doesn't scale. This bug isn't a backup issue, but it's definitely related to using RPC call rather than cast: http://status.openstack.org/elastic-recheck/#1763712 Regarding the backup tests specifically, I don't see a reason why they need to be run in the integrated gate jobs, e.g. tempest-full(-py3). They don't involve other services, so in my opinion we should move the backup tests to a separate job which only runs on cinder changes to alleviate these latent bugs failing jobs for unrelated changes and resetting the entire gate. I would need someone from the cinder team that is more involved in knowing what their job setup looks like to identify a candidate job for these tests if this is something everyone can agree on doing. [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000867.html [2] http://status.openstack.org/elastic-recheck/ -- Thanks, Matt From skaplons at redhat.com Wed Dec 12 20:28:21 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Wed, 12 Dec 2018 21:28:21 +0100 Subject: Proposal to move cinder backup tests out of the integrated gate In-Reply-To: References: Message-ID: Hi, +1 from me. We also see it quite often failing in some neutron jobs. — Slawek Kaplonski Senior software engineer Red Hat > Wiadomość napisana przez Matt Riedemann w dniu 12.12.2018, o godz. 21:00: > > I wanted to send this separate from the latest gate status update [1] since it's primarily about latent cinder bugs causing failures in the gate for which no one is really investigating. > > Running down our tracked gate bugs [2] there are several related to cinder-backup testing: > > * http://status.openstack.org/elastic-recheck/#1483434 > * http://status.openstack.org/elastic-recheck/#1745168 > * http://status.openstack.org/elastic-recheck/#1739482 > * http://status.openstack.org/elastic-recheck/#1635643 > > All of those bugs were reported a long time ago. I've done some investigation into them (at least at the time of reporting) and some are simply due to cinder-api using synchronous RPC calls to cinder-volume (or cinder-backup) and that doesn't scale. This bug isn't a backup issue, but it's definitely related to using RPC call rather than cast: > > http://status.openstack.org/elastic-recheck/#1763712 > > Regarding the backup tests specifically, I don't see a reason why they need to be run in the integrated gate jobs, e.g. tempest-full(-py3). They don't involve other services, so in my opinion we should move the backup tests to a separate job which only runs on cinder changes to alleviate these latent bugs failing jobs for unrelated changes and resetting the entire gate. > > I would need someone from the cinder team that is more involved in knowing what their job setup looks like to identify a candidate job for these tests if this is something everyone can agree on doing. > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000867.html > [2] http://status.openstack.org/elastic-recheck/ > > -- > > Thanks, > > Matt > From feilong at catalyst.net.nz Wed Dec 12 20:45:20 2018 From: feilong at catalyst.net.nz (Feilong Wang) Date: Thu, 13 Dec 2018 09:45:20 +1300 Subject: Magnum Fedora atomic 27 In-Reply-To: References: Message-ID: <8ade9716-d3c0-03d9-2688-749fb41272ef@catalyst.net.nz> Hi Ignazio, Stable/Queens should be fine though we recommend stable/rocky. And it would be easy to help if you can paste your error. Cheers. On 13/12/18 6:49 AM, Ignazio Cassano wrote: > Hello All, > Deploying swarm cluster based on Fedora atomic cloud images, does not > work fine in queens. On master node  cloud init reports etcd package > missing. > Does anyone find this issue? > Regards  > Ignazio > -- 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 -------------------------------------------------------------------------- From feilong at catalyst.net.nz Wed Dec 12 20:53:13 2018 From: feilong at catalyst.net.nz (Feilong Wang) Date: Thu, 13 Dec 2018 09:53:13 +1300 Subject: [openstack-dev] [magnum] [Rocky] K8 deployment on fedora-atomic is failed In-Reply-To: References: Message-ID: Hi Vikrant, Sorry for the late response. Could you please share the log of /var/log/cloud-init-output.log on your master node? Cheers. On 9/12/18 12:51 AM, Vikrant Aggarwal wrote: > Hello Team, > > Any help on this issue? > > Thanks & Regards, > Vikrant Aggarwal > > > On Tue, Dec 4, 2018 at 6:49 PM Vikrant Aggarwal > wrote: > > Hello Team, > > Any help on this issue? > > Thanks & Regards, > Vikrant Aggarwal > > > On Fri, Nov 30, 2018 at 9:13 AM Vikrant Aggarwal > > wrote: > > 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: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 > -------------------------------------------------------------------------- > > __________________________________________________________________________ > 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: From dradez at redhat.com Wed Dec 12 21:44:50 2018 From: dradez at redhat.com (Dan Radez) Date: Wed, 12 Dec 2018 16:44:50 -0500 Subject: Backporting networking-ansible to Queens Message-ID: <243084cd-4a9c-e9b3-af5f-07d5fd4f4b35@redhat.com> We have requested to add ansible-runner and update the version of python-pexpect from 4.3 to 4.5 in the openstack-requirements repository. https://review.openstack.org/#/c/624048 This is in effort to enable the networking-ansible ML2 driver in Queens. It was developed as part of the Rocky development cycle. We understood that this is outside the structure of standard practice and would like to request an exception for this change in light of it's low risk. We have customers that are asking for this ML2 driver to be enabled in our product that is based on Queens. We would like to push these changes to upstream first. This exposes the community to this code and prevents the need to carry patches downstream. This ML2 driver is an add on feature that should carry little to no technical debt for the stable/Queens code base. Python-pexpect need to be updated and we will update Triple-o to enable it to install and configure the new driver. Otherwise the backport consists of adding the ansible-runner dependency and packaging the code for the networking-ansible ML2 driver. End users are impacted only when they choose to install the feature and enable it. Thank you for your consideration, Dan Radez From zbitter at redhat.com Wed Dec 12 22:48:49 2018 From: zbitter at redhat.com (Zane Bitter) Date: Thu, 13 Dec 2018 11:48:49 +1300 Subject: [all][security-sig][meta-sig] Forum summary: Expose SIGs and WGs In-Reply-To: <20181212144606.wswpl7xgnlqu2nzs@yuggoth.org> References: <20181212132044.ibvr6dd54zrbqkj3@pacific.linksys.moosehall> <1b668052-b1f3-a404-2811-0acc8d76fb5c@secustack.com> <20181212144606.wswpl7xgnlqu2nzs@yuggoth.org> Message-ID: On 13/12/18 3:46 AM, Jeremy Stanley wrote: > On 2018-12-12 14:57:31 +0100 (+0100), Josephine Seifert wrote: > [...] >> Actually we already talked to the Security SIG, which are >> basically the same people as in Barbican, at the Summit. > [...] > > I really appreciate the way you've engaged with other regulars in > the Security SIG. It's a bit of a mischaracterization to suggest > that they're mostly Barbican folks though. We do see redrobot > (Douglas Mendizábal) semi-frequently in our IRC meetings, but most > of our regulars at those meetings are vulnerability managers, core > reviewers for Keystone, authors on the OpenStack Security Guide, > maintainers of the Bandit static analyzer... We've shared a room > with the Barbican team at some recent OpenStack Project Team > Gatherings to help conserve available space at the conference venues > since we definitely have some overlapping interests, so that could > be part of the confusion. Apologies, I was the source of this misinformation. Thanks for the correction. - ZB From feilong at catalyst.net.nz Wed Dec 12 22:55:41 2018 From: feilong at catalyst.net.nz (Feilong Wang) Date: Thu, 13 Dec 2018 11:55:41 +1300 Subject: Fwd: openstack queens magnum error In-Reply-To: References: Message-ID: <50328a78-8f24-e93d-78b5-24e02de8a89c@catalyst.net.nz> Seems your master node can't talk to your keystone, can you confirm that? On 13/12/18 11:08 AM, Ignazio Cassano wrote: > Hello Feilong, this forwarding contains logs. > Thanks > > ---------- Forwarded message --------- > From: *Ignazio Cassano* > > Date: Mer 12 Dic 2018 10:06 > Subject: openstack queens magnum error > To: OpenStack Operators > > > > Hello Everyone, > > I installed queens on centos with magnum and I am trying to create a > swarm cluster with one muster and one node. The image I used is > fedora-atomic 27 update 04 > > The stack generated end with an error and magnum conductor reports: > ec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.304 > 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not > have output_key api_address > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 > 09:51:17.305 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not > have output_key swarm_masters > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 > 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not > have output_key swarm_nodes > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 > 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not > have output_key discovery_url > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 > 09:51:17.317 17964 ERROR magnum.drivers.heat.driver > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] Cluster error, > stack status: CREATE_FAILED, stack_id: > 306bd83a-7878-4d94-8ed0-1d297eec9768, reason: Resource CREATE failed: > WaitConditionFailure: > resources.swarm_nodes.resources[0].resources.node_wait_condition: > swarm-agent service failed to start. > > > > I connected to the master node for verifyng if swarm agent is running. > In the cloud init log I found: > requests.exceptions.ConnectionError: > HTTPConnectionPool(host='10.102.184.190', port=5000): Max retries > exceeded with url: /v3//auth/tokens (Caused by > NewConnectionError(' 0x7f0814d4d250>: Failed to establish a new connection: [Errno 110] > Connection timed out',)) > Cloud-init v. 0.7.9 running 'modules:final' at Wed, 12 Dec 2018 > 08:45:31 +0000. Up 55.54 seconds. > 2018-12-12 08:47:45,858 - util.py[WARNING]: Failed running > /var/lib/cloud/instance/scripts/part-005 [1] > /var/lib/cloud/instance/scripts/part-006: line 13: > /etc/etcd/etcd.conf: No such file or directory > /var/lib/cloud/instance/scripts/part-006: line 26: > /etc/etcd/etcd.conf: No such file or directory > /var/lib/cloud/instance/scripts/part-006: line 38: > /etc/etcd/etcd.conf: No such file or directory > 2018-12-12 08:47:45,870 - util.py[WARNING]: Failed running > /var/lib/cloud/instance/scripts/part-006 [1] > Configuring docker network ... > Configuring docker network service ... > Removed > /etc/systemd/system/multi-user.target.wants/docker-storage-setup.service. >   New size given (1280 extents) not larger than existing size (4863 > extents) > ERROR: There is not enough free space in volume group atomicos to > create data volume of size MIN_DATA_SIZE=2G. > 2018-12-12 08:47:46,206 - util.py[WARNING]: Failed running > /var/lib/cloud/instance/scripts/part-010 [1] > + systemctl stop docker > + echo 'starting services' > starting services > + systemctl daemon-reload > + for service in etcd docker.socket docker swarm-manager > + echo 'activating service etcd' > activating service etcd > + systemctl enable etcd > Failed to enable unit: Unit file etcd.service does not exist. > + systemctl --no-block start etcd > Failed to start etcd.service: Unit etcd.service not found. > + for service in etcd docker.socket docker swarm-manager > + echo 'activating service docker.socket' > activating service docker.socket > + systemctl enable docker.socket > > > 1) Seems etcd service is not installed , > > 2) the instance required to contact controller on port 5000 (is it > correct ?) > > > Please help me. > > Regards > Ignazio > > -- 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: From rosmaita.fossdev at gmail.com Thu Dec 13 02:21:11 2018 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Wed, 12 Dec 2018 21:21:11 -0500 Subject: [cinder][ops][docs] policy configuration howto Message-ID: At last week's cinder meeting (5 December) we had a discussion about policy checks at the database layer. While these checks seem to make it difficult to perform some policy configurations, there are too many of them to simply remove them without impacting stability given our current test coverage (at least that's my feeling). Additionally, it's possible to handle the proposed use case (a read-only administrator) without making any code changes. So we decided to fix this issue by documenting how this could work. I've got a patch up for the documentation. I've flagged this email for cinder people to read for accuracy, operators to read to make sure the instructions are clear and detailed, and docs people to read for felicity of expression. Please leave comments on the patch: https://review.openstack.org/#/c/624424/ cheers, brian From ignaziocassano at gmail.com Thu Dec 13 05:29:34 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Thu, 13 Dec 2018 06:29:34 +0100 Subject: Fwd: openstack queens magnum error In-Reply-To: <50328a78-8f24-e93d-78b5-24e02de8a89c@catalyst.net.nz> References: <50328a78-8f24-e93d-78b5-24e02de8a89c@catalyst.net.nz> Message-ID: Yes, I cofirm. I solved this configuration problem and Now it can . But the etcd error remains. Fedora atomic cloud images miss etcd package. Regards Ignazio Il giorno Mer 12 Dic 2018 23:55 Feilong Wang ha scritto: > Seems your master node can't talk to your keystone, can you confirm that? > > > > On 13/12/18 11:08 AM, Ignazio Cassano wrote: > > Hello Feilong, this forwarding contains logs. > Thanks > > ---------- Forwarded message --------- > From: Ignazio Cassano > Date: Mer 12 Dic 2018 10:06 > Subject: openstack queens magnum error > To: OpenStack Operators > > > Hello Everyone, > > I installed queens on centos with magnum and I am trying to create a swarm > cluster with one muster and one node. The image I used is fedora-atomic 27 > update 04 > > The stack generated end with an error and magnum conductor reports: > ec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.304 > 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have > output_key api_address > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.305 > 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have > output_key swarm_masters > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 > 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have > output_key swarm_nodes > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 > 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have > output_key discovery_url > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.317 > 17964 ERROR magnum.drivers.heat.driver > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] Cluster error, stack > status: CREATE_FAILED, stack_id: 306bd83a-7878-4d94-8ed0-1d297eec9768, > reason: Resource CREATE failed: WaitConditionFailure: > resources.swarm_nodes.resources[0].resources.node_wait_condition: > swarm-agent service failed to start. > > > > I connected to the master node for verifyng if swarm agent is running. > In the cloud init log I found: > requests.exceptions.ConnectionError: > HTTPConnectionPool(host='10.102.184.190', port=5000): Max retries exceeded > with url: /v3//auth/tokens (Caused by > NewConnectionError(' 0x7f0814d4d250>: Failed to establish a new connection: [Errno 110] > Connection timed out',)) > Cloud-init v. 0.7.9 running 'modules:final' at Wed, 12 Dec 2018 08:45:31 > +0000. Up 55.54 seconds. > 2018-12-12 08:47:45,858 - util.py[WARNING]: Failed running > /var/lib/cloud/instance/scripts/part-005 [1] > /var/lib/cloud/instance/scripts/part-006: line 13: /etc/etcd/etcd.conf: No > such file or directory > /var/lib/cloud/instance/scripts/part-006: line 26: /etc/etcd/etcd.conf: No > such file or directory > /var/lib/cloud/instance/scripts/part-006: line 38: /etc/etcd/etcd.conf: No > such file or directory > 2018-12-12 08:47:45,870 - util.py[WARNING]: Failed running > /var/lib/cloud/instance/scripts/part-006 [1] > Configuring docker network ... > Configuring docker network service ... > Removed > /etc/systemd/system/multi-user.target.wants/docker-storage-setup.service. > New size given (1280 extents) not larger than existing size (4863 > extents) > ERROR: There is not enough free space in volume group atomicos to create > data volume of size MIN_DATA_SIZE=2G. > 2018-12-12 08:47:46,206 - util.py[WARNING]: Failed running > /var/lib/cloud/instance/scripts/part-010 [1] > + systemctl stop docker > + echo 'starting services' > starting services > + systemctl daemon-reload > + for service in etcd docker.socket docker swarm-manager > + echo 'activating service etcd' > activating service etcd > + systemctl enable etcd > Failed to enable unit: Unit file etcd.service does not exist. > + systemctl --no-block start etcd > Failed to start etcd.service: Unit etcd.service not found. > + for service in etcd docker.socket docker swarm-manager > + echo 'activating service docker.socket' > activating service docker.socket > + systemctl enable docker.socket > > > 1) Seems etcd service is not installed , > > 2) the instance required to contact controller on port 5000 (is it correct > ?) > > > Please help me. > > Regards > Ignazio > > > -- > 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: From ignaziocassano at gmail.com Thu Dec 13 05:37:26 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Thu, 13 Dec 2018 06:37:26 +0100 Subject: Fwd: openstack queens magnum error In-Reply-To: <50328a78-8f24-e93d-78b5-24e02de8a89c@catalyst.net.nz> References: <50328a78-8f24-e93d-78b5-24e02de8a89c@catalyst.net.nz> Message-ID: Ps. Solving connection problem between master node and controller node allows stack to complete successfully. But remains the problem with the etcd package. Regards Ignazio Il giorno Mer 12 Dic 2018 23:55 Feilong Wang ha scritto: > Seems your master node can't talk to your keystone, can you confirm that? > > > > On 13/12/18 11:08 AM, Ignazio Cassano wrote: > > Hello Feilong, this forwarding contains logs. > Thanks > > ---------- Forwarded message --------- > From: Ignazio Cassano > Date: Mer 12 Dic 2018 10:06 > Subject: openstack queens magnum error > To: OpenStack Operators > > > Hello Everyone, > > I installed queens on centos with magnum and I am trying to create a swarm > cluster with one muster and one node. The image I used is fedora-atomic 27 > update 04 > > The stack generated end with an error and magnum conductor reports: > ec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.304 > 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have > output_key api_address > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.305 > 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have > output_key swarm_masters > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 > 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have > output_key swarm_nodes > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 > 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have > output_key discovery_url > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.317 > 17964 ERROR magnum.drivers.heat.driver > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] Cluster error, stack > status: CREATE_FAILED, stack_id: 306bd83a-7878-4d94-8ed0-1d297eec9768, > reason: Resource CREATE failed: WaitConditionFailure: > resources.swarm_nodes.resources[0].resources.node_wait_condition: > swarm-agent service failed to start. > > > > I connected to the master node for verifyng if swarm agent is running. > In the cloud init log I found: > requests.exceptions.ConnectionError: > HTTPConnectionPool(host='10.102.184.190', port=5000): Max retries exceeded > with url: /v3//auth/tokens (Caused by > NewConnectionError(' 0x7f0814d4d250>: Failed to establish a new connection: [Errno 110] > Connection timed out',)) > Cloud-init v. 0.7.9 running 'modules:final' at Wed, 12 Dec 2018 08:45:31 > +0000. Up 55.54 seconds. > 2018-12-12 08:47:45,858 - util.py[WARNING]: Failed running > /var/lib/cloud/instance/scripts/part-005 [1] > /var/lib/cloud/instance/scripts/part-006: line 13: /etc/etcd/etcd.conf: No > such file or directory > /var/lib/cloud/instance/scripts/part-006: line 26: /etc/etcd/etcd.conf: No > such file or directory > /var/lib/cloud/instance/scripts/part-006: line 38: /etc/etcd/etcd.conf: No > such file or directory > 2018-12-12 08:47:45,870 - util.py[WARNING]: Failed running > /var/lib/cloud/instance/scripts/part-006 [1] > Configuring docker network ... > Configuring docker network service ... > Removed > /etc/systemd/system/multi-user.target.wants/docker-storage-setup.service. > New size given (1280 extents) not larger than existing size (4863 > extents) > ERROR: There is not enough free space in volume group atomicos to create > data volume of size MIN_DATA_SIZE=2G. > 2018-12-12 08:47:46,206 - util.py[WARNING]: Failed running > /var/lib/cloud/instance/scripts/part-010 [1] > + systemctl stop docker > + echo 'starting services' > starting services > + systemctl daemon-reload > + for service in etcd docker.socket docker swarm-manager > + echo 'activating service etcd' > activating service etcd > + systemctl enable etcd > Failed to enable unit: Unit file etcd.service does not exist. > + systemctl --no-block start etcd > Failed to start etcd.service: Unit etcd.service not found. > + for service in etcd docker.socket docker swarm-manager > + echo 'activating service docker.socket' > activating service docker.socket > + systemctl enable docker.socket > > > 1) Seems etcd service is not installed , > > 2) the instance required to contact controller on port 5000 (is it correct > ?) > > > Please help me. > > Regards > Ignazio > > > -- > 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: From lujinluo at gmail.com Thu Dec 13 06:18:23 2018 From: lujinluo at gmail.com (Lujin Luo) Date: Wed, 12 Dec 2018 22:18:23 -0800 Subject: [Neutron] [Upgrade] No meeting on Dec. 13th Message-ID: Hi everyone, Due to some personal reasons, I cannot hold the Neutron Upgrade subteam meeting on Dec. 13th. Let's skip it, and resume on Dec. 20th! Thank you for your understanding. Best regards, Lujin From manuel.sb at garvan.org.au Thu Dec 13 06:18:48 2018 From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros) Date: Thu, 13 Dec 2018 06:18:48 +0000 Subject: can't login to a compute node deployed using ironic Message-ID: <9D8A2486E35F0941A60430473E29F15B017BAF8E9F@MXDB2.ad.garvan.unsw.edu.au> Dear Openstack user group, I am playing with Ironic and have a very stupid question... For some reason I can't login to the server after deployment. Server status is ACTIVE and I am using the adminPass provided by openstack . The way I connect is through server console through the IPMI console (not ssh). [root at openstack-deployment ~]# openstack server create --image 760f4076-4f2d-455b-89b5-6c1248148f70 --flavor my-baremetal-flavor --network hpc demo1 +-------------------------------------+------------------------------------------------------------+ | Field | Value | +-------------------------------------+------------------------------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | | | OS-EXT-SRV-ATTR:host | None | | OS-EXT-SRV-ATTR:hypervisor_hostname | None | | OS-EXT-SRV-ATTR:instance_name | | | OS-EXT-STS:power_state | NOSTATE | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | None | | OS-SRV-USG:terminated_at | None | | accessIPv4 | | | accessIPv6 | | | addresses | | | adminPass | t3TAUNwTbuD5 | | config_drive | | | created | 2018-12-13T05:39:11Z | | flavor | my-baremetal-flavor (84abc368-1695-4387-998c-8b47da1a3a34) | | hostId | | | id | 5231e015-73e9-472f-bb84-bde9bf7e6989 | | image | centos7.5-image (760f4076-4f2d-455b-89b5-6c1248148f70) | | key_name | None | | name | demo1 | | progress | 0 | | project_id | 0b3d8fd6015048e89f4372fb1534900b | | properties | | | security_groups | name='default' | | status | BUILD | | updated | 2018-12-13T05:39:12Z | | user_id | fd244f331bc34066b7a5fae72d518261 | | volumes_attached | | +-------------------------------------+------------------------------------------------------------+ [root at openstack-deployment ~]# openstack server list +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ | 5231e015-73e9-472f-bb84-bde9bf7e6989 | demo1 | ACTIVE | hpc=10.0.32.119 | centos7.5-image | my-baremetal-flavor | | 9cc2369f-1951-4bec-bc8b-863fd6cc9983 | test | ACTIVE | hpc=10.0.32.116 | cirros | m1.tiny | +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ Any thoughts? 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: From ifatafekn at gmail.com Thu Dec 13 08:43:17 2018 From: ifatafekn at gmail.com (Ifat Afek) Date: Thu, 13 Dec 2018 10:43:17 +0200 Subject: [vitrage][monasca] Monasca datasource for Vitrage In-Reply-To: References: Message-ID: Hi Witek, On Wed, Dec 12, 2018 at 5:04 PM Bedyk, Witold wrote: > > > > There is one issue that we need to close though – how to connect the > Monasca alarms to the resources in Vitrage. > > > > > > In order to connect an alarm to a resource, Vitrage should be able to > identify that resource in its entity graph using the dimensions coming from > Monasca. I > understood that these dimensions are configurable and not > pre-defined. > > > > Correct. To make the picture complete: every alarm contains an associated > `metric name` and a set of dimensions which identify the monitored > resource. Both metric name and dimensions could potentially be used in > Vitrage. > > > > 1. For OpenStack services we typically use dimension keys `hostname` and > `service`. Examples would be: > > `name`: `http_status`, `dimensions`: {`hostname`: `node1`, > `service`: `keystone`, `url`: `http://node1/identity` > } > > > > Libvirt metrics all have the dimension keys `hostname`, > `service`=`compute`, `resource_id`=instance_id > By instance_id do you mean the libvirt id or the OpenStack UUID? In order to correlate the id with the vm that exists in Vitrage, we need the Nova UUID. Another question: are these dimensions names always the same? Is it possible to change their names? > 2. For other resources I’m not sure if we can define a general rule for > assignments. As you have said, the unique information may be included in > more the one dimension. > > > > For Prometheus, we use labels on each metric as dimensions. Additional > dimensions can be configured in agent per Prometheus endpoint. > > > > How do you assign resources for alarms from Zabbix or Prometheus > datasources? > We cannot define it hard-coded, but we are looking for a way that the end user can easily configure it. We are currently facing similar questions with Prometheus and Zabbix. In all cases, we have the basic integration working, but do not always know how to map the resources. Some examples: · Given a dimension/label with a resource name or a non-unique id, how can we tell the resource type? · For a NIC, we should get the hostname and nic name, and somehow figure the nic id in Vitrage. Or, we should configure Monasca to have a nic_id dimension in the same format that Vitrage uses. We are trying to find a configuration / heuristic method / hook mechanism that will allow us to define some basic conversions and let the user select the appropriate ones. Can you give us some more examples of Monasca dimensions? Another issue is that we need to decide where to handle the conversion – in Monasca or in Vitrage. Is it possible to define a hook or plugin in inside Monasca, that will perform some conversions on the alarm before sending it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.urdin at binero.se Thu Dec 13 08:51:56 2018 From: tobias.urdin at binero.se (Tobias Urdin) Date: Thu, 13 Dec 2018 09:51:56 +0100 Subject: Fwd: openstack queens magnum error In-Reply-To: References: <50328a78-8f24-e93d-78b5-24e02de8a89c@catalyst.net.nz> Message-ID: <3d030a47-766d-d32b-2fb3-3bc6e0beb10e@binero.se> Hello, What swam driver are you using? We use the following image Fedora-Atomic-27-20180419.0.x86_64.qcow2 and to get Kubernetes and Swarm-mode drivers working we use latest stable/rocky release which should include the patches that fixes some issues. Make sure you got correct COE set on the swarm cluster template. $openstack coe cluster template show docker-swarm | docker_storage_driver | devicemapper                         | | network_driver        | docker | coe                   | swarm-mode                           | These fixes should be released in latest stable/rocky: https://review.openstack.org/#/c/598179/ https://review.openstack.org/#/c/607089/ https://review.openstack.org/#/c/611097 Never got the "swarm" driver to work, you should use "swarm-mode" instead which uses native Docker clustering without etcd. For kubernetes there was no issues when using Fedora Atomic 27 but atomic 28 has a lot of changes so it cannot install etcd as a system service so can't use 28 until that is fixed, maybe fixed in master though. Best regards On 12/13/2018 06:39 AM, Ignazio Cassano wrote: > Ps. > Solving connection problem between master node and controller node > allows stack to complete successfully. But remains the problem with > the etcd package. > Regards > Ignazio > > > Il giorno Mer 12 Dic 2018 23:55 Feilong Wang > ha scritto: > > Seems your master node can't talk to your keystone, can you > confirm that? > > > > On 13/12/18 11:08 AM, Ignazio Cassano wrote: >> Hello Feilong, this forwarding contains logs. >> Thanks >> >> ---------- Forwarded message --------- >> From: *Ignazio Cassano* > > >> Date: Mer 12 Dic 2018 10:06 >> Subject: openstack queens magnum error >> To: OpenStack Operators > > >> >> >> Hello Everyone, >> >> I installed queens on centos with magnum and I am trying to >> create a swarm cluster with one muster and one node. The image I >> used is fedora-atomic 27 update 04 >> >> The stack generated end with an error and magnum conductor reports: >> ec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 >> 09:51:17.304 17964 WARNING magnum.drivers.heat.template_def >> [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does >> not have output_key api_address >> Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 >> 09:51:17.305 17964 WARNING magnum.drivers.heat.template_def >> [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does >> not have output_key swarm_masters >> Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 >> 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def >> [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does >> not have output_key swarm_nodes >> Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 >> 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def >> [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does >> not have output_key discovery_url >> Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 >> 09:51:17.317 17964 ERROR magnum.drivers.heat.driver >> [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] Cluster >> error, stack status: CREATE_FAILED, stack_id: >> 306bd83a-7878-4d94-8ed0-1d297eec9768, reason: Resource CREATE >> failed: WaitConditionFailure: >> resources.swarm_nodes.resources[0].resources.node_wait_condition: >> swarm-agent service failed to start. >> >> >> >> I connected to the master node for verifyng if swarm agent is >> running. >> In the cloud init log I found: >> requests.exceptions.ConnectionError: >> HTTPConnectionPool(host='10.102.184.190', port=5000): Max retries >> exceeded with url: /v3//auth/tokens (Caused by >> NewConnectionError('> 0x7f0814d4d250>: Failed to establish a new connection: [Errno >> 110] Connection timed out',)) >> Cloud-init v. 0.7.9 running 'modules:final' at Wed, 12 Dec 2018 >> 08:45:31 +0000. Up 55.54 seconds. >> 2018-12-12 08:47:45,858 - util.py[WARNING]: Failed running >> /var/lib/cloud/instance/scripts/part-005 [1] >> /var/lib/cloud/instance/scripts/part-006: line 13: >> /etc/etcd/etcd.conf: No such file or directory >> /var/lib/cloud/instance/scripts/part-006: line 26: >> /etc/etcd/etcd.conf: No such file or directory >> /var/lib/cloud/instance/scripts/part-006: line 38: >> /etc/etcd/etcd.conf: No such file or directory >> 2018-12-12 08:47:45,870 - util.py[WARNING]: Failed running >> /var/lib/cloud/instance/scripts/part-006 [1] >> Configuring docker network ... >> Configuring docker network service ... >> Removed >> /etc/systemd/system/multi-user.target.wants/docker-storage-setup.service. >>   New size given (1280 extents) not larger than existing size >> (4863 extents) >> ERROR: There is not enough free space in volume group atomicos to >> create data volume of size MIN_DATA_SIZE=2G. >> 2018-12-12 08:47:46,206 - util.py[WARNING]: Failed running >> /var/lib/cloud/instance/scripts/part-010 [1] >> + systemctl stop docker >> + echo 'starting services' >> starting services >> + systemctl daemon-reload >> + for service in etcd docker.socket docker swarm-manager >> + echo 'activating service etcd' >> activating service etcd >> + systemctl enable etcd >> Failed to enable unit: Unit file etcd.service does not exist. >> + systemctl --no-block start etcd >> Failed to start etcd.service: Unit etcd.service not found. >> + for service in etcd docker.socket docker swarm-manager >> + echo 'activating service docker.socket' >> activating service docker.socket >> + systemctl enable docker.socket >> >> >> 1) Seems etcd service is not installed , >> >> 2) the instance required to contact controller on port 5000 (is >> it correct ?) >> >> >> Please help me. >> >> Regards >> Ignazio >> >> > -- > 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: From skaplons at redhat.com Thu Dec 13 08:58:29 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Thu, 13 Dec 2018 09:58:29 +0100 Subject: [neutron] gate issue In-Reply-To: References: Message-ID: Hi all, So patch [1] is merged and neutron-tempest-iptabes_hybrid job is now non-voting. If Your patch to Neutron failed on this job, You can rebase Your patch now and it should be better. [1] https://review.openstack.org/624489 — Slawek Kaplonski Senior software engineer Red Hat > Wiadomość napisana przez Slawomir Kaplonski w dniu 12.12.2018, o godz. 08:54: > > Hi all, > > Recently we have issue with neutron-tempest-iptables_hybrid job which is failing 100% times. It is related to [1] and there is no need to recheck Your patches if CI failed on this job. > To unblock our gate we proposed patch to make this job non-voting for some time [2]. When it will be merged, please rebase Your patches and it should be good then. > > [1] https://bugs.launchpad.net/os-vif/+bug/1807949 > [2] https://review.openstack.org/#/c/624489/ > > — > Slawek Kaplonski > Senior software engineer > Red Hat > From gmann at ghanshyammann.com Thu Dec 13 08:58:55 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 13 Dec 2018 17:58:55 +0900 Subject: Proposal to move cinder backup tests out of the integrated gate In-Reply-To: References: Message-ID: <167a6ca5011.e6b7f9f746531.2755945168591922421@ghanshyammann.com> ---- On Thu, 13 Dec 2018 05:00:25 +0900 Matt Riedemann wrote ---- > I wanted to send this separate from the latest gate status update [1] > since it's primarily about latent cinder bugs causing failures in the > gate for which no one is really investigating. > > Running down our tracked gate bugs [2] there are several related to > cinder-backup testing: > > * http://status.openstack.org/elastic-recheck/#1483434 > * http://status.openstack.org/elastic-recheck/#1745168 > * http://status.openstack.org/elastic-recheck/#1739482 > * http://status.openstack.org/elastic-recheck/#1635643 I agree that those are long pending bugs but seems not occurring so frequently. First, two are ~20 times in the last 10 days and last two even less. > > All of those bugs were reported a long time ago. I've done some > investigation into them (at least at the time of reporting) and some are > simply due to cinder-api using synchronous RPC calls to cinder-volume > (or cinder-backup) and that doesn't scale. This bug isn't a backup > issue, but it's definitely related to using RPC call rather than cast: > > http://status.openstack.org/elastic-recheck/#1763712 > > Regarding the backup tests specifically, I don't see a reason why they > need to be run in the integrated gate jobs, e.g. tempest-full(-py3). > They don't involve other services, so in my opinion we should move the > backup tests to a separate job which only runs on cinder changes to > alleviate these latent bugs failing jobs for unrelated changes and > resetting the entire gate. > > I would need someone from the cinder team that is more involved in > knowing what their job setup looks like to identify a candidate job for > these tests if this is something everyone can agree on doing. Also, I would like to know that is cinder backup standard feature (including snapshot back etc)? There is no harm to test those in the integrated job. But I agree that if those tests/features are not stable then, we can skip or remove them from integrated gate testing and let cinder to test them on their gate in the specific job till they are stable. As you mentioned, let's wait for Cinder team to respond on these. -gmann > > [1] > http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000867.html > [2] http://status.openstack.org/elastic-recheck/ > > -- > > Thanks, > > Matt > > From ignaziocassano at gmail.com Thu Dec 13 09:43:43 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Thu, 13 Dec 2018 10:43:43 +0100 Subject: Fwd: openstack queens magnum error In-Reply-To: <3d030a47-766d-d32b-2fb3-3bc6e0beb10e@binero.se> References: <50328a78-8f24-e93d-78b5-24e02de8a89c@catalyst.net.nz> <3d030a47-766d-d32b-2fb3-3bc6e0beb10e@binero.se> Message-ID: I create the cluster template with the following command : openstack coe cluster template create swarm-clustergp27 \ --image fedora-magnum-27-4 \ --external-network 566 \ --dns-nameserver 10.102.184.2 \ --master-flavor m1.small \ --flavor m1.small \ --coe swarm \ --http-proxy http://10.102.162.12:3128 \ --https-proxy http://10.102.162.12:3128 \ --docker-volume-size 20 It creates the stack and completes it but loggin in the master node it reports in cloudinit logs that etcd package is missing. What about swarm-mode ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Thu Dec 13 09:47:23 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Thu, 13 Dec 2018 10:47:23 +0100 Subject: Magnum Fedora atomic 27 In-Reply-To: <97CD74D6187F9A4C8737FD2BD35403555A539A0B@CBSEX1.cloudbase.local> References: <97CD74D6187F9A4C8737FD2BD35403555A5387D4@CBSEX1.cloudbase.local> <97CD74D6187F9A4C8737FD2BD35403555A539A0B@CBSEX1.cloudbase.local> Message-ID: Hi Octavian, I cloned the magnum master. I saw there is a playbook for creating fedora atomic with diskimage builder but some files do not exist: MAGNUM_ELEMENTS=./openstack/magnum/magnum/drivers/common/image export ELEMENTS_PATH=$DIB_ELEMENTS:$MAGNUM_ELEMENTS $MAGNUM_ELEMENTS/fedora-atomic/install_imagebuild_deps.sh install_imagebuild_deps.sh does not exist in the master branch Regards Ignazio Il giorno mer 12 dic 2018 alle ore 19:34 Octavian Ciuhandu < ociuhandu at cloudbasesolutions.com> ha scritto: > Hi Ignazio, > > > > Using the magnum master branch we took the publicly-available fedora > atomic image and used that one with the standard templates from Magnum. I > will be able to check with the team again in a while but from what I know > it worked fine like this (while it did not work with any of the stable > branches of magnum). > > > > Octavian. > > > > *From:* Ignazio Cassano > *Sent:* miercuri, 12 decembrie 2018 10:32 > *To:* Octavian Ciuhandu > *Cc:* OpenStack Operators > *Subject:* Re: Magnum Fedora atomic 27 > > > > Hello Octavian, I did not understand what you used for working fine. > > Did you create an image with diskimage builder ? > > Did you create your own templates? > > Seems you are not using templates generated by Magnum. ...is it correct? > > Thanks > > Ignazio > > > > Il giorno Mer 12 Dic 2018 18:57 Octavian Ciuhandu < > ociuhandu at cloudbasesolutions.com> ha scritto: > > Hello, > > > > We never managed to get any version except the master work ok with Fedora > atomic. We ended up deloying magnum from master with a queens openstack > and this worked ok for us. > > We tried queens/pike/rocky and all of them seemed to have missing things > in the templates and doing a simple diff on the template files shows huge > changes. > > > > Regards, > > > > Octavian. > > > > *From:* Ignazio Cassano > *Sent:* miercuri, 12 decembrie 2018 09:50 > *To:* OpenStack Operators > *Subject:* Magnum Fedora atomic 27 > > > > Hello All, > > Deploying swarm cluster based on Fedora atomic cloud images, does not work > fine in queens. On master node cloud init reports etcd package missing. > > Does anyone find this issue? > > Regards > > Ignazio > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpb at dyncloud.net Thu Dec 13 12:27:31 2018 From: tpb at dyncloud.net (Tom Barron) Date: Thu, 13 Dec 2018 07:27:31 -0500 Subject: [manila] no meeting 13 December 2018 Message-ID: <20181213122731.6rlcwol5ckuudakb@barron.net> Since we have some cores at kubecon and will likely not have a quorum, I'm canceling this week's community manila meeting. Next meeting will be on 20 December at 1500 UTC. You can add agenda items here: https://wiki.openstack.org/w/index.php?title=Manila/Meetings&action=edit§ion=2 As a reminder, milestone 2 for Stein is coming up the week of 7 January. Cores need to help with the access rule priority review [1] as this is work continued from Rocky and we need to move it along. See you on #openstack-manila on freenode in the mean time! -- Tom Barron irc: tbarron [1] https://review.openstack.org/#/c/572283 From mdulko at redhat.com Thu Dec 13 12:39:35 2018 From: mdulko at redhat.com (=?UTF-8?Q?Micha=C5=82?= Dulko) Date: Thu, 13 Dec 2018 13:39:35 +0100 Subject: [dev] [infra] [devstack] [qa] [kuryr] DevStack's etcd performance on gate VM's Message-ID: Hi, In Kuryr-Kubernetes we're using the DevStack-installed etcd as a backend store for Kubernetes that we run on our gates. For some time we can see its degraded performance manifesting like this [1] in the logs. Later on this leads to various K8s errors [2], [3], up to missing notifications from the API, which causes failures in Kuryr-Kubernetes tempest tests. From what I've seen those etcd warnings normally mean that disk latency is high. This seems to be mostly happening on OVH and RAX hosts. I've looked at this with OVH folks and there isn't anything immediately alarming about their hosts running gate VM's. Upgrading the etcd version doesn't seem to help, as well as patch [4] which increases IO priority for etcd process. Any ideas of what I can try next? I think we're the only project that puts so much pressure on the DevStack's etcd. Help would really be welcomed, getting rid of this issue will greatly increase our gates stability. Thanks, Michał [1] http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/screen-etcd.txt.gz#_Dec_12_17_19_33_618619 [2] http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/screen-kubernetes-api.txt.gz#_Dec_12_17_20_19_772688 [3] http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/screen-kubernetes-scheduler.txt.gz#_Dec_12_17_18_59_045347 [4] https://review.openstack.org/#/c/624730/ From ayoung at redhat.com Thu Dec 13 01:09:17 2018 From: ayoung at redhat.com (Adam Young) Date: Wed, 12 Dec 2018 20:09:17 -0500 Subject: Meaning of role name: auditor versus reader Message-ID: We've recently come to accept reader as one of the default roles. However, one thing that is not clear to me is the intention: is this designed to be the readonly set of operations that an admin can do, or the read only set of operations that a member can do? Should we really have two read-only roles, one for each case? Perhaps the admin-read-only should be called auditor, and then reader is for member only operations? -------------- next part -------------- An HTML attachment was scrubbed... URL: From manuel.sb at garvan.org.au Thu Dec 13 05:59:41 2018 From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros) Date: Thu, 13 Dec 2018 05:59:41 +0000 Subject: can't login to baremetal deploid with ironic Message-ID: <9D8A2486E35F0941A60430473E29F15B017BAF8E62@MXDB2.ad.garvan.unsw.edu.au> Dear Openstack user group, I am playing with Ironic and have a very stupid question... For some reason I can't login to the server after deployment. Server status is ACTIVE and I am using the adminPass provided by openstack . The way I connect is through server console through the IPMI console (not ssh). [root at openstack-deployment ~]# openstack server create --image 760f4076-4f2d-455b-89b5-6c1248148f70 --flavor my-baremetal-flavor --network hpc demo1 +-------------------------------------+------------------------------------------------------------+ | Field | Value | +-------------------------------------+------------------------------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | | | OS-EXT-SRV-ATTR:host | None | | OS-EXT-SRV-ATTR:hypervisor_hostname | None | | OS-EXT-SRV-ATTR:instance_name | | | OS-EXT-STS:power_state | NOSTATE | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | None | | OS-SRV-USG:terminated_at | None | | accessIPv4 | | | accessIPv6 | | | addresses | | | adminPass | t3TAUNwTbuD5 | | config_drive | | | created | 2018-12-13T05:39:11Z | | flavor | my-baremetal-flavor (84abc368-1695-4387-998c-8b47da1a3a34) | | hostId | | | id | 5231e015-73e9-472f-bb84-bde9bf7e6989 | | image | centos7.5-image (760f4076-4f2d-455b-89b5-6c1248148f70) | | key_name | None | | name | demo1 | | progress | 0 | | project_id | 0b3d8fd6015048e89f4372fb1534900b | | properties | | | security_groups | name='default' | | status | BUILD | | updated | 2018-12-13T05:39:12Z | | user_id | fd244f331bc34066b7a5fae72d518261 | | volumes_attached | | +-------------------------------------+------------------------------------------------------------+ [root at openstack-deployment ~]# openstack server list +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ | 5231e015-73e9-472f-bb84-bde9bf7e6989 | demo1 | ACTIVE | hpc=10.0.32.119 | centos7.5-image | my-baremetal-flavor | | 9cc2369f-1951-4bec-bc8b-863fd6cc9983 | test | ACTIVE | hpc=10.0.32.116 | cirros | m1.tiny | +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ Any thoughts? 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: From iurygregory at gmail.com Thu Dec 13 13:26:03 2018 From: iurygregory at gmail.com (Iury Gregory) Date: Thu, 13 Dec 2018 14:26:03 +0100 Subject: can't login to baremetal deploid with ironic In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017BAF8E62@MXDB2.ad.garvan.unsw.edu.au> References: <9D8A2486E35F0941A60430473E29F15B017BAF8E62@MXDB2.ad.garvan.unsw.edu.au> Message-ID: Hello Manuel, Did you try the default password for cirros images? https://docs.openstack.org/image-guide/obtain-images.html#cirros-test Em qui, 13 de dez de 2018 às 14:05, Manuel Sopena Ballesteros < manuel.sb at garvan.org.au> escreveu: > Dear Openstack user group, > > > > I am playing with Ironic and have a very stupid question… > > > > For some reason I can’t login to the server after deployment. Server > status is ACTIVE and I am using the adminPass provided by openstack . > > > > The way I connect is through server console through the IPMI console (not > ssh). > > > > [root at openstack-deployment ~]# openstack server create --image > 760f4076-4f2d-455b-89b5-6c1248148f70 --flavor my-baremetal-flavor --network > hpc demo1 > > > +-------------------------------------+------------------------------------------------------------+ > > | Field | > Value | > > > +-------------------------------------+------------------------------------------------------------+ > > | OS-DCF:diskConfig | > MANUAL | > > | OS-EXT-AZ:availability_zone > | | > > | OS-EXT-SRV-ATTR:host | > None | > > | OS-EXT-SRV-ATTR:hypervisor_hostname | None > | > > | OS-EXT-SRV-ATTR:instance_name > | | > > | OS-EXT-STS:power_state | > NOSTATE | > > | OS-EXT-STS:task_state | > scheduling | > > | OS-EXT-STS:vm_state | > building | > > | OS-SRV-USG:launched_at | None > | > > | OS-SRV-USG:terminated_at | > None | > > | accessIPv4 > | | > > | accessIPv6 > | > | > > | addresses > | | > > | adminPass | t3TAUNwTbuD5 > | > > | config_drive > | | > > | created | > 2018-12-13T05:39:11Z | > > | flavor | my-baremetal-flavor > (84abc368-1695-4387-998c-8b47da1a3a34) | > > | hostId > | | > > | id | > 5231e015-73e9-472f-bb84-bde9bf7e6989 | > > | image | centos7.5-image > (760f4076-4f2d-455b-89b5-6c1248148f70) | > > | key_name | > None | > > | name | > demo1 | > > | progress | > 0 | > > | project_id | > 0b3d8fd6015048e89f4372fb1534900b | > > | properties > | | > > | security_groups | > name='default' | > > | status | > BUILD | > > | updated | > 2018-12-13T05:39:12Z | > > | user_id | > fd244f331bc34066b7a5fae72d518261 | > > | volumes_attached > | | > > > +-------------------------------------+------------------------------------------------------------+ > > [root at openstack-deployment ~]# openstack server list > > > +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ > > | ID | Name | Status | Networks > | Image | Flavor | > > > +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ > > | 5231e015-73e9-472f-bb84-bde9bf7e6989 | demo1 | ACTIVE | hpc=10.0.32.119 > | centos7.5-image | my-baremetal-flavor | > > | 9cc2369f-1951-4bec-bc8b-863fd6cc9983 | test | ACTIVE | hpc=10.0.32.116 > | cirros | m1.tiny | > > > +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ > > > > Any thoughts? > > > > *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. > -- *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: From cdent+os at anticdent.org Thu Dec 13 13:27:06 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Thu, 13 Dec 2018 13:27:06 +0000 (GMT) Subject: Proposal to move cinder backup tests out of the integrated gate In-Reply-To: References: Message-ID: On Wed, 12 Dec 2018, Matt Riedemann wrote: > I wanted to send this separate from the latest gate status update [1] since > it's primarily about latent cinder bugs causing failures in the gate for > which no one is really investigating. Thanks for writing up this and the other message [1]. It provides much more visibility and context over the situation and hopefully can stimulate people to think about making fixes and perhaps changes to some of the ways we do things that aren't always working. In that spirit... > Regarding the backup tests specifically, I don't see a reason why they need > to be run in the integrated gate jobs, e.g. tempest-full(-py3). They don't > involve other services, so in my opinion we should move the backup tests to a > separate job which only runs on cinder changes to alleviate these latent bugs > failing jobs for unrelated changes and resetting the entire gate. I guess in this case these tests were exposed by their failing, and it was only once investigating that you realized they weren't truly integration tests? Have you, Matt, got any ideas on how to find other non-integration tests that are being treated as integration which we could move to their own things? De-tangling the spaghetti is likely to reveal plenty of improvements but also plenty of areas that need more attention. A couple of things I've been working on lately that might be useful for refining tests, such that we catch failures in check before the integrated gate: * In nova, we're in the process of removing placement, but continuing to use a real, instead of fake, placement fixture in the functional tests [2][3]. This is relatively straightforward for placement, since it is just a simple wsgi app, but it might be possible to create similar things for Cinder and other services, so that functional tests that are currently using a faked out stub of an alien service can use something a bit more robust. If people are interested in trying to make that happen, I'd be happy to help make it go but I wouldn't be able until next year. * In placement we wanted to do some very simple live performance testing but didn't want to pay the time cost of setting up a devstack or tempest node, so did something much more lightweight [4] which takes about 1/3rd or less of the time. This may be a repeatable pattern for other kinds of testing. Often times devstack and tempest are overkill but we default to them because they are there. And finally, the use of wsgi-intercept[5] (usually with gabbi [6]), has made it possible to have reasonably high confidence of the behavior of the placement and nova APIs via functional tests, catching issues before anything as costly as tempest gets involved. Any service which presents its API as a WSGI should be able to use the same tooling if they want. If anyone is curious about any of this stuff, please feel free to ask. [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000867.html [2] https://review.openstack.org/#/c/617941/ [3] https://git.openstack.org/cgit/openstack/placement/tree/placement/tests/functional/fixtures/placement.py [4] https://review.openstack.org/#/c/619248/ [5] https://pypi.org/project/wsgi_intercept/ [6] https://gabbi.readthedocs.io -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From openstack at nemebean.com Thu Dec 13 13:45:21 2018 From: openstack at nemebean.com (Ben Nemec) Date: Thu, 13 Dec 2018 07:45:21 -0600 Subject: [dev] [infra] [devstack] [qa] [kuryr] DevStack's etcd performance on gate VM's In-Reply-To: References: Message-ID: <90c568b5-d46f-d068-ec9f-7524e36af696@nemebean.com> On 12/13/18 6:39 AM, Michał Dulko wrote: > Hi, > > In Kuryr-Kubernetes we're using the DevStack-installed etcd as a > backend store for Kubernetes that we run on our gates. For some time we > can see its degraded performance manifesting like this [1] in the logs. > Later on this leads to various K8s errors [2], [3], up to missing > notifications from the API, which causes failures in Kuryr-Kubernetes > tempest tests. From what I've seen those etcd warnings normally mean > that disk latency is high. > > This seems to be mostly happening on OVH and RAX hosts. I've looked at > this with OVH folks and there isn't anything immediately alarming about > their hosts running gate VM's. > > Upgrading the etcd version doesn't seem to help, as well as patch [4] > which increases IO priority for etcd process. > > Any ideas of what I can try next? I think we're the only project that > puts so much pressure on the DevStack's etcd. Help would really be > welcomed, getting rid of this issue will greatly increase our gates > stability. Do you by any chance use grpcio to talk to etcd? If so, it's possible you are hitting https://bugs.launchpad.net/python-tooz/+bug/1808046 In tooz that presents as random timeouts and everything taking a lot longer than it should. > > Thanks, > Michał > > [1] http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/screen-etcd.txt.gz#_Dec_12_17_19_33_618619 > [2] http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/screen-kubernetes-api.txt.gz#_Dec_12_17_20_19_772688 > [3] http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/screen-kubernetes-scheduler.txt.gz#_Dec_12_17_18_59_045347 > [4] https://review.openstack.org/#/c/624730/ > > From thierry at openstack.org Thu Dec 13 13:51:38 2018 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 13 Dec 2018 14:51:38 +0100 Subject: [all]Forum summary: Expose SIGs and WGs In-Reply-To: <20181212122806.kll3gw6w65wz3js3@pacific.linksys.moosehall> References: <20181212122806.kll3gw6w65wz3js3@pacific.linksys.moosehall> Message-ID: <356a8271-438e-d39c-e83c-fb50f68026b9@openstack.org> Adam Spiers wrote: > Rico Lin wrote: >> As a further idea, we can even discuss if it's a common interest to >> have a SIG to help on SIGs. > > We already have that ;-)  It's the "meta" SIG, mentioned here: >    https://governance.openstack.org/sigs/ Yes, and so far it's mostly been a two-person effort to bootstrap the SIG concept and encourage SIGs (which are basically groups of like-minded folks wanting to work on a specific topic that does not fit in the more traditional team structure) to be formed. I think the bootstrapping phase is completed now, so it's time to move to phase 2, which is putting some systems in place to make SIGs more successful. We now have enough information on the success and failures of early SIGs to debate what we could put in place to help them. I think this discussion fits right in the goals of the Meta SIG. So far the Meta SIG has been going fully async (no meeting, just ML discussion threads and reviews of proposed changes to the openstack/governance-sigs repository). -- Thierry Carrez (ttx) From thierry at openstack.org Thu Dec 13 14:05:54 2018 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 13 Dec 2018 15:05:54 +0100 Subject: [all][security-sig][meta-sig] Forum summary: Expose SIGs and WGs In-Reply-To: <20181212132044.ibvr6dd54zrbqkj3@pacific.linksys.moosehall> References: <20181212132044.ibvr6dd54zrbqkj3@pacific.linksys.moosehall> Message-ID: <8c96b29d-9c12-26ea-a9f1-2c55c7d898fc@openstack.org> Adam Spiers wrote: > Matt Riedemann wrote: >> They did what they were asked and things have stalled. At this point, >> I think it comes down to priorities, and in order to prioritize >> something big like this that requires coordinated work across several >> projects, we are going to need more stakeholders coming forward and >> saying they also want this feature so the vendors who are paying the >> people to work upstream can be given specific time to give this the >> attention it needs. And that ties back into getting the top 1 or 2 >> wishlist items from each SIG and trying to sort those based on what is >> the highest rated most common need for the greatest number of people - >> sort of like what we see happening with the resource delete API >> community wide goal proposal. > > Agreed.  The Security SIG sounds like a natural home for it.  I'm going > to wildly speculate that maybe part of the reason it stalled is that it > was perceived as coming from a couple of individuals rather than a SIG. > If the initiative had been backed by the Security SIG as something worth > prioritising, then maybe it could have received wider attention. Yes... As much as we'd like to think the problem here is purely technical, getting it done in an openly-collaborating community means it's also a social problem. It will compete with a LOT of other things to get priority. In order to get it done, you need to make it well-known, and gather a bit of mindshare, so that it gets on people's radar with some amount of priority. That means the effort needs to be clearly identified (give it a distinctive name), and a lot of communication needs to be done around it (presentations, forum/PTG sessions, ML status reports...). Working under a SIG umbrella definitely facilitates that "promotion" side of the work, since SIGs already have some visibility built in. The "top 2 wishlist per SIG" idea is just one way to encourage focusing this promotion effort on a limited number of things at the same time, because there is just no way you can promote 10 different things and expect them all to stick. -- Thierry Carrez (ttx) From openstack at nemebean.com Thu Dec 13 14:08:16 2018 From: openstack at nemebean.com (Ben Nemec) Date: Thu, 13 Dec 2018 08:08:16 -0600 Subject: [cinder][ops][docs][keystone] policy configuration howto In-Reply-To: References: Message-ID: <8a1749f7-ed18-971a-82c8-ae7e639cfe91@nemebean.com> cc Keystone. It would be interesting to know how this fits in with the new default roles work. On 12/12/18 8:21 PM, Brian Rosmaita wrote: > At last week's cinder meeting (5 December) we had a discussion about > policy checks at the database layer. While these checks seem to make it > difficult to perform some policy configurations, there are too many of > them to simply remove them without impacting stability given our current > test coverage (at least that's my feeling). Additionally, it's possible > to handle the proposed use case (a read-only administrator) without > making any code changes. So we decided to fix this issue by documenting > how this could work. > > I've got a patch up for the documentation. I've flagged this email for > cinder people to read for accuracy, operators to read to make sure the > instructions are clear and detailed, and docs people to read for > felicity of expression. Please leave comments on the patch: > > https://review.openstack.org/#/c/624424/ > > cheers, > brian > From tpb at dyncloud.net Thu Dec 13 14:16:34 2018 From: tpb at dyncloud.net (Tom Barron) Date: Thu, 13 Dec 2018 09:16:34 -0500 Subject: Proposal to move cinder backup tests out of the integrated gate In-Reply-To: References: Message-ID: <20181213141634.hkiu3of3qbecyydv@barron.net> On 12/12/18 14:00 -0600, Matt Riedemann wrote: >I wanted to send this separate from the latest gate status update [1] >since it's primarily about latent cinder bugs causing failures in the >gate for which no one is really investigating. > >Running down our tracked gate bugs [2] there are several related to >cinder-backup testing: > >* http://status.openstack.org/elastic-recheck/#1483434 >* http://status.openstack.org/elastic-recheck/#1745168 >* http://status.openstack.org/elastic-recheck/#1739482 >* http://status.openstack.org/elastic-recheck/#1635643 > >All of those bugs were reported a long time ago. I've done some >investigation into them (at least at the time of reporting) and some >are simply due to cinder-api using synchronous RPC calls to >cinder-volume (or cinder-backup) and that doesn't scale. This bug >isn't a backup issue, but it's definitely related to using RPC call >rather than cast: > >http://status.openstack.org/elastic-recheck/#1763712 > >Regarding the backup tests specifically, I don't see a reason why they >need to be run in the integrated gate jobs, e.g. tempest-full(-py3). >They don't involve other services, so in my opinion we should move the >backup tests to a separate job which only runs on cinder changes to >alleviate these latent bugs failing jobs for unrelated changes and >resetting the entire gate. FWIW cinder backup by default uses swift as the backup driver and requires its services, and that's the way it is being run in this job [1]. The job could be modified to use e.g. NFS driver and not depend on other OpenStack services (unless one wanted to be fancy and have Manila provision the backup share). Cheers, -- Tom Barron (tbarron) [1] http://logs.openstack.org/55/569055/7/gate/nova-next/2e23975/logs/screen-c-bak.txt.gz?level=DEBUG#_Nov_13_11_18_36_805573 > >I would need someone from the cinder team that is more involved in >knowing what their job setup looks like to identify a candidate job >for these tests if this is something everyone can agree on doing. > >[1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000867.html >[2] http://status.openstack.org/elastic-recheck/ > >-- > >Thanks, > >Matt > From cristian.calin at orange.com Thu Dec 13 14:18:53 2018 From: cristian.calin at orange.com (cristian.calin at orange.com) Date: Thu, 13 Dec 2018 14:18:53 +0000 Subject: Meaning of role name: auditor versus reader In-Reply-To: References: Message-ID: <6591_1544710745_5C126A59_6591_247_1_046251b454084202978c37e1ab42e152@orange.com> As operators, we have a need for both cases and actually a 3rd one as well which should be domain scoped. I think the definition of reader should also include a scope (cloud-wide, domain specific or project specific) so that we don’t need different roles. This might be a more fundamental change though as the scoping is static today, I mean defined in the policy files/code. Cristian Calin From: Adam Young [mailto:ayoung at redhat.com] Sent: Thursday, December 13, 2018 3:09 AM To: List, OpenStack Subject: Meaning of role name: auditor versus reader We've recently come to accept reader as one of the default roles.  However, one thing that is not clear to me is the intention:  is this designed to be the readonly set of operations that an admin can do, or the read only set of operations that a member can do? Should we really have two read-only roles, one for each case?  Perhaps the admin-read-only should be called auditor, and then reader is for member only operations? _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From colleen at gazlene.net Thu Dec 13 14:25:27 2018 From: colleen at gazlene.net (Colleen Murphy) Date: Thu, 13 Dec 2018 15:25:27 +0100 Subject: [keystone] Re: Meaning of role name: auditor versus reader In-Reply-To: <6591_1544710745_5C126A59_6591_247_1_046251b454084202978c37e1ab42e152@orange.com> References: <6591_1544710745_5C126A59_6591_247_1_046251b454084202978c37e1ab42e152@orange.com> Message-ID: <1544711127.2243570.1608188192.0349FB20@webmail.messagingengine.com> Tagging keystone On Thu, Dec 13, 2018, at 3:18 PM, cristian.calin at orange.com wrote: > As operators, we have a need for both cases and actually a 3rd one as > well which should be domain scoped. > I think the definition of reader should also include a scope (cloud- > wide, domain specific or project specific) so that we don’t need > different roles. > This might be a more fundamental change though as the scoping is static > today, I mean defined in the policy files/code. > > Cristian Calin > > From: Adam Young [mailto:ayoung at redhat.com] > Sent: Thursday, December 13, 2018 3:09 AM > To: List, OpenStack > Subject: Meaning of role name: auditor versus reader > > We've recently come to accept reader as one of the default roles.  > However, one thing that is not clear to me is the intention:  is this > designed to be the readonly set of operations that an admin can do, or > the read only set of operations that a member can do? > > Should we really have two read-only roles, one for each case?  Perhaps > the admin-read-only should be called auditor, and then reader is for > member only operations? > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme > ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > From gmann at ghanshyammann.com Thu Dec 13 15:02:53 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 14 Dec 2018 00:02:53 +0900 Subject: [dev] [tc][all] TC office hours is started now on #openstack-tc Message-ID: <167a817877d.12b69472f61583.6314102811644291699@ghanshyammann.com> Hello everyone, 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. - gmann & TC From jungleboyj at gmail.com Thu Dec 13 15:03:18 2018 From: jungleboyj at gmail.com (Jay Bryant) Date: Thu, 13 Dec 2018 09:03:18 -0600 Subject: Proposal to move cinder backup tests out of the integrated gate In-Reply-To: References: Message-ID: <69d803fb-b1d2-102c-c9d4-268af5e47ee0@gmail.com> On 12/12/2018 2:00 PM, Matt Riedemann wrote: > I wanted to send this separate from the latest gate status update [1] > since it's primarily about latent cinder bugs causing failures in the > gate for which no one is really investigating. > Matt, thank you for putting together this information.  I am sorry that these issues with Cinder are impacting Nova's ability to merge code.  I don't think we knew that this was having an impact on Nova. > Running down our tracked gate bugs [2] there are several related to > cinder-backup testing: > > * http://status.openstack.org/elastic-recheck/#1483434 > * http://status.openstack.org/elastic-recheck/#1745168 > * http://status.openstack.org/elastic-recheck/#1739482 > * http://status.openstack.org/elastic-recheck/#1635643 > > All of those bugs were reported a long time ago. I've done some > investigation into them (at least at the time of reporting) and some > are simply due to cinder-api using synchronous RPC calls to > cinder-volume (or cinder-backup) and that doesn't scale. This bug > isn't a backup issue, but it's definitely related to using RPC call > rather than cast: > > http://status.openstack.org/elastic-recheck/#1763712 > Thanks to bringing this up Dan Smith has proposed a patch that may help with the timeouts.  https://review.openstack.org/#/c/624809/ The thought is that cocurrent LVM processes might be the source of the timeout.  We will continue to work with Dan on that patch. > Regarding the backup tests specifically, I don't see a reason why they > need to be run in the integrated gate jobs, e.g. tempest-full(-py3). > They don't involve other services, so in my opinion we should move the > backup tests to a separate job which only runs on cinder changes to > alleviate these latent bugs failing jobs for unrelated changes and > resetting the entire gate. > > I would need someone from the cinder team that is more involved in > knowing what their job setup looks like to identify a candidate job > for these tests if this is something everyone can agree on doing. > We have a member of the team that might have some bandwidth to start working on check/gate issues.  I have added this issue to our meeting agenda for next week.  We should be able to get attention from the team members can help at that point in time. > [1] > http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000867.html > [2] http://status.openstack.org/elastic-recheck/ > From ignaziocassano at gmail.com Thu Dec 13 15:06:51 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Thu, 13 Dec 2018 16:06:51 +0100 Subject: queens heat db deadlock Message-ID: Hi All, I installed queens on centos 7. Heat seems to work fine with templates I wrote but when I create magnum cluster I often face with db deadlock in heat-engine log: 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource Traceback (most recent call last): 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 918, in _action_recorder 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource yield 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 2035, in delete 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource *action_args) 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/scheduler.py", line 346, in wrapper 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource step = next(subtask) 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 977, in action_handler_task 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource done = check(handler_data) 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", line 587, in check_delete_complete 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource return self._check_status_complete(self.DELETE) 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", line 454, in _check_status_complete 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource action=action) 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource ResourceFailure: resources[0]: (pymysql.err.InternalError) (1213, u'Deadlock found when trying to get lock; try restarting transaction') (Background on this error at: http://sqlalche.me/e/2j85) 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource 2018-12-13 11:48:46.030 89597 INFO heat.engine.stack [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] Stack DELETE FAILED (swarm-clustergp27-ebhsalhb4bop-swarm_primary_master-tzgkh3ncmymw): Resource DELETE failed: resources[0]: (pymysql.err.InternalError) (1213, u'Deadlock found when trying to get lock; try restarting transaction') (Background on this error at: http://sqlalche.me/e/2j85) 2018-12-13 11:48:46.844 89595 INFO heat.engine.resource [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] DELETE: ResourceGroup "swarm_primary_master" [6984db3c-3ac1-4afc-901f-21b3e7f230a7] Stack "swarm-clustergp27-ebhsalhb4bop" [b43256fa-52e2-4613-ac15-63fd9340a8be] I read this issue was solved in heat version 10 but seems not. Regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From jungleboyj at gmail.com Thu Dec 13 15:15:09 2018 From: jungleboyj at gmail.com (Jay Bryant) Date: Thu, 13 Dec 2018 09:15:09 -0600 Subject: Proposal to move cinder backup tests out of the integrated gate In-Reply-To: <20181213141634.hkiu3of3qbecyydv@barron.net> References: <20181213141634.hkiu3of3qbecyydv@barron.net> Message-ID: > FWIW cinder backup by default uses swift as the backup driver and > requires its services, and that's the way it is being run in this job > [1]. > > The job could be modified to use e.g. NFS driver and not depend on > other OpenStack services (unless one wanted to be fancy and have > Manila provision the backup share). > > Cheers, > > -- Tom Barron (tbarron) > Tom, Thanks for pointing this out.  I am a little nervous about changing the default in testing given that is the default configuration for backup.  I think if we are not able to narrow down the source of the issues this could be a road to investigate but I don't think that is the first course of action we want to take. Jay From tpb at dyncloud.net Thu Dec 13 15:23:02 2018 From: tpb at dyncloud.net (Tom Barron) Date: Thu, 13 Dec 2018 10:23:02 -0500 Subject: Proposal to move cinder backup tests out of the integrated gate In-Reply-To: References: <20181213141634.hkiu3of3qbecyydv@barron.net> Message-ID: <20181213152302.bzsbjlnqg5fnynpk@barron.net> On 13/12/18 09:15 -0600, Jay Bryant wrote: > >>FWIW cinder backup by default uses swift as the backup driver and >>requires its services, and that's the way it is being run in this >>job [1]. >> >>The job could be modified to use e.g. NFS driver and not depend on >>other OpenStack services (unless one wanted to be fancy and have >>Manila provision the backup share). >> >>Cheers, >> >>-- Tom Barron (tbarron) >> >Tom, > >Thanks for pointing this out.  I am a little nervous about changing >the default in testing given that is the default configuration for >backup.  I think if we are not able to narrow down the source of the >issues this could be a road to investigate but I don't think that is >the first course of action we want to take. > >Jay > > Yup, I was just pointing out that this *is* currently a service integration test and then looking at two ends of the spectrum in terms of running it without dependencies on other services (except the normal keystone, etc.) and with other dependencies than swift. FWIW I agree that keeping the default and fixing the issue makes sense :) From jean-philippe at evrard.me Thu Dec 13 16:06:43 2018 From: jean-philippe at evrard.me (Jean-Philippe Evrard) Date: Thu, 13 Dec 2018 17:06:43 +0100 Subject: [tc][all] Train Community Goals In-Reply-To: References: Message-ID: Hello everyone, We are looking for volunteers and potential future champions, particularily to assist in completing prerequisite work for service- side healthchecks and cleaning up resources when deleting a project. Goals are more likely to be successful if there is someone to drive the work. Having an accurate assessment of the prerequisite work before the goals even make it into review will help with scope and possibly finding ways to break the work into more manageable pieces. So far, the service-side health checks goal requires some oslo work for the framework that services would use to implement the goal. The cleanup of resources when deleting a project goal requires some anaylsis on what the interface would look like for both os-purge and an API in each service. Is anyone interested in driving the prerequisite work for these two proposals? Ideally, it would be great if we could have the work done by the middle of January, which gives us enough time to discuss prior to putting proposals in review. This note is specific to the most popular goals from the summit session in Berlin and prerequisite work for those goals. That said, it's certainly not too late to propose other ideas or goals for Train. Thoughts? Lance (lbragstad) and JP (evrardjp) From mdulko at redhat.com Thu Dec 13 16:20:02 2018 From: mdulko at redhat.com (=?UTF-8?Q?Micha=C5=82?= Dulko) Date: Thu, 13 Dec 2018 17:20:02 +0100 Subject: [dev] [infra] [devstack] [qa] [kuryr] DevStack's etcd performance on gate VM's In-Reply-To: <90c568b5-d46f-d068-ec9f-7524e36af696@nemebean.com> References: <90c568b5-d46f-d068-ec9f-7524e36af696@nemebean.com> Message-ID: <5d2bba9cf8a9503ae6f84cc012bbaf1a43c546a8.camel@redhat.com> On Thu, 2018-12-13 at 07:45 -0600, Ben Nemec wrote: > > On 12/13/18 6:39 AM, Michał Dulko wrote: > > Hi, > > > > In Kuryr-Kubernetes we're using the DevStack-installed etcd as a > > backend store for Kubernetes that we run on our gates. For some time we > > can see its degraded performance manifesting like this [1] in the logs. > > Later on this leads to various K8s errors [2], [3], up to missing > > notifications from the API, which causes failures in Kuryr-Kubernetes > > tempest tests. From what I've seen those etcd warnings normally mean > > that disk latency is high. > > > > This seems to be mostly happening on OVH and RAX hosts. I've looked at > > this with OVH folks and there isn't anything immediately alarming about > > their hosts running gate VM's. > > > > Upgrading the etcd version doesn't seem to help, as well as patch [4] > > which increases IO priority for etcd process. > > > > Any ideas of what I can try next? I think we're the only project that > > puts so much pressure on the DevStack's etcd. Help would really be > > welcomed, getting rid of this issue will greatly increase our gates > > stability. > > Do you by any chance use grpcio to talk to etcd? If so, it's possible > you are hitting https://bugs.launchpad.net/python-tooz/+bug/1808046 > > In tooz that presents as random timeouts and everything taking a lot > longer than it should. Seems like it's something else. We don't call etcd from Python using any lib. It's only Kubernetes that's doing that in our gates. > > Thanks, > > Michał > > > > [1] http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/screen-etcd.txt.gz#_Dec_12_17_19_33_618619 > > [2] http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/screen-kubernetes-api.txt.gz#_Dec_12_17_20_19_772688 > > [3] http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/screen-kubernetes-scheduler.txt.gz#_Dec_12_17_18_59_045347 > > [4] https://review.openstack.org/#/c/624730/ > > > > From cboylan at sapwetik.org Thu Dec 13 17:06:17 2018 From: cboylan at sapwetik.org (Clark Boylan) Date: Thu, 13 Dec 2018 09:06:17 -0800 Subject: [dev] [infra] [devstack] [qa] [kuryr] DevStack's etcd performance on gate VM's In-Reply-To: References: Message-ID: <1544720777.384097.1608336832.49746981@webmail.messagingengine.com> On Thu, Dec 13, 2018, at 4:39 AM, Michał Dulko wrote: > Hi, > > In Kuryr-Kubernetes we're using the DevStack-installed etcd as a > backend store for Kubernetes that we run on our gates. For some time we > can see its degraded performance manifesting like this [1] in the logs. > Later on this leads to various K8s errors [2], [3], up to missing > notifications from the API, which causes failures in Kuryr-Kubernetes > tempest tests. From what I've seen those etcd warnings normally mean > that disk latency is high. > > This seems to be mostly happening on OVH and RAX hosts. I've looked at > this with OVH folks and there isn't anything immediately alarming about > their hosts running gate VM's. That's interesting because we've been working with amorin at OVH over debugging similar IO problems and I think we both agree something is happening. We've disabled the BHS1 region as the vast majority of related failures were there, but kept GRA1 up and running which is where your example is from. My understanding is that a memory issue of some sort was found on the compute hypervisors (which could affect disk throughput if there isn't memory for caching available or if swap is using up available disk IO). We are currently waiting on amorin's go ahead to turn BHS1 back on after this is corrected. > > Upgrading the etcd version doesn't seem to help, as well as patch [4] > which increases IO priority for etcd process. > > Any ideas of what I can try next? I think we're the only project that > puts so much pressure on the DevStack's etcd. Help would really be > welcomed, getting rid of this issue will greatly increase our gates > stability. It wouldn't surprise me if others aren't using etcd much. One thing that may help is to use the dstat data [5] from these failed jobs to rule out resource contention from within the job (cpu, io(ps), memory, etc). One thing we've found debugging these slower nodes is that it often exposes real bugs in our software by making them cost more. We should double check there isn't anything obvious like that happening here too. I've been putting the csv file in https://lamada.eu/dstat-graph/ and that renders it for human consumption. But there are other tools out there for this too. > > Thanks, > Michał > > [1] > http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/screen-etcd.txt.gz#_Dec_12_17_19_33_618619 > [2] > http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/screen-kubernetes-api.txt.gz#_Dec_12_17_20_19_772688 > [3] > http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/screen-kubernetes-scheduler.txt.gz#_Dec_12_17_18_59_045347 > [4] https://review.openstack.org/#/c/624730/ > > [5] http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/dstat-csv_log.txt From lbragstad at gmail.com Thu Dec 13 17:06:12 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Thu, 13 Dec 2018 11:06:12 -0600 Subject: [keystone] Re: Meaning of role name: auditor versus reader In-Reply-To: <1544711127.2243570.1608188192.0349FB20@webmail.messagingengine.com> References: <6591_1544710745_5C126A59_6591_247_1_046251b454084202978c37e1ab42e152@orange.com> <1544711127.2243570.1608188192.0349FB20@webmail.messagingengine.com> Message-ID: I was under the assumption that the ``reader`` role wouldn't be specific to the actions of either operators or regular end users. I thought the intention was to leverage the scope of the assignment to answer that question for us. For example: Let's assume Sarah is granted the reader role on the system (``openstack role add --user sarah --system all reader``). In theory, she has the ability to list system-specific resources, like endpoints, services, domains, or compute hosts. She can perform audits on the deployment infrastructure. If Chris has the reader role on a project (``openstack role add --user chris --project foobar reader``), he should theoretically have the ability to list instances and volumes within the project. Even though Chris has the reader role, he doesn't have the ability to list system-specific resources, because he doesn't have the system role assignment Sarah has. We can expand the example to include domain support, too. If Jane has a reader role on a domain (``openstack role add --user jane --domain baz reader``), she theoretically has the ability to view things owned by that domain, like users, groups, or projects whose domain ID is ``baz``. The same role is used in all three cases, but the target in each user's role assignment is important, too. This might be easier to see in practice between system [0], domain] [1], and project [2] readers all using the ``reader`` role. In my opinion, this gives us more bang for our buck as far as role definitions are concerned. We aren't worried about defining system-reader, domain-reader, and project-reader roles. Additionally, I cringe a little bit thinking about the custom policy required for those cases and the confusion operators might have when Jane gets the project-reader role assignment on a domain. [0] https://review.openstack.org/#/c/619329/3/keystone/tests/unit/protection/v3/test_endpoints.py at 31 [1] https://review.openstack.org/#/c/619332/4/keystone/tests/unit/protection/v3/test_endpoints.py at 131 [2] https://review.openstack.org/#/c/619281/5/keystone/tests/unit/protection/v3/test_endpoints.py,unified at 376 On Thu, Dec 13, 2018 at 8:27 AM Colleen Murphy wrote: > Tagging keystone > > On Thu, Dec 13, 2018, at 3:18 PM, cristian.calin at orange.com wrote: > > As operators, we have a need for both cases and actually a 3rd one as > > well which should be domain scoped. > > I think the definition of reader should also include a scope (cloud- > > wide, domain specific or project specific) so that we don’t need > > different roles. > > This might be a more fundamental change though as the scoping is static > > today, I mean defined in the policy files/code. > > > > Cristian Calin > > > > From: Adam Young [mailto:ayoung at redhat.com] > > Sent: Thursday, December 13, 2018 3:09 AM > > To: List, OpenStack > > Subject: Meaning of role name: auditor versus reader > > > > We've recently come to accept reader as one of the default roles. > > However, one thing that is not clear to me is the intention: is this > > designed to be the readonly set of operations that an admin can do, or > > the read only set of operations that a member can do? > > > > Should we really have two read-only roles, one for each case? Perhaps > > the admin-read-only should be called auditor, and then reader is for > > member only operations? > > > > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > > recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme > > ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > > been modified, changed or falsified. > > Thank you. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juliaashleykreger at gmail.com Thu Dec 13 17:15:39 2018 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Thu, 13 Dec 2018 09:15:39 -0800 Subject: can't login to baremetal deploid with ironic In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017BAF8E62@MXDB2.ad.garvan.unsw.edu.au> References: <9D8A2486E35F0941A60430473E29F15B017BAF8E62@MXDB2.ad.garvan.unsw.edu.au> Message-ID: Greetings Manuel, AdminPass being able to be used would be dependent upon that password being available in the meta data service, or being burned into the configuration drive. At that point, once the OS has booted, it is up to a tool like cloud-init to put that password in place, much as it does with ssh authorized_keys. It might be doing so for a user account named something like "centos". For what it is worth, most users use key based authentication for instances they have created. -Julia On Thu, Dec 13, 2018 at 5:10 AM Manuel Sopena Ballesteros < manuel.sb at garvan.org.au> wrote: > Dear Openstack user group, > > > > I am playing with Ironic and have a very stupid question… > > > > For some reason I can’t login to the server after deployment. Server > status is ACTIVE and I am using the adminPass provided by openstack . > > > > The way I connect is through server console through the IPMI console (not > ssh). > > > > [root at openstack-deployment ~]# openstack server create --image > 760f4076-4f2d-455b-89b5-6c1248148f70 --flavor my-baremetal-flavor --network > hpc demo1 > > > +-------------------------------------+------------------------------------------------------------+ > > | Field | > Value | > > > +-------------------------------------+------------------------------------------------------------+ > > | OS-DCF:diskConfig | > MANUAL | > > | OS-EXT-AZ:availability_zone > | | > > | OS-EXT-SRV-ATTR:host | > None | > > | OS-EXT-SRV-ATTR:hypervisor_hostname | None > | > > | OS-EXT-SRV-ATTR:instance_name > | | > > | OS-EXT-STS:power_state | > NOSTATE | > > | OS-EXT-STS:task_state | > scheduling | > > | OS-EXT-STS:vm_state | > building | > > | OS-SRV-USG:launched_at | None > | > > | OS-SRV-USG:terminated_at | > None | > > | accessIPv4 > | | > > | accessIPv6 > | > | > > | addresses > | | > > | adminPass | t3TAUNwTbuD5 > | > > | config_drive > | | > > | created | > 2018-12-13T05:39:11Z | > > | flavor | my-baremetal-flavor > (84abc368-1695-4387-998c-8b47da1a3a34) | > > | hostId > | | > > | id | > 5231e015-73e9-472f-bb84-bde9bf7e6989 | > > | image | centos7.5-image > (760f4076-4f2d-455b-89b5-6c1248148f70) | > > | key_name | > None | > > | name | > demo1 | > > | progress | > 0 | > > | project_id | > 0b3d8fd6015048e89f4372fb1534900b | > > | properties > | | > > | security_groups | > name='default' | > > | status | > BUILD | > > | updated | > 2018-12-13T05:39:12Z | > > | user_id | > fd244f331bc34066b7a5fae72d518261 | > > | volumes_attached > | | > > > +-------------------------------------+------------------------------------------------------------+ > > [root at openstack-deployment ~]# openstack server list > > > +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ > > | ID | Name | Status | Networks > | Image | Flavor | > > > +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ > > | 5231e015-73e9-472f-bb84-bde9bf7e6989 | demo1 | ACTIVE | hpc=10.0.32.119 > | centos7.5-image | my-baremetal-flavor | > > | 9cc2369f-1951-4bec-bc8b-863fd6cc9983 | test | ACTIVE | hpc=10.0.32.116 > | cirros | m1.tiny | > > > +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ > > > > Any thoughts? > > > > *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: From mfedosin at redhat.com Thu Dec 13 17:16:25 2018 From: mfedosin at redhat.com (Mikhail Fedosin) Date: Thu, 13 Dec 2018 18:16:25 +0100 Subject: [TripleO] SELinux support Message-ID: Hello! One of the most important tasks for this release cycle is to provide full SELinux support in the installed overcloud. Some work in this direction has already been done and in many respects, due to the recent changes, support is almost ready. However, I would like to ask a few questions about what else can be improved. In short, to provide SELinux support the main challenge for us is to ensure that docker can write to the directories protected by SELinux. To allow writing there we change the directory type to container_file_t or its alias svirt_sandbox_file_t. There are two ways to do this: 1. Explicitly - specify the type when creating a directory. # semanage fcontext -at container_file_t "/my_folder(/.*)?" # restorecon -R /my_folder # docker run -v /my_folder:/tmp/my_folder ... 2. Implicitly - use the suffix :z when mounting the partition when creating a container. # docker run -v /my_folder:/tmp/my_folder:z ... Both methods change selinux type of /my_folder to container_file_t and allow to write to the section inside the container. You can read more about this feature in the article https://www.projectatomic.io/blog/2015/06/using-volumes-with-docker-can-cause-problems-with-selinux/ To see how it works, I wrote a small playbook that creates two directories on the host system and modifies their selinux types in two ways: http://paste.openstack.org/show/737234/ Currently there is no consensus in TripleO which of the ways to use. For example, in many cases both methods are used, which adds unnecessary redundancy: https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/cinder-api.yaml#L193-L194 https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/cinder-api.yaml#L218-L219 In some cases there is only :z https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/liquidio-compute-config.yaml#L97 In some, only explicit setting of svirt_sandbox_file_t on the directory https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-proxy.yaml#L219 https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-proxy.yaml#L248 Some services still do not have SELinux support: https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/etcd.yaml https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/zaqar.yaml https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/tacker.yaml Such inconsistency leads to hard to find bugs and makes it difficult to understand the code. An example of such a bug could be this: Here we set selinux type to svirt_sandbox_file_t for /var/log/swift https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-proxy.yaml#L249 And rewrite it back later: https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-storage.yaml#L462 For this reason, I want to come to an agreement on how we will implement SELinux support. In my understanding, the best solution would be to use the suffix :z only. Its advantage is that docker (and podman) checks the directory's selinux type before launching the container and changes it accordingly. In other words, if the type was accidentally changed during the execution of the container, then when it is restarted ":z" will return the type back. In the case of explicit type setting, we get an error. Therefore, I propose to remove the explicit setting svirt_sandbox_file_t and add the suffix ":z" where it is still missing. What do you think? Best regards, Mikhail Fedosin -------------- next part -------------- An HTML attachment was scrubbed... URL: From aspiers at suse.com Thu Dec 13 17:31:29 2018 From: aspiers at suse.com (Adam Spiers) Date: Thu, 13 Dec 2018 17:31:29 +0000 Subject: [all][meta-sig] SIG best practices In-Reply-To: <356a8271-438e-d39c-e83c-fb50f68026b9@openstack.org> References: <20181212122806.kll3gw6w65wz3js3@pacific.linksys.moosehall> <356a8271-438e-d39c-e83c-fb50f68026b9@openstack.org> Message-ID: <20181213173129.wuvgsniig6joko4k@pacific.linksys.moosehall> Thierry Carrez wrote: >I think the bootstrapping phase is completed now, so it's time to move >to phase 2, which is putting some systems in place to make SIGs more >successful. We now have enough information on the success and failures >of early SIGs to debate what we could put in place to help them. I >think this discussion fits right in the goals of the Meta SIG. Makes sense. Should I submit a review to governance-sigs adding some suggested best practices? Here are some ideas I proposed based on what seems to be working fairly well so far for the Self-healing SIG: http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000838.html Having said that, I'm sure that there are other SIGs exhibiting better momentum than the steady but modest progress we've achieved so far, so it's entirely likely that others can come up with more effective best practices than what sprang to my mind. >So far the Meta SIG has been going fully async (no meeting, just ML >discussion threads and reviews of proposed changes to the >openstack/governance-sigs repository). IMHO that seems to have worked pretty well so far. I suppose we could also set up occasional IRC meetings, e.g. every month or two? From akekane at redhat.com Thu Dec 13 17:38:25 2018 From: akekane at redhat.com (Abhishek Kekane) Date: Thu, 13 Dec 2018 23:08:25 +0530 Subject: [glance] functional-py35 job fails due to subunit.praser error Message-ID: Hi All, >From 7th December 2018, all of sudden functional-py35 check job is failing on current master. Earlier this job was failing intermittently (2-3 times from 100). I have tried to dig into the issue and find out that it is failing obly for ubuntu and working fine with Fedora, centos etc. Below are some of the findings: 1. Even if I add failure tests [1] in black-list file every time other tests reported as failure. 2. When I compared failed tests results [1] with passed tests results [2] I have found that passing tests shows 'Pass 741 Skip 7' whereas failing tests shows 'Pass 627 Failure 9 Skip 5' (it does not execute all the tests in case of failure) 3. I have compared version of subunit, oslo.service, oslo.log, tox with failed [3] and passed [4] logs and they are same. 4. I came across a bug in cinder [5] which talks about excessive logs might cause this error and I have tried to ignore the deprecation warning in tox.ini by adding 'PYTHONWARNINGS=ignore::DeprecationWarning' but it still shows DeprecationWarning in the logs. 5. I have tried executing tests by setting '--concurrency' to 1 but still the error persists. 6. Whenver subunit.parser error occurs the tests remains 'inprogress' state and sometimes time-outs. I have no clues so far to tackle this issue, kindly provide your inputs for the same. [1] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4c79eb0/testr_results.html.gz [2] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/39f2c7e/testr_results.html.gz [3] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4c79eb0/job-output.txt.gz [4] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/39f2c7e/job-output.txt.gz [5] https://bugs.launchpad.net/cinder/+bug/1728640 Thanks & Best Regards, Abhishek Kekane -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at openstack.org Thu Dec 13 17:43:37 2018 From: chris at openstack.org (Chris Hoge) Date: Thu, 13 Dec 2018 09:43:37 -0800 Subject: [loci] Release management for LOCI In-Reply-To: <64a34fd9-d31b-5d7d-ae94-053d9bdebbad@openstack.org> References: <3855B170-6E38-4DB9-A91C-9389D16D387F@openstack.org> <64a34fd9-d31b-5d7d-ae94-053d9bdebbad@openstack.org> Message-ID: There is a need for us to work out whether Loci is even appropriate for stable branch development. Over the last week or so the CentOS libvirt update has broken all stable branch builds as it introduced an incompatibility between the stable upper contraints of python-libvirt and libvirt. If we start running stable builds, it might provide a useful gate signal for when stable source builds break against upstream distributions. It's something for the Loci team to think about as we work through refactoring our gate jobs. > On Dec 5, 2018, at 2:31 AM, Thierry Carrez wrote: > > Chris Hoge wrote: >> [...] >> 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. > > Looking at the meeting logs it appears the position has not changed. > I proposed as a result: https://review.openstack.org/622902 > > Cheers, > > -- > Thierry Carrez (ttx) > From mriedemos at gmail.com Thu Dec 13 17:52:52 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 13 Dec 2018 11:52:52 -0600 Subject: Proposal to move cinder backup tests out of the integrated gate In-Reply-To: References: Message-ID: <5a13a953-02de-e49d-f3f5-71c98e2ebdc4@gmail.com> On 12/13/2018 7:27 AM, Chris Dent wrote: > I guess in this case these tests were exposed by their failing, and > it was only once investigating that you realized they weren't truly > integration tests? Have you, Matt, got any ideas on how to find > other non-integration tests that are being treated as integration > which we could move to their own things? De-tangling the spaghetti > is likely to reveal plenty of improvements but also plenty of areas > that need more attention. I haven't done a full audit anytime recent, no. I'm sure there are lots of tempest tests that are single-service, e.g. doing things in just cinder, glance, nova or neutron, which don't require any other services (nova might be the exception in some cases since we need at least glance and neutron for building a server). There was a time a few years ago where QA folk were working on pulling stuff like that out of tempest and moving it into the project trees if their functional testing would cover it, e.g. anything that just required the compute API and DB was a candidate to move into nova functional tests (like flavor and aggregates tests). However, interop tests are based on tempest so there are some tests you just can't remove because they are used by refstack. -- Thanks, Matt From mriedemos at gmail.com Thu Dec 13 17:54:40 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 13 Dec 2018 11:54:40 -0600 Subject: Proposal to move cinder backup tests out of the integrated gate In-Reply-To: <20181213141634.hkiu3of3qbecyydv@barron.net> References: <20181213141634.hkiu3of3qbecyydv@barron.net> Message-ID: On 12/13/2018 8:16 AM, Tom Barron wrote: > FWIW cinder backup by default uses swift as the backup driver and > requires its services, and that's the way it is being run in this job [1]. > > The job could be modified to use e.g. NFS driver and not depend on other > OpenStack services (unless one wanted to be fancy and have Manila > provision the backup share). For the integrated gate, I'm specifically looking for *not fancy* combinations of services. The integrated gate jobs which run on most changes throughout the system should test the most boring scenarios possible and ideally hit as many different services as possible, otherwise more exotic configurations can be run in separate special purpose jobs, much like third party CI. -- Thanks, Matt From mriedemos at gmail.com Thu Dec 13 17:57:49 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 13 Dec 2018 11:57:49 -0600 Subject: Proposal to move cinder backup tests out of the integrated gate In-Reply-To: <69d803fb-b1d2-102c-c9d4-268af5e47ee0@gmail.com> References: <69d803fb-b1d2-102c-c9d4-268af5e47ee0@gmail.com> Message-ID: On 12/13/2018 9:03 AM, Jay Bryant wrote: > Matt, thank you for putting together this information.  I am sorry that > these issues with Cinder are impacting Nova's ability to merge code.  I > don't think we knew that this was having an impact on Nova. FWIW it's not a nova thing, it's everything that uses the integrated-gate jobs (tempest-full). So failures *anywhere* in these jobs will impact our (OpenStack as a whole) ability to get changes through on *all* projects. And this isn't just a cinder issue, nova has provided our fair share of gate breakers, but I like to think that we also try to stay on top of them. -- Thanks, Matt From lbragstad at gmail.com Thu Dec 13 17:58:17 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Thu, 13 Dec 2018 11:58:17 -0600 Subject: [cinder][ops][docs][keystone] policy configuration howto In-Reply-To: <8a1749f7-ed18-971a-82c8-ae7e639cfe91@nemebean.com> References: <8a1749f7-ed18-971a-82c8-ae7e639cfe91@nemebean.com> Message-ID: Thanks for looping keystone into this, Ben. This sounds very similar, and related, to the default roles work keystone implemented in Rocky [0]. TL;DR, keystone ensures the ``member`` and ``reader`` roles are available during ``keystone-manage bootstrap``, which is typically done during installation and sometimes on upgrade. Pre-Rocky, only the ``admin`` role existed in keystone. The idea is to make it easier for other services, like cinder, to rely on these roles by default. As opposed to cinder changing a policy default to something like ``role:reader`` and another service using something like ``role:auditor``, but they both mean the same thing. We want to avoid the case where operators would need to make sure both roles exist in keystone and users have both if they're expected to perform read-only operations from each service. The work keystone did in Rocky made it possible for cinder to start making those assumptions about the existence of roles called ``member`` and ``reader``. As far as testing goes, I remember there being a cinder session in Denver about policy changes, regression, and making sure we can protect against it happening, especially late in the release. Ideally, it would be fantastic to have protection tests in each service that assert the default policies work as expected for protecting APIs. Unfortunately, testing this in its entirety makes it an integration test that requires keystone. Luckily, there are some ways for services to expand protection testing without having that dependency, which falls within the parameters of unit tests. I proposed a couple of changes to cinder that show how to do this [1], and it requires modeling an API request similar to what keystonemiddleware/oslo.context do and ensuring the actual defaults are tested by removing overridden test policies [2] that leave APIs unprotected. We attempted to document a generalized approach to this sort of testing in oslo.policy [3]. [0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html [1] https://review.openstack.org/#/c/602489/ [2] https://review.openstack.org/#/c/609498/ [3] https://docs.openstack.org/oslo.policy/latest/user/usage.html#testing-default-policies On Thu, Dec 13, 2018 at 8:10 AM Ben Nemec wrote: > cc Keystone. It would be interesting to know how this fits in with the > new default roles work. > > On 12/12/18 8:21 PM, Brian Rosmaita wrote: > > At last week's cinder meeting (5 December) we had a discussion about > > policy checks at the database layer. While these checks seem to make it > > difficult to perform some policy configurations, there are too many of > > them to simply remove them without impacting stability given our current > > test coverage (at least that's my feeling). Additionally, it's possible > > to handle the proposed use case (a read-only administrator) without > > making any code changes. So we decided to fix this issue by documenting > > how this could work. > > > > I've got a patch up for the documentation. I've flagged this email for > > cinder people to read for accuracy, operators to read to make sure the > > instructions are clear and detailed, and docs people to read for > > felicity of expression. Please leave comments on the patch: > > > > https://review.openstack.org/#/c/624424/ > > > > cheers, > > brian > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Thu Dec 13 18:01:06 2018 From: cboylan at sapwetik.org (Clark Boylan) Date: Thu, 13 Dec 2018 10:01:06 -0800 Subject: [glance] functional-py35 job fails due to subunit.praser error In-Reply-To: References: Message-ID: <1544724066.400395.1608390504.43FAE644@webmail.messagingengine.com> On Thu, Dec 13, 2018, at 9:38 AM, Abhishek Kekane wrote: > Hi All, > > From 7th December 2018, all of sudden functional-py35 check job is failing > on current master. Earlier this job was failing intermittently (2-3 times > from 100). I have tried to dig into the issue and find out that it is > failing obly for ubuntu and working fine with Fedora, centos etc. Below are > some of the findings: > > 1. Even if I add failure tests [1] in black-list file every time other > tests reported as failure. > 2. When I compared failed tests results [1] with passed tests results [2] I > have found that passing tests shows 'Pass 741 Skip 7' whereas failing tests > shows 'Pass 627 Failure 9 Skip 5' (it does not execute all the tests in > case of failure) > 3. I have compared version of subunit, oslo.service, oslo.log, tox with > failed [3] and passed [4] logs and they are same. > 4. I came across a bug in cinder [5] which talks about excessive logs might > cause this error and I have tried to ignore the deprecation warning in > tox.ini by adding 'PYTHONWARNINGS=ignore::DeprecationWarning' but it still > shows DeprecationWarning in the logs. > 5. I have tried executing tests by setting '--concurrency' to 1 but still > the error persists. > 6. Whenver subunit.parser error occurs the tests remains 'inprogress' state > and sometimes time-outs. > > I have no clues so far to tackle this issue, kindly provide your inputs for > the same. Usually I like to start with the subunit data itself [6]. You'll want to download this file locally, then unzip it. At this point it is in subunitv2 protocol format which is binary and not very human readable. If you install the python subunit package you get a tool called `subunit-2to1` that you can run on this file to get v1 protocol format which is human readable. Doing this we get: tags: worker-3 test: subunit.parser time: 2018-12-13 03:36:22.466478Z failure: subunit.parser [ multipart Content-Type: application/octet-stream Packet data 6 �+p�v�0 Content-Type: text/plain;charset=utf8 Parser Error 31 Short read - got 65530 bytes, wanted 423557 bytes0 ] tags: -worker-3 time: 2018-12-13 03:36:17.372762Z The control process got fewer bytes from worker-3 than it expected. One reason this could happen is the worker-3 test process is crashing before writing all the bytes, but there is at least one test on worker-3 that reports after this parse error so that may not be the cause. Another potential cause is subunit + testr relies on stdout and subunt + stestr relies on tcp socket (I think) and it could be that that stream is being closed by side effects in a test? To narrow this down I would use process of elimination to identify suspect test cases. Basically any test that doesn't show up in that subunit log could be causing this. Then run them in isolation to look for side effect causing errors. You may also want to cross check against several failures which may help narrow it down further. > > > [1] > http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4c79eb0/testr_results.html.gz > [2] > http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/39f2c7e/testr_results.html.gz > [3] > http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4c79eb0/job-output.txt.gz > [4] > http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/39f2c7e/job-output.txt.gz > [5] https://bugs.launchpad.net/cinder/+bug/1728640 [6] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4c79eb0/testrepository.subunit.gz From doug at doughellmann.com Thu Dec 13 18:08:26 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 13 Dec 2018 13:08:26 -0500 Subject: [tc][all] Train Community Goals In-Reply-To: References: Message-ID: Jean-Philippe Evrard writes: > Hello everyone, > > We are looking for volunteers and potential future champions, > particularily to assist in completing prerequisite work for service- > side healthchecks and cleaning up resources when deleting a project. > > Goals are more likely to be successful if there is someone to drive the > work. Having an accurate assessment of the prerequisite work before the > goals even make it into review will help with scope and possibly > finding ways to break the work into more manageable pieces. So far, the > service-side health checks goal requires some oslo work for the > framework that services would use to implement the goal. The service health check goal is an *excellent* example of an area where a relatively small number of people can have a big impact on the entire project. We need someone to spend the time to think about how the health check middleware knows which checks to run, and then to ensure that the middleware is added to all the services' WSGI stacks. I think a small team of 2-3 people could make quick work of this one. > The cleanup of resources when deleting a project goal requires some > anaylsis on what the interface would look like for both os-purge and > an API in each service. I would like to see the folks asking for this one contribute to working out those details, with help from project team experts. > Is anyone interested in driving the prerequisite work for these two > proposals? Ideally, it would be great if we could have the work done by > the middle of January, which gives us enough time to discuss prior to > putting proposals in review. > > This note is specific to the most popular goals from the summit session > in Berlin and prerequisite work for those goals. That said, it's > certainly not too late to propose other ideas or goals for Train. > > Thoughts? > > Lance (lbragstad) and JP (evrardjp) > > > -- Doug From duc.openstack at gmail.com Thu Dec 13 18:58:12 2018 From: duc.openstack at gmail.com (Duc Truong) Date: Thu, 13 Dec 2018 10:58:12 -0800 Subject: [senlin] Senlin Monthly(ish) Newsletter Nov/Dec 2018 Message-ID: HTML: https://dkt26111.wordpress.com/2018/12/13/senlin-monthlyish-newsletter-november-december-2018/ This is the November/December edition of the Senlin monthly(ish) newsletter. The goal of the newsletter is to highlight happenings in the Senlin project. If you have any feedback or questions regarding the contents, please feel free to reach out to me in the #senlin IRC channel. News ---- * The Senlin Project update video and slides from the Berlin summit have been posted: https://www.openstack.org/videos/summits/berlin-2018/senlin-project-update-1 * Autoscaling forum was held at the Berlin Summit. Notes have been captured here: https://etherpad.openstack.org/p/autoscaling-integration-and-feedback * A new autoscaling SIG has been proposed: http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000284.html * The weekly meeting was changed to have alternating times for even and odd weeks to allow for participation from developers in US / Europe: http://eavesdrop.openstack.org/#Senlin_Team_Meeting * This week is an even numbered week, so the meeting will be held on Friday at 530 UTC. Blueprint Status ---------------- * Fail fast locked resource - https://blueprints.launchpad.net/senlin/+spec/fail-fast-locked-resource - Working on documentation and release notes. * Multiple detection modes - https://blueprints.launchpad.net/senlin/+spec/multiple-detection-modes - Working on documentation and release notes. * Fail-fast on cooldown for scaling operations - https://blueprints.launchpad.net/senlin/+spec/scaling-action-acceptance - Completed * Action update - https://blueprints.launchpad.net/senlin/+spec/action-update - Basic functionality has been merged. - Currently working on force action update. Community Goal Status --------------------- * Python 3 - All patches by Python 3 goal champions for zuul migration, documentation and unit test changes have been merged. * Upgrade Checkers - The basic framework for the senlin-status upgrade check has been merged (thanks to rajathere and mriedem). It only has a placeholder check for now. If you like to help out with this task and implement the Senlin specific checks, please let me know. Reviews Needed -------------- * Health policy tempest tests: https://review.openstack.org/#/c/620716/ * Convert requests response from byte to string: https://review.openstack.org/#/c/624248/ * Fix senlin client to work with latest openstacksdk: https://review.openstack.org/#/c/624528/ * Force action update: https://review.openstack.org/#/c/624534/ * Fix senlin-dashboard bug when creating openstacksdk connection (Needs https://review.openstack.org/#/c/624528/ to merge first): https://review.openstack.org/#/c/620767/ * Update health manager to not spawn multiple tasks: https://review.openstack.org/#/c/621504/ From mtreinish at kortar.org Thu Dec 13 20:05:17 2018 From: mtreinish at kortar.org (Matthew Treinish) Date: Thu, 13 Dec 2018 15:05:17 -0500 Subject: [glance] functional-py35 job fails due to subunit.praser error In-Reply-To: <1544724066.400395.1608390504.43FAE644@webmail.messagingengine.com> References: <1544724066.400395.1608390504.43FAE644@webmail.messagingengine.com> Message-ID: <20181213200517.GA32407@sinanju.localdomain> On Thu, Dec 13, 2018 at 10:01:06AM -0800, Clark Boylan wrote: > On Thu, Dec 13, 2018, at 9:38 AM, Abhishek Kekane wrote: > > Hi All, > > > > From 7th December 2018, all of sudden functional-py35 check job is failing > > on current master. Earlier this job was failing intermittently (2-3 times > > from 100). I have tried to dig into the issue and find out that it is > > failing obly for ubuntu and working fine with Fedora, centos etc. Below are > > some of the findings: > > > > 1. Even if I add failure tests [1] in black-list file every time other > > tests reported as failure. > > 2. When I compared failed tests results [1] with passed tests results [2] I > > have found that passing tests shows 'Pass 741 Skip 7' whereas failing tests > > shows 'Pass 627 Failure 9 Skip 5' (it does not execute all the tests in > > case of failure) > > 3. I have compared version of subunit, oslo.service, oslo.log, tox with > > failed [3] and passed [4] logs and they are same. > > 4. I came across a bug in cinder [5] which talks about excessive logs might > > cause this error and I have tried to ignore the deprecation warning in > > tox.ini by adding 'PYTHONWARNINGS=ignore::DeprecationWarning' but it still > > shows DeprecationWarning in the logs. > > 5. I have tried executing tests by setting '--concurrency' to 1 but still > > the error persists. > > 6. Whenver subunit.parser error occurs the tests remains 'inprogress' state > > and sometimes time-outs. > > > > I have no clues so far to tackle this issue, kindly provide your inputs for > > the same. > > Usually I like to start with the subunit data itself [6]. You'll want to download this file locally, then unzip it. At this point it is in subunitv2 protocol format which is binary and not very human readable. If you install the python subunit package you get a tool called `subunit-2to1` that you can run on this file to get v1 protocol format which is human readable. > > Doing this we get: > > tags: worker-3 > test: subunit.parser > time: 2018-12-13 03:36:22.466478Z > failure: subunit.parser [ multipart > Content-Type: application/octet-stream > Packet data > 6 > �+p�v�0 > Content-Type: text/plain;charset=utf8 > Parser Error > 31 > Short read - got 65530 bytes, wanted 423557 bytes0 > ] > tags: -worker-3 > time: 2018-12-13 03:36:17.372762Z > > The control process got fewer bytes from worker-3 than it expected. One reason this could happen is the worker-3 test process is crashing before writing all the bytes, but there is at least one test on worker-3 that reports after this parse error so that may not be the cause. > > Another potential cause is subunit + testr relies on stdout and subunt + stestr relies on tcp socket (I think) and it could be that that stream is being closed by side effects in a test? stestr doesn't use a tcp socket for the subunit streams for the workers, it also uses stdout from subprocess. That code is actually **mostly** unchanged from testr since the actual fork. I have a neglected work in progress branch adding support for trying to use os.pipe an multiprocessing instead of wrapping the subunit.run calls in subprocess here: https://github.com/mtreinish/stestr/commit/ed390dfcea6d7cfe40908ea4dd60d9f27e5ec28c in an effort to try and making the worker schedule more dynamic. But, that hasn't merged, and even if it ever does it'll be opt-in for a while. > > To narrow this down I would use process of elimination to identify suspect test cases. Basically any test that doesn't show up in that subunit log could be causing this. Then run them in isolation to look for side effect causing errors. You may also want to cross check against several failures which may help narrow it down further. I agree with everything clarkb said here and the first step is to look at the actual subunit output to see where things are going wrong. The other thing you ishould try is running the test suite fully with subunit.run by itself in an environment where this is failing to get the subunit stream without stestr consuming it. If that fails then that gives us a good idea where to look. If not we can take that stream as a good example to compare against. This does sound very similar to the bug with the cinder unit tests that we were hitting earlier this year (which we never found a root cause or fix of). That was caused by having very large attachments in the subunit stream. (in the common case these are stdout, stderr, and python logging) When the attachments reached a certain size in the subunit stream the parser would error and cause the job to fail and all remaining tests on that worker to not run and/or had weird follow on failures (it's been a while so I don't remeber the exact behavior) because subunit.run failed. The way we worked around the issue in cinder was to stop writing such large attachments during the test run, which in that case was to stop writing tons of text to stdout during the tests. None of the things described here actually does this, so it might be worth trying to decrease the attachment size. -Matt Treinish > > > > > > > [1] > > http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4c79eb0/testr_results.html.gz > > [2] > > http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/39f2c7e/testr_results.html.gz > > [3] > > http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4c79eb0/job-output.txt.gz > > [4] > > http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/39f2c7e/job-output.txt.gz > > [5] https://bugs.launchpad.net/cinder/+bug/1728640 > > [6] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4c79eb0/testrepository.subunit.gz > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From skaplons at redhat.com Thu Dec 13 20:24:52 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Thu, 13 Dec 2018 21:24:52 +0100 Subject: [glance] functional-py35 job fails due to subunit.praser error In-Reply-To: <20181213200517.GA32407@sinanju.localdomain> References: <1544724066.400395.1608390504.43FAE644@webmail.messagingengine.com> <20181213200517.GA32407@sinanju.localdomain> Message-ID: Hi, We are facing same issue in Neutron now. Since few weeks we are trying to switch our functional job to Python 3 [1] and we had same issues. There was usually run only around 500 tests (in „good” run with py27 it’s more than 1000) and then fail with „subunit.parser error”. Now I limited to disable (almost) all python warnings, change some strings to be logged instead of printed on stdout and I finally managed to run all tests without this error. I think that we will have to live with such workaround for now as we don’t know real root cause of this issue. [1] https://review.openstack.org/#/c/577383/ — Slawek Kaplonski Senior software engineer Red Hat > Wiadomość napisana przez Matthew Treinish w dniu 13.12.2018, o godz. 21:05: > > On Thu, Dec 13, 2018 at 10:01:06AM -0800, Clark Boylan wrote: >> On Thu, Dec 13, 2018, at 9:38 AM, Abhishek Kekane wrote: >>> Hi All, >>> >>> From 7th December 2018, all of sudden functional-py35 check job is failing >>> on current master. Earlier this job was failing intermittently (2-3 times >>> from 100). I have tried to dig into the issue and find out that it is >>> failing obly for ubuntu and working fine with Fedora, centos etc. Below are >>> some of the findings: >>> >>> 1. Even if I add failure tests [1] in black-list file every time other >>> tests reported as failure. >>> 2. When I compared failed tests results [1] with passed tests results [2] I >>> have found that passing tests shows 'Pass 741 Skip 7' whereas failing tests >>> shows 'Pass 627 Failure 9 Skip 5' (it does not execute all the tests in >>> case of failure) >>> 3. I have compared version of subunit, oslo.service, oslo.log, tox with >>> failed [3] and passed [4] logs and they are same. >>> 4. I came across a bug in cinder [5] which talks about excessive logs might >>> cause this error and I have tried to ignore the deprecation warning in >>> tox.ini by adding 'PYTHONWARNINGS=ignore::DeprecationWarning' but it still >>> shows DeprecationWarning in the logs. >>> 5. I have tried executing tests by setting '--concurrency' to 1 but still >>> the error persists. >>> 6. Whenver subunit.parser error occurs the tests remains 'inprogress' state >>> and sometimes time-outs. >>> >>> I have no clues so far to tackle this issue, kindly provide your inputs for >>> the same. >> >> Usually I like to start with the subunit data itself [6]. You'll want to download this file locally, then unzip it. At this point it is in subunitv2 protocol format which is binary and not very human readable. If you install the python subunit package you get a tool called `subunit-2to1` that you can run on this file to get v1 protocol format which is human readable. >> >> Doing this we get: >> >> tags: worker-3 >> test: subunit.parser >> time: 2018-12-13 03:36:22.466478Z >> failure: subunit.parser [ multipart >> Content-Type: application/octet-stream >> Packet data >> 6 >> �+p�v�0 >> Content-Type: text/plain;charset=utf8 >> Parser Error >> 31 >> Short read - got 65530 bytes, wanted 423557 bytes0 >> ] >> tags: -worker-3 >> time: 2018-12-13 03:36:17.372762Z >> >> The control process got fewer bytes from worker-3 than it expected. One reason this could happen is the worker-3 test process is crashing before writing all the bytes, but there is at least one test on worker-3 that reports after this parse error so that may not be the cause. >> >> Another potential cause is subunit + testr relies on stdout and subunt + stestr relies on tcp socket (I think) and it could be that that stream is being closed by side effects in a test? > > stestr doesn't use a tcp socket for the subunit streams for the workers, it > also uses stdout from subprocess. That code is actually **mostly** unchanged > from testr since the actual fork. I have a neglected work in progress branch > adding support for trying to use os.pipe an multiprocessing instead of wrapping > the subunit.run calls in subprocess here: > > https://github.com/mtreinish/stestr/commit/ed390dfcea6d7cfe40908ea4dd60d9f27e5ec28c > > in an effort to try and making the worker schedule more dynamic. But, that > hasn't merged, and even if it ever does it'll be opt-in for a while. > >> >> To narrow this down I would use process of elimination to identify suspect test cases. Basically any test that doesn't show up in that subunit log could be causing this. Then run them in isolation to look for side effect causing errors. You may also want to cross check against several failures which may help narrow it down further. > > I agree with everything clarkb said here and the first step is to look at the > actual subunit output to see where things are going wrong. The other thing you > ishould try is running the test suite fully with subunit.run by itself in an > environment where this is failing to get the subunit stream without stestr > consuming it. If that fails then that gives us a good idea where to look. If > not we can take that stream as a good example to compare against. > > This does sound very similar to the bug with the cinder unit tests that we > were hitting earlier this year (which we never found a root cause or fix of). > That was caused by having very large attachments in the subunit stream. (in the > common case these are stdout, stderr, and python logging) When the attachments > reached a certain size in the subunit stream the parser would error and cause > the job to fail and all remaining tests on that worker to not run and/or had > weird follow on failures (it's been a while so I don't remeber the exact > behavior) because subunit.run failed. The way we worked around the issue in > cinder was to stop writing such large attachments during the test run, which in > that case was to stop writing tons of text to stdout during the tests. None of > the things described here actually does this, so it might be worth trying to > decrease the attachment size. > > -Matt Treinish > >> >>> >>> >>> [1] >>> http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4c79eb0/testr_results.html.gz >>> [2] >>> http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/39f2c7e/testr_results.html.gz >>> [3] >>> http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4c79eb0/job-output.txt.gz >>> [4] >>> http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/39f2c7e/job-output.txt.gz >>> [5] https://bugs.launchpad.net/cinder/+bug/1728640 >> >> [6] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4c79eb0/testrepository.subunit.gz From mriedemos at gmail.com Thu Dec 13 20:31:24 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 13 Dec 2018 14:31:24 -0600 Subject: [glance] functional-py35 job fails due to subunit.praser error In-Reply-To: References: Message-ID: <9fbbbe41-982b-0b34-4e58-7e3150be90b3@gmail.com> On 12/13/2018 11:38 AM, Abhishek Kekane wrote: > From 7th December 2018, all of sudden functional-py35 check job is > failing on current master. Earlier this job was failing intermittently > (2-3 times from 100). I have tried to dig into the issue and find out > that it is failing obly for ubuntu and working fine with Fedora, centos > etc. Below are some of the findings: Might be related to what we're debugging in https://bugs.launchpad.net/openstack-gate/+bug/1808063 - jokke noticed something added to oslo.policy 1.43.1 which uses a deepcopy might be getting messed up with the nested proxy objects in glance. oslo.policy 1.43.1 got into upper-constraints on Dec 7: https://github.com/openstack/requirements/commit/bf300c99037e0e57229e20ca7f89517d1695d6b5 -- Thanks, Matt From senrique at redhat.com Thu Dec 13 22:17:07 2018 From: senrique at redhat.com (Sofia Enriquez) Date: Thu, 13 Dec 2018 19:17:07 -0300 Subject: [cinder] [tempest] Ideas for test cases In-Reply-To: <16792b46bae.b1b7956b187049.263161708726828786@ghanshyammann.com> References: <16792b46bae.b1b7956b187049.263161708726828786@ghanshyammann.com> Message-ID: Hi Gmann, thanks for checking my patch! I've already checked the current test cases in Tempest and I think my tests cover new tests cases. I'd like to extend the current ones and reuse the code, but I'd like to update them inside the cinder-tempest-plugin repository. I wonder if anyone would like to tell me some uses cases that I could forget. Thanks, Sofi On Sun, Dec 9, 2018 at 8:25 AM Ghanshyam Mann wrote: > Thanks Sofia, > > There are few existing test cases in Tempest which cover retype and > migration cases. Check if that cover your cases or you can extend those > where you can reuse the code. > > - > https://github.com/openstack/tempest/blob/e6c330892fbc8ae790384d554dd6d5c2668d8d24/tempest/api/volume/admin/test_volume_retype.py > - > https://github.com/openstack/tempest/blob/837726a9ede64e33d0def018da24e146dd6b5af3/tempest/scenario/test_volume_migrate_attached.py > > -gmann > > > ---- On Sat, 08 Dec 2018 02:55:10 +0900 Sofia Enriquez < > senrique at redhat.com> wrote ---- > > Hello cinder guys, > > > > I'm working on increasing the coverage of Cinder Tempest [1]. > > > > Since I'm relatively new using cinder retype+migrate functionality, I'm > looking for possible ideas of test cases. > > Thanks,Sofi > > > > [1]: https://review.openstack.org/#/c/614022/ > > > > -- > > Sofia Enriquez > > Associate Software Engineer > > > > > > > > -- 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 akekane at redhat.com Thu Dec 13 17:30:47 2018 From: akekane at redhat.com (Abhishek Kekane) Date: Thu, 13 Dec 2018 23:00:47 +0530 Subject: [glance]functional-py35 fails due to subunit.praser error Message-ID: [glance]functional-py35 fails due to subunit.praser error Hi All, >From 7th December 2018, all of sudden functional-py35 check job is failing on current master. Earlier this job was failing intermittently (2-3 times from 100). I have tried to dig into the issue and find out that it is failing obly for ubuntu and working fine with Fedora, centos etc. Below are some of the findings: 1. Even if I add failure tests [1] in black-list file every time other tests reported as failure. 2. When I compared failed tests results [1] with passed tests results [2] I have found that passing tests shows 'Pass 741 Skip 7' whereas failing tests shows 'Pass 627 Failure 9 Skip 5' (it does not execute all the tests in case of failure) 3. I have compared version of subunit, oslo.service, oslo.log, tox with failed [3] and passed [4] logs and they are same. 4. I came across a bug in cinder [5] which talks about excessive logs might cause this error and I have tried to ignore the deprecation warning in tox.ini by adding 'PYTHONWARNINGS=ignore::DeprecationWarning' but it still shows DeprecationWarning in the logs. 5. I have tried executing tests by setting '--concurrency' to 1 but still the error persists. 6. Whenver subunit.parser error occurs the tests remains 'inprogress' state and sometimes time-outs. I have no clues so far to tackle this issue, kindly provide your inputs for the same. [1] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4c79eb0/testr_results.html.gz [2] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/39f2c7e/testr_results.html.gz [3] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4c79eb0/job-output.txt.gz [4] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/39f2c7e/job-output.txt.gz [5] https://bugs.launchpad.net/cinder/+bug/1728640 Thanks & Best Regards, Abhishek Kekane -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdacrema at enter.eu Thu Dec 13 17:38:27 2018 From: mdacrema at enter.eu (Matteo Dacrema) Date: Thu, 13 Dec 2018 18:38:27 +0100 Subject: Neutron performance Ocata Message-ID: <0B869824-9A47-43F9-995B-BE31406241C6@enter.eu> Hi all, I’ve recently upgraded Openstack from Mitaka to Ocata and now I’m facing an increased latency in instance creation. Before the upgrade I was able to launch sequentially 400 VMs in 5 minutes and now I need at least 15 minutes. Attached the script I use to measure timings. Here you can find the comparison between Mitaka and Ocata. I also noticed that in Ocata DHCP agent is slower and sometimes when I launch more than 30 VMs sequentially some of them doesn’t took an address. Time of instance creation increase with the number of ports in the network. https://docs.google.com/spreadsheets/d/1eHjRxkw_5BmJ2p0rBJg9suGKmu_1YrSY05f50gKJxbE/edit?usp=sharing I’ve enabled the osprofiler inside nova and neutron api and attached you can see that the most of the time is spent on wsgi component of neutron. The time is spent on getting port list. I’ve also verified with cli listing only ports and I can confirm is a port list related issue. I’m trying to profile the neutron-server with cProfile but I’ve some problems with multi-threading tracing. Does anyone have faced this issue? Thank you! Regards Matteo -------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: launch.py Type: text/x-python-script Size: 1419 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From torin.woltjer at granddial.com Thu Dec 13 22:36:57 2018 From: torin.woltjer at granddial.com (Torin Woltjer) Date: Thu, 13 Dec 2018 22:36:57 GMT Subject: Nova live migration fails - InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility. Message-ID: Having issues getting live migrations to functions between two compute nodes. One is an Opteron G4 and the other is an Opteron G5. I can migrate from the G4 to the G5 just fine. When I try to migrate an instance from the G5 node to the G4 node I get an error message: InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility. This is despite having the following setting in my /etc/nova/nova.conf on the G5 machine. [libvirt] cpu_mode = custom cpu_model = Opteron_G4 Is this not the setting I'm looking for? What can I do to make this work? Torin Woltjer Grand Dial Communications - A ZK Tech Inc. Company 616.776.1066 ext. 2006 www.granddial.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Thu Dec 13 23:31:02 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 13 Dec 2018 17:31:02 -0600 Subject: Nova live migration fails - InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility. In-Reply-To: References: Message-ID: On 12/13/2018 4:36 PM, Torin Woltjer wrote: > Having issues getting live migrations to functions between two compute > nodes. > One is an Opteron G4 and the other is an Opteron G5. I can migrate from > the G4 to the G5 just fine. When I try to migrate an instance from the > G5 node to the G4 node I get an error message: > InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility. > This is despite having the following setting in my /etc/nova/nova.conf > on the G5 machine. > > [libvirt] > cpu_mode = custom > cpu_model = Opteron_G4 > > Is this not the setting I'm looking for? What can I do to make this work? This summit talk from Kashyap might be helpful: https://www.openstack.org/videos/summits/berlin-2018/effective-virtual-cpu-configuration-in-nova -- Thanks, Matt From emccormick at cirrusseven.com Thu Dec 13 23:48:10 2018 From: emccormick at cirrusseven.com (Erik McCormick) Date: Thu, 13 Dec 2018 18:48:10 -0500 Subject: Nova live migration fails - InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility. In-Reply-To: References: Message-ID: On Thu, Dec 13, 2018 at 5:37 PM Torin Woltjer wrote: > > Having issues getting live migrations to functions between two compute nodes. > One is an Opteron G4 and the other is an Opteron G5. I can migrate from the G4 to the G5 just fine. When I try to migrate an instance from the G5 node to the G4 node I get an error message: > InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility. > This is despite having the following setting in my /etc/nova/nova.conf on the G5 machine. > > [libvirt] > cpu_mode = custom > cpu_model = Opteron_G4 > > Is this not the setting I'm looking for? What can I do to make this work? > Generally, yes this should do the trick. So long as the lowest common set of features is used, then you should be able to live migrate. You can do a diff on the feature set of each host CPU with: virsh capabilities Did you create the instances you are trying to migrate after you applied the setting? If not, do a cold migrate and then try the live one again. Did you apply the setting on both computes? I know this maybe is obvious, but I've seen people put it on the controllers and not the computes and wonder why it wasn't working. Doesn't hurt to ask :). > > Torin Woltjer > > Grand Dial Communications - A ZK Tech Inc. Company > > 616.776.1066 ext. 2006 > www.granddial.com -Erik From hjensas at redhat.com Thu Dec 13 23:49:00 2018 From: hjensas at redhat.com (Harald =?ISO-8859-1?Q?Jens=E5s?=) Date: Fri, 14 Dec 2018 00:49:00 +0100 Subject: [TripleO] - Blueprint - tripleo-routed-networks-templates Message-ID: <12c2644b82acbf57828997e6f7681c82f7c75993.camel@redhat.com> Hello TripleO Team, I have been working on the tripleo-routed-networks-templates blueprint for some time. There is a number of patches in need of reviews. Link # https://review.openstack.org/#/q/topic:bp/tripleo-routed-networks-templates+(status:open+OR+status:merged ) Most of the patches are based on top of eachoter starting with: - https://review.openstack.org/582180 One of the hurdles with all this is having an environment with a network infrastructure to run tests, routers, dhcp-relay server etc. For some time I have been collaborating with Ben Nemec on routed- networks support in OVB. And it is working really well! \o/ If anyone wants to try this out, I have set up a github repository[1] with some scripts to set up the OVB environment in rdocloud. The ansible playbook in that repo will Deploy the undercloud (including all the THT patches), build images and import the baremetal nodes. Overcloud environment files, templates and a deploy script is there in the repo as well. For the overcloud there are two set's of templates and accompanying deploy command in the git repo. The deploy command and templates with suffix '_pre_update' will deploy 1 Controller and 1 Compute node without subnets, a single leaf. By deploying using these first, and then deploying the using the templates and deploy command without suffix we can verify that the existing non-*neutron routed networks* is migrated to *neutron routed networks* with multiple subnets with network segment association during stack update. The commands to run Tempest is also in the Readme. Today's `tempest run --smoke` results: ====== Totals ====== Ran: 99 tests in 486.0000 sec. - Passed: 90 - Skipped: 9 - Expected Fail: 0 - Unexpected Success: 0 - Failed: 0 Sum of execute time for each test: 1028.2578 sec. I hope that we can merge these changes soon, so that they are available in early for downstream QA. Thank you! -- Cheers, Harald [1] https://github.com/hjensas/ooo-bp-tripleo-routed-networks-templates-testing From saphi070 at gmail.com Fri Dec 14 00:08:45 2018 From: saphi070 at gmail.com (Sa Pham) Date: Fri, 14 Dec 2018 07:08:45 +0700 Subject: Neutron performance Ocata In-Reply-To: <0B869824-9A47-43F9-995B-BE31406241C6@enter.eu> References: <0B869824-9A47-43F9-995B-BE31406241C6@enter.eu> Message-ID: Hi, I saw it. In recently release, Neutron is too slow Sa Pham Dang Cloud RnD Team - VCCLOUD Phone: 0986849582 Skype: great_bn > On Dec 14, 2018, at 12:38 AM, Matteo Dacrema wrote: > > Hi all, > > I’ve recently upgraded Openstack from Mitaka to Ocata and now I’m facing an increased latency in instance creation. > Before the upgrade I was able to launch sequentially 400 VMs in 5 minutes and now I need at least 15 minutes. Attached the script I use to measure timings. > > Here you can find the comparison between Mitaka and Ocata. I also noticed that in Ocata DHCP agent is slower and sometimes when I launch more than 30 VMs sequentially some of them doesn’t took an address. > Time of instance creation increase with the number of ports in the network. > > https://docs.google.com/spreadsheets/d/1eHjRxkw_5BmJ2p0rBJg9suGKmu_1YrSY05f50gKJxbE/edit?usp=sharing > > I’ve enabled the osprofiler inside nova and neutron api and attached you can see that the most of the time is spent on wsgi component of neutron. > The time is spent on getting port list. I’ve also verified with cli listing only ports and I can confirm is a port list related issue. > > I’m trying to profile the neutron-server with cProfile but I’ve some problems with multi-threading tracing. > > Does anyone have faced this issue? > > Thank you! > > Regards > Matteo > > > > > -------------------------------------------- > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Fri Dec 14 00:46:23 2018 From: cboylan at sapwetik.org (Clark Boylan) Date: Thu, 13 Dec 2018 16:46:23 -0800 Subject: can't login to a compute node deployed using ironic In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017BAF8E9F@MXDB2.ad.garvan.unsw.edu.au> References: <9D8A2486E35F0941A60430473E29F15B017BAF8E9F@MXDB2.ad.garvan.unsw.edu.au> Message-ID: <1544748383.508399.1608710240.111D3DF4@webmail.messagingengine.com> On Wed, Dec 12, 2018, at 10:18 PM, Manuel Sopena Ballesteros wrote: > Dear Openstack user group, > > I am playing with Ironic and have a very stupid question... > > For some reason I can't login to the server after deployment. Server > status is ACTIVE and I am using the adminPass provided by openstack . > > The way I connect is through server console through the IPMI console (not ssh). > > [root at openstack-deployment ~]# openstack server create --image 760f4076- > 4f2d-455b-89b5-6c1248148f70 --flavor my-baremetal-flavor --network hpc > demo1 > +------------------------------------- > +------------------------------------------------------------+ > | Field | Value > | > +------------------------------------- > +------------------------------------------------------------+ > | OS-DCF:diskConfig | MANUAL > | > | OS-EXT-AZ:availability_zone | > | > | OS-EXT-SRV-ATTR:host | None > | > | OS-EXT-SRV-ATTR:hypervisor_hostname | None > | > | OS-EXT-SRV-ATTR:instance_name | > | > | OS-EXT-STS:power_state | NOSTATE > | > | OS-EXT-STS:task_state | scheduling > | > | OS-EXT-STS:vm_state | building > | > | OS-SRV-USG:launched_at | None > | > | OS-SRV-USG:terminated_at | None > | > | accessIPv4 | > | > | accessIPv6 | > | > | addresses | > | > | adminPass | t3TAUNwTbuD5 > | > | config_drive | > | > | created | 2018-12-13T05:39:11Z > | > | flavor | my-baremetal-flavor (84abc368- > 1695-4387-998c-8b47da1a3a34) | > | hostId | > | > | id | 5231e015-73e9-472f-bb84- > bde9bf7e6989 | > | image | centos7.5-image (760f4076- > 4f2d-455b-89b5-6c1248148f70) | > | key_name | None > | > | name | demo1 > | > | progress | 0 > | > | project_id | 0b3d8fd6015048e89f4372fb1534900b > | > | properties | > | > | security_groups | name='default' > | > | status | BUILD > | > | updated | 2018-12-13T05:39:12Z > | > | user_id | fd244f331bc34066b7a5fae72d518261 > | > | volumes_attached | > | > +------------------------------------- > +------------------------------------------------------------+ > [root at openstack-deployment ~]# openstack server list > +--------------------------------------+-------+-------- > +-----------------+-----------------+---------------------+ > | ID | Name | Status | Networks > | Image | Flavor | > +--------------------------------------+-------+-------- > +-----------------+-----------------+---------------------+ > | 5231e015-73e9-472f-bb84-bde9bf7e6989 | demo1 | ACTIVE | > hpc=10.0.32.119 | centos7.5-image | my-baremetal-flavor | > | 9cc2369f-1951-4bec-bc8b-863fd6cc9983 | test | ACTIVE | > hpc=10.0.32.116 | cirros | m1.tiny | > +--------------------------------------+-------+-------- > +-----------------+-----------------+---------------------+ > > Any thoughts? I believe that the admin password must be set on first boot by a tool like cloud-init. I would double check that your image has cloud-init installed and configured to set the root user password. It is possible that it may be configuring a non root user (like 'centos') isntead of root too. If that all checks out I would look at your servers console log (hopefully that is working) as cloud-init should log the changes it is making and hopefully that give you a clue as to what is happening. Finally you could update the image to bake in a user and password or ssh key and log in that way then debug what is going on from there. Might even want to start here depending on how easy it is for you to modify the image. Clark From niraj.singh at nttdata.com Fri Dec 14 02:28:19 2018 From: niraj.singh at nttdata.com (Singh, Niraj) Date: Fri, 14 Dec 2018 02:28:19 +0000 Subject: [tosca-parser] Need new release of tosca-parser library In-Reply-To: References: <20181212023950.GC6373@thor.bakeyournoodle.com> <6F5CE673-171B-436B-8D08-414494A9A60C@haddleton.net>, Message-ID: Hi Bob, Verified the info about the latest tosco-parser release 1.3.0, I can see my changes in the commits [1]. But after downloading the zip file under release 1.3.0, I didn't found my changes that was in [2]. Please verify. [1] https://github.com/openstack/tosca-parser/compare/1.3.0...master [2] https://review.openstack.org/#/c/612973/ ________________________________ From: Rico Lin Sent: 12 December 2018 11:01 To: bobh at haddleton.net Cc: Tony Breeds; Singh, Niraj; openstack-discuss at lists.openstack.org Subject: Re: [tosca-parser] Need new release of tosca-parser library On Wed, Dec 12, 2018 at 11:47 AM Bob Haddleton > wrote: I will submit this patch tomorrow morning (US/Central) I will help to give my aproval just to honor the project release workflow Bob > On Dec 11, 2018, at 20:39, Tony Breeds > wrote: > >> On Wed, Dec 12, 2018 at 02:30:46AM +0000, Singh, Niraj wrote: >> Hi Team, >> >> >> Heat-translator patch [1] is dependent on tosca-parser changes that is already merged in patch [2]. >> >> >> We need new tosco-parser release so that we can add the new release version in heat-translator and proceed further with the review. > > This can be done via the openstack/releases repo. We'll need either the > heat PTL or release team liaison to approve the patch if neither of them > can propose the change. > > Yours Tony. -- May The Force of OpenStack Be With You, Rico Lin irc: ricolin Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. -------------- next part -------------- An HTML attachment was scrubbed... URL: From iwienand at redhat.com Fri Dec 14 03:42:59 2018 From: iwienand at redhat.com (Ian Wienand) Date: Fri, 14 Dec 2018 14:42:59 +1100 Subject: [dev][openstacksdk] openstacksdk and dogpile 0.7.0+ cache errors Message-ID: <20181214034259.GA16789@fedora19.localdomain> Hi, Just a heads up that the latest version of dogpile (0.7.0 onwards) have become incompatible with openstacksdk. This is causing a few issues for jobs. As usual, it's a little complex :) The error you will see is something like user_func.set = set_ AttributeError: 'method' object has no attribute 'set' The following are related: https://review.openstack.org/624697 : requirements change to pin https://review.openstack.org/624485 : openstacksdk pin https://review.openstack.org/624855 : fixes a nodepool job that openstacksdk depends on (note 624485 turns the job non-voting to break the circular dependency). The issue is being tracked in: https://storyboard.openstack.org/#!/story/2004605 : related story https://github.com/sqlalchemy/dogpile.cache/issues/140 : upstream github issue Thanks, -i From zhipengh512 at gmail.com Fri Dec 14 03:44:32 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Thu, 13 Dec 2018 19:44:32 -0800 Subject: [cyborg][ResMgmt]Cyborg Ecosystem Building Planning For 2019 Message-ID: Hi team, After the wrapping up of KubeCon this week, I have some initial thoughts on eco building for next year 1. Kubernetes We will be working on a proposal for heterogeneous resource support in k8s. This is not a new idea and we have been floating the idea around for almost a year, and based upon the discussion we had through the week, it seems a good time to do it now. Detailed proposal will come out early next year I hope for public review and discussion. To have k8s integration out is on the direction of having more form of compute with acceleration support. We will also kickstart the resource management sig activity which has been earlier this year (via email mostly) 2. RISC-V I would propose we start to talk and work with the FireSIM team to try out how could we better support RISC-V arch from a cloud perspective. 3. Edge I'm interested in have raspberry pi support with our driver gathering info from libgpio and other interfaces. It would be great to have ARM embedded devs to join the discussion :) Look forward to feedbacks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akekane at redhat.com Fri Dec 14 04:23:50 2018 From: akekane at redhat.com (Abhishek Kekane) Date: Fri, 14 Dec 2018 09:53:50 +0530 Subject: [glance] functional-py35 job fails due to subunit.praser error In-Reply-To: <9fbbbe41-982b-0b34-4e58-7e3150be90b3@gmail.com> References: <9fbbbe41-982b-0b34-4e58-7e3150be90b3@gmail.com> Message-ID: I have manually removed oslo.policy 1.43.1 and installed 1.43.0 and ran tests and those are passing without any issues. Jokke has submitted a patch [1] where he has modified requirements.txt to not install oslo.policy 1.43.1 but it still installs the same version as glance's requirements.txt is not considered while installing dependencies whereas it considers upper-constraints.txt from the openstack/requirements. [1] https://review.openstack.org/#/c/625085/1/requirements.txt Thanks & Best Regards, Abhishek Kekane On Fri, Dec 14, 2018 at 2:05 AM Matt Riedemann wrote: > On 12/13/2018 11:38 AM, Abhishek Kekane wrote: > > From 7th December 2018, all of sudden functional-py35 check job is > > failing on current master. Earlier this job was failing intermittently > > (2-3 times from 100). I have tried to dig into the issue and find out > > that it is failing obly for ubuntu and working fine with Fedora, centos > > etc. Below are some of the findings: > > Might be related to what we're debugging in > https://bugs.launchpad.net/openstack-gate/+bug/1808063 - jokke noticed > something added to oslo.policy 1.43.1 which uses a deepcopy might be > getting messed up with the nested proxy objects in glance. oslo.policy > 1.43.1 got into upper-constraints on Dec 7: > > > https://github.com/openstack/requirements/commit/bf300c99037e0e57229e20ca7f89517d1695d6b5 > > -- > > Thanks, > > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Fri Dec 14 06:25:42 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Fri, 14 Dec 2018 07:25:42 +0100 Subject: Queens magnum external network Message-ID: Hi All, I am testing magnum on Centos openstack queens. I saw magnum external network must speak with some controller services ....for example 5000 for keystone and 8004 for heat . Are there any other port to open for external network? Regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Fri Dec 14 06:33:04 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Fri, 14 Dec 2018 07:33:04 +0100 Subject: Fwd: openstack queens magnum error In-Reply-To: <3d030a47-766d-d32b-2fb3-3bc6e0beb10e@binero.se> References: <50328a78-8f24-e93d-78b5-24e02de8a89c@catalyst.net.nz> <3d030a47-766d-d32b-2fb3-3bc6e0beb10e@binero.se> Message-ID: Hello Tobias, swarm-mode solved etcd issue but the swarm stack Do es not terminate. Please: Which ports must be opened between external network used by magnum and controllers? Thanks ignazio Il giorno Gio 13 Dic 2018 09:54 Tobias Urdin ha scritto: > Hello, > What swam driver are you using? > > We use the following image Fedora-Atomic-27-20180419.0.x86_64.qcow2 and to > get Kubernetes and Swarm-mode drivers working we use latest stable/rocky > release which should > include the patches that fixes some issues. > > Make sure you got correct COE set on the swarm cluster template. > > $openstack coe cluster template show docker-swarm > | docker_storage_driver | devicemapper | > | network_driver | docker > | coe | swarm-mode | > > These fixes should be released in latest stable/rocky: > > https://review.openstack.org/#/c/598179/ > https://review.openstack.org/#/c/607089/ > https://review.openstack.org/#/c/611097 > > Never got the "swarm" driver to work, you should use "swarm-mode" instead > which uses native Docker clustering without etcd. > > For kubernetes there was no issues when using Fedora Atomic 27 but atomic > 28 has a lot of changes so it cannot install etcd as a system service > so can't use 28 until that is fixed, maybe fixed in master though. > > Best regards > > On 12/13/2018 06:39 AM, Ignazio Cassano wrote: > > Ps. > Solving connection problem between master node and controller node allows > stack to complete successfully. But remains the problem with the etcd > package. > Regards > Ignazio > > > Il giorno Mer 12 Dic 2018 23:55 Feilong Wang ha > scritto: > >> Seems your master node can't talk to your keystone, can you confirm that? >> >> >> >> On 13/12/18 11:08 AM, Ignazio Cassano wrote: >> >> Hello Feilong, this forwarding contains logs. >> Thanks >> >> ---------- Forwarded message --------- >> From: Ignazio Cassano >> Date: Mer 12 Dic 2018 10:06 >> Subject: openstack queens magnum error >> To: OpenStack Operators >> >> >> Hello Everyone, >> >> I installed queens on centos with magnum and I am trying to create a >> swarm cluster with one muster and one node. The image I used is >> fedora-atomic 27 update 04 >> >> The stack generated end with an error and magnum conductor reports: >> ec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.304 >> 17964 WARNING magnum.drivers.heat.template_def >> [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have >> output_key api_address >> Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.305 >> 17964 WARNING magnum.drivers.heat.template_def >> [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have >> output_key swarm_masters >> Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 >> 17964 WARNING magnum.drivers.heat.template_def >> [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have >> output_key swarm_nodes >> Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 >> 17964 WARNING magnum.drivers.heat.template_def >> [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have >> output_key discovery_url >> Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.317 >> 17964 ERROR magnum.drivers.heat.driver >> [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] Cluster error, stack >> status: CREATE_FAILED, stack_id: 306bd83a-7878-4d94-8ed0-1d297eec9768, >> reason: Resource CREATE failed: WaitConditionFailure: >> resources.swarm_nodes.resources[0].resources.node_wait_condition: >> swarm-agent service failed to start. >> >> >> >> I connected to the master node for verifyng if swarm agent is running. >> In the cloud init log I found: >> requests.exceptions.ConnectionError: >> HTTPConnectionPool(host='10.102.184.190', port=5000): Max retries exceeded >> with url: /v3//auth/tokens (Caused by >> NewConnectionError('> 0x7f0814d4d250>: Failed to establish a new connection: [Errno 110] >> Connection timed out',)) >> Cloud-init v. 0.7.9 running 'modules:final' at Wed, 12 Dec 2018 08:45:31 >> +0000. Up 55.54 seconds. >> 2018-12-12 08:47:45,858 - util.py[WARNING]: Failed running >> /var/lib/cloud/instance/scripts/part-005 [1] >> /var/lib/cloud/instance/scripts/part-006: line 13: /etc/etcd/etcd.conf: >> No such file or directory >> /var/lib/cloud/instance/scripts/part-006: line 26: /etc/etcd/etcd.conf: >> No such file or directory >> /var/lib/cloud/instance/scripts/part-006: line 38: /etc/etcd/etcd.conf: >> No such file or directory >> 2018-12-12 08:47:45,870 - util.py[WARNING]: Failed running >> /var/lib/cloud/instance/scripts/part-006 [1] >> Configuring docker network ... >> Configuring docker network service ... >> Removed >> /etc/systemd/system/multi-user.target.wants/docker-storage-setup.service. >> New size given (1280 extents) not larger than existing size (4863 >> extents) >> ERROR: There is not enough free space in volume group atomicos to create >> data volume of size MIN_DATA_SIZE=2G. >> 2018-12-12 08:47:46,206 - util.py[WARNING]: Failed running >> /var/lib/cloud/instance/scripts/part-010 [1] >> + systemctl stop docker >> + echo 'starting services' >> starting services >> + systemctl daemon-reload >> + for service in etcd docker.socket docker swarm-manager >> + echo 'activating service etcd' >> activating service etcd >> + systemctl enable etcd >> Failed to enable unit: Unit file etcd.service does not exist. >> + systemctl --no-block start etcd >> Failed to start etcd.service: Unit etcd.service not found. >> + for service in etcd docker.socket docker swarm-manager >> + echo 'activating service docker.socket' >> activating service docker.socket >> + systemctl enable docker.socket >> >> >> 1) Seems etcd service is not installed , >> >> 2) the instance required to contact controller on port 5000 (is it >> correct ?) >> >> >> Please help me. >> >> Regards >> Ignazio >> >> >> -- >> 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: From iurygregory at gmail.com Fri Dec 14 08:55:54 2018 From: iurygregory at gmail.com (Iury Gregory) Date: Fri, 14 Dec 2018 09:55:54 +0100 Subject: can't login to baremetal deploid with ironic In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017BAF9187@MXDB2.ad.garvan.unsw.edu.au> References: <9D8A2486E35F0941A60430473E29F15B017BAF8E62@MXDB2.ad.garvan.unsw.edu.au> <9D8A2486E35F0941A60430473E29F15B017BAF9187@MXDB2.ad.garvan.unsw.edu.au> Message-ID: I'm glad it worked =) Em sex, 14 de dez de 2018 às 01:11, Manuel Sopena Ballesteros < manuel.sb at garvan.org.au> escreveu: > Hi Lury, > > > > Yes, I can login to cirros using the default credentials cirros/gocubsgo > > > > Manuel > > > > *From:* Iury Gregory [mailto:iurygregory at gmail.com] > *Sent:* Friday, December 14, 2018 12:26 AM > *To:* Manuel Sopena Ballesteros > *Cc:* openstack at lists.openstack.org > *Subject:* Re: can't login to baremetal deploid with ironic > > > > Hello Manuel, > > > > Did you try the default password for cirros images? > https://docs.openstack.org/image-guide/obtain-images.html#cirros-test > > > > > > Em qui, 13 de dez de 2018 às 14:05, Manuel Sopena Ballesteros < > manuel.sb at garvan.org.au> escreveu: > > Dear Openstack user group, > > > > I am playing with Ironic and have a very stupid question… > > > > For some reason I can’t login to the server after deployment. Server > status is ACTIVE and I am using the adminPass provided by openstack . > > > > The way I connect is through server console through the IPMI console (not > ssh). > > > > [root at openstack-deployment ~]# openstack server create --image > 760f4076-4f2d-455b-89b5-6c1248148f70 --flavor my-baremetal-flavor --network > hpc demo1 > > > +-------------------------------------+------------------------------------------------------------+ > > | Field | > Value | > > > +-------------------------------------+------------------------------------------------------------+ > > | OS-DCF:diskConfig | > MANUAL | > > | OS-EXT-AZ:availability_zone > | | > > | OS-EXT-SRV-ATTR:host | > None | > > | OS-EXT-SRV-ATTR:hypervisor_hostname | None > | > > | OS-EXT-SRV-ATTR:instance_name > | | > > | OS-EXT-STS:power_state | > NOSTATE | > > | OS-EXT-STS:task_state | > scheduling | > > | OS-EXT-STS:vm_state | > building | > > | OS-SRV-USG:launched_at | None > | > > | OS-SRV-USG:terminated_at | > None | > > | accessIPv4 > | | > > | accessIPv6 > | > | > > | addresses > | | > > | adminPass | t3TAUNwTbuD5 > | > > | config_drive > | | > > | created | > 2018-12-13T05:39:11Z | > > | flavor | my-baremetal-flavor > (84abc368-1695-4387-998c-8b47da1a3a34) | > > | hostId > | | > > | id | > 5231e015-73e9-472f-bb84-bde9bf7e6989 | > > | image | centos7.5-image > (760f4076-4f2d-455b-89b5-6c1248148f70) | > > | key_name | > None | > > | name | > demo1 | > > | progress | > 0 | > > | project_id | > 0b3d8fd6015048e89f4372fb1534900b | > > | properties > | | > > | security_groups | > name='default' | > > | status | > BUILD | > > | updated | > 2018-12-13T05:39:12Z | > > | user_id | > fd244f331bc34066b7a5fae72d518261 | > > | volumes_attached > | | > > > +-------------------------------------+------------------------------------------------------------+ > > [root at openstack-deployment ~]# openstack server list > > > +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ > > | ID | Name | Status | Networks > | Image | Flavor | > > > +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ > > | 5231e015-73e9-472f-bb84-bde9bf7e6989 | demo1 | ACTIVE | hpc=10.0.32.119 > | centos7.5-image | my-baremetal-flavor | > > | 9cc2369f-1951-4bec-bc8b-863fd6cc9983 | test | ACTIVE | hpc=10.0.32.116 > | cirros | m1.tiny | > > > +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ > > > > Any thoughts? > > > > *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. > > > > -- > > *Att[]'s* > *Iury 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 * > 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. > -- *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: From tony at bakeyournoodle.com Fri Dec 14 09:03:54 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Fri, 14 Dec 2018 20:03:54 +1100 Subject: [tosca-parser] Need new release of tosca-parser library In-Reply-To: References: <20181212023950.GC6373@thor.bakeyournoodle.com> <6F5CE673-171B-436B-8D08-414494A9A60C@haddleton.net> Message-ID: <20181214090353.GF6373@thor.bakeyournoodle.com> On Fri, Dec 14, 2018 at 02:28:19AM +0000, Singh, Niraj wrote: > Hi Bob, > > > Verified the info about the latest tosco-parser release 1.3.0, I can see my changes in the commits [1]. But after downloading the zip file under release 1.3.0, I didn't found my changes that was in [2]. Your request for 1.3.0 was against the SHA 0c77377 Look here: [tony at thor tosca-parser]$ git lol 1.2.0..1.3.0 * 0c77377 (tag: 1.3.0) Move extension tests to where stestr can find them * f2ca5eb Merge "Use stestr instead of testr" |\ | * 803b2a8 Use stestr instead of testr * f231b27 Merge "Fix error using get_attribute with HOST in case of setting host relationship in "long" format." * c08022d Fix error using get_attribute with HOST in case of setting host relationship in "long" format. However that SHA you requested was well behind origin/master [tony at thor tosca-parser]$ git lol 1.3.0..origin/master * e0c67af (HEAD -> master, origin/master, origin/HEAD, gerrit/master) Merge "Add py36 to tox.ini and setup.cfg" |\ | * 4bdad8e Add py36 to tox.ini and setup.cfg * bfed830 Merge "Add reservation policy support" |\ | * fd3c74b Add reservation policy support * 466a489 Merge "Change openstack-dev to openstack-discuss" * f90efb1 Change openstack-dev to openstack-discuss The chnage you want is in that range. You can request a new release for 1.3.1 or 1.4.0 whichever is the appropriate semver via the same method. 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 zufar at onf-ambassador.org Fri Dec 14 11:29:51 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Fri, 14 Dec 2018 18:29:51 +0700 Subject: [magnum] region_name needs to be configured in magnum.conf Message-ID: I am following installation guide from magnum documentation. but I get an error when trying to create kubernetes cluster. *region_name needs to be configured in magnum.conf* this is my full log : [root at zu-bssn-controller1 opt]# openstack coe cluster create kubernetes-cluster --cluster-template kubernetes-cluster-template --master-count 1 --node-count 1 --keypair mykeyRequest to create cluster bfdf76df-8b43-44e3-a094-90a76189610a accepted [root at zu-bssn-controller1 opt]# openstack coe cluster list +--------------------------------------+--------------------+---------+------------+--------------+---------------+ | uuid | name | keypair | node_count | master_count | status | +--------------------------------------+--------------------+---------+------------+--------------+---------------+ | bfdf76df-8b43-44e3-a094-90a76189610a | kubernetes-cluster | mykey | 1 | 1 | CREATE_FAILED | +--------------------------------------+--------------------+---------+------------+--------------+---------------+ [root at zu-bssn-controller1 opt]# openstack coe cluster show kubernetes-cluster +---------------------+---------------------------------------------------+ | Field | Value | +---------------------+---------------------------------------------------+ | status | CREATE_FAILED | | cluster_template_id | 560f72a9-d6ac-4404-ad9e-3cd129496022 | | node_addresses | [] | | uuid | bfdf76df-8b43-44e3-a094-90a76189610a | | stack_id | None | | status_reason | region_name needs to be configured in magnum.conf | | created_at | 2018-12-14T11:25:37+00:00 | | updated_at | 2018-12-14T11:25:40+00:00 | | coe_version | None | | labels | {} | | faults | {} | | keypair | mykey | | api_address | None | | master_addresses | [] | | create_timeout | 60 | | node_count | 1 | | discovery_url | None | | master_count | 1 | | container_version | None | | name | kubernetes-cluster | | master_flavor_id | amphora | | flavor_id | amphora | +---------------------+---------------------------------------------------+ [root at zu-bssn-controller1 opt]# Anyone know what is happening? Best Regards, Zufar Dhiyaulhaq -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Fri Dec 14 12:20:26 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Fri, 14 Dec 2018 13:20:26 +0100 Subject: [magnum] region_name needs to be configured in magnum.conf In-Reply-To: References: Message-ID: I did not get this error but in magnum.conf I have the following section: [cinder_client] # # From magnum.conf # # Region in Identity service catalog to use for communication with the # OpenStack service. (string value) region_name = RegionOne Il giorno ven 14 dic 2018 alle ore 12:33 Zufar Dhiyaulhaq < zufar at onf-ambassador.org> ha scritto: > I am following installation guide from magnum documentation. but I get an > error when trying to create kubernetes cluster. > > *region_name needs to be configured in magnum.conf* > > this is my full log : > > [root at zu-bssn-controller1 opt]# openstack coe cluster create > kubernetes-cluster --cluster-template kubernetes-cluster-template > --master-count 1 --node-count 1 --keypair mykeyRequest to create cluster > bfdf76df-8b43-44e3-a094-90a76189610a accepted > [root at zu-bssn-controller1 opt]# openstack coe cluster list > > +--------------------------------------+--------------------+---------+------------+--------------+---------------+ > | uuid | name | keypair | > node_count | master_count | status | > > +--------------------------------------+--------------------+---------+------------+--------------+---------------+ > | bfdf76df-8b43-44e3-a094-90a76189610a | kubernetes-cluster | mykey > | 1 | 1 | CREATE_FAILED | > > +--------------------------------------+--------------------+---------+------------+--------------+---------------+ > [root at zu-bssn-controller1 opt]# openstack coe cluster show > kubernetes-cluster > +---------------------+---------------------------------------------------+ > | Field | Value | > +---------------------+---------------------------------------------------+ > | status | CREATE_FAILED | > | cluster_template_id | 560f72a9-d6ac-4404-ad9e-3cd129496022 | > | node_addresses | [] | > | uuid | bfdf76df-8b43-44e3-a094-90a76189610a | > | stack_id | None | > | status_reason | region_name needs to be configured in magnum.conf | > | created_at | 2018-12-14T11:25:37+00:00 | > | updated_at | 2018-12-14T11:25:40+00:00 | > | coe_version | None | > | labels | {} | > | faults | {} | > | keypair | mykey | > | api_address | None | > | master_addresses | [] | > | create_timeout | 60 | > | node_count | 1 | > | discovery_url | None | > | master_count | 1 | > | container_version | None | > | name | kubernetes-cluster | > | master_flavor_id | amphora | > | flavor_id | amphora | > +---------------------+---------------------------------------------------+ > [root at zu-bssn-controller1 opt]# > > Anyone know what is happening? > > Best Regards, > Zufar Dhiyaulhaq > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufar at onf-ambassador.org Fri Dec 14 12:24:21 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Fri, 14 Dec 2018 19:24:21 +0700 Subject: [magnum] region_name needs to be configured in magnum.conf In-Reply-To: References: Message-ID: Hi Ignazio, my OpenStack does not have cinder deployed. it is possible? Best Regards, Zufar Dhiyaulhaq On Fri, Dec 14, 2018 at 7:20 PM Ignazio Cassano wrote: > I did not get this error but in magnum.conf I have the following section: > [cinder_client] > > # > # From magnum.conf > # > > # Region in Identity service catalog to use for communication with the > # OpenStack service. (string value) > region_name = RegionOne > > > > Il giorno ven 14 dic 2018 alle ore 12:33 Zufar Dhiyaulhaq < > zufar at onf-ambassador.org> ha scritto: > >> I am following installation guide from magnum documentation. but I get an >> error when trying to create kubernetes cluster. >> >> *region_name needs to be configured in magnum.conf* >> >> this is my full log : >> >> [root at zu-bssn-controller1 opt]# openstack coe cluster create >> kubernetes-cluster --cluster-template kubernetes-cluster-template >> --master-count 1 --node-count 1 --keypair mykeyRequest to create cluster >> bfdf76df-8b43-44e3-a094-90a76189610a accepted >> [root at zu-bssn-controller1 opt]# openstack coe cluster list >> >> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >> | uuid | name | keypair | >> node_count | master_count | status | >> >> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >> | bfdf76df-8b43-44e3-a094-90a76189610a | kubernetes-cluster | mykey >> | 1 | 1 | CREATE_FAILED | >> >> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >> [root at zu-bssn-controller1 opt]# openstack coe cluster show >> kubernetes-cluster >> >> +---------------------+---------------------------------------------------+ >> | Field | Value >> | >> >> +---------------------+---------------------------------------------------+ >> | status | CREATE_FAILED >> | >> | cluster_template_id | 560f72a9-d6ac-4404-ad9e-3cd129496022 >> | >> | node_addresses | [] >> | >> | uuid | bfdf76df-8b43-44e3-a094-90a76189610a >> | >> | stack_id | None >> | >> | status_reason | region_name needs to be configured in magnum.conf >> | >> | created_at | 2018-12-14T11:25:37+00:00 >> | >> | updated_at | 2018-12-14T11:25:40+00:00 >> | >> | coe_version | None >> | >> | labels | {} >> | >> | faults | {} >> | >> | keypair | mykey >> | >> | api_address | None >> | >> | master_addresses | [] >> | >> | create_timeout | 60 >> | >> | node_count | 1 >> | >> | discovery_url | None >> | >> | master_count | 1 >> | >> | container_version | None >> | >> | name | kubernetes-cluster >> | >> | master_flavor_id | amphora >> | >> | flavor_id | amphora >> | >> >> +---------------------+---------------------------------------------------+ >> [root at zu-bssn-controller1 opt]# >> >> Anyone know what is happening? >> >> Best Regards, >> Zufar Dhiyaulhaq >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bobh at haddleton.net Fri Dec 14 12:39:59 2018 From: bobh at haddleton.net (Bob Haddleton) Date: Fri, 14 Dec 2018 06:39:59 -0600 Subject: [tosca-parser] Need new release of tosca-parser library In-Reply-To: <20181214090353.GF6373@thor.bakeyournoodle.com> References: <20181212023950.GC6373@thor.bakeyournoodle.com> <6F5CE673-171B-436B-8D08-414494A9A60C@haddleton.net> <20181214090353.GF6373@thor.bakeyournoodle.com> Message-ID: <2ad0b739-5cc5-d5d2-0c4b-226a37b771b8@haddleton.net> My apologies - I don't know where that SHA came from, my repo has the correct one. I will push a 1.3.1 release request now. Bob On 12/14/18 3:03 AM, Tony Breeds wrote: > On Fri, Dec 14, 2018 at 02:28:19AM +0000, Singh, Niraj wrote: >> Hi Bob, >> >> >> Verified the info about the latest tosco-parser release 1.3.0, I can see my changes in the commits [1]. But after downloading the zip file under release 1.3.0, I didn't found my changes that was in [2]. > Your request for 1.3.0 was against the SHA 0c77377 > > Look here: > [tony at thor tosca-parser]$ git lol 1.2.0..1.3.0 > * 0c77377 (tag: 1.3.0) Move extension tests to where stestr can find them > * f2ca5eb Merge "Use stestr instead of testr" > |\ > | * 803b2a8 Use stestr instead of testr > * f231b27 Merge "Fix error using get_attribute with HOST in case of setting host relationship in "long" format." > * c08022d Fix error using get_attribute with HOST in case of setting host relationship in "long" format. > > > However that SHA you requested was well behind origin/master > > [tony at thor tosca-parser]$ git lol 1.3.0..origin/master > * e0c67af (HEAD -> master, origin/master, origin/HEAD, gerrit/master) Merge "Add py36 to tox.ini and setup.cfg" > |\ > | * 4bdad8e Add py36 to tox.ini and setup.cfg > * bfed830 Merge "Add reservation policy support" > |\ > | * fd3c74b Add reservation policy support > * 466a489 Merge "Change openstack-dev to openstack-discuss" > * f90efb1 Change openstack-dev to openstack-discuss > > The chnage you want is in that range. > > You can request a new release for 1.3.1 or 1.4.0 whichever is the > appropriate semver via the same method. > > Yours Tony. From manuel.sb at garvan.org.au Fri Dec 14 00:11:15 2018 From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros) Date: Fri, 14 Dec 2018 00:11:15 +0000 Subject: can't login to baremetal deploid with ironic In-Reply-To: References: <9D8A2486E35F0941A60430473E29F15B017BAF8E62@MXDB2.ad.garvan.unsw.edu.au> Message-ID: <9D8A2486E35F0941A60430473E29F15B017BAF9187@MXDB2.ad.garvan.unsw.edu.au> Hi Lury, Yes, I can login to cirros using the default credentials cirros/gocubsgo Manuel From: Iury Gregory [mailto:iurygregory at gmail.com] Sent: Friday, December 14, 2018 12:26 AM To: Manuel Sopena Ballesteros Cc: openstack at lists.openstack.org Subject: Re: can't login to baremetal deploid with ironic Hello Manuel, Did you try the default password for cirros images? https://docs.openstack.org/image-guide/obtain-images.html#cirros-test Em qui, 13 de dez de 2018 às 14:05, Manuel Sopena Ballesteros > escreveu: Dear Openstack user group, I am playing with Ironic and have a very stupid question… For some reason I can’t login to the server after deployment. Server status is ACTIVE and I am using the adminPass provided by openstack . The way I connect is through server console through the IPMI console (not ssh). [root at openstack-deployment ~]# openstack server create --image 760f4076-4f2d-455b-89b5-6c1248148f70 --flavor my-baremetal-flavor --network hpc demo1 +-------------------------------------+------------------------------------------------------------+ | Field | Value | +-------------------------------------+------------------------------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | | | OS-EXT-SRV-ATTR:host | None | | OS-EXT-SRV-ATTR:hypervisor_hostname | None | | OS-EXT-SRV-ATTR:instance_name | | | OS-EXT-STS:power_state | NOSTATE | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | None | | OS-SRV-USG:terminated_at | None | | accessIPv4 | | | accessIPv6 | | | addresses | | | adminPass | t3TAUNwTbuD5 | | config_drive | | | created | 2018-12-13T05:39:11Z | | flavor | my-baremetal-flavor (84abc368-1695-4387-998c-8b47da1a3a34) | | hostId | | | id | 5231e015-73e9-472f-bb84-bde9bf7e6989 | | image | centos7.5-image (760f4076-4f2d-455b-89b5-6c1248148f70) | | key_name | None | | name | demo1 | | progress | 0 | | project_id | 0b3d8fd6015048e89f4372fb1534900b | | properties | | | security_groups | name='default' | | status | BUILD | | updated | 2018-12-13T05:39:12Z | | user_id | fd244f331bc34066b7a5fae72d518261 | | volumes_attached | | +-------------------------------------+------------------------------------------------------------+ [root at openstack-deployment ~]# openstack server list +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ | 5231e015-73e9-472f-bb84-bde9bf7e6989 | demo1 | ACTIVE | hpc=10.0.32.119 | centos7.5-image | my-baremetal-flavor | | 9cc2369f-1951-4bec-bc8b-863fd6cc9983 | test | ACTIVE | hpc=10.0.32.116 | cirros | m1.tiny | +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ Any thoughts? 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. -- Att[]'s Iury 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 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: From felluslior at gmail.com Fri Dec 14 00:23:46 2018 From: felluslior at gmail.com (Lior Fellus) Date: Fri, 14 Dec 2018 02:23:46 +0200 Subject: NTP failed on deploy Message-ID: I'm doing a fresh deploy of OpenStack using Fuel, with 3 controllers and 4 compute nodes. Network verification passes without issues, but during the OpenStack installation phase on the new compute I am trying to add I get this message: *Failed to deploy node '...': Task sync_time failed on node * I can ping the NTP servers (fuel server) from the node so connectivity shouldn't be an issue. we are using Mirantis Mitaka. Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From felluslior at gmail.com Fri Dec 14 12:24:30 2018 From: felluslior at gmail.com (Lior Fellus) Date: Fri, 14 Dec 2018 14:24:30 +0200 Subject: deploy compute node failed Message-ID: Hi All while trying to add compute to my environment i get error and this message in log: (/Stage[main]/Main/Exec[sync_time_shell]/returns) change from notrun to 0 failed: /bin/bash "/etc/puppet/shell_manifests/sync_time_command.sh" returned 1 instead of one of [0] there is connection between the fuel and the node and ntp service is up on fuel i am using Mirantis openstack mitaka. any suggestions? Thanks, Lior -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Waines at windriver.com Fri Dec 14 13:07:02 2018 From: Greg.Waines at windriver.com (Waines, Greg) Date: Fri, 14 Dec 2018 13:07:02 +0000 Subject: [openstack-dev] [keystone] Keystone support of Multi-Factor Authentication ? Message-ID: Keystone guys, What is the current status of Keystone supporting Multi-Factor Authentication ? https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/mfa-auth-receipt.html * Does this work provide true MFA ? * Is this work still active ? Are there other solutions for MFA for OpenStack Keystone ? Greg. -------------- next part -------------- An HTML attachment was scrubbed... URL: From colleen at gazlene.net Fri Dec 14 13:41:59 2018 From: colleen at gazlene.net (Colleen Murphy) Date: Fri, 14 Dec 2018 14:41:59 +0100 Subject: [openstack-dev] [keystone] Keystone support of Multi-Factor Authentication ? In-Reply-To: References: Message-ID: <1544794919.3636422.1609154600.62B5FA0A@webmail.messagingengine.com> Hi Greg, On Fri, Dec 14, 2018, at 2:07 PM, Waines, Greg wrote: > Keystone guys, > > What is the current status of Keystone supporting Multi-Factor Authentication ? > > https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/mfa-auth-receipt.html > > * Does this work provide true MFA ? It's a component of a proper MFA solution. We had already implemented TOTP as a possible auth method as well as the ability to use multiple auth methods. The MFA receipts work is to make it easier for clients to use MFA in a more natural way than what we had before. > * Is this work still active ? The API work for the receipts features is more or less completed. We still need proper documentation and an update to the API reference. We also need to work this feature into keystoneauth and horizon. Adrian Turjak has been leading this effort. I think he's still on vacation but I expect he'll pick it up when he's back. > > Are there other solutions for MFA for OpenStack Keystone ? Not in keystone, but keystone supports external authentication so if you have an external identity provider that supports MFA you can lean on that. > > Greg. Colleen From mike_mp at zzzcomputing.com Fri Dec 14 14:11:39 2018 From: mike_mp at zzzcomputing.com (Mike Bayer) Date: Fri, 14 Dec 2018 09:11:39 -0500 Subject: [dev][openstacksdk] openstacksdk and dogpile 0.7.0+ cache errors In-Reply-To: <20181214034259.GA16789@fedora19.localdomain> References: <20181214034259.GA16789@fedora19.localdomain> Message-ID: On Thu, Dec 13, 2018 at 10:46 PM Ian Wienand wrote: > > Hi, > > Just a heads up that the latest version of dogpile (0.7.0 onwards) > have become incompatible with openstacksdk. This is causing a few > issues for jobs. As usual, it's a little complex :) Can you let me know which openstack projects had a failure? For this specific change, I enabled my own openstack CI for dogpile.cache, which runs a selected set of openstack tests for the Neutron, Nova, Keystone and oslo.db projects, and I didn't observe any failures: https://gerrit.sqlalchemy.org/#/x/verify-status/jobs/996/4 > > The error you will see is something like > > user_func.set = set_ > AttributeError: 'method' object has no attribute 'set' > > The following are related: > > https://review.openstack.org/624697 : requirements change to pin > https://review.openstack.org/624485 : openstacksdk pin > https://review.openstack.org/624855 : fixes a nodepool job that > openstacksdk depends on (note 624485 turns the job non-voting to > break the circular dependency). > > The issue is being tracked in: > > https://storyboard.openstack.org/#!/story/2004605 : related story > https://github.com/sqlalchemy/dogpile.cache/issues/140 : upstream github issue I've commented on what is likely a simple fix, but it depends on what the Python decorator module, which here is our new third party dependency, is capable of doing. This review sat in the queue for a few weeks as I vaguely worried what problems this dependency might cause, so I guess I failed to get enough people to review this change. Are there folks here who would like to watch the dogpile.cache github project (now at https://github.com/sqlalchemy/dogpile.cache) as well as our gerrit so that future changes can get some more review? > > Thanks, > > -i > From thierry at openstack.org Fri Dec 14 14:29:10 2018 From: thierry at openstack.org (Thierry Carrez) Date: Fri, 14 Dec 2018 15:29:10 +0100 Subject: [tc] Creation of OSF project confirmation guidelines Message-ID: <16aa6fbb-0e5d-8c0c-12e2-d7765e95ad1d@openstack.org> Hi everyone, As you may know, a sub group of the OSF Board of Directors has recently kicked off an effort to draft guidelines on how to confirm OSF pilot projects as full, top-level, open infrastructure projects of the Foundation. The current pilot projects that will be eligible for confirmation review in 2019-2020 are Airship, Kata Containers, StarlingX and Zuul. Currently the OpenStack project is the only confirmed project. The discussion about drafting these guidelines is just getting started, but everyone can participate in this effort by reviewing the context and working draft on this etherpad and adding feedback and thoughts at the bottom: https://etherpad.openstack.org/p/BrainstormingOSFProjectConfirmationGuidelines There will most likely be some open call scheduled in early 2019 where additional feedback will also be gathered. The goal is to come up with a set of points that the Board can use when reviewing pilot projects for confirmation. This topic has previously been discussed at a very high-level at previous Board meetings, including the September 18th meeting[1] (starting around slide 38). [1] https://docs.google.com/presentation/d/10UyCpxkjPqC3kT-dYRpBxzNT39i2OhlggJvzGDosMz0/edit#slide=id.g4274351d5e_1_392 -- Thierry Carrez (ttx) From fungi at yuggoth.org Fri Dec 14 14:50:07 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 14 Dec 2018 14:50:07 +0000 Subject: [dev][openstacksdk][infra] openstacksdk and dogpile 0.7.0+ cache errors In-Reply-To: References: <20181214034259.GA16789@fedora19.localdomain> Message-ID: <20181214145007.3ftbfhscvpwibl5k@yuggoth.org> On 2018-12-14 09:11:39 -0500 (-0500), Mike Bayer wrote: [...] > Are there folks here who would like to watch the dogpile.cache > github project (now at > https://github.com/sqlalchemy/dogpile.cache) as well as our gerrit > so that future changes can get some more review? Alternatively, zuul.openstack.org has the ability to test pull requests for GitHub repositories automatically and report back configured job results (basically acting as a third-party CI system). We already do this for Ansible, for example. If we can identify a good set of candidate jobs to run, is this something you'd be interested in? -- 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 jon at csail.mit.edu Fri Dec 14 14:56:33 2018 From: jon at csail.mit.edu (Jonathan D. Proulx) Date: Fri, 14 Dec 2018 09:56:33 -0500 Subject: Nova live migration fails - InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility. In-Reply-To: References: Message-ID: <20181214145633.uubvjysgga3ftnos@csail.mit.edu> On Thu, Dec 13, 2018 at 06:48:10PM -0500, Erik McCormick wrote: :On Thu, Dec 13, 2018 at 5:37 PM Torin Woltjer : wrote: :> :> Having issues getting live migrations to functions between two compute nodes. :> One is an Opteron G4 and the other is an Opteron G5. I can migrate from the G4 to the G5 just fine. When I try to migrate an instance from the G5 node to the G4 node I get an error message: :> InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility. :> This is despite having the following setting in my /etc/nova/nova.conf on the G5 machine. :> :> [libvirt] :> cpu_mode = custom :> cpu_model = Opteron_G4 :> :> Is this not the setting I'm looking for? What can I do to make this work? :> :Did you create the instances you are trying to migrate after you :applied the setting? If not, do a cold migrate and then try the live :one again. My bets are on this one, it's the sort of thing I do anyway. An `openstack server reboot --hard` should also recreate the VM inplace with new config settings I think. you can double check that the instance you are trying to move has the correct CPU setting by looking at the libvirt XML, either in: /var/lib/nova/instances//libvirt.xml or dumping libvirt's info on running VM: virsh dumpxml what you don't want to see is: This is what I use and just live with somewhat complex mappings of what will move where because my user want all thw feature they can get. So I'm not 100% sure what you wnat to see here, but I know it's not that. -Jon From torin.woltjer at granddial.com Fri Dec 14 15:38:00 2018 From: torin.woltjer at granddial.com (Torin Woltjer) Date: Fri, 14 Dec 2018 15:38:00 GMT Subject: Nova live migration fails - InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility. Message-ID: <95b62095c56e47619cf95e7c845945bb@granddial.com> I've restarted the instances that I'm using to test but no luck. I have the setting set on just the highest compute node; I tried setting it on one of my older gen compute nodes as well but because there is production load on it, I am anxious about restarting services; I did restart the nova-compute service after making the change and there was no change in behavior. Should the setting also be set on the controllers? When I look at virsh capabilities there is certainly a difference between the two 7c7 < Opteron_G5 --- > Opteron_G4 9c9 < --- > 15d14 < 25c24 < --- > I look at the test instance on the compute node with the G5 opteron and this is in the XML Opteron_G4 This looks like it is correctly taking the CPU model that I have specified in nova.conf, yet it does not want to migrate to the Opteron_G4 node. -------------- next part -------------- An HTML attachment was scrubbed... URL: From morgan.fainberg at gmail.com Fri Dec 14 15:45:20 2018 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Fri, 14 Dec 2018 07:45:20 -0800 Subject: [dev][openstacksdk][infra] openstacksdk and dogpile 0.7.0+ cache errors In-Reply-To: <20181214145007.3ftbfhscvpwibl5k@yuggoth.org> References: <20181214034259.GA16789@fedora19.localdomain> <20181214145007.3ftbfhscvpwibl5k@yuggoth.org> Message-ID: The issue was with OpenStack SDK. SDK is doing a strange thing and wraps with dogpile the already bound-methods (from instantiated objects). It turns out this isn't really needed and the solution will be to not add the extra layer of wrapping into the SDK bits. I expect I can roll a patch for that later today. The extra layer of wrapping was to bubble up an .invalidate method, which strictly should have already existed when using dogpile. I'll make sure to unroll all the potential issues and get SDK into a sane place. In my opinion dogpile.cache is doing the right thing and assuming it is in charge of wrapping the methods. Wrapping (with a decorator) bound methods is a weird bit of meta-programming I don't see as necessary to support. With that said, this was a change in behavior. I've been unable (need to find my hardware token) to login to github to comment on the issue (will do this today) but I am going to comment much the same as I have here on the mailing list. Finally, I do think we should add the feedback loop to dogpile from openstack as we lean on it pretty heavily. I believe the big projects to catch are SDK/shade, Keystone, Keystone Middleware, and Oslo.Cache (oslo.cache should cover everything but openstackSDK/shade). I might be missing bits of infra as well in this list. On Fri, Dec 14, 2018 at 6:55 AM Jeremy Stanley wrote: > On 2018-12-14 09:11:39 -0500 (-0500), Mike Bayer wrote: > [...] > > Are there folks here who would like to watch the dogpile.cache > > github project (now at > > https://github.com/sqlalchemy/dogpile.cache) as well as our gerrit > > so that future changes can get some more review? > > Alternatively, zuul.openstack.org has the ability to test pull > requests for GitHub repositories automatically and report back > configured job results (basically acting as a third-party CI > system). We already do this for Ansible, for example. If we can > identify a good set of candidate jobs to run, is this something > you'd be interested in? > -- > Jeremy Stanley > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emccormick at cirrusseven.com Fri Dec 14 15:52:34 2018 From: emccormick at cirrusseven.com (Erik McCormick) Date: Fri, 14 Dec 2018 10:52:34 -0500 Subject: Nova live migration fails - InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility. In-Reply-To: <95b62095c56e47619cf95e7c845945bb@granddial.com> References: <95b62095c56e47619cf95e7c845945bb@granddial.com> Message-ID: On Fri, Dec 14, 2018 at 10:38 AM Torin Woltjer wrote: > > I've restarted the instances that I'm using to test but no luck. > > I have the setting set on just the highest compute node; I tried setting it on one of my older gen compute nodes as well but because there is production load on it, I am anxious about restarting services; I did restart the nova-compute service after making the change and there was no change in behavior. Should the setting also be set on the controllers? I don't believe you need it on the controllers. The host capabilities get registered by nova-compute, so the controller config wouldn't make use of those settings. I wouldn't have different CPU modes though. If you're going to hard set one, you should hard-set them all. Just the difference between custom and passthrough may be enough to make nova reject the request. You should be able to easily set the custom setting on the production node and restart nova-compute without affecting running instances. Once the instances are running, nova has very little to do with them. As mentioned before, all the settings are applied at boot. The only caveat to this I can think of is if you're running NFS shared storage and nova services are in docker containers. I have seen this cause root disks of instances to go read-only as the mounting of the NFS volume comes and goes with the container. I've done exactly this multiple times with ceph-backed instances running on both baremetal and containerized hosts with no issues. > > When I look at virsh capabilities there is certainly a difference between the two > 7c7 > < Opteron_G5 > --- > > Opteron_G4 > 9c9 > < > --- > > > 15d14 > < > 25c24 > < > --- > > > > > I look at the test instance on the compute node with the G5 opteron and this is in the XML > > Opteron_G4 > > > > > > > > This looks like it is correctly taking the CPU model that I have specified in nova.conf, yet it does not want to migrate to the Opteron_G4 node. From colleen at gazlene.net Fri Dec 14 15:58:19 2018 From: colleen at gazlene.net (Colleen Murphy) Date: Fri, 14 Dec 2018 16:58:19 +0100 Subject: [dev][keystone] Keystone Team Update - Week of 10 December 2018 Message-ID: <1544803099.3674428.1609278872.43F77EE8@webmail.messagingengine.com> # Keystone Team Update - Week of 10 December 2018 ## News ### Policy questions We had some topics related to RBAC and policy come up in discussions this week. We had an exchange over whether the reader role is really sufficient to describe the ability to read resources currently restricted to admins as well as resources currently restricted to members, or if those are really two different kinds of read levels[1][2]. We also discussed our current work on default roles with the cinder team[3] in light of their work on documenting some best practices for policy configuration in cinder[4]. Finally, in our efforts to convert our own policies to use the default roles[5], we're starting to deep-dive into the APIs to uncover their intentions, their current protections, and the most sensible default policies for them. [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000888.html [2] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-12-13.log.html#t2018-12-13T18:03:51 [3] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000875.html [4] https://review.openstack.org/624424 [5] https://review.openstack.org/#/q/status:open+topic:implement-default-roles ### Cleaning up old specs At the weekly meeting we tangented from another topic to note that we've been doing a bad job of pruning the specs backlog and that we should organize some process around regularly reevaluating and prioritizing things in it[6]. [6] http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-12-11-16.00.log.html#l-88 ### Immutable Roles and Resource Options for All Morgan proposed a new spec[7] to lay the ground work for implementing resource options for most or all resources in keystone, similar to the user options we have now that lets us control MFA rights and PCI-DSS restrictions. We'd then like to build on this to make some resources, especially roles, immutable[8] or locked in order to prevent accidentally deleting deployment-critical resources, which we know has happened to more than one person. [7] https://review.openstack.org/624692 [8] https://review.openstack.org/624162 ## Open Specs Stein specs: https://bit.ly/2Pi6dGj Ongoing specs: https://bit.ly/2OyDLTh We merged the JWT spec[9] and the domain limits spec[10]. Morgan proposed a new spec for Stein[11] although we are past the spec proposal freeze date. We may decide to push it to Train, but that will also delay starting on the new immutable resources spec[12]. [9] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/stein/json-web-tokens.html [10] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/stein/domain-level-limit.html [11] https://review.openstack.org/624162 [12] https://review.openstack.org/624692 ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 38 changes this week. These included cleanup work to finish the documentation consolidation that we started a while ago, as well as several patches for default roles policy updates. ## Changes that need Attention Search query: https://bit.ly/2RLApdA There are 98 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. These are mainly still the default roles policy changes from Lance. ## Bugs This week we opened 5 new bugs and closed 5. Bugs opened (5) Bug #1807751 (keystone:Wishlist) opened by Morgan Fainberg https://bugs.launchpad.net/keystone/+bug/1807751 Bug #1807697 (keystone:Undecided) opened by Yang Youseok https://bugs.launchpad.net/keystone/+bug/1807697 Bug #1807805 (keystone:Undecided) opened by Zhongcheng Lao https://bugs.launchpad.net/keystone/+bug/1807805 Bug #1808059 (keystone:Undecided) opened by David Vallee Delisle https://bugs.launchpad.net/keystone/+bug/1808059 Bug #1808305 (python-keystoneclient:Undecided) opened by Neha Alhat https://bugs.launchpad.net/python-keystoneclient/+bug/1808305 Bugs closed (2) Bug #1802136 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1802136 Bug #1808059 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1808059 Bugs fixed (3) Bug #1794376 (keystone:High) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1794376 Bug #1803780 (keystone:Low) fixed by Adam Young https://bugs.launchpad.net/keystone/+bug/1803780 Bug #1803940 (keystonemiddleware:Wishlist) fixed by Artem Vasilyev https://bugs.launchpad.net/keystonemiddleware/+bug/1803940 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html ## 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 chris.friesen at windriver.com Fri Dec 14 16:26:09 2018 From: chris.friesen at windriver.com (Chris Friesen) Date: Fri, 14 Dec 2018 10:26:09 -0600 Subject: Nova live migration fails - InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility. In-Reply-To: <95b62095c56e47619cf95e7c845945bb@granddial.com> References: <95b62095c56e47619cf95e7c845945bb@granddial.com> Message-ID: On 12/14/2018 9:38 AM, Torin Woltjer wrote: > I've restarted the instances that I'm using to test but no luck. > > I have the setting set on just the highest compute node; I tried setting > it on one of my older gen compute nodes as well but because there is > production load on it, I am anxious about restarting services; I did > restart the nova-compute service after making the change and there was > no change in behavior. Should the setting also be set on the controllers? You should set the model explicitly on all the nodes, you'd only need to restart nova-compute on that node after changing the setting. It might be worth booting up an instance on the G4 node after making this change and then checking whether the XML matches what you have on the G5 node. Chris From mattia.belluco at uzh.ch Fri Dec 14 16:35:52 2018 From: mattia.belluco at uzh.ch (Mattia Belluco) Date: Fri, 14 Dec 2018 17:35:52 +0100 Subject: Nova live migration fails - InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility. In-Reply-To: <20181214145633.uubvjysgga3ftnos@csail.mit.edu> References: <20181214145633.uubvjysgga3ftnos@csail.mit.edu> Message-ID: <103eb3de-cbb9-e5af-9a1c-f1af80c906cf@uzh.ch> Let me chip in on this as we are experiencing a similar issue: We have started encountering this behaviour following a ubuntu trusty to xenial upgrade (we are still running Mitaka). It affects VMs that previously were successfully migrated cross architecture (xeon v2 -> skylake and vice versa). We are yet unable to pinpoint the exact cause because the issue is difficult to reproduce: VMs started on the affected node migrate freely and their xml is *identical* (except for UUIDs and such) to the one of the VMs that refuse to migrate. As a side note I think the key is the: "InvalidCPUInfo: Unacceptable CPU info". Normally, infact, the error would also include which are the problematic flags and despite the exception coming always from driver.py the message is different. If anyone has any suggestions other than reboot the affected VMs I'll gladly give them a try. Best Mattia On 12/14/18 3:56 PM, Jonathan D. Proulx wrote: > On Thu, Dec 13, 2018 at 06:48:10PM -0500, Erik McCormick wrote: > :On Thu, Dec 13, 2018 at 5:37 PM Torin Woltjer > : wrote: > :> > :> Having issues getting live migrations to functions between two compute nodes. > :> One is an Opteron G4 and the other is an Opteron G5. I can migrate from the G4 to the G5 just fine. When I try to migrate an instance from the G5 node to the G4 node I get an error message: > :> InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility. > :> This is despite having the following setting in my /etc/nova/nova.conf on the G5 machine. > :> > :> [libvirt] > :> cpu_mode = custom > :> cpu_model = Opteron_G4 > :> > :> Is this not the setting I'm looking for? What can I do to make this work? > :> > > :Did you create the instances you are trying to migrate after you > :applied the setting? If not, do a cold migrate and then try the live > :one again. > > My bets are on this one, it's the sort of thing I do anyway. An > `openstack server reboot --hard` should also recreate the VM inplace > with new config settings I think. > > you can double check that the instance you are trying to move has the > correct CPU setting by looking at the libvirt XML, either in: > > /var/lib/nova/instances//libvirt.xml > > or dumping libvirt's info on running VM: > > virsh dumpxml > > what you don't want to see is: > > > > This is what I use and just live with somewhat complex mappings of > what will move where because my user want all thw feature they can > get. So I'm not 100% sure what you wnat to see here, but I know it's > not that. > > -Jon > > -- Mattia Belluco S3IT Services and Support for Science IT Office Y11 F 52 University of Zürich Winterthurerstrasse 190, CH-8057 Zürich (Switzerland) Tel: +41 44 635 42 22 From mriedemos at gmail.com Fri Dec 14 16:36:53 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Fri, 14 Dec 2018 10:36:53 -0600 Subject: [goals][upgrade-checkers] Week R-17 Update Message-ID: <711f84a7-0c18-d8cb-65e1-5f1de5605564@gmail.com> A few updates this week. * Some more projects have merged the base framework patch (tricircle, vitrage and zaqar). Open changes are here [1]. * Neutron has a change up to add support for loading upgrade checkers via extension point for stadium projects [2]. * There are two projects for which it may or may not make sense to add the upgrade check CLI: 1. mistral [3] - there seems to be concern about how useful the upgrade checker tool could be for mistral. I can't say I know enough about mistral or how it works, but if it is more like horizon and is stateless then maybe it's not a good fit, but I assume mistral has state (it tracks workflows right? So if it gets a start event, presumably it's tracking that to wait for an end event). When I looked over the mistral release notes I had a hard time finding anything worth adding automated checks during an upgrade. However, there is a deprecation note from queens which says, "The YAQL/jinja2 expression function json_pp has been deprecated and will be removed in the S cycle. json_dump should be used instead." I would think that when removing that function, if it's possible to determine it is being used somehow (can that be determined from the database?), then an upgrade check would be useful for that. 2. swift [4] - John has concerns that adding this to swift will expand the scope of the project to provide management functionality which the project has avoided thus far. Again, when I was looking over swift release notes for this goal I never found anything that looked like an obvious upgrade impact so if it's not useful and would set a bad precedent for the project, then I'd be OK with omitting this goal for swift. [1] https://review.openstack.org/#/q/topic:upgrade-checkers+status:open [2] https://review.openstack.org/#/c/615196/ [3] https://review.openstack.org/#/c/611513/ [4] https://review.openstack.org/#/c/611634/ -- Thanks, Matt From doug at doughellmann.com Fri Dec 14 16:47:29 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 14 Dec 2018 11:47:29 -0500 Subject: [glance] functional-py35 job fails due to subunit.praser error In-Reply-To: References: <9fbbbe41-982b-0b34-4e58-7e3150be90b3@gmail.com> Message-ID: Abhishek Kekane writes: > I have manually removed oslo.policy 1.43.1 and installed 1.43.0 and ran > tests and those are passing without any issues. > Jokke has submitted a patch [1] where he has modified requirements.txt to > not install oslo.policy 1.43.1 but it still installs the same version as > glance's requirements.txt is not considered while installing dependencies > whereas it considers upper-constraints.txt from the openstack/requirements. > > [1] https://review.openstack.org/#/c/625085/1/requirements.txt Right, all projects in the integrated gate (and many others) use the constraints lists for their tests so that we can be sure that they all work with at least one set of dependencies that makes them co-installable. See https://docs.openstack.org/project-team-guide/dependency-management.html for details on why and how it works. Doug > > Thanks & Best Regards, > > Abhishek Kekane > > > On Fri, Dec 14, 2018 at 2:05 AM Matt Riedemann wrote: > >> On 12/13/2018 11:38 AM, Abhishek Kekane wrote: >> > From 7th December 2018, all of sudden functional-py35 check job is >> > failing on current master. Earlier this job was failing intermittently >> > (2-3 times from 100). I have tried to dig into the issue and find out >> > that it is failing obly for ubuntu and working fine with Fedora, centos >> > etc. Below are some of the findings: >> >> Might be related to what we're debugging in >> https://bugs.launchpad.net/openstack-gate/+bug/1808063 - jokke noticed >> something added to oslo.policy 1.43.1 which uses a deepcopy might be >> getting messed up with the nested proxy objects in glance. oslo.policy >> 1.43.1 got into upper-constraints on Dec 7: >> >> >> https://github.com/openstack/requirements/commit/bf300c99037e0e57229e20ca7f89517d1695d6b5 >> >> -- >> >> Thanks, >> >> Matt >> >> -- Doug From kendall at openstack.org Fri Dec 14 17:05:50 2018 From: kendall at openstack.org (Kendall Waters) Date: Fri, 14 Dec 2018 11:05:50 -0600 Subject: Open Infrastructure Summit Denver Contributor Discount Information Message-ID: Hi everyone, There have been a lot of questions about discounts for the upcoming Open Infrastructure Summit so I have outlined the contributor discounts that we will be giving out below. Contributor Discount (formally known as ATC or AUC discount) 50% off any 1 ticket type until online sales close (please note ticket prices are tiered so the earlier you use your discount code, the cheaper the ticket will be) - To qualify for this discount, you will need to either have contributed at least one commit which merged to an official governed OSF project or pilot project in the last 6 months as of January 1, 2019 or qualify as an AUC: http://superuser.openstack.org/articles/auc-community/ - Discount codes will be sent by the end of January Denver 2018 PTG Attendees 82% off the early bird price of the Summit + PTG combo ticket until early bird ends - To qualify for this discount, you must have attended the Denver PTG in September 2018 - Discount codes will be sent by the end of January Please let me know if you have any questions. Cheers, Kendall Kendall Waters OpenStack Marketing & Events kendall at openstack.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike_mp at zzzcomputing.com Fri Dec 14 18:03:07 2018 From: mike_mp at zzzcomputing.com (Mike Bayer) Date: Fri, 14 Dec 2018 13:03:07 -0500 Subject: [dev][openstacksdk][infra] openstacksdk and dogpile 0.7.0+ cache errors In-Reply-To: <20181214145007.3ftbfhscvpwibl5k@yuggoth.org> References: <20181214034259.GA16789@fedora19.localdomain> <20181214145007.3ftbfhscvpwibl5k@yuggoth.org> Message-ID: On Fri, Dec 14, 2018 at 9:53 AM Jeremy Stanley wrote: > > On 2018-12-14 09:11:39 -0500 (-0500), Mike Bayer wrote: > [...] > > Are there folks here who would like to watch the dogpile.cache > > github project (now at > > https://github.com/sqlalchemy/dogpile.cache) as well as our gerrit > > so that future changes can get some more review? > > Alternatively, zuul.openstack.org has the ability to test pull > requests for GitHub repositories automatically and report back > configured job results (basically acting as a third-party CI > system). We already do this for Ansible, for example. If we can > identify a good set of candidate jobs to run, is this something > you'd be interested in? Hi Jeremy - not sure if this is an option but I'd be more interested if this would be possible from my Gerrit server at https://gerrit.sqlalchemy.org. I move PRs immediately into gerrit for testing and that's also where I do all my work on SQLAlchemy / Alembic / dogpile /etc. My own Jenkins instance is using the gerrit plugin to add verified status to gerrits. I'm right now working on an improved PR flow where github PRs would go straight into Gerrit based on a reviewer add right up front. > -- > Jeremy Stanley From mike_mp at zzzcomputing.com Fri Dec 14 18:06:17 2018 From: mike_mp at zzzcomputing.com (Mike Bayer) Date: Fri, 14 Dec 2018 13:06:17 -0500 Subject: [dev][openstacksdk][infra] openstacksdk and dogpile 0.7.0+ cache errors In-Reply-To: References: <20181214034259.GA16789@fedora19.localdomain> <20181214145007.3ftbfhscvpwibl5k@yuggoth.org> Message-ID: On Fri, Dec 14, 2018 at 10:48 AM Morgan Fainberg wrote: > > The issue was with OpenStack SDK. SDK is doing a strange thing and wraps with dogpile the already bound-methods (from instantiated objects). It turns out this isn't really needed and the solution will be to not add the extra layer of wrapping into the SDK bits. I expect I can roll a patch for that later today. The extra layer of wrapping was to bubble up an .invalidate method, which strictly should have already existed when using dogpile. I'll make sure to unroll all the potential issues and get SDK into a sane place. > > In my opinion dogpile.cache is doing the right thing and assuming it is in charge of wrapping the methods. Wrapping (with a decorator) bound methods is a weird bit of meta-programming I don't see as necessary to support. With that said, this was a change in behavior. I wasn't sure that the use of decorator instead of a homegrown was really going to be noticeable but I guess it is. Nevertheless I did move from 0.6.x to 0.7.x which in my own projects means behaviorally-modifying change (my versioning scheme is ..). > > I've been unable (need to find my hardware token) to login to github to comment on the issue (will do this today) but I am going to comment much the same as I have here on the mailing list. > > Finally, I do think we should add the feedback loop to dogpile from openstack as we lean on it pretty heavily. I believe the big projects to catch are SDK/shade, Keystone, Keystone Middleware, and Oslo.Cache (oslo.cache should cover everything but openstackSDK/shade). I might be missing bits of infra as well in this list. > > On Fri, Dec 14, 2018 at 6:55 AM Jeremy Stanley wrote: >> >> On 2018-12-14 09:11:39 -0500 (-0500), Mike Bayer wrote: >> [...] >> > Are there folks here who would like to watch the dogpile.cache >> > github project (now at >> > https://github.com/sqlalchemy/dogpile.cache) as well as our gerrit >> > so that future changes can get some more review? >> >> Alternatively, zuul.openstack.org has the ability to test pull >> requests for GitHub repositories automatically and report back >> configured job results (basically acting as a third-party CI >> system). We already do this for Ansible, for example. If we can >> identify a good set of candidate jobs to run, is this something >> you'd be interested in? >> -- >> Jeremy Stanley From emccormick at cirrusseven.com Fri Dec 14 18:06:37 2018 From: emccormick at cirrusseven.com (Erik McCormick) Date: Fri, 14 Dec 2018 13:06:37 -0500 Subject: Open Infrastructure Summit Denver Contributor Discount Information In-Reply-To: References: Message-ID: On Fri, Dec 14, 2018, 12:19 PM Kendall Waters Hi everyone, > > There have been a lot of questions about discounts for the upcoming Open > Infrastructure Summit so I have outlined the contributor discounts that we > will be giving out below. > > *Contributor Discount (formally known as ATC or AUC discount)* > 50% off any 1 ticket type until online sales close (please note ticket > prices are tiered so the earlier you use your discount code, the cheaper > the ticket will be) > - To qualify for this discount, you will need to either have contributed > at least one commit which merged to an official governed OSF project or > pilot project in the last 6 months as of January 1, 2019 or qualify as an > AUC: http://superuser.openstack.org/articles/auc-community/ > - Discount codes will be sent by the end of January > > *Denver 2018 PTG Attendees* > 82% off the early bird price of the Summit + PTG combo ticket until early > bird ends > - To qualify for this discount, you must have attended the Denver PTG in > September 2018 > - Discount codes will be sent by the end of January > For those of us that attended the last PTG but may not attend this one, will the code still cover 100% of the full summit pass? > Please let me know if you have any questions. > > Cheers, > Kendall > > Kendall Waters > OpenStack Marketing & Events > kendall at openstack.org > > > -Erik > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Fri Dec 14 18:26:23 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Fri, 14 Dec 2018 19:26:23 +0100 Subject: [magnum] region_name needs to be configured in magnum.conf In-Reply-To: References: Message-ID: Hi Zufar, Yes it is possible but if you want persistent storage you need cinder. Magnum can use cinder. Ignazio Il giorno Ven 14 Dic 2018 13:24 Zufar Dhiyaulhaq ha scritto: > Hi Ignazio, > > my OpenStack does not have cinder deployed. it is possible? > > Best Regards, > Zufar Dhiyaulhaq > > > On Fri, Dec 14, 2018 at 7:20 PM Ignazio Cassano > wrote: > >> I did not get this error but in magnum.conf I have the following section: >> [cinder_client] >> >> # >> # From magnum.conf >> # >> >> # Region in Identity service catalog to use for communication with the >> # OpenStack service. (string value) >> region_name = RegionOne >> >> >> >> Il giorno ven 14 dic 2018 alle ore 12:33 Zufar Dhiyaulhaq < >> zufar at onf-ambassador.org> ha scritto: >> >>> I am following installation guide from magnum documentation. but I get >>> an error when trying to create kubernetes cluster. >>> >>> *region_name needs to be configured in magnum.conf* >>> >>> this is my full log : >>> >>> [root at zu-bssn-controller1 opt]# openstack coe cluster create >>> kubernetes-cluster --cluster-template kubernetes-cluster-template >>> --master-count 1 --node-count 1 --keypair mykeyRequest to create cluster >>> bfdf76df-8b43-44e3-a094-90a76189610a accepted >>> [root at zu-bssn-controller1 opt]# openstack coe cluster list >>> >>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>> | uuid | name | keypair | >>> node_count | master_count | status | >>> >>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>> | bfdf76df-8b43-44e3-a094-90a76189610a | kubernetes-cluster | mykey >>> | 1 | 1 | CREATE_FAILED | >>> >>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>> [root at zu-bssn-controller1 opt]# openstack coe cluster show >>> kubernetes-cluster >>> >>> +---------------------+---------------------------------------------------+ >>> | Field | >>> Value | >>> >>> +---------------------+---------------------------------------------------+ >>> | status | >>> CREATE_FAILED | >>> | cluster_template_id | >>> 560f72a9-d6ac-4404-ad9e-3cd129496022 | >>> | node_addresses | >>> [] | >>> | uuid | >>> bfdf76df-8b43-44e3-a094-90a76189610a | >>> | stack_id | >>> None | >>> | status_reason | region_name needs to be configured in >>> magnum.conf | >>> | created_at | >>> 2018-12-14T11:25:37+00:00 | >>> | updated_at | >>> 2018-12-14T11:25:40+00:00 | >>> | coe_version | >>> None | >>> | labels | >>> {} | >>> | faults | >>> {} | >>> | keypair | >>> mykey | >>> | api_address | >>> None | >>> | master_addresses | >>> [] | >>> | create_timeout | >>> 60 | >>> | node_count | >>> 1 | >>> | discovery_url | >>> None | >>> | master_count | >>> 1 | >>> | container_version | >>> None | >>> | name | >>> kubernetes-cluster | >>> | master_flavor_id | >>> amphora | >>> | flavor_id | >>> amphora | >>> >>> +---------------------+---------------------------------------------------+ >>> [root at zu-bssn-controller1 opt]# >>> >>> Anyone know what is happening? >>> >>> Best Regards, >>> Zufar Dhiyaulhaq >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From openstack at nemebean.com Fri Dec 14 18:31:55 2018 From: openstack at nemebean.com (Ben Nemec) Date: Fri, 14 Dec 2018 12:31:55 -0600 Subject: [TripleO] OVB 2.0 Update Message-ID: <93985ba0-c57b-b9bb-ccdf-4df880c3e083@nemebean.com> Just wanted to give everyone a heads up that there's a 2.0 development branch for OVB available. I wrote up a blog post about it http://blog.nemebean.com/content/openstack-virtual-baremetal-20-update that covers the details of what changed and where you can find it. We definitely need to make sure TripleO CI will be happy with the changes, but if anyone else is using it please also give the new branch a try and let me know how it works. -Ben From fungi at yuggoth.org Fri Dec 14 18:50:43 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 14 Dec 2018 18:50:43 +0000 Subject: [dev][openstacksdk][infra] openstacksdk and dogpile 0.7.0+ cache errors In-Reply-To: References: <20181214034259.GA16789@fedora19.localdomain> <20181214145007.3ftbfhscvpwibl5k@yuggoth.org> Message-ID: <20181214185043.wrph6ncynxgyhtzq@yuggoth.org> On 2018-12-14 13:03:07 -0500 (-0500), Mike Bayer wrote: [...] > not sure if this is an option but I'd be more interested if this would > be possible from my Gerrit server at https://gerrit.sqlalchemy.org. [...] Oh, yep, zuul.openstack.org can also connect to multiple Gerrit deployments, so if that's where you're doing the bulk of your code review it's possible for us to provide third-party CI results there 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 morgan.fainberg at gmail.com Fri Dec 14 19:01:14 2018 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Fri, 14 Dec 2018 11:01:14 -0800 Subject: [dev][openstacksdk][infra] openstacksdk and dogpile 0.7.0+ cache errors In-Reply-To: References: <20181214034259.GA16789@fedora19.localdomain> <20181214145007.3ftbfhscvpwibl5k@yuggoth.org> Message-ID: Yep. I didn't mean to imply the change in behavior was wrong on a pre-1.0 in this case. We will fix SDK to do a more correct thing. On Fri, Dec 14, 2018, 10:06 Mike Bayer On Fri, Dec 14, 2018 at 10:48 AM Morgan Fainberg > wrote: > > > > The issue was with OpenStack SDK. SDK is doing a strange thing and wraps > with dogpile the already bound-methods (from instantiated objects). It > turns out this isn't really needed and the solution will be to not add the > extra layer of wrapping into the SDK bits. I expect I can roll a patch for > that later today. The extra layer of wrapping was to bubble up an > .invalidate method, which strictly should have already existed when using > dogpile. I'll make sure to unroll all the potential issues and get SDK into > a sane place. > > > > In my opinion dogpile.cache is doing the right thing and assuming it is > in charge of wrapping the methods. Wrapping (with a decorator) bound > methods is a weird bit of meta-programming I don't see as necessary to > support. With that said, this was a change in behavior. > > I wasn't sure that the use of decorator instead of a homegrown was > really going to be noticeable but I guess it is. Nevertheless I did > move from 0.6.x to 0.7.x which in my own projects means > behaviorally-modifying change (my versioning scheme is physics have changed>. changes>.). > > > > > > I've been unable (need to find my hardware token) to login to github to > comment on the issue (will do this today) but I am going to comment much > the same as I have here on the mailing list. > > > > Finally, I do think we should add the feedback loop to dogpile from > openstack as we lean on it pretty heavily. I believe the big projects to > catch are SDK/shade, Keystone, Keystone Middleware, and Oslo.Cache > (oslo.cache should cover everything but openstackSDK/shade). I might be > missing bits of infra as well in this list. > > > > On Fri, Dec 14, 2018 at 6:55 AM Jeremy Stanley > wrote: > >> > >> On 2018-12-14 09:11:39 -0500 (-0500), Mike Bayer wrote: > >> [...] > >> > Are there folks here who would like to watch the dogpile.cache > >> > github project (now at > >> > https://github.com/sqlalchemy/dogpile.cache) as well as our gerrit > >> > so that future changes can get some more review? > >> > >> Alternatively, zuul.openstack.org has the ability to test pull > >> requests for GitHub repositories automatically and report back > >> configured job results (basically acting as a third-party CI > >> system). We already do this for Ansible, for example. If we can > >> identify a good set of candidate jobs to run, is this something > >> you'd be interested in? > >> -- > >> Jeremy Stanley > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kendall at openstack.org Fri Dec 14 19:02:44 2018 From: kendall at openstack.org (Kendall Waters) Date: Fri, 14 Dec 2018 13:02:44 -0600 Subject: Open Infrastructure Summit Denver Contributor Discount Information In-Reply-To: References: Message-ID: <159CF7D5-C45C-4E28-A9E3-C03A3C112C2E@openstack.org> Hi Erik, Thats a great question! Since you registered for and attended the ops-meetup at the most recent PTG, and there isn’t an ops-meetup at the next PTG, we can go ahead and send you a free code for the upcoming Summit. I'll send you a direct email next week with the code as a next step. Looking forward to seeing you in Denver in April! Cheers, Kendall Kendall Waters OpenStack Marketing & Events kendall at openstack.org > On Dec 14, 2018, at 12:06 PM, Erik McCormick wrote: > > > > On Fri, Dec 14, 2018, 12:19 PM Kendall Waters wrote: > Hi everyone, > > There have been a lot of questions about discounts for the upcoming Open Infrastructure Summit so I have outlined the contributor discounts that we will be giving out below. > > Contributor Discount (formally known as ATC or AUC discount) > 50% off any 1 ticket type until online sales close (please note ticket prices are tiered so the earlier you use your discount code, the cheaper the ticket will be) > - To qualify for this discount, you will need to either have contributed at least one commit which merged to an official governed OSF project or pilot project in the last 6 months as of January 1, 2019 or qualify as an AUC: http://superuser.openstack.org/articles/auc-community/ > - Discount codes will be sent by the end of January > > Denver 2018 PTG Attendees > 82% off the early bird price of the Summit + PTG combo ticket until early bird ends > - To qualify for this discount, you must have attended the Denver PTG in September 2018 > - Discount codes will be sent by the end of January > > For those of us that attended the last PTG but may not attend this one, will the code still cover 100% of the full summit pass? > > > Please let me know if you have any questions. > > Cheers, > Kendall > > Kendall Waters > OpenStack Marketing & Events > kendall at openstack.org > > > -Erik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnsomor at gmail.com Fri Dec 14 20:00:59 2018 From: johnsomor at gmail.com (Michael Johnson) Date: Fri, 14 Dec 2018 12:00:59 -0800 Subject: [neutron][stadium] Switch from ryu to os-ken In-Reply-To: <0957CD8F4B55C0418161614FEC580D6B308A805A@yyzeml704-chm.china.huawei.com> References: <0957CD8F4B55C0418161614FEC580D6B308A805A@yyzeml704-chm.china.huawei.com> Message-ID: This is great news Hongbin. Thank you to everyone that worked on the transition to os-ken. Octavia will likely start using os-ken next year for OpenFlow. Michael On Mon, Dec 10, 2018 at 4:18 PM Hongbin Lu wrote: > > Hi all, > > > > Due to the advice that Ryu library won’t be maintained at the end of 2018, the neutron team decided to fork the Ryu library and maintain the fork, which is called os-ken [1], from now on. Right now, both neutron [2] and neutron-dynamic-routing [3] is switching over to os-ken. If other projects want to do the same, please feel free to handout to the openstack-neutron channel for helps or information. You can also find more in here: https://blueprints.launchpad.net/neutron/+spec/ryu-framework-maintenace-transition . > > > > [1] https://github.com/openstack/os-ken > > [2] https://review.openstack.org/#/c/607008/ > > [3] https://review.openstack.org/#/c/608357/ > > > > Best regards, > > Hongbin > > From torin.woltjer at granddial.com Fri Dec 14 20:11:00 2018 From: torin.woltjer at granddial.com (Torin Woltjer) Date: Fri, 14 Dec 2018 20:11:00 GMT Subject: Nova live migration fails - InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility. Message-ID: <1ec6c3aeedd3421fa6c7c1a52fbc8e0c@granddial.com> Looks like putting the same option on the other compute nodes did the trick. Originally I did that and it made no difference, but that must've been me not rebooting the test instances that were on that node during the change. Doing a cold migrate correctly updates the XML, so I'll have to cold migrate all of the production instances before I can live migrate them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Fri Dec 14 21:27:39 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Fri, 14 Dec 2018 22:27:39 +0100 Subject: bug openstack queens magnum Message-ID: Hi All, I am facing the same issue wrote at this link: https://ask.openstack.org/en/question/116465/magnum-kubernetes-cluster-stucks-in-create-in-progress-state-exactly-on-kube-master/ It happens for swarm and kubernets but works in swarm-mode. Please, help me Regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike_mp at zzzcomputing.com Fri Dec 14 22:20:05 2018 From: mike_mp at zzzcomputing.com (Mike Bayer) Date: Fri, 14 Dec 2018 17:20:05 -0500 Subject: [dev][openstacksdk][infra] openstacksdk and dogpile 0.7.0+ cache errors In-Reply-To: <20181214185043.wrph6ncynxgyhtzq@yuggoth.org> References: <20181214034259.GA16789@fedora19.localdomain> <20181214145007.3ftbfhscvpwibl5k@yuggoth.org> <20181214185043.wrph6ncynxgyhtzq@yuggoth.org> Message-ID: On Fri, Dec 14, 2018 at 1:56 PM Jeremy Stanley wrote: > > On 2018-12-14 13:03:07 -0500 (-0500), Mike Bayer wrote: > [...] > > not sure if this is an option but I'd be more interested if this would > > be possible from my Gerrit server at https://gerrit.sqlalchemy.org. > [...] > > Oh, yep, zuul.openstack.org can also connect to multiple Gerrit > deployments, so if that's where you're doing the bulk of your code > review it's possible for us to provide third-party CI results there > instead. OK, so first step is...identify some zuul jobs? I have CI for sqlalchemy, alembic, dogpile-cache that each would benefit from db /cache-centric builds. > -- > Jeremy Stanley From morgan.fainberg at gmail.com Fri Dec 14 23:03:32 2018 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Fri, 14 Dec 2018 15:03:32 -0800 Subject: [dev][openstacksdk][infra] openstacksdk and dogpile 0.7.0+ cache errors In-Reply-To: References: <20181214034259.GA16789@fedora19.localdomain> <20181214145007.3ftbfhscvpwibl5k@yuggoth.org> Message-ID: This is fixed with a quick added function wrapper before passing to dogpile's decorator/wrapper method(s) [0]. I have confirmed it has remedied the issue directly and locally, but have been unable to produce a full unit test yet. [0] https://review.openstack.org/#/c/625370/ --Morgan On Fri, Dec 14, 2018 at 10:06 AM Mike Bayer wrote: > On Fri, Dec 14, 2018 at 10:48 AM Morgan Fainberg > wrote: > > > > The issue was with OpenStack SDK. SDK is doing a strange thing and wraps > with dogpile the already bound-methods (from instantiated objects). It > turns out this isn't really needed and the solution will be to not add the > extra layer of wrapping into the SDK bits. I expect I can roll a patch for > that later today. The extra layer of wrapping was to bubble up an > .invalidate method, which strictly should have already existed when using > dogpile. I'll make sure to unroll all the potential issues and get SDK into > a sane place. > > > > In my opinion dogpile.cache is doing the right thing and assuming it is > in charge of wrapping the methods. Wrapping (with a decorator) bound > methods is a weird bit of meta-programming I don't see as necessary to > support. With that said, this was a change in behavior. > > I wasn't sure that the use of decorator instead of a homegrown was > really going to be noticeable but I guess it is. Nevertheless I did > move from 0.6.x to 0.7.x which in my own projects means > behaviorally-modifying change (my versioning scheme is physics have changed>. changes>.). > > > > > > I've been unable (need to find my hardware token) to login to github to > comment on the issue (will do this today) but I am going to comment much > the same as I have here on the mailing list. > > > > Finally, I do think we should add the feedback loop to dogpile from > openstack as we lean on it pretty heavily. I believe the big projects to > catch are SDK/shade, Keystone, Keystone Middleware, and Oslo.Cache > (oslo.cache should cover everything but openstackSDK/shade). I might be > missing bits of infra as well in this list. > > > > On Fri, Dec 14, 2018 at 6:55 AM Jeremy Stanley > wrote: > >> > >> On 2018-12-14 09:11:39 -0500 (-0500), Mike Bayer wrote: > >> [...] > >> > Are there folks here who would like to watch the dogpile.cache > >> > github project (now at > >> > https://github.com/sqlalchemy/dogpile.cache) as well as our gerrit > >> > so that future changes can get some more review? > >> > >> Alternatively, zuul.openstack.org has the ability to test pull > >> requests for GitHub repositories automatically and report back > >> configured job results (basically acting as a third-party CI > >> system). We already do this for Ansible, for example. If we can > >> identify a good set of candidate jobs to run, is this something > >> you'd be interested in? > >> -- > >> Jeremy Stanley > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Fri Dec 14 23:32:00 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 14 Dec 2018 23:32:00 +0000 Subject: [dev][openstacksdk][infra] openstacksdk and dogpile 0.7.0+ cache errors In-Reply-To: References: <20181214034259.GA16789@fedora19.localdomain> <20181214145007.3ftbfhscvpwibl5k@yuggoth.org> <20181214185043.wrph6ncynxgyhtzq@yuggoth.org> Message-ID: <20181214233200.tu4apx6zn6grbsic@yuggoth.org> On 2018-12-14 17:20:05 -0500 (-0500), Mike Bayer wrote: [...] > OK, so first step is...identify some zuul jobs? I have CI for > sqlalchemy, alembic, dogpile-cache that each would benefit from db > /cache-centric builds. I mean, if there's a job which was failing immediately after the release in our CI system and we think that's a reasonable integration test to perform, we could work out a way to have it install dogpile from the master branch source instead of a released package. I've not been following that part of the discussion closely (maybe some OpenStack-SDK job?) but presumably others on this thread can make recommendations. -- 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 info at openlabtesting.org Sat Dec 15 02:15:22 2018 From: info at openlabtesting.org (Melvin Hillsman) Date: Fri, 14 Dec 2018 20:15:22 -0600 Subject: [openlab] Maintenance Notification Message-ID: Hi everyone, Maintenance will be happening 12/19/2018 and 12/20/2018 so if you experience any issues we do apologize. Not everyone will be affected but it is just good to know these things even if you are not. Additionally we will not be able to onboard any new requests/projects/individuals during this time more than likely but please do fill out any requests and we will proceed as normal. If there is an issue we will work through as much as we can to fulfill requests. Kind regards, OpenLab -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.davis at suse.com Sat Dec 15 03:49:52 2018 From: joseph.davis at suse.com (Joseph Davis) Date: Fri, 14 Dec 2018 19:49:52 -0800 Subject: [vitrage][monasca] Monasca datasource for Vitrage In-Reply-To: References: Message-ID: I left Bartosz some comments on his review, and I'll add a few things below. joseph On 12/13/18 12:52 AM, openstack-discuss-request at lists.openstack.org wrote > From: Ifat Afek > Message-ID: > > > Hi Witek, > > On Wed, Dec 12, 2018 at 5:04 PM Bedyk, Witold > wrote: > > >>> There is one issue that we need to close though – how to connect the >>> Monasca alarms to the resources in Vitrage. >>> In order to connect an alarm to a resource, Vitrage should be able to >>> identify that resource in its entity graph using the dimensions coming from >>> Monasca. I understood that these dimensions are configurable and not >>> pre-defined. >> Correct. To make the picture complete: every alarm contains an associated >> `metric name` and a set of dimensions which identify the monitored >> resource. Both metric name and dimensions could potentially be used in >> Vitrage. >> >> >> >> 1. For OpenStack services we typically use dimension keys `hostname` and >> `service`. Examples would be: >> >> `name`: `http_status`, `dimensions`: {`hostname`: `node1`, >> `service`: `keystone`, `url`: `http://node1/identity` >> } >> >> >> >> Libvirt metrics all have the dimension keys `hostname`, >> `service`=`compute`, `resource_id`=instance_id >> > > By instance_id do you mean the libvirt id or the OpenStack UUID? In order > to correlate the id with the vm that exists in Vitrage, we need the Nova > UUID. > Another question: are these dimensions names always the same? Is it > possible to change their names? > I believe it is the OpenStack id in each case. Dimension names are always the same per type of metric, but different metrics can define different dimensions. For example, the http_status metric has a 'url' but disk.space_used_perc has a 'device' and cpu.idle_perc has neither.  All metrics have 'hostname', 'service', and a few other dimensions in common. >> 2. For other resources I’m not sure if we can define a general rule for >> assignments. As you have said, the unique information may be included in >> more the one dimension. >> >> >> >> For Prometheus, we use labels on each metric as dimensions. Additional >> dimensions can be configured in agent per Prometheus endpoint. >> We also have a monasca-ceilometer component (aka. Ceilosca) that can send metrics from Ceilometer to Monasca. These metrics include the OpenStack resource_id of the source of the metric. Any alarms created from Ceilometer data can carry through that resource_id. From what I've seen we don't currently include a resource_type, but that should be something we can configure in the metric. If nothing else, we may be able to statically define the resource_type as part of the metric definition (each alarm will be specific to the type of resource anyway).  But don't hold me to that - I have some more reading to do to understand the nuances. :) The dimensions from the metrics are carried over to the alarms. > > Can you give us some more examples of Monasca dimensions? As Witek said, the metric dimensions are pretty flexible. You can see some of the dimensions mentioned in my answer above. I can try to pull a list of some standard alarm definitions and associated metrics from a SUSE install, or if we have a particular few alarms we want to start with then we can focus on those. From dangtrinhnt at gmail.com Sat Dec 15 13:28:20 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Sat, 15 Dec 2018 22:28:20 +0900 Subject: [openstack-community] Asking for suggestion of video conference tool for team and webinar In-Reply-To: References: Message-ID: I just tried Jitsi and the experience was amazing! Thank everyone for the suggestion! :) On Sat, Nov 17, 2018 at 9:59 AM Trinh Nguyen wrote: > Thank Thierry, Arun, and everybody for all the suggestions. My team will > try these tools. > > On Thu, Nov 8, 2018 at 3:23 AM Arun Kumar Khan > wrote: > >> >> On Tue, Nov 6, 2018 at 5:36 AM Trinh Nguyen >> wrote: >> >>> Hi, >>> >>> I tried several free tools for team meetings, vPTG, and webinars but >>> there are always drawbacks ( because it's free, of course). For example: >>> >>> - Google Hangout: only allow a maximum of 10 people to do the video >>> calls >>> - Zoom: limits about 45m per meeting. So for a webinar or conference >>> call takes more than 45m we have to splits into 2 sessions or so. >>> >>> If anyone in the community can suggest some better video conferencing >>> tools, that would be great. So we can organize better communication for our >>> team and the community's webinars. >>> >> >> All good suggestions. >> >> A couple of other options: >> >> 1. https://hubl.in -- open source i.e. you can host your own or use the >> hosted version at https://hubl.in/ >> 2. Wire.com -- open source with mobile apps. >> >> Let us know which solution works out for you. >> >> -- Arun Khan >> > > > -- > *Trinh Nguyen* > *www.edlab.xyz * > > -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From soheil.ir08 at gmail.com Sat Dec 15 07:41:10 2018 From: soheil.ir08 at gmail.com (Soheil Pourbafrani) Date: Sat, 15 Dec 2018 11:11:10 +0330 Subject: [OpenStack][RabbitMQ] nove-compute running on controller node can not connect to rabbitmq Message-ID: Hi, I have 2 nodes on my OpenStack cluster. One act as both the controller node and the compute node and the other act as the compute node. All services were running well for days until I activate a new NIC interface to the controller node. Now the problem is the nova-compute service of the compute node can connect to the RabittMQ server but the nova-compute service of the controller node connecting to the RabiitMQ server got an error and fails. Here are the RabbitMQ logs when I start nova-compute service on the controller node: =INFO REPORT==== 15-Dec-2018::11:02:15 === Connection <0.3414.0> (192.168.0.31:35254 -> 192.168.0.31:5672) has a client-provided name: nova-compute:7425:5fb041db-c884-4c5a-86a5-6c7a490c2471 =INFO REPORT==== 15-Dec-2018::11:02:15 === accepting AMQP connection <0.3431.0> (192.168.0.31:35256 -> 192.168.0.31:5672) =INFO REPORT==== 15-Dec-2018::11:02:15 === Connection <0.3431.0> (192.168.0.31:35256 -> 192.168.0.31:5672) has a client-provided name: nova-compute:7425:911fbbc4-1cfa-45f2-a65b-23c7fb0a4aee =WARNING REPORT==== 15-Dec-2018::11:02:15 === closing AMQP connection <0.3414.0> (192.168.0.31:35254 -> 192.168.0.31:5672 - nova-compute:7425:5fb041db-c884-4c5a-86a5-6c7a490c2471): client unexpectedly closed TCP connection =WARNING REPORT==== 15-Dec-2018::11:02:15 === closing AMQP connection <0.3431.0> (192.168.0.31:35256 -> 192.168.0.31:5672 - nova-compute:7425:911fbbc4-1cfa-45f2-a65b-23c7fb0a4aee): client unexpectedly closed TCP connection =INFO REPORT==== 15-Dec-2018::11:02:21 === accepting AMQP connection <0.3446.0> (192.168.0.31:35316 -> 192.168.0.31:5672) =INFO REPORT==== 15-Dec-2018::11:02:21 === Connection <0.3446.0> (192.168.0.31:35316 -> 192.168.0.31:5672) has a client-provided name: nova-compute:7438:cac8d67b-6f5a-426d-8d03-a18c8d5a7e5a =INFO REPORT==== 15-Dec-2018::11:02:21 === accepting AMQP connection <0.3463.0> (192.168.0.31:35318 -> 192.168.0.31:5672) =INFO REPORT==== 15-Dec-2018::11:02:21 === Connection <0.3463.0> (192.168.0.31:35318 -> 192.168.0.31:5672) has a client-provided name: nova-compute:7438:b06139fd-8294-4c21-a5c3-6e1ccb45fe6f =WARNING REPORT==== 15-Dec-2018::11:02:21 === closing AMQP connection <0.3446.0> (192.168.0.31:35316 -> 192.168.0.31:5672 - nova-compute:7438:cac8d67b-6f5a-426d-8d03-a18c8d5a7e5a): client unexpectedly closed TCP connection =WARNING REPORT==== 15-Dec-2018::11:02:21 === closing AMQP connection <0.3463.0> (192.168.0.31:35318 -> 192.168.0.31:5672 - nova-compute:7438:b06139fd-8294-4c21-a5c3-6e1ccb45fe6f): client unexpectedly closed TCP connection What is the problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufar at onf-ambassador.org Sat Dec 15 17:54:03 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Sun, 16 Dec 2018 00:54:03 +0700 Subject: [magnum] cluster node fail to establish connection (wrong IP address) Message-ID: Hi I am creating a swarm cluster with this command : - openstack coe cluster template create swarm-cluster-template --image fedora-atomic-latest --external-network external --dns-nameserver 8.8.8.8 --master-flavor m1.small --flavor m1.small --coe swarm-mode --docker-volume-size 4 --docker-storage-driver=devicemapper - openstack coe cluster create swarm-cluster --cluster-template swarm-cluster-template --master-count 1 --node-count 1 --keypair mykey but its stack on *swarm_primary_master *heat with *CREATE_IN_PROGRESS*. I try to login into swarm VM and see the log. I get this : - requests.exceptions.ConnectionError: HTTPConnectionPool(host='10.60.60.10', port=5000): Max retries exceeded with url: /v3/auth/tokens (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 110] Connection timed out',)) - Cloud-init v. 0.7.9 running 'modules:final' at Sat, 15 Dec 2018 17:36:44 +0000. Up 33.29 seconds. Swarm Instance try to open connection to 10.60.60.10 which is my management ip address on OpenStack. But it cannot (by design it cannot, I try to curl manual to 10.60.60.10 and error). When curl to 10.61.61.10 which is my floating IP and external IP for OpenStack cluster, it works. Anyone know how to change the cloud-init to curl into 10.61.61.10? Best Regards, Zufar Dhiyaulhaq -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufar at onf-ambassador.org Sat Dec 15 18:01:32 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Sun, 16 Dec 2018 01:01:32 +0700 Subject: [magnum] region_name needs to be configured in magnum.conf In-Reply-To: References: Message-ID: Hi thank you, this solves my issue. Best Regards, Zufar Dhiyaulhaq On Sat, Dec 15, 2018 at 1:26 AM Ignazio Cassano wrote: > Hi Zufar, Yes it is possible but if you want persistent storage you need > cinder. > Magnum can use cinder. > Ignazio > > Il giorno Ven 14 Dic 2018 13:24 Zufar Dhiyaulhaq > ha scritto: > >> Hi Ignazio, >> >> my OpenStack does not have cinder deployed. it is possible? >> >> Best Regards, >> Zufar Dhiyaulhaq >> >> >> On Fri, Dec 14, 2018 at 7:20 PM Ignazio Cassano >> wrote: >> >>> I did not get this error but in magnum.conf I have the following section: >>> [cinder_client] >>> >>> # >>> # From magnum.conf >>> # >>> >>> # Region in Identity service catalog to use for communication with the >>> # OpenStack service. (string value) >>> region_name = RegionOne >>> >>> >>> >>> Il giorno ven 14 dic 2018 alle ore 12:33 Zufar Dhiyaulhaq < >>> zufar at onf-ambassador.org> ha scritto: >>> >>>> I am following installation guide from magnum documentation. but I get >>>> an error when trying to create kubernetes cluster. >>>> >>>> *region_name needs to be configured in magnum.conf* >>>> >>>> this is my full log : >>>> >>>> [root at zu-bssn-controller1 opt]# openstack coe cluster create >>>> kubernetes-cluster --cluster-template kubernetes-cluster-template >>>> --master-count 1 --node-count 1 --keypair mykeyRequest to create cluster >>>> bfdf76df-8b43-44e3-a094-90a76189610a accepted >>>> [root at zu-bssn-controller1 opt]# openstack coe cluster list >>>> >>>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>>> | uuid | name | keypair | >>>> node_count | master_count | status | >>>> >>>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>>> | bfdf76df-8b43-44e3-a094-90a76189610a | kubernetes-cluster | mykey >>>> | 1 | 1 | CREATE_FAILED | >>>> >>>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>>> [root at zu-bssn-controller1 opt]# openstack coe cluster show >>>> kubernetes-cluster >>>> >>>> +---------------------+---------------------------------------------------+ >>>> | Field | >>>> Value | >>>> >>>> +---------------------+---------------------------------------------------+ >>>> | status | >>>> CREATE_FAILED | >>>> | cluster_template_id | >>>> 560f72a9-d6ac-4404-ad9e-3cd129496022 | >>>> | node_addresses | >>>> [] | >>>> | uuid | >>>> bfdf76df-8b43-44e3-a094-90a76189610a | >>>> | stack_id | >>>> None | >>>> | status_reason | region_name needs to be configured in >>>> magnum.conf | >>>> | created_at | >>>> 2018-12-14T11:25:37+00:00 | >>>> | updated_at | >>>> 2018-12-14T11:25:40+00:00 | >>>> | coe_version | >>>> None | >>>> | labels | >>>> {} | >>>> | faults | >>>> {} | >>>> | keypair | >>>> mykey | >>>> | api_address | >>>> None | >>>> | master_addresses | >>>> [] | >>>> | create_timeout | >>>> 60 | >>>> | node_count | >>>> 1 | >>>> | discovery_url | >>>> None | >>>> | master_count | >>>> 1 | >>>> | container_version | >>>> None | >>>> | name | >>>> kubernetes-cluster | >>>> | master_flavor_id | >>>> amphora | >>>> | flavor_id | >>>> amphora | >>>> >>>> +---------------------+---------------------------------------------------+ >>>> [root at zu-bssn-controller1 opt]# >>>> >>>> Anyone know what is happening? >>>> >>>> Best Regards, >>>> Zufar Dhiyaulhaq >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Sat Dec 15 18:04:20 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sat, 15 Dec 2018 19:04:20 +0100 Subject: [magnum] region_name needs to be configured in magnum.conf In-Reply-To: References: Message-ID: Do you mean upgrading to Rocky solved kubernetes cluster issue? Il giorno Sab 15 Dic 2018 19:01 Zufar Dhiyaulhaq ha scritto: > Hi thank you, > > this solves my issue. > > Best Regards, > Zufar Dhiyaulhaq > > > On Sat, Dec 15, 2018 at 1:26 AM Ignazio Cassano > wrote: > >> Hi Zufar, Yes it is possible but if you want persistent storage you need >> cinder. >> Magnum can use cinder. >> Ignazio >> >> Il giorno Ven 14 Dic 2018 13:24 Zufar Dhiyaulhaq < >> zufar at onf-ambassador.org> ha scritto: >> >>> Hi Ignazio, >>> >>> my OpenStack does not have cinder deployed. it is possible? >>> >>> Best Regards, >>> Zufar Dhiyaulhaq >>> >>> >>> On Fri, Dec 14, 2018 at 7:20 PM Ignazio Cassano < >>> ignaziocassano at gmail.com> wrote: >>> >>>> I did not get this error but in magnum.conf I have the following >>>> section: >>>> [cinder_client] >>>> >>>> # >>>> # From magnum.conf >>>> # >>>> >>>> # Region in Identity service catalog to use for communication with the >>>> # OpenStack service. (string value) >>>> region_name = RegionOne >>>> >>>> >>>> >>>> Il giorno ven 14 dic 2018 alle ore 12:33 Zufar Dhiyaulhaq < >>>> zufar at onf-ambassador.org> ha scritto: >>>> >>>>> I am following installation guide from magnum documentation. but I get >>>>> an error when trying to create kubernetes cluster. >>>>> >>>>> *region_name needs to be configured in magnum.conf* >>>>> >>>>> this is my full log : >>>>> >>>>> [root at zu-bssn-controller1 opt]# openstack coe cluster create >>>>> kubernetes-cluster --cluster-template kubernetes-cluster-template >>>>> --master-count 1 --node-count 1 --keypair mykeyRequest to create cluster >>>>> bfdf76df-8b43-44e3-a094-90a76189610a accepted >>>>> [root at zu-bssn-controller1 opt]# openstack coe cluster list >>>>> >>>>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>>>> | uuid | name | keypair >>>>> | node_count | master_count | status | >>>>> >>>>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>>>> | bfdf76df-8b43-44e3-a094-90a76189610a | kubernetes-cluster | mykey >>>>> | 1 | 1 | CREATE_FAILED | >>>>> >>>>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>>>> [root at zu-bssn-controller1 opt]# openstack coe cluster show >>>>> kubernetes-cluster >>>>> >>>>> +---------------------+---------------------------------------------------+ >>>>> | Field | >>>>> Value | >>>>> >>>>> +---------------------+---------------------------------------------------+ >>>>> | status | >>>>> CREATE_FAILED | >>>>> | cluster_template_id | >>>>> 560f72a9-d6ac-4404-ad9e-3cd129496022 | >>>>> | node_addresses | >>>>> [] | >>>>> | uuid | >>>>> bfdf76df-8b43-44e3-a094-90a76189610a | >>>>> | stack_id | >>>>> None | >>>>> | status_reason | region_name needs to be configured in >>>>> magnum.conf | >>>>> | created_at | >>>>> 2018-12-14T11:25:37+00:00 | >>>>> | updated_at | >>>>> 2018-12-14T11:25:40+00:00 | >>>>> | coe_version | >>>>> None | >>>>> | labels | >>>>> {} | >>>>> | faults | >>>>> {} | >>>>> | keypair | >>>>> mykey | >>>>> | api_address | >>>>> None | >>>>> | master_addresses | >>>>> [] | >>>>> | create_timeout | >>>>> 60 | >>>>> | node_count | >>>>> 1 | >>>>> | discovery_url | >>>>> None | >>>>> | master_count | >>>>> 1 | >>>>> | container_version | >>>>> None | >>>>> | name | >>>>> kubernetes-cluster | >>>>> | master_flavor_id | >>>>> amphora | >>>>> | flavor_id | >>>>> amphora | >>>>> >>>>> +---------------------+---------------------------------------------------+ >>>>> [root at zu-bssn-controller1 opt]# >>>>> >>>>> Anyone know what is happening? >>>>> >>>>> Best Regards, >>>>> Zufar Dhiyaulhaq >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Sat Dec 15 18:08:15 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sat, 15 Dec 2018 19:08:15 +0100 Subject: [magnum] cluster node fail to establish connection (wrong IP address) In-Reply-To: References: Message-ID: Zufar, the master node must communicat with port 5000 on the network where you deployed keystone endpoint. Ignazio Il giorno Sab 15 Dic 2018 18:58 Zufar Dhiyaulhaq ha scritto: > Hi I am creating a swarm cluster with this command : > > - openstack coe cluster template create swarm-cluster-template --image > fedora-atomic-latest --external-network external --dns-nameserver 8.8.8.8 > --master-flavor m1.small --flavor m1.small --coe swarm-mode > --docker-volume-size 4 --docker-storage-driver=devicemapper > - openstack coe cluster create swarm-cluster --cluster-template > swarm-cluster-template --master-count 1 --node-count 1 --keypair mykey > > but its stack on *swarm_primary_master *heat with *CREATE_IN_PROGRESS*. I > try to login into swarm VM and see the log. > > I get this : > > > - requests.exceptions.ConnectionError: > HTTPConnectionPool(host='10.60.60.10', port=5000): Max retries exceeded > with url: /v3/auth/tokens (Caused by > NewConnectionError(' 0x7f02f57321d0>: Failed to establish a new connection: [Errno 110] > Connection timed out',)) > - Cloud-init v. 0.7.9 running 'modules:final' at Sat, 15 Dec 2018 > 17:36:44 +0000. Up 33.29 seconds. > > > Swarm Instance try to open connection to 10.60.60.10 which is my > management ip address on OpenStack. But it cannot (by design it cannot, I > try to curl manual to 10.60.60.10 and error). When curl to 10.61.61.10 > which is my floating IP and external IP for OpenStack cluster, it works. > > Anyone know how to change the cloud-init to curl into 10.61.61.10? > > Best Regards, > Zufar Dhiyaulhaq > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufar at onf-ambassador.org Sat Dec 15 18:10:34 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Sun, 16 Dec 2018 01:10:34 +0700 Subject: [magnum] region_name needs to be configured in magnum.conf In-Reply-To: References: Message-ID: No, it is a different issue. I am still stuck when creating a cluster (swarm or kubernetes) because of this error that i find in cloud-init log. - requests.exceptions.ConnectionError: HTTPConnectionPool(host='10.60.60.10', port=5000): Max retries exceeded with url: /v3/auth/tokens (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 110] Connection timed out',)) Swarm Instance try to open connection to 10.60.60.10 which is my management IP address on OpenStack. But it cannot (by design it cannot, I try to curl manual to 10.60.60.10 and error). When curl to 10.61.61.10 which is my floating IP and external IP for OpenStack cluster, it works. Do you know how to change the URL that installed inside the cloud-init? Best Regards, Zufar Dhiyaulhaq On Sun, Dec 16, 2018 at 1:04 AM Ignazio Cassano wrote: > Do you mean upgrading to Rocky solved kubernetes cluster issue? > > Il giorno Sab 15 Dic 2018 19:01 Zufar Dhiyaulhaq > ha scritto: > >> Hi thank you, >> >> this solves my issue. >> >> Best Regards, >> Zufar Dhiyaulhaq >> >> >> On Sat, Dec 15, 2018 at 1:26 AM Ignazio Cassano >> wrote: >> >>> Hi Zufar, Yes it is possible but if you want persistent storage you need >>> cinder. >>> Magnum can use cinder. >>> Ignazio >>> >>> Il giorno Ven 14 Dic 2018 13:24 Zufar Dhiyaulhaq < >>> zufar at onf-ambassador.org> ha scritto: >>> >>>> Hi Ignazio, >>>> >>>> my OpenStack does not have cinder deployed. it is possible? >>>> >>>> Best Regards, >>>> Zufar Dhiyaulhaq >>>> >>>> >>>> On Fri, Dec 14, 2018 at 7:20 PM Ignazio Cassano < >>>> ignaziocassano at gmail.com> wrote: >>>> >>>>> I did not get this error but in magnum.conf I have the following >>>>> section: >>>>> [cinder_client] >>>>> >>>>> # >>>>> # From magnum.conf >>>>> # >>>>> >>>>> # Region in Identity service catalog to use for communication with the >>>>> # OpenStack service. (string value) >>>>> region_name = RegionOne >>>>> >>>>> >>>>> >>>>> Il giorno ven 14 dic 2018 alle ore 12:33 Zufar Dhiyaulhaq < >>>>> zufar at onf-ambassador.org> ha scritto: >>>>> >>>>>> I am following installation guide from magnum documentation. but I >>>>>> get an error when trying to create kubernetes cluster. >>>>>> >>>>>> *region_name needs to be configured in magnum.conf* >>>>>> >>>>>> this is my full log : >>>>>> >>>>>> [root at zu-bssn-controller1 opt]# openstack coe cluster create >>>>>> kubernetes-cluster --cluster-template kubernetes-cluster-template >>>>>> --master-count 1 --node-count 1 --keypair mykeyRequest to create cluster >>>>>> bfdf76df-8b43-44e3-a094-90a76189610a accepted >>>>>> [root at zu-bssn-controller1 opt]# openstack coe cluster list >>>>>> >>>>>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>>>>> | uuid | name | keypair >>>>>> | node_count | master_count | status | >>>>>> >>>>>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>>>>> | bfdf76df-8b43-44e3-a094-90a76189610a | kubernetes-cluster | mykey >>>>>> | 1 | 1 | CREATE_FAILED | >>>>>> >>>>>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>>>>> [root at zu-bssn-controller1 opt]# openstack coe cluster show >>>>>> kubernetes-cluster >>>>>> >>>>>> +---------------------+---------------------------------------------------+ >>>>>> | Field | >>>>>> Value | >>>>>> >>>>>> +---------------------+---------------------------------------------------+ >>>>>> | status | >>>>>> CREATE_FAILED | >>>>>> | cluster_template_id | >>>>>> 560f72a9-d6ac-4404-ad9e-3cd129496022 | >>>>>> | node_addresses | >>>>>> [] | >>>>>> | uuid | >>>>>> bfdf76df-8b43-44e3-a094-90a76189610a | >>>>>> | stack_id | >>>>>> None | >>>>>> | status_reason | region_name needs to be configured in >>>>>> magnum.conf | >>>>>> | created_at | >>>>>> 2018-12-14T11:25:37+00:00 | >>>>>> | updated_at | >>>>>> 2018-12-14T11:25:40+00:00 | >>>>>> | coe_version | >>>>>> None | >>>>>> | labels | >>>>>> {} | >>>>>> | faults | >>>>>> {} | >>>>>> | keypair | >>>>>> mykey | >>>>>> | api_address | >>>>>> None | >>>>>> | master_addresses | >>>>>> [] | >>>>>> | create_timeout | >>>>>> 60 | >>>>>> | node_count | >>>>>> 1 | >>>>>> | discovery_url | >>>>>> None | >>>>>> | master_count | >>>>>> 1 | >>>>>> | container_version | >>>>>> None | >>>>>> | name | >>>>>> kubernetes-cluster | >>>>>> | master_flavor_id | >>>>>> amphora | >>>>>> | flavor_id | >>>>>> amphora | >>>>>> >>>>>> +---------------------+---------------------------------------------------+ >>>>>> [root at zu-bssn-controller1 opt]# >>>>>> >>>>>> Anyone know what is happening? >>>>>> >>>>>> Best Regards, >>>>>> Zufar Dhiyaulhaq >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Sat Dec 15 18:11:08 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sat, 15 Dec 2018 19:11:08 +0100 Subject: [magnum] region_name needs to be configured in magnum.conf In-Reply-To: References: Message-ID: Probably it means it solves the region error. ...sorry. Ignazio Il giorno Sab 15 Dic 2018 19:01 Zufar Dhiyaulhaq ha scritto: > Hi thank you, > > this solves my issue. > > Best Regards, > Zufar Dhiyaulhaq > > > On Sat, Dec 15, 2018 at 1:26 AM Ignazio Cassano > wrote: > >> Hi Zufar, Yes it is possible but if you want persistent storage you need >> cinder. >> Magnum can use cinder. >> Ignazio >> >> Il giorno Ven 14 Dic 2018 13:24 Zufar Dhiyaulhaq < >> zufar at onf-ambassador.org> ha scritto: >> >>> Hi Ignazio, >>> >>> my OpenStack does not have cinder deployed. it is possible? >>> >>> Best Regards, >>> Zufar Dhiyaulhaq >>> >>> >>> On Fri, Dec 14, 2018 at 7:20 PM Ignazio Cassano < >>> ignaziocassano at gmail.com> wrote: >>> >>>> I did not get this error but in magnum.conf I have the following >>>> section: >>>> [cinder_client] >>>> >>>> # >>>> # From magnum.conf >>>> # >>>> >>>> # Region in Identity service catalog to use for communication with the >>>> # OpenStack service. (string value) >>>> region_name = RegionOne >>>> >>>> >>>> >>>> Il giorno ven 14 dic 2018 alle ore 12:33 Zufar Dhiyaulhaq < >>>> zufar at onf-ambassador.org> ha scritto: >>>> >>>>> I am following installation guide from magnum documentation. but I get >>>>> an error when trying to create kubernetes cluster. >>>>> >>>>> *region_name needs to be configured in magnum.conf* >>>>> >>>>> this is my full log : >>>>> >>>>> [root at zu-bssn-controller1 opt]# openstack coe cluster create >>>>> kubernetes-cluster --cluster-template kubernetes-cluster-template >>>>> --master-count 1 --node-count 1 --keypair mykeyRequest to create cluster >>>>> bfdf76df-8b43-44e3-a094-90a76189610a accepted >>>>> [root at zu-bssn-controller1 opt]# openstack coe cluster list >>>>> >>>>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>>>> | uuid | name | keypair >>>>> | node_count | master_count | status | >>>>> >>>>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>>>> | bfdf76df-8b43-44e3-a094-90a76189610a | kubernetes-cluster | mykey >>>>> | 1 | 1 | CREATE_FAILED | >>>>> >>>>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>>>> [root at zu-bssn-controller1 opt]# openstack coe cluster show >>>>> kubernetes-cluster >>>>> >>>>> +---------------------+---------------------------------------------------+ >>>>> | Field | >>>>> Value | >>>>> >>>>> +---------------------+---------------------------------------------------+ >>>>> | status | >>>>> CREATE_FAILED | >>>>> | cluster_template_id | >>>>> 560f72a9-d6ac-4404-ad9e-3cd129496022 | >>>>> | node_addresses | >>>>> [] | >>>>> | uuid | >>>>> bfdf76df-8b43-44e3-a094-90a76189610a | >>>>> | stack_id | >>>>> None | >>>>> | status_reason | region_name needs to be configured in >>>>> magnum.conf | >>>>> | created_at | >>>>> 2018-12-14T11:25:37+00:00 | >>>>> | updated_at | >>>>> 2018-12-14T11:25:40+00:00 | >>>>> | coe_version | >>>>> None | >>>>> | labels | >>>>> {} | >>>>> | faults | >>>>> {} | >>>>> | keypair | >>>>> mykey | >>>>> | api_address | >>>>> None | >>>>> | master_addresses | >>>>> [] | >>>>> | create_timeout | >>>>> 60 | >>>>> | node_count | >>>>> 1 | >>>>> | discovery_url | >>>>> None | >>>>> | master_count | >>>>> 1 | >>>>> | container_version | >>>>> None | >>>>> | name | >>>>> kubernetes-cluster | >>>>> | master_flavor_id | >>>>> amphora | >>>>> | flavor_id | >>>>> amphora | >>>>> >>>>> +---------------------+---------------------------------------------------+ >>>>> [root at zu-bssn-controller1 opt]# >>>>> >>>>> Anyone know what is happening? >>>>> >>>>> Best Regards, >>>>> Zufar Dhiyaulhaq >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufar at onf-ambassador.org Sat Dec 15 18:12:57 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Sun, 16 Dec 2018 01:12:57 +0700 Subject: [magnum] cluster node fail to establish connection (wrong IP address) In-Reply-To: References: Message-ID: Yes. Master Node communicates with port 5000, but with a wrong IP address. Floating IP give to my instance is in 10.61.61.0/24 but all of my endpoints are in 10.60.60.0/24, but when I try to curl manual the endpoint with 10.61.61.0/24 it's working fine. It is possible to change the IP address installed on cloud-init to 10.61.61.X? Best Regards, Zufar Dhiyaulhaq On Sun, Dec 16, 2018 at 1:08 AM Ignazio Cassano wrote: > Zufar, the master node must communicat with port 5000 on the network where > you deployed keystone endpoint. > Ignazio > Il giorno Sab 15 Dic 2018 18:58 Zufar Dhiyaulhaq > ha scritto: > >> Hi I am creating a swarm cluster with this command : >> >> - openstack coe cluster template create swarm-cluster-template >> --image fedora-atomic-latest --external-network external --dns-nameserver >> 8.8.8.8 --master-flavor m1.small --flavor m1.small --coe swarm-mode >> --docker-volume-size 4 --docker-storage-driver=devicemapper >> - openstack coe cluster create swarm-cluster --cluster-template >> swarm-cluster-template --master-count 1 --node-count 1 --keypair mykey >> >> but its stack on *swarm_primary_master *heat with *CREATE_IN_PROGRESS*. >> I try to login into swarm VM and see the log. >> >> I get this : >> >> >> - requests.exceptions.ConnectionError: >> HTTPConnectionPool(host='10.60.60.10', port=5000): Max retries exceeded >> with url: /v3/auth/tokens (Caused by >> NewConnectionError('> 0x7f02f57321d0>: Failed to establish a new connection: [Errno 110] >> Connection timed out',)) >> - Cloud-init v. 0.7.9 running 'modules:final' at Sat, 15 Dec 2018 >> 17:36:44 +0000. Up 33.29 seconds. >> >> >> Swarm Instance try to open connection to 10.60.60.10 which is my >> management ip address on OpenStack. But it cannot (by design it cannot, I >> try to curl manual to 10.60.60.10 and error). When curl to 10.61.61.10 >> which is my floating IP and external IP for OpenStack cluster, it works. >> >> Anyone know how to change the cloud-init to curl into 10.61.61.10? >> >> Best Regards, >> Zufar Dhiyaulhaq >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Sat Dec 15 18:15:39 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sat, 15 Dec 2018 19:15:39 +0100 Subject: [magnum] region_name needs to be configured in magnum.conf In-Reply-To: References: Message-ID: The master node needs to speak with port 5000 where you deployed keystone endpoint. I think you must modify heat.conf under clients_keystone section. Il giorno Sab 15 Dic 2018 19:10 Zufar Dhiyaulhaq ha scritto: > No, it is a different issue. I am still stuck when creating a cluster > (swarm or kubernetes) because of this error that i find in cloud-init log. > > - requests.exceptions.ConnectionError: > HTTPConnectionPool(host='10.60.60.10', port=5000): Max retries exceeded > with url: /v3/auth/tokens (Caused by > NewConnectionError(' 0x7f02f57321d0>: Failed to establish a new connection: [Errno 110] > Connection timed out',)) > > Swarm Instance try to open connection to 10.60.60.10 which is my > management IP address on OpenStack. But it cannot (by design it cannot, I > try to curl manual to 10.60.60.10 and error). When curl to 10.61.61.10 > which is my floating IP and external IP for OpenStack cluster, it works. > > Do you know how to change the URL that installed inside the cloud-init? > > Best Regards, > Zufar Dhiyaulhaq > > > On Sun, Dec 16, 2018 at 1:04 AM Ignazio Cassano > wrote: > >> Do you mean upgrading to Rocky solved kubernetes cluster issue? >> >> Il giorno Sab 15 Dic 2018 19:01 Zufar Dhiyaulhaq < >> zufar at onf-ambassador.org> ha scritto: >> >>> Hi thank you, >>> >>> this solves my issue. >>> >>> Best Regards, >>> Zufar Dhiyaulhaq >>> >>> >>> On Sat, Dec 15, 2018 at 1:26 AM Ignazio Cassano < >>> ignaziocassano at gmail.com> wrote: >>> >>>> Hi Zufar, Yes it is possible but if you want persistent storage you >>>> need cinder. >>>> Magnum can use cinder. >>>> Ignazio >>>> >>>> Il giorno Ven 14 Dic 2018 13:24 Zufar Dhiyaulhaq < >>>> zufar at onf-ambassador.org> ha scritto: >>>> >>>>> Hi Ignazio, >>>>> >>>>> my OpenStack does not have cinder deployed. it is possible? >>>>> >>>>> Best Regards, >>>>> Zufar Dhiyaulhaq >>>>> >>>>> >>>>> On Fri, Dec 14, 2018 at 7:20 PM Ignazio Cassano < >>>>> ignaziocassano at gmail.com> wrote: >>>>> >>>>>> I did not get this error but in magnum.conf I have the following >>>>>> section: >>>>>> [cinder_client] >>>>>> >>>>>> # >>>>>> # From magnum.conf >>>>>> # >>>>>> >>>>>> # Region in Identity service catalog to use for communication with the >>>>>> # OpenStack service. (string value) >>>>>> region_name = RegionOne >>>>>> >>>>>> >>>>>> >>>>>> Il giorno ven 14 dic 2018 alle ore 12:33 Zufar Dhiyaulhaq < >>>>>> zufar at onf-ambassador.org> ha scritto: >>>>>> >>>>>>> I am following installation guide from magnum documentation. but I >>>>>>> get an error when trying to create kubernetes cluster. >>>>>>> >>>>>>> *region_name needs to be configured in magnum.conf* >>>>>>> >>>>>>> this is my full log : >>>>>>> >>>>>>> [root at zu-bssn-controller1 opt]# openstack coe cluster create >>>>>>> kubernetes-cluster --cluster-template kubernetes-cluster-template >>>>>>> --master-count 1 --node-count 1 --keypair mykeyRequest to create cluster >>>>>>> bfdf76df-8b43-44e3-a094-90a76189610a accepted >>>>>>> [root at zu-bssn-controller1 opt]# openstack coe cluster list >>>>>>> >>>>>>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>>>>>> | uuid | name | >>>>>>> keypair | node_count | master_count | status | >>>>>>> >>>>>>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>>>>>> | bfdf76df-8b43-44e3-a094-90a76189610a | kubernetes-cluster | >>>>>>> mykey | 1 | 1 | CREATE_FAILED | >>>>>>> >>>>>>> +--------------------------------------+--------------------+---------+------------+--------------+---------------+ >>>>>>> [root at zu-bssn-controller1 opt]# openstack coe cluster show >>>>>>> kubernetes-cluster >>>>>>> >>>>>>> +---------------------+---------------------------------------------------+ >>>>>>> | Field | >>>>>>> Value | >>>>>>> >>>>>>> +---------------------+---------------------------------------------------+ >>>>>>> | status | >>>>>>> CREATE_FAILED | >>>>>>> | cluster_template_id | >>>>>>> 560f72a9-d6ac-4404-ad9e-3cd129496022 | >>>>>>> | node_addresses | >>>>>>> [] | >>>>>>> | uuid | >>>>>>> bfdf76df-8b43-44e3-a094-90a76189610a | >>>>>>> | stack_id | >>>>>>> None | >>>>>>> | status_reason | region_name needs to be configured in >>>>>>> magnum.conf | >>>>>>> | created_at | >>>>>>> 2018-12-14T11:25:37+00:00 | >>>>>>> | updated_at | >>>>>>> 2018-12-14T11:25:40+00:00 | >>>>>>> | coe_version | >>>>>>> None | >>>>>>> | labels | >>>>>>> {} | >>>>>>> | faults | >>>>>>> {} | >>>>>>> | keypair | >>>>>>> mykey | >>>>>>> | api_address | >>>>>>> None | >>>>>>> | master_addresses | >>>>>>> [] | >>>>>>> | create_timeout | >>>>>>> 60 | >>>>>>> | node_count | >>>>>>> 1 | >>>>>>> | discovery_url | >>>>>>> None | >>>>>>> | master_count | >>>>>>> 1 | >>>>>>> | container_version | >>>>>>> None | >>>>>>> | name | >>>>>>> kubernetes-cluster | >>>>>>> | master_flavor_id | >>>>>>> amphora | >>>>>>> | flavor_id | >>>>>>> amphora | >>>>>>> >>>>>>> +---------------------+---------------------------------------------------+ >>>>>>> [root at zu-bssn-controller1 opt]# >>>>>>> >>>>>>> Anyone know what is happening? >>>>>>> >>>>>>> Best Regards, >>>>>>> Zufar Dhiyaulhaq >>>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufar at onf-ambassador.org Sat Dec 15 18:15:51 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Sun, 16 Dec 2018 01:15:51 +0700 Subject: [magnum] cluster node fail to establish connection (wrong IP address) In-Reply-To: References: Message-ID: By Design, my OpenStack have 2 networks. External Network (Floating IP) : 10.61.61.0/24 Management Network & Data Network (private): 10.60.60.0/24 An instance that deploys with floating IP cant access to the management network. It is possible to change the URL from the error log (10.60.60.10) to 10.61.61.10? Best Regards, Zufar Dhiyaulhaq On Sun, Dec 16, 2018 at 1:12 AM Zufar Dhiyaulhaq wrote: > Yes. Master Node communicates with port 5000, but with a wrong IP address. > > Floating IP give to my instance is in 10.61.61.0/24 but all of my > endpoints are in 10.60.60.0/24, but when I try to curl manual the > endpoint with 10.61.61.0/24 it's working fine. > It is possible to change the IP address installed on cloud-init to > 10.61.61.X? > > Best Regards, > Zufar Dhiyaulhaq > > > On Sun, Dec 16, 2018 at 1:08 AM Ignazio Cassano > wrote: > >> Zufar, the master node must communicat with port 5000 on the network >> where you deployed keystone endpoint. >> Ignazio >> Il giorno Sab 15 Dic 2018 18:58 Zufar Dhiyaulhaq < >> zufar at onf-ambassador.org> ha scritto: >> >>> Hi I am creating a swarm cluster with this command : >>> >>> - openstack coe cluster template create swarm-cluster-template >>> --image fedora-atomic-latest --external-network external --dns-nameserver >>> 8.8.8.8 --master-flavor m1.small --flavor m1.small --coe swarm-mode >>> --docker-volume-size 4 --docker-storage-driver=devicemapper >>> - openstack coe cluster create swarm-cluster --cluster-template >>> swarm-cluster-template --master-count 1 --node-count 1 --keypair mykey >>> >>> but its stack on *swarm_primary_master *heat with *CREATE_IN_PROGRESS*. >>> I try to login into swarm VM and see the log. >>> >>> I get this : >>> >>> >>> - requests.exceptions.ConnectionError: >>> HTTPConnectionPool(host='10.60.60.10', port=5000): Max retries exceeded >>> with url: /v3/auth/tokens (Caused by >>> NewConnectionError('>> 0x7f02f57321d0>: Failed to establish a new connection: [Errno 110] >>> Connection timed out',)) >>> - Cloud-init v. 0.7.9 running 'modules:final' at Sat, 15 Dec 2018 >>> 17:36:44 +0000. Up 33.29 seconds. >>> >>> >>> Swarm Instance try to open connection to 10.60.60.10 which is my >>> management ip address on OpenStack. But it cannot (by design it cannot, I >>> try to curl manual to 10.60.60.10 and error). When curl to 10.61.61.10 >>> which is my floating IP and external IP for OpenStack cluster, it works. >>> >>> Anyone know how to change the cloud-init to curl into 10.61.61.10? >>> >>> Best Regards, >>> Zufar Dhiyaulhaq >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Sat Dec 15 18:19:54 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sat, 15 Dec 2018 19:19:54 +0100 Subject: [magnum] cluster node fail to establish connection (wrong IP address) In-Reply-To: References: Message-ID: What reports the command openstack endpoint list | grep keystone ? Il giorno Sab 15 Dic 2018 19:16 Zufar Dhiyaulhaq ha scritto: > By Design, my OpenStack have 2 networks. > > External Network (Floating IP) : 10.61.61.0/24 > Management Network & Data Network (private): 10.60.60.0/24 > > An instance that deploys with floating IP cant access to the management > network. It is possible to change the URL from the error log (10.60.60.10) > to 10.61.61.10? > > Best Regards, > Zufar Dhiyaulhaq > > > On Sun, Dec 16, 2018 at 1:12 AM Zufar Dhiyaulhaq > wrote: > >> Yes. Master Node communicates with port 5000, but with a wrong IP address. >> >> Floating IP give to my instance is in 10.61.61.0/24 but all of my >> endpoints are in 10.60.60.0/24, but when I try to curl manual the >> endpoint with 10.61.61.0/24 it's working fine. >> It is possible to change the IP address installed on cloud-init to >> 10.61.61.X? >> >> Best Regards, >> Zufar Dhiyaulhaq >> >> >> On Sun, Dec 16, 2018 at 1:08 AM Ignazio Cassano >> wrote: >> >>> Zufar, the master node must communicat with port 5000 on the network >>> where you deployed keystone endpoint. >>> Ignazio >>> Il giorno Sab 15 Dic 2018 18:58 Zufar Dhiyaulhaq < >>> zufar at onf-ambassador.org> ha scritto: >>> >>>> Hi I am creating a swarm cluster with this command : >>>> >>>> - openstack coe cluster template create swarm-cluster-template >>>> --image fedora-atomic-latest --external-network external --dns-nameserver >>>> 8.8.8.8 --master-flavor m1.small --flavor m1.small --coe swarm-mode >>>> --docker-volume-size 4 --docker-storage-driver=devicemapper >>>> - openstack coe cluster create swarm-cluster --cluster-template >>>> swarm-cluster-template --master-count 1 --node-count 1 --keypair mykey >>>> >>>> but its stack on *swarm_primary_master *heat with *CREATE_IN_PROGRESS*. >>>> I try to login into swarm VM and see the log. >>>> >>>> I get this : >>>> >>>> >>>> - requests.exceptions.ConnectionError: >>>> HTTPConnectionPool(host='10.60.60.10', port=5000): Max retries exceeded >>>> with url: /v3/auth/tokens (Caused by >>>> NewConnectionError('>>> 0x7f02f57321d0>: Failed to establish a new connection: [Errno 110] >>>> Connection timed out',)) >>>> - Cloud-init v. 0.7.9 running 'modules:final' at Sat, 15 Dec 2018 >>>> 17:36:44 +0000. Up 33.29 seconds. >>>> >>>> >>>> Swarm Instance try to open connection to 10.60.60.10 which is my >>>> management ip address on OpenStack. But it cannot (by design it cannot, I >>>> try to curl manual to 10.60.60.10 and error). When curl to 10.61.61.10 >>>> which is my floating IP and external IP for OpenStack cluster, it works. >>>> >>>> Anyone know how to change the cloud-init to curl into 10.61.61.10? >>>> >>>> Best Regards, >>>> Zufar Dhiyaulhaq >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufar at onf-ambassador.org Sat Dec 15 18:39:22 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Sun, 16 Dec 2018 01:39:22 +0700 Subject: [magnum] cluster node fail to establish connection (wrong IP address) In-Reply-To: References: Message-ID: Hi Ignazio, I try to change the heat configuration as you suggested, but still my instance are try to 10.60.60.10. this is the output : | 0c34c8b0dcdc459f818c2bab04913039 | RegionOne | keystone | identity | True | public | http://10.60.60.10:5000/v3 | | 8ca42fccdb774f9daf67c95ea61fd006 | RegionOne | keystone | identity | True | admin | http://10.60.60.10:35357/v3 | | 8d0a23730608495980dce151d466a579 | RegionOne | keystone | identity | True | internal | http://10.60.60.10:5000/v3 | testing curl : @swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ curl http://10.60.60.10:5000/v3 ^C [fedora at swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ curl http://10.61.61.10:5000/v3 {"version": {"status": "stable", "updated": "2018-02-28T00:00:00Z", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"}], "id": "v3.10", "links": [{"href": "http://10.61.61.10:5000/v3/", "rel": "self"}]}}[fedora at swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ Best Regards, Zufar Dhiyaulhaq On Sun, Dec 16, 2018 at 1:20 AM Ignazio Cassano wrote: > What reports the command > openstack endpoint list | grep keystone > > ? > > > Il giorno Sab 15 Dic 2018 19:16 Zufar Dhiyaulhaq > ha scritto: > >> By Design, my OpenStack have 2 networks. >> >> External Network (Floating IP) : 10.61.61.0/24 >> Management Network & Data Network (private): 10.60.60.0/24 >> >> An instance that deploys with floating IP cant access to the management >> network. It is possible to change the URL from the error log (10.60.60.10) >> to 10.61.61.10? >> >> Best Regards, >> Zufar Dhiyaulhaq >> >> >> On Sun, Dec 16, 2018 at 1:12 AM Zufar Dhiyaulhaq < >> zufar at onf-ambassador.org> wrote: >> >>> Yes. Master Node communicates with port 5000, but with a wrong IP >>> address. >>> >>> Floating IP give to my instance is in 10.61.61.0/24 but all of my >>> endpoints are in 10.60.60.0/24, but when I try to curl manual the >>> endpoint with 10.61.61.0/24 it's working fine. >>> It is possible to change the IP address installed on cloud-init to >>> 10.61.61.X? >>> >>> Best Regards, >>> Zufar Dhiyaulhaq >>> >>> >>> On Sun, Dec 16, 2018 at 1:08 AM Ignazio Cassano < >>> ignaziocassano at gmail.com> wrote: >>> >>>> Zufar, the master node must communicat with port 5000 on the network >>>> where you deployed keystone endpoint. >>>> Ignazio >>>> Il giorno Sab 15 Dic 2018 18:58 Zufar Dhiyaulhaq < >>>> zufar at onf-ambassador.org> ha scritto: >>>> >>>>> Hi I am creating a swarm cluster with this command : >>>>> >>>>> - openstack coe cluster template create swarm-cluster-template >>>>> --image fedora-atomic-latest --external-network external --dns-nameserver >>>>> 8.8.8.8 --master-flavor m1.small --flavor m1.small --coe swarm-mode >>>>> --docker-volume-size 4 --docker-storage-driver=devicemapper >>>>> - openstack coe cluster create swarm-cluster --cluster-template >>>>> swarm-cluster-template --master-count 1 --node-count 1 --keypair mykey >>>>> >>>>> but its stack on *swarm_primary_master *heat with *CREATE_IN_PROGRESS*. >>>>> I try to login into swarm VM and see the log. >>>>> >>>>> I get this : >>>>> >>>>> >>>>> - requests.exceptions.ConnectionError: >>>>> HTTPConnectionPool(host='10.60.60.10', port=5000): Max retries exceeded >>>>> with url: /v3/auth/tokens (Caused by >>>>> NewConnectionError('>>>> 0x7f02f57321d0>: Failed to establish a new connection: [Errno 110] >>>>> Connection timed out',)) >>>>> - Cloud-init v. 0.7.9 running 'modules:final' at Sat, 15 Dec 2018 >>>>> 17:36:44 +0000. Up 33.29 seconds. >>>>> >>>>> >>>>> Swarm Instance try to open connection to 10.60.60.10 which is my >>>>> management ip address on OpenStack. But it cannot (by design it cannot, I >>>>> try to curl manual to 10.60.60.10 and error). When curl to 10.61.61.10 >>>>> which is my floating IP and external IP for OpenStack cluster, it works. >>>>> >>>>> Anyone know how to change the cloud-init to curl into 10.61.61.10? >>>>> >>>>> Best Regards, >>>>> Zufar Dhiyaulhaq >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufar at onf-ambassador.org Sat Dec 15 18:40:50 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Sun, 16 Dec 2018 01:40:50 +0700 Subject: [magnum] cluster node fail to establish connection (wrong IP address) In-Reply-To: References: Message-ID: Hi Ignazio, this is my Heat Configuration : [root at zu-controller0 ~(keystone_admin)]# egrep -v ^'(#|$)' /etc/heat/heat.conf [DEFAULT] heat_metadata_server_url=http://10.60.60.10:8000 heat_waitcondition_server_url=http://10.60.60.10:8000/v1/waitcondition heat_watch_server_url=http://10.60.60.10:8003 stack_user_domain_name=heat stack_domain_admin=heat_admin stack_domain_admin_password=b2464b7fd4694efa num_engine_workers=4 auth_encryption_key=d954b3c680fd42fb debug=False log_dir=/var/log/heat transport_url=rabbit://guest:guest at 10.60.60.10:5672/ [auth_password] [clients] [clients_aodh] [clients_barbican] [clients_ceilometer] [clients_cinder] [clients_designate] [clients_glance] [clients_heat] [clients_keystone] auth_uri=http://10.61.61.10:35357 [clients_magnum] [clients_manila][root at zu-controller0 ~(keystone_admin)]# egrep -v ^'(#|$)' /etc/heat/heat.conf [DEFAULT] heat_metadata_server_url=http://10.60.60.10:8000 heat_waitcondition_server_url=http://10.60.60.10:8000/v1/waitcondition heat_watch_server_url=http://10.60.60.10:8003 stack_user_domain_name=heat stack_domain_admin=heat_admin stack_domain_admin_password=b2464b7fd4694efa num_engine_workers=4 auth_encryption_key=d954b3c680fd42fb debug=False log_dir=/var/log/heat transport_url=rabbit://guest:guest at 10.60.60.10:5672/ [auth_password] [clients] [clients_aodh] [clients_barbican] [clients_ceilometer] [clients_cinder] [clients_designate] [clients_glance] [clients_heat] [clients_keystone] auth_uri=http://10.61.61.10:35357 [clients_magnum] [clients_manila] [clients_mistral] [clients_monasca] [clients_neutron] [clients_nova] [clients_octavia] [clients_sahara] [clients_senlin] [clients_swift] [clients_trove] [clients_zaqar] [cors] [database] connection=mysql+pymysql://heat:c553beb7ef5e4ac6 at 10.60.60.10/heat [ec2authtoken] auth_uri=http://10.61.61.10:5000/v3 [eventlet_opts] [healthcheck] [heat_api] workers=4 [heat_api_cfn] workers=4 [heat_api_cloudwatch] [matchmaker_redis] [noauth] [oslo_messaging_amqp] [oslo_messaging_kafka] [oslo_messaging_notifications] [oslo_messaging_rabbit] ssl=False [oslo_messaging_zmq] [oslo_middleware] [oslo_policy] policy_file=/etc/heat/policy.json [paste_deploy] [profiler] [revision] [ssl] [trustee] auth_type=password auth_url=http://10.60.60.10:35357 project_domain_name=Default username=heat user_domain_name=Default password=c9b4b2e3fd704048 [volumes] [keystone_authtoken] auth_uri=http://10.60.60.10:5000/v3 auth_type=password auth_url=http://10.60.60.10:35357 username=heat password=c9b4b2e3fd704048 user_domain_name=Default project_name=services project_domain_name=Default [clients_mistral] [clients_monasca] [clients_neutron] [clients_nova] [clients_octavia] [clients_sahara] [clients_senlin] [clients_swift] [clients_trove] [clients_zaqar] [cors] [database] connection=mysql+pymysql://heat:c553beb7ef5e4ac6 at 10.60.60.10/heat [ec2authtoken] auth_uri=http://10.61.61.10:5000/v3 [eventlet_opts] [healthcheck] [heat_api] workers=4 [heat_api_cfn] workers=4 [heat_api_cloudwatch] [matchmaker_redis] [noauth] [oslo_messaging_amqp] [oslo_messaging_kafka] [oslo_messaging_notifications] [oslo_messaging_rabbit] ssl=False [oslo_messaging_zmq] [oslo_middleware] [oslo_policy] policy_file=/etc/heat/policy.json [paste_deploy] [profiler] [revision] [ssl] [trustee] auth_type=password auth_url=http://10.60.60.10:35357 project_domain_name=Default username=heat user_domain_name=Default password=c9b4b2e3fd704048 [volumes] [keystone_authtoken] auth_uri=http://10.60.60.10:5000/v3 auth_type=password auth_url=http://10.60.60.10:35357 username=heat password=c9b4b2e3fd704048 user_domain_name=Default project_name=services project_domain_name=Default and this is my magnum configuration : [root at zu-controller0 ~(keystone_admin)]# egrep -v ^'(#|$)' /etc/magnum/magnum.conf [DEFAULT] log_dir=/var/log/magnum transport_url=rabbit://guest:guest at 10.60.60.10:5672/ [cors] [database] connection=mysql+pymysql://magnum:b08c5fe90a0e42e7 at 10.60.60.10/magnum [keystone_authtoken] auth_uri=http://10.60.60.10:5000/v3 auth_version=v3 memcached_servers=10.60.60.10:11211 auth_type=password admin_tenant_name=services admin_user=magnum admin_password=f784e0ac913e41e7 auth_url=http://10.60.60.10:35357 username=magnum password=f784e0ac913e41e7 user_domain_name=Default project_name=services project_domain_name=Default [matchmaker_redis] [oslo_concurrency] [oslo_messaging_amqp] [oslo_messaging_kafka] [oslo_messaging_notifications] driver=messagingv2 [oslo_messaging_rabbit] ssl=False [oslo_messaging_zmq] [oslo_policy] policy_file=/etc/magnum/policy.json [trust] trustee_domain_name=magnum trustee_domain_admin_name=magnum_admin trustee_domain_admin_password=f784e0ac913e41e7 trustee_keystone_interface=public [api] port=9511 host=0.0.0.0 max_limit=1000 enabled_ssl=False [barbican_client] region_name=RegionOne [cinder_client] region_name=RegionOne [glance_client] region_name=RegionOne api_version=2 insecure=False [heat_client] region_name=RegionOne api_version=1 insecure=False [magnum_client] region_name=RegionOne [neutron_client] region_name=RegionOne insecure=False [nova_client] region_name=RegionOne api_version=2 insecure=False [certificates] cert_manager_type=local Best Regards, Zufar Dhiyaulhaq On Sun, Dec 16, 2018 at 1:39 AM Zufar Dhiyaulhaq wrote: > Hi Ignazio, > > I try to change the heat configuration as you suggested, but still my > instance are try to 10.60.60.10. > this is the output : > > | 0c34c8b0dcdc459f818c2bab04913039 | RegionOne | keystone | > identity | True | public | http://10.60.60.10:5000/v3 > | > | 8ca42fccdb774f9daf67c95ea61fd006 | RegionOne | keystone | > identity | True | admin | http://10.60.60.10:35357/v3 > | > | 8d0a23730608495980dce151d466a579 | RegionOne | keystone | > identity | True | internal | http://10.60.60.10:5000/v3 > | > > testing curl : > > @swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ curl > http://10.60.60.10:5000/v3 > ^C > [fedora at swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ curl > http://10.61.61.10:5000/v3 > {"version": {"status": "stable", "updated": "2018-02-28T00:00:00Z", > "media-types": [{"base": "application/json", "type": > "application/vnd.openstack.identity-v3+json"}], "id": "v3.10", "links": > [{"href": "http://10.61.61.10:5000/v3/", "rel": > "self"}]}}[fedora at swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ > > > Best Regards, > Zufar Dhiyaulhaq > > > On Sun, Dec 16, 2018 at 1:20 AM Ignazio Cassano > wrote: > >> What reports the command >> openstack endpoint list | grep keystone >> >> ? >> >> >> Il giorno Sab 15 Dic 2018 19:16 Zufar Dhiyaulhaq < >> zufar at onf-ambassador.org> ha scritto: >> >>> By Design, my OpenStack have 2 networks. >>> >>> External Network (Floating IP) : 10.61.61.0/24 >>> Management Network & Data Network (private): 10.60.60.0/24 >>> >>> An instance that deploys with floating IP cant access to the management >>> network. It is possible to change the URL from the error log (10.60.60.10) >>> to 10.61.61.10? >>> >>> Best Regards, >>> Zufar Dhiyaulhaq >>> >>> >>> On Sun, Dec 16, 2018 at 1:12 AM Zufar Dhiyaulhaq < >>> zufar at onf-ambassador.org> wrote: >>> >>>> Yes. Master Node communicates with port 5000, but with a wrong IP >>>> address. >>>> >>>> Floating IP give to my instance is in 10.61.61.0/24 but all of my >>>> endpoints are in 10.60.60.0/24, but when I try to curl manual the >>>> endpoint with 10.61.61.0/24 it's working fine. >>>> It is possible to change the IP address installed on cloud-init to >>>> 10.61.61.X? >>>> >>>> Best Regards, >>>> Zufar Dhiyaulhaq >>>> >>>> >>>> On Sun, Dec 16, 2018 at 1:08 AM Ignazio Cassano < >>>> ignaziocassano at gmail.com> wrote: >>>> >>>>> Zufar, the master node must communicat with port 5000 on the network >>>>> where you deployed keystone endpoint. >>>>> Ignazio >>>>> Il giorno Sab 15 Dic 2018 18:58 Zufar Dhiyaulhaq < >>>>> zufar at onf-ambassador.org> ha scritto: >>>>> >>>>>> Hi I am creating a swarm cluster with this command : >>>>>> >>>>>> - openstack coe cluster template create swarm-cluster-template >>>>>> --image fedora-atomic-latest --external-network external --dns-nameserver >>>>>> 8.8.8.8 --master-flavor m1.small --flavor m1.small --coe swarm-mode >>>>>> --docker-volume-size 4 --docker-storage-driver=devicemapper >>>>>> - openstack coe cluster create swarm-cluster --cluster-template >>>>>> swarm-cluster-template --master-count 1 --node-count 1 --keypair mykey >>>>>> >>>>>> but its stack on *swarm_primary_master *heat with >>>>>> *CREATE_IN_PROGRESS*. I try to login into swarm VM and see the log. >>>>>> >>>>>> I get this : >>>>>> >>>>>> >>>>>> - requests.exceptions.ConnectionError: >>>>>> HTTPConnectionPool(host='10.60.60.10', port=5000): Max retries exceeded >>>>>> with url: /v3/auth/tokens (Caused by >>>>>> NewConnectionError('>>>>> 0x7f02f57321d0>: Failed to establish a new connection: [Errno 110] >>>>>> Connection timed out',)) >>>>>> - Cloud-init v. 0.7.9 running 'modules:final' at Sat, 15 Dec 2018 >>>>>> 17:36:44 +0000. Up 33.29 seconds. >>>>>> >>>>>> >>>>>> Swarm Instance try to open connection to 10.60.60.10 which is my >>>>>> management ip address on OpenStack. But it cannot (by design it cannot, I >>>>>> try to curl manual to 10.60.60.10 and error). When curl to 10.61.61.10 >>>>>> which is my floating IP and external IP for OpenStack cluster, it works. >>>>>> >>>>>> Anyone know how to change the cloud-init to curl into 10.61.61.10? >>>>>> >>>>>> Best Regards, >>>>>> Zufar Dhiyaulhaq >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Sat Dec 15 19:02:55 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sat, 15 Dec 2018 20:02:55 +0100 Subject: [magnum] cluster node fail to establish connection (wrong IP address) In-Reply-To: References: Message-ID: Pobably you configured all services (Nova , magnum and so on) with endpoint on 10.60.60..... in keystone section Il giorno Sab 15 Dic 2018 19:39 Zufar Dhiyaulhaq ha scritto: > Hi Ignazio, > > I try to change the heat configuration as you suggested, but still my > instance are try to 10.60.60.10. > this is the output : > > | 0c34c8b0dcdc459f818c2bab04913039 | RegionOne | keystone | > identity | True | public | http://10.60.60.10:5000/v3 > | > | 8ca42fccdb774f9daf67c95ea61fd006 | RegionOne | keystone | > identity | True | admin | http://10.60.60.10:35357/v3 > | > | 8d0a23730608495980dce151d466a579 | RegionOne | keystone | > identity | True | internal | http://10.60.60.10:5000/v3 > | > > testing curl : > > @swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ curl > http://10.60.60.10:5000/v3 > ^C > [fedora at swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ curl > http://10.61.61.10:5000/v3 > {"version": {"status": "stable", "updated": "2018-02-28T00:00:00Z", > "media-types": [{"base": "application/json", "type": > "application/vnd.openstack.identity-v3+json"}], "id": "v3.10", "links": > [{"href": "http://10.61.61.10:5000/v3/", "rel": > "self"}]}}[fedora at swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ > > > Best Regards, > Zufar Dhiyaulhaq > > > On Sun, Dec 16, 2018 at 1:20 AM Ignazio Cassano > wrote: > >> What reports the command >> openstack endpoint list | grep keystone >> >> ? >> >> >> Il giorno Sab 15 Dic 2018 19:16 Zufar Dhiyaulhaq < >> zufar at onf-ambassador.org> ha scritto: >> >>> By Design, my OpenStack have 2 networks. >>> >>> External Network (Floating IP) : 10.61.61.0/24 >>> Management Network & Data Network (private): 10.60.60.0/24 >>> >>> An instance that deploys with floating IP cant access to the management >>> network. It is possible to change the URL from the error log (10.60.60.10) >>> to 10.61.61.10? >>> >>> Best Regards, >>> Zufar Dhiyaulhaq >>> >>> >>> On Sun, Dec 16, 2018 at 1:12 AM Zufar Dhiyaulhaq < >>> zufar at onf-ambassador.org> wrote: >>> >>>> Yes. Master Node communicates with port 5000, but with a wrong IP >>>> address. >>>> >>>> Floating IP give to my instance is in 10.61.61.0/24 but all of my >>>> endpoints are in 10.60.60.0/24, but when I try to curl manual the >>>> endpoint with 10.61.61.0/24 it's working fine. >>>> It is possible to change the IP address installed on cloud-init to >>>> 10.61.61.X? >>>> >>>> Best Regards, >>>> Zufar Dhiyaulhaq >>>> >>>> >>>> On Sun, Dec 16, 2018 at 1:08 AM Ignazio Cassano < >>>> ignaziocassano at gmail.com> wrote: >>>> >>>>> Zufar, the master node must communicat with port 5000 on the network >>>>> where you deployed keystone endpoint. >>>>> Ignazio >>>>> Il giorno Sab 15 Dic 2018 18:58 Zufar Dhiyaulhaq < >>>>> zufar at onf-ambassador.org> ha scritto: >>>>> >>>>>> Hi I am creating a swarm cluster with this command : >>>>>> >>>>>> - openstack coe cluster template create swarm-cluster-template >>>>>> --image fedora-atomic-latest --external-network external --dns-nameserver >>>>>> 8.8.8.8 --master-flavor m1.small --flavor m1.small --coe swarm-mode >>>>>> --docker-volume-size 4 --docker-storage-driver=devicemapper >>>>>> - openstack coe cluster create swarm-cluster --cluster-template >>>>>> swarm-cluster-template --master-count 1 --node-count 1 --keypair mykey >>>>>> >>>>>> but its stack on *swarm_primary_master *heat with >>>>>> *CREATE_IN_PROGRESS*. I try to login into swarm VM and see the log. >>>>>> >>>>>> I get this : >>>>>> >>>>>> >>>>>> - requests.exceptions.ConnectionError: >>>>>> HTTPConnectionPool(host='10.60.60.10', port=5000): Max retries exceeded >>>>>> with url: /v3/auth/tokens (Caused by >>>>>> NewConnectionError('>>>>> 0x7f02f57321d0>: Failed to establish a new connection: [Errno 110] >>>>>> Connection timed out',)) >>>>>> - Cloud-init v. 0.7.9 running 'modules:final' at Sat, 15 Dec 2018 >>>>>> 17:36:44 +0000. Up 33.29 seconds. >>>>>> >>>>>> >>>>>> Swarm Instance try to open connection to 10.60.60.10 which is my >>>>>> management ip address on OpenStack. But it cannot (by design it cannot, I >>>>>> try to curl manual to 10.60.60.10 and error). When curl to 10.61.61.10 >>>>>> which is my floating IP and external IP for OpenStack cluster, it works. >>>>>> >>>>>> Anyone know how to change the cloud-init to curl into 10.61.61.10? >>>>>> >>>>>> Best Regards, >>>>>> Zufar Dhiyaulhaq >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufar at onf-ambassador.org Sat Dec 15 19:09:08 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Sun, 16 Dec 2018 02:09:08 +0700 Subject: [magnum] cluster node fail to establish connection (wrong IP address) In-Reply-To: References: Message-ID: Hi, Ignazio, yes all of my endpoint is in 10.60.60. Ignazio, can you check `sudo cat /etc/sysconfig/heat-params` inside the VM and see `DOCKER_VOLUME_SIZE="0"` Maybe this give you solution. Best Regards, Zufar Dhiyaulhaq On Sun, Dec 16, 2018 at 2:03 AM Ignazio Cassano wrote: > Pobably you configured all services > (Nova , magnum and so on) with endpoint on 10.60.60..... in keystone > section > > Il giorno Sab 15 Dic 2018 19:39 Zufar Dhiyaulhaq > ha scritto: > >> Hi Ignazio, >> >> I try to change the heat configuration as you suggested, but still my >> instance are try to 10.60.60.10. >> this is the output : >> >> | 0c34c8b0dcdc459f818c2bab04913039 | RegionOne | keystone | >> identity | True | public | http://10.60.60.10:5000/v3 >> | >> | 8ca42fccdb774f9daf67c95ea61fd006 | RegionOne | keystone | >> identity | True | admin | http://10.60.60.10:35357/v3 >> | >> | 8d0a23730608495980dce151d466a579 | RegionOne | keystone | >> identity | True | internal | http://10.60.60.10:5000/v3 >> | >> >> testing curl : >> >> @swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ curl >> http://10.60.60.10:5000/v3 >> ^C >> [fedora at swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ curl >> http://10.61.61.10:5000/v3 >> {"version": {"status": "stable", "updated": "2018-02-28T00:00:00Z", >> "media-types": [{"base": "application/json", "type": >> "application/vnd.openstack.identity-v3+json"}], "id": "v3.10", "links": >> [{"href": "http://10.61.61.10:5000/v3/", "rel": >> "self"}]}}[fedora at swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ >> >> >> Best Regards, >> Zufar Dhiyaulhaq >> >> >> On Sun, Dec 16, 2018 at 1:20 AM Ignazio Cassano >> wrote: >> >>> What reports the command >>> openstack endpoint list | grep keystone >>> >>> ? >>> >>> >>> Il giorno Sab 15 Dic 2018 19:16 Zufar Dhiyaulhaq < >>> zufar at onf-ambassador.org> ha scritto: >>> >>>> By Design, my OpenStack have 2 networks. >>>> >>>> External Network (Floating IP) : 10.61.61.0/24 >>>> Management Network & Data Network (private): 10.60.60.0/24 >>>> >>>> An instance that deploys with floating IP cant access to the management >>>> network. It is possible to change the URL from the error log (10.60.60.10) >>>> to 10.61.61.10? >>>> >>>> Best Regards, >>>> Zufar Dhiyaulhaq >>>> >>>> >>>> On Sun, Dec 16, 2018 at 1:12 AM Zufar Dhiyaulhaq < >>>> zufar at onf-ambassador.org> wrote: >>>> >>>>> Yes. Master Node communicates with port 5000, but with a wrong IP >>>>> address. >>>>> >>>>> Floating IP give to my instance is in 10.61.61.0/24 but all of my >>>>> endpoints are in 10.60.60.0/24, but when I try to curl manual the >>>>> endpoint with 10.61.61.0/24 it's working fine. >>>>> It is possible to change the IP address installed on cloud-init to >>>>> 10.61.61.X? >>>>> >>>>> Best Regards, >>>>> Zufar Dhiyaulhaq >>>>> >>>>> >>>>> On Sun, Dec 16, 2018 at 1:08 AM Ignazio Cassano < >>>>> ignaziocassano at gmail.com> wrote: >>>>> >>>>>> Zufar, the master node must communicat with port 5000 on the network >>>>>> where you deployed keystone endpoint. >>>>>> Ignazio >>>>>> Il giorno Sab 15 Dic 2018 18:58 Zufar Dhiyaulhaq < >>>>>> zufar at onf-ambassador.org> ha scritto: >>>>>> >>>>>>> Hi I am creating a swarm cluster with this command : >>>>>>> >>>>>>> - openstack coe cluster template create swarm-cluster-template >>>>>>> --image fedora-atomic-latest --external-network external --dns-nameserver >>>>>>> 8.8.8.8 --master-flavor m1.small --flavor m1.small --coe swarm-mode >>>>>>> --docker-volume-size 4 --docker-storage-driver=devicemapper >>>>>>> - openstack coe cluster create swarm-cluster --cluster-template >>>>>>> swarm-cluster-template --master-count 1 --node-count 1 --keypair mykey >>>>>>> >>>>>>> but its stack on *swarm_primary_master *heat with >>>>>>> *CREATE_IN_PROGRESS*. I try to login into swarm VM and see the log. >>>>>>> >>>>>>> I get this : >>>>>>> >>>>>>> >>>>>>> - requests.exceptions.ConnectionError: >>>>>>> HTTPConnectionPool(host='10.60.60.10', port=5000): Max retries exceeded >>>>>>> with url: /v3/auth/tokens (Caused by >>>>>>> NewConnectionError('>>>>>> 0x7f02f57321d0>: Failed to establish a new connection: [Errno 110] >>>>>>> Connection timed out',)) >>>>>>> - Cloud-init v. 0.7.9 running 'modules:final' at Sat, 15 Dec >>>>>>> 2018 17:36:44 +0000. Up 33.29 seconds. >>>>>>> >>>>>>> >>>>>>> Swarm Instance try to open connection to 10.60.60.10 which is my >>>>>>> management ip address on OpenStack. But it cannot (by design it cannot, I >>>>>>> try to curl manual to 10.60.60.10 and error). When curl to 10.61.61.10 >>>>>>> which is my floating IP and external IP for OpenStack cluster, it works. >>>>>>> >>>>>>> Anyone know how to change the cloud-init to curl into 10.61.61.10? >>>>>>> >>>>>>> Best Regards, >>>>>>> Zufar Dhiyaulhaq >>>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufar at onf-ambassador.org Sat Dec 15 19:10:40 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Sun, 16 Dec 2018 02:10:40 +0700 Subject: [magnum] cluster node fail to establish connection (wrong IP address) In-Reply-To: References: Message-ID: Hi Ignazio, I think my problem is from this file to, [fedora at swarm-cluster-hekxryp2n6ke-primary-master-0 ~]$ sudo cat /etc/sysconfig/heat-params IS_PRIMARY_MASTER="True" WAIT_CURL="curl -i -X POST -H 'X-Auth-Token: gAAAAABcFVD3Lq8v3cBGbpnejxNtqkDZPIDBYg6LBXTifXQxPowzdWhYHnRT7MWE48fwPwTYTJxM6TS_v32gl4OZu5GInufoXmnBFApdOmUg9KzeJGz8iGvg0tl62ratgRN40SMXNM7ZEXIflDQHO9tKrVdpJ9v6KY8HV2rZ0mspzTUDnsg0NjE' -H 'Content-Type: application/json' -H 'Accept: application/json' http://10.60.60.10:8004/v1/c508af1f5ad741dbb2e3e2b5eee5855e/stacks/swarm-cluster-hekxryp2n6ke-swarm_primary_master-hkgjpiv34bcl-0-323fkifz7mim/a5cabefd-417c-41ad-bf43-2ab27d572d08/resources/master_wait_handle/signal " DOCKER_VOLUME="6101c99c-9072-4290-9691-e679dbb44f8f" DOCKER_VOLUME_SIZE="0" DOCKER_STORAGE_DRIVER="devicemapper" HTTP_PROXY="" HTTPS_PROXY="" NO_PROXY="" PRIMARY_MASTER_IP="" SWARM_API_IP="10.0.0.13" SWARM_NODE_IP="10.0.0.13" CLUSTER_UUID="17a9eb19-2d22-473a-a292-df2d06197974" MAGNUM_URL="http://10.60.60.10:9511/v1" TLS_DISABLED="False" API_IP_ADDRESS="10.61.61.111" TRUSTEE_USER_ID="f61ff2de879548e9b46bd5609a696b6c" TRUSTEE_PASSWORD="T6zjpQGjqcPwv7684F" TRUST_ID="" AUTH_URL="http://10.60.60.10:5000/v3" VOLUME_DRIVER="" REXRAY_PREEMPT="false" VERIFY_CA="True" Best Regards, Zufar Dhiyaulhaq On Sun, Dec 16, 2018 at 2:09 AM Zufar Dhiyaulhaq wrote: > Hi, Ignazio, > > yes all of my endpoint is in 10.60.60. > > Ignazio, can you check `sudo cat /etc/sysconfig/heat-params` inside the VM > and see `DOCKER_VOLUME_SIZE="0"` > Maybe this give you solution. > > Best Regards, > Zufar Dhiyaulhaq > > > On Sun, Dec 16, 2018 at 2:03 AM Ignazio Cassano > wrote: > >> Pobably you configured all services >> (Nova , magnum and so on) with endpoint on 10.60.60..... in keystone >> section >> >> Il giorno Sab 15 Dic 2018 19:39 Zufar Dhiyaulhaq < >> zufar at onf-ambassador.org> ha scritto: >> >>> Hi Ignazio, >>> >>> I try to change the heat configuration as you suggested, but still my >>> instance are try to 10.60.60.10. >>> this is the output : >>> >>> | 0c34c8b0dcdc459f818c2bab04913039 | RegionOne | keystone | >>> identity | True | public | http://10.60.60.10:5000/v3 >>> | >>> | 8ca42fccdb774f9daf67c95ea61fd006 | RegionOne | keystone | >>> identity | True | admin | http://10.60.60.10:35357/v3 >>> | >>> | 8d0a23730608495980dce151d466a579 | RegionOne | keystone | >>> identity | True | internal | http://10.60.60.10:5000/v3 >>> | >>> >>> testing curl : >>> >>> @swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ curl >>> http://10.60.60.10:5000/v3 >>> ^C >>> [fedora at swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ curl >>> http://10.61.61.10:5000/v3 >>> {"version": {"status": "stable", "updated": "2018-02-28T00:00:00Z", >>> "media-types": [{"base": "application/json", "type": >>> "application/vnd.openstack.identity-v3+json"}], "id": "v3.10", "links": >>> [{"href": "http://10.61.61.10:5000/v3/", "rel": >>> "self"}]}}[fedora at swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ >>> >>> >>> Best Regards, >>> Zufar Dhiyaulhaq >>> >>> >>> On Sun, Dec 16, 2018 at 1:20 AM Ignazio Cassano < >>> ignaziocassano at gmail.com> wrote: >>> >>>> What reports the command >>>> openstack endpoint list | grep keystone >>>> >>>> ? >>>> >>>> >>>> Il giorno Sab 15 Dic 2018 19:16 Zufar Dhiyaulhaq < >>>> zufar at onf-ambassador.org> ha scritto: >>>> >>>>> By Design, my OpenStack have 2 networks. >>>>> >>>>> External Network (Floating IP) : 10.61.61.0/24 >>>>> Management Network & Data Network (private): 10.60.60.0/24 >>>>> >>>>> An instance that deploys with floating IP cant access to the >>>>> management network. It is possible to change the URL from the error log >>>>> (10.60.60.10) to 10.61.61.10? >>>>> >>>>> Best Regards, >>>>> Zufar Dhiyaulhaq >>>>> >>>>> >>>>> On Sun, Dec 16, 2018 at 1:12 AM Zufar Dhiyaulhaq < >>>>> zufar at onf-ambassador.org> wrote: >>>>> >>>>>> Yes. Master Node communicates with port 5000, but with a wrong IP >>>>>> address. >>>>>> >>>>>> Floating IP give to my instance is in 10.61.61.0/24 but all of my >>>>>> endpoints are in 10.60.60.0/24, but when I try to curl manual the >>>>>> endpoint with 10.61.61.0/24 it's working fine. >>>>>> It is possible to change the IP address installed on cloud-init to >>>>>> 10.61.61.X? >>>>>> >>>>>> Best Regards, >>>>>> Zufar Dhiyaulhaq >>>>>> >>>>>> >>>>>> On Sun, Dec 16, 2018 at 1:08 AM Ignazio Cassano < >>>>>> ignaziocassano at gmail.com> wrote: >>>>>> >>>>>>> Zufar, the master node must communicat with port 5000 on the network >>>>>>> where you deployed keystone endpoint. >>>>>>> Ignazio >>>>>>> Il giorno Sab 15 Dic 2018 18:58 Zufar Dhiyaulhaq < >>>>>>> zufar at onf-ambassador.org> ha scritto: >>>>>>> >>>>>>>> Hi I am creating a swarm cluster with this command : >>>>>>>> >>>>>>>> - openstack coe cluster template create swarm-cluster-template >>>>>>>> --image fedora-atomic-latest --external-network external --dns-nameserver >>>>>>>> 8.8.8.8 --master-flavor m1.small --flavor m1.small --coe swarm-mode >>>>>>>> --docker-volume-size 4 --docker-storage-driver=devicemapper >>>>>>>> - openstack coe cluster create swarm-cluster --cluster-template >>>>>>>> swarm-cluster-template --master-count 1 --node-count 1 --keypair mykey >>>>>>>> >>>>>>>> but its stack on *swarm_primary_master *heat with >>>>>>>> *CREATE_IN_PROGRESS*. I try to login into swarm VM and see the log. >>>>>>>> >>>>>>>> I get this : >>>>>>>> >>>>>>>> >>>>>>>> - requests.exceptions.ConnectionError: >>>>>>>> HTTPConnectionPool(host='10.60.60.10', port=5000): Max retries exceeded >>>>>>>> with url: /v3/auth/tokens (Caused by >>>>>>>> NewConnectionError('>>>>>>> 0x7f02f57321d0>: Failed to establish a new connection: [Errno 110] >>>>>>>> Connection timed out',)) >>>>>>>> - Cloud-init v. 0.7.9 running 'modules:final' at Sat, 15 Dec >>>>>>>> 2018 17:36:44 +0000. Up 33.29 seconds. >>>>>>>> >>>>>>>> >>>>>>>> Swarm Instance try to open connection to 10.60.60.10 which is my >>>>>>>> management ip address on OpenStack. But it cannot (by design it cannot, I >>>>>>>> try to curl manual to 10.60.60.10 and error). When curl to 10.61.61.10 >>>>>>>> which is my floating IP and external IP for OpenStack cluster, it works. >>>>>>>> >>>>>>>> Anyone know how to change the cloud-init to curl into 10.61.61.10? >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> Zufar Dhiyaulhaq >>>>>>>> >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Sat Dec 15 19:26:22 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sat, 15 Dec 2018 20:26:22 +0100 Subject: [magnum] cluster node fail to establish connection (wrong IP address) In-Reply-To: References: Message-ID: That file is not static file but I think it is generated at boot. It reads your endpoint are on a network unreacheable by master node. So....it is easier to change external network where you deploy your cluster rather than modify the openstack configuration. If you choos an external network which can speak with keystone endpoint on 5000 port the problem la solved. Regards Ignazio Il giorno Sab 15 Dic 2018 20:10 Zufar Dhiyaulhaq ha scritto: > Hi Ignazio, > > I think my problem is from this file to, > > [fedora at swarm-cluster-hekxryp2n6ke-primary-master-0 ~]$ sudo cat > /etc/sysconfig/heat-params > IS_PRIMARY_MASTER="True" > WAIT_CURL="curl -i -X POST -H 'X-Auth-Token: > gAAAAABcFVD3Lq8v3cBGbpnejxNtqkDZPIDBYg6LBXTifXQxPowzdWhYHnRT7MWE48fwPwTYTJxM6TS_v32gl4OZu5GInufoXmnBFApdOmUg9KzeJGz8iGvg0tl62ratgRN40SMXNM7ZEXIflDQHO9tKrVdpJ9v6KY8HV2rZ0mspzTUDnsg0NjE' > -H 'Content-Type: application/json' -H 'Accept: application/json' > http://10.60.60.10:8004/v1/c508af1f5ad741dbb2e3e2b5eee5855e/stacks/swarm-cluster-hekxryp2n6ke-swarm_primary_master-hkgjpiv34bcl-0-323fkifz7mim/a5cabefd-417c-41ad-bf43-2ab27d572d08/resources/master_wait_handle/signal > " > DOCKER_VOLUME="6101c99c-9072-4290-9691-e679dbb44f8f" > DOCKER_VOLUME_SIZE="0" > DOCKER_STORAGE_DRIVER="devicemapper" > HTTP_PROXY="" > HTTPS_PROXY="" > NO_PROXY="" > PRIMARY_MASTER_IP="" > SWARM_API_IP="10.0.0.13" > SWARM_NODE_IP="10.0.0.13" > CLUSTER_UUID="17a9eb19-2d22-473a-a292-df2d06197974" > MAGNUM_URL="http://10.60.60.10:9511/v1" > TLS_DISABLED="False" > API_IP_ADDRESS="10.61.61.111" > TRUSTEE_USER_ID="f61ff2de879548e9b46bd5609a696b6c" > TRUSTEE_PASSWORD="T6zjpQGjqcPwv7684F" > TRUST_ID="" > AUTH_URL="http://10.60.60.10:5000/v3" > VOLUME_DRIVER="" > REXRAY_PREEMPT="false" > VERIFY_CA="True" > > Best Regards, > Zufar Dhiyaulhaq > > > On Sun, Dec 16, 2018 at 2:09 AM Zufar Dhiyaulhaq > wrote: > >> Hi, Ignazio, >> >> yes all of my endpoint is in 10.60.60. >> >> Ignazio, can you check `sudo cat /etc/sysconfig/heat-params` inside the >> VM and see `DOCKER_VOLUME_SIZE="0"` >> Maybe this give you solution. >> >> Best Regards, >> Zufar Dhiyaulhaq >> >> >> On Sun, Dec 16, 2018 at 2:03 AM Ignazio Cassano >> wrote: >> >>> Pobably you configured all services >>> (Nova , magnum and so on) with endpoint on 10.60.60..... in keystone >>> section >>> >>> Il giorno Sab 15 Dic 2018 19:39 Zufar Dhiyaulhaq < >>> zufar at onf-ambassador.org> ha scritto: >>> >>>> Hi Ignazio, >>>> >>>> I try to change the heat configuration as you suggested, but still my >>>> instance are try to 10.60.60.10. >>>> this is the output : >>>> >>>> | 0c34c8b0dcdc459f818c2bab04913039 | RegionOne | keystone | >>>> identity | True | public | http://10.60.60.10:5000/v3 >>>> | >>>> | 8ca42fccdb774f9daf67c95ea61fd006 | RegionOne | keystone | >>>> identity | True | admin | http://10.60.60.10:35357/v3 >>>> | >>>> | 8d0a23730608495980dce151d466a579 | RegionOne | keystone | >>>> identity | True | internal | http://10.60.60.10:5000/v3 >>>> | >>>> >>>> testing curl : >>>> >>>> @swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ curl >>>> http://10.60.60.10:5000/v3 >>>> ^C >>>> [fedora at swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ curl >>>> http://10.61.61.10:5000/v3 >>>> {"version": {"status": "stable", "updated": "2018-02-28T00:00:00Z", >>>> "media-types": [{"base": "application/json", "type": >>>> "application/vnd.openstack.identity-v3+json"}], "id": "v3.10", "links": >>>> [{"href": "http://10.61.61.10:5000/v3/", "rel": >>>> "self"}]}}[fedora at swarm-cluster-wtet5ppc5eqi-primary-master-0 ~]$ >>>> >>>> >>>> Best Regards, >>>> Zufar Dhiyaulhaq >>>> >>>> >>>> On Sun, Dec 16, 2018 at 1:20 AM Ignazio Cassano < >>>> ignaziocassano at gmail.com> wrote: >>>> >>>>> What reports the command >>>>> openstack endpoint list | grep keystone >>>>> >>>>> ? >>>>> >>>>> >>>>> Il giorno Sab 15 Dic 2018 19:16 Zufar Dhiyaulhaq < >>>>> zufar at onf-ambassador.org> ha scritto: >>>>> >>>>>> By Design, my OpenStack have 2 networks. >>>>>> >>>>>> External Network (Floating IP) : 10.61.61.0/24 >>>>>> Management Network & Data Network (private): 10.60.60.0/24 >>>>>> >>>>>> An instance that deploys with floating IP cant access to the >>>>>> management network. It is possible to change the URL from the error log >>>>>> (10.60.60.10) to 10.61.61.10? >>>>>> >>>>>> Best Regards, >>>>>> Zufar Dhiyaulhaq >>>>>> >>>>>> >>>>>> On Sun, Dec 16, 2018 at 1:12 AM Zufar Dhiyaulhaq < >>>>>> zufar at onf-ambassador.org> wrote: >>>>>> >>>>>>> Yes. Master Node communicates with port 5000, but with a wrong IP >>>>>>> address. >>>>>>> >>>>>>> Floating IP give to my instance is in 10.61.61.0/24 but all of my >>>>>>> endpoints are in 10.60.60.0/24, but when I try to curl manual the >>>>>>> endpoint with 10.61.61.0/24 it's working fine. >>>>>>> It is possible to change the IP address installed on cloud-init to >>>>>>> 10.61.61.X? >>>>>>> >>>>>>> Best Regards, >>>>>>> Zufar Dhiyaulhaq >>>>>>> >>>>>>> >>>>>>> On Sun, Dec 16, 2018 at 1:08 AM Ignazio Cassano < >>>>>>> ignaziocassano at gmail.com> wrote: >>>>>>> >>>>>>>> Zufar, the master node must communicat with port 5000 on the >>>>>>>> network where you deployed keystone endpoint. >>>>>>>> Ignazio >>>>>>>> Il giorno Sab 15 Dic 2018 18:58 Zufar Dhiyaulhaq < >>>>>>>> zufar at onf-ambassador.org> ha scritto: >>>>>>>> >>>>>>>>> Hi I am creating a swarm cluster with this command : >>>>>>>>> >>>>>>>>> - openstack coe cluster template create swarm-cluster-template >>>>>>>>> --image fedora-atomic-latest --external-network external --dns-nameserver >>>>>>>>> 8.8.8.8 --master-flavor m1.small --flavor m1.small --coe swarm-mode >>>>>>>>> --docker-volume-size 4 --docker-storage-driver=devicemapper >>>>>>>>> - openstack coe cluster create swarm-cluster >>>>>>>>> --cluster-template swarm-cluster-template --master-count 1 --node-count 1 >>>>>>>>> --keypair mykey >>>>>>>>> >>>>>>>>> but its stack on *swarm_primary_master *heat with >>>>>>>>> *CREATE_IN_PROGRESS*. I try to login into swarm VM and see the >>>>>>>>> log. >>>>>>>>> >>>>>>>>> I get this : >>>>>>>>> >>>>>>>>> >>>>>>>>> - requests.exceptions.ConnectionError: >>>>>>>>> HTTPConnectionPool(host='10.60.60.10', port=5000): Max retries exceeded >>>>>>>>> with url: /v3/auth/tokens (Caused by >>>>>>>>> NewConnectionError('>>>>>>>> 0x7f02f57321d0>: Failed to establish a new connection: [Errno 110] >>>>>>>>> Connection timed out',)) >>>>>>>>> - Cloud-init v. 0.7.9 running 'modules:final' at Sat, 15 Dec >>>>>>>>> 2018 17:36:44 +0000. Up 33.29 seconds. >>>>>>>>> >>>>>>>>> >>>>>>>>> Swarm Instance try to open connection to 10.60.60.10 which is my >>>>>>>>> management ip address on OpenStack. But it cannot (by design it cannot, I >>>>>>>>> try to curl manual to 10.60.60.10 and error). When curl to 10.61.61.10 >>>>>>>>> which is my floating IP and external IP for OpenStack cluster, it works. >>>>>>>>> >>>>>>>>> Anyone know how to change the cloud-init to curl into 10.61.61.10? >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Zufar Dhiyaulhaq >>>>>>>>> >>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ifatafekn at gmail.com Sun Dec 16 12:14:11 2018 From: ifatafekn at gmail.com (Ifat Afek) Date: Sun, 16 Dec 2018 14:14:11 +0200 Subject: [vitrage][monasca] Monasca datasource for Vitrage In-Reply-To: References: Message-ID: Hi Joseph, Thanks for your comments. What I understand is that we can always assume that Vitrage gets from Monasca enough dimensions to identify the resource in Vitrage, and the challenge is to define a mechanism for correlating the Monasca dimensions with Vitrage resource properties. I thought of a possible solution. We can write in Vitrage a configuration file, which defines for every metric which dimension(s) from Monsaca should be mapped to which property in Vitrage in order to uniquely identify the resource. For example, for libvirt metrics, ‘resource_id’ dimension should be mapped to ‘id’ in Vitrage. A draft of the file structure: * metric_name: the name of the metric in Monasca * vitrage_property: the name of a property to match in the Vitrage resource * vitrage_property_value: the value to match based on the dimensions coming from Monasca For example: config: - metric_name: low_disk_space vitrage_property: id vitrage_property_value: ${resource_id} # resource_id is the dimension of libvirt metrics - metric_name: low_disk_space vitrage_property: id vitrage_property_value: ${hosname} # in case the disk_space is monitored for a host (?) - metric_name: http_status vitrage_property: service_id vitrage_property_value: ${hostname}/${service} - metric_name: nic_status vitrage_property: id vitrage_property_value: ${hostname}/${nic_name} - … What do you think? Can a metric like low_disk_space be set both for an instance (with a resource_id that is uuid) and for a host (with hostname)? How can we tell which dimension to use? Do you think that this configuration can solve the POC use case? Ifat On Sat, Dec 15, 2018 at 5:50 AM Joseph Davis wrote: > I left Bartosz some comments on his review, and I'll add a few things > below. > > joseph > > On 12/13/18 12:52 AM, openstack-discuss-request at lists.openstack.org wrote > > From: Ifat Afek > > Message-ID: > > < > CALxdkcxxrtYYv+f4-enZ2uuA88qJdPuze732Ufg6MLMADBcOtg at mail.gmail.com> > > > > Hi Witek, > > > > On Wed, Dec 12, 2018 at 5:04 PM Bedyk, Witold < > witold.bedyk at est.fujitsu.com> > > wrote: > > > > > >>> There is one issue that we need to close though – how to connect the > >>> Monasca alarms to the resources in Vitrage. > >>> In order to connect an alarm to a resource, Vitrage should be able to > >>> identify that resource in its entity graph using the dimensions coming > from > >>> Monasca. I understood that these dimensions are configurable and not > >>> pre-defined. > >> Correct. To make the picture complete: every alarm contains an > associated > >> `metric name` and a set of dimensions which identify the monitored > >> resource. Both metric name and dimensions could potentially be used in > >> Vitrage. > >> > >> > >> > >> 1. For OpenStack services we typically use dimension keys `hostname` and > >> `service`. Examples would be: > >> > >> `name`: `http_status`, `dimensions`: {`hostname`: > `node1`, > >> `service`: `keystone`, `url`: `http://node1/identity` > > >> } > >> > >> > >> > >> Libvirt metrics all have the dimension keys `hostname`, > >> `service`=`compute`, `resource_id`=instance_id > >> > > > > By instance_id do you mean the libvirt id or the OpenStack UUID? In order > > to correlate the id with the vm that exists in Vitrage, we need the Nova > > UUID. > > Another question: are these dimensions names always the same? Is it > > possible to change their names? > > > I believe it is the OpenStack id in each case. > > Dimension names are always the same per type of metric, but different > metrics can define different dimensions. > > For example, the http_status metric has a 'url' but disk.space_used_perc > has a 'device' and cpu.idle_perc has neither. All metrics have > 'hostname', 'service', and a few other dimensions in common. > > >> 2. For other resources I’m not sure if we can define a general rule for > >> assignments. As you have said, the unique information may be included in > >> more the one dimension. > >> > >> > >> > >> For Prometheus, we use labels on each metric as dimensions. Additional > >> dimensions can be configured in agent per Prometheus endpoint. > >> > We also have a monasca-ceilometer component (aka. Ceilosca) that can > send metrics from Ceilometer to Monasca. These metrics include the > OpenStack resource_id of the source of the metric. Any alarms created > from Ceilometer data can carry through that resource_id. From what I've > seen we don't currently include a resource_type, but that should be > something we can configure in the metric. If nothing else, we may be > able to statically define the resource_type as part of the metric > definition (each alarm will be specific to the type of resource > anyway). But don't hold me to that - I have some more reading to do to > understand the nuances. :) The dimensions from the metrics are carried > over to the alarms. > > > > Can you give us some more examples of Monasca dimensions? > > As Witek said, the metric dimensions are pretty flexible. You can see > some of the dimensions mentioned in my answer above. I can try to pull a > list of some standard alarm definitions and associated metrics from a > SUSE install, or if we have a particular few alarms we want to start > with then we can focus on those. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfredo.deluca at gmail.com Sat Dec 15 15:24:53 2018 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Sat, 15 Dec 2018 16:24:53 +0100 Subject: Openstack Magnum Message-ID: Hi all. Just installed *openstack* and *magnum* with *ansible-openstack AIO.* All works well except magnum itself. When I click on the dashboard on* Container Infra *then C*lusters or clusters templates *I get the following errors: *Error: *Unable to retrieve the clusters. *Error: *Unable to retrieve the stats. - Not sure why. Any clue? Cheers -- *Alfredo* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Sun Dec 16 17:52:19 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sun, 16 Dec 2018 18:52:19 +0100 Subject: Openstack Magnum In-Reply-To: References: Message-ID: Hello Luca, I git same issue on queens. Are you in rocky? Regards Ignazio Il giorno Dom 16 Dic 2018 16:57 Alfredo De Luca ha scritto: > Hi all. > Just installed *openstack* and *magnum* with *ansible-openstack AIO.* > > All works well except magnum itself. When I click on the dashboard on* > Container Infra *then C*lusters or clusters templates *I get the > following errors: > *Error: *Unable to retrieve the clusters. > *Error: *Unable to retrieve the stats. > > - Not sure why. > > > Any clue? > > Cheers > > -- > *Alfredo* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Sun Dec 16 18:30:48 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sun, 16 Dec 2018 19:30:48 +0100 Subject: Magnum queens requirements Message-ID: Hi All, Does magnum require etcd installed on controller and computes nodes? Which opentack services require etcd on controllers and computes? Recards ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From feilong at catalyst.net.nz Sun Dec 16 20:43:31 2018 From: feilong at catalyst.net.nz (Feilong Wang) Date: Mon, 17 Dec 2018 09:43:31 +1300 Subject: Magnum queens requirements In-Reply-To: References: Message-ID: <6914326c-a1ca-d328-4d28-e1a37162820a@catalyst.net.nz> Hi Ignazio, Magnum doesn't need etcd on your OpenStack controller and compute nodes. Magnum will install etcd on your k8s master nodes if you're trying to create k8s cluster. At this moment, for all the core services, I don't think any of them depedending on etcd. I would suggest to join in #openstack-container irc channel to resolve your Magnum issues more quicker. Cheers. On 17/12/18 7:30 AM, Ignazio Cassano wrote: > Hi All, > Does magnum require etcd installed on controller and computes nodes? > Which opentack services require etcd on controllers  and computes? > Recards > ignazio -- 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 -------------------------------------------------------------------------- From feilong at catalyst.net.nz Sun Dec 16 20:47:10 2018 From: feilong at catalyst.net.nz (Feilong Wang) Date: Mon, 17 Dec 2018 09:47:10 +1300 Subject: Magnum queens requirements In-Reply-To: <6914326c-a1ca-d328-4d28-e1a37162820a@catalyst.net.nz> References: <6914326c-a1ca-d328-4d28-e1a37162820a@catalyst.net.nz> Message-ID: <70ff1595-7cef-d863-9b70-130d86794437@catalyst.net.nz> typo, it should be #openstack-containers On 17/12/18 9:43 AM, Feilong Wang wrote: > Hi Ignazio, > > Magnum doesn't need etcd on your OpenStack controller and compute nodes. > Magnum will install etcd on your k8s master nodes if you're trying to > create k8s cluster. At this moment, for all the core services, I don't > think any of them depedending on etcd. I would suggest to join in > #openstack-container irc channel to resolve your Magnum issues more > quicker. Cheers. > > > On 17/12/18 7:30 AM, Ignazio Cassano wrote: >> Hi All, >> Does magnum require etcd installed on controller and computes nodes? >> Which opentack services require etcd on controllers  and computes? >> Recards >> ignazio -- 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 -------------------------------------------------------------------------- From mrhillsman at gmail.com Sun Dec 16 22:07:30 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Sun, 16 Dec 2018 16:07:30 -0600 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: References: <380a044d-8185-a312-2f7e-40bd663cf49c@openstack.org> Message-ID: Hi everyone, I would hate for this fade away as I think we have support to keep this moving forward even if it is very slowly. What should be the next step? OpenLab can provide the infrastructure needed to run pretty much anything as folks need without disturbing any existing production environments. Honestly if folks interested in seeing this happen can help draft the scope of work and a roadmap to get it done that would be great. I personally do not want to be the primary person to handle this as it is not my strength but I can help make sure the environment(s) needed are available, work on recruiting help once we have some things outlined, keep communication available, facilitate meetings (even in different time zones), etc. Thoughts? On Fri, Dec 7, 2018 at 1:13 PM Michael McCune wrote: > hey folks, > > i realized after some discussion with the other API SIG cores that i > might not have been clear enough in my responses. > > for the record, i _do not_ have an objection to bringing the SDK work > into the mission of the API SIG. further, i think it does make good > sense to rally all these concerns in one place and will reduce the > confusion that coalesces around new SIG formations. i do maintain that > we will need to do some work and bring on fresh bodies into the SIG to > ensure the best outcomes. > > for transparency sake, here is a link[0] to the chat we had in > #openstack-sdk among the API SIG cores. > > peace o/ > > [0]: > http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2018-12-07.log.html#t2018-12-07T16:06:43 > > -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zbitter at redhat.com Sun Dec 16 23:24:42 2018 From: zbitter at redhat.com (Zane Bitter) Date: Mon, 17 Dec 2018 12:24:42 +1300 Subject: queens heat db deadlock In-Reply-To: References: Message-ID: <38bae882-b4ac-4b55-5345-e27edbd582f3@redhat.com> On 14/12/18 4:06 AM, Ignazio Cassano wrote: > Hi All, > I installed queens on centos 7. > Heat seems to work fine with templates I wrote but when I create magnum > cluster > I often face with db deadlock in heat-engine log: The stacktrace below is in stack delete, so do you mean that the problem occurs when deleting a Magnum cluster, or can it occur any time with a magnum cluster? > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource Traceback (most > recent call last): > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource   File > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 918, in > _action_recorder > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource     yield > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource   File > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 2035, > in delete > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource     *action_args) > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource   File > "/usr/lib/python2.7/site-packages/heat/engine/scheduler.py", line 346, > in wrapper > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource     step = > next(subtask) > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource   File > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 977, in > action_handler_task > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource     done = > check(handler_data) > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource   File > "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", > line 587, in check_delete_complete > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource     return > self._check_status_complete(self.DELETE) > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource   File > "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", > line 454, in _check_status_complete > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource     action=action) > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > ResourceFailure: resources[0]: (pymysql.err.InternalError) (1213, > u'Deadlock found when trying to get lock; try restarting transaction') > (Background on this error at: http://sqlalche.me/e/2j85) > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > 2018-12-13 11:48:46.030 89597 INFO heat.engine.stack > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] > Stack DELETE FAILED > (swarm-clustergp27-ebhsalhb4bop-swarm_primary_master-tzgkh3ncmymw): > Resource DELETE failed: resources[0]: (pymysql.err.InternalError) (1213, > u'Deadlock found when trying to get lock; try restarting transaction') > (Background on this error at: http://sqlalche.me/e/2j85) > 2018-12-13 11:48:46.844 89595 INFO heat.engine.resource > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] > DELETE: ResourceGroup "swarm_primary_master" > [6984db3c-3ac1-4afc-901f-21b3e7f230a7] Stack > "swarm-clustergp27-ebhsalhb4bop" [b43256fa-52e2-4613-ac15-63fd9340a8be] > > > I read this issue was solved in heat version 10 but seems not. The patch for bug 1732969, which is in Queens, is probably the fix you're referring to: https://review.openstack.org/#/c/521170/1 The traceback in that bug included the SQL statement that was failing. I'm not sure if that isn't included in your traceback because SQLAlchemy didn't report it, or if it's because that traceback is actually from the parent stack. If you have a traceback from the original failure in the child stack that would be useful. If there's a way to turn on more detailed reporting of errors in SQLAlchemy that would also be useful. Since this is a delete, it's possible that we need a retry-on-deadlock on the resource_delete() function also (though resource_update() is actually used more during a delete to update the status). - ZB From alfredo.deluca at gmail.com Sun Dec 16 21:51:34 2018 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Sun, 16 Dec 2018 22:51:34 +0100 Subject: Openstack Magnum In-Reply-To: References: Message-ID: Hi Ignazio. I am actually on Stein.... On Sun, Dec 16, 2018 at 6:52 PM Ignazio Cassano wrote: > Hello Luca, I git same issue on queens. > Are you in rocky? > Regards > Ignazio > > > Il giorno Dom 16 Dic 2018 16:57 Alfredo De Luca > ha scritto: > >> Hi all. >> Just installed *openstack* and *magnum* with *ansible-openstack AIO.* >> >> All works well except magnum itself. When I click on the dashboard on* >> Container Infra *then C*lusters or clusters templates *I get the >> following errors: >> *Error: *Unable to retrieve the clusters. >> *Error: *Unable to retrieve the stats. >> >> - Not sure why. >> >> >> Any clue? >> >> Cheers >> >> -- >> *Alfredo* >> >> -- *Alfredo* -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangtrinhnt at gmail.com Mon Dec 17 01:29:13 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Mon, 17 Dec 2018 10:29:13 +0900 Subject: [Searchlight] Team meeting today at 13:30 UTC Message-ID: Hi team, We will have a team meeting today at 13:30 UTC on the #openstack-searchlight channel. Please join me for updates and discussion about the next steps of Searchlight. Bests, -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangtrinhnt at gmail.com Mon Dec 17 01:48:36 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Mon, 17 Dec 2018 10:48:36 +0900 Subject: [Devstack][Freezer] ElasticSearch installation fails Message-ID: Dear devstack team, Recently, the ElasticSearch installation fails and that makes Freezer (e.g., [1]) or any other services that depend on ElasticSearch fail the CI tests. A preliminary investigation suggests that it may cause by the test environment was switched to Ubuntu 18.04 (i.e., bionic). I made some modifications to the installation script in [2] hopefully will fix the problem. If someone in the Devstack team can have look at [2], it would be great. [1] http://logs.openstack.org/49/624549/3/check/freezer-tempest-agent/d0a52d0/job-output.txt.gz#_2018-12-13_01_38_02_974809 [2] https://review.openstack.org/#/c/625174/ Many thanks, -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From iwienand at redhat.com Mon Dec 17 03:16:26 2018 From: iwienand at redhat.com (Ian Wienand) Date: Mon, 17 Dec 2018 14:16:26 +1100 Subject: [dev][openstacksdk][infra] openstacksdk and dogpile 0.7.0+ cache errors In-Reply-To: <20181214233200.tu4apx6zn6grbsic@yuggoth.org> References: <20181214034259.GA16789@fedora19.localdomain> <20181214145007.3ftbfhscvpwibl5k@yuggoth.org> <20181214185043.wrph6ncynxgyhtzq@yuggoth.org> <20181214233200.tu4apx6zn6grbsic@yuggoth.org> Message-ID: <20181217031626.GA31348@fedora19.localdomain> On Fri, Dec 14, 2018 at 11:32:00PM +0000, Jeremy Stanley wrote: > On 2018-12-14 17:20:05 -0500 (-0500), Mike Bayer wrote: > [...] > > OK, so first step is...identify some zuul jobs? I have CI for > > sqlalchemy, alembic, dogpile-cache that each would benefit from db > > /cache-centric builds. > > I mean, if there's a job which was failing immediately after the > release in our CI system and we think that's a reasonable > integration test to perform, we could work out a way to have it > install dogpile from the master branch source instead of a released > package. I would suggest we use the nodepool-functional-py35-src jobs. These jobs are failing [1] These jobs install a devstack environment, then nodepool, openstacksdk, diskimage-builder and glean from git; then they build an image with dib, upload it to the devstack cloud and ensure it boots and communicates. This means openstacksdk (and hence dogpile) is being used by nodepool against a real-life cloud doing very real-life things like creating servers, listing them and connecting all the various bits up. Connecting to dogpile's gerrit as 3rd party CI is possible. But I'd suggest we KISS to start with. As mentioned above, cloning from github master during the job is a good place to start, as I'm not sure at this point if devstack correctly handles installing non-openstack dependencies from Zuul checkouts during test runs. Reviews: https://review.openstack.org/625467 Add github dogpile.cache to project list https://review.openstack.org/625457 [wip] Add dogpile.cache master to the -src tests -i [1] http://logs.openstack.org/55/624855/3/check/nodepool-functional-py35-src/c63c515/controller/logs/screen-nodepool-builder.txt.gz#_Dec_13_14_46_10_332628 From ignaziocassano at gmail.com Mon Dec 17 05:44:36 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 17 Dec 2018 06:44:36 +0100 Subject: queens heat db deadlock In-Reply-To: <38bae882-b4ac-4b55-5345-e27edbd582f3@redhat.com> References: <38bae882-b4ac-4b55-5345-e27edbd582f3@redhat.com> Message-ID: Hello Zane, it happens also when I create a magnum cluster . My mariadb cluster is behind haproxy. Do you need any other info? Thanks Ignazio Il giorno Lun 17 Dic 2018 00:28 Zane Bitter ha scritto: > On 14/12/18 4:06 AM, Ignazio Cassano wrote: > > Hi All, > > I installed queens on centos 7. > > Heat seems to work fine with templates I wrote but when I create magnum > > cluster > > I often face with db deadlock in heat-engine log: > > The stacktrace below is in stack delete, so do you mean that the problem > occurs when deleting a Magnum cluster, or can it occur any time with a > magnum cluster? > > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource Traceback (most > > recent call last): > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 918, in > > _action_recorder > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource yield > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 2035, > > in delete > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > *action_args) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > "/usr/lib/python2.7/site-packages/heat/engine/scheduler.py", line 346, > > in wrapper > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource step = > > next(subtask) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 977, in > > action_handler_task > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource done = > > check(handler_data) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > > "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", > > line 587, in check_delete_complete > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource return > > self._check_status_complete(self.DELETE) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > > "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", > > line 454, in _check_status_complete > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > action=action) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > > ResourceFailure: resources[0]: (pymysql.err.InternalError) (1213, > > u'Deadlock found when trying to get lock; try restarting transaction') > > (Background on this error at: http://sqlalche.me/e/2j85) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > > 2018-12-13 11:48:46.030 89597 INFO heat.engine.stack > > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] > > Stack DELETE FAILED > > (swarm-clustergp27-ebhsalhb4bop-swarm_primary_master-tzgkh3ncmymw): > > Resource DELETE failed: resources[0]: (pymysql.err.InternalError) (1213, > > u'Deadlock found when trying to get lock; try restarting transaction') > > (Background on this error at: http://sqlalche.me/e/2j85) > > 2018-12-13 11:48:46.844 89595 INFO heat.engine.resource > > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] > > DELETE: ResourceGroup "swarm_primary_master" > > [6984db3c-3ac1-4afc-901f-21b3e7f230a7] Stack > > "swarm-clustergp27-ebhsalhb4bop" [b43256fa-52e2-4613-ac15-63fd9340a8be] > > > > > > I read this issue was solved in heat version 10 but seems not. > > The patch for bug 1732969, which is in Queens, is probably the fix > you're referring to: https://review.openstack.org/#/c/521170/1 > > The traceback in that bug included the SQL statement that was failing. > I'm not sure if that isn't included in your traceback because SQLAlchemy > didn't report it, or if it's because that traceback is actually from the > parent stack. If you have a traceback from the original failure in the > child stack that would be useful. If there's a way to turn on more > detailed reporting of errors in SQLAlchemy that would also be useful. > > Since this is a delete, it's possible that we need a retry-on-deadlock > on the resource_delete() function also (though resource_update() is > actually used more during a delete to update the status). > > - ZB > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Mon Dec 17 05:47:49 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 17 Dec 2018 06:47:49 +0100 Subject: Openstack Magnum In-Reply-To: References: Message-ID: Thanks . Il giorno Dom 16 Dic 2018 22:51 Alfredo De Luca ha scritto: > Hi Ignazio. I am actually on Stein.... > > > On Sun, Dec 16, 2018 at 6:52 PM Ignazio Cassano > wrote: > >> Hello Luca, I git same issue on queens. >> Are you in rocky? >> Regards >> Ignazio >> >> >> Il giorno Dom 16 Dic 2018 16:57 Alfredo De Luca >> ha scritto: >> >>> Hi all. >>> Just installed *openstack* and *magnum* with *ansible-openstack AIO.* >>> >>> All works well except magnum itself. When I click on the dashboard on* >>> Container Infra *then C*lusters or clusters templates *I get the >>> following errors: >>> *Error: *Unable to retrieve the clusters. >>> *Error: *Unable to retrieve the stats. >>> >>> - Not sure why. >>> >>> >>> Any clue? >>> >>> Cheers >>> >>> -- >>> *Alfredo* >>> >>> > > -- > *Alfredo* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Mon Dec 17 05:48:40 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 17 Dec 2018 06:48:40 +0100 Subject: Magnum queens requirements In-Reply-To: <70ff1595-7cef-d863-9b70-130d86794437@catalyst.net.nz> References: <6914326c-a1ca-d328-4d28-e1a37162820a@catalyst.net.nz> <70ff1595-7cef-d863-9b70-130d86794437@catalyst.net.nz> Message-ID: Many thanks Il giorno Dom 16 Dic 2018 21:49 Feilong Wang ha scritto: > typo, it should be #openstack-containers > > > On 17/12/18 9:43 AM, Feilong Wang wrote: > > Hi Ignazio, > > > > Magnum doesn't need etcd on your OpenStack controller and compute nodes. > > Magnum will install etcd on your k8s master nodes if you're trying to > > create k8s cluster. At this moment, for all the core services, I don't > > think any of them depedending on etcd. I would suggest to join in > > #openstack-container irc channel to resolve your Magnum issues more > > quicker. Cheers. > > > > > > On 17/12/18 7:30 AM, Ignazio Cassano wrote: > >> Hi All, > >> Does magnum require etcd installed on controller and computes nodes? > >> Which opentack services require etcd on controllers and computes? > >> Recards > >> ignazio > > -- > 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: From ignaziocassano at gmail.com Mon Dec 17 05:49:54 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 17 Dec 2018 06:49:54 +0100 Subject: queens heat db deadlock In-Reply-To: <38bae882-b4ac-4b55-5345-e27edbd582f3@redhat.com> References: <38bae882-b4ac-4b55-5345-e27edbd582f3@redhat.com> Message-ID: Ps I will send logs for stack create asap. Ignazio Il giorno Lun 17 Dic 2018 00:28 Zane Bitter ha scritto: > On 14/12/18 4:06 AM, Ignazio Cassano wrote: > > Hi All, > > I installed queens on centos 7. > > Heat seems to work fine with templates I wrote but when I create magnum > > cluster > > I often face with db deadlock in heat-engine log: > > The stacktrace below is in stack delete, so do you mean that the problem > occurs when deleting a Magnum cluster, or can it occur any time with a > magnum cluster? > > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource Traceback (most > > recent call last): > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 918, in > > _action_recorder > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource yield > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 2035, > > in delete > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > *action_args) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > "/usr/lib/python2.7/site-packages/heat/engine/scheduler.py", line 346, > > in wrapper > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource step = > > next(subtask) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 977, in > > action_handler_task > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource done = > > check(handler_data) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > > "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", > > line 587, in check_delete_complete > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource return > > self._check_status_complete(self.DELETE) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > > "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", > > line 454, in _check_status_complete > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > action=action) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > > ResourceFailure: resources[0]: (pymysql.err.InternalError) (1213, > > u'Deadlock found when trying to get lock; try restarting transaction') > > (Background on this error at: http://sqlalche.me/e/2j85) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > > 2018-12-13 11:48:46.030 89597 INFO heat.engine.stack > > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] > > Stack DELETE FAILED > > (swarm-clustergp27-ebhsalhb4bop-swarm_primary_master-tzgkh3ncmymw): > > Resource DELETE failed: resources[0]: (pymysql.err.InternalError) (1213, > > u'Deadlock found when trying to get lock; try restarting transaction') > > (Background on this error at: http://sqlalche.me/e/2j85) > > 2018-12-13 11:48:46.844 89595 INFO heat.engine.resource > > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] > > DELETE: ResourceGroup "swarm_primary_master" > > [6984db3c-3ac1-4afc-901f-21b3e7f230a7] Stack > > "swarm-clustergp27-ebhsalhb4bop" [b43256fa-52e2-4613-ac15-63fd9340a8be] > > > > > > I read this issue was solved in heat version 10 but seems not. > > The patch for bug 1732969, which is in Queens, is probably the fix > you're referring to: https://review.openstack.org/#/c/521170/1 > > The traceback in that bug included the SQL statement that was failing. > I'm not sure if that isn't included in your traceback because SQLAlchemy > didn't report it, or if it's because that traceback is actually from the > parent stack. If you have a traceback from the original failure in the > child stack that would be useful. If there's a way to turn on more > detailed reporting of errors in SQLAlchemy that would also be useful. > > Since this is a delete, it's possible that we need a retry-on-deadlock > on the resource_delete() function also (though resource_update() is > actually used more during a delete to update the status). > > - ZB > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Mon Dec 17 07:56:14 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 17 Dec 2018 08:56:14 +0100 Subject: queens heat db deadlock In-Reply-To: <38bae882-b4ac-4b55-5345-e27edbd582f3@redhat.com> References: <38bae882-b4ac-4b55-5345-e27edbd582f3@redhat.com> Message-ID: Hello, attached here there is part of heat engine log when creating a stack Regards Ignazio Il giorno lun 17 dic 2018 alle ore 00:28 Zane Bitter ha scritto: > On 14/12/18 4:06 AM, Ignazio Cassano wrote: > > Hi All, > > I installed queens on centos 7. > > Heat seems to work fine with templates I wrote but when I create magnum > > cluster > > I often face with db deadlock in heat-engine log: > > The stacktrace below is in stack delete, so do you mean that the problem > occurs when deleting a Magnum cluster, or can it occur any time with a > magnum cluster? > > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource Traceback (most > > recent call last): > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 918, in > > _action_recorder > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource yield > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 2035, > > in delete > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > *action_args) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > "/usr/lib/python2.7/site-packages/heat/engine/scheduler.py", line 346, > > in wrapper > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource step = > > next(subtask) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 977, in > > action_handler_task > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource done = > > check(handler_data) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > > "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", > > line 587, in check_delete_complete > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource return > > self._check_status_complete(self.DELETE) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > > > "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", > > line 454, in _check_status_complete > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > action=action) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > > ResourceFailure: resources[0]: (pymysql.err.InternalError) (1213, > > u'Deadlock found when trying to get lock; try restarting transaction') > > (Background on this error at: http://sqlalche.me/e/2j85) > > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > > 2018-12-13 11:48:46.030 89597 INFO heat.engine.stack > > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] > > Stack DELETE FAILED > > (swarm-clustergp27-ebhsalhb4bop-swarm_primary_master-tzgkh3ncmymw): > > Resource DELETE failed: resources[0]: (pymysql.err.InternalError) (1213, > > u'Deadlock found when trying to get lock; try restarting transaction') > > (Background on this error at: http://sqlalche.me/e/2j85) > > 2018-12-13 11:48:46.844 89595 INFO heat.engine.resource > > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] > > DELETE: ResourceGroup "swarm_primary_master" > > [6984db3c-3ac1-4afc-901f-21b3e7f230a7] Stack > > "swarm-clustergp27-ebhsalhb4bop" [b43256fa-52e2-4613-ac15-63fd9340a8be] > > > > > > I read this issue was solved in heat version 10 but seems not. > > The patch for bug 1732969, which is in Queens, is probably the fix > you're referring to: https://review.openstack.org/#/c/521170/1 > > The traceback in that bug included the SQL statement that was failing. > I'm not sure if that isn't included in your traceback because SQLAlchemy > didn't report it, or if it's because that traceback is actually from the > parent stack. If you have a traceback from the original failure in the > child stack that would be useful. If there's a way to turn on more > detailed reporting of errors in SQLAlchemy that would also be useful. > > Since this is a delete, it's possible that we need a retry-on-deadlock > on the resource_delete() function also (though resource_update() is > actually used more during a delete to update the status). > > - ZB > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: heat-engine.log Type: text/x-log Size: 5684 bytes Desc: not available URL: From strigazi at gmail.com Mon Dec 17 08:14:56 2018 From: strigazi at gmail.com (Spyros Trigazis) Date: Mon, 17 Dec 2018 09:14:56 +0100 Subject: [magnum] Core reviewers update Message-ID: Hello list, During 2018 magnum's repos became more active with notable contributions, in alphabetical order, from Blizzard, Catalyst Cloud and StackHPC. At the same time part of the core reviewers group was inactive. Adrian Otto, Eli Qiao, Jaycen Grant, Madhuri Kumari and Ton Ngo have agreed to step down and make room for new contributors. Thank you for all your contributions! I would like to encourage current core reviewers to participate in the project. Let's evaluate the status of the core team in three months (end of March 2019). Cheers, Spyros -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfredo.deluca at gmail.com Mon Dec 17 08:53:01 2018 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Mon, 17 Dec 2018 09:53:01 +0100 Subject: Openstack Magnum In-Reply-To: References: Message-ID: Hi Ignazio. Any clue. Not sure why it doesn't work. anyone? On Mon, Dec 17, 2018 at 6:48 AM Ignazio Cassano wrote: > Thanks . > > Il giorno Dom 16 Dic 2018 22:51 Alfredo De Luca > ha scritto: > >> Hi Ignazio. I am actually on Stein.... >> >> >> On Sun, Dec 16, 2018 at 6:52 PM Ignazio Cassano >> wrote: >> >>> Hello Luca, I git same issue on queens. >>> Are you in rocky? >>> Regards >>> Ignazio >>> >>> >>> Il giorno Dom 16 Dic 2018 16:57 Alfredo De Luca < >>> alfredo.deluca at gmail.com> ha scritto: >>> >>>> Hi all. >>>> Just installed *openstack* and *magnum* with *ansible-openstack AIO.* >>>> >>>> All works well except magnum itself. When I click on the dashboard on* >>>> Container Infra *then C*lusters or clusters templates *I get the >>>> following errors: >>>> *Error: *Unable to retrieve the clusters. >>>> *Error: *Unable to retrieve the stats. >>>> >>>> - Not sure why. >>>> >>>> >>>> Any clue? >>>> >>>> Cheers >>>> >>>> -- >>>> *Alfredo* >>>> >>>> >> >> -- >> *Alfredo* >> >> -- *Alfredo* -------------- next part -------------- An HTML attachment was scrubbed... URL: From strigazi at gmail.com Mon Dec 17 09:05:30 2018 From: strigazi at gmail.com (Spyros Trigazis) Date: Mon, 17 Dec 2018 10:05:30 +0100 Subject: Openstack Magnum In-Reply-To: References: Message-ID: Hello Alfredo, Try with the cli openstack coe service list. Check the logs of the magnum conductor and API. Cheers, Spyros On Mon, 17 Dec 2018 at 09:54, Alfredo De Luca wrote: > Hi Ignazio. Any clue. Not sure why it doesn't work. > > anyone? > > > > On Mon, Dec 17, 2018 at 6:48 AM Ignazio Cassano > wrote: > >> Thanks . >> >> Il giorno Dom 16 Dic 2018 22:51 Alfredo De Luca >> ha scritto: >> >>> Hi Ignazio. I am actually on Stein.... >>> >>> >>> On Sun, Dec 16, 2018 at 6:52 PM Ignazio Cassano < >>> ignaziocassano at gmail.com> wrote: >>> >>>> Hello Luca, I git same issue on queens. >>>> Are you in rocky? >>>> Regards >>>> Ignazio >>>> >>>> >>>> Il giorno Dom 16 Dic 2018 16:57 Alfredo De Luca < >>>> alfredo.deluca at gmail.com> ha scritto: >>>> >>>>> Hi all. >>>>> Just installed *openstack* and *magnum* with *ansible-openstack AIO.* >>>>> >>>>> All works well except magnum itself. When I click on the dashboard on* >>>>> Container Infra *then C*lusters or clusters templates *I get the >>>>> following errors: >>>>> *Error: *Unable to retrieve the clusters. >>>>> *Error: *Unable to retrieve the stats. >>>>> >>>>> - Not sure why. >>>>> >>>>> >>>>> Any clue? >>>>> >>>>> Cheers >>>>> >>>>> -- >>>>> *Alfredo* >>>>> >>>>> >>> >>> -- >>> *Alfredo* >>> >>> > > -- > *Alfredo* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikal at stillhq.com Mon Dec 17 09:25:52 2018 From: mikal at stillhq.com (Michael Still) Date: Mon, 17 Dec 2018 20:25:52 +1100 Subject: [tosca-parser] Failing to get functions from capabilities Message-ID: Hi, I'm trying to use tosca-parser to parse CSAR files. Its working quite well, until I hit a wall with capabilities today. Specifically I am testing with the single instance wordpress example CSAR, which uses a get_input for the num_cpus argument for host capabilities for the server. Based on how properties work, I would expect to get a function back for anything which requires referencing another value, but in the case of capabilities I either get the hardcoded value (strings, ints etc), or a None for values which would be functions if we were talking about prototypes. Here's a snippet of example code: #!/usr/bin/python import sys from jinja2 import Template import toscaparser.functions from toscaparser.tosca_template import ToscaTemplate tosca = ToscaTemplate(sys.argv[1]) for nodetemplate in tosca.nodetemplates: print print('Processing node template %s'% nodetemplate.name) capabilities = nodetemplate.get_capabilities_objects() for cap in capabilities: propobjs = cap.get_properties_objects() if not propobjs: continue for po in propobjs: print(' %s: %s' %(po.name, po.value)) Which returns this: $ python _capabilities.py csar_wordpress.zip No handlers could be found for logger "tosca.model" Processing node template wordpress network_name: PRIVATE initiator: source protocol: tcp secure: False Processing node template webserver network_name: PRIVATE initiator: source protocol: tcp secure: False secure: True Processing node template mysql_dbms Processing node template mysql_database Processing node template server secure: True min_instances: 1 max_instances: 1 mem_size: 4096 MB num_cpus: None disk_size: 10 GB distribution: Fedora version: 18.0 type: Linux architecture: x86_64 I would expect num_cpus for the "server" node_template to be a GetInput() function based on its definition in the CSAR, but instead I get None. Is there an example somewhere of how to correctly access functions for capabilities? Thanks, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Mon Dec 17 09:29:11 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Mon, 17 Dec 2018 10:29:11 +0100 Subject: Openstack Magnum In-Reply-To: References: Message-ID: I am on #openstack-containers irc. They help us Il giorno lun 17 dic 2018 alle ore 09:53 Alfredo De Luca < alfredo.deluca at gmail.com> ha scritto: > Hi Ignazio. Any clue. Not sure why it doesn't work. > > anyone? > > > > On Mon, Dec 17, 2018 at 6:48 AM Ignazio Cassano > wrote: > >> Thanks . >> >> Il giorno Dom 16 Dic 2018 22:51 Alfredo De Luca >> ha scritto: >> >>> Hi Ignazio. I am actually on Stein.... >>> >>> >>> On Sun, Dec 16, 2018 at 6:52 PM Ignazio Cassano < >>> ignaziocassano at gmail.com> wrote: >>> >>>> Hello Luca, I git same issue on queens. >>>> Are you in rocky? >>>> Regards >>>> Ignazio >>>> >>>> >>>> Il giorno Dom 16 Dic 2018 16:57 Alfredo De Luca < >>>> alfredo.deluca at gmail.com> ha scritto: >>>> >>>>> Hi all. >>>>> Just installed *openstack* and *magnum* with *ansible-openstack AIO.* >>>>> >>>>> All works well except magnum itself. When I click on the dashboard on* >>>>> Container Infra *then C*lusters or clusters templates *I get the >>>>> following errors: >>>>> *Error: *Unable to retrieve the clusters. >>>>> *Error: *Unable to retrieve the stats. >>>>> >>>>> - Not sure why. >>>>> >>>>> >>>>> Any clue? >>>>> >>>>> Cheers >>>>> >>>>> -- >>>>> *Alfredo* >>>>> >>>>> >>> >>> -- >>> *Alfredo* >>> >>> > > -- > *Alfredo* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amotoki at gmail.com Mon Dec 17 09:29:35 2018 From: amotoki at gmail.com (Akihiro Motoki) Date: Mon, 17 Dec 2018 18:29:35 +0900 Subject: [dev] [horizon] [tc] [release] [PTI] is tox a requirement even if tox is not used? Message-ID: Hi, # I am not sure [tc] and [release] tags are appropriate. Horizon team maintains xstatic-* repositories [1]. We have a question on the need for tox.ini. Can we drop tox.ini completely considering the situation below? These repositories do not depend on 'tox' on testing from their nature of re-packaging JS module in a python way. In addition, there is no document provided. The current PTI mentions only "tox -e docs". # Previously PTI required "venv" tox ini but it is no longer mentioned. [1] http://git.openstack.org/cgit/?q=xstatic- Best Regards, Akihiro Motoki (IRC: amotoki) -------------- next part -------------- An HTML attachment was scrubbed... URL: From amotoki at gmail.com Mon Dec 17 09:42:14 2018 From: amotoki at gmail.com (Akihiro Motoki) Date: Mon, 17 Dec 2018 18:42:14 +0900 Subject: [dev] [neutron] policy-in-code status update Message-ID: Hi neutrinos, I am working on policy-in-code support in neutron and have a good progress these weeks. [Progress] - The basic policy-in-code in neutron repo was merged. Several follow-up improvements and cleanup will be coming in the neutron repo. - policy-in-code support in several neutron related projects are proposed. There are found at https://review.openstack.org/#/q/topic:bp/neutron-policy-in-code+(status:open+OR+status:merged) [Request to neutron related project maintainers] neutron-dynamic-routing, neutron-fwaas,neutron-vpnaas, networking-bgpvpn, networking-sfc and vmware-nsx: I proposed patches. Review and testing from each team would be appreciated. networking-midonet and networking-cisco In my understanding, they defines its own resources and attributes, so their own policies exists. My bandwidth cannot cover them. Could you take over policy-in-code support? I belileve the above gerrit link would provide good examples. networking-ovn, networking-odl and networking-bagpipe In my understanding, they defines no extra resources and attributes, so there is no policies specific to them and policy-in-code support is unnecessary. Could you confirm my understanding is correct. If you need some policy definition, it means you need some work on policy-in-code. If you have questions, feel free to ask me. Best Regards, Akihiro Motoki (IRC: amotoki) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougal at redhat.com Mon Dec 17 10:13:44 2018 From: dougal at redhat.com (Dougal Matthews) Date: Mon, 17 Dec 2018 10:13:44 +0000 Subject: [mistral] Standing down as PTL Message-ID: Hey everyone, I am announcing that I am going to stand down as Mistral PTL. Due to a change in priorities I am no longer able to give the project the time it needs and deserves. This change will come into effect immediately. Being PTL has been a pleasure and a great learning experience for me. I have had the chance to work with a number of great folks and I am saddened to hang up the hat, particularly mid-cycle. However, I don't plan on going anywhere, I'll still be around and hope to remain an active member of the core team. Renat Akhmerov will be taking the role on again[1]. It is likely you will all know him as the previous Mistral PTL and therefore know the project will be in safe hands. Thanks everyone, Dougal [1]: https://review.openstack.org/#/c/625537/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From renat.akhmerov at gmail.com Mon Dec 17 10:25:38 2018 From: renat.akhmerov at gmail.com (Renat Akhmerov) Date: Mon, 17 Dec 2018 17:25:38 +0700 Subject: [mistral] Standing down as PTL In-Reply-To: References: Message-ID: <5634dc59-d1a8-4df8-b7ae-528c8e2b324a@Spark> Dougal, It’s been awesome time working with you regardless of your role. You did a great job as a PTL, I’m more than sure about that and yes, it is kind of sad that you’re stepping down. However, I understand the reasoning well and give a respect to your decision. I’m ready to continue as the new (actually old too) PTL and I hope we will do much more together. Thanks Renat Akhmerov @Nokia On 17 Dec 2018, 17:14 +0700, Dougal Matthews , wrote: > Hey everyone, > > I am announcing that I am going to stand down as Mistral PTL. Due to a change in priorities I am no longer able to give the project the time it needs and deserves. This change will come into effect immediately. > > Being PTL has been a pleasure and a great learning experience for me. I have had the chance to work with a number of great folks and I am saddened to hang up the hat, particularly mid-cycle. However, I don't plan on going anywhere, I'll still be around and hope to remain an active member of the core team. > > Renat Akhmerov will be taking the role on again[1]. It is likely you will all know him as the previous Mistral PTL and therefore know the project will be in safe hands. > > Thanks everyone, > Dougal > > [1]: https://review.openstack.org/#/c/625537/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcafarel at redhat.com Mon Dec 17 10:43:46 2018 From: bcafarel at redhat.com (Bernard Cafarelli) Date: Mon, 17 Dec 2018 11:43:46 +0100 Subject: [neutron] Bug deputy report, December 10 - December 16 Message-ID: Hi neutron folks, we started a new rotation of bug deputies, which means it was my turn to watch over new bugs. Here is the list of reported bugs, I highlighted those worth another look (other high bugs already have pending patches) *Undecided* * https://bugs.launchpad.net/neutron/+bug/1808731 - Needs the method to stop metadata proxy Latest bug, discussion in progress - feedback welcome *High* * https://bugs.launchpad.net/neutron/+bug/1808136 - l2 pop doesn't always provide the whole list of fdb entries on OVS restart A follow-up to https://bugs.launchpad.net/neutron/+bug/1804842, patch proposed at https://review.openstack.org/#/c/624669/ * https://bugs.launchpad.net/neutron/+bug/1808595 - fullstack test neutron.tests.fullstack.test_l3_agent.TestHAL3Agent.test_gateway_ip_changed failed intermittently Gate failure with patch proposed at https://review.openstack.org/#/c/625359/ * https://bugs.launchpad.net/neutron/+bug/1808541 - Openflow entries are not totally removed for stopped VM OVS flows issue (possible race condition?) - Has reproducer, details and logs but needs another pair of eyes *Medium* * https://bugs.launchpad.net/neutron/+bug/1808112 - rule:shared is not respected in port/subnet create waiting for feedback from policy experts * https://bugs.launchpad.net/neutron/+bug/1808171 - TaggedBootDevicesTest.test_tagged_boot_devices intermittently fails waiting for network-vif-plugged event which neutron does not send Intermittent gate failure in nova * https://bugs.launchpad.net/python-neutronclient/+bug/1808451 - Add Support for Querying Quotas with Usage CLI support for quotas detail, patch proposed at https://review.openstack.org/#/c/621507/ *RFE* * https://bugs.launchpad.net/neutron/+bug/1808062 - Limit VXLAN to within Neutron availability zones * https://bugs.launchpad.net/neutron/+bug/1808594 - Limit Geneve to within Neutron availability zones Clone of the previous one, for OVN (I added networking-ovn in affected projects) *Low* * https://bugs.launchpad.net/neutron/+bug/1807673 - Networking (neutron) concepts in neutron Easy doc fix ("facets" term use explanation) *Incomplete* * https://bugs.launchpad.net/neutron/+bug/1807483 - networksegments table in neutron can not be cleared automatically * https://bugs.launchpad.net/bugs/1808504 - the ip of port which device type is dhcp is null -- Bernard Cafarelli -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilien at redhat.com Mon Dec 17 11:35:50 2018 From: emilien at redhat.com (Emilien Macchi) Date: Mon, 17 Dec 2018 11:35:50 +0000 Subject: [tripleo] undercloud / standalone have switched to podman by default Message-ID: For your information, default deployment of Undercloud and Standalone are now using Podman instead of Docker by default. The switch doesn't affect the Overcloud yet but we also aim to change the default before the end of Stein release. If you still want to use docker: * For Undercloud: undercloud.conf : container_cli = docker * For Standalone: in your environment: ContainerCli: docker Please let us know any problem regarding that change. -- Emilien Macchi -------------- next part -------------- An HTML attachment was scrubbed... URL: From marios at redhat.com Mon Dec 17 11:40:22 2018 From: marios at redhat.com (Marios Andreou) Date: Mon, 17 Dec 2018 13:40:22 +0200 Subject: [tripleo] undercloud / standalone have switched to podman by default In-Reply-To: References: Message-ID: On Mon, Dec 17, 2018 at 1:37 PM Emilien Macchi wrote: > For your information, default deployment of Undercloud and Standalone are > now using Podman instead of Docker by default. > The switch doesn't affect the Overcloud yet but we also aim to change the > default before the end of Stein release. > > If you still want to use docker: > * For Undercloud: undercloud.conf : container_cli = docker > * For Standalone: in your environment: ContainerCli: docker > > Please let us know any problem regarding that change. > o/ Emilien FYI there is this https://bugs.launchpad.net/tripleo/+bug/1808767 on rocky... looks like it is related to the podman patch at https://review.openstack.org/#/c/608452/21 (credit ykarel) I don't think we need a full revert trying right now with a conditional for the buildah at https://review.openstack.org/#/c/625531/ (testing in https://review.openstack.org/625535) waiting for zuul run now but i think it passed the point it was failing at thanks > -- > Emilien Macchi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufar at onf-ambassador.org Mon Dec 17 11:53:12 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Mon, 17 Dec 2018 18:53:12 +0700 Subject: Instance Unable to connect to Data/Management Network Message-ID: Hi, I have OpenStack cluster with this following network environment. Global Configuration : Data & Management Network : 10.60.60.0/24 External Network: 10.61.61.0/24 - All my endpoint is created in the Data & Management Network - Instance get floating IP from External Network IP Address Allocation : Controller: 10.60.60.10 | 10.61.61.10 Compute0: 10.60.60.20 | 10.61.61.20 Compute1: 10.60.60.30 | 10.61.61.30 Floating IP range : 10.61.61.100 - 10.61.61.200 My problem is the Instance cannot connect (ping, ssh, all connection) into the data/management network. I am running a magnum cluster but the instance needs to communicate with the endpoint. How to allow an Instance to connect to the data/management network? Best Regards, Zufar Dhiyaulhaq -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdent+os at anticdent.org Mon Dec 17 13:38:13 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Mon, 17 Dec 2018 13:38:13 +0000 (GMT) Subject: [dev] lower-constraints job moving to py36 Message-ID: There is a review in progress to change the lower-constraints CI job to explicitly use python 3.6 [1]. This is part of an ongoing migration to 3.6 throughout all the jobs. This has some small potential to break some projects, so in the review it was decided that making an announcement here would be best so that projects that run the lower-constraints job could have a chance to try it out before we make the switch: When we do, it will switch everyone, all at once. If you would like to try it out, please submit a null-change that depends-on the review [1]. [1] https://review.openstack.org/#/c/623229/ -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From bobh at haddleton.net Mon Dec 17 14:21:57 2018 From: bobh at haddleton.net (Bob Haddleton) Date: Mon, 17 Dec 2018 08:21:57 -0600 Subject: [tosca-parser] Failing to get functions from capabilities In-Reply-To: References: Message-ID: <25707aa1-bdd5-bef8-a038-e6369670cd5c@haddleton.net> Hi Michael: tosca-parser expects that the input values will be defined already and passed to the ToscaTemplate object in the parsed_params argument. If you change: tosca = ToscaTemplate(sys.argv[1]) to: tosca = ToscaTemplate(sys.argv[1], parsed_params={'cpus': 4}) the output becomes: Processing node template server   disk_size: 10 GB   num_cpus: 4   mem_size: 4096 MB   architecture: x86_64   type: Linux   distribution: Fedora   version: 18.0   min_instances: 1   max_instances: 1   secure: True Hope this helps. Bob On 12/17/18 3:25 AM, Michael Still wrote: > Hi, > > I'm trying to use tosca-parser to parse CSAR files. Its working quite > well, until I hit a wall with capabilities today. Specifically I am > testing with the single instance wordpress example CSAR, which uses a > get_input for the num_cpus argument for host capabilities for the server. > > Based on how properties work, I would expect to get a function back > for anything which requires referencing another value, but in the case > of capabilities I either get the hardcoded value (strings, ints etc), > or a None for values which would be functions if we were talking about > prototypes. > > Here's a snippet of example code: > > #!/usr/bin/python > > import sys > > from jinja2 import Template > import toscaparser.functions > from toscaparser.tosca_template import ToscaTemplate > > tosca = ToscaTemplate(sys.argv[1]) > > for nodetemplate in tosca.nodetemplates: >     print >     print('Processing node template %s'% nodetemplate.name > ) > >     capabilities = nodetemplate.get_capabilities_objects() >     for cap in capabilities: >         propobjs = cap.get_properties_objects() >         if not propobjs: >             continue > >         for po in propobjs: >             print('  %s: %s' %(po.name , po.value)) > > Which returns this: > > $ python _capabilities.py csar_wordpress.zip > No handlers could be found for logger "tosca.model" > > Processing node template wordpress >   network_name: PRIVATE >   initiator: source >   protocol: tcp >   secure: False > > Processing node template webserver >   network_name: PRIVATE >   initiator: source >   protocol: tcp >   secure: False >   secure: True > > Processing node template mysql_dbms > > Processing node template mysql_database > > Processing node template server >   secure: True >   min_instances: 1 >   max_instances: 1 >   mem_size: 4096 MB >   num_cpus: None >   disk_size: 10 GB >   distribution: Fedora >   version: 18.0 >   type: Linux >   architecture: x86_64 > > I would expect num_cpus for the "server" node_template to be a > GetInput() function based on its definition in the CSAR, but instead I > get None. > > Is there an example somewhere of how to correctly access functions for > capabilities? > > Thanks, > Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Mon Dec 17 14:42:44 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 17 Dec 2018 14:42:44 +0000 Subject: [dev] [horizon] [tc] [release] [PTI] is tox a requirement even if tox is not used? In-Reply-To: References: Message-ID: <20181217144244.tzbu24nqbjdtv73p@yuggoth.org> On 2018-12-17 18:29:35 +0900 (+0900), Akihiro Motoki wrote: [...] > Can we drop tox.ini completely considering the situation below? Seems reasonable to me. Can you help us clarify this in the Python PTI with a patch to openstack/governance? > These repositories do not depend on 'tox' on testing from their > nature of re-packaging JS module in a python way. In addition, > there is no document provided. The current PTI mentions only "tox > -e docs". I take it there's no point to publishing repository-specific documentation for these? > # Previously PTI required "venv" tox ini but it is no longer mentioned. Yes, we used to require a tox "venv" testenv as a generic environment setup and invocation entrypoint for generating sdist tarballs and wheels to publish on PyPI, but have since switched to invoking the relevant tools directly under the system Python interpreter 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 smooney at redhat.com Mon Dec 17 14:57:54 2018 From: smooney at redhat.com (Sean Mooney) Date: Mon, 17 Dec 2018 14:57:54 +0000 Subject: [dev] [horizon] [tc] [release] [PTI] is tox a requirement even if tox is not used? In-Reply-To: <20181217144244.tzbu24nqbjdtv73p@yuggoth.org> References: <20181217144244.tzbu24nqbjdtv73p@yuggoth.org> Message-ID: <3b9210e9dd833988df171f09122cf113692d5257.camel@redhat.com> On Mon, 2018-12-17 at 14:42 +0000, Jeremy Stanley wrote: > On 2018-12-17 18:29:35 +0900 (+0900), Akihiro Motoki wrote: > [...] > > Can we drop tox.ini completely considering the situation below? > > Seems reasonable to me. Can you help us clarify this in the Python > PTI with a patch to openstack/governance? > > > These repositories do not depend on 'tox' on testing from their > > nature of re-packaging JS module in a python way. In addition, > > there is no document provided. The current PTI mentions only "tox > > -e docs". > > I take it there's no point to publishing repository-specific > documentation for these? well i think it would make sense to still use tox because of documentation. ideally we should use common docs tools even if the project is not written in python to maintian a common look and feel across all the offial proejcst. also presumably horizon will continue to use reno for release notes and therefor we shoudl keep tox for that usecase also. > > > # Previously PTI required "venv" tox ini but it is no longer mentioned. > > Yes, we used to require a tox "venv" testenv as a generic > environment setup and invocation entrypoint for generating sdist > tarballs and wheels to publish on PyPI, but have since switched to > invoking the relevant tools directly under the system Python > interpreter instead. From msm at redhat.com Mon Dec 17 15:53:22 2018 From: msm at redhat.com (Michael McCune) Date: Mon, 17 Dec 2018 10:53:22 -0500 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: References: <380a044d-8185-a312-2f7e-40bd663cf49c@openstack.org> Message-ID: On Sun, Dec 16, 2018 at 5:08 PM Melvin Hillsman wrote: > I would hate for this fade away as I think we have support to keep this moving forward even if it is very slowly. What should be the next step? OpenLab can provide the infrastructure needed to run pretty much anything as folks need without disturbing any existing production environments. Honestly if folks interested in seeing this happen can help draft the scope of work and a roadmap to get it done that would be great. I personally do not want to be the primary person to handle this as it is not my strength but I can help make sure the environment(s) needed are available, work on recruiting help once we have some things outlined, keep communication available, facilitate meetings (even in different time zones), etc. Thoughts? > under the assumption that the SDK work could be brought in to the API SIG charter, i think another important step in this process is finding someone who is able and willing to join the API SIG as a core member to represent the SDK side of the story. peace o/ From artem.goncharov at gmail.com Mon Dec 17 16:11:17 2018 From: artem.goncharov at gmail.com (Artem Goncharov) Date: Mon, 17 Dec 2018 17:11:17 +0100 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: References: <380a044d-8185-a312-2f7e-40bd663cf49c@openstack.org> Message-ID: On Mon, 17 Dec 2018, 16:56 Michael McCune, wrote: > On Sun, Dec 16, 2018 at 5:08 PM Melvin Hillsman > wrote: > > I would hate for this fade away as I think we have support to keep this > moving forward even if it is very slowly. What should be the next step? > OpenLab can provide the infrastructure needed to run pretty much anything > as folks need without disturbing any existing production environments. > Honestly if folks interested in seeing this happen can help draft the scope > of work and a roadmap to get it done that would be great. I personally do > not want to be the primary person to handle this as it is not my strength > but I can help make sure the environment(s) needed are available, work on > recruiting help once we have some things outlined, keep communication > available, facilitate meetings (even in different time zones), etc. > Thoughts? > > > > under the assumption that the SDK work could be brought in to the API > SIG charter, i think another important step in this process is finding > someone who is able and willing to join the API SIG as a core member > to represent the SDK side of the story. > I am willing to. Artem -------------- next part -------------- An HTML attachment was scrubbed... URL: From bathanhtlu at gmail.com Mon Dec 17 16:16:27 2018 From: bathanhtlu at gmail.com (=?UTF-8?B?VGjDoG5oIE5ndXnhu4VuIELDoQ==?=) Date: Mon, 17 Dec 2018 23:16:27 +0700 Subject: [oslo] How to use library "oslo.messaging" In-Reply-To: References: Message-ID: With your help, my program has run :D. But when my program listen nova's notification topic, it receive 'instance.*' but it doesn't receive Flavor's Notification ('flavor.*'). This is my nova config: http://paste.openstack.org/show/737493/ Am i missing something? *Nguyễn Bá Thành* *Mobile*: 0128 748 0391 *Email*: bathanhtlu at gmail.com Vào Th 3, 11 thg 12, 2018 vào lúc 00:00 Ken Giusti đã viết: > > > On Mon, Dec 10, 2018 at 9:24 AM Thành Nguyễn Bá > wrote: > >> Dear all, >> I have a question about "library oslo.messaging". How can i use this >> librabry to write simple program listen event on Openstack (like Nova, >> Cinder)? I had read on docs, nova support "oslo_messaging_notifications" to >> send message via RabbitMQ, so I’m try to use this library but it seem very >> hard for me. >> >> *Nguyễn Bá Thành* >> >> *Mobile*: 0128 748 0391 >> >> *Email*: bathanhtlu at gmail.com >> > > Nguyen - just following up to the wider group: > > I've got a few simple example clients/servers that do RPC and > Notifications. > Check them out on my git repo: > > https://github.com/kgiusti/oslo-messaging-clients > > If folks find them useful I'll be more than glad to move them to the > oslo.messaging repo (an examples directory, perhaps?) > > -- > Ken Giusti (kgiusti at gmail.com) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrhillsman at gmail.com Mon Dec 17 16:18:22 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Mon, 17 Dec 2018 10:18:22 -0600 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: References: <380a044d-8185-a312-2f7e-40bd663cf49c@openstack.org> Message-ID: Thanks Artem for stepping up; please know I will be available as much as humanly possible to assist you. On Mon, Dec 17, 2018 at 10:11 AM Artem Goncharov wrote: > > > On Mon, 17 Dec 2018, 16:56 Michael McCune, wrote: > >> On Sun, Dec 16, 2018 at 5:08 PM Melvin Hillsman >> wrote: >> > I would hate for this fade away as I think we have support to keep this >> moving forward even if it is very slowly. What should be the next step? >> OpenLab can provide the infrastructure needed to run pretty much anything >> as folks need without disturbing any existing production environments. >> Honestly if folks interested in seeing this happen can help draft the scope >> of work and a roadmap to get it done that would be great. I personally do >> not want to be the primary person to handle this as it is not my strength >> but I can help make sure the environment(s) needed are available, work on >> recruiting help once we have some things outlined, keep communication >> available, facilitate meetings (even in different time zones), etc. >> Thoughts? >> > >> >> under the assumption that the SDK work could be brought in to the API >> SIG charter, i think another important step in this process is finding >> someone who is able and willing to join the API SIG as a core member >> to represent the SDK side of the story. >> > > I am willing to. > > Artem > -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From codeology.lab at gmail.com Mon Dec 17 16:46:19 2018 From: codeology.lab at gmail.com (Cody) Date: Mon, 17 Dec 2018 11:46:19 -0500 Subject: [publiccloud]Choice of deployment tools Message-ID: Hello stackers, What deployment tools would be of your choice for deploying a public IaaS with an initial size of 200~300 nodes? Would TripleO be suitable for this cluster size? Thank you very much. Wish you all a happy holiday season! Best regards, Cody From sean.mcginnis at gmx.com Mon Dec 17 16:57:01 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Mon, 17 Dec 2018 10:57:01 -0600 Subject: [dev] [horizon] [tc] [release] [PTI] is tox a requirement even if tox is not used? In-Reply-To: <20181217144244.tzbu24nqbjdtv73p@yuggoth.org> References: <20181217144244.tzbu24nqbjdtv73p@yuggoth.org> Message-ID: <20181217165701.GA30870@sm-workstation> > > > # Previously PTI required "venv" tox ini but it is no longer mentioned. > > Yes, we used to require a tox "venv" testenv as a generic > environment setup and invocation entrypoint for generating sdist > tarballs and wheels to publish on PyPI, but have since switched to > invoking the relevant tools directly under the system Python > interpreter instead. > -- > Jeremy Stanley Ah, this was the thing that jumped to mind when reading the earlier messages, but I wasn't sure if that had all changed. I know we had some release job issues at one point because of "tox -e venv" missing, but if the tooling has been updated now to not need that then I think we are probably safe dropping tox if there really is no other need for it. From doug at doughellmann.com Mon Dec 17 16:58:36 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 17 Dec 2018 11:58:36 -0500 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> Message-ID: Thierry Carrez writes: > Hi, > > A while ago, the Technical Committee designated specific hours in the > week where members would make extra effort to be around on #openstack-tc > on IRC, so that community members looking for answers to their questions > or wanting to engage can find a time convenient for them and a critical > mass of TC members around. We currently have 3 weekly spots: > > - 09:00 UTC on Tuesdays > - 01:00 UTC on Wednesdays > - 15:00 UTC on Thursdays > > But after a few months it appears that: > > 1/ nobody really comes on channel at office hour time to ask questions. > We had a questions on the #openstack-tc IRC channel, but I wouldn't say > people take benefit of the synced time > > 2/ some office hours (most notably the 01:00 UTC on Wednesdays, but also > to a lesser extent the 09:00 UTC on Tuesdays) end up just being a couple > of TC members present > > So the schedule is definitely not reaching its objectives, and as such > may be a bit overkill. I was also wondering if this is not a case where > the offer is hurting the demand -- by having so many office hour spots > around, nobody considers them special. > > Should we: > > - Reduce office hours to one or two per week, possibly rotating times > > - Dump the whole idea and just encourage people to ask questions at any > time on #openstack-tc, and get asynchronous answers > > - Keep it as-is, it still has the side benefit of triggering spikes of > TC member activity > > Thoughts ? > > -- > Thierry Carrez (ttx) > I would like for us to make a decision about this. The 0100 Wednesday meeting was generally seen as a good candidate to drop, if we do drop one. No one seemed to support the idea of rotating meeting times, so I'm going to eliminate that from consideration. We can discuss the idea of changing the schedule of the meetings separately from how many we want to have, so I will also postpone that question for later. TC members, please respond to this thread indicating your support for one of these options: 1. Keep the 3 fixed office hours. 2. Drop the 0100 Wednesday meeting, keeping the other 2. 3. Drop all office hours. -- Doug From doug at doughellmann.com Mon Dec 17 17:00:20 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 17 Dec 2018 12:00:20 -0500 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> Message-ID: Doug Hellmann writes: > Thierry Carrez writes: > >> Hi, >> >> A while ago, the Technical Committee designated specific hours in the >> week where members would make extra effort to be around on #openstack-tc >> on IRC, so that community members looking for answers to their questions >> or wanting to engage can find a time convenient for them and a critical >> mass of TC members around. We currently have 3 weekly spots: >> >> - 09:00 UTC on Tuesdays >> - 01:00 UTC on Wednesdays >> - 15:00 UTC on Thursdays >> >> But after a few months it appears that: >> >> 1/ nobody really comes on channel at office hour time to ask questions. >> We had a questions on the #openstack-tc IRC channel, but I wouldn't say >> people take benefit of the synced time >> >> 2/ some office hours (most notably the 01:00 UTC on Wednesdays, but also >> to a lesser extent the 09:00 UTC on Tuesdays) end up just being a couple >> of TC members present >> >> So the schedule is definitely not reaching its objectives, and as such >> may be a bit overkill. I was also wondering if this is not a case where >> the offer is hurting the demand -- by having so many office hour spots >> around, nobody considers them special. >> >> Should we: >> >> - Reduce office hours to one or two per week, possibly rotating times >> >> - Dump the whole idea and just encourage people to ask questions at any >> time on #openstack-tc, and get asynchronous answers >> >> - Keep it as-is, it still has the side benefit of triggering spikes of >> TC member activity >> >> Thoughts ? >> >> -- >> Thierry Carrez (ttx) >> > > I would like for us to make a decision about this. > > The 0100 Wednesday meeting was generally seen as a good candidate to > drop, if we do drop one. No one seemed to support the idea of rotating > meeting times, so I'm going to eliminate that from consideration. We can > discuss the idea of changing the schedule of the meetings separately > from how many we want to have, so I will also postpone that question for > later. > > TC members, please respond to this thread indicating your support for > one of these options: > > 1. Keep the 3 fixed office hours. > 2. Drop the 0100 Wednesday meeting, keeping the other 2. > 3. Drop all office hours. > > -- > Doug I prefer option 2, but could also accept option 1. I think option 3 is a bad idea, because even if we are not seeing many community requests during office hours, it does give us an opportunity to sync up and discuss current events. -- Doug From mrhillsman at gmail.com Mon Dec 17 17:02:12 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Mon, 17 Dec 2018 11:02:12 -0600 Subject: [publiccloud]Choice of deployment tools In-Reply-To: References: Message-ID: Personally I have found openstack-ansible to be robust and very useful for a production environment. Not only the tool itself but also the help offered by those whose develop and use it. There is a bit of a learning curve however. At the end of the day I think the best solution is the one that works for you and if you have a chance you should try each one to see which is most suitable. I have not tried TripleO, Airship in a bottle did not work out the box, Kolla-Ansible is useful also but gave me fits troubleshooting, and OpenStack-Ansible I mentioned the learning curve. I do not deal with a lot of manual deploying these days but if I was spinning up a public cloud personally I would roll with OpenStack-Ansible On Mon, Dec 17, 2018, 10:47 AM Cody Hello stackers, > > What deployment tools would be of your choice for deploying a public > IaaS with an initial size of 200~300 nodes? Would TripleO be suitable > for this cluster size? > > Thank you very much. Wish you all a happy holiday season! > > Best regards, > Cody > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Mon Dec 17 17:51:23 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 17 Dec 2018 17:51:23 +0000 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> Message-ID: <20181217175122.m5jnjaq2w4zbcy6y@yuggoth.org> On 2018-12-17 11:58:36 -0500 (-0500), Doug Hellmann wrote: [...] > TC members, please respond to this thread indicating your support for > one of these options: > > 1. Keep the 3 fixed office hours. > 2. Drop the 0100 Wednesday meeting, keeping the other 2. > 3. Drop all office hours. As someone who usually manages to be around for the 0100 Wednesday slot, I'm fine keeping it. In my opinion, we have it so that if people in APAC timezones want to have an informal synchronous conversation with a few TC members in the Americas timezones (where a slight majority of us do still reside at the moment) we can point them to that option. If there is a time which would be more attractive to folks in the major population centers there, I'm fine with that too. I do think TC member office hours are good for us to offer our community, even if they aren't often taken advantage of, so am not as keen on your third option but would accept it if there's broad support to drop them altogether. -- 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 lbragstad at gmail.com Mon Dec 17 17:57:06 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Mon, 17 Dec 2018 11:57:06 -0600 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> Message-ID: On Mon, Dec 17, 2018 at 11:02 AM Doug Hellmann wrote: > Doug Hellmann writes: > > > Thierry Carrez writes: > > > >> Hi, > >> > >> A while ago, the Technical Committee designated specific hours in the > >> week where members would make extra effort to be around on > #openstack-tc > >> on IRC, so that community members looking for answers to their > questions > >> or wanting to engage can find a time convenient for them and a critical > >> mass of TC members around. We currently have 3 weekly spots: > >> > >> - 09:00 UTC on Tuesdays > >> - 01:00 UTC on Wednesdays > >> - 15:00 UTC on Thursdays > >> > >> But after a few months it appears that: > >> > >> 1/ nobody really comes on channel at office hour time to ask questions. > >> We had a questions on the #openstack-tc IRC channel, but I wouldn't say > >> people take benefit of the synced time > >> > >> 2/ some office hours (most notably the 01:00 UTC on Wednesdays, but > also > >> to a lesser extent the 09:00 UTC on Tuesdays) end up just being a > couple > >> of TC members present > >> > >> So the schedule is definitely not reaching its objectives, and as such > >> may be a bit overkill. I was also wondering if this is not a case where > >> the offer is hurting the demand -- by having so many office hour spots > >> around, nobody considers them special. > >> > >> Should we: > >> > >> - Reduce office hours to one or two per week, possibly rotating times > >> > >> - Dump the whole idea and just encourage people to ask questions at any > >> time on #openstack-tc, and get asynchronous answers > >> > >> - Keep it as-is, it still has the side benefit of triggering spikes of > >> TC member activity > >> > >> Thoughts ? > >> > >> -- > >> Thierry Carrez (ttx) > >> > > > > I would like for us to make a decision about this. > > > > The 0100 Wednesday meeting was generally seen as a good candidate to > > drop, if we do drop one. No one seemed to support the idea of rotating > > meeting times, so I'm going to eliminate that from consideration. We can > > discuss the idea of changing the schedule of the meetings separately > > from how many we want to have, so I will also postpone that question for > > later. > > > > TC members, please respond to this thread indicating your support for > > one of these options: > > > > 1. Keep the 3 fixed office hours. > > 2. Drop the 0100 Wednesday meeting, keeping the other 2. > > 3. Drop all office hours. > > > > -- > > Doug > > I prefer option 2, but could also accept option 1. I think option 3 is a > bad idea, because even if we are not seeing many community requests > during office hours, it does give us an opportunity to sync up and > discuss current events. > I have a similar opinion. I support the first two options and I agree that option #3 is a bad idea. I'm not sure I have a preference of either of the first two options. I like the idea of option #1, since it's APAC friendly (and APAC communication is a frequent topic at TC gatherings), but I won't object if the overall consensus is to drop that particular time. > > -- > Doug > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Arkady.Kanevsky at dell.com Mon Dec 17 18:12:17 2018 From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com) Date: Mon, 17 Dec 2018 18:12:17 +0000 Subject: [publiccloud]Choice of deployment tools In-Reply-To: References: Message-ID: <2cd80ff44dad46ed8f2f93b1c9578fda@AUSX13MPS308.AMER.DELL.COM> We had done TripleO deployment with 3 racks several times and it worked fined. From: Melvin Hillsman [mailto:mrhillsman at gmail.com] Sent: Monday, December 17, 2018 11:02 AM To: Cody Cc: openstack-operators at lists.openstack.org Subject: Re: [publiccloud]Choice of deployment tools [EXTERNAL EMAIL] Personally I have found openstack-ansible to be robust and very useful for a production environment. Not only the tool itself but also the help offered by those whose develop and use it. There is a bit of a learning curve however. At the end of the day I think the best solution is the one that works for you and if you have a chance you should try each one to see which is most suitable. I have not tried TripleO, Airship in a bottle did not work out the box, Kolla-Ansible is useful also but gave me fits troubleshooting, and OpenStack-Ansible I mentioned the learning curve. I do not deal with a lot of manual deploying these days but if I was spinning up a public cloud personally I would roll with OpenStack-Ansible On Mon, Dec 17, 2018, 10:47 AM Cody wrote: Hello stackers, What deployment tools would be of your choice for deploying a public IaaS with an initial size of 200~300 nodes? Would TripleO be suitable for this cluster size? Thank you very much. Wish you all a happy holiday season! Best regards, Cody -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Mon Dec 17 18:16:39 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 17 Dec 2018 13:16:39 -0500 Subject: [tc] Technical Committee Status for 17 Dec 2081 Message-ID: This is the (mostly) weekly summary of work being done by the Technical Committee members. The full list of active items is managed in the wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker We also track TC objectives for the cycle using StoryBoard at: https://storyboard.openstack.org/#!/project/923 == Recent Activity == Project updates: * Add os-resource-classes under Nova: https://review.openstack.org/#/c/621699/ Other updates: * I added a TC "house rule" for voting on updates to the release management metadata for projects, to make it easier to keep those up to date: https://review.openstack.org/#/c/622989/ * Thierry has been working on a series of changes on behalf of the release management team to record the release management style used for each deliverable listed in the governance repository. ** https://review.openstack.org/#/c/622902/ ** https://review.openstack.org/#/c/622903/ ** https://review.openstack.org/#/c/622904/ ** https://review.openstack.org/#/c/624704/ ** https://review.openstack.org/#/c/624951/ ** https://review.openstack.org/#/c/624996/ * I updated the documentation of chair responsibilities to include the OSF annual report: https://review.openstack.org/#/c/624790/ * Lance proposed an update to document the process for changing PTLs in the middle of a cycle: https://review.openstack.org/#/c/620928/ * Ghanshyam proposed an update to clarify the term of TC chair, since some responsibilities include managing the election fo the next chair: https://review.openstack.org/#/c/621498/ * Zane's resolution describing how we will keep up with future Python 3 releases has been approved: https://review.openstack.org/#/c/613145/ * Thierry and Chris' work to document the role of the TC has been approved: https://review.openstack.org/#/c/622400/ * I documented the official topic tags used to designate the voting rules to apply to each governance patch: https://review.openstack.org/#/c/625004/ == TC Meetings == The next TC meeting will be 3 December @ 1400 UTC in #openstack-tc. See http://eavesdrop.openstack.org/#Technical_Committee_Meeting for details == Ongoing Discussions == Ghanshyam has proposed an enhancement to the Vision for OpenStack Clouds to cover feature discovery. * https://review.openstack.org/#/c/621516/ I have proposed an update to the TC house voting rules to cover documentation changes in the governance repository. * https://review.openstack.org/625005 Dougal Matthews is stepping down as Mistral PTL, to be replaced by Renat Akhmerov. * https://review.openstack.org/#/c/625537/ == TC member actions/focus/discussions for the coming week(s) == We need to work to approve Sean's patch with the Stein supported/testing runtimes list. * https://review.openstack.org/611080 Thierry started a thread on the mailing list about adapting our office hours times. It would be good for us to resolve that so we can make the change after the new year, so I have renewed the thread with a summary of the options. Please vote. * http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001036.html == Contacting the TC == The Technical Committee uses a series of weekly "office hour" time slots for synchronous communication. We hope that by having several such times scheduled, we will have more opportunities to engage with members of the community from different timezones. Office hour times in #openstack-tc: - 09:00 UTC on Tuesdays - 01:00 UTC on Wednesdays - 15:00 UTC on Thursdays If you have something you would like the TC to discuss, you can add it to our office hour conversation starter etherpad at: https://etherpad.openstack.org/p/tc-office-hour-conversation-starters Many of us also run IRC bouncers which stay in #openstack-tc most of the time, so please do not feel that you need to wait for an office hour time to pose a question or offer a suggestion. You can use the string "tc-members" to alert the members to your question. You will find channel logs with past conversations at http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ If you expect your topic to require significant discussion or to need input from members of the community other than the TC, please start a mailing list discussion on openstack-discuss at lists.openstack.org and use the subject tag "[tc]" to bring it to the attention of TC members. -- Doug From codeology.lab at gmail.com Mon Dec 17 18:41:00 2018 From: codeology.lab at gmail.com (Cody) Date: Mon, 17 Dec 2018 13:41:00 -0500 Subject: [publiccloud]Choice of deployment tools In-Reply-To: <2cd80ff44dad46ed8f2f93b1c9578fda@AUSX13MPS308.AMER.DELL.COM> References: <2cd80ff44dad46ed8f2f93b1c9578fda@AUSX13MPS308.AMER.DELL.COM> Message-ID: Hi Melvin and Arkady, Thank you for the replies. I have been using TripleO on a small scale (10~20 nodes per deployment) and it worked well. That said, I am not sure what capacity it is designed for and whether it is still suitable to go beyond 2~300 nodes. @Melvin: I attempted to try Kolla-Ansible and OpenStack-Ansible, but failed to find documentations that provide coverages as detail as TripleO's. Do you happen to know any resources or books on the subjects for me to work on? @Arkady: May I ask if you used a Spine/Leaf network topology (i.e. using a fully meshed layer 3 network above ToR) to deploy the 3 racks? Thank you to all! Best regards, Cody On Mon, Dec 17, 2018 at 1:12 PM wrote: > > We had done TripleO deployment with 3 racks several times and it worked fined. > > > > From: Melvin Hillsman [mailto:mrhillsman at gmail.com] > Sent: Monday, December 17, 2018 11:02 AM > To: Cody > Cc: openstack-operators at lists.openstack.org > Subject: Re: [publiccloud]Choice of deployment tools > > > > [EXTERNAL EMAIL] > > Personally I have found openstack-ansible to be robust and very useful for a production environment. Not only the tool itself but also the help offered by those whose develop and use it. There is a bit of a learning curve however. At the end of the day I think the best solution is the one that works for you and if you have a chance you should try each one to see which is most suitable. I have not tried TripleO, Airship in a bottle did not work out the box, Kolla-Ansible is useful also but gave me fits troubleshooting, and OpenStack-Ansible I mentioned the learning curve. I do not deal with a lot of manual deploying these days but if I was spinning up a public cloud personally I would roll with OpenStack-Ansible > > > > On Mon, Dec 17, 2018, 10:47 AM Cody > Hello stackers, > > What deployment tools would be of your choice for deploying a public > IaaS with an initial size of 200~300 nodes? Would TripleO be suitable > for this cluster size? > > Thank you very much. Wish you all a happy holiday season! > > Best regards, > Cody From msm at redhat.com Mon Dec 17 18:49:27 2018 From: msm at redhat.com (Michael McCune) Date: Mon, 17 Dec 2018 13:49:27 -0500 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: References: <380a044d-8185-a312-2f7e-40bd663cf49c@openstack.org> Message-ID: On Mon, Dec 17, 2018 at 11:11 AM Artem Goncharov wrote: > I am willing to. awesome, this is great to hear Artem. would you be willing to stop by our office hours in #openstack-sdks this thursday at 1600UTC to meet the rest of the SIG? assuming there are no objections we can add you to the SIG wiki and related governance stuff. peace o/ From openstack at nemebean.com Mon Dec 17 18:51:42 2018 From: openstack at nemebean.com (Ben Nemec) Date: Mon, 17 Dec 2018 12:51:42 -0600 Subject: [tc] Technical Committee Status for 17 Dec 2081 In-Reply-To: References: Message-ID: <026afe3e-7f26-6dff-cbe0-be67cae66cb9@nemebean.com> Paging Sarah Connor. Doug may be a Terminator sent back from the future. ;-) -Your friendly neighborhood date obsessive On 12/17/18 12:16 PM, Doug Hellmann wrote: > This is the (mostly) weekly summary of work being done by the Technical > Committee members. The full list of active items is managed in the > wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker > > We also track TC objectives for the cycle using StoryBoard at: > https://storyboard.openstack.org/#!/project/923 > > == Recent Activity == > > Project updates: > > * Add os-resource-classes under Nova: > https://review.openstack.org/#/c/621699/ > > Other updates: > > * I added a TC "house rule" for voting on updates to the release > management metadata for projects, to make it easier to keep those up > to date: https://review.openstack.org/#/c/622989/ > * Thierry has been working on a series of changes on behalf of the > release management team to record the release management style used > for each deliverable listed in the governance repository. > ** https://review.openstack.org/#/c/622902/ > ** https://review.openstack.org/#/c/622903/ > ** https://review.openstack.org/#/c/622904/ > ** https://review.openstack.org/#/c/624704/ > ** https://review.openstack.org/#/c/624951/ > ** https://review.openstack.org/#/c/624996/ > * I updated the documentation of chair responsibilities to include the > OSF annual report: https://review.openstack.org/#/c/624790/ > * Lance proposed an update to document the process for changing PTLs in > the middle of a cycle: https://review.openstack.org/#/c/620928/ > * Ghanshyam proposed an update to clarify the term of TC chair, since > some responsibilities include managing the election fo the next chair: > https://review.openstack.org/#/c/621498/ > * Zane's resolution describing how we will keep up with future Python 3 > releases has been approved: https://review.openstack.org/#/c/613145/ > * Thierry and Chris' work to document the role of the TC has been > approved: https://review.openstack.org/#/c/622400/ > * I documented the official topic tags used to designate the voting > rules to apply to each governance patch: > https://review.openstack.org/#/c/625004/ > > == TC Meetings == > > The next TC meeting will be 3 December @ 1400 UTC in #openstack-tc. See > http://eavesdrop.openstack.org/#Technical_Committee_Meeting for details > > == Ongoing Discussions == > > Ghanshyam has proposed an enhancement to the Vision for OpenStack Clouds > to cover feature discovery. > > * https://review.openstack.org/#/c/621516/ > > I have proposed an update to the TC house voting rules to cover > documentation changes in the governance repository. > > * https://review.openstack.org/625005 > > Dougal Matthews is stepping down as Mistral PTL, to be replaced by Renat > Akhmerov. > > * https://review.openstack.org/#/c/625537/ > > == TC member actions/focus/discussions for the coming week(s) == > > We need to work to approve Sean's patch with the Stein supported/testing > runtimes list. > > * https://review.openstack.org/611080 > > Thierry started a thread on the mailing list about adapting our office > hours times. It would be good for us to resolve that so we can make the > change after the new year, so I have renewed the thread with a summary > of the options. Please vote. > > * http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001036.html > > == Contacting the TC == > > The Technical Committee uses a series of weekly "office hour" time > slots for synchronous communication. We hope that by having several > such times scheduled, we will have more opportunities to engage > with members of the community from different timezones. > > Office hour times in #openstack-tc: > > - 09:00 UTC on Tuesdays > - 01:00 UTC on Wednesdays > - 15:00 UTC on Thursdays > > If you have something you would like the TC to discuss, you can add > it to our office hour conversation starter etherpad at: > https://etherpad.openstack.org/p/tc-office-hour-conversation-starters > > Many of us also run IRC bouncers which stay in #openstack-tc most > of the time, so please do not feel that you need to wait for an > office hour time to pose a question or offer a suggestion. You can > use the string "tc-members" to alert the members to your question. > > You will find channel logs with past conversations at > http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ > > If you expect your topic to require significant discussion or to > need input from members of the community other than the TC, please > start a mailing list discussion on openstack-discuss at > lists.openstack.org > and use the subject tag "[tc]" to bring it to the attention of TC > members. > From doug at doughellmann.com Mon Dec 17 18:54:40 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 17 Dec 2018 13:54:40 -0500 Subject: [tc] Technical Committee Status for 17 Dec 2081 In-Reply-To: <026afe3e-7f26-6dff-cbe0-be67cae66cb9@nemebean.com> References: <026afe3e-7f26-6dff-cbe0-be67cae66cb9@nemebean.com> Message-ID: > On Dec 17, 2018, at 1:51 PM, Ben Nemec wrote: > > Paging Sarah Connor. Doug may be a Terminator sent back from the future. ;-) > > -Your friendly neighborhood date obsessive That’s what I get for trying to send email while I’m in a meeting, I guess. Ahl-be-bahck-ly, Doug > > On 12/17/18 12:16 PM, Doug Hellmann wrote: >> This is the (mostly) weekly summary of work being done by the Technical >> Committee members. The full list of active items is managed in the >> wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker >> We also track TC objectives for the cycle using StoryBoard at: >> https://storyboard.openstack.org/#!/project/923 >> == Recent Activity == >> Project updates: >> * Add os-resource-classes under Nova: >> https://review.openstack.org/#/c/621699/ >> Other updates: >> * I added a TC "house rule" for voting on updates to the release >> management metadata for projects, to make it easier to keep those up >> to date: https://review.openstack.org/#/c/622989/ >> * Thierry has been working on a series of changes on behalf of the >> release management team to record the release management style used >> for each deliverable listed in the governance repository. >> ** https://review.openstack.org/#/c/622902/ >> ** https://review.openstack.org/#/c/622903/ >> ** https://review.openstack.org/#/c/622904/ >> ** https://review.openstack.org/#/c/624704/ >> ** https://review.openstack.org/#/c/624951/ >> ** https://review.openstack.org/#/c/624996/ >> * I updated the documentation of chair responsibilities to include the >> OSF annual report: https://review.openstack.org/#/c/624790/ >> * Lance proposed an update to document the process for changing PTLs in >> the middle of a cycle: https://review.openstack.org/#/c/620928/ >> * Ghanshyam proposed an update to clarify the term of TC chair, since >> some responsibilities include managing the election fo the next chair: >> https://review.openstack.org/#/c/621498/ >> * Zane's resolution describing how we will keep up with future Python 3 >> releases has been approved: https://review.openstack.org/#/c/613145/ >> * Thierry and Chris' work to document the role of the TC has been >> approved: https://review.openstack.org/#/c/622400/ >> * I documented the official topic tags used to designate the voting >> rules to apply to each governance patch: >> https://review.openstack.org/#/c/625004/ >> == TC Meetings == >> The next TC meeting will be 3 December @ 1400 UTC in #openstack-tc. See >> http://eavesdrop.openstack.org/#Technical_Committee_Meeting for details >> == Ongoing Discussions == >> Ghanshyam has proposed an enhancement to the Vision for OpenStack Clouds >> to cover feature discovery. >> * https://review.openstack.org/#/c/621516/ >> I have proposed an update to the TC house voting rules to cover >> documentation changes in the governance repository. >> * https://review.openstack.org/625005 >> Dougal Matthews is stepping down as Mistral PTL, to be replaced by Renat >> Akhmerov. >> * https://review.openstack.org/#/c/625537/ >> == TC member actions/focus/discussions for the coming week(s) == >> We need to work to approve Sean's patch with the Stein supported/testing >> runtimes list. >> * https://review.openstack.org/611080 >> Thierry started a thread on the mailing list about adapting our office >> hours times. It would be good for us to resolve that so we can make the >> change after the new year, so I have renewed the thread with a summary >> of the options. Please vote. >> * http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001036.html >> == Contacting the TC == >> The Technical Committee uses a series of weekly "office hour" time >> slots for synchronous communication. We hope that by having several >> such times scheduled, we will have more opportunities to engage >> with members of the community from different timezones. >> Office hour times in #openstack-tc: >> - 09:00 UTC on Tuesdays >> - 01:00 UTC on Wednesdays >> - 15:00 UTC on Thursdays >> If you have something you would like the TC to discuss, you can add >> it to our office hour conversation starter etherpad at: >> https://etherpad.openstack.org/p/tc-office-hour-conversation-starters >> Many of us also run IRC bouncers which stay in #openstack-tc most >> of the time, so please do not feel that you need to wait for an >> office hour time to pose a question or offer a suggestion. You can >> use the string "tc-members" to alert the members to your question. >> You will find channel logs with past conversations at >> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ >> If you expect your topic to require significant discussion or to >> need input from members of the community other than the TC, please >> start a mailing list discussion on openstack-discuss at >> lists.openstack.org >> and use the subject tag "[tc]" to bring it to the attention of TC >> members. From openstack at nemebean.com Mon Dec 17 19:02:30 2018 From: openstack at nemebean.com (Ben Nemec) Date: Mon, 17 Dec 2018 13:02:30 -0600 Subject: [Oslo] End of year schedule and plans Message-ID: Hi Norwegians, As we discussed in the meeting today, there will be no Oslo meetings for the next two weeks due to the holidays. We'll resume Jan. 7. Releases will happen as normal this week, but after that I wouldn't expect any more until 2019. We generally try to avoid releasing when people aren't going to be around to deal with any fallout. Finally, I believe most of the Oslo cores will be unavailable after this week, so expect review activity to slow significantly until the new year too. I will be around for the rest of the week, so if you have any Oslo-related stuff that needs to happen in 2018 let me know. After that all bets are off for my availability. Thanks and Happy New Year in advance! -Ben From mrhillsman at gmail.com Mon Dec 17 19:09:22 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Mon, 17 Dec 2018 13:09:22 -0600 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: References: <380a044d-8185-a312-2f7e-40bd663cf49c@openstack.org> Message-ID: +michael mccune I will be sure to stop by as well. On Mon, Dec 17, 2018 at 12:49 PM Michael McCune wrote: > On Mon, Dec 17, 2018 at 11:11 AM Artem Goncharov > wrote: > > I am willing to. > > awesome, this is great to hear Artem. would you be willing to stop by > our office hours in #openstack-sdks this thursday at 1600UTC to meet > the rest of the SIG? > > assuming there are no objections we can add you to the SIG wiki and > related governance stuff. > > peace o/ > -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikal at stillhq.com Mon Dec 17 19:22:55 2018 From: mikal at stillhq.com (Michael Still) Date: Tue, 18 Dec 2018 06:22:55 +1100 Subject: [tosca-parser] Failing to get functions from capabilities In-Reply-To: <25707aa1-bdd5-bef8-a038-e6369670cd5c@haddleton.net> References: <25707aa1-bdd5-bef8-a038-e6369670cd5c@haddleton.net> Message-ID: Thanks for that. That approach seems fair enough, but inconsistent with how other things are represented as functions. How am I meant to know what the inputs to the CSAR are before the CSAR is parsed? Michael On Tue, Dec 18, 2018 at 1:28 AM Bob Haddleton wrote: > Hi Michael: > > tosca-parser expects that the input values will be defined already and > passed to the ToscaTemplate object in the parsed_params argument. > > If you change: > > tosca = ToscaTemplate(sys.argv[1]) > > to: > > tosca = ToscaTemplate(sys.argv[1], parsed_params={'cpus': 4}) > > the output becomes: > > Processing node template server > disk_size: 10 GB > num_cpus: 4 > mem_size: 4096 MB > architecture: x86_64 > type: Linux > distribution: Fedora > version: 18.0 > min_instances: 1 > max_instances: 1 > secure: True > > > Hope this helps. > > Bob > > > On 12/17/18 3:25 AM, Michael Still wrote: > > Hi, > > I'm trying to use tosca-parser to parse CSAR files. Its working quite > well, until I hit a wall with capabilities today. Specifically I am testing > with the single instance wordpress example CSAR, which uses a get_input for > the num_cpus argument for host capabilities for the server. > > Based on how properties work, I would expect to get a function back for > anything which requires referencing another value, but in the case of > capabilities I either get the hardcoded value (strings, ints etc), or a > None for values which would be functions if we were talking about > prototypes. > > Here's a snippet of example code: > > #!/usr/bin/python > > import sys > > from jinja2 import Template > import toscaparser.functions > from toscaparser.tosca_template import ToscaTemplate > > tosca = ToscaTemplate(sys.argv[1]) > > for nodetemplate in tosca.nodetemplates: > print > print('Processing node template %s'% nodetemplate.name) > > capabilities = nodetemplate.get_capabilities_objects() > for cap in capabilities: > propobjs = cap.get_properties_objects() > if not propobjs: > continue > > for po in propobjs: > print(' %s: %s' %(po.name, po.value)) > > Which returns this: > > $ python _capabilities.py csar_wordpress.zip > No handlers could be found for logger "tosca.model" > > Processing node template wordpress > network_name: PRIVATE > initiator: source > protocol: tcp > secure: False > > Processing node template webserver > network_name: PRIVATE > initiator: source > protocol: tcp > secure: False > secure: True > > Processing node template mysql_dbms > > Processing node template mysql_database > > Processing node template server > secure: True > min_instances: 1 > max_instances: 1 > mem_size: 4096 MB > num_cpus: None > disk_size: 10 GB > distribution: Fedora > version: 18.0 > type: Linux > architecture: x86_64 > > I would expect num_cpus for the "server" node_template to be a GetInput() > function based on its definition in the CSAR, but instead I get None. > > Is there an example somewhere of how to correctly access functions for > capabilities? > > Thanks, > Michael > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at topjian.net Mon Dec 17 19:37:53 2018 From: joe at topjian.net (Joe Topjian) Date: Mon, 17 Dec 2018 12:37:53 -0700 Subject: queens heat db deadlock In-Reply-To: References: <38bae882-b4ac-4b55-5345-e27edbd582f3@redhat.com> Message-ID: Hi Ignazio, Do you currently have HAProxy configured to route requests to multiple MariaDB nodes? If so, as a workaround, try doing an active/backup configuration where all but 1 node is configured as an HAProxy "backup". Thanks, Joe On Sun, Dec 16, 2018 at 10:46 PM Ignazio Cassano wrote: > Hello Zane, it happens also when I create a magnum cluster . > My mariadb cluster is behind haproxy. > Do you need any other info? > Thanks > Ignazio > > > Il giorno Lun 17 Dic 2018 00:28 Zane Bitter ha > scritto: > >> On 14/12/18 4:06 AM, Ignazio Cassano wrote: >> > Hi All, >> > I installed queens on centos 7. >> > Heat seems to work fine with templates I wrote but when I create magnum >> > cluster >> > I often face with db deadlock in heat-engine log: >> >> The stacktrace below is in stack delete, so do you mean that the problem >> occurs when deleting a Magnum cluster, or can it occur any time with a >> magnum cluster? >> >> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource Traceback >> (most >> > recent call last): >> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >> > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 918, >> in >> > _action_recorder >> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource yield >> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >> > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 2035, >> > in delete >> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >> *action_args) >> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >> > "/usr/lib/python2.7/site-packages/heat/engine/scheduler.py", line 346, >> > in wrapper >> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource step = >> > next(subtask) >> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >> > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 977, >> in >> > action_handler_task >> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource done = >> > check(handler_data) >> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >> > >> "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", >> > line 587, in check_delete_complete >> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource return >> > self._check_status_complete(self.DELETE) >> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >> > >> "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", >> > line 454, in _check_status_complete >> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >> action=action) >> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >> > ResourceFailure: resources[0]: (pymysql.err.InternalError) (1213, >> > u'Deadlock found when trying to get lock; try restarting transaction') >> > (Background on this error at: http://sqlalche.me/e/2j85) >> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >> > 2018-12-13 11:48:46.030 89597 INFO heat.engine.stack >> > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] >> > Stack DELETE FAILED >> > (swarm-clustergp27-ebhsalhb4bop-swarm_primary_master-tzgkh3ncmymw): >> > Resource DELETE failed: resources[0]: (pymysql.err.InternalError) >> (1213, >> > u'Deadlock found when trying to get lock; try restarting transaction') >> > (Background on this error at: http://sqlalche.me/e/2j85) >> > 2018-12-13 11:48:46.844 89595 INFO heat.engine.resource >> > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] >> > DELETE: ResourceGroup "swarm_primary_master" >> > [6984db3c-3ac1-4afc-901f-21b3e7f230a7] Stack >> > "swarm-clustergp27-ebhsalhb4bop" [b43256fa-52e2-4613-ac15-63fd9340a8be] >> > >> > >> > I read this issue was solved in heat version 10 but seems not. >> >> The patch for bug 1732969, which is in Queens, is probably the fix >> you're referring to: https://review.openstack.org/#/c/521170/1 >> >> The traceback in that bug included the SQL statement that was failing. >> I'm not sure if that isn't included in your traceback because SQLAlchemy >> didn't report it, or if it's because that traceback is actually from the >> parent stack. If you have a traceback from the original failure in the >> child stack that would be useful. If there's a way to turn on more >> detailed reporting of errors in SQLAlchemy that would also be useful. >> >> Since this is a delete, it's possible that we need a retry-on-deadlock >> on the resource_delete() function also (though resource_update() is >> actually used more during a delete to update the status). >> >> - ZB >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfinucan at redhat.com Mon Dec 17 16:46:56 2018 From: sfinucan at redhat.com (Stephen Finucane) Date: Mon, 17 Dec 2018 16:46:56 +0000 Subject: [all] Service-specific configuration options Message-ID: <78c490d4eb78b48f0fd2910bb69104f809c7c9fa.camel@redhat.com> I proposed a WIP change for oslo.config [1] last week that would allow us to specify what services (e.g. nova-compute, nova-scheduler, nova- api, etc.) an option applies to. This came about because of comments on another issue where we found no one could say with surety what services needed an option in their configuration option (which in turn brought up questions about why those services needed the option). It was suggested I bring the idea up on the mailing list before we proceeded any further with it so here I am. I'm interested in two things. Firstly, I'd like to know whether generation of per-service configuration files is actually something others find problematic? I'm imagining this is annoying for operators and those working on deployment tooling but I've never got any hard data to back up that assumption. Secondly, I didn't see anything in the likes of cinder, nova or neutron but has anyone else already worked on something like this? For what it's worth, I did explain why I've gone with the approach I have in the commit message, but that doesn't mean there aren't other options I could be missing. Stephen [1] https://review.openstack.org/#/c/625011/ PS: I've tagged this [all] as enumerating the projects this actually affected left me with at least a dozen tags before I was even done. Sorry for any possible noise. From allison at openstack.org Mon Dec 17 21:31:26 2018 From: allison at openstack.org (Allison Price) Date: Mon, 17 Dec 2018 15:31:26 -0600 Subject: [ptl] [user survey] Cinder Superuser Article Addressing User Survey Feedback Message-ID: <95512068-058A-4151-A854-07E03B75B011@openstack.org> Hi everyone, I wanted to share a really helpful article [1] that Jay Bryant wrote for Superuser after receiving the Cinder feedback from the 2018 OpenStack User Survey. This is really valuable content for the users that are expressing challenges and feedback in the survey. I would like to encourage any PTLs that have the bandwidth to directly address some of the feedback they received from the user survey to draft something similar. With the publication of this article, we will reach out to users who expressed that they are running Cinder to show how their feedback has had a direct impact on the development of OpenStack. If anyone is interested, please email me directly, and we can get the process started. We have also made the 2019 OpenStack User Survey [2] live. We will be reaching out to all PTLs in the next month to make updates to the project-specific questions. If you have any questions in the meantime, please let me know. Thanks! Allison [1] http://superuser.openstack.org/articles/how-your-feedback-sparked-whats-next-for-cinder/ [2] https://www.openstack.org/user-survey/survey-2019 Allison Price OpenStack Foundation allison at openstack.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From msm at redhat.com Mon Dec 17 21:34:38 2018 From: msm at redhat.com (Michael McCune) Date: Mon, 17 Dec 2018 16:34:38 -0500 Subject: [sdk] Establishing SDK Validation Baseline In-Reply-To: References: <380a044d-8185-a312-2f7e-40bd663cf49c@openstack.org> Message-ID: On Mon, Dec 17, 2018 at 2:10 PM Melvin Hillsman wrote: > > +michael mccune I will be sure to stop by as well. > awesome! thanks Melvin peace o/ From cboylan at sapwetik.org Mon Dec 17 21:55:14 2018 From: cboylan at sapwetik.org (Clark Boylan) Date: Mon, 17 Dec 2018 13:55:14 -0800 Subject: Gate fracas (status) update In-Reply-To: References: Message-ID: <1545083714.1804387.1611839384.4E27DF7E@webmail.messagingengine.com> On Wed, Dec 12, 2018, at 11:50 AM, Matt Riedemann wrote: > I wanted to follow up from Clark's last gate status update [1]. Lots of > work has been going on the last few weeks to try and get the gate under > control since it's hard to merge code when you can't merge code. Most of > my update is specific to nova, but some of it might be interesting to > others as well for general QA/infra FYI. I'll group this into a few > categories of issue. Now a few days later I figure it is worth another update. > Snip > > Zuul queuing changes > -------------------- > > An infra thread [5] prompted some discussion in IRC which led to changes > in how tripleo changes will be queued by zuul [6][7]. The idea here is > to isolate tripleo changes into their own queue so failures in tripleo > changes don't disrupt (or starve) changes in openstack projects (in > general) from getting queued up for test nodes. tl;dr: nova changes > should enqueue more like they used to before [5]. https://review.openstack.org/#/c/625645/ has merged which reorgs projects based on their logical groups when it comes to relative priority. We hope this is a fairer accounting of priority. > > Gate bugs > --------- > Snip > > * http://status.openstack.org/elastic-recheck/#1808010 > > This is a real snowball issue where the cirros filesystem fills up so > config drive fails, falling back to use the metadata API to get > networking information but the metadata API response is too slow and > cloud-init times out. I've got a related fix [13] but we likely need > someone to help profile where our other inefficiencies are in responding > the metadata API requests. Devstack has updated to using the cirros 0.3.6 image which should fix the config drive support in cirros. This means that config drive based tests will be tested properly now, but any tests relying on metadata server will be affected if it is slow. > > * http://status.openstack.org/elastic-recheck/#1808063 > > This one is also relatively new and I'm not sure what might be causing it. > * http://status.openstack.org/elastic-recheck/index.html#1708704 This bug is tracking flaky yum installs. From what I have seen this is largely due to centos.org repos being unreliable and jobs not using our in cloud region mirrors. We updated multinode setup on centos in zuul-jobs (https://review.openstack.org/#/c/624817/) to address one case of this, but other jobs are seeing this too. If you run jobs against centos7 you may want to double check that this query doesn't affect your jobs (and fix the jobs if they do). Another change that went in was an update to devstack, https://review.openstack.org/#/c/625269/, to have losetup enable direct-io with its loopback devices. The thought here is that it may make cinder tests which rely on lvm on loopback devices more reliable. > ---- > > There are other bugs in the e-r page but the hits are low enough, or > they are latent enough, that I won't bother trying to detail them here. > > [1] > http://lists.openstack.org/pipermail/openstack-discuss/2018-December/thread.html#709 > [2] https://review.openstack.org/#/c/623538/ > [3] https://review.openstack.org/#/q/topic:drop-multiattach-job > [4] https://bugs.launchpad.net/tempest/+bug/1807723 > [5] > http://lists.openstack.org/pipermail/openstack-discuss/2018-December/thread.html#482 > [6] https://review.openstack.org/#/c/623595/ - this is the zuul feature > [7] https://review.openstack.org/#/c/624246/ - the tripleo-ci change > [8] https://review.openstack.org/#/c/615347/ > [9] https://bugs.launchpad.net/nova/+bug/1807219 > [10] https://bugs.launchpad.net/nova/+bug/1807044 > [11] https://review.openstack.org/#/c/623596 > [12] > https://review.openstack.org/#/q/I833d79ecc97ddc844bf156ab64477c7c77424f20 > [13] https://review.openstack.org/#/c/624778 > We've seen people show up across many projects to help debug and fix a variety of issues over the last week or two. Thank you to everyone that has helped, it does seem like the gate is a bit happier in recent days (though that may also be reduction in demand due to holidays). That said there is still quite a bit to clean up based on e-r data. Also our classification rate is still only about 60% so that can be improved too. All this to say don't let the holiday break undo the progress we've made. I look forward to continuing to debug this stuff with you in the new year. Clark From sean.mcginnis at gmx.com Mon Dec 17 22:12:38 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Mon, 17 Dec 2018 16:12:38 -0600 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> Message-ID: <20181217221238.GA17659@sm-workstation> > > The 0100 Wednesday meeting was generally seen as a good candidate to > drop, if we do drop one. No one seemed to support the idea of rotating > meeting times, so I'm going to eliminate that from consideration. We can > discuss the idea of changing the schedule of the meetings separately > from how many we want to have, so I will also postpone that question for > later. > > TC members, please respond to this thread indicating your support for > one of these options: > > 1. Keep the 3 fixed office hours. > 2. Drop the 0100 Wednesday meeting, keeping the other 2. > 3. Drop all office hours. > > -- > Doug > I'm about even on 1 or 2. Since there are a few TC folks that are able and willing to be around for the 0100 office hour, it doesn't really hurt to keep it as an encouraged time for anyone from those timezones to stop by with any questions. That said, these office hours were really only to "encourage" times when someone would be around for questions. It doesn't mean we couldn't drop it as an office hour and still have folks asking questions in the -tc channel. I guess that just depends on how much we want to try to get TC members to be immediately responsive during those times. I would not want to go with 3 and drop all office hours completely. I think we need at a minimum one office hour a week. Sean From bobh at haddleton.net Mon Dec 17 22:35:07 2018 From: bobh at haddleton.net (Bob Haddleton) Date: Mon, 17 Dec 2018 16:35:07 -0600 Subject: [tosca-parser] Failing to get functions from capabilities In-Reply-To: References: <25707aa1-bdd5-bef8-a038-e6369670cd5c@haddleton.net> Message-ID: I'm not sure where the inconsistency is?  Can you elaborate? You can get the inputs from the tosca.inputs attribute without passing any input parameters: tosca = ToscaTemplate(sys.argv[1]) print([input.name for input in tosca.inputs]) ['cpus', 'db_name', 'db_user', 'db_pwd', 'db_root_pwd', 'db_port'] Bob On 12/17/18 1:22 PM, Michael Still wrote: > Thanks for that. > > That approach seems fair enough, but inconsistent with how other > things are represented as functions. How am I meant to know what the > inputs to the CSAR are before the CSAR is parsed? > > Michael > > > > On Tue, Dec 18, 2018 at 1:28 AM Bob Haddleton > wrote: > > Hi Michael: > > tosca-parser expects that the input values will be defined already > and passed to the ToscaTemplate object in the parsed_params argument. > > If you change: > > tosca = ToscaTemplate(sys.argv[1]) > > to: > > tosca = ToscaTemplate(sys.argv[1], parsed_params={'cpus': 4}) > > the output becomes: > > Processing node template server >   disk_size: 10 GB >   num_cpus: 4 >   mem_size: 4096 MB >   architecture: x86_64 >   type: Linux >   distribution: Fedora >   version: 18.0 >   min_instances: 1 >   max_instances: 1 >   secure: True > > > Hope this helps. > > Bob > > > On 12/17/18 3:25 AM, Michael Still wrote: >> Hi, >> >> I'm trying to use tosca-parser to parse CSAR files. Its working >> quite well, until I hit a wall with capabilities today. >> Specifically I am testing with the single instance wordpress >> example CSAR, which uses a get_input for the num_cpus argument >> for host capabilities for the server. >> >> Based on how properties work, I would expect to get a function >> back for anything which requires referencing another value, but >> in the case of capabilities I either get the hardcoded value >> (strings, ints etc), or a None for values which would be >> functions if we were talking about prototypes. >> >> Here's a snippet of example code: >> >> #!/usr/bin/python >> >> import sys >> >> from jinja2 import Template >> import toscaparser.functions >> from toscaparser.tosca_template import ToscaTemplate >> >> tosca = ToscaTemplate(sys.argv[1]) >> >> for nodetemplate in tosca.nodetemplates: >>     print >>     print('Processing node template %s'% nodetemplate.name >> ) >> >>     capabilities = nodetemplate.get_capabilities_objects() >>     for cap in capabilities: >>         propobjs = cap.get_properties_objects() >>         if not propobjs: >>             continue >> >>         for po in propobjs: >>             print('  %s: %s' %(po.name , po.value)) >> >> Which returns this: >> >> $ python _capabilities.py csar_wordpress.zip >> No handlers could be found for logger "tosca.model" >> >> Processing node template wordpress >>   network_name: PRIVATE >>   initiator: source >>   protocol: tcp >>   secure: False >> >> Processing node template webserver >>   network_name: PRIVATE >>   initiator: source >>   protocol: tcp >>   secure: False >>   secure: True >> >> Processing node template mysql_dbms >> >> Processing node template mysql_database >> >> Processing node template server >>   secure: True >>   min_instances: 1 >>   max_instances: 1 >>   mem_size: 4096 MB >>   num_cpus: None >>   disk_size: 10 GB >>   distribution: Fedora >>   version: 18.0 >>   type: Linux >>   architecture: x86_64 >> >> I would expect num_cpus for the "server" node_template to be a >> GetInput() function based on its definition in the CSAR, but >> instead I get None. >> >> Is there an example somewhere of how to correctly access >> functions for capabilities? >> >> Thanks, >> Michael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikal at stillhq.com Mon Dec 17 22:45:47 2018 From: mikal at stillhq.com (Michael Still) Date: Tue, 18 Dec 2018 09:45:47 +1100 Subject: [tosca-parser] Failing to get functions from capabilities In-Reply-To: References: <25707aa1-bdd5-bef8-a038-e6369670cd5c@haddleton.net> Message-ID: In my mind (and I might be wrong), the inconsistency is that for properties, interfaces and outputs if the value parsed is a reference to something else I get a function which will resolve the value if I ask it nicely. However for capabilities, I instead get None unless I have passed in parsed parameters. This is despite the functions code supporting get_input. The issue with parsed parameters is I now need to run the parser twice -- the first run to detect what the inputs are, and then the second to provide values for those so that the substitution occurs. That seems like a confusing user interface to me. Michael On Tue, Dec 18, 2018 at 9:35 AM Bob Haddleton wrote: > I'm not sure where the inconsistency is? Can you elaborate? > > You can get the inputs from the tosca.inputs attribute without passing any > input parameters: > > tosca = ToscaTemplate(sys.argv[1]) > > print([input.name for input in tosca.inputs]) > > ['cpus', 'db_name', 'db_user', 'db_pwd', 'db_root_pwd', 'db_port'] > > > Bob > > On 12/17/18 1:22 PM, Michael Still wrote: > > Thanks for that. > > That approach seems fair enough, but inconsistent with how other things > are represented as functions. How am I meant to know what the inputs to the > CSAR are before the CSAR is parsed? > > Michael > > > > On Tue, Dec 18, 2018 at 1:28 AM Bob Haddleton wrote: > >> Hi Michael: >> >> tosca-parser expects that the input values will be defined already and >> passed to the ToscaTemplate object in the parsed_params argument. >> >> If you change: >> >> tosca = ToscaTemplate(sys.argv[1]) >> >> to: >> >> tosca = ToscaTemplate(sys.argv[1], parsed_params={'cpus': 4}) >> >> the output becomes: >> >> Processing node template server >> disk_size: 10 GB >> num_cpus: 4 >> mem_size: 4096 MB >> architecture: x86_64 >> type: Linux >> distribution: Fedora >> version: 18.0 >> min_instances: 1 >> max_instances: 1 >> secure: True >> >> >> Hope this helps. >> >> Bob >> >> >> On 12/17/18 3:25 AM, Michael Still wrote: >> >> Hi, >> >> I'm trying to use tosca-parser to parse CSAR files. Its working quite >> well, until I hit a wall with capabilities today. Specifically I am testing >> with the single instance wordpress example CSAR, which uses a get_input for >> the num_cpus argument for host capabilities for the server. >> >> Based on how properties work, I would expect to get a function back for >> anything which requires referencing another value, but in the case of >> capabilities I either get the hardcoded value (strings, ints etc), or a >> None for values which would be functions if we were talking about >> prototypes. >> >> Here's a snippet of example code: >> >> #!/usr/bin/python >> >> import sys >> >> from jinja2 import Template >> import toscaparser.functions >> from toscaparser.tosca_template import ToscaTemplate >> >> tosca = ToscaTemplate(sys.argv[1]) >> >> for nodetemplate in tosca.nodetemplates: >> print >> print('Processing node template %s'% nodetemplate.name) >> >> capabilities = nodetemplate.get_capabilities_objects() >> for cap in capabilities: >> propobjs = cap.get_properties_objects() >> if not propobjs: >> continue >> >> for po in propobjs: >> print(' %s: %s' %(po.name, po.value)) >> >> Which returns this: >> >> $ python _capabilities.py csar_wordpress.zip >> No handlers could be found for logger "tosca.model" >> >> Processing node template wordpress >> network_name: PRIVATE >> initiator: source >> protocol: tcp >> secure: False >> >> Processing node template webserver >> network_name: PRIVATE >> initiator: source >> protocol: tcp >> secure: False >> secure: True >> >> Processing node template mysql_dbms >> >> Processing node template mysql_database >> >> Processing node template server >> secure: True >> min_instances: 1 >> max_instances: 1 >> mem_size: 4096 MB >> num_cpus: None >> disk_size: 10 GB >> distribution: Fedora >> version: 18.0 >> type: Linux >> architecture: x86_64 >> >> I would expect num_cpus for the "server" node_template to be a GetInput() >> function based on its definition in the CSAR, but instead I get None. >> >> Is there an example somewhere of how to correctly access functions for >> capabilities? >> >> Thanks, >> Michael >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Mon Dec 17 23:15:11 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Mon, 17 Dec 2018 17:15:11 -0600 Subject: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata" In-Reply-To: <8557b741-d4f5-cdfd-a244-65b47a1c3445@gmail.com> References: <8557b741-d4f5-cdfd-a244-65b47a1c3445@gmail.com> Message-ID: <058f5de0-9ebb-3cda-9216-5554fc229433@gmail.com> On 12/12/2018 1:18 PM, Matt Riedemann wrote: > Coming back on this thread [1], I've got a partial fix up which I'm > hoping will help: > > https://review.openstack.org/#/c/624778/ > > That will avoid joining on some other tables depending on your > configuration. It would be great if you could see if that helps resolve > your issue. I think you just reverted > https://review.openstack.org/#/c/276861/ as a workaround but it would be > good to know if a more permanent fix (mine) gets you similar, or at > least satisfactory, results. > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2018-October/thread.html#135941 I have abandoned that change since it turns out that we need to join on the instance_system_metadata table to get the instance password which is retrieved from a base metadata request. Otherwise you can see the failures here [1]. So either we need to: * Optimize the instance get DB query and joins we do. Dan was looking at this but it was non-trivial. * Reconsider how we store the instance password so it's not in the instance_system_metadata table. Or deployments can aggressively cache the metadata API responses (or scale out the number of metadata API workers) to try and deal with load. [1] http://logs.openstack.org/78/624778/1/check/tempest-full/8d3c124/controller/logs/screen-n-api-meta.txt.gz#_Dec_13_08_45_56_602421 -- Thanks, Matt From manuel.sb at garvan.org.au Mon Dec 17 23:54:27 2018 From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros) Date: Mon, 17 Dec 2018 23:54:27 +0000 Subject: [KOLLA][MONASCA] monasca containers not running Message-ID: <9D8A2486E35F0941A60430473E29F15B017BAF995F@MXDB2.ad.garvan.unsw.edu.au> Dear Openstack and Kolla community, I am trying to deploy monasca using kolla-ansible 7.0.0 and realised a couple of containers are not working Container monasca_log_persister See: 'bin/logstash --help' + sudo -E kolla_set_configs INFO:__main__:Loading config file at /var/lib/kolla/config_files/config.json INFO:__main__:Validating config file INFO:__main__:Kolla config strategy set to: COPY_ALWAYS INFO:__main__:Copying service configuration files INFO:__main__:Deleting /etc/logstash/conf.d/log-persister.conf INFO:__main__:Copying /var/lib/kolla/config_files/log-persister.conf to /etc/logstash/conf.d/log-persister.conf INFO:__main__:Setting permission for /etc/logstash/conf.d/log-persister.conf INFO:__main__:Deleting /etc/logstash/elasticsearch-template.json INFO:__main__:Copying /var/lib/kolla/config_files/elasticsearch-template.json to /etc/logstash/elasticsearch-template.json INFO:__main__:Setting permission for /etc/logstash/elasticsearch-template.json INFO:__main__:Writing out command to execute INFO:__main__:Setting permission for /var/log/kolla/monasca INFO:__main__:Setting permission for /var/log/kolla/monasca/monasca-api-error.log INFO:__main__:Setting permission for /var/log/kolla/monasca/monasca-api-access.log INFO:__main__:Setting permission for /var/log/kolla/monasca/monasca-log-api-error.log INFO:__main__:Setting permission for /var/log/kolla/monasca/monasca-log-api-access.log ++ cat /run_command + CMD='/usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/monasca/monasca-log-persister.log -f /etc/logstash/conf.d/log-persister.conf' + ARGS= + [[ ! -n '' ]] + . kolla_extend_start ++ [[ ! -d /var/log/kolla/logstash ]] +++ stat -c %a /var/log/kolla/logstash ++ [[ 755 != \7\5\5 ]] + echo 'Running command: '\''/usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/monasca/monasca-log-persister.log -f /etc/logstash/conf.d/log-persister.conf'\''' Running command: '/usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/monasca/monasca-log-persister.log -f /etc/logstash/conf.d/log-persister.conf' + exec /usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/monasca/monasca-log-persister.log -f /etc/logstash/conf.d/log-persister.conf WARNING: Could not find logstash.yml which is typically located in $LS_HOME/config or /etc/logstash. You can specify the path using --path.settings. Continuing using the defaults ERROR: Unrecognised option '--log-in-json' Container monasca_log_transformer See: 'bin/logstash --help' + sudo -E kolla_set_configs INFO:__main__:Loading config file at /var/lib/kolla/config_files/config.json INFO:__main__:Validating config file INFO:__main__:Kolla config strategy set to: COPY_ALWAYS INFO:__main__:Copying service configuration files INFO:__main__:Deleting /etc/logstash/conf.d/log-transformer.conf INFO:__main__:Copying /var/lib/kolla/config_files/log-transformer.conf to /etc/logstash/conf.d/log-transformer.conf INFO:__main__:Setting permission for /etc/logstash/conf.d/log-transformer.conf INFO:__main__:Writing out command to execute INFO:__main__:Setting permission for /var/log/kolla/logstash ++ cat /run_command + CMD='/usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/logstash/monasca-log-transformer.log -f /etc/logstash/conf.d/log-transformer.conf' + ARGS= + [[ ! -n '' ]] + . kolla_extend_start ++ [[ ! -d /var/log/kolla/logstash ]] +++ stat -c %a /var/log/kolla/logstash ++ [[ 755 != \7\5\5 ]] + echo 'Running command: '\''/usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/logstash/monasca-log-transformer.log -f /etc/logstash/conf.d/log-transformer.conf'\''' Running command: '/usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/logstash/monasca-log-transformer.log -f /etc/logstash/conf.d/log-transformer.conf' + exec /usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/logstash/monasca-log-transformer.log -f /etc/logstash/conf.d/log-transformer.conf WARNING: Could not find logstash.yml which is typically located in $LS_HOME/config or /etc/logstash. You can specify the path using --path.settings. Continuing using the defaults ERROR: Unrecognised option '--log-in-json' Any thoughts? 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: From doug at doughellmann.com Tue Dec 18 00:04:52 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 17 Dec 2018 19:04:52 -0500 Subject: [all] Service-specific configuration options In-Reply-To: <78c490d4eb78b48f0fd2910bb69104f809c7c9fa.camel@redhat.com> References: <78c490d4eb78b48f0fd2910bb69104f809c7c9fa.camel@redhat.com> Message-ID: Stephen Finucane writes: > I proposed a WIP change for oslo.config [1] last week that would allow > us to specify what services (e.g. nova-compute, nova-scheduler, nova- > api, etc.) an option applies to. This came about because of comments on > another issue where we found no one could say with surety what services > needed an option in their configuration option (which in turn brought > up questions about why those services needed the option). It was > suggested I bring the idea up on the mailing list before we proceeded > any further with it so here I am. > > I'm interested in two things. Firstly, I'd like to know whether > generation of per-service configuration files is actually something > others find problematic? I'm imagining this is annoying for operators > and those working on deployment tooling but I've never got any hard > data to back up that assumption. Secondly, I didn't see anything in the > likes of cinder, nova or neutron but has anyone else already worked on > something like this? For what it's worth, I did explain why I've gone > with the approach I have in the commit message, but that doesn't mean > there aren't other options I could be missing. > > Stephen > > [1] https://review.openstack.org/#/c/625011/ > > PS: I've tagged this [all] as enumerating the projects this actually > affected left me with at least a dozen tags before I was even done. > Sorry for any possible noise. > > Glance uses different entry points to produce service-specific configuration option sample files and documentation. See https://docs.openstack.org/glance/latest/configuration/index.html for example. -- Doug From bobh at haddleton.net Tue Dec 18 01:20:16 2018 From: bobh at haddleton.net (Bob Haddleton) Date: Mon, 17 Dec 2018 19:20:16 -0600 Subject: [tosca-parser] Failing to get functions from capabilities In-Reply-To: References: <25707aa1-bdd5-bef8-a038-e6369670cd5c@haddleton.net> Message-ID: I see what you mean.  It appears to be intentional, since there is code here [1] that explicitly replaces the GetInput function with the value of the passed parameter. At a minimum it might make sense to only replace the function with the parameter value if the parameter is not None. I don't there is a way to provide input values to the ToscaTemplate object after it has been created, so I don't know how any "future" input values would be handled. Is there a specific scenario you want to support that requires this? Thanks Bob [1] - https://github.com/openstack/tosca-parser/blob/master/toscaparser/topology_template.py#L282 On 12/17/18 4:45 PM, Michael Still wrote: > In my mind (and I might be wrong), the inconsistency is that for > properties, interfaces and outputs if the value parsed is a reference > to something else I get a function which will resolve the value if I > ask it nicely. However for capabilities, I instead get None unless I > have passed in parsed parameters. This is despite the functions code > supporting get_input. > > The issue with parsed parameters is I now need to run the parser twice > -- the first run to detect what the inputs are, and then the second to > provide values for those so that the substitution occurs. That seems > like a confusing user interface to me. > > Michael > > > On Tue, Dec 18, 2018 at 9:35 AM Bob Haddleton > wrote: > > I'm not sure where the inconsistency is?  Can you elaborate? > > You can get the inputs from the tosca.inputs attribute without > passing any input parameters: > > tosca = ToscaTemplate(sys.argv[1]) > > print([input.name for input in tosca.inputs]) > > ['cpus', 'db_name', 'db_user', 'db_pwd', 'db_root_pwd', 'db_port'] > > > Bob > > On 12/17/18 1:22 PM, Michael Still wrote: >> Thanks for that. >> >> That approach seems fair enough, but inconsistent with how other >> things are represented as functions. How am I meant to know what >> the inputs to the CSAR are before the CSAR is parsed? >> >> Michael >> >> >> >> On Tue, Dec 18, 2018 at 1:28 AM Bob Haddleton > > wrote: >> >> Hi Michael: >> >> tosca-parser expects that the input values will be defined >> already and passed to the ToscaTemplate object in the >> parsed_params argument. >> >> If you change: >> >> tosca = ToscaTemplate(sys.argv[1]) >> >> to: >> >> tosca = ToscaTemplate(sys.argv[1], parsed_params={'cpus': 4}) >> >> the output becomes: >> >> Processing node template server >>   disk_size: 10 GB >>   num_cpus: 4 >>   mem_size: 4096 MB >>   architecture: x86_64 >>   type: Linux >>   distribution: Fedora >>   version: 18.0 >>   min_instances: 1 >>   max_instances: 1 >>   secure: True >> >> >> Hope this helps. >> >> Bob >> >> >> On 12/17/18 3:25 AM, Michael Still wrote: >>> Hi, >>> >>> I'm trying to use tosca-parser to parse CSAR files. Its >>> working quite well, until I hit a wall with capabilities >>> today. Specifically I am testing with the single instance >>> wordpress example CSAR, which uses a get_input for the >>> num_cpus argument for host capabilities for the server. >>> >>> Based on how properties work, I would expect to get a >>> function back for anything which requires referencing >>> another value, but in the case of capabilities I either get >>> the hardcoded value (strings, ints etc), or a None for >>> values which would be functions if we were talking about >>> prototypes. >>> >>> Here's a snippet of example code: >>> >>> #!/usr/bin/python >>> >>> import sys >>> >>> from jinja2 import Template >>> import toscaparser.functions >>> from toscaparser.tosca_template import ToscaTemplate >>> >>> tosca = ToscaTemplate(sys.argv[1]) >>> >>> for nodetemplate in tosca.nodetemplates: >>>     print >>>     print('Processing node template %s'% nodetemplate.name >>> ) >>> >>>     capabilities = nodetemplate.get_capabilities_objects() >>>     for cap in capabilities: >>>         propobjs = cap.get_properties_objects() >>>         if not propobjs: >>>             continue >>> >>>         for po in propobjs: >>>             print('  %s: %s' %(po.name , >>> po.value)) >>> >>> Which returns this: >>> >>> $ python _capabilities.py csar_wordpress.zip >>> No handlers could be found for logger "tosca.model" >>> >>> Processing node template wordpress >>>   network_name: PRIVATE >>>   initiator: source >>>   protocol: tcp >>>   secure: False >>> >>> Processing node template webserver >>>   network_name: PRIVATE >>>   initiator: source >>>   protocol: tcp >>>   secure: False >>>   secure: True >>> >>> Processing node template mysql_dbms >>> >>> Processing node template mysql_database >>> >>> Processing node template server >>>   secure: True >>>   min_instances: 1 >>>   max_instances: 1 >>>   mem_size: 4096 MB >>>   num_cpus: None >>>   disk_size: 10 GB >>>   distribution: Fedora >>>   version: 18.0 >>>   type: Linux >>>   architecture: x86_64 >>> >>> I would expect num_cpus for the "server" node_template to be >>> a GetInput() function based on its definition in the CSAR, >>> but instead I get None. >>> >>> Is there an example somewhere of how to correctly access >>> functions for capabilities? >>> >>> Thanks, >>> Michael >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikal at stillhq.com Tue Dec 18 01:46:12 2018 From: mikal at stillhq.com (Michael Still) Date: Tue, 18 Dec 2018 12:46:12 +1100 Subject: [tosca-parser] Failing to get functions from capabilities In-Reply-To: References: <25707aa1-bdd5-bef8-a038-e6369670cd5c@haddleton.net> Message-ID: Yeah, fair enough. What leads me here is I am writing a converter from CSAR to Cloudify blueprints (which is similar to the CSAR to Heat converter which already exists). Cloudify blueprints are another TOSCA dialect, so I want to leave the get_input line preserved and let Cloudify sort that out when it executes the blueprint. Thanks, Michael On Tue, Dec 18, 2018 at 12:20 PM Bob Haddleton wrote: > I see what you mean. It appears to be intentional, since there is code > here [1] that explicitly replaces the GetInput function with the value of > the passed parameter. > > At a minimum it might make sense to only replace the function with the > parameter value if the parameter is not None. > > I don't there is a way to provide input values to the ToscaTemplate object > after it has been created, so I don't know how any "future" input values > would be handled. > > Is there a specific scenario you want to support that requires this? > > Thanks > > Bob > > > [1] - > https://github.com/openstack/tosca-parser/blob/master/toscaparser/topology_template.py#L282 > On 12/17/18 4:45 PM, Michael Still wrote: > > In my mind (and I might be wrong), the inconsistency is that for > properties, interfaces and outputs if the value parsed is a reference to > something else I get a function which will resolve the value if I ask it > nicely. However for capabilities, I instead get None unless I have passed > in parsed parameters. This is despite the functions code supporting > get_input. > > The issue with parsed parameters is I now need to run the parser twice -- > the first run to detect what the inputs are, and then the second to provide > values for those so that the substitution occurs. That seems like a > confusing user interface to me. > > Michael > > > On Tue, Dec 18, 2018 at 9:35 AM Bob Haddleton wrote: > >> I'm not sure where the inconsistency is? Can you elaborate? >> >> You can get the inputs from the tosca.inputs attribute without passing >> any input parameters: >> >> tosca = ToscaTemplate(sys.argv[1]) >> >> print([input.name for input in tosca.inputs]) >> >> ['cpus', 'db_name', 'db_user', 'db_pwd', 'db_root_pwd', 'db_port'] >> >> >> Bob >> >> On 12/17/18 1:22 PM, Michael Still wrote: >> >> Thanks for that. >> >> That approach seems fair enough, but inconsistent with how other things >> are represented as functions. How am I meant to know what the inputs to the >> CSAR are before the CSAR is parsed? >> >> Michael >> >> >> >> On Tue, Dec 18, 2018 at 1:28 AM Bob Haddleton wrote: >> >>> Hi Michael: >>> >>> tosca-parser expects that the input values will be defined already and >>> passed to the ToscaTemplate object in the parsed_params argument. >>> >>> If you change: >>> >>> tosca = ToscaTemplate(sys.argv[1]) >>> >>> to: >>> >>> tosca = ToscaTemplate(sys.argv[1], parsed_params={'cpus': 4}) >>> >>> the output becomes: >>> >>> Processing node template server >>> disk_size: 10 GB >>> num_cpus: 4 >>> mem_size: 4096 MB >>> architecture: x86_64 >>> type: Linux >>> distribution: Fedora >>> version: 18.0 >>> min_instances: 1 >>> max_instances: 1 >>> secure: True >>> >>> >>> Hope this helps. >>> >>> Bob >>> >>> >>> On 12/17/18 3:25 AM, Michael Still wrote: >>> >>> Hi, >>> >>> I'm trying to use tosca-parser to parse CSAR files. Its working quite >>> well, until I hit a wall with capabilities today. Specifically I am testing >>> with the single instance wordpress example CSAR, which uses a get_input for >>> the num_cpus argument for host capabilities for the server. >>> >>> Based on how properties work, I would expect to get a function back for >>> anything which requires referencing another value, but in the case of >>> capabilities I either get the hardcoded value (strings, ints etc), or a >>> None for values which would be functions if we were talking about >>> prototypes. >>> >>> Here's a snippet of example code: >>> >>> #!/usr/bin/python >>> >>> import sys >>> >>> from jinja2 import Template >>> import toscaparser.functions >>> from toscaparser.tosca_template import ToscaTemplate >>> >>> tosca = ToscaTemplate(sys.argv[1]) >>> >>> for nodetemplate in tosca.nodetemplates: >>> print >>> print('Processing node template %s'% nodetemplate.name) >>> >>> capabilities = nodetemplate.get_capabilities_objects() >>> for cap in capabilities: >>> propobjs = cap.get_properties_objects() >>> if not propobjs: >>> continue >>> >>> for po in propobjs: >>> print(' %s: %s' %(po.name, po.value)) >>> >>> Which returns this: >>> >>> $ python _capabilities.py csar_wordpress.zip >>> No handlers could be found for logger "tosca.model" >>> >>> Processing node template wordpress >>> network_name: PRIVATE >>> initiator: source >>> protocol: tcp >>> secure: False >>> >>> Processing node template webserver >>> network_name: PRIVATE >>> initiator: source >>> protocol: tcp >>> secure: False >>> secure: True >>> >>> Processing node template mysql_dbms >>> >>> Processing node template mysql_database >>> >>> Processing node template server >>> secure: True >>> min_instances: 1 >>> max_instances: 1 >>> mem_size: 4096 MB >>> num_cpus: None >>> disk_size: 10 GB >>> distribution: Fedora >>> version: 18.0 >>> type: Linux >>> architecture: x86_64 >>> >>> I would expect num_cpus for the "server" node_template to be a >>> GetInput() function based on its definition in the CSAR, but instead I get >>> None. >>> >>> Is there an example somewhere of how to correctly access functions for >>> capabilities? >>> >>> Thanks, >>> Michael >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bobh at haddleton.net Tue Dec 18 01:55:06 2018 From: bobh at haddleton.net (Bob Haddleton) Date: Mon, 17 Dec 2018 19:55:06 -0600 Subject: [tosca-parser] Failing to get functions from capabilities In-Reply-To: References: <25707aa1-bdd5-bef8-a038-e6369670cd5c@haddleton.net> Message-ID: Can you open a bug and I’ll run it by a couple of people to make sure it doesn’t break anything? I think it makes sense to leave the function in place if there are no parameters provided. Thanks Bob > On Dec 17, 2018, at 19:46, Michael Still wrote: > > Yeah, fair enough. > > What leads me here is I am writing a converter from CSAR to Cloudify blueprints (which is similar to the CSAR to Heat converter which already exists). Cloudify blueprints are another TOSCA dialect, so I want to leave the get_input line preserved and let Cloudify sort that out when it executes the blueprint. > > Thanks, > Michael > > >> On Tue, Dec 18, 2018 at 12:20 PM Bob Haddleton wrote: >> I see what you mean. It appears to be intentional, since there is code here [1] that explicitly replaces the GetInput function with the value of the passed parameter. >> >> At a minimum it might make sense to only replace the function with the parameter value if the parameter is not None. >> >> I don't there is a way to provide input values to the ToscaTemplate object after it has been created, so I don't know how any "future" input values would be handled. >> >> Is there a specific scenario you want to support that requires this? >> >> Thanks >> >> Bob >> >> >> [1] - https://github.com/openstack/tosca-parser/blob/master/toscaparser/topology_template.py#L282 >>> On 12/17/18 4:45 PM, Michael Still wrote: >>> In my mind (and I might be wrong), the inconsistency is that for properties, interfaces and outputs if the value parsed is a reference to something else I get a function which will resolve the value if I ask it nicely. However for capabilities, I instead get None unless I have passed in parsed parameters. This is despite the functions code supporting get_input. >>> >>> The issue with parsed parameters is I now need to run the parser twice -- the first run to detect what the inputs are, and then the second to provide values for those so that the substitution occurs. That seems like a confusing user interface to me. >>> >>> Michael >>> >>> >>>> On Tue, Dec 18, 2018 at 9:35 AM Bob Haddleton wrote: >>>> I'm not sure where the inconsistency is? Can you elaborate? >>>> >>>> You can get the inputs from the tosca.inputs attribute without passing any input parameters: >>>> >>>> tosca = ToscaTemplate(sys.argv[1]) >>>> >>>> print([input.name for input in tosca.inputs]) >>>> >>>> ['cpus', 'db_name', 'db_user', 'db_pwd', 'db_root_pwd', 'db_port'] >>>> >>>> >>>> Bob >>>> >>>>> On 12/17/18 1:22 PM, Michael Still wrote: >>>>> Thanks for that. >>>>> >>>>> That approach seems fair enough, but inconsistent with how other things are represented as functions. How am I meant to know what the inputs to the CSAR are before the CSAR is parsed? >>>>> >>>>> Michael >>>>> >>>>> >>>>> >>>>>> On Tue, Dec 18, 2018 at 1:28 AM Bob Haddleton wrote: >>>>>> Hi Michael: >>>>>> >>>>>> tosca-parser expects that the input values will be defined already and passed to the ToscaTemplate object in the parsed_params argument. >>>>>> >>>>>> If you change: >>>>>> >>>>>> tosca = ToscaTemplate(sys.argv[1]) >>>>>> >>>>>> to: >>>>>> >>>>>> tosca = ToscaTemplate(sys.argv[1], parsed_params={'cpus': 4}) >>>>>> >>>>>> the output becomes: >>>>>> >>>>>> Processing node template server >>>>>> disk_size: 10 GB >>>>>> num_cpus: 4 >>>>>> mem_size: 4096 MB >>>>>> architecture: x86_64 >>>>>> type: Linux >>>>>> distribution: Fedora >>>>>> version: 18.0 >>>>>> min_instances: 1 >>>>>> max_instances: 1 >>>>>> secure: True >>>>>> >>>>>> >>>>>> Hope this helps. >>>>>> >>>>>> Bob >>>>>> >>>>>> >>>>>>> On 12/17/18 3:25 AM, Michael Still wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'm trying to use tosca-parser to parse CSAR files. Its working quite well, until I hit a wall with capabilities today. Specifically I am testing with the single instance wordpress example CSAR, which uses a get_input for the num_cpus argument for host capabilities for the server. >>>>>>> >>>>>>> Based on how properties work, I would expect to get a function back for anything which requires referencing another value, but in the case of capabilities I either get the hardcoded value (strings, ints etc), or a None for values which would be functions if we were talking about prototypes. >>>>>>> >>>>>>> Here's a snippet of example code: >>>>>>> >>>>>>> #!/usr/bin/python >>>>>>> >>>>>>> import sys >>>>>>> >>>>>>> from jinja2 import Template >>>>>>> import toscaparser.functions >>>>>>> from toscaparser.tosca_template import ToscaTemplate >>>>>>> >>>>>>> tosca = ToscaTemplate(sys.argv[1]) >>>>>>> >>>>>>> for nodetemplate in tosca.nodetemplates: >>>>>>> print >>>>>>> print('Processing node template %s'% nodetemplate.name) >>>>>>> >>>>>>> capabilities = nodetemplate.get_capabilities_objects() >>>>>>> for cap in capabilities: >>>>>>> propobjs = cap.get_properties_objects() >>>>>>> if not propobjs: >>>>>>> continue >>>>>>> >>>>>>> for po in propobjs: >>>>>>> print(' %s: %s' %(po.name, po.value)) >>>>>>> >>>>>>> Which returns this: >>>>>>> >>>>>>> $ python _capabilities.py csar_wordpress.zip >>>>>>> No handlers could be found for logger "tosca.model" >>>>>>> >>>>>>> Processing node template wordpress >>>>>>> network_name: PRIVATE >>>>>>> initiator: source >>>>>>> protocol: tcp >>>>>>> secure: False >>>>>>> >>>>>>> Processing node template webserver >>>>>>> network_name: PRIVATE >>>>>>> initiator: source >>>>>>> protocol: tcp >>>>>>> secure: False >>>>>>> secure: True >>>>>>> >>>>>>> Processing node template mysql_dbms >>>>>>> >>>>>>> Processing node template mysql_database >>>>>>> >>>>>>> Processing node template server >>>>>>> secure: True >>>>>>> min_instances: 1 >>>>>>> max_instances: 1 >>>>>>> mem_size: 4096 MB >>>>>>> num_cpus: None >>>>>>> disk_size: 10 GB >>>>>>> distribution: Fedora >>>>>>> version: 18.0 >>>>>>> type: Linux >>>>>>> architecture: x86_64 >>>>>>> >>>>>>> I would expect num_cpus for the "server" node_template to be a GetInput() function based on its definition in the CSAR, but instead I get None. >>>>>>> >>>>>>> Is there an example somewhere of how to correctly access functions for capabilities? >>>>>>> >>>>>>> Thanks, >>>>>>> Michael >>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zbitter at redhat.com Tue Dec 18 02:52:51 2018 From: zbitter at redhat.com (Zane Bitter) Date: Tue, 18 Dec 2018 15:52:51 +1300 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> Message-ID: <1167de33-6942-13de-67e0-c86756deab25@redhat.com> On 18/12/18 5:58 AM, Doug Hellmann wrote: > Thierry Carrez writes: > >> Hi, >> >> A while ago, the Technical Committee designated specific hours in the >> week where members would make extra effort to be around on #openstack-tc >> on IRC, so that community members looking for answers to their questions >> or wanting to engage can find a time convenient for them and a critical >> mass of TC members around. We currently have 3 weekly spots: >> >> - 09:00 UTC on Tuesdays >> - 01:00 UTC on Wednesdays >> - 15:00 UTC on Thursdays >> >> But after a few months it appears that: >> >> 1/ nobody really comes on channel at office hour time to ask questions. >> We had a questions on the #openstack-tc IRC channel, but I wouldn't say >> people take benefit of the synced time >> >> 2/ some office hours (most notably the 01:00 UTC on Wednesdays, but also >> to a lesser extent the 09:00 UTC on Tuesdays) end up just being a couple >> of TC members present >> >> So the schedule is definitely not reaching its objectives, and as such >> may be a bit overkill. I was also wondering if this is not a case where >> the offer is hurting the demand -- by having so many office hour spots >> around, nobody considers them special. >> >> Should we: >> >> - Reduce office hours to one or two per week, possibly rotating times >> >> - Dump the whole idea and just encourage people to ask questions at any >> time on #openstack-tc, and get asynchronous answers >> >> - Keep it as-is, it still has the side benefit of triggering spikes of >> TC member activity >> >> Thoughts ? >> >> -- >> Thierry Carrez (ttx) >> > > I would like for us to make a decision about this. > > The 0100 Wednesday meeting was generally seen as a good candidate to > drop, if we do drop one. No one seemed to support the idea of rotating > meeting times, so I'm going to eliminate that from consideration. We can > discuss the idea of changing the schedule of the meetings separately > from how many we want to have, so I will also postpone that question for > later. > > TC members, please respond to this thread indicating your support for > one of these options: > > 1. Keep the 3 fixed office hours. > 2. Drop the 0100 Wednesday meeting, keeping the other 2. > 3. Drop all office hours. Of those options I think I have to vote for 1. The 0100 Wednesday is (temporarily) the only one I can actually attend, so I'm in favour of keeping it. I'm also deeply sceptical that having fewer office hours will boost interest. TBH I'm not actually sure I know what we are trying to achieve at this point. When the TC started office hours it was as a more time-zone-friendly replacement for the weekly meeting. And the weekly meeting was mainly used for discussion amongst the TC members and those folks who consistently follow the TC's activity (many of whom are hopefully future TC candidates - the fact that largely only folks from certain time zones were joining this group was the problematic part of meetings to my mind). However, recently we've been saying that the purpose of office hours is to bring in folks who aren't part of that group to ask questions, and that the folks who are in the group should actively avoid discussion in order to not discourage them. Then we are surprised when things are quiet. Is there actually any reason to think that there is a problematic level of under-reporting of TC-escalation-worthy issues? I can't think an a priori reason to expect that in a healthy project there should be large numbers of issues escalated to the TC. And despite focusing our meeting strategy around that and conducting a massively time-consuming campaign of reaching out to teams individually via the health checks, I'm not seeing any empirical evidence of it either. Meanwhile there's ample evidence that we need more time to discuss things as a group - just witness the difficulty of getting through a monthly meeting in < 1 hour by trying to stick to purely procedural stuff. (A more cynical person than I might suggest that going searching for trivial issues that we can 'solve' by fiat offers a higher dopamine-to-time-spent ratio than working together as a team to do... anything at all, and that this may explain some of its popularity.) IMHO our goal should be - like every other team's - to grow the group of people around the TC who form the 'governance team' for which the TC members are effectively the core reviewers, and from which we expect to find our next generation of TC members. While doing that, we must try to ensure that we're not structurally limiting the composition of the group by longitude. But I don't think we'll get there by trying to be quiet so they can speak up - we'll get there by being present and talking about interesting stuff that people want to join in on. If there's a problem with casual contributors making themselves heard, provide them with a way to get their topic on an informal agenda (or encourage them to begin on the mailing list) and make sure it gets raised during office hours so they are not drowned out. I might support rejigging the times and dropping to twice a week if I thought that it meant a majority of the TC would show up each time and discussions would actually happen (we had an etherpad of topics at some point that I haven't seen in a long time). In that case I would even join the 10pm session if necessary to participate, though we should recognise that for folks from this part of the world who *don't* have a formal role that's a massive obstacle. cheers, Zane. From mriedemos at gmail.com Tue Dec 18 04:26:02 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Mon, 17 Dec 2018 22:26:02 -0600 Subject: [all] Service-specific configuration options In-Reply-To: <78c490d4eb78b48f0fd2910bb69104f809c7c9fa.camel@redhat.com> References: <78c490d4eb78b48f0fd2910bb69104f809c7c9fa.camel@redhat.com> Message-ID: <995c6808-7305-7ea5-d32d-7e056723d476@gmail.com> On 12/17/2018 10:46 AM, Stephen Finucane wrote: > Secondly, I didn't see anything in the > likes of cinder, nova or neutron but has anyone else already worked on > something like this? For what it's worth, I did explain why I've gone > with the approach I have in the commit message, but that doesn't mean > there aren't other options I could be missing. When Markus Zoeller was originally doing the nova config option cleanup [1] which included centralizing everything under nova/conf/ and also updating the documentation on all options to have a standard format, he also included a list of which services used each option. Over time that was dropped, presumably because (1) it's hard as hell to maintain with as many options as nova has and as much code motion that nova has and (2) it's hard to know if it is useful at all given I expect most people are pushing config option changes to a single nova.conf that gets pushed to all of their services (there are especially some options which simply don't work if they aren't in nova-api and nova-compute for example [reclaim_instance_interval]). John Garbutt and/or Michael Still might remember more, but that's my recollection. So I'd rather not re-open this can of worms. If a particular option or set of options are hairy with service configuration, then call those out specifically in the help for those options. Having said that, I recently helped someone in IRC who couldn't figure out how to get vendor data from the metadata API into the config drive and it was because they weren't setting some metadata API config options in nova-compute where the config drive is built. That was likely due to confusion because the "vendordata_jsonfile_path" option in nova is in the [api] group which would naturally make one think that's only needed in nova-api, but it's also used in nova-compute when building a config drive. As a result, I opted to cleanup the help and our docs [2]. Anyway, I think we've got wayyyyy bigger problems to solve than dig back into a multi-release effort to document where all of our config options are used. [1] https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/centralize-config-options.html [2] https://review.openstack.org/#/c/624518/ -- Thanks, Matt From ignaziocassano at gmail.com Tue Dec 18 05:28:51 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Tue, 18 Dec 2018 06:28:51 +0100 Subject: queens heat db deadlock In-Reply-To: References: <38bae882-b4ac-4b55-5345-e27edbd582f3@redhat.com> Message-ID: Yes, I tried on yesterday and this workaround solved. Thanks Ignazio Il giorno Lun 17 Dic 2018 20:38 Joe Topjian ha scritto: > Hi Ignazio, > > Do you currently have HAProxy configured to route requests to multiple > MariaDB nodes? If so, as a workaround, try doing an active/backup > configuration where all but 1 node is configured as an HAProxy "backup". > > Thanks, > Joe > > > > On Sun, Dec 16, 2018 at 10:46 PM Ignazio Cassano > wrote: > >> Hello Zane, it happens also when I create a magnum cluster . >> My mariadb cluster is behind haproxy. >> Do you need any other info? >> Thanks >> Ignazio >> >> >> Il giorno Lun 17 Dic 2018 00:28 Zane Bitter ha >> scritto: >> >>> On 14/12/18 4:06 AM, Ignazio Cassano wrote: >>> > Hi All, >>> > I installed queens on centos 7. >>> > Heat seems to work fine with templates I wrote but when I create >>> magnum >>> > cluster >>> > I often face with db deadlock in heat-engine log: >>> >>> The stacktrace below is in stack delete, so do you mean that the problem >>> occurs when deleting a Magnum cluster, or can it occur any time with a >>> magnum cluster? >>> >>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource Traceback >>> (most >>> > recent call last): >>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>> > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 918, >>> in >>> > _action_recorder >>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource yield >>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>> > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 2035, >>> > in delete >>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >>> *action_args) >>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>> > "/usr/lib/python2.7/site-packages/heat/engine/scheduler.py", line 346, >>> > in wrapper >>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource step = >>> > next(subtask) >>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>> > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 977, >>> in >>> > action_handler_task >>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource done = >>> > check(handler_data) >>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>> > >>> "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", >>> > line 587, in check_delete_complete >>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource return >>> > self._check_status_complete(self.DELETE) >>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>> > >>> "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", >>> > line 454, in _check_status_complete >>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >>> action=action) >>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >>> > ResourceFailure: resources[0]: (pymysql.err.InternalError) (1213, >>> > u'Deadlock found when trying to get lock; try restarting transaction') >>> > (Background on this error at: http://sqlalche.me/e/2j85) >>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >>> > 2018-12-13 11:48:46.030 89597 INFO heat.engine.stack >>> > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] >>> > Stack DELETE FAILED >>> > (swarm-clustergp27-ebhsalhb4bop-swarm_primary_master-tzgkh3ncmymw): >>> > Resource DELETE failed: resources[0]: (pymysql.err.InternalError) >>> (1213, >>> > u'Deadlock found when trying to get lock; try restarting transaction') >>> > (Background on this error at: http://sqlalche.me/e/2j85) >>> > 2018-12-13 11:48:46.844 89595 INFO heat.engine.resource >>> > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] >>> > DELETE: ResourceGroup "swarm_primary_master" >>> > [6984db3c-3ac1-4afc-901f-21b3e7f230a7] Stack >>> > "swarm-clustergp27-ebhsalhb4bop" [b43256fa-52e2-4613-ac15-63fd9340a8be] >>> > >>> > >>> > I read this issue was solved in heat version 10 but seems not. >>> >>> The patch for bug 1732969, which is in Queens, is probably the fix >>> you're referring to: https://review.openstack.org/#/c/521170/1 >>> >>> The traceback in that bug included the SQL statement that was failing. >>> I'm not sure if that isn't included in your traceback because SQLAlchemy >>> didn't report it, or if it's because that traceback is actually from the >>> parent stack. If you have a traceback from the original failure in the >>> child stack that would be useful. If there's a way to turn on more >>> detailed reporting of errors in SQLAlchemy that would also be useful. >>> >>> Since this is a delete, it's possible that we need a retry-on-deadlock >>> on the resource_delete() function also (though resource_update() is >>> actually used more during a delete to update the status). >>> >>> - ZB >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at bakeyournoodle.com Tue Dec 18 05:44:14 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Tue, 18 Dec 2018 16:44:14 +1100 Subject: [loci] Release management for LOCI In-Reply-To: References: <3855B170-6E38-4DB9-A91C-9389D16D387F@openstack.org> <64a34fd9-d31b-5d7d-ae94-053d9bdebbad@openstack.org> Message-ID: <20181218054413.GG6373@thor.bakeyournoodle.com> On Thu, Dec 13, 2018 at 09:43:37AM -0800, Chris Hoge wrote: > There is a need for us to work out whether Loci is even appropriate for > stable branch development. Over the last week or so the CentOS libvirt > update has broken all stable branch builds as it introduced an > incompatibility between the stable upper contraints of python-libvirt and > libvirt. Yup, as we've seen on https://review.openstack.org/#/c/622262 this is a common thing and happens with every CentOS minor release. We're working the update to make sure we don't cause more breakage as we try to fix this thing. > libvirt. If we start running stable builds, it might provide a useful > gate signal for when stable source builds break against upstream > distributions. It's something for the Loci team to think about as we > work through refactoring our gate jobs. That's interesting idea. Happy to discuss how we can do that in a way that makes sense for each project. How long does LOCI build take? 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 nick at stackhpc.com Tue Dec 18 08:05:14 2018 From: nick at stackhpc.com (Nick Jones) Date: Tue, 18 Dec 2018 08:05:14 +0000 Subject: [publiccloud]Choice of deployment tools In-Reply-To: References: <2cd80ff44dad46ed8f2f93b1c9578fda@AUSX13MPS308.AMER.DELL.COM> Message-ID: <2D3117DF-945A-4A51-9498-93F0E72A8A65@stackhpc.com> I’ve previously bootstrapped a public cloud of a similar size using Foreman and Puppet. However, that was over five years ago - if I was doing it again today I’d go with Kolla-Ansible. Point taken regarding the documentation, but if you can make your way onto Freenode you’ll find the folks in #openstack-kolla a very helpful bunch. As an simpler alternative to Triple-O, I’d also recommend you take a look at Kayobe: https://kayobe.readthedocs.io/en/latest/ or for a brief introduction: https://www.slideshare.net/MarkGoddard2/to-kayobe-or-not-to-kayobe Again, if you’re on Freenode then give us a shout in #openstack-kayobe Good luck! -- -Nick > On 17 Dec 2018, at 18:41, Cody wrote: > > Hi Melvin and Arkady, > > Thank you for the replies. > > I have been using TripleO on a small scale (10~20 nodes per > deployment) and it worked well. That said, I am not sure what capacity > it is designed for and whether it is still suitable to go beyond 2~300 > nodes. > > @Melvin: I attempted to try Kolla-Ansible and OpenStack-Ansible, but > failed to find documentations that provide coverages as detail as > TripleO's. Do you happen to know any resources or books on the > subjects for me to work on? > > @Arkady: May I ask if you used a Spine/Leaf network topology (i.e. > using a fully meshed layer 3 network above ToR) to deploy the 3 racks? > > Thank you to all! > > Best regards, > Cody > > On Mon, Dec 17, 2018 at 1:12 PM wrote: >> >> We had done TripleO deployment with 3 racks several times and it worked fined. >> >> >> >> From: Melvin Hillsman [mailto:mrhillsman at gmail.com] >> Sent: Monday, December 17, 2018 11:02 AM >> To: Cody >> Cc: openstack-operators at lists.openstack.org >> Subject: Re: [publiccloud]Choice of deployment tools >> >> >> >> [EXTERNAL EMAIL] >> >> Personally I have found openstack-ansible to be robust and very useful for a production environment. Not only the tool itself but also the help offered by those whose develop and use it. There is a bit of a learning curve however. At the end of the day I think the best solution is the one that works for you and if you have a chance you should try each one to see which is most suitable. I have not tried TripleO, Airship in a bottle did not work out the box, Kolla-Ansible is useful also but gave me fits troubleshooting, and OpenStack-Ansible I mentioned the learning curve. I do not deal with a lot of manual deploying these days but if I was spinning up a public cloud personally I would roll with OpenStack-Ansible >> >> >> >> On Mon, Dec 17, 2018, 10:47 AM Cody > >> Hello stackers, >> >> What deployment tools would be of your choice for deploying a public >> IaaS with an initial size of 200~300 nodes? Would TripleO be suitable >> for this cluster size? >> >> Thank you very much. Wish you all a happy holiday season! >> >> Best regards, >> Cody > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.rydberg at citynetwork.eu Tue Dec 18 08:13:18 2018 From: tobias.rydberg at citynetwork.eu (Tobias Rydberg) Date: Tue, 18 Dec 2018 09:13:18 +0100 Subject: [publiccloud]Choice of deployment tools In-Reply-To: <2D3117DF-945A-4A51-9498-93F0E72A8A65@stackhpc.com> References: <2cd80ff44dad46ed8f2f93b1c9578fda@AUSX13MPS308.AMER.DELL.COM> <2D3117DF-945A-4A51-9498-93F0E72A8A65@stackhpc.com> Message-ID: <13ee20eb-2201-e862-cd24-03e30c192e22@citynetwork.eu> OpenStack Ansible is my recommendation, but haven't tried Tripple-O just to have that said. We've found the documentation (standard ops docs on o.o) pretty good, and that together with OpenStack Ansible team that are super helpful it's been working great. Cheers, Tobias 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 On 2018-12-18 09:05, Nick Jones wrote: > I’ve previously bootstrapped a public cloud of a similar size using > Foreman and Puppet.  However, that was over five years ago - if I was > doing it again today I’d go with Kolla-Ansible.  Point taken regarding > the documentation, but if you can make your way onto Freenode you’ll > find the folks in #openstack-kolla a very helpful bunch. > > As an simpler alternative to Triple-O, I’d also recommend you take a > look at Kayobe: https://kayobe.readthedocs.io/en/latest/ or for a > brief introduction: > https://www.slideshare.net/MarkGoddard2/to-kayobe-or-not-to-kayobe > > Again, if you’re on Freenode then give us a shout in #openstack-kayobe > > Good luck! > > -- > > -Nick > >> On 17 Dec 2018, at 18:41, Cody > > wrote: >> >> Hi Melvin and Arkady, >> >> Thank you for the replies. >> >> I have been using TripleO on a small scale (10~20 nodes per >> deployment) and it worked well. That said, I am not sure what capacity >> it is designed for and whether it is still suitable to go beyond 2~300 >> nodes. >> >> @Melvin: I attempted to try Kolla-Ansible and OpenStack-Ansible, but >> failed to find documentations that provide coverages as detail as >> TripleO's. Do you happen to know any resources or books on the >> subjects for me to work on? >> >> @Arkady: May I ask if you used a Spine/Leaf network topology (i.e. >> using a fully meshed layer 3 network above ToR) to deploy the 3 racks? >> >> Thank you to all! >> >> Best regards, >> Cody >> >> On Mon, Dec 17, 2018 at 1:12 PM > > wrote: >>> >>> We had done TripleO deployment with 3 racks several times and it >>> worked fined. >>> >>> >>> >>> From: Melvin Hillsman [mailto:mrhillsman at gmail.com] >>> Sent: Monday, December 17, 2018 11:02 AM >>> To: Cody >>> Cc: openstack-operators at lists.openstack.org >>> >>> Subject: Re: [publiccloud]Choice of deployment tools >>> >>> >>> >>> [EXTERNAL EMAIL] >>> >>> Personally I have found openstack-ansible to be robust and very >>> useful for a production environment. Not only the tool itself but >>> also the help offered by those whose develop and use it. There is a >>> bit of a learning curve however. At the end of the day I think the >>> best solution is the one that works for you and if you have a chance >>> you should try each one to see which is most suitable. I have not >>> tried TripleO, Airship in a bottle did not work out the box, >>> Kolla-Ansible is useful also but gave me fits troubleshooting, and >>> OpenStack-Ansible I mentioned the learning curve. I do not deal with >>> a lot of manual deploying these days but if I was spinning up a >>> public cloud personally I would roll with OpenStack-Ansible >>> >>> >>> >>> On Mon, Dec 17, 2018, 10:47 AM Cody >> wrote: >>> >>> Hello stackers, >>> >>> What deployment tools would be of your choice for deploying a public >>> IaaS with an initial size of 200~300 nodes? Would TripleO be suitable >>> for this cluster size? >>> >>> Thank you very much. Wish you all a happy holiday season! >>> >>> Best regards, >>> Cody >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yongli.he at intel.com Tue Dec 18 08:20:45 2018 From: yongli.he at intel.com (yonglihe) Date: Tue, 18 Dec 2018 16:20:45 +0800 Subject: [nova] implementation options for nova spec: show-server-numa-topology Message-ID: Hi, guys This spec needs input and discuss for move on. Currently the spec is under reviewing: https://review.openstack.org/#/c/612256/8 Plus with POC code: https://review.openstack.org/#/c/621476/3 and related stein PTG discuss: https://etherpad.openstack.org/p/nova-ptg-stein start from line 897 NUMA topology had lots of information to expose, for saving you time to jumping into to the spec, the information need to return include NUMA related like: numa_node,cpu_pinning,cpu_thread_policy,cpuset,siblings, mem,pagesize,sockets,cores, threads, and PCI device's information. Base on IRC's discuss, we may have 3 options about how to deal with those blobs: 1) include those directly in the server response details, like the released POC does: https://review.openstack.org/#/c/621476/3 2) add a new sub-resource endpoint to servers, most likely use key word 'topology' then: "GET /servers/{server_id}/topology" returns the NUMA information for one server. 3) put the NUMA info under existing 'diagnostics' API. "GET /servers/{server_id}/diagnostics" this is admin only API, normal user loss the possible to check their topology. when the information put into diagnostics, they will be look like: {    ....    "numa_topology": {       cells  [                {                     "numa_node" : 3                     "cpu_pinning": {0:5, 1:6},                     "cpu_thread_policy": "prefer",                     "cpuset": [0,1,2,3],                     "siblings": [[0,1],[2,3]],                     "mem": 1024,                     "pagesize": 4096,                     "sockets": 0,                     "cores": 2,                      "threads": 2,                  },              ...            ] # cells     }     "emulator_threads_policy": "share"     "pci_devices": [         {                 "address":"00:1a.0",                 "type": "VF",                 "vendor": "8086",                 "product": "1526"         },     ]  } Regards Yongli He From gmann at ghanshyammann.com Tue Dec 18 09:04:50 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 18 Dec 2018 18:04:50 +0900 Subject: [dev] [tc][all] TC office hours is started now on #openstack-tc Message-ID: <167c08f842d.1267db0af58986.2722307368190907736@ghanshyammann.com> Hello everyone, 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. - gmann & TC From andre at florath.net Tue Dec 18 10:07:43 2018 From: andre at florath.net (Andre Florath) Date: Tue, 18 Dec 2018 11:07:43 +0100 Subject: [glance] (Silly) question about container_format and disk_format Message-ID: Hello! I do not completely understand the parameters 'container_format' and 'disk_format' as described in [1]. The documentation always uses 'the format' but IMHO there might be two formats involved. Are those formats either (A) the formats of the image file that is passed in. Like (from the official documentation [2]) $ openstack image create --disk-format qcow2 --container-format bare \ --public --file ./centos63.qcow2 centos63-image qcow2 / bare are the formats of the passed in image. or (B) the formats that are used internally to store the image Like $ openstack image create --disk-format vmdk --container-format ova \ --public --file ./centos63.qcow2 centos63-image vmdk / ova are formats that are used internally in OpenStack glance to store the image. In this case there must be an auto-detection of the image file format that is passed in and an automatic conversion into the new format. Kind regards Andre [1] https://developer.openstack.org/api-ref/image/v2/index.html?expanded=create-image-detail#create-image [2] https://docs.openstack.org/glance/pike/admin/manage-images.html From ignaziocassano at gmail.com Tue Dec 18 11:03:12 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Tue, 18 Dec 2018 12:03:12 +0100 Subject: Instance Unable to connect to Data/Management Network In-Reply-To: References: Message-ID: Hello Zufar, on yesterday I connected to irc #openstack-containers and they helped me a log. Regards Ignazio Il giorno Lun 17 Dic 2018 12:56 Zufar Dhiyaulhaq ha scritto: > Hi, I have OpenStack cluster with this following network environment. > > Global Configuration : > > Data & Management Network : 10.60.60.0/24 > External Network: 10.61.61.0/24 > > - All my endpoint is created in the Data & Management Network > - Instance get floating IP from External Network > > IP Address Allocation : > > Controller: 10.60.60.10 | 10.61.61.10 > Compute0: 10.60.60.20 | 10.61.61.20 > Compute1: 10.60.60.30 | 10.61.61.30 > Floating IP range : 10.61.61.100 - 10.61.61.200 > > My problem is the Instance cannot connect (ping, ssh, all connection) into > the data/management network. I am running a magnum cluster but the instance > needs to communicate with the endpoint. > > How to allow an Instance to connect to the data/management network? > > Best Regards, > Zufar Dhiyaulhaq > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdent+os at anticdent.org Tue Dec 18 11:31:04 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Tue, 18 Dec 2018 11:31:04 +0000 (GMT) Subject: [tc] Adapting office hours schedule to demand In-Reply-To: <1167de33-6942-13de-67e0-c86756deab25@redhat.com> References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> <1167de33-6942-13de-67e0-c86756deab25@redhat.com> Message-ID: On Tue, 18 Dec 2018, Zane Bitter wrote: This is such a great message that I feel obliged to respond, even though I haven't got much to add. But I will anyway, because I love email. > Of those options I think I have to vote for 1. The 0100 Wednesday is > (temporarily) the only one I can actually attend, so I'm in favour of keeping > it. I'm also deeply sceptical that having fewer office hours will boost > interest. Agreed. > TBH I'm not actually sure I know what we are trying to achieve at this point. > When the TC started office hours it was as a more time-zone-friendly > replacement for the weekly meeting. And the weekly meeting was mainly used > for discussion amongst the TC members and those folks who consistently follow > the TC's activity (many of whom are hopefully future TC candidates - the fact > that largely only folks from certain time zones were joining this group was > the problematic part of meetings to my mind). However, recently we've been > saying that the purpose of office hours is to bring in folks who aren't part > of that group to ask questions, and that the folks who are in the group > should actively avoid discussion in order to not discourage them. Then we are > surprised when things are quiet. I believe where we went wrong was thinking that people want us to answer questions. I'm sure there's some desire for that, but I suspect there are plenty of other people who want us to _do stuff_, some of which is hard stuff that requires the big talks and major efforts that come about from reaching consensus through fairly casual conversation. > (A more cynical person than I might suggest that going searching for trivial > issues that we can 'solve' by fiat offers a higher dopamine-to-time-spent > ratio than working together as a team to do... anything at all, and that this > may explain some of its popularity.) Dopamine Ho! > IMHO our goal should be - like every other team's - to grow the group of > people around the TC who form the 'governance team' for which the TC members > are effectively the core reviewers, and from which we expect to find our next > generation of TC members. While doing that, we must try to ensure that we're > not structurally limiting the composition of the group by longitude. But I > don't think we'll get there by trying to be quiet so they can speak up - > we'll get there by being present and talking about interesting stuff that > people want to join in on. If there's a problem with casual contributors > making themselves heard, provide them with a way to get their topic on an > informal agenda (or encourage them to begin on the mailing list) and make > sure it gets raised during office hours so they are not drowned out. Yes. "Talking about interesting stuff" seems to have tailed off a lot lately. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From doug at stackhpc.com Tue Dec 18 12:23:25 2018 From: doug at stackhpc.com (Doug Szumski) Date: Tue, 18 Dec 2018 12:23:25 +0000 Subject: [KOLLA][MONASCA] monasca containers not running In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017BAF995F@MXDB2.ad.garvan.unsw.edu.au> References: <9D8A2486E35F0941A60430473E29F15B017BAF995F@MXDB2.ad.garvan.unsw.edu.au> Message-ID: Thanks for giving it a go Manuel - replies inline. On 17/12/2018 23:54, Manuel Sopena Ballesteros wrote: > > Dear Openstack and Kolla community, > > I am trying to deploy monasca using kolla-ansible 7.0.0 and realised a > couple of containers are not working > Monasca is supported in Stein. Only partial support is available in Rocky. > Container monasca_log_persister > > See: 'bin/logstash --help' > > + sudo -E kolla_set_configs > > INFO:__main__:Loading config file at > /var/lib/kolla/config_files/config.json > > INFO:__main__:Validating config file > > INFO:__main__:Kolla config strategy set to: COPY_ALWAYS > > INFO:__main__:Copying service configuration files > > INFO:__main__:Deleting /etc/logstash/conf.d/log-persister.conf > > INFO:__main__:Copying /var/lib/kolla/config_files/log-persister.conf > to /etc/logstash/conf.d/log-persister.conf > > INFO:__main__:Setting permission for > /etc/logstash/conf.d/log-persister.conf > > INFO:__main__:Deleting /etc/logstash/elasticsearch-template.json > > INFO:__main__:Copying > /var/lib/kolla/config_files/elasticsearch-template.json to > /etc/logstash/elasticsearch-template.json > > INFO:__main__:Setting permission for > /etc/logstash/elasticsearch-template.json > > INFO:__main__:Writing out command to execute > > INFO:__main__:Setting permission for /var/log/kolla/monasca > > INFO:__main__:Setting permission for > /var/log/kolla/monasca/monasca-api-error.log > > INFO:__main__:Setting permission for > /var/log/kolla/monasca/monasca-api-access.log > > INFO:__main__:Setting permission for > /var/log/kolla/monasca/monasca-log-api-error.log > > INFO:__main__:Setting permission for > /var/log/kolla/monasca/monasca-log-api-access.log > > ++ cat /run_command > > + CMD='/usr/share/logstash/bin/logstash --log-in-json --log > /var/log/kolla/monasca/monasca-log-persister.log -f > /etc/logstash/conf.d/log-persister.conf' > > + ARGS= > > + [[ ! -n '' ]] > > + . kolla_extend_start > > ++ [[ ! -d /var/log/kolla/logstash ]] > > +++ stat -c %a /var/log/kolla/logstash > > ++ [[ 755 != \7\5\5 ]] > > + echo 'Running command: '\''/usr/share/logstash/bin/logstash > --log-in-json --log /var/log/kolla/monasca/monasca-log-persister.log > -f /etc/logstash/conf.d/log-persister.conf'\''' > > Running command: '/usr/share/logstash/bin/logstash --log-in-json --log > /var/log/kolla/monasca/monasca-log-persister.log -f > /etc/logstash/conf.d/log-persister.conf' > > + exec /usr/share/logstash/bin/logstash --log-in-json --log > /var/log/kolla/monasca/monasca-log-persister.log -f > /etc/logstash/conf.d/log-persister.conf > > WARNING: Could not find logstash.yml which is typically located in > $LS_HOME/config or /etc/logstash. You can specify the path using > --path.settings. Continuing using the defaults > > ERROR: Unrecognised option '--log-in-json' > This Error is because the Logstash version is too recent in Rocky. In Stein, it was downgraded for Monasca. Please see this commit for more details: https://github.com/openstack/kolla/commit/0cf2c5345029b981c3302e21d25e90d0c3239dd7 > Container monasca_log_transformer > > See: 'bin/logstash --help' > > + sudo -E kolla_set_configs > > INFO:__main__:Loading config file at > /var/lib/kolla/config_files/config.json > > INFO:__main__:Validating config file > > INFO:__main__:Kolla config strategy set to: COPY_ALWAYS > > INFO:__main__:Copying service configuration files > > INFO:__main__:Deleting /etc/logstash/conf.d/log-transformer.conf > > INFO:__main__:Copying /var/lib/kolla/config_files/log-transformer.conf > to /etc/logstash/conf.d/log-transformer.conf > > INFO:__main__:Setting permission for > /etc/logstash/conf.d/log-transformer.conf > > INFO:__main__:Writing out command to execute > > INFO:__main__:Setting permission for /var/log/kolla/logstash > > ++ cat /run_command > > + CMD='/usr/share/logstash/bin/logstash --log-in-json --log > /var/log/kolla/logstash/monasca-log-transformer.log -f > /etc/logstash/conf.d/log-transformer.conf' > > + ARGS= > > + [[ ! -n '' ]] > > + . kolla_extend_start > > ++ [[ ! -d /var/log/kolla/logstash ]] > > +++ stat -c %a /var/log/kolla/logstash > > ++ [[ 755 != \7\5\5 ]] > > + echo 'Running command: '\''/usr/share/logstash/bin/logstash > --log-in-json --log > /var/log/kolla/logstash/monasca-log-transformer.log -f > /etc/logstash/conf.d/log-transformer.conf'\''' > > Running command: '/usr/share/logstash/bin/logstash --log-in-json --log > /var/log/kolla/logstash/monasca-log-transformer.log -f > /etc/logstash/conf.d/log-transformer.conf' > > + exec /usr/share/logstash/bin/logstash --log-in-json --log > /var/log/kolla/logstash/monasca-log-transformer.log -f > /etc/logstash/conf.d/log-transformer.conf > > WARNING: Could not find logstash.yml which is typically located in > $LS_HOME/config or /etc/logstash. You can specify the path using > --path.settings. Continuing using the defaults > > ERROR: Unrecognised option '--log-in-json' > > Any thoughts? > > 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. From jaypipes at gmail.com Tue Dec 18 12:48:08 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Tue, 18 Dec 2018 07:48:08 -0500 Subject: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata" In-Reply-To: <058f5de0-9ebb-3cda-9216-5554fc229433@gmail.com> References: <8557b741-d4f5-cdfd-a244-65b47a1c3445@gmail.com> <058f5de0-9ebb-3cda-9216-5554fc229433@gmail.com> Message-ID: <0b4dd02e-92f7-e59f-82f7-951b5be45027@gmail.com> On 12/17/2018 06:15 PM, Matt Riedemann wrote: > On 12/12/2018 1:18 PM, Matt Riedemann wrote: >> Coming back on this thread [1], I've got a partial fix up which I'm >> hoping will help: >> >> https://review.openstack.org/#/c/624778/ >> >> That will avoid joining on some other tables depending on your >> configuration. It would be great if you could see if that helps >> resolve your issue. I think you just reverted >> https://review.openstack.org/#/c/276861/ as a workaround but it would >> be good to know if a more permanent fix (mine) gets you similar, or at >> least satisfactory, results. >> >> [1] >> http://lists.openstack.org/pipermail/openstack-dev/2018-October/thread.html#135941 >> > > I have abandoned that change since it turns out that we need to join on > the instance_system_metadata table to get the instance password which is > retrieved from a base metadata request. Otherwise you can see the > failures here [1]. > > So either we need to: > > * Optimize the instance get DB query and joins we do. Dan was looking at > this but it was non-trivial. > > * Reconsider how we store the instance password so it's not in the > instance_system_metadata table. > > Or deployments can aggressively cache the metadata API responses (or > scale out the number of metadata API workers) to try and deal with load. > > [1] > http://logs.openstack.org/78/624778/1/check/tempest-full/8d3c124/controller/logs/screen-n-api-meta.txt.gz#_Dec_13_08_45_56_602421 Well, technically, we *could* do all three of the above, right? :) It's not an either/or situation, AFAIU. From looking at your patches, I think the long-term solution to this would be to stop storing the instance password in the instance_system_metadata table, but from looking into those code paths (eww...) I realize that would be a huge chunk of tech debt refactoring. Maybe something to line up for early Train? Best, -jay From cjeanner at redhat.com Tue Dec 18 13:47:54 2018 From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=) Date: Tue, 18 Dec 2018 14:47:54 +0100 Subject: [TripleO] flattening tripleo-heat-templates: what about pacemaker? Message-ID: <9c97af56-bc1c-f2ac-f19f-983cf18192a2@redhat.com> Hello folks, While working on the service flattening in t-h-t, I have some question regarding the pacemaker things. If we take rabbitmq: - we have rabbitmq things in docker/services - we have rabbitmq things in puppet/services - we have rabbitmq things in docker/services/pacemaker - we have rabbitmq things in puppet/services/pacemaker If the plain services are easy to flatten, the pacemaker part is more annoying, at least on the naming/location. I see the following possibilities: - create a deployment/pacemaker and move all pacemaker-related things in there - name files something like rabbitmq-pacemaker-foo.yaml and push them in deployment/rabbitmq Both look valid. And both might have their downsides. Any advice, idea, feeling on that? Also, regarding the workflow: do we do that flattening in one, or two passes? i.e. we can move all rabbitmq related code at once, or only the plain service, and do a second patch for the pacemaker things. Here again, both look valid, but I'm more in the "2 passes" idea. So... yeah, I'd like to get some feedback on that in order to do things right, and avoid monkey-patching because paths/naming aren't good ;). Thanks! Cheers, C. -- Cédric Jeanneret Software Engineer DFG:DF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From alfredo.deluca at gmail.com Tue Dec 18 13:51:52 2018 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Tue, 18 Dec 2018 14:51:52 +0100 Subject: Openstack Magnum In-Reply-To: References: Message-ID: Hi Paul, Spyros et all. I looked up on some bugs and info and even implementing them still got the same errors. I installed magnum client and when I try to do any command I get the same error message: # magnum cluster-list *ERROR: 'NoneType' object has no attribute 'replace' (HTTP 500) (Request-ID: req-20c34d30-3bc9-4757-8aa7-3b4ecd35940e)* I found this bug but it says We do currently not support www_authentication_uri at all, which is the new standard, as auth_uri has long been deprecated. https://review.openstack.org/#/c/614082/ So I am confused what to do. Any suggestions? On Mon, Dec 17, 2018 at 10:29 AM Ignazio Cassano wrote: > I am on #openstack-containers irc. > They help us > > > Il giorno lun 17 dic 2018 alle ore 09:53 Alfredo De Luca < > alfredo.deluca at gmail.com> ha scritto: > >> Hi Ignazio. Any clue. Not sure why it doesn't work. >> >> anyone? >> >> >> >> On Mon, Dec 17, 2018 at 6:48 AM Ignazio Cassano >> wrote: >> >>> Thanks . >>> >>> Il giorno Dom 16 Dic 2018 22:51 Alfredo De Luca < >>> alfredo.deluca at gmail.com> ha scritto: >>> >>>> Hi Ignazio. I am actually on Stein.... >>>> >>>> >>>> On Sun, Dec 16, 2018 at 6:52 PM Ignazio Cassano < >>>> ignaziocassano at gmail.com> wrote: >>>> >>>>> Hello Luca, I git same issue on queens. >>>>> Are you in rocky? >>>>> Regards >>>>> Ignazio >>>>> >>>>> >>>>> Il giorno Dom 16 Dic 2018 16:57 Alfredo De Luca < >>>>> alfredo.deluca at gmail.com> ha scritto: >>>>> >>>>>> Hi all. >>>>>> Just installed *openstack* and *magnum* with *ansible-openstack AIO.* >>>>>> >>>>>> All works well except magnum itself. When I click on the dashboard on* >>>>>> Container Infra *then C*lusters or clusters templates *I get the >>>>>> following errors: >>>>>> *Error: *Unable to retrieve the clusters. >>>>>> *Error: *Unable to retrieve the stats. >>>>>> >>>>>> - Not sure why. >>>>>> >>>>>> >>>>>> Any clue? >>>>>> >>>>>> Cheers >>>>>> >>>>>> -- >>>>>> *Alfredo* >>>>>> >>>>>> >>>> >>>> -- >>>> *Alfredo* >>>> >>>> >> >> -- >> *Alfredo* >> >> -- *Alfredo* -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Tue Dec 18 13:52:41 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Tue, 18 Dec 2018 08:52:41 -0500 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: <1167de33-6942-13de-67e0-c86756deab25@redhat.com> References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> <1167de33-6942-13de-67e0-c86756deab25@redhat.com> Message-ID: Zane Bitter writes: > Is there actually any reason to think that there is a problematic level > of under-reporting of TC-escalation-worthy issues? I can't think an a > priori reason to expect that in a healthy project there should be large > numbers of issues escalated to the TC. And despite focusing our meeting > strategy around that and conducting a massively time-consuming campaign > of reaching out to teams individually via the health checks, I'm not > seeing any empirical evidence of it either. Meanwhile there's ample > evidence that we need more time to discuss things as a group - just > witness the difficulty of getting through a monthly meeting in < 1 hour > by trying to stick to purely procedural stuff. > > (A more cynical person than I might suggest that going searching for > trivial issues that we can 'solve' by fiat offers a higher > dopamine-to-time-spent ratio than working together as a team to do... > anything at all, and that this may explain some of its popularity.) I suggested we start doing the health checks more formally after the 2nd Vancouver summit because during that week we did discover issues that 2 teams had been dealing with for at least a cycle, if not longer. The teams involved never escalated the problems, and the situations had devolved into lingering anger and resentment. In one case we had a project purposefully being misconfigured in CI in a misguided attempt to "force" the team to comply with some policy by making it impossible for them to test a feature. Once we found out about the problems, we had them resolved within the week. So, I don't think it's too much to ask of TC members to actively seek out team leads and try to establish a line of communication to avoid ending up in that situation again. I consider it a preventive measure. -- Doug From cristian.calin at orange.com Tue Dec 18 14:06:05 2018 From: cristian.calin at orange.com (cristian.calin at orange.com) Date: Tue, 18 Dec 2018 14:06:05 +0000 Subject: [keystone] Re: Meaning of role name: auditor versus reader In-Reply-To: References: <6591_1544710745_5C126A59_6591_247_1_046251b454084202978c37e1ab42e152@orange.com> <1544711127.2243570.1608188192.0349FB20@webmail.messagingengine.com> Message-ID: <19889_1545141966_5C18FECE_19889_375_1_6724558309ff45e09af3223c7f412af6@orange.com> Thanks for pointing out that this is already supported. Indeed this single reader role (while scoped appropriately) covers the needs I was thinking about. I missed the fact that we could have system and domain scoping. From: Lance Bragstad [mailto:lbragstad at gmail.com] Sent: Thursday, December 13, 2018 7:06 PM To: openstack-discuss at lists.openstack.org Subject: Re: [keystone] Re: Meaning of role name: auditor versus reader I was under the assumption that the ``reader`` role wouldn't be specific to the actions of either operators or regular end users. I thought the intention was to leverage the scope of the assignment to answer that question for us. For example: Let's assume Sarah is granted the reader role on the system (``openstack role add --user sarah --system all reader``). In theory, she has the ability to list system-specific resources, like endpoints, services, domains, or compute hosts. She can perform audits on the deployment infrastructure. If Chris has the reader role on a project (``openstack role add --user chris --project foobar reader``), he should theoretically have the ability to list instances and volumes within the project. Even though Chris has the reader role, he doesn't have the ability to list system-specific resources, because he doesn't have the system role assignment Sarah has. We can expand the example to include domain support, too. If Jane has a reader role on a domain (``openstack role add --user jane --domain baz reader``), she theoretically has the ability to view things owned by that domain, like users, groups, or projects whose domain ID is ``baz``. The same role is used in all three cases, but the target in each user's role assignment is important, too. This might be easier to see in practice between system [0], domain] [1], and project [2] readers all using the ``reader`` role. In my opinion, this gives us more bang for our buck as far as role definitions are concerned. We aren't worried about defining system-reader, domain-reader, and project-reader roles. Additionally, I cringe a little bit thinking about the custom policy required for those cases and the confusion operators might have when Jane gets the project-reader role assignment on a domain. [0] https://review.openstack.org/#/c/619329/3/keystone/tests/unit/protection/v3/test_endpoints.py at 31 [1] https://review.openstack.org/#/c/619332/4/keystone/tests/unit/protection/v3/test_endpoints.py at 131 [2] https://review.openstack.org/#/c/619281/5/keystone/tests/unit/protection/v3/test_endpoints.py,unified at 376 On Thu, Dec 13, 2018 at 8:27 AM Colleen Murphy > wrote: Tagging keystone On Thu, Dec 13, 2018, at 3:18 PM, cristian.calin at orange.com wrote: > As operators, we have a need for both cases and actually a 3rd one as > well which should be domain scoped. > I think the definition of reader should also include a scope (cloud- > wide, domain specific or project specific) so that we don’t need > different roles. > This might be a more fundamental change though as the scoping is static > today, I mean defined in the policy files/code. > > Cristian Calin > > From: Adam Young [mailto:ayoung at redhat.com] > Sent: Thursday, December 13, 2018 3:09 AM > To: List, OpenStack > Subject: Meaning of role name: auditor versus reader > > We've recently come to accept reader as one of the default roles. > However, one thing that is not clear to me is the intention: is this > designed to be the readonly set of operations that an admin can do, or > the read only set of operations that a member can do? > > Should we really have two read-only roles, one for each case? Perhaps > the admin-read-only should be called auditor, and then reader is for > member only operations? > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme > ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mcginnis at gmx.com Tue Dec 18 14:35:32 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Tue, 18 Dec 2018 08:35:32 -0600 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: <1167de33-6942-13de-67e0-c86756deab25@redhat.com> References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> <1167de33-6942-13de-67e0-c86756deab25@redhat.com> Message-ID: <20181218143531.GA12889@sm-workstation> > > When the TC started office hours it was as a more time-zone-friendly > replacement for the weekly meeting. I do agree with a lot of what you are saying Zane, but I feel I need to call out this statement. The office hours were never meant as a replacement for the weekly meeting. The weekly meeting was supposed to be replaced by more conversations on the ML and, to a lesser degree, by casual conversations throughtout the week on IRC. But the focus was on using the ML so that it was easier for folks in all timezones to be able to follow along and participate in those conversations. The office hours were intended to fill the need of having a time that we would know at least some majority of TC members would be around in case someone needed something. It was not a way to take one meeting hour and turn it into three fragmented ones. From doug at stackhpc.com Tue Dec 18 14:44:19 2018 From: doug at stackhpc.com (Doug Szumski) Date: Tue, 18 Dec 2018 14:44:19 +0000 Subject: can't login to a compute node deployed using ironic In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017BAF8E9F@MXDB2.ad.garvan.unsw.edu.au> References: <9D8A2486E35F0941A60430473E29F15B017BAF8E9F@MXDB2.ad.garvan.unsw.edu.au> Message-ID: On 13/12/2018 06:18, Manuel Sopena Ballesteros wrote: > > Dear Openstack user group, > > I am playing with Ironic and have a very stupid question… > > For some reason I can’t login to the server after deployment.  Server > status is ACTIVE and I am using the adminPass provided by openstack . > > The way I connect is through server console through the IPMI console > (not ssh). > The way it normally works is that cloud init copies a public key from a keypair that you specify when booting the instance to the node that your deploy. There aren't normally back door passwords in the deploy images, which is why you can't get in via the IPMI console. Try ssh :) > > [root at openstack-deployment ~]# openstack server create --image > 760f4076-4f2d-455b-89b5-6c1248148f70 --flavor my-baremetal-flavor > --network hpc demo1 > > +-------------------------------------+------------------------------------------------------------+ > > | Field                               | > Value                                                      | > > +-------------------------------------+------------------------------------------------------------+ > > | OS-DCF:diskConfig                   | > MANUAL                                                     | > > | OS-EXT-AZ:availability_zone | | > > | OS-EXT-SRV-ATTR:host                | > None                                                       | > > | OS-EXT-SRV-ATTR:hypervisor_hostname | None >                                              | > > | OS-EXT-SRV-ATTR:instance_name | | > > | OS-EXT-STS:power_state              | > NOSTATE                                                    | > > | OS-EXT-STS:task_state               | > scheduling                                                 | > > | OS-EXT-STS:vm_state                 | > building                                                   | > > | OS-SRV-USG:launched_at              | None >                                       | > > | OS-SRV-USG:terminated_at            | > None                                                       | > > | accessIPv4 | | > > | accessIPv6                         | | > > | addresses | | > > | adminPass                           | t3TAUNwTbuD5                >                                | > > | config_drive | | > > | created                             | > 2018-12-13T05:39:11Z                                       | > > | flavor                              | my-baremetal-flavor > (84abc368-1695-4387-998c-8b47da1a3a34) | > > | hostId | | > > | id                                  | > 5231e015-73e9-472f-bb84-bde9bf7e6989                       | > > | image                               | centos7.5-image > (760f4076-4f2d-455b-89b5-6c1248148f70)     | > > | key_name                            | > None                                                       | > > | name                                | > demo1                                                      | > > | progress                            | > 0                                                          | > > | project_id                          | > 0b3d8fd6015048e89f4372fb1534900b                           | > > | properties | | > > | security_groups                     | > name='default'                                             | > > | status                              | > BUILD                                                      | > > | updated                             | > 2018-12-13T05:39:12Z                                       | > > | user_id                             | > fd244f331bc34066b7a5fae72d518261                           | > > | volumes_attached | | > > +-------------------------------------+------------------------------------------------------------+ > > [root at openstack-deployment ~]# openstack server list > > +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ > > | ID                                   | Name  | Status | > Networks        | Image           | Flavor              | > > +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ > > | 5231e015-73e9-472f-bb84-bde9bf7e6989 | demo1 | ACTIVE | > hpc=10.0.32.119 | centos7.5-image | my-baremetal-flavor | > > | 9cc2369f-1951-4bec-bc8b-863fd6cc9983 | test  | ACTIVE | > hpc=10.0.32.116 | cirros          | m1.tiny             | > > +--------------------------------------+-------+--------+-----------------+-----------------+---------------------+ > > Any thoughts? > > *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. From dprince at redhat.com Tue Dec 18 14:59:24 2018 From: dprince at redhat.com (Dan Prince) Date: Tue, 18 Dec 2018 09:59:24 -0500 Subject: [TripleO] flattening tripleo-heat-templates: what about pacemaker? In-Reply-To: <9c97af56-bc1c-f2ac-f19f-983cf18192a2@redhat.com> References: <9c97af56-bc1c-f2ac-f19f-983cf18192a2@redhat.com> Message-ID: <93db2a00d0e739cc9832fb45809a755424176321.camel@redhat.com> On Tue, 2018-12-18 at 14:47 +0100, Cédric Jeanneret wrote: > Hello folks, > > While working on the service flattening in t-h-t, I have some > question > regarding the pacemaker things. > > If we take rabbitmq: > - we have rabbitmq things in docker/services > - we have rabbitmq things in puppet/services > - we have rabbitmq things in docker/services/pacemaker > - we have rabbitmq things in puppet/services/pacemaker > > If the plain services are easy to flatten, the pacemaker part is more > annoying, at least on the naming/location. > > I see the following possibilities: > - create a deployment/pacemaker and move all pacemaker-related things > in > there This was the old way. A directory for all the 'docker' stuff. A directory for all the 'puppet' stuff. It doesn't seem like people prefered this so we are re-organizing it by service now. There are pros and cons to both approaches I think. It largely comes down to preference. > > - name files something like rabbitmq-pacemaker-foo.yaml and push them > in deployment/rabbitmq I think this options seems reasonable and would seem to follow the convention are moving to in the deployments directory to split things out by service. You might call it rabbitmq-pacemaker-puppet.yaml for example. The convention is - - . Or something like that. > > Both look valid. And both might have their downsides. > Any advice, idea, feeling on that? > > Also, regarding the workflow: do we do that flattening in one, or two > passes? Flattening and moving files in the same patch leads to larger reviews. But it also saves CI reasources. For smaller services perhaps do them together. For services with multiple files perhaps consider splitting up the patchset somehow to make it smaller. Dan > i.e. we can move all rabbitmq related code at once, or only the plain > service, and do a second patch for the pacemaker things. > > Here again, both look valid, but I'm more in the "2 passes" idea. > > So... yeah, I'd like to get some feedback on that in order to do > things > right, and avoid monkey-patching because paths/naming aren't good ;). > > Thanks! > > Cheers, > > C. > > > > From hberaud at redhat.com Tue Dec 18 15:07:10 2018 From: hberaud at redhat.com (Herve Beraud) Date: Tue, 18 Dec 2018 16:07:10 +0100 Subject: [oslo][migrator] RFE Configuration mapping tool for upgrade - coordinate teams Message-ID: Hey teams, ## Summary The main goal of this thread is to coordinate teams to adopt the oslo realease migrator tools and raise prior on this topics. ## History During the openstack submit in 2017 at Sydney a team from the Fujitsu company propose a talk about how to make fast forward upgrade from an openstack release to an another, and present the state of art of the configuration migrator inside openstack and the tools availables to do that. This team describe that for now, we have oslo.config generator tool to show deprecated options in newer release but they are still lacking some mapping configurations. After that the same team propose oslo.config specifications to improve migrators. Where specifications was designed by the following reviews: - https://review.openstack.org/#/c/520043/ - https://review.openstack.org/#/c/526314/ - https://review.openstack.org/#/c/526261/ The main goal of the proposed changes in these specs is to handle configuration changes over releases: - https://specs.openstack.org/openstack/oslo-specs/specs/rocky/handle-config-changes.html These specifications describe that there should be some helper in oslo.config for automatically adopt new changes and help users manage their configuration files easily. Scenario: Below is the proposed workflow that users can perform on old system to generate new configuration for preparing upgrading to new release: +--------------+ Old configuration +--------> | (N-1 release) | Oslo | | Config +-------> New configuration Namespaces +--------> Migrator | (N release) | | +--------------+ Running on new environment Since these specifications was validated, some patches was submitted by the Fujitsu team to implement them: https://review.openstack.org/#/q/status:open+project:openstack/oslo.config+branch:master+topic:migrator Details: - handle config mapping changes ( https://review.openstack.org/526314 ) - update valid value in choice list for the opt ( https://review.openstack.org/603060 ) - update 'sample_default' instead of 'default' when migrating ( https://review.openstack.org/606211 ) - use difflib to report mismatches in migrator tests ( https://review.openstack.org/606210 ) - replace loop with dictionary lookup ( https://review.openstack.org/606209 ) - replace 'upgrade_value' with 'convert_on_upgrade' ( https://review.openstack.org/606207 ) Since these changes was proposed some peoples from the Fujitsu seems to left the company and also seems to abandon this topic. During the last oslo meeting I had added this topic to the meeting agenda to bring up this topic and to help us to move forward on it. http://eavesdrop.openstack.org/meetings/oslo/2018/oslo.2018-12-17-15.00.log.html http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000856.html ## Current state Some reviews was validated but some others need to be recovered due to the lack of response about the original authors. I've submit some patches on reviews to help us to move on it. I've made some reviews based on the last comments and based on the asked changes but now we need someone with an deeply knowledge on oslo.config to validate the works. ## Others aspects Some tools like puppet/ansible/chef etc... already in use in openstack can already handle migrators/upgrades and manage config changes. - Do we need to introduce an another tool like this one to do this job? - How many people are manually writing OpenStack configs in the first place? - Does it make sense to implement these changes? ## List of similar features on others projects - Tripleo provide a major release upgrade mechanisme ( https://docs.openstack.org/tripleo-docs/latest/upgrade/developer/upgrades/major_upgrade.html ) - Openstack-Ansible also provide release upgrade mechanisme ( https://docs.openstack.org/openstack-ansible/latest/admin/upgrades/major-upgrades.html ) - OpenStack fuel also propose specifications to upgrade configuration and release ( https://specs.openstack.org/openstack/fuel-specs/specs/7.0/upgrade-major-openstack-environment.html ) This wiki can be useful to obtain the big picture of the release upgrade management in openstack ( https://wiki.openstack.org/wiki/Upgrade-with-minimal-downtime ) I surely forgot some tools and alternatives, if you see something that can be added here do not hesitate to reply to add it. ## Conclusion I bring up this topic to open a debate so do not hesitate react on this topic by responding at this thread to help us to have a better big picture to make the best choice. Thanks folks. Best regards. -- 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 ssbarnea at redhat.com Tue Dec 18 15:13:10 2018 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Tue, 18 Dec 2018 15:13:10 +0000 Subject: Firefox context search text across openstack related websites like codesearch, logstash, launchpad Message-ID: <6A35BC0D-9ABC-4E36-8A58-189D3586CF3F@redhat.com> As many of us have to search for pieces of text on many places, like codesearch, logstash,.... I invested some time in making this possible with a right-click. Warning: requires Firefox extension. Details https://github.com/openstack/coats#context-search-for-firefox I hope it would make your life easier. PS. Improvements on the search engines definition files are welcomed, on Gerrit :) Cheers, Sorin Sbarnea -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Tue Dec 18 15:38:12 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 18 Dec 2018 15:38:12 +0000 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: <1167de33-6942-13de-67e0-c86756deab25@redhat.com> References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> <1167de33-6942-13de-67e0-c86756deab25@redhat.com> Message-ID: <20181218153811.7xm5ht54pbfmeo7k@yuggoth.org> On 2018-12-18 15:52:51 +1300 (+1300), Zane Bitter wrote: [...] > TBH I'm not actually sure I know what we are trying to achieve at > this point. When the TC started office hours it was as a more > time-zone-friendly replacement for the weekly meeting. And the > weekly meeting was mainly used for discussion amongst the TC > members and those folks who consistently follow the TC's activity > (many of whom are hopefully future TC candidates - the fact that > largely only folks from certain time zones were joining this group > was the problematic part of meetings to my mind). However, > recently we've been saying that the purpose of office hours is to > bring in folks who aren't part of that group to ask questions, and > that the folks who are in the group should actively avoid > discussion in order to not discourage them. Then we are surprised > when things are quiet. My interpretation of the resolution which created our office hours is actually entirely that. It describes[0] them as "a good time for non-TC members to interact with TC members" and "for folks from any timezone to drop in and ask questions." Review comments on Flavio's change[1] which added it, along with the ML thread[2] which kicked off the idea and the subsequent TC meetings[3][4][5] where we debated the topic all seem to back up that interpretation. A lot of it stemmed from disproportionate geographic and cultural diversity within the TC and other community leadership positions at that time, and seeking ways to get representatives involved from more parts of the World so they could better figure out how/why to become leaders themselves. > Is there actually any reason to think that there is a problematic > level of under-reporting of TC-escalation-worthy issues? I can't > think an a priori reason to expect that in a healthy project there > should be large numbers of issues escalated to the TC. And despite > focusing our meeting strategy around that and conducting a > massively time-consuming campaign of reaching out to teams > individually via the health checks, I'm not seeing any empirical > evidence of it either. As above, I don't think it's because we perceive a lack of escalation for matters the TC should be handling, but just generally about being more approachable and getting the community increasingly involved in what we do so that we're not seen as some elite and mystical (or out-of-touch) group of elders sending down decrees from on high. > Meanwhile there's ample evidence that we need more time to discuss > things as a group - just witness the difficulty of getting through > a monthly meeting in < 1 hour by trying to stick to purely > procedural stuff. [...] When we dropped formal meetings, the idea was that we were going to push all official TC discussion to the openstack-dev (now openstack-discuss) mailing list and into openstack/governance change reviews. It seems more like we've failed at doing that, if we have trouble making the newly reestablished meetings more than just a brief touchpoint to run through what discussions we're having in those more appropriate and accessible venues. Also, I don't personally think we've entirely failed at it, as we *aren't* having this particular discussion in IRC. ;) > IMHO our goal should be - like every other team's - to grow the > group of people around the TC who form the 'governance team' for > which the TC members are effectively the core reviewers, and from > which we expect to find our next generation of TC members. While > doing that, we must try to ensure that we're not structurally > limiting the composition of the group by longitude. But I don't > think we'll get there by trying to be quiet so they can speak up - > we'll get there by being present and talking about interesting > stuff that people want to join in on. If there's a problem with > casual contributors making themselves heard, provide them with a > way to get their topic on an informal agenda (or encourage them to > begin on the mailing list) and make sure it gets raised during > office hours so they are not drowned out. > > I might support rejigging the times and dropping to twice a week > if I thought that it meant a majority of the TC would show up each > time and discussions would actually happen (we had an etherpad of > topics at some point that I haven't seen in a long time). In that > case I would even join the 10pm session if necessary to > participate, though we should recognise that for folks from this > part of the world who *don't* have a formal role that's a massive > obstacle. I do basically agree with these thoughts/suggestions at least. For me, they fit just fine with why we started having office hours. Unlike some, I don't think that having casual discussion between TC members during IRC office hours is likely to be off-putting to people who are maybe a little shy or simply afraid of interrupting but want to engage us in conversation. I do however feel like trying to force more official discussions during office hours is an impediment, and we should be making sure those topics are being handled more asynchronously instead so that they're open to participation by a much wider audience. [0] https://governance.openstack.org/tc/resolutions/20170425-drop-tc-weekly-meetings.html#office-hours [1] https://review.openstack.org/459848 [2] http://lists.openstack.org/pipermail/openstack-dev/2017-April/115227.html [3] http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-04-25-20.00.log.html#l-385 [4] http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-05-02-20.01.log.html#l-23 [5] http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-05-16-20.01.log.html#l-316 -- 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 Arkady.Kanevsky at dell.com Tue Dec 18 15:45:31 2018 From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com) Date: Tue, 18 Dec 2018 15:45:31 +0000 Subject: [publiccloud]Choice of deployment tools In-Reply-To: References: <2cd80ff44dad46ed8f2f93b1c9578fda@AUSX13MPS308.AMER.DELL.COM> Message-ID: Cody, It is documented in https://www.dellemc.com/resources/en-us/asset/technical-guides-support-information/solutions/Dell_EMC_NFV_Ready_Bundle_for_Red_Hat_Multi_rack_Architecture_Guide.pdf Thanks, Arkady -----Original Message----- From: Cody [mailto:codeology.lab at gmail.com] Sent: Monday, December 17, 2018 12:41 PM To: Kanevsky, Arkady Cc: mrhillsman at gmail.com; openstack-operators at lists.openstack.org Subject: Re: [publiccloud]Choice of deployment tools [EXTERNAL EMAIL] Hi Melvin and Arkady, Thank you for the replies. I have been using TripleO on a small scale (10~20 nodes per deployment) and it worked well. That said, I am not sure what capacity it is designed for and whether it is still suitable to go beyond 2~300 nodes. @Melvin: I attempted to try Kolla-Ansible and OpenStack-Ansible, but failed to find documentations that provide coverages as detail as TripleO's. Do you happen to know any resources or books on the subjects for me to work on? @Arkady: May I ask if you used a Spine/Leaf network topology (i.e. using a fully meshed layer 3 network above ToR) to deploy the 3 racks? Thank you to all! Best regards, Cody On Mon, Dec 17, 2018 at 1:12 PM wrote: > > We had done TripleO deployment with 3 racks several times and it worked fined. > > > > From: Melvin Hillsman [mailto:mrhillsman at gmail.com] > Sent: Monday, December 17, 2018 11:02 AM > To: Cody > Cc: openstack-operators at lists.openstack.org > Subject: Re: [publiccloud]Choice of deployment tools > > > > [EXTERNAL EMAIL] > > Personally I have found openstack-ansible to be robust and very useful > for a production environment. Not only the tool itself but also the > help offered by those whose develop and use it. There is a bit of a > learning curve however. At the end of the day I think the best > solution is the one that works for you and if you have a chance you > should try each one to see which is most suitable. I have not tried > TripleO, Airship in a bottle did not work out the box, Kolla-Ansible > is useful also but gave me fits troubleshooting, and OpenStack-Ansible > I mentioned the learning curve. I do not deal with a lot of manual > deploying these days but if I was spinning up a public cloud > personally I would roll with OpenStack-Ansible > > > > On Mon, Dec 17, 2018, 10:47 AM Cody > Hello stackers, > > What deployment tools would be of your choice for deploying a public > IaaS with an initial size of 200~300 nodes? Would TripleO be suitable > for this cluster size? > > Thank you very much. Wish you all a happy holiday season! > > Best regards, > Cody From mihalis68 at gmail.com Tue Dec 18 15:54:09 2018 From: mihalis68 at gmail.com (Chris Morgan) Date: Tue, 18 Dec 2018 10:54:09 -0500 Subject: [Ops] ops meetups team meeting 2018-12-18 Message-ID: Meeting minutes from our meeting today on IRC are linked below. Key points: - next meeting Jan 8th 2019 - ops meetup #1 looks likely to be at Deutsche Telekom, Berlin, March 7,8 2019 - the team hopes to confirm this soon and commence technical agenda planning early January - team meetings will continue to be 10AM EST Tuesdays on #openstack-operators Meeting ended Tue Dec 18 15:44:05 2018 UTC. 10:44 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_team.2018-12-18-15.03.html 10:44 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_team.2018-12-18-15.03.txt 10:44 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_team.2018-12-18-15.03.log.html About the OpenStack Operators Meetups team: https://wiki.openstack.org/wiki/Ops_Meetups_Team Chris -- Chris Morgan -------------- next part -------------- An HTML attachment was scrubbed... URL: From liliueecg at gmail.com Tue Dec 18 04:44:38 2018 From: liliueecg at gmail.com (Li Liu) Date: Mon, 17 Dec 2018 23:44:38 -0500 Subject: [cyborg] IRC meeting for Dec 18th Message-ID: The IRC meeting will be held tomorrow at 0300 UTC, which is 10:00 pm est(Tuesday) / 7:00 pm pst(Tuesday) /11 am Beijing time (Wednesday) This week's agenda: 1. Try to merge https://review.openstack.org/#/c/615462/ 2. Review https://review.openstack.org/#/c/625630/ from CoCo 3. Review https://review.openstack.org/#/c/596691/ from Zhenghao 4. Track status updates. -- Thank you Regards Li -------------- next part -------------- An HTML attachment was scrubbed... URL: From dradez at redhat.com Tue Dec 18 16:00:39 2018 From: dradez at redhat.com (Dan Radez) Date: Tue, 18 Dec 2018 11:00:39 -0500 Subject: Backporting networking-ansible to Queens In-Reply-To: <243084cd-4a9c-e9b3-af5f-07d5fd4f4b35@redhat.com> References: <243084cd-4a9c-e9b3-af5f-07d5fd4f4b35@redhat.com> Message-ID: <0019d2fb-2925-267d-2478-e642f986ae6b@redhat.com> On 12/12/18 4:44 PM, Dan Radez wrote: > We have requested to add ansible-runner and update the version of > python-pexpect from 4.3 to 4.5 in the openstack-requirements repository. > https://review.openstack.org/#/c/624048 > > This is in effort to enable the networking-ansible ML2 driver in > Queens. It was developed as part of the Rocky development cycle. > > We understood that this is outside the structure of standard practice > and would like to request an exception for this change in light of > it's low risk. > > We have customers that are asking for this ML2 driver to be enabled in > our product that is based on Queens. We would like to push these > changes to upstream first. This exposes the community to this code and > prevents the need to carry patches downstream. > > This ML2 driver is an add on feature that should carry little to no > technical debt for the stable/Queens code base. Python-pexpect need to > be updated and we will update Triple-o to enable it to install and > configure the new driver. Otherwise the backport consists of adding > the ansible-runner dependency and packaging the code for the > networking-ansible ML2 driver. End users are impacted only when they > choose to install the feature and enable it. > > Thank you for your consideration, > > Dan Radez python-pexpect is used by a small handful of projects. There a chance that pyyaml may have to be bumped one minor version as well. These changes seem to be a fairly low impact for networking-ansible's dependency updates. The community is not being asked to take on any more maintenance or spend extra time as a result of this backport. The requirements update for the backport has passed all of its tests. While this is an unusual request, our hope is the value for us and for queens users can be seen. In light of the low risk and the expected zero additional time/maintenance could an exception be made to approve this update to happen? Dan Radez From ashlee at openstack.org Tue Dec 18 16:00:44 2018 From: ashlee at openstack.org (Ashlee Ferguson) Date: Tue, 18 Dec 2018 10:00:44 -0600 Subject: Denver Open Infrastructure Summit CFP Open Message-ID: <27C44F4A-16A0-4503-BC75-7BB07E50114F@openstack.org> Hi everyone, The OpenStack Summit has a new name! To reflect our evolving community, the first Open Infrastructure Summit will be held in Denver, Colorado April 29 - May 1, 2019. The Call for Presentations (CFP) is now open, and the deadline to submit your presentations, panels, and workshops is Wednesday, January 23 at 11:59pm PT (January 24 at 7:59am UTC). Here are the Summit Tracks as well as the Programming Committee nomination form if you are interested in helping shape the content of the Summit. The content submission process for the Forum and Project Teams Gathering will be managed separately in the upcoming months. SUBMIT YOUR PRESENTATION New for the Denver Summit: Based on previous track chair and attendee feedback, we have added / updated three Tracks: Security, Getting Started, Open Development. You can find the Track descriptions here . In addition to OpenStack, you’ll see the OSF pilot projects —Airship, Kata Containers, StarlingX and Zuul —front and center alongside Ansible, Cloud Foundry, Docker, Kubernetes, and many more. The Open Infrastructure Summit, has evolved to recognize our diverse audience, and to signal to the market that the event is relevant for all IT infrastructure decision makers. We are working with the Programming Committee members to share the topics they’re looking for within each Track. Stay tuned on Superuser as we post these recommendations. If you’re interested in influencing the Summit content, apply to be a Programming Committee member *, where you can also find a full list of time requirements and expectations. Nominations will close on January 4, 2019. *OSF Staff will serve as the Programming Committee for the Getting Started Track. Denver Summit registration and sponsor sales are currently open. Learn more Please email speakersupport at openstack.org with any questions or feedback. Cheers, Ashlee Ashlee Ferguson OpenStack Foundation ashlee at openstack.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike_mp at zzzcomputing.com Tue Dec 18 16:06:19 2018 From: mike_mp at zzzcomputing.com (Mike Bayer) Date: Tue, 18 Dec 2018 11:06:19 -0500 Subject: queens heat db deadlock In-Reply-To: References: <38bae882-b4ac-4b55-5345-e27edbd582f3@redhat.com> Message-ID: On Tue, Dec 18, 2018 at 12:36 AM Ignazio Cassano wrote: > > Yes, I tried on yesterday and this workaround solved. > Thanks > Ignazio OK, so that means this "deadlock" is not really a deadlock but it is a write-conflict between two Galera masters. I have a long term goal to being relaxing this common requirement that Openstack apps only refer to one Galera master at a time. If this is a particular hotspot for Heat (no pun intended) can we pursue adding a transaction retry decorator for this operation? This is the standard approach for other applications that are subject to galera multi-master writeset conflicts such as Neutron. > > Il giorno Lun 17 Dic 2018 20:38 Joe Topjian ha scritto: >> >> Hi Ignazio, >> >> Do you currently have HAProxy configured to route requests to multiple MariaDB nodes? If so, as a workaround, try doing an active/backup configuration where all but 1 node is configured as an HAProxy "backup". >> >> Thanks, >> Joe >> >> >> >> On Sun, Dec 16, 2018 at 10:46 PM Ignazio Cassano wrote: >>> >>> Hello Zane, it happens also when I create a magnum cluster . >>> My mariadb cluster is behind haproxy. >>> Do you need any other info? >>> Thanks >>> Ignazio >>> >>> >>> Il giorno Lun 17 Dic 2018 00:28 Zane Bitter ha scritto: >>>> >>>> On 14/12/18 4:06 AM, Ignazio Cassano wrote: >>>> > Hi All, >>>> > I installed queens on centos 7. >>>> > Heat seems to work fine with templates I wrote but when I create magnum >>>> > cluster >>>> > I often face with db deadlock in heat-engine log: >>>> >>>> The stacktrace below is in stack delete, so do you mean that the problem >>>> occurs when deleting a Magnum cluster, or can it occur any time with a >>>> magnum cluster? >>>> >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource Traceback (most >>>> > recent call last): >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>>> > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 918, in >>>> > _action_recorder >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource yield >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>>> > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 2035, >>>> > in delete >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource *action_args) >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>>> > "/usr/lib/python2.7/site-packages/heat/engine/scheduler.py", line 346, >>>> > in wrapper >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource step = >>>> > next(subtask) >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>>> > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 977, in >>>> > action_handler_task >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource done = >>>> > check(handler_data) >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>>> > "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", >>>> > line 587, in check_delete_complete >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource return >>>> > self._check_status_complete(self.DELETE) >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>>> > "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", >>>> > line 454, in _check_status_complete >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource action=action) >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >>>> > ResourceFailure: resources[0]: (pymysql.err.InternalError) (1213, >>>> > u'Deadlock found when trying to get lock; try restarting transaction') >>>> > (Background on this error at: http://sqlalche.me/e/2j85) >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >>>> > 2018-12-13 11:48:46.030 89597 INFO heat.engine.stack >>>> > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] >>>> > Stack DELETE FAILED >>>> > (swarm-clustergp27-ebhsalhb4bop-swarm_primary_master-tzgkh3ncmymw): >>>> > Resource DELETE failed: resources[0]: (pymysql.err.InternalError) (1213, >>>> > u'Deadlock found when trying to get lock; try restarting transaction') >>>> > (Background on this error at: http://sqlalche.me/e/2j85) >>>> > 2018-12-13 11:48:46.844 89595 INFO heat.engine.resource >>>> > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] >>>> > DELETE: ResourceGroup "swarm_primary_master" >>>> > [6984db3c-3ac1-4afc-901f-21b3e7f230a7] Stack >>>> > "swarm-clustergp27-ebhsalhb4bop" [b43256fa-52e2-4613-ac15-63fd9340a8be] >>>> > >>>> > >>>> > I read this issue was solved in heat version 10 but seems not. >>>> >>>> The patch for bug 1732969, which is in Queens, is probably the fix >>>> you're referring to: https://review.openstack.org/#/c/521170/1 >>>> >>>> The traceback in that bug included the SQL statement that was failing. >>>> I'm not sure if that isn't included in your traceback because SQLAlchemy >>>> didn't report it, or if it's because that traceback is actually from the >>>> parent stack. If you have a traceback from the original failure in the >>>> child stack that would be useful. If there's a way to turn on more >>>> detailed reporting of errors in SQLAlchemy that would also be useful. >>>> >>>> Since this is a delete, it's possible that we need a retry-on-deadlock >>>> on the resource_delete() function also (though resource_update() is >>>> actually used more during a delete to update the status). >>>> >>>> - ZB >>>> From ralonsoh at redhat.com Tue Dec 18 16:22:25 2018 From: ralonsoh at redhat.com (Rodolfo Alonso) Date: Tue, 18 Dec 2018 16:22:25 +0000 Subject: [neutron][qos] IRC meeting Jan 1, 2019 Message-ID: <9e4b8f7ec04020b6d172d323f2b78e18e28af9be.camel@redhat.com> Hello: Next meeting on January 1, 2019, is canceled. The next meeting of the Neutron QoS subteam will be on January 15, 2019. Regards. From codeology.lab at gmail.com Tue Dec 18 16:39:34 2018 From: codeology.lab at gmail.com (Cody) Date: Tue, 18 Dec 2018 11:39:34 -0500 Subject: [publiccloud]Choice of deployment tools In-Reply-To: References: <2cd80ff44dad46ed8f2f93b1c9578fda@AUSX13MPS308.AMER.DELL.COM> Message-ID: Many, many thanks to everyone for your helps on this topic and wish you all a Happy New Year! Best regards, Cody On Tue, Dec 18, 2018 at 10:45 AM wrote: > > Cody, > It is documented in https://www.dellemc.com/resources/en-us/asset/technical-guides-support-information/solutions/Dell_EMC_NFV_Ready_Bundle_for_Red_Hat_Multi_rack_Architecture_Guide.pdf > Thanks, > Arkady > > -----Original Message----- > From: Cody [mailto:codeology.lab at gmail.com] > Sent: Monday, December 17, 2018 12:41 PM > To: Kanevsky, Arkady > Cc: mrhillsman at gmail.com; openstack-operators at lists.openstack.org > Subject: Re: [publiccloud]Choice of deployment tools > > > [EXTERNAL EMAIL] > > Hi Melvin and Arkady, > > Thank you for the replies. > > I have been using TripleO on a small scale (10~20 nodes per > deployment) and it worked well. That said, I am not sure what capacity it is designed for and whether it is still suitable to go beyond 2~300 nodes. > > @Melvin: I attempted to try Kolla-Ansible and OpenStack-Ansible, but failed to find documentations that provide coverages as detail as TripleO's. Do you happen to know any resources or books on the subjects for me to work on? > > @Arkady: May I ask if you used a Spine/Leaf network topology (i.e. > using a fully meshed layer 3 network above ToR) to deploy the 3 racks? > > Thank you to all! > > Best regards, > Cody > > On Mon, Dec 17, 2018 at 1:12 PM wrote: > > > > We had done TripleO deployment with 3 racks several times and it worked fined. > > > > > > > > From: Melvin Hillsman [mailto:mrhillsman at gmail.com] > > Sent: Monday, December 17, 2018 11:02 AM > > To: Cody > > Cc: openstack-operators at lists.openstack.org > > Subject: Re: [publiccloud]Choice of deployment tools > > > > > > > > [EXTERNAL EMAIL] > > > > Personally I have found openstack-ansible to be robust and very useful > > for a production environment. Not only the tool itself but also the > > help offered by those whose develop and use it. There is a bit of a > > learning curve however. At the end of the day I think the best > > solution is the one that works for you and if you have a chance you > > should try each one to see which is most suitable. I have not tried > > TripleO, Airship in a bottle did not work out the box, Kolla-Ansible > > is useful also but gave me fits troubleshooting, and OpenStack-Ansible > > I mentioned the learning curve. I do not deal with a lot of manual > > deploying these days but if I was spinning up a public cloud > > personally I would roll with OpenStack-Ansible > > > > > > > > On Mon, Dec 17, 2018, 10:47 AM Cody > > > Hello stackers, > > > > What deployment tools would be of your choice for deploying a public > > IaaS with an initial size of 200~300 nodes? Would TripleO be suitable > > for this cluster size? > > > > Thank you very much. Wish you all a happy holiday season! > > > > Best regards, > > Cody From alfredo.deluca at gmail.com Tue Dec 18 16:41:46 2018 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Tue, 18 Dec 2018 17:41:46 +0100 Subject: Openstack Magnum In-Reply-To: References: Message-ID: Hi all. I was able to fix the issue. The magnum.conf was pointing to another IP address on the authtoken section. Now I am able to create a cluster template. Tomorrow I will try to create a k8s cluster. Cheers On Tue, Dec 18, 2018 at 2:51 PM Alfredo De Luca wrote: > Hi Paul, Spyros et all. > I looked up on some bugs and info and even implementing them still got the > same errors. > I installed magnum client and when I try to do any command I get the same > error message: > > # magnum cluster-list > *ERROR: 'NoneType' object has no attribute 'replace' (HTTP 500) > (Request-ID: req-20c34d30-3bc9-4757-8aa7-3b4ecd35940e)* > > I found this bug but it says > We do currently not support www_authentication_uri at all, which is the > new standard, as auth_uri has long been deprecated. > > https://review.openstack.org/#/c/614082/ > > > So I am confused what to do. > Any suggestions? > > > > On Mon, Dec 17, 2018 at 10:29 AM Ignazio Cassano > wrote: > >> I am on #openstack-containers irc. >> They help us >> >> >> Il giorno lun 17 dic 2018 alle ore 09:53 Alfredo De Luca < >> alfredo.deluca at gmail.com> ha scritto: >> >>> Hi Ignazio. Any clue. Not sure why it doesn't work. >>> >>> anyone? >>> >>> >>> >>> On Mon, Dec 17, 2018 at 6:48 AM Ignazio Cassano < >>> ignaziocassano at gmail.com> wrote: >>> >>>> Thanks . >>>> >>>> Il giorno Dom 16 Dic 2018 22:51 Alfredo De Luca < >>>> alfredo.deluca at gmail.com> ha scritto: >>>> >>>>> Hi Ignazio. I am actually on Stein.... >>>>> >>>>> >>>>> On Sun, Dec 16, 2018 at 6:52 PM Ignazio Cassano < >>>>> ignaziocassano at gmail.com> wrote: >>>>> >>>>>> Hello Luca, I git same issue on queens. >>>>>> Are you in rocky? >>>>>> Regards >>>>>> Ignazio >>>>>> >>>>>> >>>>>> Il giorno Dom 16 Dic 2018 16:57 Alfredo De Luca < >>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>> >>>>>>> Hi all. >>>>>>> Just installed *openstack* and *magnum* with *ansible-openstack >>>>>>> AIO.* >>>>>>> >>>>>>> All works well except magnum itself. When I click on the dashboard on* >>>>>>> Container Infra *then C*lusters or clusters templates *I get the >>>>>>> following errors: >>>>>>> *Error: *Unable to retrieve the clusters. >>>>>>> *Error: *Unable to retrieve the stats. >>>>>>> >>>>>>> - Not sure why. >>>>>>> >>>>>>> >>>>>>> Any clue? >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> -- >>>>>>> *Alfredo* >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> *Alfredo* >>>>> >>>>> >>> >>> -- >>> *Alfredo* >>> >>> > > -- > *Alfredo* > > -- *Alfredo* -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcafarel at redhat.com Tue Dec 18 16:44:27 2018 From: bcafarel at redhat.com (Bernard Cafarelli) Date: Tue, 18 Dec 2018 17:44:27 +0100 Subject: [neutron] Subnet onboard and changing API definitions in neutron-lib In-Reply-To: <6043f799-3413-62f8-1f21-6e5f3dd5988a@suse.com> References: <6043f799-3413-62f8-1f21-6e5f3dd5988a@suse.com> Message-ID: On Mon, 10 Dec 2018 at 23:46, Ryan Tidwell wrote: > All, > > I alluded to some concerns about the current state of subnet onboard at > the end of today's neutron team meeting. I felt the mailing list was > probably the best starting point for a discussion, so here it goes :) > > > As I'm dealing with the last loose ends, I'm starting to deal with the > 'subnets' extension to the subnetpool resource on the API [1]. This has > me scratching my head at what the intent of this is since there isn't > much history to work with. When I look at the definition of the subnet > onboard extension in neutron-lib, I can see two possible "meanings" of > POST/PUT here: > > 1. Create a subnet from this subnetpool using the default prefix length > of the subnet pool. > > 2. Onboard the given subnet into the subnet pool. > As mentioned, when I worked on this blueprint, I only thought of this option. It does not make much sense to use this extension for other steps (especially as we already have API for 1) > > In addition to this ambiguity around the usage of the API, I also have > concerns that ONBOARD_SUBNET_SPECS as currently defined makes no sense > for either case. ONBOARD_SUBNET_SPECS requires that an id, network_id, > and ip_version be sent on any request made. This seems unnecessary for > both cases. > > Case 1 where we assume that we are using an alternate API to create a > subnet is problematic in the following ways: > > - Specifying an ip_version is unnecessary because it can be inferred > from the subnet pool > > - The definition as written doesn't seem to allow us to respond to the > user with anything other than a UUID. The user then has to make a second > call to actually go read the details like CIDR that are going to be > useful for them going forward. > > - More importantly, we already have an API (and corresponding CLI) for > creating subnets that works well and has much more flexibility than this > provides. Why duplicate functionality here? > > > Case 2 where we assume that we are onboarding a subnet is problematic in > the following ways: > > - Specifying network_id and ip_version are unnecessary. These values can > be read right off the subnet (which we would need to read for onboarding > anyway), all that needs to be passed is the subnet UUID. > > - Again, we would be duplicating functionality here because we have > already defined an API for onboarding a subnet in the ACTION_MAP [2] > Indeed, re-reading the blueprint, we "just" need to act on a subnet (from its id) to add it to a subnet pool So extra parameters look unnecessary at best > > > My intent is to figure out where to go from here to make this better > and/or alleviate the confusion on my part so this feature can be wrapped > up. Here is what I propose: > > Because subnet onboard is still incomplete and we are not claiming > support for it yet, I am proposing we simply remove the 'subnets' > extension to the subnetpools resource [3]. This simplifies the API and > resolves the concerns I expressed above. It also allows us to quickly > finish up subnet onboard without losing any of the desired > functionality, namely the ability to move ("onboard") an existing subnet > into a subnet pool (and by extension and address scope). > https://review.openstack.org/#/c/625936/ (for further discussion) > > The reason I am looking for input here is that it isn't clear to me > whether the approach I'm suggesting is acceptable to the team given our > policies around changing API definitions in neutron-lib. I'm not aware > of a situation where we have had an unreleased feature and have > discovered we don't like the API definition in neutron-lib (which has > sat for quite a while unimplemented) and want to change it. I'm just not > aware of any precedent for this situation, so I'm hoping the team has > some thoughts on how best to move forward. > We already did a change to this API definition recently with the default value change in change I6c0b5aa784a380502b9e5fd062dacd10a95b4cbf so I would say we can do the same here (fixing API before first implementation gets out) > > For reference, the current review for subnet onboard is > https://review.openstack.org/#/c/348080/. Any thoughts on this topic > would be greatly appreciated by me, and hopefully this discussion can be > useful to a broad audience going forward. > > > -Ryan > > > [1] > > https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/subnet_onboard.py#L32 > > [2] > > https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/subnet_onboard.py#L58 > > [3] > > https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/subnet_onboard.py#L41 > > > > -- Bernard Cafarelli -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmellado at redhat.com Tue Dec 18 16:55:25 2018 From: dmellado at redhat.com (Daniel Mellado) Date: Tue, 18 Dec 2018 17:55:25 +0100 Subject: [kuryr] Meetings canceled due to holidays, we'll be back on Jan 7th Message-ID: <8c43d7bf-6f96-f0d6-b34a-edae2ca44f3f@redhat.com> Hi kuryrs! We'll be having a break from our weekly meetings due to Christmas' holidays! First weekly meeting will be Monday January 7th. If there are any questions, please feel free to reach out to me or post to the mailing list, as well as pinging us on #openstack-kuryr. Best! Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x13DDF774E05F5B85.asc Type: application/pgp-keys Size: 2208 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From mriedemos at gmail.com Tue Dec 18 17:08:45 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Tue, 18 Dec 2018 11:08:45 -0600 Subject: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata" In-Reply-To: <0b4dd02e-92f7-e59f-82f7-951b5be45027@gmail.com> References: <8557b741-d4f5-cdfd-a244-65b47a1c3445@gmail.com> <058f5de0-9ebb-3cda-9216-5554fc229433@gmail.com> <0b4dd02e-92f7-e59f-82f7-951b5be45027@gmail.com> Message-ID: <27d65f26-fffa-d45e-55f7-ed76cc8f0d26@gmail.com> On 12/18/2018 6:48 AM, Jay Pipes wrote: > Well, technically, we *could* do all three of the above, right? :) It's > not an either/or situation, AFAIU. True. > > From looking at your patches, I think the long-term solution to this > would be to stop storing the instance password in the > instance_system_metadata table, but from looking into those code paths > (eww...) I realize that would be a huge chunk of tech debt refactoring. > Maybe something to line up for early Train? I would think we'd do an online data migration on access of a new Instance.password field. When building new instances or setting the instance password via the API, we'd set that field rather than in instance.system_metadata. When accessing the Instance.password field, if it's not set, we'd lazy-load and pop it from system_metadata, set it on the Instance.password field and save() that change. That's the model we have used for migrating things like instance.flavor and instance.keypairs. We'd still be stuck with my patch to the metadata API that conditionally joins system_metadata if vendordata_providers are configured, so anyone using those probably doesn't get the performance benefit anyway. It's hard to assess the benefit of prioritizing work on any of this without more operators coming forward and saying, "yes this is definitely a specific pain for us running the metadata-api", especially since the pre-loading of metadata/system_metadata in the API happened back in Mitaka. -- Thanks, Matt From mriedemos at gmail.com Tue Dec 18 17:15:26 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Tue, 18 Dec 2018 11:15:26 -0600 Subject: Backporting networking-ansible to Queens In-Reply-To: <243084cd-4a9c-e9b3-af5f-07d5fd4f4b35@redhat.com> References: <243084cd-4a9c-e9b3-af5f-07d5fd4f4b35@redhat.com> Message-ID: On 12/12/2018 3:44 PM, Dan Radez wrote: > We have customers that are asking for this ML2 driver to be enabled in > our product that is based on Queens. We would like to push these changes > to upstream first. This exposes the community to this code and prevents > the need to carry patches downstream. Replaying what I said in the review: "That is not sufficient justification for breaking stable branch policy. We all have customers on older versions of openstack that would like newer features. It is the job of vendors, not the community, to figure out how to satisfy those requests for their customers, either by getting the customer upgraded or carrying internal forks on stable branches." Regardless of impact, I don't want to set a precedent for picking and choosing which features are safe to backport to stable branches based on one vendor's customer demands. -- Thanks, Matt From adriant at catalyst.net.nz Tue Dec 18 17:36:24 2018 From: adriant at catalyst.net.nz (Adrian Turjak) Date: Wed, 19 Dec 2018 06:36:24 +1300 Subject: [openstack-dev] [keystone] Keystone support of Multi-Factor Authentication ? In-Reply-To: <1544794919.3636422.1609154600.62B5FA0A@webmail.messagingengine.com> References: <1544794919.3636422.1609154600.62B5FA0A@webmail.messagingengine.com> Message-ID: <8c86ff03-838f-ac54-76c3-29380a6022fc@catalyst.net.nz> On 15/12/18 2:41 AM, Colleen Murphy wrote: > Hi Greg, > > On Fri, Dec 14, 2018, at 2:07 PM, Waines, Greg wrote: >> Keystone guys, >> >> What is the current status of Keystone supporting Multi-Factor Authentication ? >> >> https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/mfa-auth-receipt.html >> >> * Does this work provide true MFA ? > It's a component of a proper MFA solution. We had already implemented TOTP as a possible auth method as well as the ability to use multiple auth methods. The MFA receipts work is to make it easier for clients to use MFA in a more natural way than what we had before. > >> * Is this work still active ? > The API work for the receipts features is more or less completed. We still need proper documentation and an update to the API reference. We also need to work this feature into keystoneauth and horizon. Adrian Turjak has been leading this effort. I think he's still on vacation but I expect he'll pick it up when he's back. Yes this work is active, just slowed. My holiday has been more of a holiday than a working holiday than expected, but the docs work will be done soon, and hopefully merged soon into the new year. I can then hopefully start work on Keystoneauth, but I don't know how long that will take or if we can get it done before the end of Stein (I hope so). > >> Are there other solutions for MFA for OpenStack Keystone ? > Not in keystone, but keystone supports external authentication so if you have an external identity provider that supports MFA you can lean on that. For our cloud we did a custom auth plugin for Keystone that solved this for us, and most importantly, a migration path to the auth rules and auth receipts method in keystone will be easy: https://github.com/catalyst-cloud/adjutant-mfa If running the latest version of Keystone won't be possible, this may be an alternative and mostly works now, but if you can, and can wait, the proper auth-receipt based method will be better. > >> Greg. > Colleen > From kor.jmlim at gmail.com Tue Dec 18 17:37:59 2018 From: kor.jmlim at gmail.com (Jea-Min Lim) Date: Wed, 19 Dec 2018 02:37:59 +0900 Subject: [devstack][neutron] truble with setting local.conf with neutron Message-ID: Dear all, I`m trying to test neutron with qos module using devstack in OpenStack pike in a single VM environment. However, I can`t figure out how to run devstack with my local.conf[1]. While configuring network and bridges, devstack lost connection to outside VM. As a result, devstack couldn`t complete settings. My local.conf example is based on doc[2]. If you have any comments on my local.conf, reply in this mail or, if you know the working configuration, it would be glad to share with me. Regards, [1] http://paste.openstack.org/show/737586/ [2] https://docs.openstack.org/devstack/latest/guides/neutron.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaypipes at gmail.com Tue Dec 18 17:49:42 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Tue, 18 Dec 2018 12:49:42 -0500 Subject: queens heat db deadlock In-Reply-To: References: <38bae882-b4ac-4b55-5345-e27edbd582f3@redhat.com> Message-ID: <82a140e4-55b7-453f-593d-d7423ac34e64@gmail.com> On 12/18/2018 11:06 AM, Mike Bayer wrote: > On Tue, Dec 18, 2018 at 12:36 AM Ignazio Cassano > wrote: >> >> Yes, I tried on yesterday and this workaround solved. >> Thanks >> Ignazio > > OK, so that means this "deadlock" is not really a deadlock but it is a > write-conflict between two Galera masters. I have a long term > goal to being relaxing this common requirement that Openstack apps > only refer to one Galera master at a time. If this is a particular > hotspot for Heat (no pun intended) can we pursue adding a transaction > retry decorator for this operation? This is the standard approach for > other applications that are subject to galera multi-master writeset > conflicts such as Neutron. Correct. Heat doesn't use SELECT .. FOR UPDATE does it? That's also a big cause of the aforementioned "deadlocks". Best, -jay >> >> Il giorno Lun 17 Dic 2018 20:38 Joe Topjian ha scritto: >>> >>> Hi Ignazio, >>> >>> Do you currently have HAProxy configured to route requests to multiple MariaDB nodes? If so, as a workaround, try doing an active/backup configuration where all but 1 node is configured as an HAProxy "backup". >>> >>> Thanks, >>> Joe >>> >>> >>> >>> On Sun, Dec 16, 2018 at 10:46 PM Ignazio Cassano wrote: >>>> >>>> Hello Zane, it happens also when I create a magnum cluster . >>>> My mariadb cluster is behind haproxy. >>>> Do you need any other info? >>>> Thanks >>>> Ignazio >>>> >>>> >>>> Il giorno Lun 17 Dic 2018 00:28 Zane Bitter ha scritto: >>>>> >>>>> On 14/12/18 4:06 AM, Ignazio Cassano wrote: >>>>>> Hi All, >>>>>> I installed queens on centos 7. >>>>>> Heat seems to work fine with templates I wrote but when I create magnum >>>>>> cluster >>>>>> I often face with db deadlock in heat-engine log: >>>>> >>>>> The stacktrace below is in stack delete, so do you mean that the problem >>>>> occurs when deleting a Magnum cluster, or can it occur any time with a >>>>> magnum cluster? >>>>> >>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource Traceback (most >>>>>> recent call last): >>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>>>>> "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 918, in >>>>>> _action_recorder >>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource yield >>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>>>>> "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 2035, >>>>>> in delete >>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource *action_args) >>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>>>>> "/usr/lib/python2.7/site-packages/heat/engine/scheduler.py", line 346, >>>>>> in wrapper >>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource step = >>>>>> next(subtask) >>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>>>>> "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 977, in >>>>>> action_handler_task >>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource done = >>>>>> check(handler_data) >>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>>>>> "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", >>>>>> line 587, in check_delete_complete >>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource return >>>>>> self._check_status_complete(self.DELETE) >>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File >>>>>> "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", >>>>>> line 454, in _check_status_complete >>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource action=action) >>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >>>>>> ResourceFailure: resources[0]: (pymysql.err.InternalError) (1213, >>>>>> u'Deadlock found when trying to get lock; try restarting transaction') >>>>>> (Background on this error at: http://sqlalche.me/e/2j85) >>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >>>>>> 2018-12-13 11:48:46.030 89597 INFO heat.engine.stack >>>>>> [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] >>>>>> Stack DELETE FAILED >>>>>> (swarm-clustergp27-ebhsalhb4bop-swarm_primary_master-tzgkh3ncmymw): >>>>>> Resource DELETE failed: resources[0]: (pymysql.err.InternalError) (1213, >>>>>> u'Deadlock found when trying to get lock; try restarting transaction') >>>>>> (Background on this error at: http://sqlalche.me/e/2j85) >>>>>> 2018-12-13 11:48:46.844 89595 INFO heat.engine.resource >>>>>> [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] >>>>>> DELETE: ResourceGroup "swarm_primary_master" >>>>>> [6984db3c-3ac1-4afc-901f-21b3e7f230a7] Stack >>>>>> "swarm-clustergp27-ebhsalhb4bop" [b43256fa-52e2-4613-ac15-63fd9340a8be] >>>>>> >>>>>> >>>>>> I read this issue was solved in heat version 10 but seems not. >>>>> >>>>> The patch for bug 1732969, which is in Queens, is probably the fix >>>>> you're referring to: https://review.openstack.org/#/c/521170/1 >>>>> >>>>> The traceback in that bug included the SQL statement that was failing. >>>>> I'm not sure if that isn't included in your traceback because SQLAlchemy >>>>> didn't report it, or if it's because that traceback is actually from the >>>>> parent stack. If you have a traceback from the original failure in the >>>>> child stack that would be useful. If there's a way to turn on more >>>>> detailed reporting of errors in SQLAlchemy that would also be useful. >>>>> >>>>> Since this is a delete, it's possible that we need a retry-on-deadlock >>>>> on the resource_delete() function also (though resource_update() is >>>>> actually used more during a delete to update the status). >>>>> >>>>> - ZB >>>>> > From adriant at catalyst.net.nz Tue Dec 18 17:58:45 2018 From: adriant at catalyst.net.nz (Adrian Turjak) Date: Wed, 19 Dec 2018 06:58:45 +1300 Subject: [tc][all] Train Community Goals In-Reply-To: References: Message-ID: <66d73db6-9f84-1290-1ab8-cf901a7fb355@catalyst.net.nz> I put my hand up during the summit for being at least one of the champions for the deletion of project resources effort. I have been meaning to do a follow up email and options as well as steps for how the goal might go, but my working holiday in Europe after the summit turned into more of a holiday than originally planned. I'll get a thread going around what I (and the public cloud working group) think project resource deletion should look like, and what the options are, and where we should aim to be with it. We can then turn that discussion into a final 'spec' of sorts. On 14/12/18 5:06 AM, Jean-Philippe Evrard wrote: > Hello everyone, > > We are looking for volunteers and potential future champions, > particularily to assist in completing prerequisite work for service- > side healthchecks and cleaning up resources when deleting a project. > > Goals are more likely to be successful if there is someone to drive the > work. Having an accurate assessment of the prerequisite work before the > goals even make it into review will help with scope and possibly > finding ways to break the work into more manageable pieces. So far, the > service-side health checks goal requires some oslo work for the > framework that services would use to implement the goal. The cleanup of > resources when deleting a project goal requires some anaylsis on what > the interface would look like for both os-purge and an API in each > service. > > Is anyone interested in driving the prerequisite work for these two > proposals? Ideally, it would be great if we could have the work done by > the middle of January, which gives us enough time to discuss prior to > putting proposals in review. > > This note is specific to the most popular goals from the summit session > in Berlin and prerequisite work for those goals. That said, it's > certainly not too late to propose other ideas or goals for Train. > > Thoughts? > > Lance (lbragstad) and JP (evrardjp) > > > From ignaziocassano at gmail.com Tue Dec 18 18:23:20 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Tue, 18 Dec 2018 19:23:20 +0100 Subject: queens heat db deadlock In-Reply-To: References: <38bae882-b4ac-4b55-5345-e27edbd582f3@redhat.com> Message-ID: Hello, seems deadlock happens when heat craates network objects. I am not sure, but if I remember some db deadlock also in cinder. Any case with the workaround heat never fails for db deadlock and Now stack deleting do not stop. Ignazio Il giorno Mar 18 Dic 2018 17:06 Mike Bayer ha scritto: > On Tue, Dec 18, 2018 at 12:36 AM Ignazio Cassano > wrote: > > > > Yes, I tried on yesterday and this workaround solved. > > Thanks > > Ignazio > > OK, so that means this "deadlock" is not really a deadlock but it is a > write-conflict between two Galera masters. I have a long term > goal to being relaxing this common requirement that Openstack apps > only refer to one Galera master at a time. If this is a particular > hotspot for Heat (no pun intended) can we pursue adding a transaction > retry decorator for this operation? This is the standard approach for > other applications that are subject to galera multi-master writeset > conflicts such as Neutron. > > > > > > > > Il giorno Lun 17 Dic 2018 20:38 Joe Topjian ha > scritto: > >> > >> Hi Ignazio, > >> > >> Do you currently have HAProxy configured to route requests to multiple > MariaDB nodes? If so, as a workaround, try doing an active/backup > configuration where all but 1 node is configured as an HAProxy "backup". > >> > >> Thanks, > >> Joe > >> > >> > >> > >> On Sun, Dec 16, 2018 at 10:46 PM Ignazio Cassano < > ignaziocassano at gmail.com> wrote: > >>> > >>> Hello Zane, it happens also when I create a magnum cluster . > >>> My mariadb cluster is behind haproxy. > >>> Do you need any other info? > >>> Thanks > >>> Ignazio > >>> > >>> > >>> Il giorno Lun 17 Dic 2018 00:28 Zane Bitter ha > scritto: > >>>> > >>>> On 14/12/18 4:06 AM, Ignazio Cassano wrote: > >>>> > Hi All, > >>>> > I installed queens on centos 7. > >>>> > Heat seems to work fine with templates I wrote but when I create > magnum > >>>> > cluster > >>>> > I often face with db deadlock in heat-engine log: > >>>> > >>>> The stacktrace below is in stack delete, so do you mean that the > problem > >>>> occurs when deleting a Magnum cluster, or can it occur any time with a > >>>> magnum cluster? > >>>> > >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource Traceback > (most > >>>> > recent call last): > >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > >>>> > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line > 918, in > >>>> > _action_recorder > >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource yield > >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > >>>> > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line > 2035, > >>>> > in delete > >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > *action_args) > >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > >>>> > "/usr/lib/python2.7/site-packages/heat/engine/scheduler.py", line > 346, > >>>> > in wrapper > >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource step = > >>>> > next(subtask) > >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > >>>> > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line > 977, in > >>>> > action_handler_task > >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource done = > >>>> > check(handler_data) > >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > >>>> > > "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", > >>>> > line 587, in check_delete_complete > >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource return > >>>> > self._check_status_complete(self.DELETE) > >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File > >>>> > > "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", > >>>> > line 454, in _check_status_complete > >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > action=action) > >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > >>>> > ResourceFailure: resources[0]: (pymysql.err.InternalError) (1213, > >>>> > u'Deadlock found when trying to get lock; try restarting > transaction') > >>>> > (Background on this error at: http://sqlalche.me/e/2j85) > >>>> > 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource > >>>> > 2018-12-13 11:48:46.030 89597 INFO heat.engine.stack > >>>> > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] > >>>> > Stack DELETE FAILED > >>>> > (swarm-clustergp27-ebhsalhb4bop-swarm_primary_master-tzgkh3ncmymw): > >>>> > Resource DELETE failed: resources[0]: (pymysql.err.InternalError) > (1213, > >>>> > u'Deadlock found when trying to get lock; try restarting > transaction') > >>>> > (Background on this error at: http://sqlalche.me/e/2j85) > >>>> > 2018-12-13 11:48:46.844 89595 INFO heat.engine.resource > >>>> > [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] > >>>> > DELETE: ResourceGroup "swarm_primary_master" > >>>> > [6984db3c-3ac1-4afc-901f-21b3e7f230a7] Stack > >>>> > "swarm-clustergp27-ebhsalhb4bop" > [b43256fa-52e2-4613-ac15-63fd9340a8be] > >>>> > > >>>> > > >>>> > I read this issue was solved in heat version 10 but seems not. > >>>> > >>>> The patch for bug 1732969, which is in Queens, is probably the fix > >>>> you're referring to: https://review.openstack.org/#/c/521170/1 > >>>> > >>>> The traceback in that bug included the SQL statement that was failing. > >>>> I'm not sure if that isn't included in your traceback because > SQLAlchemy > >>>> didn't report it, or if it's because that traceback is actually from > the > >>>> parent stack. If you have a traceback from the original failure in the > >>>> child stack that would be useful. If there's a way to turn on more > >>>> detailed reporting of errors in SQLAlchemy that would also be useful. > >>>> > >>>> Since this is a delete, it's possible that we need a retry-on-deadlock > >>>> on the resource_delete() function also (though resource_update() is > >>>> actually used more during a delete to update the status). > >>>> > >>>> - ZB > >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Tue Dec 18 19:41:25 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Tue, 18 Dec 2018 20:41:25 +0100 Subject: [devstack][neutron] truble with setting local.conf with neutron In-Reply-To: References: Message-ID: <0165F120-FF53-4C2C-A51E-9D3851DF41CB@redhat.com> Hi, I’m using local.conf like: http://paste.openstack.org/show/737595/ and it works perfectly fine for me. Config of my network interfaces on vm looks like on http://paste.openstack.org/show/737596/ — Slawek Kaplonski Senior software engineer Red Hat > Wiadomość napisana przez Jea-Min Lim w dniu 18.12.2018, o godz. 18:37: > > Dear all, > > I`m trying to test neutron with qos module using devstack in OpenStack pike in a single VM environment. > > However, I can`t figure out how to run devstack with my local.conf[1]. > > While configuring network and bridges, devstack lost connection to outside VM. > As a result, devstack couldn`t complete settings. > > My local.conf example is based on doc[2]. > > If you have any comments on my local.conf, reply in this mail or, if you know the working configuration, it would be glad to share with me. > > Regards, > > [1] http://paste.openstack.org/show/737586/ > [2] https://docs.openstack.org/devstack/latest/guides/neutron.html From skaplons at redhat.com Tue Dec 18 19:47:19 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Tue, 18 Dec 2018 20:47:19 +0100 Subject: [neutron] CI meetings cancelled Message-ID: Hi, Due to Christmas and New Year, next 2 Neutron CI meetings are cancelled. Next CI meeting will be on 8.01.2019. — Slawek Kaplonski Senior software engineer Red Hat From johnsomor at gmail.com Tue Dec 18 21:47:54 2018 From: johnsomor at gmail.com (Michael Johnson) Date: Tue, 18 Dec 2018 13:47:54 -0800 Subject: [octavia] Octavia weekly IRC meeting is cancelled December 26th. Message-ID: Hello OpenStack folks! Due to the number of folks taking vacation time next week, we are cancelling the December 26th Octavia IRC meeting. We will resume our regular schedule starting January 2nd, 2019. I look forward to working with you all in the new year! Michael From johnsomor at gmail.com Tue Dec 18 21:59:05 2018 From: johnsomor at gmail.com (Michael Johnson) Date: Tue, 18 Dec 2018 13:59:05 -0800 Subject: [octavia][lbaas] Octavia v1 API will be retired along with neutron-lbaas in 2019. Message-ID: Hi Octavia folks, I wanted to send a reminder e-mail out that we are planning to retire both neutron-lbaas and the Octavia v1 API in September 2019 or the OpenStack "U" release, whichever comes first. The Octavia v1 API was used by the neutron-lbaas Octavia provider driver and was not an end-user API. The Octavia v1 API is a proprietary API and is not compatible with the LBaaS v2 API specification or any other LBaaS API specification. If you have questions about this deprecation cycle please see the FAQ wiki: https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation If you have questions or concerns not covered by the FAQ, please reach out to the Octavia team either by using the "[octavia]" subject prefix on this mailing list or in our IRC channel #openstack-lbaas. Have a great rest of 2018 and we look forward to working with you in the new year! Michael From miguel at mlavalle.com Tue Dec 18 23:55:07 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Tue, 18 Dec 2018 17:55:07 -0600 Subject: [neutron] Subnet onboard and changing API definitions in neutron-lib In-Reply-To: <6043f799-3413-62f8-1f21-6e5f3dd5988a@suse.com> References: <6043f799-3413-62f8-1f21-6e5f3dd5988a@suse.com> Message-ID: Hi, Based on the proposed Neutron patch ( https://review.openstack.org/#/c/348080/36/neutron/db/db_base_plugin_v2.py at 1252), clearly the intent of ONBOARD_SUBNETS_SPECS is the creation of new subnets when a subnetpool is created or updated. No ambiguity there. Having said that, I agree with you, it is a cumbersome way to create subnets out of subnetpools that forces the user to issue a additional calls to retrieve the the details of the subnets, since few details are returned in the first call: https://review.openstack.org/#/c/348080/36/neutron/db/db_base_plugin_v2.py at 1255. As a consequence, I am in favor of just removing ONBOARD_SUBNETS_SPECS and use the 'onboard_network_subnets' action to onboard existing subnets. As for the API definition sitting a long time in neutron-lib, I don't see that as a problem. The API definition hasn't actually been available to users through any functionality in Neutron, so I don't think we have any Thanks for working on this Miguel On Mon, Dec 10, 2018 at 4:45 PM Ryan Tidwell wrote: > All, > > I alluded to some concerns about the current state of subnet onboard at > the end of today's neutron team meeting. I felt the mailing list was > probably the best starting point for a discussion, so here it goes :) > > > As I'm dealing with the last loose ends, I'm starting to deal with the > 'subnets' extension to the subnetpool resource on the API [1]. This has > me scratching my head at what the intent of this is since there isn't > much history to work with. When I look at the definition of the subnet > onboard extension in neutron-lib, I can see two possible "meanings" of > POST/PUT here: > > 1. Create a subnet from this subnetpool using the default prefix length > of the subnet pool. > > 2. Onboard the given subnet into the subnet pool. > > In addition to this ambiguity around the usage of the API, I also have > concerns that ONBOARD_SUBNET_SPECS as currently defined makes no sense > for either case. ONBOARD_SUBNET_SPECS requires that an id, network_id, > and ip_version be sent on any request made. This seems unnecessary for > both cases. > > Case 1 where we assume that we are using an alternate API to create a > subnet is problematic in the following ways: > > - Specifying an ip_version is unnecessary because it can be inferred > from the subnet pool > > - The definition as written doesn't seem to allow us to respond to the > user with anything other than a UUID. The user then has to make a second > call to actually go read the details like CIDR that are going to be > useful for them going forward. > > - More importantly, we already have an API (and corresponding CLI) for > creating subnets that works well and has much more flexibility than this > provides. Why duplicate functionality here? > > > Case 2 where we assume that we are onboarding a subnet is problematic in > the following ways: > > - Specifying network_id and ip_version are unnecessary. These values can > be read right off the subnet (which we would need to read for onboarding > anyway), all that needs to be passed is the subnet UUID. > > - Again, we would be duplicating functionality here because we have > already defined an API for onboarding a subnet in the ACTION_MAP [2] > > > My intent is to figure out where to go from here to make this better > and/or alleviate the confusion on my part so this feature can be wrapped > up. Here is what I propose: > > Because subnet onboard is still incomplete and we are not claiming > support for it yet, I am proposing we simply remove the 'subnets' > extension to the subnetpools resource [3]. This simplifies the API and > resolves the concerns I expressed above. It also allows us to quickly > finish up subnet onboard without losing any of the desired > functionality, namely the ability to move ("onboard") an existing subnet > into a subnet pool (and by extension and address scope). > > The reason I am looking for input here is that it isn't clear to me > whether the approach I'm suggesting is acceptable to the team given our > policies around changing API definitions in neutron-lib. I'm not aware > of a situation where we have had an unreleased feature and have > discovered we don't like the API definition in neutron-lib (which has > sat for quite a while unimplemented) and want to change it. I'm just not > aware of any precedent for this situation, so I'm hoping the team has > some thoughts on how best to move forward. > > For reference, the current review for subnet onboard is > https://review.openstack.org/#/c/348080/. Any thoughts on this topic > would be greatly appreciated by me, and hopefully this discussion can be > useful to a broad audience going forward. > > > -Ryan > > > [1] > > https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/subnet_onboard.py#L32 > > [2] > > https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/subnet_onboard.py#L58 > > [3] > > https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/subnet_onboard.py#L41 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Wed Dec 19 01:03:39 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 19 Dec 2018 10:03:39 +0900 Subject: [dev] [tc][all] TC office hours is started now on #openstack-tc Message-ID: <167c3fd5640.d6d3ee7183919.3731656748593890706@ghanshyammann.com> Hello everyone, 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. - gmann & TC From gmann at ghanshyammann.com Wed Dec 19 01:38:24 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 19 Dec 2018 10:38:24 +0900 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> <1167de33-6942-13de-67e0-c86756deab25@redhat.com> Message-ID: <167c41d28e7.f0809a1983972.3892133550810877683@ghanshyammann.com> ---- On Tue, 18 Dec 2018 22:52:41 +0900 Doug Hellmann wrote ---- > Zane Bitter writes: > > > Is there actually any reason to think that there is a problematic level > > of under-reporting of TC-escalation-worthy issues? I can't think an a > > priori reason to expect that in a healthy project there should be large > > numbers of issues escalated to the TC. And despite focusing our meeting > > strategy around that and conducting a massively time-consuming campaign > > of reaching out to teams individually via the health checks, I'm not > > seeing any empirical evidence of it either. Meanwhile there's ample > > evidence that we need more time to discuss things as a group - just > > witness the difficulty of getting through a monthly meeting in < 1 hour > > by trying to stick to purely procedural stuff. > > > > (A more cynical person than I might suggest that going searching for > > trivial issues that we can 'solve' by fiat offers a higher > > dopamine-to-time-spent ratio than working together as a team to do... > > anything at all, and that this may explain some of its popularity.) > > I suggested we start doing the health checks more formally after the 2nd > Vancouver summit because during that week we did discover issues that 2 > teams had been dealing with for at least a cycle, if not longer. The > teams involved never escalated the problems, and the situations had > devolved into lingering anger and resentment. In one case we had a > project purposefully being misconfigured in CI in a misguided attempt to > "force" the team to comply with some policy by making it impossible for > them to test a feature. Once we found out about the problems, we had > them resolved within the week. > > So, I don't think it's too much to ask of TC members to actively seek > out team leads and try to establish a line of communication to avoid > ending up in that situation again. I consider it a preventive measure. +1. This is nice point. Establishing communication (free and live communication) with team leads is something will solve a lot of problems. I remember few teams lead telling me that they heard first time from TC about checking "what issues they are facing and want us to solve". TC reaching out to team leads via health check/informal meeting during events etc can make all the teams more free to raise the question to TC or suggest/request the team needs at least. This is especially good for projects which are more independent services and not interacting with other openstack services/team. They are small team and it is good to tell our presence and we are there to help them. -gmann > > -- > Doug > > From mriedemos at gmail.com Wed Dec 19 02:04:00 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Tue, 18 Dec 2018 20:04:00 -0600 Subject: [nova][ops] Trying to get per-instance live migration timeout action spec unstuck Message-ID: <4f696e01-9c04-2da9-34b6-86bdce0c6cdd@gmail.com> I'm looking at this (previously approved [1]) spec again [2] and trying to sort out what needs to happen to reach agreement on this feature. Note the dependent blueprint is now complete in Stein [3]. The idea is pretty simple: provide new parameters to the live migration API to (1) override [libvirt]/live_migration_completion_timeout [4] and/or (2) provide a timeout action in case the provided (or configured) timeout is reached which would override [libvirt]/live_migration_timeout_action [5]. The use case is also pretty simple: you can have a default timeout and action (abort) configured but there could be cases where you need to override that on a per-instance basis to move a set of VMs off a host for maintenance, so you want to tell nova to force complete (post-copy or pause) in case of a timeout. The abort and force-complete actions are the same as in the API ([6] and [7] respectively). There are two main sticking points against this in the review: 1. This can already be done using existing APIs (as noted) client-side if monitoring the live migration and it times out for whatever you consider a reasonable timeout at the time. 2. The libvirt driver is the only one that currently supports abort and force-complete. For #1, while valid as a workaround, is less than ideal since it would mean having to orchestrate that into any tooling that needs that kind of workaround, be that OSC, openstacksdk, python-novaclient, gophercloud, etc. I think it would be relatively simple to pass those parameters through with the live migration request down to nova-compute and have the parameters override the config options and then it's natively supported in the API. For #2, while also true, I think is not a great reason *not* to support per-instance timeouts/actions in the API when we already have existing APIs that do the same thing and have the same backend compute driver limitations. To ease this, I think we can sort out two things: a) Can other virt drivers that support live migration (xenapi, hyperv, vmware in tree, and powervm out of tree) also support abort and force-complete actions? John Garbutt at least thought it should be possible for xenapi at the Stein PTG. I don't know about the others - driver maintainers please speak up here. The next challenge would be getting driver maintainers to actually add that feature parity, but that need not be a priority for Stein as long as we know it's possible to add the support eventually. b) There are pre-live migration checks that happen on the source compute before we initiate the actual guest transfer. If a user (admin) specified these new parameters and the driver does not support them, we could fail the live migration early. This wouldn't change the instance status but the migration would fail and an instance action event would be recorded to explain why it didn't work, and then the admin can retry without those parameters. This would shield us from exposing something in the API that could give a false sense of functionality when the backend doesn't support it. Given all of this, are these reasonable compromises to continue trying to drive this feature forward, and more importantly, are other operators looking to see this functionality added to nova? Huawei public cloud operators want it because they routinely are doing live migrations as part of maintenance activities and want to be able to control these values per-instance. I assume there are other deployments that would like the same. If this is something you'd like to see move forward, please speak up soon since the nova spec freeze for Stein is January 10. [1] https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/live-migration-per-instance-timeout.html [2] https://review.openstack.org/#/c/600613/ [3] https://blueprints.launchpad.net/nova/+spec/live-migration-force-after-timeout [4] https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_completion_timeout [5] https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_timeout_action [6] https://developer.openstack.org/api-ref/compute/?expanded=#delete-abort-migration [7] https://developer.openstack.org/api-ref/compute/?expanded=#force-migration-complete-action-force-complete-action -- Thanks, Matt From vedarthambharath at gmail.com Wed Dec 19 04:50:45 2018 From: vedarthambharath at gmail.com (Vedartham Bharath) Date: Wed, 19 Dec 2018 10:20:45 +0530 Subject: [swift]Putting Swift storage disks to sleep Message-ID: Hi all, I am an undergraduate currently working on a research project which involves OpenStack Swift. In my project, I have set up Swift to run on 4 disks. I want to put down one of the hard disks to sleep i.e reduce the spin. I am using the hdparm tool in Linux to do this. The problem is that the disk automatically wakes back up after being put to sleep. I have found out that this is due to the fact that all the storage disks of Swift have to be mounted with XFS and the sync processes of XFS require the disk to wake up. I was wondering if there is a way to use a disk without a filesystem in Swift and if not, are there any other ways of putting storage disks in Swift to sleep? I have made sure the object replicator and object auditor do not wake the disk up. My goal is to be able to control putting the disk to sleep and waking it up when I need. Details of set up: Software: OpenStack Swift Newton with Keystone OS: Ubuntu 16.04 Thanks! From nakamura.tetsuro at lab.ntt.co.jp Wed Dec 19 07:22:47 2018 From: nakamura.tetsuro at lab.ntt.co.jp (TETSURO NAKAMURA) Date: Wed, 19 Dec 2018 16:22:47 +0900 Subject: [placement] How do we migrate DB manipulating data? Message-ID: Hi, I'd like to discuss how we can have DB upgrade migration method (with data manipulation) in placement. --- BackGround ========== https://bugs.launchpad.net/nova/+bug/1803925 * In Rocky, to have nested resource provider feature, we expanded the DB to have root provider id column. * The root provider id shouldn't be None and for root providers it should be the same value of its resource provider id. * In Rocky, the code is build in a backward compatible way doing online migration. * For each request of listing/showing resource providers, we look the root provider id and if it is stale and empty, we assume the resource provider is a root and set the same value as resource provider id. * Those providers that are not called in the Rocky cycle will still have an empty value for the root provider id. * In Stein or later, we want a way to be sure that all the root provider id contains some non-None value. * This is because we have a lot of TODOs in code which we want to clean up once we are sure all the root provider ids have non-None value in the DB. * In Stein, we are already ready use alembic to manage DB schema changes in placement. Question ======== How should we copy the resource provider id to root provider id if the root provider id is None? Options ======= 1. Do it in the alembic script in the same way as the schema expansion * This is done in the https://review.openstack.org/#/c/619126/ and brought several concerns. * We don't want the data manipulation migration to be inter-mixed with schema changes. * For cases skipping one release in an FFU fashion, there would be a lot of rows to be changed. 2. Have two stable version branches for alembic to separate schema changes and data manipulation * Neutron has been managing two branches in alembic already. * https://specs.openstack.org/openstack/neutron-specs/specs/liberty/online-schema-migrations.html * Developers would specify on which branch to have a new version via some a new CLI something like; `placement-db-manage revision -m "description of revision" (--schema-change|--data-manipulate)` * We should be careful for the dependency management across the two branches. * https://alembic.sqlalchemy.org/en/latest/branches.html 3. Bring the online-migration batch CLI command * Follow the traditional way to manage DB data in Nova * `placement-manage db online-data-migration [--max-count]` * I'm looking into this in https://review.openstack.org/#/c/624942/. 4. Any other ideas? --- Since it looks like it's going to have an impact both on operators who upgrade and developers who add new features in placement, it is nice to seek more ideas and to have a consensus before we go further. Thanks, -- Tetsuro Nakamura NTT Network Service Systems Laboratories TEL:0422 59 6914(National)/+81 422 59 6914(International) 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan From aschadin at sbcloud.ru Wed Dec 19 07:31:03 2018 From: aschadin at sbcloud.ru (=?utf-8?B?0KfQsNC00LjQvSDQkNC70LXQutGB0LDQvdC00YAg0KHQtdGA0LPQtdC10LI=?= =?utf-8?B?0LjRhw==?=) Date: Wed, 19 Dec 2018 07:31:03 +0000 Subject: Watcher team meeting Message-ID: <6A0205E0-D8DE-4B5E-9F5E-CAD0B5D01FF6@sbcloud.ru> Watcher team, I propose to shift today’s meeting from 08:00 UTC to 08:45 UTC. Alex From chkumar246 at gmail.com Wed Dec 19 09:11:14 2018 From: chkumar246 at gmail.com (Chandan kumar) Date: Wed, 19 Dec 2018 14:41:14 +0530 Subject: [tripleo][openstack-ansible] collaboration on os_tempest role update IV - Dec 19, 2018 Message-ID: Hello, As 2018 is about to end, Here is the last updates on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Things got merged: os_tempest: [1.] Create basic doc structure - https://review.openstack.org/623512 [2.] Added support for installing tempestconf from distro - https://review.openstack.org/622999 [3.] Revert "Use tempest run for generating subunit results" - https://review.openstack.org/625070 Revert reason: when --subunit flag is used with tempest run, either the tests passes or fails, It was always returning success. We are investigating and working on the same to fix it. python-tempestconf: [4.] Handle Forbidden exception when creating role - https://review.openstack.org/#/c/624411/ [5.] Adapt python-tempestconf to python3 - https://review.openstack.org/#/c/622343/ [6.] Add argument which allows users to add extensions - https://review.openstack.org/620379 Works still in progress: os_tempest: [1.] Better tempest black and whitelist management - https://review.openstack.org/621605 [2.] Update all plugin urls to use https rather than git - https://review.openstack.org/625670 [3.] Remove octavia in favor of octavia-tempest-plugin - https://review.openstack.org/625828 [4.] Use tempest_tempestconf_profile for handling named args - https://review.openstack.org/623187 [5.] Add tempestconf_git_url var for tempestconf testing - https://review.openstack.org/626092 [6.] Added support for installing python-tempestconf from git - https://review.openstack.org/625904 python-tempestconf: [7.] Add profile argument - https://review.openstack.org/621567 Summary: While working on adding support of python-tempestconf profile feature support in os_tempest, we found that we cannot test tempestconf patches with os_tempest as tempestconf is getting installed by pip, that's why we were working on adding support for the same to install it from git. Thanks to evrardjp, odyssey4me, jrosser, arxcruz, mnaser, kopecmartin for helping us on our silly queries. Upcoming two weeks: * Complete existing work in progress patches. Note: We are sending next update on 09th Jan, 2019 as Holidays started. Here is the third update [2] Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000831.html Thanks, Chandan Kumar From stig.openstack at telfer.org Wed Dec 19 09:27:38 2018 From: stig.openstack at telfer.org (Stig Telfer) Date: Wed, 19 Dec 2018 09:27:38 +0000 Subject: [scientific-sig] IRC meeting today, 1100UTC: 2018 retrospective, 2019 conferences, etc Message-ID: <88671526-3CF6-4126-84F4-7370EC9D3680@telfer.org> Hi All - We have an IRC meeting today in #openstack-meeting at 1100UTC - about 90 minutes time. Everyone is welcome. The agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_December_19th_2018 Today we’d like to cover the activities of the SIG in 2018, and what we would like to do in 2019. I thought it would also be useful to gather together CFPs and announcements for relevant conferences for the year to come. Cheers, Stig From ignaziocassano at gmail.com Wed Dec 19 10:00:04 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Wed, 19 Dec 2018 11:00:04 +0100 Subject: openstack magnum on queens kubectl errors Message-ID: Hello I've just installe openstack magnum on queens and I deployed a kubernets cluster. Heat stack terminated successfully but running kubectl describe node, at the end it reports: Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) Resource Requests Limits -------- -------- ------ cpu 0 (0%) 0 (0%) memory 0 (0%) 0 (0%) ephemeral-storage 0 (0%) 0 (0%) Events: Type Reason Age >From Message ---- ------ ---- ---- ------- Warning FailedNodeAllocatableEnforcement 4s (x71 over 70m) kubelet, kubecerts-pvfagyxq6gf6-minion-0 Failed to update Node Allocatable Limits "": failed to set supported cgroup subsystems for cgroup : Failed to set config for supported subsystems : failed to write 2089619456 to memory.limit_in_bytes: write /rootfs/var/lib/containers/atomic/kubelet.0/rootfs/sys/fs/cgroup/memory/memory.limit_in_bytes: invalid argument Anyone can help me ? I read some patches has been applyed on queens for this issue: https://bugs.launchpad.net/magnum/+bug/1763405 but , anycase, I am facing the issue. Regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From witold.bedyk at est.fujitsu.com Wed Dec 19 11:02:58 2018 From: witold.bedyk at est.fujitsu.com (Bedyk, Witold) Date: Wed, 19 Dec 2018 11:02:58 +0000 Subject: [dev][ops][monasca] Additional meeting time Message-ID: Hello everyone, Monasca team has decided to hold additional team meetings on Thursdays, 7am UTC [1]. This way we would like to offer more suitable meeting time for developers and operators from Asia/Australia. We would like to try this new format of `double meetings` for some time and we'll keep it if there is demand. Everyone interested is warmly invited to join. If you have any topics you would like to discuss, please add them to the agenda [2]. The next meetings are planned today 1500 UTC and tomorrow 0700 UTC. See you there Witek [1] http://eavesdrop.openstack.org/#Monasca_Team_Meeting [2] https://etherpad.openstack.org/p/monasca-team-meeting-agenda From ssbarnea at redhat.com Wed Dec 19 11:14:32 2018 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Wed, 19 Dec 2018 11:14:32 +0000 Subject: [requirements] adding pre-commit to requirements blacklist (skip check) Message-ID: <388CC0F1-E269-46A0-9FB9-F8E652B7AFEA@redhat.com> It seems that the list of linters from the the blacklist.txt file is a bit outdated and missing things like: pre-commit bashate ansilbe-lint ansible-review I discovered that while trying to enable pre-commit on tripleo-upgrades and discovered that check-requirements jobs was failing. If someone can help me merge that it would be great https://review.openstack.org/#/c/626000/ My review contains only pre-commit because that was the one I really needed but looking at the file it seems it may be useful to add all known https://github.com/openstack/requirements/blob/master/blacklist.txt Thanks Sorin -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Wed Dec 19 12:42:01 2018 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 19 Dec 2018 13:42:01 +0100 Subject: [Release-job-failures] Release of openstack/karma-subunit-reporter failed In-Reply-To: References: Message-ID: <0e2af392-902c-e046-663f-1d9d20e239d8@openstack.org> zuul at openstack.org wrote: > - release-openstack-javascript http://logs.openstack.org/64/647112461fdc90aa3e468f0d5f846e16b032c87d/release/release-openstack-javascript/d6af9b6/ : POST_FAILURE in 5m 07s > - announce-release announce-release : SKIPPED Error is npm ERR! You cannot publish over the previously published versions: 0.0.4. : karma-subunit-reporter History here is that the tag in the git repo was incorrectly named (v0.0.4) last time the release was manually uploaded to npm (as 0.0.4). Since this is a re-release of the tag with correct name (0.0.4), the fact that the publication is failing (and announcement is skipped) is probably a good thing. -- Thierry Carrez (ttx) From hberaud at redhat.com Wed Dec 19 13:12:35 2018 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 19 Dec 2018 14:12:35 +0100 Subject: [Release-job-failures] Release of openstack/karma-subunit-reporter failed In-Reply-To: <0e2af392-902c-e046-663f-1d9d20e239d8@openstack.org> References: <0e2af392-902c-e046-663f-1d9d20e239d8@openstack.org> Message-ID: Hey, Yeah this error seems to be normal since the version 0.0.4 already exist on the repository. - https://www.npmjs.com/package/karma-subunit-reporter An another question is 2 lines below the npm error : + npm at 4.6.12018-12-19 10:15:02.372290 | localhost | added 299 packages from 591 contributors and audited 1181 packages in 9.459s2018-12-19 10:15:02.372387 | localhost | found 42 vulnerabilities (2 low, 34 moderate, 6 high) 42 Vulnerabilities found... I not an nodejs and npm expert so I'm not sure that is a real problem but I think we need to take look about this. Thoughts? Le mer. 19 déc. 2018 à 13:44, Thierry Carrez a écrit : > zuul at openstack.org wrote: > > - release-openstack-javascript > http://logs.openstack.org/64/647112461fdc90aa3e468f0d5f846e16b032c87d/release/release-openstack-javascript/d6af9b6/ > : POST_FAILURE in 5m 07s > > - announce-release announce-release : SKIPPED > > Error is npm ERR! You cannot publish over the previously published > versions: 0.0.4. : karma-subunit-reporter > > History here is that the tag in the git repo was incorrectly named > (v0.0.4) last time the release was manually uploaded to npm (as 0.0.4). > > Since this is a re-release of the tag with correct name (0.0.4), the > fact that the publication is failing (and announcement is skipped) is > probably a good thing. > > -- > Thierry Carrez (ttx) > > -- 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 Wed Dec 19 13:55:38 2018 From: mnaser at vexxhost.com (Mohammed Naser) Date: Wed, 19 Dec 2018 08:55:38 -0500 Subject: [tripleo][openstack-ansible] collaboration on os_tempest role update IV - Dec 19, 2018 In-Reply-To: References: Message-ID: Thanks for your updates, it's been great working with the TripleO team :) On Wed, Dec 19, 2018 at 4:14 AM Chandan kumar wrote: > Hello, > > As 2018 is about to end, Here is the last updates on collaboration on > os_tempest[1] role > between TripleO and OpenStack-Ansible projects. > > Things got merged: > os_tempest: > [1.] Create basic doc structure - https://review.openstack.org/623512 > [2.] Added support for installing tempestconf from distro - > https://review.openstack.org/622999 > [3.] Revert "Use tempest run for generating subunit results" - > https://review.openstack.org/625070 > Revert reason: when --subunit flag is used with tempest run, > either the tests passes or fails, > It was always returning success. We are investigating and working > on the same > to fix it. > python-tempestconf: > [4.] Handle Forbidden exception when creating role - > https://review.openstack.org/#/c/624411/ > [5.] Adapt python-tempestconf to python3 - > https://review.openstack.org/#/c/622343/ > [6.] Add argument which allows users to add extensions - > https://review.openstack.org/620379 > > Works still in progress: > os_tempest: > [1.] Better tempest black and whitelist management - > https://review.openstack.org/621605 > [2.] Update all plugin urls to use https rather than git - > https://review.openstack.org/625670 > [3.] Remove octavia in favor of octavia-tempest-plugin - > https://review.openstack.org/625828 > [4.] Use tempest_tempestconf_profile for handling named args - > https://review.openstack.org/623187 > [5.] Add tempestconf_git_url var for tempestconf testing - > https://review.openstack.org/626092 > [6.] Added support for installing python-tempestconf from git - > https://review.openstack.org/625904 > > python-tempestconf: > [7.] Add profile argument - https://review.openstack.org/621567 > > Summary: While working on adding support of python-tempestconf profile > feature support in os_tempest, > we found that we cannot test tempestconf patches with > os_tempest as tempestconf is getting > installed by pip, that's why we were working on adding > support for the same to install it > from git. > > Thanks to evrardjp, odyssey4me, jrosser, arxcruz, mnaser, kopecmartin > for helping us on our silly queries. > > Upcoming two weeks: > * Complete existing work in progress patches. > > Note: We are sending next update on 09th Jan, 2019 as Holidays started. > > Here is the third update [2] > Have queries, Feel free to ping us on #tripleo or #openstack-ansible > channel. > > Links: > [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest > [2.] > http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000831.html > > Thanks, > > Chandan Kumar > > -- 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 d.lake at surrey.ac.uk Wed Dec 19 09:56:58 2018 From: d.lake at surrey.ac.uk (d.lake at surrey.ac.uk) Date: Wed, 19 Dec 2018 09:56:58 +0000 Subject: =?Windows-1252?Q?Devstack_failure_=93Oslo.concurrency=94?= Message-ID: Hello I’m trying to rebuild a Devstack system on an identical machine to a working system from August. Same base OS (Centos 7.5), same simple local.conf. But this system is failing with Oslo.concurrency not at 2.26. This is bizarre because when I update Oslo.concurrency using pip, I’m given 2.29. Yet something in Devstack insists on going back to 2.25.1 despite knowing that I need 2.26. What is most annoying is that I thought that by keeping all the basic build identical I would save myself the pain that is OpenStack installation. How do I work around this please? If I clear out /usr/lib/python2.7/site-packages, this doesn’t seem to help at all. Thanks David Sent from my iPhone -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellorent at redhat.com Wed Dec 19 14:28:34 2018 From: ellorent at redhat.com (Felix Enrique Llorente Pastora) Date: Wed, 19 Dec 2018 15:28:34 +0100 Subject: [tripleo][ci] Reducing merge time by moving nv job to experimental Message-ID: Hello, To reduce merge time, would be nice from a review to go from check pipeline to gate pipeline without waiting for non-voting jobs, one way to do that is changing non-voting jobs at different pipelien like experimental one, so we have their result but don't wait for them to change to gate pipepeline. -- Quique Llorente Openstack TripleO CI -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Wed Dec 19 14:37:56 2018 From: zigo at debian.org (Thomas Goirand) Date: Wed, 19 Dec 2018 15:37:56 +0100 Subject: [tc][all] Train Community Goals In-Reply-To: References: Message-ID: On 12/4/18 6:38 PM, Lance Bragstad wrote: > Hi all, > > The purpose of this thread is to have a more focused discussion about > what we'd like to target for Train community goals, bootstrapped with > the outcomes from the session in Berlin [0]. > > During the session, we went through each item as a group and let the > person who added it share why they thought it would be a good community > goal candidate for the next release. Most goals have feedback captured > in etherpad describing next steps, but the following stuck out as top > contenders from the session (rated by upvotes): > > 1. Moving legacy clients to python-openstackclient > 2. Cleaning up resources when deleting a project > 3. Service-side health checks > > I don't think I missed any goals from the session, but if I did, please > let me know and I'll add it to the list so that we can discuss it here. > > Does anyone have strong opinions either way about the goals listed above? > > [0] https://etherpad.openstack.org/p/BER-t-series-goals It'd be nice if we could have decent support for uwsgi for Glance. With the move to Py3, there's no other way if we want SSL. There are other projects still missing it completely (like Designate). Cheers, Thomas Goirand (zigo) From aschultz at redhat.com Wed Dec 19 14:44:22 2018 From: aschultz at redhat.com (Alex Schultz) Date: Wed, 19 Dec 2018 07:44:22 -0700 Subject: [tripleo][ci] Reducing merge time by moving nv job to experimental In-Reply-To: References: Message-ID: On Wed, Dec 19, 2018 at 7:34 AM Felix Enrique Llorente Pastora wrote: > > Hello, > > To reduce merge time, would be nice from a review to go from check pipeline to gate pipeline without waiting for non-voting jobs, one way to do that is changing non-voting jobs at different pipelien like experimental one, so we have their result but don't wait for them to change to gate pipepeline. > The goal should be to get them to voting. The problem with experimental is that it requires folks to know to run them (which generally does not happen for our project). We currently have the scenario jobs as non-voting because of capacity problems but we still need the coverage so I'm not keen on moving them to non-voting. I'd rather we spend the time to land the standalone versions and get them voting again. Thanks, -Alex > -- > Quique Llorente > > Openstack TripleO CI From aschultz at redhat.com Wed Dec 19 14:47:44 2018 From: aschultz at redhat.com (Alex Schultz) Date: Wed, 19 Dec 2018 07:47:44 -0700 Subject: [tripleo][ci] Reducing merge time by moving nv job to experimental In-Reply-To: References: Message-ID: On Wed, Dec 19, 2018 at 7:44 AM Alex Schultz wrote: > > On Wed, Dec 19, 2018 at 7:34 AM Felix Enrique Llorente Pastora > wrote: > > > > Hello, > > > > To reduce merge time, would be nice from a review to go from check pipeline to gate pipeline without waiting for non-voting jobs, one way to do that is changing non-voting jobs at different pipelien like experimental one, so we have their result but don't wait for them to change to gate pipepeline. > > > > The goal should be to get them to voting. The problem with > experimental is that it requires folks to know to run them (which > generally does not happen for our project). We currently have the > scenario jobs as non-voting because of capacity problems but we still > need the coverage so I'm not keen on moving them to non-voting. I'd err experimental not non-voting. > rather we spend the time to land the standalone versions and get them > voting again. > > Thanks, > -Alex > > > -- > > Quique Llorente > > > > Openstack TripleO CI From balazs.gibizer at ericsson.com Wed Dec 19 15:03:43 2018 From: balazs.gibizer at ericsson.com (=?iso-8859-1?Q?Bal=E1zs_Gibizer?=) Date: Wed, 19 Dec 2018 15:03:43 +0000 Subject: [nova] review guide for the bandwidth patches Message-ID: <1545231821.28650.2@smtp.office365.com> Hi, After discussing generic concerns about the current proposed patch series[1] for the bandwidth-resource-provider bp [2] with Matt, I decided to write a summary that might help other reviewers. Grouping of the pathes ---------------------- The whole nova implementation is one long patch series that can be splitted into smaller logical steps * Already merged patches added the two new standard resource classes and added a field to RequestSpec to store the resource request of each neutron port. * The open patch series start at [3] now and the patches between [3] [4] introduce the ability to boot a server with neutron ports that has resource request. These patches implement handling the extra resources during boot, re-schedule and delete. These patches only work if a server has maximum one neutron port that has resource request. * The patches after [4] until [5] implement the calculation and communiction of the mapping between ports and resource providers that are fulfilling the given port resource request. (The reason why this is done in nova described below.) So these patches allow having more than one neutron port per server having resource request. * the next two patches [6][7] implement rejecting use cases that was decided to out of scope for the feature (interface attach with resource requst, booting with network having resource request) * The next patch [8] add support for removing resource allocation during interface detach if the detached port has resource request * The rest of the series up until [9] implement support for selecting VFs form the same PF that the bandwidth was allocated from. This allows handling bandwidth and VF resources properly even if there are more than one PFs on the same compute connected to the same physnet. What is still missing from the patch series: * Support for any kind of server move operations (resize, migrate, evacuate, live-migrate, unshelve) * Upgrade support: Bound SRIOV ports might already have QoS policy that would need healing resource allocation in placement. * Supporting separation of QoS aware and non aware ports on the same host. This can be done with host aggregates today, but the bp described possible ways to support a better separation. * Supporting multisegment network that has more than one segment having physnet name. For this we would need any-trait support from placement. The spec for it is approved but the implementation is on hold due to placement extraction. Order of the patches -------------------- One comment I got from Matt is that the patches are in wrong order. The current order allows booting server with bandwidth request _before_ every other server operation is supported (or rejected). This could lead to the violation of the resource view of the system. For example booting a server with a QoS aware port will result in bandwidth allocation on the compute host. But then later on migrating that server to another host does not properly handle moving the allocation to the target host. In my view reordering the patches to only allow booting the first server with bandwdith after every other operation is supported is not feasible. The current chain is already 17 patches long and it does not touch server moving operations at all. Also if I cannot boot a server with bandwidth then I cannot test that such server can be moved properly. So all the functional test would end up in the last patch of the series. However I think we can use the feature flag approach. We can implement and verify everything in the current order without the end user seeing or causing any kind of inconsistencies. The nova implementation is only activated if a neutron port has a resource_request field. This field is added to the neutron API as an API extension. We can mark this extension experimental while we are working through the missing pieces of the feature. But we can also turn on that extension in our test envirnoment to verify each and every step during the implementation process. Which RP fulfills the request of a neutron port ----------------------------------------------- Neutron expects a single RP uuid sent by nova in the port binding that tells neutron about which RP providers the resources for that port. This is the famous problem to find which request group is fulfilled by which resource provider in an allocation candidate. There are 3 possible solutions: * Neutron does the mapping. This would require Neutron to see each port binding for a given server as a single request. This is not the case today and not feasible to hack around in neutron. * Placement does the mapping. This is technically feasible and in my oppinion this is the good solution. But placement is in feature freeze so the spec [10] describing this change is put on hold. * Nova does the mapping. This is what pathes after [4] until [5] implement. It is a temporary solution until the placement based solution can be provided. The current patches are structured in a way that all ovo and neutronv2/api impacts in nova are reusable for the placement based solution later without change. There is only one patch [11] that will be thrown away when the placement based solution is available. I hope this mail helps reviewing the series. Cheers, gibi [1] https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider+(status:open+OR+status:merged) [2] https://blueprints.launchpad.net/nova/+spec/bandwidth-resource-provider [3] https://review.openstack.org/#/c/625941/ [4] https://review.openstack.org/#/c/567268/ [5] https://review.openstack.org/#/c/573317/ [6] https://review.openstack.org/#/c/570078 [7] https://review.openstack.org/#/c/570079 [8] https://review.openstack.org/#/c/622421 [9] https://review.openstack.org/#/c/623543 [10] https://review.openstack.org/#/c/597601 [11] https://review.openstack.org/#/c/616239 From torin.woltjer at granddial.com Wed Dec 19 15:09:40 2018 From: torin.woltjer at granddial.com (Torin Woltjer) Date: Wed, 19 Dec 2018 15:09:40 GMT Subject: Failed live migration and duplicate attachments Message-ID: After doing live migrations for some instances, and those migrations failing, the attached volumes show duplicates of the same attachment. This is the error message I get when the migration fails: https://pastebin.com/raw/3mxSVnRR openstack volume list shows the volume is attached to the instance twice. | a424fd41-a72f-4099-9c1a-47114d43c1dc | zktech-wpdb1 | in-use | 50 | Attached to ead8ecc3-f473-4672-a67b-c44534c6042d on /dev/vda Attached to ead8ecc3-f473-4672-a67b-c44534c6042d on /dev/vda How do I remove the duplicate attachment, and why could the live migration be failing in the first place? Not all migrations fail, but sometimes they do and I have multiple volumes with duplicate attachments. Torin Woltjer Grand Dial Communications - A ZK Tech Inc. Company 616.776.1066 ext. 2006 www.granddial.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nickeysgo at gmail.com Wed Dec 19 15:17:16 2018 From: nickeysgo at gmail.com (Minjun Hong) Date: Thu, 20 Dec 2018 00:17:16 +0900 Subject: [Cinder] cinder-volume connection problem when creating the instance Message-ID: Hi. I'm installing Cinder service in an storage server of my laboratory and I need you guys' help about Cinder. I'm installing Cinder by referring 'Cinder Installation Guide for Ubuntu' ( https://docs.openstack.org/cinder/queens/install/index-ubuntu.html). However, when I request creating an instance, it seems that Openstack cannot receive the volume which the instance needs from the storage server. And seeing status message of tgt service for iSCSI, it seems that the service needs certain kernel module. Status of tgt service is following: > ● tgt.service - (i)SCSI target daemon > Loaded: loaded (/lib/systemd/system/tgt.service; enabled; vendor > preset: enabled) > Active: active (running) since Wed 2018-12-19 22:05:55 KST; 26min ago > Docs: man:tgtd(8) > Process: 2249 ExecStartPost=/usr/sbin/tgtadm --op update --mode sys > --name State -v ready (code=exited, status=0/SUCCESS) > Process: 2230 ExecStartPost=/usr/sbin/tgt-admin -e -c > /etc/tgt/targets.conf (code=exited, status=0/SUCCESS) > Process: 2206 ExecStartPost=/usr/sbin/tgtadm --op update --mode sys > --name State -v offline (code=exited, status=0/SUCCESS) > Main PID: 2170 (tgtd) > Status: "Starting event loop..." > Tasks: 1 > Memory: 2.7M > CPU: 87ms > CGroup: /system.slice/tgt.service > └─2170 /usr/sbin/tgtd -f > Dec 19 22:05:55 node0 systemd[1]: Starting (i)SCSI target daemon... > Dec 19 22:05:55 node0 tgtd[2170]: tgtd: iser_ib_init(3434) Failed to > initialize RDMA; load kernel modules? > Dec 19 22:05:55 node0 tgtd[2170]: tgtd: work_timer_start(150) use signal > based scheduler > Dec 19 22:05:55 node0 tgtd[2170]: tgtd: bs_init(387) use signalfd > notification > Dec 19 22:05:55 node0 systemd[1]: Started (i)SCSI target daemon. And the status of Cinder-volume service as follows: > ● cinder-volume.service - OpenStack Cinder Volume > Loaded: loaded (/lib/systemd/system/cinder-volume.service; enabled; > vendor preset: enabled) > Active: active (running) since Wed 2018-12-19 22:05:55 KST; 45min ago > Main PID: 2110 (cinder-volume) > Tasks: 2 > Memory: 210.2M > CPU: 1min 23.649s > CGroup: /system.slice/cinder-volume.service > ├─2110 /usr/bin/python2 /usr/bin/cinder-volume > --config-file=/etc/cinder/cinder.conf > --log-file=/var/log/cinder/cinder-volume.log > └─2657 /usr/bin/python2 /usr/bin/cinder-volume > --config-file=/etc/cinder/cinder.conf > --log-file=/var/log/cinder/cinder-volume.log > Dec 19 22:05:55 node0 systemd[1]: Started OpenStack Cinder Volume. > Dec 19 22:06:00 node0 sudo[2658]: pam_unix(sudo:auth): auth could not > identify password for [cinder] Log message of Cinder-volume service continuously complains that the service cannot communicate with the internal driver (maybe, LVM?). In other words, when Cinder-volume is accessed (e.g. instance creation), an error message is printed and after that, the same message is repeated every second as follows: 2018-12-19 22:04:00.747 35996 INFO oslo_service.service > [req-bcc39e60-531e-4484-ab4b-bab085d112c4 - - - - -] Caught SIGTERM, > stopping children > 2018-12-19 22:04:00.784 35996 INFO oslo_service.service > [req-bcc39e60-531e-4484-ab4b-bab085d112c4 - - - - -] Waiting on 1 children > to exit > 2018-12-19 22:04:00.809 35996 INFO oslo_service.service > [req-bcc39e60-531e-4484-ab4b-bab085d112c4 - - - - -] Child 36039 killed by > signal 15 > 2018-12-19 22:05:58.378 2110 INFO root [-] Generating grammar tables from > /usr/lib/python2.7/lib2to3/Grammar.txt > 2018-12-19 22:05:58.403 2110 INFO root [-] Generating grammar tables from > /usr/lib/python2.7/lib2to3/PatternGrammar.txt > 2018-12-19 22:05:59.820 2110 INFO cinder.rpc > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Automatically selected > cinder-scheduler objects version 1.35 as minimum service version. > 2018-12-19 22:05:59.826 2110 INFO cinder.rpc > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Automatically selected > cinder-scheduler RPC version 3.10 as minimum service version. > 2018-12-19 22:05:59.875 2110 INFO cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Determined volume DB > was empty at startup. > 2018-12-19 22:05:59.908 2110 WARNING oslo_config.cfg > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Option "iscsi_helper" > from group "lvm" is deprecated. Use option "target_helper" from group "lvm". > 2018-12-19 22:05:59.914 2110 WARNING oslo_config.cfg > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Option > "iscsi_protocol" from group "lvm" is deprecated. Use option > "target_protocol" from group "lvm". > 2018-12-19 22:05:59.916 2110 INFO cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Image-volume cache > disabled for host node0 at lvm. > 2018-12-19 22:05:59.932 2110 INFO oslo_service.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Starting 1 workers > 2018-12-19 22:05:59.940 2657 INFO cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Starting cinder-volume > node (version 13.0.0) > 2018-12-19 22:05:59.942 2110 WARNING oslo_config.cfg > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Option "iscsi_helper" > from group "DEFAULT" is deprecated. Use option "target_helper" from group > "DEFAULT". > 2018-12-19 22:05:59.952 2110 WARNING oslo_config.cfg > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Option "auth_uri" from > group "keystone_authtoken" is deprecated for removal (The auth_uri option > is deprecated in favor of www_authenticate_uri and will be removed in the > S release.). Its value may be silently ignored in the future. > 2018-12-19 22:05:59.953 2110 WARNING oslo_config.cfg > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Option "auth_uri" from > group "keystone_authtoken" is deprecated. Use option "www_authenticate_uri" > from group "keystone_authtoken". > 2018-12-19 22:05:59.961 2657 INFO cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Starting volume driver > LVMVolumeDriver (3.0.0) > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Failed to initialize > driver.: ProcessExecutionError: Unexpected error while running command. > Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C vgs > --version > Exit code: 1 > Stdout: u'' > Stderr: u'sudo: no tty present and no askpass program specified\n' > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager Traceback (most > recent call last): > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/opt/stack/cinder/cinder/volume/manager.py", line 433, in init_host > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > self.driver.check_for_setup_error() > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/opt/stack/cinder/cinder/volume/drivers/lvm.py", line 286, in > check_for_setup_error > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager if > volutils.supports_thin_provisioning(): > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/opt/stack/cinder/cinder/volume/utils.py", line 628, in > supports_thin_provisioning > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > utils.get_root_helper()) > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/opt/stack/cinder/cinder/brick/local_dev/lvm.py", line 225, in > supports_thin_provisioning > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager return > LVM.get_lvm_version(root_helper) >= (2, 2, 95) > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/opt/stack/cinder/cinder/brick/local_dev/lvm.py", line 202, in > get_lvm_version > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > run_as_root=True) > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager File > "/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", > line 424, in execute > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > cmd=sanitized_cmd) > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > ProcessExecutionError: Unexpected error while running command. > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager Command: sudo > cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C vgs --version > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager Exit code: 1 > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager Stdout: u'' > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager Stderr: u'sudo: > no tty present and no askpass program specified\n' > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > 2018-12-19 22:06:00.075 2657 INFO cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Initializing RPC > dependent components of volume driver LVMVolumeDriver (3.0.0) > 2018-12-19 22:06:00.076 2657 ERROR cinder.utils > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Volume driver > LVMVolumeDriver not initialized > 2018-12-19 22:06:00.076 2657 ERROR cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Cannot complete RPC > initialization because driver isn't initialized properly.: > DriverNotInitialized: Volume driver not ready. > 2018-12-19 22:06:10.077 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0 at lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:06:20.077 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0 at lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:06:30.078 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0 at lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:06:40.078 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0 at lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:06:50.079 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0 at lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:07:00.079 2657 ERROR cinder.service > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Manager for service > cinder-volume node0 at lvm is reporting problems, not sending heartbeat. > Service will appear "down". > 2018-12-19 22:07:10.078 2657 WARNING cinder.volume.manager > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Update driver status > failed: (config name lvm) is uninitialized. In above log, 'Manage for service cinder -volume node0 at lvm is ...' is the repeated part. If there is anyone who has experienced this kind of problem, please give me any advice. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Wed Dec 19 15:28:50 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 19 Dec 2018 10:28:50 -0500 Subject: Devstack failure =?utf-8?Q?=E2=80=9COslo=2Econcurrency?= =?utf-8?Q?=E2=80=9D?= In-Reply-To: References: Message-ID: "d.lake at surrey.ac.uk" writes: > Hello > > I’m trying to rebuild a Devstack system on an identical machine to a working system from August. > > Same base OS (Centos 7.5), same simple local.conf. > > But this system is failing with Oslo.concurrency not at 2.26. > > This is bizarre because when I update Oslo.concurrency using pip, I’m given 2.29. > > Yet something in Devstack insists on going back to 2.25.1 despite > knowing that I need 2.26. Devstack runs pip using the constraints file to restrict the versions of packages installed to those known to have worked in CI. When you run pip by itself, those constraints are not applied and the newer version is used. Does the error message tell you which package depends on 2.25.1? Why do you need 2.26.0? > > What is most annoying is that I thought that by keeping all the basic build identical I would save myself the pain that is OpenStack installation. > > How do I work around this please? > > If I clear out /usr/lib/python2.7/site-packages, this doesn’t seem to help at all. > > Thanks > > David > > Sent from my iPhone -- Doug From sean.mcginnis at gmx.com Wed Dec 19 15:37:28 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Wed, 19 Dec 2018 09:37:28 -0600 Subject: [Cinder] cinder-volume connection problem when creating the instance In-Reply-To: References: Message-ID: <20181219153728.GA4860@sm-workstation> > > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Failed to initialize > > driver.: ProcessExecutionError: Unexpected error while running command. > > Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C vgs > > --version > > Exit code: 1 > > Stdout: u'' > > Stderr: u'sudo: no tty present and no askpass program specified\n' This appears to be the problem, or at least one of them. The account the cinder services are running under (usually "cinder") needs to be able to perform password-less sudo calls to execute some of the privileged calls needed to set up and interact with storage. I thought typically the system packages used in the install guides would create this user and set the appropriate permissions to do that. But something may have been modified on your system that is causing it to require a password on sudo calls, which as a headless service will not work. I don't have any systems that have that issue to verify with, but I believe if you run "visudo" and explicitly set cinder to NOPASSWD, you should then be able to restart the service and get better results. Sean From me at not.mn Wed Dec 19 15:39:22 2018 From: me at not.mn (John Dickinson) Date: Wed, 19 Dec 2018 07:39:22 -0800 Subject: [swift] Putting Swift storage disks to sleep In-Reply-To: References: Message-ID: <40598C97-567A-4636-B2C5-85FD9C257332@not.mn> There is no way to use raw disks in Swift. Swift requires drives to have a filesystem that supports (large) xattrs. We strongly recommend using XFS. I'm not sure why you are trying to sleep the drives; Swift is designed to keep drives spinning all the time (via spreading requests across all drives and continually performing background checks). In fact, oftentimes deployers replace "green" firmware with firmware that does not sleep the drives. If you are trying to simulate failures, unmounting the drives should be sufficient. If you are trying to simply reduce power consumption, temporarily putting drives to sleep is likely to be a lot of work (ie code changes) to do effectively and likely to not yield significant results. For power savings, I'd recommend looking at lower powered CPUs first and switching to lower powered storage (eg flash) second. --John On 18 Dec 2018, at 20:50, Vedartham Bharath wrote: > Hi all, > > I am an undergraduate currently working on a research project which > involves OpenStack Swift. In my project, I have set up Swift to run on > 4 disks. I want to put down one of the hard disks to sleep i.e reduce > the spin. I am using the hdparm tool in Linux to do this. > > The problem is that the disk automatically wakes back up after being > put to sleep. I have found out that this is due to the fact that all > the storage disks of Swift have to be mounted with XFS and the sync > processes of XFS require the disk to wake up. I was wondering if there > is a way to use a disk without a filesystem in Swift and if not, are > there any other ways of putting storage disks in Swift to sleep? I > have made sure the object replicator and object auditor do not wake > the disk up. My goal is to be able to control putting the disk to > sleep and waking it up when I need. > > Details of set up: > Software: OpenStack Swift Newton with Keystone > OS: Ubuntu 16.04 > > Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 850 bytes Desc: OpenPGP digital signature URL: From openstack at nemebean.com Wed Dec 19 16:15:48 2018 From: openstack at nemebean.com (Ben Nemec) Date: Wed, 19 Dec 2018 10:15:48 -0600 Subject: =?UTF-8?Q?Re=3a_Devstack_failure_=e2=80=9cOslo=2econcurrency?= =?UTF-8?B?4oCd?= In-Reply-To: References: Message-ID: <356c3afc-1826-553a-444e-595515392a07@nemebean.com> Quick note: There are no 2.2X releases of oslo.concurrency. It looks like we're probably talking about 3.2X. On 12/19/18 9:28 AM, Doug Hellmann wrote: > "d.lake at surrey.ac.uk" writes: > >> Hello >> >> I’m trying to rebuild a Devstack system on an identical machine to a working system from August. >> >> Same base OS (Centos 7.5), same simple local.conf. >> >> But this system is failing with Oslo.concurrency not at 2.26. >> >> This is bizarre because when I update Oslo.concurrency using pip, I’m given 2.29. >> >> Yet something in Devstack insists on going back to 2.25.1 despite >> knowing that I need 2.26. > > Devstack runs pip using the constraints file to restrict the versions of > packages installed to those known to have worked in CI. When you run pip > by itself, those constraints are not applied and the newer version is > used. > > Does the error message tell you which package depends on 2.25.1? > > Why do you need 2.26.0 Glancing at the current requirements I would guess it's because a lot of services are requiring 3.26: http://codesearch.openstack.org/?q=oslo.concurrency&i=nope&files=requirements.txt&repos= Maybe there's a mismatch with the requirements repo that is capping it at 3.25.1 when some of the other repos moved on to requiring 3.26? > >> >> What is most annoying is that I thought that by keeping all the basic build identical I would save myself the pain that is OpenStack installation. >> >> How do I work around this please? >> >> If I clear out /usr/lib/python2.7/site-packages, this doesn’t seem to help at all. >> >> Thanks >> >> David >> >> Sent from my iPhone > From melwittt at gmail.com Wed Dec 19 16:49:10 2018 From: melwittt at gmail.com (melanie witt) Date: Wed, 19 Dec 2018 08:49:10 -0800 Subject: [nova][dev] tracking spec reviews ahead of spec freeze Message-ID: <67c6b11f-a6a5-67cf-1b31-8ae8b5e580ae@gmail.com> Hey all, Spec freeze is coming up shortly after the holidays on January 10, 2019. Since we don't have much time after returning to work next year before spec freeze, let's keep track of specs that are close to approval or otherwise candidates to focus on in the last stretch before freeze. Here's an etherpad where I've collected a list of possible candidates for focus the first week of January. Feel free to add notes and specs I might have missed: https://etherpad.openstack.org/p/nova-stein-blueprint-spec-freeze Cheers, -melanie From openstack at nemebean.com Wed Dec 19 17:07:40 2018 From: openstack at nemebean.com (Ben Nemec) Date: Wed, 19 Dec 2018 11:07:40 -0600 Subject: [oslo][migrator] RFE Configuration mapping tool for upgrade - coordinate teams In-Reply-To: References: Message-ID: <4c6d85cc-a566-f981-433e-992a7433a236@nemebean.com> I'll reiterate what I said in the meeting for the broader audience: I'm unclear how much need there is for a tool of this nature. As you mentioned, deployment tools all have config management bits already that will be handling updates and upgrade. The only instance where I could see this being used is if someone were writing their configs by hand, and I'm skeptical that happens very often with a system as complex as OpenStack. When there was a team that was interested in implementing and using this I was fine with adding it, but if the people who wanted the tool are no longer around then we have no one to maintain it or assist with the adoption of some of the new features it adds. Given my concerns above, I don't want to add a large feature that the Oslo team will then have to maintain. We really don't have the capacity to be taking on lower priority work, especially if there's no one saying "yeah, I'll use that". I've left a comment on the first patch in the series[1] (and marked it WIP) to ask if there is still interest in this feature. Of course, if anyone reading this has interest please feel free to indicate that as well. It's unfortunate because I and a number of the other Oslo contributors have put a significant amount of time into the design and implementation of this tool, but if no one's going to use it then I'd rather cut our losses than continue pouring time into it. Thanks. -Ben 1: https://review.openstack.org/#/c/526314 On 12/18/18 9:07 AM, Herve Beraud wrote: > Hey teams, > > ## Summary > > The main goal of this thread is to coordinate teams to adopt the oslo > realease migrator tools and raise prior on this topics. > > ## History > > During the openstack submit in 2017 at Sydney a team from the Fujitsu > company propose a talk about how to > make fast forward upgrade from an openstack release to an another, and > present the state of art of the configuration migrator > inside openstack and the tools availables to do that. > > This team describe that for now, we have oslo.config generator tool to > show deprecated options in newer release > but they are still lacking some mapping configurations. > > After that the same team propose oslo.config specifications to improve > migrators. > > Where specifications was designed by the following reviews: > - https://review.openstack.org/#/c/520043/ > - https://review.openstack.org/#/c/526314/ > - https://review.openstack.org/#/c/526261/ > > The main goal of the proposed changes in these specs is to handle > configuration changes over releases: > - > https://specs.openstack.org/openstack/oslo-specs/specs/rocky/handle-config-changes.html > > These specifications describe that there should be some helper in > oslo.config for automatically adopt > new changes and help users manage their configuration files easily. > > Scenario: > Below is the proposed workflow that users can perform on old system to > generate new configuration for preparing upgrading to new release: >                                             +--------------+ > Old configuration  +-------->                  | >  (N-1 release)                    |     Oslo      | >                                             |    Config    +-------> > New configuration >       Namespaces  +-------->   Migrator |            (N release) >                                              |                  | >                                             +--------------+ >                                Running on new environment > > Since these specifications was validated, some patches was submitted by > the Fujitsu team to implement them: > https://review.openstack.org/#/q/status:open+project:openstack/oslo.config+branch:master+topic:migrator > > Details: >     - handle config mapping changes ( https://review.openstack.org/526314) >     - update valid value in choice list for the opt ( > https://review.openstack.org/603060) >     - update 'sample_default' instead of 'default' when migrating ( > https://review.openstack.org/606211) >     - use difflib to report mismatches in migrator tests ( > https://review.openstack.org/606210) >     - replace loop with dictionary lookup ( > https://review.openstack.org/606209) >     - replace 'upgrade_value' with 'convert_on_upgrade' ( > https://review.openstack.org/606207) > > Since these changes was proposed some peoples from the Fujitsu seems to > left the company and also seems to abandon this topic. > > During the last oslo meeting I had added this topic to the meeting > agenda to bring up this topic and to help us to move forward on it. > http://eavesdrop.openstack.org/meetings/oslo/2018/oslo.2018-12-17-15.00.log.html > http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000856.html > > ## Current state > > Some reviews was validated but some others need to be recovered due to the > lack of response about the original authors. > > I've submit some patches on reviews to help us to move on it. > > I've made some reviews based on the last comments and based on the asked > changes but now we need someone with an deeply > knowledge on oslo.config to validate the works. > > ## Others aspects > > Some tools like puppet/ansible/chef etc... already in use in openstack > can already handle migrators/upgrades and manage config changes. > > - Do we need to introduce an another tool like this one to do this job? > - How many people are manually writing OpenStack configs in the first place? > - Does it make sense to implement these changes? > > ## List of similar features on others projects > > - Tripleo provide a major release upgrade mechanisme ( > https://docs.openstack.org/tripleo-docs/latest/upgrade/developer/upgrades/major_upgrade.html) > - Openstack-Ansible also provide release upgrade mechanisme ( > https://docs.openstack.org/openstack-ansible/latest/admin/upgrades/major-upgrades.html) > - OpenStack fuel also propose specifications to upgrade configuration > and release ( > https://specs.openstack.org/openstack/fuel-specs/specs/7.0/upgrade-major-openstack-environment.html) > > This wiki can be useful to obtain the big picture of the release upgrade > management in openstack ( > https://wiki.openstack.org/wiki/Upgrade-with-minimal-downtime) > > I surely forgot some tools and alternatives, if you see something that > can be added here do not hesitate to reply to add it. > > ## Conclusion > > I bring up this topic to open a debate so do not hesitate react on this > topic by responding at this thread to help us to have a better big > picture to make the best choice. > > Thanks folks. > > Best regards. > > -- > 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 mriedemos at gmail.com Wed Dec 19 17:16:01 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 19 Dec 2018 11:16:01 -0600 Subject: [nova] When can/should we remove old nova-status upgrade checks? In-Reply-To: <9d50c6bd-7e9f-6ef9-7b4b-826c770b2c91@fried.cc> References: <41dda844-4466-84b6-6f47-3996d2b955cc@gmail.com> <57d607fb-ae4a-0bb7-ad4f-a70f8217735e@gmail.com> <9d50c6bd-7e9f-6ef9-7b4b-826c770b2c91@fried.cc> Message-ID: <26df166a-98b4-e360-0775-8ded3d0080b4@gmail.com> On 12/3/2018 10:59 AM, Eric Fried wrote: > I say remove the check. Its usefulness is negligible compared to the > effort that would be required to maintain it. It certainly isn't worth > writing a whole new placement feature to replace the db access. And > using existing interfaces would be very heavy in large deployments. (Not > that that's a show-stopper for running an upgrade check, but still.) I'm not really sure what you're saying about existing interfaces but I get the point (and from gibi). The tipping point for me at this juncture is OSA is hitting problems [1] with using extracted placement because of that check so I'm just going to kill it as I don't have the energy to rewrite nor maintain it anymore. [1] https://bugs.launchpad.net/nova/+bug/1808956 -- Thanks, Matt From ifatafekn at gmail.com Wed Dec 19 17:29:09 2018 From: ifatafekn at gmail.com (Ifat Afek) Date: Wed, 19 Dec 2018 19:29:09 +0200 Subject: [nova][vitrage] Nova extended server attributes Message-ID: Hi, Is there a way to get Nova extended server attributes (and specifically, OS-EXT-SRV-ATTR:instance_name) as part of the notification that is sent upon instance creation? In Vitrage we are using the immediate notifications from Nova, but this specific information is missing. Thanks, Ifat -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.friesen at windriver.com Wed Dec 19 17:34:33 2018 From: chris.friesen at windriver.com (Chris Friesen) Date: Wed, 19 Dec 2018 11:34:33 -0600 Subject: [nova][ops] Trying to get per-instance live migration timeout action spec unstuck In-Reply-To: <4f696e01-9c04-2da9-34b6-86bdce0c6cdd@gmail.com> References: <4f696e01-9c04-2da9-34b6-86bdce0c6cdd@gmail.com> Message-ID: <7ed7360a-475e-e654-13b3-0b288b134049@windriver.com> On 12/18/2018 8:04 PM, Matt Riedemann wrote: > There are two main sticking points against this in the review: > > 1. This can already be done using existing APIs (as noted) client-side > if monitoring the live migration and it times out for whatever you > consider a reasonable timeout at the time. > > 2. The libvirt driver is the only one that currently supports abort and > force-complete. > > For #1, while valid as a workaround, is less than ideal since it would > mean having to orchestrate that into any tooling that needs that kind of > workaround, be that OSC, openstacksdk, python-novaclient, gophercloud, > etc. I think it would be relatively simple to pass those parameters > through with the live migration request down to nova-compute and have > the parameters override the config options and then it's natively > supported in the API. I agree that it would be cleaner to support it in one place rather than needing to add timeout handling to all the various clients. > For #2, while also true, I think is not a great reason *not* to support > per-instance timeouts/actions in the API when we already have existing > APIs that do the same thing and have the same backend compute driver > limitations. To ease this, I think we can sort out two things: > b) There are pre-live migration checks that happen on the source compute > before we initiate the actual guest transfer. If a user (admin) > specified these new parameters and the driver does not support them, we > could fail the live migration early. This wouldn't change the instance > status but the migration would fail and an instance action event would > be recorded to explain why it didn't work, and then the admin can retry > without those parameters. This would shield us from exposing something > in the API that could give a false sense of functionality when the > backend doesn't support it. I think this would be a reasonable way to handle it. > Given all of this, are these reasonable compromises to continue trying > to drive this feature forward, and more importantly, are other operators > looking to see this functionality added to nova? Huawei public cloud > operators want it because they routinely are doing live migrations as > part of maintenance activities and want to be able to control these > values per-instance. I assume there are other deployments that would > like the same. We added nova extensions to the existing Wind River Titanium Cloud product to allow more control over the handling of live migrations because they're frequently used by our operators and have caused issues in the past. The new StarlingX project is more aligned with upstream, so it'd be good to have some sort of per-migration options available. Chris From mriedemos at gmail.com Wed Dec 19 17:46:36 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 19 Dec 2018 11:46:36 -0600 Subject: [nova][vitrage] Nova extended server attributes In-Reply-To: References: Message-ID: On 12/19/2018 11:29 AM, Ifat Afek wrote: > Is there a way to get Nova extended server attributes (and > specifically, OS-EXT-SRV-ATTR:instance_name) as part of the notification > that is sent upon instance creation? > > In Vitrage we are using the immediate notifications from Nova, but this > specific information is missing. We could add it into the versioned notification payload if that works for you (I heard vitrage was moving to using versioned notifications). If you only need it on create, it could go here: https://github.com/openstack/nova/blob/86a23f417a3e569afd74b513dc977780b40ead35/nova/notifications/objects/instance.py#L213 or more generically here: https://github.com/openstack/nova/blob/86a23f417a3e569afd74b513dc977780b40ead35/nova/notifications/objects/instance.py#L25 The tricky thing about that value is it gets generated from config: https://github.com/openstack/nova/blob/86a23f417a3e569afd74b513dc977780b40ead35/nova/objects/instance.py#L285 So depending on what "instance_name_template" is configured to be on each service that sends the notification, the value could be different, which could break unsuspecting consumers. It looks like the instance.create.* versioned notifications all get sent from the nova-compute service though which aligns with how "instance_name_template" is used to generate the guest name in the hypervisor. If you only need that value for instance.create notifications, maybe we should just restrict it to that rather than *all* InstancePayload-generated versioned notifications since the value isn't stored in the database. -- Thanks, Matt From miguel at mlavalle.com Wed Dec 19 18:40:19 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Wed, 19 Dec 2018 12:40:19 -0600 Subject: [openstack-dev] [Neutron] Propose Ryan Tidwell for neutron-dynamic-routing core Message-ID: Hi Stackers, I want to nominate Ryan Tidwell (irc: tidwellr) as a core reviewer for neutron-dynamic-routing ( https://github.com/openstack/neutron-dynamic-routing). Ryan has a long history with everything L3 in Neutron. He started contributing code back in 2014, helping to implement subnet pools ( https://review.openstack.org/#/c/148698/). Over the years he did great work improving Neutron's IP address manager and was the driving force in the creation and implementation of the neutron-dynamic-routing project. After a hiatus of a few cycles, Ryan came back to the community and has been very active adding support for MP-BGP in neutron-dynamic-routing and the on boarding of subnets in Neutron. The quality and number of his code reviews during the Stein cycle are on par with members of the Neutron core team: http://stackalytics.com/?module=neutron-group. I will keep this nomination open as customary. Thank you. Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: From vedarthambharath at gmail.com Wed Dec 19 19:04:18 2018 From: vedarthambharath at gmail.com (Vedartham Bharath) Date: Thu, 20 Dec 2018 00:34:18 +0530 Subject: [swift] Putting Swift storage disks to sleep In-Reply-To: <40598C97-567A-4636-B2C5-85FD9C257332@not.mn> References: <40598C97-567A-4636-B2C5-85FD9C257332@not.mn> Message-ID: Thank you for the reply! This is what we are attempting to do in our project: We have a Swift set up with where it stores 3 replicas of each object. The primary disks(ie disks in the ring) are all HDDs. We want to keep one of the primary disks of an object write to sleep and write the 3rd replica to a SSD handoff. After a while, we wake the HDD which was in sleep and the 3rd replica is put back using the replicator daemon. Once everything is restored back to the 3rd HDD, we keep the HDD back to sleep. This cycle continues. I would love your insight on this. Bharath On Wed, Dec 19, 2018 at 9:09 PM John Dickinson wrote: > > There is no way to use raw disks in Swift. Swift requires drives to have a filesystem that supports (large) xattrs. We strongly recommend using XFS. > > I'm not sure why you are trying to sleep the drives; Swift is designed to keep drives spinning all the time (via spreading requests across all drives and continually performing background checks). In fact, oftentimes deployers replace "green" firmware with firmware that does not sleep the drives. If you are trying to simulate failures, unmounting the drives should be sufficient. If you are trying to simply reduce power consumption, temporarily putting drives to sleep is likely to be a lot of work (ie code changes) to do effectively and likely to not yield significant results. For power savings, I'd recommend looking at lower powered CPUs first and switching to lower powered storage (eg flash) second. > > --John > > > > On 18 Dec 2018, at 20:50, Vedartham Bharath wrote: > > > Hi all, > > > > I am an undergraduate currently working on a research project which > > involves OpenStack Swift. In my project, I have set up Swift to run on > > 4 disks. I want to put down one of the hard disks to sleep i.e reduce > > the spin. I am using the hdparm tool in Linux to do this. > > > > The problem is that the disk automatically wakes back up after being > > put to sleep. I have found out that this is due to the fact that all > > the storage disks of Swift have to be mounted with XFS and the sync > > processes of XFS require the disk to wake up. I was wondering if there > > is a way to use a disk without a filesystem in Swift and if not, are > > there any other ways of putting storage disks in Swift to sleep? I > > have made sure the object replicator and object auditor do not wake > > the disk up. My goal is to be able to control putting the disk to > > sleep and waking it up when I need. > > > > Details of set up: > > Software: OpenStack Swift Newton with Keystone > > OS: Ubuntu 16.04 > > > > Thanks! From vedarthambharath at gmail.com Wed Dec 19 19:29:39 2018 From: vedarthambharath at gmail.com (Vedartham Bharath) Date: Thu, 20 Dec 2018 00:59:39 +0530 Subject: [glance][dev] Regarding "Eliminate Redundant Downloads of Uncached Images" project Message-ID: Hi all, I am very interested in working on one of the untargeted approved specifications in Glance. It is titled "Eliminate Redundant Downloads of Uncached Images". I have noticed that it is currently unassigned. My experience with OpenStack: I have setup Devstack. I have worked extensively on Swift as part of a research project. I have set up Swift All in One multiple times. I have also set up a multi-server installation of Swift. I have studied the codebase of Swift and added my own features for my project. I am willing to dedicate myself to study glance and work on this project. I would love to know if it is up for grabs! Bharath From mriedemos at gmail.com Wed Dec 19 19:46:44 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 19 Dec 2018 13:46:44 -0600 Subject: Failed live migration and duplicate attachments In-Reply-To: References: Message-ID: <8e305cf3-949d-46a9-0410-ccad7a2000b9@gmail.com> On 12/19/2018 9:09 AM, Torin Woltjer wrote: > After doing live migrations for some instances, and those migrations > failing, the attached volumes show duplicates of the same attachment. > This is the error message I get when the migration fails: > https://pastebin.com/raw/3mxSVnRR > > openstack volume list shows the volume is attached to the instance twice. > | a424fd41-a72f-4099-9c1a-47114d43c1dc | zktech-wpdb1            | > in-use    |   50 | Attached to ead8ecc3-f473-4672-a67b-c44534c6042d on > /dev/vda Attached to ead8ecc3-f473-4672-a67b-c44534c6042d on /dev/vda > > How do I remove the duplicate attachment, and why could the live > migration be failing in the first place? Not all migrations fail, but > sometimes they do and I have multiple volumes with duplicate attachments. > > /*Torin Woltjer*/ > *Grand Dial Communications - A ZK Tech Inc. Company* > *616.776.1066 ext. 2006* > /*www.granddial.com */ From the log, it looks like the live migration is timing out and aborting itself: 2018-12-17 13:47:12.449 16987 INFO nova.virt.libvirt.driver [req-7bc758de-b2e4-461b-a971-f79be6cd4703 313d1247d7b845da9c731eec53e50a26 2f693c782fa748c2baece8db95b4ba5b - default default] [instance: ead8ecc3-f473-4672-a67b-c44534c6042d] Migration running for 2280 secs, memory 3% remaining; (bytes processed=2541888418, remaining=126791680, total=3226542080) 2018-12-17 13:47:29.591 16987 WARNING nova.virt.libvirt.migration [req-7bc758de-b2e4-461b-a971-f79be6cd4703 313d1247d7b845da9c731eec53e50a26 2f693c782fa748c2baece8db95b4ba5b - default default] [instance: ead8ecc3-f473-4672-a67b-c44534c6042d] Live migration not completed after 2400 sec 2018-12-17 13:47:30.097 16987 WARNING nova.virt.libvirt.driver [req-7bc758de-b2e4-461b-a971-f79be6cd4703 313d1247d7b845da9c731eec53e50a26 2f693c782fa748c2baece8db95b4ba5b - default default] [instance: ead8ecc3-f473-4672-a67b-c44534c6042d] Migration operation was cancelled 2018-12-17 13:47:30.299 16987 ERROR nova.virt.libvirt.driver [req-7bc758de-b2e4-461b-a971-f79be6cd4703 313d1247d7b845da9c731eec53e50a26 2f693c782fa748c2baece8db95b4ba5b - default default] [instance: ead8ecc3-f473-4672-a67b-c44534c6042d] Live Migration failure: operation aborted: migration job: canceled by client: libvirtError: operation aborted: migration job: canceled by client After that, the _rollback_live_migration method is called which is trying to cleanup volume attachments created against the destination host (during pre_live_migration). The attachment cleanup is failing because it looks like the user token has expired: 2018-12-17 13:47:30.685 16987 INFO nova.compute.manager [req-7bc758de-b2e4-461b-a971-f79be6cd4703 313d1247d7b845da9c731eec53e50a26 2f693c782fa748c2baece8db95b4ba5b - default default] [instance: ead8ecc3-f473-4672-a67b-c44534c6042d] Swapping old allocation on 3e32d595-bd1f-4136-a7f4-c6703d2fbe18 held by migration 17bec61d-544d-47e0-a1c1-37f9d7385286 for instance 2018-12-17 13:47:32.450 16987 ERROR nova.volume.cinder [req-7bc758de-b2e4-461b-a971-f79be6cd4703 313d1247d7b845da9c731eec53e50a26 2f693c782fa748c2baece8db95b4ba5b - default default] Delete attachment failed for attachment 58997d5b-24f0-4073-819e-97916fb1ee19. Error: The request you have made requires authentication. (HTTP 401) Code: 401: Unauthorized: The request you have made requires authentication. (HTTP 401) 2018-12-17 13:47:32.497 16987 WARNING nova.virt.libvirt.driver [req-7bc758de-b2e4-461b-a971-f79be6cd4703 313d1247d7b845da9c731eec53e50a26 2f693c782fa748c2baece8db95b4ba5b - default default] [instance: ead8ecc3-f473-4672-a67b-c44534c6042d] Error monitoring migration: The request you have made requires authentication. (HTTP 401): Unauthorized: The request you have made requires authentication. (HTTP 401) Given that, you'd probably be interested in configuring nova to use service user tokens: https://docs.openstack.org/nova/latest/configuration/config.html#service-user With that feature, you configure nova with service user credentials so in the case that the user token times out, keystone automatically re-authenticates using the service user credentials. More details can be found in the spec: https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/use-service-tokens.html -- Thanks, Matt From doug at doughellmann.com Wed Dec 19 20:00:16 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 19 Dec 2018 15:00:16 -0500 Subject: [oslo][migrator] RFE Configuration mapping tool for upgrade - coordinate teams In-Reply-To: <4c6d85cc-a566-f981-433e-992a7433a236@nemebean.com> References: <4c6d85cc-a566-f981-433e-992a7433a236@nemebean.com> Message-ID: Ben Nemec writes: > I'll reiterate what I said in the meeting for the broader audience: > > I'm unclear how much need there is for a tool of this nature. As you > mentioned, deployment tools all have config management bits already that > will be handling updates and upgrade. The only instance where I could > see this being used is if someone were writing their configs by hand, > and I'm skeptical that happens very often with a system as complex as > OpenStack. > > When there was a team that was interested in implementing and using this > I was fine with adding it, but if the people who wanted the tool are no > longer around then we have no one to maintain it or assist with the > adoption of some of the new features it adds. Given my concerns above, I > don't want to add a large feature that the Oslo team will then have to > maintain. We really don't have the capacity to be taking on lower > priority work, especially if there's no one saying "yeah, I'll use that". > > I've left a comment on the first patch in the series[1] (and marked it > WIP) to ask if there is still interest in this feature. Of course, if > anyone reading this has interest please feel free to indicate that as well. > > It's unfortunate because I and a number of the other Oslo contributors > have put a significant amount of time into the design and implementation > of this tool, but if no one's going to use it then I'd rather cut our > losses than continue pouring time into it. +1 > > Thanks. > > -Ben > > 1: https://review.openstack.org/#/c/526314 > > On 12/18/18 9:07 AM, Herve Beraud wrote: >> Hey teams, >> >> ## Summary >> >> The main goal of this thread is to coordinate teams to adopt the oslo >> realease migrator tools and raise prior on this topics. >> >> ## History >> >> During the openstack submit in 2017 at Sydney a team from the Fujitsu >> company propose a talk about how to >> make fast forward upgrade from an openstack release to an another, and >> present the state of art of the configuration migrator >> inside openstack and the tools availables to do that. >> >> This team describe that for now, we have oslo.config generator tool to >> show deprecated options in newer release >> but they are still lacking some mapping configurations. >> >> After that the same team propose oslo.config specifications to improve >> migrators. >> >> Where specifications was designed by the following reviews: >> - https://review.openstack.org/#/c/520043/ >> - https://review.openstack.org/#/c/526314/ >> - https://review.openstack.org/#/c/526261/ >> >> The main goal of the proposed changes in these specs is to handle >> configuration changes over releases: >> - >> https://specs.openstack.org/openstack/oslo-specs/specs/rocky/handle-config-changes.html >> >> These specifications describe that there should be some helper in >> oslo.config for automatically adopt >> new changes and help users manage their configuration files easily. >> >> Scenario: >> Below is the proposed workflow that users can perform on old system to >> generate new configuration for preparing upgrading to new release: >>                                             +--------------+ >> Old configuration  +-------->                  | >>  (N-1 release)                    |     Oslo      | >>                                             |    Config    +-------> >> New configuration >>       Namespaces  +-------->   Migrator |            (N release) >>                                              |                  | >>                                             +--------------+ >>                                Running on new environment >> >> Since these specifications was validated, some patches was submitted by >> the Fujitsu team to implement them: >> https://review.openstack.org/#/q/status:open+project:openstack/oslo.config+branch:master+topic:migrator >> >> Details: >>     - handle config mapping changes ( https://review.openstack.org/526314) >>     - update valid value in choice list for the opt ( >> https://review.openstack.org/603060) >>     - update 'sample_default' instead of 'default' when migrating ( >> https://review.openstack.org/606211) >>     - use difflib to report mismatches in migrator tests ( >> https://review.openstack.org/606210) >>     - replace loop with dictionary lookup ( >> https://review.openstack.org/606209) >>     - replace 'upgrade_value' with 'convert_on_upgrade' ( >> https://review.openstack.org/606207) >> >> Since these changes was proposed some peoples from the Fujitsu seems to >> left the company and also seems to abandon this topic. >> >> During the last oslo meeting I had added this topic to the meeting >> agenda to bring up this topic and to help us to move forward on it. >> http://eavesdrop.openstack.org/meetings/oslo/2018/oslo.2018-12-17-15.00.log.html >> http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000856.html >> >> ## Current state >> >> Some reviews was validated but some others need to be recovered due to the >> lack of response about the original authors. >> >> I've submit some patches on reviews to help us to move on it. >> >> I've made some reviews based on the last comments and based on the asked >> changes but now we need someone with an deeply >> knowledge on oslo.config to validate the works. >> >> ## Others aspects >> >> Some tools like puppet/ansible/chef etc... already in use in openstack >> can already handle migrators/upgrades and manage config changes. >> >> - Do we need to introduce an another tool like this one to do this job? >> - How many people are manually writing OpenStack configs in the first place? >> - Does it make sense to implement these changes? >> >> ## List of similar features on others projects >> >> - Tripleo provide a major release upgrade mechanisme ( >> https://docs.openstack.org/tripleo-docs/latest/upgrade/developer/upgrades/major_upgrade.html) >> - Openstack-Ansible also provide release upgrade mechanisme ( >> https://docs.openstack.org/openstack-ansible/latest/admin/upgrades/major-upgrades.html) >> - OpenStack fuel also propose specifications to upgrade configuration >> and release ( >> https://specs.openstack.org/openstack/fuel-specs/specs/7.0/upgrade-major-openstack-environment.html) >> >> This wiki can be useful to obtain the big picture of the release upgrade >> management in openstack ( >> https://wiki.openstack.org/wiki/Upgrade-with-minimal-downtime) >> >> I surely forgot some tools and alternatives, if you see something that >> can be added here do not hesitate to reply to add it. >> >> ## Conclusion >> >> I bring up this topic to open a debate so do not hesitate react on this >> topic by responding at this thread to help us to have a better big >> picture to make the best choice. >> >> Thanks folks. >> >> Best regards. >> >> -- >> 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----- >> > -- Doug From mriedemos at gmail.com Wed Dec 19 20:34:05 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 19 Dec 2018 14:34:05 -0600 Subject: Failed live migration and duplicate attachments In-Reply-To: <8e305cf3-949d-46a9-0410-ccad7a2000b9@gmail.com> References: <8e305cf3-949d-46a9-0410-ccad7a2000b9@gmail.com> Message-ID: <517d376e-824c-cd89-9e8a-0644197f2f8c@gmail.com> On 12/19/2018 1:46 PM, Matt Riedemann wrote: > Given that, you'd probably be interested in configuring nova to use > service user tokens: > > https://docs.openstack.org/nova/latest/configuration/config.html#service-user I've posted https://review.openstack.org/#/c/626388/ to document this in the nova docs - that should have been done way back in Ocata when the feature was added. -- Thanks, Matt From tobias.rydberg at citynetwork.eu Wed Dec 19 20:42:33 2018 From: tobias.rydberg at citynetwork.eu (Tobias Rydberg) Date: Wed, 19 Dec 2018 21:42:33 +0100 Subject: [publiccloud-wg][sigs] Reminder weekly meeting Public Cloud WG Message-ID: Hi everyone, Time for a new meeting for Public Cloud WG - tomorrow 1400 UTC in #openstack-publiccloud! Agenda found at https://etherpad.openstack.org/p/publiccloud-wg Hope to see a lot of you there for the last meeting during 2018! Cheers, Tobias -- 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 From d.lake at surrey.ac.uk Wed Dec 19 15:22:10 2018 From: d.lake at surrey.ac.uk (d.lake at surrey.ac.uk) Date: Wed, 19 Dec 2018 15:22:10 +0000 Subject: [networking-ovs-dpdk] Issue creating br-ex... Message-ID: Hello Trying to re-run a Queens DPDK all-in-one using devstack which I built in August and hitting issues. The local.conf is identical between the two machines except I had to take the "stable/queens" off the end of the "networking-ovs-dpdk" plugin line as that no longer appears to work. The installation seems to proceed until it gets to setting the ip mtu on br-ex. I'm not using br-ex. I've declared OVS bridge mappings in the local.conf: #Dual socket platform with 16GB RAM,3072*2048kB hugepages leaves ~4G for the system. OVS_NUM_HUGEPAGES=3072 #Dual socket platform with 64GB RAM,14336*2048kB hugepages leaves ~6G for the system. #OVS_NUM_HUGEPAGES=14336 OVS_DATAPATH_TYPE=netdev OVS_LOG_DIR=/opt/stack/logs #OVS_DPDK_PORT_MAPPINGS=p1p1:br-dpdk1,p1p2:br-dpdk2,p2p1:br-dpdk3,p2p2:br-dpdk4 OVS_DPDK_PORT_MAPPINGS=p6p1:br-dpdk1,p6p2:br-dpdk2 #OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2,physnet3:br-dpdk3,physnet4:br-dpdk4 OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2 [[post-config|$NOVA_CONF]] [DEFAULT] firewall_driver=nova.virt.firewall.NoopFirewallDriver scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter [[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]] [OVS] datapath_type=netdev [ml2_type_flat] #flat_networks=physnet1,physnet2,physnet3,physnet4 flat_networks=physnet1,physnet2 I cannot stress again how identical these systems are - same hardware, same base OS install (CentOS 7.5). I was (maybe erroneously!) thinking that if I had it devstack working on one system, having an identical system would be a piece of cake to install. This is the installation error: +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:21 local bridge=br-ex +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:22 local 'addbr_cmd=sudo ovs-vsctl -- --may-exist add-br br-ex' +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:24 '[' netdev '!=' system ']' +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:25 addbr_cmd='sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev' +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:28 sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_public_bridge:119 set_mtu br-ex 1500 +functions:set_mtu:750 local dev=br-ex +functions:set_mtu:751 local mtu=1500 +functions:set_mtu:752 sudo ip link set mtu 1500 dev br-ex Cannot find device "br-ex" +functions:set_mtu:1 exit_trap +./stack.sh:exit_trap:522 local r=1 ++./stack.sh:exit_trap:523 jobs -p +./stack.sh:exit_trap:523 jobs= +./stack.sh:exit_trap:526 [[ -n '' ]] +./stack.sh:exit_trap:532 '[' -f /tmp/tmp.Dzbqzlk2fs ']' +./stack.sh:exit_trap:533 rm /tmp/tmp.Dzbqzlk2fs +./stack.sh:exit_trap:537 kill_spinner +./stack.sh:kill_spinner:432 '[' '!' -z '' ']' +./stack.sh:exit_trap:539 [[ 1 -ne 0 ]] +./stack.sh:exit_trap:540 echo 'Error on exit' Error on exit +./stack.sh:exit_trap:542 type -p generate-subunit +./stack.sh:exit_trap:543 generate-subunit 1545230781 1747 fail +./stack.sh:exit_trap:545 [[ -z /opt/stack/logs/screen ]] +./stack.sh:exit_trap:548 /home/stack/devstack/tools/worlddump.py -d /opt/stack/logs/screen Can someone explain what is going on here please? Thanks David -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.lake at surrey.ac.uk Wed Dec 19 15:33:28 2018 From: d.lake at surrey.ac.uk (d.lake at surrey.ac.uk) Date: Wed, 19 Dec 2018 15:33:28 +0000 Subject: =?utf-8?B?UkU6IERldnN0YWNrIGZhaWx1cmUg4oCcT3Nsby5jb25jdXJyZW5jeeKAnQ==?= In-Reply-To: References: Message-ID: Hi Doug I cleared that error by recloning Devstack and recompiling. But now I am hitting another issue with trying to set the ip mtu on br-ex which is failing... Have just posted a second email. Thanks David -----Original Message----- From: Doug Hellmann Sent: 19 December 2018 15:29 To: Lake, David (PG/R - Elec Electronic Eng) ; openstack at lists.openstack.org Subject: Re: Devstack failure “Oslo.concurrency” "d.lake at surrey.ac.uk" writes: > Hello > > I’m trying to rebuild a Devstack system on an identical machine to a working system from August. > > Same base OS (Centos 7.5), same simple local.conf. > > But this system is failing with Oslo.concurrency not at 2.26. > > This is bizarre because when I update Oslo.concurrency using pip, I’m given 2.29. > > Yet something in Devstack insists on going back to 2.25.1 despite > knowing that I need 2.26. Devstack runs pip using the constraints file to restrict the versions of packages installed to those known to have worked in CI. When you run pip by itself, those constraints are not applied and the newer version is used. Does the error message tell you which package depends on 2.25.1? Why do you need 2.26.0? > > What is most annoying is that I thought that by keeping all the basic build identical I would save myself the pain that is OpenStack installation. > > How do I work around this please? > > If I clear out /usr/lib/python2.7/site-packages, this doesn’t seem to help at all. > > Thanks > > David > > Sent from my iPhone -- Doug From d.lake at surrey.ac.uk Wed Dec 19 20:29:28 2018 From: d.lake at surrey.ac.uk (d.lake at surrey.ac.uk) Date: Wed, 19 Dec 2018 20:29:28 +0000 Subject: FW: [networking-ovs-dpdk] Issue creating br-ex... In-Reply-To: References: Message-ID: Would appreciate some help here please. Br-ex is not being added and the mtu command causes the whole thing to not install. David From: Lake, David (PG/R - Elec Electronic Eng) Sent: 19 December 2018 15:22 To: openstack-dev at lists.openstack.org Subject: [networking-ovs-dpdk] Issue creating br-ex... Hello Trying to re-run a Queens DPDK all-in-one using devstack which I built in August and hitting issues. The local.conf is identical between the two machines except I had to take the "stable/queens" off the end of the "networking-ovs-dpdk" plugin line as that no longer appears to work. The installation seems to proceed until it gets to setting the ip mtu on br-ex. I'm not using br-ex. I've declared OVS bridge mappings in the local.conf: #Dual socket platform with 16GB RAM,3072*2048kB hugepages leaves ~4G for the system. OVS_NUM_HUGEPAGES=3072 #Dual socket platform with 64GB RAM,14336*2048kB hugepages leaves ~6G for the system. #OVS_NUM_HUGEPAGES=14336 OVS_DATAPATH_TYPE=netdev OVS_LOG_DIR=/opt/stack/logs #OVS_DPDK_PORT_MAPPINGS=p1p1:br-dpdk1,p1p2:br-dpdk2,p2p1:br-dpdk3,p2p2:br-dpdk4 OVS_DPDK_PORT_MAPPINGS=p6p1:br-dpdk1,p6p2:br-dpdk2 #OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2,physnet3:br-dpdk3,physnet4:br-dpdk4 OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2 [[post-config|$NOVA_CONF]] [DEFAULT] firewall_driver=nova.virt.firewall.NoopFirewallDriver scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter [[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]] [OVS] datapath_type=netdev [ml2_type_flat] #flat_networks=physnet1,physnet2,physnet3,physnet4 flat_networks=physnet1,physnet2 I cannot stress again how identical these systems are - same hardware, same base OS install (CentOS 7.5). I was (maybe erroneously!) thinking that if I had it devstack working on one system, having an identical system would be a piece of cake to install. This is the installation error: +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:21 local bridge=br-ex +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:22 local 'addbr_cmd=sudo ovs-vsctl -- --may-exist add-br br-ex' +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:24 '[' netdev '!=' system ']' +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:25 addbr_cmd='sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev' +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:28 sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_public_bridge:119 set_mtu br-ex 1500 +functions:set_mtu:750 local dev=br-ex +functions:set_mtu:751 local mtu=1500 +functions:set_mtu:752 sudo ip link set mtu 1500 dev br-ex Cannot find device "br-ex" +functions:set_mtu:1 exit_trap +./stack.sh:exit_trap:522 local r=1 ++./stack.sh:exit_trap:523 jobs -p +./stack.sh:exit_trap:523 jobs= +./stack.sh:exit_trap:526 [[ -n '' ]] +./stack.sh:exit_trap:532 '[' -f /tmp/tmp.Dzbqzlk2fs ']' +./stack.sh:exit_trap:533 rm /tmp/tmp.Dzbqzlk2fs +./stack.sh:exit_trap:537 kill_spinner +./stack.sh:kill_spinner:432 '[' '!' -z '' ']' +./stack.sh:exit_trap:539 [[ 1 -ne 0 ]] +./stack.sh:exit_trap:540 echo 'Error on exit' Error on exit +./stack.sh:exit_trap:542 type -p generate-subunit +./stack.sh:exit_trap:543 generate-subunit 1545230781 1747 fail +./stack.sh:exit_trap:545 [[ -z /opt/stack/logs/screen ]] +./stack.sh:exit_trap:548 /home/stack/devstack/tools/worlddump.py -d /opt/stack/logs/screen Can someone explain what is going on here please? Thanks David -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.lake at surrey.ac.uk Wed Dec 19 21:04:24 2018 From: d.lake at surrey.ac.uk (d.lake at surrey.ac.uk) Date: Wed, 19 Dec 2018 21:04:24 +0000 Subject: Devstack - yet more problems on install Message-ID: Following on from the last email about br-ex causing everything to baulk, I manually created the br-ex using brctl addbr br-ex and got past that hurdle. But now falling over with another one ERROR oslo_db.sqlalchemy.exc_filters InternalError: (1071, u'Specified key was too long; max key length is 767 bytes') ERROR oslo_db.sqlalchemy.exc_filters Error during database migration: (pymysql.err.InternalError) (1071, u'Specified key was too long; max key length is 767 bytes') [SQL: u'\nALTER TABLE quota_usages CHANGE COLUMN resource resource VARCHAR(300)'] (Background on this error at: http://sqlalche.me/e/2j85) Base OS is CentOS 7.5. I've found this which looks similar - https://review.openstack.org/#/c/626146/ - but I've no idea how to apply it to my Devstack installation. I'd appreciate some assistance please. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mcginnis at gmx.com Wed Dec 19 22:01:45 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Wed, 19 Dec 2018 16:01:45 -0600 Subject: Devstack - yet more problems on install In-Reply-To: References: Message-ID: <20181219220144.GA28606@sm-workstation> > But now falling over with another one > > ERROR oslo_db.sqlalchemy.exc_filters InternalError: (1071, u'Specified key was too long; max key length is 767 bytes') > ERROR oslo_db.sqlalchemy.exc_filters > Error during database migration: (pymysql.err.InternalError) (1071, u'Specified key was too long; max key length is 767 bytes') [SQL: u'\nALTER TABLE quota_usages CHANGE COLUMN resource resource VARCHAR(300)'] (Background on this error at: http://sqlalche.me/e/2j85) > > Base OS is CentOS 7.5. > > I've found this which looks similar - https://review.openstack.org/#/c/626146/ - but I've no idea how to apply it to my Devstack installation. > Yep, you found the right patch. That is a known issue right now and we should hopefully have the fix merged very shortly. In the meantime, you could add this to your local.conf: CINDER_BRANCH=refs/changes/46/626146/3 With that, devstack will pull down that version of the code and you should be able to get by this failure until we merge the fix. As of this moment, there is just a pep8 error that is preventing that from merging. That will not impact the ability to actually run the code. Once that merges you can take that line out of the local.conf file to just get the current code from master. Hope that helps. Sean From kennelson11 at gmail.com Wed Dec 19 22:05:43 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Wed, 19 Dec 2018 14:05:43 -0800 Subject: [first contact] Cancelling Next Meeting Message-ID: Hello! During the meeting yesterday, we voted to cancel our next meeting which would have been January 1 st. After that we will resume our regularly scheduled programming :) Have a good rest of the year everyone! -Kendall (diablo_rojo) -------------- next part -------------- An HTML attachment was scrubbed... URL: From haleyb.dev at gmail.com Thu Dec 20 00:07:19 2018 From: haleyb.dev at gmail.com (Brian Haley) Date: Wed, 19 Dec 2018 19:07:19 -0500 Subject: FW: [networking-ovs-dpdk] Issue creating br-ex... In-Reply-To: References: Message-ID: On 12/19/18 3:29 PM, d.lake at surrey.ac.uk wrote: > Would appreciate some help here please.   Br-ex is not being added and > the mtu command causes the whole thing to not install. Comments inline. > *From:*Lake, David (PG/R - Elec Electronic Eng) > *Sent:* 19 December 2018 15:22 > *To:* openstack-dev at lists.openstack.org > *Subject:* [networking-ovs-dpdk] Issue creating br-ex... > > Hello > > Trying to re-run a Queens DPDK all-in-one using devstack which I built > in August and hitting issues. > > The local.conf is identical between the two machines except I had to > take the “stable/queens” off the end of the “networking-ovs-dpdk” plugin > line as that no longer appears to work. > > The installation seems to proceed until it gets to setting the ip mtu on > br-ex. > > I’m not using br-ex.  I’ve declared OVS bridge mappings in the local.conf: > > #Dual socket platform with 16GB RAM,3072*2048kB hugepages leaves ~4G for > the system. > > OVS_NUM_HUGEPAGES=3072 > > #Dual socket platform with 64GB RAM,14336*2048kB hugepages leaves ~6G > for the system. > > #OVS_NUM_HUGEPAGES=14336 > > OVS_DATAPATH_TYPE=netdev > > OVS_LOG_DIR=/opt/stack/logs > > #OVS_DPDK_PORT_MAPPINGS=p1p1:br-dpdk1,p1p2:br-dpdk2,p2p1:br-dpdk3,p2p2:br-dpdk4 > > OVS_DPDK_PORT_MAPPINGS=p6p1:br-dpdk1,p6p2:br-dpdk2 > > #OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2,physnet3:br-dpdk3,physnet4:br-dpdk4 > > OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2 > > [[post-config|$NOVA_CONF]] > > [DEFAULT] > > firewall_driver=nova.virt.firewall.NoopFirewallDriver > > scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter > > [[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]] > > [OVS] > > datapath_type=netdev > > [ml2_type_flat] > > #flat_networks=physnet1,physnet2,physnet3,physnet4 > > flat_networks=physnet1,physnet2 > > I cannot stress again how identical these systems are – same hardware, > same base OS install (CentOS 7.5).   I was (maybe erroneously!) thinking > that if I had it devstack working on one system, having an identical > system would be a piece of cake to install. > > This is the installation error: > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:21  local > bridge=br-ex > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:22  local > 'addbr_cmd=sudo ovs-vsctl -- --may-exist add-br br-ex' > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:24  '[' > netdev '!=' system ']' > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:25 > addbr_cmd='sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge > br-ex datapath_type=netdev' > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:28  sudo > ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex > datapath_type=netdev Have you tried running this by hand on the system and see what happens? 'sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev' It works for me locally, creating br-ex. Perhaps there is some delay on your system? But I would expect the call wouldn't return successfully then. Or perhaps I'm mis-understanding and you meant to set PUBLIC_BRIDGE in your local.conf as well? Short of that you should look at what's changed in the relevant files in the devstack tree to see if it was caused by a recent change. -Brian > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_public_bridge:119 > set_mtu br-ex 1500 > > +functions:set_mtu:750                     local dev=br-ex > > +functions:set_mtu:751                     local mtu=1500 > > +functions:set_mtu:752                     sudo ip link set mtu 1500 dev > br-ex > > Cannot find device "br-ex" > > +functions:set_mtu:1                       exit_trap > > +./stack.sh:exit_trap:522                  local r=1 > > ++./stack.sh:exit_trap:523                  jobs -p > > +./stack.sh:exit_trap:523                  jobs= > > +./stack.sh:exit_trap:526                  [[ -n '' ]] > > +./stack.sh:exit_trap:532                  '[' -f /tmp/tmp.Dzbqzlk2fs ']' > > +./stack.sh:exit_trap:533                  rm /tmp/tmp.Dzbqzlk2fs > > +./stack.sh:exit_trap:537                  kill_spinner > > +./stack.sh:kill_spinner:432               '[' '!' -z '' ']' > > +./stack.sh:exit_trap:539                  [[ 1 -ne 0 ]] > > +./stack.sh:exit_trap:540                  echo 'Error on exit' > > Error on exit > > +./stack.sh:exit_trap:542                  type -p generate-subunit > > +./stack.sh:exit_trap:543                  generate-subunit 1545230781 > 1747 fail > > +./stack.sh:exit_trap:545                  [[ -z /opt/stack/logs/screen ]] > > +./stack.sh:exit_trap:548 > /home/stack/devstack/tools/worlddump.py -d /opt/stack/logs/screen > > Can someone explain what is going on here please? > > Thanks > > > David > From mike.carden at gmail.com Thu Dec 20 01:32:16 2018 From: mike.carden at gmail.com (Mike Carden) Date: Thu, 20 Dec 2018 12:32:16 +1100 Subject: [Openstack] unexpected distribution of compute instances in queens In-Reply-To: References: <815799a8-c2d1-39b4-ba4a-8cc0f0d7b5cf@gmail.com> <4273f2ee3117b06cb52f553e2bdbb2b20a816039.camel@redhat.com> Message-ID: Just an update on this. I have found a 'fix' that is more like a workaround in that I still don't know what causes the problem. So, to start with, all VMs are being spawned on a single node and while I can live migrate to another node, the scheduler never sends VMs there. To fix this, I disable the hypervisor on the node that is getting all the VMs, then I spawn a bunch of VMs. They go to the node that still has its hypervisor enabled. Then I re-enable the disabled hypervisor and spawn a bunch of VMs. Now they get evenly split across the two nodes. Fixed. -- MC -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundar.nadathur at intel.com Thu Dec 20 02:01:27 2018 From: sundar.nadathur at intel.com (Nadathur, Sundar) Date: Wed, 19 Dec 2018 18:01:27 -0800 Subject: [dev] How to develop changes in a series Message-ID: <4c62b826-7124-b8c4-e28e-3441203b7371@intel.com> On Dec 5, 2018, Eric fried wrote: > This started off as a response to some questions Sundar asked, but Ithought it might be interesting/useful for new[er] OpenStack developers at large, so broadcasting. Most of this is familiar material for those used to github process. The 'git restack' part is interesting, though it seems a lot like 'git rebase -i'. Eric answered far more than what I asked. Thanks, Eric. Regards, Sundar From kor.jmlim at gmail.com Thu Dec 20 02:14:12 2018 From: kor.jmlim at gmail.com (Jea-Min Lim) Date: Thu, 20 Dec 2018 11:14:12 +0900 Subject: [devstack][neutron] truble with setting local.conf with neutron In-Reply-To: <0165F120-FF53-4C2C-A51E-9D3851DF41CB@redhat.com> References: <0165F120-FF53-4C2C-A51E-9D3851DF41CB@redhat.com> Message-ID: Thank you for sharing local.conf. :) Regards, 2018년 12월 19일 (수) 오전 4:41, Slawomir Kaplonski 님이 작성: > Hi, > > I’m using local.conf like: http://paste.openstack.org/show/737595/ and it > works perfectly fine for me. > Config of my network interfaces on vm looks like on > http://paste.openstack.org/show/737596/ > > — > Slawek Kaplonski > Senior software engineer > Red Hat > > > Wiadomość napisana przez Jea-Min Lim w dniu > 18.12.2018, o godz. 18:37: > > > > Dear all, > > > > I`m trying to test neutron with qos module using devstack in OpenStack > pike in a single VM environment. > > > > However, I can`t figure out how to run devstack with my local.conf[1]. > > > > While configuring network and bridges, devstack lost connection to > outside VM. > > As a result, devstack couldn`t complete settings. > > > > My local.conf example is based on doc[2]. > > > > If you have any comments on my local.conf, reply in this mail or, if you > know the working configuration, it would be glad to share with me. > > > > Regards, > > > > [1] http://paste.openstack.org/show/737586/ > > [2] https://docs.openstack.org/devstack/latest/guides/neutron.html > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Thu Dec 20 04:29:18 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 20 Dec 2018 04:29:18 +0000 Subject: [dev] How to develop changes in a series In-Reply-To: <4c62b826-7124-b8c4-e28e-3441203b7371@intel.com> References: <4c62b826-7124-b8c4-e28e-3441203b7371@intel.com> Message-ID: <20181220042918.i4jhvqgux5uhgchy@yuggoth.org> On 2018-12-19 18:01:27 -0800 (-0800), Nadathur, Sundar wrote: [...] > Most of this is familiar material for those used to github process. The 'git > restack' part is interesting, though it seems a lot like 'git rebase -i'. [...] That's precisely what it is, plus a little scripting to figure out how to identify the last commit in your history in common with the remote branch so that you don't inadvertently rebase onto a newer branch state and unnecessarily muddy the subsequent interdiff for your reviewers. -- 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 Dave.Chen at Dell.com Thu Dec 20 05:28:30 2018 From: Dave.Chen at Dell.com (Dave.Chen at Dell.com) Date: Thu, 20 Dec 2018 05:28:30 +0000 Subject: [ironic][neutron] Baremetal node cannot get back IP address from neutron Message-ID: Hi all, I have setup ironic with devstack, initially, there are three fake nodes and I could successfully create a server, access to the server with the IP assigned from neutron as well, so I guess the configuration should be good, then I move to a real baremetal node, and want to do the same thing, so I issued the below command, $ openstack server create --flavor baremetal --image ${IMAGE_NAME} --key-name local realnode The node could power on and start to boot with PXE, two MAC address has been bound to the node, and seen from the BOOT screen the NIC was up but was pending on configuration and then exit, seem like it cannot get the IP address back from the Neutron. On the Ironic server, I can see the DHCP request from the baremetal node, but there is no ACK no IP offering here. $ sudo tcpdump -i enp0s3 -n port 67 and port 68 ... 18:21:08.112923 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 50:6b:4b:df:35:87, length 394 18:21:12.143679 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 50:6b:4b:df:35:87, length 394 ... Also tried to capture the traffic on the switch, it shows the request has been sent as well but no IP offering. dnsmasq is running, $ ps -ef | grep dnsm dnsmasq --no-hosts --strict-order --except-interface=lo --pid-file=/opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4-d42914af536c/pid --dhcp-hostsfile=/opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4-d42914af536c/host --addn-hosts=/opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4-d42914af536c/addn_hosts --dhcp-optsfile=/opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4-d42914af536c/opts --dhcp-leasefile=/opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4-d42914af536c/leases --dhcp-match=set:ipxe,175 --bind-interfaces --interface=tap4c76340a-7f --dhcp-range=set:tag1,10.0.0.0,static,255.255.255.192,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=64 --conf-file= --domain=openstacklocal The data in neutron looks like below, $ /opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4-d42914af536c/host fa:16:3e:43:85:35,host-10-0-0-1.openstacklocal,10.0.0.1 fa:16:3e:19:60:19,host-10-0-0-2.openstacklocal,10.0.0.2 52:54:00:72:0e:a8,host-10-0-0-9.openstacklocal,10.0.0.9,set:348f921b-62c3-451f-884c-d630ae8f60b9 IP seems has been assigned to the baremetal node, but after the node changed its status to "Maintenance", the entry removed from this file, and the entry never get into the "lease" file, $ /opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4-d42914af536c/leases 1545344481 52:54:00:72:0e:a8 10.0.0.9 host-10-0-0-9 01:52:54:00:72:0e:a8 The only entry listed here is for the fake node. Could anyone kindly give me any suggestion where to looking into? How can I identify the root cause? Many thanks! Best Regards, Dave Chen From hyangii at gmail.com Thu Dec 20 05:32:53 2018 From: hyangii at gmail.com (Jae Sang Lee) Date: Thu, 20 Dec 2018 14:32:53 +0900 Subject: [opensetack-discuss][Openstack-Helm] Patches for upgrade rally Message-ID: Hi, I recently watched IRC talk about revert rally commit. I posted a patch[1] to upgrade rally last October. This is because openstack-helm is using a very old rally, which caused a dependency error when creating another image. I also changed the helm-toolkit of openstack-helm-infra because we need to change the rally init script.[2] After patch # 1 has been applied first, patch # 2 has to be merged. Only patch # 2 has been merged. Failure of all chart helm test or patch # 2 has been reverted again. So I updated the patch to upgrade rally today[3][4]. I hope [3] merges first. After that, [4] should be merged. Thanks. Jaesang [1] https://review.openstack.org/#/c/586783/1 [2] https://review.openstack.org/#/c/607822/ [3] https://review.openstack.org/#/c/586783 [4] https://review.openstack.org/626490 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomi.juvonen at nokia.com Thu Dec 20 05:42:41 2018 From: tomi.juvonen at nokia.com (Juvonen, Tomi (Nokia - FI/Espoo)) Date: Thu, 20 Dec 2018 05:42:41 +0000 Subject: [nova][ops] Trying to get per-instance live migration timeout action spec unstuck In-Reply-To: <4f696e01-9c04-2da9-34b6-86bdce0c6cdd@gmail.com> References: <4f696e01-9c04-2da9-34b6-86bdce0c6cdd@gmail.com> Message-ID: > Given all of this, are these reasonable compromises to continue trying > to drive this feature forward, and more importantly, are other operators > looking to see this functionality added to nova? Huawei public cloud > operators want it because they routinely are doing live migrations as > part of maintenance activities and want to be able to control these > values per-instance. I assume there are other deployments that would > like the same. I would say that any Telco would be very happy to have this in Nova. Br, Tomi From yongli.he at intel.com Thu Dec 20 05:48:56 2018 From: yongli.he at intel.com (yonglihe) Date: Thu, 20 Dec 2018 13:48:56 +0800 Subject: [nova][dev] tracking spec reviews ahead of spec freeze In-Reply-To: <67c6b11f-a6a5-67cf-1b31-8ae8b5e580ae@gmail.com> References: <67c6b11f-a6a5-67cf-1b31-8ae8b5e580ae@gmail.com> Message-ID: <48646e88-23f1-b302-aced-ca91fe634724@intel.com> On 2018/12/20 上午12:49, melanie witt wrote: > Hey all, > > Spec freeze is coming up shortly after the holidays on January 10, > 2019. Since we don't have much time after returning to work next year > before spec freeze, let's keep track of specs that are close to > approval or otherwise candidates to focus on in the last stretch > before freeze. > > Here's an etherpad where I've collected a list of possible candidates > for focus the first week of January. Feel free to add notes and specs > I might have missed: > > https://etherpad.openstack.org/p/nova-stein-blueprint-spec-freeze I also want some movement on show NUMA information one: https://review.openstack.org/#/c/612256/8 Thanks. Yongli He > > Cheers, > -melanie > > From Dave.Chen at Dell.com Thu Dec 20 05:56:27 2018 From: Dave.Chen at Dell.com (Dave.Chen at Dell.com) Date: Thu, 20 Dec 2018 05:56:27 +0000 Subject: [ironic][neutron] Baremetal node cannot get back IP address from neutron In-Reply-To: References: Message-ID: <8daf207a0d334d148dbefd0c7ab8d797@KULX13MDC117.APAC.DELL.COM> Forgot to mention that OpenStack I am using is pike stable release, thanks! Best Regards, Dave Chen > -----Original Message----- > From: Chen2, Dave > Sent: Thursday, December 20, 2018 1:29 PM > To: openstack-discuss at lists.openstack.org > Subject: [ironic][neutron] Baremetal node cannot get back IP address from > neutron > > > > Hi all, > > I have setup ironic with devstack, initially, there are three fake nodes and I > could successfully create a server, access to the server with the IP assigned > from neutron as well, so I guess the configuration should be good, then I > move to a real baremetal node, and want to do the same thing, so I issued > the below command, > > $ openstack server create --flavor baremetal --image ${IMAGE_NAME} -- > key-name local realnode > > The node could power on and start to boot with PXE, two MAC address has > been bound to the node, and seen from the BOOT screen the NIC was up > but was pending on configuration and then exit, seem like it cannot get the > IP address back from the Neutron. > > On the Ironic server, I can see the DHCP request from the baremetal node, > but there is no ACK no IP offering here. > $ sudo tcpdump -i enp0s3 -n port 67 and port 68 ... > 18:21:08.112923 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request > from 50:6b:4b:df:35:87, length 394 > 18:21:12.143679 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request > from 50:6b:4b:df:35:87, length 394 ... > Also tried to capture the traffic on the switch, it shows the request has been > sent as well but no IP offering. > > dnsmasq is running, > $ ps -ef | grep dnsm > dnsmasq --no-hosts --strict-order --except-interface=lo --pid- > file=/opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4- > d42914af536c/pid --dhcp- > hostsfile=/opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4- > d42914af536c/host --addn-hosts=/opt/stack/data/neutron/dhcp/ca541e23- > 629b-440d-9ef4-d42914af536c/addn_hosts --dhcp- > optsfile=/opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4- > d42914af536c/opts --dhcp- > leasefile=/opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4- > d42914af536c/leases --dhcp-match=set:ipxe,175 --bind-interfaces -- > interface=tap4c76340a-7f --dhcp- > range=set:tag1,10.0.0.0,static,255.255.255.192,86400s --dhcp-option- > force=option:mtu,1450 --dhcp-lease-max=64 --conf-file= -- > domain=openstacklocal > > The data in neutron looks like below, > $ /opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4- > d42914af536c/host > fa:16:3e:43:85:35,host-10-0-0-1.openstacklocal,10.0.0.1 > fa:16:3e:19:60:19,host-10-0-0-2.openstacklocal,10.0.0.2 > 52:54:00:72:0e:a8,host-10-0-0-9.openstacklocal,10.0.0.9,set:348f921b-62c3- > 451f-884c-d630ae8f60b9 > > IP seems has been assigned to the baremetal node, but after the node > changed its status to "Maintenance", the entry removed from this file, and > the entry never get into the "lease" file, > > $ /opt/stack/data/neutron/dhcp/ca541e23-629b-440d-9ef4- > d42914af536c/leases > 1545344481 52:54:00:72:0e:a8 10.0.0.9 host-10-0-0-9 01:52:54:00:72:0e:a8 > > The only entry listed here is for the fake node. > > > Could anyone kindly give me any suggestion where to looking into? How can I > identify the root cause? > > > Many thanks! > > Best Regards, > Dave Chen > From melwittt at gmail.com Thu Dec 20 06:13:18 2018 From: melwittt at gmail.com (melanie witt) Date: Wed, 19 Dec 2018 22:13:18 -0800 Subject: [nova][dev] tracking spec reviews ahead of spec freeze In-Reply-To: <48646e88-23f1-b302-aced-ca91fe634724@intel.com> References: <67c6b11f-a6a5-67cf-1b31-8ae8b5e580ae@gmail.com> <48646e88-23f1-b302-aced-ca91fe634724@intel.com> Message-ID: On Thu, 20 Dec 2018 13:48:56 +0800, Yonglihe wrote: > On 2018/12/20 上午12:49, melanie witt wrote: >> Hey all, >> >> Spec freeze is coming up shortly after the holidays on January 10, >> 2019. Since we don't have much time after returning to work next year >> before spec freeze, let's keep track of specs that are close to >> approval or otherwise candidates to focus on in the last stretch >> before freeze. >> >> Here's an etherpad where I've collected a list of possible candidates >> for focus the first week of January. Feel free to add notes and specs >> I might have missed: >> >> https://etherpad.openstack.org/p/nova-stein-blueprint-spec-freeze > I also want some movement on show NUMA information one: > > https://review.openstack.org/#/c/612256/8 Thanks, I've added it to the simple/small specs section. -melanie From zbitter at redhat.com Thu Dec 20 07:01:31 2018 From: zbitter at redhat.com (Zane Bitter) Date: Thu, 20 Dec 2018 20:01:31 +1300 Subject: queens heat db deadlock In-Reply-To: <82a140e4-55b7-453f-593d-d7423ac34e64@gmail.com> References: <38bae882-b4ac-4b55-5345-e27edbd582f3@redhat.com> <82a140e4-55b7-453f-593d-d7423ac34e64@gmail.com> Message-ID: <94442ceb-1278-a573-1456-9f44204a8ccd@redhat.com> On 19/12/18 6:49 AM, Jay Pipes wrote: > On 12/18/2018 11:06 AM, Mike Bayer wrote: >> On Tue, Dec 18, 2018 at 12:36 AM Ignazio Cassano >> wrote: >>> >>> Yes, I  tried on yesterday and this workaround solved. >>> Thanks >>> Ignazio >> >> OK, so that means this "deadlock" is not really a deadlock but it is a >> write-conflict between two Galera masters.      I have a long term >> goal to being relaxing this common requirement that Openstack apps >> only refer to one Galera master at a time.    If this is a particular >> hotspot for Heat (no pun intended) can we pursue adding a transaction >> retry decorator for this operation?  This is the standard approach for >> other applications that are subject to galera multi-master writeset >> conflicts such as Neutron. The weird thing about this issue is that we actually have a retry decorator on the operation that I assume is the problem. It was added in Queens and largely fixed this issue in the gate: https://review.openstack.org/#/c/521170/1/heat/db/sqlalchemy/api.py > Correct. > > Heat doesn't use SELECT .. FOR UPDATE does it? That's also a big cause > of the aforementioned "deadlocks". AFAIK, no. In fact we were quite careful to design stuff that is expected to be subject to write contention to use UPDATE ... WHERE (by doing query().filter_by().update() in sqlalchemy), but it turned out to be those very statements that were most prone to causing deadlocks in the gate (i.e. we added retry decorators in those two places and the failures went away), according to me in the commit message for that patch: https://review.openstack.org/521170 Are we Doing It Wrong(TM)? thanks, Zane. > Best, > -jay > >>> >>> Il giorno Lun 17 Dic 2018 20:38 Joe Topjian ha >>> scritto: >>>> >>>> Hi Ignazio, >>>> >>>> Do you currently have HAProxy configured to route requests to >>>> multiple MariaDB nodes? If so, as a workaround, try doing an >>>> active/backup configuration where all but 1 node is configured as an >>>> HAProxy "backup". >>>> >>>> Thanks, >>>> Joe >>>> >>>> >>>> >>>> On Sun, Dec 16, 2018 at 10:46 PM Ignazio Cassano >>>> wrote: >>>>> >>>>> Hello Zane, it happens also when I create a magnum cluster . >>>>> My mariadb cluster is behind haproxy. >>>>> Do you need any other info? >>>>> Thanks >>>>> Ignazio >>>>> >>>>> >>>>> Il giorno Lun 17 Dic 2018 00:28 Zane Bitter ha >>>>> scritto: >>>>>> >>>>>> On 14/12/18 4:06 AM, Ignazio Cassano wrote: >>>>>>> Hi All, >>>>>>> I installed queens on centos 7. >>>>>>> Heat seems to work fine with templates I wrote but when I create >>>>>>> magnum >>>>>>> cluster >>>>>>> I often face with db deadlock in heat-engine log: >>>>>> >>>>>> The stacktrace below is in stack delete, so do you mean that the >>>>>> problem >>>>>> occurs when deleting a Magnum cluster, or can it occur any time >>>>>> with a >>>>>> magnum cluster? >>>>>> >>>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >>>>>>> Traceback (most >>>>>>> recent call last): >>>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource   File >>>>>>> "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line >>>>>>> 918, in >>>>>>> _action_recorder >>>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource     yield >>>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource   File >>>>>>> "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line >>>>>>> 2035, >>>>>>> in delete >>>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >>>>>>> *action_args) >>>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource   File >>>>>>> "/usr/lib/python2.7/site-packages/heat/engine/scheduler.py", line >>>>>>> 346, >>>>>>> in wrapper >>>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource     step = >>>>>>> next(subtask) >>>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource   File >>>>>>> "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line >>>>>>> 977, in >>>>>>> action_handler_task >>>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource     done = >>>>>>> check(handler_data) >>>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource   File >>>>>>> "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", >>>>>>> >>>>>>> line 587, in check_delete_complete >>>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource     return >>>>>>> self._check_status_complete(self.DELETE) >>>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource   File >>>>>>> "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", >>>>>>> >>>>>>> line 454, in _check_status_complete >>>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >>>>>>> action=action) >>>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >>>>>>> ResourceFailure: resources[0]: (pymysql.err.InternalError) (1213, >>>>>>> u'Deadlock found when trying to get lock; try restarting >>>>>>> transaction') >>>>>>> (Background on this error at: http://sqlalche.me/e/2j85) >>>>>>> 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource >>>>>>> 2018-12-13 11:48:46.030 89597 INFO heat.engine.stack >>>>>>> [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] >>>>>>> Stack DELETE FAILED >>>>>>> (swarm-clustergp27-ebhsalhb4bop-swarm_primary_master-tzgkh3ncmymw): >>>>>>> Resource DELETE failed: resources[0]: (pymysql.err.InternalError) >>>>>>> (1213, >>>>>>> u'Deadlock found when trying to get lock; try restarting >>>>>>> transaction') >>>>>>> (Background on this error at: http://sqlalche.me/e/2j85) >>>>>>> 2018-12-13 11:48:46.844 89595 INFO heat.engine.resource >>>>>>> [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] >>>>>>> DELETE: ResourceGroup "swarm_primary_master" >>>>>>> [6984db3c-3ac1-4afc-901f-21b3e7f230a7] Stack >>>>>>> "swarm-clustergp27-ebhsalhb4bop" >>>>>>> [b43256fa-52e2-4613-ac15-63fd9340a8be] >>>>>>> >>>>>>> >>>>>>> I read this issue was solved in heat version 10 but seems not. >>>>>> >>>>>> The patch for bug 1732969, which is in Queens, is probably the fix >>>>>> you're referring to: https://review.openstack.org/#/c/521170/1 >>>>>> >>>>>> The traceback in that bug included the SQL statement that was >>>>>> failing. >>>>>> I'm not sure if that isn't included in your traceback because >>>>>> SQLAlchemy >>>>>> didn't report it, or if it's because that traceback is actually >>>>>> from the >>>>>> parent stack. If you have a traceback from the original failure in >>>>>> the >>>>>> child stack that would be useful. If there's a way to turn on more >>>>>> detailed reporting of errors in SQLAlchemy that would also be useful. >>>>>> >>>>>> Since this is a delete, it's possible that we need a >>>>>> retry-on-deadlock >>>>>> on the resource_delete() function also (though resource_update() is >>>>>> actually used more during a delete to update the status). >>>>>> >>>>>> - ZB >>>>>> >> > From ellorent at redhat.com Thu Dec 20 07:07:56 2018 From: ellorent at redhat.com (Felix Enrique Llorente Pastora) Date: Thu, 20 Dec 2018 08:07:56 +0100 Subject: [tripleo][ci] Reducing merge time by moving nv job to experimental In-Reply-To: References: Message-ID: The problem with > experimental is that it requires folks to know to run them (which > generally does not happen for our project). So we have two options here: - Make experimental pipeline run on reviews directly without the "check-experimental" comment. - Create a new pipeline "draf" pipeline at infra, that runs WIP jobs or problematic jobs without interfering in normal production "check" pipeline. What do you think ? On Wed, Dec 19, 2018 at 3:48 PM Alex Schultz wrote: > On Wed, Dec 19, 2018 at 7:44 AM Alex Schultz wrote: > > > > On Wed, Dec 19, 2018 at 7:34 AM Felix Enrique Llorente Pastora > > wrote: > > > > > > Hello, > > > > > > To reduce merge time, would be nice from a review to go from check > pipeline to gate pipeline without waiting for non-voting jobs, one way to > do that is changing non-voting jobs at different pipelien like experimental > one, so we have their result but don't wait for them to change to gate > pipepeline. > > > > > > > The goal should be to get them to voting. The problem with > > experimental is that it requires folks to know to run them (which > > generally does not happen for our project). We currently have the > > scenario jobs as non-voting because of capacity problems but we still > > need the coverage so I'm not keen on moving them to non-voting. I'd > > err experimental not non-voting. > > > rather we spend the time to land the standalone versions and get them > > voting again. > > > > Thanks, > > -Alex > > > > > -- > > > Quique Llorente > > > > > > Openstack TripleO CI > -- Quique Llorente Openstack TripleO CI -------------- next part -------------- An HTML attachment was scrubbed... URL: From phuongnh at vn.fujitsu.com Thu Dec 20 08:26:12 2018 From: phuongnh at vn.fujitsu.com (Nguyen Hung, Phuong) Date: Thu, 20 Dec 2018 08:26:12 +0000 Subject: [oslo][migrator] RFE Configuration mapping tool for upgrade - coordinate teams In-Reply-To: <4c6d85cc-a566-f981-433e-992a7433a236@nemebean.com> References: <4c6d85cc-a566-f981-433e-992a7433a236@nemebean.com> Message-ID: Hi Ben, I am apology that in last month we do not have much time maintaining the code. > but if no one's going to use it then I'd rather cut our > losses than continue pouring time into it. I agree, we will wait for the community to decide the need for the feature. In the near future, we do not have ability to maintain the code. If anyone has interest to continue maintaining the patch, we will support with document, reviewing... in our possibility. Thanks, Phuong. -----Original Message----- From: Ben Nemec [mailto:openstack at nemebean.com] Sent: Thursday, December 20, 2018 12:08 AM To: Herve Beraud; openstack-discuss at lists.openstack.org Subject: Re: [oslo][migrator] RFE Configuration mapping tool for upgrade - coordinate teams I'll reiterate what I said in the meeting for the broader audience: I'm unclear how much need there is for a tool of this nature. As you mentioned, deployment tools all have config management bits already that will be handling updates and upgrade. The only instance where I could see this being used is if someone were writing their configs by hand, and I'm skeptical that happens very often with a system as complex as OpenStack. When there was a team that was interested in implementing and using this I was fine with adding it, but if the people who wanted the tool are no longer around then we have no one to maintain it or assist with the adoption of some of the new features it adds. Given my concerns above, I don't want to add a large feature that the Oslo team will then have to maintain. We really don't have the capacity to be taking on lower priority work, especially if there's no one saying "yeah, I'll use that". I've left a comment on the first patch in the series[1] (and marked it WIP) to ask if there is still interest in this feature. Of course, if anyone reading this has interest please feel free to indicate that as well. It's unfortunate because I and a number of the other Oslo contributors have put a significant amount of time into the design and implementation of this tool, but if no one's going to use it then I'd rather cut our losses than continue pouring time into it. Thanks. -Ben 1: https://review.openstack.org/#/c/526314 On 12/18/18 9:07 AM, Herve Beraud wrote: > Hey teams, > > ## Summary > > The main goal of this thread is to coordinate teams to adopt the oslo > realease migrator tools and raise prior on this topics. > > ## History > > During the openstack submit in 2017 at Sydney a team from the Fujitsu > company propose a talk about how to > make fast forward upgrade from an openstack release to an another, and > present the state of art of the configuration migrator > inside openstack and the tools availables to do that. > > This team describe that for now, we have oslo.config generator tool to > show deprecated options in newer release > but they are still lacking some mapping configurations. > > After that the same team propose oslo.config specifications to improve > migrators. > > Where specifications was designed by the following reviews: > - https://review.openstack.org/#/c/520043/ > - https://review.openstack.org/#/c/526314/ > - https://review.openstack.org/#/c/526261/ > > The main goal of the proposed changes in these specs is to handle > configuration changes over releases: > - > https://specs.openstack.org/openstack/oslo-specs/specs/rocky/handle-config-changes.html > > These specifications describe that there should be some helper in > oslo.config for automatically adopt > new changes and help users manage their configuration files easily. > > Scenario: > Below is the proposed workflow that users can perform on old system to > generate new configuration for preparing upgrading to new release: >                                             +--------------+ > Old configuration  +-------->                  | >  (N-1 release)                    |     Oslo      | >                                             |    Config    +-------> > New configuration >       Namespaces  +-------->   Migrator |            (N release) >                                              |                  | >                                             +--------------+ >                                Running on new environment > > Since these specifications was validated, some patches was submitted by > the Fujitsu team to implement them: > https://review.openstack.org/#/q/status:open+project:openstack/oslo.config+branch:master+topic:migrator > > Details: >     - handle config mapping changes ( https://review.openstack.org/526314) >     - update valid value in choice list for the opt ( > https://review.openstack.org/603060) >     - update 'sample_default' instead of 'default' when migrating ( > https://review.openstack.org/606211) >     - use difflib to report mismatches in migrator tests ( > https://review.openstack.org/606210) >     - replace loop with dictionary lookup ( > https://review.openstack.org/606209) >     - replace 'upgrade_value' with 'convert_on_upgrade' ( > https://review.openstack.org/606207) > > Since these changes was proposed some peoples from the Fujitsu seems to > left the company and also seems to abandon this topic. > > During the last oslo meeting I had added this topic to the meeting > agenda to bring up this topic and to help us to move forward on it. > http://eavesdrop.openstack.org/meetings/oslo/2018/oslo.2018-12-17-15.00.log.html > http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000856.html > > ## Current state > > Some reviews was validated but some others need to be recovered due to the > lack of response about the original authors. > > I've submit some patches on reviews to help us to move on it. > > I've made some reviews based on the last comments and based on the asked > changes but now we need someone with an deeply > knowledge on oslo.config to validate the works. > > ## Others aspects > > Some tools like puppet/ansible/chef etc... already in use in openstack > can already handle migrators/upgrades and manage config changes. > > - Do we need to introduce an another tool like this one to do this job? > - How many people are manually writing OpenStack configs in the first place? > - Does it make sense to implement these changes? > > ## List of similar features on others projects > > - Tripleo provide a major release upgrade mechanisme ( > https://docs.openstack.org/tripleo-docs/latest/upgrade/developer/upgrades/major_upgrade.html) > - Openstack-Ansible also provide release upgrade mechanisme ( > https://docs.openstack.org/openstack-ansible/latest/admin/upgrades/major-upgrades.html) > - OpenStack fuel also propose specifications to upgrade configuration > and release ( > https://specs.openstack.org/openstack/fuel-specs/specs/7.0/upgrade-major-openstack-environment.html) > > This wiki can be useful to obtain the big picture of the release upgrade > management in openstack ( > https://wiki.openstack.org/wiki/Upgrade-with-minimal-downtime) > > I surely forgot some tools and alternatives, if you see something that > can be added here do not hesitate to reply to add it. > > ## Conclusion > > I bring up this topic to open a debate so do not hesitate react on this > topic by responding at this thread to help us to have a better big > picture to make the best choice. > > Thanks folks. > > Best regards. > > -- > 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 mark at stackhpc.com Thu Dec 20 08:49:12 2018 From: mark at stackhpc.com (Mark Goddard) Date: Thu, 20 Dec 2018 08:49:12 +0000 Subject: [storyboard] it's all gone quiet Message-ID: I haven't received an email from StoryBoard for a few weeks now. While I'm quite enjoying the silence, it's probably not productive... I'm subscribed to a few projects and have email notifications checked in preferences. Is it just me? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Thu Dec 20 10:29:03 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 20 Dec 2018 19:29:03 +0900 Subject: [dev][qa] Cancelling QA Office Hour for next two weeks Message-ID: <167cb29569c.12558d3ec83087.7784378938182642021@ghanshyammann.com> Hello Everyone, I will be on vacation from 24th Dec till 9th Jan, so cancelling the QA office hour for the next two weeks (27th Dec and 3rd Jan). We will resume it from 10th Jan. -gmann From hberaud at redhat.com Thu Dec 20 10:41:11 2018 From: hberaud at redhat.com (Herve Beraud) Date: Thu, 20 Dec 2018 11:41:11 +0100 Subject: [oslo][migrator] RFE Configuration mapping tool for upgrade - coordinate teams In-Reply-To: References: <4c6d85cc-a566-f981-433e-992a7433a236@nemebean.com> Message-ID: Le jeu. 20 déc. 2018 à 09:26, Nguyen Hung, Phuong a écrit : > Hi Ben, > > I am apology that in last month we do not have much time maintaining the > code. > > > but if no one's going to use it then I'd rather cut our > > losses than continue pouring time into it. > > I agree, we will wait for the community to decide the need for the > feature. > In the near future, we do not have ability to maintain the code. If anyone > has interest to continue maintaining the patch, we will support with > document, > reviewing... in our possibility. > I can help you to maintain the code if needed. Personaly I doesn't need this feature so I agree Ben and Doug point of view. We need to measure how many this feature is useful and if it make sense to support and maintain more code in the future related to this feature without any usages behind that. > Thanks, > Phuong. > > -----Original Message----- > From: Ben Nemec [mailto:openstack at nemebean.com] > Sent: Thursday, December 20, 2018 12:08 AM > To: Herve Beraud; openstack-discuss at lists.openstack.org > Subject: Re: [oslo][migrator] RFE Configuration mapping tool for upgrade - > coordinate teams > > I'll reiterate what I said in the meeting for the broader audience: > > I'm unclear how much need there is for a tool of this nature. As you > mentioned, deployment tools all have config management bits already that > will be handling updates and upgrade. The only instance where I could > see this being used is if someone were writing their configs by hand, > and I'm skeptical that happens very often with a system as complex as > OpenStack. > > When there was a team that was interested in implementing and using this > I was fine with adding it, but if the people who wanted the tool are no > longer around then we have no one to maintain it or assist with the > adoption of some of the new features it adds. Given my concerns above, I > don't want to add a large feature that the Oslo team will then have to > maintain. We really don't have the capacity to be taking on lower > priority work, especially if there's no one saying "yeah, I'll use that". > > I've left a comment on the first patch in the series[1] (and marked it > WIP) to ask if there is still interest in this feature. Of course, if > anyone reading this has interest please feel free to indicate that as well. > > It's unfortunate because I and a number of the other Oslo contributors > have put a significant amount of time into the design and implementation > of this tool, but if no one's going to use it then I'd rather cut our > losses than continue pouring time into it. > > Thanks. > > -Ben > > 1: https://review.openstack.org/#/c/526314 > > On 12/18/18 9:07 AM, Herve Beraud wrote: > > Hey teams, > > > > ## Summary > > > > The main goal of this thread is to coordinate teams to adopt the oslo > > realease migrator tools and raise prior on this topics. > > > > ## History > > > > During the openstack submit in 2017 at Sydney a team from the Fujitsu > > company propose a talk about how to > > make fast forward upgrade from an openstack release to an another, and > > present the state of art of the configuration migrator > > inside openstack and the tools availables to do that. > > > > This team describe that for now, we have oslo.config generator tool to > > show deprecated options in newer release > > but they are still lacking some mapping configurations. > > > > After that the same team propose oslo.config specifications to improve > > migrators. > > > > Where specifications was designed by the following reviews: > > - https://review.openstack.org/#/c/520043/ > > - https://review.openstack.org/#/c/526314/ > > - https://review.openstack.org/#/c/526261/ > > > > The main goal of the proposed changes in these specs is to handle > > configuration changes over releases: > > - > > > https://specs.openstack.org/openstack/oslo-specs/specs/rocky/handle-config-changes.html > > > > These specifications describe that there should be some helper in > > oslo.config for automatically adopt > > new changes and help users manage their configuration files easily. > > > > Scenario: > > Below is the proposed workflow that users can perform on old system to > > generate new configuration for preparing upgrading to new release: > > +--------------+ > > Old configuration +--------> | > > (N-1 release) | Oslo | > > | Config +-------> > > New configuration > > Namespaces +--------> Migrator | (N release) > > | | > > +--------------+ > > Running on new environment > > > > Since these specifications was validated, some patches was submitted by > > the Fujitsu team to implement them: > > > https://review.openstack.org/#/q/status:open+project:openstack/oslo.config+branch:master+topic:migrator > > > > Details: > > - handle config mapping changes ( > https://review.openstack.org/526314) > > - update valid value in choice list for the opt ( > > https://review.openstack.org/603060) > > - update 'sample_default' instead of 'default' when migrating ( > > https://review.openstack.org/606211) > > - use difflib to report mismatches in migrator tests ( > > https://review.openstack.org/606210) > > - replace loop with dictionary lookup ( > > https://review.openstack.org/606209) > > - replace 'upgrade_value' with 'convert_on_upgrade' ( > > https://review.openstack.org/606207) > > > > Since these changes was proposed some peoples from the Fujitsu seems to > > left the company and also seems to abandon this topic. > > > > During the last oslo meeting I had added this topic to the meeting > > agenda to bring up this topic and to help us to move forward on it. > > > http://eavesdrop.openstack.org/meetings/oslo/2018/oslo.2018-12-17-15.00.log.html > > > http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000856.html > > > > ## Current state > > > > Some reviews was validated but some others need to be recovered due to > the > > lack of response about the original authors. > > > > I've submit some patches on reviews to help us to move on it. > > > > I've made some reviews based on the last comments and based on the asked > > changes but now we need someone with an deeply > > knowledge on oslo.config to validate the works. > > > > ## Others aspects > > > > Some tools like puppet/ansible/chef etc... already in use in openstack > > can already handle migrators/upgrades and manage config changes. > > > > - Do we need to introduce an another tool like this one to do this job? > > - How many people are manually writing OpenStack configs in the first > place? > > - Does it make sense to implement these changes? > > > > ## List of similar features on others projects > > > > - Tripleo provide a major release upgrade mechanisme ( > > > https://docs.openstack.org/tripleo-docs/latest/upgrade/developer/upgrades/major_upgrade.html > ) > > - Openstack-Ansible also provide release upgrade mechanisme ( > > > https://docs.openstack.org/openstack-ansible/latest/admin/upgrades/major-upgrades.html > ) > > - OpenStack fuel also propose specifications to upgrade configuration > > and release ( > > > https://specs.openstack.org/openstack/fuel-specs/specs/7.0/upgrade-major-openstack-environment.html > ) > > > > This wiki can be useful to obtain the big picture of the release upgrade > > management in openstack ( > > https://wiki.openstack.org/wiki/Upgrade-with-minimal-downtime) > > > > I surely forgot some tools and alternatives, if you see something that > > can be added here do not hesitate to reply to add it. > > > > ## Conclusion > > > > I bring up this topic to open a debate so do not hesitate react on this > > topic by responding at this thread to help us to have a better big > > picture to make the best choice. > > > > Thanks folks. > > > > Best regards. > > > > -- > > 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 thierry at openstack.org Thu Dec 20 10:48:15 2018 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 20 Dec 2018 11:48:15 +0100 Subject: [all] Please help document dependencies between services Message-ID: Hi everyone, As Jimmy announced[1] a couple of weeks ago, we need your help in compiling accurate dependency information between OpenStack services, to display in future versions of the openstack.org/software pages[2]. Each OpenStack service may have hard dependencies (can't work without) or soft dependencies (benefits of the presence of) on other services, and that is very useful information for users looking into various OpenStack components. You can help accurately document those, by proposing changes to the openstack/openstack-map repository[3], looking up your service in the openstack_components.yaml file and adding the following keys: dependencies: (for hard dependencies, when the service can't work without those other services) see-also: (for soft dependencies, when the service benefits of the presence of those other services) As an example, you can look at Octavia's entry[4]. Once we have that information compiled, we'll be able to publish it on the website, adding links between related services. Thanks in advance, [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000568.html [2] https://www.openstack.org/software/project-navigator/openstack-components#openstack-services [3] https://git.openstack.org/cgit/openstack/openstack-map/ [4] https://git.openstack.org/cgit/openstack/openstack-map/tree/openstack_components.yaml#n164 -- Thierry Carrez (ttx) From serverascode at gmail.com Thu Dec 20 12:12:51 2018 From: serverascode at gmail.com (Curtis) Date: Thu, 20 Dec 2018 07:12:51 -0500 Subject: [edge] Zero Touch Provisioning Message-ID: Hi, I've been looking through the docs I can find related to the edge working group, and I'm wondering if there has been any discussion/documentation of a Zero Touch Provisioning use case. I can't seem to find anything, but I may not be looking in the right place. Just wanted to double check and see what the current state is, if any. Thanks, Curtis -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.urdin at binero.se Thu Dec 20 12:55:13 2018 From: tobias.urdin at binero.se (Tobias Urdin) Date: Thu, 20 Dec 2018 13:55:13 +0100 Subject: [openstack-dev] [Neutron] Propose Ryan Tidwell for neutron-dynamic-routing core In-Reply-To: References: Message-ID: Not a core but super +1 Ryan has been awesome in solving many bugs seen recently in Neutron and it's related projects. Thanks Ryan! Best regards Tobias On 12/19/2018 08:00 PM, Miguel Lavalle wrote: > Hi Stackers, > > I want to nominate Ryan Tidwell (irc: tidwellr) as a core reviewer for > neutron-dynamic-routing > (https://github.com/openstack/neutron-dynamic-routing). Ryan has a > long history with everything L3 in Neutron. He started contributing > code back in 2014, helping to implement subnet pools > (https://review.openstack.org/#/c/148698/). Over the years he did > great work improving Neutron's IP address manager and was the driving > force in the creation and implementation of the > neutron-dynamic-routing project. After a hiatus of a few cycles, Ryan > came back to the community and has been very active adding support for > MP-BGP in neutron-dynamic-routing and the on boarding of subnets in > Neutron. The quality and number of his code reviews during the Stein > cycle are on par with members of the Neutron core team: > http://stackalytics.com/?module=neutron-group. > > I will keep this nomination open as customary. > > Thank you. > > Miguel From skaplons at redhat.com Thu Dec 20 13:02:53 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Thu, 20 Dec 2018 14:02:53 +0100 Subject: [openstack-dev] [Neutron] Propose Ryan Tidwell for neutron-dynamic-routing core In-Reply-To: References: Message-ID: <9F0ECAAE-40AD-4540-BC63-5F06E71B0C24@redhat.com> +1 — Slawek Kaplonski Senior software engineer Red Hat > Wiadomość napisana przez Miguel Lavalle w dniu 19.12.2018, o godz. 19:40: > > Hi Stackers, > > I want to nominate Ryan Tidwell (irc: tidwellr) as a core reviewer for neutron-dynamic-routing (https://github.com/openstack/neutron-dynamic-routing). Ryan has a long history with everything L3 in Neutron. He started contributing code back in 2014, helping to implement subnet pools (https://review.openstack.org/#/c/148698/). Over the years he did great work improving Neutron's IP address manager and was the driving force in the creation and implementation of the neutron-dynamic-routing project. After a hiatus of a few cycles, Ryan came back to the community and has been very active adding support for MP-BGP in neutron-dynamic-routing and the on boarding of subnets in Neutron. The quality and number of his code reviews during the Stein cycle are on par with members of the Neutron core team: http://stackalytics.com/?module=neutron-group. > > I will keep this nomination open as customary. > > Thank you. > > Miguel From jaypipes at gmail.com Thu Dec 20 13:03:29 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Thu, 20 Dec 2018 08:03:29 -0500 Subject: [edge] Zero Touch Provisioning In-Reply-To: References: Message-ID: <3a1ca5f4-0c3a-ae32-3e0b-b346cf653f65@gmail.com> On 12/20/2018 07:12 AM, Curtis wrote: > Hi, > > I've been looking through the docs I can find related to the edge > working group, and I'm wondering if there has been any > discussion/documentation of a Zero Touch Provisioning use case. I can't > seem to find anything, but I may not be looking in the right place. Just > wanted to double check and see what the current state is, if any. I take it that by "zero touch *provisioning*" (emphasis added to differentiate from zero *configuration* networking, you are referring to the ability for a new server to be rack-and-stacked in a site, powered on, and immediately register itself with either a local inventory management system or a remote one? In either case, the issue I foresee is that the firmware (or initial boot/ramdisk that comes from the factory or supply chain team) will need to have some program installed in it that sends out a request looking for some known/assumed inventory management service [1]. The thing that *responds* to such a request would, of course, need to be already installed and available either on a switch or a pre-installed machine pingable on the out-of-band network and already configured by the team that handles hardware inventory. I can see some vendors working on their own custom low-touch provisioning software -- and this software would likely end up depending on their own proprietary (or subscription-based) server software ala Red Hat's Satellite software [2]). But getting all the vendors to come together on a unified low-touch provisioning system? Chances are pretty slim, IMHO. Still, it's an interesting problem domain and I'd be interested in sharing thoughts and discussing it with others. Here at "Yahoo!/Oath/Verizon Media Group/Whatever we'll be called next month" we have custom software (and a bit of custom hardware!) that handles base hardware provisioning and I'm definitely interested in seeing if other shops that handle hundreds of thousands of baremetal machines are looking to collaborate in this area ("edge" or otherwise!). Best, -jay [1] this could be done via some custom DHCPDISCOVER/DHCPREQUEST bits I suppose -- which would require a DHCP client in the firmware/bootdisk -- but more likely would depend on the IPMI/BMC system in use for the hardware. As soon as IPMI/BMC comes into play, the extreme differences in OEM vendor support will rule out a generic workable solution here as many in the Ironic community will likely attest to [3]. If you can rely on a homogeneous set of hardware at edge sites, you might be able to put something together that just suits your company's need, however. [2] https://www.redhat.com/en/technologies/management/satellite [3] https://github.com/openstack/ironic/tree/master/ironic/drivers From fungi at yuggoth.org Thu Dec 20 13:07:04 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 20 Dec 2018 13:07:04 +0000 Subject: [storyboard][infra] it's all gone quiet In-Reply-To: References: Message-ID: <20181220130704.fpzkrwqmcgkdgexf@yuggoth.org> On 2018-12-20 08:49:12 +0000 (+0000), Mark Goddard wrote: > I haven't received an email from StoryBoard for a few weeks now. > While I'm quite enjoying the silence, it's probably not > productive... I'm subscribed to a few projects and have email > notifications checked in preferences. Is it just me? It appears that Rackspace has recently added the surrounding IPv4 /22 CIDR to the Spamhaus Policy Block List: https://www.spamhaus.org/pbl/query/PBL1660430 As a result, the receiving MTA is rejecting E-mail from the server destined for your domain. I have filed with Spamhaus to get a PBL exception added for this specific IP address, which should take effect within the next hour. Sorry to say, you'll probably start finding out about more bugs! ;) (Also, huge thanks for bringing this to our 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 jaypipes at gmail.com Thu Dec 20 13:07:34 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Thu, 20 Dec 2018 08:07:34 -0500 Subject: queens heat db deadlock In-Reply-To: <94442ceb-1278-a573-1456-9f44204a8ccd@redhat.com> References: <38bae882-b4ac-4b55-5345-e27edbd582f3@redhat.com> <82a140e4-55b7-453f-593d-d7423ac34e64@gmail.com> <94442ceb-1278-a573-1456-9f44204a8ccd@redhat.com> Message-ID: <028c4ec2-d6a7-d5a2-190d-91065d7231ee@gmail.com> On 12/20/2018 02:01 AM, Zane Bitter wrote: > On 19/12/18 6:49 AM, Jay Pipes wrote: >> On 12/18/2018 11:06 AM, Mike Bayer wrote: >>> On Tue, Dec 18, 2018 at 12:36 AM Ignazio Cassano >>> wrote: >>>> >>>> Yes, I  tried on yesterday and this workaround solved. >>>> Thanks >>>> Ignazio >>> >>> OK, so that means this "deadlock" is not really a deadlock but it is a >>> write-conflict between two Galera masters.      I have a long term >>> goal to being relaxing this common requirement that Openstack apps >>> only refer to one Galera master at a time.    If this is a particular >>> hotspot for Heat (no pun intended) can we pursue adding a transaction >>> retry decorator for this operation?  This is the standard approach for >>> other applications that are subject to galera multi-master writeset >>> conflicts such as Neutron. > > The weird thing about this issue is that we actually have a retry > decorator on the operation that I assume is the problem. It was added in > Queens and largely fixed this issue in the gate: > > https://review.openstack.org/#/c/521170/1/heat/db/sqlalchemy/api.py > >> Correct. >> >> Heat doesn't use SELECT .. FOR UPDATE does it? That's also a big cause >> of the aforementioned "deadlocks". > > AFAIK, no. In fact we were quite careful to design stuff that is > expected to be subject to write contention to use UPDATE ... WHERE (by > doing query().filter_by().update() in sqlalchemy), but it turned out to > be those very statements that were most prone to causing deadlocks in > the gate (i.e. we added retry decorators in those two places and the > failures went away), according to me in the commit message for that > patch: https://review.openstack.org/521170 > > Are we Doing It Wrong(TM)? No, it looks to me like you're doing things correctly. The OP mentioned that this only happens when deleting a Magnum cluster -- and that it doesn't occur in normal Heat template usage. I wonder (as I really don't know anything about Magnum, unfortunately), is there something different about the Magnum cluster resource handling in Heat that might be causing the wonkiness? Best, -jay From fungi at yuggoth.org Thu Dec 20 13:13:16 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 20 Dec 2018 13:13:16 +0000 Subject: [tripleo][ci] Reducing merge time by moving nv job to experimental In-Reply-To: References: Message-ID: <20181220131316.by5h6vpe2vbh3oc4@yuggoth.org> On 2018-12-20 08:07:56 +0100 (+0100), Felix Enrique Llorente Pastora wrote: [...] > So we have two options here: > > - Make experimental pipeline run on reviews directly without the > "check-experimental" comment. > > - Create a new pipeline "draf" pipeline at infra, that runs WIP > jobs or problematic jobs without interfering in normal production > "check" pipeline. > > What do you think ? [...] If you're expecting reviewers to approve changes which pass voting jobs without waiting for non-voting job to return results, this begs the question why you're running them on changes at all. -- 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 zhipengh512 at gmail.com Thu Dec 20 13:16:08 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Thu, 20 Dec 2018 21:16:08 +0800 Subject: [edge] Zero Touch Provisioning In-Reply-To: <3a1ca5f4-0c3a-ae32-3e0b-b346cf653f65@gmail.com> References: <3a1ca5f4-0c3a-ae32-3e0b-b346cf653f65@gmail.com> Message-ID: I'm also very interested in the use case here, for accelerators deployed at edge it would be needed to have zero touch provision capability as Jay described. I'm wondering if the open firmware project [0] could be of help here by any means ? I saw there was a FB presentation that they use it for provisioning automation in their datacenter at the OCP Regional Summit. [0] https://www.opencompute.org/wiki/Open_System_Firmware On Thu, Dec 20, 2018 at 9:09 PM Jay Pipes wrote: > On 12/20/2018 07:12 AM, Curtis wrote: > > Hi, > > > > I've been looking through the docs I can find related to the edge > > working group, and I'm wondering if there has been any > > discussion/documentation of a Zero Touch Provisioning use case. I can't > > seem to find anything, but I may not be looking in the right place. Just > > wanted to double check and see what the current state is, if any. > > I take it that by "zero touch *provisioning*" (emphasis added to > differentiate from zero *configuration* networking, you are referring to > the ability for a new server to be rack-and-stacked in a site, powered > on, and immediately register itself with either a local inventory > management system or a remote one? > > In either case, the issue I foresee is that the firmware (or initial > boot/ramdisk that comes from the factory or supply chain team) will need > to have some program installed in it that sends out a request looking > for some known/assumed inventory management service [1]. The thing that > *responds* to such a request would, of course, need to be already > installed and available either on a switch or a pre-installed machine > pingable on the out-of-band network and already configured by the team > that handles hardware inventory. > > I can see some vendors working on their own custom low-touch > provisioning software -- and this software would likely end up depending > on their own proprietary (or subscription-based) server software ala Red > Hat's Satellite software [2]). But getting all the vendors to come > together on a unified low-touch provisioning system? Chances are pretty > slim, IMHO. > > Still, it's an interesting problem domain and I'd be interested in > sharing thoughts and discussing it with others. Here at > "Yahoo!/Oath/Verizon Media Group/Whatever we'll be called next month" we > have custom software (and a bit of custom hardware!) that handles base > hardware provisioning and I'm definitely interested in seeing if other > shops that handle hundreds of thousands of baremetal machines are > looking to collaborate in this area ("edge" or otherwise!). > > Best, > -jay > > [1] this could be done via some custom DHCPDISCOVER/DHCPREQUEST bits I > suppose -- which would require a DHCP client in the firmware/bootdisk -- > but more likely would depend on the IPMI/BMC system in use for the > hardware. As soon as IPMI/BMC comes into play, the extreme differences > in OEM vendor support will rule out a generic workable solution here as > many in the Ironic community will likely attest to [3]. If you can rely > on a homogeneous set of hardware at edge sites, you might be able to put > something together that just suits your company's need, however. > > [2] https://www.redhat.com/en/technologies/management/satellite > > [3] https://github.com/openstack/ironic/tree/master/ironic/drivers > > -- Zhipeng (Howard) Huang Principle Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.lake at surrey.ac.uk Thu Dec 20 10:39:22 2018 From: d.lake at surrey.ac.uk (d.lake at surrey.ac.uk) Date: Thu, 20 Dec 2018 10:39:22 +0000 Subject: FW: [networking-ovs-dpdk] Issue creating br-ex... In-Reply-To: References: Message-ID: "Have you tried running this by hand on the system and see what happens? 'sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev'" Yes - that creates the br-ex in ovs-vsctl on the second attempt but it does not create a bridge that ip link can act on. If I do an "ip link show br-ex" after the installation script has run, then I do not see a bridge at all on this system. There is no PUBLIC_BRIDGE because I'm not using one. I am creating 4 DPDK NICS which are connected to the virtual machines. Again, after many, many weeks of testing to arrive at a known-good configuration script, the assumption was that we could just push-the-button and roll-out re-installations at-will. I will have 4 ovs bridge ports - br-dpdk1, br-dpdk2, br-dpdk3, br-dpdk4. Each one will connect to one physical NIC. Each will then be known in OpenStack as physnet1, physnet2, physnet3, physnet4. This is how my existing system is setup and working using the Devstack installation system. " Short of that you should look at what's changed in the relevant files in the devstack tree to see if it was caused by a recent change." But I have no idea where to start looking! I've also had to give up trying to install Queens as the installation script moans about oslo.concurrency and seems to be installing a version that it KNOWS is not compatible. Again, this is something that worked perfectly on the installation I carried out in August. Surely nothing can have changed in the basic installation in less than 6 months? Even the basic command for cloning the networking_ovs_dpdk broke from the working local.conf because the -b stable/queens suffix failed. In fact looking at the source site for that piece of code, there is no queens release on the site anymore. I am now not sure if the version I have is compatible or not! So I've had to clone devstack master which has now lead to the Cinder bug which I am now trying to patch around. I'm hoping that we can get to a stable system by the time the centre shuts for Christmas tomorrow. Four days should have been more than enough given the working system which took three months to build! Frustrated - but thank you for your help. David -----Original Message----- From: Brian Haley Sent: 20 December 2018 00:07 To: Lake, David (PG/R - Elec Electronic Eng) ; openstack at lists.openstack.org Subject: Re: FW: [networking-ovs-dpdk] Issue creating br-ex... On 12/19/18 3:29 PM, d.lake at surrey.ac.uk wrote: > Would appreciate some help here please.   Br-ex is not being added and > the mtu command causes the whole thing to not install. Comments inline. > *From:*Lake, David (PG/R - Elec Electronic Eng) > *Sent:* 19 December 2018 15:22 > *To:* openstack-dev at lists.openstack.org > *Subject:* [networking-ovs-dpdk] Issue creating br-ex... > > Hello > > Trying to re-run a Queens DPDK all-in-one using devstack which I built > in August and hitting issues. > > The local.conf is identical between the two machines except I had to > take the "stable/queens" off the end of the "networking-ovs-dpdk" > plugin line as that no longer appears to work. > > The installation seems to proceed until it gets to setting the ip mtu > on br-ex. > > I'm not using br-ex.  I've declared OVS bridge mappings in the local.conf: > > #Dual socket platform with 16GB RAM,3072*2048kB hugepages leaves ~4G > for the system. > > OVS_NUM_HUGEPAGES=3072 > > #Dual socket platform with 64GB RAM,14336*2048kB hugepages leaves ~6G > for the system. > > #OVS_NUM_HUGEPAGES=14336 > > OVS_DATAPATH_TYPE=netdev > > OVS_LOG_DIR=/opt/stack/logs > > #OVS_DPDK_PORT_MAPPINGS=p1p1:br-dpdk1,p1p2:br-dpdk2,p2p1:br-dpdk3,p2p2 > :br-dpdk4 > > OVS_DPDK_PORT_MAPPINGS=p6p1:br-dpdk1,p6p2:br-dpdk2 > > #OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2,physnet3:br-d > pdk3,physnet4:br-dpdk4 > > OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2 > > [[post-config|$NOVA_CONF]] > > [DEFAULT] > > firewall_driver=nova.virt.firewall.NoopFirewallDriver > > scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilt > er,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilte > r > > [[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]] > > [OVS] > > datapath_type=netdev > > [ml2_type_flat] > > #flat_networks=physnet1,physnet2,physnet3,physnet4 > > flat_networks=physnet1,physnet2 > > I cannot stress again how identical these systems are - same hardware, > same base OS install (CentOS 7.5).   I was (maybe erroneously!) > thinking that if I had it devstack working on one system, having an > identical system would be a piece of cake to install. > > This is the installation error: > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:21  local > bridge=br-ex > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:22  local > 'addbr_cmd=sudo ovs-vsctl -- --may-exist add-br br-ex' > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:24  '[' > netdev '!=' system ']' > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:25 > addbr_cmd='sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge > br-ex datapath_type=netdev' > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:28  sudo > ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex > datapath_type=netdev Have you tried running this by hand on the system and see what happens? 'sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev' It works for me locally, creating br-ex. Perhaps there is some delay on your system? But I would expect the call wouldn't return successfully then. Or perhaps I'm mis-understanding and you meant to set PUBLIC_BRIDGE in your local.conf as well? Short of that you should look at what's changed in the relevant files in the devstack tree to see if it was caused by a recent change. -Brian > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_public_bridge:119 > set_mtu br-ex 1500 > > +functions:set_mtu:750                     local dev=br-ex > > +functions:set_mtu:751                     local mtu=1500 > > +functions:set_mtu:752                     sudo ip link set mtu 1500 > +dev > br-ex > > Cannot find device "br-ex" > > +functions:set_mtu:1                       exit_trap > > +./stack.sh:exit_trap:522                  local r=1 > > ++./stack.sh:exit_trap:523                  jobs -p > > +./stack.sh:exit_trap:523                  jobs= > > +./stack.sh:exit_trap:526                  [[ -n '' ]] > > +./stack.sh:exit_trap:532                  '[' -f /tmp/tmp.Dzbqzlk2fs ']' > > +./stack.sh:exit_trap:533                  rm /tmp/tmp.Dzbqzlk2fs > > +./stack.sh:exit_trap:537                  kill_spinner > > +./stack.sh:kill_spinner:432               '[' '!' -z '' ']' > > +./stack.sh:exit_trap:539                  [[ 1 -ne 0 ]] > > +./stack.sh:exit_trap:540                  echo 'Error on exit' > > Error on exit > > +./stack.sh:exit_trap:542                  type -p generate-subunit > > +./stack.sh:exit_trap:543                  generate-subunit 1545230781 > 1747 fail > > +./stack.sh:exit_trap:545                  [[ -z > +/opt/stack/logs/screen ]] > > +./stack.sh:exit_trap:548 > /home/stack/devstack/tools/worlddump.py -d /opt/stack/logs/screen > > Can someone explain what is going on here please? > > Thanks > > > David > From Viktor_Shulhin at jabil.com Thu Dec 20 12:00:12 2018 From: Viktor_Shulhin at jabil.com (Viktor Shulhin) Date: Thu, 20 Dec 2018 12:00:12 +0000 Subject: [Heat][Octavia] Is autoscaling feature missing? Message-ID: Hi all, I am trying to create Heat template with autoscaling and loadbalancing. I didn't find any similar Heat template examples. Individually, loadbalancing and autoscaling work well, but loadbalancing OS::Octavia::PoolMember can be added only manually. Is there any way to use OS::Heat::AutoScalingGroup as server pool for loadbalancing? Regards, Viktor. From d.lake at surrey.ac.uk Thu Dec 20 13:16:53 2018 From: d.lake at surrey.ac.uk (d.lake at surrey.ac.uk) Date: Thu, 20 Dec 2018 13:16:53 +0000 Subject: Devstack - yet more problems on install In-Reply-To: <20181219220144.GA28606@sm-workstation> References: <20181219220144.GA28606@sm-workstation> Message-ID: Thanks, but yet another different error now. Seems to be this: .ml2.drivers.openvswitch.agent.ovs_neutron_agent [-] No datapath_id on bridge br-int Agent terminated!: RuntimeError: No datapath_id on bridge br-int Tearing my hair out here. David Dec 20 11:34:28 localhost neutron-openvswitch-agent[70126]: ERROR neutron.agent. common.ovs_lib File "/usr/lib/python2.7/site-packages/tenacity/__init__.py", l ine 331, in iter Dec 20 11:34:28 localhost neutron-openvswitch-agent[70126]: ERROR neutron.agent. common.ovs_lib raise retry_exc.reraise() Dec 20 11:34:28 localhost neutron-openvswitch-agent[70126]: ERROR neutron.agent. common.ovs_lib File "/usr/lib/python2.7/site-packages/tenacity/__init__.py", l ine 168, in reraise Dec 20 11:34:28 localhost neutron-openvswitch-agent[70126]: ERROR neutron.agent. common.ovs_lib raise self Dec 20 11:34:28 localhost neutron-openvswitch-agent[70126]: ERROR neutron.agent. common.ovs_lib RetryError: RetryError[] Dec 20 11:34:28 localhost neutron-openvswitch-agent[70126]: ERROR neutron.agent. common.ovs_lib Dec 20 11:34:28 localhost neutron-openvswitch-agent[70126]: ERROR neutron.plugin s.ml2.drivers.openvswitch.agent.ovs_neutron_agent [-] No datapath_id on bridge b r-int Agent terminated!: RuntimeError: No datapath_id on bridge br-int Dec 20 11:34:28 localhost systemd[1]: devstack at q-agt.service: main process exite d, code=exited, status=1/FAILURE Dec 20 11:34:28 localhost systemd[1]: Unit devstack at q-agt.service entered failed state. Dec 20 11:34:28 localhost systemd[1]: devstack at q-agt.service failed. +functions-common:service_check:1 exit_trap +./stack.sh:exit_trap:522 local r=3 ++./stack.sh:exit_trap:523 jobs -p +./stack.sh:exit_trap:523 jobs= +./stack.sh:exit_trap:526 [[ -n '' ]] +./stack.sh:exit_trap:532 '[' -f /tmp/tmp.YgbuTdLJS4 ']' +./stack.sh:exit_trap:533 rm /tmp/tmp.YgbuTdLJS4 +./stack.sh:exit_trap:537 kill_spinner +./stack.sh:kill_spinner:432 '[' '!' -z '' ']' +./stack.sh:exit_trap:539 [[ 3 -ne 0 ]] +./stack.sh:exit_trap:540 echo 'Error on exit' Error on exit +./stack.sh:exit_trap:542 type -p generate-subunit +./stack.sh:exit_trap:543 generate-subunit 1545304664 1078 fail +./stack.sh:exit_trap:545 [[ -z /opt/stack/logs/screen ]] +./stack.sh:exit_trap:548 /home/stack/devstack/tools/worlddump. -----Original Message----- From: Sean McGinnis Sent: 19 December 2018 22:02 To: Lake, David (PG/R - Elec Electronic Eng) Cc: openstack at lists.openstack.org; openstack-dev at lists.openstack.org Subject: Re: Devstack - yet more problems on install > But now falling over with another one > > ERROR oslo_db.sqlalchemy.exc_filters InternalError: (1071, u'Specified > key was too long; max key length is 767 bytes') ERROR > oslo_db.sqlalchemy.exc_filters Error during database migration: > (pymysql.err.InternalError) (1071, u'Specified key was too long; max > key length is 767 bytes') [SQL: u'\nALTER TABLE quota_usages CHANGE > COLUMN resource resource VARCHAR(300)'] (Background on this error at: > http://sqlalche.me/e/2j85) > > Base OS is CentOS 7.5. > > I've found this which looks similar - https://review.openstack.org/#/c/626146/ - but I've no idea how to apply it to my Devstack installation. > Yep, you found the right patch. That is a known issue right now and we should hopefully have the fix merged very shortly. In the meantime, you could add this to your local.conf: CINDER_BRANCH=refs/changes/46/626146/3 With that, devstack will pull down that version of the code and you should be able to get by this failure until we merge the fix. As of this moment, there is just a pep8 error that is preventing that from merging. That will not impact the ability to actually run the code. Once that merges you can take that line out of the local.conf file to just get the current code from master. Hope that helps. Sean From aschadin at sbcloud.ru Thu Dec 20 13:19:22 2018 From: aschadin at sbcloud.ru (=?koi8-r?B?/sHEyc4g4czFy9PBzsTSIPPF0sfFxdfJ3g==?=) Date: Thu, 20 Dec 2018 13:19:22 +0000 Subject: [watcher] core reviewers update Message-ID: <10D5269D-E895-46EF-AD2F-5723306F14AE@sbcloud.ru> Hello Watcher team, Some of core contributors are inactive for a year or more and their priorities have been changed. I suggest to remove the following contributors from core reviewers of Watcher: - Joe Cropper - Prashanth Hari - Prudhvi Rao Shedimbi - Susanne Balle - Vincent Francoise - David Tardivel If some of them would like to get back to work on Watcher, I see no barriers for that. Best Regards, ____ Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Thu Dec 20 13:21:00 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 20 Dec 2018 08:21:00 -0500 Subject: [ptl][goals][python3] please update your team's status in the wiki Message-ID: I noticed this morning that the last time the Python 3 status page [1] was updated in the wiki was August. I hope we've had changes to the level of support since then. Keeping that page up to date is part of fulfilling the goal this cycle. Please take a few minutes to review the content today and update it if necessary. Thanks! [1] https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects -- Doug From ifatafekn at gmail.com Thu Dec 20 13:23:48 2018 From: ifatafekn at gmail.com (Ifat Afek) Date: Thu, 20 Dec 2018 15:23:48 +0200 Subject: [nova][vitrage] Nova extended server attributes In-Reply-To: References: Message-ID: Hi, Indeed, Vitrage now uses the Nova versioned notifications (we pushed that code a few days ago). I'm only interested at the instance.create.* notifications, so I'll try to add the OS-EXT-SRV-ATTR:instance_name where you suggested. Thanks! Ifat On Wed, Dec 19, 2018 at 7:52 PM Matt Riedemann wrote: > On 12/19/2018 11:29 AM, Ifat Afek wrote: > > Is there a way to get Nova extended server attributes (and > > specifically, OS-EXT-SRV-ATTR:instance_name) as part of the notification > > that is sent upon instance creation? > > > > In Vitrage we are using the immediate notifications from Nova, but this > > specific information is missing. > > We could add it into the versioned notification payload if that works > for you (I heard vitrage was moving to using versioned notifications). > > If you only need it on create, it could go here: > > > https://github.com/openstack/nova/blob/86a23f417a3e569afd74b513dc977780b40ead35/nova/notifications/objects/instance.py#L213 > > or more generically here: > > > https://github.com/openstack/nova/blob/86a23f417a3e569afd74b513dc977780b40ead35/nova/notifications/objects/instance.py#L25 > > The tricky thing about that value is it gets generated from config: > > > https://github.com/openstack/nova/blob/86a23f417a3e569afd74b513dc977780b40ead35/nova/objects/instance.py#L285 > > So depending on what "instance_name_template" is configured to be on > each service that sends the notification, the value could be different, > which could break unsuspecting consumers. > > It looks like the instance.create.* versioned notifications all get sent > from the nova-compute service though which aligns with how > "instance_name_template" is used to generate the guest name in the > hypervisor. If you only need that value for instance.create > notifications, maybe we should just restrict it to that rather than > *all* InstancePayload-generated versioned notifications since the value > isn't stored in the database. > > -- > > Thanks, > > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramishra at redhat.com Thu Dec 20 13:37:35 2018 From: ramishra at redhat.com (Rabi Mishra) Date: Thu, 20 Dec 2018 19:07:35 +0530 Subject: [Heat][Octavia] Is autoscaling feature missing? In-Reply-To: References: Message-ID: On Thu, Dec 20, 2018, 18:51 Viktor Shulhin Hi all, > > I am trying to create Heat template with autoscaling and loadbalancing. > I didn't find any similar Heat template examples. > Individually, loadbalancing and autoscaling work well, but loadbalancing > OS::Octavia::PoolMember can be added only manually. > I guess you're looking for this[1] which is for scaling a WordPress application. https://review.openstack.org/#/c/619577/ updates it to use octavia instead of lbaasv2 resources. [1] https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml Is there any way to use OS::Heat::AutoScalingGroup as server pool for > loadbalancing > Regards, Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cecilia.dimaulo at osones.com Thu Dec 20 13:45:27 2018 From: cecilia.dimaulo at osones.com (Cecilia Di Maulo) Date: Thu, 20 Dec 2018 14:45:27 +0100 Subject: [openstack-ansible][cinder] Multiple backends for Cinder Message-ID: Dear all, I currently have a NFS backend for Cinder and I would like to add an iSCSI (hpmsa) backend. However I was wondering where should the cinder services run? For now cinder-api.service and cinder-scheduler.service run in a lxc while cinder-volume.service runs in bare metal on the controllers. I also would like to separate as much as possible the 2 backend types to be able to remove 'easily' my NFS backend once the other one has proved it really works. I was thinking to have the services related to the NFS backend in a lxc and the services related to the HPMSA backend on metal. Is this even possible? How should I do it? Should I name 2 different services in the container_skel or..? Thank you for your help, Best Regards, Cecilia -------------- next part -------------- An HTML attachment was scrubbed... URL: From serverascode at gmail.com Thu Dec 20 13:47:54 2018 From: serverascode at gmail.com (Curtis) Date: Thu, 20 Dec 2018 08:47:54 -0500 Subject: [edge] Zero Touch Provisioning In-Reply-To: <3a1ca5f4-0c3a-ae32-3e0b-b346cf653f65@gmail.com> References: <3a1ca5f4-0c3a-ae32-3e0b-b346cf653f65@gmail.com> Message-ID: On Thu, Dec 20, 2018 at 8:09 AM Jay Pipes wrote: > On 12/20/2018 07:12 AM, Curtis wrote: > > Hi, > > > > I've been looking through the docs I can find related to the edge > > working group, and I'm wondering if there has been any > > discussion/documentation of a Zero Touch Provisioning use case. I can't > > seem to find anything, but I may not be looking in the right place. Just > > wanted to double check and see what the current state is, if any. > > I take it that by "zero touch *provisioning*" (emphasis added to > differentiate from zero *configuration* networking, you are referring to > the ability for a new server to be rack-and-stacked in a site, powered > on, and immediately register itself with either a local inventory > management system or a remote one? > In this case, yes that is what I'm talking about, just the provisioning aspect, and mostly related to the "edge" which in my case I usually consider to be one or two physical servers (but that's just one use case). I'm a relatively new member of the StarlingX TSC and there is some discussion about deployment models, of which ZTP would presumably be a part, so I wanted to check in with the edge working group to see what's been going on in that area if anything. > > In either case, the issue I foresee is that the firmware (or initial > boot/ramdisk that comes from the factory or supply chain team) will need > to have some program installed in it that sends out a request looking > for some known/assumed inventory management service [1]. The thing that > *responds* to such a request would, of course, need to be already > installed and available either on a switch or a pre-installed machine > pingable on the out-of-band network and already configured by the team > that handles hardware inventory. > > I can see some vendors working on their own custom low-touch > provisioning software -- and this software would likely end up depending > on their own proprietary (or subscription-based) server software ala Red > Hat's Satellite software [2]). But getting all the vendors to come > together on a unified low-touch provisioning system? Chances are pretty > slim, IMHO. > Well, perhaps ONIE [1] is the best example. Switches that can run multiple network OSes have pretty much standardized on it. But I don't know if ONIE is the right example here, though it very well might be. > > Still, it's an interesting problem domain and I'd be interested in > sharing thoughts and discussing it with others. Here at > "Yahoo!/Oath/Verizon Media Group/Whatever we'll be called next month" we > have custom software (and a bit of custom hardware!) that handles base > hardware provisioning and I'm definitely interested in seeing if other > shops that handle hundreds of thousands of baremetal machines are > looking to collaborate in this area ("edge" or otherwise!). > > Best, > -jay > > [1] this could be done via some custom DHCPDISCOVER/DHCPREQUEST bits I > suppose -- which would require a DHCP client in the firmware/bootdisk -- > but more likely would depend on the IPMI/BMC system in use for the > hardware. As soon as IPMI/BMC comes into play, the extreme differences > in OEM vendor support will rule out a generic workable solution here as > many in the Ironic community will likely attest to [3]. If you can rely > on a homogeneous set of hardware at edge sites, you might be able to put > something together that just suits your company's need, however. > > [2] https://www.redhat.com/en/technologies/management/satellite > > [3] https://github.com/openstack/ironic/tree/master/ironic/drivers > > [1]: https://opencomputeproject.github.io/onie/ -- Blog: serverascode.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From amotoki at gmail.com Thu Dec 20 13:47:58 2018 From: amotoki at gmail.com (Akihiro Motoki) Date: Thu, 20 Dec 2018 22:47:58 +0900 Subject: [openstack-dev] [Neutron] Propose Ryan Tidwell for neutron-dynamic-routing core In-Reply-To: References: Message-ID: +1 from me 2018年12月20日(木) 3:47 Miguel Lavalle : > Hi Stackers, > > I want to nominate Ryan Tidwell (irc: tidwellr) as a core reviewer for > neutron-dynamic-routing ( > https://github.com/openstack/neutron-dynamic-routing). Ryan has a long > history with everything L3 in Neutron. He started contributing code back in > 2014, helping to implement subnet pools ( > https://review.openstack.org/#/c/148698/). Over the years he did great > work improving Neutron's IP address manager and was the driving force in > the creation and implementation of the neutron-dynamic-routing project. > After a hiatus of a few cycles, Ryan came back to the community and has > been very active adding support for MP-BGP in neutron-dynamic-routing and > the on boarding of subnets in Neutron. The quality and number of his code > reviews during the Stein cycle are on par with members of the Neutron core > team: http://stackalytics.com/?module=neutron-group. > > I will keep this nomination open as customary. > > Thank you. > > Miguel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serverascode at gmail.com Thu Dec 20 13:53:47 2018 From: serverascode at gmail.com (Curtis) Date: Thu, 20 Dec 2018 08:53:47 -0500 Subject: [edge] Zero Touch Provisioning In-Reply-To: References: <3a1ca5f4-0c3a-ae32-3e0b-b346cf653f65@gmail.com> Message-ID: On Thu, Dec 20, 2018 at 8:22 AM Zhipeng Huang wrote: > I'm also very interested in the use case here, for accelerators deployed > at edge it would be needed to have zero touch provision capability as Jay > described. > Accelerators...interesting. I would be happy to hear more about that use case. > > I'm wondering if the open firmware project [0] could be of help here by > any means ? I saw there was a FB presentation that they use it for > provisioning automation in their datacenter at the OCP Regional Summit. > > [0] https://www.opencompute.org/wiki/Open_System_Firmware > Quite possibly, or perhaps ONIE as well, or a combination. :) Mostly I was wondering if there had been any discussion in the edge group, or if anyone knows of any major activities around this area. I think a zero touch related group was just recently started at ETSI [1] but haven't read through related docs yet. Thanks, Curtis [1]: https://www.etsi.org/index.php/technologies-clusters/technologies/zero-touch-network-service-management > > On Thu, Dec 20, 2018 at 9:09 PM Jay Pipes wrote: > >> On 12/20/2018 07:12 AM, Curtis wrote: >> > Hi, >> > >> > I've been looking through the docs I can find related to the edge >> > working group, and I'm wondering if there has been any >> > discussion/documentation of a Zero Touch Provisioning use case. I can't >> > seem to find anything, but I may not be looking in the right place. >> Just >> > wanted to double check and see what the current state is, if any. >> >> I take it that by "zero touch *provisioning*" (emphasis added to >> differentiate from zero *configuration* networking, you are referring to >> the ability for a new server to be rack-and-stacked in a site, powered >> on, and immediately register itself with either a local inventory >> management system or a remote one? >> >> In either case, the issue I foresee is that the firmware (or initial >> boot/ramdisk that comes from the factory or supply chain team) will need >> to have some program installed in it that sends out a request looking >> for some known/assumed inventory management service [1]. The thing that >> *responds* to such a request would, of course, need to be already >> installed and available either on a switch or a pre-installed machine >> pingable on the out-of-band network and already configured by the team >> that handles hardware inventory. >> >> I can see some vendors working on their own custom low-touch >> provisioning software -- and this software would likely end up depending >> on their own proprietary (or subscription-based) server software ala Red >> Hat's Satellite software [2]). But getting all the vendors to come >> together on a unified low-touch provisioning system? Chances are pretty >> slim, IMHO. >> >> Still, it's an interesting problem domain and I'd be interested in >> sharing thoughts and discussing it with others. Here at >> "Yahoo!/Oath/Verizon Media Group/Whatever we'll be called next month" we >> have custom software (and a bit of custom hardware!) that handles base >> hardware provisioning and I'm definitely interested in seeing if other >> shops that handle hundreds of thousands of baremetal machines are >> looking to collaborate in this area ("edge" or otherwise!). >> >> Best, >> -jay >> >> [1] this could be done via some custom DHCPDISCOVER/DHCPREQUEST bits I >> suppose -- which would require a DHCP client in the firmware/bootdisk -- >> but more likely would depend on the IPMI/BMC system in use for the >> hardware. As soon as IPMI/BMC comes into play, the extreme differences >> in OEM vendor support will rule out a generic workable solution here as >> many in the Ironic community will likely attest to [3]. If you can rely >> on a homogeneous set of hardware at edge sites, you might be able to put >> something together that just suits your company's need, however. >> >> [2] https://www.redhat.com/en/technologies/management/satellite >> >> [3] https://github.com/openstack/ironic/tree/master/ironic/drivers >> >> > > -- > Zhipeng (Howard) Huang > > Principle Engineer > IT Standard & Patent/IT Product Line > Huawei Technologies Co,. Ltd > Email: huangzhipeng at huawei.com > Office: Huawei Industrial Base, Longgang, Shenzhen > > -- Blog: serverascode.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaypipes at gmail.com Thu Dec 20 14:01:39 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Thu, 20 Dec 2018 09:01:39 -0500 Subject: [edge] Zero Touch Provisioning In-Reply-To: References: <3a1ca5f4-0c3a-ae32-3e0b-b346cf653f65@gmail.com> Message-ID: <59f29ce7-aa3e-7f68-4e53-2623d35cf778@gmail.com> On 12/20/2018 08:47 AM, Curtis wrote: > On Thu, Dec 20, 2018 at 8:09 AM Jay Pipes > wrote: > > On 12/20/2018 07:12 AM, Curtis wrote: > > Hi, > > > > I've been looking through the docs I can find related to the edge > > working group, and I'm wondering if there has been any > > discussion/documentation of a Zero Touch Provisioning use case. I > can't > > seem to find anything, but I may not be looking in the right > place. Just > > wanted to double check and see what the current state is, if any. > > I take it that by "zero touch *provisioning*" (emphasis added to > differentiate from zero *configuration* networking, you are > referring to > the ability for a new server to be rack-and-stacked in a site, powered > on, and immediately register itself with either a local inventory > management system or a remote one? > > In this case, yes that is what I'm talking about, just the provisioning > aspect, and mostly related to the "edge" which in my case I usually > consider to be one or two physical servers (but that's just one use case). > > I'm a relatively new member of the StarlingX TSC and there is some > discussion about deployment models, of which ZTP would presumably be a > part, so I wanted to check in with the edge working group to see what's > been going on in that area if anything. I'm not involved in StarlingX so can't speak to that area. > In either case, the issue I foresee is that the firmware (or initial > boot/ramdisk that comes from the factory or supply chain team) will > need > to have some program installed in it that sends out a request looking > for some known/assumed inventory management service [1]. The thing that > *responds* to such a request would, of course, need to be already > installed and available either on a switch or a pre-installed machine > pingable on the out-of-band network and already configured by the team > that handles hardware inventory. > > I can see some vendors working on their own custom low-touch > provisioning software -- and this software would likely end up > depending > on their own proprietary (or subscription-based) server software ala > Red > Hat's Satellite software [2]). But getting all the vendors to come > together on a unified low-touch provisioning system? Chances are pretty > slim, IMHO. > > Well, perhaps ONIE [1] is the best example. Switches that can run > multiple network OSes have pretty much standardized on it. But I don't > know if ONIE is the right example here, though it very well might be. ONIE looks interesting, thanks for the link. It does seem to be specific to network switches, though, not general compute hardware (or servers that need large root disks and partitioning). It seems to be kind of a custom TFTP server for network devices? Is ONIE something you're saying would be a solution for inventory management? Because I don't really see anything in there (or the scope of ONIE) about that... Best, -jay > Still, it's an interesting problem domain and I'd be interested in > sharing thoughts and discussing it with others. Here at > "Yahoo!/Oath/Verizon Media Group/Whatever we'll be called next > month" we > have custom software (and a bit of custom hardware!) that handles base > hardware provisioning and I'm definitely interested in seeing if other > shops that handle hundreds of thousands of baremetal machines are > looking to collaborate in this area ("edge" or otherwise!). > > Best, > -jay > > [1] this could be done via some custom DHCPDISCOVER/DHCPREQUEST bits I > suppose -- which would require a DHCP client in the > firmware/bootdisk -- > but more likely would depend on the IPMI/BMC system in use for the > hardware. As soon as IPMI/BMC comes into play, the extreme differences > in OEM vendor support will rule out a generic workable solution here as > many in the Ironic community will likely attest to [3]. If you can rely > on a homogeneous set of hardware at edge sites, you might be able to > put > something together that just suits your company's need, however. > > [2] https://www.redhat.com/en/technologies/management/satellite > > [3] https://github.com/openstack/ironic/tree/master/ironic/drivers > > > [1]: https://opencomputeproject.github.io/onie/ > > -- > Blog: serverascode.com From bence.romsics at gmail.com Thu Dec 20 14:02:00 2018 From: bence.romsics at gmail.com (Bence Romsics) Date: Thu, 20 Dec 2018 15:02:00 +0100 Subject: [nova] review guide for the bandwidth patches In-Reply-To: <1545231821.28650.2@smtp.office365.com> References: <1545231821.28650.2@smtp.office365.com> Message-ID: Hi Gibi, > However I think we can use the feature flag approach. We can implement > and verify everything in the current order without the end user seeing > or causing any kind of inconsistencies. The nova implementation is only > activated if a neutron port has a resource_request field. This field is > added to the neutron API as an API extension. We can mark this > extension experimental while we are working through the missing pieces > of the feature. I like the idea of a feature flag, however technically in neutron we don't directly control the list of extensions loaded. Instead what we control (through configuration) is the list of service plugins loaded. The 'resource_request' extension is implemented by the 'qos' service plugin. But the 'qos' service plugin implements other API extensions and features too. A cloud admin may want to use these other features of the 'qos' service plugin, but not the guaranteed minimum bandwidth. Therefore I'd suggest adding the feature flag to nova to keep this usage possible. Cheers, Bence From lujinluo at gmail.com Thu Dec 20 14:13:18 2018 From: lujinluo at gmail.com (Lujin Luo) Date: Thu, 20 Dec 2018 06:13:18 -0800 Subject: [neutron] [upgrade] No meeting on Dec. 27th Message-ID: Hi everyone, We will not have the next subteam meeting on Dec. 27th. Thank you for all of your work this year, and let's resume in next year, Jan. 3rd. Happy Holidays! Best regards, Lujin From serverascode at gmail.com Thu Dec 20 14:33:12 2018 From: serverascode at gmail.com (Curtis) Date: Thu, 20 Dec 2018 09:33:12 -0500 Subject: [edge] Zero Touch Provisioning In-Reply-To: <59f29ce7-aa3e-7f68-4e53-2623d35cf778@gmail.com> References: <3a1ca5f4-0c3a-ae32-3e0b-b346cf653f65@gmail.com> <59f29ce7-aa3e-7f68-4e53-2623d35cf778@gmail.com> Message-ID: On Thu, Dec 20, 2018 at 9:01 AM Jay Pipes wrote: > On 12/20/2018 08:47 AM, Curtis wrote: > > On Thu, Dec 20, 2018 at 8:09 AM Jay Pipes > > wrote: > > > > On 12/20/2018 07:12 AM, Curtis wrote: > > > Hi, > > > > > > I've been looking through the docs I can find related to the edge > > > working group, and I'm wondering if there has been any > > > discussion/documentation of a Zero Touch Provisioning use case. I > > can't > > > seem to find anything, but I may not be looking in the right > > place. Just > > > wanted to double check and see what the current state is, if any. > > > > I take it that by "zero touch *provisioning*" (emphasis added to > > differentiate from zero *configuration* networking, you are > > referring to > > the ability for a new server to be rack-and-stacked in a site, > powered > > on, and immediately register itself with either a local inventory > > management system or a remote one? > > > > In this case, yes that is what I'm talking about, just the provisioning > > aspect, and mostly related to the "edge" which in my case I usually > > consider to be one or two physical servers (but that's just one use > case). > > > > I'm a relatively new member of the StarlingX TSC and there is some > > discussion about deployment models, of which ZTP would presumably be a > > part, so I wanted to check in with the edge working group to see what's > > been going on in that area if anything. > > I'm not involved in StarlingX so can't speak to that area. > > > In either case, the issue I foresee is that the firmware (or initial > > boot/ramdisk that comes from the factory or supply chain team) will > > need > > to have some program installed in it that sends out a request looking > > for some known/assumed inventory management service [1]. The thing > that > > *responds* to such a request would, of course, need to be already > > installed and available either on a switch or a pre-installed machine > > pingable on the out-of-band network and already configured by the > team > > that handles hardware inventory. > > > > I can see some vendors working on their own custom low-touch > > provisioning software -- and this software would likely end up > > depending > > on their own proprietary (or subscription-based) server software ala > > Red > > Hat's Satellite software [2]). But getting all the vendors to come > > together on a unified low-touch provisioning system? Chances are > pretty > > slim, IMHO. > > > > Well, perhaps ONIE [1] is the best example. Switches that can run > > multiple network OSes have pretty much standardized on it. But I don't > > know if ONIE is the right example here, though it very well might be. > > ONIE looks interesting, thanks for the link. It does seem to be specific > to network switches, though, not general compute hardware (or servers > that need large root disks and partitioning). It seems to be kind of a > custom TFTP server for network devices? > > Is ONIE something you're saying would be a solution for inventory > management? Because I don't really see anything in there (or the scope > of ONIE) about that... > No, it doesn't do inventory management. It's like a small base OS for network switches, they come with it, boot up into it, and you can use it to install other OSes. At least that's how it's used with the whitebox switches I have. With ONIE it'd install the OS, then the initial OS could register with some kind of inventory system. Thanks, Curtis > > Best, > -jay > > > Still, it's an interesting problem domain and I'd be interested in > > sharing thoughts and discussing it with others. Here at > > "Yahoo!/Oath/Verizon Media Group/Whatever we'll be called next > > month" we > > have custom software (and a bit of custom hardware!) that handles > base > > hardware provisioning and I'm definitely interested in seeing if > other > > shops that handle hundreds of thousands of baremetal machines are > > looking to collaborate in this area ("edge" or otherwise!). > > > > Best, > > -jay > > > > [1] this could be done via some custom DHCPDISCOVER/DHCPREQUEST bits > I > > suppose -- which would require a DHCP client in the > > firmware/bootdisk -- > > but more likely would depend on the IPMI/BMC system in use for the > > hardware. As soon as IPMI/BMC comes into play, the extreme > differences > > in OEM vendor support will rule out a generic workable solution here > as > > many in the Ironic community will likely attest to [3]. If you can > rely > > on a homogeneous set of hardware at edge sites, you might be able to > > put > > something together that just suits your company's need, however. > > > > [2] https://www.redhat.com/en/technologies/management/satellite > > > > [3] https://github.com/openstack/ironic/tree/master/ironic/drivers > > > > > > [1]: https://opencomputeproject.github.io/onie/ > > > > -- > > Blog: serverascode.com > -- Blog: serverascode.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at ericsson.com Thu Dec 20 14:33:48 2018 From: balazs.gibizer at ericsson.com (=?iso-8859-1?Q?Bal=E1zs_Gibizer?=) Date: Thu, 20 Dec 2018 14:33:48 +0000 Subject: [nova] review guide for the bandwidth patches In-Reply-To: References: <1545231821.28650.2@smtp.office365.com> Message-ID: <1545316423.10879.3@smtp.office365.com> On Thu, Dec 20, 2018 at 3:02 PM, Bence Romsics wrote: > Hi Gibi, > >> However I think we can use the feature flag approach. We can >> implement >> and verify everything in the current order without the end user >> seeing >> or causing any kind of inconsistencies. The nova implementation is >> only >> activated if a neutron port has a resource_request field. This >> field is >> added to the neutron API as an API extension. We can mark this >> extension experimental while we are working through the missing >> pieces >> of the feature. > > I like the idea of a feature flag, however technically in neutron we > don't directly control the list of extensions loaded. Instead what we > control (through configuration) is the list of service plugins loaded. > The 'resource_request' extension is implemented by the 'qos' service > plugin. But the 'qos' service plugin implements other API extensions > and features too. A cloud admin may want to use these other features > of the 'qos' service plugin, but not the guaranteed minimum bandwidth. > Therefore I'd suggest adding the feature flag to nova to keep this > usage possible. Thanks Bence. I still want to belive that the proper solution for this long running implementation is to use a feature flag. Nova has a 'workaround' config section that might be used to add a new config option as a feature flag similar to the existing 'enable_numa_live_migration' option. This way the feature can be controller externally. Would be good to see the reaction from other Nova developers about this approch. cheers, gibi > > Cheers, > Bence > From torin.woltjer at granddial.com Thu Dec 20 14:35:12 2018 From: torin.woltjer at granddial.com (Torin Woltjer) Date: Thu, 20 Dec 2018 14:35:12 GMT Subject: Failed live migration and duplicate attachments Message-ID: How would you recommend addressing the duplicate attachments? There doesn't seem to be any adverse effect of them being there, but I cannot detach them because they are root volumes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaypipes at gmail.com Thu Dec 20 14:35:47 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Thu, 20 Dec 2018 09:35:47 -0500 Subject: [edge] Zero Touch Provisioning In-Reply-To: References: <3a1ca5f4-0c3a-ae32-3e0b-b346cf653f65@gmail.com> <59f29ce7-aa3e-7f68-4e53-2623d35cf778@gmail.com> Message-ID: On 12/20/2018 09:33 AM, Curtis wrote: > No, it doesn't do inventory management. It's like a small base OS for > network switches, they come with it, boot up into it, and you can use it > to install other OSes. At least that's how it's used with the whitebox > switches I have. With ONIE it'd install the OS, then the initial OS > could register with some kind of inventory system. What about for non-network devices -- i.e. general compute hardware? After all, edge is more than just the network switches :) Best, -jay From serverascode at gmail.com Thu Dec 20 14:39:48 2018 From: serverascode at gmail.com (Curtis) Date: Thu, 20 Dec 2018 09:39:48 -0500 Subject: [edge] Zero Touch Provisioning In-Reply-To: References: <3a1ca5f4-0c3a-ae32-3e0b-b346cf653f65@gmail.com> <59f29ce7-aa3e-7f68-4e53-2623d35cf778@gmail.com> Message-ID: On Thu, Dec 20, 2018 at 9:35 AM Jay Pipes wrote: > On 12/20/2018 09:33 AM, Curtis wrote: > > No, it doesn't do inventory management. It's like a small base OS for > > network switches, they come with it, boot up into it, and you can use it > > to install other OSes. At least that's how it's used with the whitebox > > switches I have. With ONIE it'd install the OS, then the initial OS > > could register with some kind of inventory system. > > What about for non-network devices -- i.e. general compute hardware? > After all, edge is more than just the network switches :) > I'm not sure; that's a good question. I was just using it as an example of a piece of ZTP related technology that has been adopted by vendors who build physical devices and include them by default, though of course, only a subset of network switches. :) If ONIE was a good example, and it could not be used for general compute hardware, then perhaps something like it could be built using lessons learned by ONIE. I dunno. :) Thanks, Curits > > Best, > -jay > -- Blog: serverascode.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nickeysgo at gmail.com Thu Dec 20 14:41:17 2018 From: nickeysgo at gmail.com (Minjun Hong) Date: Thu, 20 Dec 2018 23:41:17 +0900 Subject: [Cinder] cinder-volume connection problem when creating the instance In-Reply-To: <20181219153728.GA4860@sm-workstation> References: <20181219153728.GA4860@sm-workstation> Message-ID: On Thu, Dec 20, 2018 at 12:37 AM Sean McGinnis wrote: > > > 2018-12-19 22:06:00.007 2657 ERROR cinder.volume.manager > > > [req-b3178448-4e17-489b-8267-2fd7992bc876 - - - - -] Failed to > initialize > > > driver.: ProcessExecutionError: Unexpected error while running command. > > > Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C > vgs > > > --version > > > Exit code: 1 > > > Stdout: u'' > > > Stderr: u'sudo: no tty present and no askpass program specified\n' > > This appears to be the problem, or at least one of them. > > The account the cinder services are running under (usually "cinder") needs > to > be able to perform password-less sudo calls to execute some of the > privileged > calls needed to set up and interact with storage. > > I thought typically the system packages used in the install guides would > create > this user and set the appropriate permissions to do that. But something may > have been modified on your system that is causing it to require a password > on > sudo calls, which as a headless service will not work. > > I don't have any systems that have that issue to verify with, but I > believe if > you run "visudo" and explicitly set cinder to NOPASSWD, you should then be > able > to restart the service and get better results. > > Sean > Thanks for your advice, Sean. The problem was caused by omitting "Install OpenStack Packages" step. So, I reinstalled Host OS and Cinder on the storage server again. And then, it looks working well. Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaypipes at gmail.com Thu Dec 20 14:47:40 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Thu, 20 Dec 2018 09:47:40 -0500 Subject: [nova] review guide for the bandwidth patches In-Reply-To: <1545316423.10879.3@smtp.office365.com> References: <1545231821.28650.2@smtp.office365.com> <1545316423.10879.3@smtp.office365.com> Message-ID: On 12/20/2018 09:33 AM, Balázs Gibizer wrote: > On Thu, Dec 20, 2018 at 3:02 PM, Bence Romsics > wrote: >> Hi Gibi, >> >>> However I think we can use the feature flag approach. We can >>> implement >>> and verify everything in the current order without the end user >>> seeing >>> or causing any kind of inconsistencies. The nova implementation is >>> only >>> activated if a neutron port has a resource_request field. This >>> field is >>> added to the neutron API as an API extension. We can mark this >>> extension experimental while we are working through the missing >>> pieces >>> of the feature. >> >> I like the idea of a feature flag, however technically in neutron we >> don't directly control the list of extensions loaded. Instead what we >> control (through configuration) is the list of service plugins loaded. >> The 'resource_request' extension is implemented by the 'qos' service >> plugin. But the 'qos' service plugin implements other API extensions >> and features too. A cloud admin may want to use these other features >> of the 'qos' service plugin, but not the guaranteed minimum bandwidth. >> Therefore I'd suggest adding the feature flag to nova to keep this >> usage possible. > > Thanks Bence. I still want to belive that the proper solution for this > long running implementation is to use a feature flag. Nova has a > 'workaround' config section that might be used to add a new config > option as a feature flag similar to the existing > 'enable_numa_live_migration' option. This way the feature can be > controller externally. > > Would be good to see the reaction from other Nova developers about this > approch. The problem with feature flags is they are not discoverable. As much as I hate API extensions, at least they are discoverable. Is there a reason why we can't just put code into Nova that, upon seeing the resource requests, acts on it? Is there a reason it needs to be behind a feature flag or even needs to query Neutron for extension support? I mean, if it's in the response payload, just use it, right? Best, -jay From mriedemos at gmail.com Thu Dec 20 14:47:52 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 20 Dec 2018 08:47:52 -0600 Subject: [nova] implementation options for nova spec: show-server-numa-topology In-Reply-To: References: Message-ID: <06c01a05-30a0-6671-0c89-780927da6793@gmail.com> On 12/18/2018 2:20 AM, yonglihe wrote: > > Base on IRC's discuss, we may have 3 options about how to deal with > those blobs: > > 1) include those directly in the server response details, like the > released POC does: > https://review.openstack.org/#/c/621476/3 I would think these are potentially admin-level sensitive details as well and thus only exposed based on a policy check. A user requests a certain topology, but I'm not sure how low-level the user needs/should see what nova is doing for satisfying that topology, especially for things like pinning CPUs on the host. I thought the main use case for this spec (and several like these discussed at the PTG) was more about being able to get information (reporting) out of the REST API for debugging (by admins and/or support team members), less about user need. > > 2) add a new sub-resource endpoint to servers, most likely use key word > 'topology' then: > "GET /servers/{server_id}/topology" returns the NUMA information for one > server. Similar to (1) in that I'd think there would be a new policy check on this which defaults to admin-only. I think this would be better than (1) since it wouldnt' be confused with listing servers (GET /servers/detail). > > 3) put the NUMA info under existing 'diagnostics' API. > "GET /servers/{server_id}/diagnostics" > this is admin only API, normal user loss the possible to check their > topology. By default it's an admin-only API, but that is configurable in policy, so if a given cloud wants to expose this for admin or owner of the instance, they can do that, or alternatively expose it to support team members via a special role in keystone. > > when the information put into diagnostics, they will be look like: > { >    .... >    "numa_topology": { >       cells  [ >                { >                     "numa_node" : 3 >                     "cpu_pinning": {0:5, 1:6}, >                     "cpu_thread_policy": "prefer", >                     "cpuset": [0,1,2,3], >                     "siblings": [[0,1],[2,3]], >                     "mem": 1024, >                     "pagesize": 4096, >                     "sockets": 0, >                     "cores": 2, >                      "threads": 2, >                  }, >              ... >            ] # cells >     } >     "emulator_threads_policy": "share" > >     "pci_devices": [ >         { >                 "address":"00:1a.0", >                 "type": "VF", >                 "vendor": "8086", >                 "product": "1526" >         }, >     ] >  } I tend to prefer option (3) since it seems topology is a much more natural fit with the existing information (low-level CPU/RAM/disk usage) we expose out of the diagnostics API and is already restricted to admins by default in policy (but again as noted this can be configured). -- Thanks, Matt From mdulko at redhat.com Thu Dec 20 15:18:38 2018 From: mdulko at redhat.com (=?UTF-8?Q?Micha=C5=82?= Dulko) Date: Thu, 20 Dec 2018 16:18:38 +0100 Subject: [dev] [infra] [devstack] [qa] [kuryr] DevStack's etcd performance on gate VM's In-Reply-To: <1544720777.384097.1608336832.49746981@webmail.messagingengine.com> References: <1544720777.384097.1608336832.49746981@webmail.messagingengine.com> Message-ID: <73a791f2566f4f5618109b8570672a30edaa6008.camel@redhat.com> On Thu, 2018-12-13 at 09:06 -0800, Clark Boylan wrote: > On Thu, Dec 13, 2018, at 4:39 AM, Michał Dulko wrote: > > Hi, > > > > In Kuryr-Kubernetes we're using the DevStack-installed etcd as a > > backend store for Kubernetes that we run on our gates. For some time we > > can see its degraded performance manifesting like this [1] in the logs. > > Later on this leads to various K8s errors [2], [3], up to missing > > notifications from the API, which causes failures in Kuryr-Kubernetes > > tempest tests. From what I've seen those etcd warnings normally mean > > that disk latency is high. > > > > This seems to be mostly happening on OVH and RAX hosts. I've looked at > > this with OVH folks and there isn't anything immediately alarming about > > their hosts running gate VM's. > > That's interesting because we've been working with amorin at OVH over > debugging similar IO problems and I think we both agree something is > happening. We've disabled the BHS1 region as the vast majority of > related failures were there, but kept GRA1 up and running which is > where your example is from. My understanding is that a memory issue > of some sort was found on the compute hypervisors (which could affect > disk throughput if there isn't memory for caching available or if > swap is using up available disk IO). We are currently waiting on > amorin's go ahead to turn BHS1 back on after this is corrected. > > > Upgrading the etcd version doesn't seem to help, as well as patch [4] > > which increases IO priority for etcd process. > > > > Any ideas of what I can try next? I think we're the only project that > > puts so much pressure on the DevStack's etcd. Help would really be > > welcomed, getting rid of this issue will greatly increase our gates > > stability. > > It wouldn't surprise me if others aren't using etcd much. One thing > that may help is to use the dstat data [5] from these failed jobs to > rule out resource contention from within the job (cpu, io(ps), > memory, etc). One thing we've found debugging these slower nodes is > that it often exposes real bugs in our software by making them cost > more. We should double check there isn't anything obvious like that > happening here too. There are multiple moments we're experiencing this, but mostly in interaction with K8s API, so of course software bug in there is possible. We've seen it earlier, but seems like failures became more often when we've updated K8s version. > I've been putting the csv file in https://lamada.eu/dstat-graph/ and > that renders it for human consumption. But there are other tools out > there for this too. I've rendered it as well, but besides finding a bug in dstat [6] that made it show that kuryr-daemon is using 2 TB of RAM I didn't noticed anything special, especially on io operations. In one of most recent failures there's only a spike on processes and paging [7] around the time we see fatal failure. Any ideas how I should proceed? From the number of rechecks we're doing you can easily see that this is hitting us hard. > > Thanks, > > Michał > > > > [1] > > http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/screen-etcd.txt.gz#_Dec_12_17_19_33_618619 > > [2] > > http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/screen-kubernetes-api.txt.gz#_Dec_12_17_20_19_772688 > > [3] > > http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/screen-kubernetes-scheduler.txt.gz#_Dec_12_17_18_59_045347 > > [4] https://review.openstack.org/#/c/624730/ > > > > > > [5] http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon-octavia/4a47162/controller/logs/dstat-csv_log.txt > [6] https://github.com/dagwieers/dstat/pull/162 [7] https://i.imgur.com/B8HQM8t.png From balazs.gibizer at ericsson.com Thu Dec 20 15:18:57 2018 From: balazs.gibizer at ericsson.com (=?iso-8859-1?Q?Bal=E1zs_Gibizer?=) Date: Thu, 20 Dec 2018 15:18:57 +0000 Subject: [nova] review guide for the bandwidth patches In-Reply-To: References: <1545231821.28650.2@smtp.office365.com> <1545316423.10879.3@smtp.office365.com> Message-ID: <1545319132.10879.4@smtp.office365.com> On Thu, Dec 20, 2018 at 3:47 PM, Jay Pipes wrote: > On 12/20/2018 09:33 AM, Balázs Gibizer wrote: >> On Thu, Dec 20, 2018 at 3:02 PM, Bence Romsics >> wrote: >>> Hi Gibi, >>> >>>> However I think we can use the feature flag approach. We can >>>> implement >>>> and verify everything in the current order without the end user >>>> seeing >>>> or causing any kind of inconsistencies. The nova implementation >>>> is >>>> only >>>> activated if a neutron port has a resource_request field. This >>>> field is >>>> added to the neutron API as an API extension. We can mark this >>>> extension experimental while we are working through the missing >>>> pieces >>>> of the feature. >>> >>> I like the idea of a feature flag, however technically in neutron we >>> don't directly control the list of extensions loaded. Instead what >>> we >>> control (through configuration) is the list of service plugins >>> loaded. >>> The 'resource_request' extension is implemented by the 'qos' service >>> plugin. But the 'qos' service plugin implements other API extensions >>> and features too. A cloud admin may want to use these other features >>> of the 'qos' service plugin, but not the guaranteed minimum >>> bandwidth. >>> Therefore I'd suggest adding the feature flag to nova to keep this >>> usage possible. >> >> Thanks Bence. I still want to belive that the proper solution for >> this >> long running implementation is to use a feature flag. Nova has a >> 'workaround' config section that might be used to add a new config >> option as a feature flag similar to the existing >> 'enable_numa_live_migration' option. This way the feature can be >> controller externally. >> >> Would be good to see the reaction from other Nova developers about >> this >> approch. > > The problem with feature flags is they are not discoverable. As much > as I hate API extensions, at least they are discoverable. > > Is there a reason why we can't just put code into Nova that, upon > seeing the resource requests, acts on it? Is there a reason it needs > to be behind a feature flag or even needs to query Neutron for > extension support? I mean, if it's in the response payload, just use > it, right? The currently proposed Nova implementation only acts if it sees a resource request in a neturon port[1]. However the currently proposed nova implementation is incomplete as I descibed in my inital mail of this thread. So Neutron can send resource request in the ports before Nova can fully handle it, which can lead to resource allocation inconsistencies. This is why I'm trying to merge the partial support (e.g. boot, delete) guarded by a feature flag while the other operations (migrate, evacuate) are under developement. Cheers, gibi [1] https://review.openstack.org/#/c/567268/41/nova/network/neutronv2/api.py at 1873 > > Best, > -jay > From jungleboyj at gmail.com Thu Dec 20 15:25:29 2018 From: jungleboyj at gmail.com (Jay Bryant) Date: Thu, 20 Dec 2018 09:25:29 -0600 Subject: [openstack-ansible][cinder] Multiple backends for Cinder In-Reply-To: References: Message-ID: <630fc946-bb08-9eb1-85ad-af658b6075b2@gmail.com> Cecilia, There isn't really a recommended configuration for what you are trying to do.  It really comes down to what works best for you. If Cinder has been performing well enough for you running on the Controller then I personally wouldn't change that. If you update your configuration to add the HPMSA backend it will start a new volume process for handling management of that backend.  So, it will be a separate process from the one that is currently managing the NFS storage.  Otherwise, you can configure the volume process to run on any other baremetal server for the HPMSA management.  That, however, seems overly complicated for your use case. Hope this helps. Jay On 12/20/2018 7:45 AM, Cecilia Di Maulo wrote: > Dear all, > > I currently have a NFS backend for Cinder and I would like to add an > iSCSI (hpmsa) backend. However I was wondering where should the cinder > services run? For now cinder-api.service and cinder-scheduler.service > run in a lxc while cinder-volume.service runs in bare metal on the > controllers. > > I also would like to separate as much as possible the 2 backend types > to be able to remove 'easily' my NFS backend once the other one has > proved it really works. > > I was thinking to have the services related to the NFS backend in a > lxc and the services related to the HPMSA backend on metal. Is this > even possible? How should I do it? Should I name 2 different services > in the container_skel or..? > > Thank you for your help, > > Best Regards, > > Cecilia From doug at doughellmann.com Thu Dec 20 15:27:22 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 20 Dec 2018 10:27:22 -0500 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> Message-ID: Doug Hellmann writes: > Thierry Carrez writes: > >> Hi, >> >> A while ago, the Technical Committee designated specific hours in the >> week where members would make extra effort to be around on #openstack-tc >> on IRC, so that community members looking for answers to their questions >> or wanting to engage can find a time convenient for them and a critical >> mass of TC members around. We currently have 3 weekly spots: >> >> - 09:00 UTC on Tuesdays >> - 01:00 UTC on Wednesdays >> - 15:00 UTC on Thursdays >> >> But after a few months it appears that: >> >> 1/ nobody really comes on channel at office hour time to ask questions. >> We had a questions on the #openstack-tc IRC channel, but I wouldn't say >> people take benefit of the synced time >> >> 2/ some office hours (most notably the 01:00 UTC on Wednesdays, but also >> to a lesser extent the 09:00 UTC on Tuesdays) end up just being a couple >> of TC members present >> >> So the schedule is definitely not reaching its objectives, and as such >> may be a bit overkill. I was also wondering if this is not a case where >> the offer is hurting the demand -- by having so many office hour spots >> around, nobody considers them special. >> >> Should we: >> >> - Reduce office hours to one or two per week, possibly rotating times >> >> - Dump the whole idea and just encourage people to ask questions at any >> time on #openstack-tc, and get asynchronous answers >> >> - Keep it as-is, it still has the side benefit of triggering spikes of >> TC member activity >> >> Thoughts ? >> >> -- >> Thierry Carrez (ttx) >> > > I would like for us to make a decision about this. > > The 0100 Wednesday meeting was generally seen as a good candidate to > drop, if we do drop one. No one seemed to support the idea of rotating > meeting times, so I'm going to eliminate that from consideration. We can > discuss the idea of changing the schedule of the meetings separately > from how many we want to have, so I will also postpone that question for > later. > > TC members, please respond to this thread indicating your support for > one of these options: > > 1. Keep the 3 fixed office hours. > 2. Drop the 0100 Wednesday meeting, keeping the other 2. > 3. Drop all office hours. > > -- > Doug My impression of the answers so far is that everyone would be able to live with option 1 (keeping the 3 fixed office hour slots), so let's do that. If you disagree, please do speak up. I know we haven't heard from everyone, yet. Does anyone want to propose any schedule changes? -- Doug From nickeysgo at gmail.com Thu Dec 20 15:48:11 2018 From: nickeysgo at gmail.com (Minjun Hong) Date: Fri, 21 Dec 2018 00:48:11 +0900 Subject: [Cinder] Image Name of all Instances does not show up Message-ID: Hi. After I installed Cinder, 'Image Name' of the created instances does not show up on horizon. When I created instances without Cinder, 'Image Name' of all instances was filled with the name of image which is used for creating the instance on horizon, like this link (https://imgur.com/0Habda7). Actually, although this does not cause any critical incorrect operation, it can make the users who use the Openstack system confused what image is used for the instances. That's why I need to resolve this issue. How can I fill 'Image Name' column with the name of the image ? Thanks! Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufar at onf-ambassador.org Thu Dec 20 15:57:27 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Thu, 20 Dec 2018 22:57:27 +0700 Subject: [magnum] Magnum missing project ID for octavia client Message-ID: Hi, I am trying to create Kubenetes multi-master with Magnum. I get 'Create Failed error` in etcd_lb and api_lb and the log is : OctaviaClientException: resources.etcd_lb.resources.loadbalancer: Validation failure: Missing project ID in requea-8cce-27a3c49b9d28) full log from /var/log/magnum/magnum-conductor.api : 2018-12-20 22:41:33.362 9733 ERROR magnum.drivers.heat.driver [req-98498689-f584-47ab-b500-839a9e0d07cc - - - - -] Cluster error, stack staton: Resource CREATE failed: OctaviaClientException: resources.etcd_lb.resources.loadbalancer: Validation failure: Missing project ID in requ2a-8cce-27a3c49b9d28) I have working Octavia and magnum (only with 1 master, kubernetes or docker), this is my magnum configuration : [api] host = 10.111.111.10 [certificates] cert_manager_type = x509keypair [database] connection = mysql+pymysql:// magnum:556a8c5002cce3d8933 at 10.111.111.100/magnum [keystone_authtoken] memcached_servers = 10.111.111.10:11211,10.111.111.20:11211, 10.111.111.30:11211 auth_version = v3 auth_uri = http://10.111.111.100:5000/v3 project_domain_id = default project_name = service user_domain_id = default password = a13dfbbac5a0e03754773 username = magnum auth_url = http://10.111.111.100:35357 auth_type = password admin_user = magnum admin_password = a13dfbbac5a0e03754773 admin_tenant_name = service [trust] trustee_domain_name = magnum trustee_domain_admin_name = magnum_domain_admin trustee_domain_admin_password = b13dfbbac5a0e03754773 trustee_keystone_interface = public [oslo_messaging_notifications] driver = messaging [DEFAULT] transport_url=rabbit://openstack:5e81fb9286a573a1e4e33 at 10.111.111.10:5672, openstack:5e81fb9286a573a1e4e3 at 10.111.111.20:5672, openstack:5e81fb9286a573a1e4e3 at 10.111.111.30:5672 log_dir=/var/log/magnum [cinder_client] region_name = RegionOne [octavia_client] region_name = RegionOne Anyone know what is the problem? Thank you. Best Regards, Zufar Dhiyaulhaq -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Thu Dec 20 16:08:12 2018 From: smooney at redhat.com (Sean Mooney) Date: Thu, 20 Dec 2018 16:08:12 +0000 Subject: [Cinder][horizon] Image Name of all Instances does not show up In-Reply-To: References: Message-ID: <2e3102a47ebb73a5522a90ea154d11dc1d87e2c5.camel@redhat.com> On Fri, 2018-12-21 at 00:48 +0900, Minjun Hong wrote: > Hi. > After I installed Cinder, 'Image Name' of the created instances does not show up on horizon. > When I created instances without Cinder, 'Image Name' of all instances was filled with the name of image which is used > for creating the instance on horizon, like this link (https://imgur.com/0Habda7). > > Actually, although this does not cause any critical incorrect operation, it can make the users who use the Openstack > system confused what image is used for the instances. > That's why I need to resolve this issue. > > How can I fill 'Image Name' column with the name of the image ? this happens when using a boot from volume instance. the image name is stored in the instance root vlomue metadata horizon obvirously is not reading it from that location. since the vm was not actully booted form an image it does not have one associated with the instance iteslf. To correct this the horizon interface will likely need to be modified to determin the root volume and retrinve the image from there. i have added horizon to the subject as this is not really a cinder issue. this is more of less expected behavior based on the internal of how this works. you did not mention what realase of openstack you are using so its also posible this has been resoved in later releases. > Thanks! Regards, From openstack at nemebean.com Thu Dec 20 16:20:57 2018 From: openstack at nemebean.com (Ben Nemec) Date: Thu, 20 Dec 2018 10:20:57 -0600 Subject: [tripleo][ci] Reducing merge time by moving nv job to experimental In-Reply-To: References: Message-ID: <776615dd-02fd-d21b-486a-69b446b532f3@nemebean.com> On 12/20/18 1:07 AM, Felix Enrique Llorente Pastora wrote: >  The problem with >> experimental is that it requires folks to know to run them (which >> generally does not happen for our project). > > So we have two options here: > - Make experimental pipeline run on reviews directly without the > "check-experimental" comment. > - Create a new pipeline "draf" pipeline at infra, that runs WIP jobs or > problematic jobs without interfering in normal production "check" pipeline. > > What do you think ? I think Alex already answered this: Fix the scenario jobs so they can be voting again. We need that coverage or we'll be perpetually breaking services that are only tested in scenarios. As a result, any queue hacks that we do would only be temporary anyway. There's no good reason to spend a bunch of time on a one-off configuration that will go away in the near future (hopefully ;-). > > On Wed, Dec 19, 2018 at 3:48 PM Alex Schultz > wrote: > > On Wed, Dec 19, 2018 at 7:44 AM Alex Schultz > wrote: > > > > On Wed, Dec 19, 2018 at 7:34 AM Felix Enrique Llorente Pastora > > > wrote: > > > > > > Hello, > > > > > >    To reduce merge time, would be nice from a review to go from > check pipeline to gate pipeline without waiting for non-voting jobs, > one way to do that is changing non-voting jobs at different pipelien > like experimental one, so we have their result but don't wait for > them to change to gate pipepeline. > > > > > > > The goal should be to get them to voting.  The problem with > > experimental is that it requires folks to know to run them (which > > generally does not happen for our project).  We currently have the > > scenario jobs as non-voting because of capacity problems but we still > > need the coverage so I'm not keen on moving them to non-voting. I'd > > err experimental not non-voting. > > > rather we spend the time to land the standalone versions and get them > > voting again. > > > > Thanks, > > -Alex > > > > > -- > > > Quique Llorente > > > > > > Openstack TripleO CI > > > > -- > Quique Llorente > > Openstack TripleO CI From nickeysgo at gmail.com Thu Dec 20 16:35:43 2018 From: nickeysgo at gmail.com (Minjun Hong) Date: Fri, 21 Dec 2018 01:35:43 +0900 Subject: [Cinder][horizon] Image Name of all Instances does not show up In-Reply-To: <2e3102a47ebb73a5522a90ea154d11dc1d87e2c5.camel@redhat.com> References: <2e3102a47ebb73a5522a90ea154d11dc1d87e2c5.camel@redhat.com> Message-ID: On Fri, Dec 21, 2018 at 1:08 AM Sean Mooney wrote: > On Fri, 2018-12-21 at 00:48 +0900, Minjun Hong wrote: > > Hi. > > After I installed Cinder, 'Image Name' of the created instances does not > show up on horizon. > > When I created instances without Cinder, 'Image Name' of all instances > was filled with the name of image which is used > > for creating the instance on horizon, like this link ( > https://imgur.com/0Habda7). > > > > Actually, although this does not cause any critical incorrect operation, > it can make the users who use the Openstack > > system confused what image is used for the instances. > > That's why I need to resolve this issue. > > > > How can I fill 'Image Name' column with the name of the image ? > this happens when using a boot from volume instance. > the image name is stored in the instance root vlomue metadata > horizon obvirously is not reading it from that location. > since the vm was not actully booted form an image it does not have one > associated with the instance iteslf. To correct this the horizon interface > will > likely need to be modified to determin the root volume and retrinve the > image from there. > i have added horizon to the subject as this is not really a cinder issue. > this is more of less expected behavior based on the internal of how this > works. > > you did not mention what realase of openstack you are using so its also > posible > this has been resoved in later releases. > > Thanks! Regards, > > Thanks for your kind reply, Sean. I'm currently using Queens and I want to know where the patch is. If you don't mind, could you give me the link? Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbragstad at gmail.com Thu Dec 20 17:00:04 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Thu, 20 Dec 2018 11:00:04 -0600 Subject: [tc] Technical Committee Status for 17 Dec 2081 In-Reply-To: References: Message-ID: On Mon, Dec 17, 2018 at 12:18 PM Doug Hellmann wrote: > This is the (mostly) weekly summary of work being done by the Technical > Committee members. The full list of active items is managed in the > wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker > > We also track TC objectives for the cycle using StoryBoard at: > https://storyboard.openstack.org/#!/project/923 > > == Recent Activity == > > Project updates: > > * Add os-resource-classes under Nova: > https://review.openstack.org/#/c/621699/ > > Other updates: > > * I added a TC "house rule" for voting on updates to the release > management metadata for projects, to make it easier to keep those up > to date: https://review.openstack.org/#/c/622989/ > * Thierry has been working on a series of changes on behalf of the > release management team to record the release management style used > for each deliverable listed in the governance repository. > ** https://review.openstack.org/#/c/622902/ > ** https://review.openstack.org/#/c/622903/ > ** https://review.openstack.org/#/c/622904/ > ** https://review.openstack.org/#/c/624704/ > ** https://review.openstack.org/#/c/624951/ > ** https://review.openstack.org/#/c/624996/ > * I updated the documentation of chair responsibilities to include the > OSF annual report: https://review.openstack.org/#/c/624790/ > * Lance proposed an update to document the process for changing PTLs in > the middle of a cycle: https://review.openstack.org/#/c/620928/ > * Ghanshyam proposed an update to clarify the term of TC chair, since > some responsibilities include managing the election fo the next chair: > https://review.openstack.org/#/c/621498/ > * Zane's resolution describing how we will keep up with future Python 3 > releases has been approved: https://review.openstack.org/#/c/613145/ > * Thierry and Chris' work to document the role of the TC has been > approved: https://review.openstack.org/#/c/622400/ > * I documented the official topic tags used to designate the voting > rules to apply to each governance patch: > https://review.openstack.org/#/c/625004/ > > == TC Meetings == > > The next TC meeting will be 3 December @ 1400 UTC in #openstack-tc. See > http://eavesdrop.openstack.org/#Technical_Committee_Meeting for details > This will be on 3 January, right? > > == Ongoing Discussions == > > Ghanshyam has proposed an enhancement to the Vision for OpenStack Clouds > to cover feature discovery. > > * https://review.openstack.org/#/c/621516/ > > I have proposed an update to the TC house voting rules to cover > documentation changes in the governance repository. > > * https://review.openstack.org/625005 > > Dougal Matthews is stepping down as Mistral PTL, to be replaced by Renat > Akhmerov. > > * https://review.openstack.org/#/c/625537/ > > == TC member actions/focus/discussions for the coming week(s) == > > We need to work to approve Sean's patch with the Stein supported/testing > runtimes list. > > * https://review.openstack.org/611080 > > Thierry started a thread on the mailing list about adapting our office > hours times. It would be good for us to resolve that so we can make the > change after the new year, so I have renewed the thread with a summary > of the options. Please vote. > > * > http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001036.html > > == Contacting the TC == > > The Technical Committee uses a series of weekly "office hour" time > slots for synchronous communication. We hope that by having several > such times scheduled, we will have more opportunities to engage > with members of the community from different timezones. > > Office hour times in #openstack-tc: > > - 09:00 UTC on Tuesdays > - 01:00 UTC on Wednesdays > - 15:00 UTC on Thursdays > > If you have something you would like the TC to discuss, you can add > it to our office hour conversation starter etherpad at: > https://etherpad.openstack.org/p/tc-office-hour-conversation-starters > > Many of us also run IRC bouncers which stay in #openstack-tc most > of the time, so please do not feel that you need to wait for an > office hour time to pose a question or offer a suggestion. You can > use the string "tc-members" to alert the members to your question. > > You will find channel logs with past conversations at > http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ > > If you expect your topic to require significant discussion or to > need input from members of the community other than the TC, please > start a mailing list discussion on openstack-discuss at > lists.openstack.org > and use the subject tag "[tc]" to bring it to the attention of TC > members. > > -- > Doug > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manuel.sb at garvan.org.au Thu Dec 20 15:17:27 2018 From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros) Date: Thu, 20 Dec 2018 15:17:27 +0000 Subject: [IRONIC] vif attached to baremetal node DOWN Message-ID: <9D8A2486E35F0941A60430473E29F15B017BAFA31B@MXDB2.ad.garvan.unsw.edu.au> Dear Openstack community, I am having huge problems setting up baremetal port group: PROBLEM: VIF DOWN Environment: Openstack Rocky Deployment: kolla-ansible 7.0.0 Provider network # SERVER AND NEUTRON PORTS ########################## [root at openstack-deployment ~]# openstack server list +--------------------------------------+------------+--------+-----------------+-------------------+---------------------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+------------+--------+-----------------+-------------------+---------------------+ | ce8e10ab-12b4-476e-8990-b2aeda8510a0 | demo1 | ACTIVE | hpc=10.0.32.103 | centos7.5-image | my-baremetal-flavor | ... +--------------------------------------+------------+--------+-----------------+-------------------+---------------------+ [root at openstack-deployment ~]# openstack port list +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ | 1e1c3f40-1ee0-46d1-8e38-0b0617893ccf | | 7c:fe:90:12:1f:f0 | ip_address='10.0.32.103', subnet_id='506af593-659b-4c58-a180-897dd0b04957' | DOWN | ... +--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+ # BAREMETAL PORT GROUP ###################### [root at openstack-deployment ~]# openstack baremetal port group show 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 +----------------------------+------------------------------------------------------------------------------------+ | Field | Value | +----------------------------+------------------------------------------------------------------------------------+ | address | 7c:fe:90:12:1f:f0 | | created_at | 2018-12-20T14:27:53+00:00 | | extra | {} | | internal_info | {u'tenant_vif_port_id': u'1e1c3f40-1ee0-46d1-8e38-0b0617893ccf'} | | mode | 802.3ad | | name | zeus-54-hpc-bond | | node_uuid | e30e76a4-a39e-4560-9bff-d3d9af66c503 | | properties | {u'downdelay': 0, u'miimon': 110, u'xmit_hash_policy': u'layer2+3', u'updelay': 0} | | standalone_ports_supported | False | | updated_at | 2018-12-20T14:28:57+00:00 | | uuid | 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 | +----------------------------+------------------------------------------------------------------------------------+ # BAREMETAL PORTS ################## [root at openstack-deployment ~]# openstack baremetal port show 4a00e6fa-a7c1-4916-b540-01fef95c90c1 +-----------------------+--------------------------------------+ | Field | Value | +-----------------------+--------------------------------------+ | address | 7c:fe:90:12:1f:f0 | | created_at | 2018-12-20T14:28:09+00:00 | | extra | {} | | internal_info | {} | | local_link_connection | {} | | node_uuid | e30e76a4-a39e-4560-9bff-d3d9af66c503 | | physical_network | physnet1 | | portgroup_uuid | 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 | | pxe_enabled | True | | updated_at | None | | uuid | 4a00e6fa-a7c1-4916-b540-01fef95c90c1 | +-----------------------+--------------------------------------+ [root at openstack-deployment ~]# openstack baremetal port show 4510e849-ed21-46f8-bf4c-ca91c7e6b648 +-----------------------+--------------------------------------+ | Field | Value | +-----------------------+--------------------------------------+ | address | 7c:fe:90:12:1f:f1 | | created_at | 2018-12-20T14:28:14+00:00 | | extra | {} | | internal_info | {} | | local_link_connection | {} | | node_uuid | e30e76a4-a39e-4560-9bff-d3d9af66c503 | | physical_network | physnet1 | | portgroup_uuid | 2de8c1ae-a5bf-418e-b07a-1c0fbf676f36 | | pxe_enabled | True | | updated_at | None | | uuid | 4510e849-ed21-46f8-bf4c-ca91c7e6b648 | +-----------------------+--------------------------------------+ # NETWORK AND SUBNET CONFIG ############################### [root at openstack-deployment ~]# openstack network show hpc +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | UP | | availability_zone_hints | | | availability_zones | nova | | created_at | 2018-12-17T02:07:46Z | | description | | | dns_domain | None | | id | f630b54b-2b07-44a3-8196-5a0ea9cc7969 | | ipv4_address_scope | None | | ipv6_address_scope | None | | is_default | None | | is_vlan_transparent | None | | location | None | | mtu | 1500 | | name | hpc | | port_security_enabled | True | | project_id | b91520cff5bd45c59a8de07c38641582 | | provider:network_type | flat | | provider:physical_network | physnet1 | | provider:segmentation_id | None | | qos_policy_id | None | | revision_number | 3 | | router:external | Internal | | segments | None | | shared | True | | status | ACTIVE | | subnets | 506af593-659b-4c58-a180-897dd0b04957 | | tags | | | updated_at | 2018-12-20T12:21:09Z | +---------------------------+--------------------------------------+ [root at openstack-deployment ~]# openstack subnet show hpc_subnet +-------------------+--------------------------------------+ | Field | Value | +-------------------+--------------------------------------+ | allocation_pools | 10.0.32.100-10.0.32.150 | | cidr | 10.0.0.0/16 | | created_at | 2018-12-17T02:07:49Z | | description | | | dns_nameservers | 8.8.8.8 | | enable_dhcp | True | | gateway_ip | 10.0.32.1 | | host_routes | | | id | 506af593-659b-4c58-a180-897dd0b04957 | | ip_version | 4 | | ipv6_address_mode | None | | ipv6_ra_mode | None | | location | None | | name | hpc_subnet | | network_id | f630b54b-2b07-44a3-8196-5a0ea9cc7969 | | project_id | b91520cff5bd45c59a8de07c38641582 | | revision_number | 2 | | segment_id | None | | service_types | | | subnetpool_id | None | | tags | | | updated_at | 2018-12-20T12:21:09Z | +-------------------+--------------------------------------+ # BONUS: THIS IS THE NIC CONFIGURATION THAT WORKS ON A SERVER ############################################################## [root at zeus-52 ~]# cat /etc/sysconfig/network-scripts/ifcfg-Bond_connection_1 BONDING_OPTS="downdelay=0 miimon=110 mode=802.3ad updelay=0" TYPE=Bond BONDING_MASTER=yes MTU=9000 PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=none IPADDR=10.0.32.52 PREFIX=16 GATEWAY=10.0.32.1 DNS1=8.8.8.8 DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_PRIVACY=no IPV6_ADDR_GEN_MODE=stable-privacy NAME="Bond connection 1" UUID=5153a698-46ca-4234-a71b-7c88e4c92b91 DEVICE=bond0 ONBOOT=yes Any thought about what am I doing wrong or what to do next? Thank you very much 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: From thierry at openstack.org Thu Dec 20 17:17:16 2018 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 20 Dec 2018 18:17:16 +0100 Subject: [tc] Adapting office hours schedule to demand In-Reply-To: References: <20cbf1ae-eb09-5193-01cd-0f14fa674a51@openstack.org> Message-ID: <45907726-fb13-2644-f867-6e938ebb2b5d@openstack.org> Doug Hellmann wrote: > My impression of the answers so far is that everyone would be able to > live with option 1 (keeping the 3 fixed office hour slots), so let's do > that. > > If you disagree, please do speak up. I know we haven't heard from > everyone, yet. I have no objection. I just wanted us to take a quick step back and reconsider, given the limited outside participation we've been getting on those. I agree that they are cheap to maintain and create peaks of activity in the channel that are generally useful. -- Thierry Carrez (ttx) From smooney at redhat.com Thu Dec 20 17:20:54 2018 From: smooney at redhat.com (Sean Mooney) Date: Thu, 20 Dec 2018 17:20:54 +0000 Subject: FW: [networking-ovs-dpdk] Issue creating br-ex... In-Reply-To: References: Message-ID: <4b040675ed74ad1966ef7839fdf5d96c5fb639d2.camel@redhat.com> hi i am the maintainer of networking-ovs-dpdk sorry i did not see this until now as i moved company and my new email account is only subsribed to openstack-discuss and i dont not ehve a filter to highlight [networking-ovs-dpdk] topics yet. ill correct that. On Thu, 2018-12-20 at 10:39 +0000, d.lake at surrey.ac.uk wrote: > "Have you tried running this by hand on the system and see what happens? > > 'sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev'" you should never need to set this. if you want a br-ex to exist it should be specified in the OVS_BRRIDGE_MAPPINGS that will instuct the devstack plugin to create the bridge. you will then need to specify the port using the OVS_DPDK_PORT_MAPPINGS. e.g. assuming eth0 is managment eth1 is wan link and eth2 is datacenter network for teantat traffic. OVS_BRIDGE_MAPPINGS=wan:br-ex,datacenter:br-tenant OVS_DPDK_PORT_MAPPINGS=eth1:br-ex,eth2:br-tenant > > Yes - that creates the br-ex in ovs-vsctl on the second attempt but it does not create a bridge that ip link can act > on. > > If I do an "ip link show br-ex" after the installation script has run, then I do not see a bridge at all on this > system. > > There is no PUBLIC_BRIDGE because I'm not using one. I am creating 4 DPDK NICS which are connected to the virtual > machines. Again, after many, many weeks of testing to arrive at a known-good configuration script, the assumption was > that we could just push-the-button and roll-out re-installations at-will. that shoudl be possible i have not chagned my local.confs much for many years that said the ones in teh repo are rather outdated as most of the local.conf enteries are nolonger needed. > > I will have 4 ovs bridge ports - br-dpdk1, br-dpdk2, br-dpdk3, br-dpdk4. Each one will connect to one physical > NIC. Each will then be known in OpenStack as physnet1, physnet2, physnet3, physnet4. This is how my existing > system is setup and working using the Devstack installation system. that is relitively striat froward with devstack you would do this by setting OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2,physnet3:br-dpdk3,physnet4:br-dpdk4 OVS_DPDK_PORT_MAPPINGS=eth1:br-dpdk1,eth2:br-dpdk2,eth3:br-dpdk3,eth4:br-dpdk4 if you want to use a br-ex in this deployment you will need to also add it to both of the above. if you dont make sure Q_USE_PROVIDERNET_FOR_PUBLIC=True. the Q_USE_PROVIDERNET_FOR_PUBLIC is deprecated as the external_network_bridge option in the l3 agent is being removed in stien https://review.openstack.org/#/c/567369/. > > > " Short of that you should look at what's changed in the relevant files in the devstack tree to see if it was caused > by a recent change." > > But I have no idea where to start looking! > > I've also had to give up trying to install Queens as the installation script moans about oslo.concurrency and seems to > be installing a version that it KNOWS is not compatible. this might be because of how networking-ovs-dpdk install itself without using the upper-constiarints https://github.com/openstack/networking-ovs-dpdk/blob/master/devstack/plugin.sh#L33-L35 i have been meaning to fix this for litrally years but it has never broken our ci so it was alway a low prioity bug. ill submit a patch to correct that. > Again, this is something that worked perfectly on the installation I carried out in August. Surely nothing can have > changed in the basic installation in less than 6 months? Even the basic command for cloning the networking_ovs_dpdk > broke from the working local.conf because the -b stable/queens suffix failed. this failed as i did not get time to curt the stable/queens branch as i was not working upstream activly for most of the queens cycle. i have created it now. > In fact looking at the source site for that piece of code, there is no queens release on the site anymore. I am now > not sure if the version I have is compatible or not! i have retroactivly taged the versions that should be compatible. note that the networking-ovs-dpdk repo is only needed when using devstack to install as it provides the plugin. in a production enviornmen after juno or kilo i belive we had upstream all the fuctional python changes to neutron. As such networking-ovs-dpdk is really just used for developemnt and ci as a devstack plugin to simplfy installation. because it can install ovs-dpdk from source and apply patches form patchwork i also use it to test some patches before they are merged into ovs to ensure they are compatible with how openstack uses ovs-dpdk. > > So I've had to clone devstack master which has now lead to the Cinder bug which I am now trying to patch around. > > I'm hoping that we can get to a stable system by the time the centre shuts for Christmas tomorrow. Four days should > have been more than enough given the working system which took three months to build! im sorry the experince has been so rough for you. i have had almost no time to maintain this repo for the better part of a year there are several cleanup i plan to work on while im on vacation and before the end of the cycle. as the usecase i have been testing locally have all contiued to work i have assumed it contiued to work but i have only been testing master and the ci system that was testign older release is offline. i am planning to set up a new ci before teh end of stien release and will be hopefully get time to refactor some of the legacy documentation and implementation choices. > > Frustrated - but thank you for your help. if you can provide a description of the enviromnemtn you want to deploy i can proably provide a local.conf for the 3 commons senairos for you e.g. all-in-one, controller, compute but it may be some time before i check my email again as i was ment to already be on vaction. > > David > > > -----Original Message----- > From: Brian Haley > Sent: 20 December 2018 00:07 > To: Lake, David (PG/R - Elec Electronic Eng) ; openstack at lists.openstack.org > Subject: Re: FW: [networking-ovs-dpdk] Issue creating br-ex... > > On 12/19/18 3:29 PM, d.lake at surrey.ac.uk wrote: > > Would appreciate some help here please. Br-ex is not being added and > > the mtu command causes the whole thing to not install. > > Comments inline. > > > *From:*Lake, David (PG/R - Elec Electronic Eng) > > *Sent:* 19 December 2018 15:22 > > *To:* openstack-dev at lists.openstack.org > > *Subject:* [networking-ovs-dpdk] Issue creating br-ex... > > > > Hello > > > > Trying to re-run a Queens DPDK all-in-one using devstack which I built > > in August and hitting issues. > > > > The local.conf is identical between the two machines except I had to > > take the "stable/queens" off the end of the "networking-ovs-dpdk" > > plugin line as that no longer appears to work. > > > > The installation seems to proceed until it gets to setting the ip mtu > > on br-ex. > > > > I'm not using br-ex. I've declared OVS bridge mappings in the local.conf: > > > > #Dual socket platform with 16GB RAM,3072*2048kB hugepages leaves ~4G > > for the system. > > > > OVS_NUM_HUGEPAGES=3072 > > > > #Dual socket platform with 64GB RAM,14336*2048kB hugepages leaves ~6G > > for the system. > > > > #OVS_NUM_HUGEPAGES=14336 > > > > OVS_DATAPATH_TYPE=netdev > > > > OVS_LOG_DIR=/opt/stack/logs > > > > #OVS_DPDK_PORT_MAPPINGS=p1p1:br-dpdk1,p1p2:br-dpdk2,p2p1:br-dpdk3,p2p2 > > :br-dpdk4 > > > > OVS_DPDK_PORT_MAPPINGS=p6p1:br-dpdk1,p6p2:br-dpdk2 > > > > #OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2,physnet3:br-d > > pdk3,physnet4:br-dpdk4 > > > > OVS_BRIDGE_MAPPINGS=physnet1:br-dpdk1,physnet2:br-dpdk2 > > > > [[post-config|$NOVA_CONF]] > > > > [DEFAULT] > > > > firewall_driver=nova.virt.firewall.NoopFirewallDriver > > > > scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilt > > er,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilte > > r > > > > [[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]] > > > > [OVS] > > > > datapath_type=netdev > > > > [ml2_type_flat] > > > > #flat_networks=physnet1,physnet2,physnet3,physnet4 > > > > flat_networks=physnet1,physnet2 > > > > I cannot stress again how identical these systems are - same hardware, > > same base OS install (CentOS 7.5). I was (maybe erroneously!) > > thinking that if I had it devstack working on one system, having an > > identical system would be a piece of cake to install. > > > > This is the installation error: > > > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:21 local > > bridge=br-ex > > > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:22 local > > 'addbr_cmd=sudo ovs-vsctl -- --may-exist add-br br-ex' > > > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:24 '[' > > netdev '!=' system ']' > > > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:25 > > addbr_cmd='sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge > > br-ex datapath_type=netdev' > > > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_bridge:28 sudo > > ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex > > datapath_type=netdev > > Have you tried running this by hand on the system and see what happens? > > 'sudo ovs-vsctl -- --may-exist add-br br-ex -- set Bridge br-ex datapath_type=netdev' > > It works for me locally, creating br-ex. Perhaps there is some delay on your system? But I would expect the call > wouldn't return successfully then. > > Or perhaps I'm mis-understanding and you meant to set PUBLIC_BRIDGE in your local.conf as well? > > Short of that you should look at what's changed in the relevant files in the devstack tree to see if it was caused by > a recent change. > > -Brian > > > > +lib/neutron_plugins/ovs_base:_neutron_ovs_base_add_public_bridge:119 > > set_mtu br-ex 1500 > > > > +functions:set_mtu:750 local dev=br-ex > > > > +functions:set_mtu:751 local mtu=1500 > > > > +functions:set_mtu:752 sudo ip link set mtu 1500 > > +dev > > br-ex > > > > Cannot find device "br-ex" > > > > +functions:set_mtu:1 exit_trap > > > > +./stack.sh:exit_trap:522 local r=1 > > > > ++./stack.sh:exit_trap:523 jobs -p > > > > +./stack.sh:exit_trap:523 jobs= > > > > +./stack.sh:exit_trap:526 [[ -n '' ]] > > > > +./stack.sh:exit_trap:532 '[' -f /tmp/tmp.Dzbqzlk2fs ']' > > > > +./stack.sh:exit_trap:533 rm /tmp/tmp.Dzbqzlk2fs > > > > +./stack.sh:exit_trap:537 kill_spinner > > > > +./stack.sh:kill_spinner:432 '[' '!' -z '' ']' > > > > +./stack.sh:exit_trap:539 [[ 1 -ne 0 ]] > > > > +./stack.sh:exit_trap:540 echo 'Error on exit' > > > > Error on exit > > > > +./stack.sh:exit_trap:542 type -p generate-subunit > > > > +./stack.sh:exit_trap:543 generate-subunit 1545230781 > > 1747 fail > > > > +./stack.sh:exit_trap:545 [[ -z > > +/opt/stack/logs/screen ]] > > > > +./stack.sh:exit_trap:548 > > /home/stack/devstack/tools/worlddump.py -d /opt/stack/logs/screen > > > > Can someone explain what is going on here please? > > > > Thanks > > > > > > David > > > > From mriedemos at gmail.com Thu Dec 20 17:54:25 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 20 Dec 2018 11:54:25 -0600 Subject: [nova] review guide for the bandwidth patches In-Reply-To: <1545231821.28650.2@smtp.office365.com> References: <1545231821.28650.2@smtp.office365.com> Message-ID: On 12/19/2018 9:03 AM, Balázs Gibizer wrote: > * the next two patches [6][7] implement rejecting use cases that was > decided to out of scope for the feature (interface attach with resource > requst, booting with network having resource request) I really thought these would go *before* any new feature changes since we currently do not support these types of ports, so if a user were to create a port (or network) with QoS rules and attach it to a server in nova, we're just ignoring it, which is essentially broken. I think of this like how we rejected attempts to rebuild a volume-backed server with a new image (we used to just let that slide with no errors but it didn't actually rebuild the root volume) or trying to attach SR-IOV ports (again, not supported in compute). I think of the "reject" patches more as bug fixes for existing broken, or at least misleading, code. > * The next patch [8] add support for removing resource allocation > during interface detach if the detached port has resource request This is one example of how the implementation is backward. This is something that would be necessary plumbing before enabling a new feature in the API (assuming this cleanup happens in nova-compute?). > * The rest of the series up until [9] implement support for selecting > VFs form the same PF that the bandwidth was allocated from. This allows > handling bandwidth and VF resources properly even if there are more > than one PFs on the same compute connected to the same physnet. This is really kind of news to me. Maybe I glossed over this or didn't understand it in the spec, but the spec doesn't really say much about this either. There is only one mention of VFs in the spec: "When multiple ports, having QoS policy rules towards the same physical network, are attached to the server (e.g. two VFs on the same PF) then the resulting allocation is the sum of the resource amounts of each individual port request." Anyway, it seems like a sub-feature and I just didn't realize it. > > What is still missing from the patch series: > * Support for any kind of server move operations (resize, migrate, > evacuate, live-migrate, unshelve) > * Upgrade support: Bound SRIOV ports might already have QoS policy that > would need healing resource allocation in placement. This wouldn't be a problem if we were already rejecting ports with QoS rules applied as mentioned above. > > Order of the patches > -------------------- > > One comment I got from Matt is that the patches are in wrong order. The > current order allows booting server with bandwidth request_before_ > every other server operation is supported (or rejected). This could > lead to the violation of the resource view of the system. For example > booting a server with a QoS aware port will result in bandwidth > allocation on the compute host. But then later on migrating that server > to another host does not properly handle moving the allocation to the > target host. > > In my view reordering the patches to only allow booting the first > server with bandwdith after every other operation is supported is not > feasible. The current chain is already 17 patches long and it does not > touch server moving operations at all. Also if I cannot boot a server > with bandwidth then I cannot test that such server can be moved > properly. So all the functional test would end up in the last patch of > the series. When I say wrong order, I mostly mean from the bottom up, not from a feature parity perspective. The normal way a long complicated feature series like this that involves the entire stack would be to start plumbing code into nova-compute at the bottom layer and then work your way up to the control layer services (conductor/scheduler) and finally the API where the feature is turned on (usually with a microversion). I am semi OK with deferring move operation support in v1 and building that on later given the complicated nature of this feature, but my real issue in the order is the backward nature of it (I don't want to approve patches that add code to the API for a feature just to leave it fall on the ground if the compute code isn't already merged). > > However I think we can use the feature flag approach. We can implement > and verify everything in the current order without the end user seeing > or causing any kind of inconsistencies. The nova implementation is only > activated if a neutron port has a resource_request field. This field is > added to the neutron API as an API extension. We can mark this > extension experimental while we are working through the missing pieces > of the feature. But we can also turn on that extension in our test > envirnoment to verify each and every step during the implementation > process. I'm definitely not crazy about the feature flag idea, but I need to read and reply to the other responses in the thread first. > > > Which RP fulfills the request of a neutron port > ----------------------------------------------- > > Neutron expects a single RP uuid sent by nova in the port binding that > tells neutron about which RP providers the resources for that port. > This is the famous problem to find which request group is fulfilled by > which resource provider in an allocation candidate. There are 3 > possible solutions: > > * Neutron does the mapping. This would require Neutron to see each port > binding for a given server as a single request. This is not the case > today and not feasible to hack around in neutron. Before I started reviewing the code, I read the spec again to get the context in my head and I really thought this is what was proposed - that the allocation candidates that we used to claim resources in the scheduler would be passed through to the port binding request and neutron would sort out whatever it needed to from that. This is the section of the spec I'm thinking of: https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/bandwidth-resource-provider.html#mapping-between-physical-resource-consumption-and-claimed-resources Did something change drastically since the spec was written such that nova needs to do this now, at least temporarily? -- Thanks, Matt From mriedemos at gmail.com Thu Dec 20 17:57:55 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 20 Dec 2018 11:57:55 -0600 Subject: [nova] review guide for the bandwidth patches In-Reply-To: References: <1545231821.28650.2@smtp.office365.com> Message-ID: <2a13e4e3-2add-76ef-9fd9-018dfc493cdb@gmail.com> On 12/20/2018 8:02 AM, Bence Romsics wrote: > I like the idea of a feature flag, however technically in neutron we > don't directly control the list of extensions loaded. Instead what we > control (through configuration) is the list of service plugins loaded. > The 'resource_request' extension is implemented by the 'qos' service > plugin. But the 'qos' service plugin implements other API extensions > and features too. A cloud admin may want to use these other features > of the 'qos' service plugin, but not the guaranteed minimum bandwidth. > Therefore I'd suggest adding the feature flag to nova to keep this > usage possible. Can't the resource_request part of this be controlled via policy rules or something similar? If neutron were using microversions, users would have to opt into this new QoS bandwidth behavior and nova, as a client, would also have to request that information about each port from neutron to know if it's even available in the neutron server version they are talking to. Anyway, microversions aside, it's not clear to me why a neutron API extension doesn't control if this new field is added to the port resource response? Barring that, are policy rules something that could be used for deployers could decide which users can use this feature while it's being rolled out? -- Thanks, Matt From chris at openstack.org Thu Dec 20 17:58:57 2018 From: chris at openstack.org (Chris Hoge) Date: Thu, 20 Dec 2018 09:58:57 -0800 Subject: [loci] Stable Branches in Loci In-Reply-To: <20181218054413.GG6373@thor.bakeyournoodle.com> References: <3855B170-6E38-4DB9-A91C-9389D16D387F@openstack.org> <64a34fd9-d31b-5d7d-ae94-053d9bdebbad@openstack.org> <20181218054413.GG6373@thor.bakeyournoodle.com> Message-ID: > On Dec 17, 2018, at 9:44 PM, Tony Breeds wrote: > > On Thu, Dec 13, 2018 at 09:43:37AM -0800, Chris Hoge wrote: >> There is a need for us to work out whether Loci is even appropriate for >> stable branch development. Over the last week or so the CentOS libvirt >> update has broken all stable branch builds as it introduced an >> incompatibility between the stable upper contraints of python-libvirt and >> libvirt. > > Yup, as we've seen on https://review.openstack.org/#/c/622262 this is a > common thing and happens with every CentOS minor release. We're working > the update to make sure we don't cause more breakage as we try to fix > this thing. > >> libvirt. If we start running stable builds, it might provide a useful >> gate signal for when stable source builds break against upstream >> distributions. It's something for the Loci team to think about as we >> work through refactoring our gate jobs. > > That's interesting idea. Happy to discuss how we can do that in a way > that makes sense for each project. How long does LOCI build take? Loci makes one build for each OpenStack project you want to deploy. The requirements container takes the most time, as it does a pip wheel of every requirement listed in the openstack/requirements repository, then bind-mounts the complete set of wheels into the service containers during those builds to ensure a complete and consistent set of dependencies. Requirements must be done serially, but the rest of the builds can be done in parallel. What I'm thinking is if we do stable builds of Loci that stand up a simplified all-in-one environment we can run Tempest against, we would both get a signal for the Loci stable build (as well as master) and a signal for requirements. Co-gating means we can check that an update to requirements to fix one distrubution does not negatively impact the stability of other distributions. I have some very initial work on this in a personal project (this is how I like to spend some of my holiday down time), and we can bring it up as an agenda item for the Loci meeting tomorrow morning. -Chris From mriedemos at gmail.com Thu Dec 20 18:14:53 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 20 Dec 2018 12:14:53 -0600 Subject: [nova] review guide for the bandwidth patches In-Reply-To: References: <1545231821.28650.2@smtp.office365.com> <1545316423.10879.3@smtp.office365.com> Message-ID: On 12/20/2018 8:47 AM, Jay Pipes wrote: > > The problem with feature flags is they are not discoverable. As much as > I hate API extensions, at least they are discoverable. 100% agree. Config-driven API behavior like this flies in the face of any kind of hope for interoperability of this feature. Can I do this on cloud X? Maybe? Can I do it on cloud Y? Let's find out! At the very least, I would think if you're going to add a config option to enable/disable this support in the compute API, at least temporarily, you would fail any requests which include ports with QoS resource requests because we're not going to honor them. That aligns more with what I was saying about how I thought the "reject" patches would come earlier in the series since we're currently not supporting this feature, and lying to users by allowing them to attach these kinds of ports. Although I might be conflating QoS ports in general and QoS ports that have the bandwidth resource request things on them. During the spec review, we waffled a bit on whether or not this should have a new microversion with it [1][2]. The way this works definitely sounds like how volume multiattach is setup - you create a resource in another service with a special characteristic and then try to attach that thing to a server. Nova can either support that thing or not, and the only way for a user to find that out without a microversion is to try it and find out (does it fail? if it doesn't fail, is the thing working in my guest? if not, is it because it's not supported or because something failed or there is a bug?). With volume multiattach we added a microversion so that users could know if they can even make the request to attach those types of volumes so they didn't have to guess. So I could argue that QoS ports like this should get similar treatment, but things get fuzzy when it's implicit behavior on some external resource > > Is there a reason why we can't just put code into Nova that, upon seeing > the resource requests, acts on it? Is there a reason it needs to be > behind a feature flag or even needs to query Neutron for extension > support? I mean, if it's in the response payload, just use it, right? The main reason is how the code is written backward, as I've said elsewhere in this thread. If everything was properly plumbed in from the bottom up for at least creating servers with these kinds of ports (and cleaning them up properly), then it's just a matter of doing like you said - take action on the thing if it's there. Like [3] I think we could explicitly fail for things that are not supported until they do become supported, like any move operations. Whether those are considered bug fixes or new features (a la microversions) is debatable. It sucks adding stuff that works when creating a server but isn't supported when you perform actions on that server, and it sucks holding up features before everything is ready, and it sucks to need microversions for every little thing that ideally would have just be done up front, so I can't really say here on what we should do. I know in the golden days before microversions it was totally kosher to just feature flag our way to nirvana and we're still dealing with a lot of that fallout (like the fact that live migration with NUMA-affined instances still doesn't work properly). [1] https://review.openstack.org/#/c/502306/17/specs/rocky/approved/bandwidth-resource-provider.rst at 142 [2] https://review.openstack.org/#/c/502306/26/specs/rocky/approved/bandwidth-resource-provider.rst at 99 [3] https://review.openstack.org/#/c/611088/ -- Thanks, Matt From miguel at mlavalle.com Thu Dec 20 18:48:25 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Thu, 20 Dec 2018 12:48:25 -0600 Subject: [openstack-dev] [neutron] [neutron-interconnection] neutron-interconnection core reviewers Message-ID: Hi Neutrinos, During the Dublin PTG we discussed and approved a neutron-interconnection proposal. Over the past few months the spec was merged ( https://specs.openstack.org/openstack/neutron-specs/specs/rocky/neutron-inter.html) and the corresponding repo was also approved and created: https://review.openstack.org/#/c/599428/ and https://review.openstack.org/#/c/599429/. Earlier today the core team of reviewers was created. This team includes the current Neutron core plus Thomas Morin and Yannick Thomas. So let's start pushing and reviewing code Best regards Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Thu Dec 20 18:59:04 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 20 Dec 2018 13:59:04 -0500 Subject: [tc] Technical Committee Status for 17 Dec 2081 In-Reply-To: References: Message-ID: Lance Bragstad writes: > On Mon, Dec 17, 2018 at 12:18 PM Doug Hellmann > wrote: > >> == TC Meetings == >> >> The next TC meeting will be 3 December @ 1400 UTC in #openstack-tc. See >> http://eavesdrop.openstack.org/#Technical_Committee_Meeting for details >> > > This will be on 3 January, right? Yes, sorry. 3 January 1400 UTC in #openstack-tc. -- Doug From ildiko.vancsa at gmail.com Thu Dec 20 19:07:37 2018 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Thu, 20 Dec 2018 20:07:37 +0100 Subject: Use cases mapping to MVP architectures - FEEDBACK NEEDED Message-ID: Hi, Hereby I would like to forward you the mapping of use cases to MVP architectures that Gergely Csatari is working on. Please provide feedback on this work item to make sure we are considering all the aspects. Thanks and Best Regards, Gergely and Ildikó In the Edge Coputing Group we are collecting use cases for the edge cloud infrastructure. They are recorded in our wiki [1] and they describe high level scenarios when an edge cloud infrastructure would be needed. During the second Denver PTG discussions we drafted two MVP architectures what we could build from the current functionality of OpenStack with some slight modifications [2]. These are based on the work of James and his team from Oath. We differentiate between a distributed [3] and a centralized [4] control plane architecture scenarios. In one of the Berlin Forum sessions we were asked to map the MVP architecture scenarios to the use cases so I made an initial mapping and now I’m looking for feedback. This mapping only means, that the listed use case can be implemented using the MVP architecture scenarios. It should be noted, that none of the MVP architecture scenarios provide solution for edge cloud infrastructure upgrade or centralized management. Here I list the use cases and the mapped architecture scenarios: Mobile service provider 5G/4G virtual RAN deployment and Edge Cloud B2B2X [5] Both distributed [3] and centralized [4] Universal customer premise equipment (uCPE) for Enterprise Network Services[6] Both distributed [3] and centralized [4] Unmanned Aircraft Systems (Drones) [7] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Cloud Storage Gateway - Storage at the Edge [8] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Open Caching - stream/store data at the edge [9] Both distributed [3] and centralized [4] Smart City as Software-Defined closed-loop system [10] The use case is not complete enough to figure out Augmented Reality -- Sony Gaming Network [11] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Analytics/control at the edge [12] The use case is not complete enough to figure out Manage retail chains - chick-fil-a [13] The use case is not complete enough to figure out At this moment chick-fil-a uses a different Kubernetes cluster in every edge location and they manage them using Git [14] Smart Home [15] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Data Collection - Smart cooler/cold chain tracking [16] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event VPN Gateway Service Delivery [17] The use case is not complete enough to figure out [1]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases [2]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures [3]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Distributed_Control_Plane_Scenario [4]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Centralized_Control_Plane_Scenario [5]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Mobile_service_provider_5G.2F4G_virtual_RAN_deployment_and_Edge_Cloud_B2B2X. [6]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Universal_customer_premise_equipment_.28uCPE.29_for_Enterprise_Network_Services [7]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Unmanned_Aircraft_Systems_.28Drones.29 [8]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Cloud_Storage_Gateway_-_Storage_at_the_Edge [9]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Open_Caching_-_stream.2Fstore_data_at_the_edge [10]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_City_as_Software-Defined_closed-loop_system [11]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Augmented_Reality_--_Sony_Gaming_Network [12]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Analytics.2Fcontrol_at_the_edge [13]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Manage_retail_chains_-_chick-fil-a [14]: https://schd.ws/hosted_files/kccna18/34/GitOps.pdf [15]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_Home [16]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Data_Collection_-_Smart_cooler.2Fcold_chain_tracking [17]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#VPN_Gateway_Service_Delivery _______________________________________________ Edge-computing mailing list Edge-computing at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing From mriedemos at gmail.com Thu Dec 20 19:07:45 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 20 Dec 2018 13:07:45 -0600 Subject: [nova] Granular locks in the API Message-ID: I wanted to float something that we talked about in the public cloud SIG meeting today [1] which is the concept of making the lock API more granular to lock on a list of actions rather than globally locking all actions that can be performed on a server. The primary use case we discussed was around a pre-paid pricing model for servers. A user can pre-pay resources at a discount if let's say they are going to use them for a month at a fixed rate. However, once they do, they can't resize those servers without going through some kind of approval (billing) process to resize up. With this, the provider could lock the user from performing the resize action on the server but the user could do other things like stop/start/reboot/snapshot/etc. The pricing model sounds similar to pre-emptible instances for getting a discount but the scenario is different in that these servers couldn't be pre-empted (they are definitely more non-cloudy pets than cattle). An alternative solution for that locked resize issue is using granular policy rules such that pre-paid servers have some other kind of role attached to them so by policy you could restrict users from performing actions on those servers (but the admin could override). In reality I'm not sure how feasible that is in a public cloud with several thousand projects. The issue I see with policy controlling this is the role is attached to the project, not the resource (the server), so if you did this would users have to have separate projects for on-demand vs pre-paid resources? I believe that's what CERN and StackHPC are doing with pre-emptible instances (you have different projects with different quota models for pre-emptible resources). I believe there are probably other use cases for granular locks on servers for things like service VMs (trove creates some service VMs to run a database cluster and puts locks on those servers). Again, definitely a pet scenario but it's one I've heard before. Would people be generally in favor of this or opposed, or just meh? [1] https://etherpad.openstack.org/p/publiccloud-wg -- Thanks, Matt From ildiko.vancsa at gmail.com Thu Dec 20 19:11:07 2018 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Thu, 20 Dec 2018 20:11:07 +0100 Subject: [edge][all] Use cases mapping to MVP architectures - FEEDBACK NEEDED In-Reply-To: References: Message-ID: <75A2AB7C-0E2C-4489-A197-705BB9FC361A@gmail.com> And now with tags in the subject. :) Thanks, Ildikó > > Hi, > > Hereby I would like to forward you the mapping of use cases to MVP architectures that Gergely Csatari is working on. > > Please provide feedback on this work item to make sure we are considering all the aspects. > > Thanks and Best Regards, > Gergely and Ildikó > > > In the Edge Coputing Group we are collecting use cases for the edge cloud infrastructure. They are recorded in our wiki [1] and they describe high level scenarios when an edge cloud infrastructure would be needed. > > During the second Denver PTG discussions we drafted two MVP architectures what we could build from the current functionality of OpenStack with some slight modifications [2]. These are based on the work of James and his team from Oath. We differentiate between a distributed [3] and a centralized [4] control plane architecture scenarios. > > In one of the Berlin Forum sessions we were asked to map the MVP architecture scenarios to the use cases so I made an initial mapping and now I’m looking for feedback. > > This mapping only means, that the listed use case can be implemented using the MVP architecture scenarios. It should be noted, that none of the MVP architecture scenarios provide solution for edge cloud infrastructure upgrade or centralized management. > > Here I list the use cases and the mapped architecture scenarios: > > Mobile service provider 5G/4G virtual RAN deployment and Edge Cloud B2B2X [5] > Both distributed [3] and centralized [4] > Universal customer premise equipment (uCPE) for Enterprise Network Services[6] > Both distributed [3] and centralized [4] > Unmanned Aircraft Systems (Drones) [7] > None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event > Cloud Storage Gateway - Storage at the Edge [8] > None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event > Open Caching - stream/store data at the edge [9] > Both distributed [3] and centralized [4] > Smart City as Software-Defined closed-loop system [10] > The use case is not complete enough to figure out > Augmented Reality -- Sony Gaming Network [11] > None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event > Analytics/control at the edge [12] > The use case is not complete enough to figure out > Manage retail chains - chick-fil-a [13] > The use case is not complete enough to figure out > At this moment chick-fil-a uses a different Kubernetes cluster in every edge location and they manage them using Git [14] > Smart Home [15] > None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event > Data Collection - Smart cooler/cold chain tracking [16] > None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event > VPN Gateway Service Delivery [17] > The use case is not complete enough to figure out > > [1]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases > [2]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures > [3]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Distributed_Control_Plane_Scenario > [4]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Centralized_Control_Plane_Scenario > [5]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Mobile_service_provider_5G.2F4G_virtual_RAN_deployment_and_Edge_Cloud_B2B2X. > [6]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Universal_customer_premise_equipment_.28uCPE.29_for_Enterprise_Network_Services > [7]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Unmanned_Aircraft_Systems_.28Drones.29 > [8]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Cloud_Storage_Gateway_-_Storage_at_the_Edge > [9]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Open_Caching_-_stream.2Fstore_data_at_the_edge > [10]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_City_as_Software-Defined_closed-loop_system > [11]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Augmented_Reality_--_Sony_Gaming_Network > [12]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Analytics.2Fcontrol_at_the_edge > [13]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Manage_retail_chains_-_chick-fil-a > [14]: https://schd.ws/hosted_files/kccna18/34/GitOps.pdf > [15]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_Home > [16]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Data_Collection_-_Smart_cooler.2Fcold_chain_tracking > [17]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#VPN_Gateway_Service_Delivery > > > > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing From haleyb.dev at gmail.com Thu Dec 20 19:33:42 2018 From: haleyb.dev at gmail.com (Brian Haley) Date: Thu, 20 Dec 2018 14:33:42 -0500 Subject: Devstack - yet more problems on install In-Reply-To: References: <20181219220144.GA28606@sm-workstation> Message-ID: <16d29937-0311-36a3-798d-e0dfbc0ebc70@gmail.com> On 12/20/18 8:16 AM, d.lake at surrey.ac.uk wrote: > Thanks, but yet another different error now. Seems to be this: > > .ml2.drivers.openvswitch.agent.ovs_neutron_agent [-] No datapath_id on bridge br-int Agent terminated!: RuntimeError: No datapath_id on bridge br-int > > Tearing my hair out here. What other customizations have you done in local.conf? I created a 'stack' yesterday (without any extra changes in local.conf) and didn't see the error you describe. This command should print the datapatch information fyi: sudo ovs-appctl dpif/show -Brian > Dec 20 11:34:28 localhost neutron-openvswitch-agent[70126]: ERROR neutron.agent. common.ovs_lib File "/usr/lib/python2.7/site-packages/tenacity/__init__.py", l ine 331, in iter > Dec 20 11:34:28 localhost neutron-openvswitch-agent[70126]: ERROR neutron.agent. common.ovs_lib raise retry_exc.reraise() > Dec 20 11:34:28 localhost neutron-openvswitch-agent[70126]: ERROR neutron.agent. common.ovs_lib File "/usr/lib/python2.7/site-packages/tenacity/__init__.py", l ine 168, in reraise > Dec 20 11:34:28 localhost neutron-openvswitch-agent[70126]: ERROR neutron.agent. common.ovs_lib raise self > Dec 20 11:34:28 localhost neutron-openvswitch-agent[70126]: ERROR neutron.agent. common.ovs_lib RetryError: RetryError[] > Dec 20 11:34:28 localhost neutron-openvswitch-agent[70126]: ERROR neutron.agent. common.ovs_lib > Dec 20 11:34:28 localhost neutron-openvswitch-agent[70126]: ERROR neutron.plugin s.ml2.drivers.openvswitch.agent.ovs_neutron_agent [-] No datapath_id on bridge b r-int Agent terminated!: RuntimeError: No datapath_id on bridge br-int > Dec 20 11:34:28 localhost systemd[1]: devstack at q-agt.service: main process exite d, code=exited, status=1/FAILURE > Dec 20 11:34:28 localhost systemd[1]: Unit devstack at q-agt.service entered failed state. > Dec 20 11:34:28 localhost systemd[1]: devstack at q-agt.service failed. > +functions-common:service_check:1 exit_trap > +./stack.sh:exit_trap:522 local r=3 > ++./stack.sh:exit_trap:523 jobs -p > +./stack.sh:exit_trap:523 jobs= > +./stack.sh:exit_trap:526 [[ -n '' ]] > +./stack.sh:exit_trap:532 '[' -f /tmp/tmp.YgbuTdLJS4 ']' > +./stack.sh:exit_trap:533 rm /tmp/tmp.YgbuTdLJS4 > +./stack.sh:exit_trap:537 kill_spinner > +./stack.sh:kill_spinner:432 '[' '!' -z '' ']' > +./stack.sh:exit_trap:539 [[ 3 -ne 0 ]] > +./stack.sh:exit_trap:540 echo 'Error on exit' > Error on exit > +./stack.sh:exit_trap:542 type -p generate-subunit > +./stack.sh:exit_trap:543 generate-subunit 1545304664 1078 fail > +./stack.sh:exit_trap:545 [[ -z /opt/stack/logs/screen ]] > +./stack.sh:exit_trap:548 /home/stack/devstack/tools/worlddump. > > -----Original Message----- > From: Sean McGinnis > Sent: 19 December 2018 22:02 > To: Lake, David (PG/R - Elec Electronic Eng) > Cc: openstack at lists.openstack.org; openstack-dev at lists.openstack.org > Subject: Re: Devstack - yet more problems on install > >> But now falling over with another one >> >> ERROR oslo_db.sqlalchemy.exc_filters InternalError: (1071, u'Specified >> key was too long; max key length is 767 bytes') ERROR >> oslo_db.sqlalchemy.exc_filters Error during database migration: >> (pymysql.err.InternalError) (1071, u'Specified key was too long; max >> key length is 767 bytes') [SQL: u'\nALTER TABLE quota_usages CHANGE >> COLUMN resource resource VARCHAR(300)'] (Background on this error at: >> http://sqlalche.me/e/2j85) >> >> Base OS is CentOS 7.5. >> >> I've found this which looks similar - https://review.openstack.org/#/c/626146/ - but I've no idea how to apply it to my Devstack installation. >> > > Yep, you found the right patch. That is a known issue right now and we should hopefully have the fix merged very shortly. > > In the meantime, you could add this to your local.conf: > > CINDER_BRANCH=refs/changes/46/626146/3 > > With that, devstack will pull down that version of the code and you should be able to get by this failure until we merge the fix. As of this moment, there is just a pep8 error that is preventing that from merging. That will not impact the ability to actually run the code. > > Once that merges you can take that line out of the local.conf file to just get the current code from master. > > Hope that helps. > > Sean > > From haleyb.dev at gmail.com Thu Dec 20 19:35:30 2018 From: haleyb.dev at gmail.com (Brian Haley) Date: Thu, 20 Dec 2018 14:35:30 -0500 Subject: [openstack-dev] [Neutron] Propose Ryan Tidwell for neutron-dynamic-routing core In-Reply-To: References: Message-ID: <23bb07f4-104c-137a-3396-f8789da25e58@gmail.com> Big +1 from me. On 12/19/18 1:40 PM, Miguel Lavalle wrote: > Hi Stackers, > > I want to nominate Ryan Tidwell (irc: tidwellr) as a core reviewer for > neutron-dynamic-routing > (https://github.com/openstack/neutron-dynamic-routing). Ryan has a long > history with everything L3 in Neutron. He started contributing code back > in 2014, helping to implement subnet pools > (https://review.openstack.org/#/c/148698/). Over the years he did great > work improving Neutron's IP address manager and was the driving force in > the creation and implementation of the neutron-dynamic-routing project. > After a hiatus of a few cycles, Ryan came back to the community and has > been very active adding support for MP-BGP in neutron-dynamic-routing > and the on boarding of subnets in Neutron. The quality and number of his > code reviews during the Stein cycle are on par with members of the > Neutron core team: http://stackalytics.com/?module=neutron-group. > > I will keep this nomination open as customary. > > Thank you. > > Miguel From lbragstad at gmail.com Thu Dec 20 19:45:14 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Thu, 20 Dec 2018 13:45:14 -0600 Subject: [nova] Granular locks in the API In-Reply-To: References: Message-ID: On Thu, Dec 20, 2018 at 1:09 PM Matt Riedemann wrote: > I wanted to float something that we talked about in the public cloud SIG > meeting today [1] which is the concept of making the lock API more > granular to lock on a list of actions rather than globally locking all > actions that can be performed on a server. > > The primary use case we discussed was around a pre-paid pricing model > for servers. A user can pre-pay resources at a discount if let's say > they are going to use them for a month at a fixed rate. However, once > they do, they can't resize those servers without going through some kind > of approval (billing) process to resize up. With this, the provider > could lock the user from performing the resize action on the server but > the user could do other things like stop/start/reboot/snapshot/etc. > > The pricing model sounds similar to pre-emptible instances for getting a > discount but the scenario is different in that these servers couldn't be > pre-empted (they are definitely more non-cloudy pets than cattle). > > An alternative solution for that locked resize issue is using granular > policy rules such that pre-paid servers have some other kind of role > attached to them so by policy you could restrict users from performing > actions on those servers (but the admin could override). In reality I'm > not sure how feasible that is in a public cloud with several thousand > projects. The issue I see with policy controlling this is the role is > attached to the project, not the resource (the server), so if you did > this would users have to have separate projects for on-demand vs > pre-paid resources? I believe that's what CERN and StackHPC are doing > with pre-emptible instances (you have different projects with different > quota models for pre-emptible resources). > One way you might be able to do this is by shoveling off the policy check using oslo.policy's http_check functionality [0]. But, it still doesn't fix the problem that users have roles on projects, and that's the standard for relaying information from keystone to services today. Hypothetically, the external policy system *could* be an API that allows operators to associate users to different policies that are more granular than what OpenStack offers today (I could POST to this policy system that a specific user can do everything but resize up this *specific* instance). When nova parses a policy check, it hands control to oslo.policy, which shuffles it off to this external system for enforcement. This external policy system evaluates the policies based on what information nova passes it, which would require the policy check string, context of the request like the user, and the resource they are trying operate on (the instance in this case). The external policy system could query it's own policy database for any policies matching that data, run the decisions, and return the enforcement decision per the oslo.limit API. Conversely, you'll have a performance hit since the policy decision and policy enforcement points are no longer oslo.policy *within* nova, but some external system being called by oslo.policy... Might not be the best idea, but food for thought based on the architecture we have today. [0] https://docs.openstack.org/oslo.policy/latest/user/plugins.html > > I believe there are probably other use cases for granular locks on > servers for things like service VMs (trove creates some service VMs to > run a database cluster and puts locks on those servers). Again, > definitely a pet scenario but it's one I've heard before. > > Would people be generally in favor of this or opposed, or just meh? > > [1] https://etherpad.openstack.org/p/publiccloud-wg > > -- > > Thanks, > > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hongbin.lu at huawei.com Thu Dec 20 19:51:13 2018 From: hongbin.lu at huawei.com (Hongbin Lu) Date: Thu, 20 Dec 2018 19:51:13 +0000 Subject: [openstack-dev] [Neutron] Propose Ryan Tidwell for neutron-dynamic-routing core In-Reply-To: References: Message-ID: <0957CD8F4B55C0418161614FEC580D6B308B17F0@yyzeml704-chm.china.huawei.com> +1 From: Miguel Lavalle [mailto:miguel at mlavalle.com] Sent: December-19-18 1:40 PM To: openstack-discuss at lists.openstack.org Subject: [openstack-dev] [Neutron] Propose Ryan Tidwell for neutron-dynamic-routing core Hi Stackers, I want to nominate Ryan Tidwell (irc: tidwellr) as a core reviewer for neutron-dynamic-routing (https://github.com/openstack/neutron-dynamic-routing). Ryan has a long history with everything L3 in Neutron. He started contributing code back in 2014, helping to implement subnet pools (https://review.openstack.org/#/c/148698/). Over the years he did great work improving Neutron's IP address manager and was the driving force in the creation and implementation of the neutron-dynamic-routing project. After a hiatus of a few cycles, Ryan came back to the community and has been very active adding support for MP-BGP in neutron-dynamic-routing and the on boarding of subnets in Neutron. The quality and number of his code reviews during the Stein cycle are on par with members of the Neutron core team: http://stackalytics.com/?module=neutron-group. I will keep this nomination open as customary. Thank you. Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mcginnis at gmx.com Thu Dec 20 20:07:52 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Thu, 20 Dec 2018 14:07:52 -0600 Subject: [release] Release countdown for week R-15, Dec 24-28 Message-ID: <20181220200752.GA5345@sm-workstation> Development Focus ----------------- There are a few project-specific deadlines coming up for milestone 2. Development should be focused on meeting any of those deadlines and preparing for the library releases that will be proposed at the milestone. General Information ------------------- This cycle we have stopped required milestone releases, and that has introduced a side-effect that means we need to take other steps to ensure that downstream packagers testing upgrades from Rocky to Stein do not have issues with the version numbers calculated by PBR on the master branch.More details can be found in the mailing list post here: http://lists.openstack.org/pipermail/openstack-dev/2018-October/135706.html The release team has generated empty commits to cause PBR to increment its calculated version as a fix for the situation, and we have a few of those patches open still. Please merge them as soon as possible to support the people who are testing upgrades. https://review.openstack.org/#/q/status:open+branch:master+topic:sem-ver Upcoming Deadlines & Dates -------------------------- Stein-2 Milestone: January 10 -- Sean McGinnis (smcginnis) From nate.johnston at redhat.com Thu Dec 20 20:28:08 2018 From: nate.johnston at redhat.com (Nate Johnston) Date: Thu, 20 Dec 2018 15:28:08 -0500 Subject: [openstack-dev] [Neutron] Propose Ryan Tidwell for neutron-dynamic-routing core In-Reply-To: References: Message-ID: Big +1 here too! Nate Sent from my iPhone > On Dec 19, 2018, at 1:40 PM, Miguel Lavalle wrote: > > Hi Stackers, > > I want to nominate Ryan Tidwell (irc: tidwellr) as a core reviewer for neutron-dynamic-routing (https://github.com/openstack/neutron-dynamic-routing). Ryan has a long history with everything L3 in Neutron. He started contributing code back in 2014, helping to implement subnet pools (https://review.openstack.org/#/c/148698/). Over the years he did great work improving Neutron's IP address manager and was the driving force in the creation and implementation of the neutron-dynamic-routing project. After a hiatus of a few cycles, Ryan came back to the community and has been very active adding support for MP-BGP in neutron-dynamic-routing and the on boarding of subnets in Neutron. The quality and number of his code reviews during the Stein cycle are on par with members of the Neutron core team: http://stackalytics.com/?module=neutron-group. > > I will keep this nomination open as customary. > > Thank you. > > Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfolco at redhat.com Thu Dec 20 21:11:05 2018 From: rfolco at redhat.com (Rafael Folco) Date: Thu, 20 Dec 2018 19:11:05 -0200 Subject: [openstack-dev][tripleo] TripleO CI Summary: Sprint 23 Message-ID: Greetings, The TripleO CI team has just completed Sprint 23 (Nov 28 thru Dec 19). The following is a summary of completed work during this sprint cycle: - Completed adding standalone scenarios(1-4) jobs and disabled equivalent multinode jobs on master to save upstream resources. We will now start adding the standalone scenario jobs to tripleo projects - Improved python3 support and fixed Tempest packaging on Fedora 28 job. This is part of python3 and RHEL8 validation in upstream CI. The Fedora 28 standalone job has flapped from passing to failed, currently failing on bug [3]. - After the review of the team, we have decided to use upstream zuul containers to facilitate the tripleo job recreation [4] The team is continuing to evaluate software factory rpms as the base for this work. Instructions are posted internally atm. - Tested a new CI environment for OVB jobs on RDO cloud, aka “OVB 2.0”. Experiments include ovb deployment without the te-broker. The te-broker is now offline!!! - Tempest update can be found here [5]. The planned work for the next sprint are: - Continue to fix Fedora 28 standalone job and add Fedora 28 jobs to the promotion pipeline. - Add Standalone scenarios[1-4] jobs across TripleO repos for Stein - Follow the docs and test the new “Container Zuulv3” reproducer. - Continue to work on the OVB improvements The sprint board is tracked on Taiga [1]. The Ruck and Rover for this sprint are Ronnele Landy (rlandy) and Wes Hayutin (weshay). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. The Ruck and Rover notes for this sprint are tracked on etherpad [2]. Thanks, Folco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-3 [2] https://review.rdoproject.org/etherpad/p/ruckrover-sprint24 [3] https://bugs.launchpad.net/tripleo/+bug/1808118 [4] https://docs.openstack.org/tripleo-docs/latest/contributor/reproduce-ci.html [5] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001116.html -- Rafael Folco Senior Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Thu Dec 20 21:20:56 2018 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Thu, 20 Dec 2018 16:20:56 -0500 Subject: [cinder][ops][docs][keystone] policy configuration howto In-Reply-To: References: <8a1749f7-ed18-971a-82c8-ae7e639cfe91@nemebean.com> Message-ID: Update: I've revised the patch documenting how to configure Cinder policies to enable a read-only administrator [0] to take into account the ongoing Keystone work that Lance discussed earlier in this thread. At this point in the development cycle, I think it makes the most sense to continue with the plan to "fix" this via documentation, especially since the workaround documented immediately applies to the stable branches. The work Yikun Jiang is doing now to get "protection" tests into Cinder [1] will give us a base to work from if we decide to refactor the code to make this easier (or to implement default policies that recognize a 'reader' role out of the box, as Keystone is doing this cycle). In any case, reviews of [0] will be appreciated, especially during this festive holiday season. cheers, brian [0] https://review.openstack.org/#/c/624424/ [1] https://review.openstack.org/#/q/status:open+project:openstack/cinder+branch:master+topic:policy_in_code_test On 12/13/18 12:58 PM, Lance Bragstad wrote: > Thanks for looping keystone into this, Ben. > > This sounds very similar, and related, to the default roles work > keystone implemented in Rocky [0]. TL;DR, keystone ensures the > ``member`` and ``reader`` roles are available during ``keystone-manage > bootstrap``, which is typically done during installation and sometimes > on upgrade. Pre-Rocky, only the ``admin`` role existed in keystone. > > The idea is to make it easier for other services, like cinder, to rely > on these roles by default. As opposed to cinder changing a policy > default to something like ``role:reader`` and another service using > something like ``role:auditor``, but they both mean the same thing. We > want to avoid the case where operators would need to make sure both > roles exist in keystone and users have both if they're expected to > perform read-only operations from each service. > > The work keystone did in Rocky made it possible for cinder to start > making those assumptions about the existence of roles called ``member`` > and ``reader``. > > As far as testing goes, I remember there being a cinder session in > Denver about policy changes, regression, and making sure we can protect > against it happening, especially late in the release. Ideally, it would > be fantastic to have protection tests in each service that assert the > default policies work as expected for protecting APIs. Unfortunately, > testing this in its entirety makes it an integration test that requires > keystone. Luckily, there are some ways for services to expand protection > testing without having that dependency, which falls within the > parameters of unit tests. I proposed a couple of changes to cinder that > show how to do this [1], and it requires modeling an API request similar > to what keystonemiddleware/oslo.context do and ensuring the actual > defaults are tested by removing overridden test policies [2] that leave > APIs unprotected. We attempted to document a generalized approach to > this sort of testing in oslo.policy [3]. > > [0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html > [1] https://review.openstack.org/#/c/602489/ > [2] https://review.openstack.org/#/c/609498/ > [3] https://docs.openstack.org/oslo.policy/latest/user/usage.html#testing-default-policies > > On Thu, Dec 13, 2018 at 8:10 AM Ben Nemec > wrote: > > cc Keystone. It would be interesting to know how this fits in with the > new default roles work. > > On 12/12/18 8:21 PM, Brian Rosmaita wrote: > > At last week's cinder meeting (5 December) we had a discussion about > > policy checks at the database layer.  While these checks seem to > make it > > difficult to perform some policy configurations, there are too many of > > them to simply remove them without impacting stability given our > current > > test coverage (at least that's my feeling).  Additionally, it's > possible > > to handle the proposed use case (a read-only administrator) without > > making any code changes.  So we decided to fix this issue by > documenting > > how this could work. > > > > I've got a patch up for the documentation.  I've flagged this > email for > > cinder people to read for accuracy, operators to read to make sure the > > instructions are clear and detailed, and docs people to read for > > felicity of expression.  Please leave comments on the patch: > > > > https://review.openstack.org/#/c/624424/ > > > > cheers, > > brian > > > From mriedemos at gmail.com Thu Dec 20 21:48:24 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 20 Dec 2018 15:48:24 -0600 Subject: [nova] Granular locks in the API In-Reply-To: References: Message-ID: <7e570da6-af7a-1439-9172-e454590d52cf@gmail.com> On 12/20/2018 1:45 PM, Lance Bragstad wrote: > > One way you might be able to do this is by shoveling off the policy > check using oslo.policy's http_check functionality [0]. But, it still > doesn't fix the problem that users have roles on projects, and that's > the standard for relaying information from keystone to services today. > > Hypothetically, the external policy system *could* be an API that allows > operators to associate users to different policies that are more > granular than what OpenStack offers today (I could POST to this policy > system that a specific user can do everything but resize up this > *specific* instance). When nova parses a policy check, it hands control > to oslo.policy, which shuffles it off to this external system for > enforcement. This external policy system evaluates the policies based on > what information nova passes it, which would require the policy check > string, context of the request like the user, and the resource they are > trying operate on (the instance in this case). The external policy > system could query it's own policy database for any policies matching > that data, run the decisions, and return the enforcement decision per > the oslo.limit API. One thing I'm pretty sure of in nova is we do not do a great job of getting the target of the policy check before actually doing the check. In other words, our target is almost always the project/user from the request context, and not the actual resource upon which the action is being performed (the server in most cases). I know John Garbutt had a spec for this before. It always confused me. > > Conversely, you'll have a performance hit since the policy decision and > policy enforcement points are no longer oslo.policy *within* nova, but > some external system being called by oslo.policy... Yeah. The other thing is if I'm just looking at my server, I can see if it's locked or not since it's an attribute of the server resource. With policy I would only know if I can perform a certain action if I get a 403 or not, which is fine in most cases. Being able to see via some list of locked actions per server is arguably more user friendly. This also reminds me of reporting / capabilities APIs we've talked about over the years, e.g. what I can do on this cloud, on this host, or with this specific server? > > Might not be the best idea, but food for thought based on the > architecture we have today. Definitely, thanks for the alternative. This is something one could implement per-provider based on need if we don't have a standard solution. -- Thanks, Matt From mriedemos at gmail.com Thu Dec 20 22:33:36 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 20 Dec 2018 16:33:36 -0600 Subject: Failed live migration and duplicate attachments In-Reply-To: References: Message-ID: <8e4dafe9-04e3-2668-2078-34c8d5c1fcf8@gmail.com> On 12/20/2018 8:35 AM, Torin Woltjer wrote: > How would you recommend addressing the duplicate attachments? There > doesn't seem to be any adverse effect of them being there, but I cannot > detach them because they are root volumes. These are records in the cinder "volume_attachment" table correct? If so, there should be volume attachment records for both the source host and the destination host for the live migration. There should be a "connector" json blob in them and the ones to remove would be the ones that have the destination host information (should at least have the host IP). Since the live migration failed, you should only care about the volume attachments for the source host. Before deleting anything, cross-check that the block_device_mappings.attachment_id in the nova (cell) database matches the source host volume attachments in the cinder DB. nova-compute should have made sure those BDM records were rolled back properly here: https://github.com/openstack/nova/blob/a1c01f97ae0397e8f4ccff5eb2a8b8f5ef7f7221/nova/compute/manager.py#L6843 but you should double check. Actually, looking at that code, they are likely still pointing at the destination volume attachments since we try to delete the attachments before updating the block_device_mappings table entries (we should probably reverse that order in the code). When it comes to actually deleting those destination host volume attachment records, I would use the cinder API: https://developer.openstack.org/api-ref/block-storage/v3/#delete-attachment Just to make sure something doesn't get screwed up if you try and do manual database surgery (as noted, you might need to manually update the block_device_mappings.attachment_id values in the nova DB to point at the source host volume attachments for that instance). -- Thanks, Matt From saphi070 at gmail.com Thu Dec 20 22:36:09 2018 From: saphi070 at gmail.com (Sa Pham) Date: Fri, 21 Dec 2018 05:36:09 +0700 Subject: [Cinder][horizon] Image Name of all Instances does not show up In-Reply-To: References: <2e3102a47ebb73a5522a90ea154d11dc1d87e2c5.camel@redhat.com> Message-ID: Currently, Horizon does not have this patch. You can raise a blueprint to implement it. Sa Pham Dang Cloud RnD Team - VCCLOUD Phone: 0986849582 Skype: great_bn > On Dec 20, 2018, at 11:35 PM, Minjun Hong wrote: > >> On Fri, Dec 21, 2018 at 1:08 AM Sean Mooney wrote: > >> On Fri, 2018-12-21 at 00:48 +0900, Minjun Hong wrote: >> > Hi. >> > After I installed Cinder, 'Image Name' of the created instances does not show up on horizon. >> > When I created instances without Cinder, 'Image Name' of all instances was filled with the name of image which is used >> > for creating the instance on horizon, like this link (https://imgur.com/0Habda7). >> > >> > Actually, although this does not cause any critical incorrect operation, it can make the users who use the Openstack >> > system confused what image is used for the instances. >> > That's why I need to resolve this issue. >> > >> > How can I fill 'Image Name' column with the name of the image ? >> this happens when using a boot from volume instance. >> the image name is stored in the instance root vlomue metadata >> horizon obvirously is not reading it from that location. >> since the vm was not actully booted form an image it does not have one >> associated with the instance iteslf. To correct this the horizon interface will >> likely need to be modified to determin the root volume and retrinve the image from there. >> i have added horizon to the subject as this is not really a cinder issue. >> this is more of less expected behavior based on the internal of how this works. >> >> you did not mention what realase of openstack you are using so its also posible >> this has been resoved in later releases. >> > Thanks! Regards, >> > > Thanks for your kind reply, Sean. > I'm currently using Queens and I want to know where the patch is. > If you don't mind, could you give me the link? > > Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbragstad at gmail.com Thu Dec 20 22:43:14 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Thu, 20 Dec 2018 16:43:14 -0600 Subject: [cinder][ops][docs][keystone] policy configuration howto In-Reply-To: References: <8a1749f7-ed18-971a-82c8-ae7e639cfe91@nemebean.com> Message-ID: On Thu, Dec 20, 2018 at 3:23 PM Brian Rosmaita wrote: > Update: I've revised the patch documenting how to configure Cinder > policies to enable a read-only administrator [0] to take into account > the ongoing Keystone work that Lance discussed earlier in this thread. > > At this point in the development cycle, I think it makes the most sense > to continue with the plan to "fix" this via documentation, especially > since the workaround documented immediately applies to the stable branches. > > The work Yikun Jiang is doing now to get "protection" tests into Cinder > [1] will give us a base to work from if we decide to refactor the code > to make this easier (or to implement default policies that recognize a > 'reader' role out of the box, as Keystone is doing this cycle). > > ++ I like this idea, too. Increasing test coverage of what cinder's policy supports today will make it easier to improve things later. For example, adding formal read-only support by changing the default policies, or even refactoring the contextual admin checks out of the cinder database layer and into a formal validation layer closer to the API. Thanks for the summary, Brian! > In any case, reviews of [0] will be appreciated, especially during this > festive holiday season. > > cheers, > brian > > [0] https://review.openstack.org/#/c/624424/ > [1] > > https://review.openstack.org/#/q/status:open+project:openstack/cinder+branch:master+topic:policy_in_code_test > > > On 12/13/18 12:58 PM, Lance Bragstad wrote: > > Thanks for looping keystone into this, Ben. > > > > This sounds very similar, and related, to the default roles work > > keystone implemented in Rocky [0]. TL;DR, keystone ensures the > > ``member`` and ``reader`` roles are available during ``keystone-manage > > bootstrap``, which is typically done during installation and sometimes > > on upgrade. Pre-Rocky, only the ``admin`` role existed in keystone. > > > > The idea is to make it easier for other services, like cinder, to rely > > on these roles by default. As opposed to cinder changing a policy > > default to something like ``role:reader`` and another service using > > something like ``role:auditor``, but they both mean the same thing. We > > want to avoid the case where operators would need to make sure both > > roles exist in keystone and users have both if they're expected to > > perform read-only operations from each service. > > > > The work keystone did in Rocky made it possible for cinder to start > > making those assumptions about the existence of roles called ``member`` > > and ``reader``. > > > > As far as testing goes, I remember there being a cinder session in > > Denver about policy changes, regression, and making sure we can protect > > against it happening, especially late in the release. Ideally, it would > > be fantastic to have protection tests in each service that assert the > > default policies work as expected for protecting APIs. Unfortunately, > > testing this in its entirety makes it an integration test that requires > > keystone. Luckily, there are some ways for services to expand protection > > testing without having that dependency, which falls within the > > parameters of unit tests. I proposed a couple of changes to cinder that > > show how to do this [1], and it requires modeling an API request similar > > to what keystonemiddleware/oslo.context do and ensuring the actual > > defaults are tested by removing overridden test policies [2] that leave > > APIs unprotected. We attempted to document a generalized approach to > > this sort of testing in oslo.policy [3]. > > > > [0] > http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html > > [1] https://review.openstack.org/#/c/602489/ > > [2] https://review.openstack.org/#/c/609498/ > > [3] > https://docs.openstack.org/oslo.policy/latest/user/usage.html#testing-default-policies > > > > On Thu, Dec 13, 2018 at 8:10 AM Ben Nemec > > wrote: > > > > cc Keystone. It would be interesting to know how this fits in with > the > > new default roles work. > > > > On 12/12/18 8:21 PM, Brian Rosmaita wrote: > > > At last week's cinder meeting (5 December) we had a discussion > about > > > policy checks at the database layer. While these checks seem to > > make it > > > difficult to perform some policy configurations, there are too > many of > > > them to simply remove them without impacting stability given our > > current > > > test coverage (at least that's my feeling). Additionally, it's > > possible > > > to handle the proposed use case (a read-only administrator) without > > > making any code changes. So we decided to fix this issue by > > documenting > > > how this could work. > > > > > > I've got a patch up for the documentation. I've flagged this > > email for > > > cinder people to read for accuracy, operators to read to make sure > the > > > instructions are clear and detailed, and docs people to read for > > > felicity of expression. Please leave comments on the patch: > > > > > > https://review.openstack.org/#/c/624424/ > > > > > > cheers, > > > brian > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbragstad at gmail.com Thu Dec 20 22:58:58 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Thu, 20 Dec 2018 16:58:58 -0600 Subject: [nova] Granular locks in the API In-Reply-To: <7e570da6-af7a-1439-9172-e454590d52cf@gmail.com> References: <7e570da6-af7a-1439-9172-e454590d52cf@gmail.com> Message-ID: On Thu, Dec 20, 2018 at 3:50 PM Matt Riedemann wrote: > On 12/20/2018 1:45 PM, Lance Bragstad wrote: > > > > One way you might be able to do this is by shoveling off the policy > > check using oslo.policy's http_check functionality [0]. But, it still > > doesn't fix the problem that users have roles on projects, and that's > > the standard for relaying information from keystone to services today. > > > > Hypothetically, the external policy system *could* be an API that allows > > operators to associate users to different policies that are more > > granular than what OpenStack offers today (I could POST to this policy > > system that a specific user can do everything but resize up this > > *specific* instance). When nova parses a policy check, it hands control > > to oslo.policy, which shuffles it off to this external system for > > enforcement. This external policy system evaluates the policies based on > > what information nova passes it, which would require the policy check > > string, context of the request like the user, and the resource they are > > trying operate on (the instance in this case). The external policy > > system could query it's own policy database for any policies matching > > that data, run the decisions, and return the enforcement decision per > > the oslo.limit API. > > One thing I'm pretty sure of in nova is we do not do a great job of > getting the target of the policy check before actually doing the check. > In other words, our target is almost always the project/user from the > request context, and not the actual resource upon which the action is > being performed (the server in most cases). I know John Garbutt had a > spec for this before. It always confused me. > I doubt nova is alone in this position. I would bet there are a lot of cases across OpenStack where we could be more consistent in how this information is handed to oslo.policy. We attempted to solve this for the other half of the equation, which is the `creds` dictionary. Turns out a lot of what was in this arbitrary `creds` dict, was actually just information from the request context object. The oslo.policy library now supports context objects directly [0], as opposed to hoping services build the dictionary properly. Target information will be a bit harder to do because it's different across services and even APIs within the same service. But yeah, I totally sympathize with the complexity it puts on developers. [0] https://review.openstack.org/#/c/578995/ > > > > > Conversely, you'll have a performance hit since the policy decision and > > policy enforcement points are no longer oslo.policy *within* nova, but > > some external system being called by oslo.policy... > > Yeah. The other thing is if I'm just looking at my server, I can see if > it's locked or not since it's an attribute of the server resource. With > policy I would only know if I can perform a certain action if I get a > 403 or not, which is fine in most cases. Being able to see via some list > of locked actions per server is arguably more user friendly. This also > reminds me of reporting / capabilities APIs we've talked about over the > years, e.g. what I can do on this cloud, on this host, or with this > specific server? > Yeah - I wouldn't mind picking that conversation up, maybe in a separate thread. An idea we had with keystone was to run a user's request through all registered policies and return a list of the ones they could access (e.g., take my token and tell me what I can do with it.) There are probably other issues with this, since policy names are mostly operator facing and end users don't really care at the moment. > > > > > Might not be the best idea, but food for thought based on the > > architecture we have today. > > Definitely, thanks for the alternative. This is something one could > implement per-provider based on need if we don't have a standard solution. > Right, I always thought it would be a good fit for people providing super-specific policy checks or have a custom syntax they want to implement. It keeps most of that separate from the services and oslo.policy. So long as we pass target and context information consistently, they essentially have an API they can write policies against. > > -- > > Thanks, > > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yongli.he at intel.com Fri Dec 21 01:13:22 2018 From: yongli.he at intel.com (yonglihe) Date: Fri, 21 Dec 2018 09:13:22 +0800 Subject: [nova] implementation options for nova spec: show-server-numa-topology In-Reply-To: <06c01a05-30a0-6671-0c89-780927da6793@gmail.com> References: <06c01a05-30a0-6671-0c89-780927da6793@gmail.com> Message-ID: <23c8790e-f62d-c742-d726-7c5e63f38f4a@intel.com> On 2018/12/20 下午10:47, Matt Riedemann wrote: > On 12/18/2018 2:20 AM, yonglihe wrote: >> >> Base on IRC's discuss, we may have 3 options about how to deal with >> those blobs: >> >> 1) include those directly in the server response details, like the >> released POC does: >> https://review.openstack.org/#/c/621476/3 > > I would think these are potentially admin-level sensitive details as > well and thus only exposed based on a policy check. A user requests a > certain topology, but I'm not sure how low-level the user needs/should > see what nova is doing for satisfying that topology, especially for > things like pinning CPUs on the host. I thought the main use case for > this spec (and several like these discussed at the PTG) was more about > being able to get information (reporting) out of the REST API for > debugging (by admins and/or support team members), less about user need. > >> >> 2) add a new sub-resource endpoint to servers, most likely use key >> word 'topology' then: >> "GET /servers/{server_id}/topology" returns the NUMA information for >> one server. > > Similar to (1) in that I'd think there would be a new policy check on > this which defaults to admin-only. I think this would be better than > (1) since it wouldnt' be confused with listing servers (GET > /servers/detail). > >> >> 3) put the NUMA info under existing 'diagnostics' API. >> "GET /servers/{server_id}/diagnostics" >> this is admin only API, normal user loss the possible to check their >> topology. > > By default it's an admin-only API, but that is configurable in policy, > so if a given cloud wants to expose this for admin or owner of the > instance, they can do that, or alternatively expose it to support team > members via a special role in keystone. > >> >> when the information put into diagnostics, they will be look like: >> { >>     .... >>     "numa_topology": { >>        cells  [ >>                 { >>                      "numa_node" : 3 >>                      "cpu_pinning": {0:5, 1:6}, >>                      "cpu_thread_policy": "prefer", >>                      "cpuset": [0,1,2,3], >>                      "siblings": [[0,1],[2,3]], >>                      "mem": 1024, >>                      "pagesize": 4096, >>                      "sockets": 0, >>                      "cores": 2, >>                       "threads": 2, >>                   }, >>               ... >>             ] # cells >>      } >>      "emulator_threads_policy": "share" >> >>      "pci_devices": [ >>          { >>                  "address":"00:1a.0", >>                  "type": "VF", >>                  "vendor": "8086", >>                  "product": "1526" >>          }, >>      ] >>   } > > I tend to prefer option (3) since it seems topology is a much more > natural fit with the existing information (low-level CPU/RAM/disk > usage) we expose out of the diagnostics API and is already restricted > to admins by default in policy (but again as noted this can be > configured). > Matt, thanks point this out.  (3)  is more clear and less configuration mess, so (3) winning, spec is gonna be revised. Regards Yongli He From mriedemos at gmail.com Fri Dec 21 01:28:32 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 20 Dec 2018 19:28:32 -0600 Subject: [nova] implementation options for nova spec: show-server-numa-topology In-Reply-To: <23c8790e-f62d-c742-d726-7c5e63f38f4a@intel.com> References: <06c01a05-30a0-6671-0c89-780927da6793@gmail.com> <23c8790e-f62d-c742-d726-7c5e63f38f4a@intel.com> Message-ID: <962173e9-62e4-63f1-6b52-a97350e02d00@gmail.com> On 12/20/2018 7:13 PM, yonglihe wrote: > On 2018/12/20 下午10:47, Matt Riedemann wrote: >> On 12/18/2018 2:20 AM, yonglihe wrote: >>> >>> Base on IRC's discuss, we may have 3 options about how to deal with >>> those blobs: >>> >>> 1) include those directly in the server response details, like the >>> released POC does: >>> https://review.openstack.org/#/c/621476/3 >> >> I would think these are potentially admin-level sensitive details as >> well and thus only exposed based on a policy check. A user requests a >> certain topology, but I'm not sure how low-level the user needs/should >> see what nova is doing for satisfying that topology, especially for >> things like pinning CPUs on the host. I thought the main use case for >> this spec (and several like these discussed at the PTG) was more about >> being able to get information (reporting) out of the REST API for >> debugging (by admins and/or support team members), less about user need. >> >>> >>> 2) add a new sub-resource endpoint to servers, most likely use key >>> word 'topology' then: >>> "GET /servers/{server_id}/topology" returns the NUMA information for >>> one server. >> >> Similar to (1) in that I'd think there would be a new policy check on >> this which defaults to admin-only. I think this would be better than >> (1) since it wouldnt' be confused with listing servers (GET >> /servers/detail). >> >>> >>> 3) put the NUMA info under existing 'diagnostics' API. >>> "GET /servers/{server_id}/diagnostics" >>> this is admin only API, normal user loss the possible to check their >>> topology. >> >> By default it's an admin-only API, but that is configurable in policy, >> so if a given cloud wants to expose this for admin or owner of the >> instance, they can do that, or alternatively expose it to support team >> members via a special role in keystone. >> >>> >>> when the information put into diagnostics, they will be look like: >>> { >>>     .... >>>     "numa_topology": { >>>        cells  [ >>>                 { >>>                      "numa_node" : 3 >>>                      "cpu_pinning": {0:5, 1:6}, >>>                      "cpu_thread_policy": "prefer", >>>                      "cpuset": [0,1,2,3], >>>                      "siblings": [[0,1],[2,3]], >>>                      "mem": 1024, >>>                      "pagesize": 4096, >>>                      "sockets": 0, >>>                      "cores": 2, >>>                       "threads": 2, >>>                   }, >>>               ... >>>             ] # cells >>>      } >>>      "emulator_threads_policy": "share" >>> >>>      "pci_devices": [ >>>          { >>>                  "address":"00:1a.0", >>>                  "type": "VF", >>>                  "vendor": "8086", >>>                  "product": "1526" >>>          }, >>>      ] >>>   } >> >> I tend to prefer option (3) since it seems topology is a much more >> natural fit with the existing information (low-level CPU/RAM/disk >> usage) we expose out of the diagnostics API and is already restricted >> to admins by default in policy (but again as noted this can be >> configured). >> > Matt, thanks point this out.  (3)  is more clear and less configuration > mess, so (3) winning, spec is gonna be revised. I also commented in the spec today. I would also be OK(ish) with option 2. I'm mostly concerned about the performance implications of needing to fetch and process this data, including policy checks, when listing 1000 servers with details. The spec wasn't clear (to me) about where the data comes from exactly (do we join on the compute_nodes table?). I'm also unsure about how much end users need to see the NUMA/PCI information for their server (so is the admin-only policy sufficient for the diagnostics API?). I'd really like input from others here. I mostly just want users to have to opt in to getting this information, not nova needing to produce it in the main server resource response during show/list, so option 2 or 3 are preferable *to me*. I think option 3 is the safest one if we're unsure or deadlocked otherwise, but no one else has really said anything (outside of the spec anyway). -- Thanks, Matt From tony at bakeyournoodle.com Fri Dec 21 05:00:02 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Fri, 21 Dec 2018 16:00:02 +1100 Subject: Backporting networking-ansible to Queens In-Reply-To: <0019d2fb-2925-267d-2478-e642f986ae6b@redhat.com> References: <243084cd-4a9c-e9b3-af5f-07d5fd4f4b35@redhat.com> <0019d2fb-2925-267d-2478-e642f986ae6b@redhat.com> Message-ID: <20181221050002.GA9606@thor.bakeyournoodle.com> On Tue, Dec 18, 2018 at 11:00:39AM -0500, Dan Radez wrote: > python-pexpect is used by a small handful of projects. There a chance that > pyyaml may have to be bumped one minor version as well. These changes seem > to be a fairly low impact for networking-ansible's dependency updates. Why would we bump pyyaml? I don't see that covered in the change. There are 56 consumers of pyyaml in stable/queens, depending on the nature of the bump, many or which would need to take some action. > The community is not being asked to take on any more maintenance or spend > extra time as a result of this backport. The requirements update for the > backport has passed all of its tests. That's not quite accurate. Merging 624048, would mean generating, merging requirements updates to all consumers of pyexpect: Package : pexpect [pexpect!=3.3,>=3.1] (used by 3 projects) Also affects : 3 projects openstack/rpm-packaging [None] openstack/storlets [None] openstack/trove [None] Which would then force immediate releases of storlets and trove (minor updates) which then means all vendors and operators using those services need to re-generate packages and environments for those services. So the broader developer, vendor and operator community is being asked to do non-zero amounts of work. Now clearly RedHat (our employer) sees value in this work but do SUSE, Canonical, Gentoo and Debian? We could *not* do that work but then those projects would be working by luck rather than design. > While this is an unusual request, our hope is the value for us and for > queens users can be seen. In light of the low risk and the expected zero > additional time/maintenance could an exception be made to approve this > update to happen? At this point I don't see a compelling reason deviate from from the established norm. 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 zhipengh512 at gmail.com Fri Dec 21 06:40:57 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Fri, 21 Dec 2018 14:40:57 +0800 Subject: [edge] Zero Touch Provisioning In-Reply-To: References: <3a1ca5f4-0c3a-ae32-3e0b-b346cf653f65@gmail.com> <59f29ce7-aa3e-7f68-4e53-2623d35cf778@gmail.com> Message-ID: ICYMI: https://blog.ipspace.net/2018/12/zero-touch-provisioning-with-patrick_20.html Shall we collect items of OCP/OpenStack components that could composite a ZTP stack somewhere ? On Thu, Dec 20, 2018 at 10:51 PM Curtis wrote: > On Thu, Dec 20, 2018 at 9:35 AM Jay Pipes wrote: > >> On 12/20/2018 09:33 AM, Curtis wrote: >> > No, it doesn't do inventory management. It's like a small base OS for >> > network switches, they come with it, boot up into it, and you can use >> it >> > to install other OSes. At least that's how it's used with the whitebox >> > switches I have. With ONIE it'd install the OS, then the initial OS >> > could register with some kind of inventory system. >> >> What about for non-network devices -- i.e. general compute hardware? >> After all, edge is more than just the network switches :) >> > > I'm not sure; that's a good question. I was just using it as an example of > a piece of ZTP related technology that has been adopted by vendors who > build physical devices and include them by default, though of course, only > a subset of network switches. :) > > If ONIE was a good example, and it could not be used for general compute > hardware, then perhaps something like it could be built using lessons > learned by ONIE. I dunno. :) > > Thanks, > Curits > > >> >> Best, >> -jay >> > > > -- > Blog: serverascode.com > -- Zhipeng (Howard) Huang Principle Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Fri Dec 21 07:16:31 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 21 Dec 2018 16:16:31 +0900 Subject: [dev][tc] Feedback on adding the 'API Version Based Feature Discovery' in OpenStack Technical Vision Message-ID: <167cf9f6f88.1254a349412500.7364756323995768865@ghanshyammann.com> Hello everyone, As you know, last month we had merged the very well written technical vision doc by Zane[1]. To extend it further, I am proposing a section/item to add about API-Version based feature discovery [1]. Each OpenStack Service should provide a mechanism to know the supported min and max API version in a cloud which further will help to discover the enhanced or new features. Also, a user should be able to query detailed information about features and enhancement per version. Patch 621516 is documenting this API version based discovery idea in vision doc, and I am looking forward for more feedback/opinion on this. [1] https://governance.openstack.org/tc/reference/technical-vision.html [2] https://review.openstack.org/#/c/621516/ -gmann From vedarthambharath at gmail.com Fri Dec 21 07:46:02 2018 From: vedarthambharath at gmail.com (Vedartham Bharath) Date: Fri, 21 Dec 2018 13:16:02 +0530 Subject: [glance][dev] Regarding "Eliminate Redundant Downloads of Uncached Images" project In-Reply-To: References: Message-ID: Hi all, I am very interested in working on one of the untargeted approved specifications in Glance. It is titled "Eliminate Redundant Downloads of Uncached Images". I have noticed that it is currently unassigned. My experience with OpenStack: I have setup Devstack. I have worked extensively on Swift as part of a research project. I have set up Swift All in One multiple times. I have also set up a multi-server installation of Swift. I have studied the codebase of Swift and added my own features for my project. I don't have a lot of experience with Glance. I have experience with dealing with large codebases and I am willing to dedicate myself to study Glance and work on this project. I would love to know if it is up for grabs! Bharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From yongli.he at intel.com Fri Dec 21 08:15:34 2018 From: yongli.he at intel.com (yonglihe) Date: Fri, 21 Dec 2018 16:15:34 +0800 Subject: [nova] implementation options for nova spec: show-server-numa-topology In-Reply-To: <962173e9-62e4-63f1-6b52-a97350e02d00@gmail.com> References: <06c01a05-30a0-6671-0c89-780927da6793@gmail.com> <23c8790e-f62d-c742-d726-7c5e63f38f4a@intel.com> <962173e9-62e4-63f1-6b52-a97350e02d00@gmail.com> Message-ID: <01fc9c18-60a1-7f79-f5b8-152f72388784@intel.com> On 2018/12/21 上午9:28, Matt Riedemann wrote: > On 12/20/2018 7:13 PM, yonglihe wrote: >> On 2018/12/20 下午10:47, Matt Riedemann wrote: >>> On 12/18/2018 2:20 AM, yonglihe wrote: >>>> >>>> Base on IRC's discuss, we may have 3 options about how to deal with >>>> those blobs: >>>> >>>> 1) include those directly in the server response details, like the >>>> released POC does: >>>> https://review.openstack.org/#/c/621476/3 >>> >>> I would think these are potentially admin-level sensitive details as >>> well and thus only exposed based on a policy check. A user requests >>> a certain topology, but I'm not sure how low-level the user >>> needs/should see what nova is doing for satisfying that topology, >>> especially for things like pinning CPUs on the host. I thought the >>> main use case for this spec (and several like these discussed at the >>> PTG) was more about being able to get information (reporting) out of >>> the REST API for debugging (by admins and/or support team members), >>> less about user need. >>> >>>> >>>> 2) add a new sub-resource endpoint to servers, most likely use key >>>> word 'topology' then: >>>> "GET /servers/{server_id}/topology" returns the NUMA information >>>> for one server. >>> >>> Similar to (1) in that I'd think there would be a new policy check >>> on this which defaults to admin-only. I think this would be better >>> than (1) since it wouldnt' be confused with listing servers (GET >>> /servers/detail). >>> >>>> >>>> 3) put the NUMA info under existing 'diagnostics' API. >>>> "GET /servers/{server_id}/diagnostics" >>>> this is admin only API, normal user loss the possible to check >>>> their topology. >>> >>> By default it's an admin-only API, but that is configurable in >>> policy, so if a given cloud wants to expose this for admin or owner >>> of the instance, they can do that, or alternatively expose it to >>> support team members via a special role in keystone. >>> >>>> >>>> when the information put into diagnostics, they will be look like: >>>> { >>>>     .... >>>>     "numa_topology": { >>>>        cells  [ >>>>                 { >>>>                      "numa_node" : 3 >>>>                      "cpu_pinning": {0:5, 1:6}, >>>>                      "cpu_thread_policy": "prefer", >>>>                      "cpuset": [0,1,2,3], >>>>                      "siblings": [[0,1],[2,3]], >>>>                      "mem": 1024, >>>>                      "pagesize": 4096, >>>>                      "sockets": 0, >>>>                      "cores": 2, >>>>                       "threads": 2, >>>>                   }, >>>>               ... >>>>             ] # cells >>>>      } >>>>      "emulator_threads_policy": "share" >>>> >>>>      "pci_devices": [ >>>>          { >>>>                  "address":"00:1a.0", >>>>                  "type": "VF", >>>>                  "vendor": "8086", >>>>                  "product": "1526" >>>>          }, >>>>      ] >>>>   } >>> >>> I tend to prefer option (3) since it seems topology is a much more >>> natural fit with the existing information (low-level CPU/RAM/disk >>> usage) we expose out of the diagnostics API and is already >>> restricted to admins by default in policy (but again as noted this >>> can be configured). >>> >> Matt, thanks point this out.  (3)  is more clear and less >> configuration mess, so (3) winning, spec is gonna be revised. > > I also commented in the spec today. I would also be OK(ish) with > option 2. I'm mostly concerned about the performance implications of > needing to fetch and process this data, including policy checks, when > listing 1000 servers with details. The spec wasn't clear (to me) about > where the data comes from exactly (do we join on the compute_nodes > table?). I'm also unsure about how much end users need to see the > NUMA/PCI information for their server (so is the admin-only policy > sufficient for the diagnostics API?). I'd really like input from > others here. I mostly just want users to have to opt in to getting > this information, not nova needing to produce it in the main server > resource response during show/list, so option 2 or 3 are preferable > *to me*. > > I think option 3 is the safest one if we're unsure or deadlocked > otherwise, but no one else has really said anything (outside of the > spec anyway). Spec patch set 10 address all your comments, and thanks a lot for all typo things. Spec path set 11, switch to implementation option 2, cause the data did come from another DB query, it's obviously impact the performance some how, especially on a batch operations. thanks. Regards Yongli he From rui.zang at yandex.com Fri Dec 21 08:45:14 2018 From: rui.zang at yandex.com (Rui Zang) Date: Fri, 21 Dec 2018 16:45:14 +0800 Subject: [nova] Persistent memory resource tracking model Message-ID: <16197751545381914@sas2-857317bd6599.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: From dabarren at gmail.com Fri Dec 21 09:21:48 2018 From: dabarren at gmail.com (Eduardo Gonzalez) Date: Fri, 21 Dec 2018 10:21:48 +0100 Subject: [stable][kolla] EOL kolla ocata branch Message-ID: Hi stable team, Kolla project is ready to tag EOL the stable/ocata branch. We would like to tag the following repositories as EOL: - openstack/kolla - openstack/kolla-ansible Let me know if need anything else. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdent+os at anticdent.org Fri Dec 21 10:18:27 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Fri, 21 Dec 2018 10:18:27 +0000 (GMT) Subject: [placement] How do we migrate DB manipulating data? In-Reply-To: References: Message-ID: On Wed, 19 Dec 2018, TETSURO NAKAMURA wrote: > 1. Do it in the alembic script in the same way as the schema expansion > 2. Have two stable version branches for alembic to separate schema changes > and data manipulation > 3. Bring the online-migration batch CLI command > 4. Any other ideas? > Since it looks like it's going to have an impact both on operators who > upgrade and developers who add new features in placement, it is nice to seek > more ideas and to have a consensus before we go further. As I said on the review of https://review.openstack.org/#/c/624942/ I'm somewhat reluctant to add yet another command, simply because each moving part is another thing to know about and to manage, and sometimes, yet another command to run. In that sense of the options presented, I prefer option 1, but Dan makes good points on https://review.openstack.org/#/c/619126/ . The idealist in me thinks that we ought to be able to: * ensure any migrations we do (schema or data) that need to be done from the command line are quick and light * enable anything that is neither quick nor light on an as needed basis in the running code Where this latter option with root id went wrong is that the implementation was incomplete: It didn't cover all the cases where a root id would be involved, or perhaps we added cases later that didn't account for that possibility. In either case we didn't make good enough tests. However: the command that's been implemented in 624942 is pretty clean and if it is what people think is the best solution, it's likely the shortest path for us to have something that works and keep the most people happy is using it. Unless we hear from other people we should probably just go with that, but we should wait until January to decide since not many people are around now. For the record, my real preference is that we have neither of 'db sync' nor 'db online-data-migration' commands and simply do those things when the server process starts itself (but before listening on a socket). There's a WIP for that in https://review.openstack.org/#/c/619050/ . I've not pursued that too aggressively because people don't seem that into it, but, to me, having placement self contained with as few additional processes is the way to have the most flexibility. However, my position doesn't take into account the many diverse ways that people deploy their clouds. Which is why we need input from the larger community on these kinds of decisions. Thanks. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From ellorent at redhat.com Fri Dec 21 10:43:41 2018 From: ellorent at redhat.com (Felix Enrique Llorente Pastora) Date: Fri, 21 Dec 2018 11:43:41 +0100 Subject: [tripleo][ci] Reducing merge time by moving nv job to experimental In-Reply-To: <776615dd-02fd-d21b-486a-69b446b532f3@nemebean.com> References: <776615dd-02fd-d21b-486a-69b446b532f3@nemebean.com> Message-ID: Ack, let's fix stuff, so merge time is not a painful thing. On Thu, Dec 20, 2018 at 5:21 PM Ben Nemec wrote: > > > On 12/20/18 1:07 AM, Felix Enrique Llorente Pastora wrote: > > The problem with > >> experimental is that it requires folks to know to run them (which > >> generally does not happen for our project). > > > > So we have two options here: > > - Make experimental pipeline run on reviews directly without the > > "check-experimental" comment. > > - Create a new pipeline "draf" pipeline at infra, that runs WIP jobs or > > problematic jobs without interfering in normal production "check" > pipeline. > > > > What do you think ? > > I think Alex already answered this: Fix the scenario jobs so they can be > voting again. We need that coverage or we'll be perpetually breaking > services that are only tested in scenarios. As a result, any queue hacks > that we do would only be temporary anyway. There's no good reason to > spend a bunch of time on a one-off configuration that will go away in > the near future (hopefully ;-). > > > > > On Wed, Dec 19, 2018 at 3:48 PM Alex Schultz > > wrote: > > > > On Wed, Dec 19, 2018 at 7:44 AM Alex Schultz > > wrote: > > > > > > On Wed, Dec 19, 2018 at 7:34 AM Felix Enrique Llorente Pastora > > > > wrote: > > > > > > > > Hello, > > > > > > > > To reduce merge time, would be nice from a review to go from > > check pipeline to gate pipeline without waiting for non-voting jobs, > > one way to do that is changing non-voting jobs at different pipelien > > like experimental one, so we have their result but don't wait for > > them to change to gate pipepeline. > > > > > > > > > > The goal should be to get them to voting. The problem with > > > experimental is that it requires folks to know to run them (which > > > generally does not happen for our project). We currently have the > > > scenario jobs as non-voting because of capacity problems but we > still > > > need the coverage so I'm not keen on moving them to non-voting. > I'd > > > > err experimental not non-voting. > > > > > rather we spend the time to land the standalone versions and get > them > > > voting again. > > > > > > Thanks, > > > -Alex > > > > > > > -- > > > > Quique Llorente > > > > > > > > Openstack TripleO CI > > > > > > > > -- > > Quique Llorente > > > > Openstack TripleO CI > -- Quique Llorente Openstack TripleO CI -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaypipes at gmail.com Fri Dec 21 13:25:50 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Fri, 21 Dec 2018 08:25:50 -0500 Subject: [edge] Zero Touch Provisioning In-Reply-To: References: <3a1ca5f4-0c3a-ae32-3e0b-b346cf653f65@gmail.com> <59f29ce7-aa3e-7f68-4e53-2623d35cf778@gmail.com> Message-ID: <04d66a74-5560-45c5-d61f-fd38277b467d@gmail.com> On 12/21/2018 01:40 AM, Zhipeng Huang wrote: > ICYMI: > https://blog.ipspace.net/2018/12/zero-touch-provisioning-with-patrick_20.html From that article: "ZTP can be used internally connecting to an internal provisioning server, and it can be used externally connecting to an external provisioning server. Some commercial products use ZTP in connection with a vendor-controlled cloud-based provisioning server." Funny, that's almost exactly what I said in my original response on this thread :) > Shall we collect items of OCP/OpenStack components that could composite > a ZTP stack somewhere ? Sure, just make sure we're being explicit about the things we're discussing. If you want to focus exclusively on *network device* provisioning, that's fine, but that should be explicitly stated. Network device provisioning is an important but ultimately tiny part of infrastructure provisioning. Unfortunately, most of the telco and network OEM community (understandably) only refer to network device provisioning when they talk about "ZTP". Also, the less this can be pidgeon-holed into the amorphous "edge" category, the better, IMHO ;) Best, -jay > On Thu, Dec 20, 2018 at 10:51 PM Curtis > wrote: > > On Thu, Dec 20, 2018 at 9:35 AM Jay Pipes > wrote: > > On 12/20/2018 09:33 AM, Curtis wrote: > > No, it doesn't do inventory management. It's like a small > base OS for > > network switches, they come with it, boot up into it, and you > can use it > > to install other OSes. At least that's how it's used with the > whitebox > > switches I have. With ONIE it'd install the OS, then the > initial OS > > could register with some kind of inventory system. > > What about for non-network devices -- i.e. general compute > hardware? > After all, edge is more than just the network switches :) > > > I'm not sure; that's a good question. I was just using it as an > example of a piece of ZTP related technology that has been adopted > by vendors who build physical devices and include them by default, > though of course, only a subset of network switches. :) > > If ONIE was a good example, and it could not be used for general > compute hardware, then perhaps something like it could be built > using lessons learned by ONIE. I dunno. :) > > Thanks, > Curits > > > Best, > -jay > > > > -- > Blog: serverascode.com > > > > -- > Zhipeng (Howard) Huang > > Principle Engineer > IT Standard & Patent/IT Product Line > Huawei Technologies Co,. Ltd > Email: huangzhipeng at huawei.com > Office: Huawei Industrial Base, Longgang, Shenzhen > From jaypipes at gmail.com Fri Dec 21 13:40:52 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Fri, 21 Dec 2018 08:40:52 -0500 Subject: [placement] How do we migrate DB manipulating data? In-Reply-To: References: Message-ID: <461bee2d-267f-56d9-b3f7-06523744cf73@gmail.com> On 12/21/2018 05:18 AM, Chris Dent wrote: > On Wed, 19 Dec 2018, TETSURO NAKAMURA wrote: > >> 1. Do it in the alembic script in the same way as the schema expansion >> 2. Have two stable version branches for alembic to separate schema >> changes and data manipulation >> 3. Bring the online-migration batch CLI command >> 4. Any other ideas? > >> Since it looks like it's going to have an impact both on operators who >> upgrade and developers who add new features in placement, it is nice >> to seek more ideas and to have a consensus before we go further. > > As I said on the review of https://review.openstack.org/#/c/624942/ > I'm somewhat reluctant to add yet another command, simply because > each moving part is another thing to know about and to manage, and > sometimes, yet another command to run. In that sense of the options > presented, I prefer option 1, but Dan makes good points on > https://review.openstack.org/#/c/619126/ . The idealist in me thinks > that we ought to be able to: > > * ensure any migrations we do (schema or data) that need to be >   done from the command line are quick and light > * enable anything that is neither quick nor light on an as needed >   basis in the running code > > Where this latter option with root id went wrong is that the > implementation was incomplete: It didn't cover all the cases where a > root id would be involved, or perhaps we added cases later that > didn't account for that possibility. In either case we didn't make > good enough tests. > > However: the command that's been implemented in 624942 is pretty > clean and if it is what people think is the best solution, it's > likely the shortest path for us to have something that works and > keep the most people happy is using it. > > Unless we hear from other people we should probably just go with > that, but we should wait until January to decide since not many > people are around now. > > For the record, my real preference is that we have neither of > 'db sync' nor 'db online-data-migration' commands and simply do > those things when the server process starts itself (but before > listening on a socket). +1000 This is how Swift works [1] and is the least operational burden of all approaches I've seen. > There's a WIP for that in https://review.openstack.org/#/c/619050/ . > I've not pursued that too aggressively because people don't seem that > into it, but, to me, having placement self contained with as few > additional processes is the way to have the most flexibility. > However, my position doesn't take into account the many diverse ways > that people deploy their clouds. I haven't looked at the WIP patch for this yet. I will try to do that soon. > Which is why we need input from the larger community on these kinds > of decisions. Agreed. Best, -jay [1] examples: https://github.com/openstack/swift/blob/a7aa2329584f1d02f7d1fa205d56aeadffdc980f/swift/account/backend.py#L557-L632 From dabarren at gmail.com Fri Dec 21 13:58:05 2018 From: dabarren at gmail.com (Eduardo Gonzalez) Date: Fri, 21 Dec 2018 14:58:05 +0100 Subject: [stable][kolla] EOL kolla ocata branch In-Reply-To: References: Message-ID: I've missed the extended maintenance, sorry about that. I don't fully understand what's the process for extended maintenance mode, who is responsible of the management and to take care of it. Is the core group responsible at all of the branch? Change any policy regarding what can be merged, backport, etc? Ocata branch has been unmaintained for a few months until a couple of patches fixes before putting into EOL. If someone wants to maintain ocata, I guess we should tag as EM. Should the core group vote this decision or is something decided based of people whiling to maintaining the branch? Regards n Fri, Dec 21, 2018, 10:21 AM Eduardo Gonzalez wrote: > Hi stable team, > > Kolla project is ready to tag EOL the stable/ocata branch. We would like > to tag the following repositories as EOL: > > - openstack/kolla > - openstack/kolla-ansible > > Let me know if need anything else. > Regards > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabarren at gmail.com Fri Dec 21 14:04:55 2018 From: dabarren at gmail.com (Eduardo Gonzalez) Date: Fri, 21 Dec 2018 15:04:55 +0100 Subject: [stable][kolla][EOL][EM] kolla ocata branch In-Reply-To: References: Message-ID: Please stable team, don't EOL kolla ocata yet, until we clarify if want EM or EOL the branch. Regards On Fri, Dec 21, 2018, 2:58 PM Eduardo Gonzalez wrote: > I've missed the extended maintenance, sorry about that. > > I don't fully understand what's the process for extended maintenance mode, > who is responsible of the management and to take care of it. Is the core > group responsible at all of the branch? Change any policy regarding what > can be merged, backport, etc? > > Ocata branch has been unmaintained for a few months until a couple of > patches fixes before putting into EOL. If someone wants to maintain ocata, > I guess we should tag as EM. > > Should the core group vote this decision or is something decided based of > people whiling to maintaining the branch? > > > Regards > > > > n Fri, Dec 21, 2018, 10:21 AM Eduardo Gonzalez wrote: > >> Hi stable team, >> >> Kolla project is ready to tag EOL the stable/ocata branch. We would like >> to tag the following repositories as EOL: >> >> - openstack/kolla >> - openstack/kolla-ansible >> >> Let me know if need anything else. >> Regards >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaypipes at gmail.com Fri Dec 21 14:21:02 2018 From: jaypipes at gmail.com (Jay Pipes) Date: Fri, 21 Dec 2018 09:21:02 -0500 Subject: [placement] How do we migrate DB manipulating data? In-Reply-To: References: Message-ID: <0b20ea80-77a2-e8e4-e9e6-089292609509@gmail.com> On 12/19/2018 02:22 AM, TETSURO NAKAMURA wrote: > Hi, > > I'd like to discuss how we can have DB upgrade migration method (with > data manipulation) in placement. > > --- > > BackGround > ========== > > https://bugs.launchpad.net/nova/+bug/1803925 > > * In Rocky, to have nested resource provider feature, we expanded the DB > to have root provider id column. Technically, we did this in Queens. The commit was in Sept 2016, more than two years ago: https://github.com/openstack/nova/commit/b10f11d7e8e1afb7a12a470f92c42bf3c23eca95 >     * The root provider id shouldn't be None and for root providers it > should be the same value of its resource provider id. > > * In Rocky, the code is build in a backward compatible way doing online > migration. >     * For each request of listing/showing resource providers, we look > the root provider id and if it is stale and empty, we assume the > resource provider is a root and set the same value as resource provider id. >     * Those providers that are not called in the Rocky cycle will still > have an empty value for the root provider id. > > * In Stein or later, we want a way to be sure that all the root provider > id contains some non-None value. To be more succinct, we want to be able to modify the root_provider_id column's nullability constraint to be NOT NULL. >     * This is because we have a lot of TODOs in code which we want to > clean up once we are sure all the root provider ids have non-None value > in the DB. ++ > * In Stein, we are already ready use alembic to manage DB schema changes > in placement. > > Question > ======== > > How should we copy the resource provider id to root provider id if the > root provider id is None? > > Options > ======= > > 1. Do it in the alembic script in the same way as the schema expansion >     * This is done in the https://review.openstack.org/#/c/619126/ and > brought several concerns. >         * We don't want the data manipulation migration to be > inter-mixed with schema changes. >         * For cases skipping one release in an FFU fashion, there would > be a lot of rows to be changed. > > 2. Have two stable version branches for alembic to separate schema > changes and data manipulation >     * Neutron has been managing two branches in alembic already. >         * > https://specs.openstack.org/openstack/neutron-specs/specs/liberty/online-schema-migrations.html > >     * Developers would specify on which branch to have a new version > via some a new CLI something like; `placement-db-manage revision -m > "description of revision" (--schema-change|--data-manipulate)` >     * We should be careful for the dependency management across the two > branches. >     * https://alembic.sqlalchemy.org/en/latest/branches.html > > 3. Bring the online-migration batch CLI command >     * Follow the traditional way to manage DB data in Nova >         * `placement-manage db online-data-migration [--max-count]` >         * I'm looking into this in > https://review.openstack.org/#/c/624942/. > > 4. Any other ideas? I think #2 is the best of the options, but not to separate data from schema migrations. Rather, just separate expand from contract migrations, as the original Neutron work did. Some data migrations can be done in an expand migration. Others must be done in a contract migration because the underlying software that uses the data may make assumptions that break after that data migration is run. The data migration of setting NULL root_provider_id to the value of the provider's id is a good example of a data migration that can run in an expand migration. The underlying code that uses root_provider_id handles cases where root_provider_id is NULL (it defaults those NULL values to the provider's id value). The only thing that would need to go into a contract migration is the schema migration to change the resource_providers.root_provider_id column constraint from NULL to NOT NULL, since that cannot run against the database unless all records have had their NULL root_provider_id column set with a value. The primary problem I have with the way Nova's online database migration functionality works is that the original idea of separating expanding and contracting schema migrations became muddied with the concept of whether the migration might cause some performance degradation of the database. Because a certain OpenStack deployer (RAX) was having issues running migrations against their database infrastructure, we started equating *all* schema and data migrations with the foregone conclusion of "this will take down the control plane for a long time!". Which simply isn't the case. We've added a large amount of code in the nova-manage online_data_migration command to deal with data migrations in a batched manner when running a simple single SQL statement against a database with even a huge number of rows would have taken milliseconds and caused zero disruption. We've foregone the simple solution and always go with the complex solution, and I think we're worse off for that in Nova. Ultimately, I think that both schema and data migrations should be triggered upon startup of a placement-api worker before it starts accepting connections (as noted in cdent's response here). However, that preference does not preclude the #2 solution above from being used (the placement-api service could simply automatically call the expand phase migrations on startup and optionally call the contract phase migrations on startup or some other trigger). So, in short, my vote is #2 but just call the two phases expand and contract, and don't differentiate between "schema migration" and "data migration". Best, -jay From mriedemos at gmail.com Fri Dec 21 14:52:29 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Fri, 21 Dec 2018 08:52:29 -0600 Subject: [stable][kolla] EOL kolla ocata branch In-Reply-To: References: Message-ID: On 12/21/2018 7:58 AM, Eduardo Gonzalez wrote: > I don't fully understand what's the process for extended maintenance > mode, who is responsible of the management and to take care of it. Is > the core group responsible at all of the branch? Change any policy > regarding what can be merged, backport, etc? Details are in [1][2]. The same project stable core team is responsible for the branch, it doesn't transfer to some new stable EM core team. The appropriate fix model is essentially the same - only backport fixes, not features, no new dependencies, etc. Gauge risk vs reward as normal. > > Ocata branch has been unmaintained for a few months until a couple of > patches fixes before putting into EOL. If someone wants to maintain > ocata, I guess we should tag as EM. Generally if CI is still working for the branch and people are using it, and it's not a burden, it's fine to leave it open. If it starts failing CI and no one is caring for it (fixing CI issues etc) then it's acceptable to move to EOL after 6 months (see the "Unmaintained" section in [2]). > > Should the core group vote this decision or is something decided based > of people whiling to maintaining the branch? It's really up to the core group. If there are people willing to maintain the branch outside of the core group, they should work with the core group, essentially like a liaison. [1] https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html [2] https://docs.openstack.org/project-team-guide/stable-branches.html -- Thanks, Matt From vedarthambharath at gmail.com Fri Dec 21 14:56:06 2018 From: vedarthambharath at gmail.com (Vedartham Bharath) Date: Fri, 21 Dec 2018 20:26:06 +0530 Subject: [glance][dev] Regarding "Eliminate Redundant Downloads of Uncached Images" project In-Reply-To: References: Message-ID: Hey Jim, Thank you for the reply! I was looking at this untargeted specs page for the project. http://specs.openstack.org/openstack/glance-specs/specs/untargeted/glance/duplicate-downloads.html It is stated in this page that this project is currently unassigned. I will start working on this spec. I will begin by studying Glance and start making smaller contributions to it for now. I need all the help I can get! I am very passionate about OpenStack and it's services! I will keep in touch with you and the developers through this mailing list and the IRC channel. Thank you Bharath On Fri, Dec 21, 2018, 7:20 PM Jim Rollenhagen On Fri, Dec 21, 2018 at 2:50 AM Vedartham Bharath < > vedarthambharath at gmail.com> wrote: > >> Hi all, >> >> I am very interested in working on one of the untargeted approved >> specifications in Glance. It is titled "Eliminate Redundant Downloads >> of Uncached Images". >> I have noticed that it is currently unassigned. >> >> My experience with OpenStack: >> I have setup Devstack. >> I have worked extensively on Swift as part of a research project. >> I have set up Swift All in One multiple times. >> I have also set up a multi-server installation of Swift. >> I have studied the codebase of Swift and added my own features for my >> project. >> >> I don't have a lot of experience with Glance. >> I have experience with dealing with large codebases and I am willing to >> dedicate myself to study Glance and work on this project. >> I would love to know if it is up for grabs! >> > > Hi Bharath, > > The untargeted specs page for glance says "The following specs have been > reviewed and approved but have not been targeted for a release because the > proposer is no longer available to work on the implementation". I do see > the blueprint for the spec[0] is assigned, but I know Jesse no longer works > on OpenStack. I'd say go ahead and assign the blueprint to yourself and > start hacking! :) > > [0] https://blueprints.launchpad.net/glance/+spec/duplicate-downloads > > // jim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Fri Dec 21 15:14:14 2018 From: thierry at openstack.org (Thierry Carrez) Date: Fri, 21 Dec 2018 16:14:14 +0100 Subject: [Release-job-failures] Release of openstack/karma-subunit-reporter failed In-Reply-To: References: <0e2af392-902c-e046-663f-1d9d20e239d8@openstack.org> Message-ID: Herve Beraud wrote: > Hey, > > Yeah this error seems to be normal since the version 0.0.4 already exist > on the repository. > > - https://www.npmjs.com/package/karma-subunit-reporter > > An another question is 2 lines below the npm error : > > + npm at 4.6.1 2018-12-19 10:15:02.372290 > > | localhost | added 299 packages from 591 contributors and audited 1181 > packages in 9.459s 2018-12-19 10:15:02.372387 > > | localhost | found 42 vulnerabilities (2 low, 34 moderate, 6 high) > > 42 Vulnerabilities found... I not an nodejs and npm expert so I'm not > sure that is a real problem but I think we need to take look about this. > Thoughts? Not a NPM specialist, but this might be due to karma-subunit-reporter not having been updated for a couple of years, and declaring outdated dependencies. The log is unclear whether those are directly tied to "npm at 4.6.1" (which I could not find as a direct dependency) or coming from the direct deps of k-s-r (subunit-js at 0.0.2, karma>=0.9...) -- Thierry Carrez (ttx) From alfredo.deluca at gmail.com Fri Dec 21 15:18:40 2018 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Fri, 21 Dec 2018 16:18:40 +0100 Subject: openstack stack fails Message-ID: Hi all. I installed magnum on openstack and now, after a few issue with cinder type list error, it passed that issue but now I have another one.... AuthorizationFailure: resources.kube_masters.resources[0].resources.master_wait_handle: Authorization failed. Not sure what to do nor check Any clue? Cheers -- *Alfredo* -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at jimrollenhagen.com Fri Dec 21 15:38:01 2018 From: jim at jimrollenhagen.com (Jim Rollenhagen) Date: Fri, 21 Dec 2018 10:38:01 -0500 Subject: [glance][dev] Regarding "Eliminate Redundant Downloads of Uncached Images" project In-Reply-To: References: Message-ID: On Fri, Dec 21, 2018 at 9:56 AM Vedartham Bharath < vedarthambharath at gmail.com> wrote: > Hey Jim, > > Thank you for the reply! > > I was looking at this untargeted specs page for the project. > > http://specs.openstack.org/openstack/glance-specs/specs/untargeted/glance/duplicate-downloads.html > It is stated in this page that this project is currently unassigned. > > I will start working on this spec. I will begin by studying Glance and > start making smaller contributions to it for now. > I need all the help I can get! I am very passionate about OpenStack and > it's services! > > I will keep in touch with you and the developers through this mailing list > and the IRC channel. > Thanks for adding the list back in, I forgot! :) I'm not a glance developer, FWIW, but they're all very helpful. Good luck! // jim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.morin at orange.com Fri Dec 21 16:05:09 2018 From: thomas.morin at orange.com (thomas.morin at orange.com) Date: Fri, 21 Dec 2018 17:05:09 +0100 Subject: [openstack-dev] [neutron] [neutron-interconnection] neutron-interconnection core reviewers In-Reply-To: References: Message-ID: <25624_1545408315_5C1D0F3B_25624_117_2_a9645dea-dcb0-4bd7-a71d-1ba60b5c04cc@OPEXCLILM6E.corporate.adroot.infra.ftgroup> Thanks Miguel! For those less familiar with this project, have a look at the summit presentation (slides [1], video [2]). We'll start to push some code for review, some now (cookiecutter), and more after the end of year/new year break. A change for the API definition was already pushed today in neutron-lib by the way [3]. Contributions welcome! -Thomas [1] https://www.slideshare.net/ThomasMorin1/neutrontoneutron-interconnecting-multiple-openstack-deployments [2] https://www.openstack.org/videos/berlin-2018/neutron-to-neutron-interconnecting-multiple-openstack-deployments [3] https://review.openstack.org/626871 On 20/12/2018 19:48, Miguel Lavalle wrote: > Hi Neutrinos, > > During the Dublin PTG we discussed and approved a > neutron-interconnection proposal. Over the past few months the spec > was merged > (https://specs.openstack.org/openstack/neutron-specs/specs/rocky/neutron-inter.html) > and the corresponding repo was also approved and created: > https://review.openstack.org/#/c/599428/ and > https://review.openstack.org/#/c/599429/. Earlier today the core team > of reviewers was created. This team includes the current Neutron core > plus Thomas Morin and Yannick Thomas. So let's start pushing and > reviewing code > > Best regards > > Miguel _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From miguel at mlavalle.com Fri Dec 21 16:43:25 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Fri, 21 Dec 2018 10:43:25 -0600 Subject: [openstack-dev] [neutron] Cancelling next two team meetings Message-ID: Hi Neutrinos, Due to the Holidays season in many parts of the world, we will cancel the weekly Neutron meeting on December 24th and January 1st. We will resume normally on January 7th Best regards Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbragstad at gmail.com Fri Dec 21 16:56:06 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Fri, 21 Dec 2018 10:56:06 -0600 Subject: [keystone] No meetings December 25th or January 1st Message-ID: Hey all, We talked about this in last week's meeting, but I'm sending a reminder to the list. We won't be having a team meeting or holding office hours next week or the week after since they fall on Christmas Day and New Year's. We'll resume meetings and office hours on January 8th. Happy holidays, Lance -------------- next part -------------- An HTML attachment was scrubbed... URL: From duc.openstack at gmail.com Fri Dec 21 17:16:31 2018 From: duc.openstack at gmail.com (Duc Truong) Date: Fri, 21 Dec 2018 09:16:31 -0800 Subject: [senlin] No meetings next two weeks Message-ID: Everyone, Due to the holidays there will be no meetings on December 28th and January 3rd. We will resume the regular meetings on Friday January 11th at 530 UTC. Duc From lbragstad at gmail.com Fri Dec 21 17:26:11 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Fri, 21 Dec 2018 11:26:11 -0600 Subject: [dev][keystone] Keystone Team Update - Week of 17 December 2018 Message-ID: # Keystone Team Update - Week of 17 December 2018 ## News This week was really quiet due to the holiday. Note that there won't be keystone meetings or office hours for the next two weeks since they fall on Christmas Day and New Years. If you have questions, please don't hesitate to use asynchronous communication like the mailing lists, especially since folks are likely on vacation and not lingering in IRC. ### Granular Instance Locks There is a thread about solving the problem on granular instance locks [0], which is kind of policy related. We're currently airing out all possible solutions. [0] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001223.html ## Open Specs Reminder that we're about a month away from specification freeze, so specification reviews are important. I'd like to specifically call attention to the renewable app creds specification [1] since that is one the few left on our radar for this release. Stein specs: https://bit.ly/2Pi6dGj Ongoing specs: https://bit.ly/2OyDLTh [0] https://review.openstack.org/#/c/604201/ ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 4 changes this week. ## Changes that need Attention Search query: https://bit.ly/2RLApdA There are 117 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. It'll be good to start ramping up review focus since we'll start running up against deadlines shortly after the new year. Please have a look if you have time. ## Bugs This week we opened 5 new bugs and closed 1. Bugs opened (5) Bug #1808859 (keystone:High) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1808859 Bug #1809116 (keystone:Undecided) opened by Kristi Nikolla https://bugs.launchpad.net/keystone/+bug/1809116 Bug #1809237 (keystone:Undecided) opened by varocho https://bugs.launchpad.net/keystone/+bug/1809237 Bug #1808550 (keystoneauth:Undecided) opened by Ievgeniia Zadorozhna https://bugs.launchpad.net/keystoneauth/+bug/1808550 Bug #1809101 (keystonemiddleware:Undecided) opened by leehom https://bugs.launchpad.net/keystonemiddleware/+bug/1809101 Bugs closed (1) Bug #1809237 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1809237 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html ## 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguel at mlavalle.com Fri Dec 21 17:58:35 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Fri, 21 Dec 2018 11:58:35 -0600 Subject: openstack-dev] [neutron] Cancelling next Neutron drivers meeting Message-ID: Hi Neutrinos, Due to the Holidays season in many parts of the world, we will cancel the Neutron drivers meeting on December 28th. We will resume normally on January 4th. Best regards Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpb at dyncloud.net Fri Dec 21 19:18:49 2018 From: tpb at dyncloud.net (Tom Barron) Date: Fri, 21 Dec 2018 14:18:49 -0500 Subject: [manila] no community meeting 27 December Message-ID: <20181221191849.r6b7b4yqo5ptpl6e@barron.net> As agreed at our last meeting, we will skip the regular manila community meeting on 27 December and resume our weekly cadence on 3 January 2019 at 1500 UTC on freenode #openstack-meeting-alt. All are welcome, and as usual please feel free to add to the agenda [1]. -- Tom Barron (irc: tbarron) [1] https://wiki.openstack.org/w/index.php?title=Manila/Meetings&action=edit§ion=2 From mriedemos at gmail.com Fri Dec 21 21:43:15 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Fri, 21 Dec 2018 15:43:15 -0600 Subject: [goals][upgrade-checkers] Week R-16 Update Message-ID: By my count, 34 of 43 projects have at least the initial framework change in place (up from 28 in November). Neutron has merged the change to enable loading upgrade checks via extension point: https://review.openstack.org/#/c/615196/ The designate check has been updated (thanks Ben) and is ready for review: https://review.openstack.org/#/c/604430/ - this one is not a placeholder Otherwise I would like to highlight some initial framework changes that I think are ready to go: * magnum: https://review.openstack.org/#/c/611505/ * cloudkitty: https://review.openstack.org/#/c/613076/ * aodh: https://review.openstack.org/#/c/614401/ * barbican: https://review.openstack.org/#/c/611574/ * ceilometer: https://review.openstack.org/#/c/614400/ -- Thanks, Matt From ignaziocassano at gmail.com Sat Dec 22 08:29:51 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sat, 22 Dec 2018 09:29:51 +0100 Subject: openstack stack fails In-Reply-To: References: Message-ID: Hi Alfredo, I am working on queens and I am not sure my answer could help you.... Can your master speak with kyestone public endpoint port (5000) ? Ignazio Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca ha scritto: > Hi all. > I installed magnum on openstack and now, after a few issue with cinder > type list error, it passed that issue but now I have another one.... > > > > AuthorizationFailure: > resources.kube_masters.resources[0].resources.master_wait_handle: > Authorization failed. > Not sure what to do nor check > Any clue? > Cheers > > > > -- > *Alfredo* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaosorior at redhat.com Sat Dec 22 11:40:24 2018 From: jaosorior at redhat.com (Juan Antonio Osorio Robles) Date: Sat, 22 Dec 2018 13:40:24 +0200 Subject: [TripleO] SELinux support In-Reply-To: References: Message-ID: On 12/13/18 7:16 PM, Mikhail Fedosin wrote: > Hello! > > One of the most important tasks for this release cycle is to provide > full SELinux support in the installed overcloud. Some work in this > direction has already been done and in many respects, due to the > recent changes, support is almost ready. > > However, I would like to ask a few questions about what else can be > improved. > In short, to provide SELinux support the main challenge for us is to > ensure that docker can write to the directories protected by SELinux. > To allow writing there we change the directory type to > container_file_t or its alias svirt_sandbox_file_t. > > There are two ways to do this: > 1. Explicitly - specify the type when creating a directory. > # semanage fcontext -at container_file_t "/my_folder(/.*)?" > # restorecon -R /my_folder > # docker run -v /my_folder:/tmp/my_folder ... > 2. Implicitly - use the suffix :z when mounting the partition when > creating a container. > # docker run -v /my_folder:/tmp/my_folder:z ... > > Both methods change selinux type of /my_folder to container_file_t and > allow to write to the section inside the container. > You can read more about this feature in the article > https://www.projectatomic.io/blog/2015/06/using-volumes-with-docker-can-cause-problems-with-selinux/ > To see how it works, I wrote a small playbook that creates two > directories on the host system and modifies their selinux types in two > ways: http://paste.openstack.org/show/737234/ > > Currently there is no consensus in TripleO which of the ways to use. > For example, in many cases both methods are used, which adds > unnecessary redundancy: > https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/cinder-api.yaml#L193-L194 > https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/cinder-api.yaml#L218-L219 > > In some cases there is only :z > https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/liquidio-compute-config.yaml#L97 > > In some, only explicit setting of svirt_sandbox_file_t on the directory > https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-proxy.yaml#L219 > https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-proxy.yaml#L248 > > Some services still do not have SELinux support: > https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/etcd.yaml > https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/zaqar.yaml > https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/tacker.yaml > > Such inconsistency leads to hard to find bugs and makes it difficult > to understand the code.  > An example of such a bug could be this: > Here we set selinux type to svirt_sandbox_file_t for /var/log/swift > https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-proxy.yaml#L249 > And rewrite it back later: > https://github.com/openstack/tripleo-heat-templates/blob/89d13583f7c706d5c7fbd5052fbedec53474f248/docker/services/swift-storage.yaml#L462 > For this reason, I want to come to an agreement on how we will > implement SELinux support. > > In my understanding, the best solution would be to use the suffix :z > only. Its advantage is that docker (and podman) checks the directory's > selinux type before launching the container and changes it > accordingly. In other words, if the type was accidentally changed > during the execution of the container, then when it is restarted ":z" > will return the type back. In the case of explicit type setting, we > get an error. > > Therefore, I propose to remove the explicit setting > svirt_sandbox_file_t and add the suffix ":z" where it is still missing. > > What do you think? This sounds like a reasonable solution. I actually didn't know we were expliclty changing stuff to svirt_sandbox_file_t, and thought we were solely relying on :z. Thanks for bringing this up. I like your proposal. > > Best regards, > Mikhail Fedosin From alfredo.deluca at gmail.com Sat Dec 22 16:18:14 2018 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Sat, 22 Dec 2018 17:18:14 +0100 Subject: openstack stack fails In-Reply-To: References: Message-ID: Ciao Ignazio What do you mean with master? you mean k8s master? I guess everything is fine... but I'll double check. Cheers On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano wrote: > Hi Alfredo, I am working on queens and I am not sure my answer could help > you.... > Can your master speak with kyestone public endpoint port (5000) ? > Ignazio > > Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca > ha scritto: > >> Hi all. >> I installed magnum on openstack and now, after a few issue with cinder >> type list error, it passed that issue but now I have another one.... >> >> >> >> AuthorizationFailure: >> resources.kube_masters.resources[0].resources.master_wait_handle: >> Authorization failed. >> Not sure what to do nor check >> Any clue? >> Cheers >> >> >> >> -- >> *Alfredo* >> >> -- *Alfredo* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Sat Dec 22 17:03:21 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sat, 22 Dec 2018 18:03:21 +0100 Subject: openstack stack fails In-Reply-To: References: Message-ID: Ciao Alfredo, yes I mean kubernetes master. Il giorno Sab 22 Dic 2018 17:18 Alfredo De Luca ha scritto: > Ciao Ignazio > What do you mean with master? you mean k8s master? > I guess everything is fine... but I'll double check. > > Cheers > > > On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano > wrote: > >> Hi Alfredo, I am working on queens and I am not sure my answer could help >> you.... >> Can your master speak with kyestone public endpoint port (5000) ? >> Ignazio >> >> Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca >> ha scritto: >> >>> Hi all. >>> I installed magnum on openstack and now, after a few issue with cinder >>> type list error, it passed that issue but now I have another one.... >>> >>> >>> >>> AuthorizationFailure: >>> resources.kube_masters.resources[0].resources.master_wait_handle: >>> Authorization failed. >>> Not sure what to do nor check >>> Any clue? >>> Cheers >>> >>> >>> >>> -- >>> *Alfredo* >>> >>> > > -- > *Alfredo* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Sat Dec 22 17:06:44 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sat, 22 Dec 2018 18:06:44 +0100 Subject: openstack stack fails In-Reply-To: References: Message-ID: Anycase during deployment you can connect with ssh to the master and tail the /var/log/ cloud in it output for checking. Ignazio Il giorno Sab 22 Dic 2018 17:18 Alfredo De Luca ha scritto: > Ciao Ignazio > What do you mean with master? you mean k8s master? > I guess everything is fine... but I'll double check. > > Cheers > > > On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano > wrote: > >> Hi Alfredo, I am working on queens and I am not sure my answer could help >> you.... >> Can your master speak with kyestone public endpoint port (5000) ? >> Ignazio >> >> Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca >> ha scritto: >> >>> Hi all. >>> I installed magnum on openstack and now, after a few issue with cinder >>> type list error, it passed that issue but now I have another one.... >>> >>> >>> >>> AuthorizationFailure: >>> resources.kube_masters.resources[0].resources.master_wait_handle: >>> Authorization failed. >>> Not sure what to do nor check >>> Any clue? >>> Cheers >>> >>> >>> >>> -- >>> *Alfredo* >>> >>> > > -- > *Alfredo* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfredo.deluca at gmail.com Sat Dec 22 19:51:00 2018 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Sat, 22 Dec 2018 20:51:00 +0100 Subject: openstack stack fails In-Reply-To: References: Message-ID: HI IGNAZIO The problem is that doesn't go that far... It fails before even creating the master. On Sat., 22 Dec. 2018, 6:06 pm Ignazio Cassano Anycase during deployment you can connect with ssh to the master and tail > the /var/log/ cloud in it output for checking. > Ignazio > > Il giorno Sab 22 Dic 2018 17:18 Alfredo De Luca > ha scritto: > >> Ciao Ignazio >> What do you mean with master? you mean k8s master? >> I guess everything is fine... but I'll double check. >> >> Cheers >> >> >> On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano >> wrote: >> >>> Hi Alfredo, I am working on queens and I am not sure my answer could >>> help you.... >>> Can your master speak with kyestone public endpoint port (5000) ? >>> Ignazio >>> >>> Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca < >>> alfredo.deluca at gmail.com> ha scritto: >>> >>>> Hi all. >>>> I installed magnum on openstack and now, after a few issue with cinder >>>> type list error, it passed that issue but now I have another one.... >>>> >>>> >>>> >>>> AuthorizationFailure: >>>> resources.kube_masters.resources[0].resources.master_wait_handle: >>>> Authorization failed. >>>> Not sure what to do nor check >>>> Any clue? >>>> Cheers >>>> >>>> >>>> >>>> -- >>>> *Alfredo* >>>> >>>> >> >> -- >> *Alfredo* >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Sat Dec 22 21:37:52 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sat, 22 Dec 2018 22:37:52 +0100 Subject: openstack stack fails In-Reply-To: References: Message-ID: Il giorno Sab 22 Dic 2018 20:51 Alfredo De Luca ha scritto: > HI IGNAZIO > The problem is that doesn't go that far... It fails before even creating > the master. > > On Sat., 22 Dec. 2018, 6:06 pm Ignazio Cassano wrote: > >> Anycase during deployment you can connect with ssh to the master and tail >> the /var/log/ cloud in it output for checking. >> Ignazio >> >> Il giorno Sab 22 Dic 2018 17:18 Alfredo De Luca >> ha scritto: >> >>> Ciao Ignazio >>> What do you mean with master? you mean k8s master? >>> I guess everything is fine... but I'll double check. >>> >>> Cheers >>> >>> >>> On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano < >>> ignaziocassano at gmail.com> wrote: >>> >>>> Hi Alfredo, I am working on queens and I am not sure my answer could >>>> help you.... >>>> Can your master speak with kyestone public endpoint port (5000) ? >>>> Ignazio >>>> >>>> Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca < >>>> alfredo.deluca at gmail.com> ha scritto: >>>> >>>>> Hi all. >>>>> I installed magnum on openstack and now, after a few issue with cinder >>>>> type list error, it passed that issue but now I have another one.... >>>>> >>>>> >>>>> >>>>> AuthorizationFailure: >>>>> resources.kube_masters.resources[0].resources.master_wait_handle: >>>>> Authorization failed. >>>>> Not sure what to do nor check >>>>> Any clue? >>>>> Cheers >>>>> >>>>> >>>>> >>>>> -- >>>>> *Alfredo* >>>>> >>>>> >>> >>> -- >>> *Alfredo* >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Sat Dec 22 21:49:53 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sat, 22 Dec 2018 22:49:53 +0100 Subject: openstack stack fails In-Reply-To: References: Message-ID: Hi Alfredo, have you tried a simple heat template to verify if heat is working fine? Ignazio Il giorno Sab 22 Dic 2018 20:51 Alfredo De Luca ha scritto: > HI IGNAZIO > The problem is that doesn't go that far... It fails before even creating > the master. > > On Sat., 22 Dec. 2018, 6:06 pm Ignazio Cassano wrote: > >> Anycase during deployment you can connect with ssh to the master and tail >> the /var/log/ cloud in it output for checking. >> Ignazio >> >> Il giorno Sab 22 Dic 2018 17:18 Alfredo De Luca >> ha scritto: >> >>> Ciao Ignazio >>> What do you mean with master? you mean k8s master? >>> I guess everything is fine... but I'll double check. >>> >>> Cheers >>> >>> >>> On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano < >>> ignaziocassano at gmail.com> wrote: >>> >>>> Hi Alfredo, I am working on queens and I am not sure my answer could >>>> help you.... >>>> Can your master speak with kyestone public endpoint port (5000) ? >>>> Ignazio >>>> >>>> Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca < >>>> alfredo.deluca at gmail.com> ha scritto: >>>> >>>>> Hi all. >>>>> I installed magnum on openstack and now, after a few issue with cinder >>>>> type list error, it passed that issue but now I have another one.... >>>>> >>>>> >>>>> >>>>> AuthorizationFailure: >>>>> resources.kube_masters.resources[0].resources.master_wait_handle: >>>>> Authorization failed. >>>>> Not sure what to do nor check >>>>> Any clue? >>>>> Cheers >>>>> >>>>> >>>>> >>>>> -- >>>>> *Alfredo* >>>>> >>>>> >>> >>> -- >>> *Alfredo* >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfredo.deluca at gmail.com Sun Dec 23 10:19:32 2018 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Sun, 23 Dec 2018 11:19:32 +0100 Subject: openstack stack fails In-Reply-To: References: Message-ID: I ll try asap. Thanks On Sat., 22 Dec. 2018, 10:50 pm Ignazio Cassano Hi Alfredo, have you tried a simple heat template to verify if heat is > working fine? > Ignazio > > > > Il giorno Sab 22 Dic 2018 20:51 Alfredo De Luca > ha scritto: > >> HI IGNAZIO >> The problem is that doesn't go that far... It fails before even creating >> the master. >> >> On Sat., 22 Dec. 2018, 6:06 pm Ignazio Cassano > wrote: >> >>> Anycase during deployment you can connect with ssh to the master and >>> tail the /var/log/ cloud in it output for checking. >>> Ignazio >>> >>> Il giorno Sab 22 Dic 2018 17:18 Alfredo De Luca < >>> alfredo.deluca at gmail.com> ha scritto: >>> >>>> Ciao Ignazio >>>> What do you mean with master? you mean k8s master? >>>> I guess everything is fine... but I'll double check. >>>> >>>> Cheers >>>> >>>> >>>> On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano < >>>> ignaziocassano at gmail.com> wrote: >>>> >>>>> Hi Alfredo, I am working on queens and I am not sure my answer could >>>>> help you.... >>>>> Can your master speak with kyestone public endpoint port (5000) ? >>>>> Ignazio >>>>> >>>>> Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca < >>>>> alfredo.deluca at gmail.com> ha scritto: >>>>> >>>>>> Hi all. >>>>>> I installed magnum on openstack and now, after a few issue with >>>>>> cinder type list error, it passed that issue but now I have another one.... >>>>>> >>>>>> >>>>>> >>>>>> AuthorizationFailure: >>>>>> resources.kube_masters.resources[0].resources.master_wait_handle: >>>>>> Authorization failed. >>>>>> Not sure what to do nor check >>>>>> Any clue? >>>>>> Cheers >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Alfredo* >>>>>> >>>>>> >>>> >>>> -- >>>> *Alfredo* >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From guoyongxhzhf at 163.com Sun Dec 23 17:31:18 2018 From: guoyongxhzhf at 163.com (guoyongxhzhf at 163.com) Date: Mon, 24 Dec 2018 01:31:18 +0800 Subject: The design choice of keystone sso Message-ID: <6DA2B899471D49A696BD48A96338F724@guoyongPC> The problem is about keystone with sso The situation: 1. the cloud based on OpenStack has use keystone to build its own user account system, and no third user account like ldap or google accounts 2. the cloud may have multi web application/entrance and have multi domain name, so we need sso So there are two choice to implement sso 1. use CAS or other open source components as sso service and use database authentication which query keystone database.(I think it's odd) 2. use cookies(including keystone token) between multi web application/entrance which is the better choice? I think if we use only users from keystone, it's not necessary to use an extra sso service. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Sun Dec 23 20:00:59 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Sun, 23 Dec 2018 20:00:59 +0000 Subject: [infra][storyboard] Project Update/Some New Things In-Reply-To: <20180910143449.ycbttjla2tn4ysql@yuggoth.org> References: <1536586998.2089.20.camel@sotk.co.uk> <20180910143449.ycbttjla2tn4ysql@yuggoth.org> Message-ID: <20181223200059.lco557g4atqy2hn5@yuggoth.org> On 2018-09-10 14:34:49 +0000 (+0000), Jeremy Stanley wrote: > On 2018-09-10 14:43:18 +0100 (+0100), Adam Coldrick wrote: [...] > > # Finding stories from a task ID > > > > It is now possible to navigate to a story given just a task ID, > > if for whatever reason that's all the information you have > > available. A link like > > > > https://storyboard.openstack.org/#!/task/12389 > > > > will work. This will redirect to the story containing the task, > > and is the first part of work to support linking directly to an > > individual task in a story. > [...] > > As an aside, I think this makes it possible now for us to start > hyperlinking Task footers in commit messages within the Gerrit > change view. I'll try and figure out what we need to adjust in our > Gerrit commentlink and its-storyboard plugin configs to make that > happen. As of Friday (2018-12-21) our Gerrit instance at https://review.openstack.org/ has started hyperlinking task footers in commit messages, leveraging the above feature (the configuration change for it merged months ago but Gerrit has been so stable lately we've not gotten around to restarting it for that to take effect until now). At this point you can omit the story footer if you have a task footer, since all the story footer has been providing is a hyperlink 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 skaplons at redhat.com Sun Dec 23 20:19:40 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Sun, 23 Dec 2018 21:19:40 +0100 Subject: [neutron] Subnet onboard and changing API definitions in neutron-lib In-Reply-To: References: <6043f799-3413-62f8-1f21-6e5f3dd5988a@suse.com> Message-ID: Hi, Sorry for late answer. I also think that changing this API definition shouldn’t be a problem if it was never implemented yet. For me case 2 sounds reasonable and I think that we should make API as simple as it’s possible, so we shouldn’t force users to pass with request data which is not really needed. — Slawek Kaplonski Senior software engineer Red Hat > Wiadomość napisana przez Miguel Lavalle w dniu 19.12.2018, o godz. 00:55: > > Hi, > > Based on the proposed Neutron patch (https://review.openstack.org/#/c/348080/36/neutron/db/db_base_plugin_v2.py at 1252), clearly the intent of ONBOARD_SUBNETS_SPECS is the creation of new subnets when a subnetpool is created or updated. No ambiguity there. Having said that, I agree with you, it is a cumbersome way to create subnets out of subnetpools that forces the user to issue a additional calls to retrieve the the details of the subnets, since few details are returned in the first call: https://review.openstack.org/#/c/348080/36/neutron/db/db_base_plugin_v2.py at 1255. As a consequence, I am in favor of just removing ONBOARD_SUBNETS_SPECS and use the 'onboard_network_subnets' action to onboard existing subnets. As for the API definition sitting a long time in neutron-lib, I don't see that as a problem. The API definition hasn't actually been available to users through any functionality in Neutron, so I don't think we have any > > Thanks for working on this > > Miguel > > On Mon, Dec 10, 2018 at 4:45 PM Ryan Tidwell wrote: > All, > > I alluded to some concerns about the current state of subnet onboard at > the end of today's neutron team meeting. I felt the mailing list was > probably the best starting point for a discussion, so here it goes :) > > > As I'm dealing with the last loose ends, I'm starting to deal with the > 'subnets' extension to the subnetpool resource on the API [1]. This has > me scratching my head at what the intent of this is since there isn't > much history to work with. When I look at the definition of the subnet > onboard extension in neutron-lib, I can see two possible "meanings" of > POST/PUT here: > > 1. Create a subnet from this subnetpool using the default prefix length > of the subnet pool. > > 2. Onboard the given subnet into the subnet pool. > > In addition to this ambiguity around the usage of the API, I also have > concerns that ONBOARD_SUBNET_SPECS as currently defined makes no sense > for either case. ONBOARD_SUBNET_SPECS requires that an id, network_id, > and ip_version be sent on any request made. This seems unnecessary for > both cases. > > Case 1 where we assume that we are using an alternate API to create a > subnet is problematic in the following ways: > > - Specifying an ip_version is unnecessary because it can be inferred > from the subnet pool > > - The definition as written doesn't seem to allow us to respond to the > user with anything other than a UUID. The user then has to make a second > call to actually go read the details like CIDR that are going to be > useful for them going forward. > > - More importantly, we already have an API (and corresponding CLI) for > creating subnets that works well and has much more flexibility than this > provides. Why duplicate functionality here? > > > Case 2 where we assume that we are onboarding a subnet is problematic in > the following ways: > > - Specifying network_id and ip_version are unnecessary. These values can > be read right off the subnet (which we would need to read for onboarding > anyway), all that needs to be passed is the subnet UUID. > > - Again, we would be duplicating functionality here because we have > already defined an API for onboarding a subnet in the ACTION_MAP [2] > > > My intent is to figure out where to go from here to make this better > and/or alleviate the confusion on my part so this feature can be wrapped > up. Here is what I propose: > > Because subnet onboard is still incomplete and we are not claiming > support for it yet, I am proposing we simply remove the 'subnets' > extension to the subnetpools resource [3]. This simplifies the API and > resolves the concerns I expressed above. It also allows us to quickly > finish up subnet onboard without losing any of the desired > functionality, namely the ability to move ("onboard") an existing subnet > into a subnet pool (and by extension and address scope). > > The reason I am looking for input here is that it isn't clear to me > whether the approach I'm suggesting is acceptable to the team given our > policies around changing API definitions in neutron-lib. I'm not aware > of a situation where we have had an unreleased feature and have > discovered we don't like the API definition in neutron-lib (which has > sat for quite a while unimplemented) and want to change it. I'm just not > aware of any precedent for this situation, so I'm hoping the team has > some thoughts on how best to move forward. > > For reference, the current review for subnet onboard is > https://review.openstack.org/#/c/348080/. Any thoughts on this topic > would be greatly appreciated by me, and hopefully this discussion can be > useful to a broad audience going forward. > > > -Ryan > > > [1] > https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/subnet_onboard.py#L32 > > [2] > https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/subnet_onboard.py#L58 > > [3] > https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/subnet_onboard.py#L41 > > > From guoyongxhzhf at 163.com Mon Dec 24 01:44:15 2018 From: guoyongxhzhf at 163.com (guoyongxhzhf at 163.com) Date: Mon, 24 Dec 2018 09:44:15 +0800 Subject: [keystone] The design choice of keystone sso Message-ID: <5CD617C5A47045A5BF7F2845C258835A@guoyongPC> The problem is about keystone with sso The situation: 1. the cloud based on OpenStack has use keystone to build its own user account system, and no third user account like ldap or google accounts 2. the cloud may have multi web application/entrance and have multi domain name, so we need sso So there are two choice to implement sso 1. use CAS or other open source components as sso service and use database authentication which query keystone database.(I think it's odd) 2. use cookies(including keystone token) between multi web application/entrance which is the better choice? I think if we use only users from keystone, it's not necessary to use an extra sso service. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafaelweingartner at gmail.com Mon Dec 24 02:20:23 2018 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Mon, 24 Dec 2018 00:20:23 -0200 Subject: The design choice of keystone sso In-Reply-To: <6DA2B899471D49A696BD48A96338F724@guoyongPC> References: <6DA2B899471D49A696BD48A96338F724@guoyongPC> Message-ID: We have this very same design. Why not just use Keycloak (with either SAML or OIDC) and OpenStack. At the end of the day, that is why you use Keycloak. Remember, when using Keycloak or any other identity management system, you are offloading the identity management to another system (out of your application). Then, your applications/”service providers” only need to worry about the service/resource being delivered, and the authentication and identity management is executed in the identity management system (Keycloak in your case). On Sun, Dec 23, 2018 at 3:34 PM wrote: > The problem is about keystone with sso > > The situation: > 1. the cloud based on OpenStack has use keystone to build its own user > account system, and no third user account like ldap or google accounts > 2. the cloud may have multi web application/entrance and have multi domain > name, so we need sso > > So there are two choice to implement sso > 1. use CAS or other open source components as sso service and use database > authentication which query keystone database.(I think it's odd) > 2. use cookies(including keystone token) between multi web > application/entrance > > which is the better choice? I think if we use only users from keystone, > it's not necessary to use an extra sso service. > -- Rafael Weingärtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From pawel at suder.info Mon Dec 24 10:35:49 2018 From: pawel at suder.info (=?UTF-8?Q?Pawe=C5=82?= Suder) Date: Mon, 24 Dec 2018 11:35:49 +0100 Subject: [neutron] Bug deputy report 17th~23rd Dec 2018 Message-ID: <1545647749.6273.1.camel@suder.info> Hello Neutrons, Following bugs/RFE/issues have been raised during last week. Some of them were already recognized, triaged, checked: >From oldest: https://bugs.launchpad.net/neutron/+bug/1808731 [RFE] Needs to restart metadata proxy with the start/restart of l3/dhcp agent - IMO need to discus how to do that. https://bugs.launchpad.net/neutron/+bug/1808916 Update mailinglist from dev to discuss - it is done. https://bugs.launchpad.net/neutron/+bug/1808917 RetryRequest shouldn't log stack trace by default, or it should be configurable by the exception - confirmed by Sławek ;) https://bugs.launchpad.net/neutron/+bug/1809037 [RFE] Add anti_affinity_group to binding:profile - RFE connected with another RFE from Nova related to NFV and (anti)affinity of resources like PFs. https://bugs.launchpad.net/neutron/+bug/1809080 reload_cfg doesn't work correctly - change in review, I tried to review, but no comments left - new contributor https://bugs.launchpad.net/neutron/+bug/1809134 - TypeError in QoS gateway_ip code in l3-agent logs - review in progress https://bugs.launchpad.net/neutron/+bug/1809238 - [l3] `port_forwarding` cannot be set before l3 `router` in service_plugins - review in progress https://bugs.launchpad.net/neutron/+bug/1809447 - performance regression from mitaka to ocata - not triaged, I am not sure how to handle it - it is a wide thing.. https://bugs.launchpad.net/neutron/+bug/1809497 - bug noticed on gates related to another bug opened last week: https://bugs.launchpad.net/neu tron/+bug/1809134 Wish you a good time this week and for the next year! :) Cheers, Paweł From miguel at mlavalle.com Mon Dec 24 18:42:30 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Mon, 24 Dec 2018 12:42:30 -0600 Subject: [neutron] Bug deputy report 17th~23rd Dec 2018 In-Reply-To: <1545647749.6273.1.camel@suder.info> References: <1545647749.6273.1.camel@suder.info> Message-ID: Hi Pawel, Thanks for the update Merry Christmas On Mon, Dec 24, 2018 at 7:58 AM Paweł Suder wrote: > Hello Neutrons, > > Following bugs/RFE/issues have been raised during last week. Some of > them were already recognized, triaged, checked: > > From oldest: > > https://bugs.launchpad.net/neutron/+bug/1808731 [RFE] Needs to restart > metadata proxy with the start/restart of l3/dhcp agent - IMO need to > discus how to do that. > > https://bugs.launchpad.net/neutron/+bug/1808916 Update mailinglist from > dev to discuss - it is done. > > https://bugs.launchpad.net/neutron/+bug/1808917 RetryRequest shouldn't > log stack trace by default, or it should be configurable by the > exception - confirmed by Sławek ;) > > https://bugs.launchpad.net/neutron/+bug/1809037 [RFE] Add > anti_affinity_group to binding:profile - RFE connected with another RFE > from Nova related to NFV and (anti)affinity of resources like PFs. > > https://bugs.launchpad.net/neutron/+bug/1809080 reload_cfg doesn't work > correctly - change in review, I tried to review, but no comments left - > new contributor > > https://bugs.launchpad.net/neutron/+bug/1809134 - TypeError in QoS > gateway_ip code in l3-agent logs - review in progress > > https://bugs.launchpad.net/neutron/+bug/1809238 - [l3] > `port_forwarding` cannot be set before l3 `router` in service_plugins - > review in progress > > https://bugs.launchpad.net/neutron/+bug/1809447 - performance > regression from mitaka to ocata - not triaged, I am not sure how to > handle it - it is a wide thing.. > > https://bugs.launchpad.net/neutron/+bug/1809497 - bug noticed on gates > related to another bug opened last week: https://bugs.launchpad.net/neu > tron/+bug/1809134 > > Wish you a good time this week and for the next year! :) > > Cheers, > Paweł > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liliueecg at gmail.com Mon Dec 24 20:56:19 2018 From: liliueecg at gmail.com (Li Liu) Date: Mon, 24 Dec 2018 15:56:19 -0500 Subject: [cyborg] No IRC meetings for until the week of Jan 7th 2019 Message-ID: Hi Team, Due to the holiday season, we will not have irc meetings for this week and the week after. The next meeting will be held on Jan 8th 2019 Enjoy the holidays and happy new year. -- Thank you Regards Li -------------- next part -------------- An HTML attachment was scrubbed... URL: From rico.lin.guanyu at gmail.com Tue Dec 25 06:08:44 2018 From: rico.lin.guanyu at gmail.com (Rico Lin) Date: Tue, 25 Dec 2018 14:08:44 +0800 Subject: [heat] No IRC meeting until Jan. 9th Message-ID: Dear all, these two weeks are Christmas and new year. We will resume our meeting on Jan. 9th, 2019 So I wish you all a merry Christmas and happy new year. -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin -------------- next part -------------- An HTML attachment was scrubbed... URL: From dharmendra.kushwaha at india.nec.com Tue Dec 25 08:05:11 2018 From: dharmendra.kushwaha at india.nec.com (Dharmendra Kushwaha) Date: Tue, 25 Dec 2018 08:05:11 +0000 Subject: [Tacker] No IRC meetings taday and next week. Message-ID: Dear Folks, Due to the holiday season, we will not have IRC meetings today and the next week. The next meeting will be held on Jan 8th 2019. Good wishes for X-mas & new year. Enjoy holidays. Thanks & Regards Dharmendra Kushwaha -------------- next part -------------- An HTML attachment was scrubbed... URL: From feli5 at cisco.com Tue Dec 25 09:06:15 2018 From: feli5 at cisco.com (Leehom Li (feli5)) Date: Tue, 25 Dec 2018 09:06:15 +0000 Subject: =?utf-8?B?W29wZW5zdGFjay1kaXNjdXNzXVtHbGFuY2VdQlAgdG8gdHJhY2UgY2hhbmdl?= =?utf-8?B?IHRvIHN0b3JlIGNvbnRleHQgaW4gcmVxdWVzdC5lbnZpcm9uW+KAmGdsYW5j?= =?utf-8?B?ZS5jb250ZXh04oCZXQ==?= Message-ID: <32AF056F-A448-4372-AF89-AE7EA0FD5CF0@cisco.com> Hi, I encountered an error when enable audit for glance. And a bug is fired to fix the conflict in keystone middleware project. https://bugs.launchpad.net/keystonemiddleware/+bug/1809101 Brief about the bug is both keystone audit middleware and glance are using req.context. They are conflict with each other. I upload a patch to fix this issue for keystone audit middleware. But I think it would be nice to have glance consist with other OpenStack component like nova to store context in request.environ[‘glance.context’]. I checked the code of glance, use of req.context spread cross entire API level code, so I think it would be better to have a BP to trace about the change. Needs your kind advice. Best regards, Leehom Li feli5 at cisco.com Phone: +86 512 8777 4186 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jazeltq at gmail.com Tue Dec 25 09:26:54 2018 From: jazeltq at gmail.com (Jaze Lee) Date: Tue, 25 Dec 2018 17:26:54 +0800 Subject: =?UTF-8?Q?Fwd=3A_=5Bcinder=5D_Is_the_cinder_Active=2DActive_feature_OK?= =?UTF-8?Q?=EF=BC=9F?= In-Reply-To: References: Message-ID: Hello, In my opinion, all rest api will get to manager of cinder volume. If the manager is using DLM, we can say cinder volume can support active-active. So, can we rewrite the comments and option's help in page https://github.com/openstack/cinder/blob/master/cinder/cmd/volume.py#L78 ? Thanks a lot. -- 谦谦君子 From renat.akhmerov at gmail.com Tue Dec 25 09:39:02 2018 From: renat.akhmerov at gmail.com (Renat Akhmerov) Date: Tue, 25 Dec 2018 16:39:02 +0700 Subject: [mistral] =?utf-8?Q?Let=E2=80=99s_?=meet in IRC after Jan 8 Message-ID: <4f565a46-2386-43da-99eb-52888446cddb@Spark> Hi, I guess there won’t be many working people till Jan 9 (Christmas & NY holidays) so I’m hereby calling Mistral contributors to meet after the holidays and discuss the project course and priorities for the next few months. We can do it during one of our allocated office hours slots. Will decide later when exactly. Thanks Renat Akhmerov @Nokia -------------- next part -------------- An HTML attachment was scrubbed... URL: From jazeltq at gmail.com Tue Dec 25 08:46:03 2018 From: jazeltq at gmail.com (Jaze Lee) Date: Tue, 25 Dec 2018 16:46:03 +0800 Subject: =?UTF-8?Q?=5Bcinder=5D_Is_the_cinder_Active=2DActive_feature_OK=EF=BC=9F?= Message-ID: Hello, In my opinion, all rest api will get to manager of cinder volume. If the manager is using DLM, we can say cinder volume can support active-active. So, can we rewrite the comments and option's help in page https://github.com/openstack/cinder/blob/master/cinder/cmd/volume.py#L78 ? Thanks a lot. -- 谦谦君子 From ifatafekn at gmail.com Tue Dec 25 17:47:04 2018 From: ifatafekn at gmail.com (Ifat Afek) Date: Tue, 25 Dec 2018 19:47:04 +0200 Subject: [self-healing-sig][vitrage][monasca] Vitrage and Monasca integration Message-ID: Hi, In the last self-healing SIG meeting, we discussed the integration of Monasca and Vitrage [1]. We talked about the challenge of identifying the resource in Vitrage based on Monasca metric dimensions. As we discussed [2], I wrote an initial spec for mapping the different use cases [3]. I’ll be happy to get your feedback - at this stage our main interest is to collect more use cases and concrete examples. Thanks, Ifat [1] https://review.openstack.org/#/c/622899/ [2] http://eavesdrop.openstack.org/meetings/self_healing/2018/self_healing.2018-12-19-09.02.log.html [3] https://review.openstack.org/#/c/627180 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ifatafekn at gmail.com Tue Dec 25 17:48:25 2018 From: ifatafekn at gmail.com (Ifat Afek) Date: Tue, 25 Dec 2018 19:48:25 +0200 Subject: [vitrage] No IRC meeting tomorrow Message-ID: Hi, We will skip the IRC meeting this week. We will meet again next Wednesday, January 2nd. Thanks, Ifat -------------- next part -------------- An HTML attachment was scrubbed... URL: From gagehugo at gmail.com Tue Dec 25 21:21:50 2018 From: gagehugo at gmail.com (Gage Hugo) Date: Tue, 25 Dec 2018 15:21:50 -0600 Subject: [security] No meeting Dec 27th & Jan 3rd Message-ID: The Security SIG meetings for this week and next week are canceled. We will meet again on Jan 10th. Enjoy the holidays! -------------- next part -------------- An HTML attachment was scrubbed... URL: From akekane at redhat.com Wed Dec 26 03:50:59 2018 From: akekane at redhat.com (Abhishek Kekane) Date: Wed, 26 Dec 2018 09:20:59 +0530 Subject: =?UTF-8?Q?Re=3A_=5Bopenstack=2Ddiscuss=5D=5BGlance=5DBP_to_trace_change_to?= =?UTF-8?Q?_store_context_in_request=2Eenviron=5B=E2=80=98glance=2Econtext=E2=80=99=5D?= In-Reply-To: <32AF056F-A448-4372-AF89-AE7EA0FD5CF0@cisco.com> References: <32AF056F-A448-4372-AF89-AE7EA0FD5CF0@cisco.com> Message-ID: Hi Leehom, IMO you should go ahead create a blueprint and submit a lite-specs in glance which will help other reviewers to understand your proposal. Thanks & Best Regards, Abhishek Kekane On Tue, Dec 25, 2018 at 2:42 PM Leehom Li (feli5) wrote: > Hi, > > > > I encountered an error when enable audit for glance. > > And a bug is fired to fix the conflict in keystone middleware project. > > https://bugs.launchpad.net/keystonemiddleware/+bug/1809101 > > > > Brief about the bug is both keystone audit middleware and glance are using > req.context. > > They are conflict with each other. > > > > I upload a patch to fix this issue for keystone audit middleware. > > > > But I think it would be nice to have glance consist with other OpenStack > component like nova to store context in request.environ[‘glance.context’]. > > I checked the code of glance, use of req.context spread cross entire API > level code, so I think it would be better to have a BP to trace about the > change. > > > > Needs your kind advice. > > > > > > Best regards, > > Leehom Li > > > > feli5 at cisco.com > Phone: *+86 512 8777 4186* > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From e0ne at e0ne.info Wed Dec 26 07:53:55 2018 From: e0ne at e0ne.info (Ivan Kolodyazhny) Date: Wed, 26 Dec 2018 09:53:55 +0200 Subject: [dev] [horizon] No meetings until January, 9th Message-ID: Hi all, We agreed to skip the next two meetings due to the Christmas and New Year holidays at the last meeting [1]. Enjoy the holidays! [1] http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-12-19-15.00.html Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabarren at gmail.com Wed Dec 26 10:50:29 2018 From: dabarren at gmail.com (Eduardo Gonzalez) Date: Wed, 26 Dec 2018 11:50:29 +0100 Subject: [kolla] Today and next week meeting cancelled Message-ID: Dear Kolla Team, Because Christmas holidays many people could not attend the Kolla weekly meeting, we will cancel today (26th December) and next meeting (2nd January). We will resume the weekly meetings on 9th January. Have a nice Christmas Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangtrinhnt at gmail.com Wed Dec 26 11:07:39 2018 From: dangtrinhnt at gmail.com (Trinh Nguyen) Date: Wed, 26 Dec 2018 20:07:39 +0900 Subject: [Searchlight] Next meeting cancelled Message-ID: Hi team, Next week I'm on vacation so we will have to cancel the meeting on 31st December. See you next year :) P/S: I'll be at the VietOpenInfra meetup in Ho Chi Minh city this Saturday :) -- *Trinh Nguyen* *www.edlab.xyz * -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufar at onf-ambassador.org Wed Dec 26 18:06:42 2018 From: zufar at onf-ambassador.org (Zufar Dhiyaulhaq) Date: Thu, 27 Dec 2018 01:06:42 +0700 Subject: [magnum][octavia] Error provisioning multi master cluster with magnum. Message-ID: Hello, I am success create a single master cluster (docker or kubernetes) using magnum. but always fail when creating magnum. all the log is point into Octavia error. I have tested the Octavia and its working. this is error I get from the stack debug. OctaviaClientException: resources.etcd_lb.resources.loadbalancer: Validation failure: Missing project ID in request where one is required. (HTTP 400) the full log : *[root at controller3 ~]# openstack stack resource list kubernetes-cluster-multi-maste-txdrmrikn3a4+-----------------------------+--------------------------------------+--------------------------------------------------------------------------------------+-----------------+----------------------+| resource_name | physical_resource_id | resource_type | resource_status | updated_time |+-----------------------------+--------------------------------------+--------------------------------------------------------------------------------------+-----------------+----------------------+| etcd_lb | 7aa39847-3602-4673-973e-26fc12974bb9 | file:///usr/lib/python2.7/site-packages/magnum/drivers/common/templates/lb.yaml | CREATE_FAILED | 2018-12-22T20:17:00Z || kube_masters | | OS::Heat::ResourceGroup | INIT_COMPLETE | 2018-12-22T20:17:00Z || network | e8eb37ec-bde3-4f26-b337-7c5fad937212 | file:///usr/lib/python2.7/site-packages/magnum/drivers/common/templates/network.yaml | CREATE_COMPLETE | 2018-12-22T20:17:00Z || api_lb | bc59c786-9126-4d97-9edc-ee2127acc8e3 | file:///usr/lib/python2.7/site-packages/magnum/drivers/common/templates/lb.yaml | CREATE_FAILED | 2018-12-22T20:17:00Z || secgroup_kube_minion | 72278f6b-039d-402a-b4df-77d5c8c64a0b | OS::Neutron::SecurityGroup | CREATE_COMPLETE | 2018-12-22T20:17:00Z || nodes_server_group | 1cf676b0-d09c-44a7-8f4f-7c6e7363390e | OS::Nova::ServerGroup | CREATE_COMPLETE | 2018-12-22T20:17:00Z || secgroup_kube_master | 1e96573d-0972-4f05-8876-6bbb83246cb8 | OS::Neutron::SecurityGroup | CREATE_COMPLETE | 2018-12-22T20:17:00Z || kube_minions | | OS::Heat::ResourceGroup | INIT_COMPLETE | 2018-12-22T20:17:00Z || api_address_floating_switch | | Magnum::FloatingIPAddressSwitcher | INIT_COMPLETE | 2018-12-22T20:17:00Z || api_address_lb_switch | | Magnum::ApiGatewaySwitcher | INIT_COMPLETE | 2018-12-22T20:17:00Z || etcd_address_lb_switch | | Magnum::ApiGatewaySwitcher | INIT_COMPLETE | 2018-12-22T20:17:00Z |+-----------------------------+--------------------------------------+--------------------------------------------------------------------------------------+-----------------+----------------------+[root at controller3 ~]# openstack stack resource show kubernetes-cluster-multi-maste-txdrmrikn3a4 etcd_lb| resource_status_reason | OctaviaClientException: resources.etcd_lb.resources.loadbalancer: Validation failure: Missing project ID in request where one is required. (HTTP 400) (Request-ID: req-4bd9b688-8309-4a51-b6c7-4a617b49fa45) |[root at controller3 ~]# openstack stack resource show kubernetes-cluster-multi-maste-txdrmrikn3a4 api_lb | resource_status_reason | OctaviaClientException: resources.api_lb.resources.loadbalancer: Validation failure: Missing project ID in request where one is required. (HTTP 400) (Request-ID: req-d3bd4431-4b77-45de-b0ce-44b0e3e97618) |* anyone know what is happen? Best Regards, Zufar Dhiyaulhaq -------------- next part -------------- An HTML attachment was scrubbed... URL: From eumel at arcor.de Wed Dec 26 19:04:21 2018 From: eumel at arcor.de (Frank Kloeker) Date: Wed, 26 Dec 2018 20:04:21 +0100 Subject: [I18n] No team meeting Message-ID: Hello, due the vacation period the I18n team will also skip the next team meetings. Our next appointment will be 2019/01/10 07:00 UTC in #openstack-meeting. Enjoy the time and a Happy New Year! Frank From miguel at mlavalle.com Wed Dec 26 21:27:13 2018 From: miguel at mlavalle.com (Miguel Lavalle) Date: Wed, 26 Dec 2018 15:27:13 -0600 Subject: [openstack-dev] [Neutron] Propose Ryan Tidwell for neutron-dynamic-routing core In-Reply-To: References: Message-ID: Hi Stackers, It has been more than a week since I sent this nomination and I have only received positive feedback. As a consequence, I just added Ryan as core reviewer for neutron-dynamic-routing. Welcome to the team Ryan and keep up the great work! Best regards Miguel On Wed, Dec 19, 2018 at 12:40 PM Miguel Lavalle wrote: > Hi Stackers, > > I want to nominate Ryan Tidwell (irc: tidwellr) as a core reviewer for > neutron-dynamic-routing ( > https://github.com/openstack/neutron-dynamic-routing). Ryan has a long > history with everything L3 in Neutron. He started contributing code back in > 2014, helping to implement subnet pools ( > https://review.openstack.org/#/c/148698/). Over the years he did great > work improving Neutron's IP address manager and was the driving force in > the creation and implementation of the neutron-dynamic-routing project. > After a hiatus of a few cycles, Ryan came back to the community and has > been very active adding support for MP-BGP in neutron-dynamic-routing and > the on boarding of subnets in Neutron. The quality and number of his code > reviews during the Stein cycle are on par with members of the Neutron core > team: http://stackalytics.com/?module=neutron-group. > > I will keep this nomination open as customary. > > Thank you. > > Miguel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tenobreg at redhat.com Thu Dec 27 12:08:05 2018 From: tenobreg at redhat.com (Telles Nobrega) Date: Thu, 27 Dec 2018 09:08:05 -0300 Subject: [openstack-dev][sahara] No meeting today Message-ID: Hi Saharans, We won't be having meeting today, we get back next week. Thanks all, -- TELLES NOBREGA SOFTWARE ENGINEER Red Hat Brasil Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo tenobreg at redhat.com TRIED. TESTED. TRUSTED. Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil pelo Great Place to Work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfredo.deluca at gmail.com Thu Dec 27 22:25:44 2018 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Fri, 28 Dec 2018 09:25:44 +1100 Subject: openstack stack fails In-Reply-To: References: Message-ID: Hi Ignazio. I tried to spin up a stack but I got an error... Authorization failed. Not sure why. I am a bit stuck On Sun., 23 Dec. 2018, 9:19 pm Alfredo De Luca I ll try asap. Thanks > > On Sat., 22 Dec. 2018, 10:50 pm Ignazio Cassano wrote: > >> Hi Alfredo, have you tried a simple heat template to verify if heat is >> working fine? >> Ignazio >> >> >> >> Il giorno Sab 22 Dic 2018 20:51 Alfredo De Luca >> ha scritto: >> >>> HI IGNAZIO >>> The problem is that doesn't go that far... It fails before even creating >>> the master. >>> >>> On Sat., 22 Dec. 2018, 6:06 pm Ignazio Cassano >> wrote: >>> >>>> Anycase during deployment you can connect with ssh to the master and >>>> tail the /var/log/ cloud in it output for checking. >>>> Ignazio >>>> >>>> Il giorno Sab 22 Dic 2018 17:18 Alfredo De Luca < >>>> alfredo.deluca at gmail.com> ha scritto: >>>> >>>>> Ciao Ignazio >>>>> What do you mean with master? you mean k8s master? >>>>> I guess everything is fine... but I'll double check. >>>>> >>>>> Cheers >>>>> >>>>> >>>>> On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano < >>>>> ignaziocassano at gmail.com> wrote: >>>>> >>>>>> Hi Alfredo, I am working on queens and I am not sure my answer could >>>>>> help you.... >>>>>> Can your master speak with kyestone public endpoint port (5000) ? >>>>>> Ignazio >>>>>> >>>>>> Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca < >>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>> >>>>>>> Hi all. >>>>>>> I installed magnum on openstack and now, after a few issue with >>>>>>> cinder type list error, it passed that issue but now I have another one.... >>>>>>> >>>>>>> >>>>>>> >>>>>>> AuthorizationFailure: >>>>>>> resources.kube_masters.resources[0].resources.master_wait_handle: >>>>>>> Authorization failed. >>>>>>> Not sure what to do nor check >>>>>>> Any clue? >>>>>>> Cheers >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Alfredo* >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> *Alfredo* >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bathanhtlu at gmail.com Fri Dec 28 02:22:38 2018 From: bathanhtlu at gmail.com (=?UTF-8?B?VGjDoG5oIE5ndXnhu4VuIELDoQ==?=) Date: Fri, 28 Dec 2018 09:22:38 +0700 Subject: [oslo] Problem when use library "oslo.messaging" for HA Openstack Message-ID: Dear all, I have a problem when use 'notification listener' oslo-message for HA Openstack. It raise 'oslo_messaging.exceptions.MessageDeliveryFailure: Unable to connect to AMQP server on 172.16.4.125:5672 after inf tries: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'nova' in vhost '/': received 'false' but current is 'true''. How can i fix this?. I think settings default in my program set 'durable' is False so it can't listen RabbitMQ Openstack? This is my nova.conf > http://paste.openstack.org/show/738813/ And section [oslo_messaging_rabbit] [oslo_messaging_rabbit] > rabbit_ha_queues = true > rabbit_retry_interval = 1 > rabbit_retry_backoff = 2 > amqp_durable_queues= true *Nguyễn Bá Thành* *Mobile*: 0128 748 0391 *Email*: bathanhtlu at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From liliueecg at gmail.com Fri Dec 28 05:31:51 2018 From: liliueecg at gmail.com (Li Liu) Date: Fri, 28 Dec 2018 00:31:51 -0500 Subject: [Cyborg] Nominating Yumeng Bao for Cyborg Core Reviewer Message-ID: Hi Team, Yumeng Bao has high-quality reviews in the last couple of cycles so I would like to nominate her for Cyborg core Please respond with your +1 or -1 votes. We'll hold voting open for 7 days -- Thank you Regards Li -------------- next part -------------- An HTML attachment was scrubbed... URL: From singh.surya64mnnit at gmail.com Fri Dec 28 05:34:41 2018 From: singh.surya64mnnit at gmail.com (Surya Singh) Date: Fri, 28 Dec 2018 11:04:41 +0530 Subject: Review-Priority for Project Repos Message-ID: Dear All, There are many occasion when we want to priorities some of the patches whether it is related to unblock the gates or blocking the non freeze patches during RC. So adding the Review-Priority will allow more precise dashboard. As Designate and Cinder projects already experiencing this[1][2] and after discussion with Jeremy brought this to ML to interact with these team before landing [3], as there is possibility that reapply the priority vote following any substantive updates to change could make it more cumbersome than it is worth. Teams please share your experience of using Review-Priority. [1] https://review.openstack.org/#/c/295253/ [2] https://review.openstack.org/#/c/620664/ [3] https://review.openstack.org/#/c/626824/ --- Best Regards Surya -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfredo.deluca at gmail.com Fri Dec 28 06:48:09 2018 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Fri, 28 Dec 2018 07:48:09 +0100 Subject: openstack stack fails In-Reply-To: References: Message-ID: I still get the same error..... Resource CREATE failed: AuthorizationFailure: resources.kube_masters.resources[0].resources.master_wait_handle: Authorization failed. Also if I create a basic stack I got authorization failed. Not sure where to look at ln the logs I can see the following error 2018-12-28 05:59:40.725 91 ERROR heat.engine.clients.keystoneclient [req-1c937165-0eca-4d1e-9072-d6d74983ee63 - admin - default default] Domain admin client authentication failed: Unauthorized: The request you have made requires authentication. (HTTP 401) (Request-ID: req-ac27e679-5b32-4e1c-a27e-ab59c5a4cff4) Cheers On Thu, Dec 27, 2018 at 11:25 PM Alfredo De Luca wrote: > Hi Ignazio. I tried to spin up a stack but I got an error... Authorization > failed. Not sure why. I am a bit stuck > > On Sun., 23 Dec. 2018, 9:19 pm Alfredo De Luca wrote: > >> I ll try asap. Thanks >> >> On Sat., 22 Dec. 2018, 10:50 pm Ignazio Cassano > wrote: >> >>> Hi Alfredo, have you tried a simple heat template to verify if heat is >>> working fine? >>> Ignazio >>> >>> >>> >>> Il giorno Sab 22 Dic 2018 20:51 Alfredo De Luca < >>> alfredo.deluca at gmail.com> ha scritto: >>> >>>> HI IGNAZIO >>>> The problem is that doesn't go that far... It fails before even >>>> creating the master. >>>> >>>> On Sat., 22 Dec. 2018, 6:06 pm Ignazio Cassano < >>>> ignaziocassano at gmail.com wrote: >>>> >>>>> Anycase during deployment you can connect with ssh to the master and >>>>> tail the /var/log/ cloud in it output for checking. >>>>> Ignazio >>>>> >>>>> Il giorno Sab 22 Dic 2018 17:18 Alfredo De Luca < >>>>> alfredo.deluca at gmail.com> ha scritto: >>>>> >>>>>> Ciao Ignazio >>>>>> What do you mean with master? you mean k8s master? >>>>>> I guess everything is fine... but I'll double check. >>>>>> >>>>>> Cheers >>>>>> >>>>>> >>>>>> On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano < >>>>>> ignaziocassano at gmail.com> wrote: >>>>>> >>>>>>> Hi Alfredo, I am working on queens and I am not sure my answer could >>>>>>> help you.... >>>>>>> Can your master speak with kyestone public endpoint port (5000) ? >>>>>>> Ignazio >>>>>>> >>>>>>> Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca < >>>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>>> >>>>>>>> Hi all. >>>>>>>> I installed magnum on openstack and now, after a few issue with >>>>>>>> cinder type list error, it passed that issue but now I have another one.... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> AuthorizationFailure: >>>>>>>> resources.kube_masters.resources[0].resources.master_wait_handle: >>>>>>>> Authorization failed. >>>>>>>> Not sure what to do nor check >>>>>>>> Any clue? >>>>>>>> Cheers >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Alfredo* >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> *Alfredo* >>>>>> >>>>>> -- *Alfredo* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Fri Dec 28 07:48:16 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Fri, 28 Dec 2018 08:48:16 +0100 Subject: openstack stack fails In-Reply-To: References: Message-ID: Hi Alfredo, what is reported in your /var/log/heat/heat-engine.log ? Ignazio Il giorno Gio 27 Dic 2018 23:25 Alfredo De Luca ha scritto: > Hi Ignazio. I tried to spin up a stack but I got an error... Authorization > failed. Not sure why. I am a bit stuck > > On Sun., 23 Dec. 2018, 9:19 pm Alfredo De Luca wrote: > >> I ll try asap. Thanks >> >> On Sat., 22 Dec. 2018, 10:50 pm Ignazio Cassano > wrote: >> >>> Hi Alfredo, have you tried a simple heat template to verify if heat is >>> working fine? >>> Ignazio >>> >>> >>> >>> Il giorno Sab 22 Dic 2018 20:51 Alfredo De Luca < >>> alfredo.deluca at gmail.com> ha scritto: >>> >>>> HI IGNAZIO >>>> The problem is that doesn't go that far... It fails before even >>>> creating the master. >>>> >>>> On Sat., 22 Dec. 2018, 6:06 pm Ignazio Cassano < >>>> ignaziocassano at gmail.com wrote: >>>> >>>>> Anycase during deployment you can connect with ssh to the master and >>>>> tail the /var/log/ cloud in it output for checking. >>>>> Ignazio >>>>> >>>>> Il giorno Sab 22 Dic 2018 17:18 Alfredo De Luca < >>>>> alfredo.deluca at gmail.com> ha scritto: >>>>> >>>>>> Ciao Ignazio >>>>>> What do you mean with master? you mean k8s master? >>>>>> I guess everything is fine... but I'll double check. >>>>>> >>>>>> Cheers >>>>>> >>>>>> >>>>>> On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano < >>>>>> ignaziocassano at gmail.com> wrote: >>>>>> >>>>>>> Hi Alfredo, I am working on queens and I am not sure my answer could >>>>>>> help you.... >>>>>>> Can your master speak with kyestone public endpoint port (5000) ? >>>>>>> Ignazio >>>>>>> >>>>>>> Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca < >>>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>>> >>>>>>>> Hi all. >>>>>>>> I installed magnum on openstack and now, after a few issue with >>>>>>>> cinder type list error, it passed that issue but now I have another one.... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> AuthorizationFailure: >>>>>>>> resources.kube_masters.resources[0].resources.master_wait_handle: >>>>>>>> Authorization failed. >>>>>>>> Not sure what to do nor check >>>>>>>> Any clue? >>>>>>>> Cheers >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Alfredo* >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> *Alfredo* >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Fri Dec 28 07:57:04 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Fri, 28 Dec 2018 08:57:04 +0100 Subject: openstack stack fails In-Reply-To: References: Message-ID: Check heat user and domani are c onfigured like at the following: https://docs.openstack.org/heat/rocky/install/install-rdo.html Il giorno Gio 27 Dic 2018 23:25 Alfredo De Luca ha scritto: > Hi Ignazio. I tried to spin up a stack but I got an error... Authorization > failed. Not sure why. I am a bit stuck > > On Sun., 23 Dec. 2018, 9:19 pm Alfredo De Luca wrote: > >> I ll try asap. Thanks >> >> On Sat., 22 Dec. 2018, 10:50 pm Ignazio Cassano > wrote: >> >>> Hi Alfredo, have you tried a simple heat template to verify if heat is >>> working fine? >>> Ignazio >>> >>> >>> >>> Il giorno Sab 22 Dic 2018 20:51 Alfredo De Luca < >>> alfredo.deluca at gmail.com> ha scritto: >>> >>>> HI IGNAZIO >>>> The problem is that doesn't go that far... It fails before even >>>> creating the master. >>>> >>>> On Sat., 22 Dec. 2018, 6:06 pm Ignazio Cassano < >>>> ignaziocassano at gmail.com wrote: >>>> >>>>> Anycase during deployment you can connect with ssh to the master and >>>>> tail the /var/log/ cloud in it output for checking. >>>>> Ignazio >>>>> >>>>> Il giorno Sab 22 Dic 2018 17:18 Alfredo De Luca < >>>>> alfredo.deluca at gmail.com> ha scritto: >>>>> >>>>>> Ciao Ignazio >>>>>> What do you mean with master? you mean k8s master? >>>>>> I guess everything is fine... but I'll double check. >>>>>> >>>>>> Cheers >>>>>> >>>>>> >>>>>> On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano < >>>>>> ignaziocassano at gmail.com> wrote: >>>>>> >>>>>>> Hi Alfredo, I am working on queens and I am not sure my answer could >>>>>>> help you.... >>>>>>> Can your master speak with kyestone public endpoint port (5000) ? >>>>>>> Ignazio >>>>>>> >>>>>>> Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca < >>>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>>> >>>>>>>> Hi all. >>>>>>>> I installed magnum on openstack and now, after a few issue with >>>>>>>> cinder type list error, it passed that issue but now I have another one.... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> AuthorizationFailure: >>>>>>>> resources.kube_masters.resources[0].resources.master_wait_handle: >>>>>>>> Authorization failed. >>>>>>>> Not sure what to do nor check >>>>>>>> Any clue? >>>>>>>> Cheers >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Alfredo* >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> *Alfredo* >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfredo.deluca at gmail.com Fri Dec 28 08:06:44 2018 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Fri, 28 Dec 2018 09:06:44 +0100 Subject: openstack stack fails In-Reply-To: References: Message-ID: Hi Ignazio. The engine log doesn 't say anything...except 2018-12-17 11:51:35.284 4064 INFO oslo_service.service [-] Child 4202 killed by signal 15 which is last log from a few days ago. While the journal of the heat engine says Dec 28 06:36:29 aio1-heat-api-container-16f41ed7 systemd[1]: Started heat-engine service. Dec 28 06:36:31 aio1-heat-api-container-16f41ed7 heat-engine[91]: /openstack/venvs/heat-19.0.0.0b1/lib/python2.7/site-packages/sqlalchemy/sql/sqltypes.py:226: SAWarning: Unicode type received non-unicode bind param value 'data-processing-cluster'. (this warning may be suppressed after 10 occurrences) Dec 28 06:36:31 aio1-heat-api-container-16f41ed7 heat-engine[91]: (util.ellipses_string(value),)) I also checked the configuration and it seems to be ok. the problem is that I installed openstack with ansible-openstack.... so I can't change anything unless I re run everything. On Fri, Dec 28, 2018 at 8:57 AM Ignazio Cassano wrote: > Check heat user and domani are c onfigured like at the following: > https://docs.openstack.org/heat/rocky/install/install-rdo.html > > Il giorno Gio 27 Dic 2018 23:25 Alfredo De Luca > ha scritto: > >> Hi Ignazio. I tried to spin up a stack but I got an error... >> Authorization failed. Not sure why. I am a bit stuck >> >> On Sun., 23 Dec. 2018, 9:19 pm Alfredo De Luca > wrote: >> >>> I ll try asap. Thanks >>> >>> On Sat., 22 Dec. 2018, 10:50 pm Ignazio Cassano < >>> ignaziocassano at gmail.com wrote: >>> >>>> Hi Alfredo, have you tried a simple heat template to verify if heat is >>>> working fine? >>>> Ignazio >>>> >>>> >>>> >>>> Il giorno Sab 22 Dic 2018 20:51 Alfredo De Luca < >>>> alfredo.deluca at gmail.com> ha scritto: >>>> >>>>> HI IGNAZIO >>>>> The problem is that doesn't go that far... It fails before even >>>>> creating the master. >>>>> >>>>> On Sat., 22 Dec. 2018, 6:06 pm Ignazio Cassano < >>>>> ignaziocassano at gmail.com wrote: >>>>> >>>>>> Anycase during deployment you can connect with ssh to the master and >>>>>> tail the /var/log/ cloud in it output for checking. >>>>>> Ignazio >>>>>> >>>>>> Il giorno Sab 22 Dic 2018 17:18 Alfredo De Luca < >>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>> >>>>>>> Ciao Ignazio >>>>>>> What do you mean with master? you mean k8s master? >>>>>>> I guess everything is fine... but I'll double check. >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> >>>>>>> On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano < >>>>>>> ignaziocassano at gmail.com> wrote: >>>>>>> >>>>>>>> Hi Alfredo, I am working on queens and I am not sure my answer >>>>>>>> could help you.... >>>>>>>> Can your master speak with kyestone public endpoint port (5000) ? >>>>>>>> Ignazio >>>>>>>> >>>>>>>> Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca < >>>>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>>>> >>>>>>>>> Hi all. >>>>>>>>> I installed magnum on openstack and now, after a few issue with >>>>>>>>> cinder type list error, it passed that issue but now I have another one.... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> AuthorizationFailure: >>>>>>>>> resources.kube_masters.resources[0].resources.master_wait_handle: >>>>>>>>> Authorization failed. >>>>>>>>> Not sure what to do nor check >>>>>>>>> Any clue? >>>>>>>>> Cheers >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Alfredo* >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Alfredo* >>>>>>> >>>>>>> -- *Alfredo* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Fri Dec 28 08:39:39 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Fri, 28 Dec 2018 09:39:39 +0100 Subject: openstack stack fails In-Reply-To: References: Message-ID: Alfredo, 1 . how did you run the last heat template? By dashboard ? 2. Using openstack command you can check if ansible configured heat user/domain correctly It seems a problem related to heat user rights? Il giorno Ven 28 Dic 2018 09:06 Alfredo De Luca ha scritto: > Hi Ignazio. The engine log doesn 't say anything...except > 2018-12-17 11:51:35.284 4064 INFO oslo_service.service [-] Child 4202 > killed by signal 15 > which is last log from a few days ago. > > While the journal of the heat engine says > Dec 28 06:36:29 aio1-heat-api-container-16f41ed7 systemd[1]: Started > heat-engine service. > Dec 28 06:36:31 aio1-heat-api-container-16f41ed7 heat-engine[91]: > /openstack/venvs/heat-19.0.0.0b1/lib/python2.7/site-packages/sqlalchemy/sql/sqltypes.py:226: > SAWarning: Unicode type received non-unicode bind param value > 'data-processing-cluster'. (this warning may be suppressed after 10 > occurrences) > Dec 28 06:36:31 aio1-heat-api-container-16f41ed7 heat-engine[91]: > (util.ellipses_string(value),)) > > > I also checked the configuration and it seems to be ok. the problem is > that I installed openstack with ansible-openstack.... so I can't change > anything unless I re run everything. > > > > > > On Fri, Dec 28, 2018 at 8:57 AM Ignazio Cassano > wrote: > >> Check heat user and domani are c onfigured like at the following: >> https://docs.openstack.org/heat/rocky/install/install-rdo.html >> >> Il giorno Gio 27 Dic 2018 23:25 Alfredo De Luca >> ha scritto: >> >>> Hi Ignazio. I tried to spin up a stack but I got an error... >>> Authorization failed. Not sure why. I am a bit stuck >>> >>> On Sun., 23 Dec. 2018, 9:19 pm Alfredo De Luca >> wrote: >>> >>>> I ll try asap. Thanks >>>> >>>> On Sat., 22 Dec. 2018, 10:50 pm Ignazio Cassano < >>>> ignaziocassano at gmail.com wrote: >>>> >>>>> Hi Alfredo, have you tried a simple heat template to verify if heat is >>>>> working fine? >>>>> Ignazio >>>>> >>>>> >>>>> >>>>> Il giorno Sab 22 Dic 2018 20:51 Alfredo De Luca < >>>>> alfredo.deluca at gmail.com> ha scritto: >>>>> >>>>>> HI IGNAZIO >>>>>> The problem is that doesn't go that far... It fails before even >>>>>> creating the master. >>>>>> >>>>>> On Sat., 22 Dec. 2018, 6:06 pm Ignazio Cassano < >>>>>> ignaziocassano at gmail.com wrote: >>>>>> >>>>>>> Anycase during deployment you can connect with ssh to the master and >>>>>>> tail the /var/log/ cloud in it output for checking. >>>>>>> Ignazio >>>>>>> >>>>>>> Il giorno Sab 22 Dic 2018 17:18 Alfredo De Luca < >>>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>>> >>>>>>>> Ciao Ignazio >>>>>>>> What do you mean with master? you mean k8s master? >>>>>>>> I guess everything is fine... but I'll double check. >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano < >>>>>>>> ignaziocassano at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi Alfredo, I am working on queens and I am not sure my answer >>>>>>>>> could help you.... >>>>>>>>> Can your master speak with kyestone public endpoint port (5000) ? >>>>>>>>> Ignazio >>>>>>>>> >>>>>>>>> Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca < >>>>>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>>>>> >>>>>>>>>> Hi all. >>>>>>>>>> I installed magnum on openstack and now, after a few issue with >>>>>>>>>> cinder type list error, it passed that issue but now I have another one.... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> AuthorizationFailure: >>>>>>>>>> resources.kube_masters.resources[0].resources.master_wait_handle: >>>>>>>>>> Authorization failed. >>>>>>>>>> Not sure what to do nor check >>>>>>>>>> Any clue? >>>>>>>>>> Cheers >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Alfredo* >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Alfredo* >>>>>>>> >>>>>>>> > > -- > *Alfredo* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhipengh512 at gmail.com Fri Dec 28 09:35:11 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Fri, 28 Dec 2018 17:35:11 +0800 Subject: [Cyborg] Nominating Coco Gao for Cyborg Core Reviewer Message-ID: Hi folks, Coco has been participating in Cyborg project from Rocky design discussion and has been driving the DB refactoring work ever since. I would like to nominate her as a new core reviewer of the team to recognize her contribution as well as increase the bandwidth of cyborg core team. If you have any concerns by replying to this email thread within a week. Thank you very much ! -- Zhipeng (Howard) Huang Principle Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at ericsson.com Fri Dec 28 10:13:37 2018 From: balazs.gibizer at ericsson.com (=?iso-8859-1?Q?Bal=E1zs_Gibizer?=) Date: Fri, 28 Dec 2018 10:13:37 +0000 Subject: [nova] review guide for the bandwidth patches In-Reply-To: References: <1545231821.28650.2@smtp.office365.com> <1545316423.10879.3@smtp.office365.com> Message-ID: <1545992000.14055.0@smtp.office365.com> On Thu, Dec 20, 2018 at 7:14 PM, Matt Riedemann wrote: > On 12/20/2018 8:47 AM, Jay Pipes wrote: >> >> The problem with feature flags is they are not discoverable. As much >> as I hate API extensions, at least they are discoverable. > > 100% agree. Config-driven API behavior like this flies in the face of > any kind of hope for interoperability of this feature. Can I do this > on cloud X? Maybe? Can I do it on cloud Y? Let's find out! At the > very least, I would think if you're going to add a config option to > enable/disable this support in the compute API, at least temporarily, > you would fail any requests which include ports with QoS resource > requests because we're not going to honor them. That aligns more with > what I was saying about how I thought the "reject" patches would come > earlier in the series since we're currently not supporting this > feature, and lying to users by allowing them to attach these kinds of > ports. Although I might be conflating QoS ports in general and QoS > ports that have the bandwidth resource request things on them. > > > During the spec review, we waffled a bit on whether or not this > should have a new microversion with it [1][2]. The way this works > definitely sounds like how volume multiattach is setup - you create a > resource in another service with a special characteristic and then > try to attach that thing to a server. Nova can either support that > thing or not, and the only way for a user to find that out without a > microversion is to try it and find out (does it fail? if it doesn't > fail, is the thing working in my guest? if not, is it because it's > not supported or because something failed or there is a bug?). With > volume multiattach we added a microversion so that users could know > if they can even make the request to attach those types of volumes so > they didn't have to guess. So I could argue that QoS ports like this > should get similar treatment, but things get fuzzy when it's implicit > behavior on some external resource >> >> Is there a reason why we can't just put code into Nova that, upon >> seeing the resource requests, acts on it? Is there a reason it >> needs to be behind a feature flag or even needs to query Neutron >> for extension support? I mean, if it's in the response payload, >> just use it, right? > > The main reason is how the code is written backward, as I've said > elsewhere in this thread. If everything was properly plumbed in from > the bottom up for at least creating servers with these kinds of ports > (and cleaning them up properly), then it's just a matter of doing > like you said - take action on the thing if it's there. Like [3] I > think we could explicitly fail for things that are not supported > until they do become supported, like any move operations. Whether > those are considered bug fixes or new features (a la microversions) > is debatable. It sucks adding stuff that works when creating a server > but isn't supported when you perform actions on that server, and it > sucks holding up features before everything is ready, and it sucks to > need microversions for every little thing that ideally would have > just be done up front, so I can't really say here on what we should > do. I know in the golden days before microversions it was totally > kosher to just feature flag our way to nirvana and we're still > dealing with a lot of that fallout (like the fact that live migration > with NUMA-affined instances still doesn't work properly). I'd like to make this feature work and merged without drowning into the huge patch series I'm already pushing forward. I'd like to make small and verifyable steps toward the full feature, so for me, moving the functional tests to the end is scary like hell. I'm wondering that introducing an API microversion could act like a feature flag I need and at the same time still make the feautre discoverable as you would like to see it. Something like: Create a feature flag in the code but do not put it in the config as a settable flag. Instead add an API microversion patch to the top of the series and when the new version is requested it enables the feature via the feature flag. This API patch can be small and simple enough to cherry-pick to earlier into the series for local end-to-end testing if needed. Also in functional test I can set the flag via a mock so I can add and run functional tests patch by patch. Regarding rejections. I can add patches that rejects server operations (including create too) if the new microversion isn't requested but a port included in the request or associated to the server has resource request. How does this sound to you? Cheers, gibi [1] https://review.openstack.org/#/c/569459 [2] https://review.openstack.org/#/c/623543 [3] https://review.openstack.org/#/c/567268/42/nova/conf/workarounds.py > > [1] > https://review.openstack.org/#/c/502306/17/specs/rocky/approved/bandwidth-resource-provider.rst at 142 > [2] > https://review.openstack.org/#/c/502306/26/specs/rocky/approved/bandwidth-resource-provider.rst at 99 > [3] https://review.openstack.org/#/c/611088/ > > -- > > Thanks, > > Matt > From emilien at redhat.com Fri Dec 28 11:50:47 2018 From: emilien at redhat.com (Emilien Macchi) Date: Fri, 28 Dec 2018 12:50:47 +0100 Subject: [tripleo] removing MongoDB Message-ID: Hi, MongoDB hasn't been used anywhere and it's even unsupported in TripleO since Pike. I think it's time to clean it up, therefore I propose we remove it from TripleO: https://review.openstack.org/#/q/topic:tripleo/rm/mongodb+(status:open+OR+status:merged) Feedback is welcome, Thanks -- Emilien Macchi -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbragstad at gmail.com Fri Dec 28 15:36:10 2018 From: lbragstad at gmail.com (Lance Bragstad) Date: Fri, 28 Dec 2018 09:36:10 -0600 Subject: Review-Priority for Project Repos In-Reply-To: References: Message-ID: I'm curious about this feedback, too. I have this topic as an agenda item for the next keystone meeting [0], but it would be good to hear what the cinder and designate folks think. [0] https://etherpad.openstack.org/p/keystone-weekly-meeting On Thu, Dec 27, 2018 at 11:37 PM Surya Singh wrote: > Dear All, > > There are many occasion when we want to priorities some of the patches > whether it is related to unblock the gates or blocking the non freeze > patches during RC. > > So adding the Review-Priority will allow more precise dashboard. As > Designate and Cinder projects already experiencing this[1][2] and after > discussion with Jeremy brought this to ML to interact with these team > before landing [3], as there is possibility that reapply the priority vote > following any substantive updates to change could make it more cumbersome > than it is worth. > > Teams please share your experience of using Review-Priority. > > [1] https://review.openstack.org/#/c/295253/ > [2] https://review.openstack.org/#/c/620664/ > [3] https://review.openstack.org/#/c/626824/ > > --- > Best Regards > Surya > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nickeysgo at gmail.com Fri Dec 28 16:26:16 2018 From: nickeysgo at gmail.com (Minjun Hong) Date: Sat, 29 Dec 2018 01:26:16 +0900 Subject: [openstack-discuss][Nova][Horizon] 'Too many connections' error Message-ID: Hi. I'm currently trying to substitute the existing controller node with a new server. After I install the 'Minimal deployment for Queens' on the new server, I connect all nodes. However, when I made an instance on Horizon, there were some error messages, as below link: https://imgur.com/hSfHx4M And, when I typed 'openstack flavor list', the result was as follows: > # openstack flavor list > Unexpected API Error. Please report this at > http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. > (HTTP 500) (Request-ID: > req-666d4e30-081a-429f-88ae-763e62990770) Moreover, I found something regarding this problem in the Nova log: 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > [req-666d4e30-081a-429f-88ae-763e62990770 bb1e571e4d64462bac80654b153a88c3 > 96ad10a59d114042b8f1ee82c438649a - default default] Unexpected exception in > API method: OperationalError: (pymysql.err.OperationalError) (1040, u'Too > many connections') 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi Traceback (most > recent call last): > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py", line 788, in > wrapped > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > f(*args, **kwargs) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/flavors.py", > line 50, in detail > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > limited_flavors = self._get_flavors(req) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/flavors.py", > line 117, in _get_flavors > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > limit=limit, marker=marker) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line 184, > in wrapper > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi result = > fn(cls, context, *args, **kwargs) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/nova/objects/flavor.py", line 650, in > get_all > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > marker=marker) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line > 985, in wrapper > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi with > self._transaction_scope(context): > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/contextlib.py", line 17, in __enter__ > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > self.gen.next() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line > 1035, in _transaction_scope > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > context=context) as resource: > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/contextlib.py", line 17, in __enter__ > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > self.gen.next() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line > 638, in _session > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > bind=self.connection, mode=self.mode) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line > 403, in _create_session > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > self._start() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line > 489, in _start > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > engine_args, maker_args) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line > 513, in _setup_for_connection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > sql_connection=sql_connection, **engine_kwargs) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/debtcollector/renames.py", line 45, in > wrapper > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > f(*args, **kwargs) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/engines.py", line 184, > in create_engine > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi test_conn = > _test_connection(engine, max_retries, retry_interval) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/engines.py", line 362, > in _test_connection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > engine.connect() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2091, in > connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > self._connection_cls(self, **kwargs) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 90, in > __init__ > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi if > connection is not None else engine.raw_connection() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2177, in > raw_connection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > self.pool.unique_connection, _connection) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2151, in > _wrap_pool_connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi e, dialect, > self) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1461, in > _handle_dbapi_exception_noconnection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > util.raise_from_cause(newraise, exc_info) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 203, in > raise_from_cause > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > reraise(type(exception), exception, tb=exc_tb, cause=cause) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2147, in > _wrap_pool_connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return fn() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 328, in > unique_connection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > _ConnectionFairy._checkout(self) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2151, in > _wrap_pool_connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi e, dialect, > self) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1461, in > _handle_dbapi_exception_noconnection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > util.raise_from_cause(newraise, exc_info) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 203, in > raise_from_cause > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > reraise(type(exception), exception, tb=exc_tb, cause=cause) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2147, in > _wrap_pool_connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return fn() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 328, in > unique_connection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > _ConnectionFairy._checkout(self) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 766, in > _checkout > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi fairy = > _ConnectionRecord.checkout(pool) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 516, in checkout > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi rec = > pool._do_get() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 1138, in _do_get > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > self._dec_overflow() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py", line 66, > in __exit__ > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > compat.reraise(exc_type, exc_value, exc_tb) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 1135, in _do_get > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > self._create_connection() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 333, in > _create_connection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > _ConnectionRecord(self) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 461, in __init__ > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > self.__connect(first_connect_check=True) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 651, in > __connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi connection > = pool._invoke_creator(self) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/strategies.py", line > 105, in connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > dialect.connect(*cargs, **cparams) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 393, > in connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > self.dbapi.connect(*cargs, **cparams) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/pymysql/__init__.py", line 90, in Connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > Connection(*args, **kwargs) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 699, in > __init__ > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > self.connect() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 936, in > connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > self._request_authentication() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 1156, in > _request_authentication > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi auth_packet > = self._read_packet() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 1018, in > _read_packet > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > packet.check_error() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 384, in > check_error > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > err.raise_mysql_exception(self._data) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/pymysql/err.py", line 107, in > raise_mysql_exception > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi raise > errorclass(errno, errval) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > OperationalError: (pymysql.err.OperationalError) (1040, u'Too many > connections') > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > 2018-12-29 00:58:52.930 3765 INFO nova.api.openstack.wsgi > [req-666d4e30-081a-429f-88ae-763e62990770 bb1e571e4d64462bac80654b153a88c3 > 96ad10a59d114042b8f1ee82c438649a - default default] HTTP exception thrown: > Unexpected API Error. Please report this at > http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. > > 2018-12-29 00:58:52.931 3765 INFO nova.osapi_compute.wsgi.server > [req-666d4e30-081a-429f-88ae-763e62990770 bb1e571e4d64462bac80654b153a88c3 > 96ad10a59d114042b8f1ee82c438649a - default default] 10.150.21.195 "GET > /v2.1/flavors/detail HTTP/1.1" status: 500 len: 638 time: 0.1569352 I already did googling with 'Too many connections' but, there were only results about 'max_connections' of the mysql config file. I also set the value as 4096 and I think it is enough. Now, I do not know what to look for to resolve this problem. Please give me any clue. Thanks! Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Fri Dec 28 17:32:24 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Fri, 28 Dec 2018 18:32:24 +0100 Subject: openstack magnum kubernetes load balancer Message-ID: Hello All, I created a kuberneted cluster with magnum. Than I would like to create a load balancer for nginx: kubectl run nginx --image=nginx --replicas=2 --port=80 kubectl expose deployment nginx --target-port=80 --type=LoadBalancer But kubectl get service gives: kubernetes ClusterIP 10.254.0.1 443/TCP 152m nginx LoadBalancer 10.254.161.102 80:30648/TCP 2m58s If I use NodePort instead of LoadBalancer it works. Does kubernetes requires octavia ? I am using loadbalance v2 without octavia. Regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From liliueecg at gmail.com Thu Dec 27 17:22:35 2018 From: liliueecg at gmail.com (Li Liu) Date: Thu, 27 Dec 2018 12:22:35 -0500 Subject: [Cyborg] Nominating Yumeng Bao for Cyborg Core Reviewer Message-ID: Hi Team, Yumeng Bao has high-quality reviews in the last couple of cycles so I would like to nominate her for Cyborg core Please respond with your +1 or -1 votes. We'll hold voting open for 7 days Thank you Regards Li Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From raniaadouni at gmail.com Thu Dec 27 19:07:37 2018 From: raniaadouni at gmail.com (Rania Adouni) Date: Thu, 27 Dec 2018 20:07:37 +0100 Subject: [openstack_FWaaS] Message-ID: hi, I am looking for instruction to set up FWaaS for openstack queens with multiple node (controller node and network node )!! i did try this : https://docs.openstack.org/neutron/queens/admin/fwaas-v1-scenario.html but nothing was working !! anu help please Best Regards, Rania Adouni -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfredo.deluca at gmail.com Fri Dec 28 21:15:12 2018 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Sat, 29 Dec 2018 08:15:12 +1100 Subject: openstack stack fails In-Reply-To: References: Message-ID: Yes. Next step is to check with ansible. I do think it's some rights somewhere... I'll check later. Thanks On Fri., 28 Dec. 2018, 7:39 pm Ignazio Cassano Alfredo, > 1 . how did you run the last heat template? By dashboard ? > 2. Using openstack command you can check if ansible configured heat > user/domain correctly > > > It seems a problem related to > heat user rights? > > Il giorno Ven 28 Dic 2018 09:06 Alfredo De Luca > ha scritto: > >> Hi Ignazio. The engine log doesn 't say anything...except >> 2018-12-17 11:51:35.284 4064 INFO oslo_service.service [-] Child 4202 >> killed by signal 15 >> which is last log from a few days ago. >> >> While the journal of the heat engine says >> Dec 28 06:36:29 aio1-heat-api-container-16f41ed7 systemd[1]: Started >> heat-engine service. >> Dec 28 06:36:31 aio1-heat-api-container-16f41ed7 heat-engine[91]: >> /openstack/venvs/heat-19.0.0.0b1/lib/python2.7/site-packages/sqlalchemy/sql/sqltypes.py:226: >> SAWarning: Unicode type received non-unicode bind param value >> 'data-processing-cluster'. (this warning may be suppressed after 10 >> occurrences) >> Dec 28 06:36:31 aio1-heat-api-container-16f41ed7 heat-engine[91]: >> (util.ellipses_string(value),)) >> >> >> I also checked the configuration and it seems to be ok. the problem is >> that I installed openstack with ansible-openstack.... so I can't change >> anything unless I re run everything. >> >> >> >> >> >> On Fri, Dec 28, 2018 at 8:57 AM Ignazio Cassano >> wrote: >> >>> Check heat user and domani are c onfigured like at the following: >>> https://docs.openstack.org/heat/rocky/install/install-rdo.html >>> >>> Il giorno Gio 27 Dic 2018 23:25 Alfredo De Luca < >>> alfredo.deluca at gmail.com> ha scritto: >>> >>>> Hi Ignazio. I tried to spin up a stack but I got an error... >>>> Authorization failed. Not sure why. I am a bit stuck >>>> >>>> On Sun., 23 Dec. 2018, 9:19 pm Alfredo De Luca < >>>> alfredo.deluca at gmail.com wrote: >>>> >>>>> I ll try asap. Thanks >>>>> >>>>> On Sat., 22 Dec. 2018, 10:50 pm Ignazio Cassano < >>>>> ignaziocassano at gmail.com wrote: >>>>> >>>>>> Hi Alfredo, have you tried a simple heat template to verify if heat >>>>>> is working fine? >>>>>> Ignazio >>>>>> >>>>>> >>>>>> >>>>>> Il giorno Sab 22 Dic 2018 20:51 Alfredo De Luca < >>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>> >>>>>>> HI IGNAZIO >>>>>>> The problem is that doesn't go that far... It fails before even >>>>>>> creating the master. >>>>>>> >>>>>>> On Sat., 22 Dec. 2018, 6:06 pm Ignazio Cassano < >>>>>>> ignaziocassano at gmail.com wrote: >>>>>>> >>>>>>>> Anycase during deployment you can connect with ssh to the master >>>>>>>> and tail the /var/log/ cloud in it output for checking. >>>>>>>> Ignazio >>>>>>>> >>>>>>>> Il giorno Sab 22 Dic 2018 17:18 Alfredo De Luca < >>>>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>>>> >>>>>>>>> Ciao Ignazio >>>>>>>>> What do you mean with master? you mean k8s master? >>>>>>>>> I guess everything is fine... but I'll double check. >>>>>>>>> >>>>>>>>> Cheers >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano < >>>>>>>>> ignaziocassano at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Alfredo, I am working on queens and I am not sure my answer >>>>>>>>>> could help you.... >>>>>>>>>> Can your master speak with kyestone public endpoint port (5000) ? >>>>>>>>>> Ignazio >>>>>>>>>> >>>>>>>>>> Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca < >>>>>>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>>>>>> >>>>>>>>>>> Hi all. >>>>>>>>>>> I installed magnum on openstack and now, after a few issue with >>>>>>>>>>> cinder type list error, it passed that issue but now I have another one.... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> AuthorizationFailure: >>>>>>>>>>> resources.kube_masters.resources[0].resources.master_wait_handle: >>>>>>>>>>> Authorization failed. >>>>>>>>>>> Not sure what to do nor check >>>>>>>>>>> Any clue? >>>>>>>>>>> Cheers >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> *Alfredo* >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Alfredo* >>>>>>>>> >>>>>>>>> >> >> -- >> *Alfredo* >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From woojay at linbit.com Fri Dec 28 21:55:30 2018 From: woojay at linbit.com (Woojay Poynter) Date: Fri, 28 Dec 2018 13:55:30 -0800 Subject: [Infra][Cinder] Request for voting permission from LINBIT LINSTOR CI (linbit_ci@linbit.com) for Cinder projects In-Reply-To: References: Message-ID: Hello, I would like to request a voting permission on LINBIT LINSTOR CI for Cinder project. We are looking to satisfy third-party testing requirement for Cinder volume driver for LINSTOR (https://review.openstack.org/#/c/624233/). The CI's test result of the lastest patch is at http://us.linbit.com:8080/CI-LINSTOR/33/456/ While the driver itself is still being tweaked on the remaining two failed tests, I hope I can have the CI portion of the requirement ready w/ this request. The testbeds are jenkins slave running fresh installation of devstack w/ target patch triggered from gerrit with lvmthin storage backend managed by LINSTOR driver for Cinder. LINSTOR is storage provisioner using DRBD for block replication. Some of the test results of the LINBIT LINSTOR CI running on openstack-dev/ci-sandbox are here; https://review.openstack.org/#/c/627599/ https://review.openstack.org/#/c/627596/ https://review.openstack.org/#/c/626625/ Thank you for your time during the holidays. Sincerely, Woojay Poynter -- 541-435-1001 woojay at linbit.com LINBIT | Keeping the Digital World Running DRBD – Corosync – Pacemaker DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. On Fri, Dec 28, 2018 at 1:51 PM Woojay Poynter wrote: > Hello, > > I would like to request a voting permission on LINBIT LINSTOR CI for > Cinder project. We are looking to satisfy third-party testing requirement > for Cinder volume driver for LINSTOR ( > https://review.openstack.org/#/c/624233/). The CI's test result of the > lastest patch is at http://us.linbit.com:8080/CI-LINSTOR/33/456/ > > While the driver itself is still being tweaked on the remaining two failed > tests, I hope I can have the CI portion of the requirement ready w/ this > request. > > The testbeds are jenkins slave running fresh installation of devstack w/ > target patch triggered from gerrit with lvmthin storage backend managed by > LINSTOR driver for Cinder. LINSTOR is storage provisioner using DRBD for > block replication. > > Some of the test results of the LINBIT LINSTOR CI running on > openstack-dev/ci-sandbox are here; > https://review.openstack.org/#/c/627599/ > https://review.openstack.org/#/c/627596/ > https://review.openstack.org/#/c/626625/ > > Thank you for your time during the holidays. > > Sincerely, > > Woojay Poynter > -- > 541-435-1001 > woojay at linbit.com > > LINBIT | Keeping the Digital World Running > DRBD – Corosync – Pacemaker > > DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. > -- Woojay Poynter – Software Developer +1 503 573-1262 x211 woojay at linbit.com LINBIT | Keeping the Digital World Running DRBD – Corosync – Pacemaker DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gang.sungjin at gmail.com Sat Dec 29 03:13:29 2018 From: gang.sungjin at gmail.com (Sungjin Kang) Date: Sat, 29 Dec 2018 12:13:29 +0900 Subject: [OpenStack-I18n] [I18n] No team meeting In-Reply-To: References: Message-ID: Happy New Year !!! :) 2018년 12월 27일 (목) 오전 4:05, Frank Kloeker 님이 작성: > Hello, > > due the vacation period the I18n team will also skip the next team > meetings. Our next appointment will be 2019/01/10 07:00 UTC in > #openstack-meeting. > > Enjoy the time and a Happy New Year! > > Frank > > _______________________________________________ > 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 emilien at redhat.com Sat Dec 29 13:52:54 2018 From: emilien at redhat.com (Emilien Macchi) Date: Sat, 29 Dec 2018 14:52:54 +0100 Subject: [tripleo] cleaning-up old reviews Message-ID: Like once a year, we usually clean-up old reviews in Gerrit. Per policy, I've abandoned a lot of patches that were in merge conflict, or not reviewed, or WIP or not passing CI, older than 6 months. If you want to check if one of your patches were abandoned: https://review.openstack.org/#/q/status:abandoned+owner:self Please feel free to re-open it, and let me know if any trouble. I'll also spend time on our Launchpad and also remove old bugs without any activity. Thanks, -- Emilien Macchi -------------- next part -------------- An HTML attachment was scrubbed... URL: From soheil.ir08 at gmail.com Sat Dec 29 07:31:58 2018 From: soheil.ir08 at gmail.com (Soheil Pourbafrani) Date: Sat, 29 Dec 2018 11:01:58 +0330 Subject: [Firewall][OpenStack] Message-ID: I tried to configure the firewall for OpenStack Controller and Compute node and here are the rules I added to the firewall: myZone (active) target: default icmp-block-inversion: no interfaces: enp2s0 enp7s4 sources: services: ssh dhcpv6-client ports: 80/tcp 6080/tcp 11211/tcp 9696/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" source address="192.168.0.32" accept rule family="ipv4" source address="192.168.0.31" accept The address of the Controller and the Compute nodes are 192.168.0.31 and 192.168.0.32, respectively. Using these rules I can use Horizon on the browser and the Compute node services can connect to the Controller nodes ports. The problem is when the firewall is enabled on the Controller node, instances that are running on the Controller node (I configure the Controller node as the Compute node, too) just can be pinged and all other VMs and nodes (including the Controller node) cannot connect to it (using SSH or any other connection to a specific port). - There is no firewall running on instances. - I configured an external network to connect VMs to each other - CentOS7 is running on all nodes Here are ports listening on the Controller node: Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:8775 0.0.0.0:* LISTEN 4478/python2 tcp 0 0 0.0.0.0:9191 0.0.0.0:* LISTEN 4461/python2 tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 10189/httpd tcp 0 0 0.0.0.0:8776 0.0.0.0:* LISTEN 4487/python2 tcp 0 0 0.0.0.0:25672 0.0.0.0:* LISTEN 4466/beam.smp tcp 0 0 0.0.0.0:8778 0.0.0.0:* LISTEN 10189/httpd tcp 0 0 192.168.0.31:3306 0.0.0.0:* LISTEN 4860/mysqld tcp 0 0 192.168.0.31:2379 0.0.0.0:* LISTEN 4464/etcd tcp 0 0 192.168.0.31:11211 0.0.0.0:* LISTEN 4457/memcached tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 4457/memcached tcp 0 0 192.168.0.31:5900 0.0.0.0:* LISTEN 16844/qemu-kvm tcp 0 0 0.0.0.0:9292 0.0.0.0:* LISTEN 4500/python2 tcp 0 0 192.168.0.31:2380 0.0.0.0:* LISTEN 4464/etcd tcp 0 0 192.168.0.31:5901 0.0.0.0:* LISTEN 16982/qemu-kvm tcp 0 0 192.168.0.31:5902 0.0.0.0:* LISTEN 17339/qemu-kvm tcp 0 0 192.168.0.31:5903 0.0.0.0:* LISTEN 17621/qemu-kvm tcp 0 0 192.168.0.31:5904 0.0.0.0:* LISTEN 17840/qemu-kvm tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 10189/httpd 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 4468/sshd tcp 0 0 192.168.0.31:3260 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:6080 0.0.0.0:* LISTEN 4458/python2 tcp 0 0 0.0.0.0:9696 0.0.0.0:* LISTEN 4473/python2 tcp 0 0 0.0.0.0:8774 0.0.0.0:* LISTEN 4478/python2 tcp6 0 0 :::5672 :::* LISTEN 4466/beam.smp tcp6 0 0 :::22 :::* LISTEN 4468/sshd So, is there any port or something to add to firewall rules for making instances reachable when the firewall is running on the Controller node? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jftalta at gmail.com Sat Dec 29 11:51:18 2018 From: jftalta at gmail.com (JF Taltavull) Date: Sat, 29 Dec 2018 12:51:18 +0100 Subject: [OpenStack-I18n] [I18n] No team meeting In-Reply-To: References: Message-ID: Happy New Year to everyone ! -JF Le sam. 29 déc. 2018 à 04:14, Sungjin Kang a écrit : > Happy New Year !!! :) > > 2018년 12월 27일 (목) 오전 4:05, Frank Kloeker 님이 작성: > >> Hello, >> >> due the vacation period the I18n team will also skip the next team >> meetings. Our next appointment will be 2019/01/10 07:00 UTC in >> #openstack-meeting. >> >> Enjoy the time and a Happy New Year! >> >> Frank >> >> _______________________________________________ >> 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 alfredo.deluca at gmail.com Sun Dec 30 00:31:41 2018 From: alfredo.deluca at gmail.com (Alfredo De Luca) Date: Sun, 30 Dec 2018 01:31:41 +0100 Subject: openstack stack fails In-Reply-To: References: Message-ID: so. Creating a stack either manually or dashboard works fine. The problem seems to be when I create a cluster (kubernetes/swarm) that I got that error. Maybe the magnum conf it's not properly setup? In the heat section of the magnum.conf I have only *[heat_client]* *region_name = RegionOne* *endpoint_type = internalURL* Cheers On Fri, Dec 28, 2018 at 10:15 PM Alfredo De Luca wrote: > Yes. Next step is to check with ansible. > I do think it's some rights somewhere... > I'll check later. Thanks > > On Fri., 28 Dec. 2018, 7:39 pm Ignazio Cassano wrote: > >> Alfredo, >> 1 . how did you run the last heat template? By dashboard ? >> 2. Using openstack command you can check if ansible configured heat >> user/domain correctly >> >> >> It seems a problem related to >> heat user rights? >> >> Il giorno Ven 28 Dic 2018 09:06 Alfredo De Luca >> ha scritto: >> >>> Hi Ignazio. The engine log doesn 't say anything...except >>> 2018-12-17 11:51:35.284 4064 INFO oslo_service.service [-] Child 4202 >>> killed by signal 15 >>> which is last log from a few days ago. >>> >>> While the journal of the heat engine says >>> Dec 28 06:36:29 aio1-heat-api-container-16f41ed7 systemd[1]: Started >>> heat-engine service. >>> Dec 28 06:36:31 aio1-heat-api-container-16f41ed7 heat-engine[91]: >>> /openstack/venvs/heat-19.0.0.0b1/lib/python2.7/site-packages/sqlalchemy/sql/sqltypes.py:226: >>> SAWarning: Unicode type received non-unicode bind param value >>> 'data-processing-cluster'. (this warning may be suppressed after 10 >>> occurrences) >>> Dec 28 06:36:31 aio1-heat-api-container-16f41ed7 heat-engine[91]: >>> (util.ellipses_string(value),)) >>> >>> >>> I also checked the configuration and it seems to be ok. the problem is >>> that I installed openstack with ansible-openstack.... so I can't change >>> anything unless I re run everything. >>> >>> >>> >>> >>> >>> On Fri, Dec 28, 2018 at 8:57 AM Ignazio Cassano < >>> ignaziocassano at gmail.com> wrote: >>> >>>> Check heat user and domani are c onfigured like at the following: >>>> https://docs.openstack.org/heat/rocky/install/install-rdo.html >>>> >>>> Il giorno Gio 27 Dic 2018 23:25 Alfredo De Luca < >>>> alfredo.deluca at gmail.com> ha scritto: >>>> >>>>> Hi Ignazio. I tried to spin up a stack but I got an error... >>>>> Authorization failed. Not sure why. I am a bit stuck >>>>> >>>>> On Sun., 23 Dec. 2018, 9:19 pm Alfredo De Luca < >>>>> alfredo.deluca at gmail.com wrote: >>>>> >>>>>> I ll try asap. Thanks >>>>>> >>>>>> On Sat., 22 Dec. 2018, 10:50 pm Ignazio Cassano < >>>>>> ignaziocassano at gmail.com wrote: >>>>>> >>>>>>> Hi Alfredo, have you tried a simple heat template to verify if heat >>>>>>> is working fine? >>>>>>> Ignazio >>>>>>> >>>>>>> >>>>>>> >>>>>>> Il giorno Sab 22 Dic 2018 20:51 Alfredo De Luca < >>>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>>> >>>>>>>> HI IGNAZIO >>>>>>>> The problem is that doesn't go that far... It fails before even >>>>>>>> creating the master. >>>>>>>> >>>>>>>> On Sat., 22 Dec. 2018, 6:06 pm Ignazio Cassano < >>>>>>>> ignaziocassano at gmail.com wrote: >>>>>>>> >>>>>>>>> Anycase during deployment you can connect with ssh to the master >>>>>>>>> and tail the /var/log/ cloud in it output for checking. >>>>>>>>> Ignazio >>>>>>>>> >>>>>>>>> Il giorno Sab 22 Dic 2018 17:18 Alfredo De Luca < >>>>>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>>>>> >>>>>>>>>> Ciao Ignazio >>>>>>>>>> What do you mean with master? you mean k8s master? >>>>>>>>>> I guess everything is fine... but I'll double check. >>>>>>>>>> >>>>>>>>>> Cheers >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano < >>>>>>>>>> ignaziocassano at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Alfredo, I am working on queens and I am not sure my answer >>>>>>>>>>> could help you.... >>>>>>>>>>> Can your master speak with kyestone public endpoint port (5000) ? >>>>>>>>>>> Ignazio >>>>>>>>>>> >>>>>>>>>>> Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca < >>>>>>>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>>>>>>> >>>>>>>>>>>> Hi all. >>>>>>>>>>>> I installed magnum on openstack and now, after a few issue with >>>>>>>>>>>> cinder type list error, it passed that issue but now I have another one.... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> AuthorizationFailure: >>>>>>>>>>>> resources.kube_masters.resources[0].resources.master_wait_handle: >>>>>>>>>>>> Authorization failed. >>>>>>>>>>>> Not sure what to do nor check >>>>>>>>>>>> Any clue? >>>>>>>>>>>> Cheers >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> *Alfredo* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Alfredo* >>>>>>>>>> >>>>>>>>>> >>> >>> -- >>> *Alfredo* >>> >>> -- *Alfredo* -------------- next part -------------- An HTML attachment was scrubbed... URL: From jma.ayala at gmail.com Sat Dec 29 21:16:35 2018 From: jma.ayala at gmail.com (zud0ku) Date: Sat, 29 Dec 2018 14:16:35 -0700 (MST) Subject: Openstack-ansible and HAProxy In-Reply-To: References: Message-ID: <1546118195735-0.post@n7.nabble.com> Hi, I am having same problem. Were you able to solve the situation? Please can you share any updates? Thanks in advance. -- Sent from: http://openstack.10931.n7.nabble.com/Operators-f4774.html From ignaziocassano at gmail.com Sun Dec 30 07:43:26 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sun, 30 Dec 2018 08:43:26 +0100 Subject: openstack stack fails In-Reply-To: References: Message-ID: Hi Alfredo, attached here there is my magnum.conf for queens release As you can see my heat sections are empty When you create your cluster, I suggest to check heat logs e magnum logs for verifyng what is wrong Ignazio Il giorno dom 30 dic 2018 alle ore 01:31 Alfredo De Luca < alfredo.deluca at gmail.com> ha scritto: > so. Creating a stack either manually or dashboard works fine. The problem > seems to be when I create a cluster (kubernetes/swarm) that I got that > error. > Maybe the magnum conf it's not properly setup? > In the heat section of the magnum.conf I have only > *[heat_client]* > *region_name = RegionOne* > *endpoint_type = internalURL* > > Cheers > > > On Fri, Dec 28, 2018 at 10:15 PM Alfredo De Luca > wrote: > >> Yes. Next step is to check with ansible. >> I do think it's some rights somewhere... >> I'll check later. Thanks >> >> On Fri., 28 Dec. 2018, 7:39 pm Ignazio Cassano > wrote: >> >>> Alfredo, >>> 1 . how did you run the last heat template? By dashboard ? >>> 2. Using openstack command you can check if ansible configured heat >>> user/domain correctly >>> >>> >>> It seems a problem related to >>> heat user rights? >>> >>> Il giorno Ven 28 Dic 2018 09:06 Alfredo De Luca < >>> alfredo.deluca at gmail.com> ha scritto: >>> >>>> Hi Ignazio. The engine log doesn 't say anything...except >>>> 2018-12-17 11:51:35.284 4064 INFO oslo_service.service [-] Child 4202 >>>> killed by signal 15 >>>> which is last log from a few days ago. >>>> >>>> While the journal of the heat engine says >>>> Dec 28 06:36:29 aio1-heat-api-container-16f41ed7 systemd[1]: Started >>>> heat-engine service. >>>> Dec 28 06:36:31 aio1-heat-api-container-16f41ed7 heat-engine[91]: >>>> /openstack/venvs/heat-19.0.0.0b1/lib/python2.7/site-packages/sqlalchemy/sql/sqltypes.py:226: >>>> SAWarning: Unicode type received non-unicode bind param value >>>> 'data-processing-cluster'. (this warning may be suppressed after 10 >>>> occurrences) >>>> Dec 28 06:36:31 aio1-heat-api-container-16f41ed7 heat-engine[91]: >>>> (util.ellipses_string(value),)) >>>> >>>> >>>> I also checked the configuration and it seems to be ok. the problem is >>>> that I installed openstack with ansible-openstack.... so I can't change >>>> anything unless I re run everything. >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Dec 28, 2018 at 8:57 AM Ignazio Cassano < >>>> ignaziocassano at gmail.com> wrote: >>>> >>>>> Check heat user and domani are c onfigured like at the following: >>>>> https://docs.openstack.org/heat/rocky/install/install-rdo.html >>>>> >>>>> Il giorno Gio 27 Dic 2018 23:25 Alfredo De Luca < >>>>> alfredo.deluca at gmail.com> ha scritto: >>>>> >>>>>> Hi Ignazio. I tried to spin up a stack but I got an error... >>>>>> Authorization failed. Not sure why. I am a bit stuck >>>>>> >>>>>> On Sun., 23 Dec. 2018, 9:19 pm Alfredo De Luca < >>>>>> alfredo.deluca at gmail.com wrote: >>>>>> >>>>>>> I ll try asap. Thanks >>>>>>> >>>>>>> On Sat., 22 Dec. 2018, 10:50 pm Ignazio Cassano < >>>>>>> ignaziocassano at gmail.com wrote: >>>>>>> >>>>>>>> Hi Alfredo, have you tried a simple heat template to verify if heat >>>>>>>> is working fine? >>>>>>>> Ignazio >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Il giorno Sab 22 Dic 2018 20:51 Alfredo De Luca < >>>>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>>>> >>>>>>>>> HI IGNAZIO >>>>>>>>> The problem is that doesn't go that far... It fails before even >>>>>>>>> creating the master. >>>>>>>>> >>>>>>>>> On Sat., 22 Dec. 2018, 6:06 pm Ignazio Cassano < >>>>>>>>> ignaziocassano at gmail.com wrote: >>>>>>>>> >>>>>>>>>> Anycase during deployment you can connect with ssh to the master >>>>>>>>>> and tail the /var/log/ cloud in it output for checking. >>>>>>>>>> Ignazio >>>>>>>>>> >>>>>>>>>> Il giorno Sab 22 Dic 2018 17:18 Alfredo De Luca < >>>>>>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>>>>>> >>>>>>>>>>> Ciao Ignazio >>>>>>>>>>> What do you mean with master? you mean k8s master? >>>>>>>>>>> I guess everything is fine... but I'll double check. >>>>>>>>>>> >>>>>>>>>>> Cheers >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sat, Dec 22, 2018 at 9:30 AM Ignazio Cassano < >>>>>>>>>>> ignaziocassano at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Alfredo, I am working on queens and I am not sure my answer >>>>>>>>>>>> could help you.... >>>>>>>>>>>> Can your master speak with kyestone public endpoint port (5000) >>>>>>>>>>>> ? >>>>>>>>>>>> Ignazio >>>>>>>>>>>> >>>>>>>>>>>> Il giorno Ven 21 Dic 2018 16:20 Alfredo De Luca < >>>>>>>>>>>> alfredo.deluca at gmail.com> ha scritto: >>>>>>>>>>>> >>>>>>>>>>>>> Hi all. >>>>>>>>>>>>> I installed magnum on openstack and now, after a few issue >>>>>>>>>>>>> with cinder type list error, it passed that issue but now I have another >>>>>>>>>>>>> one.... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> AuthorizationFailure: >>>>>>>>>>>>> resources.kube_masters.resources[0].resources.master_wait_handle: >>>>>>>>>>>>> Authorization failed. >>>>>>>>>>>>> Not sure what to do nor check >>>>>>>>>>>>> Any clue? >>>>>>>>>>>>> Cheers >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> *Alfredo* >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> *Alfredo* >>>>>>>>>>> >>>>>>>>>>> >>>> >>>> -- >>>> *Alfredo* >>>> >>>> > > -- > *Alfredo* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: magnum.conf Type: application/octet-stream Size: 1533 bytes Desc: not available URL: From nickeysgo at gmail.com Sun Dec 30 09:41:35 2018 From: nickeysgo at gmail.com (Minjun Hong) Date: Sun, 30 Dec 2018 18:41:35 +0900 Subject: [openstack-discuss][Nova][Horizon] 'Too many connections' error In-Reply-To: <6E74D8DE-E99C-4FDB-991D-FA659D89A1F6@openstack.org> References: <6E74D8DE-E99C-4FDB-991D-FA659D89A1F6@openstack.org> Message-ID: Thanks for your reply, Chris. Following your advice, I adjusted the values in 'nova.conf' file. Setting max_connections in the mysql config file to 4096, the modified values are: 1. max_pool_size in [database] section to 1000 2. max_pool_size in [api_database] section to 1000 3. max_overflow in [database] section to 1000 4. max_overflow in [api_database] section to 1000 However, the problem which some services, such as Nova or Neutron, cannot connect to mysql DB occurred again. So that, I also modified the number of workers you had mentioned as follows: 1. osapi_compute_workers in [DEFAULT] section to 128 2. metadata_workers in [DEFAULT] section to 128 3. workers in [conductor] section to 128 And then, I could not use all openstack command at all. I mean, all openstack command did not work with "An unexpected error prevented the server from fulfilling your request. (HTTP 500)" error messages. After looking into some config files of the openstack services, I found out some similar parameters with the parameters you had mentioned were in the config files. For example, in neutron.conf file, max_pool_size also exists and glance-api.conf has worker parameter, either. I'm confused for what parameters should I use. Actually, I'm not sure of functions of the parameters and I need your help more. Thanks! Regards, On Sat, Dec 29, 2018 at 2:11 PM Chris Hoge wrote: > I’ve run into something similar. By default there are a few things going > on with Nova. To begin with, Nova starts up several services multiplied > by the number of cores on your system. When you add to this that Nova > doesn't by default constrain its database connection pool and it's eager > to create new database connections, you can quickly open tens of > thousands of new connections across more than a dozen processes in a > matter of minutes when starting a complete Nova control plane. > > Thankfully, this is easy to fix by setting the max_pool_size and > max_overflow parameters, as well as constraining the number of workers > for the different processes in nova.conf. > > You’ll want to tune your mysql max-connections to match your expected > volume of connections from the control plane. > > Hope that helps. > > On Dec 28, 2018, at 8:26 AM, Minjun Hong wrote: > > Hi. > I'm currently trying to substitute the existing controller node with a new > server. > After I install the 'Minimal deployment for Queens' on the new server, I > connect all nodes. > > However, when I made an instance on Horizon, there were some error > messages, as below link: > > https://imgur.com/hSfHx4M > > And, when I typed 'openstack flavor list', the result was as follows: > >> # openstack flavor list >> Unexpected API Error. Please report this at >> http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. >> (HTTP 500) (Request-ID: >> req-666d4e30-081a-429f-88ae-763e62990770) > > > Moreover, I found something regarding this problem in the Nova log: > > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> [req-666d4e30-081a-429f-88ae-763e62990770 bb1e571e4d64462bac80654b153a88c3 >> 96ad10a59d114042b8f1ee82c438649a - default default] Unexpected exception in >> API method: OperationalError: (pymysql.err.OperationalError) (1040, u'Too >> many connections') > > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi Traceback (most >> recent call last): >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py", line 788, in >> wrapped >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> f(*args, **kwargs) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/flavors.py", >> line 50, in detail >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> limited_flavors = self._get_flavors(req) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/flavors.py", >> line 117, in _get_flavors >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> limit=limit, marker=marker) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line 184, >> in wrapper >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi result = >> fn(cls, context, *args, **kwargs) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/nova/objects/flavor.py", line 650, in >> get_all >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> marker=marker) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line >> 985, in wrapper >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi with >> self._transaction_scope(context): >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/contextlib.py", line 17, in __enter__ >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> self.gen.next() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line >> 1035, in _transaction_scope >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> context=context) as resource: >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/contextlib.py", line 17, in __enter__ >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> self.gen.next() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line >> 638, in _session >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> bind=self.connection, mode=self.mode) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line >> 403, in _create_session >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> self._start() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line >> 489, in _start >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> engine_args, maker_args) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line >> 513, in _setup_for_connection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> sql_connection=sql_connection, **engine_kwargs) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/debtcollector/renames.py", line 45, in >> wrapper >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> f(*args, **kwargs) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/engines.py", line 184, >> in create_engine >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi test_conn >> = _test_connection(engine, max_retries, retry_interval) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/engines.py", line 362, >> in _test_connection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> engine.connect() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2091, in >> connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> self._connection_cls(self, **kwargs) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 90, in >> __init__ >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi if >> connection is not None else engine.raw_connection() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2177, in >> raw_connection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> self.pool.unique_connection, _connection) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2151, in >> _wrap_pool_connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi e, >> dialect, self) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1461, in >> _handle_dbapi_exception_noconnection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> util.raise_from_cause(newraise, exc_info) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 203, in >> raise_from_cause >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> reraise(type(exception), exception, tb=exc_tb, cause=cause) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2147, in >> _wrap_pool_connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return fn() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 328, in >> unique_connection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> _ConnectionFairy._checkout(self) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2151, in >> _wrap_pool_connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi e, >> dialect, self) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1461, in >> _handle_dbapi_exception_noconnection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> util.raise_from_cause(newraise, exc_info) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 203, in >> raise_from_cause >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> reraise(type(exception), exception, tb=exc_tb, cause=cause) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2147, in >> _wrap_pool_connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return fn() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 328, in >> unique_connection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> _ConnectionFairy._checkout(self) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 766, in >> _checkout >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi fairy = >> _ConnectionRecord.checkout(pool) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 516, in checkout >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi rec = >> pool._do_get() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 1138, in _do_get >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> self._dec_overflow() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py", line 66, >> in __exit__ >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> compat.reraise(exc_type, exc_value, exc_tb) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 1135, in _do_get >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> self._create_connection() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 333, in >> _create_connection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> _ConnectionRecord(self) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 461, in __init__ >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> self.__connect(first_connect_check=True) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 651, in >> __connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi connection >> = pool._invoke_creator(self) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/strategies.py", line >> 105, in connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> dialect.connect(*cargs, **cparams) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 393, >> in connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> self.dbapi.connect(*cargs, **cparams) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/pymysql/__init__.py", line 90, in Connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> Connection(*args, **kwargs) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 699, in >> __init__ >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> self.connect() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 936, in >> connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> self._request_authentication() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 1156, in >> _request_authentication >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> auth_packet = self._read_packet() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 1018, in >> _read_packet >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> packet.check_error() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 384, in >> check_error >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> err.raise_mysql_exception(self._data) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/pymysql/err.py", line 107, in >> raise_mysql_exception >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi raise >> errorclass(errno, errval) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> OperationalError: (pymysql.err.OperationalError) (1040, u'Too many >> connections') >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> 2018-12-29 00:58:52.930 3765 INFO nova.api.openstack.wsgi >> [req-666d4e30-081a-429f-88ae-763e62990770 bb1e571e4d64462bac80654b153a88c3 >> 96ad10a59d114042b8f1ee82c438649a - default default] HTTP exception thrown: >> Unexpected API Error. Please report this at >> http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. >> >> 2018-12-29 00:58:52.931 3765 INFO nova.osapi_compute.wsgi.server >> [req-666d4e30-081a-429f-88ae-763e62990770 bb1e571e4d64462bac80654b153a88c3 >> 96ad10a59d114042b8f1ee82c438649a - default default] 10.150.21.195 "GET >> /v2.1/flavors/detail HTTP/1.1" status: 500 len: 638 time: 0.1569352 > > > I already did googling with 'Too many connections' but, there were only > results about 'max_connections' of the mysql config file. > I also set the value as 4096 and I think it is enough. > > Now, I do not know what to look for to resolve this problem. > Please give me any clue. > > Thanks! > Regards, > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nickeysgo at gmail.com Sun Dec 30 09:55:33 2018 From: nickeysgo at gmail.com (Minjun Hong) Date: Sun, 30 Dec 2018 18:55:33 +0900 Subject: [Openstack-discuss][Horizon] Domain input in the login page disappeared Message-ID: Hi. I'm replacing existing controller node with a new server. After the setup step, I found something weird. The domain input in the horizon login page disappeared as following link https://imgur.com/Vuj7uNT I'm not sure that is normal situation but, horizon login page in the previous system always consisted of Domain, User Name and Password. So, is there anyone who has experienced this problem? Thanks. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Sun Dec 30 10:39:08 2018 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sun, 30 Dec 2018 11:39:08 +0100 Subject: openstack magnum on queens: please help me Message-ID: Hello Everybody, I created a kubernetes cluster with mugnum under queens. After that I ran the folloquing commands: mkdir -p /root/clusters/kubecertslb/config export KUBECONFIG=/root/clusters/kubecertslb/config $(openstack coe cluster config kubecertslb --dir ~/clusters/kubecertslb) Then the command "kubectl -n kube-system get po" reports: NAME READY STATUS RESTARTS AGE coredns-5864cfd79d-76889 1/1 Running 0 18h heapster-68b976dd7-7vdlq 1/1 Running 0 18h kubernetes-dashboard-846b8b6844-cjp2f 1/1 Running 0 18h the command "kubectl cluster-info" reports: Kubernetes master is running at https://10.102.186.126:6443 Heapster is running at https://10.102.186.126:6443/api/v1/namespaces/kube-system/services/heapster/proxy CoreDNS is running at https://10.102.186.126:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump' I deployed nginx: kubectl run nginx --image=nginx --replicas=2 --port=80 Then the command "kubectl get po" reports: NAME READY STATUS RESTARTS AGE nginx-7587c6fdb6-chnw6 1/1 Running 0 18h nginx-7587c6fdb6-m7fr2 1/1 Running 0 18h Exposing nginx service with type NodePort works fine. Exposing with type LoadBalancer does not work: kubectl expose deployment nginx --target-port=80 --type=LoadBalancer kubectl get svc: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.254.0.1 443/TCP 19h nginx LoadBalancer 10.254.97.40 80:31568/TCP 165m No load balancer is created. Im not using octavia but standard lbaas v2. Lbaas is working fine because I tried a configuration between two ssh vm. I read somting about the magnum.conf trust section: someone suggested to enable "cluster_user_trust = True" I tried it but with this parameter the kubernetes cluster does not finish: the heat template remains in pending ang goes in timeout during the master creation. I read also something aboud kubernetes cloud provider must be "external" or "openstack" but I think it should the automatically configured by heat. Any help, please ? Thanks and Regards Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From zufardhiyaulhaq at gmail.com Sun Dec 30 11:30:55 2018 From: zufardhiyaulhaq at gmail.com (Zufar Dhiyaulhaq) Date: Sun, 30 Dec 2018 18:30:55 +0700 Subject: [heat] Bug : Heat cannot create Octavia Load Balancer Message-ID: I have try creating load balancer with Heat. but always get this error : Resource CREATE failed: OctaviaClientException: resources.loadbalancer: Validation failure: Missing project ID in request where one is required. (HTTP 400) (Request-ID: req-b45208e1-a200-47f9-8aad-b130c4c12272) OctaviaClientException: resources.loadbalancer: Validation failure: Missing project ID in request where one is required. (HTTP 400) (Request-ID: req-b45208e1-a200-47f9-8aad-b130c4c12272) I create 2 openstack environment : - Heat with Octavia (Octavia Heat Template : http://paste.opensuse.org/view//33592182 ) - Heat with Neutron Lbaasv2 (Neutron LBaaSv2 Heat Template : http://paste.opensuse.org/view//71741503) But always error when creating with octavia : - Octavia Log (https://imgur.com/a/EsuWvla) - LBaaS v2 (https://imgur.com/a/BqNGRPH) Are Heat code is broken to create Octavia Load Balancer? Best Regards, Zufar Dhiyaulhaq -------------- next part -------------- An HTML attachment was scrubbed... URL: From nickeysgo at gmail.com Sun Dec 30 19:55:24 2018 From: nickeysgo at gmail.com (Minjun Hong) Date: Mon, 31 Dec 2018 04:55:24 +0900 Subject: [Openstack-discuss][Cinder] Fail to mount the volume on the target node Message-ID: Hi. After I installed Cinder, I have had a problem which I cannot make instances with volume storage. I created an instance on Horizon and it always has failed. Actually, I'm using Xen as the hypervisor and there was not any special log about Nova. But, in the Xen's log (/var/log/xen/bootloader.5.log), I saw the hypervisor cannot find the volume which is provided by Cinder: Traceback (most recent call last): > File "/usr/lib/xen/bin/pygrub", line 929, in > raise RuntimeError, "Unable to find partition containing kernel" > RuntimeError: Unable to find partition containing kernel And, I also found something noticeable in the Cinder's log ('/var/log/cinder/cinder-volume.log' on the Block storage node): 2018-12-31 04:08:11.189 12380 INFO cinder.volume.manager > [req-93eb0ad3-6c6c-4842-851f-435e15d8639b bb1e571e4d64462bac80654b153a88c3 > 96ad10a59d114042b8f1ee82c438649a - default default] Attaching volume > 4c21b8f1-ff07-4916-9692-e74759635978 to instance > bea7dca6-fb04-4791-bac9-3ad560280cc3 at mountpoint /dev/xvda on host None. It seems that Cinder cannot receive information of the target node ('on host None' above) so, I think it can cause the problem that Cinder fails to provide the volume due to lack of the host information. Since I could not find any other logs except that log, I need more hints. Please give me some help Thanks! Regard, -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepanshuchandna at hotmail.com Mon Dec 31 07:16:53 2018 From: deepanshuchandna at hotmail.com (Deep C) Date: Mon, 31 Dec 2018 07:16:53 +0000 Subject: [Mistral] Message-ID: Hi Team, Could anyone please help me fixing the below issue - Mistral server throws error when i execute workflows - 2018-12-31 00:49:40.025 59372 ERROR mistral.notifiers.default_notifier Exception: [9ad86428-59ca-4823-87ad-61915f61410d] Unable to publish event because st2 returned status code 500. { 2018-12-31 00:49:40.025 59372 ERROR mistral.notifiers.default_notifier "faultstring": "Internal Server Error" 2018-12-31 00:49:40.025 59372 ERROR mistral.notifiers.default_notifier } 2018-12-31 00:49:40.025 59372 ERROR mistral.notifiers.default_notifier Bug also raised for more details - https://bugs.launchpad.net/mistral/+bug/1808668 Please suggest the solution . -------------- next part -------------- An HTML attachment was scrubbed... URL: