From berndbausch at gmail.com Sat Nov 9 01:35:07 2019 From: berndbausch at gmail.com (Bernd Bausch) Date: Sat, 9 Nov 2019 10:35:07 +0900 Subject: [OpenStack-Infra] ask.openstack.org down for some days Message-ID: ask.openstack.org has been down for most of the week: /Firefox can’t establish a connection to the server at ask.openstack.org./ I wouldn't mind helping if I knew how. Bernd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Sat Nov 9 17:07:06 2019 From: fungi at yuggoth.org (Jeremy Stanley) Date: Sat, 9 Nov 2019 17:07:06 +0000 Subject: [OpenStack-Infra] ask.openstack.org down for some days In-Reply-To: References: Message-ID: <20191109170706.r2556yzdxpceqmc2@yuggoth.org> On 2019-11-09 10:35:07 +0900 (+0900), Bernd Bausch wrote: > ask.openstack.org has been down for most of the week: > > /Firefox can’t establish a connection to the server at > ask.openstack.org./ > > I wouldn't mind helping if I knew how. For some reason Apache has been failing to restart during daily log rotation all week. I've manually started it again. Most of the sysadmins have been busy with other things in Shanghai (myself included), but I had a few free minutes on a layover just now. It's worth keeping in mind that the ask.openstack.org site has basically been unmaintained for years, ever since the AskBot maintainer OSF was contracting to run it disappeared. If folks are still finding the service useful, then we probably need to have a conversation about finding a maintainer for 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 berndbausch at gmail.com Sun Nov 10 01:06:16 2019 From: berndbausch at gmail.com (Bernd Bausch) Date: Sun, 10 Nov 2019 10:06:16 +0900 Subject: [OpenStack-Infra] ask.openstack.org down for some days In-Reply-To: <20191109170706.r2556yzdxpceqmc2@yuggoth.org> References: <20191109170706.r2556yzdxpceqmc2@yuggoth.org> Message-ID: <027f0f07-28fa-a930-aa75-fea945e30e28@gmail.com> Yes, I guess it's still useful. Traffic is not very high, perhaps 5 questions a day (if there are logs, it should be easy to confirm this), both from absolute beginners and advanced users. No idea what time and skill is required to maintain an Askbot site, but I am certainly curious. Bernd. On 2019/11/10 2:07 AM, Jeremy Stanley wrote: > For some reason Apache has been failing to restart during daily log > rotation all week. I've manually started it again. Most of the > sysadmins have been busy with other things in Shanghai (myself > included), but I had a few free minutes on a layover just now. > > It's worth keeping in mind that the ask.openstack.org site has > basically been unmaintained for years, ever since the AskBot > maintainer OSF was contracting to run it disappeared. If folks are > still finding the service useful, then we probably need to have a > conversation about finding a maintainer for it. From jimmy at tipit.net Sun Nov 10 03:46:06 2019 From: jimmy at tipit.net (Jimmy McArthur) Date: Sun, 10 Nov 2019 03:46:06 +0000 Subject: [OpenStack-Infra] ask.openstack.org down for some days In-Reply-To: <027f0f07-28fa-a930-aa75-fea945e30e28@gmail.com> References: <027f0f07-28fa-a930-aa75-fea945e30e28@gmail.com> Message-ID: Typically we give a cry for help and people pay attention and start moderating again for a month or so. Then it falls off of people’s radar again. The site needs massive improvements: better spam filtering, smarter suggestion engine to discourage duplicate posts, better tagging and search, etc... most questions go unanswered or unmoderated for months. I’d love it if someone took up that task, but I fear it won’t happen. Ifwecant find a champion, I believe we should think about winding down the service. In its current state it’s doing more harm than good. Thanks, Jimmy > On Nov 9, 2019, at 7:06 PM, Bernd Bausch wrote: > > Yes, I guess it's still useful. Traffic is not very high, perhaps 5 questions a day (if there are logs, it should be easy to confirm this), both from absolute beginners and advanced users. > > No idea what time and skill is required to maintain an Askbot site, but I am certainly curious. > > Bernd. > >> On 2019/11/10 2:07 AM, Jeremy Stanley wrote: >> For some reason Apache has been failing to restart during daily log >> rotation all week. I've manually started it again. Most of the >> sysadmins have been busy with other things in Shanghai (myself >> included), but I had a few free minutes on a layover just now. >> >> It's worth keeping in mind that the ask.openstack.org site has >> basically been unmaintained for years, ever since the AskBot >> maintainer OSF was contracting to run it disappeared. If folks are >> still finding the service useful, then we probably need to have a >> conversation about finding a maintainer for it. > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra From berndbausch at gmail.com Sun Nov 10 11:15:23 2019 From: berndbausch at gmail.com (Bernd Bausch) Date: Sun, 10 Nov 2019 20:15:23 +0900 Subject: [OpenStack-Infra] ask.openstack.org down for some days In-Reply-To: References: <027f0f07-28fa-a930-aa75-fea945e30e28@gmail.com> Message-ID: <67EBCE56-F2CD-4148-9742-A9DAD21051EC@gmail.com> I am one of the moderators (no admin privileges though). Spam is not a problem, perhaps twice a month. Unmoderated questions aren't either (from my narrow perspective), but it is true that we could do with more answers, especially to the more specialized questions. And it is true that the user interface is lacking at several levels. I am happy to volunteer though, having no real system administration experience, there would be a learning curve, i.e. no immediate resolution. Bernd > On Nov 10, 2019, at 12:46, Jimmy McArthur wrote: > > Typically we give a cry for help and people pay attention and start > moderating again for a month or so. Then it falls off of people’s > radar again. The site needs massive improvements: better spam > filtering, smarter suggestion engine to discourage duplicate posts, > better tagging and search, etc... most questions go unanswered or > unmoderated for months. > > I’d love it if someone took up that task, but I fear it won’t happen. > Ifwecant find a champion, I believe we should think about winding down > the service. In its current state it’s doing more harm than good. > > Thanks, > Jimmy > >> On Nov 9, 2019, at 7:06 PM, Bernd Bausch wrote: >> >> Yes, I guess it's still useful. Traffic is not very high, perhaps 5 questions a day (if there are logs, it should be easy to confirm this), both from absolute beginners and advanced users. >> >> No idea what time and skill is required to maintain an Askbot site, but I am certainly curious. >> >> Bernd. >> >>> On 2019/11/10 2:07 AM, Jeremy Stanley wrote: >>> For some reason Apache has been failing to restart during daily log >>> rotation all week. I've manually started it again. Most of the >>> sysadmins have been busy with other things in Shanghai (myself >>> included), but I had a few free minutes on a layover just now. >>> >>> It's worth keeping in mind that the ask.openstack.org site has >>> basically been unmaintained for years, ever since the AskBot >>> maintainer OSF was contracting to run it disappeared. If folks are >>> still finding the service useful, then we probably need to have a >>> conversation about finding a maintainer for it. >> >> _______________________________________________ >> OpenStack-Infra mailing list >> OpenStack-Infra at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra From ssbarnea at redhat.com Mon Nov 11 16:03:58 2019 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Mon, 11 Nov 2019 16:03:58 +0000 Subject: [OpenStack-Infra] ask.openstack.org down for some days In-Reply-To: <67EBCE56-F2CD-4148-9742-A9DAD21051EC@gmail.com> References: <027f0f07-28fa-a930-aa75-fea945e30e28@gmail.com> <67EBCE56-F2CD-4148-9742-A9DAD21051EC@gmail.com> Message-ID: Having a StackOverflow kind Q&A site is of great value but only if there is enough critical mass to maintain it. Clearly ask.openstack.org is far from reaching that mass. I would personally see more useful to redirect users to two existing platforms that already passed the critical mass and which have active moderators, like: - https://stackoverflow.com for developers - https://serverfault.com for operators I know that on OpenStack we have good track of DIY on anything but we need to realize about what is achievable or not. Sometimes is better to focus on core business and outsource some services. Cheers Sorin Sbarnea > On 10 Nov 2019, at 11:15, Bernd Bausch wrote: > > I am one of the moderators (no admin privileges though). Spam is not a problem, perhaps twice a month. Unmoderated questions aren't either (from my narrow perspective), but it is true that we could do with more answers, especially to the more specialized questions. And it is true that the user interface is lacking at several levels. > > I am happy to volunteer though, having no real system administration experience, there would be a learning curve, i.e. no immediate resolution. > > Bernd > >> On Nov 10, 2019, at 12:46, Jimmy McArthur wrote: >> >> Typically we give a cry for help and people pay attention and start >> moderating again for a month or so. Then it falls off of people’s >> radar again. The site needs massive improvements: better spam >> filtering, smarter suggestion engine to discourage duplicate posts, >> better tagging and search, etc... most questions go unanswered or >> unmoderated for months. >> >> I’d love it if someone took up that task, but I fear it won’t happen. >> Ifwecant find a champion, I believe we should think about winding down >> the service. In its current state it’s doing more harm than good. >> >> Thanks, >> Jimmy >> >>> On Nov 9, 2019, at 7:06 PM, Bernd Bausch wrote: >>> >>> Yes, I guess it's still useful. Traffic is not very high, perhaps 5 questions a day (if there are logs, it should be easy to confirm this), both from absolute beginners and advanced users. >>> >>> No idea what time and skill is required to maintain an Askbot site, but I am certainly curious. >>> >>> Bernd. >>> >>>> On 2019/11/10 2:07 AM, Jeremy Stanley wrote: >>>> For some reason Apache has been failing to restart during daily log >>>> rotation all week. I've manually started it again. Most of the >>>> sysadmins have been busy with other things in Shanghai (myself >>>> included), but I had a few free minutes on a layover just now. >>>> >>>> It's worth keeping in mind that the ask.openstack.org site has >>>> basically been unmaintained for years, ever since the AskBot >>>> maintainer OSF was contracting to run it disappeared. If folks are >>>> still finding the service useful, then we probably need to have a >>>> conversation about finding a maintainer for it. >>> >>> _______________________________________________ >>> OpenStack-Infra mailing list >>> OpenStack-Infra at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra From cboylan at sapwetik.org Mon Nov 11 22:37:12 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Mon, 11 Nov 2019 14:37:12 -0800 Subject: [OpenStack-Infra] Meeting Agenda for November 12, 2019 Message-ID: <96032e5e-b9c1-4a6b-80a9-de6ef2da4cc8@www.fastmail.com> We will meet in #openstack-meeting at 19:00 UTC on November 12, 2019 with this agenda: == Agenda for next meeting == * Announcements * Actions from last meeting * Specs approval * Priority Efforts (Standing meeting agenda items. Please expand if you have subtopics.) ** [http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html A Task Tracker for OpenStack] ** [http://specs.openstack.org/openstack-infra/infra-specs/specs/update-config-management.html Update Config Management] *** topic:update-cfg-mgmt *** Zuul as CD engine ** OpenDev * General topics ** PTG and Summit Recap (clarkb 20191112) *** https://etherpad.openstack.org/p/OpenDev-Shanghai-PTG-2019 ** Trusty Upgrade Progress (clarkb 20191029) *** Wiki updates ** static.openstack.org (ianw,corvus,mnaser,fungi 20191112) *** At PTG mnaser volunteered to work with us on the openstack side. *** We'll start DNS changes with static's hosted names prior to doing any mass migration. ** ask.openstack.org apache2 crashing daily during logrotate (frickler 20191111) *** Needs a volunteer to further debug and find a permanent fix *** Some logs: http://paste.openstack.org/show/785843/ * Open discussion From thierry at openstack.org Tue Nov 12 09:54:02 2019 From: thierry at openstack.org (Thierry Carrez) Date: Tue, 12 Nov 2019 10:54:02 +0100 Subject: [OpenStack-Infra] ask.openstack.org down for some days In-Reply-To: References: <027f0f07-28fa-a930-aa75-fea945e30e28@gmail.com> <67EBCE56-F2CD-4148-9742-A9DAD21051EC@gmail.com> Message-ID: Sorin Sbarnea wrote: > Having a StackOverflow kind Q&A site is of great value but only if there is enough critical mass to maintain it. Clearly ask.openstack.org is far from reaching that mass. > > I would personally see more useful to redirect users to two existing platforms that already passed the critical mass and which have active moderators, like: > > - https://stackoverflow.com for developers > - https://serverfault.com for operators +1 We could look at making ask read-only for a while, explicitly redirecting to serverfault ("openstack" tag) for new questions. > I know that on OpenStack we have good track of DIY on anything but we need to realize about what is achievable or not. Sometimes is better to focus on core business and outsource some services. We are also quite bad at stopping doing things :) -- Thierry From cboylan at sapwetik.org Wed Nov 13 00:14:23 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Tue, 12 Nov 2019 16:14:23 -0800 Subject: [OpenStack-Infra] Infra Shanghai PTG Recap Message-ID: Going to do my best to summarize the events of the PTG for the Infra team. Notes were taken at the event in this etherpad: https://etherpad.openstack.org/p/OpenDev-Shanghai-PTG-2019. Feel free to ask followup questions and I will do my best to answer them. Our PTG started with Gitea as two local Gitea maintainers were able to make it to the event for half a day to talk to us. They are aware of the performance problems we have experienced and it is important to them to get these issues fixed as we are not the only users that have noticed. There is also work in progress to implement elasticsearch hosted indexes for code search and issue searching. The person working on this for code search is no longer working on this PR so monty and jim will see if they can revive it. When asked where the Gitea project could use help it seemed these two items were top of the list. If you want to get involved they use discord for communictions: https://discordapp.com/channels/322538954119184384/322538954119184384. Other things to keep in mind with Gitea is they are pushing to be self hosted. There are web hooks that could be used to build a Gitea driver for Zuul. This may be useful if we decide to perform third party CI for Gitea when they are self hosted (and otherwise if people want to use Zuul and Gitea together). Gitea exposes Prometheus metrics which we may want to start recording in order to measure performance improvements over time as upstream merges fixes. I was unable to find a Prometheus to statsd converter though so we may need some infrastructure for this. Next up was OpenDev discussions. We talked about decoupling Zuul driven deployments from our desire to implement automation of project management for our hosted orgs. This was openstack and zuul et al could potentially start self managing project creation prior to Zuul driven CD. To do this we would likely have a cron run an ansible playbook. Then when Zuul driven CD is ready on our side have it run that playbook instead of cron. We also talked about sending out the governance email (this is fairly high on my todo list). Related to governance was formalizing the relationship a bit more with our infrastructure donors and having proper liaisons (we have informal liaisons today). Then using these liaisons to help push the benefits of having us consume their clouds (we find bugs before customers, ensure that cloud can handle fairly high level of load, etc). In our containerization efforts we heard from Monty that podman should be ready to go. There is minor concern that the Ubuntu PPA is pulling development updates rather than stable releases, but with newer software like podman this may be desirable. We'll avoid rolling it out everywhere until we have proper support for speculative testing and gating of containers with podman in our Zuul jobs. Until then we'll keep it to the review(-dev) images as they don't change often. Recently we've had trouble where our nodepool builder hosts are unable to bootstrap new images because the host platform doesn't have zypper (bionic) or can't uncompress fedora 31 RPM packages (xenial). It was pointed out that something like 50% of possible DIB + build platform choices result in being unable to build one image or another. To help address this Monty and Jim had the idea that we could bypass direct bootstrapping and simply unpack upstream docker images. Then we'd have a filesystem we can chroot into that includes all necessary tools for that platform. To do this we do need to figure out kernel management (as well as GRUB?) because container images don't typically include this data. For the static.openstack.org rebuild mnaser has volunteered to help with job changes on the OpenStack side of things. Ajaeger has also gotten this process started. That means we need to go ahead and start provisioning AFS volumes to publish into. For the DNS updates we talked about using the static.o.o hosted names as a proving ground for the larger plan to CNAME all openstack.org names into opendev.org. We don't need to batch that all up, but can if we are happy with the results with static's previously hosted content. We also talked about translation services as Zanata is no longer supported. The i18n team is interested in using weblate, we (probably me?) need to reach out to the weblate team to see if hosting an open source project the size of openstack is outside of their scope for their normal open source hosting. If it is then we can work with the OSF to see if using the paid hosting platform for weblate is viable. If not we also have the option of possibly hosting our own weblate. Finally there were discussions about Zuul specific topics. This email is already quite long so I'll keep it scoped to the OpenDev/Infra topics. If there is interest in a similar email re Zuul topics I can probably send one out to the Zuul list. Clark From jimmy at tipit.net Wed Nov 13 01:46:35 2019 From: jimmy at tipit.net (Jimmy Mcarthur) Date: Tue, 12 Nov 2019 19:46:35 -0600 Subject: [OpenStack-Infra] Infra Shanghai PTG Recap In-Reply-To: References: Message-ID: <5DCB607B.6070900@tipit.net> Just to add a bit to this... Clark Boylan wrote: > We also talked about translation services as Zanata is no longer supported. The i18n team is interested in using weblate, we (probably me?) need to reach out to the weblate team to see if hosting an open source project the size of openstack is outside of their scope for their normal open source hosting. If it is then we can work with the OSF to see if using the paid hosting platform for weblate is viable. If not we also have the option of possibly hosting our own weblate. Apparently Fedora already moved to weblate and did so through some kind of sponsorship/partnership. I've raised this flag already with OSF staff, though I think I misheard weblate as "Red Plate", I think I got the gist across. Basically Fedora was able to dedicate some time and resources to help move the project forward. As a result, weblate is helping Fedora get set up. So far, they've been working on it for a year. i18n has asked OSF to reach out to weblate to see if we can do some in-kind exchange as well so they can help us with the transition. Ian Choi estimated it would take 2 years to completely transition from Zanata to weblate. I have no idea the scope of that move, so I can't speak to that estimate. From mnaser at vexxhost.com Wed Nov 13 15:57:10 2019 From: mnaser at vexxhost.com (Mohammed Naser) Date: Wed, 13 Nov 2019 10:57:10 -0500 Subject: [OpenStack-Infra] Infra Shanghai PTG Recap In-Reply-To: References: Message-ID: On Tue, Nov 12, 2019 at 7:17 PM Clark Boylan wrote: > > Going to do my best to summarize the events of the PTG for the Infra team. Notes were taken at the event in this etherpad: https://etherpad.openstack.org/p/OpenDev-Shanghai-PTG-2019. Feel free to ask followup questions and I will do my best to answer them. > > Our PTG started with Gitea as two local Gitea maintainers were able to make it to the event for half a day to talk to us. They are aware of the performance problems we have experienced and it is important to them to get these issues fixed as we are not the only users that have noticed. There is also work in progress to implement elasticsearch hosted indexes for code search and issue searching. The person working on this for code search is no longer working on this PR so monty and jim will see if they can revive it. > > When asked where the Gitea project could use help it seemed these two items were top of the list. If you want to get involved they use discord for communictions: https://discordapp.com/channels/322538954119184384/322538954119184384. > > Other things to keep in mind with Gitea is they are pushing to be self hosted. There are web hooks that could be used to build a Gitea driver for Zuul. This may be useful if we decide to perform third party CI for Gitea when they are self hosted (and otherwise if people want to use Zuul and Gitea together). Gitea exposes Prometheus metrics which we may want to start recording in order to measure performance improvements over time as upstream merges fixes. I was unable to find a Prometheus to statsd converter though so we may need some infrastructure for this. > > Next up was OpenDev discussions. We talked about decoupling Zuul driven deployments from our desire to implement automation of project management for our hosted orgs. This was openstack and zuul et al could potentially start self managing project creation prior to Zuul driven CD. To do this we would likely have a cron run an ansible playbook. Then when Zuul driven CD is ready on our side have it run that playbook instead of cron. > > We also talked about sending out the governance email (this is fairly high on my todo list). Related to governance was formalizing the relationship a bit more with our infrastructure donors and having proper liaisons (we have informal liaisons today). Then using these liaisons to help push the benefits of having us consume their clouds (we find bugs before customers, ensure that cloud can handle fairly high level of load, etc). > > In our containerization efforts we heard from Monty that podman should be ready to go. There is minor concern that the Ubuntu PPA is pulling development updates rather than stable releases, but with newer software like podman this may be desirable. We'll avoid rolling it out everywhere until we have proper support for speculative testing and gating of containers with podman in our Zuul jobs. Until then we'll keep it to the review(-dev) images as they don't change often. > > Recently we've had trouble where our nodepool builder hosts are unable to bootstrap new images because the host platform doesn't have zypper (bionic) or can't uncompress fedora 31 RPM packages (xenial). It was pointed out that something like 50% of possible DIB + build platform choices result in being unable to build one image or another. To help address this Monty and Jim had the idea that we could bypass direct bootstrapping and simply unpack upstream docker images. Then we'd have a filesystem we can chroot into that includes all necessary tools for that platform. To do this we do need to figure out kernel management (as well as GRUB?) because container images don't typically include this data. > > For the static.openstack.org rebuild mnaser has volunteered to help with job changes on the OpenStack side of things. Ajaeger has also gotten this process started. That means we need to go ahead and start provisioning AFS volumes to publish into. For the DNS updates we talked about using the static.o.o hosted names as a proving ground for the larger plan to CNAME all openstack.org names into opendev.org. We don't need to batch that all up, but can if we are happy with the results with static's previously hosted content. Yep. I'll be waiting for the green light that the AFS volumes are ready and I'll proceed. > We also talked about translation services as Zanata is no longer supported. The i18n team is interested in using weblate, we (probably me?) need to reach out to the weblate team to see if hosting an open source project the size of openstack is outside of their scope for their normal open source hosting. If it is then we can work with the OSF to see if using the paid hosting platform for weblate is viable. If not we also have the option of possibly hosting our own weblate. > > Finally there were discussions about Zuul specific topics. This email is already quite long so I'll keep it scoped to the OpenDev/Infra topics. If there is interest in a similar email re Zuul topics I can probably send one out to the Zuul list. > > Clark > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser at vexxhost.com W. https://vexxhost.com From thierry at openstack.org Thu Nov 14 16:54:45 2019 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 14 Nov 2019 17:54:45 +0100 Subject: [OpenStack-Infra] Checking release approvals automatically Message-ID: Hi infra-folk, During the PTG in Shanghai the Release Management team discussed solving one of the remaining pain points in reviewing release requests: checking that the PTL or designated liaisons have actually +1 the request, before casting our own +2 vote. Since they change every 6 months, it's hard to remember names for the 60+ teams we have, so this manual check currently involves each of us diving into test logs, scrolling down to the place where PTLs and liaisons are listed, and then comparing them with current approvals in Gerrit. What if... we could automate that ? My proposed solution for this would be to create a specific pipeline that would trigger on specific comments (including "CodeReview"), and vote Label-PTL-approved on success. Then create a job that would run for openstack/releases changes altering deliverables/** files, and check the current change approvals against the list of PTLs and release liaisons. The job should be lightweight enough to run on the executor. With all those safeguards in place, I do not expect it to trigger significant additional load. Let me know if the idea generally sounds good or bad, or if you see simpler ways to achieve a similar results. Regards, -- Thierry Carrez (ttx) From fungi at yuggoth.org Thu Nov 14 17:14:35 2019 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 14 Nov 2019 17:14:35 +0000 Subject: [OpenStack-Infra] Checking release approvals automatically In-Reply-To: References: Message-ID: <20191114171435.ngghq2shabhrg5to@yuggoth.org> On 2019-11-14 17:54:45 +0100 (+0100), Thierry Carrez wrote: [...] > "checking that the PTL or designated liaisons have actually +1 the > request, before casting our own +2 vote." [...] Not that I have a better alternative implementation to suggest, but just to clarify it seems like the underlying problem statement is really "block merging a release request without confirmation by a corresponding PTL or release liaison" (and the Gerrit votes themselves are more of an implementation detail). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From fungi at yuggoth.org Thu Nov 14 17:23:32 2019 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 14 Nov 2019 17:23:32 +0000 Subject: [OpenStack-Infra] Checking release approvals automatically In-Reply-To: <20191114171435.ngghq2shabhrg5to@yuggoth.org> References: <20191114171435.ngghq2shabhrg5to@yuggoth.org> Message-ID: <20191114172331.ke73ytsq7lldv4x5@yuggoth.org> On 2019-11-14 17:14:35 +0000 (+0000), Jeremy Stanley wrote: > On 2019-11-14 17:54:45 +0100 (+0100), Thierry Carrez wrote: > [...] > > "checking that the PTL or designated liaisons have actually +1 the > > request, before casting our own +2 vote." > [...] > > Not that I have a better alternative implementation to suggest, but > just to clarify it seems like the underlying problem statement is > really "block merging a release request without confirmation by a > corresponding PTL or release liaison" (and the Gerrit votes > themselves are more of an implementation detail). Or is it maybe "avoid spending release team review time on release requests until a corresponding PTL/liaison has confirmed them" rather than blocking merge? -- 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 thierry at openstack.org Fri Nov 15 13:48:11 2019 From: thierry at openstack.org (Thierry Carrez) Date: Fri, 15 Nov 2019 14:48:11 +0100 Subject: [OpenStack-Infra] Checking release approvals automatically In-Reply-To: <20191114172331.ke73ytsq7lldv4x5@yuggoth.org> References: <20191114171435.ngghq2shabhrg5to@yuggoth.org> <20191114172331.ke73ytsq7lldv4x5@yuggoth.org> Message-ID: <731ff5d2-940e-814f-37b1-71671313964c@openstack.org> Jeremy Stanley wrote: > On 2019-11-14 17:14:35 +0000 (+0000), Jeremy Stanley wrote: >> On 2019-11-14 17:54:45 +0100 (+0100), Thierry Carrez wrote: >> [...] >>> "checking that the PTL or designated liaisons have actually +1 the >>> request, before casting our own +2 vote." >> [...] >> >> Not that I have a better alternative implementation to suggest, but >> just to clarify it seems like the underlying problem statement is >> really "block merging a release request without confirmation by a >> corresponding PTL or release liaison" (and the Gerrit votes >> themselves are more of an implementation detail). > > Or is it maybe "avoid spending release team review time on release > requests until a corresponding PTL/liaison has confirmed them" > rather than blocking merge? I'd say "Have a way to tell when the PTL/liaison approved the request without having to manually check who the PTL and liaisons are". The vote should not be blocking since we'd likely override it in corner cases. Regarding implementation, the benefit of using a specific label is that it would (also) appear in dashboards. -- Thierry Carrez (ttx) From cboylan at sapwetik.org Tue Nov 19 00:21:54 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Mon, 18 Nov 2019 16:21:54 -0800 Subject: [OpenStack-Infra] Meeting Agenda for November 19, 2019 Message-ID: <40237501-ad9c-4531-8da5-064a498571bd@www.fastmail.com> Hello, We will have our weekly team meeting tomorrow, November 19 at 19:00UTC in #openstack-meeting. Note that I may be a little late to the meeting myself as I have poorly scheduled a dentist visit with the recent DST change. == Agenda for next meeting == * Announcements * Actions from last meeting * Specs approval * Priority Efforts (Standing meeting agenda items. Please expand if you have subtopics.) ** [http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html A Task Tracker for OpenStack] ** [http://specs.openstack.org/openstack-infra/infra-specs/specs/update-config-management.html Update Config Management] *** topic:update-cfg-mgmt *** Zuul as CD engine ** OpenDev *** LetsEncrypt issued cert for opendev.org https://review.opendev.org/#/c/694181/12 *** Possible gitea/go-git bug in current version of gitea we are running https://storyboard.openstack.org/#!/story/2006849 * General topics ** Trusty Upgrade Progress (clarkb 20191119) *** Wiki updates ** static.openstack.org (ianw,corvus,mnaser,fungi 20191119) *** Ajaeger started writing some changes https://review.opendev.org/#/q/topic:static-services+(status:open+OR+status:merged) *** Infra-root needs to create AFS volumes. ** ask.openstack.org apache2 crashing daily during logrotate (clarkb 20191119) *** Needs a volunteer to further debug and find a permanent fix *** Some logs: http://paste.openstack.org/show/785843/ *** Any progress on this? ** Installing tox with py3 in base images runs some envs with py3 now (frickler 20191115) *** See http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2019-11-15.log.html#t2019-11-15T11:10:57 ff. * Open discussion From mkolesni at redhat.com Wed Nov 20 10:22:44 2019 From: mkolesni at redhat.com (Mike Kolesnik) Date: Wed, 20 Nov 2019 12:22:44 +0200 Subject: [OpenStack-Infra] Adding submariner to opendev.org Message-ID: Hi, We would like to add the submariner repositories currently hosted at [1] to opendev.org. The website itself doesn't have much information on how to go about it. Would it be possible? And if so, is there some guide to follow? [1] https://github.com/submariner-io/ -- Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From paye600 at gmail.com Wed Nov 20 11:43:45 2019 From: paye600 at gmail.com (Roman Gorshunov) Date: Wed, 20 Nov 2019 12:43:45 +0100 Subject: [OpenStack-Infra] Adding submariner to opendev.org In-Reply-To: References: Message-ID: Hello Mike, You probably would start with Project Creator's Guide, which is published here [0]. [0] https://docs.openstack.org/infra/manual/creators.html Best regards, -- Roman Gorshunov From mnaser at vexxhost.com Wed Nov 20 15:24:35 2019 From: mnaser at vexxhost.com (Mohammed Naser) Date: Wed, 20 Nov 2019 10:24:35 -0500 Subject: [OpenStack-Infra] Adding submariner to opendev.org In-Reply-To: References: Message-ID: On Wed, Nov 20, 2019 at 5:25 AM Mike Kolesnik wrote: > > Hi, > > We would like to add the submariner repositories currently hosted at [1] to opendev.org. That's great. I've been a big fan of Submariner for quite sometime and I'd love to help you out in bringing it into opendev.org I would be happy to help you out in that effort over IRC if you'd like (or perhaps some other method of communication if you'd like). > The website itself doesn't have much information on how to go about it. > > Would it be possible? > And if so, is there some guide to follow? > > [1] https://github.com/submariner-io/ > > -- > Regards, > Mike > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra From iwienand at redhat.com Mon Nov 25 05:02:13 2019 From: iwienand at redhat.com (Ian Wienand) Date: Mon, 25 Nov 2019 16:02:13 +1100 Subject: [OpenStack-Infra] [zuul-jobs] configure-mirrors: deprecate mirroring configuration for easy_install Message-ID: <20191125050213.GA1161931@fedora19.localdomain> Hello, Today I force-merged [5] to avoid widespread gate breakage. Because the change is in zuul-jobs, we have a policy of annoucing deprecations. I've written the following but not sent it to zuul-announce (per policy) yet, as I'm not 100% confident in the explanation. I'd appreciate it if, once proof-read, someone could send it out (modified or otherwise). Thanks, -i -- Hello, The recent release of setuptools 42.0.0 has broken the method used by the configure-mirrors role to ensure easy_install (the older method of install packages, before pip became in widespread use [1]) would only access the PyPi mirror. The prior mirror setup code would set the "allow_hosts" whitelist to the mirror host exclusively in pydistutils.cfg. This would avoid easy_install "leaking" access outside the specified mirror. Change [2] in setuptools means that pip is now used to fetch packages. Since it does not implement the constraints of the "allow_hosts" setting, specifying this option has become an error condition. This is reported as: the `allow-hosts` option is not supported 'when using pip to install requirements It has been pointed out [3] that this prior code would break any dependency_links [4] that might be specified for the package (as the external URLs will not match the whitelist). Overall, there is no desire to work-around this behaviour as easy_install is considered deprecated for any current use. In short, this means the only solution is to remove the now conflicting configuration from pydistutils.cfg. Due to the urgency of this update, it has been merged with [5] before our usual 2-week deprecation notice. The result of this is that older setuptools (perhaps in a virtualenv) with jobs still using easy_install may not correctly access the specified mirror. Assuming jobs have access to PyPi they would still work, although without the benefits of a local mirror. If such jobs are firewalled from usptream they may now fail. We consider the chance of jobs using this legacy install method in this situation to be very low. Please contact zuul-discuss [6] with any concerns. We now return you to your regularly scheduled programming :) [1] https://packaging.python.org/discussions/pip-vs-easy-install/ [2] https://github.com/pypa/setuptools/commit/d6948c636f5e657ac56911b71b7a459d326d8389 [3] https://github.com/pypa/setuptools/issues/1916 [4] https://python-packaging.readthedocs.io/en/latest/dependencies.html [5] https://review.opendev.org/695821 [6] http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss From ssbarnea at redhat.com Mon Nov 25 12:15:56 2019 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Mon, 25 Nov 2019 12:15:56 +0000 Subject: [OpenStack-Infra] helping openstack-infra Message-ID: <577CD532-6F82-4CF2-8FC0-0094A3B170EE@redhat.com> Hi! In response to https://governance.openstack.org/tc/reference/upstream-investment-opportunities/2019/community-infrastructure-sysadmins.html would like to state that I am more than willing to help the openstack-infra team with sysadmin tasks needed. I am fully aware this will require me investing more time on infra specific tasks but I am glad it do have the support from my organization for doing this. As I was really happy about my last year experience with others from infra and I valued a lot their help on various tasks, I want to also return the favor and help with other chores or features we may need do to make our CI even better. So mainly, just let me know what needs should be done? Thanks Sorin Sbarnea Red Hat TripleO CI From pabelanger at redhat.com Mon Nov 25 13:38:55 2019 From: pabelanger at redhat.com (Paul Belanger) Date: Mon, 25 Nov 2019 08:38:55 -0500 Subject: [OpenStack-Infra] [zuul-jobs] configure-mirrors: deprecate mirroring configuration for easy_install In-Reply-To: <20191125050213.GA1161931@fedora19.localdomain> References: <20191125050213.GA1161931@fedora19.localdomain> Message-ID: <20191125133855.GA13793@localhost.localdomain> On Mon, Nov 25, 2019 at 04:02:13PM +1100, Ian Wienand wrote: > Hello, > > Today I force-merged [5] to avoid widespread gate breakage. Because > the change is in zuul-jobs, we have a policy of annoucing > deprecations. I've written the following but not sent it to > zuul-announce (per policy) yet, as I'm not 100% confident in the > explanation. > > I'd appreciate it if, once proof-read, someone could send it out > (modified or otherwise). > > Thanks, > Greetings! Rather then force merge, and potential break other zuul installs. What about a new feature flag, that was still enabled but have openstack base jobs disabled? This would still allow older versions of setuptools to work I would guess? That said, ansible Zuul is not affected as we currently fork configure-mirrors for our open puproses, I'll check now that we are also not affected. > -i > > -- > > Hello, > > The recent release of setuptools 42.0.0 has broken the method used by > the configure-mirrors role to ensure easy_install (the older method of > install packages, before pip became in widespread use [1]) would only > access the PyPi mirror. > > The prior mirror setup code would set the "allow_hosts" whitelist to > the mirror host exclusively in pydistutils.cfg. This would avoid > easy_install "leaking" access outside the specified mirror. > > Change [2] in setuptools means that pip is now used to fetch packages. > Since it does not implement the constraints of the "allow_hosts" > setting, specifying this option has become an error condition. This > is reported as: > > the `allow-hosts` option is not supported 'when using pip to install requirements > > It has been pointed out [3] that this prior code would break any > dependency_links [4] that might be specified for the package (as the > external URLs will not match the whitelist). Overall, there is no > desire to work-around this behaviour as easy_install is considered > deprecated for any current use. > > In short, this means the only solution is to remove the now > conflicting configuration from pydistutils.cfg. Due to the urgency of > this update, it has been merged with [5] before our usual 2-week > deprecation notice. > > The result of this is that older setuptools (perhaps in a virtualenv) > with jobs still using easy_install may not correctly access the > specified mirror. Assuming jobs have access to PyPi they would still > work, although without the benefits of a local mirror. If such jobs > are firewalled from usptream they may now fail. We consider the > chance of jobs using this legacy install method in this situation to > be very low. > > Please contact zuul-discuss [6] with any concerns. > > We now return you to your regularly scheduled programming :) > > [1] https://packaging.python.org/discussions/pip-vs-easy-install/ > [2] https://github.com/pypa/setuptools/commit/d6948c636f5e657ac56911b71b7a459d326d8389 > [3] https://github.com/pypa/setuptools/issues/1916 > [4] https://python-packaging.readthedocs.io/en/latest/dependencies.html > [5] https://review.opendev.org/695821 > [6] http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss > > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra From cboylan at sapwetik.org Mon Nov 25 17:23:15 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Mon, 25 Nov 2019 09:23:15 -0800 Subject: [OpenStack-Infra] =?utf-8?q?=5Bzuul-jobs=5D_configure-mirrors=3A_?= =?utf-8?q?deprecate_mirroring_configuration_for_easy=5Finstall?= In-Reply-To: <20191125133855.GA13793@localhost.localdomain> References: <20191125050213.GA1161931@fedora19.localdomain> <20191125133855.GA13793@localhost.localdomain> Message-ID: <5f4946ad-49be-4dc7-b7c2-d1e4824f2b53@www.fastmail.com> On Mon, Nov 25, 2019, at 5:38 AM, Paul Belanger wrote: > On Mon, Nov 25, 2019 at 04:02:13PM +1100, Ian Wienand wrote: > > Hello, > > > > Today I force-merged [5] to avoid widespread gate breakage. Because > > the change is in zuul-jobs, we have a policy of annoucing > > deprecations. I've written the following but not sent it to > > zuul-announce (per policy) yet, as I'm not 100% confident in the > > explanation. > > > > I'd appreciate it if, once proof-read, someone could send it out > > (modified or otherwise). > > > > Thanks, > > > Greetings! > > Rather then force merge, and potential break other zuul installs. What > about a new feature flag, that was still enabled but have openstack base > jobs disabled? This would still allow older versions of setuptools to > work I would guess? > I think the ship has sailed and the change has already been force merged. That said setuptools isn't something that you can easily control versioning of. For example when you create a virtualenv the version of setuptools in the virtualenv is automatically updated to the latest version. For this reason I think the merge was the best course of action. > That said, ansible Zuul is not affected as we currently fork > configure-mirrors for our open puproses, I'll check now that we are also > not affected. > From cboylan at sapwetik.org Mon Nov 25 17:48:20 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Mon, 25 Nov 2019 09:48:20 -0800 Subject: [OpenStack-Infra] helping openstack-infra In-Reply-To: <577CD532-6F82-4CF2-8FC0-0094A3B170EE@redhat.com> References: <577CD532-6F82-4CF2-8FC0-0094A3B170EE@redhat.com> Message-ID: On Mon, Nov 25, 2019, at 4:15 AM, Sorin Sbarnea wrote: > Hi! > > In response to > https://governance.openstack.org/tc/reference/upstream-investment-opportunities/2019/community-infrastructure-sysadmins.html would like to state that I am more than willing to help the openstack-infra team with sysadmin tasks needed. > > I am fully aware this will require me investing more time on infra > specific tasks but I am glad it do have the support from my > organization for doing this. > > As I was really happy about my last year experience with others from > infra and I valued a lot their help on various tasks, I want to also > return the favor and help with other chores or features we may need do > to make our CI even better. > > So mainly, just let me know what needs should be done? Current priority efforts include OpenDev-ification of services and updating config management for puppet managed services to ansible and containers. To opendevify services we are updating them to be hosted at opendev.org domains as well as updating theming if necessary to incorporate the opendev logo and color scheme. In many cases we want to install redirects from the old openstack.org names to the new opendev.org name. For services with SSL/TLS this is likely the trickiest bit of the conversion as our plan is to use LetsEncrypt for opendev.org names. Thankfully, we've sorted out a plan [0] for managing openstack.org names with LetsEncrypt certs as well. For the config management updates we've been converting deployments of services from puppet to ansible and in many cases having ansible drive docker-compose to do the actual deployments. This process typically starts by determining if we can use an upstream image or not. If not we add a Dockerfile and corresponding image build jobs to the opendev/system-config repo. Then we can add jobs to test deployment of those containers and finally deploy to production via this method. The great thing about this process is we can fully test the deployment easily and there are many examples of that in system-config now (see Gitea). Whether or not it makes more sense to convert a service to opendev or update its config management first, likely depends on how difficult it is to set up SSL/TLS for multiple domains. My hunch is that for most services doing the config management update with the SSL/TLS needs in mind is likely easiest. If you'd like a concrete place to start I would suggest taking a service like ethercalc or etherpad, udpate its config management to ansible + docker-compose, implement test jobs as others have, then when all that is happy you can work with an infra root to replace our deployment of these services in production. Then if we haven't already done it in conjunction with the config management updates we can update the SSL/TLS setup and convert to an opendev service. Another different but slightly related OpenDev topic is to start implementing tooling so that top level orgs can manage their repositories directly. At the PTG we discussed doing this via a meta project per repo that determines who is allowed to make those changes, then via ansible of some sort implement those updates when the appropriate approvers have ACKed the change. This likely needs a bit of design work just to be sure we are all in agreement of the plan. A lightweight spec would be helpful. [0] https://opendev.org/opendev/infra-specs/src/branch/master/specs/retire-static.rst#opendev-infrastructure-migration Hope this helps. Feel free to dig in or ask questions and I'll do my best to expand on this topic. Clark From fungi at yuggoth.org Mon Nov 25 18:04:13 2019 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 25 Nov 2019 18:04:13 +0000 Subject: [OpenStack-Infra] helping openstack-infra In-Reply-To: References: <577CD532-6F82-4CF2-8FC0-0094A3B170EE@redhat.com> Message-ID: <20191125180413.2c56akj4yyr3xp6c@yuggoth.org> On 2019-11-25 09:48:20 -0800 (-0800), Clark Boylan wrote: [...] > For the config management updates we've been converting > deployments of services from puppet to ansible [...] It also merits pointing out that this is in part driven by our inability to easily apply our existing Puppet manifests with any of the versions of Puppet available for newer operating systems like Ubuntu 18.04 LTS, so if there is a desire to do something which needs a newer operating system than (rapidly aging) Ubuntu 16.04 LTS, replacing the Puppet automation with Ansible is a necessary prerequisite. -- 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 Mon Nov 25 20:21:56 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Mon, 25 Nov 2019 12:21:56 -0800 Subject: [OpenStack-Infra] Meeting Agenda for November 26, 2019 Message-ID: We will meet in #openstack-meeting at 19:00UTC November 26 with this agenda: == Agenda for next meeting == * Announcements ** Holiday week for those in the USA * Actions from last meeting * Specs approval * Priority Efforts (Standing meeting agenda items. Please expand if you have subtopics.) ** [http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html A Task Tracker for OpenStack] ** [http://specs.openstack.org/openstack-infra/infra-specs/specs/update-config-management.html Update Config Management] *** topic:update-cfg-mgmt *** Zuul as CD engine ** OpenDev *** Possible gitea/go-git bug in current version of gitea we are running https://storyboard.openstack.org/#!/story/2006849 * General topics ** Trusty Upgrade Progress (clarkb 20191126) *** Wiki updates ** static.openstack.org (ianw,corvus,mnaser,fungi 20191126) *** Infra-root needs to create AFS volumes. ** Installing tox with py3 in base images runs some envs with py3 now - update (ianw 20191125) *** http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010957.html ** Submariner on opendev.org (dgroisma, mkolesni) ** dib/nodepool container (ianw 20191125) *** ianw to do writeup before ** Discussion on retiring services that are largely unmaintained or unused (clarkb 20191126) *** Want to start this discussion as services like Ask are barely on life support and we should probably clean them up. *** https://etherpad.openstack.org/infra-service-list * Open discussion From iwienand at redhat.com Tue Nov 26 06:31:07 2019 From: iwienand at redhat.com (Ian Wienand) Date: Tue, 26 Nov 2019 17:31:07 +1100 Subject: [OpenStack-Infra] Creating OpenDev control-plane docker images and naming Message-ID: <20191126063107.GB1161931@fedora19.localdomain> Hello, I'm trying to get us to a point where we can use nodepool container images in production, particularly because I want to use updated tools available in later distributions than our current Xenial builders [1] We have hit the hardest problem; naming :) To build a speculative nodepool-builder container image that is suitable for a CI job (the prerequisite for production), we need to somehow layer openstacksdk, diskimage-builder and finally nodepool itself into one image for testing. [2] These all live in different namespaces, and the links between them are not always clear. Maybe a builder doesn't need diskimage-builder if images come from elsewhere. Maybe a launcher doesn't need openstacksdk if it's talking to some other cloud. This becomes weird when the zuul/nodepool-builder image depends on opendev/python-base but also openstack/diskimage-builder and openstack/openstacksdk. You've got 3 different namespaces crossing with no clear indication of what is supposed to work together. I feel like we've been (or at least I have been) thinking that each project will have *a* Dockerfile that produces some canonical image. I think I've come to the conclusion this is infeasible. There can't be a single container that suits everyone, and indeed this isn't the Zen of containers anyway. What I would propose is that projects do *not* have a single, top-level Dockerfile, but only (potentially many) specifically name-spaced versions. So for example, everything in the opendev/ namespace will be expected to build from opendev/python-base. Even though dib, openstacksdk and zuul come from difference source-repo namespaces, it will make sense to have: opendev/python-base +-> opendev/openstacksdk +-> opendev/diskimage-builder +-> opendev/nodepool-builder because these containers are expected to work together as the opendev control plane containers. Since opendev/nodepool-builder is defined as an image that expected to make RAX compatible, OpenStack uploadable images it makes logical sense for it to bundle the kitchen sink. I would expect that nodepool would also have a Docker.zuul file to create images in the zuul/ namespace as the "reference" implementation. Maybe that looks a lot like Dockerfile.opendev -- but then again maybe it makes different choices and does stuff like Windows support etc. that the opendev ecosystem will not be interested in. You can still build and test these images just the same; just we'll know they're targeted at doing something different. As an example: https://review.opendev.org/696015 - create opendev/openstacksdk image https://review.opendev.org/693971 - create opendev/diskimage-builder (a nodepool change will follow, but it's a bit harder as it's cross-tenant so projects need to be imported). Perhaps codifying that there's no such thing as *a* Dockerfile, and possibly rules about what happens in the opendev/ namespace is spec worthy, I'm not sure. I hope this makes some sense! Otherwise, I'd be interested in any and all ideas of how we basically convert the nodepool-functional-openstack-base job to containers (that means, bring up a devstack, and test nodepool, dib & openstacksdk with full Depends-On: support to make sure it can build, upload and boot). I consider that a pre-requisite before we start rolling anything out in production. -i [1] I know we have ideas to work around the limitations of using host tools to build images, but one thing at a time! :) [2] I started looking at installing these together from a Dockerfile in system-config. The problem is that you have a "build context", basically the directory the Dockerfile is in and everything under it. You can't reference anything outside this. This does not play well with Zuul, which has checked out the code for dib, openstacksdk & nodepool into three different sibling directories. So to speculatively build them together, you have to start copying Zuul checkouts of code underneath your system-config Dockerfile which is crazy. It doesn't use any of the speculative build registry stuff and just feels wrong because you're not building small parts ontop of each other, as Docker is designed to do. I still don't really know how it will work across all the projects for testing either. https://review.opendev.org/696000 From a.hosseinbeigi at parsonline.com Wed Nov 27 13:42:46 2019 From: a.hosseinbeigi at parsonline.com (Ali Hossein Beigi) Date: Wed, 27 Nov 2019 13:42:46 +0000 Subject: [OpenStack-Infra] Problem with Openstack Message-ID: Hi, Ive installed openstack (train) via MAAS and juju (Conjure-up, nova-kvm ). Every thing works fine but I have problem with instance console. When I click on console the message "Instance Console Unable to load console. Please reload page to try again." appears. Is there anyone to helm me? Br, -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Wed Nov 27 17:41:31 2019 From: cboylan at sapwetik.org (Clark Boylan) Date: Wed, 27 Nov 2019 09:41:31 -0800 Subject: [OpenStack-Infra] Problem with Openstack In-Reply-To: References: Message-ID: <0bf24d22-be9d-4680-8d08-8d10afb0c3ea@www.fastmail.com> On Wed, Nov 27, 2019, at 5:42 AM, Ali Hossein Beigi wrote: > > Hi, > > Ive installed openstack (train) via MAAS and juju (Conjure-up, nova-kvm ). > > Every thing works fine but I have problem with instance console. > > When I click on console the message “Instance Console Unable to load > console. Please reload page to try again.” appears. > > Is there anyone to helm me? This mailing list is used to coordinate the efforts to produce OpenStack software: things like Gerrit and Zuul. Unfortunately this means we are not in a great position to help debug OpenStack installations. For that you should send mail to openstack-discuss at lists.openstack.org instead. Clark From donny at fortnebula.com Wed Nov 27 17:55:55 2019 From: donny at fortnebula.com (Donny Davis) Date: Wed, 27 Nov 2019 12:55:55 -0500 Subject: [OpenStack-Infra] Problem with Openstack In-Reply-To: <0bf24d22-be9d-4680-8d08-8d10afb0c3ea@www.fastmail.com> References: <0bf24d22-be9d-4680-8d08-8d10afb0c3ea@www.fastmail.com> Message-ID: You can also jump on irc and maybe check out #openstack-mentoring On Wed, Nov 27, 2019 at 12:50 PM Clark Boylan wrote: > On Wed, Nov 27, 2019, at 5:42 AM, Ali Hossein Beigi wrote: > > > > Hi, > > > > Ive installed openstack (train) via MAAS and juju (Conjure-up, nova-kvm > ). > > > > Every thing works fine but I have problem with instance console. > > > > When I click on console the message “Instance Console Unable to load > > console. Please reload page to try again.” appears. > > > > Is there anyone to helm me? > > This mailing list is used to coordinate the efforts to produce OpenStack > software: things like Gerrit and Zuul. Unfortunately this means we are not > in a great position to help debug OpenStack installations. For that you > should send mail to openstack-discuss at lists.openstack.org instead. > > Clark > > _______________________________________________ > OpenStack-Infra mailing list > OpenStack-Infra at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra -- ~/DonnyD C: 805 814 6800 "No mission too difficult. No sacrifice too great. Duty First" -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.hosseinbeigi at gmail.com Thu Nov 28 06:47:02 2019 From: ali.hosseinbeigi at gmail.com (Ali Hosseinbeigi) Date: Thu, 28 Nov 2019 10:17:02 +0330 Subject: [OpenStack-Infra] Openstack console not working Message-ID: Hi, Ive installed openstack (train) via MAAS and juju (Conjure-up, nova-kvm ). Every thing works fine but I have problem with instance console. When I click on console the message “Instance Console Unable to load console. Please reload page to try again.” appears. Is there anyone to helm me? Br, -------------- next part -------------- An HTML attachment was scrubbed... URL: